Re: [ITCH] pull.default

From: Ramkumar Ramachandra <artagnon@gmail.com>
Date: Apr 13, 2013, 21:54 UTC
Message-ID: <CALkWK0kbsYgOy6KjcgZe8+cKucqzWPQ3wyp3SqaYy372pW0eFw@mail.gmail.com>
In-Reply-To: <7vy5dkmt7k.fsf@alter.siamese.dyndns.org>

Junio C Hamano wrote:

Show 7 quoted lines

> 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