Re: [PATCH v2] pull: require choice between rebase/merge on non-fast-forward pull

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

 



Eric Sunshine <sunshine@xxxxxxxxxxxxxx> writes:

> Dropping the parenthetical comment might improve flow slightly:
>
>     Without repository or branch on the command line, `git pull`
>     needs to be told how to integrate the changes with your history,
>     via either `--merge` or `--rebase`.
>
> With or without mention of the configuration options, either phrasing
> seems pretty easy to digest.

Yeah, that reads much better, but I do prefer to see something that
explains this is often "just make sure you use the one that suits
your project and always use that".  How about something like this?

    With no repository or branch on the command line, `git pull` needs
    to be told how to integrate the changes with your history.

    This can be done via either `--merge` or `--rebase` option, but most
    people would want to decide which method matches the workflow of the
    project once, and set the configuration variable `pull.rebase` or
    `branch.<name>.rebase` to stick to it; see linkgit:git-config[1].
--
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]