Op 20-3-2012 0:15, Richard Heck schreef:
On 03/19/2012 06:47 PM, Lars Gullik Bjønnes wrote:
Richard Heck<[email protected]>  writes:

| On 03/19/2012 06:04 PM, [email protected] wrote:
Author: Richard Heck<[email protected]>
Date: Tue, 13 Mar 2012 12:08:25 -0400
New Commit: 0a0a837b70a8e4736b6b848060b6a893a8578306
URL: http://git.lyx.org/?p=lyx.git;a=commit;h=0a0a837b70a8e4736b6b848060b6a893a8578306

Log:
Address bug 7975 by changing how toggling works, as suggested by
JMarc.

| Can someone please check this commit? I was trying to follow the
| suggestions given
| by Lars about how to handle personal repos, etc, but it looks as if I
| got some weird
| merge commit along the way. I'm not sure why. Maybe I didn't quite
| have that branch
| up to date. I'm not sure.

One super trick is to use "gitk --all" to view what your repo and
branches look like, or just "gitk" to view a single branch and see how
the different paths of development ends up fitting together.

As to your change. The merge node is really strange. Did you remove the
suggested text from the merge? Use '-m'?

No, what I did was this.

This is in my private repo. I have a branch master, and another branch bugs/7975, and another branch lyx/trunk that is tracking the main repo, set up as you suggested. The master and lyx/trunk branches were completely in sync, or so I thought. So then I did:
    git checkout lyx/trunk
    git merge bugs/7975
and I ended up with the merge commit, representing the new commit from bugs/7975 as one branch and some of the material from lyx/trunk as a separate branch. I think was, in part, because bugs/7975 had been rebased against branch. I've done some other tests, and if I rebase it against lyx/trunk then of course it is OK.


This is just the classic example of a merge. In one branch is the development of the others (master) and your development is in your private branch (bugs/7975). Now you merged the two together.

If you rebase your feature branch on top of master first and then do a merge, you will get a special type of merge, namely a fast-forward merge. If you would specify --no-ff, you would still get a merge commit.

I'm not sure what part is surprising to you.

Vincent




Reply via email to