Tassilo Horn <tass...@member.fsf.org> 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

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.


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 git-users@googlegroups.com.
To unsubscribe from this group, send email to 
For more options, visit this group at 

Reply via email to