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