Michael Sperber writes: Sure, because you use Mercurial, which supports named branches poorly. With git, I need to use a separate repository only if I need to have simultaneous builds with different versions of the source. This means that I can use named branches to organize my work, where you use MQ for organizing the current "main task", and separate repositories to organize main tasks for the long term. This simplifies my life. For example, I do "git branch", and get a list of all pending tasks. Indeed ... but I can do exactly the same thing with branches, and don't need to learn a separate tool, with a rather complex UI. The task that MQ is designed for (managing "large" collections of patches) simply isn't relevant to my life (I learned that when I was trying Darcs out on XEmacs). Basically, I don't work on any read-only codebases, so patch management is always Somebody Else's Problem (except for XEmacs 21.4, but there patch management is Vin's Problem, not mine :-). Also, I found the way that changesets disappeared and changed identity across a pop/push cycle was disconcerting. _______________________________________________ XEmacs-Beta mailing list XEmacs-Beta(a)xemacs.org http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta

Michael Sperber writes: It is complex, overly and unnecessarily so. It's slowly evolving toward a sane state, with a couple of big improvements in the last year (ie, since we switched to hg). The most important one for distributed development I think is a separate namespace for tracking branches (sort of like automated CVS vendor branches). An important UI improvement is interactive versions of the add and rebase commands. The Git Community Book (http://book.git-scm.com) helps simplify things for the new user by describing ONLY the commands used in a normal workflow, although you're probably past the stage where it sort of peters out. Heh. As I told a guy who came busting into the local LUG mailing list with "My Ubuntu fell down and no matter how hard I kick it it won't get up!!", "You really ought to stop trying to 'fix' the thing and start trying to *understand* it." The difference between you and him of course is that *your* "thing" is hg, not git, and it ain't broken (for you), leaving you with very little incentive to sit under a tree and meditate on the git-ness of it all. That is undoubtedly a lot of my problem with hg, too. Well, it's a little worse than that. I don't find the documented practices efficient or effective compared to git (for my task list, of course; I make no claims about how I would feel if I were managing a "gamma" and getting not tens of patches a week, but hundreds a day). As documented in the Mercurial book, when you pop a patch, the corresponding changeset disappears, and when you push it, the changeset that is created will often (always?) have a new identity. I had notes that referred to things by changeset id, and they were invalid afterward. Since I accomplish the same kind of effect in git with "reset" and typically rebase any new parallel patches on the existing ones, I am used to stability of changesets, and to moving up and down the stack in git, not in some auxiliary tool like MQ or quilt. _______________________________________________ XEmacs-Beta mailing list XEmacs-Beta(a)xemacs.org http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta

Michael Sperber writes: Indeed. git's failure to track patch identity is a defect. I'm not yet convinced it's a design defect (nor do I claim to be sure it's not). I believe git can be extended to track patches without changing repo format, or at worst with the addition of a new object type. I haven't actually tried to do it yet, though. (To be honest, I have so little use for patch identity, vs. revision identity, that I haven't even checked if Stacked Git does what I think is DaRightThang.) Now, why doesn't that bother me? In my usage, for that reason I don't use rebase except when I find an irreversible change necessary. While I'm working, I have something like this: current tip | | V V A --- B --- C --- D --- E So the "current" branch is there, but I know I can always revert to "tip". I manipulate "current" with "git reset". If I need to commit to "current" because "C" is unsatisfactory and the needed change "F" conflicts with "D", a merge of "current" into "tip" does the right thing: it leaves "C" and "D" alone, with the mainline history indicating that "G" (the merge commit) follows "E", and the branch history showing that "G" is conceptually based in "F" but required alteration to work with "D" and "E". Things are a little less clear when "F" is a sequence of patches branching at "D", but rebase does basically the same thing in that case as merge does in the one patch case. In both cases I could do the work at "C" even if there were no conflicts, but I probably wouldn't bother. Finally, at the time of submitting, I might change my mind, and rebase "D---E" on "F", getting "H" which will have the same tree as "G". (This can be efficiently checked by extracting the tree SHA1s and comparing.) Or I might use cherry-pick to extract and coalesce "A---B", "C---F", and "D---E" into three "coherent" patches, and arrange them as AB --- CF --- I where "I" is a new commit (since "CF" is a new parent), and has the same tree as "H" and "G". If I'm careful about all the above, I can then push "I", and naive use of the "~N" operators by third parties to get mainline parents will DTRT, while the full history is available to anyone who wants to try to figure out "WTF Steve was thinking?!?" I find this all totally intuitive, YMMV. Certainly the git UI leaves a lot to be desired (but it's improving rapidly). It took me a long time to figure *how* to do all that and that it would do the right thing. _______________________________________________ XEmacs-Beta mailing list XEmacs-Beta(a)xemacs.org http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta

