Hi, Kevin Buchs wrote: > For many years of using Git, I always struggled to make sense of > commit history graphs (git log --graph; gitk). Just recently I > discovered that git does not track the history of branches to which > commits belonged and the lightbulb turned on. This is proving to be > painful in a project I inherited with permanent multiple branches. > Now, I am a bit curious as to the rationale behind this intentional > decision not to track branch history. Is it entirely a matter of > keeping branches lightweight? > > I am assuming one can backfill for the missing capability by using a > commit hook to manually track when a branch head is changed. Perhaps > by storing the branch in the commit notes. I think this comes down to a question of mental model: one thing I value when using Git is that each commit does *not* belong to a specific branch --- branches describe the shape of history, and commits are points in that history. This becomes particularly relevant when working with multiple colleagues, sharing history between different servers: I may have a branch I call "linus" that points to the same history that a colleague called "master". That said, I can understand how that may be difficult to get used to coming from other version control systems (such as Subversion) in which a revision does belong to a branch. Can you say a little more about what aim you're trying to achieve when you want to make this lookup? For example: - are you looking to figure out what the commit author was working on when they made the commit? For that, the commit message is meant to provide context, and a commit hook like you describe can be a good way to enforce that (for example if you want every commit message to contain a bug number for context). - are you looking to find out *when* a commit became part of a particular published branch? It's true that Git doesn't provide a good way to do that today. I have some hope that some best practices like discussed in [1][2] will coalesce for attesting to the history of a branch's state. If you always perform merges with --no-ff, then you can find some things out using the --first-parent history. It is possible to enforce such practices using hooks, but this may be a lot of fuss for little gain, depending on the underlying need. I find "git log --ancestry-path" to be very useful for finding out *how* a commit became part of a particular published branch. - or are you looking for this information for some other purpose? Returning to your question: one reason that I find Git not recording the current branch name to be liberating is that I am not great at naming things. I can use a placeholder name, knowing that I am its only audience, without fear of embarrassment. Thanks and hope that helps, Jonathan [1] https://git.eclipse.org/r/c/51128, describing refs/meta/push-certs [2] https://lore.kernel.org/git/22945.15202.337224.529980@xxxxxxxxxxxxxxxxxxxxxx/
