Page MenuHomePhabricator

In "arc land", recursively resolve tracking branches until we reach one in a remote
Closed, ResolvedPublic

Description

My team's shared git repository tends to have long branch names, but, for convenience I often use shorter names in my local branches. So, for example, if I'm working with a remote branch named origin/personal/dibiase/land-example, I'll create a local tracking branch that's just named land-example. Then, when I'm working on features, I'll check out a new branch as usual, e.g. arc feature land-example-feature land-example, make my changes, and then run arc land.

It looks like arc land expects the local target branch to be named the same as the remote branch, however, so it fails with an error like this:

> arc land
Landing current branch 'land-example-feature'.
Switched to branch land-example. Updating branch...
Switched back to branch land-example-feature.
Exception
Command failed with error #128!
COMMAND
git log 'origin/land-example'..'land-example'

STDOUT
(empty)

STDERR
fatal: ambiguous argument 'origin/land-example..land-example': unknown revision or path not in the working tree.
Use '--' to separate paths from revisions, like this:
'git <command> [<revision>...] -- [<file>...]'

(Run with `--trace` for a full exception trace.)

It would be nice if Arcanist could detect this case and use the name of the branch that the target branch is tracking.

Event Timeline

edibiase created this task.Oct 9 2015, 5:43 PM
edibiase updated the task description. (Show Details)
edibiase added a project: Arcanist.
edibiase added a subscriber: edibiase.
epriestley added a subscriber: epriestley.

I think we probably solve this incidentally by doing T3855, T9537, making --onto mean in the remote, and defaulting it to the tracked branch (although I think it already does?). The only problem with this is that land-example wont get updated but from T9537 maybe you're completely fine with that?

I guess that won't quite do what you want since you're legitimately tracking a local branch which tracks a different remote branch in this case. But maybe you're partially doing this only because T9537 doesn't work?

In the specific case of the local branch existing and tracking a remote branch of a different name, I think we can use that other name by default. However, it potentially puts us in a situation where we receive an identical request asking for the other behavior and have no choice but to add --ignore-source-tracking, --ignore-destination-tracking, --onto-remote, etc.

At some point, I think we hit diminishing returns where we cover 95% or 98% of workflows and getting to 99% requires adding twice as many flags. Somewhere around there our time is probably better spent on tasks like T5055 so it's more practical for you to distribute a replacement arc workflow to accommodate your unusual requirements.

Anyway, pretty much same story here as T9537 -- I want to sort out T3855 better first, then we can tackle refinements here.

It seems perfectly reasonably to tackle the specialty-workflow problem via T5055, rather than blowing up the number of Arcanist flags. And, as you suggest, I think T9537 will largely eliminate my desire for this, since it will allow me to name my local feature branches whatever I want, and I'll only have to type the long remote branch name at feature branch creation time.

So, in short, everything you said makes total sense. Thanks!

(In this case I think your behavior is the more natural one and I'd probably want to tell the hypothetical future users wanting the other behavior to go build a custom version of "land" via T5055 with one million flags, and they may not really exist, I just want to have some sort of contingency plan in mind before making the change.)

(Cool—that seems very reasonable.)

Oh, sorry, D14356 doesn't actually fix this.

epriestley renamed this task from Unable to 'arc land' a branch if the target local branch has a different name than the remote branch to In "arc land", recursively resolve tracking branches until we reach one in a remote.Oct 28 2015, 2:30 AM

D14357 fixes this. The new behavior is to recursively resolve upstreams until we:

  • reach a local branch with a remote upstream (use the remote upstream and remote branch);
  • reach a local branch with no upstream (ignore all the tracking/upstream information -- possibly we should use the last branch we reached?);
  • reach a local branch we have previously reached (print a waring about the cycle, ignore all tracking/upstream information).