Re: Re: Re: Re: [ANNOUNCE] git-pasky-0.1

[Petr Baudis]

Dear diary, on Mon, Apr 11, 2005 at 01:10:58AM CEST, I got a letter
where Linus Torvalds <torvalds@xxxxxxxx> told me that...
> 
> 
> On Mon, 11 Apr 2005, Petr Baudis wrote:
> > 
> > I currently already do a merge when you track someone's source - it will
> > throw away your previous HEAD record though
> 
> Not only that, it doesn't do what I consider a "merge". 
> 
> A real merge should have two or more parents. The "commit-tree" command
> already allows that: just add any arbitrary number of "-p xxxxxxxxx"  
> switches (well, I think I limited it to 16 parents, but that's just a
> totally random number, there's nothing in the file format or anything 
> else that limits it).
> 
> So while you've merged my "data", but you've not actually merged my
> revision history in your tree.

Well, that's exactly what I was (am) going to do. :-) That's also why I
said that I (virtually) throw the local commits away now. Instead, if
there were any local commits, I will do git merge:

	commit-tree $(write-tree) -p $local_head -p $tracked_tree

Note that I will need to make this two-phase - first applying the
changes, then doing the commit; between those two phases, the user
should resolve potential conflicts and check if the merge went right.

I think I will name the first phase git merge and the second phase will
be just git commit, and I will store the merge information in
.dircache/. (BTW, I think the directory name is pretty awful; what about
.git/ ?)

> And the reason a real merge _has_ to show both parents properly is that 
> unless you do that, you can never merge sanely another time without 
> getting lots of clashes from the previous merge. So it's important that a 
> merge really shows both trees it got data from.
> 
> This is, btw, also the reason I haven't merged with your tree - I want to 
> get to the point where I really _can_ merge without throwing away the 
> information. In fact, at this point I'd rather not merge with your tree at 
> all, because I consider your tree to be "corrupt" thanks to lacking the 
> merge history.
> 
> So you've done the data merge, but not the history merge.
> 
> And because you didn't do the history merge, there's no way to
> automatically find out what point of my tree you merged _with_. See?
> 
> And since I have no way to see what point in time you merged with me, now
> I can't generate a nice 3-way diff against the last common ancestor of
> both of our trees.
> 
> So now I can't do a three-way merge with you based on any sane ancestor,
> unless I start guessing which ancestor of mine you merged with. Now, that
> "guess" is easy enough to do with a project like "git" which currently has
> just a few tens of commits and effectively only two parallell development
> trees, but the whole point is to get to a system where that isn't true..

Well, I've wanted to get the basic things working first before doing git
merge. (Especially since until recently, diff-tree was PITA to work
with, and before that it didn't even exist.) If you want, I can rebuild
my tree with doing the merging properly, after I have git merge working.

(BTW, it would be useful to have a tool which just blindly takes what
you give it on input and throws it to an object of given type; I will
need to construct arbitrary commits during the rebuild if I'm to keep
the correct dates.)

-- 
				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@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/