Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support additional worktrees #719

Open
hilkoc opened this issue Jan 29, 2018 · 9 comments
Open

Support additional worktrees #719

hilkoc opened this issue Jan 29, 2018 · 9 comments

Comments

@hilkoc
Copy link

hilkoc commented Jan 29, 2018

As described in this issue: #344 .
Since it's now almost 3 years later, it would be great if support for additional worktrees can be added.

@KellyDeveloped
Copy link

KellyDeveloped commented Jan 30, 2018

There isn't a wrapper for worktrees yet, but I found using Repo.git.worktree("add", folder, branch) will load the worktree for you.

From there you can navigate into the worktree and use it like you world any other worktree.

To unload the worktree, simply remove the folder and then call Repo.git.worktree("prune").

This works with the latest version.

Full example:

import os
import git
import shutil

os.mkdir(<desired-folder>)

repo = git.Repo()
print (repo) # You'll see the original branch path that you're on here

repo.git.worktree("add", <folder>, <branch>)

test_repo = git.Repo(<folder>)
print (test_repo) # Now you'll see that with this new git.Repo object that it's referencing your worktree
print (repo) # Just to confirm that this is pointing to the original location

# Run a simple command to make sure everythings working - might be better to use the wrapper library to confirm though
print (repo.git.status())
print (test_repo.git.status())

# Remove the worktree like this:
shutil.rmtree(<folder>)
repo.git.worktree("prune")

@hilkoc
Copy link
Author

hilkoc commented Feb 1, 2018

Thanks for this.
I managed to get it working. The main problem was this:
When you're in an additional worktree,

remote = repo.remote(name='origin')
remote.push()

does not work.

So instead, all the remote commands need to be called with repo.git.push() or repo.git.pull() etc.

@skharat8
Copy link

@KellyDeveloped @hilkoc

I am curious how you got this working. The example where you used Repo.git.worktree("add", folder, branch) and then initialized with git.Repo() doesn't seem to work. git.Repo() always throws an InvalidGitRepositoryError when the folder path is a worktree.

My main objective is to get all the file names from the previous commit, which I can do using "repo.git.diff('HEAD~1', name_only=True)". This works with git clones, but with worktrees, git.Repo() throws an InvalidGitRepositoryError.

Do you know how I could get this working? or is there another way to get file names from git commits?

@KellyDeveloped
Copy link

@KellyDeveloped @hilkoc

I am curious how you got this working. The example where you used Repo.git.worktree("add", folder, branch) and then initialized with git.Repo() doesn't seem to work. git.Repo() always throws an InvalidGitRepositoryError when the folder path is a worktree.

My main objective is to get all the file names from the previous commit, which I can do using "repo.git.diff('HEAD~1', name_only=True)". This works with git clones, but with worktrees, git.Repo() throws an InvalidGitRepositoryError.

Do you know how I could get this working? or is there another way to get file names from git commits?

It sounds like you're navigating into the wrong folder. This error throws when you aren't inside any type of git repo. I'd suggest using REPL to go through it line by line and see what folder you're in and checking to see if there's a .git folder in there.

The .git folder simply points back to the real git repo.

@skharat8
Copy link

@KellyDeveloped

I think the problem is that there is no .git folder for worktrees. There is a .git file instead.

I tried printing out the path that is_git_dir() is checking in fun.py in GitPython (called in Repo class __init__ function). It looks like it goes in a loop like this and then fails with InvalidGitRepositoryError:

C:/test_worktree
C:/test_worktree/.git
C:/test_clone/.git/worktrees/test_worktree
C:/test_worktree/.git
C:/test_clone/.git/worktrees/test_worktree

Just tried changing the is_git_dir() function to add a check for a file as well, and that actually worked! Since worktrees are not really supported, I am not sure if this would cause other issues, but it seems to initialize the git repo properly with git.Repo() for my use case.

def is_git_dir(d):
    """ This is taken from the git setup.c:is_git_directory
    function.
    @throws WorkTreeRepositoryUnsupported if it sees a worktree directory. It's quite hacky to do that here,
            but at least clearly indicates that we don't support it.
            There is the unlikely danger to throw if we see directories which just look like a worktree dir,
            but are none."""
    if osp.isdir(d):
        if osp.isdir(osp.join(d, 'objects')) and osp.isdir(osp.join(d, 'refs')):
            headref = osp.join(d, 'HEAD')
            return osp.isfile(headref) or \
                (osp.islink(headref) and
                 os.readlink(headref).startswith('refs'))
        elif (osp.isfile(osp.join(d, 'gitdir')) and
              osp.isfile(osp.join(d, 'commondir')) and
              osp.isfile(osp.join(d, 'gitfile'))):
            raise WorkTreeRepositoryUnsupported(d)
   # Added this for worktree support
    elif osp.isfile(d):
        return True
    return False

@Byron
Copy link
Member

Byron commented Oct 14, 2018

Thanks for sharing all your insights! It's much appreciated and certainly helpful to others.

@yarikoptic
Copy link
Contributor

Keeps biting us in DataLad, so if some brave soul gets to resolve it -- would be much appreciated!

@Byron
Copy link
Member

Byron commented Aug 14, 2019

This was closed via #894 and released with v3.0.0

@Byron Byron closed this as completed Aug 14, 2019
ghost pushed a commit that referenced this issue Aug 14, 2019
Revert "use git rev-parse to look for config file"

This reverts commit 0b6b90f.

Fix #906
Reopen #719
@Byron
Copy link
Member

Byron commented Aug 14, 2019

Reopened as the fix was reverted to deal with the performance regression reported in #906 . We hope to let the fix return in a version that caches the output it receives from git-revparse or obtains the information in another way.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Development

No branches or pull requests

5 participants