Fix a botched log-message
Matthieu.Moy at imag.fr
Fri Apr 4 10:17:56 BST 2008
"Stephen J. Turnbull" <stephen at xemacs.org> writes:
> Matthieu Moy writes:
> > > But that is not a problem in principle because
> > Err, have you _really_ used git to say such thing ?
> Do you understand the difference between "in principle" and "in
No, I don't understand what you mean here.
> > Git considers commit sha1 as commit identity, and all the history
> > information is based on that. Re-creating a new commit with almost
> > the same content, but different sha1 means you totally break any
> > DAG-aware further commands (merging in particular).
> No, you don't *totally* break anything, in fact. The reason is that
> the rebased branch is isomorphic to the old one. git shows that it is
> reasonable to compute these things on the fly. When you do, you'll
> end up at either the same common ancestor, or an isomorphic one (ie,
> one which has the same chain of trees).
My Git doesn't do that. Just checked, I get a different,
non-isomorphic, common ancestor. And yes, I do get spurious conflicts.
$ git forest --all
╓─[merged-two-non-rebased]──Merge branch 'non-rebased-first' into non-rebased-second
║ ║ ╓─[rebased-second]──in-second-branch
║ ║ ╟ reasonable-init (fixed log message)
Here, "init" at the bottom has a file "file", with arbitrary content.
"reasonable-init" gives a very different content to the file, and it's
later "commit --amend"-ed, without changing the file content. I build
two branches on top it.
merging "non-rebased-first" and "non-rebased-second" works like a
charm, and merging "rebased-second" and "non-rebased-first" fails:
$ git checkout rebased-second
Switched to branch "rebased-second"
$ git merge non-rebased-first
CONFLICT (content): Merge conflict in file
Automatic merge failed; fix conflicts and then commit the result.
Can you provide an example where it works as you say?
More information about the bazaar