Please auto-detect and open nearest parent Git repository

[hartwork]

What current behavior doesn't fully fit your needs? Why? When using gitg or QGit and I'm in a direct or indirect subfolder of the Git clone, gitg/QGit will detect the nearest .git folder further up the file system hierarchy and show the related repository, e.g.:

# git clone --depth 1 https://github.com/libexpat/libexpat
# cd libexpat/expat  # two levels!
# gitg &             # shows ../
# qgit . &           # shows ../

I tried to mimic that by running…

# gitclient .

…but I get error The selected path is not a Git repository. Please make sure you opened the correct directory. It would be nice to have GitQlient work like gitg/QGit in that regard.

What you'd like to see? Propose a solution It would be great if GitQlient could traverse upwards and pick the first parent .git that it finds, if any, instead like gitg and QGit would.

Describe alternatives you've considered On a Bash terminal:

# gitqlient "$(d="${PWD}"; while [[ "${d}" != / ]]; do [[ -d "${d}"/.git ]] && { echo "${d}" ; break ; } || d="$(dirname "${d}")"; done)"

Additional context n/a

[francescmm]

This is an interesting idea. I never though people would open it like this!

In the beginning I kinda forked from QGit, although I got rid of 99% of the code. I think I remember QGit having support from some command line options that I'm pretty sure I don't support in GitQlient.

Are you missing any of them as well? If so I could include them as part of the ticket.

[hartwork]

@francescmm I helped getting --help, --help-all and --version supported in QGit in the past and in that context I made an overview of their output at https://github.com/tibirna/qgit/pull/112#issuecomment-917626807 . Personally, I don't need anything beyond --help, --help-all, --version, <path>|<sub_path> regarding the GitQlient CLI but thanks for asking :+1:

[francescmm]

@hartwork I'll add this in the new release :)

[hartwork]

@francescmm you mean before or after 1.6.2? Just want to be sure to understand your message correctly.

[francescmm]

Oh, before 1.6.2! I want to close this tiny things before doing the release :)

Unless you are in a rush, if so I can branch from 1.6.1, take the PRs and ship it.

[hartwork]

@francescmm I'm not in a rush, but thanks for asking, please proceed as you please :+1:

[francescmm]

@hartwork Just FYI, in GitQlient you can execute with --help to see the different options you have. The version is one of them. There is also two options to manage logs and one argument to provide the paths (it supports passing several paths at once) to open de repos.

I just tried locally to execute ./gitqlient . and it does open the repo in the local folder I'm executing the command :thinking:

[hartwork]

I just tried locally to execute ./gitqlient . and it does open the repo in the local folder I'm executing the command thinking

@francescmm you would need to be in a subfolder of the clone to see it fail, not the clone root folder, like this:

# git clone --depth 1 https://github.com/libexpat/libexpat
# cd libexpat/expat  # two levels!
# gitqlient .

Is that what you did?

[francescmm]

I see, so you want to open a repository from its subfolder.

Is it a submodule or just a subfolder in a repo? Is there any reason for opening that way?

[hartwork]

I see, so you want to open a repository from its subfolder.

@francescmm yes.

Is it a submodule or just a subfolder in a repo?

Any non-submodule folder.

Is there any reason for opening that way?

One reason is convenience, it's just a bit tedious to first think about how many levels I'm apart from the root and then type ../../.. if I'm three levels in. Another reason that all core Git commands and other GUI tools do that detection without any user effort out of the box, so it has become a baseline, at least to me personally.

[hartwork]

Thanks! :pray: