(no subject)

[fu]

I did a quick run through of a changeset submission process with exor674, one for Mercurial and one for Git.

Assumptions:

• pulling from the dev branch back to stable is roughly equivalent between Git and Mercurial, or is easy enough to work around on the committer side, so this is not shown here.


• we want to move away from asking for patches, to pull requests which include more context


• we need to concentrate on the branching workflow. We will encourage branching even for small bugfixes or feature development, to make it easy for devs to pick up a different bug once they have submitted a pull request for what they are currently working on.
  
  This is particularly important because we get devs that happily submit their first patch, and then get frustrated trying to clean up their repo when working on their second. This may also be useful when we discover that tweaks need to be done on review. Instead of doing:
  
  
  
  1. clean up old/current work
     
  2. grab patch from zilla or a saved file and reapply
     
  3. do tweaks
     
  4. generate a new patch containing the original patch + changes requested
     
  
  We might do:
  
  
  
  1. save current work on current branch
     
  2. switch to previous branch
     
  3. do tweaks
     
  4. submit pull request again, with the tweaks as a separate commit
     
  
  Thus the emphasis on branching in this run through.


• we're trying to analyze the core features to determine whether they can work the way we need them to, so we've left github and bitbucket out of the equation (except as ways to make the code public)

Mercurial Workflow using Bookmarks

dre> # I am at default
dre> dw@dw-dev:~/dw/cvs/dw-free$ hg bookmark upstream
dre> dw@dw-dev:~/dw/cvs/dw-free$ hg bookmarks
dre>  * upstream                  4425:dbe9fa643bb3
dre> dw@dw-dev:~/dw/cvs/dw-free$ hg bookmark feature/Bug4432
dre> dw@dw-dev:~/dw/cvs/dw-free$ hg bookmarks
dre>  * feature/Bug4432           4425:dbe9fa643bb3
dre>    upstream                  4425:dbe9fa643bb3

dre> # Do work ( or in this case... )
dre> dw@dw-dev:~/dw/cvs/dw-free$ curl "http://bugs.dwscoalition.org/attachment.cgi?id=6214" | patch -p1
dre> # Snip
dre> patching file cgi-bin/DW/Controller/Manage/Logins.pm
dre> patching file htdocs/manage/logins.bml
dre> patching file views/manage/logins.tt
dre> patching file htdocs/manage/logins.bml.text


dre> # Artifact of how the patch applied
dre> dw@dw-dev:~/dw/cvs/dw-free$ hg status
dre> M htdocs/manage/logins.bml.text
dre> ! htdocs/manage/logins.bml
dre> ? cgi-bin/DW/Controller/Manage/Logins.pm
dre> ? views/manage/logins.tt
dre> dw@dw-dev:~/dw/cvs/dw-free$ hg rm htdocs/manage/logins.bml 
dre> dw@dw-dev:~/dw/cvs/dw-free$ hg add cgi-bin/DW/Controller/Manage/Logins.pm 
dre> dw@dw-dev:~/dw/cvs/dw-free$ hg add views/manage/logins.tt 
dre> dw@dw-dev:~/dw/cvs/dw-free$ hg status
dre> M htdocs/manage/logins.bml.text
dre> A cgi-bin/DW/Controller/Manage/Logins.pm
dre> A views/manage/logins.tt
dre> R htdocs/manage/logins.bml
dre> dw@dw-dev:~/dw/cvs/dw-free$ hg mv htdocs/manage/logins.bml.text views/manage/logins.tt.text

dre> # And how it would look hopefully if I actually did the work during this.
dre> dw@dw-dev:~/dw/cvs/dw-free$ hg status
dre> A cgi-bin/DW/Controller/Manage/Logins.pm
dre> A views/manage/logins.tt
dre> A views/manage/logins.tt.text
dre> R htdocs/manage/logins.bml
dre> R htdocs/manage/logins.bml.text

dre> dw@dw-dev:~/dw/cvs/dw-free$ hg commit -m "Convert /manage/logins to Template Toolkit."

dre> # ( I have my default path as my bitbucket repo ( https://bitbucket.org/anall/dw-free-test )
dre> dw@dw-dev:~/dw/cvs/dw-free$ hg log -l 2
dre> changeset:   4426:cdf474d786e5
dre> bookmark:    feature/Bug4432
dre> tag:         tip
dre> user:        Andrea Nall <anall@andreanall.com>
dre> date:        Mon May 07 04:35:52 2012 +0000
dre> summary:     Convert /manage/logins to Template Toolkit.
dre> 
dre> changeset:   4425:dbe9fa643bb3
dre> bookmark:    upstream
dre> user:        fu
dre> date:        Tue May 01 20:38:04 2012 +0800
dre> summary:     http://bugs.dwscoalition.org/show_bug.cgi?id=3669

