4 ms·

Branchless Workflow for Git

54 points by modinfo 4y ago

wodenokoto 4y ago
What makes the workflow branchless?
- Izkata 4y ago
  Answer might be under Demos -> Visualize -> Why not git log --graph? > git log --graph only shows commits which have branches attached with them. If you prefer to work without branches, then git log --graph won't work for you. This seems to be about working with commits, including branched trees/graphs, without creating a named branch..?
  - arxanas 4y ago
    > This seems to be about working with commits, including branched trees/graphs, without creating a named branch..? That's correct.
sebazzz 4y ago
The biggest issue of working without branches is that virtually all code review tools nowadays work on a Pull Request basis (thus branches). Almost no tool allows adding individual commits to a code review, the only one I know is Upsource but that is unfortunately no longer being developed. As my team does trunk based development we're struggling with that. Since we're not able to find a code review tool that is compatible with our workflow, I assume we are doing something wrong and trunk based development is no longer an industry practice - though it works very well for us.
- choeger 4y ago
  And all these tools struggle with incremental code reviews for some reason. There are currently two options: 1. Add new commits to an existing branch. Any reviewier always needs the context from the earlier commits. 2. Overwrite the whole branch (force push). Older comments, and generally the delta between different versions of the change request, get lost or are at least very hard to see (e.g., might get mixed with changes from a rebate). Working with the patch/commit as artifact (as, e.g., Gerrit does it) seems so much more usable for code review that I can only speculate why no big tool offers it. Presumably, it requires too much internal knowledge about git to implement the backend correctly.
- littlestymaar 4y ago
  Sending git patches on a mailing list works I guess (after all, it works well enough for the Linux kernel), but yeah it's a bit crude of a tool…
- arxanas 4y ago
  Trunk-based development is still in use at large companies. Usually they use something like Gerrit or Phabricator. You could try tools like https://graphite.dev/ https://graphite.dev/ or https://reviewable.io/ https://reviewable.io/, or Meta's Sapling + ReviewStack.
doix 4y ago
I feel like I have a pretty good understanding of git, but the problems these helpers are trying to solve make my head spin. > git rebase --interactive can only repair linear series of commits, not trees. If you modify a commit with multiple children, then you have to be sure to rebase all of the other children commits appropriately. Can someone explain (preferably with a sequence of git commands) how you end up in such a situation? When would you end up modifying a commit with multiple children? Is this for a case where a bunch of people branch from master@HEAD (lets call this A), then you need to modify A, so you then need to rebase each branch that branched from A individually? I guess the workflows I'm used too explicitly try to avoid doing things that cause the problems that these helpers try to solve. I'm so used to thinking in this current mode that I find it hard to imagine when these problems would arise. 'git undo' terrifies me though. I really hate when there's lots of magic going on and I don't know what state my git repo will end up when I run a command. I rather run N commands, where I'm pretty confident what will happen in each stage, than one command that just 'fixes' things. Because if it fails to fix something, I'll be in some unknown state without understanding how I got into it.
- arxanas 4y ago
  > Is this for a case where a bunch of people branch from master@HEAD (lets call this A), then you need to modify A, so you then need to rebase each branch that branched from A individually? Mainly it's for when you branch from A multiple times, and then modify A. This can happen if you have some base work that you build multiple features on top of. I routinely do this as part of rapid prototyping, as described here: https://github.com/arxanas/git-branchless/wiki/Workflow:-divergent-development https://github.com/arxanas/git-branchless/wiki/Workflow:-div... `git undo` shows a list of operations it'll execute, which you have to confirm before accepting. Of course, it's ultimately a matter of trust in the tools you use.
  - doix 4y ago
    Ah, I should have looked through the wiki. That is cool, I do something similar with a scuffed workflow with lots of cherry-picking. My approach does look significantly worse than this helper though. > `git undo` shows a list of operations it'll execute, which you have to confirm before accepting. Of course, it's ultimately a matter of trust in the tools you use. Nice! I guess it's time to setup rust and check this out. Are you the author? I hope my comments did not come across as too negative. It's more a matter of me living in a git bubble and failing to appreciate the tool.
