Hi everybody, Johan Tibell has made some nice comments things he misses in Darcs as a convert to and happy user of Git. I had asked him to elaborate on a complaint he made earlier and he was very kind to write up some fairly detailed comments. Interesting reading for us!
I've forward along my reply to Johan later as I have to rush off now.
Thanks! and happy reading!
PS. I asked what 'cheap' meant for him, and he meant just having one
make-me-a-branch command and near instantaneousness.
--
Eric Kow <http://www.nltg.brighton.ac.uk/home/Eric.Kow>
PGP Key ID: 08AC04F9
--- Begin Message ---Hi, Let me start by apologizing for the snarky comment. I was a bit frustrated. Let me describe what I currently miss in darcs but I get from Git. I maintain a couple of different Haskell libraries and I'm lucky to have a few contributors. This means that a large portion of the time I spend with a VCS is spent reviewing, patching and merging changes. Here's my typical Git workflow: 1. Receive a number of patches via email. 2. Create a cheap branch (of my master branch) and apply the changes. $ git checkout -b integration $ git am some-patch-file.mbox 3. Makes sure that the patch builds cleanly. $ cabal clean && cabal configure && cabal build && cabal test 4. Figure out what the changes actually is about. I often do this by diffing the master branch (i.e. the current stable branch) against each commit I received in the patch bundle. This way I can see what happened between patch 1 and 2, 2 and 3, etc, giving me a good overview of the progression. $ git diff master..integration # All changes taken together to get an overview $ git diff integration~2..integration~3 # Patch 3 (newest) $ git diff integration~1..integration~2 # Patch 2 $ git diff master..integration~1 # Patch 1 (oldest) 5. Send some review comments over email. 6. Receive updated patches over email. 7. Kill the old patches (by e.g. killing the branch) and apply the updated patches. $ git reset --hard HEAD^3 $ git am some-updated-patch-file.mbox 8. Repeat step 3-4 (and 5 if necessary.) 9. Optionally slice and dice the patches into something more logical in preparation for merging with the master branch: $ git rebase --interactive master 10. Apply the patches to the master branch. (This will be a fast-forward merge as we rebased on top of the master branch before.) $ git checkout master $ git merge integration $ git branch -d integration # Don't need this branch anymore. $ git push origin master # Upload to main repo. Note that I did no work on the master branch leaving me free to apply bug fixes in the mean time. I can also at any point throw away the integration branch if I screw up. No destructive updates to the main branch (i.e. no obliterate!) Random other things I miss: * Being able to easily refer to any patch -- typing a regex the matches the commit messages uniquely is a pain. So is counting backwards (i.e. --last=54.) * blame with a human readable output format (this should be easy to fix.) * Incrementally building up the next commit using a staging area. * rebase --interactive * Cheap branches for development (I never develop on the master branch) * Using the pager when it makes sense. * Not when typing "darcs help". You want the help text to stay when you're looking for command line flags to give to a command! The pager makes the help text disappear when you're supposed to type the command. * When looking through the change log (darcs changes.) You rarely want all the commits to scroll by and see the oldest commit! * Speed. Perhaps my role as a developer has changed over time. When you're a maintainer you need different tools than when you're a single developer. Diffing different branches and handling a number of (sometime conflicting) incoming patches at the same time becomes more important. Hope this is useful, Johan
--- End Message ---
signature.asc
Description: Digital signature
_______________________________________________ darcs-users mailing list [email protected] http://lists.osuosl.org/mailman/listinfo/darcs-users
