Re: [PATCH v2] pull: require choice between rebase/merge on non-fast-forward pull
Has this patch been released yet? -- View this message in context: http://git.661346.n2.nabble.com/first-parent-commit-graph-layout-and-pull-merge-direction-tp7586671p7602383.html Sent from the git mailing list archive at Nabble.com. -- 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
Re: [PATCH v2] pull: require choice between rebase/merge on non-fast-forward pull
Eric Sunshine sunsh...@sunshineco.com writes: +When `git pull` that does not explicitly specify what branch from +which repository is to be integrated with your history on the +command line, recent Git will refuse to work until you specify how +that integration should happen, either with a command line option +(`--merge` or `--rebase`) or a configuration variable (`pull.rebase` +or `branch.name.rebase`, which is the same as `--merge` +(`--rebase`) when set to `false` (`true`) respectively. This paragraph-long single sentence may be intimidating. Perhaps some simplification is possible: As a safety measure, bare `git pull` (without repository or branch) needs to be told how to integrate pulled changes with your history; either via `--merge` or `--rebase`. Also see configuration variables `pull.rebase` and `branch.name.rebase` in linkgit:git-config[1]. I intentionally omitted the true/false explanation of the configuration variables since the user can follow the link and read about them. It also may make sense to drop mention of those variables altogether since they are already described (including link) in the description of --rebase. I also intentionally omitted recent Git since it's rather nebulous. Looks much better than the original. I would further suggest dropping the As a safety measure, bare at the beginning. `git pull` (without repository or branch on the command line) needs to be told how to integrate the changes with your history via either `--merge` or `--rebase` (see configuration variables `pull.rebase` and `branch.name.rebase` in linkgit:git-config[1]). perhaps? -- 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
Re: [PATCH v2] pull: require choice between rebase/merge on non-fast-forward pull
On Fri, Jul 19, 2013 at 12:22 PM, Junio C Hamano gits...@pobox.com wrote: Eric Sunshine sunsh...@sunshineco.com writes: +When `git pull` that does not explicitly specify what branch from +which repository is to be integrated with your history on the +command line, recent Git will refuse to work until you specify how +that integration should happen, either with a command line option +(`--merge` or `--rebase`) or a configuration variable (`pull.rebase` +or `branch.name.rebase`, which is the same as `--merge` +(`--rebase`) when set to `false` (`true`) respectively. This paragraph-long single sentence may be intimidating. Perhaps some simplification is possible: As a safety measure, bare `git pull` (without repository or branch) needs to be told how to integrate pulled changes with your history; either via `--merge` or `--rebase`. Also see configuration variables `pull.rebase` and `branch.name.rebase` in linkgit:git-config[1]. I intentionally omitted the true/false explanation of the configuration variables since the user can follow the link and read about them. It also may make sense to drop mention of those variables altogether since they are already described (including link) in the description of --rebase. I also intentionally omitted recent Git since it's rather nebulous. Looks much better than the original. I would further suggest dropping the As a safety measure, bare at the beginning. `git pull` (without repository or branch on the command line) needs to be told how to integrate the changes with your history via either `--merge` or `--rebase` (see configuration variables `pull.rebase` and `branch.name.rebase` in linkgit:git-config[1]). perhaps? That works; or without the mentioning the configuration variables at all (assuming the reader will discover them from reading --rebase description): `git pull` (without repository or branch on the command line) needs to be told how to integrate the changes with your history via either `--merge` or `--rebase`. 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. -- 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
Re: [PATCH v2] pull: require choice between rebase/merge on non-fast-forward pull
Eric Sunshine sunsh...@sunshineco.com 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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] pull: require choice between rebase/merge on non-fast-forward pull
On Fri, Jul 19, 2013 at 6:20 PM, Junio C Hamano gits...@pobox.com wrote: Eric Sunshine sunsh...@sunshineco.com 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]. At this point, I'm probably just bike-shedding. Perhaps? With no 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`. To match a project's workflow and make the choice of merge or rebase permanent, set configuration variable `pull.rebase` or `branch.name.rebase` (see linkgit:git-config[1]). -- 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
Re: [PATCH v2] pull: require choice between rebase/merge on non-fast-forward pull
Eric Sunshine sunsh...@sunshineco.com writes: 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]. At this point, I'm probably just bike-shedding. Perhaps? With no 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`. To match a project's workflow and make the choice of merge or rebase permanent, set configuration variable `pull.rebase` or `branch.name.rebase` (see linkgit:git-config[1]). I agree with the bike-shedding aspect of your comment, and actually I like my version better. It makes it clear that a single-shot --merge or --rebase from the command line is not recommended. To match the project's workflow is not optional in most projects, and it is preferrable to decide once and set the choice in stone. -- 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
Re: [PATCH v2] pull: require choice between rebase/merge on non-fast-forward pull
On Thu, Jul 18, 2013 at 3:35 PM, Junio C Hamano gits...@pobox.com wrote: Add a safety valve to fail git pull that does not explicitly specify what branch from which repository to integrate your history with, when it is neither a fast-forward or already up-to-date, until/unless the user expressed her preference between the two ways of integration. --- diff --git a/Documentation/git-pull.txt b/Documentation/git-pull.txt index 24ab07a..86f5170 100644 --- a/Documentation/git-pull.txt +++ b/Documentation/git-pull.txt @@ -97,6 +97,14 @@ must be given before the options meant for 'git fetch'. Options related to merging ~~ +When `git pull` that does not explicitly specify what branch from +which repository is to be integrated with your history on the +command line, recent Git will refuse to work until you specify how +that integration should happen, either with a command line option +(`--merge` or `--rebase`) or a configuration variable (`pull.rebase` +or `branch.name.rebase`, which is the same as `--merge` +(`--rebase`) when set to `false` (`true`) respectively. This paragraph-long single sentence may be intimidating. Perhaps some simplification is possible: As a safety measure, bare `git pull` (without repository or branch) needs to be told how to integrate pulled changes with your history; either via `--merge` or `--rebase`. Also see configuration variables `pull.rebase` and `branch.name.rebase` in linkgit:git-config[1]. I intentionally omitted the true/false explanation of the configuration variables since the user can follow the link and read about them. It also may make sense to drop mention of those variables altogether since they are already described (including link) in the description of --rebase. I also intentionally omitted recent Git since it's rather nebulous. -- 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
