> 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.
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.
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.
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.
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.
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.