bmitc 4y ago
Although GitHub offers a lot of features and generally makes Git tolerable, I’ll be pretty happy when Git gets supplanted by something else more popular and hopefully better. The latter should not be hard to do. As someone who cut my teeth on Perforce, I’m still learning the ins and outs of Git and generally actively avoid Git features. Whereas with Perforce, I was writing custom applications using its API and powerful workspace concept in just a couple years. Perforce is just easier to understand, easier to customize, great visualization tools, and has more sane names for things.
- sausagefeet 4y ago
  I use Mercurial and hg-git, which is a two-way interface between mercurial and git, and except for a few situations (tags, for example) it is, IMO, a vastly superior client to git. I think a possible step forward would be to just accept git as an underlying file format and build clients that are not insane on top of it. Maybe we could move off the file format later.
  - bmitc 4y ago
    Plastic SCM has some Git interfacing, but I’m unsure of the details. I like some of their other solutions as well, namely semantic versioning. https://docs.plasticscm.com/gitsync/plastic-scm-version-control-gitsync-guide https://docs.plasticscm.com/gitsync/plastic-scm-version-cont...
  - arxanas 4y ago
    https://github.com/martinvonz/jj https://github.com/martinvonz/jj and http://sapling-scm.com/ http://sapling-scm.com/ are good steps in this direction!
- unmole 4y ago
  Heh. I picked up git in college because I wanted to hack on the Linux kernel. Once I grokked git's simple data model, I have never run into problems with it. On the other hand, I've had to use Perforce professionally and I find it unbearable. It lacks features and everything is just convoluted and ridiculously slow in comparison. Thankfully I can avoid having to deal with Perforce using a git wrapper.
kramerger 4y ago
Why should I want to use smartlog instead of something like tig? While at it, I am amazed how much effort people put into not using git as intended due to some (often imaginary) corner case shortcomings I do like the performance improvements and git sync however, maybe they could be merged into mainline git?
antman 4y ago
This is kind of presented like a tool but it really is a workflow, I think presenting it in an e.g. gitflow manner woukd make it more clear on how it would work on an example project
tlarkworthy 4y ago
I have a lot of trouble pipelining my commits when I get reviewer comments on an early branch, it's very error prone to squash the changes and distribute downstream to avoid merge problems later. I think this tool is for me, am I able to adopt it without my team needing too?
- arxanas 4y ago
  Yes, it's entirely client-side.

54 points by modinfo 4y ago

wodenokoto 4y ago

What makes the workflow branchless?

Izkata 4y ago
Answer might be under Demos -> Visualize -> Why not git log --graph? > git log --graph only shows commits which have branches attached with them. If you prefer to work without branches, then git log --graph won't work for you. This seems to be about working with commits, including branched trees/graphs, without creating a named branch..?
- arxanas 4y ago
  > This seems to be about working with commits, including branched trees/graphs, without creating a named branch..? That's correct.

sebazzz 4y ago

The biggest issue of working without branches is that virtually all code review tools nowadays work on a Pull Request basis (thus branches). Almost no tool allows adding individual commits to a code review, the only one I know is Upsource but that is unfortunately no longer being developed. As my team does trunk based development we're struggling with that. Since we're not able to find a code review tool that is compatible with our workflow, I assume we are doing something wrong and trunk based development is no longer an industry practice - though it works very well for us.

choeger 4y ago
And all these tools struggle with incremental code reviews for some reason. There are currently two options: 1. Add new commits to an existing branch. Any reviewier always needs the context from the earlier commits. 2. Overwrite the whole branch (force push). Older comments, and generally the delta between different versions of the change request, get lost or are at least very hard to see (e.g., might get mixed with changes from a rebate). Working with the patch/commit as artifact (as, e.g., Gerrit does it) seems so much more usable for code review that I can only speculate why no big tool offers it. Presumably, it requires too much internal knowledge about git to implement the backend correctly.
littlestymaar 4y ago
Sending git patches on a mailing list works I guess (after all, it works well enough for the Linux kernel), but yeah it's a bit crude of a tool…
arxanas 4y ago
Trunk-based development is still in use at large companies. Usually they use something like Gerrit or Phabricator. You could try tools like https://graphite.dev/ https://graphite.dev/ or https://reviewable.io/ https://reviewable.io/, or Meta's Sapling + ReviewStack.

doix 4y ago

