Hacker News Reader

Comment by loup-vaillant | Hacker News Reader

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

View on HN

I was referring to the fact that in git you can cherry-pick a commit as the similar mechanism.

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.

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.

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

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.

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.

Reply on news.ycombinator.com