Junio C Hamano wrote:
> Ramkumar Ramachandra <artag...@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
> 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.
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html