[parisc-linux] Proposal for git tree management

[parisc-linux] Proposal for git tree management

[Matthew Wilcox]

I think the git development model is working out pretty well.  We've
committed around 100 patches to our tree since we switched to using git.
Most of those have gone upstream, mostly through Kyle's hard work.

However, figuring out what is left to merge is getting harder.  Due to
trying to keep Linus' tree clean, the commit that goes into our
development tree isn't the same one that ends up in his tree.  So it's
hard to tell what's been committed and what hasn't.  Don't get me wrong,
it's still an improvement over using CVS, but I think we could use Git
more effectively.

Right now, git-log linus..origin shows all the patches we've ever
committed, regardless of whether they've been merged.  A graphic would
make this easier:

A -> B -> C -> D' -> E
 \-> D -------/-> F --\->G

This illustrates Linus' tree at time A.  We clone his tree and make
change D, and eventually it ends up in Linus' tree as D' (after changes
B and C have happened in his tree).  At point G, git-log linus..master
shows change D, even though it was already merged to the linus tree.

The obvious solution is to rebase the tree.  We start a new origin
branch from point E and pull commit F onto it as commit F'.  But if we
delete the former origin branch we lose our history.  So I'd like to
rename it (probably to something like devel-2006-10-07), and create a
new origin.  That way we can still go back and find our history, and
still keep git-log useful.

I'm concerned we may get an unreasonable number of branches using this
scheme.  Using a date (rather than a cardinal) helps understand how
relevant a branch may be.

Anyway, comments, suggestions, alternatives, abuse?
_______________________________________________
parisc-linux mailing list
parisc-linux@lists.parisc-linux.org
http://lists.parisc-linux.org/mailman/listinfo/parisc-linux

Re: [parisc-linux] Proposal for git tree management

[Grant Grundler]

On Sat, Oct 07, 2006 at 06:41:52PM -0600, Matthew Wilcox wrote:
> 
> I think the git development model is working out pretty well.  We've
> committed around 100 patches to our tree since we switched to using git.
> Most of those have gone upstream, mostly through Kyle's hard work.

Agreed - many kudos/thanks to kyle!

...
> The obvious solution is to rebase the tree.  We start a new origin
> branch from point E and pull commit F onto it as commit F'.  But if we
> delete the former origin branch we lose our history.

I don't care so much about "our" history. I mostly care
about the commit message(s) that end up in linus' tree.

> I'm concerned we may get an unreasonable number of branches using this
> scheme.  Using a date (rather than a cardinal) helps understand how
> relevant a branch may be.

I think anything is ok if it helps us determine what's missing
from linus' tree and ship those patches (when ready) to him.
I'll probably end up ignoring the branches anyway.

Please just make it "KISS". I'm only using git a few times per month
and it's just not enough to do anything complicated right now.
My goal is any git commits I make can (indirectly via kyle) go
to linus without the confusion you described.

thanks!
grant
_______________________________________________
parisc-linux mailing list
parisc-linux@lists.parisc-linux.org
http://lists.parisc-linux.org/mailman/listinfo/parisc-linux

Re: [parisc-linux] Proposal for git tree management

[Thibaut VARENE]

On 10/9/06, Grant Grundler <grundler@parisc-linux.org> wrote:
> On Sat, Oct 07, 2006 at 06:41:52PM -0600, Matthew Wilcox wrote:
> >
> > I think the git development model is working out pretty well.  We've
> > committed around 100 patches to our tree since we switched to using git.
> > Most of those have gone upstream, mostly through Kyle's hard work.
>
> Agreed - many kudos/thanks to kyle!

All hail Kyle indeed :)

> > The obvious solution is to rebase the tree.  We start a new origin
> > branch from point E and pull commit F onto it as commit F'.  But if we
> > delete the former origin branch we lose our history.
>
> I don't care so much about "our" history. I mostly care
> about the commit message(s) that end up in linus' tree.

