0

I'm working on a project using git and github that has several contributors, and each one has their own fork.

I recently made a commit on the master branch of the original project (merging a branch called chris-work), and then (as an experiment) re-based one of the forks (using details in How do I update a GitHub forked repository?); this leads to a picture like this, where the fork is shown in yellow.

screenshot

If you'd like to see the live graph, it's here.

The newly-re-based fork has no new changes, and should be (and is) completely the same as the master branch from the main project, and yet it appears to be out in front.

I'm sure this is to be expected, but it seems that to remove the fork from the Network diagram I have to submit and merge a (seemingly) redundant pull request. Could someone explain the finer details, and help me understand this behaviour?

Community
  • 1
  • 1
cmhughes
  • 911
  • 1
  • 8
  • 17

1 Answers1

1

Git commit IDs (SHA-1 hashes) are calculated based on several pieces of information, including

  • the content of the commit,
  • the parents of the commit,
  • the commit message,
  • the timestamp of the commit, and
  • probably a few I'm forgetting.

The important thing is that many bits of data and metadata affect the generated hash. If any are different (timestamp and parents in this case, at least), you'll get a different hash, which means a different commit. Git will never consider two commits to be equal if they have different hashes.

In this case, the tip of your rebased branch has id 13c310f and the tip of your your "real master" has id 2d51e9e.

Note also that rebasing of published commits is strongly discouraged.

ChrisGPT was on strike
  • 127,765
  • 105
  • 273
  • 257
  • +1 thanks for information, it's very helpful. So is this the expected behaviour? or should I be using `forks` differently? As you might have seen in the link, we're creating a (quite big) document, and we're using `git` & `github` to help with the version control. instead of forks should we simply be using branches? If you have any insight, I'd be much obliged. – cmhughes Jan 07 '14 at 04:08
  • @cmhughes, yes, this is expected behaviour. You can use forks or branches in this case; it depends whether you want to give contributors commit access to your repository. (You can still do merge requests between branches in one repository, if you wish.) I think the issue you're really concerned with is rebasing. Rebasing a commit will always change its hash, which is why it is [strongly discouraged to rebase pushed commits](http://git-scm.com/book/en/Git-Branching-Rebasing#The-Perils-of-Rebasing). – ChrisGPT was on strike Jan 07 '14 at 14:00
  • Thanks for the follow-up, I really appreciate your time. Reading the link you provided (which might be worth adding to your answer), it sounds like I would be better served using `merge` rather than `rebase`? Or is the fix more complicated? Thanks again. – cmhughes Jan 07 '14 at 18:52