1

I have a problem which is the reverse case of the problem here and here. My situation looks like this:

enter image description here

So, remotes/origin/master is ahead of master. When I issue git status I obtain:

On branch master
Your branch is behind 'origin/master' by 1 commit, and can be fast-forwarded.
  (use "git pull" to update your local branch)

However, I do not want to move or fast-forward master to remote/origin/master. Rather, I want remotes/origin/master to move back or rewind to where master currently is. All of the Local uncommitted changes, not checked in to index has been backed up elsewhere so that after moving remotes/origin/master back to master, I can recreate the changes if needed. All of the changes currently in remotes/origin/master are not useful and can be discarded.

I tried the following:

git branch -d babe82a3bb3efb71e6fdff38e40ec08fe691e5d6 in an attempt to achieve this rewind of remotes/origin/master. This gives error:

error: branch 'babe82a3bb3efb71e6fdff38e40ec08fe691e5d6' not found.

I then tried:

git branch -d remotes/origin/master, and this gives error:

error: branch 'remotes/origin/master' not found.

Is there a way to achieve this?

yivi
  • 42,438
  • 18
  • 116
  • 138
Tryer
  • 3,580
  • 1
  • 26
  • 49

1 Answers1

2

The reason the git branch -d remotes/origin/master fails is simple enough: it's not a branch. What it is, is a remote-tracking name, rather than a branch name. It's often shown as just origin/master: Git is inconsistent about how much to remove from names like refs/heads/master, which becomes master, vs refs/remotes/origin/master, which becomes either origin/master or remotes/origin/master depending on whether Git feels like stripping off one component—refs/—or two, refs/remotes/.

Your Git—your software, working in/on your repository—creates or updates remote-tracking names based on what your Git gets from some other Git: some version of Git software working in/on some other repository. That other repository has branch names, which find commits. When you connect your Git to their Git, your Git gets from them any commits they have, that you don't, and then creates or updates your remote-tracking names to remember where their branch names go.

So, this means their branch named master identifies commit babe82a3bb3efb71e6fdff38e40ec08fe691e5d6. Your own Git repository has this commit because you got it from their Git repository; your Git finds it using the name origin/master, as produced by changing master (their branch name) into origin/master (your remote-tracking name).

If you think their Git repository should move their branch name master back one step so as to forget babe82a3bb3efb71e6fdff38e40ec08fe691e5d6, and instead use whichever commit your own master specifies, you can use a forced git push operation to command them—their Git software on their repository—to do that. Whether their Git will obey your Git's command is up to them. Note that their commit may be in millions of other clones by now (depending on how popular their Git repository is). If it's only in their repository, and you have permission to "rewind" their branches like this with git push --force or git push --force-with-lease, you'll be fine.

torek
  • 448,244
  • 59
  • 642
  • 775
  • This worked out exactly. When I issued `git push --force` I obtained: `Total 0 (delta 0), reused 0 (delta 0), pack-reused 0 + babe82a...f599114 master -> master (forced update)` and then on going to the online repo, indeed there is no mention of the `babe82a...` commit/push. – Tryer Sep 12 '21 at 07:14
  • 1
    Yes - the commit itself (babe82a...) might linger on the server for some time (especially noticeable on GitHub, where there are URLs you can use to find out: just visit some commit that you can find easily, then swap in the raw hash ID of the other one) but you won't *see* it, and other Gits getting commits from the Git at `origin` won't see it either. – torek Sep 12 '21 at 07:23
  • There seems to be a size limit on private repositories on github. Would pushes such as `babe82a3bb3efb71e6fdff38e40ec08fe691e5d6` above, once they are "rewound", still continue to contribute to the limit? I would expect that once they are disassociated as above, they do not contribute to a user's upper size limit and they are routinely cleaned from the system and not occupy unnecessary space. – Tryer Sep 12 '21 at 11:11
  • 1
    There are multiple size limits. The one most people hit first is on individual file sizes: GitHub do some extra GitHub-only checking of the size of each file ("blob", really) stored in each commit, and if any one file goes over 100 MB, they reject the commit entirely, so it never winds up in the repository at all. I'm not sure how one reaches the other size limits as I have never run into that myself. :-) If you find yourself hitting size limits that don't seem to make sense other than maybe the "removed" commit, you could contact the GitHub support folks. – torek Sep 12 '21 at 19:14