14 ms·

So it looks like you're ready for a change ... What's next on the horizon?

Zacharias030 3y ago
Generally git‘s support for a stacked PR workflow is poor [0], but imho that is the future of team collab (git is great for very asynchronously built projects, like the linux kernel). I also wonder, how much better git could be if it was based on DAGs not trees (I may want to use a changeset that is still developing in more than one branch without maintaining copies of it) and corollarily I‘d like to rebase subtrees (sub-DAGs) instead of single branches. I have introduced a stacked PR workflow to our team a while ago and a few months later half of the team had migrated to some kind of stacked PR workflow tool (on top of github and git, even though support is sub-optimal). It seems like this is an idea that is really sticky. [0] https://github.com/ezyang/ghstack https://github.com/ezyang/ghstack
- eru 3y ago
  > I also wonder, how much better git could be if it was based on DAGs not trees [...] Git generally supports DAGs. > [...] corollarily I‘d like to rebase subtrees (sub-DAGs) instead of single branches. Rebasing is something you do to the commit graph, which is a DAG. Branches only come in incidentally. Branches in git are really just mutable pointer to immutable commits. What you are describing is probably some useful workflow, I guess?
  - seba_dos1 3y ago
    Not only it's useful, it's as easy to do in git as typing `git rebase -r`. Recently it even gained support for rewriting branch pointers in the process.
    - marcandre 3y ago
      Do you mean it can rewrite branch pointers that pointed to intermediate commits? How?
      - seba_dos1 3y ago
        --update-refs
    - eru 3y ago
      In general, it's almost always better to use long options. So that would be `git rebase --rebase-merges` in this case. Almost always means: it's better eg when communicating with other humans, whether that's on a forum like HN or in code or scripts. Long options are easier for humans to understand and to 'google'. They also provide some redundancy against typos. The sole exception, where short options can be useful, is when you are actually using a command line interactively. Use short options to your heart's content there.
  - lloeki 3y ago
    I seem to understand GP wants to move a whole DAG potentially having multiple leaves, not just a DAG ending at a single leaf. IOW git rebase --onto shaX shaY shaZ ends at shaZ, git walks backwards from it until the commit whose parent is shaY to produce the list of commits to cherry-pick onto shaX So presumably this would be useful: git rebase --onto shaX shaY [shaZ1 shaZ2 shaZ3 ...] with shaZn being optional and consisting of all leaves down from shaY This is achievable with git but it's not just doing n rebases like so: git rebase --onto shaX shaY shaZ1 git rebase --onto shaX shaY shaZ2 git rebase --onto shaX shaY shaZ3 ... because each rebase would produce different commits for parts that are common to shaZ n1 and shaZn2 ancestry, so one would have to first find all the branching points and do partial rebases onto the rebased parent commits in order. It definitely can be done (manually or automatically) but is not as trivial as one might think.
    - eru 3y ago
      OK, that makes sense. I think if you wanted to do this, it would probably be easiest to produce an artificial leaf that points to all the leaves you want to rebase.
      - sanderjd 3y ago
        Yes, and the original commenter's point is that git does not support this well, at the data model layer even. Because commits have exactly one parent commit, which is immutable, and because rebasing creates a new commit, rebasing an entire subtree with N nodes under it requires N operations, rather than just 1. Personally I think it's a pretty small price to pay for the advantage of the single-immutable-parent model, but I do think it's surprising that there aren't better tools for this workflow. I do this all the time, but manually and painstakingly.
        zrail 3y ago
        You're right that the tooling doesn't support it well but commits have more than one parent all the time, they're just called merge commits. They can actually have as many parent branches as you please but conflicts get harder to deal with the more parents you have.[1] [1]: https://www.freblogg.com/git-octopus-merge https://www.freblogg.com/git-octopus-merge
- seba_dos1 3y ago
  > (I may want to use a changeset that is still developing in more than one branch without maintaining copies of it) Not sure if you realize, but a commit is a state of all files in the repository, not a patch. Patches are calculated for you at display time (and can be calculated against any other commit, not just a parent). Sounds like you may be confused because of trying to apply a wrong mental model of how the repository represents things. I'd say that git actually supports stacked workflows quite well. It's GitHub's PR model that makes it hard.
  - tempay 3y ago
    > I'd say that git actually supports stacked workflows quite well. It's GitHub's PR model that makes it hard. I agree that the model does but I’m not aware of any good way of using such a workflow with the CLI either. Is there a reasonable way to effectively keep rebasing on top of multiple upstream branches?
    - pravus 3y ago
      > Is there a reasonable way to effectively keep rebasing on top of multiple upstream branches? This is the problem. You cannot rebase with a stacked PR flow. The correct way to do this is use the merge command as intended. One of the most powerful features of git is the ability to understand a common history between multiple parties and everyone throws this away entirely with a rebase and causes non-stop conflicts. I simply do not understand the preference for it, especially in shared repos. Do not use a rebase workflow with any work that is shared with others unless you are communicating regularly and understand how obliterating your commit history will change how git views what is changed between two repositories. Rebase only works well if you are in a leaf branch you control and even then I prefer a single squash merge back into upstream rather than multiple rebases if possible. I can't even tell you how much of my life has been lost correcting merge conflicts caused by bad rebasing of my commits by others.
  - kps 3y ago
    > Not sure if you realize, but a commit is a state of all files in the repository, not a patch. I think that's a core problem. It's not just that git calculates a patch to show you, it's that — in every git-using project I've seen — a developer writes a patch, and writes a commit message describing that patch. It's not just github. And then developers make the incorrect assumption that git's later presentation of the commit as a patch matches the original patch and is accurately described by the commit message.

