small `arc` victory -- commit message not changed

[Simon Marlow]

I've never used --head, and it's not even documented in the help for the 
version of arc I have (which ought to be no more than a couple of months 
old).  Maybe it's a new feature.

So I'm hesitant to recommend this workflow.  I think the biggest problem 
in your description is the bit where you "de-Phabbed" the commit 
message, which meant that you had to tell Phabricator exactly which diff 
you wanted to update later.

When I have some time I'll write up the workflow I use for multiple 
dependent patches on the wiki.  But basically it amounts to

  - one Phab diff per git commit
  - use 'git rebase -i' to amend individual commits in the stack
  - use 'arc patch Dnnn && arc land' to land

I always avoid uploading multiple commits as a single diff to 
Phabricator, because it

  - make reviewing harder
  - concatenates the commit messages
  - is just confusing.

I don't know why Phab wants to do it this way, but you can just avoid it 
by using one diff per commit.  Depending on how your Phab config is set 
up this might be the default, or you might have to say "arc diff HEAD^" 
every time.

Cheers,
Simon

On 28/10/2014 12:39, Richard Eisenberg wrote:
> I just revised a Phab revision using `arc`, and it all worked swimmingly, doing exactly what I wanted, even though this was non-trivial. I describe the process below, and am happy to add to the Phab wiki page, but wanted to check here first to make sure I wasn't making an invisible dreadful mistake.
>
> Here's my story:
>
> - I had done a few edits in TcSplice and posted the (boring) revision D359.
>
> - Austin and Harbormaster both had good suggestions for me.
>
> - I spent a week completing other tasks.
>
> - I rebased my WIP branch against master. This worried me about what Phab might think.
>
> - I incorporated the suggestions. As is my usual workflow, I then rebased to integrate these changes into my original commits. As previously discussed, I think breaking a patch into separable commits is a Good Thing, and I curate these commits to be reader-friendly as I work. In the process, I de-Phabified my previous commit message, worried I was inviting demons, but determined to proceed.
>
> - I then updated my Phab revision with this:
>
> arc diff --allow-untracked --head HEAD --update D359
>
> Explanation: --allow-untracked is because I have testsuite garbage floating in my working directory, and I'm never confident enough to modify .gitignore to ignore this garbage. `--head HEAD`, I think, is the magic bit. It specifies the *end* of the commit range to be included in the Phab diff. (The beginning was inferred to be origin/master, but can be specified without flags on the command line.) According to `arc help`, "This [flag] disables many Arcanist/Phabricator features which depend on having access to the working copy." Indeed, it was this warning which made me think `--head` was my friend. Of course, specifying `--head HEAD` on the command line seems redundant, but it still effectively stopped `arc` from touching my commits, thinking that this would break my git-ness. So, `arc` did the best job it could without touching my git information, which is exactly what I wanted.
>
> Results: My new code is now viewable and reviewable at D359. Despite all of my rebasing, the diffs are clean. You can even ask for the differences between my two revisions, and Phab does the right thing -- even though there's a week's worth of other commits that were rebased in. I'm sure Harbormaster is hard at work right now checking my changes. Fellow devs can offer nice feedback. And, I have retained control over my git structure. Hooray!
>
> Question: Have I done anything wrong here? By "wrong", I mean both in a technical sense (e.g., is Harbormaster now deeply confused?) and in a project-management sense (e.g., would this be a bad pattern for others to follow?). Should I put this workflow on the wiki?
>
> If no one tells me otherwise, I plan on using `--head` every time.
>
> Thanks,
> Richard
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://www.haskell.org/mailman/listinfo/ghc-devs
>