Sign Up to our social questions and Answers Engine to ask questions, answer people’s questions, and connect with other people.
Login to our social questions & Answers Engine to ask questions answer people’s questions & connect with other people.
Lost your password? Please enter your email address. You will receive a link and will create a new password via email.
Please briefly explain why you feel this question should be reported.
Please briefly explain why you feel this answer should be reported.
Please briefly explain why you feel this user should be reported.
As I understand it, a git commit object will always point exactly one tree object.
What I’m wondering is whether, in practice, this tree object is always guaranteed to be a git repository’s top-level tree object, representing the entire state of my code at the point the commit object was created.
Is there any chance, in an actual git repository, that any commit object could point to a tree object lower down in the hierarchy?
Well, commits DO always point to the entire tree/branch history as it was at the time of commit, but you’re not limited to having just one history in your repository…
You can have a branch for ProjectA and a branch for ProjectB (with completely different histories and sets of files) and using the subtree merge strategy, you can merge ProjectB’s changes into a subdirectory of ProjectA, keeping the history of ProjectB attached! Now, those commits from ProjectB’s branch history will still be in the root of their branch, but the merge commit will map them into a subtree of ProjectA. You can even re-merge when there are more commits in ProjectB to get the updates in ProjectA.
Pretty confusing thing to do though, if you ask me… This Pro Git section suggests merging without keeping the history from the other branch, which seems a lot saner.