* git fetch with GIT_SSH fails with "The remote end hung up unexpectedly"
From: Gert Palok @ 2009-12-11 11:57 UTC (permalink / raw)
To: git
At my work I have to use an intermediate gateway to ssh to the outer
world. I have set up private-public keys to allow easy connection:
ssh gateway ssh user@outside
Now, I want to fetch from outside repo, so I created a GIT_SSH wrapper:
#! /bin/bash
LOG="/path/to/git-ssh-wrapper.
log"
HOST="$1"
COMMAND="$2"
echo host: $HOST >>"$LOG"
echo command: $COMMAND >>"$LOG"
echo exec: ssh gateway ssh "$HOST" $COMMAND >>"$LOG"
ssh gateway ssh "$HOST" $COMMAND
And ran:
$ GIT_SSH="/path/to/git-ssh-wrapper" git clone ssh://user@outside/path/to/repo
Initialized empty Git repository in /path/to/local-repo/.git/
warning: You appear to have cloned an empty repository.
$ fatal: The remote end hung up unexpectedly
And again just to be sure:
$ GIT_SSH="/path/to/git-ssh-wrapper" git fetch origin
$ fatal: The remote end hung up unexpectedly
fatal: The remote end hung up unexpectedly
Now, the log says:
host: user@outside
command: git-upload-pack '/path/to/repo'
exec: ssh gateway ssh user@outside git-upload-pack '/path/to/repo'
When I ran the command from shell I got:
$ "$GIT_SSH" user@outside "git-upload-pack '/path/to/repo'"
0000
And the connection was kept open (waiting for input, got protocol
error after entering something)
Local environment: Windows Vista 32-bit, cygwin 1.7
Local git version (installed by cygwin): 1.6.4.2
Remote git version: 1.6.4.4
What might be the cause(s)? Have there been compatibility breaking
protocol changes between those version?
--
Gert Palok
^ permalink raw reply
* Re: How to selectively recreate merge state?
From: Jakub Narebski @ 2009-12-11 11:20 UTC (permalink / raw)
To: Michael J Gruber; +Cc: Junio C Hamano, Jay Soffian, git
In-Reply-To: <4B222289.6000004@drmicha.warpmail.net>
Dnia piątek 11. grudnia 2009 11:44, Michael J Gruber napisał:
> Jakub Narebski venit, vidit, dixit 11.12.2009 02:33:
>> Dnia piątek 11. grudnia 2009 02:11, Junio C Hamano napisał:
>>> Jakub Narebski <jnareb@gmail.com> writes:
>>>
>>>> --unresolve::
>>>> Restores the 'unmerged' or 'needs updating' state of a
>>>> file during a merge if it was cleared by accident.
>>>>
>>>> Unless "git add foo" not only adds current contents of foo at stage 0,
>>>> but also removes higher stages from index...
>>>
>>> By definition, adding anything at stage #0 is to remove higher stages.
>>
>> Hmmm... let's test it:
>>
>> $ git merge side-branch
>> Auto-merging foo
>> CONFLICT (content): Merge conflict in foo
>> Automatic merge failed; fix conflicts and then commit the result.
>> $ git ls-files --stage
>> 100644 257cc5642cb1a054f08cc83f2d943e56fd3ebe99 1 foo
>> 100644 3bd1f0e29744a1f32b08d5650e62e2e62afb177c 2 foo
>> 100644 469a41eda5c8b45503a3bfc32ad6b5decc658132 3 foo
>> $ <edit foo>
>> $ git add foo
>> $ git ls-files --stage
>> 100644 a1b58d38ffa61e8e99b7cb95cdf540aedf2a96b3 0 foo
I thought that "git add foo" only adds current contents of foo in stage 0,
and does not delete other stages.
Unless "git add foo" does more than "git update-index foo" does here.
>> Now let's test '--unresolve' option of git-update-index:
>>
>> $ git update-index --unresolve foo
>> $ git ls-files --stage foo
>> 100644 3bd1f0e29744a1f32b08d5650e62e2e62afb177c 2 foo
>> 100644 469a41eda5c8b45503a3bfc32ad6b5decc658132 3 foo
>>
>> WTF? What happened to stage 1 (ancestor)?
>
> 2 and 3 are easy (cheap) to recreate from HEAD and MERGE_HEAD, 1 is not.
> I guess that's why --unresolve doesn't even attempt to do anything with 1.
But then "git update-index --unresolve <file>" is next to useless.
>>
>> $ git checkout --conflict=merge foo
>> error: path 'foo' does not have all three versions
>>
>> Let's recover it by hand:
>>
>> $ echo -e "100644 257cc5642cb1a054f08cc83f2d943e56fd3ebe99 1\tfoo" |
>> git update-index --index-info
>> $ git ls-files --stage foo
>> 100644 257cc5642cb1a054f08cc83f2d943e56fd3ebe99 1 foo
>> 100644 3bd1f0e29744a1f32b08d5650e62e2e62afb177c 2 foo
>> 100644 469a41eda5c8b45503a3bfc32ad6b5decc658132 3 foo
>> $ git checkout --conflict=merge foo
>
> Yeah, if we knew that sha1...
Isn't it:
$ git ls-tree $(git merge-base HEAD MERGE_HEAD) -- foo
or
$ git rev-parse "$(git merge-base HEAD MERGE_HEAD):foo"
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: How to selectively recreate merge state?
From: Björn Steinbrink @ 2009-12-11 11:09 UTC (permalink / raw)
To: Michael J Gruber; +Cc: Jakub Narebski, Junio C Hamano, Jay Soffian, git
In-Reply-To: <4B222289.6000004@drmicha.warpmail.net>
On 2009.12.11 11:44:25 +0100, Michael J Gruber wrote:
> Jakub Narebski venit, vidit, dixit 11.12.2009 02:33:
> > $ git checkout --conflict=merge foo
> > error: path 'foo' does not have all three versions
> >
> > Let's recover it by hand:
> >
> > $ echo -e "100644 257cc5642cb1a054f08cc83f2d943e56fd3ebe99 1\tfoo" |
> > git update-index --index-info
> > $ git ls-files --stage foo
> > 100644 257cc5642cb1a054f08cc83f2d943e56fd3ebe99 1 foo
> > 100644 3bd1f0e29744a1f32b08d5650e62e2e62afb177c 2 foo
> > 100644 469a41eda5c8b45503a3bfc32ad6b5decc658132 3 foo
> > $ git checkout --conflict=merge foo
>
> Yeah, if we knew that sha1...
Hm, isn't that "$(git merge-base HEAD MERGE_HEAD):foo"?
Björn
^ permalink raw reply
* Re: [PATCH RFC] rebase: add --revisions flag
From: Björn Steinbrink @ 2009-12-11 11:07 UTC (permalink / raw)
To: Junio C Hamano
Cc: Michael S. Tsirkin, Andreas Schwab, Peter Krefting,
Git Mailing List
In-Reply-To: <7vpr6mkaoz.fsf@alter.siamese.dyndns.org>
On 2009.12.10 09:20:28 -0800, Junio C Hamano wrote:
> Björn Steinbrink <B.Steinbrink@gmx.de> writes:
>
> >> But at the conceptual level, "merge --squash" is a short-hand for this
> >> command sequence:
> >>
> >> git rebase -i HEAD that-branch
> >> ... make everything except the first one into "squash"
> >> git checkout - ;# come back to the original branch
> >> git merge that-branch ;# fast forward to it
> >>
> >> So after all, it is "merge it after squashing them".
> >
> > To me, that approach looks backwards,...
>
> Yes, of course, but what you are missing (and I am at blame for forgetting
> to mention the history behind this in the message you are responding to)
> is that "merge --squash" to support a particular need/use case was done
> way before "rebase -i" came into existence.
Hm? You started explaining that "merge --squash" would be right because
you can do it via some command sequence that involves rebase -i and then
merge. I said that using that rebase+merge sequence as an argument for
the choice of the name is wrong. It would even have made more sense to
me if you said:
git merge that-branch
git reset --soft HEAD^
git commit -C ORIG_HEAD
Which is "merge, but then drop the extra parents", which pretty close to
what "merge --squash" does (and that sequence even gets it right not to
rewrite that-branch).
I'm not arguing that you shouldn't have chosen "merge --squash" to do
that. You couldn't possibly foresee the future and that git might get
rebase -i or maybe at some day cherry-pick -i <range>. I'm just saying
that in retrospective, it's sad that merge doesn't always mean "merge
histories", but that --squash makes it degenerate to "merge changes".
I don't see why you're trying to defend the choice of "merge --squash"
using a IMHO rather weird command sequence that happens to involve
"merge", using commands that weren't present when "merge --squash" was
added, but at the same ignore the "cherry-pick -i <range>" command git
might learn in the near future, which allows for a much saner
explanation:
git cherry-pick -i ..that-branch
... make everything except the first one into "squash"
And given that, one could add a --squash flag to cherry-pick that makes
it do the "squash everything" itself, allowing it to be a bit smarter
about the whole thing, because it could use a three-way merge
internally, instead of cherry-picking all the individual commits. Making
"git cherry-pick --squash ..that-branch" the same as "git merge --squash
that-branch".
> A nicer workflow may be to use "rebase -i" to clean up the history before
> even contemplating to integrate the topic to the mainline, instead of the
> above "abandoning or forking off again", if you know today's git.
Well, I'm not saying that git should completely lose the abilitiy to do
something like "merge --squash", just that if it learns "git cherry-pick
<range>", it might as well get the --squash thing for cherry-pick, maybe
allowing for "merge --squash" to be phased out. And heck, having it as
an option to cherry-pick instead of merge would probably already help a
lot to make people realise that it won't remember that the changes got
"integrated". We've had people on #git that wondered why repeated "git
merge --squash" commands would try to merge the same stuff over and over
again, leading to the same conflicts every time. Because they didn't
realise that with --squash, "git merge" is no longer about merging
histories.
> But interactive was not available back then. It was introduced at 1b1dce4
> (Teach rebase an interactive mode, 2007-06-25), which is 1 year after
> 7d0c688 (git-merge --squash, 2006-06-23).
Again, I'm not blaming you for having chosen that command back then.
Just saying that it might be better to have the same functionality in an
extended cherry-pick now.
Björn
^ permalink raw reply
* Re: [PATCH 2/6] GITWEB - Missmatching git w/ gitweb
From: Jakub Narebski @ 2009-12-11 10:52 UTC (permalink / raw)
To: John 'Warthog9' Hawley; +Cc: git, John 'Warthog9' Hawley
In-Reply-To: <1260488743-25855-3-git-send-email-warthog9@kernel.org>
"John 'Warthog9' Hawley" <warthog9@kernel.org> writes:
> This adds $missmatch_git so that gitweb can run with a miss-matched
> git install. Gitweb, generally, runs fine on a very broad range of
> git versions, but it's not always practicle or useful to upgrade it
> every time you upgrade git.
>
> This allows the administrator to realize they are miss-matched, and
> should they be so inclined, disable the check entirely and run in
> a miss-matched fasion.
>
> This is more here to give an obvious warning as to whats going on
> vs. silently failing.
First, why one would want to require that gitweb version (version at
the time of build) and runtime git version (version of git used to run
commands) match?
Second, it is mismatch, not missmatch (one 's', not double 's').
Third, in my opinion it would be better to name variable in question
e.g. $versions_must_match and also flip its meaning (true means check
that versions match, and show an error otherwise).
>
> Signed-off-by: John 'Warthog9' Hawley <warthog9@eaglescrag.net>
signoff mismatch
> ---
> gitweb/gitweb.perl | 22 ++++++++++++++++++++++
> 1 files changed, 22 insertions(+), 0 deletions(-)
>
>
> diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
> index 813e48f..d84f4c0 100755
> --- a/gitweb/gitweb.perl
> +++ b/gitweb/gitweb.perl
> @@ -221,6 +221,9 @@ our %avatar_size = (
> 'double' => 32
> );
>
> +# This is here to allow for missmatch git & gitweb versions
> +our $missmatch_git = '';
> +
First, 'undef' is false, so it could have been written as
+our $missmatch_git;
Or if you prefer explicit false-ish value as default, 0 would be I
think better than empty string '':
+our $missmatch_git = 0;
Second, there is question whether default should be to allow
mismatched versions (current behaviour, more lenient...) or deny (or
warn about) mismatched version, i.e. should it be $versions_must_match
false by default, or $allow_versions_mismatch false by default.
> # Used to set the maximum load that we will still respond to gitweb queries.
> # if we exceed this than we do the processing to figure out if there's a mirror
> # and redirect to it, or to just return 503 server busy
> @@ -579,6 +582,25 @@ if (get_loadavg() > $maxload) {
> our $git_version = qx("$GIT" --version) =~ m/git version (.*)$/ ? $1 : "unknown";
> $number_of_git_cmds++;
>
> +# There's a pretty serious flaw that we silently fail if git doesn't find something it needs
> +# a quick and simple check is to have gitweb do a simple check - are we running on the same
> +# version of git that we shipped with - if not, throw up an error so that people doing
> +# first installs don't have to debug perl to figure out whats going on
Could you please clean up language in above comment? It is very
convoluted. Please also limit line width of above comment to 76 / 80
columns.
> +if (
> + $git_version ne $version
> + &&
> + $missmatch_git eq ''
> +){
Style
+if (!$allow_versions_mismatch &&
+ $git_version ne $version) {
Do not compare $missmatch_git / $allow_versions_mismatch against '':
it is a boolean value!
> + git_header_html();
Shouldn't this be "500 Internal Server Error" or something (using the
optional parameter to git_header_html())?
> + print "<p><b>*** Warning ***</b></p>\n";
> + print "<p>\n";
> + print "This version of gitweb was compiled for <b>$version</b> however git version <b>$git_version</b> was found<br/>\n";
> + print "If you are sure this version of git works with this version of gitweb - please define <b>\$missmatch_git</b> to a non empty string in your git config file.\n";
Too long lines. Here-doc could be better here.
> + print "</p>\n";
> + git_footer_html();
> + exit;
> +}
> +
> $projects_list ||= $projectroot;
>
> # ======================================================================
--
Jakub Narebski
Poland
ShadeHawk on #git
^ permalink raw reply
* Re: How to selectively recreate merge state?
From: Michael J Gruber @ 2009-12-11 10:44 UTC (permalink / raw)
To: Jakub Narebski; +Cc: Junio C Hamano, Jay Soffian, git
In-Reply-To: <200912110233.18756.jnareb@gmail.com>
Jakub Narebski venit, vidit, dixit 11.12.2009 02:33:
> Dnia piątek 11. grudnia 2009 02:11, Junio C Hamano napisał:
>> Jakub Narebski <jnareb@gmail.com> writes:
>>
>>> --unresolve::
>>> Restores the 'unmerged' or 'needs updating' state of a
>>> file during a merge if it was cleared by accident.
>>>
>>> Unless "git add foo" not only adds current contents of foo at stage 0,
>>> but also removes higher stages from index...
>>
>> By definition, adding anything at stage #0 is to remove higher stages.
>
> Hmmm... let's test it:
>
> $ git merge side-branch
> Auto-merging foo
> CONFLICT (content): Merge conflict in foo
> Automatic merge failed; fix conflicts and then commit the result.
> $ git ls-files --stage
> 100644 257cc5642cb1a054f08cc83f2d943e56fd3ebe99 1 foo
> 100644 3bd1f0e29744a1f32b08d5650e62e2e62afb177c 2 foo
> 100644 469a41eda5c8b45503a3bfc32ad6b5decc658132 3 foo
> $ <edit foo>
> $ git add foo
> $ git ls-files --stage
> 100644 a1b58d38ffa61e8e99b7cb95cdf540aedf2a96b3 0 foo
>
> Now let's test '--unresolve' option of git-update-index:
>
> $ git update-index --unresolve foo
> $ git ls-files --stage foo
> 100644 3bd1f0e29744a1f32b08d5650e62e2e62afb177c 2 foo
> 100644 469a41eda5c8b45503a3bfc32ad6b5decc658132 3 foo
>
> WTF? What happened to stage 1 (ancestor)?
2 and 3 are easy (cheap) to recreate from HEAD and MERGE_HEAD, 1 is not.
I guess that's why --unresolve doesn't even attempt to do anything with 1.
>
> $ git checkout --conflict=merge foo
> error: path 'foo' does not have all three versions
>
> Let's recover it by hand:
>
> $ echo -e "100644 257cc5642cb1a054f08cc83f2d943e56fd3ebe99 1\tfoo" |
> git update-index --index-info
> $ git ls-files --stage foo
> 100644 257cc5642cb1a054f08cc83f2d943e56fd3ebe99 1 foo
> 100644 3bd1f0e29744a1f32b08d5650e62e2e62afb177c 2 foo
> 100644 469a41eda5c8b45503a3bfc32ad6b5decc658132 3 foo
> $ git checkout --conflict=merge foo
Yeah, if we knew that sha1...
^ permalink raw reply
* Re: [PATCH 1/6] GITWEB - Load Checking
From: Jakub Narebski @ 2009-12-11 10:09 UTC (permalink / raw)
To: J.H.; +Cc: git, John 'Warthog9' Hawley
In-Reply-To: <4B21AC4D.2020407@kernel.org>
On Fri, 11 Dec 2009, J.H. wrote:
> <snip>
>>> adds $maxload configuration variable. Default is a load of 300,
>>> which for most cases should never be hit.
>>
>> Your patch doesn't allow for *turning off* this feature. Reasonable
>> solution would be to use 'undef' or negative number to turn off this
>> check (this feature).
>
> Well there's the opposite argument that setting the number arbitrarily
> high, 4096 for instance would also in essence negate this (though I'll
> admit I've reached and exceeded those numbers before)
>
> That said I agree, being able to turn this off needs to be added and
> will be shortly.
Simplest solution would be to used 'undef' (undefined value) for
"turned off", i.e.:
if (defined $maxload && get_loadavg() > $maxload) {
>>> Please note this makes the assumption that /proc/loadavg exists
>>> as there is no good way to read load averages on a great number of
>>> platforms [READ: Windows], or that it's reasonably accurate.
>>
>> What about MacOS X, or FreeBSD, or OpenSolaris?
>
> Will comment on this further down
I think it would be better to write in commit message that because finding
load average is OS dependent, there is provided (sample) solution which
uses /proc/loadavg and works (at least) on Linux. And that for platforms
which do not have /proc/loadavg the feature is simply turned off (by the
way of using load=0 if load cannot be determined).
>> You should mention that it is intended that if gitweb cannot read load
>> average (for example /proc/loadavg does not exist), then the feature
>> is turned off, i.e. the check always succeeds. Which is reasonable.
>
> That's fine.
See above proposal. This information should be present in commit message,
and perhaps maybe even as one-line comment above opening /proc/loadavg.
>>> +# loadavg throttle
>>> +sub get_loadavg() {
>>> + my $load;
>>> + my @loads;
>>> +
>>> + open($load, '<', '/proc/loadavg') or return 0;
>>
>> Why not use one of existing CPAN modules: Sys::Info::Device::CPU,
>> BSD::getloadavg, Sys::CpuLoad?
>
> Here's the fundamental problem:
>
> Sys:Info:Device:CPU
> Windows:
> Using this method under Windows is not recommended
> since, the WMI interface will possibly take at least 2
> seconds to complete the request.
>
> BSD::getloadavg
> While this more or less supports anything with a libc getloadavg
> (and thus might be the best one I've seen, I'll admit I didn't
> notice this one when I looked years ago) getting it to work on
> windows looks, exciting.
>
> Sys::CpuLoad:
> http://cpansearch.perl.org/src/CLINTDW/Sys-CpuLoad-0.03/README
> Specifically:
> - Currently FreeBSD and OpenBSD are supported.
> - Wanted: HPUX 11.11 ...
> - Todo: Win32 support
>
> So this doesn't really buy me anything but, maybe, BSD support.
>
> So at the end of the day, none of those really gets me a "useful" cross
> platform load checker (though like I said BSD::getloadavg looks to be
> the best of the ones you mentioned) and more or less Windows is going to
> lose this as a usable feature no matter what.
>
> I think I'd almost rather set this up so that if it can't get something
> useful (I.E. /proc/loadavg is missing) it just skips past it as if the
> load was 0.
>
> I might try out the BSD::getloadavg but I want to take a look and see if
> that's easily installed or not, if it's not it might be difficult to
> justify that as a dependency.
After thinking about this a bit, now I don't think that it is terribly
important. You *might* describe alternate approaches (roads not taken)
in commit message, but requiring /proc/loadavg for the feature to work
is fine for first patch (it makes patch simpler).
>>> +if (get_loadavg()> $maxload) {
>>> + print "Content-Type: text/plain\n";
>>> + print "Status: 503 Excessive load on server\n";
>>> + print "\n";
>>> + print "The load average on the server is too high\n";
>>> + exit 0;
>>
>> Why not use die_error subroutine? Is it to have generate absolutely
>> minimal load, and that is why you do not use die_error(), or even
>> $cgi->header()?
>>
>> Wouldn't a better solution be to use here-doc syntax?
>>
>> + print <<'EOF';
>> +Content-Type: text/plain; charset=utf-8
>> +Status: 503 Excessive load on server
>> +
>> +The load average on the server is too high
>> +EOF
>> + exit 0;
>
> It was intended to be the most minimal possible, mainly get in, get out.
>
> Also not sure the die_error existed in gitweb when this was originally
> written. Probably worth switching to it now since it's there either
> way, and I don't think using it would add enough overhead to matter.
Well, if you are not worring excessively about overhead, then I think
using die_error would be the best solution, as it would preserve look
of gitweb. It would require extending die_error by 503 response, or
rather %http_responses hash and comment above die_error.
Also I think that Status: should be before Content-Type: header (but
probably it is not required by the standard).
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: git svn fetch loses data
From: Victor Engmark @ 2009-12-11 8:32 UTC (permalink / raw)
To: Thomas Rast; +Cc: Johan 't Hart, Sverre Rabbelier, git
In-Reply-To: <200911152152.01513.trast@student.ethz.ch>
On Sun, Nov 15, 2009 at 9:52 PM, Thomas Rast <trast@student.ethz.ch> wrote:
> Johan 't Hart wrote:
>> I didn't even know you could also do
>> $ git rebase git-svn
>> Unless git-svn is a ref...
>
> You can't, but in git-svn's default configuration (without
> --stdlayout) the cloned SVN history is called refs/remotes/git-svn.
Thanks all; now it all works a lot more smoothly.
--
Victor Engmark
^ permalink raw reply
* Re: Ambiguous ref names
From: Jeenu V @ 2009-12-11 8:03 UTC (permalink / raw)
To: git
In-Reply-To: <5195c8760911200355x1aff9781l848f974c9f09f416@mail.gmail.com>
On Fri, Nov 20, 2009 at 5:25 PM, Jeenu V <jeenuv@gmail.com> wrote:
>
> On Fri, Nov 20, 2009 at 4:29 PM, Junio C Hamano <gitster@pobox.com> wrote:
> > Jeenu V <jeenuv@gmail.com> writes:
> >
> >> On Fri, Nov 20, 2009 at 3:56 PM, Junio C Hamano <gitster@pobox.com> wrote:
> >>> [...]
> >>> It could be that you have a tag and a branch that are both named a.b.c,
> >>> though.
> >>
> >> Hm, right. But I'm getting this from an existing local repo of mine. I
> >> can't see any tags; 'git tag -l' is empty. Is there any more info that
> >> I can provide?
> >
> > man git-for-each-ref?
>
> It does list all refs that I know of, but I don't see any duplicate entries.
Ah, I think I get what happened here: I had used git update-ref, which
turned out to be used wrongly. My intention was to update a.b.c to a
new ref, but I used it 'git update-ref XXXXXX', rather than 'git
update-ref refs/heads/a.b.c XXXXXX'. The wrong usage created
.git/a.b.c and I guess this was causing the warning.
--
:J
^ permalink raw reply
* [ANNOUNCE] Git 1.6.5.6
From: Junio C Hamano @ 2009-12-11 6:09 UTC (permalink / raw)
To: git
The latest maintenance release Git 1.6.5.6 is available at the
usual places:
http://www.kernel.org/pub/software/scm/git/
git-1.6.5.6.tar.{gz,bz2} (source tarball)
git-htmldocs-1.6.5.6.tar.{gz,bz2} (preformatted docs)
git-manpages-1.6.5.6.tar.{gz,bz2} (preformatted docs)
The RPM binary packages for a few architectures are found in:
RPMS/$arch/git-*-1.6.5.6-1.fc11.$arch.rpm (RPM)
Hopefully this will be the last update to the 1.6.5.X series before the
upcoming feature release (1.6.6). It fixes a security issue, and users of
older 1.6.5.X series are strongly recommended to update to this version.
Git v1.6.5.6 Release Notes
==========================
Fixes since v1.6.5.5
--------------------
* "git add -p" had a regression since v1.6.5.3 that broke deletion of
non-empty files.
* "git archive -o o.zip -- Makefile" produced an archive in o.zip
but in POSIX tar format.
* Error message given to "git pull --rebase" when the user didn't give
enough clue as to what branch to integrate with still talked about
"merging with" the branch.
* Error messages given by "git merge" when the merge resulted in a
fast-forward still were in plumbing lingo, even though in v1.6.5
we reworded messages in other cases.
* The post-upload-hook run by upload-pack in response to "git fetch" has
been removed, due to security concerns (the hook first appeared in
1.6.5).
----------------------------------------------------------------
Changes since v1.6.5.5 are as follows:
Jan Krüger (1):
pull: clarify advice for the unconfigured error case
Jeff King (1):
add-interactive: fix deletion of non-empty files
Junio C Hamano (3):
Remove post-upload-hook
Fix archive format with -- on the command line
Git 1.6.5.6
Matthieu Moy (2):
merge-recursive: make the error-message generation an extern function
builtin-merge: show user-friendly error messages for fast-forward too.
^ permalink raw reply
* Re: [PATCH 1/6] GITWEB - Load Checking
From: Junio C Hamano @ 2009-12-11 3:09 UTC (permalink / raw)
To: J.H.; +Cc: Jakub Narebski, git
In-Reply-To: <4B21B550.1060806@kernel.org>
"J.H." <warthog9@kernel.org> writes:
>> Thanks; all sounded a reasonable response to the review. Are you
>> re-rolling the series anytime soon (I am asking because then I'd rather
>> not to queue this round especially because I didn't see 5/6).
>
> I'll probably have some changes up and about tomorrow, and it's a
> little troubling that 5/6 didn't come through for you
>
> 6 at least made it to marc.info:
> http://marc.info/?l=git&m=126048884825985&w=2
Sorry; I meant to say "[PATCH 5/6]", not "5 and 6 didn't come".
> and 5 seems to have been eaten by a grue somewhere. It was a *big*
> patch mainly because all the caching flips over in a single go. If
> you want I can privately bounce 5 & 6 to you so you have a complete
> tree right now?
Thanks, but not interested, in the sense that it wouldn't make much sense
to me to have a version tonight that is known to go stale within a few
days. I only pick up and queue patches to 'pu' to save me from later
trouble of finding them from the mailing list backlog, and not to actively
review and engage in the discussion to polish them right now. We are
already deep in pre-release freeze and my attention is not currently on
anything that won't go in to the upcoming release.
I want to have a solid 1.6.6 before the holidays as a present to all ;-).
^ permalink raw reply
* Re: [PATCH 1/6] GITWEB - Load Checking
From: J.H. @ 2009-12-11 3:07 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jakub Narebski, git
In-Reply-To: <4B21B550.1060806@kernel.org>
J.H. wrote:
> Junio C Hamano wrote:
>> "J.H." <warthog9@kernel.org> writes:
>>
>>> It was intended to be the most minimal possible, mainly get in, get
>>> out. Also not sure the die_error existed in gitweb when this was
>>> originally written. Probably worth switching to it now since it's
>>> there either way, and I don't think using it would add enough overhead
>>> to matter.
>>
>> Thanks; all sounded a reasonable response to the review. Are you
>> re-rolling the series anytime soon (I am asking because then I'd rather
>> not to queue this round especially because I didn't see 5/6).
>
> I'll probably have some changes up and about tomorrow, and it's a little
> troubling that 5/6 didn't come through for you
>
> 6 at least made it to marc.info:
> http://marc.info/?l=git&m=126048884825985&w=2
>
> and 5 seems to have been eaten by a grue somewhere. It was a *big*
> patch mainly because all the caching flips over in a single go. If you
> want I can privately bounce 5 & 6 to you so you have a complete tree
> right now?
Not to reply to myself but this might also be helpful:
http://git.kernel.org/?p=git/warthog9/gitweb.git;a=shortlog;h=refs/heads/gitweb-ml-v2
- John 'Warthog9' Hawley
^ permalink raw reply
* Re: [RFC/PATCHv10 01/11] fast-import: Proper notes tree manipulation
From: Junio C Hamano @ 2009-12-11 3:00 UTC (permalink / raw)
To: Johan Herland; +Cc: git, Shawn O. Pearce
In-Reply-To: <200912101540.43521.johan@herland.net>
Johan Herland <johan@herland.net> writes:
> On Thursday 10 December 2009, Shawn O. Pearce wrote:
>> Johan Herland <johan@herland.net> wrote:
>> > Do you have more comments/suggestions on this patch? Or is it ok to
>> > include in fast-import as-is?
>>
>> Oops, sorry.
>>
>> No, no additional comments. I am happy with this patch.
>>
>> Acked-by: Shawn O. Pearce <spearce@spearce.org>
>
> Thanks.
>
> Junio: With the above Ack, I believe patches #1 - #4 (and possibly #5)
> from this series are ready for 'next'.
>
> You may want to hold off on the remainder of the series until I get
> around to writing some functionality that actually _uses_ the new API.
Thanks for a notice, but we are already deep in pre-release freeze. I'll
hold onto the message I am replying to, but I won't be adding anything to
'next' until 1.6.6 final, unless it is somehow really urgent and deserves
to be in 'maint' and/or 'master'.
^ permalink raw reply
* Re: [PATCH 1/6] GITWEB - Load Checking
From: J.H. @ 2009-12-11 2:58 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jakub Narebski, git
In-Reply-To: <7vk4wu6x6a.fsf@alter.siamese.dyndns.org>
Junio C Hamano wrote:
> "J.H." <warthog9@kernel.org> writes:
>
>> It was intended to be the most minimal possible, mainly get in, get
>> out. Also not sure the die_error existed in gitweb when this was
>> originally written. Probably worth switching to it now since it's
>> there either way, and I don't think using it would add enough overhead
>> to matter.
>
> Thanks; all sounded a reasonable response to the review. Are you
> re-rolling the series anytime soon (I am asking because then I'd rather
> not to queue this round especially because I didn't see 5/6).
I'll probably have some changes up and about tomorrow, and it's a little
troubling that 5/6 didn't come through for you
6 at least made it to marc.info:
http://marc.info/?l=git&m=126048884825985&w=2
and 5 seems to have been eaten by a grue somewhere. It was a *big*
patch mainly because all the caching flips over in a single go. If you
want I can privately bounce 5 & 6 to you so you have a complete tree
right now?
- John 'Warthog9' Hawley
^ permalink raw reply
* Re: [PATCH 1/6] GITWEB - Load Checking
From: Junio C Hamano @ 2009-12-11 2:50 UTC (permalink / raw)
To: J.H.; +Cc: Jakub Narebski, git, John 'Warthog9' Hawley
In-Reply-To: <4B21AC4D.2020407@kernel.org>
"J.H." <warthog9@kernel.org> writes:
> It was intended to be the most minimal possible, mainly get in, get
> out. Also not sure the die_error existed in gitweb when this was
> originally written. Probably worth switching to it now since it's
> there either way, and I don't think using it would add enough overhead
> to matter.
Thanks; all sounded a reasonable response to the review. Are you
re-rolling the series anytime soon (I am asking because then I'd rather
not to queue this round especially because I didn't see 5/6).
^ permalink raw reply
* Re: [PATCH 1/6] GITWEB - Load Checking
From: J.H. @ 2009-12-11 2:19 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git, John 'Warthog9' Hawley
In-Reply-To: <m34onye3h8.fsf@localhost.localdomain>
<snip>
>> adds $maxload configuration variable. Default is a load of 300,
>> which for most cases should never be hit.
>
> Your patch doesn't allow for *turning off* this feature. Reasonable
> solution would be to use 'undef' or negative number to turn off this
> check (this feature).
Well there's the opposite argument that setting the number arbitrarily
high, 4096 for instance would also in essence negate this (though I'll
admit I've reached and exceeded those numbers before)
That said I agree, being able to turn this off needs to be added and
will be shortly.
>> Please note this makes the assumption that /proc/loadavg exists
>> as there is no good way to read load averages on a great number of
>> platforms [READ: Windows], or that it's reasonably accurate.
>
> What about MacOS X, or FreeBSD, or OpenSolaris?
Will comment on this further down
> You should mention that it is intended that if gitweb cannot read load
> average (for example /proc/loadavg does not exist), then the feature
> is turned off, i.e. the check always succeeds. Which is reasonable.
That's fine.
>
>> Signed-off-by: John 'Warthog9' Hawley <warthog9@eaglescrag.net>
>
> Why signoff is different from author (warthog9@kernel.org)? Why this
> email for signoff? Just curious...
My bad, did the patches up on my laptop but had to send them out from
kernel.org, thus the miss-match: I.E. user error.
<snip>
>> +# loadavg throttle
>> +sub get_loadavg() {
>> + my $load;
>> + my @loads;
>> +
>> + open($load, '<', '/proc/loadavg') or return 0;
>
> Why not use one of existing CPAN modules: Sys::Info::Device::CPU,
> BSD::getloadavg, Sys::CpuLoad?
Here's the fundamental problem:
Sys:Info:Device:CPU
Windows:
Using this method under Windows is not recommended
since, the WMI interface will possibly take at least 2
seconds to complete the request.
BSD::getloadavg
While this more or less supports anything with a libc getloadavg
(and thus might be the best one I've seen, I'll admit I didn't
notice this one when I looked years ago) getting it to work on
windows looks, exciting.
Sys::CpuLoad:
http://cpansearch.perl.org/src/CLINTDW/Sys-CpuLoad-0.03/README
Specifically:
- Currently FreeBSD and OpenBSD are supported.
- Wanted: HPUX 11.11 ...
- Todo: Win32 support
So this doesn't really buy me anything but, maybe, BSD support.
So at the end of the day, none of those really gets me a "useful" cross
platform load checker (though like I said BSD::getloadavg looks to be
the best of the ones you mentioned) and more or less Windows is going to
lose this as a usable feature no matter what.
I think I'd almost rather set this up so that if it can't get something
useful (I.E. /proc/loadavg is missing) it just skips past it as if the
load was 0.
I might try out the BSD::getloadavg but I want to take a look and see if
that's easily installed or not, if it's not it might be difficult to
justify that as a dependency.
<snip>
>> +if (get_loadavg() > $maxload) {
>> + print "Content-Type: text/plain\n";
>> + print "Status: 503 Excessive load on server\n";
>> + print "\n";
>> + print "The load average on the server is too high\n";
>> + exit 0;
>
> Why not use die_error subroutine? Is it to have generate absolutely
> minimal load, and that is why you do not use die_error(), or even
> $cgi->header()?
>
> Wouldn't a better solution be to use here-doc syntax?
>
> + print <<'EOF';
> +Content-Type: text/plain; charset=utf-8
> +Status: 503 Excessive load on server
> +
> +The load average on the server is too high
> +EOF
> + exit 0;
It was intended to be the most minimal possible, mainly get in, get out.
Also not sure the die_error existed in gitweb when this was originally
written. Probably worth switching to it now since it's there either
way, and I don't think using it would add enough overhead to matter.
- John 'Warthog9' Hawley
^ permalink raw reply
* Re: How to selectively recreate merge state?
From: Jakub Narebski @ 2009-12-11 1:33 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jay Soffian, git
In-Reply-To: <7vzl5q71rp.fsf@alter.siamese.dyndns.org>
Dnia piątek 11. grudnia 2009 02:11, Junio C Hamano napisał:
> Jakub Narebski <jnareb@gmail.com> writes:
>
> > --unresolve::
> > Restores the 'unmerged' or 'needs updating' state of a
> > file during a merge if it was cleared by accident.
> >
> > Unless "git add foo" not only adds current contents of foo at stage 0,
> > but also removes higher stages from index...
>
> By definition, adding anything at stage #0 is to remove higher stages.
Hmmm... let's test it:
$ git merge side-branch
Auto-merging foo
CONFLICT (content): Merge conflict in foo
Automatic merge failed; fix conflicts and then commit the result.
$ git ls-files --stage
100644 257cc5642cb1a054f08cc83f2d943e56fd3ebe99 1 foo
100644 3bd1f0e29744a1f32b08d5650e62e2e62afb177c 2 foo
100644 469a41eda5c8b45503a3bfc32ad6b5decc658132 3 foo
$ <edit foo>
$ git add foo
$ git ls-files --stage
100644 a1b58d38ffa61e8e99b7cb95cdf540aedf2a96b3 0 foo
Now let's test '--unresolve' option of git-update-index:
$ git update-index --unresolve foo
$ git ls-files --stage foo
100644 3bd1f0e29744a1f32b08d5650e62e2e62afb177c 2 foo
100644 469a41eda5c8b45503a3bfc32ad6b5decc658132 3 foo
WTF? What happened to stage 1 (ancestor)?
$ git checkout --conflict=merge foo
error: path 'foo' does not have all three versions
Let's recover it by hand:
$ echo -e "100644 257cc5642cb1a054f08cc83f2d943e56fd3ebe99 1\tfoo" |
git update-index --index-info
$ git ls-files --stage foo
100644 257cc5642cb1a054f08cc83f2d943e56fd3ebe99 1 foo
100644 3bd1f0e29744a1f32b08d5650e62e2e62afb177c 2 foo
100644 469a41eda5c8b45503a3bfc32ad6b5decc658132 3 foo
$ git checkout --conflict=merge foo
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: How to selectively recreate merge state?
From: Junio C Hamano @ 2009-12-11 1:11 UTC (permalink / raw)
To: Jakub Narebski; +Cc: Junio C Hamano, Jay Soffian, git
In-Reply-To: <m38wdae4k4.fsf@localhost.localdomain>
Jakub Narebski <jnareb@gmail.com> writes:
> --unresolve::
> Restores the 'unmerged' or 'needs updating' state of a
> file during a merge if it was cleared by accident.
>
> Unless "git add foo" not only adds current contents of foo at stage 0,
> but also removes higher stages from index...
By definition, adding anything at stage #0 is to remove higher stages.
^ permalink raw reply
* Re: [PATCH 1/6] GITWEB - Load Checking
From: Junio C Hamano @ 2009-12-11 1:10 UTC (permalink / raw)
To: Jakub Narebski
Cc: John 'Warthog9' Hawley, git,
John 'Warthog9' Hawley
In-Reply-To: <m34onye3h8.fsf@localhost.localdomain>
Jakub Narebski <jnareb@gmail.com> writes:
>> +# loadavg throttle
>> +sub get_loadavg() {
>> + my $load;
>> + my @loads;
>> +
>> + open($load, '<', '/proc/loadavg') or return 0;
>
> Why not use one of existing CPAN modules: Sys::Info::Device::CPU,
> BSD::getloadavg, Sys::CpuLoad?
I would prefer to hear something along the lines of...
I like this. Here is a follow-up patch you can squash in to
support other platforms.
I gave the patches a cursory look (I somehow didn't see 5/6, though) and
they all looked decently done, except that some of the lines were
excessively long.
^ permalink raw reply
* Re: [PATCH 1/6] GITWEB - Load Checking
From: Jakub Narebski @ 2009-12-11 0:52 UTC (permalink / raw)
To: John 'Warthog9' Hawley; +Cc: git, John 'Warthog9' Hawley
In-Reply-To: <1260488743-25855-2-git-send-email-warthog9@kernel.org>
"John 'Warthog9' Hawley" <warthog9@kernel.org> writes:
> This changes the behavior, slightly, of gitweb so that it verifies
> that the box isn't inundated with before attempting to serve gitweb.
> If the box is overloaded, it basically returns a 503 server unavailable
> until the load falls below the defined threshold. This helps dramatically
> if you have a box that's I/O bound, reaches a certain load and you
> don't want gitweb, the I/O hog that it is, increasing the pain the
> server is already undergoing.
>
> adds $maxload configuration variable. Default is a load of 300,
> which for most cases should never be hit.
Your patch doesn't allow for *turning off* this feature. Reasonable
solution would be to use 'undef' or negative number to turn off this
check (this feature).
>
> Please note this makes the assumption that /proc/loadavg exists
> as there is no good way to read load averages on a great number of
> platforms [READ: Windows], or that it's reasonably accurate.
What about MacOS X, or FreeBSD, or OpenSolaris?
You should mention that it is intended that if gitweb cannot read load
average (for example /proc/loadavg does not exist), then the feature
is turned off, i.e. the check always succeeds. Which is reasonable.
>
> Signed-off-by: John 'Warthog9' Hawley <warthog9@eaglescrag.net>
Why signoff is different from author (warthog9@kernel.org)? Why this
email for signoff? Just curious...
> ---
> gitweb/gitweb.perl | 24 ++++++++++++++++++++++++
> 1 files changed, 24 insertions(+), 0 deletions(-)
Please post patches inline, not as attachement.
> diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
> index 7e477af..813e48f 100755
> --- a/gitweb/gitweb.perl
> +++ b/gitweb/gitweb.perl
> @@ -221,6 +221,11 @@ our %avatar_size = (
> 'double' => 32
> );
>
> +# Used to set the maximum load that we will still respond to gitweb queries.
> +# if we exceed this than we do the processing to figure out if there's a mirror
> +# and redirect to it, or to just return 503 server busy
I'd probably say:
+# 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,
+# (it is also possible to redirect to mirror, if it exists, instead).
> +our $maxload = 300;
> +
> # You define site-wide feature defaults here; override them with
> # $GITWEB_CONFIG as necessary.
> our %feature = (
> @@ -551,6 +556,25 @@ if (-e $GITWEB_CONFIG) {
> do $GITWEB_CONFIG_SYSTEM if -e $GITWEB_CONFIG_SYSTEM;
> }
>
> +# loadavg throttle
> +sub get_loadavg() {
> + my $load;
> + my @loads;
> +
> + open($load, '<', '/proc/loadavg') or return 0;
Why not use one of existing CPAN modules: Sys::Info::Device::CPU,
BSD::getloadavg, Sys::CpuLoad?
Style:
+ open (my $load, '<', '/proc/loadavg') or return 0;
and of course no "my $load" at beginning. Also perhaps $fh, or
$loadfh instead of $load? But this is a minor nit.
> + @loads = split(/\s+/, scalar <$load>);
> + close($load);
> + return $loads[0];
> +}
> +
> +if (get_loadavg() > $maxload) {
> + print "Content-Type: text/plain\n";
> + print "Status: 503 Excessive load on server\n";
> + print "\n";
> + print "The load average on the server is too high\n";
> + exit 0;
Why not use die_error subroutine? Is it to have generate absolutely
minimal load, and that is why you do not use die_error(), or even
$cgi->header()?
Wouldn't a better solution be to use here-doc syntax?
+ print <<'EOF';
+Content-Type: text/plain; charset=utf-8
+Status: 503 Excessive load on server
+
+The load average on the server is too high
+EOF
+ exit 0;
> +}
> +
> # version of the core git binary
> our $git_version = qx("$GIT" --version) =~ m/git version (.*)$/ ? $1 : "unknown";
> $number_of_git_cmds++;
--
Jakub Narebski
Poland
ShadeHawk on #git
^ permalink raw reply
* Re: How to selectively recreate merge state?
From: Jakub Narebski @ 2009-12-11 0:28 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jay Soffian, git
In-Reply-To: <7v8wda8jg3.fsf@alter.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> Jay Soffian <jaysoffian@gmail.com> writes:
>
> > Let's say you initiate a merge:
> >
> > $ git merge topic
> >
> > And this merge results in conflicts in two files, foo and bar. You
> > resolve the conflicts in both files, but then decide you don't like
> > how you resolved bar.
> >
> > How do you set the index and working-copy back to the state it was
> > immediately after doing the merge for bar, while leaving the merge
> > resolution alone for foo?
>
> Before you "git add bar", you can say "git checkout --conflict=merge bar"
> (or --conflict=diff3).
Or (if I understand manpage correctly) just "git checkout --conflict bar".
> After "git add bar", you can't. Save what you have resolved so far in a
> separate file (e.g. "cp foo foo.resolved"), reset to the previous state
> and redo the merge.
Hmmm... isn't it what "git update-index --unresolve bar" is for?
--unresolve::
Restores the 'unmerged' or 'needs updating' state of a
file during a merge if it was cleared by accident.
Unless "git add foo" not only adds current contents of foo at stage 0,
but also removes higher stages from index...
--
Jakub Narebski
Poland
ShadeHawk on #git
^ permalink raw reply
* Re: How to selectively recreate merge state?
From: Junio C Hamano @ 2009-12-11 0:04 UTC (permalink / raw)
To: Jay Soffian; +Cc: git
In-Reply-To: <76718490912101556o3e2911e8t32b48c0b735fd98c@mail.gmail.com>
Jay Soffian <jaysoffian@gmail.com> writes:
> Let's say you initiate a merge:
>
> $ git merge topic
>
> And this merge results in conflicts in two files, foo and bar. You
> resolve the conflicts in both files, but then decide you don't like
> how you resolved bar.
>
> How do you set the index and working-copy back to the state it was
> immediately after doing the merge for bar, while leaving the merge
> resolution alone for foo?
Before you "git add bar", you can say "git checkout --conflict=merge bar"
(or --conflict=diff3).
After "git add bar", you can't. Save what you have resolved so far in a
separate file (e.g. "cp foo foo.resolved"), reset to the previous state
and redo the merge.
^ permalink raw reply
* How to selectively recreate merge state?
From: Jay Soffian @ 2009-12-10 23:56 UTC (permalink / raw)
To: git
Let's say you initiate a merge:
$ git merge topic
And this merge results in conflicts in two files, foo and bar. You
resolve the conflicts in both files, but then decide you don't like
how you resolved bar.
How do you set the index and working-copy back to the state it was
immediately after doing the merge for bar, while leaving the merge
resolution alone for foo?
j.
^ permalink raw reply
* Re: [PATCH 1/6] GITWEB - Load Checking
From: Sverre Rabbelier @ 2009-12-10 23:54 UTC (permalink / raw)
To: John 'Warthog9' Hawley; +Cc: git, John 'Warthog9' Hawley
In-Reply-To: <1260488743-25855-2-git-send-email-warthog9@kernel.org>
Heya,
On Fri, Dec 11, 2009 at 00:45, John 'Warthog9' Hawley
<warthog9@kernel.org> wrote:
> gitweb/gitweb.perl | 24 ++++++++++++++++++++++++
> 1 files changed, 24 insertions(+), 0 deletions(-)
>
>
Also, what happened to including patches inline for ease of review?
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* Re: [PATCH 0/6] Gitweb caching changes v2
From: Sverre Rabbelier @ 2009-12-10 23:53 UTC (permalink / raw)
To: John 'Warthog9' Hawley; +Cc: git, John 'Warthog9' Hawley
In-Reply-To: <1260488743-25855-1-git-send-email-warthog9@kernel.org>
Heya,
On Fri, Dec 11, 2009 at 00:45, John 'Warthog9' Hawley
<warthog9@kernel.org> wrote:
> John 'Warthog9' Hawley (6):
> GITWEB - Load Checking
> GITWEB - Missmatching git w/ gitweb
> GITWEB - Add git:// link to summary pages
> GITWEB - Makefile changes
> GITWEB - File based caching layer
> GITWEB - Separate defaults from main file
I'd prefer not to be shouted at, how about s/GITWEB/gitweb: /g ? :)
--
Cheers,
Sverre Rabbelier
^ 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