1. 15
  1.  

  2. 15

    I don’t get what this buys you over short lived and tightly scoped branches deleted on Pull/Merge…

    Sometimes I like having multiple commits in a PR, it tells a story I would like told

    1. 6

      This is something lost in the translation of changeset evolution in Mercurial to branchless Git: in Mercurial, the entire history of that changeset is cleanly preserved (and shareable!) in the repo history, so you can see the story when you want it, but just the overall change in the common case. Git really doesn’t provide a good facility to do that (at least, not today), which is where git-branchless ends up with the limitation you’re highlighting. I’m unfortunately not sure how you’d really navigate around that without some changes to core Git’s management of refs, at a bare minimum.

      1. 1

        git-branchless keeps the history of the commit in your repository, but unfortunately, this information can’t easily be synced between machines at present.

        I’ve been thinking about if it’s possible to add this to Git while still supporting common workflows. One way is to store obsolescence markers and rewrite edges as files in the source tree, under some .branchless directory. Since these structures form a CRDT, there should be an encoding which is conflict-free under Git’s merge rules as well (for example, say that there is a rewrite edge from abc to def iff there exists a file .branchless/rewrite/abc/def in the source tree).

        However, this doesn’t ensure that the pointed-to-objects are actually kept live. There are some encodings which would keep the objects live using a lot of parent commits, which might work when communicating directly with a Git server, or when using services like Github where you can create a multi-parent commit as part of a pull request, but I don’t see a way to support a patch-based workflow, since Git patches fundamentally don’t represent merge commits (or other data).

      2. 3

        I’m not using a branchless git tool now, but this sounds very attractive to me. I think what it gets you is that the process is automated.

        For me as a solo dev, I usually start work on something, realize that I should be in a branch, make a branch (which means thinking up some short arbitrary name for what I’m doing), get to where I think I’m done, do a pull request and review my work, and then finally merge it in, but then I have to back and clean things up by switching back to main and pulling, deleting the local branch, etc. It’s sort of a waste of time usually since for me having multiple live branches is the exception. It means I didn’t finish work on a feature before I had to do something else first. If I could get a tool to handle it for me, that would be nice.

        1. 3

          I also work on a branch for “too long” in hindsight, and Magit has a perfect (IMO) solution for this. It does all your steps with the two keys “b s” (see magit-branch-spinoff here: https://magit.vc/manual/magit/Branch-Commands.html). This is one of the many user-friendly interfaces Magit provides, and I think it hits a sweet spot between magic and shortcuts to things I already know about.

        2. 2

          Try it out – it’s really nice. And you can still have multiple commits in a PR.

        3. 5

          Instead of 1-commit-per-PR, do 1-local-branch-per-PR, which is “git as intended”.

          1. 2

            Sounds a lot like got ( http://gameoftrees.org/ ), where i have to take a 2nd look at. I hear it’s progressing nicely.

            1. 1

              I thought got was a BSD reimplementation of git.

              1. 1

                It uses the git repo, but promotes a different development cycle. Main branch with linear history and feature branches which need to be rebases on main (HEAD) before merge, to get a linear main branch again. So very similar to “branchless git”

            2. 1

              There’s definitely a need for tools to better manage a “sequence of related changes” workflow. (I’ve been trying out Graphite at work for that exact use case and it has saved me a ton of time.)

              But I’m not sure I’d want to work in a fully branchless setup. A pretty common scenario for me is that I’ll fix a few bugs in a row, each in its own branch, and send out a PR for each one. There is no ordering among them: any of them can be merged first, and any of them can be revised based on review feedback without holding up the others. Modeling that set of fixes as a single linear thread of history obscures the fact that they don’t have any dependencies on one another.

              1. 2

                You can do that with git-branchless too. Just base each commit off main, or commit them sequentially and then use git move -s bugfix_sha -d main to move them later before uploading a PR. For example, here is part of my smartlog at work right now, with commit info removed:

                ◇ main
                ┣━┓
                ┃ ◯
                ┃ ┣━┓
                ┃ ┃ ◯
                ┃ ┃ ┃
                ┃ ┃ ◯
                ┃ ┃ ┃
                ┃ ┃ ◯
                ┃ ┣━┓
                ┃ ┃ ◯
                ┃ ┃ ┃
                ┃ ┃ ●
                ┃ ┣━┓
                ┃ ┃ ◯
                ┃ ┃
                ┃ ◯
                ┣━┓
                ┃ ◯
                ┃
                ◯
                

                I already give the commits descriptive titles, so managing branch names is just a chore. With git-branchless I don’t have to.

                1. 2

                  Unfortunately, the name “git-branchless” unnecessarily discourages potential users! I haven’t found a good name to capture the essence of it; “git-branchless” just seemed to be one of the better of a poor set of choices.

              2. 1

                I guess this is the same concept as squashing before merging?

                1. 1

                  I’ve been looking for something like this. I really enjoy pr’s being one commit but i hate the loss of history that comes with the constant amending or a final squash.