9

Instead of a one long flat commit history, why isn't there a hierarchy, so at the top level you might have pull requests, then you could go down a level and look at the commits in that PR. I realise that PR's are specific to github, but you get the idea. I just mean grouping a number of commits as a feature or bug-fix, for example.

Surely it would make the commit history a lot easier to navigate.

I'm sure there is an obvious answer this question, but I can't seem to find it.

  • 1
    A user interface could probably group commits for display and navigation. But it doesn't seem universally useful enough to hard-wire in the (very general and workflow-agnostic) core. – user7043 May 20 '14 at 8:55
  • If the commits are logically distinct, they should not be grouped. If they are logically parts of one change, they should be one commit (that's what all the rebase stuff is for). And if they are related, they will most likely be close together and easy to find anyway. – Jan Hudec May 20 '14 at 9:11
  • This is done as you describe with the use off branches, read up on feature-branches. – iveqy May 20 '14 at 10:01
  • ask the people who designed git, I'm sure they know why they made their design decisions. – jwenting May 20 '14 at 10:09
  • I agree with the poster conceptually. The fact that something works in a certain way right now, does not mean that it should. Personally, I use "squash merge" frequently to summarize several commits into one, and put that into the master branch. The level of detail I want to see in master is higher than in development for instance. The problem with that is that there is basically no relationship between the newly-created squash commit and the commits that originated it. I can certainly imagine being able to group several commits into one, which itself a commit with a clear before and after – Daniel Langdon Jun 16 '16 at 15:49
9

There is one long flat commit history because the changes are sequential. Each one build on the 'before' state and leaves an 'after' state. It would be hard to have changes not reflect this.

One option for grouping related changes is to use tags - http://git-scm.com/book/en/Git-Basics-Tagging though they are used more for tagging a point in history rather than grouping disparate commits.

To group together commits into larger ones you can also do interactive rebasing.

Branches are one option, You can create a branch and do a bunch of commits that are logically related. You can merge those commits back into master as desired - probably using the --no-ff option.

The relationship between branches can also be seen in visual tools such as gitg/gitx enter image description here

| improve this answer | |
0

I had the same issue thinking about this until I discovered that Git numbers its parent branches. Given this, the usually annoying merge commits that are generated can be considered summary nodes. And all extra details can be banished from view, leaving a single, summarized linear history.

Check this blog post for details and examples.

| improve this answer | |
0

You group commits in branches: each branch is a set of commits. When you merge commits, you are putting one set of commits inside another branch, effectively building a hierarchy of commits: main branch, features, bugs, experiments, you name it.

Ideally, your main branch is a succession of merge commits. If you only look at first-parents (git commands accepts such an option), you'll have the high-level view of your history (hopefully, you write a meaningful merge commit, not the auto-generated one). But when you look at the 2nd, 3rd, etc. parents of a merge in your history, you are opening the box to see what's inside a merge. Here you have details of what happened.

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.