Updating x265 to a specific revision: git vs. Mercurial

[LigH]

I already asked it once in the x265 encoder thread, but there are still issues, and I don't want to clutter that thread more, so I'll prefer a separate thread.

When x265 used Mercurial (hg), I could use a simple shell script to update my local working directory to either the latest commit in the default branch, or the "tip" regardless of the branch, or a specific commit by checksum.

uptodate_x265.sh
#!/bin/sh
hg pull --cwd build/x265-hg -r "${1:-default}"
hg update --cwd build/x265-hg -r "${1:-default}"

Apparently, this worked due to the simplicity and flexibility of hg handling submitted parameters and deciding which meaning a parameter has.

I had to learn that I am not able to understand the meaning of all the parameters git offers to achieve the same result.

Until today I believed that the following script is able to ensure that my local working directory gets updated to the latest commit in the default branch:

uptodate_x265-git.sh
#!/bin/sh
git -C build/x265_git-git fetch -v --progress origin
git -C build/x265_git-git pull -v --no-rebase --progress origin master

But since I failed updating it to a specific revision by checksum with a modified script, until I ran a "git merge" command (which popped up a Vim which I don't want and need), I started to doubt that.

So I remain helpless. :confused:

It would be nice if I could have one script which does the same as my previous one, but won't mind if I have to split it into separate versions to handle default, tip, and revision-by-checksum-parameter in optimal sequences, to avoid complex case switches.

[LoRd_MuldeR]

In most cases a simple git pull will be sufficient ;)

Anyway, I think the most reliable way to update your local branch to the latest commit (HEAD) of the remote branch is:
git fetch --all && git reset --hard origin/master

If you want a different branch or a specific commit, replace origin/master with origin/some_branch or just commit_id. Additionally, you may want to run git clean -fdx after the update, in order to get rid of any old cruft.

Note that git pull is just a shorthand for git fetch followed by git merge FETCH_HEAD. In other words, it first fetches the latest changes from the remote tracking branch and then merges them into your local branch. This will create additional "merge" commits in your local branch, unless the merge is purely fast forward. These merge commits obviously won't exist on the remote. Also, the merge can fail for various reasons.

With the "git fetch plus git reset --hard" method you throw away the local changes (if any) and simply reset your local branch to the HEAD of the remote. It will not try to merge anything, which probably is what you want here.

Using a GUI like "Tortoise Git" can help to make things more obvious:
https://i.imgur.com/m7W3xRB.png

[LigH]

I want to run it semi-automated in scripts in the MinGW shells of MABS. So I will test your suggestions soonish...

I will always only retrieve from the distant repo to my local working directory, revoking local changes will be intended.

[LoRd_MuldeR]

I want to run it semi-automated in scripts in the MinGW shells of MABS. So I will test your suggestions soonish...

I will always only retrieve from the distant repo to my local working directory, revoking local changes will be intended.

Then I'd suggest either rm -rf the existing directory and do a fresh git clone or, as was suggested before, do git fetch followed by git reset --hard (followed by git clean -fdx) :)

[LigH]

Cleaning so thoroughly would be counterproductive, using MABS with ccache as environment, I found... but apart from that it works well now.