Re: [ITCH] pull.default

[Junio C Hamano <gitster@pobox.com>]

Ramkumar Ramachandra <artagnon@gmail.com> writes:

> I usually use `git fetch`, inspect state, and then merge/ rebase
> accordingly.  Unfortunately, this is very sub-optimal as I can
> automate this 80% of the time.  I want to be able to decide what to do
> on a repository-specific basis, and hence propose a pull.default which
> can be set to the following:
> 1. fetch.  Just fetch.  (I will set this as my default in ~/.gitconfig)
> 2. fast-forward.  Fetch.  If the FETCH_HEAD is directly ahead of HEAD,
> `stash`, merge, and stash apply.  Otherwise, do nothing.
> 3. rebase.  Fetch.  stash, rebase, stash apply. `git pull n` will do
> rebase --onto master HEAD~n instead of rebase.
> 4. reset.  Fetch, stash, reset --hard FETCH_HEAD, stash apply.
>
> Ofcourse, it should print a message saying what it did at the end.
>
> What do you think?

Many other possibilities are missing.  "fetch and merge", for
example.

You seem to be generalizing the "--rebase" and "--ff-only" options
of "git pull" with 2 and 3, which may (or may not) make sense.

I think you can shrink and enhance the above repertoire at the same
time by separating "do I want to have stash and stash pop around"
bit into an orthogonal axis.  The other orthogonal axes are "Under
what condition do I integrate the work from the upstream?" (e.g.
"only when I do not have anything, aka, ff-only") and "How would I
integrate the work from the upstream?" (e.g. "rebase my work" and
"discard anything I did aka reset --hard").

By the way, I do not think you should start your design from a
configuration (this is a general principle, not limited to this
case).  Think about what the smallest number of independent options
you need to add to express various workflows, and then turn them
into configuration variables that can set the default, all of which
have to be overridable from the command line.