Re: [lyx/refs/heads/master] Address bug 7975 by changing how toggling works, as suggested by

[Vincent van Ravesteijn]

Op 20-3-2012 20:35, Richard Heck schreef:

On 03/20/2012 07:44 AM, Vincent van Ravesteijn wrote:

Op 20-3-2012 0:15, Richard Heck schreef:


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.

What's surprising is that I get a non-fast-forward merge that is 
empty. Unsurprising that it's empty, since the two branches are 
completely synchronized, but surprising that the empty merge shows up 
as a commit. Note that, as I said, this does not happen if I've 
rebased against the other branch.


* First, I'm not sure what you mean by the merge is empty. Indeed,  
'git show 9236a938' does not show any changes in the code, but that's 
normal. A merge only combines two sets of commits; the actual changes to 
the code is done in the commits themselves. In this case in commit 
0a0a837b and in commits 8be18455..758d0482. (try: 'gitk 
8be18455..758d0482' this will show all commits that are in this range). 
If you want to see the code changes introduced by a merge you can do:


$ git diff 9236a938 9236a938^1

This will show you that the merge is not empty at all.

* Second, what do you mean with two branches are completely 
synchronized ? I guess you mean that if one branch is based on top the 
other they are synchronized ? And if they are  'synchronized', you get a 
fast-forward merge and thus no merge commit. This really is a special 
case and technically not even a merge.



So whether I get the empty commit depends upon which branch I rebased 
against, not what's actually in that branch.


If you rebase a branch A against another branch B, all commits of the 
branch B are actually included in branch A. So please don't rebase a 
branch A versus another branch B before merging it with branch C, 
because than branch B will also be merged into branch C.


If you would have rebased your feature branch against the 2.0.x branch 
before merging it into master, you are bound to run into problems if the 
commits in the 2.0.x branch are not _exactly_ the same as those in the 
master branch.


Vincent

Re: [lyx/refs/heads/master] Address bug 7975 by changing how toggling works, as suggested by

[Pavel Sanda]

Vincent van Ravesteijn wrote:
 all commits that are in this range). If you want to see the code changes 
 introduced by a merge you can do:

 $ git diff 9236a938 9236a938^1

 This will show you that the merge is not empty at all.

Is there a way how to obtain full listing of diffs which went into the master?
(I mean something like git log -p produced by git-svn on the old svn trunk).

Pavel

Re: [lyx/refs/heads/master] Address bug 7975 by changing how toggling works, as suggested by

[Vincent van Ravesteijn]

Op 21-3-2012 15:00, Pavel Sanda schreef:

Vincent van Ravesteijn wrote:

all commits that are in this range). If you want to see the code changes
introduced by a merge you can do:

$ git diff 9236a938 9236a938^1

This will show you that the merge is not empty at all.

Is there a way how to obtain full listing of diffs which went into the master?
(I mean something like git log -p produced by git-svn on the old svn trunk).



Something like this:

$ git log 9236a938^1..9236a938 --no-merges -p

you mean ?

Vincent

Re: [lyx/refs/heads/master] Address bug 7975 by changing how toggling works, as suggested by

[Pavel Sanda]

Vincent van Ravesteijn wrote:
 Op 21-3-2012 15:00, Pavel Sanda schreef:
 Vincent van Ravesteijn wrote:
 all commits that are in this range). If you want to see the code changes
 introduced by a merge you can do:

 $ git diff 9236a938 9236a938^1

 This will show you that the merge is not empty at all.
 Is there a way how to obtain full listing of diffs which went into the 
 master?
 (I mean something like git log -p produced by git-svn on the old svn 
 trunk).


 Something like this:

 $ git log 9236a938^1..9236a938 --no-merges -p

 you mean ?

Not at all. I want see all code changes which went into the master.
Lets say I know there existed patch which I'm able to grep for (eg.
I can remember particular code change or string change, whatsoever).

When using git-svn I simply typed:
git log -p 
and I got full listing of trunk history which I could grep as much
as I want (or with combination with -S).

Now with the merging commit of Richard the real code change
disappeared from the listing, but I want to see it as well
(and all other merges in history like this one).

How?

Pavel

Re: [lyx/refs/heads/master] Address bug 7975 by changing how toggling works, as suggested by