dre> # Push?
dre> dw@dw-dev:~/dw/cvs/dw-free$ hg push
dre> pushing to ssh://hg@bitbucket.org/anall/dw-free-test
dre> searching for changes
dre> remote: adding changesets
dre> remote: adding manifests
dre> remote: adding file changes
dre> remote: added 1 changesets with 3 changes to 3 files
dre> remote: bb/acl: anall is allowed. accepted payload.

dre> # Except I don't think the bookmark showed up.
dre> dw@dw-dev:~/dw/cvs/dw-free$ hg push -B feature/Bug4432
dre> pushing to ssh://hg@bitbucket.org/anall/dw-free-test
dre> searching for changes
dre> no changes found
dre> exporting bookmark feature/Bug4432

dre> # Seems like that worked.

dre> dw@dw-dev:~/dw/cvs/dw-free$ hg heads
dre> changeset:   4426:cdf474d786e5
dre> bookmark:    feature/Bug4432
dre> tag:         tip
dre> user:        Andrea Nall <anall@andreanall.com>
dre> date:        Mon May 07 04:35:52 2012 +0000
dre> summary:     Convert /manage/logins to Template Toolkit.
dre> 
dre> changeset:   2674:d74055a213da
dre> branch:      production
dre> user:        fu
dre> date:        Thu Jul 29 02:27:30 2010 -0700
dre> summary:     http://bugs.dwscoalition.org/show_bug.cgi?id=2918

dre> # ---- Now on the committers end
fu>  afuna@ubuntu:~/dw/cvs/dw-free$ hg pull -B feature/Bug4432 https://bitbucket.org/anall/dw-free-test
fu>  pulling from https://bitbucket.org/anall/dw-free-test
fu>  searching for changes
fu>  adding changesets
fu>  adding manifests
fu>  adding file changes
fu>  added 1 changesets with 3 changes to 3 files
fu>  (run 'hg update' to get a working copy)
fu>  importing bookmark feature/Bug4432
fu>  
fu>  afuna@ubuntu:~/dw/cvs/dw-free$ hg update
fu>  3 files updated, 0 files merged, 2 files removed, 0 files unresolved
fu>  afuna@ubuntu:~/dw/cvs/dw-free$ hg log -l2
fu>  changeset:   4426:cdf474d786e5
fu>  bookmark:    feature/Bug4432
fu>  tag:         tip
fu>  user:        Andrea Nall <anall@andreanall.com>
fu>  date:        Mon May 07 04:35:52 2012 +0000
fu>  summary:     Convert /manage/logins to Template Toolkit.
fu>  
fu>  changeset:   4425:dbe9fa643bb3
fu>  user:        fu
fu>  date:        Tue May 01 20:38:04 2012 +0800
fu>  summary:     http://bugs.dwscoalition.org/show_bug.cgi?id=3669

dre> # Unless the committer also had a bookmark set and tracked to where the default branch was
dre> #  it could get "misplaced" by this.

fu>  afuna@ubuntu:~/dw/cvs/dw-free$ hg bookmark -d feature/Bug4432 

fu>  # now push to remote
fu>  # err this is pushed, but not posted to changelog because of the username thing
fu>  3:02:37 Blanket:~/dw/cvs/dw-free athens$ hg push 
fu>  pushing to ssh://hg@hg.dwscoalition.org/dw-free
fu>  searching for changes
fu>  I think weremote: adding changesets
fu>  remote: adding manifests
fu>  remote: adding file changes
fu>  remote: added 1 changesets with 3 changes to 3 files
fu>  remote: xmlrpc_call_helper error:
fu>  remote:         String: Invalid username
fu>  remote:         Code: 100
fu>  remote: warning: changegroup.post hook exited with status 1

fu>  # issues:
fu>  # need to enforce the commit message socially
fu>  # I've redacted an attempt to update the commit message by doing a separate merge, because basically it did nothing
fu>  # nooo mercurial still doesn't have a way to distinguish between the patch author and committer

