1. 50
  1.  

  2. 17

    I’m a fan of the merge approach, with the requirement the commit messages are useful.

    … with this kind of an entangled graph, it’s practically impossible to find anything in it.

    git log --first-parent is great for this. If you are on main, it will show you only merge commits and any commits made directly to main without including all the commits on the branches. Although the author is correct that branches are just pointers and you can’t know which branch a commit was created on, the first parent of a merge commit will always be the “main” branch. This is enough information for –first-parent to filter the history of a branch when needed without actually throwing it away when merging. More info here: https://www.davidchudzicki.com/posts/first-parent/

    1. 5

      Responded to this on the orange site as well, but git has both the ability to view a “clean” squash-and-rebase style history, as well as a chronological history of when commits entered the main branch, as well as a “true” history of when commits were authored (IMO least useful history, despite it being the default of git log)… Assuming you use regular merges with --no-ff, which is the default on Github.

      • To view the history of PR merges: git log --merges

      • To view the history of when commits entered the main branch (i.e. view all commits, but group them by PR rather than interspersing based on commit timestamp): git log --topo-order. Some people don’t like viewing the “useless” merge commits in this view, so you can also pass --no-merges if you want to skip those (IMO it’s useful to see them, but if you disagree, you can filter them out).

      • To view the fairly useless history of when commits were authored, of course, you just use git log. This probably shouldn’t have been the default; I can’t think of a time I ever wanted this view. I think much of the handwringing around merge/rebase strategies is due to git choosing this as the default log view, and thus Github choosing it as the only log view in its GUI.

      Since Github doesn’t support any of these views other than the fairly useless default one, unfortunately, many people aren’t aware of them. But git already supports “commit groups” — that is, branches — with rich ways of viewing the history of a repo! You don’t need to destroy commit history in order to get the views you want.

      1. 4

        So this prevents you from being able to confidently answer questions such as: [..] “what was the state of main as of a given date?”.

        Although it is not w/o caveats when talking about a refname git accepts a date. Quoting man 7 gitrevisions:

            [<refname>]@{<date>}, e.g. master@{yesterday}, HEAD@{5 minutes ago}
                   A ref followed by the suffix @ with a date specification enclosed in a brace pair (e.g.  {yesterday}, {1 month 2
                   weeks 3 days 1 hour 1 second ago} or {1979-02-26 18:30:00}) specifies the value of the ref at a prior point in time.
                   This suffix may only be used immediately following a ref name and the ref must have an existing log
                   ($GIT_DIR/logs/<ref>). Note that this looks up the state of your local ref at a given time; e.g., what was in your
                   local master branch last week. If you want to look at commits made during certain times, see --since and --until.
        

        This doesn’t detract from the point of the post, but I thought I’d share

        1. 3

          I enjoyed the discussion of various commit strategies. We do rebase and merge, but in combination with bors to squash our PRs into a single commit at the end. I definitely feel like something is lost in that strategy however. Something like commit groups would definitely be nice.

          1. 4

            If you rebate and then merge –no-ff what would you gain by also squashing things? It seems like you lose the story if you squash, whereas a merge –no-ff gives you a clean “commit group” on the graph

            1. 1

              You lose having every commit on master beeing green.

              1. 3

                Green? You mean passing tests? Why are you making commits that don’t pass tests?

                1. 3

                  Testsuites can take a lot of time. It’s not perfect but it is a reality.

          2. 3

            I got quite confused by “merge commit 9 in the image above” until I realized that you’re referring to the diagram, not the screenshot.

            1. 3

              Funnily enough, Bazaar NG does something extraordinarily close to this: merges are shown as a collapsed commit that’s basically just the entire merge. While you can explode the merge into the component commits, that requires a bit of extra digging. This is the one and only feature of Bazaar I somewhat preferred over Monotone, Git, and Mercurial at the time.

              Modern Mercurial allows something pretty similar via changeset evolution: basically, the actual final changeset (commit) would be a squash-and-rebase, but you can inspect its history to see the original component changesets that existed prior to the squash. This feature hasn’t yet been merged into core Mercurial, but has been on the shortlist for quite a while.

              1. 1

                I always loved bazaar’s UI and design. I used it for personal projects for a short while but then got too frustrated by its performance. I also lost some code while using the plugin which allows you to use it as a frontend for git repos, which made it hard for me to trust it anymore. I switched to Mercurial for a while afterwards, but eventually to git because it became clear that it had throughly won the VCS wars.