Re: cc/cherry-pick-ff

From: Jonathan Nieder <jrnieder@gmail.com>
Date: Mar 20, 2010, 22:09 UTC
Message-ID: <20100320220914.GA31098@progeny.tock>
In-Reply-To: <7v1vffqdm4.fsf@alter.siamese.dyndns.org>

Junio C Hamano wrote:

> Christian Couder <chriscool@tuxfamily.org> writes:

Show 11 quoted lines

>> ... if we implement "git cherry-pick A..B", and if many people 
>> start to use it, then perhaps it will make sense for --ff to become the 
>> default.
>
> That doesn't make any sense to me.
> 
> Think why you are saying A..B, with an explicit "A".
> 
> It is because you know it is different from HEAD; otherwise you would have
> done "git merge B"---slurp all changes between HEAD..B, which would be
> equivalent to "cherry-pick --ff HEAD..B".

In a project that is deeply dedicated to a linear history, the workflow might be something like this:

 contributor:
	hack hack hack
	git commit
	...
	git pull --rebase upstream; # Rebase for submission upstream.
	git push +HEAD:topic

 upstream:
	git pull --cherry-pick contributor1 topic
	git pull --cherry-pick contributor2 other-topic
	...
	run tests
	git push master

Here, “git pull --cherry-pick remote branch” is shorthand for “git fetch remote branch && git cherry-pick --ff HEAD..FETCH_HEAD”. It is not always a fast-forward because contributors’ changes can be based on an out-of-date upstream version.

This imposes all the conflict resolution trouble on upstream and blames the result on the contributors, which may be what some people want (especially if upstream and the contributors are all the same person).

> But running cherry-pick as the top-level operation is a conscious act of
> "I want to replay the change done by that one", and it would be utterly
> confusing if it fast-forwarded by default.

All that said, I still agree with this conclusion. It is only a gut feeling. I could be convinced in the future, but I do not want to impose the imagined work of adding --no-ff to scripts until it is clear it is the right thing to do.

One way to avoid trouble: add a --no-ff option, but make it mean “negates any previous --ff option on the same command line”. This way, _if_ we decide to ask in the release notes for 1.8 for people to add --no-ff to their scripts in preparation for 1.9, then they can do so without breaking compatibility with git 1.7.1 (and without adding a version check).

Cheers, Jonathan