Re: rev-parse --show-toplevel broken during exec'ed rebase?
On Thu, Jul 12, 2018 at 8:23 AM Junio C Hamano wrote: > > Vitali Lovich writes: > > > Repro (starting with cwd within git project): > >> (cd xdiff; git rev-parse --show-toplevel) > > ... path to git repository > >> git rebase -i 18404434bf406f6a6f892ed73320c5cf9cc187dd > > # Stop at some commit for editing > >> (cd xdiff; git rev-parse --show-toplevel) > > ... path to git repository > >> git rebase 18404434bf406f6a6f892ed73320c5cf9cc187dd -x "(cd xdiff; git > >> rev-parse --show-toplevel)" > > ... path to git repository/xdiff !!! > > > > This seems like incorrect behaviour to me since it's a weird > > inconsistency (even with other rebase contexts) & the documentation > > says "Show the absolute path of the top-level directory." with no > > caveats. > > Does it reproduce with older rebase (say from v2.10 days), too? > > I suspect that the above is because "git rebase" is exporting > GIT_DIR without exporting GIT_WORK_TREE. When the former is given > without the latter, that tells Git that you are at the top-level of > the working tree (if that is not the case, you also export the > latter to tell Git where the top-level is). > > I suspect that "git rebase" before the ongoing piecemeal rewrite to > C started (or scripted Porcelain in general) refrained from > exporting GIT_DIR to the environment, and if my suspicion is correct, > older "git rebase" would behave differently to your test case. Unfortunately I don't have an older git version handy to test this out.
Re: rev-parse --show-toplevel broken during exec'ed rebase?
Sorry. Forgot to include the git versions I tested with (2.13.1, 2.17.0, 2.18.0) On Wed, Jul 11, 2018 at 7:50 PM Vitali Lovich wrote: > > Typically git rev-parse --show-toplevel prints the folder containing > the .git folder regardless what subdirectory one is in. One exception > I have found is that if one is within the context of git rebase --exec > then show-toplevel always just prints the current directory it's > running from. > > Repro (starting with cwd within git project): > > (cd xdiff; git rev-parse --show-toplevel) > ... path to git repository > > git rebase -i 18404434bf406f6a6f892ed73320c5cf9cc187dd > # Stop at some commit for editing > > (cd xdiff; git rev-parse --show-toplevel) > ... path to git repository > > git rebase 18404434bf406f6a6f892ed73320c5cf9cc187dd -x "(cd xdiff; git > > rev-parse --show-toplevel)" > ... path to git repository/xdiff !!! > > This seems like incorrect behaviour to me since it's a weird > inconsistency (even with other rebase contexts) & the documentation > says "Show the absolute path of the top-level directory." with no > caveats. > > Thanks, > Vital
rev-parse --show-toplevel broken during exec'ed rebase?
Typically git rev-parse --show-toplevel prints the folder containing the .git folder regardless what subdirectory one is in. One exception I have found is that if one is within the context of git rebase --exec then show-toplevel always just prints the current directory it's running from. Repro (starting with cwd within git project): > (cd xdiff; git rev-parse --show-toplevel) ... path to git repository > git rebase -i 18404434bf406f6a6f892ed73320c5cf9cc187dd # Stop at some commit for editing > (cd xdiff; git rev-parse --show-toplevel) ... path to git repository > git rebase 18404434bf406f6a6f892ed73320c5cf9cc187dd -x "(cd xdiff; git > rev-parse --show-toplevel)" ... path to git repository/xdiff !!! This seems like incorrect behaviour to me since it's a weird inconsistency (even with other rebase contexts) & the documentation says "Show the absolute path of the top-level directory." with no caveats. Thanks, Vital
Re: --progress option for git submodule update?
& then do a git submodule init? > On Sep 11, 2015, at 4:05 PM, Stefan Beller <sbel...@google.com> wrote: > > On Wed, Sep 9, 2015 at 8:06 PM, Vitali Lovich <vlov...@gmail.com> wrote: >>> Doh! I see what you're missing now after rereading the email closely. >>> You can add a --quiet option, >>> but --verbose or --progress just errors out, but you want that as a >>> possible argument for git clone >>> inside the git submodule update code. >> Yes exactly. > > Instead of cloning with submodules, you could also clone only the > superproject and then do a git fetch --recuse-submodules=yes -v > instead soonish. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
--progress option for git submodule update?
Hi, Git submodule doesn’t have a --progress option like regular clone/fetch does. This means that it can hang a long time without output as it’s transferring data, particularly for large repositories. This is problematic in automation scenarios where there can be upper-bounds on how long a process may run without any output (to protect against processes hanging for long periods of time without forward progress). I’m sure this has been asked for before but having this option would be really nice for automation system (like buildbot) to take advantage of. The only alternative is a hacky solution to clone locally first with the —progress option & then somehow set up the submodule to use the local clone as a reference. Thanks, Vitali-- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: --progress option for git submodule update?
> On Sep 9, 2015, at 4:40 PM, Stefan Beller <sbel...@google.com> wrote: > > So submodules... > > I am currently working on improving submodules (some basic performance > improvements have been done, soon to be merged upstream, I currently > try to get parallelism working for git fetch --recurse-submodules and for > git submodule update eventually. I sent some early working patches for that, > but I am doing a whole new redesign without threads now). That sounds exciting. Can’t wait. > On Wed, Sep 9, 2015 at 3:52 PM, Vitali Lovich <vlov...@gmail.com> wrote: >> Hi, >> >> Git submodule doesn’t have a --progress option like regular clone/fetch >> does. This means that it can hang a long time without output as it’s >> transferring data, particularly for large repositories. > > For repositories with nested submodules it is impossible to estimate > the progress because you don't know how many there are. > Say you have a layout like: > > A > -> B > -> C > -> D >-> E >-> F > > whereas each letter is a repository and B,C,D are submodules of A and > E,F are submodules of D. > So if D is not cloned yet, it looks like A has only 3 submodules, but > in fact we need to update 5 > submodules. I don’t think I’m asking for an overall --progress. As you point out that is very difficult/an intractable problem. I was thinking it would just report the progress for each submodule it encounters as it fetches/clones. The added benefit to that is that if there’s a lot of submodules, an overall progress might get stuck at a long time at a given percentage whereas it’s less likely cloning just a single module would depending on the size of repositories. >> This is problematic in automation scenarios where there can be upper-bounds >> on how long a process may run without any output (to protect against >> processes hanging for long periods of time without forward progress). > > Maybe a better error-out-if-hanging would be better IMHO ? > Another option would be to enumerate the submodules and give the > currently estimated upper bound ? That’s much more difficult & I’m still left with the original problem where I have to set a very conservative upper-bound which wastes valuable machine time & causes extra contention for automation resources. > Doh! I see what you're missing now after rereading the email closely. > You can add a --quiet option, > but --verbose or --progress just errors out, but you want that as a > possible argument for git clone > inside the git submodule update code. Yes exactly. > > Thanks, > Stefan > >> >> I’m sure this has been asked for before but having this option would be >> really nice for automation system (like buildbot) to take advantage of. The >> only alternative is a hacky solution to clone locally first with the >> —progress option >> & then somehow set up the submodule to use the local clone as a reference. >> >> Thanks, >> Vitali-- >> To unsubscribe from this list: send the line "unsubscribe git" in >> the body of a message to majord...@vger.kernel.org >> More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
