5 ms·

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

by 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.
        cm3 10y ago
        I mean when you get a .patch file and git-am that doesn't provide the same associated info (or environment) for git to resolve a merge.
        loup-vaillant 10y ago
        Oh my, I was confusing git commit -am with git am. Didn't know about that last one. Knowing that, it is very strange that the two methods should yield different results: the patch file is supposed to rely on a parent commit that should be accessible on the local repository, just like a local series of commits. That somehow the associated info/environment differs indicates there's a bug somewhere —or at least yet another poorly thought out corner of the UI.
        cm3 10y ago
        I can't find anything in the manpage about git-am checking the patch file's parent(s), but a patch file is accepted by git-apply as well, and then it's certainly not expected to consider a parent. That said, I've had git-am fail while git-merge or git-rebase would do the right thing, so git-am is probably, judging by the docs as well, not taking the history into account. If it does and I forgot to tell it how, I didn't know what options it is.

by cm3 10y ago

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.
      - cm3 10y ago
        I mean when you get a .patch file and git-am that doesn't provide the same associated info (or environment) for git to resolve a merge.
        loup-vaillant 10y ago
        Oh my, I was confusing git commit -am with git am. Didn't know about that last one. Knowing that, it is very strange that the two methods should yield different results: the patch file is supposed to rely on a parent commit that should be accessible on the local repository, just like a local series of commits. That somehow the associated info/environment differs indicates there's a bug somewhere —or at least yet another poorly thought out corner of the UI.
        cm3 10y ago
        I can't find anything in the manpage about git-am checking the patch file's parent(s), but a patch file is accepted by git-apply as well, and then it's certainly not expected to consider a parent. That said, I've had git-am fail while git-merge or git-rebase would do the right thing, so git-am is probably, judging by the docs as well, not taking the history into account. If it does and I forgot to tell it how, I didn't know what options it is.