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
[email protected]
http://www.haskell.org/mailman/listinfo/ghc-devs
_______________________________________________
ghc-devs mailing list
[email protected]
http://www.haskell.org/mailman/listinfo/ghc-devs