dre> # Back on patch author's end
dre> dw@dw-dev:~/dw/cvs/dw-free$ hg pull http://hg.dwscoalition.org/dw-free/
dre> pulling from http://hg.dwscoalition.org/dw-free/
dre> searching for changes
dre> no changes found

fu>  # ^-- is fine because she already had that commit
fu>  # but what if I'd forcefully amended the commit message / user name by pulling into MQ, so it would fit our guidelines?

dre> # I would either end up with a dangling head ( after dealing with the bookmark )
dre> #  and have to live with it or strip the commit(s) -- and maybe accidentally nom something important
dre> #  and have to reset my hack, recheckout, maybe lose work or something
dre> #    { or fix it another way, but that would require knowing what to do }.

fu>  # yeah we'd have to enforce commit messages socially
fu>  # reject for incorrect commit messages or something. Meh. 
fu>  # on the other hand, would be good to learn to make self-descriptive error messages
dre> # We might lose history if we rejected though
dre> #   ( Seeing the process of a bug may be a good idea, if debugging a feature
dre> #      "it worked before changeset deadbeef, and that was pre-submit whitespace cleanup and removed an important line accidentally" )
fu>  # I think this is *not* a dealbreaker, because a lot of the issues are based on the fact that our tools are pretty simple
fu>  # and we could amend the tools, but it's definitely something we need to address when deciding
 
dre> dw@dw-dev:~/dw/cvs/dw-free$ hg bookmarks
dre>    feature/Bug4432           4426:cdf474d786e5
dre>  * upstream                  4425:dbe9fa643bb3
dre> dw@dw-dev:~/dw/cvs/dw-free$ hg bookmark -d feature/Bug4432 
dre> dw@dw-dev:~/dw/cvs/dw-free$ hg checkout default
dre> 3 files updated, 0 files merged, 2 files removed, 0 files unresolved
dre> dw@dw-dev:~/dw/cvs/dw-free$ hg bookmark upstream
dre> abort: a bookmark of the same name already exists
dre> dw@dw-dev:~/dw/cvs/dw-free$ hg bookmark -f upstream

dre> # And delete the remote bookmark
dre> dw@dw-dev:~/dw/cvs/dw-free$ hg push -B feature/Bug4432
dre> pushing to ssh://hg@bitbucket.org/anall/dw-free-test
dre> searching for changes
dre> no changes found
dre> deleting remote bookmark feature/Bug4432


dre> dw@dw-dev:~/dw/cvs/dw-free$ hg bookmarks
dre>  * upstream                  4426:cdf474d786e5

Git workflow using git branches

dre> ## Comments here are double-hash because command output can start with "# "

dre> athena:dw-free anall$ git branch
dre> * develop
dre> athena:dw-free anall$ git branch feature/Bug4432
dre> athena:dw-free anall$ git branch
dre> * develop
dre>   feature/Bug4432
dre> athena:dw-free anall$ git checkout feature/Bug4432
dre> Switched to branch 'feature/Bug4432'

dre> ## Do work ( or in this case... )
dre> athena:dw-free anall$ curl "http://bugs.dwscoalition.org/attachment.cgi?id=6214" | patch -p1
dre>   ## Snip
dre> patching file htdocs/manage/logins.bml
dre> patching file views/manage/logins.tt
dre> patching file htdocs/manage/logins.bml.text

dre> ## Artifact of how the patch was applied
dre> ##  If I actually did the work here, we wouldn't have to do this
dre> athena:dw-free anall$ git status
dre> # On branch feature/Bug4432
dre> # Changed but not updated:
dre> #   (use "git add/rm <file>..." to update what will be committed)
dre> #   (use "git checkout -- <file>..." to discard changes in working directory)
dre> #
dre> #        deleted:    htdocs/manage/logins.bml
dre> #        modified:   htdocs/manage/logins.bml.text
dre> #
dre> # Untracked files:
dre> #   (use "git add <file>..." to include in what will be committed)
dre> #
dre> #        cgi-bin/DW/Controller/Manage/
dre> #        views/manage/
dre> no changes added to commit (use "git add" and/or "git commit -a")

dre> athena:dw-free anall$ git mv htdocs/manage/logins.bml.text views/manage/logins.tt.text
dre> athena:dw-free anall$ git add views/manage/logins.tt
dre> athena:dw-free anall$ git add views/manage/logins.tt.text 
dre> athena:dw-free anall$ git rm htdocs/manage/logins.bml

