* 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: [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: [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: [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: 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
* [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: 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 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: [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
* 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 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 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: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:32 UTC (permalink / raw)
To: Johannes Sixt; +Cc: Git Mailing List
In-Reply-To: <200912182004.25520.j.sixt@viscovery.net>
Johannes Sixt <j.sixt@viscovery.net> writes:
> Sorry to drag you into this discussion, but I felt this change is
> maint-worthy (because the behavior is not only risky, but dangerous).
>
> -- Hannes
In short, that is where we differ, as I don't think it is dangerous at
all in the "maint-worthy" sense.
"read-tree" without -m is to "populate the index from emptiness with given
trees". Unless you are hit by the bug in the auto-correction (whose fix
was maint-worthy), nobody would say read-tree without parameter and expect
that it wouldn't touch the index.
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. But these are all
features that are "dangerous if you didn't mean to do so but wanted to do
something else."
Removal of such features might turn out to be maint-worthy but
Previously, it was possible to run read-tree without any arguments,
whereupon it purged the index!
doesn't justify it well enough.
^ permalink raw reply
* Re: [PATCH 2/2] read-tree: at least one tree-ish argument is required
From: Sverre Rabbelier @ 2009-12-18 19:24 UTC (permalink / raw)
To: Johannes Sixt; +Cc: Junio C Hamano, Git Mailing List
In-Reply-To: <200912182004.25520.j.sixt@viscovery.net>
Heya,
On Fri, Dec 18, 2009 at 13:04, Johannes Sixt <j.sixt@viscovery.net> wrote:
> Sorry to drag you into this discussion, but I felt this change is maint-worthy
> (because the behavior is not only risky, but dangerous).
I agree, shouldn't such a dangerous function at least require a flag?
'git read-tree --empty' or something?
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* [RFC/PATCHv2 2/6] gitweb: Add option to force version match
From: Jakub Narebski @ 2009-12-18 19:18 UTC (permalink / raw)
To: git
Cc: John 'Warthog9' Hawley, John 'Warthog9' Hawley,
Jakub Narebski
In-Reply-To: <m3y6l9dbop.fsf@localhost.localdomain>
From: John 'Warthog9' Hawley <warthog9@kernel.org>
This adds $git_versions_must_match variable, which is set to true
value checks that we are running on the same version of git that we
shipped with, and if not throw '500 Internal Server Error' error.
What is checked is the version of gitweb (embedded in building
gitweb.cgi), against version of runtime git binary used.
Gitweb can usually run with a mismatched git install. This is more
here to give an obvious warning as to whats going on vs. silently
failing.
By default this feature is turned off.
Signed-off-by: John 'Warthog9' Hawley <warthog9@kernel.org>
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
---
I don't quite see the reason behind such option, and I think that
error (instead of for example warning) on version mismatch is too much.
This is an RFC because formatting of error page is a bit rough, and
(ab)uses exist CSS classes instead of creating new classnames for
semantic markup.
Differences from original version, by J.H.:
* Changed name and flipped meaning of config variable, from
$missmatch_git to $git_versions_must_match
* $git_versions_must_match is boolean flag - do not compare with an
empty string.
* Changed error message a bit, fixed style, added entry in README
gitweb/README | 3 +++
gitweb/gitweb.perl | 33 +++++++++++++++++++++++++++++++++
2 files changed, 36 insertions(+), 0 deletions(-)
diff --git a/gitweb/README b/gitweb/README
index 6c2c8e1..608b0f8 100644
--- a/gitweb/README
+++ b/gitweb/README
@@ -233,6 +233,9 @@ not include variables usually directly set during build):
If server load exceed this value then return "503 Service Unavaliable" error.
Server load is taken to be 0 if gitweb cannot determine its value. Set it to
undefined value to turn it off. The default is 300.
+ * $git_versions_must_match
+ If set, gitweb fails with 500 Internal Server Error if the version of gitweb
+ doesn't match version of git binary. The default is false.
Projects list file format
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index 3222131..b9bd865 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -221,6 +221,9 @@ our %avatar_size = (
'double' => 32
);
+# If it is true, exit if gitweb version and git binary version don't match
+our $git_versions_must_match = 0;
+
# 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.
@@ -581,6 +584,36 @@ if (defined $maxload && get_loadavg() > $maxload) {
our $git_version = qx("$GIT" --version) =~ m/git version (.*)$/ ? $1 : "unknown";
$number_of_git_cmds++;
+# Throw an error if git versions does not match, if $git_versions_must_match is true.
+if ($git_versions_must_match &&
+ $git_version ne $version) {
+ git_header_html('500 - Internal Server Error');
+ my $admin_contact =
+ defined $ENV{'SERVER_ADMIN'} ? ", $ENV{'SERVER_ADMIN'}," : '';
+ print <<"EOT";
+<div class="page_body">
+<br /><br />
+500 - Internal Server Error
+<br />
+</div>
+<hr />
+<div class="readme">
+<h1 align="center">*** Warning ***</h1>
+<p>
+This version of gitweb was compiled for <b>@{[esc_html($version)]}</b>,
+however git version <b>@{[esc_html($git_version)]}</b> was found on server,
+and administrator requested strict version checking.
+</p>
+<p>
+Please contact the server administrator${admin_contact} to either configure
+gitweb to allow mismatched versions, or update git or gitweb installation.
+</p>
+</div>
+EOT
+ git_footer_html();
+ exit;
+}
+
$projects_list ||= $projectroot;
# ======================================================================
--
1.6.5.3
^ permalink raw reply related
* Re: [PATCH 2/2] read-tree: at least one tree-ish argument is required
From: Johannes Sixt @ 2009-12-18 19:04 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Git Mailing List
In-Reply-To: <7v4onoywws.fsf@alter.siamese.dyndns.org>
On Freitag, 18. Dezember 2009, Junio C Hamano wrote:
> Johannes Sixt <j.sixt@viscovery.net> writes:
> > You have queued 1/2 (filter-branch: remove an unnecessary use of
> > 'git read-tree') of this 2-patch series, but I haven't seen any comments
> > about this 2/2 nor is it queued. Did it fall through the cracks?
>
> No. I think saying "is not allowed" is going a bit too far [*1*].
Yes, you said that, but in response to the footnote in 1/2.
> The
> documentation does not list it as a commonly useful thing, that's all.
IMO, not only is it not useful, but it is also dangerous - it erases the
index!
> When a user wants to have an empty index, and does not want to touch files
> under $GIT_DIR with any non-git tools (e.g. "rm -f $GIT_DIR/index) for
> some religious reasons, "read-tree" without a tree would be one valid way
> to do so [*2*].
> *2* I suspect "rm --cached ." might be another, but it would probably be
> much more expensive.
For an operation like this, shouldn't we advocate this alternate instruction
(which explicitly tells what is wanted) rather than the implicit and
undocumented operation of parameter-less read-tree?
> We need to make arguments like "'read-tree' given by mistake to empty the
> index is risky", "'read-tree' as 'rm -f $GIT_DIR/index' replacement has
> little value", and "'read-tree' as 'rm -f $GIT_DIR/index' replacement is
> the best way to get an empty index" to weigh pros and cons between two
> possible approaches before deciding which way to go, but in a pre-release
> freeze, I wasn't in the mood to be one who is doing the arguments myself.
Sorry to drag you into this discussion, but I felt this change is maint-worthy
(because the behavior is not only risky, but dangerous).
-- Hannes
^ permalink raw reply
* Re: repo corruption - Egit's fault?
From: Eugene Sajine @ 2009-12-18 18:51 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: git
In-Reply-To: <76c5b8580912181030k56cb7dd7l811c0a0d4773d309@mail.gmail.com>
> Thank you for prompt answer, Shawn!
>
> The problem is that as i'm maintaining multiple repos and their
> quantity will grow i would need to apply this setting site wide. Do
> you know if i can specify this service for git daemon? It seems like
> in git deamon docs this service is not listed, but just in case the
> docs are not up to date... I really don't want to set this up for
> every repo manually...
>
> Thanks,
> Eugene
>
I found it.
$ git config --global receive.fsckObjects true
should do the trick.
Thanks,
Eugene
^ permalink raw reply
* Re: repo corruption - Egit's fault?
From: Eugene Sajine @ 2009-12-18 18:30 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: git
In-Reply-To: <20091218181613.GA10687@spearce.org>
> To prevent this in the future, you can force a server to check during
> push by enabling receive.fsckObjects in the server repository's
> configuration file. A broken EGit client will have the push
> rejected immediately.
>
> --
> Shawn.
>
Thank you for prompt answer, Shawn!
The problem is that as i'm maintaining multiple repos and their
quantity will grow i would need to apply this setting site wide. Do
you know if i can specify this service for git daemon? It seems like
in git deamon docs this service is not listed, but just in case the
docs are not up to date... I really don't want to set this up for
every repo manually...
Thanks,
Eugene
^ permalink raw reply
* Re: [PATCH v2] Let format-patch and rebase ignore trivial merges.
From: Junio C Hamano @ 2009-12-18 18:23 UTC (permalink / raw)
To: Bernhard R. Link; +Cc: git, j.sixt
In-Reply-To: <20091218151102.GB7211@pcpool00.mathematik.uni-freiburg.de>
"Bernhard R. Link" <brlink@debian.org> writes:
[offtopic: weren't you already asked not to try redirecting away direct
responses to you by using M-F-T and wasting time of people who do want to
respond directly to you? Please don't.]
> As git rebase and git format-patch linearize commits,
> having the same change in different branches causes in the
> best case duplicate patches in the produced series and in the
> worst case conflicts. If there are trivial merges involved
> (i.e. merges that do not change the tree), then this patch
> will cause git to only look at one branch, thereby avoiding
> duplicates and reducing the chance of conflicts.
The patch text itself from the cursory review looks Ok (I haven't thought
things through yet, let alone applying it, though).
One issue in the proposed commit log message above is that "trivial merge"
is an established technical term that means something very different from
"resulting tree of the merge matches exactly one of the parents' tree",
and it needs to be reworded. In this case it is easy [*1*]. Drop
everything after "If there are ...", and add something like this as a
separate paragraph:
Avoid outputting duplicate patches by ignoring all other parents when
the merge result matches exactly one of the parents.
The code comment also needs to be adjusted.
Thanks.
[Footnote]
*1* It is a good habit to acquire to question yourself if you can omit "X"
altogether and just say "Y" after writing "X (i.e. Y)".
^ permalink raw reply
* Re: repo corruption - Egit's fault?
From: Shawn O. Pearce @ 2009-12-18 18:16 UTC (permalink / raw)
To: Eugene Sajine; +Cc: git
In-Reply-To: <76c5b8580912181006p2aef9d2fj95bb4c8456d965b@mail.gmail.com>
Eugene Sajine <euguess@gmail.com> wrote:
> When I???m looking at the bare repo in CGit ??it shows me ??Bad object:
> and object SHA-1 instead of ??the tree.
>
> As the only difference between this project and about 30 others was
> that there was an additional branch pushed via Egit I suspect that
> this is what screwed up things, but I ???m not sure??? I???m in progress of
> testing it I don???t know if I will be able to reproduce.
Its a somewhat known problem, but thus far has only shown up in
contexts where I'm unable to get enough data to debug the problem.
https://bugs.eclipse.org/bugs/show_bug.cgi?id=286653
> Please, advise if this can be fixed and which options I have if it
> will happen again (how to properly and quickly restore bare repo)
Delete the branch and repush it. The bug is that EGit didn't push
all of the objects needed by the branch. If you put the missing
objects from the source client into the server repository, it'll
be fine.
To prevent this in the future, you can force a server to check during
push by enabling receive.fsckObjects in the server repository's
configuration file. A broken EGit client will have the push
rejected immediately.
--
Shawn.
^ permalink raw reply
* Re: [PATCH 2/2] read-tree: at least one tree-ish argument is required
From: Junio C Hamano @ 2009-12-18 18:11 UTC (permalink / raw)
To: Johannes Sixt; +Cc: Git Mailing List
In-Reply-To: <4B2B5085.1050906@viscovery.net>
Johannes Sixt <j.sixt@viscovery.net> writes:
> You have queued 1/2 (filter-branch: remove an unnecessary use of
> 'git read-tree') of this 2-patch series, but I haven't seen any comments
> about this 2/2 nor is it queued. Did it fall through the cracks?
No. I think saying "is not allowed" is going a bit too far [*1*]. The
documentation does not list it as a commonly useful thing, that's all.
When a user wants to have an empty index, and does not want to touch files
under $GIT_DIR with any non-git tools (e.g. "rm -f $GIT_DIR/index) for
some religious reasons, "read-tree" without a tree would be one valid way
to do so [*2*]. That is not documented (the synopsis section even hints
that read-tree wants to take at least one tree), and I think it is a
problem that the documentation does not match what the program actually
allows.
The approach taken by [2/2] is to match the program to the documentation
by forbidding what has been allowed and what people may have been relying
on being able to do,
It was obvious that the line removed by [1/2] was a no-op not only in the
usual case but also in an error case (i.e. when the user does not have
write access to the repository), as I wrote in my review of the patch.
Compared to that, I do not think it is cut-and-dried clear that [2/2] is
the right kind of improvement. An alternative approach to document the
zero-tree case would be a valid way to address the documentation mismatch
problem.
We need to make arguments like "'read-tree' given by mistake to empty the
index is risky", "'read-tree' as 'rm -f $GIT_DIR/index' replacement has
little value", and "'read-tree' as 'rm -f $GIT_DIR/index' replacement is
the best way to get an empty index" to weigh pros and cons between two
possible approaches before deciding which way to go, but in a pre-release
freeze, I wasn't in the mood to be one who is doing the arguments myself.
[Footnote]
*1* Didn't I say that somewhere?
*2* I suspect "rm --cached ." might be another, but it would probably be
much more expensive.
^ permalink raw reply
* repo corruption - Egit's fault?
From: Eugene Sajine @ 2009-12-18 18:06 UTC (permalink / raw)
To: git, Shawn O. Pearce
Hi,
We have imported a project from CVS. Then created a bare repo and
placed on the central server. From the server repos are served via git
protocol for push and pull operations (no SSH is involved for intranet
set up)
After this operations there were several extensive changes made (3
commits but they were pretty big) in development branch which were
then pushed to the server. So the branch was pushed too.
All changes and commits and pushes were performed under eclipse 3.5
using Egit plugin v0.5.
After it I could not clone this repo from the server as it was giving
me an error like this (I will shorten it up a bit using “…” as I have
no way to copy paste):
$git clone git://server/repo.git
Initialized empty git…
remote:counting…done
remote:compressing…done
remote: aborting due to possible repository corruption on the remote side.
Receiving object: 100% …done
Resolving deltas: 100% …done
error: waitpid (async) failed
fatal: error in sideband demultiplexer (I know right words to curse now;))
When I’m looking at the bare repo in CGit it shows me Bad object:
and object SHA-1 instead of the tree.
As the only difference between this project and about 30 others was
that there was an additional branch pushed via Egit I suspect that
this is what screwed up things, but I ‘m not sure… I’m in progress of
testing it I don’t know if I will be able to reproduce.
Please, advise if this can be fixed and which options I have if it
will happen again (how to properly and quickly restore bare repo)
Thanks,
Eugene
^ permalink raw reply
* Re: git remote set-head not working?
From: Eugene Sajine @ 2009-12-18 17:38 UTC (permalink / raw)
To: Jeff King; +Cc: Jay Soffian, git, Eugene Sajine
In-Reply-To: <20091218165302.GA1746@sigill.intra.peff.net>
> Hmm. It probably worked, but what you are being shown is a bit
> confusing.
>
> "git remote show" will actually query the remote server to find where
> its HEAD is pointing. But "git remote set-head" is about changing your
> _local_ idea of where the remote head is pointing (in general, "git
> remote" does not change anything on the remote side. It is about
> managing the local configuration of your remotes).
>
> AFAICT, there is no way to use "git remote" to query the result of your
> set-head. And the "show" output makes no distinction between the two.
>
> Perhaps we should print both in "git remote show" if they differ.
> Something like:
>
> HEAD branch: qa (remote points to "master")
>
> or
>
> HEAD branch (local): qa
> HEAD branch (remote): master
>
> That would clear up the confusion of what is happening. Whether that is
> what you actually wanted, I don't know. If you want to be able to refer
> to "origin/qa" as "origin", then you're fine. But if you wanted to
> actually change the remote repository's idea of HEAD so that further
> clones will clone "qa" by default, then you can't do that with "git
> remote". You would have to go to the remote repository and run "git
> symbolic-ref", I think.
>
> -Peff
>
Yes. I was trying to change the HEAD on the bare remote (origin) repo
and the concept here is really confusing.
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.
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? 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.
The problem with this is that it can be screwed up easily (i did
it;)), but the fix is not trivial.
Scenario i hit was:
My colleague created bare repo on the server and performed some
commits and pushed. We've got 3 branches on the server: master, qa and
featureX The repo got screwed up - i was unable to clone because of
repository corruption (another story probably for Shawn as there was
Egit involved;) )
So i tried to recover I cloned from my colleague, but his head was
pointing to featureX so I've got this featureX, when i was expecting
to see master.
I realized that i have to add master and qa as tracking branches for
origin/master and origin/qa.
Then i deleted corrupted server repo, created bare repo using "clone
--bare" and put it on the server. But i didn't know that i have to
checkout to master branch in order for it to be default branch served
from the server before cloning. So i ended up with the featureX being
default HEAD on the server.
That was not user friendly stuff...
And here i am trying to change this setting on the server...
Thanks,
Eugene
^ permalink raw reply
* How to exclude files from "git diff"
From: H.J. Lu @ 2009-12-18 17:09 UTC (permalink / raw)
To: git
Hi,
I have some bookkeeping files in my git repository. How do I
exclude them from "git diff"? Does "git diff" support
# git diff --exclude="foo.*.bar*"
Please CC me since I am not on the git mailing list.
Thanks.
--
H.J.
^ 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