On Thu, 29 Jun 2006, Alex Riesen wrote:
>
> On 6/29/06, Linus Torvalds <torvalds@xxxxxxxx> wrote:
> > +static void *three_way_filemerge(mmfile_t *base, mmfile_t *our, mmfile_t
> > *their, unsigned long *size)
> > +{
> ...
> > + if (t1 && t2 && t3) {
> > + int code = run_command("merge", t2, t1, t3, NULL);
>
> This does not use the labels of merge(1) and the merged file will contain
> the names of temporary files at conflict places, which is very confusing if
> you happen to loose context while doing a merge with lots of conflicts.
Yes.
I was really really _really_ just hoping that I could do the nasty core
code that others might feel uncomfortable with, and get it working from a
_technical_ level well enough that others (hint hint) would decide that
they can fix up the details.
Getting the first version working is often the hardest. When you reach the
point of "it works, but I want to extend it to do X", you've usually
already gotten pretty far.
Anyway, all of this was really just preparatory work to show what
git-merge-tree does. A few more improvements to git-merge-tree, and
hopefully it can start being useful - perhaps not initially for actually
merging, but for doing a tree-level three-way diff between two branches.
In other words, my current goal is really do make it possible to get good
diffs out of git from two branches that aren't directly related. You and
Dscho seem to be doing well on the git-merge-recursive front, so my
personal goal is actually to be able to get a saner diff than what
git diff mine..theirs
gives you.
The above "git diff" is a perfectly fine thing to do, but it's usually not
what you actually _want_. Almost always, what you want a diff between two
branches, what you want is actually the diff after a merge of the
branches, not the raw _current_ differences.
For example, look at our current
Documentation/howto/using-topic-branches.txt
file, and realize that the current scripts it suggests are actually
broken:
To create diffstat and shortlog summaries of changes to include in
a "pleasepull" request to Linus you can use:
$ git-whatchanged -p release ^linus | diffstat -p1
and
$ git-whatchanged release ^linus | git-shortlog
where that "git-whatchanged -p release ^linus | diffstat -p1" won't
actually be what I see when I merge (although it will hopefully be close
enough). Also, there's no indication that the merge will fail when I pull,
something that _would_ be very useful.
IOW, what I'd like git-merge-tree to do is to be able to at a minimum say:
- will a merge succeed cleanly, and if not, show me where the problem
spots are.
- what will the result of the merge look like.
because that's actually what a downstream developer wants to do. He'd just
do
git fetch linus
git show-changes linus..my-branch
which would basically be the preparatory thing for sending me an email
saying "please merge 'my-branch', and you'll see this".
Now, obviously, I think that there's a _lot_ of overlap between doing this
and actually doing the merge itself, so hopefully the things I do will at
least have some things in common and perhaps help you do the proper
recursive merger.
But one thing I was actually hoping to do was to literally be able to do
this without either tree being checked out, exactly so that you can check
the status of a branch that you may not even _be_ on (eg that "my-branch"
in the example above may not even be your current HEAD: you might be on
your development branch when you actually ask me to pull from your stable
branch).
So the "show differences" has a lot in common with "merge them", but there
are literally a few stages missing. One thing missing in just showing
differences is that you can't actually fix up the merge clashes: if you
don't have a checked-out tree, you're not going to be able to do a real
merge. But you can see what a merge would _look_ like, and whether there
are any clashes that you will have to fix..
Linus
-
: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html