relative objects/info/alternates doesn't work on remote SMB repo
Hi, I have a repo accessed through //server/share/foo/repo (Using msysgit). .git/objects/info/alternates contains '../../../bare/objects' Running 'git status' (or almost any other action) gives the following output: error: object directory /server/share/foo/bare/objects does not exist; check .git/objects/info/alternates. Note that it tries to access /server instead of //server. - Orgad -- 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: relative objects/info/alternates doesn't work on remote SMB repo
On Thu, Aug 30, 2012 at 3:51 PM, Nguyen Thai Ngoc Duy wrote: > > On Wed, Aug 29, 2012 at 1:43 PM, Orgad and Raizel Shaneh > wrote: > > Hi, > > > > I have a repo accessed through //server/share/foo/repo (Using msysgit). > > > > .git/objects/info/alternates contains '../../../bare/objects' > > > > Running 'git status' (or almost any other action) gives the following > > output: > > error: object directory /server/share/foo/bare/objects does not exist; > > check .git/objects/info/alternates. > > > > Note that it tries to access /server instead of //server. > > Could be path normalization. What does "git rev-parse --git-dir" say? > Try to run it at top working directory and a subdirectory as well. > > If you set GIT_OBJECT_DIRECTORY environment variable to > //server/share/foo/repo/.git/objects, does it work? > -- > Duy git rev-parse --git-dir in a subdirectory has //server setting GIT_OBJECT_DIRECTORY prints "fatal: bad object HEAD" on git status. - Orgad -- 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: relative objects/info/alternates doesn't work on remote SMB repo
On Thu, Aug 30, 2012 at 4:22 PM, Nguyen Thai Ngoc Duy wrote: > On Thu, Aug 30, 2012 at 8:12 PM, Orgad and Raizel Shaneh > wrote: >>> Could be path normalization. What does "git rev-parse --git-dir" say? >>> Try to run it at top working directory and a subdirectory as well. >>> >>> If you set GIT_OBJECT_DIRECTORY environment variable to >>> //server/share/foo/repo/.git/objects, does it work? >> >> git rev-parse --git-dir in a subdirectory has //server > > Hmm where is your git repository? That does not look like a git > repository's path. > Let me try to explain again. I have /d/share/bare, which is a bare repository, and /d/share/repo which is a clone with a relative path to bare/.git/objects in its .git/objects/info/alternates D:\share is configured as a SMB shared folder. It is accessed using //server/share. I do not clone from this directory, but work directly in it using 'cd //server/share', then performing git operations. >> setting GIT_OBJECT_DIRECTORY prints "fatal: bad object HEAD" on git status. > > I guessed you put your repo in .../repo/.git, but I was probably > wrong. Try setting again, pointing GIT_OBJECT_DIRECTORY to the > "objects" directory inside your repository. I just want to make see if > it's because git miscalculates this path. If setting the env variable > works, then it probably does. > -- > Duy Same result. fatal: bad object HEAD. Tried even using a full (local) path to the objects dir. - Orgad -- 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: [PATCH] git-submodule: respect -q for add/update
On Tue, Sep 4, 2012 at 6:28 PM, Jens Lehmann wrote: > > Am 04.09.2012 09:31, schrieb Orgad Shaneh: > > Signed-off-by: Orgad Shaneh > > Before the "Signed-off-by" is the place where you should have > explained why this would be a worthwhile change ;-) > > To me this looks like you make the default noisier and require an > explicit "-q" to make it quiet again. There is a reason you don't > normally get bothered with the output of the checkout command run > under the hood of git submodule add/update, so I don't think this > change makes things better. > > But you might want to think about adding a "-v/--verbose" flag to > make the submodule add/update checkouts more verbose, in case you > care about the output of the checkout command. That would be a > sane thing to do, so what about changing your patch into this > direction? > I don't agree the default should be quiet. That's what the (submodule) -q flag is there for. When I run 'git submodule update' I don't expect to be in the dark until the submodule/s finishes checkout, this sometimes can take a significant amount of time and feedback is expected. - Orgad -- 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
git rebase -i does not rebase if all lines are removed
Make a commit on top of master. git rebase -i origin/master Remove the commit. Git prints "Nothing to do" and does not rebase. Running 'git rebase -i' when there are no local commits has 'noop' in the first line, and with it the rebase is successful. Why is this 'noop' mandatory? - Orgad -- 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