* rebase not honoring core.worktree pointing elsewhere @ 2010-11-01 17:22 Paul Drews 2010-11-01 17:38 ` Sverre Rabbelier 2010-11-02 0:11 ` Nguyen Thai Ngoc Duy 0 siblings, 2 replies; 10+ messages in thread From: Paul Drews @ 2010-11-01 17:22 UTC (permalink / raw) To: git Hello, I'm observing an unexpected error from "git rebase" run from the directory containing the ".git" directory: $ git --version git version 1.7.3.GIT (includes up to commit ca2090 from git repository at http://www.kernel.org/pub/scm/git/git.git) $ mkdir wherefilesare $ mkdir wheregitis $ cd wherefilesare $ echo "Here is a line from the original" > myfile.txt $ cd ../wheregitis $ git init $ git config core.worktree /absolute/path/to/wherefilesare/ $ git add . $ git commit $ git branch mybranch $ git checkout mybranch $ vim ../wherefilesare/myfile.txt $ git add . $ git commit $ git checkout master $ vim ../wherefilesare/myfile.txt $ git add . $ git commit $ git checkout mybranch $ git rebase master fatal: /usr/libexec/git-core/git-rebase cannot be used without a working tree. Since I'm in the directory containing ".git" at this point, the ".git" directory and the worktree can be unambiguously found. Other commands besides "git rebase" work. I would expect "git rebase" to work as well. Is this a bug or an unreasonable expectation on my part? ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: rebase not honoring core.worktree pointing elsewhere 2010-11-01 17:22 rebase not honoring core.worktree pointing elsewhere Paul Drews @ 2010-11-01 17:38 ` Sverre Rabbelier 2010-11-02 0:11 ` Nguyen Thai Ngoc Duy 1 sibling, 0 replies; 10+ messages in thread From: Sverre Rabbelier @ 2010-11-01 17:38 UTC (permalink / raw) To: Paul Drews, Nguyễn Thái Ngọc Duy; +Cc: git [+Nguyễn Thái Ngọc Duy, who is currently working on improving/fixing how git handles worktree detection] On Mon, Nov 1, 2010 at 18:22, Paul Drews <paul.drews@intel.com> wrote: > I'm observing an unexpected error from "git rebase" run from the directory > containing the ".git" directory: > > $ git --version > > git version 1.7.3.GIT > (includes up to commit ca2090 from git repository at > http://www.kernel.org/pub/scm/git/git.git) > > $ mkdir wherefilesare > $ mkdir wheregitis > $ cd wherefilesare > $ echo "Here is a line from the original" > myfile.txt > $ cd ../wheregitis > $ git init > $ git config core.worktree /absolute/path/to/wherefilesare/ > $ git add . > $ git commit > $ git branch mybranch > $ git checkout mybranch > $ vim ../wherefilesare/myfile.txt > $ git add . > $ git commit > $ git checkout master > $ vim ../wherefilesare/myfile.txt > $ git add . > $ git commit > $ git checkout mybranch > $ git rebase master > > fatal: /usr/libexec/git-core/git-rebase cannot be used without a working tree. > > Since I'm in the directory containing ".git" at this point, the ".git" directory > and the worktree can be unambiguously found. Other commands besides "git > rebase" work. I would expect "git rebase" to work as well. Is this a bug or an > unreasonable expectation on my part? Sounds like a bug. -- Cheers, Sverre Rabbelier ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: rebase not honoring core.worktree pointing elsewhere 2010-11-01 17:22 rebase not honoring core.worktree pointing elsewhere Paul Drews 2010-11-01 17:38 ` Sverre Rabbelier @ 2010-11-02 0:11 ` Nguyen Thai Ngoc Duy 2010-11-02 1:21 ` Junio C Hamano 2010-11-02 16:26 ` Paul Drews 1 sibling, 2 replies; 10+ messages in thread From: Nguyen Thai Ngoc Duy @ 2010-11-02 0:11 UTC (permalink / raw) To: Paul Drews; +Cc: git On Tue, Nov 2, 2010 at 12:22 AM, Paul Drews <paul.drews@intel.com> wrote: > Hello, > > I'm observing an unexpected error from "git rebase" run from the directory > containing the ".git" directory: > > $ git --version > > git version 1.7.3.GIT > (includes up to commit ca2090 from git repository at > http://www.kernel.org/pub/scm/git/git.git) > > $ mkdir wherefilesare > $ mkdir wheregitis > $ cd wherefilesare > $ echo "Here is a line from the original" > myfile.txt > $ cd ../wheregitis > $ git init > $ git config core.worktree /absolute/path/to/wherefilesare/ > $ git add . > $ git commit > $ git branch mybranch > $ git checkout mybranch > $ vim ../wherefilesare/myfile.txt > $ git add . > $ git commit > $ git checkout master > $ vim ../wherefilesare/myfile.txt > $ git add . > $ git commit > $ git checkout mybranch > $ git rebase master > > fatal: /usr/libexec/git-core/git-rebase cannot be used without a working tree. > > Since I'm in the directory containing ".git" at this point, the ".git" directory > and the worktree can be unambiguously found. Other commands besides "git > rebase" work. I would expect "git rebase" to work as well. Is this a bug or an > unreasonable expectation on my part? First of all, core.worktree should not matter because GIT_DIR has not been set (No don't trust core.worktree documentation, it's equivalent to --work-tree in "man git"). You need to set GIT_DIR (or --git-dir). That's a bug I'm working on. Then, yes, rebase should be updated to use worktree even if it's outside cwd. I'm not sure how to do it properly in git-rebase.sh though. The requirement "require_work_tree" can be loosen a bit. -- Duy ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: rebase not honoring core.worktree pointing elsewhere 2010-11-02 0:11 ` Nguyen Thai Ngoc Duy @ 2010-11-02 1:21 ` Junio C Hamano 2010-11-02 16:26 ` Paul Drews 1 sibling, 0 replies; 10+ messages in thread From: Junio C Hamano @ 2010-11-02 1:21 UTC (permalink / raw) To: Nguyen Thai Ngoc Duy; +Cc: Paul Drews, git Nguyen Thai Ngoc Duy <pclouds@gmail.com> writes: > Then, yes, rebase should be updated to use worktree even if it's > outside cwd. I'm not sure how to do it properly in git-rebase.sh > though. The requirement "require_work_tree" can be loosen a bit. require-work-tree traditionally meant "you must be inside the working tree, you could be in a subdirectory of it", but as long as the command is about the whole tree operation (which rebase is) and takes no pathname relative to the $(cwd) as an argument (which rebase does not), there is no strong reason why you should be _inside_ the working tree. For such commands, require-work-tree should mean "you must have a working tree, and make it known where it is to git", nothing more. ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: rebase not honoring core.worktree pointing elsewhere 2010-11-02 0:11 ` Nguyen Thai Ngoc Duy 2010-11-02 1:21 ` Junio C Hamano @ 2010-11-02 16:26 ` Paul Drews 2010-11-03 0:13 ` Nguyen Thai Ngoc Duy 1 sibling, 1 reply; 10+ messages in thread From: Paul Drews @ 2010-11-02 16:26 UTC (permalink / raw) To: git Nguyen Thai Ngoc Duy <pclouds <at> gmail.com> writes: > First of all, core.worktree should not matter because GIT_DIR has not > been set (No don't trust core.worktree documentation, it's equivalent > to --work-tree in "man git"). You need to set GIT_DIR (or --git-dir). > That's a bug I'm working on. > > Then, yes, rebase should be updated to use worktree even if it's > outside cwd. I'm not sure how to do it properly in git-rebase.sh > though. The requirement "require_work_tree" can be loosen a bit. Thanks, I can confirm that the following works: () have /abs/path/to/wheregitis/.git () have /abs/path/to/wherefilesare () export GIT_DIR=/abs/path/to/wheregitis/.git () DO NOT have core.worktree (or related items) set () cd /abs/path/to/wherefilesare () git rebase master This is a bit more dangerous than running git commands in GIT_DIR and pointing core.worktree elsewhere, since I could make the error of (1) leaving GIT_DIR unintentionally still set when doing something else, or (2) running git commands outside the (unmarked) root of the worktree. Still... it works. BTW, the impetus for this is a big integrated cross-compilation build system that has a nasty habit of deleting and re-creating a chroot environment containing the directory structures including the work tree. If the ".git" dir is at the "normal" place "inside" the work tree, it gets deleted along with all the work I have done. Not good, which is why I want to keep the ".git" somewhere else that's safe. Solutions to this: (preferred) core.worktree pointing into worktree elsewhere, run all git commands from GIT_DIR. Would be great if rebase worked under these circumstances. (best fallback) no core.worktree, export GIT_DIR pointing elsewhere, run all git commands from unmarked root of worktree. (complex) A complex scenario pushing and pulling stuff between a git repo inside the worktree and another git clone outside the worktree. (implementation dependent) Having the ".git" dir inside the worktree be a symbolic link to a dir somewhere outside the work tree. Keeps the actual ".git" contents safe from deletion. Works so far, but this is Tampering With The Implementation in a way that is likely to fail down the road somewhere, e.g., if an internal script does cd to the GIT_DIR, then cd relative to that to try to get back into somewhere else in the work tree. ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: rebase not honoring core.worktree pointing elsewhere 2010-11-02 16:26 ` Paul Drews @ 2010-11-03 0:13 ` Nguyen Thai Ngoc Duy 2010-11-03 15:41 ` Paul Drews 0 siblings, 1 reply; 10+ messages in thread From: Nguyen Thai Ngoc Duy @ 2010-11-03 0:13 UTC (permalink / raw) To: Paul Drews; +Cc: git On Tue, Nov 2, 2010 at 11:26 PM, Paul Drews <paul.drews@intel.com> wrote: > BTW, the impetus for this is a big integrated cross-compilation build system > that has a nasty habit of deleting and re-creating a chroot environment > containing the directory structures including the work tree. If the ".git" > dir is at the "normal" place "inside" the work tree, it gets deleted along > with all the work I have done. Not good, which is why I want to keep the > ".git" somewhere else that's safe. Solutions to this: > > (preferred) core.worktree pointing into worktree elsewhere, run all git > commands from GIT_DIR. Would be great if rebase worked under these > circumstances. > > (best fallback) no core.worktree, export GIT_DIR pointing elsewhere, run all > git commands from unmarked root of worktree. > > (complex) A complex scenario pushing and pulling stuff between a git repo > inside the worktree and another git clone outside the worktree. > > (implementation dependent) Having the ".git" dir inside the worktree be a > symbolic link to a dir somewhere outside the work tree. Keeps the actual ".git" > contents safe from deletion. Works so far, but this is Tampering With The > Implementation in a way that is likely to fail down the road somewhere, > e.g., if an internal script does cd to the GIT_DIR, then cd relative to > that to try to get back into somewhere else in the work tree. Another one: create a .git file with this line and put it in worktree's topdir gitdir: /path/to/real/git.dir See gitrepository-layout.txt. -- Duy ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: rebase not honoring core.worktree pointing elsewhere 2010-11-03 0:13 ` Nguyen Thai Ngoc Duy @ 2010-11-03 15:41 ` Paul Drews 2010-11-03 15:52 ` Nguyen Thai Ngoc Duy 2010-11-03 16:13 ` Jonathan Nieder 0 siblings, 2 replies; 10+ messages in thread From: Paul Drews @ 2010-11-03 15:41 UTC (permalink / raw) To: git Nguyen Thai Ngoc Duy <pclouds <at> gmail.com> writes: > > (implementation dependent) Having the ".git" dir inside the worktree be a > > symbolic link to a dir somewhere outside the work tree. Keeps the actual > > ".git" > > contents safe from deletion. Works so far, but this is Tampering With The > > Implementation in a way that is likely to fail down the road somewhere, > > e.g., if an internal script does cd to the GIT_DIR, then cd relative to > > that to try to get back into somewhere else in the work tree. > > Another one: create a .git file with this line and put it in worktree's > topdir > > gitdir: /path/to/real/git.dir > > See gitrepository-layout.txt. Ooh! That would be my favorite, since it's a documented legal usage. Unfortunately, although the rebase scenario works that way a local "git clone" doesn't work: # git clone /abs/path/to/proj Cloning into proj... fatal: failed to open '/abs/path/to/proj/objects': No such file or directory # git clone /abs/path/to/proj/ Cloning into proj... fatal: failed to open '/abs/path/to/proj//objects': No such file or directory # git --version git version 1.7.3.GIT weird ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: rebase not honoring core.worktree pointing elsewhere 2010-11-03 15:41 ` Paul Drews @ 2010-11-03 15:52 ` Nguyen Thai Ngoc Duy 2010-11-03 16:13 ` Jonathan Nieder 1 sibling, 0 replies; 10+ messages in thread From: Nguyen Thai Ngoc Duy @ 2010-11-03 15:52 UTC (permalink / raw) To: Paul Drews; +Cc: git On Wed, Nov 3, 2010 at 10:41 PM, Paul Drews <paul.drews@intel.com> wrote: >> Another one: create a .git file with this line and put it in worktree's >> topdir >> >> gitdir: /path/to/real/git.dir >> >> See gitrepository-layout.txt. > > Ooh! That would be my favorite, since it's a documented legal usage. > Unfortunately, although the rebase scenario works that way a local > "git clone" doesn't work: > > # git clone /abs/path/to/proj > Cloning into proj... > fatal: failed to open '/abs/path/to/proj/objects': No such file or directory > # git clone /abs/path/to/proj/ > Cloning into proj... > fatal: failed to open '/abs/path/to/proj//objects': No such file or directory > # git --version > git version 1.7.3.GIT "git clone" needs to learn about .git file. Thanks for pointing it out. -- Duy ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: rebase not honoring core.worktree pointing elsewhere 2010-11-03 15:41 ` Paul Drews 2010-11-03 15:52 ` Nguyen Thai Ngoc Duy @ 2010-11-03 16:13 ` Jonathan Nieder 2010-11-04 14:20 ` Nguyen Thai Ngoc Duy 1 sibling, 1 reply; 10+ messages in thread From: Jonathan Nieder @ 2010-11-03 16:13 UTC (permalink / raw) To: Paul Drews; +Cc: git, Nguyen Thai Ngoc Duy, Lars Hjemli Paul Drews wrote: > Nguyen Thai Ngoc Duy <pclouds <at> gmail.com> writes: >> Another one: create a .git file with this line and put it in worktree's >> topdir >> >> gitdir: /path/to/real/git.dir >> >> See gitrepository-layout.txt. > > Ooh! That would be my favorite, since it's a documented legal usage. By the way, .git symlinks have been historically supported and are not likely to break, either. Maybe gitrepository-layout should grow to include a section on the repository search. > Unfortunately, although the rebase scenario works that way a local > "git clone" doesn't work: > > # git clone /abs/path/to/proj > Cloning into proj... > fatal: failed to open '/abs/path/to/proj/objects': No such file or directory enter_repo() never learned .git file support, though I see no reason it should be hard to add. Pointers: - v1.5.6-rc0~93^2~3 (Add platform-independent .git "symlink", 2008-02-20) - v0.99.9l^2 (daemon.c and path.enter_repo(): revamp path validation, 2005-12-03) The precise return value from enter_repo() is currently only used by "git daemon", to handle directory arguments as in git daemon -- /srv/git so returning a fictional path like /abs/path/to/proj/.git might work ok. :) Good catch. ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: rebase not honoring core.worktree pointing elsewhere 2010-11-03 16:13 ` Jonathan Nieder @ 2010-11-04 14:20 ` Nguyen Thai Ngoc Duy 0 siblings, 0 replies; 10+ messages in thread From: Nguyen Thai Ngoc Duy @ 2010-11-04 14:20 UTC (permalink / raw) To: Jonathan Nieder; +Cc: Paul Drews, git, Lars Hjemli On Wed, Nov 3, 2010 at 11:13 PM, Jonathan Nieder <jrnieder@gmail.com> wrote: > Paul Drews wrote: >> Nguyen Thai Ngoc Duy <pclouds <at> gmail.com> writes: > >>> Another one: create a .git file with this line and put it in worktree's >>> topdir >>> >>> gitdir: /path/to/real/git.dir >>> >>> See gitrepository-layout.txt. >> >> Ooh! That would be my favorite, since it's a documented legal usage. > > By the way, .git symlinks have been historically supported and are not > likely to break, either. Maybe gitrepository-layout should grow to > include a section on the repository search. > >> Unfortunately, although the rebase scenario works that way a local >> "git clone" doesn't work: >> >> # git clone /abs/path/to/proj >> Cloning into proj... >> fatal: failed to open '/abs/path/to/proj/objects': No such file or directory > > enter_repo() never learned .git file support, though I see no reason it should > be hard to add. Also get_repo_path(). By the way if you work on this, please move enter_repo() to setup.c. Keeping it close to setup_* functions may increase the chance that it also gets fixed along with setup_*. Another thing. "git init" should probably learn to create .git file. Each time I use .git file I have to look at man page^W^Wsource code again to know its syntax. -- Duy ^ permalink raw reply [flat|nested] 10+ messages in thread
end of thread, other threads:[~2010-11-04 14:20 UTC | newest] Thread overview: 10+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2010-11-01 17:22 rebase not honoring core.worktree pointing elsewhere Paul Drews 2010-11-01 17:38 ` Sverre Rabbelier 2010-11-02 0:11 ` Nguyen Thai Ngoc Duy 2010-11-02 1:21 ` Junio C Hamano 2010-11-02 16:26 ` Paul Drews 2010-11-03 0:13 ` Nguyen Thai Ngoc Duy 2010-11-03 15:41 ` Paul Drews 2010-11-03 15:52 ` Nguyen Thai Ngoc Duy 2010-11-03 16:13 ` Jonathan Nieder 2010-11-04 14:20 ` Nguyen Thai Ngoc Duy
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.