GIT_INDEX_FILE relative paths are relative to the work tree
When I use a relative path in the GIT_INDEX_FILE environment variable, git interprets that path relative to the the work tree. This can be confusing if my cwd is some subdirectory of my project; in that case an index file is created in the project root rather than in my cwd. It can also be confusing if I'm using --git-dir and --work-tree, in which case the path is interpreted relative to the latter. Is this behavior intentional? If so, I think it would be worth mentioning in the documentation for GIT_INDEX_FILE. But I can't think of a case where I would ever want an index file to end up inside my work tree. This also comes up in http://stackoverflow.com/a/7645492/823869. Using absolute paths is a workaround. -- 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
Bug: version 2.4 seems to have broken `git clone --progress`
In git 2.3.7 I could run the following command and see progress in the terminal, despite the redirection of stdout and stderr: git clone https://github.com/oconnor663/dotfiles --progress 2>&1 | cat As of 2.4, that command no longer shows progress. When I bisect, the responsible commit is 2879bc3b0c3acc89f0415ac0d0e3946599d9fc88 ("transport-helper: ask the helper to set progress and verbosity options after asking for its capabilities"). Can anyone suggest a workaround? -- Jack O'Connor -- 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: Bug? Subtree merge seems to choke on trailing slashes.
Do I have the right list for bug reports? Apologies if not. On Tue, Nov 6, 2012 at 5:58 PM, Jack O'Connor wrote: > > I'm summarizing from here: > http://stackoverflow.com/questions/5904256/git-subtree-merge-into-a-deeply-nested-subdirectory > > Quick repro: > 1) I do an initial subtree merge in what I think is the standard way > (http://www.kernel.org/pub/software/scm/git/docs/howto/using-merge-subtree.html). > My prefix is simply "test/". > 2) I try to merge more upstream changes on top of that with the > following command: > git merge --strategy-option=subtree='test/' $upstream_stuff > 3) Git fails with an obscure error: > fatal: entry not found in tree daf4d0f0a20b8b6ec007be9fcafeac84a6eba4f0 > > If I remove the trailing slash from the command in step 2, it works just fine: > git merge --strategy-option=subtree='test' $upstream_stuff > > Note in the error message above, there's a double space after "entry". > Is it looking for a tree with an empty name? Did my trailing slash > imply a directory named empty-string? > > Thanks for your help. > > -- Jack O'Connor -- 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