Communities

Writing
Writing
Codidact Meta
Codidact Meta
The Great Outdoors
The Great Outdoors
Photography & Video
Photography & Video
Scientific Speculation
Scientific Speculation
Cooking
Cooking
Electrical Engineering
Electrical Engineering
Judaism
Judaism
Languages & Linguistics
Languages & Linguistics
Software Development
Software Development
Mathematics
Mathematics
Christianity
Christianity
Code Golf
Code Golf
Music
Music
Physics
Physics
Linux Systems
Linux Systems
Power Users
Power Users
Tabletop RPGs
Tabletop RPGs
Community Proposals
Community Proposals
tag:snake search within a tag
answers:0 unanswered questions
user:xxxx search by author id
score:0.5 posts with 0.5+ score
"snake oil" exact phrase
votes:4 posts with 4+ votes
created:<1w created < 1 week ago
post_type:xxxx type of post
Search help
Notifications
Mark all as read See all your notifications »
Q&A

Welcome to Software Development on Codidact!

Will you help us build our independent community of developers helping developers? We're small and trying to grow. We welcome questions about all aspects of software development, from design to code to QA and more. Got questions? Got answers? Got code you'd like someone to review? Please join us.

Comments on Is `git pull` dangerous?

Parent

Is `git pull` dangerous?

+4
−2

I heard git pull is dangerous.

  • Is it really dangerous?

  • If so, why or how is it dangerous?

  • Are there any flags that mitigate or remove the danger?

  • What are the alternatives if it is dangerous?

History
Why does this post require attention from curators or moderators?
You might want to add some details to your flag.
Why should this post be closed?

1 comment thread

Unclear (3 comments)
Post
+4
−3

git pull is dangerous, but not a security problem. The only danger is that it's difficult or inconvenient (but not impossible) to recover to the state prior to the pull, if it would be necessary.


Merge commits

The remote branch might have diverged from your own, in which case git will automatically try to resolve any conflicts with a merge commit. This might result in bad conflict resolutions (although that's rare).

This can be solved by running git pull --ff-only instead, which will only merge the origin changes if your local branch can be fast-forwarded (no merge commits).

If there are any local changes not in the remote branch, the pull will fail, and you'll be able to resolve the situation with a different method.

However, this solution doesn't solve the other problems of git-pull(1), so continue reading.


Predictability

git-pull(1) performs two operations:

  • download the latest branch from the remote
  • merge it to the local branch

But you can't predict what's in the remote branch. This means that your local branch will blindly jump to whatever commit the remote branch is in (assuming git pull --ff-only, and that your local branch has no changes).

You won't know where your branch was prior to the jump, unless you wrote the old commit hash somewhere. If after the pull you find out that you don't like the changes and want to go back to the old state, it will be hard to know where you were. (Imagine for example that the remote could have been hacked, and malicious contents could have been introduced in the branch.)

git-pull(1) has no way to mitigate this, since it's a problem inherent to the fact that git-pull(1) performs two operations.

The solution is to run two commands to perform those operations separately:

  • git fetch origin
  • git merge --ff-only origin/master

Between the fetch and the merge, you can print a graph of the log, to analyze what will be merged:

$ git fetch origin
$ git log --all --graph --oneline
$ git merge --ff-only origin/master  # or rebase, or whatever you need; you already know what you're merging.  :)

Printing the log graph in the terminal will also let you have all the commit hashes written, in case you make any mistakes and need to go back to the original state (git reset <old-master> --hard) and start again.

This approach allows you to review all of the remote commits before merging them into any local branch.

History
Why does this post require attention from curators or moderators?
You might want to add some details to your flag.

3 comment threads

Losing old HEAD is not unpredictable (9 comments)
Unfamiliar notation (7 comments)
Use config rather than command-line flags (4 comments)
Unfamiliar notation
trichoplax‭ wrote 3 months ago

I notice that in several places the notation "git pull(1)" is used, which I do not understand. It makes me think of either a label or a footnote, but I can see no previous introduction of a label, nor a footnote at the end of the answer.

Is there some other meaning to the "(1)"? If so could this meaning be defined in the answer for people like me who are unfamiliar with it?

alx‭ wrote 3 months ago · edited 3 months ago

Sure. It's Unix notation for commands that have a manual page.

See this extract from the intro(1) manual page (the first page of the Linux programmer's manual):

$ MANWIDTH=72 man intro | sed -n '/Getting information/,+12p'
   Getting information
     There are thousands of commands, each with many  options.   Tradi‐
     tionally commands are documented on man pages, (like this one), so
     that  the  command "man kill" will document the use of the command
     "kill" (and "man man" document the command  "man").   The  program
     man  sends  the  text  through  some pager, usually less.  Hit the
     space bar to get the next page, hit q to quit.

     In documentation it is customary to refer to man pages  by  giving
     the  name  and section number, as in man(1).  Man pages are terse,
     and allow you to find quickly some forgotten detail.  For  newcom‐
     ers  an  introductory  text with more examples and explanations is
     useful.

Skipping 1 deleted comment.

alx‭ wrote 3 months ago · edited 3 months ago

git-pull(1) basically means that you can run man 1 git-pull

trichoplax‭ wrote 3 months ago

Thanks for explaining. I would not expect everyone who has a use for git to also have sufficient Unix knowledge to know why a command is postfixed "(1)", so I'd recommend mentioning this in the answer (perhaps in a footnote), rather than just in one of the comment threads.

The notation makes sense in the context of a man page. Outside that context, numbers in parentheses are used with many other meanings, so using the notation without mentioning why is likely to lead to confusion for some readers (such as me).

alx‭ wrote 3 months ago

I think the comment should be enough. It's common to explain these details in comments. :)

It is actually common in Unix contexts to use this notation, BTW, even outside of manual pages. Hopefully, using it more will make people more used to it.

matthewsnyder‭ wrote 3 months ago

IMO in this context it's okay to assume the reader has heard of man pages, and even noticed the common idiom of identifying programs according to the title of their manual section. It makes no difference to say "git-pull(1)" or git pull.

That said, since you used git pull in your question, you might as well be consistent and use that in the answer.

alx‭ wrote 3 months ago · edited 3 months ago

I originally wrote git-pull(1) in the title too, but thought that it might cause confusion in the title, so I changed it to git pull in the title but kept git-pull in the text. :)

In running text, when I mean exactly git pull (with no flags), I use that. When I mean the command, with any optional flags, I say git-pull(1).