Automatically try open path + "/.git"

[yysun]

Is it possible in the constructor of Repository if repo not found on given path, automatically try path + "/.git", and then path + ".git", maybe even parent directories, before throw exception?

thanks,

yysun

[tclem]

I see that this might be nice from the API consumer perspective, but I have mixed feelings.

First of all the .git directory is basically a database and it is important to specify which database you want to open. Some cases where I think it might be confusing if we start searching around for .git folders include repos that have submodules or subprojects (or even fake submodules which is what I tend to you). You may end up opening a completely different repository than you expected.

Second, what is your use case for this? It seems like having to new up a Repository with an explicit path to the db isn't a lot of work and actually might be a good thing. I've even seen people name there repositories like this: /path_to_repo/repo.git/.git - where they've suffixed the working directory with .git - I think I'd rather force people to be explicit.

[yysun]

In my case (https://github.com/yysun/Git-Source-Control-Provider), visual studio projects' repositories usually are in then solution folder. Given a path to the project, it is easy to find out where is the repository if it automatically searches directories. I feel it is convenient as GitSharp does this.

    public static Repository Open(DirectoryInfo directory)
    {
        var name = directory.FullName;
        if (name.EndsWith(Constants.DOT_GIT_EXT))
        {
            return new Repository(directory);
        }

        var subDirectories = directory.GetDirectories(Constants.DOT_GIT);
        if (subDirectories.Length > 0)
        {
            return new Repository(subDirectories[0]);
        }

        if (directory.Parent == null) return null;

        return Open(directory.Parent);

     } 

I agree for lower level call NativeMethods.git_repository_open explicit is good. But as high lever, maybe it's better to have more side features.

Regards,

yysun

[nulltoken]

I agree with Tim on this. The constructor shouldn't guess.

Even in GitSharp/JGit, the constructor doesn't probe anything. It expects a valid path.

Open is only a helper method.

[nulltoken]

It looks like libigit2 might merge some similar helper method.

[txdv]

It is in the development branch now!

[nulltoken]

Merged in libgit2 with commit libgit2/libgit2@793545e.@davidebbo also expressed some interest in this functionality.

I still feel uneasy with adding this to the ctor. How about adding a helper method the Repository type?

public static string ProbeForGitDirectory(string startingPath)

Proposals for a better name are also welcome :)

[txdv]

public static string Discover(string startingPath);

So we got:

Repository.Discover(@"C:\My Documents and Settings\Tom Taylor\");

So it is kinda obvious what it is searching for!

[davidebbo]

Personally, I think it would make sense to have this discovery be automatic. The way I look at it, the .git folder is an implementation detail of git, and not something that should bleed though the API. And for the most part, that's how it works from the git command line: you can clone a repo, do all kind of things and push back changes without ever being aware of the existence of the .git folder.

That being said, the Discover API would be better than nothing :)

[txdv]

I don't think this is a good idea, has a lot potential of commiting to the wrong repo without even noticing, what happen in my case, because I had a .git repo in my home folder and sometimes I added unwillingly some coding stuff to the config repo.

[davidebbo]

About it having "a lot potential of commiting to the wrong repo without even noticing", I don't really understand that argument. How is it different from the behavior of git from the command line? If you run 'git commit' from some folder, it uses some predictable logic to determine what repo the commit belongs to. So making the API work the same way doesn't feel like a stretch.

Though if some think that's too scary, we could limit this discovery to simply allowing the root of the working folder to be used, and not arbitrary folders below it. So if I have c:\project, c:\project.git and c:\project\sub, I'd be able to pass in the first two but not the third. Can we agree that this wouldn't add much risk of committing to the wrong repo? :)

[nulltoken]

A new version a libgit2 binaries have been pushed to LibGit2Sharp/vNext branch. They've been compiled against libgit2/libgit2@a5aa5bd

[nulltoken]

@davidebbo, I think I'll stick with my initial design proposal: a static helper method. However, I can't really explain why it feels to me like a better/safer/more predictable choice from an API perspective.

All that I can come with is "This feels more like a DateTime.TryParse() rather than a DateTime ctor."

From another perspective, according to semver.org, the API is not considered stable due to our version number, so this might be re-evaluated later :-)

[txdv]

The Discover API goes in a recursive way through all parent directories and tries to add .git everywhere.
Just probing path + "/.git" won't hurt, but going the recursive way (which the new discover libgit2 provides) has a few bad scenarios:

/home/bentkus/.git is my homes directory git repository, /home/bentkus/Projects/libgit2net/.git is my project git repo, If I create a directory in Projects, forget to initiate a git repo => I will end up adding stuff to my home git repo.

Now that I'm reviewing the topic, am I talking about something completely different? Cause I'm talking about the extern git_repository_discover functionality.

[nulltoken]

Merged in LibGit2Sharp/vNext