[Vincent van Ravesteijn]

Op 21-3-2012 16:16, Pavel Sanda schreef:

Vincent van Ravesteijn wrote:

Op 21-3-2012 15:00, Pavel Sanda schreef:

Vincent van Ravesteijn wrote:

all commits that are in this range). If you want to see the code changes
introduced by a merge you can do:

$ git diff 9236a938 9236a938^1

This will show you that the merge is not empty at all.

Is there a way how to obtain full listing of diffs which went into the
master?
(I mean something like git log -p produced by git-svn on the old svn
trunk).


Something like this:

$ git log 9236a938^1..9236a938 --no-merges -p

you mean ?

Not at all. I want see all code changes which went into the master.
Lets say I know there existed patch which I'm able to grep for (eg.
I can remember particular code change or string change, whatsoever).

When using git-svn I simply typed:
git log -p
and I got full listing of trunk history which I could grep as much
as I want (or with combination with -S).

Now with the merging commit of Richard the real code change
disappeared from the listing, but I want to see it as well
(and all other merges in history like this one).

How?


git log -p really shows all commits that went into master. The problem 
is that by using git log you're forcing the history to be linear, 
while it actually isn't. Git therefore sorts the commit based on the 
date of the commit (not the date of the merge). So, the date of the 
actual code change that was merged in by Richard was March 13.


You can see this immediately if you limit the output to only Richard's 
commits:


$ git log -p --author='Richard Heck'

Vincent

Re: [lyx/refs/heads/master] Address bug 7975 by changing how toggling works, as suggested by

[Vincent van Ravesteijn]

Op 21-3-2012 16:39, Vincent van Ravesteijn schreef:

Op 21-3-2012 16:16, Pavel Sanda schreef:

Vincent van Ravesteijn wrote:

Op 21-3-2012 15:00, Pavel Sanda schreef:

Vincent van Ravesteijn wrote:
all commits that are in this range). If you want to see the code 
changes

introduced by a merge you can do:

$ git diff 9236a938 9236a938^1

This will show you that the merge is not empty at all.

Is there a way how to obtain full listing of diffs which went into the
master?
(I mean something like git log -p produced by git-svn on the old svn
trunk).


Something like this:

$ git log 9236a938^1..9236a938 --no-merges -p

you mean ?

Not at all. I want see all code changes which went into the master.
Lets say I know there existed patch which I'm able to grep for (eg.
I can remember particular code change or string change, whatsoever).

When using git-svn I simply typed:
git log -p
and I got full listing of trunk history which I could grep as much
as I want (or with combination with -S).

Now with the merging commit of Richard the real code change
disappeared from the listing, but I want to see it as well
(and all other merges in history like this one).

How?


git log -p really shows all commits that went into master. The 
problem is that by using git log you're forcing the history to be 
linear, while it actually isn't. Git therefore sorts the commit based 
on the date of the commit (not the date of the merge). So, the date of 
the actual code change that was merged in by Richard was March 13.


You can see this immediately if you limit the output to only Richard's 
commits:


$ git log -p --author='Richard Heck'

Vincent


The following shows the diffs in order they got into master:

$ git log -p --simplify-merges

Vincent

Re: [lyx/refs/heads/master] Address bug 7975 by changing how toggling works, as suggested by

[Vincent van Ravesteijn]

Op 21-3-2012 16:48, Vincent van Ravesteijn schreef:

Op 21-3-2012 16:39, Vincent van Ravesteijn schreef:

Op 21-3-2012 16:16, Pavel Sanda schreef:

Vincent van Ravesteijn wrote:

Op 21-3-2012 15:00, Pavel Sanda schreef:

Vincent van Ravesteijn wrote:
all commits that are in this range). If you want to see the code 
changes

introduced by a merge you can do:

$ git diff 9236a938 9236a938^1

This will show you that the merge is not empty at all.
Is there a way how to obtain full listing of diffs which went into 
the

master?
(I mean something like git log -p produced by git-svn on the old svn
trunk).


Something like this:

$ git log 9236a938^1..9236a938 --no-merges -p

you mean ?

Not at all. I want see all code changes which went into the master.
Lets say I know there existed patch which I'm able to grep for (eg.
I can remember particular code change or string change, whatsoever).

