Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1290051

Stupid git question...

Show all headers | View raw

[Multipart message — attachments visible in raw view] - view raw

OK.. Here's the situation - I've got several sets of patches I'll probably
be cooking over the holidays, and I'm planning to base on linux-next (though
any other moving-target base has the same issues).

What I *want* to accomplish:

At any given point, linux-next may or may not have breakages that cause
me grief (anything from compile issues to can't-boot-to-multiuser crashes).
What's the *clean* way to accomplish the following:

<assume I have a current linux-next/master copied to my box>

git branch --track linux-next/master local-fixes

git branch --track local-fixes project-1
git branch --track local-fixes project-2
git branch --track local-fixes project-3

Basically, have some way to keep track of the small integer number of
local things that I don't want escaping if I do a 'git format-patch project-2'
or other similar thing, and so I only have to deal with doing the local
fix once.  Just dropping commits on top of linux-next doesn't seem right, as
it could get ugly the next 'git remote update'.

What are maintainers doing to deal with similar issues, where you need to
make sure that your test builds in fact contain unrelated commits needed for
the build to be testable?

Back to linux.kernel | Previous | Next — Next in thread | Find similar | Unroll thread

Thread

Stupid git question... Valdis Kletnieks <Valdis.Kletnieks@vt.edu> - 2015-12-12 02:30 +0100
  Re: Stupid git question... Jeff Kirsher <jeffrey.t.kirsher@intel.com> - 2015-12-12 09:10 +0100

csiph-web