dre> ## And how it would look hopefully if I actually did the work during this.
dre> athena:dw-free anall$ git status
dre> # On branch feature/Bug4432
dre> # Changes to be committed:
dre> #   (use "git reset HEAD <file>..." to unstage)
dre> #
dre> #        new file:   cgi-bin/DW/Controller/Manage/Logins.pm
dre> #        deleted:    htdocs/manage/logins.bml
dre> #        new file:   views/manage/logins.tt
dre> #        renamed:    htdocs/manage/logins.bml.text -> views/manage/logins.tt.text
dre> #

dre> athena:dw-free anall$ git commit -m "Convert /manage/logins to Template Toolkit."
dre> [feature/Bug4432 12aaf4c] Convert /manage/logins to Template Toolkit.
dre>  4 files changed, 187 insertions(+), 135 deletions(-)
dre>  create mode 100644 cgi-bin/DW/Controller/Manage/Logins.pm
dre>  delete mode 100644 htdocs/manage/logins.bml
dre>  create mode 100644 views/manage/logins.tt
dre>  rename htdocs/manage/logins.bml.text => views/manage/logins.tt.text (97%)
dre> athena:dw-free anall$ git log
dre> commit 12aaf4cdcb4f51a0e8153883aca3fb84b60ad871
dre> Author: Andrea Nall <anall@andreanall.com>
dre> Date:   Sun May 6 23:27:50 2012 -0600
dre> 
dre>     Convert /manage/logins to Template Toolkit.
dre> 
dre> commit 7e18284332b02805d621697cbc3e0b97b007f1a9
dre> Merge: e83dba7 ddd37a5
dre> Author: Afuna <afunamatata+github@gmail.com>
dre> Date:   Wed Dec 21 00:00:16 2011 -0800
dre> 
dre>     Merge pull request #4 from anall/develop
dre>     
dre>     Address Bug something something something.
dre> 
dre> ## snip ( yes, this repo is a test repo and horribly out of date )

dre> athena:dw-free anall$ git push origin feature/Bug4432
dre> Counting objects: 20, done.
dre> Delta compression using up to 8 threads.
dre> Compressing objects: 100% (12/12), done.
dre> Writing objects: 100% (13/13), 3.16 KiB, done.
dre> Total 13 (delta 7), reused 0 (delta 0)
dre> To git@github.com:anall/dw-free.git
dre>  * [new branch]      feature/Bug4432 -> feature/Bug4432

dre> # And on the committers end
fu>  afuna@ubuntu:~/dw/cvs/dw-free.github.dw$ git fetch https://github.com/anall/dw-free.git feature/Bug4432
fu>  From https://github.com/anall/dw-free
fu>   * branch            feature/Bug4432 -> FETCH_HEAD
fu>  afuna@ubuntu:~/dw/cvs/dw-free.github.dw$ git merge --no-ff --no-commit FETCH_HEAD
fu>  Removing htdocs/manage/logins.bml
fu>  Automatic merge went well; stopped before committing as requested
fu>  afuna@ubuntu:~/dw/cvs/dw-free.github.dw$ git commit
fu>  [develop 184d169] http://bugs.dwscoalition.org/show_bug.cgi?id=4432
fu>  afuna@ubuntu:~/dw/cvs/dw-free.github.dw$ git log
fu>  commit 184d1693b7cff10d4d964e4cfdc1fe4c20828248
fu>  Merge: e83dba7 12aaf4c
fu>  Author: Afuna <afuna@dream.fu>
fu>  Date:   Fri Apr 20 12:23:19 2012 +0000
fu>  
fu>      http://bugs.dwscoalition.org/show_bug.cgi?id=4432
fu>      
fu>      Merge branch 'feature/Bug4432' of https://github.com/anall/dw-free into develop
fu>      
fu>      TT-ize manage/logins
fu>      
fu>      Patch by exor674.
fu>  
fu>  commit 12aaf4cdcb4f51a0e8153883aca3fb84b60ad871
fu>  Author: Andrea Nall <anall@andreanall.com>
fu>  Date:   Sun May 6 23:27:50 2012 -0600
fu>  
fu>      Convert /manage/logins to Template Toolkit.

fu>  13:50:15 Blanket:~/dw/cvs/dw-free.github.dw athens$ git push
fu>  Counting objects: 24, done.
fu>  Delta compression using up to 2 threads.
fu>  Compressing objects: 100% (13/13), done.
fu>  Writing objects: 100% (14/14), 3.45 KiB, done.
fu>  Total 14 (delta 7), reused 0 (delta 0)
fu>  To git@github.com:dreamwidth/dw-free.git
fu>     7e18284..184d169  develop -> develop