Generally git‘s support for a stacked PR workflow is poor [0], but imho that is the future of team collab (git is great for very asynchronously built projects, like the linux kernel). I also wonder, how much better git could be if it was based on DAGs not trees (I may want to use a changeset that is still developing in more than one branch without maintaining copies of it) and corollarily I‘d like to rebase subtrees (sub-DAGs) instead of single branches. I have introduced a stacked PR workflow to our team a while ago and a few months later half of the team had migrated to some kind of stacked PR workflow tool (on top of github and git, even though support is sub-optimal). It seems like this is an idea that is really sticky. [0] https://github.com/ezyang/ghstack https://github.com/ezyang/ghstack

eru 3y ago
> I also wonder, how much better git could be if it was based on DAGs not trees [...] Git generally supports DAGs. > [...] corollarily I‘d like to rebase subtrees (sub-DAGs) instead of single branches. Rebasing is something you do to the commit graph, which is a DAG. Branches only come in incidentally. Branches in git are really just mutable pointer to immutable commits. What you are describing is probably some useful workflow, I guess?
- seba_dos1 3y ago
  Not only it's useful, it's as easy to do in git as typing `git rebase -r`. Recently it even gained support for rewriting branch pointers in the process.
  - marcandre 3y ago
    Do you mean it can rewrite branch pointers that pointed to intermediate commits? How?
    - seba_dos1 3y ago
      --update-refs
  - eru 3y ago
    In general, it's almost always better to use long options. So that would be `git rebase --rebase-merges` in this case. Almost always means: it's better eg when communicating with other humans, whether that's on a forum like HN or in code or scripts. Long options are easier for humans to understand and to 'google'. They also provide some redundancy against typos. The sole exception, where short options can be useful, is when you are actually using a command line interactively. Use short options to your heart's content there.
- lloeki 3y ago
  I seem to understand GP wants to move a whole DAG potentially having multiple leaves, not just a DAG ending at a single leaf. IOW git rebase --onto shaX shaY shaZ ends at shaZ, git walks backwards from it until the commit whose parent is shaY to produce the list of commits to cherry-pick onto shaX So presumably this would be useful: git rebase --onto shaX shaY [shaZ1 shaZ2 shaZ3 ...] with shaZn being optional and consisting of all leaves down from shaY This is achievable with git but it's not just doing n rebases like so: git rebase --onto shaX shaY shaZ1 git rebase --onto shaX shaY shaZ2 git rebase --onto shaX shaY shaZ3 ... because each rebase would produce different commits for parts that are common to shaZ n1 and shaZn2 ancestry, so one would have to first find all the branching points and do partial rebases onto the rebased parent commits in order. It definitely can be done (manually or automatically) but is not as trivial as one might think.
  - eru 3y ago
    OK, that makes sense. I think if you wanted to do this, it would probably be easiest to produce an artificial leaf that points to all the leaves you want to rebase.
    - sanderjd 3y ago
      Yes, and the original commenter's point is that git does not support this well, at the data model layer even. Because commits have exactly one parent commit, which is immutable, and because rebasing creates a new commit, rebasing an entire subtree with N nodes under it requires N operations, rather than just 1. Personally I think it's a pretty small price to pay for the advantage of the single-immutable-parent model, but I do think it's surprising that there aren't better tools for this workflow. I do this all the time, but manually and painstakingly.
      - zrail 3y ago
        You're right that the tooling doesn't support it well but commits have more than one parent all the time, they're just called merge commits. They can actually have as many parent branches as you please but conflicts get harder to deal with the more parents you have.[1] [1]: https://www.freblogg.com/git-octopus-merge https://www.freblogg.com/git-octopus-merge
seba_dos1 3y ago
> (I may want to use a changeset that is still developing in more than one branch without maintaining copies of it) Not sure if you realize, but a commit is a state of all files in the repository, not a patch. Patches are calculated for you at display time (and can be calculated against any other commit, not just a parent). Sounds like you may be confused because of trying to apply a wrong mental model of how the repository represents things. I'd say that git actually supports stacked workflows quite well. It's GitHub's PR model that makes it hard.
- tempay 3y ago
  > I'd say that git actually supports stacked workflows quite well. It's GitHub's PR model that makes it hard. I agree that the model does but I’m not aware of any good way of using such a workflow with the CLI either. Is there a reasonable way to effectively keep rebasing on top of multiple upstream branches?
  - pravus 3y ago
    > Is there a reasonable way to effectively keep rebasing on top of multiple upstream branches? This is the problem. You cannot rebase with a stacked PR flow. The correct way to do this is use the merge command as intended. One of the most powerful features of git is the ability to understand a common history between multiple parties and everyone throws this away entirely with a rebase and causes non-stop conflicts. I simply do not understand the preference for it, especially in shared repos. Do not use a rebase workflow with any work that is shared with others unless you are communicating regularly and understand how obliterating your commit history will change how git views what is changed between two repositories. Rebase only works well if you are in a leaf branch you control and even then I prefer a single squash merge back into upstream rather than multiple rebases if possible. I can't even tell you how much of my life has been lost correcting merge conflicts caused by bad rebasing of my commits by others.
- kps 3y ago
  > Not sure if you realize, but a commit is a state of all files in the repository, not a patch. I think that's a core problem. It's not just that git calculates a patch to show you, it's that — in every git-using project I've seen — a developer writes a patch, and writes a commit message describing that patch. It's not just github. And then developers make the incorrect assumption that git's later presentation of the commit as a patch matches the original patch and is accurately described by the commit message.