When using git-svn I simply typed:
git log -p
and I got full listing of trunk history which I could grep as much
as I want (or with combination with -S).

Now with the merging commit of Richard the real code change
disappeared from the listing, but I want to see it as well
(and all other merges in history like this one).

How?


git log -p really shows all commits that went into master. The 
problem is that by using git log you're forcing the history to be 
linear, while it actually isn't. Git therefore sorts the commit based 
on the date of the commit (not the date of the merge). So, the date 
of the actual code change that was merged in by Richard was March 13.


You can see this immediately if you limit the output to only 
Richard's commits:


$ git log -p --author='Richard Heck'

Vincent


The following shows the diffs in order they got into master:


or:

git log -p -m --first-parent

-m

   This flag makes the merge commits show the full diff like regular
   commits; for each merge parent, a separate log entry and diff is
   generated. An exception is that only diff against the first parent
   is shown when /--first-parent/ option is given; in that case, the
   output represents the changes the merge brought /into/ the
   then-current branch.



Vincent

Re: [lyx/refs/heads/master] Address bug 7975 by changing how toggling works, as suggested by

[Pavel Sanda]

Vincent van Ravesteijn wrote:
 change that was merged in by Richard was March 13.

 You can see this immediately if you limit the output to only Richard's 
 commits:

 $ git log -p --author='Richard Heck'

 Vincent

 The following shows the diffs in order they got into master:

 or:

 git log -p -m --first-parent

I see. Actually even git log -p is fine with me, I just didn't catch
that the commit was from March 13...

Pavel

Re: [lyx/refs/heads/master] Address bug 7975 by changing how toggling works, as suggested by

[Vincent van Ravesteijn]

Op 20-3-2012 20:35, Richard Heck schreef:

On 03/20/2012 07:44 AM, Vincent van Ravesteijn wrote:

Op 20-3-2012 0:15, Richard Heck schreef:


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.

What's surprising is that I get a non-fast-forward merge that is 
empty. Unsurprising that it's empty, since the two branches are 
completely synchronized, but surprising that the empty merge shows up 
as a commit. Note that, as I said, this does not happen if I've 
rebased against the other branch.


* First, I'm not sure what you mean by "the merge is empty". Indeed,  
'git show 9236a938' does not show any changes in the code, but that's 
normal. A merge only combines two sets of commits; the actual changes to 
the code is done in the commits themselves. In this case in commit 
0a0a837b and in commits 8be18455..758d0482. (try: 'gitk 
8be18455..758d0482' this will show all commits that are in this range). 
If you want to see the code changes introduced by a merge you can do:


$ git diff 9236a938 9236a938^1

This will show you that the merge is not empty at all.

* Second, what do you mean with "two branches are completely 
synchronized" ? I guess you mean that if one branch is based on top the 
other they are synchronized ? And if they are  'synchronized', you get a 
fast-forward merge and thus no merge commit. This really is a special 
case and technically not even a merge.



So whether I get the empty commit depends upon which branch I rebased 
against, not what's actually in that branch.


If you rebase a branch A against another branch B, all commits of the 
branch B are actually included in branch A. So please don't rebase a 
branch A versus another branch B before merging it with branch C, 
because than branch B will also be merged into branch C.


If you would have rebased your feature branch against the 2.0.x branch 
before merging it into master, you are bound to run into problems if the 
commits in the 2.0.x branch are not _exactly_ the same as those in the 
master branch.


Vincent

Re: [lyx/refs/heads/master] Address bug 7975 by changing how toggling works, as suggested by

[Pavel Sanda]

Vincent van Ravesteijn wrote:
> all commits that are in this range). If you want to see the code changes 
> introduced by a merge you can do:
>
> $ git diff 9236a938 9236a938^1
>
> This will show you that the merge is not empty at all.

Is there a way how to obtain full listing of diffs which went into the master?
(I mean something like git log -p produced by git-svn on the old svn trunk).

Pavel

Re: [lyx/refs/heads/master] Address bug 7975 by changing how toggling works, as suggested by

[Vincent van Ravesteijn]

Op 21-3-2012 15:00, Pavel Sanda schreef:

Vincent van Ravesteijn wrote:

