On Wed, Apr 22, 2009 at 10:44:06AM -0700, skillzero@xxxxxxxxx wrote:
> Then I rebased feature:
>
> git rebase --onto merge-base-of-1.1-and-master feature-before-first feature
>
> [...]
>
> I can merge 'feature' into 1.1, 1.2, etc. then theoretically, I should
> be able to apply bug fixes to 'feature' later and re-merge into 1.1,
> 1.2, etc. to pick up just the bug fixes, right?
Exactly.
> 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.
> BTW...Is there a way to find the first commit of a branch? I had to
> just look at the log manually to see what I remembered to be the first
> commit.
Sort of. Branches in git are really just refs pointing to the tip of the
branch. So once the tip advances, the ref no longer remembers "oh, this
is where I branched from". If there are other commits along the thing
you branched off of, you can calculate the merge-base of the thing you
branched from, and your branch.
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.
-Peff
--
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