Changes between Version 22 and Version 23 of GitMigrationProposal

Timestamp:

03/28/09 13:32:27 (4 years ago)

Author:

pv

Comment:

More notes and points of comparison

GitMigrationProposal

@@ -15 +15 @@
   - Bzr: status, diff against last commit are fast enough, even for big working trees. History related commands are slow. Network operations are very inefficient (up to bzr 1.12 at least).
 
-== Merging ==
-
-XXX: merging in Bzr can be a bit confusing. Eg. how to find out what is the difference between two merged branches in the middle of the merge?
-
 == Branches ==
 
@@ -31 +27 @@
 
   - comparing branches is difficult, as they are in different repositories. For example, say one branch is the mainline (trunk), and one branch is a release branch, comparing, diffing them from the tool is awkward at best. git log/diff branch1..branch2 is extremely useful to follow what's happening in a branch, for review and so on.
-  - switching between branches is inconvenient.
+  - switching between branches in different repositories is inconvenient.
 
 Evaluation:
 
   - Git's branches can be easily used as topic branches, and also as permanent ones. Switching between branches is very fast within the same working copy.
-  - Git's collaboration features appear to be the best of the three.
+  - Git's collaboration features for tracking what's going on in remote branches appear to be the best of the three.
   - Bzr's repository branches are clumsier than Git's for use as topic branches; requires cd'ing to a different working copy. Long URLs difficult to remember, and no way to list available branches from command line.
   - Hg's repository branches: similar to Bzr.
   - Hg's named branches: use as throwaway topic branches questionable, since they cannot be deleted.
-  - Hg's plugins: at least the localbranch one seemed to suffer from the 80%-20% problem. Also, it was not suitable for collaboration, as IIRC there was no way to publish the local branches separately.
-
-Another consequence of those differences is that both bzr and hg use "simple" numbers for versioning (bzr emphasizes this much more than hg), but this breaks horribly when using branches: there is no simple ordering in a DAG anymore, and things like topological order can only be done for a known structure, that is the number -> internal id changes (a same version can refer to different things on different branches). This is extremely confusing in advanced scenario. Note that this happens in svn too: when you have several branches, svn revisions 'jump' for each branch, and they can't be used in any meaningful way.
+  - Hg's plugins that provide git-like branches: "non-standard" solutions. At least the localbranch one seemed to suffer from the 80%-20% problem. Also, it was not suitable for collaboration, as IIRC there was no way to publish the local branches separately.
+
+Another consequence of those differences is that Bzr uses "simple" numbers for versioning (HG also uses simple numbers for convenience in UI, alongside SHA hashes similar to git), but this breaks horribly when using branches: there is no simple ordering in a DAG anymore, and things like topological order can only be done for a known structure, that is the number -> internal id changes (a same version can refer to different things on different branches). This is extremely confusing in advanced scenario. Note that this happens in svn too: when you have several branches, svn revisions 'jump' for each branch, and they can't be used in any meaningful way.
 
 Git simply gives up the normal "simple revision" concept, and uses the internally used revision by default. In practice, this is not so much a problem, because git can refer to a specific change in many different ways: the internal number (sha1 checksum), parent ordering, time, etc...:
-
 {{{
 # Diff between the working tree and the last commit on the current branch
@@ -56 +51 @@
 git log --since="7 days"
 }}}
-
-To talk about a given change, one can simply tag it a simple name, use branches for review, etc... In my experience, the weird internal revision number feeling in git disappears quickly.
-
-== explicit meta-data vs guessing ==
+To talk about a given change, one can simply tag it a simple name, use branches for review, etc... In my (David) experience, the weird internal revision number feeling in git disappears quickly. However, in my experience (Pauli) one ends up pasting the SHA hashes especially when rebasing interactively against older revisions, and the "convenience" numbers on the revisions could be useful.
+
+Strangely enough, HG does not appear to have a syntax similar to HEAD^^ for referring quickly to changesets preceding current head. XXX: is this true?
+
+== Merging ==
+
+Merging in Git/Hg:
+
+  - Fetch remote branch to local storage
+  - Merge the new branch/head to the local branch
+
+Merging in Bzr:
+
+  - Merge directly against remote.
+
+In both HG and Git the changesets to be merged are locally accessible in the normal way to commands "diff", "revert", etc., and it is easy to examine the csets to be merged. In Bzr, you apparently need to use a bit more awkward branch:URL syntax to refer to the remote branch, which also requires over-the-network operations.
+
+XXX: Is there in Bzr some other way to referer to the changesets to be merged? It appears that they *are* temporarily stored locally, but I couldn't figure out the proper syntax.
+
+== Publishing branches ==
+
+Git, Bzr and HG support "dumb" read-only repositories served over plain HTTP. (Git requires running git update-server-info, though, after every push.) Also, for all of the three, there are free services (github, gitorius, launchpad, bitbucket, freehg) for publishing branches conveniently.
+
+== History rewriting ==
+
+Attitude to history rewriting is perhaps the most controversial difference between Git and Bzr/HG.
+
+Git comes built-in with the "rebase" command, which is fairly easy to use.
+In Bzr and HG, similar features are available as extensions, though.
+
+XXX: I (Pauli) haven't tested the HG and Bzr rebase functionality carefully. Does it work well?
+
+== Explicit meta-data vs guessing ==
 
 Another strong internal difference between git and bzr is how to deal with meta-data: file moves, tracking directories, etc... Git does not track any of this (git in particular cannot track empty directory). This has consequences on rename/merge interaction  (e.g. assuming one file foo.c in trunk renamed to foobar.c, but barfoo.c in branch1, what happens when branch1 and is merged into trunk ?). Git's approach advantages:
@@ -66 +90 @@
  - changing things from a patch, or from git itself results in exactly the same commit (assuming the changes are the same of course)
 
-The bzr advantages:
+The bzr/hg advantages:
 
  - rename sometimes behaves more like people expect during merges.
  - git automatic detection of renames is based on heuristics, which sometimes fail.
 
+Mercurial repository format also has a disadvantage when it comes to moving big files: when you move a file, the data currently in it becomes duplicated in the repository. So if you have a X MB file in the repository, after renaming it, you repository size has increased by X MB. (Bzr and Git do not have this problem.)
+
 git usage of heuristics is a bit controversial: some people say that git behaves better for renames because of this, other the contrary. One potentially very useful feature is the automatic code move detection for code moves within files. For example, here is the output of git blame for one file of the talkbox git repo:
-
 {{{
 ^6f8dca2 setup.py  (David Cournapeau 2008-09-03 10:33:42 +0000  1) descr   = """Talkbox, to make your numpy environment speech aware !
@@ -136 +161 @@
 dc91bfef common.py (David Cournapeau 2009-03-26 18:02:24 +0900 61) INSTALL_REQUIRE = 'numpy'
 }}}
-
 As you can see, blame not only outputs the commit for each line, but also the original file. Note that the committer has never told git about code move: git automatically saw that there were some common code portions between this file and some other files at a previous revision.
 
@@ -157 +181 @@
 In svn, any of this operation is so slow and awkward that nobody does it. Points 2 and 3 are equally easy (tag is one command, and cherry picking is done through git cherry-pick).
 
+== Keeping a "patch" up-to-date ==
+
+XXX: the rebase feature allows one to keep a patch up-to-date easily, and also polish it. (Though it has the danger that you lose history...)
+
 == Significant changes ==
 
@@ -164 +192 @@
 
 XXX
+
+XXX: Linux-like workflow, use of Signed-off-by
 
 = How to do the migration =