5 ms·

It does seem in some ways similar to Mercurial, but changes things which both Mercurial and Git share (like having to resolve tracked modified files before swit

by xixixao 10y ago

It does seem in some ways similar to Mercurial, but changes things which both Mercurial and Git share (like having to resolve tracked modified files before switching branches/bookmarks). I think if you want to make a fast and simple interface though, you should go a step further towards gui (like https://github.com/xixixao/hg-sl-up https://github.com/xixixao/hg-sl-up ) and remove the concept of branches/bookmarks altogether (I stopped using bookmarks in mercurial). The repo is just a tree of changes, I already tag it with commit messages, shouldn't need to tag it again with branch/bookmark names. Would love to be able to leave the commits in WIP state though, that would be super convenient (shelving sucks).

masklinn 10y ago
That sounds a lot like Darcs's model, which is pretty fun to play with (and darcs has a really nice CLI). You may want to take a gander at it.
- botexpert 10y ago
  Or pijul. https://pijul.org/ https://pijul.org/
  - masklinn 10y ago
    While in theory I appreciate what pijul is trying to do, I'm not going to plug it until it at the very least self-hosts. Two years in, still not there.
- cm3 10y ago
  git and hg are somewhere between Subversion and Darcs/Pijul. You kinda deal with individual patches (commits) but not quite as prominently as in Darcs/Pijul. It's all a compromise, and even Subversion gained merge features, leaning more into the git/hg realm. Tracking patches has huge advantages, especially in open source work, whereas it's not really needed if you just commit to master/trunk all the time and merge with a tool and not by tracking patches. Darcs and Pijul are what would be a perfect fit for the patch queue model used by kernel maintainers.
  - loup-vaillant 10y ago
    > You kinda deal with individual patches (commits) but not quite as prominently as in Darcs/Pijul. Darcs patches and git commits are markedly different. A git commit is a snapshot. A Darcs patch is a set of changes (that is, the difference between two snapshot). Any similarity necessarily comes from the ability to recover a snapshot from sets of changes, or deduce a set of changes from two snapshots. As far as I know, subversion only deals with a linear history. Its way of doing branching and merging is necessarily a kludge on top of this: branching and tagging actually perform a copy. Which explains the original difficulties with merging: a mere copy makes it harder to recover the most recent common ancestor required for a 3-way merge.
    - cm3 10y ago
      I was referring to the fact that in git you can cherry-pick a commit as the similar mechanism.
      - loup-vaillant 10y ago
        Ah, such a misnomer: you don't cherry pick a commit, you cherry pick the patch that lies between the selected commit and its parent. It may feel like nitpicking, but it's quite important when trying to understand the differences and commonalities between various version control systems.
        cm3 10y ago
        Yes, and it's why running git-am on the isolated commit can fail whereas cherry-picking does a proper merge and is more likely to apply cleanly.
        loup-vaillant 10y ago
        > running git-am on the isolated commit Huh? That command just turns the working copy into a commit, and mark it as the unique descendent as the commit currently pointed to by HEAD. Worst case, you just created another branch (happens if HEAD happens to point to something other than the last commit of an existing branch). You wouldn't happen to try and save the state of one branch in the working copy, then using that working copy to update another branch, right? That's just asking for trouble: done naively, it'd cancel all changes made in that another branch. If you know anyone who did this kind of mistake, do them a favour and explain the difference between a commit and a patch.

by xixixao 10y ago

masklinn 10y ago

That sounds a lot like Darcs's model, which is pretty fun to play with (and darcs has a really nice CLI). You may want to take a gander at it.

botexpert 10y ago
Or pijul. https://pijul.org/ https://pijul.org/
- masklinn 10y ago
  While in theory I appreciate what pijul is trying to do, I'm not going to plug it until it at the very least self-hosts. Two years in, still not there.
cm3 10y ago
git and hg are somewhere between Subversion and Darcs/Pijul. You kinda deal with individual patches (commits) but not quite as prominently as in Darcs/Pijul. It's all a compromise, and even Subversion gained merge features, leaning more into the git/hg realm. Tracking patches has huge advantages, especially in open source work, whereas it's not really needed if you just commit to master/trunk all the time and merge with a tool and not by tracking patches. Darcs and Pijul are what would be a perfect fit for the patch queue model used by kernel maintainers.
- loup-vaillant 10y ago
  > You kinda deal with individual patches (commits) but not quite as prominently as in Darcs/Pijul. Darcs patches and git commits are markedly different. A git commit is a snapshot. A Darcs patch is a set of changes (that is, the difference between two snapshot). Any similarity necessarily comes from the ability to recover a snapshot from sets of changes, or deduce a set of changes from two snapshots. As far as I know, subversion only deals with a linear history. Its way of doing branching and merging is necessarily a kludge on top of this: branching and tagging actually perform a copy. Which explains the original difficulties with merging: a mere copy makes it harder to recover the most recent common ancestor required for a 3-way merge.
  - cm3 10y ago
    I was referring to the fact that in git you can cherry-pick a commit as the similar mechanism.
    - loup-vaillant 10y ago
      Ah, such a misnomer: you don't cherry pick a commit, you cherry pick the patch that lies between the selected commit and its parent. It may feel like nitpicking, but it's quite important when trying to understand the differences and commonalities between various version control systems.
      - cm3 10y ago
        Yes, and it's why running git-am on the isolated commit can fail whereas cherry-picking does a proper merge and is more likely to apply cleanly.
        loup-vaillant 10y ago
        > running git-am on the isolated commit Huh? That command just turns the working copy into a commit, and mark it as the unique descendent as the commit currently pointed to by HEAD. Worst case, you just created another branch (happens if HEAD happens to point to something other than the last commit of an existing branch). You wouldn't happen to try and save the state of one branch in the working copy, then using that working copy to update another branch, right? That's just asking for trouble: done naively, it'd cancel all changes made in that another branch. If you know anyone who did this kind of mistake, do them a favour and explain the difference between a commit and a patch.