From: Ramkumar Ramachandra <artagnon@gmail.com>
Date: Sat, 13 Apr 2013 21:54:56 GMT
Subject: Re: [ITCH] pull.default
Message-ID: <CALkWK0kbsYgOy6KjcgZe8+cKucqzWPQ3wyp3SqaYy372pW0eFw@mail.gmail.com>
In-Reply-To: <7vy5dkmt7k.fsf@alter.siamese.dyndns.org>

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