Richard Hansen wrote:
> 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),
But these cases are completely different. One should reverse the
parents, the other one not.
I feel if a new command is to be added, it should be the one that is
introducing the brand new behavior: switching the parents. So it would
be appropriate for 1. and 2.
> >> * 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.)
Actually I think they are too many for any point in time.
Maybe pull.updateArgs would make more sense.
> 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.
Seems sensible.
> > 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.
Not if by default they are already handled.
> > 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.
That is what my patch series is doing already, basically.
The new warning I'm proposing would be for the split behavior of 'git
merge' and 'git merge $there'. Which is what is worrysome.
> mode = rebase-here-then-merge-no-ff would do what I described
I think that mode is way too specific to be useful for most people.
--
Felipe Contreras
--
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