dre> ## And back on my end
dre> athena:dw-free anall$ git checkout develop
dre> Switched to branch 'develop'
dre> athena:dw-free anall$ git pull https://github.com/dreamwidth/dw-free develop
dre> From https://github.com/dreamwidth/dw-free
dre>  * branch            develop    -> FETCH_HEAD
dre> Updating 7e18284..184d169
dre> Fast-forward
dre>  cgi-bin/DW/Controller/Manage/Logins.pm             |  101 +++++++++++++++
dre>  htdocs/manage/logins.bml                           |  135 --------------------
dre>  views/manage/logins.tt                             |   84 ++++++++++++
dre>  .../logins.bml.text => views/manage/logins.tt.text |    2 +
dre>  4 files changed, 187 insertions(+), 135 deletions(-)
dre>  create mode 100644 cgi-bin/DW/Controller/Manage/Logins.pm
dre>  delete mode 100644 htdocs/manage/logins.bml
dre>  create mode 100644 views/manage/logins.tt
dre>  rename htdocs/manage/logins.bml.text => views/manage/logins.tt.text (97%)

dre> ## Delete my local branch.
dre> athena:dw-free anall$ git branch
dre> * develop
dre>   feature/Bug4432
dre> athena:dw-free anall$ git branch -d feature/Bug4432
dre> Deleted branch feature/Bug4432 (was 184d169).

dre> ## Now update my fork
dre> athena:dw-free anall$ git push origin
dre> Counting objects: 1, done.
dre> Writing objects: 100% (1/1), 322 bytes, done.
dre> Total 1 (delta 0), reused 0 (delta 0)
dre> To git@github.com:anall/dw-free.git
dre>   7e18284..184d169  develop -> develop

dre> ## And delete the remote branch
dre> athena:dw-free anall$ git push origin :feature/Bug4432
dre> To git@github.com:anall/dw-free.git
dre>  - [deleted]         feature/Bug4432

dre> athena:dw-free anall$ git log -3
dre> commit 184d1693b7cff10d4d964e4cfdc1fe4c20828248
dre> Merge: e83dba7 12aaf4c
dre> Author: Afuna <afuna@dream.fu>
dre> Date:   Fri Apr 20 12:23:19 2012 +0000
dre> 
dre>     http://bugs.dwscoalition.org/show_bug.cgi?id=4432
dre>     
dre>     Merge branch 'feature/Bug4432' of https://github.com/anall/dw-free into develop
dre>     
dre>     TT-ize manage/logins
dre>     
dre>     Patch by exor674.
dre> 
dre> commit 12aaf4cdcb4f51a0e8153883aca3fb84b60ad871
dre> Author: Andrea Nall <anall@andreanall.com>
dre> Date:   Sun May 6 23:27:50 2012 -0600
dre> 
dre>     Convert /manage/logins to Template Toolkit.
dre> 
dre> commit 7e18284332b02805d621697cbc3e0b97b007f1a9
dre> Merge: e83dba7 ddd37a5
dre> Author: Afuna <afunamatata+github@gmail.com>
dre> Date:   Wed Dec 21 00:00:16 2011 -0800
dre> 
dre>     Merge pull request #4 from anall/develop
dre>     
dre>     Address Bug something something something.

Summary of what we found:

• When using Mercurial bookmarks, we ran into an odd(?) issue where we lost track of where we were branching from (what would, in git, be the branch "master"). I'm assuming this is a bit of a workflow thing, and we can work around by creating the new bookmark upstream or master, so we could get back to the point in our repo before we started making any changes


• Same issue, but this time from the committer side? or, since we've merged at this point, and won't need to eep track of bookmarks, perhaps less of an issue?


• What am I doing when I pull then remove the bookmark? I ... managed to merge, right? That's what I did?


• Commit messages are now an issue. We standardized around a commit format containing the bug id, commit message, and patch author and enforced it by having the committer supply the commit message.
  
  Now, we'll either need to enforce a strict policy on commit messages before accepting the commit, or have the committer amend the commit messages beforehand. Other options are to make the changelog hook smarter (detect things of the form "Bug #"?), use a "changelog_bot" for all commits. We might also want to look into having the committer sign off the commit.
  
  *Finally* this might become a moot point, depending on what's available to us from github/bitbucket that will let us put stuff into the changelog community.


