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
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 git-users@googlegroups.com.
To unsubscribe from this group, send email to 
git-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/git-users?hl=en.

Reply via email to