Re: pull --preserve-merges

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

 



> Awhile ago I brought up wanting to have a "rebase with preserve merges"
> option for `git pull`:
>
> http://thread.gmane.org/gmane.comp.version-control.git/96513
>
> Andreas had a patch to help by supporting manually typing out `git pull
> --rebase --preserve-merges`:
>
> http://thread.gmane.org/gmane.comp.version-control.git/96593
>
> And then I did another small copy/paste patch on top to add a config
> setting of `branch.<name>.preservemerges` much like the existing
> `branch.<name>.rebase`.

I just noticed the `branch.<name>.mergeoptions` flag in the merge docs.
Instead of having both `branch.<name>.rebase` and `.preservemerges`, and
possibly even more config parameters for whatever other people what to
configure as well, would something like `branch.<name>.pulloptions` be a
better idea?

In our case, we could then set all the `branch.<name>.pulloptions` to
"--rebase --preserve-merges" (likely via a post-checkout hook) and be
happy with `git pull` "just working".

Adding pulloptions would make the patch a little bit trickier, for me
to implement anyway, and I assume the rebase flag would have to stay
for backwards compatibility, but if a pulloptions config parameter
approach would be more acceptable than an explicit preservemerges
config (and hence more likely to get the patches accepted), I'd be
willing to work on that.

Thanks,
Stephen

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

  Powered by Linux