2 ms·

I hate git passionately, but I still find it somewhat understandable. I understand what it does but that of course doesn’t change my view that its UX has the el

I hate git passionately, but I still find it somewhat understandable. I understand what it does but that of course doesn’t change my view that its UX has the elegance and consistency of an early php draft that went through a document shredder. Git has a nice elegant layer underneath though. The DAG of commits is a very nice model, covered in a layer of terrible commands, and a few rather unnatural abstractions like the staging area. I think to effectively use it you need to work with your brain squarely in that lower layer. Trying to think in terms of sequences of commands rather than a tree of commits and references is hopeless. The fact that the UX concepts (commands, working copy, reflog staging area, …) and the underlying model (graph) are difficult to reconcile is git’s biggest weakness. The difficulty with which is models some of the most common use cases (centralized, often including a few large binary files) is another.

yarg 5y ago
There's a limitation to the DAG model that has bothered me for a long time. I don't always want a branch to descend from a commit - sometimes I want it to descend from another (less featureful) branch. I want the ability to say that branch 1.1 is equivalent to branch 1.0 + {some set of changes} is something that would be exceptionally useful in a lot of circumstances. (And I know this would create some new fun and games from a conflicts perspective, but I think it'd be worth it for any use case that involves long term maintenance of different releases of the same piece of software.)
- leafmeal 5y ago
  So like a branch that automatically rebases on another branch? I think the issue with this is the inevitable conflicts and race-conditions. While nice in theory, often you need manual control to sort things out.
  - yarg 5y ago
    Not quite - branches get ancestors. A new repository starts with an empty branch. A DAG gets layered on top. I mentioned conflicts, but can you explain where race conditions would arise?
    - leafmeal 5y ago
      I guess I was imagining a conflict as the result of a race condition. Two concurrent changes are made where if they were ordered, there would be no conflict.
      - yarg 5y ago
        Ideally it should be no different to the current situation; you cannot push to a branch that has been pushed to since your last pull - the difference being that changes to the parent are also considered.
- hassancf 5y ago
  Can’t you create a branch from a commit that itself represents a branch? Is that no possible? What would it mean then to have a branch descend from a branch? I’m not sure I follow
- CRConrad 5y ago
  > I don't always want a branch to descend from a commit What does this even mean? > sometimes I want it to descend from another (less featureful) branch. Yeah, so? Just do that, then. Checkout the branch you want to descend from, create your new branch, and it's descended from the branch you checked out. (That's literally the default for how branching works in git, so... What are you actually asking about?)

yarg 5y ago

There's a limitation to the DAG model that has bothered me for a long time. I don't always want a branch to descend from a commit - sometimes I want it to descend from another (less featureful) branch. I want the ability to say that branch 1.1 is equivalent to branch 1.0 + {some set of changes} is something that would be exceptionally useful in a lot of circumstances. (And I know this would create some new fun and games from a conflicts perspective, but I think it'd be worth it for any use case that involves long term maintenance of different releases of the same piece of software.)

leafmeal 5y ago
So like a branch that automatically rebases on another branch? I think the issue with this is the inevitable conflicts and race-conditions. While nice in theory, often you need manual control to sort things out.
- yarg 5y ago
  Not quite - branches get ancestors. A new repository starts with an empty branch. A DAG gets layered on top. I mentioned conflicts, but can you explain where race conditions would arise?
  - leafmeal 5y ago
    I guess I was imagining a conflict as the result of a race condition. Two concurrent changes are made where if they were ordered, there would be no conflict.
    - yarg 5y ago
      Ideally it should be no different to the current situation; you cannot push to a branch that has been pushed to since your last pull - the difference being that changes to the parent are also considered.
hassancf 5y ago
Can’t you create a branch from a commit that itself represents a branch? Is that no possible? What would it mean then to have a branch descend from a branch? I’m not sure I follow
CRConrad 5y ago
> I don't always want a branch to descend from a commit What does this even mean? > sometimes I want it to descend from another (less featureful) branch. Yeah, so? Just do that, then. Checkout the branch you want to descend from, create your new branch, and it's descended from the branch you checked out. (That's literally the default for how branching works in git, so... What are you actually asking about?)