all commits that are in this range). If you want to see the code changes
introduced by a merge you can do:

$ git diff 9236a938 9236a938^1

This will show you that the merge is not empty at all.

Is there a way how to obtain full listing of diffs which went into the master?
(I mean something like git log -p produced by git-svn on the old svn trunk).



Something like this:

$ git log 9236a938^1..9236a938 --no-merges -p

you mean ?

Vincent

Re: [lyx/refs/heads/master] Address bug 7975 by changing how toggling works, as suggested by

[Pavel Sanda]

Vincent van Ravesteijn wrote:
> Op 21-3-2012 15:00, Pavel Sanda schreef:
>> Vincent van Ravesteijn wrote:
>>> all commits that are in this range). If you want to see the code changes
>>> introduced by a merge you can do:
>>>
>>> $ git diff 9236a938 9236a938^1
>>>
>>> This will show you that the merge is not empty at all.
>> Is there a way how to obtain full listing of diffs which went into the 
>> master?
>> (I mean something like git log -p produced by git-svn on the old svn 
>> trunk).
>>
>
> Something like this:
>
> $ git log 9236a938^1..9236a938 --no-merges -p
>
> you mean ?

Not at all. I want see all code changes which went into the master.
Lets say I know there existed patch which I'm able to grep for (eg.
I can remember particular code change or string change, whatsoever).

When using git-svn I simply typed:
git log -p 
and I got full listing of trunk history which I could grep as much
as I want (or with combination with -S).

Now with the merging commit of Richard the real code change
disappeared from the listing, but I want to see it as well
(and all other merges in history like this one).

How?

Pavel

Re: [lyx/refs/heads/master] Address bug 7975 by changing how toggling works, as suggested by

[Vincent van Ravesteijn]

Op 21-3-2012 16:16, Pavel Sanda schreef:

Vincent van Ravesteijn wrote:

Op 21-3-2012 15:00, Pavel Sanda schreef:

Vincent van Ravesteijn wrote:

all commits that are in this range). If you want to see the code changes
introduced by a merge you can do:

$ git diff 9236a938 9236a938^1

This will show you that the merge is not empty at all.

Is there a way how to obtain full listing of diffs which went into the
master?
(I mean something like git log -p produced by git-svn on the old svn
trunk).


Something like this:

$ git log 9236a938^1..9236a938 --no-merges -p

you mean ?

Not at all. I want see all code changes which went into the master.
Lets say I know there existed patch which I'm able to grep for (eg.
I can remember particular code change or string change, whatsoever).

When using git-svn I simply typed:
git log -p
and I got full listing of trunk history which I could grep as much
as I want (or with combination with -S).

Now with the merging commit of Richard the real code change
disappeared from the listing, but I want to see it as well
(and all other merges in history like this one).

How?


"git log -p" really shows all commits that went into master. The problem 
is that by using "git log" you're forcing the history to be linear, 
while it actually isn't. Git therefore sorts the commit based on the 
date of the commit (not the date of the merge). So, the date of the 
actual code change that was merged in by Richard was March 13.


You can see this immediately if you limit the output to only Richard's 
commits:


$ git log -p --author='Richard Heck'

Vincent

Re: [lyx/refs/heads/master] Address bug 7975 by changing how toggling works, as suggested by

[Vincent van Ravesteijn]

Op 21-3-2012 16:39, Vincent van Ravesteijn schreef:

Op 21-3-2012 16:16, Pavel Sanda schreef:

Vincent van Ravesteijn wrote:

Op 21-3-2012 15:00, Pavel Sanda schreef:

Vincent van Ravesteijn wrote:
all commits that are in this range). If you want to see the code 
changes

introduced by a merge you can do:

$ git diff 9236a938 9236a938^1

This will show you that the merge is not empty at all.

Is there a way how to obtain full listing of diffs which went into the
master?
(I mean something like git log -p produced by git-svn on the old svn
trunk).


Something like this:

$ git log 9236a938^1..9236a938 --no-merges -p

you mean ?

Not at all. I want see all code changes which went into the master.
Lets say I know there existed patch which I'm able to grep for (eg.
I can remember particular code change or string change, whatsoever).

When using git-svn I simply typed:
git log -p
and I got full listing of trunk history which I could grep as much
as I want (or with combination with -S).

Now with the merging commit of Richard the real code change
disappeared from the listing, but I want to see it as well
(and all other merges in history like this one).

How?


"git log -p" really shows all commits that went into master. The 
problem is that by using "git log" you're forcing the history to be 
linear, while it actually isn't. Git therefore sorts the commit based 
on the date of the commit (not the date of the merge). So, the date of 
the actual code change that was merged in by Richard was March 13.


You can see this immediately if you limit the output to only Richard's 
commits:


$ git log -p --author='Richard Heck'

Vincent


The following shows the diffs in order they got into master:

$ git log -p --simplify-merges

Vincent

Re: [lyx/refs/heads/master] Address bug 7975 by changing how toggling works, as suggested by

[Vincent van Ravesteijn]

Op 21-3-2012 16:48, Vincent van Ravesteijn schreef:

Op 21-3-2012 16:39, Vincent van Ravesteijn schreef:

Op 21-3-2012 16:16, Pavel Sanda schreef:

Vincent van Ravesteijn wrote:

Op 21-3-2012 15:00, Pavel Sanda schreef:

Vincent van Ravesteijn wrote:
all commits that are in this range). If you want to see the code 
changes

introduced by a merge you can do:

$ git diff 9236a938 9236a938^1

This will show you that the merge is not empty at all.
Is there a way how to obtain full listing of diffs which went into 
the

master?
(I mean something like git log -p produced by git-svn on the old svn
trunk).


Something like this:

$ git log 9236a938^1..9236a938 --no-merges -p

you mean ?

Not at all. I want see all code changes which went into the master.
Lets say I know there existed patch which I'm able to grep for (eg.
I can remember particular code change or string change, whatsoever).

When using git-svn I simply typed:
git log -p
and I got full listing of trunk history which I could grep as much
as I want (or with combination with -S).

Now with the merging commit of Richard the real code change
disappeared from the listing, but I want to see it as well
(and all other merges in history like this one).

How?


"git log -p" really shows all commits that went into master. The 
problem is that by using "git log" you're forcing the history to be 
linear, while it actually isn't. Git therefore sorts the commit based 
on the date of the commit (not the date of the merge). So, the date 
of the actual code change that was merged in by Richard was March 13.


You can see this immediately if you limit the output to only 
Richard's commits:


$ git log -p --author='Richard Heck'

Vincent


The following shows the diffs in order they got into master:


or:

git log -p -m --first-parent

-m

   This flag makes the merge commits show the full diff like regular
   commits; for each merge parent, a separate log entry and diff is
   generated. An exception is that only diff against the first parent
   is shown when /--first-parent/ option is given; in that case, the
   output represents the changes the merge brought /into/ the
   then-current branch.



Vincent

Re: [lyx/refs/heads/master] Address bug 7975 by changing how toggling works, as suggested by

[Pavel Sanda]

Vincent van Ravesteijn wrote:
>>> change that was merged in by Richard was March 13.
>>>
>>> You can see this immediately if you limit the output to only Richard's 
>>> commits:
>>>
>>> $ git log -p --author='Richard Heck'
>>>
>>> Vincent
>>
>> The following shows the diffs in order they got into master:
>>
> or:
>
> git log -p -m --first-parent

I see. Actually even git log -p is fine with me, I just didn't catch
that the commit was from March 13...

Pavel

Re: [lyx/refs/heads/master] Address bug 7975 by changing how toggling works, as suggested by

[Vincent van Ravesteijn]

Op 20-3-2012 0:15, Richard Heck schreef:

On 03/19/2012 06:47 PM, Lars Gullik Bjønnes wrote:

Richard Heckrgh...@comcast.net  writes:

| On 03/19/2012 06:04 PM, rgh...@lyx.org wrote:

Author: Richard Heckrgh...@lyx.org
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

Re: [lyx/refs/heads/master] Address bug 7975 by changing how toggling works, as suggested by

[Richard Heck]

On 03/20/2012 07:44 AM, Vincent van Ravesteijn wrote:

Op 20-3-2012 0:15, Richard Heck schreef:


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.

