2

Is there a way to do a detailed, deep comparison of your local GIT repo vs the remote repo?

By this I mean a full comparison of file names, dates and contents, not just a comparison that relies on the GIT history information.

This may sound like a strange request, but after having just spent hours wrestling with GIT I would like extra confirmation that my local repo is really in the state it is telling me.

Improve this question
1
  • have you tried the basic, git diff -- origin/master assuming your local is on the master branch? if it's not, just shift the origin/<branch> Commented Feb 22, 2016 at 15:49

3 Answers 3

Reset to default
3

Well, the hash of the last commit is based on all the information you mentioned. So all you need is to do git fetch and then check the hash of the last commit. If you would like to be extra sure, you can run git fsck to make sure the repo is in a consistent state (git fsck will basically check all the checksums so if anything was changed by some insidious error, this will catch it).

Improve this answer
Sign up to request clarification or add additional context in comments.

2 Comments

I don't believe a git diff is what I mean, because it is so quick it is obviously just comparing the log of your local repo vs the remote one. I want something to actually compare the files. I will look at git fsck though.
@AntCDLWaters yeah, dit diff uses git graph to find out which files needs to be compared. But that's totally ok, as I said, it's not possible to have different files in remote and local branch without git knowing about it - with an exception of git metadata corruption - which could be checked by git fsck. See how it actually works here: newartisans.com/2008/04/git-from-the-bottom-up
2

For starters you may safely assume that two git commits having a same SHA1 are the same and focus on your working directories.

Is the same commit checked out?

Anything shown in git status?

Potentially ignored via .gitignore?

Are there any line ending conversions (mac,linux v win)?

Improve this answer

Comments

0

This may sound like a strange request, but after having just spent hours wrestling with GIT I would like extra confirmation that my local repo is really in the state it is telling me.

You dont need to verify it.

Using the fetch command you r local repository will be up to date with the remote repository.
Simply run this command:

# update the local repo with all the changes from the remote repo # including tags, branches and remove deleted branches as well git fetch --all --prune

git fetch

Fetch branches and/or tags (collectively, "refs") from one or more other repositories, along with the objects necessary to complete their histories.

Remote-tracking branches are updated .

--all

Fetch all remotes.

-p / --prune

After fetching, remove any remote-tracking references that no longer exist on the remote.

Tags are not subject to pruning if they are fetched only because of the default tag auto-following or due to a --tags option.

However, if tags are fetched due to an explicit refspec (either on the command line or in the remote configuration, for example if the remote was cloned with the --mirror option), then they are also subject to pruning.

Improve this answer

1 Comment

My concern is that, as far as I know, GIT Fetch does not compare the actual files, but instead will rely on the recorded history of what has been done locally, and on the remote repo, and the differences between the two histories. That's fine, but I was hoping for an additional check that would be more akin to comparing the two folder structures directly. This is analogous to using a script to copy files, but also wanting to check the result afterwards (rather than just relying on the output from the copy command).

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.