* Re: [PATCH 2/2] read-tree: at least one tree-ish argument is required
From: Sverre Rabbelier @ 2009-12-18 19:37 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Johannes Sixt, Git Mailing List
In-Reply-To: <7voclwxemf.fsf@alter.siamese.dyndns.org>
Heya,
On Fri, Dec 18, 2009 at 13:32, Junio C Hamano <gitster@pobox.com> wrote:
> Sure, it will empty the index, so it is dangerous in the same sense that
> "reset --hard" is dangerous because it will wipe all your local changes,
> or "rm -rf it" will remove everything underneath it.
With the difference that both 'reset --hard' and 'rm -rf' need a flag
to do their destructive work? Although 'git reset' might be just as
destructive if you've been using 'git add -p' a lot or something,
mhh...
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* Re: [PATCH 2/2] read-tree: at least one tree-ish argument is required
From: Junio C Hamano @ 2009-12-18 19:49 UTC (permalink / raw)
To: Sverre Rabbelier; +Cc: Johannes Sixt, Git Mailing List
In-Reply-To: <fabb9a1e0912181137t1265f86cs9e02019da136a0a@mail.gmail.com>
Sverre Rabbelier <srabbelier@gmail.com> writes:
> On Fri, Dec 18, 2009 at 13:32, Junio C Hamano <gitster@pobox.com> wrote:
>> Sure, it will empty the index, so it is dangerous in the same sense that
>> "reset --hard" is dangerous because it will wipe all your local changes,
>> or "rm -rf it" will remove everything underneath it.
>
> With the difference that both 'reset --hard' and 'rm -rf' need a flag
> to do their destructive work? Although 'git reset' might be just as
> destructive if you've been using 'git add -p' a lot or something,
> mhh...
I'll grant you that at least "rm -rf it" names "it" that will be wiped
very explicitly. But just like the index and the work tree plus the index
are the implicit targets to "reset" and "reset --hard" respectively, the
index is the implicit target to "read-tree".
So it may be "dangerous" in the sense that "it would change things and if
you meant to do something else the end result would be different from what
you wanted to do". In that sense, "log", "cat-file" and friends may be
danger-free commands and all others would be dangerous. You might type
"commit" when you meant to say "commit -a" and record an incomplete state;
it is "dangerous" in that sense.
These are part of their feature.
^ permalink raw reply
* Re: [PATCH 2/2] read-tree: at least one tree-ish argument is required
From: Sverre Rabbelier @ 2009-12-18 19:59 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Johannes Sixt, Git Mailing List
In-Reply-To: <7veimsvz8a.fsf@alter.siamese.dyndns.org>
Heya,
On Fri, Dec 18, 2009 at 13:49, Junio C Hamano <gitster@pobox.com> wrote:
> You might type
> "commit" when you meant to say "commit -a" and record an incomplete state;
> it is "dangerous" in that sense.
Speaking of which, it has hit me multiple times that I craft out a
commit with 'git add -p' and then do "git commit -am 'foo some bars'"
and lose all my hard work (because I'm used to typing 'git commit -am'
for temporary commits). I'd be happy if "git commit -am" learned to
second-guess me when I already have something in the index.
> These are part of their feature.
Fair enough, then perhaps it is time for "core.nodataloss" which
either logs states to a seperate reflog (so that you can go back to
the state you were in before doing 'git read-tree') or interactively
informs the user that this will command will result in data loss
(although that sounds a tad too much like Window's "Are you sure?"
dialogs).
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* Re: [PATCH 2/2] read-tree: at least one tree-ish argument is required
From: Junio C Hamano @ 2009-12-18 20:13 UTC (permalink / raw)
To: Sverre Rabbelier; +Cc: Johannes Sixt, Git Mailing List
In-Reply-To: <fabb9a1e0912181159u65ae9c6fg1481ab744575475f@mail.gmail.com>
Sverre Rabbelier <srabbelier@gmail.com> writes:
> On Fri, Dec 18, 2009 at 13:49, Junio C Hamano <gitster@pobox.com> wrote:
>> You might type
>> "commit" when you meant to say "commit -a" and record an incomplete state;
>> it is "dangerous" in that sense.
>
> Speaking of which, it has hit me multiple times that I craft out a
> commit with 'git add -p' and then do "git commit -am 'foo some bars'"
> and lose all my hard work (because I'm used to typing 'git commit -am'
> for temporary commits). I'd be happy if "git commit -am" learned to
> second-guess me when I already have something in the index.
Sounds like "commit.confirm = xxx" configuration patches are coming? What
other questionable operations we might want to let users configure git to
ask for confirmation?
> Fair enough, then perhaps it is time for "core.nodataloss" which
> either logs states to a seperate reflog (so that you can go back to
> the state you were in before doing 'git read-tree') or interactively
> informs the user that this will command will result in data loss
> (although that sounds a tad too much like Window's "Are you sure?"
> dialogs).
I somehow suspect that you had your morning coffee yet ;-) Aren't we
talking about the index, and why are you bringing up the reflog?
More importantly, if you accept that there are non-interrogator commands
in the git command set, I somehow suspect that you will soon realize that
"git config core.nodataloss true" is equivalent to "chmod a-w -R .". It
might be useful mode of non-operation (read-only historical archive) but I
do not think it deserves a configuration of its own with checks in the
code all over the place that might possibly change any states of the
repository.
"git config user.novice true" to increase the verbosity and degree of
hand-holding is an entirely different matter, but if that is what you are
advocating, you shouldn't call it "core.nodataloss".
^ permalink raw reply
* Re: [PATCH 2/2] read-tree: at least one tree-ish argument is required
From: Sverre Rabbelier @ 2009-12-18 20:21 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Johannes Sixt, Git Mailing List
In-Reply-To: <7vy6l0ujkx.fsf@alter.siamese.dyndns.org>
Heya,
On Fri, Dec 18, 2009 at 14:13, Junio C Hamano <gitster@pobox.com> wrote:
> Sounds like "commit.confirm = xxx" configuration patches are coming?
Not a bad idea.
> What
> other questionable operations we might want to let users configure git to
> ask for confirmation?
I don't see any other of the above category, that is, the category of
operations that contain 'git commit -a' with a non-empty index, and
'git rm' on a modified file (which we already prevent). But see below.
> I somehow suspect that you haven't had your morning coffee yet ;-)
> Aren't we talking about the index, and why are you bringing up the reflog?
It was a topic hijack of sorts, we were talking about data loss. I
brought up the reflog since I think that was mentioned before when we
discussed ways to prevent data loss (e.g., create a commit of the
current state when doing 'git reset --hard' and record it in such a
reflog).
> More importantly, if you accept that there are non-interrogator commands
> in the git command set, I somehow suspect that you will soon realize that
> "git config core.nodataloss true" is equivalent to "chmod a-w -R .".
I don't think that's quite right, since you don't lose any data if you
do only additive commands (e.g., create new commits, etc).
> might be useful mode of non-operation (read-only historical archive) but I
> do not think it deserves a configuration of its own with checks in the
> code all over the place that might possibly change any states of the
> repository.
That is not quite what I intended with 'core.preventdataloss' (which I
agree is a bad name for what I intend with it). I meant for a
configuration option which insures that all non-interrogation commands
make sure that what they throw away is recoverable (for example
through the reflog).
> "git config user.novice true" to increase the verbosity and degree of
> hand-holding is an entirely different matter, but if that is what you are
> advocating, you shouldn't call it "core.nodataloss".
I'm not sure I'd call it "user.novice", since I don't consider myself
a novice user, and I would definitely like to be able to recover data
that I accidentally deleted with 'git reset --hard'.
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* [PATCHv2 3/6] gitweb: Optionally add "git" links in project list page
From: Jakub Narebski @ 2009-12-18 21:02 UTC (permalink / raw)
To: git
Cc: John 'Warthog9' Hawley, John 'Warthog9' Hawley,
Jakub Narebski
In-Reply-To: <m3tyvxd3pr.fsf@localhost.localdomain>
From: John 'Warthog9' Hawley <warthog9@kernel.org>
This adds a "git" link for each project in the project list page,
should a common $gitlinkurl_base be defined and not empty. The full
URL of each link is composed of $gitlinkurl_base and project name.
It is intended for git:// links, and in fact GITWEB_BASE_URL build
variable is used as its default value only if it starts with git://
This does make the assumption that the git repositories share a common
path. Nothing to date is known to actually make use of introduced
link.
Created "git" link follows rel=vcs-* microformat specification:
http://kitenet.net/~joey/rfc/rel-vcs/
Signed-off-by: John 'Warthog9' Hawley <warthog9@kernel.org>
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
---
I think it might be good idea... but for the fact "Nothing to date is
known to actually make use of introduced link". What's its intended
use?
Differences to original version by John 'Warthog9' Hawley (J.H.):
* It doesn't cause syntax error ;-)
* Escaping of attribute value is left to CGI.pm
* $gitlinkurl got renamed to $gitlinkurl_base, now includes git://
prefix, and defaults to GITWEB_BASE_URL if it begins with git://
* Added description to gitweb/README
* Uses rel=vcs-* microformat by Joey Hess
I assume that nobody sane would define $gitlinkurl_base to "0"...
gitweb/README | 4 ++++
gitweb/gitweb.perl | 8 ++++++++
2 files changed, 12 insertions(+), 0 deletions(-)
diff --git a/gitweb/README b/gitweb/README
index 608b0f8..36fb059 100644
--- a/gitweb/README
+++ b/gitweb/README
@@ -71,6 +71,7 @@ You can specify the following configuration variables when building GIT:
* GITWEB_BASE_URL
Git base URLs used for URL to where fetch project from, i.e. full
URL is "$git_base_url/$project". Shown on projects summary page.
+ If it begins with "git://" it is also used for $gitlinkurl_base, see below.
Repository URL for project can be also configured per repository; this
takes precedence over URLs composed from base URL and a project name.
Note that you can setup multiple base URLs (for example one for
@@ -204,6 +205,9 @@ not include variables usually directly set during build):
access, and one for http:// "dumb" protocol access). Note that per
repository configuration in 'cloneurl' file, or as values of gitweb.url
project config.
+ * $gitlinkurl_base
+ Git base URL used (if it is defined and not empty) for "git" link in
+ projects list, for each project. Full URL is "$gitlinkurl_base/$project".
* $default_blob_plain_mimetype
Default mimetype for blob_plain (raw) view, if mimetype checking
doesn't result in some other type; by default 'text/plain'.
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index b9bd865..efb6471 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -224,6 +224,10 @@ our %avatar_size = (
# If it is true, exit if gitweb version and git binary version don't match
our $git_versions_must_match = 0;
+# If this variable is set and not empty, add an extra link called "git"
+# for each project in project list. Full URL is "$gitlinkurl_base/$project".
+our $gitlinkurl_base = ("++GITWEB_BASE_URL++" =~ m!^(git://.*)$!) ? $1 : '';
+
# Used to set the maximum load that we will still respond to gitweb queries.
# If server load exceed this value then return "503 server busy" error.
# If gitweb cannot determined server load, it is taken to be 0.
@@ -4472,6 +4476,10 @@ sub git_project_list_body {
$cgi->a({-href => href(project=>$pr->{'path'}, action=>"log")}, "log") . " | " .
$cgi->a({-href => href(project=>$pr->{'path'}, action=>"tree")}, "tree") .
($pr->{'forks'} ? " | " . $cgi->a({-href => href(project=>$pr->{'path'}, action=>"forks")}, "forks") : '') .
+ ($gitlinkurl_base ?
+ " | " . $cgi->a({-href=>"$gitlinkurl_base/$pr->{'path'}",
+ -rel=>"vcs-git"}, "git")
+ : '') .
"</td>\n" .
"</tr>\n";
}
--
1.6.5.3
^ permalink raw reply related
* Re: git remote set-head not working?
From: Jay Soffian @ 2009-12-18 21:28 UTC (permalink / raw)
To: Eugene Sajine; +Cc: Jeff King, git
In-Reply-To: <76c5b8580912180938s2b885efax33be860f963ba92f@mail.gmail.com>
On Fri, Dec 18, 2009 at 12:38 PM, Eugene Sajine <euguess@gmail.com> wrote:
> Yes. I was trying to change the HEAD on the bare remote (origin) repo
> and the concept here is really confusing.
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?
> Firstly, when i cloned from some repo "clone" comand is setting HEAD
> branch for remote in accordance to where the HEAD is pointing on
> origin side. I just recently realized that and i'm not sure it is best
> thing to do - i think it should default to origin/master first, if it
> doesn't exist then to where the HEAD is pointing.
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 ...
And you'll get master checked out instead of whatever the remote HEAD is.
> 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"
updates the remote server I can see some confusion. Perhaps the
DESCRIPTION for git remote should include something like:
"This command updates the local repository only. For updating a remote
repository, see git push."
> I might not
> have access to the server to perform git symbolic-ref on my bare repo
> (imagine the repo on github), so it might be not an option.
Understood. I'm not sure whether the send-pack/receive-pack protocol
supports the notion of "I want to change what HEAD points to."
j.
^ permalink raw reply
* [PATCHv2] am: fix patch format detection for Thunderbird "Save As" emails
From: Stephen Boyd @ 2009-12-18 21:34 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano
In-Reply-To: <7vtyvpcf36.fsf@alter.siamese.dyndns.org>
The patch detection wants to inspect all the headers of a rfc2822 message
and ensure that they look like header field names. The headers are always
separated from the message body with a blank line. When Thunderbird saves
the message the blank line separating the headers from the body includes a
CR. The patch detection is failing because a CRLF doesn't match /^$/. Fix
this by allowing a CR to exist on the separating line.
Signed-off-by: Stephen Boyd <bebarino@gmail.com>
---
Changes since v1:
- More portable code using tr (thanks Junio)
- More portable testing by manually adding CRLFs
git-am.sh | 3 ++-
t/t4150-am.sh | 24 ++++++++++++++++++++++++
2 files changed, 26 insertions(+), 1 deletions(-)
diff --git a/git-am.sh b/git-am.sh
index 4838cdb..9e64deb 100755
--- a/git-am.sh
+++ b/git-am.sh
@@ -204,7 +204,8 @@ check_patch_format () {
# discarding the indented remainder of folded lines,
# and see if it looks like that they all begin with the
# header field names...
- sed -n -e '/^$/q' -e '/^[ ]/d' -e p "$1" |
+ tr -d '\015' <"$1" |
+ sed -n -e '/^$/q' -e '/^[ ]/d' -e p |
sane_egrep -v '^[!-9;-~]+:' >/dev/null ||
patch_format=mbox
fi
diff --git a/t/t4150-am.sh b/t/t4150-am.sh
index 8296605..7b6269d 100755
--- a/t/t4150-am.sh
+++ b/t/t4150-am.sh
@@ -83,6 +83,21 @@ test_expect_success setup '
echo "X-Fake-Field: Line Three" &&
git format-patch --stdout first | sed -e "1d"
} > patch1.eml &&
+ {
+ echo "X-Fake-Field: Line One\015" &&
+ echo "X-Fake-Field: Line Two\015" &&
+ echo "X-Fake-Field: Line Three\015" &&
+ git format-patch --stdout first |
+ sed -e "1d" -e "3,\$d" | tr -d "\n" &&
+ echo "\015" &&
+ git format-patch --stdout first |
+ sed -e "1,2d" -e "4,\$d" | tr -d "\n" &&
+ echo "\015" &&
+ git format-patch --stdout first |
+ sed -e "1,3d" -e "5,\$d" | tr -d "\n" &&
+ echo "\015\n\015" &&
+ git format-patch --stdout first | sed -e "1,5d"
+ } > patch1-crlf.eml &&
sed -n -e "3,\$p" msg >file &&
git add file &&
test_tick &&
@@ -123,6 +138,15 @@ test_expect_success 'am applies patch e-mail not in a mbox' '
test "$(git rev-parse second^)" = "$(git rev-parse HEAD^)"
'
+test_expect_success 'am applies patch e-mail not in a mbox with CRLF' '
+ git checkout first &&
+ git am patch1-crlf.eml &&
+ ! test -d .git/rebase-apply &&
+ test -z "$(git diff second)" &&
+ test "$(git rev-parse second)" = "$(git rev-parse HEAD)" &&
+ test "$(git rev-parse second^)" = "$(git rev-parse HEAD^)"
+'
+
GIT_AUTHOR_NAME="Another Thor"
GIT_AUTHOR_EMAIL="a.thor@example.com"
GIT_COMMITTER_NAME="Co M Miter"
--
1.6.6.rc3.1.g8df51
^ permalink raw reply related
* Re: git remote set-head not working?
From: Junio C Hamano @ 2009-12-18 21:42 UTC (permalink / raw)
To: Jay Soffian; +Cc: Eugene Sajine, Jeff King, git
In-Reply-To: <76718490912181328k5f87d82u499b7a1eba471126@mail.gmail.com>
Jay Soffian <jaysoffian@gmail.com> writes:
> On Fri, Dec 18, 2009 at 12:38 PM, Eugene Sajine <euguess@gmail.com> wrote:
>> Yes. I was trying to change the HEAD on the bare remote (origin) repo
>> and the concept here is really confusing.
>
> 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.
> 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.
^ permalink raw reply
* Re: [PATCHv2] am: fix patch format detection for Thunderbird "Save As" emails
From: Eric Blake @ 2009-12-18 21:42 UTC (permalink / raw)
To: git
In-Reply-To: <1261172078-9174-1-git-send-email-bebarino@gmail.com>
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'
--
Eric Blake
^ permalink raw reply
* Re: [PATCHv2] am: fix patch format detection for Thunderbird "Save As" emails
From: Stephen Boyd @ 2009-12-18 21:59 UTC (permalink / raw)
To: Eric Blake; +Cc: git, Junio C Hamano
In-Reply-To: <loom.20091218T223918-175@post.gmane.org>
On Fri, 2009-12-18 at 21:42 +0000, Eric Blake wrote:
> 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. Hopefully squashing this in will make it even more portable?
--->8---
diff --git a/t/t4150-am.sh b/t/t4150-am.sh
index 7b6269d..19d5ca1 100755
--- a/t/t4150-am.sh
+++ b/t/t4150-am.sh
@@ -84,18 +84,18 @@ test_expect_success setup '
git format-patch --stdout first | sed -e "1d"
} > patch1.eml &&
{
- echo "X-Fake-Field: Line One\015" &&
- echo "X-Fake-Field: Line Two\015" &&
- echo "X-Fake-Field: Line Three\015" &&
+ printf "X-Fake-Field: Line One\015\n" &&
+ printf "X-Fake-Field: Line Two\015\n" &&
+ printf "X-Fake-Field: Line Three\015\n" &&
git format-patch --stdout first |
sed -e "1d" -e "3,\$d" | tr -d "\n" &&
- echo "\015" &&
+ printf "\015\n" &&
git format-patch --stdout first |
sed -e "1,2d" -e "4,\$d" | tr -d "\n" &&
- echo "\015" &&
+ printf "\015\n" &&
git format-patch --stdout first |
sed -e "1,3d" -e "5,\$d" | tr -d "\n" &&
- echo "\015\n\015" &&
+ printf "\015\n\015\n" &&
git format-patch --stdout first | sed -e "1,5d"
} > patch1-crlf.eml &&
sed -n -e "3,\$p" msg >file &&
^ permalink raw reply related
* Re: [PATCH 2/2] read-tree: at least one tree-ish argument is required
From: Johannes Sixt @ 2009-12-18 22:04 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Sverre Rabbelier, Git Mailing List
In-Reply-To: <7veimsvz8a.fsf@alter.siamese.dyndns.org>
On Freitag, 18. Dezember 2009, Junio C Hamano wrote:
> I'll grant you that at least "rm -rf it" names "it" that will be wiped
> very explicitly. But just like the index and the work tree plus the index
> are the implicit targets to "reset" and "reset --hard" respectively, the
> index is the implicit target to "read-tree".
>
> [...] You might type
> "commit" when you meant to say "commit -a" and record an incomplete state;
> it is "dangerous" in that sense.
>
> These are part of their feature.
Really? "rm -rf", "reset --hard", "commit -a": yes, RTFM. But "read-tree" (w/o
arguments): no. There is no such sign in the documentation. Since the
operation of the latter is dubious at best, I'd rather change the program
than the documentation.
How about this commit message, then?
Subject: [PATCH] read-tree: at least one tree-ish argument is required
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.
Signed-off-by: Johannes Sixt <j6t@kdbg.org>
^ permalink raw reply
* 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
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