What's surprising is that I get a non-fast-forward merge that is empty. 
Unsurprising that it's empty, since the two branches are completely 
synchronized, but surprising that the empty merge shows up as a commit. 
Note that, as I said, this does not happen if I've rebased against the 
other branch. So whether I get the empty commit depends upon which 
branch I rebased against, not what's actually in that branch.


Richard

Re: [lyx/refs/heads/master] Address bug 7975 by changing how toggling works, as suggested by

[Vincent van Ravesteijn]

Op 20-3-2012 0:15, Richard Heck schreef:

On 03/19/2012 06:47 PM, Lars Gullik Bjønnes wrote:

Richard Heck  writes:

| On 03/19/2012 06:04 PM, rgh...@lyx.org wrote:

Author: Richard Heck
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

Re: [lyx/refs/heads/master] Address bug 7975 by changing how toggling works, as suggested by

[Richard Heck]

On 03/20/2012 07:44 AM, Vincent van Ravesteijn wrote:

Op 20-3-2012 0:15, Richard Heck schreef:


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.

What's surprising is that I get a non-fast-forward merge that is empty. 
Unsurprising that it's empty, since the two branches are completely 
synchronized, but surprising that the empty merge shows up as a commit. 
Note that, as I said, this does not happen if I've rebased against the 
other branch. So whether I get the empty commit depends upon which 
branch I rebased against, not what's actually in that branch.


Richard

Re: [lyx/refs/heads/master] Address bug 7975 by changing how toggling works, as suggested by

[Richard Heck]

On 03/19/2012 06:04 PM, rgh...@lyx.org wrote:

Author: Richard Heckrgh...@lyx.org
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.

Richard

Re: [lyx/refs/heads/master] Address bug 7975 by changing how toggling works, as suggested by

[Pavel Sanda]

Richard Heck wrote:
 On 03/19/2012 06:04 PM, rgh...@lyx.org wrote:
 Author: Richard Heckrgh...@lyx.org 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.

It seems in the tree, however when I try git log -p I see just empty merge
commit without diff and I need to manually lookup sha in the header :(

Pavel

Re: [lyx/refs/heads/master] Address bug 7975 by changing how toggling works, as suggested by

[Lars Gullik Bjønnes]

Richard Heck rgh...@comcast.net writes:

| On 03/19/2012 06:04 PM, rgh...@lyx.org wrote:
 Author: Richard Heckrgh...@lyx.org
 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'?

-- 
   Lgb

Re: [lyx/refs/heads/master] Address bug 7975 by changing how toggling works, as suggested by

[Richard Heck]

On 03/19/2012 06:47 PM, Lars Gullik Bjønnes wrote:

Richard Heckrgh...@comcast.net  writes:

| On 03/19/2012 06:04 PM, rgh...@lyx.org wrote:

Author: Richard Heckrgh...@lyx.org
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.


It may be that I had merged lyx/trunk into master rather than rebasing.

Richard

Re: [lyx/refs/heads/master] Address bug 7975 by changing how toggling works, as suggested by

[Richard Heck]

On 03/19/2012 06:04 PM, rgh...@lyx.org wrote:

Author: Richard Heck
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.

Richard

Re: [lyx/refs/heads/master] Address bug 7975 by changing how toggling works, as suggested by

[Pavel Sanda]

Richard Heck wrote:
> On 03/19/2012 06:04 PM, rgh...@lyx.org wrote:
>> Author: Richard Heck 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.

It seems in the tree, however when I try git log -p I see just empty merge
commit without diff and I need to manually lookup sha in the header :(

Pavel

Re: [lyx/refs/heads/master] Address bug 7975 by changing how toggling works, as suggested by

[Lars Gullik Bjønnes]

Richard Heck  writes:

| On 03/19/2012 06:04 PM, rgh...@lyx.org wrote:
>> Author: Richard Heck
>> 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'?

-- 
   Lgb

Re: [lyx/refs/heads/master] Address bug 7975 by changing how toggling works, as suggested by

[Richard Heck]

On 03/19/2012 06:47 PM, Lars Gullik Bjønnes wrote:

Richard Heck  writes:

| On 03/19/2012 06:04 PM, rgh...@lyx.org wrote:

Author: Richard Heck
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.


It may be that I had merged lyx/trunk into master rather than rebasing.

Richard