On Mar 09, 2016, at 09:29 AM, Junio C Hamano wrote:
>Let me understand the use case. You have $HOME/.git that governs
>everything under $HOME, but there are parts of $HOME/, such as
>$HOME/projects/*, that will never be controled by $HOME/.git?
Correct.
>Two obvious reactions are:
>
> - hopeful
I put my home directory under git (recently converted from bzr), but since I
have some subdirectories under $HOME that are not under git (and some that
are) I want to stop e.g. `git status` from traversing up into $HOME. For
example, I have a ~/projects directory with lots of subdirectories so whe
On Sep 01, 2015, at 09:42 AM, Junio C Hamano wrote:
>That way, you are forcing all the existing scripts to be updated to
>say "git -c ..." for _all_ invocations of Git they have, aren't you?
No, why? If the default value enables the current ui, then no scripts need
changing. Users can enable th
On Sep 01, 2015, at 02:28 AM, David Aguilar wrote:
>While a script writer could write, "git -c core.cliversion=1 ...",
>no one does that, no one wants to do that, and it just seems
>like a bad idea that's best left unexplored.
Sure, no one will do that from the command line, but I don't think peo
On Aug 31, 2015, at 05:10 PM, Duy Nguyen wrote:
>I'm probably shot down for this. But could we go with a clean plate
>and create a new command prefix (something like git-next, git2, or
>gt...)? We could then redesign the entire UI without worrying about
>backward compatibility. At some point we ca
5 matches
Mail list logo
