Re: [PATCH] git-merge: add option --no-ff

"Lars Hjemli" [off-list ref] writes:

On 9/18/07, Eric Wong [off-list ref] wrote:

quoted

Would automatically enabling --no-ff when it detects merging of two (or
more) SVN branches be a good thing?

I'd say 'git-svn merge' as a wrapper for 'git merge --no-ff' would be cleaner.

That unfortunately does not solve the problem.

Junio C Hamano wrote:

"Lars Hjemli" [off-list ref] writes:

quoted

On 9/18/07, Eric Wong [off-list ref] wrote:

quoted

Would automatically enabling --no-ff when it detects merging of two (or
more) SVN branches be a good thing?

I'd say 'git-svn merge' as a wrapper for 'git merge --no-ff' would be cleaner.

That unfortunately does not solve the problem.

I think we 'just' need to fix pushing merges back to SVN - so that they
properly set Subversion 1.5+ (and possibly SVK) merge attributes - and
if it is ambiguous which branch to push to, force the user to decide.

Sam.

On 9/18/07, Junio C Hamano [off-list ref] wrote:

"Lars Hjemli" [off-list ref] writes:

quoted

On 9/18/07, Eric Wong [off-list ref] wrote:

quoted

Would automatically enabling --no-ff when it detects merging of two (or
more) SVN branches be a good thing?

I'd say 'git-svn merge' as a wrapper for 'git merge --no-ff' would be cleaner.

That unfortunately does not solve the problem.

The problem we're trying to solve is to somehow avoid fast-forward
merges between git-svn branches, right?

I don't think it's a big issue in itself. If a fast-forward occurs,
what will happen is basically that git-svn will guess the wrong
upstream branch and then proceed to do nothing [1]. The user can
always recover from this state with 'git-reset' and 'git-merge
--no-ff'. So I think the result of a fast-forward merge between
git-svn branches is annoying, but not fatal [2].

But a closely related issue is that git-svn shouldn't dcommit to the
wrong upstream (even in the case of a fast-forward merge). We need a
way to explicitly show the link between the local and remote svn
branch (something like .git/config perhaps).

-- 
larsh

[1] If the merged-in branch had local commits they will be 'dcommited'
to the correct upstream of the merged-in branch, which isn't to bad

[2] if git-svn could be fixed to handle even the ff case, someone
could actually prefer to get the 'cherry-picked' history in
subversion. I don't, hence my --no-ff patch, but I'm not at all
certain this should be _forced_ on git-svn branches.

Sam Vilain wrote:

quoted

quoted

I'd say 'git-svn merge' as a wrapper for 'git merge --no-ff' would be cleaner.
      

That unfortunately does not solve the problem.
    

I think we 'just' need to fix pushing merges back to SVN - so that they
properly set Subversion 1.5+ (and possibly SVK) merge attributes - and
if it is ambiguous which branch to push to, force the user to decide.
  

Whoops, I missed the thrust of the current issue; it won't be ambiguous,
it'll be unambiguously wrong, so this doesn't apply.

In which case I'd guess the moral equivalent of --track would have to go
forward, or a per-branch basis.

I think that writing a real fast-forward merge should only happen on
dcommit, not git merge, because that is what is required for SVN. 
Ideally, it should also have the property that it doesn't cycle; null
merges between two branches should not carry on indefinitely.

Sam.

On 9/18/07, Sam Vilain [off-list ref] wrote:

I think that writing a real fast-forward merge should only happen on
dcommit, not git merge, because that is what is required for SVN.

I don't think git-svn has any way of knowing that the user wanted a
merge, unless a merge commit is present. So the user would have to
specify the set of commits which should be considered a merge during
dcommit (this would actually resemble how merges are performed in
subversion).

Sidenote: this might be slightly controversial, but I've sometimes
missed a --no-ff option to 'git merge' when working on plain git
repositories; IMHO preserving the 'logical' merge history when the
merge of a topic branch results in a fast-forward can be interesting.

-- 
larsh

Lars Hjemli wrote:

On 9/18/07, Sam Vilain [off-list ref] wrote:
  

quoted

I think that writing a real fast-forward merge should only happen on
dcommit, not git merge, because that is what is required for SVN.
    

I don't think git-svn has any way of knowing that the user wanted a
merge, unless a merge commit is present. So the user would have to
specify the set of commits which should be considered a merge during
dcommit (this would actually resemble how merges are performed in
subversion).
  