I feel like I have a pretty good understanding of git, but the problems these helpers are trying to solve make my head spin. > git rebase --interactive can only repair linear series of commits, not trees. If you modify a commit with multiple children, then you have to be sure to rebase all of the other children commits appropriately. Can someone explain (preferably with a sequence of git commands) how you end up in such a situation? When would you end up modifying a commit with multiple children? Is this for a case where a bunch of people branch from master@HEAD (lets call this A), then you need to modify A, so you then need to rebase each branch that branched from A individually? I guess the workflows I'm used too explicitly try to avoid doing things that cause the problems that these helpers try to solve. I'm so used to thinking in this current mode that I find it hard to imagine when these problems would arise. 'git undo' terrifies me though. I really hate when there's lots of magic going on and I don't know what state my git repo will end up when I run a command. I rather run N commands, where I'm pretty confident what will happen in each stage, than one command that just 'fixes' things. Because if it fails to fix something, I'll be in some unknown state without understanding how I got into it.

arxanas 4y ago
> Is this for a case where a bunch of people branch from master@HEAD (lets call this A), then you need to modify A, so you then need to rebase each branch that branched from A individually? Mainly it's for when you branch from A multiple times, and then modify A. This can happen if you have some base work that you build multiple features on top of. I routinely do this as part of rapid prototyping, as described here: https://github.com/arxanas/git-branchless/wiki/Workflow:-divergent-development https://github.com/arxanas/git-branchless/wiki/Workflow:-div... `git undo` shows a list of operations it'll execute, which you have to confirm before accepting. Of course, it's ultimately a matter of trust in the tools you use.
- doix 4y ago
  Ah, I should have looked through the wiki. That is cool, I do something similar with a scuffed workflow with lots of cherry-picking. My approach does look significantly worse than this helper though. > `git undo` shows a list of operations it'll execute, which you have to confirm before accepting. Of course, it's ultimately a matter of trust in the tools you use. Nice! I guess it's time to setup rust and check this out. Are you the author? I hope my comments did not come across as too negative. It's more a matter of me living in a git bubble and failing to appreciate the tool.

bmitc 4y ago

Although GitHub offers a lot of features and generally makes Git tolerable, I’ll be pretty happy when Git gets supplanted by something else more popular and hopefully better. The latter should not be hard to do. As someone who cut my teeth on Perforce, I’m still learning the ins and outs of Git and generally actively avoid Git features. Whereas with Perforce, I was writing custom applications using its API and powerful workspace concept in just a couple years. Perforce is just easier to understand, easier to customize, great visualization tools, and has more sane names for things.

sausagefeet 4y ago
I use Mercurial and hg-git, which is a two-way interface between mercurial and git, and except for a few situations (tags, for example) it is, IMO, a vastly superior client to git. I think a possible step forward would be to just accept git as an underlying file format and build clients that are not insane on top of it. Maybe we could move off the file format later.
- bmitc 4y ago
  Plastic SCM has some Git interfacing, but I’m unsure of the details. I like some of their other solutions as well, namely semantic versioning. https://docs.plasticscm.com/gitsync/plastic-scm-version-control-gitsync-guide https://docs.plasticscm.com/gitsync/plastic-scm-version-cont...
- arxanas 4y ago
  https://github.com/martinvonz/jj https://github.com/martinvonz/jj and http://sapling-scm.com/ http://sapling-scm.com/ are good steps in this direction!
unmole 4y ago
Heh. I picked up git in college because I wanted to hack on the Linux kernel. Once I grokked git's simple data model, I have never run into problems with it. On the other hand, I've had to use Perforce professionally and I find it unbearable. It lacks features and everything is just convoluted and ridiculously slow in comparison. Thankfully I can avoid having to deal with Perforce using a git wrapper.

kramerger 4y ago

Why should I want to use smartlog instead of something like tig? While at it, I am amazed how much effort people put into not using git as intended due to some (often imaginary) corner case shortcomings I do like the performance improvements and git sync however, maybe they could be merged into mainline git?

antman 4y ago

This is kind of presented like a tool but it really is a workflow, I think presenting it in an e.g. gitflow manner woukd make it more clear on how it would work on an example project

tlarkworthy 4y ago

I have a lot of trouble pipelining my commits when I get reviewer comments on an early branch, it's very error prone to squash the changes and distribute downstream to avoid merge problems later. I think this tool is for me, am I able to adopt it without my team needing too?

arxanas 4y ago
Yes, it's entirely client-side.