Page MenuHomePhabricator

Add support for git worktree
Open, WishlistPublic

Description

For users that are working on several orthogonal features at once in different branches, the git worktree command added in version 2.5 is nice, as it allows each branch to be checked out to a different working directory while they all share the same Git repository underneath.

This workflow is sort-of supported by arc, except that arc land would fail when trying to switch back to the branch being merged to (e.g. master) since git worktree strictly enforces the rule that no two work trees may be based on the same git branch.

Even arc land --keep-branch switches back to the branch the revision is being landed on.

This is not fatal since the error happens after the revision is landed, but it would be nice if arc would do this if the current directory is a worktree:

  • switch to the directory containing the main git checkout
  • delete the worktree directory
  • git worktree prune to remove reference to the deleted worktree
  • git branch -D to delete the branch

Event Timeline

michel-slm raised the priority of this task from to Needs Triage.
michel-slm updated the task description. (Show Details)
michel-slm changed the edit policy from "All Users" to "Custom Policy".
michel-slm added a project: Feature Request.
michel-slm added a subscriber: michel-slm.
michel-slm updated the task description. (Show Details)Dec 7 2015, 1:07 PM
epriestley triaged this task as Wishlist priority.Dec 7 2015, 5:40 PM
epriestley added a subscriber: epriestley.

Git 2.5 is less than 6 months old and we haven't seen other interest in this, so it will probably be a while before we get to it, but it's reasonable for us to try to accommodate this better.

(I'm generally curious what the use case for git worktree is, it's not immediately obvious to me why it would be useful -- maybe for projects which have a lengthy build step that produces some sort of binary?)

turadg added a subscriber: turadg.Dec 7 2015, 7:06 PM
avivey added a subscriber: avivey.Dec 7 2015, 7:22 PM

It might make sense in JAVA world, where IDEs load the whole tree and still don't play nice with everything changing on them (Windows?); So you'd equate "branch" with "workdir" and "disk path", and don't bother the IDE about it.

It also sounds like an easier way to do "git clone --reference", which is actually kinda easy anyway, so IDK.

One use case is indeed in the Java world (we're a Java shop). But support for this would also be really useful in situations where you're working on a feature (or several different features) orthogonally in different branches, and sometimes have uncommitted files lying around you don't want to commit just yet, and have to perform reviews on other people's code to boot. So - a technical team lead would encounter this.

Without git worktree, you'd have to remember to pop the stash after you're done.

But anyway, I agree that it's a "nice to have" but not a high priority for now. I could always work on the main repo checkout when landing the feature in question.

So - a technical team lead would encounter this.

I'd describe myself as this, at least approximately, but never have files lying around that I don't want to commit. Why wouldn't you want to commit a file?

sometimes have uncommitted files lying around you don't want to commit just yet

I'm in a Java + Mercurial shop -- this situation sometimes comes up, but I've gotten in the habit of just committing the changes as-is (even if not compilable). Both mercurial and git support amending commits, so it's usually trivial to make a "transient" commit, come back to pick it up later. Alternative to an amend, I had considered making an hg alias which would essentially dump the last commit back into working dir state (I wouldn't be surprised if there's already a way to do this in hg):

  1. export commit to patch
  2. strip commit
  3. apply patch with --no-commit

There might be some benefit I'm not aware of with git related to the index which I think is additional state a user might want to keep around?

So - a technical team lead would encounter this.

I'd describe myself as this, at least approximately, but never have files lying around that I don't want to commit. Why wouldn't you want to commit a file?

In my situation, this normally comes up when I'm still exploring the problem space for a particular feature. The alternative is, as @cspeckmim says, to just commit anyway and later amend them (or, in Git, squashing the changes etc.).

With worktree, if I'm finding myself suddenly having to abandon the exploration to work on something urgent, I can just start a new work tree off of master in a different directory, and it starts in a clean state - no need to stash.

Though we're a Java shop, funnily enough, this is happening during a major refactoring of our orchestration playbooks written in Ansible. While there is less of a need for it once things settle down, the "never having to deal with the stash stack" alone is probably worth using work trees -- we're using it now despite the slight annoyance with arc land!

turadg removed a subscriber: turadg.Dec 9 2015, 11:14 PM
eadler added projects: Restricted Project, FreeBSD.Jun 17 2016, 6:56 AM
eadler moved this task from Restricted Project Column to Restricted Project Column on the Restricted Project board.Jun 17 2016, 7:08 AM
eadler moved this task from Restricted Project Column to Restricted Project Column on the Restricted Project board.Jul 4 2016, 9:05 PM