1

I use the following commands to push local branch changes to remote branch (in some automated script):

#while being on main branch
git checkout -B new_local_branch_unix_timestamp

#optionally modify some files

# check if there are modified files
git diff --exit-code

# if there are changes commit and push
git commit -am 'commit message'
git push --set-upstream origin new_local_branch_unix_timestamp

# get latest local commit id 
git rev-parse HEAD

# busy wait until latest remote commit id equal to latest local commit id 
# latest remote commit id is extracted using
git rev-parse origin/new_local_branch_unix_timestamp

Busy wait means applying git rev-parse origin/new_local_branch_unix_timestamp fixed number of times until local last commit id equals remote last commit id.

Running git rev-parse origin/new_local_branch_unix_timestamp to get latest remote commit id occasionally returns below output and error.

stdout: origin/new_local_branch
sterr: fatal: ambiguous argument 'origin/new_local_branch_unix_timestamp': unknown revision or path not in the working tree. Use '--' to separate paths from revisions, like this: 'git <command> [<revision>...] -- [<file>...]'

It's very rare and random.

I always mitigate it by removing local repository, recloning remote one. Then the above steps succeed until the next time.

Is there a reason why it happens and is there a better way to mitigate it?

There could be many remote branches created earlier with similar names (having similar first characters, because of unix timestamps similarity).

Could this be the reason for sterr: fatal: ambiguous argument git error?

rok
  • 9,403
  • 17
  • 70
  • 126
  • 1
    Is `origin/origin/new_local_branch_unix_timestamp` a typo or is that really what the message says? I ask because `sterr:` was clearly a manual typo. – jthill Aug 04 '21 at 16:06
  • it's a typo, fixed the question – rok Aug 09 '21 at 08:14

1 Answers1

1

Your local Git will create or update origin/* names based on branch name existence (and hash IDs found) in the other Git repository over at origin. If you set fetch.prune to true or use git fetch --prune or git remote update --prune, your local Git will also delete origin/* names based on the other Git's branch names.

The updating happens "opportunistically". That is, your Git gets, from their Git, a list of some or all of their branch names and hash IDs, on some operations: particular git fetch (or git remote update, which is largely the same code). If your Git has, or obtains, the appropriate commits at this time, your Git is then able to create or update your remote-tracking names at this time, and does so.

In very old Git versions (predating 1.8.4), some updating does not happen even when the opportunity crops up and you must use an unrestricted git fetch to force the update to occur.

The error you are seeing occurs when your local Git repository has not created the origin/* remote-tracking name corresponding to some branch name you expected your Git to have seen. In that case, running git fetch (with or without --prune) or git remote update should fix the problem.

You have a rather abstract comment:

# busy wait until latest remote commit id equal to latest local commit id

What's not clear is how you implement this "busy wait": whether it uses git fetch, and if so, whether it uses a restricted git fetch. If you are using a restricted git fetch and have a particularly ancient Git, you'll definitely see issues. Even if you're using an unrestricted git fetch and have a modern Git, I can envision races here, depending on how you've implemented this operation, which you have not described.

torek
  • 448,244
  • 59
  • 642
  • 775
  • Thanks a lot! By `busy wait` i mean apply `git rev-parse origin/new_local_branch_unix_timestamp` fixed number of times until local last commit id equals remote last commit id. I've updated the question. – rok Aug 09 '21 at 08:05
  • 1
    Unless you, or someone else, is doing some other Git operation (`git fetch` etc) in the repository, the loop doing this busy-wait won't ever see any value change. So *something* must be doing Git operations that eventually lead to the value changing, or—since you say "fixed number of times"—you run out of retries. If you're running out of retries and/or whatever is updating this doesn't create the *other* remote-tracking name, that's the problem. – torek Aug 09 '21 at 08:20
  • 1
    Note that if this something-else (whatever it is) *is* using `git fetch -p` or `git remote update --prune`, that could delete the remote-tracking name you're busy-waiting-on. – torek Aug 09 '21 at 08:22