Sure it can.  If you're committing to branch X, and the current tree has
a whole lot of commits above that, then it should do the only thing you
can do with SVN.

Which is write a squash commit, and set the "svn:merge" and/or
"svk:merge" properties to represent what happened.

Sidenote: this might be slightly controversial, but I've sometimes
missed a --no-ff option to 'git merge' when working on plain git
repositories; IMHO preserving the 'logical' merge history when the
merge of a topic branch results in a fast-forward can be interesting.

If you really want one, use git commit-tree directly.

Sam.

[...sorry for making this such a long thread...]

On 9/18/07, Sam Vilain [off-list ref] wrote:

Lars Hjemli wrote:

quoted

On 9/18/07, Sam Vilain [off-list ref] wrote:

quoted

I think that writing a real fast-forward merge should only happen on
dcommit, not git merge, because that is what is required for SVN.

I don't think git-svn has any way of knowing that the user wanted a
merge, unless a merge commit is present. So the user would have to
specify the set of commits which should be considered a merge during
dcommit (this would actually resemble how merges are performed in
subversion).

Sure it can.  If you're committing to branch X, and the current tree has
a whole lot of commits above that, then it should do the only thing you
can do with SVN.

Which is write a squash commit, and set the "svn:merge" and/or
"svk:merge" properties to represent what happened.

I often have prepared a series of local commits which I _want_ to
preserve as different subversion revisions.

Also, doing a --squash means that I loose the merge history in git
(and then I need to edit the grafts file again)

quoted

Sidenote: this might be slightly controversial, but I've sometimes
missed a --no-ff option to 'git merge' when working on plain git
repositories; IMHO preserving the 'logical' merge history when the
merge of a topic branch results in a fast-forward can be interesting.

If you really want one, use git commit-tree directly.

Yeah, that's an option, but --no-ff is somewhat less work ;-)

--
larsh

Hi,

On Tue, 18 Sep 2007, Lars Hjemli wrote:

Sidenote: this might be slightly controversial, but I've sometimes 
missed a --no-ff option to 'git merge' when working on plain git 
repositories; IMHO preserving the 'logical' merge history when the merge 
of a topic branch results in a fast-forward can be interesting.

Linus explained a lot of times why this is wrong.  It encourages 
upstream-downstream thinking.  We should really turn this into a FAQ.

Ciao,
Dscho