• need to determine what happens if you try to amend someone's commit in Mercurial by running it through MQ in order to fit guidelines above *points up*. At a guess, we'd end up with a dangling commit that would need to be stripped out of the submitting dev's repo, because the changeset hashes would no longer match


• git index! oh git index. You might be a pain. The question is, are you a pain that can be hidden away?


• it's much easier grokking branches, IMO, than bookmarks, because there's never any risk of forgetting where "master" is.


• git lets me do a merge commit, in order make sure that the bug number is mentioned in a related commit. *Might* be a bit of a moot point if we end up doing a rebase instead of a merge

Comments

[exor674]

Without having the "development" or whatever bookmark tracked in the dreamwidth dw-free repository, it can still get lost -- and probably require a baby-dev ask for help in finding it again.

[vlion]

this is a flaw imo of bookmarks. you will need a bookmark for 'point of development'

[cdybedahl]

By "git index", do you mean the git staging area (the place where you assemble your commit before you actually commit it)? If so, that's not a pain, it's one of git's best features. It takes some getting used to, that's true, but once you do systems that don't have it start feeling crippled.

As someone who has switched from Mercurial to git for all projects where I have a choice, I'd give git's advantages as roughly these:

* Much larger developer community, meaning that git itself and tools around it have a considerably faster pace of development.

* The staging area, which enables workflows that plain aren't possible in hg. Not least including the ability to only commit part of the changes in a file, unless hg has gained that ability since I stopped using it.

* At least back then, git was much, much faster than hg.

* git has the ability to re-order and merge commits, so you can commit as often as you like while you work and still present a logical progression of commits when you push to the rest of the world. Differently put, you can clean out "fixed typo" commits so the world doesn't have to see them.

[exor674]

* At least back then, git was much, much faster than hg.

I think this is still technically true. Maybe not in practice, but since IIRC git's written in what? C? While mercurial's python...

[vlion]

speed: git vs. hg: git not practically faster in most cases, but is true in some. facebook is having trouble scaling git and bryan o'sullivan is looking into patching hg. those are massive multi-gigabyte repos though.

I don't notice a difference between my gitting and my hging in speed.

[fu]

The larger developer community is definitely a very sweet incentive to move over!

hg has the ability to cherry-pick, but I think it might have been part of the MQ extension, or maybe it was another extension I'd enabled way back when. The fact that so much of what is close to core functionality for managing a repository with multiple developers either needs you to install/enable an extension, or use a very modern version of hg though...

I'm pretty sold on Git. Git index though... on the one hand, I like knowing it can be there. On the other hand, it's one of those things that's a pain to explain. (sudden flash of insight: I've seen this exact same thing in GUI skins for things like SVN, say. That might make it easier to explain the concept)

[cdybedahl]

Do you think it'd be worth the effort to write an explanation specifically of the git staging area? I can give that a shot, if there's a reasonable chance it'll be read.

[fu]

Hmm, I think that would be a good thing to have, yes.

I just posted an entry on workflow with a very quick description of the staging area, but I bet that more explanation would be useful.

[cdybedahl]

I just posted a bit on what the staging area is and why it exists, since I suspect those are the bits that are hardest to figure out from man pages and other documentation. It's in http://cdybedahl.dreamwidth.org/498668.html

[vlion]

Going to kick off threads for my responses.

[vlion]

fu> # nooo mercurial still doesn't have a way to distinguish between the patch author and committer

Yes, very true. Is this important?


pull and remove bookmark should not cause merge.

amending commits is not going to work for a centralized repo for either git or hg. once you push, you'll have that changeset sitting there looking malformed at you. someone will have to do central repo surgery. (looks over at github repo sadly)

git index is imo a pain

bookmarks do float upwards on commit, like branches.

hg exposes bookmarks poorly in general imo. that is part of why I suggested mixing branches and bookmarks, so that dev and prod can be kept very separate.

[fu]

fu> # nooo mercurial still doesn't have a way to distinguish between the patch author and committer

Yes, very true. Is this important?

For DW's purposes -- because we have so few people who can commit directly, and relatively many that go through code review, yes it is. We record it in the commit message itself, but...

Not planning on amending commits pushed to the main repo, but it would be good to have the ability to amend a commit when merging it from the feature branch to the develop/master branch after it's gone through code review (again something that would be really helpful for us here on DW!)