Re: [ITCH] pull.default

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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


[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]