For a while, I tried working around this using a "branch summary patch", which is just an empty commit I kept on top of the patchset which then Phabricator would hit.
It was really annoying and Git kept swallowing up. So I eventually gave up and just arc diff'd each patch in the set individually. Edward Excerpts from Richard Eisenberg's message of 2014-10-21 06:34:31 -0700: > Hi all, > > Is there a way to put `arc` into a read-only mode? > > Frequently while working on a patch, I make several commits, preferring to > separate out testing commits from productive work commits and non-productive > (whitespace, comments) commits. Sometimes each of these categories are > themselves broken into several commits. These commits are *not* my internal > workflow. They are intentionally curated by rebasing as I'm ready to publish > the patch, as I think the patches are easy to read this way. (Tell me if I'm > wrong, here!) I've resolved myself not to use `arc land`, but instead to > apply the patch using git. > > Yet, when I call `arc diff`, even if I haven't amended my patch during the > `arc diff`ing process, the commit message of the tip of my branch is changed, > and without telling me. I recently pushed my (tiny, uninteresting) fix to > #9692. Luckily, my last commit happened to be the meat, so the amended commit > message is still wholly relevant. But, that won't always be the case, and I > was surprised to see a Phab-ified commit message appear in the Trac ticket > after pushing. > > I know I could use more git-ery to restore my old commit message. But is > there a way to stop `arc` from doing the message change in the first place? > > Thanks! > Richard _______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
