Re: [ITCH] pull.default

> 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.