Re: Re: Re: Re: GIT license (Re: Re: Re: Re: Re: [ANNOUNCE] git-pasky-0.1)

[Petr Baudis <pasky@ucw.cz>]

Dear diary, on Tue, Apr 12, 2005 at 10:39:40AM CEST, I got a letter
where Geert Uytterhoeven <geert@linux-m68k.org> told me that...
> On Tue, 12 Apr 2005, Petr Baudis wrote:
..snip..
> > Basically, when you look at merge(1) :
> > 
> > SYNOPSIS
> >        merge [ options ] file1 file2 file3
> > DESCRIPTION
> >        merge  incorporates  all  changes that lead from file2 to file3
> > into file1.
> > 
> > The only big problem is how to guess the best file2 when you give it
> > file3 and file1.
> 
> That's either the point just before you started modifying the file, or your
> last merge point. Sounds simple, but if your SCM system doesn't track merges,
> your SOL...

Well, yes, but the last merge point search may not be so simple:

A --1---2----6---7
B    \   `-4-.  /
C     `-3-----5'

Now, when at 7, your last merge point is not 1, but 2.

What I have proposed at the git mailing list was to have simple merging
tracking - merges/branch1/branch2 directory structure which would store
merges from branch2 to branch1. Then, when merging say to branch3, you
traverse all of them and if any of the branch1/* commits is newer than
branch3/*, you update it.

The disadvantage is that you now need to strictly use gitmerge.sh to do
the merges - Linus' revtree solution is nicer in the regard that it
works without any explicit bookkeeping, and tracks any merges properly
recorded with commit-file; it is more complex and more expensive,
though.

-- 
				Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
98% of the time I am right. Why worry about the other 3%.
-
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/