A diff per commit is not that bad, this is my usual workflow. Using
'git rebase -i' and 'edit' you can amend individual commits in a stack.
The workflow is
* git rebase -i <oldest commit in the stack>
* 'edit' the commit you want to modify
* modify away
* arc diff
* git commit --continue
Landing is a bit more tricky though. 'arc patch D1234 && arc land' is
probably the easiest way, because you can't do arc land during a git rebase.
Cheers,
Simon
On 21/10/14 14:46, Johan Tibell wrote:
This is probably the biggest shortcoming of Phab. If you don't want this
merging behavior you need to make a separate Phab review *per commit*.
When I use arc I usually use git to rewrite the message after the review
to something less messy.
On Tue, Oct 21, 2014 at 11:04 AM, Richard Eisenberg <[email protected]
<mailto:[email protected]>> wrote:
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
[email protected] <mailto:[email protected]>
http://www.haskell.org/mailman/listinfo/ghc-devs
_______________________________________________
ghc-devs mailing list
[email protected]
http://www.haskell.org/mailman/listinfo/ghc-devs
_______________________________________________
ghc-devs mailing list
[email protected]
http://www.haskell.org/mailman/listinfo/ghc-devs
