Re: GIT - breaking backward compatibility
- From
- Sven Verdoolaege <skimo@kotnet.org>
- Date
- Sep 20, 2005, 07:11 UTC
- Message-ID
- <20050920071116.GJ15165MdfPADPa@greensroom.kotnet.org>
- In-Reply-To
- <7v3bo06xv4.fsf@assigned-by-dhcp.cox.net>
On Mon, Sep 19, 2005 at 11:45:35PM -0700, Junio C Hamano wrote:
Show 8 quoted lines
> Sven Verdoolaege <skimo@kotnet.org> writes: > > > What tool can be used as a replacement for git-diff-stages ? > > If we removed it, you would probably end up scripting it by > using output from git-ls-files --stage (or --unmerged), and > comparing the mode and SHA1 for the stages, and if you want -p > output then git-unpack-file and diff too.
OK, that was basically what I had planed to do, until I noticed in your mail that there was a tool called git-diff-stages. I just thought your removing it meant that it had become a special case of some other tool.
Show 11 quoted lines
> But the real question was how useful what git-diff-stages does > is. Comparing stage3 (or stage1) and working tree might be > suseful, but comparing stage<n> and stage<m> is what the command > is about. Since those stages are present after/during an > incomplete merge, probably the user or script is trying to > figure out what happened by inspecting the trees being merged -- > if that is the case, instead of inspecting what the merge > algorithm which did not complete used to apply its heuristics > (which is essentially what is left in those stages), you or your > script can run 'git-diff-tree' across trees involved in the > merge directly.
But the merge heuristics usually do a pretty good job so the user would have to perform fewer manual merge operations if she starts off from the result of the failed merge. (And if it turns out that the merge heuristics really didn't work, she can still throw the results away.)
The reason I'm asking is that I used dirdiff to do a "difficult" merge which required some manual intervention. The way I used it now, was to load the merge base, the two heads and the working directory (containing the result of the failed merge) in dirdiff and then to merge the final result into the working directory.
I still need to look at the merging stuff in more detail, but I figured that it would actually be more interesting if dirdiff could perform the merge on the index rather than the working directory. What do you think ?
skimo