On 2014-05-04 06:17, Felipe Contreras wrote:
> Richard Hansen wrote:
>> On 2014-05-03 23:08, Felipe Contreras wrote:
>>> It is the only solution that has been proposed.
>>
>> It's not the only proposal -- I proposed a few alternatives in my
>> earlier email (though not in the form of code), and others have too. In
>> particular:
>>
>> * create a new 'git integrate' command/alias that behaves like 'git
>> pull --no-ff'
>
> Yeah but that's for a different issue altogheter. I doesn't solve the
> problems in 1. nor 2. nor 3.
'git integrate' would handle usage cases #2 (update a published branch
to its "parent" branch) and #3 (integrate a completed task into the main
line of development), making it feasible to change 'git pull' and 'git
pull $remote [$refspec]' to default to --ff-only to handle usage case #1
(update local branch to @{u}).
>
>> * change 'git pull' and 'git pull $remote [$refspec]' to do --ff-only
>> by default
>>
>> Another option that I just thought of: Instead of your proposed
>> pull.mode and branch.<name>.pullmode, add the following two sets of configs:
>>
>> * pull.updateMode, branch.<name>.pullUpdateMode:
>>
>> The default mode to use when running 'git pull' without naming a
>> remote repository or when the named remote branch is @{u}. Valid
>> options: ff-only (default), merge-ff, merge-ff-there, merge-no-ff,
>> merge-no-ff-there, rebase, rebase-here, rebase-here-then-merge-no-ff
>
> Those are way too many options to be able to sensibly explain them.
Certainly this is too many options for a first patch series, but I don't
think they're unexplainable. (I listed a bunch of options because I was
trying to envision where this might take us in the long run.)
For the first patch series, I'd expect: merge (which uses the merge.ff
option to determine whether to ff, ff-only, or no-ff), rebase, and ff-only.
Later ff-only would be made the default.
Later some or all of the other options would be added depending on user
interest.
>
>> * pull.integrateMode, branch.<name>.pullIntegrateMode:
>>
>> The default mode to use when running 'git pull $remote [$refspec]'
>> when '$remote [$refspec]' is not @{u}. Valid options are the same
>> as those for pull.updateMode. Default is merge-ff.
>>
>> This gives the default split behavior as you propose, but the user can
>> reconfigure to suit personal preference (and we can easily change the
>> default for one or the other if there's too much outcry).
>
> If we reduce the number of options to begin with (more can be added
> later),
yup
> then it might make sense to have these two options.
>
> However, that doesn't change the proposal you described above (1. 2.
> 3.).
Not sure what you mean. I oulined three usage cases:
#1 update local branch to @{u}
#2 update a published branch to its "parent" branch
#3 integrate a completed task into the main line of development
Having these two sets of options (updateMode and integrateMode) would
make it possible to configure plain 'git pull' to handle usage case #1
and 'git pull $remote [$refspec]' to handle usage cases #2 and #3.
Or the user could configure 'git pull' and 'git pull $remote [$refspec]'
to behave the same, in case they find the different behaviors to be too
confusing.
> There's something we can do, and let me clarify my proposal. What you
> described above is what I think should happen eventually, however, we
> can start by doing something like what my patch series is doing; issue a
> warning that the merge is not fast-forward and things might change in
> the future.
OK, let me rephrase to make sure I understand:
1. leave the default behavior as-is for now (merge with local
branch the first parent)
2. add --merge argument
3. add ff-only setting
4. plan to eventually change the plain 'git pull' default to ff-only,
but don't change the default yet
5. add a warning if the plain 'git pull' is a non-ff
6. wait and see how users react. If they're OK with it, switch the
default of the plain 'git pull' to ff-only.
Is that accurate? If so, sounds OK to me.
>
> If people find this behavior confusing they will complain in the mailing
> list.
true
> Although I suspect it would be for other reasons, not the 'git
> pull'/'git pull $there' division.
probably
> Either way we would see in the discussion.
sounds good to me
>
>>>>>> 3. integrate a more-or-less complete feature/fix back into the line
>>>>>> of development it forked off of
>>>>>>
>>>>>> In this case the local branch is a primary line of development and
>>>>>> the remote branch contains the derivative work. Think Linus
>>>>>> pulling in contributions. Different situations will call for
>>>>>> different ways to handle this case, but most will probably want
>>>>>> some or all of:
>>>>>>
>>>>>> * rebase the remote commits onto local HEAD
>>>>>
>>>>> No. Most people will merge the remote branch as it is. There's no reason
>>>>> to rebase, specially if you are creating a merge commit.
>>>>
>>>> I disagree. I prefer to rebase a topic branch before merging (no-ff) to
>>>> the main line of development for a couple of reasons:
>>>
>>> Well that is *your* preference. Most people would prefer to preserve the
>>> history.
>>
>> Probably. My point is that the behavior should be configurable, and I'd
>> like that particular behavior to be one of the options (but not the
>> default -- that wouldn't be appropriate).
>
> All right. But I'm a bit overwhelmed by all the things to keep in mind.
Sure, this would be an option to add later.
> Does your proposed IntegradeMode/UpdateMode deal with this?
mode = rebase-here-then-merge-no-ff would do what I described
> Anyway, I'll try to grab what I can from previous discussions (mainly
> about switching the merge parents) and create a new thread with a
> summary.
That would be nice, thanks.
-Richard
--
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