Michael Sperber writes: I don't know how to do "reset" in Mercurial. Is there a way, preserving changesets and branch inclusion relationships? Note that in git, git checkout current; git reset --hard tip is possible and will be equivalent to git checkout current; git merge tip because the latter merge is a fast-forward. If instead I use MQ, the identities of D and E change every time I push or pop. In git, file contents are stored in blobs, which are a short "object header" followed by the contents. The blob is stored in a file whose name is the SHA1 of the contents. Note that a blob does not know what its name is in the working tree. A tree is a list of (SHA1 name mode) records. It is stored in a file whose name is the SHA1 of the list. Each SHA1 may be a blob name, a tree name, or (in very recent versions of git) a commit name, similar to an SVN external object. A commit is a structure containing author and committer information, a list of commit SHA1s (the parents), and a tree SHA1. Thus you can traverse the history DAG by using only the commits. You can reconstruct the state from a commit by extracting the tree SHA1, getting the corresponding tree object, and then populating a directory tree with the files and subtrees in the list contained in that object. You can tell whether two trees are identical or not by comparing their SHA1s. I don't know how to do the equivalent of "git reset --hard" with Mercurial. It would be nice to be able to protect the receiving repository from inadvertant branch changes. If we can't do that, then the whole named branch thing probably can't be done. If it is possible to move commits from one branch to another, that might do the trick. _______________________________________________ XEmacs-Beta mailing list XEmacs-Beta(a)xemacs.org http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta

Michael Sperber writes: No, I *definitely* don't want the -C, and if I do have AFAICT when you do "hg qpop", the changeset disappears irreversibly. When you do "hg qpush", the same patch is reapplied but a new changeset is created. Am I missing something? I don't know what you're talking about "implies a merge" -- so let's not worry about it, just assume I wrote something meaningless and forgot to delete it before sending. No, reset (without a file argument) by default affects the index and HEAD and leaves the working tree alone. (The index is where the "add", "remove", and "to commit" state is stored, among other things.) The revision history itself is immutable except by "git gc --prune". "git reset --hard" is exactly equivalent to "hg update -C", I think. So, for example if I do # make changes git commit -m "first" # make changes git commit -m "second" git tag tip git reset HEAD^ then the index ("git status", more or less) will show that I've got the changes in "second" in the workspace, but HEAD will point to the commit logged as "first", and a new commit will have the commit logged as "first" as its parent. If I use the "--soft" flag, then the index will show that all of those changes are staged for committing. Finally, I can do "git reset tip" and I'll be back where I started. To use the Lisp analogy, HEAD is a (magic) variable containing a commit. A commit is basically a cons. All information except ancestry is encapsulated in the car of a commit, the parent is the cdr. "git commit" is like "(push (make-commit-info) HEAD)". "^" is the cdr operation, and "~" is nthcdr. "git reset" is basically "setq"; without --soft or --hard, it has no implicit side effects, just the explicit one. So "git reset HEAD^" is just "(setq HEAD (cdr HEAD))". "git tag" and "git branch" also are basically "setq". The naive Lisp analogy fails at two points. First, a git commit's "cdr" can be multivalued, ie, if it's a merge commit. Second, HEAD is "(magic)" because its value is normally not a commit, it's a branch. The branch is automatically dereferenced to a commit in all contexts I know of (except if you cheat and look from outside of git at the symlink or file that is the OS-level implementation of HEAD), and the branch doesn't appear in a log listing, etc. So this magic dereference is transparent to the user; HEAD looks like a commit to her. Yeah, well, somebody whose favorite tool is something called "queue" whose primary mode of operation is stack-like can't complain about confusing docs. :-) I have to admit that the git nomenclature seems designed to put off newbies and people who "just want to use the tool dammit!" No, I don't want to undo the commit, at least to the extent I need to replicate git behavior. I want to change hg's idea of what commit is at the head of my current branch, without losing the commits I've made. I'm not really sure what I actually need, just that everything I try to do in hg seems either to be impossible or to pollute the public namespace. :-P Do tags and branch points move too? I suspect not. (In git they don't move when you rebase, but I don't use rebase to emulate patch stacks in git.) _______________________________________________ XEmacs-Beta mailing list XEmacs-Beta(a)xemacs.org http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta

