[ITCH] pull.default

[ITCH] pull.default

[Ramkumar Ramachandra]

Hi,

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?

Ram

Re: [ITCH] pull.default

[Junio C Hamano]

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.

Re: [ITCH] pull.default

[Ramkumar Ramachandra]

Junio C Hamano wrote:
> 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").

Excellent I was hoping to start a discussion like this.  My initial
thought was designing a custom script that git-pull will execute like
a hook; we should, however, be able to get away with designing enough
configuration orthogonal configuration variables.  For anything more
complex, just do it by hand!

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

Will do.  Expect a draft soon.

Re: [ITCH] pull.default

[Ramkumar Ramachandra]

Junio C Hamano wrote:
> 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").

Okay, so this is what I currently have:

- pull.condition = clean-worktree | ff-update | no-local-changes |
always | never
- pull.action = merge | rebase* | reset
- pull.resetType = soft | hard | merge | keep
- pull.autostash = true | false

(ff-update is satisfied when FETCH_HEAD is directly ahead of
refs/remotes/<branch>, while no-local-changes is satisfied when
FETCH_HEAD is directly ahead of refs/heads/<branch>)

Personally, I would love the defaults pull.condition = ff-update,
pull.action = rebase, pull.autostash = true.  However, there are
branches that I have where this isn't applicable.  Any clues on how to
design branch-specific options for all these (there's
branch.<name>.pullAction is a bit yuck)?

Did I manage to cover everything?  Now that pull.autostash is done, I
will start writing pull.condition after feedback.

* pull.rebase is pending deprecation