Page MenuHomePhabricator

Use GIT tracked branches for arc land targets when reasonable
ClosedPublic

Authored by bttelle on Jul 26 2014, 4:16 AM.
Tags
None
Referenced Files
F13191990: D10058.id24183.diff
Sun, May 12, 3:45 AM
F13190762: D10058.id24191.diff
Sat, May 11, 1:26 PM
F13187548: D10058.diff
Sat, May 11, 4:35 AM
Unknown Object (File)
Mon, May 6, 9:14 PM
Unknown Object (File)
Fri, May 3, 2:04 AM
Unknown Object (File)
Sun, Apr 28, 10:56 PM
Unknown Object (File)
Wed, Apr 24, 10:09 PM
Unknown Object (File)
Sun, Apr 21, 4:20 PM
Subscribers

Details

Summary

See T5690.
-arc land now respects tracked branch when choosing 'onto'; '--onto' option remains as an override.
-arc land now respects tracked branch when choosing a remote; the remote is taken from 'onto's upstream unless the '--remote' option is present; when 'onto' branch has no upstream the '--remote' option must be provided as before.

Since 'arc feature' branches are (already) created as tracking branches, 'arc.land.onto.default' if present, is only used as the default when a non-tracking branch created by some other means is landed with out explicit '--onto'. This may be surprising but is probably the correct go-forward behavior and is inline with the description in T5690.

Test Plan

-checked having no arc.land.onto.default still assumes 'master'
-checked 'arc.land.onto.default' still overrides 'master'
-checked upstream branch (of feature branch) overrides 'master' and 'arc.land.onto.default'
-checked '--onto' overrides all
-checked origin is default for non-tracking branches
-checked the land onto branch's upstream remote is used instead of 'origin'
-checked '--remote' overrides 'origin' and the tracked upstream
-tested several crazy branch names including 'something/like/this' for both the upstream and tracking branches
-tested on linux and OS X
-rinse and repeat on Windows

Diff Detail

Repository
rARC Arcanist
Lint
Lint Skipped
Unit
Tests Skipped

Event Timeline

bttelle retitled this revision from to Use GIT tracked branches for arc land targets when reasonable.
bttelle updated this object.
bttelle edited the test plan for this revision. (Show Details)
bttelle added a reviewer: epriestley.
bttelle edited edge metadata.

Added --no-color to the git branch --list commands

I'll bullet-proof the matching a bit more if the overall approach looks ok. Let me know if I'm on the right track. I tested about half of the test plan so far.

src/workflow/ArcanistLandWorkflow.php
247

this regex needs to be tightened up; right now it is incorrect for this oddball case:

  • master 76d80fa [master] Rename blah [1/50]

i.e., master has no upstream set and commit message looks like a tracking branch

src/workflow/ArcanistLandWorkflow.php
258

actually it's this regex that applies to above comment; sorry I'm a noob with the tools

Oh, I think you can figure out the tracked name more easily with:

$ git rev-parse --symbolic-full-name master@{upstream}

...where master is the name of the branch you want to learn the upstream for. The flag --abbrev-ref might also be helpful, but I think it might introduce ambiguity for branches which contain slashes in their names. This approach otherwise looks generally correct, but I think using rev-parse can simplify it a lot. Let me know if there's a reason that doesn't work and maybe I can come up with another approach.

I had a feeling you would show me a much better approach than my -v/-vv hack. Thanks for the feedback. I'll resubmit after testing with rev-parse. It looks like it will work fine.

bttelle edited edge metadata.

uses rev-parse for discovering upstreams; simpler, handles branches with slashes

tweaked regex for matching remotes

epriestley edited edge metadata.

Yep, this seems reasonable. Thanks!

This revision is now accepted and ready to land.Jul 28 2014, 11:20 PM
epriestley updated this revision to Diff 24209.

Closed by commit rARCbb6d11b73222 (authored by Joseph Battelle <git@bttelle.com>, committed by @epriestley).