Despite not being terribly active nowadays, I'd like to contrast this
view a little bit. "Our" history has proven very useful (at least to
me) in a number of cases (comes to mind the development of gscps2
input driver based on evolutions of hp_kbd.c and friends) and I
remember quite a few occasion where it was actually interesting to be
able to track down who committed any given bit of code (for some
reason I remember tracking down prumpf's commits in some well known
locking routine, among other things).

On a more "play the devil's advocate" side of things, i believe it's
of great importance to be able to track down when any given code was
first introduced and who committed it. Copyright issues such as the
SCO-induced shite are a good demonstration that being able to quickly
assert copyright/genealogy on any given bit is a good thing...

> > I'm concerned we may get an unreasonable number of branches using this
> > scheme.  Using a date (rather than a cardinal) helps understand how
> > relevant a branch may be.
>
> I think anything is ok if it helps us determine what's missing
> from linus' tree and ship those patches (when ready) to him.
> I'll probably end up ignoring the branches anyway.
>
> Please just make it "KISS". I'm only using git a few times per month
> and it's just not enough to do anything complicated right now.
> My goal is any git commits I make can (indirectly via kyle) go
> to linus without the confusion you described.

I'd also strongly support a KISS approach. Yet I was under the
impression that rebasing the tree would break any subsequent 'git
pull' on older trees, is that right?

Along those lines I'm also thinking that assuming we want to revive
our kernel autobuilder, we probably want to think of a git tree
architecture that will induce minimal man handling of the autobuilder
once started...

Just my 2c, well aware that I'm not paying enough attention to our
development process lately, and thus I may be full of sh*t  ;^)

HTH

T-Bone

-- 
Thibaut VARENE
http://www.parisc-linux.org/~varenet/
_______________________________________________
parisc-linux mailing list
parisc-linux@lists.parisc-linux.org
http://lists.parisc-linux.org/mailman/listinfo/parisc-linux

Re: [parisc-linux] Proposal for git tree management

[Matthew Wilcox]

On Mon, Oct 09, 2006 at 01:39:58PM +0200, Thibaut VARENE wrote:
> >Please just make it "KISS". I'm only using git a few times per month
> >and it's just not enough to do anything complicated right now.
> >My goal is any git commits I make can (indirectly via kyle) go
> >to linus without the confusion you described.
> 
> I'd also strongly support a KISS approach. Yet I was under the
> impression that rebasing the tree would break any subsequent 'git
> pull' on older trees, is that right?

Yes.  And no.  It depends ;-)

If your refspec looks like this:

$ cat .git/remotes/origin 
URL: ssh://git.parisc-linux.org/var/git/linux-2.6.git
Pull: refs/heads/master:refs/heads/origin
Pull: refs/heads/linus:refs/heads/linus

then it's going to whinge about not being able to fast-forward.
However, if you add a +, like this:

Pull: +refs/heads/master:refs/heads/origin

then it'll update the ref, even if it's not a fast-forward.

> Along those lines I'm also thinking that assuming we want to revive
> our kernel autobuilder, we probably want to think of a git tree
> architecture that will induce minimal man handling of the autobuilder
> once started...

I agree, though I wouldn't expect rebasing to be a common operation
(every 2-3 months), it would suck to inadvertently break the autobuilder.
_______________________________________________
parisc-linux mailing list
parisc-linux@lists.parisc-linux.org
http://lists.parisc-linux.org/mailman/listinfo/parisc-linux

Re: [parisc-linux] Proposal for git tree management

[Kyle McMartin]

On Mon, Oct 09, 2006 at 12:06:52PM -0600, Matthew Wilcox wrote:
> I agree, though I wouldn't expect rebasing to be a common operation
> (every 2-3 months), it would suck to inadvertently break the autobuilder.
>

if we queue the autobuilder based on tags, even if we rebase, we will never
have an issue, since git-prune will only remove unreachable commits. as long
as we have a tag for the pre-rebased commits, they'll never be removed, which
is the desired behaviour (since the autobuilder will always be able to check
them out.)

cheers,
	kyle
_______________________________________________
parisc-linux mailing list
parisc-linux@lists.parisc-linux.org
http://lists.parisc-linux.org/mailman/listinfo/parisc-linux