1

1) In local repo, I created and switched to a branch postacl by running git checkout -b postacl

2) Then I ran git push -u origin postacl

3) From the remote repo, while I was still on the master branch there, I accidentally ran git pull origin postacl. Then I realized that I did not switch to postacl.

What happened due to the above-mentioned actions?

Tanmay
  • 3,009
  • 9
  • 53
  • 83
  • Assuming your created a new branch from master and pushed it to remote repo, pulling the changes into master from this newly created repo won't affect anything if you haven't committed and pushed any changes to `postacl`. – Shubham Khatri Jul 25 '18 at 05:22
  • Possible duplicate of [What is the difference between 'git pull' and 'git fetch'?](https://stackoverflow.com/questions/292357/what-is-the-difference-between-git-pull-and-git-fetch) – phd Jul 25 '18 at 12:00
  • https://stackoverflow.com/a/7169390/7976758 – phd Jul 25 '18 at 12:01

3 Answers3

1

In the general case, most likely, you just added a merge commit on top of your local master branch. You may verify this by running git log from your master branch. You would probably see a new merge commit, with a commit message mentioning something about a merge. If you don't see any merge commit, then you need not do anything. If you do see one, then keep reading.

In this particular case, you should be safe just doing a hard reset to remove the merge commit:

git reset --hard HEAD~1

This should nuke that accidental merge commit, leaving your local master as it was. You could also try resetting your local master to the tracking branch:

git reset --hard origin/master
Tim Biegeleisen
  • 502,043
  • 27
  • 286
  • 360
1

git pull means:

  1. Run git fetch, passing (most of) any additional arguments on to git fetch
  2. Run git merge (default—you can change this), merging the commit(s) brought in via step 1

So this meant:

git fetch origin postacl

which had your Git call up the Git that you call origin and obtain from them their latest commits on their postacl branch. Then, your Git ran:

git merge --edit -m <message> <commit-hash-ID>

where the <message> part is the string:

Merge branch 'postacl' of <url> [into <branch>]

(using the <url> stored with your name origin), and the <commit-hash-ID> is whatever commit hash ID their Git told your Git that their postacl branch names. (The into <branch> part appears if and only if you are on some branch other than master.)

This is almost the same as if you ran:

git fetch origin && git merge origin/postacl

except that the default merge message in this case would be slightly different.

Note that if you did all this while logged in to some other machine ("the remote repo", as you put it), "your" Git is the one on that remote machine, and "their" Git is the one that the remote machine's Git has set as its origin.

torek
  • 448,244
  • 59
  • 642
  • 775
  • `So this meant` ... unless the original problem has pull configured to use rebase, in which case the steps would be different. Also, there may not have been a merge commit at all if the branch doesn't have any commits beyond what `master` already had. – Tim Biegeleisen Jul 25 '18 at 05:29
  • @TimBiegeleisen: Right: `git merge` might do nothing, or might produce a fast-forward; or `git pull` might be configured to run `git rebase` as its step 2. Had the OP included the *output* from `git pull`, we could say a lot more. – torek Jul 25 '18 at 05:38
1

First, you've simply created a new branch from the master (assuming).

Second, you've pushed without changes and using -u changed the branch to track the changes, so whenever you're going to use argument less git pull then it will consider postacl's head refs to use as FETCH_HEAD.

And at third step, it'll show you something like this:

From <url>:<org>/<branch>
 * branch              <tracking_upstream_branch>     -> FETCH_HEAD
Already up to date.
Gaurav Paliwal
  • 1,556
  • 16
  • 27