0

I did git clone some 12 days ago, and then since then, I have updated or added a branch in that repo foo from upstream (where my repo was forked from GitHub).

But in that old directory, I could not even change to that branch at first.

And then, I did

git fetch --all
git checkout -b some-branch-name   # the  -b  is important or else it 
                                   #   thinks some-branch-name is a filename

and can switch to that branch. But when I git log, I am seeing the most recent commit that was 12 days ago.

How do I make it current? If I git clone again from GitHub and git checkout <some-branch-name>, then I git log and will see commits done today instead of 12 days old.

But I don't want to have to set everything up again using npm i etc etc, so I would hope to have the old directory be able to see the current branch content.

nonopolarity
  • 130,775
  • 117
  • 415
  • 675

2 Answers2

0

A branch name remembers some specific commit for you. A tag name does the same thing. The difference between the two (branch name vs tag name) is that Git, and Git users, are expected to move branch names to newer commits.

In your case, you would simply run:

  • git fetch or git fetch origin: the origin part is the name of a remote, which is mainly just a short name for a URL. This tells your Git to call up another Git—the Git you cloned from originally—and to bring in new commits that you do not already have. It remembers where the other Git's branches are, using your remote-tracking branch names. So if they have a branch named master, you get one named origin/master, which remembers where their Git's master was on the last git fetch.

  • git log on the remote-tracking branch name(s): for instance, git log origin/master to see what is in origin/master after you have updated your origin/master from the other Git's master.

  • git merge or git rebase: these merge with, or rebase (copy) your commits, on to some other branch, such as a remote-tracking branch.

If you create a new branch (as you did with git checkout -b), this new branch probably does not have an upstream setting. You can choose one (and only one) of your remote-tracking branches to set as its upstream. For instance, if your new branch some-branch-name should have origin/master as its upstream:

git branch --set-upstream-to=origin/master some-branch-name

Once you have set this, your Git knows that when you are on your some-branch-name branch, a plain git merge or git rebase should use your origin/master to do the merge or rebase.

Once you know how all this works, you can combine the git fetch command and the second (merge or rebase) command using the git pull convenience command. I recommend delaying this until you are familiar with the individual commands. Sometimes, the second command (of the two commands that git pull runs for you) fails. When this command fails, you need to know what command you were running. If you know only git pull you will not know what second command you were running!

torek
  • 330,127
  • 43
  • 437
  • 552
  • the `-b` was not to create the branch here but to switch branch. Without the `-b`, it thinks `some-branch-name` is a filename, and keep on giving `error: pathspec 'some-branch-name' did not match any file(s) known to git.` – nonopolarity Jun 28 '17 at 00:34
  • 1
    But `-b` *does* create a branch. For that matter, `git checkout master` in a new clone *also* creates a branch—it's just that it automatically creates one *from* `origin/master` with the new branch's upstream set to `origin/master`. This is a special case that `git checkout` implements: if you name a local branch that does not exist yet, it looks to see if it can create a local branch from one of your remote-tracking branches. If `some-branch-name` does not match exactly one remote-tracking branch name, Git cannot create the local branch using this short-cut. – torek Jun 28 '17 at 00:42
  • hm... as it is right now, if it created a branch... then why is it showing the most recent commit as of 12 days ago? The bottom line is, how do I get it to show the commit as of today? (to make the directory current) – nonopolarity Jun 28 '17 at 00:44
  • Once you are on a branch, that's *your branch* to do with as you will. If you wish to update your branch, you must tell Git to update your branch, as I said above. – torek Jun 28 '17 at 00:45
  • how do I "update" the branch? I have `git fetch` and `git fetch --all`... so why is it not current? What do I need to do to "update"? As I said if I `git clone` again and switch to that branch, I see it all "updated". So why not that old folder? – nonopolarity Jun 28 '17 at 00:49
  • As I said above, `git fetch` brings in the commits and updates your *remote-tracking* branches (but not *your* branches, those are *yours*). You must then run a second command, such as `git merge` or `git rebase`, to update your own branches. You can also create new branches or delete existing branches—all of these are *your* branches, as opposed to your remote-tracking branches, which are your Git's memory of some other Git's branches. – torek Jun 28 '17 at 02:01
0

git checkout -b some-branch-name creates a new branch some-branch-name from HEAD and then checks out the new branch. If HEAD points to the commit 12 days ago, the new branch points to this old commit too.

If a branch in the remote repo, which is the fork in your case, has been updated since your last clone. You could update the local corresponding branch:

git checkout <branch-name>
git fetch origin <branch-name>
git merge FETCH_HEAD
#Or use rebase. It depends on your workflow and strategy.
git rebase FETCH_HEAD

The fetch-merge is equivalent to git pull origin <branch-name>, and fetch-rebase to git pull --rebase origin <branch-name>, by default.

It doesn't matter if it has no upstream branch. If the local branch has no local new commits yet, or if it has but you think they can be abandoned, git reset FETCH_HEAD --hard is also okay.

ElpieKay
  • 19,185
  • 5
  • 22
  • 36