On Wed, Apr 22, 2009 at 1:15 PM, Jeff King <peff@xxxxxxxx> wrote:
>
> On Wed, Apr 22, 2009 at 10:44:06AM -0700, skillzero@xxxxxxxxx wrote:
>
>> It seems like this merge conflict is going to cause problems if I try
>> to re-merge to pick up a bug fix to 'feature' in the future. Looking
>> at the documentation, it sounds like 'git rerere' can help by
>> re-applying the manual conflict resolution I did?
>
> It shouldn't. Remember that your merges into 1.1, 1.2, etc, created a
> new merge base. So when you have bug fixes to make to this topic, you
> don't put them on the "feature" branch, but onto this topic branch. Then
> you re-merge the topic branch into 1.1., 1.2, feature, etc, and it will
> look only at the new bugfix.
I'm not sure I understand. When I did the original rebase of "feature"
onto the merge-base of all the branches I wanted to merge to (v1.1 and
v1.2 in this case), the end result was that "feature" is now based on
the merge-base. When I merged "feature" into 1.1, I had to fix some
conflicts so in the log I see my conflict fix commit then a merge
commit, but "feature" wasn't changed (only v1.1 was).
I was thinking that if I find a bug in my original "feature" branch, I
would commit the fix to the "feature" branch then merge that into
v1.1, v1.2, master, etc. But I was thinking that when I tried to merge
"feature" into v1.1 (which previously needed a commit to fix
conflicts), I'd need to re-fix those same conflicts.
When I look at the log for v1.1 though, maybe I just misunderstood the
way the conflicts are resolved in git? I was thinking the conflicting
merge would end up as one big commit that's a combination of the
"feature"'s commits and my conflict fixes.
But in the log for v1.1, it looks like my conflict fixing commit may
have just "fixed" the v1.1 branch such that it could accept a
"feature" merge without conflict. If that's true then a future merge
of "feature" containing new commits should just merge without
conflict. That would be awesome if that's the way conflicting
resolving in git works.
> However, the first entry in the reflog for that branch ref should
> indicate branch creation (unless it is so old that it has expired).
> Something like:
>
> $ git branch foo origin/master
> $ git reflog show foo
> 0be9bc0 foo@{0}: branch: Created from origin/master
>
> So 0be9bc0 would be the creation point in this case. But you might have
> totally rewritten the branch after that point, so 0be9bc0 might not be a
> useful value anymore.
Thanks, that shows what I need. For my case, it happened to be @{58}.
Is there a way to reverse the order or a special syntax to say "0 from
the end"? Trying --reverse said "cannot combine --reverse with
--walk-reflogs" and trying @{-1} show me something else.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html