CODEWITHSUNDEEP
gitversion-controlgit-branchrebasepull
MRedant
MRedant

Reputation: 15

Difference between 'git pull origin develop --rebase' and 'git pull --rebase origin develop'

I couldn't find a difference but could there be one? Between:

Git docs state :

git pull [<options>] [<repository> [<refspec>…​]]

So you would think of option B being the correct one, but than..

Upvotes: 0

Views: 335

Answers (1)

torek
torek

Reputation: 487755

There are competing theories on how rigid one should be with placement of options vs arguments. POSIX utility guidelines prescribe what you called Option B. Git, however, tries to be quite flexible about option placement, even when there are optional or required positional arguments.

These are the general rules for Git options:

  • Options placed between git and the sub-command verb, such as git --no-replace-objects log, are handled by the Git front end (the git program itself). The front end transforms these into environment variable settings, which means that there's always an environment variable you could set instead. For instance:

     git --git-dir=<path> ...

    and

     GIT_DIR=<path> git ...

    do the same thing.

    Options placed after the sub-command verb are handled by the sub-command.

  • Single-letter options, such as -v, are preceded by a single hyphen, and can be grouped together. Multi-letter options, such as --name-status, are preceded by a double hyphen. Hence in git diff, there is a -c option ("combined diffs") but also a --cc option ("dense combined diffs"); the single-c option takes a single dash and the double-c option takes a double dash.

  • Anything starting with a hyphen is an option, anywhere, except after a double-hyphen.

The git filter-branch command breaks the last rule a bit because it has to parse its own options, then pass some options to git rev-list. So with filter-branch, you run:

git filter-branch <filter-options> -- <rev-list-options>

and the <rev-list-options> itself can have options, then a second stand-alone double hyphen --, then path names.1

This all adds up to what you called Option A. But note that if you write your commands with Option B in mind, they all work under Option A.

and is there maybe an order by which the options are handled?

There were, in the past, for some Git sub-commands, some places where order was particularly important. That's fixed now but you will see this remark in the git checkout-index documentation:

The order of the flags used to matter, but not anymore.

In general, however, options are processed in the order they appear, and often, a repeated option will overwrite a previous one. For instance:

git --git-dir=/tmp --git-dir=.git status

uses .git as the Git directory, not /tmp.

1By can here, I mean is physically able to. You shouldn't actually use this capacity with git filter-branch as it is a form of aiming a gun at your own foot.

Upvotes: 1

Related Questions