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

Groups > linux.kernel > #1290051 > unrolled thread

Stupid git question...

Back to article view | Back to linux.kernel

Contents

  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

#1290051 — Stupid git question...

[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?

[toc] | [next] | [standalone]

#1290138

On Fri, Dec 11, 2015 at 5:27 PM, Valdis Kletnieks
<Valdis.Kletnieks@vt.edu> wrote:
> 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?

Look at stacked git (stgit), it can resolve a number of the issues you
seem to be running into.  It makes it easy to modify patches in a
series and you can easily update your tree.

-- 
Cheers,
Jeff
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web