Michael Sperber writes: git reset leaves the working copy alone. No patches applied or reversed, just an in-memory operation on the index, and a change of HEAD. Once again this is an unfortunate UI. The working copy is changed if you specify the --hard flag. That makes sense (YMMV), "reset" is an operation on the index, and the --hard flag says "after resetting the index to <commit>, sync the hard drive to that index". Or a file argument. That is pretty unintuitive to me, I would call that "checkout". _______________________________________________ XEmacs-Beta mailing list XEmacs-Beta(a)xemacs.org http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta

Michael Sperber writes: Fixing a typo or something in the last (unpublished commit) commit (so you don't care if the ID changes, there are no references to it. Forgetting a series of commits and mashing the whole thing into one commit (I do this *a lot* because I forget to commit the ChangeLog). You'd think it would be a purely internal operation, a building block for more complex to implement but intuitively atomic operations. But I find myself using it a fair amount. _______________________________________________ XEmacs-Beta mailing list XEmacs-Beta(a)xemacs.org http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta

On Tue, Jan 06, 2009 at 05:40:52PM +0900, Stephen J. Turnbull wrote: git commit --amend is nice for that too. In some aspects, git is a little perlish. There's more than one way to do what you want. I think that's in part the reason for its success, and the reason for its reputation as hard to learn: git gives you a set of tools but does not impose a specific workflow. That freedom is seen in the myriad of git tutorials you can find, they more often than not present different workflows rather than different commands. And it's very much by design. Hg seems to me (but I can be wrong) to have been designed with one specific workflow in mind (mostly centralized development with quality offline work support, branches as directories, ), and support for others feels a little tacked on after the fact. The revision numbers look like a symptom. Git is very much about powerful elementary tools (DAG of revisions, unique naming, merge), usually called plumbing, and higher level tools in support of a variety of workflows on top of it (pull, rebase, branch, tag...) usually called porcelain. Which makes it useful both for me on my projects nobody else sees and for large scale things like Xorg or the linux kernel. But more often than not encountering git is being given a compiler when what you need is software design courses. OG. _______________________________________________ XEmacs-Beta mailing list XEmacs-Beta(a)xemacs.org http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta

On Mon, Jan 05, 2009 at 12:27:01PM +0100, Michael Sperber wrote: Semantically, an unambigious label referring to a point in the version DAG. Figure a cryptographic hash computed recusively from all the files creations (including content), changes, changelogs, etc that led to a specific version of your data. That makes it unique, unchanging even through distribution and with such a low probability of collision it's not worth bothering about. That allows you to point to a revision in your tree and be sure that if someone else has a tree with the same sha1, he's talking about the exact same thing. It wasn't invented by Linus btw, it comes from Monotone. SHA1s can be a tad unweidly, even if you get used to it, but the nice dispersion properties of hashes make it so that you can shorten these names to the first few digits when using commands. How many digits depends on the size of your history, the kernel tends to use 8. It's just a shorthand of the user interface though, the repository stores full 40-digits IDs always. In contrast Hg's revision id can't be stable on a global level since being low increasing integers they can't use probabilities to compensate for the lack of information. In practice it seems that people tends to use them as references (obviously, since they're visible and handy) not always realizing that there is no guarantee who they're talking with has these numbers referring to thesame thing. I suspect the best effort algorithms of Hg making them work at least part of the time have a side effect of increasing the confusion. OG. _______________________________________________ XEmacs-Beta mailing list XEmacs-Beta(a)xemacs.org http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta

Michael Sperber writes: No more handy than git's HEAD~N notation. (Hint, don't use "git log" and count logs to find out what N is, use "git show-branch".) _______________________________________________ XEmacs-Beta mailing list XEmacs-Beta(a)xemacs.org http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta

Michael Sperber writes: Even more confusing, I think, but git's notation is much less likely to be (mis)used in that way. _______________________________________________ XEmacs-Beta mailing list XEmacs-Beta(a)xemacs.org http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta