* Re: [PATCH 2/2] read-tree: at least one tree-ish argument is required
From: Jakub Narebski @ 2009-12-18 22:17 UTC (permalink / raw)
To: Johannes Sixt; +Cc: Junio C Hamano, Sverre Rabbelier, Git Mailing List
In-Reply-To: <200912182304.27656.j.sixt@viscovery.net>
Johannes Sixt <j.sixt@viscovery.net> writes:
> Running read-tree without any arguments purges the index, but this is not
> documented. This behavior is dubious at best because contrary to many
> other commands, it does not use HEAD if nothing else is specified.
>
> If one really wants to clear the index, this can be achieved with
> 'git rm --cached .' or 'rm -f .git/index' in a more explicit way.
One can (I think) also always use "git read-tree <empty tree>",
where <empty tree> = 4b825dc642cb6eb9a060e54bf8d69288fbee4904
--
Jakub Narebski
Poland
ShadeHawk on #git
^ permalink raw reply
* Re: git remote set-head not working?
From: Jay Soffian @ 2009-12-18 22:24 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Eugene Sajine, Jeff King, git
In-Reply-To: <7veimst0w6.fsf@alter.siamese.dyndns.org>
On Fri, Dec 18, 2009 at 4:42 PM, Junio C Hamano <gitster@pobox.com> wrote:
> Jay Soffian <jaysoffian@gmail.com> writes:
>
>> The remote command is about updating things under .git/refs/remotes,
>> not about updating a remote server. For updating a remote server,
>> there is really only push. Clear as mud?
>
> We still support (and unfortunately we would probably end up supporting
> for a long time) "remote update" so it is not strictly true, but that is
> the original motivation behind "git remote" subcommand.
But "remote update" updates the local repo from the remote, it doesn't
do anything to the remote itself. That is the point I was trying to
make clear -- "git remote" doesn't ever do anything to the remote
repo, it only updates things on the local repo.
>> Understood. I'm not sure whether the send-pack/receive-pack protocol
>> supports the notion of "I want to change what HEAD points to."
>
> It does not support it, but that is not because there is a strong reason
> it shouldn't.
Okay. I'm sure deciding where to place the command "I want to update
what HEAD on remote points to" would be a fun discussion. :-)
j.
^ permalink raw reply
* Re: [PATCHv2] am: fix patch format detection for Thunderbird "Save As" emails
From: Eric Blake @ 2009-12-18 22:42 UTC (permalink / raw)
To: git
In-Reply-To: <1261173577.14059.5.camel@swboyd-laptop>
Stephen Boyd <bebarino <at> gmail.com> writes:
> > echo and \ do not portably mix. For that matter, shell double quotes and
> > backslash escapes that are not required by POSIX do not portably mix.
>
> Thanks. Hopefully squashing this in will make it even more portable?
>
> + printf "X-Fake-Field: Line One\015\n" &&
Nope. You need either "\\015\\n" or '\015\n', since "\015" and "\n" are both
undefined in portable shell.
--
Eric Blake
^ permalink raw reply
* FEATURE REQUEST: Env override GIT_GLOBAL_CONFIG
From: Moe @ 2009-12-18 22:54 UTC (permalink / raw)
To: git
Hello list,
I'm looking for a way to read a custom config file in
addition to .git/config.
An env var along the lines of GIT_GLOBAL_CONFIG (and perhaps
GIT_SYSTEM_CONFIG) to override the default locations of
~/.gitconfig or $prefix/etc/gitconfig would be most
welcome here.
$GIT_CONFIG doesn't work for this purpose because when set
git will *only* read the referenced file and ignore the
repository settings.
$GIT_CONFIG_LOCAL wouldn't do either and has been
removed from git anyways.
Use-Case:
Multiple users sharing one unix account. Trying to inject the respective
git identity and other preferences without overwriting
the actual .gitconfig-file - because that doesn't work when multiple
users are logged in concurrently to the same unix-account.
Kind regards,
Moe
^ permalink raw reply
* Re: [PATCH 2/2] read-tree: at least one tree-ish argument is required
From: Junio C Hamano @ 2009-12-18 23:46 UTC (permalink / raw)
To: Jakub Narebski; +Cc: Johannes Sixt, Sverre Rabbelier, Git Mailing List
In-Reply-To: <m3d42cc4i8.fsf@localhost.localdomain>
Jakub Narebski <jnareb@gmail.com> writes:
> Johannes Sixt <j.sixt@viscovery.net> writes:
>
>> Running read-tree without any arguments purges the index, but this is not
>> documented. This behavior is dubious at best because contrary to many
>> other commands, it does not use HEAD if nothing else is specified.
>>
>> If one really wants to clear the index, this can be achieved with
>> 'git rm --cached .' or 'rm -f .git/index' in a more explicit way.
>
> One can (I think) also always use "git read-tree <empty tree>",
> where <empty tree> = 4b825dc642cb6eb9a060e54bf8d69288fbee4904
Come on. If you genuinely believe that
$ git read-tree 4b825dc642cb6eb9a060e54bf8d69288fbee4904
is a better way to purge the index than
$ git read-tree
then you need to get your head examined. No, read-tree does not default
to examine HEAD and that will not change ;-).
Besides, read-tree is a plumbing.
Come back with a proof that there has never existed any script that uses
"read-tree" without arguments to purge the index, and I'd immediately
accept and apply the patch to retroactively forbid what the implementation
has allowed users to do for a long time. Otherwise, I won't be involved
in discussing this before the next release is cut, as a change like this
needs a reasonable transition strategy as usual, and needs to happen after
the next release.
^ permalink raw reply
* Re: [PATCHv2] am: fix patch format detection for Thunderbird "Save As" emails
From: Junio C Hamano @ 2009-12-18 23:49 UTC (permalink / raw)
To: Eric Blake, Stephen Boyd; +Cc: git
In-Reply-To: <loom.20091218T223918-175@post.gmane.org>
Eric Blake <ebb9@byu.net> writes:
> Stephen Boyd <bebarino <at> gmail.com> writes:
>
>> + {
>> + echo "X-Fake-Field: Line One\015" &&
>
> echo and \ do not portably mix. For that matter, shell double quotes and
> backslash escapes that are not required by POSIX do not portably mix. To
> reliably create carriage returns in shell, you need to use printf, or else
> something like:
>
> echo "...@" | tr '@' '\015'
Thanks.
Also we probably want to change the "only munge the first three lines" to
something like:
format-patch --stdout |
sed -e 's/$/Q/' |
tr 'Q' '\015'
picking some 'Q' that we know does not appear in the text.
^ permalink raw reply
* Re: git remote set-head not working?
From: Eugene Sajine @ 2009-12-18 23:55 UTC (permalink / raw)
To: Jay Soffian; +Cc: Jeff King, git
In-Reply-To: <76718490912181328k5f87d82u499b7a1eba471126@mail.gmail.com>
> The remote command is about updating things under .git/refs/remotes,
> not about updating a remote server. For updating a remote server,
> there is really only push. Clear as mud?
>
> It is expected that the person setting up the bare repo is the person
> who knows best which is the "default" branch. Which is why clone uses
> the remote HEAD as the default branch to checkout.
>
> But, if you don't like that, you can always use:
>
> % git clone -b master ...
didn't know that, thanks!
>> Secondly, I don't really understand what is the purpose of "git remote
>> set-head" if the change cannot be transferred to the actual origin
>> repo, so it will start serving another branch as default?
>
> Hmm, the man page says:
>
> set-head
> Sets or deletes the default branch ($GIT_DIR/remotes/<name>/HEAD)
> for the named remote. Having a default branch for a remote is not
> required, but allows the name of the remote to be specified in lieu
> of a specific branch. For example, if the default branch for origin
> is set to master, then origin may be specified wherever you would
> normally specify origin/master.
>
> This seems clear to me, but I guess if you expect that "git remote"...
terms i'll use here:
remote - instance created using git remote add or by cloning
origin - actual remote repo I cloned from
If it would be exactly as you said then it would probably not be so confusing.
The problem here is that if set-head is only about the remote, then
why after i change it from master to qa and "git show remote origin"
doesn't show this change? Bug? Probably, because "git show remote
origin" actually queries origin for this info and always shows origin
HEAD branch, as Jeff pointed out. If this is the case then there is an
inconsistency between those two commands which caused this confusion.
Please, correct me If i'm wrong but i really think that there should
be a way to not only set it up for remote but also for origin , where
the remote points to if you have push rights of course.
Of course all of this could be avoided if I knew that i have to be
explicit during cloning from my colleagues, because their HEAD may be
pointing to some BUTT, which I don't even want to know about;)
Thanks,
Eugene
^ permalink raw reply
* Feature suggestion: support arguments for GIT_PROXY_COMMAND & core.gitproxy
From: Joey Korkames @ 2009-12-18 23:39 UTC (permalink / raw)
To: git
Could /connect.c be patched to support multiple arguments in
ENV[GIT_PROXY_COMMAND] and git config core.gitproxy?
For instance, something like :
GIT_PROXY_COMMAND="myproxyscript arg1 arg2"
or (way more useful):
git config core.gitproxy \
'"myproxyscript -mode git -proxy joey@gw.myhouse.com -proxy joey@bastion.foocorp.com" for foocorp.com$'
Its slightly annoying to maintain and distribute custom copies of myproxyscript
that carry the repo-specific proxy arguments inline just because git won't
pass those arguments itself (arguments that a repo's .git/config can easily
store).
I think supporting tokens (ala ssh's ProxyCommand - %h=repohost,
%p=repoport, %u=repouser) would be awesome, but that change would not be
backward-compatible with existing .git/config files or GIT_PROXY_COMMAND
utilizing-scripts. Its enough to assume that "$host $port" will always be
appended to the gitproxy arg list.
Thanks for reading, (and thnaks for git!)
-joey
^ permalink raw reply
* git-svn mergeinfo support performance problem
From: Andrew Myrick @ 2009-12-19 1:08 UTC (permalink / raw)
To: git
I've been testing git-svn v1.6.6-rc3's mergeinfo support on a large
svn repository (60,000+ revisions, 20+ GiB) that uses a very
branch-heavy integration model in which every change gets its own
branch before being committed to trunk. As a result of the model,
there are currently over 1000 lines in the svn:mergeinfo property on
trunk. Unfortunately, with the current implementation, git svn fetch
takes more than a minute per revision pouring through all of those
merge tickets; obviously, this is too slow to be usable for my
repository.
Are there any ideas on how git svn fetch can be sped up when facing
hundreds of mergeinfo properties? Alternatively, would it be possible
to add an argument that would ignore the merge info? Or, is there any
maintenance I could perform on the svn repository that would help
reduce the amount of work that git-svn must do? In the meantime, I'll
have to stick with git 1.6.5.*.
Regards,
Andrew
P.S. This is my first post to the list. My apologies if this issue
has already been discussed and I did not see it in the archives, or if
I have missed a more formal mechanism for filing bug reports.
^ permalink raw reply
* Re: Feature suggestion: support arguments for GIT_PROXY_COMMAND & core.gitproxy
From: Joey Korkames @ 2009-12-19 0:58 UTC (permalink / raw)
To: git
In-Reply-To: <cone.1261179562.490491.4033.1000@toolshiner.phx1.kidfixit.com>
I forgot to mention that this all applies to ENV[GIT_SSH] as well, which
has no correspondgin git-config option, currently.
I see there's some hardcoding of Tortoise and PuTTY's plink
argument-handling in connect.c . I think a tokenable core.sshproxy option in
~/.gitconfig would be way less hinky, IMHO.
I just played with the man options in git config and I really liked how that
worked; maybe that's a good part of the codebase to copy-paste from? I'm no
C hacker, otherwise I'd be shutting up and sending a patch...
-joey
^ permalink raw reply
* [PATCH] Introduce the GIT_CONFIG_EXTRA environment variable
From: Miklos Vajna @ 2009-12-19 1:32 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Moe, git
In-Reply-To: <4B2C0828.4010505@signalbeam.net>
This is like GIT_CONFIG but it is not read instead of .git/config, but
in addtition to it.
Signed-off-by: Miklos Vajna <vmiklos@frugalware.org>
---
On Fri, Dec 18, 2009 at 11:54:32PM +0100, Moe <moe@signalbeam.net> wrote:
> $GIT_CONFIG doesn't work for this purpose because when set
> git will *only* read the referenced file and ignore the
> repository settings.
What about this?
Documentation/git-config.txt | 3 +++
builtin-config.c | 7 ++++++-
config.c | 9 ++++++++-
t/t1300-repo-config.sh | 16 ++++++++++++++++
4 files changed, 33 insertions(+), 2 deletions(-)
diff --git a/Documentation/git-config.txt b/Documentation/git-config.txt
index f68b198..668db3f 100644
--- a/Documentation/git-config.txt
+++ b/Documentation/git-config.txt
@@ -211,6 +211,9 @@ GIT_CONFIG::
Using the "--global" option forces this to ~/.gitconfig. Using the
"--system" option forces this to $(prefix)/etc/gitconfig.
+GIT_CONFIG_EXTRA::
+ Take the configuration from the given file in addition to .git/config.
+
See also <<FILES>>.
diff --git a/builtin-config.c b/builtin-config.c
index a2d656e..4a702f6 100644
--- a/builtin-config.c
+++ b/builtin-config.c
@@ -142,7 +142,7 @@ static int get_value(const char *key_, const char *regex_)
int ret = -1;
char *tl;
char *global = NULL, *repo_config = NULL;
- const char *system_wide = NULL, *local;
+ const char *system_wide = NULL, *local, *extra = NULL;
local = config_exclusive_filename;
if (!local) {
@@ -152,6 +152,7 @@ static int get_value(const char *key_, const char *regex_)
global = xstrdup(mkpath("%s/.gitconfig", home));
if (git_config_system())
system_wide = git_etc_gitconfig();
+ extra = getenv("GIT_CONFIG_EXTRA");
}
key = xstrdup(key_);
@@ -185,11 +186,15 @@ static int get_value(const char *key_, const char *regex_)
git_config_from_file(show_config, system_wide, NULL);
if (do_all && global)
git_config_from_file(show_config, global, NULL);
+ if (do_all && extra)
+ git_config_from_file(show_config, extra, NULL);
git_config_from_file(show_config, local, NULL);
if (!do_all && !seen && global)
git_config_from_file(show_config, global, NULL);
if (!do_all && !seen && system_wide)
git_config_from_file(show_config, system_wide, NULL);
+ if (!do_all && !seen && extra)
+ git_config_from_file(show_config, extra, NULL);
free(key);
if (regexp) {
diff --git a/config.c b/config.c
index 37385ce..cf816ed 100644
--- a/config.c
+++ b/config.c
@@ -700,7 +700,7 @@ int git_config(config_fn_t fn, void *data)
{
int ret = 0, found = 0;
char *repo_config = NULL;
- const char *home = NULL;
+ const char *home = NULL, *extra = NULL;
/* Setting $GIT_CONFIG makes git read _only_ the given config file. */
if (config_exclusive_filename)
@@ -727,6 +727,13 @@ int git_config(config_fn_t fn, void *data)
found += 1;
}
free(repo_config);
+
+ extra = getenv("GIT_CONFIG_EXTRA");
+ if (extra && !access(extra, R_OK)) {
+ ret += git_config_from_file(fn, extra, data);
+ found += 1;
+ }
+
if (found == 0)
return -1;
return ret;
diff --git a/t/t1300-repo-config.sh b/t/t1300-repo-config.sh
index 83b7294..ed7fcb6 100755
--- a/t/t1300-repo-config.sh
+++ b/t/t1300-repo-config.sh
@@ -398,6 +398,22 @@ test_expect_success 'alternative GIT_CONFIG' 'cmp output expect'
test_expect_success 'alternative GIT_CONFIG (--file)' \
'git config --file other-config -l > output && cmp output expect'
+cat > extra-config <<EOF
+[extra]
+ config = value
+EOF
+
+cat > expect << EOF
+c
+value
+EOF
+
+test_expect_success 'additional GIT_CONFIG_EXTRA' '
+ GIT_CONFIG_EXTRA=extra-config git config a.b > output &&
+ GIT_CONFIG_EXTRA=extra-config git config extra.config >> output &&
+ cmp output expect
+'
+
GIT_CONFIG=other-config git config anwohner.park ausweis
cat > expect << EOF
--
1.6.5.2
^ permalink raw reply related
* Re: [PATCH] Introduce the GIT_CONFIG_EXTRA environment variable
From: Shawn O. Pearce @ 2009-12-19 2:09 UTC (permalink / raw)
To: Miklos Vajna; +Cc: Junio C Hamano, Moe, git
In-Reply-To: <20091219013246.GD25474@genesis.frugalware.org>
Miklos Vajna <vmiklos@frugalware.org> wrote:
> This is like GIT_CONFIG but it is not read instead of .git/config, but
> in addtition to it.
What file does `git config --add` modify? Should we be able to
modify the GIT_CONFIG_EXTRA file?
What order is GIT_CONFIG_EXTRA applied in relative to other files
that git config would also have read?
--
Shawn.
^ permalink raw reply
* Re: [PATCHv2] am: fix patch format detection for Thunderbird "Save As" emails
From: Stephen Boyd @ 2009-12-19 2:24 UTC (permalink / raw)
To: Eric Blake; +Cc: git
In-Reply-To: <loom.20091218T234129-280@post.gmane.org>
On 12/18/2009 02:42 PM, Eric Blake wrote:
> Stephen Boyd<bebarino<at> gmail.com> writes:
>>> echo and \ do not portably mix. For that matter, shell double quotes and
>>> backslash escapes that are not required by POSIX do not portably mix.
>>
>> Thanks. Hopefully squashing this in will make it even more portable?
>>
>> + printf "X-Fake-Field: Line One\015\n"&&
>
> Nope. You need either "\\015\\n" or '\015\n', since "\015" and "\n" are both
> undefined in portable shell.
So, how about this?
{
echo "X-Fake-Field: Line One"&&
echo "X-Fake-Field: Line Two"&&
echo "X-Fake-Field: Line Three"&&
git format-patch --stdout first | sed -e "1d"
} | sed -e "s/$/;/" | tr "'";"'" "'"\015"'"> patch1-crlf.eml
Or maybe this?
{
echo "X-Fake-Field: Line One"&&
echo "X-Fake-Field: Line Two"&&
echo "X-Fake-Field: Line Three"&&
git format-patch --stdout first | sed -e "1d"
} | sed -e "s/$/;/" | tr ";" "\\015"> patch1-crlf.eml
^ permalink raw reply
* Re: [PATCH] Introduce the GIT_CONFIG_EXTRA environment variable
From: Moe @ 2009-12-19 3:06 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Miklos Vajna, Junio C Hamano, git
In-Reply-To: <20091219020947.GB10687@spearce.org>
Shawn O. Pearce wrote:
> Miklos Vajna <vmiklos@frugalware.org> wrote:
>> This is like GIT_CONFIG but it is not read instead of .git/config, but
>> in addtition to it.
>
> What file does `git config --add` modify? Should we be able to
> modify the GIT_CONFIG_EXTRA file?
>From my use-case corner: Yes, this would basically be used
to divert ~/.gitconfig and should behave in all the same ways.
> What order is GIT_CONFIG_EXTRA applied in relative to other files
> that git config would also have read?
This is up to Miklos to answer but again from my use-case angle it would
make the most sense to read the usual config files first
and GIT_CONFIG_EXTRA last - that way the user config gets the
last word in terms of overriding global and repository defaults.
And btw, thanks for the fast action Miklos!
Kind regards,
Moe
^ permalink raw reply
* Re: [PATCH] Introduce the GIT_CONFIG_EXTRA environment variable
From: Junio C Hamano @ 2009-12-19 3:24 UTC (permalink / raw)
To: Miklos Vajna; +Cc: Moe, git
In-Reply-To: <20091219013246.GD25474@genesis.frugalware.org>
Miklos Vajna <vmiklos@frugalware.org> writes:
> This is like GIT_CONFIG but it is not read instead of .git/config, but
> in addtition to it.
>
> Signed-off-by: Miklos Vajna <vmiklos@frugalware.org>
> ---
>
> On Fri, Dec 18, 2009 at 11:54:32PM +0100, Moe <moe@signalbeam.net> wrote:
>> $GIT_CONFIG doesn't work for this purpose because when set
>> git will *only* read the referenced file and ignore the
>> repository settings.
>
> What about this?
The patch text itself may be fine, in the sense that it makes "we read
from three" to "we now read from four", but I am not impressed.
I find the original use case highly moronic.
For people to be sharing an account, hence $HOME, there must be a reason.
They want to (rather, the administrator wants them to) use a common shared
set of settings, so $HOME/.gitconfig should be shared among them, just
like $HOME/.emacs and $HOME/.login are, unless there is some strong reason
to treat .gitconfig any differently from all the other $HOME/.whatever
files. But I don't think there wasn't any argument to defend that.
That makes the patch doubly suspect and throws it into "because we can",
not "because we should".
Wouldn't it be just a matter of giving different HOME after they log-in?
After all, Moe will be giving _some_ way to his users set different value
to GIT_CONFIG_EXTRA depending on who they really are, and that same
mechanism should be usable to set different HOME to them, no?
As $HOME/.gitconfig is relative to the value of that environment variable,
I don't see a reason for us to fall into this "three is not enough, but
when we add another, we are fine" attitude, which makes me suspect that
there is something fundamentally wrong there.
^ permalink raw reply
* Re: [PATCH 2/2] read-tree: at least one tree-ish argument is required
From: Nanako Shiraishi @ 2009-12-19 3:25 UTC (permalink / raw)
To: Junio C Hamano
Cc: Jakub Narebski, Johannes Sixt, Sverre Rabbelier, Git Mailing List
In-Reply-To: <7vr5qrsv4g.fsf@alter.siamese.dyndns.org>
Quoting Junio C Hamano <gitster@pobox.com>
> Come back with a proof that there has never existed any script that uses
> "read-tree" without arguments to purge the index, and I'd immediately
> accept and apply the patch to retroactively forbid what the implementation
> has allowed users to do for a long time.
For what it's worth, I compiled the very first version of git
commit e83c5163316f89bfbde7d9ab23ca2e25604af290
Author: Linus Torvalds <torvalds@ppc970.osdl.org>
Date: Thu Apr 7 15:13:13 2005 -0700
Initial revision of "git", the information manager from hell
and its read-tree fails with
read-tree: read-tree <key>
Is it a proof enough?
--
Nanako Shiraishi
http://ivory.ap.teacup.com/nanako3/
^ permalink raw reply
* Re: [PATCH] Introduce the GIT_CONFIG_EXTRA environment variable
From: Moe @ 2009-12-19 4:44 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Miklos Vajna, git
In-Reply-To: <7vhbrnodd9.fsf@alter.siamese.dyndns.org>
Junio C Hamano wrote:
> Miklos Vajna <vmiklos@frugalware.org> writes:
>
>> This is like GIT_CONFIG but it is not read instead of .git/config, but
>> in addtition to it.
>>
>> Signed-off-by: Miklos Vajna <vmiklos@frugalware.org>
>> ---
>>
>> On Fri, Dec 18, 2009 at 11:54:32PM +0100, Moe <moe@signalbeam.net> wrote:
>>> $GIT_CONFIG doesn't work for this purpose because when set
>>> git will *only* read the referenced file and ignore the
>>> repository settings.
>> What about this?
>
>
> The patch text itself may be fine, in the sense that it makes "we read
> from three" to "we now read from four", but I am not impressed.
>
> I find the original use case highly moronic.
>
> For people to be sharing an account, hence $HOME, there must be a reason.
> They want to (rather, the administrator wants them to) use a common shared
> set of settings, so $HOME/.gitconfig should be shared among them, just
> like $HOME/.emacs and $HOME/.login are, unless there is some strong reason
> to treat .gitconfig any differently from all the other $HOME/.whatever
> files. But I don't think there wasn't any argument to defend that.
I'm not arguing to treat .gitconfig differently from other
dot-files, but to treat it differently from .git/config.
The former is user-specific, the latter is repository-specific.
For a contrived analogy: Imagine apache would ignore the contents
of .htaccess files when you start httpd with the "-f" switch to
load a different configuration file.
> That makes the patch doubly suspect and throws it into "because we can",
> not "because we should".
>
> Wouldn't it be just a matter of giving different HOME after they log-in?
>
> After all, Moe will be giving _some_ way to his users set different value
> to GIT_CONFIG_EXTRA depending on who they really are, and that same
> mechanism should be usable to set different HOME to them, no?
The individual users are identified by their ssh key. Ssh sets a
distinct environment variable for each, which in turn is used in
.bash_profile to read an additional user-profile.
Yes, we could overwrite $HOME but that would defeat the purpose.
The goal of this setup is to share almost all settings.
Overwriting $HOME would turn this upside down. Instead of diverting
the two bits that we want to customize (git identity and editor
preferences) we would then have to duplicate all other dot-files
for each virtual user - and probably watch out for unforeseen side-effects.
> As $HOME/.gitconfig is relative to the value of that environment variable,
> I don't see a reason for us to fall into this "three is not enough, but
> when we add another, we are fine" attitude, which makes me suspect that
> there is something fundamentally wrong there.
I understand the sentiment.
Without drifting into a discussion about the merit of shared
unix-accounts (they do make a lot of sense in some scenarios)
I hope this can still make it, considering the small size of
the patch and the .git/config vs ~/.gitconfig argument.
--
Kind regards, Moe
^ permalink raw reply
* Re: [PATCH 2/2] read-tree: at least one tree-ish argument is required
From: Junio C Hamano @ 2009-12-19 4:43 UTC (permalink / raw)
To: Nanako Shiraishi
Cc: Jakub Narebski, Johannes Sixt, Sverre Rabbelier, Git Mailing List
In-Reply-To: <20091219122509.6117@nanako3.lavabit.com>
Nanako Shiraishi <nanako3@lavabit.com> writes:
> Quoting Junio C Hamano <gitster@pobox.com>
>
>> Come back with a proof that there has never existed any script that uses
>> "read-tree" without arguments to purge the index, and I'd immediately
>> accept and apply the patch to retroactively forbid what the implementation
>> has allowed users to do for a long time.
>
> For what it's worth, I compiled the very first version of git
>
> commit e83c5163316f89bfbde7d9ab23ca2e25604af290
> Author: Linus Torvalds <torvalds@ppc970.osdl.org>
> Date: Thu Apr 7 15:13:13 2005 -0700
>
> Initial revision of "git", the information manager from hell
>
> and its read-tree fails with
>
> read-tree: read-tree <key>
>
> Is it a proof enough?
Ok, that initial one was "read a single tree to populate the index".
I consider it a fundamentally different program from "read-tree" as we
know now, which was introduced by d99082e (Make "read-tree" merge the
trees it reads by giving them consecutive states., 2005-04-15). Ever
since that "multi-stage" version, read-tree was "starting from an empty
index, read these trees into stages #1, #2, ..." And even that version
called the program "read-tree", not "git read-tree". IOW, "git read-tree"
never had that "no tree is an error" restriction during its entire life.
Having said all that, I don't care that deeply either way myself.
As read-tree is a very basic and low-level Porcelain, if somebody were
using it to empty the index in an existing script, this change would
appear as a regression and hopefully will be caught eventually, and
updating such a script can be made reasonably easy if we want to be
helpful (the error message can suggest running "rm $GIT_DIR/index", for
example).
^ permalink raw reply
* Re: [PATCH 2/2] read-tree: at least one tree-ish argument is required
From: Junio C Hamano @ 2009-12-19 4:53 UTC (permalink / raw)
To: Nanako Shiraishi
Cc: Jakub Narebski, Johannes Sixt, Sverre Rabbelier, Git Mailing List
In-Reply-To: <7veimrmv3r.fsf@alter.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> As read-tree is a very basic and low-level Porcelain, if somebody were
> using it to empty the index in an existing script, this change would
> appear as a regression and hopefully will be caught eventually, and
> updating such a script can be made reasonably easy if we want to be
> helpful (the error message can suggest running "rm $GIT_DIR/index", for
> example).
IOW, I would prefer to queue something like this in the upcoming version,
and then later make it die(). I do not think anybody relies on it, but we
have been wrong before. If the warning doesn't trigger for anybody, that
is also fine as well.
builtin-read-tree.c | 3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/builtin-read-tree.c b/builtin-read-tree.c
index 2a3a32c..311c489 100644
--- a/builtin-read-tree.c
+++ b/builtin-read-tree.c
@@ -111,6 +111,9 @@ int cmd_read_tree(int argc, const char **argv, const char *unused_prefix)
argc = parse_options(argc, argv, unused_prefix, read_tree_options,
read_tree_usage, 0);
+ if (!argc)
+ warning("running read-tree without argument to empty the index is deprecated.");
+
newfd = hold_locked_index(&lock_file, 1);
prefix_set = opts.prefix ? 1 : 0;
^ permalink raw reply related
* Re: [PATCHv2] am: fix patch format detection for Thunderbird "Save As" emails
From: Eric Blake @ 2009-12-19 5:38 UTC (permalink / raw)
To: Stephen Boyd; +Cc: git
In-Reply-To: <4B2C395A.6080300@gmail.com>
According to Stephen Boyd on 12/18/2009 7:24 PM:
>> Nope. You need either "\\015\\n" or '\015\n', since "\015" and "\n"
>> are both
>> undefined in portable shell.
>
> So, how about this?
>
> {
> echo "X-Fake-Field: Line One"&&
> echo "X-Fake-Field: Line Two"&&
> echo "X-Fake-Field: Line Three"&&
> git format-patch --stdout first | sed -e "1d"
> } | sed -e "s/$/;/" | tr "'";"'" "'"\015"'"> patch1-crlf.eml
Syntax error. "$/" is not defined, so the argument to sed is not
portable. Then, following the tr, you have an unquoted ;, meaning you
invoked 'tr "'"', followed by invoking the (non-existent) command '.
>
> Or maybe this?
>
> {
> echo "X-Fake-Field: Line One"&&
> echo "X-Fake-Field: Line Two"&&
> echo "X-Fake-Field: Line Three"&&
> git format-patch --stdout first | sed -e "1d"
> } | sed -e "s/$/;/" | tr ";" "\\015"> patch1-crlf.eml
Closer, but not there yet. "$/" is still not defined. Then, as a matter
of style, '\' is more readable than "\\" for representing a backslash. So
as long as we are shifting to '', we might as well do it everywhere in
that line - write it like this:
} | sed -e 's/$/;/' | tr ';' '\015' > patch1-crlf.eml
and you should be set.
--
Don't work too hard, make some time for fun as well!
Eric Blake ebb9@byu.net
^ permalink raw reply
* Re: [PATCH] Introduce the GIT_CONFIG_EXTRA environment variable
From: Junio C Hamano @ 2009-12-19 5:55 UTC (permalink / raw)
To: Moe; +Cc: Miklos Vajna, git
In-Reply-To: <4B2C5A1A.8000201@signalbeam.net>
Moe <moe@signalbeam.net> writes:
>> I find the original use case highly moronic.
>>
>> For people to be sharing an account, hence $HOME, there must be a reason.
>> They want to (rather, the administrator wants them to) use a common shared
>> set of settings, so $HOME/.gitconfig should be shared among them, just
>> like $HOME/.emacs and $HOME/.login are, unless there is some strong reason
>> to treat .gitconfig any differently from all the other $HOME/.whatever
>> files. But I don't think there wasn't any argument to defend that.
>
> I'm not arguing to treat .gitconfig differently from other
> dot-files, but to treat it differently from .git/config.
>
> The former is user-specific, the latter is repository-specific.
That is something we already do, like everybody else. $HOME/.emacs is
user specific, /etc/emacs.d/* are site-wide, and "Local Variables:..End:"
section is per-document. Have you asked emacs guys (and vim folks) about
a change similar to the one on topic here? This question is rhetoric and
you do not have to answer it.
>> Wouldn't it be just a matter of giving different HOME after they log-in?
>>
>> After all, Moe will be giving _some_ way to his users set different value
>> to GIT_CONFIG_EXTRA depending on who they really are, and that same
>> mechanism should be usable to set different HOME to them, no?
>
> The individual users are identified by their ssh key. Ssh sets a
> distinct environment variable for each, which in turn is used in
> .bash_profile to read an additional user-profile.
>
> Yes, we could overwrite $HOME but that would defeat the purpose.
> The goal of this setup is to share almost all settings.
You haven't answered the crucial question, and repeating yourself is not
an explanation. I've already said sharing the account is to share things,
you know I understand you want to _share_. I asked why $HOME/.gitconfig
has to be treated differently from others like $HOME/.mailrc, $HOME/.gitk,
etc. that are shared. You are not answering the question.
What makes $HOME/.gitconfig different from $HOME/.ssh/., $HOME/.vimrc, and
all the other things? Why do you want to share all the other dot files,
most of which lack the support for you to do the "set-up" you have to do
in $HOME/.bashrc to switch based on something other than the UID (I would
call that a "set-up", not a "hack", because you have to do that
somewhere)? Why do your users tolerate that they cannot have their own
private $HOME/.rpmmacros nor $HOME/.newsrc but it is not Ok that they have
to share $HOME/.gitconfig with others?
Knowing that is very important for us, as $HOME/.gitconfig will not stay
the only thing you would need to single out with future versions of git.
For example, we have discussed a support for $HOME/.git-excludes that sits
between $GIT_DIR/info/exclude and the file pointed at by core.excludesfile
configuration variable. Should it be shared, or separated? Why?
I do not want to count on you, who I have never seen on this list before,
being around to ask if such a change would break your use case when the
day comes. If we do not know the _criteria_ you are using, the reason why
you want to single out $HOME/.gitconfig when it is Ok for your users to
share $HOME/.vimrc, we will not be able to make good design decisions to
support this "shared account" configuration [*1*]. Will we introduce
GIT_EXCLUDE_EXTRA at the time like Miklos added GIT_CONFIG_EXTRA? Where
does it end?
> I hope this can still make it, considering the small size of
> the patch and the .git/config vs ~/.gitconfig argument.
That is not an argument at all. We handle .git/config vs $HOME/.gitconfig
just fine; see above.
One plausible answer you could have given is that your users do not have
an account in the usual sense of the word at all, and the _only_ thing
they can do with your system is to run git and nothing else. IOW they
have no business with even having $HOME/.vimrc or $HOME/.rhosts, so these
other dotfiles do not matter at all. That makes $HOME/.gitconfig special.
A possible solution might be for us to honor $GIT_HOME that is favoured
over $HOME, just like $GIT_EDITOR overrides $EDITOR. That allows us to
extend the notion more naturally in the future. For example, when we
start reading from $HOME/.git-excludes, if the GIT_HOME environment is
set, we would instead read from $GIT_HOME/.git-excludes. That would be a
much cleaner solution than Miklos's patch [*2*].
But you have given us too little for us to be able to judge what the best
longer-term course of action is. How could you even _hope_ it can "make
it"?
[Footnote]
*1* Of course, before doing so, we need to decide if this "shared account"
configuration makes sense or not to begin with, but you haven't given us
enough to work with to even decide that.
*2* I am not criticizing Miklos's patch in particular. The patch was done
in the same void without any usable information from you what you really
needed, so the lack of provision for future we can see in the patch is not
Miklos's fault. Also he is not the git maintainer and is not used to
worry about the future like I do.
^ permalink raw reply
* Re: [PATCHv2] am: fix patch format detection for Thunderbird "Save As" emails
From: Stephen Boyd @ 2009-12-19 6:21 UTC (permalink / raw)
To: Eric Blake; +Cc: git
In-Reply-To: <4B2C66D3.1070508@byu.net>
On 12/18/2009 09:38 PM, Eric Blake wrote:
> Closer, but not there yet. "$/" is still not defined. Then, as a matter
> of style, '\' is more readable than "\\" for representing a backslash. So
> as long as we are shifting to '', we might as well do it everywhere in
> that line - write it like this:
>
> } | sed -e 's/$/;/' | tr ';' '\015'> patch1-crlf.eml
>
> and you should be set.
Ah, I think you missed that this stuff is inside single quotes already.
I would love to just do what you suggest here.
I'm a little confused because I see this in a test (am
--committer-date-is-author-date) a ways down in the same file
git cat-file commit HEAD | sed -e "/^$/q">head1&&
and following your reasoning that wouldn't be portable?
Either way, I'll look for a better replacement character instead of
semi-colon.
^ permalink raw reply
* Re: [PATCHv2] am: fix patch format detection for Thunderbird "Save As" emails
From: Stephen Boyd @ 2009-12-19 7:07 UTC (permalink / raw)
To: Eric Blake; +Cc: git
In-Reply-To: <4B2C70ED.1020602@gmail.com>
I found this in t0022
sed -e "s/\$/
^M/" "$TEST_DIRECTORY"/t0022-crlf-rename.sh>elpmas&&
so I'd like to use that if possible.
^ permalink raw reply
* Re: [PATCH] Introduce the GIT_CONFIG_EXTRA environment variable
From: Moe @ 2009-12-19 7:20 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Miklos Vajna, git
In-Reply-To: <7vzl5fik3o.fsf@alter.siamese.dyndns.org>
Junio C Hamano wrote:
> Moe <moe@signalbeam.net> writes:
>
>>> I find the original use case highly moronic.
>>>
>>> For people to be sharing an account, hence $HOME, there must be a reason.
>>> They want to (rather, the administrator wants them to) use a common shared
>>> set of settings, so $HOME/.gitconfig should be shared among them, just
>>> like $HOME/.emacs and $HOME/.login are, unless there is some strong reason
>>> to treat .gitconfig any differently from all the other $HOME/.whatever
>>> files. But I don't think there wasn't any argument to defend that.
>> I'm not arguing to treat .gitconfig differently from other
>> dot-files, but to treat it differently from .git/config.
>>
>> The former is user-specific, the latter is repository-specific.
>
> That is something we already do, like everybody else. $HOME/.emacs is
> user specific, /etc/emacs.d/* are site-wide, and "Local Variables:..End:"
> section is per-document. Have you asked emacs guys (and vim folks) about
> a change similar to the one on topic here? This question is rhetoric and
> you do not have to answer it.
>
>>> Wouldn't it be just a matter of giving different HOME after they log-in?
>>>
>>> After all, Moe will be giving _some_ way to his users set different value
>>> to GIT_CONFIG_EXTRA depending on who they really are, and that same
>>> mechanism should be usable to set different HOME to them, no?
>> The individual users are identified by their ssh key. Ssh sets a
>> distinct environment variable for each, which in turn is used in
>> .bash_profile to read an additional user-profile.
>>
>> Yes, we could overwrite $HOME but that would defeat the purpose.
>> The goal of this setup is to share almost all settings.
>
> You haven't answered the crucial question, and repeating yourself is not
> an explanation. I've already said sharing the account is to share things,
> you know I understand you want to _share_. I asked why $HOME/.gitconfig
> has to be treated differently from others like $HOME/.mailrc, $HOME/.gitk,
> etc. that are shared. You are not answering the question.
I refrained from delving deeper into our particular use-case at first,
due to the verbosity and to avoid a potential "git wasn't meant for
this" knockout. But it seems we're over this, so see below.
> What makes $HOME/.gitconfig different from $HOME/.ssh/., $HOME/.vimrc, and
> all the other things? Why do you want to share all the other dot files,
> most of which lack the support for you to do the "set-up" you have to do
> in $HOME/.bashrc to switch based on something other than the UID (I would
> call that a "set-up", not a "hack", because you have to do that
> somewhere)? Why do your users tolerate that they cannot have their own
> private $HOME/.rpmmacros nor $HOME/.newsrc but it is not Ok that they have
> to share $HOME/.gitconfig with others?
>
> Knowing that is very important for us, as $HOME/.gitconfig will not stay
> the only thing you would need to single out with future versions of git.
>
> For example, we have discussed a support for $HOME/.git-excludes that sits
> between $GIT_DIR/info/exclude and the file pointed at by core.excludesfile
> configuration variable. Should it be shared, or separated? Why?
>
> I do not want to count on you, who I have never seen on this list before,
> being around to ask if such a change would break your use case when the
> day comes. If we do not know the _criteria_ you are using, the reason why
> you want to single out $HOME/.gitconfig when it is Ok for your users to
> share $HOME/.vimrc, we will not be able to make good design decisions to
> support this "shared account" configuration [*1*]. Will we introduce
> GIT_EXCLUDE_EXTRA at the time like Miklos added GIT_CONFIG_EXTRA? Where
> does it end?
>
>> I hope this can still make it, considering the small size of
>> the patch and the .git/config vs ~/.gitconfig argument.
>
> That is not an argument at all. We handle .git/config vs $HOME/.gitconfig
> just fine; see above.
>
> One plausible answer you could have given is that your users do not have
> an account in the usual sense of the word at all, and the _only_ thing
> they can do with your system is to run git and nothing else. IOW they
> have no business with even having $HOME/.vimrc or $HOME/.rhosts, so these
> other dotfiles do not matter at all. That makes $HOME/.gitconfig special.
Yes, that's pretty close. What we do is, we put our entire runtime
environment [for a web application] under a dedicated user and under
version control. This is a very comfortable way to maintain an
identical environment across the board, we even deploy this way
to our production servers by the means of a git pull on a
dedicated branch.
In practice our developers will su or ssh to this user to get working
and generally they need only a very small set of divertions from the
common configuration - such as their personal git identity and their
preferred editor settings.
One may argue that a bunch of host-specific symlinks could achieve a
similar effect - and that would be correct - but having literally
everything under version control yields certain advantages that we
wouldn't want to miss. Such as any developer being able to ssh into
the shared user on any host and being right at home (including
properly attributed git commits) without further twiddling.
(that usually comes into play when ssh'ing into a production host,
performing a hotfix and feeding it back)
This all may seem esoteric or even moronic to you. All I can say is
that it's been working extraordinary well for us over the past 2 years,
despite the minor git inconvenience.
> A possible solution might be for us to honor $GIT_HOME that is favoured
> over $HOME, just like $GIT_EDITOR overrides $EDITOR. That allows us to
> extend the notion more naturally in the future. For example, when we
> start reading from $HOME/.git-excludes, if the GIT_HOME environment is
> set, we would instead read from $GIT_HOME/.git-excludes. That would be a
> much cleaner solution than Miklos's patch [*2*].
Sounds like that would serve our case just as well
and yes, probably much cleaner in the long run.
> But you have given us too little for us to be able to judge what the best
> longer-term course of action is. How could you even _hope_ it can "make
> it"?
Well, sorry for being so brief initially. Being not as involved with git
development I based my request on what I figured could be a
sane generalization of our particular problem.
Also I don't mean to blow this out of proportion; it's a minor,
mostly cosmetic inconvenience for us and we can stick to our workarounds
or Miklos' patch if a mainline change shakes
things up too much.
^ permalink raw reply
* Re: [PATCHv2] am: fix patch format detection for Thunderbird "Save As" emails
From: Junio C Hamano @ 2009-12-19 7:39 UTC (permalink / raw)
To: Stephen Boyd; +Cc: Eric Blake, git
In-Reply-To: <4B2C7B9C.1030404@gmail.com>
Stephen Boyd <bebarino@gmail.com> writes:
> I found this in t0022
>
> sed -e "s/\$/
> ^M/" "$TEST_DIRECTORY"/t0022-crlf-rename.sh>elpmas&&
>
> so I'd like to use that if possible.
That needs fixing; I think we caught something similar from Shawn before
it got in, primarily because the mail path corrupted the message and
turned the literal CR into LF.
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox