git and bzr

[Linus Torvalds]

On Tue, 28 Nov 2006, Nicholas Allen wrote:
> 
> Also what happens if I loose the messages because they scrolled off
> screen or the power goes down, I need to reboot for some reason, or I
> don't have time and want to shutdown my computer restart another day and
> resolve the conflicts then?

I'd suggest just re-doing the merge. Something like

	git reset --hard
	git merge -m "dummy message" MERGE_HEAD

will do it for you (that's the new "nicer syntax" for doing a merge, in 
real life I'd personally just have done a re-pull or somehing)

> All useful conflict status is lost isn't it?

No, it's actually there, but "git status" doesn't really explain it to 
you.

The go-to command tends to be "git diff", which after a merge will not 
show anything that already merged correctly (because it will have been 
updated in the git index _and_ updated in the working tree, so there will 
be no diff from stuff that auto-merged). So any output at all after a 
failed merge from "git diff" generally tells you exactly what failed.

But since 99%+ of all merge conflicts are data-conflicts, I suspect the 
output is mostly geared towards that.

The other useful tools to be used are "git log --merge" (explained in a 
separate mail) and for people like me who like the git index and grok it 
fully, doing a

	git ls-files --unmerged --stage

is probably what I'd do (but I have to admit, that is _not_ a very 
user-friendly interface - you need to not only have understood the index 
file, you actually need to understand it on a very deep level).

"git status" is really used to be just a stupid around "git ls-files" 
(it's now largely a built-in), but it was really _so_ stupid that it 
doesn't really try to explain what it does - it's more like a simplified 
version of ls-files with some of the information pruned away, and other 
parts in a slightly more palatable format ;)

So improving "git status" might mean that some people could avoid having 
to learn about the index file details ;)

			Linus