Junio C Hamano <gitster@xxxxxxxxx> writes:
Linus Arver <linusa@xxxxxxxxxx> writes:
Aside: interestingly, there appears to be a "--no-rebase" option that
means "--rebase=false" (see cd67e4d46b (Teach 'git pull' about
--rebase,
2007-11-28)):
--no-rebase
This is shorthand for --rebase=false.
...
How about adding something like this instead as the very first
paragraph
for this flag?
Supplying "--rebase" defaults to "--rebase=true". Running
git-pull
without arguments implies "--rebase=false", unless relevant
configuration variables have been set otherwise.
Phrase nit.
$ git pull origin
does run the command with arguments.
Ah, good catch.
What you mean is "running
git-pull without any --rebase arguments implies --no-rebase",
Right (modulo your "--rebase arguments" -> "--rebase option" correction
in your follow-up email).
but
that is saying "not giving --rebase=<any> and not giving --rebase
means not rebasing", which makes my head spin.
Me too.
"--no-rebase" as a command line option does have use to defeat
configured pull.rebase that is not set to "false"
Yes, I noticed this too after digging around a bit more after I sent my
message. Thanks for clarifying for the record.
and allowing
"pull.rebase" to be set to "false" does have use to defeat settings
for the same variable made by lower-precedence configuration file.
Indeed! I did not think of this. IOW, Git can be configured in
multiple places (the "pull.rebase" setting in ~/.gitconfig can be
overridden by the same config in ~/myrepo/.git/config).
"--rebase=false" does not have any reason to exist, except for
making the repertoire of "--rebase=<kind>" to be complete.
Agreed. In a sense, the docs for "--rebase=false" should say that it is
a synonym for "--no-rebase" (because "--no-rebase" came first,
historically), and not the other way around (that "--no-rebase" is
shorthand for "--rebase=false").
So, I am still not sure if saying "'git pull' (no other arguments
and no configuration) is equivalent to 'git pull --rebase=false'"
adds much value.
Fair point. That is, there are so many gotchas and "edge case"-like
behaviors to consider here, so the statement "'git pull' (no other
arguments
and no configuration) is equivalent to 'git pull --rebase=false'" is an
oversimplification that can be misleading. I agree.
If --no-rebase and --rebase=false are explained in terms of why
these options that specify such an unnatural action (after all, you
say "do this" or "do it this way", but do not usually have to say
"do not do it that way") need to exist.
If I were writing this patch, I would rearrange the existing text
like so:
* Update the description of "--no-rebase" *NOT* to depend on
--rebase=false. Instead move it higher and say
- The default for "git pull" is to "merge" the other history into
your history, but optionally you can "rebase" your history on
top of the other history.
- There are configuration variables (pull.rebase and
branch.<name>.rebase) that trigger the optional behaviour, and
when you set it, your "git pull" would "rebase".
- The "--no-rebase" option is to defeat such configuration to
tell the command to "merge" for this particular invocation.
* Update the description of "--rebase=<kind>" and move the
paragraph that begins with "When false" to the end, something
like:
- `--rebase` alone is equivalent to `--rebase=true`.
- When set to 'merges'...
- When set to 'interactive'...
- See `pull.rebase`, ..., if you want to make `git pull` always
rebase your history on top of theirs, instead of merging their
history to yours.
- `--rebase=false` is synonym to `--no-rebase`.
I think this captures the finer details while still preserving the
spirit of Dragan's original patch, so SGTM.
@Dragan if you are OK with doing the (much more substantial) change as
suggested, please do. Thanks!
