Tassilo Horn <[email protected]> writes:
> we've just converted from HG to git. Thereby, I've accidentally
> deleted an empty commit that actually was the BASE of master (HG
> default) and a new foobar branch. (I did "git filter-branch
> --prune-empty" to prune the empty "hg commit --close-branch" commits
> in order to strip old branches from the history. Unfortunately, the
> commit that started the foobar branch was empty, too.)
>
> Ok, so now
>
> $ git checkout foobar
> $ git merge master
>
> produces gazillions of conflicts, because the BASE version used for
> the 3-way-merge is some years old in some cases. (Yeah, stupid me, I
> know.)
Instead of the idea in my other mail: isn't there a way to explicitly
tell Git to use commit <somesha1> as BASE revision when doing 3-way
merges?
I mean, due to my empty commit pruning, I modified the history from
something like this
(..) --> (A) --> (B) --> (C) --> (D) --> (E) [master]
\
`--> (F) --> (G) --> (H) [foobar]
where the commit (F) was empty but started the foobar branch to
something like this
(..) --> (A) --> (B) --> (C) --> (D) --> (E) [master]
(..) --> (G) --> (H) [foobar]
If I could somehow specify that Git should use commit (B) as BASE
version when doing the merge, then I think my problem was solved.
Bye,
Tassilo
--
You received this message because you are subscribed to the Google Groups "Git
for human beings" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/git-users?hl=en.