[...stripped the Cc, as we're slightly changing topic...]

On 9/18/07, Johannes Schindelin [off-list ref] wrote:

On Tue, 18 Sep 2007, Lars Hjemli wrote:

quoted

Sidenote: this might be slightly controversial, but I've sometimes
missed a --no-ff option to 'git merge' when working on plain git
repositories; IMHO preserving the 'logical' merge history when the merge
of a topic branch results in a fast-forward can be interesting.

Linus explained a lot of times why this is wrong.  It encourages
upstream-downstream thinking.  We should really turn this into a FAQ.

Well, the cases where I've wanted to do this is when I've developed
some new feature in cgit as a topic branch. I've then merged the topic
branch into my master branch which had been idle since the creation of
the topic branch (cgit doesn't get as many patches as git...). So I
get a fast-forward and my precious topic-branch is no longer visible
(at least for anyone cloning my repo). Not very important, but I'd
like to preserve the fact that this was a topic branch. How would this
encourage 'upstream-downstream thinking'?

-- 
larsh

Lars Hjemli wrote:

[...sorry for making this such a long thread...]

On 9/18/07, Sam Vilain [off-list ref] wrote:
  

quoted

Lars Hjemli wrote:
    

quoted

On 9/18/07, Sam Vilain [off-list ref] wrote:

      

quoted

I think that writing a real fast-forward merge should only happen on
dcommit, not git merge, because that is what is required for SVN.

        

I don't think git-svn has any way of knowing that the user wanted a
merge, unless a merge commit is present. So the user would have to
specify the set of commits which should be considered a merge during
dcommit (this would actually resemble how merges are performed in
subversion).

      

Sure it can.  If you're committing to branch X, and the current tree has
a whole lot of commits above that, then it should do the only thing you
can do with SVN.

Which is write a squash commit, and set the "svn:merge" and/or
"svk:merge" properties to represent what happened.
    

I often have prepared a series of local commits which I _want_ to
preserve as different subversion revisions.
  

But for the scenario we are discussing the revisions already exist
upstream otherwise there would be no fast forward merge.  So, if you
want that behaviour you can use cherry-pick on the git side and the
correct behaviour for git-svn is to write svn merge properties.

Also, doing a --squash means that I loose the merge history in git
(and then I need to edit the grafts file again)
  

There is no merge history in git, it was a fast forward.

quoted

quoted

Sidenote: this might be slightly controversial, but I've sometimes
missed a --no-ff option to 'git merge' when working on plain git
repositories; IMHO preserving the 'logical' merge history when the
merge of a topic branch results in a fast-forward can be interesting.
      

If you really want one, use git commit-tree directly.
    

Yeah, that's an option, but --no-ff is somewhat less work ;-)
  

Sure.  I just don't see a good use case for it from this yet.

Sam.

On 9/18/07, Sam Vilain [off-list ref] wrote:

Lars Hjemli wrote:

quoted

On 9/18/07, Sam Vilain [off-list ref] wrote:

quoted

If you really want one, use git commit-tree directly.

Yeah, that's an option, but --no-ff is somewhat less work ;-)

Sure.  I just don't see a good use case for it from this yet.

Ok. I'll try to explain why I needed --no-ff in the first place:

I have two git-svn brances, lets call them FEATURE and RELEASE. At one
point, I did
  $ git checkout FEATURE
  $ git merge RELEASE
  $ git svn dcommit

Now, my coworkers can continue testing/developing on top of the
subversion branch FEATURE (I'm currently the only git user), knowing
that every bugfix from RELEASE have been merged.

A few days later, FEATURE is completed and tested and should be
integrated in RELEASE. I did

  $ git checkout RELEASE
  $ git merge FEATURE
  $ git svn dcommit -n

and noticed that git-svn wanted to commit the result to FEATURE, since
the merge actually was a fast-forward. If this was a a pure git
environment it would be no problem, but as I needed to get a merge
revision on top of the subversion RELEASE branch, I was in trouble.

My options:
* rebase FEATURE onto RELEASE: this would have duplicated ~150
revisions from FEATURE onto RELEASE in subversion
* merge --squash: this would have created the wanted history in
subversion, but my git history would have lacked the info that
everything in FEATURE had been integrated into RELEASE (this could
have been fixed by editing the grafts file)
* merge --no-ff: this made both the subversion history and my local
git history reflect what actually happened.

So I went for the --no-ff option.

If this use-case isn't good enough, oh well. I can always carry the
patch forward in my git repo ;-)

--
larsh

Lars Hjemli wrote:

Ok. I'll try to explain why I needed --no-ff in the first place:

I have two git-svn brances, lets call them FEATURE and RELEASE. At one
point, I did
  $ git checkout FEATURE
  $ git merge RELEASE
  $ git svn dcommit

Now, my coworkers can continue testing/developing on top of the
subversion branch FEATURE (I'm currently the only git user), knowing
that every bugfix from RELEASE have been merged.

A few days later, FEATURE is completed and tested and should be
integrated in RELEASE. I did

  $ git checkout RELEASE
  $ git merge FEATURE
  $ git svn dcommit -n

and noticed that git-svn wanted to commit the result to FEATURE, since
the merge actually was a fast-forward. If this was a a pure git
environment it would be no problem, but as I needed to get a merge
revision on top of the subversion RELEASE branch, I was in trouble.
  

I understand.  But if you could specify a target branch of "RELEASE" to
dcommit (which git-svn might know based on which svn tracking branch it
was branched from), then it should be able to do the same thing that
'svn merge' would do on svn 1.5+, or 'svk sm' does.  Which is to write
to the SVN repository a squash merge, and write svn properties to let
merge-aware svn tools know which SVN revisions are being squashed.

My options:
* rebase FEATURE onto RELEASE: this would have duplicated ~150
revisions from FEATURE onto RELEASE in subversion
  

Yes, not desirable.

* merge --squash: this would have created the wanted history in
subversion, but my git history would have lacked the info that
everything in FEATURE had been integrated into RELEASE (this could
have been fixed by editing the grafts file)
  

This is a current deficiency in git-svn; bidirectional merge tracking is
not there yet.

* merge --no-ff: this made both the subversion history and my local
git history reflect what actually happened.

So I went for the --no-ff option.

If this use-case isn't good enough, oh well. I can always carry the
patch forward in my git repo ;-)
  

And you'll probably need to keep it around until bidirectional merge
handling is in.

Sam.