* Re: how to determine oldest supported version of git
From: Neal Kreitzinger @ 2012-02-03 20:19 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Neal Kreitzinger, git
In-Reply-To: <7v8vkktt6y.fsf@alter.siamese.dyndns.org>
On 2/2/2012 10:52 PM, Junio C Hamano wrote:
> As other people mentioned, if you are on a (probably paid) support plan
> from a(n enterprise) distro, asking them would be the best way, and if you
> are running Git supplied as part of a distro, the distro would dictate the
> version it supplies to you, so asking here would not help very much.
We compile our git from you (and your cohort). (Our paid distro does
not keep up.) Your replies have been *very* helpful.
thanks!
v/r,
neal
^ permalink raw reply
* Re: [PATCH v4 1/4] completion: work around zsh option propagation bug
From: Junio C Hamano @ 2012-02-03 20:23 UTC (permalink / raw)
To: Felipe Contreras
Cc: git, Junio C Hamano, SZEDER Gábor, Jonathan Nieder,
Thomas Rast, Shawn O. Pearce
In-Reply-To: <1328214625-3576-2-git-send-email-felipe.contreras@gmail.com>
Felipe Contreras <felipe.contreras@gmail.com> writes:
> Right now when listing commands in zsh (git <TAB><TAB>), all of them
> will show up, instead of only porcelain ones.
Jonathan's rewrite goes straight to the root cause instead, which is
another way to describe the problem.
Explaining user-visible symptoms at the beginning like you did is a good
strategy that I would want to see more contributors follow, though.
> Basically, in zsh, this:
>
> for i in $__git_all_commands
>
> Should be:
>
> for i in ${=__git_all_commands}
>
> Otherwise there's no word-splitting expansion (unless SH_WORD_SPLIT is
> set). sh emulation should take care of that, but the subshell is messing
> up with that. So __git_list_porcelain_commands does not do any
> filtering.
Let me step back a bit and see if we are on the same page wrt the root
cause of the problem and for whom we are explaining the change.
The adaptation of the bash completion script to zsh is done by asking zsh
to obey POSIXy word splitting rules to honor $IFS that is in effect when
the words are split. However zsh does not do a good job at it in some
cases, and your patch works it around by avoiding a construct known to be
troublesome to zsh.
Am I correct so far? If so, especially if the first sentence of the above
paragraph is correct, then how would it help others to teach "this is the
right way to do a word-split if we were writing in native zsh" when we are
not?
While it probably is a good description to have in a bug report given to
zsh folks, it is useless for people who read the history of Git. Unless
you are writing zsh-native completion script and this patch is not about
git-completion.bash, that is.
The readers need to read the solution described in order to understand why
the updated construct is written in an unnatural (to people who write to
POSIXy shells) way, or to avoid reintroducing a similar problem elsewhere
in the future. I find that what Jonathan gave you helps them much better:
...
fn () {
var='one two'
printf '%s\n' $var
}
x=$(fn)
: ${y=$(fn)}
printing "$x" results in two lines as expected, but printing "$y" results
in a single line because $var is expanded as a single word when evaluating
fn to compute y.
So avoid the construct, and use an explicit 'test -n "$foo" || foo=$(bar)'
instead.
So I'll take the first two lines of the message (good bits), and simplify
the "This fixes a bug tht caused..." from the last paragraph (or perhaps
even drop it).
Thanks.
^ permalink raw reply
* Re: [PATCH v4 4/4] completion: simplify __gitcomp*
From: Junio C Hamano @ 2012-02-03 20:23 UTC (permalink / raw)
To: Felipe Contreras
Cc: git, Junio C Hamano, SZEDER Gábor, Jonathan Nieder,
Thomas Rast, Shawn O. Pearce
In-Reply-To: <1328214625-3576-5-git-send-email-felipe.contreras@gmail.com>
Felipe Contreras <felipe.contreras@gmail.com> writes:
> @@ -495,11 +495,7 @@ fi
> # 4: A suffix to be appended to each possible completion word (optional).
> __gitcomp ()
> {
> - local cur_="$cur"
> -
> - if [ $# -gt 2 ]; then
> - cur_="$3"
> - fi
> + local cur_="${3:-$cur}"
> case "$cur_" in
> --*=)
> COMPREPLY=()
I think this rewrite is wrong, even though it may not make a difference to
the current callers (I didn't check). Drop the colon from ${3:-...}.
> @@ -524,18 +520,8 @@ __gitcomp ()
> # appended.
> __gitcomp_nl ()
> {
> - local s=$'\n' IFS=' '$'\t'$'\n'
> - local cur_="$cur" suffix=" "
> -
> - if [ $# -gt 2 ]; then
> - cur_="$3"
> - if [ $# -gt 3 ]; then
> - suffix="$4"
> - fi
> - fi
> -
> - IFS=$s
> - COMPREPLY=($(compgen -P "${2-}" -S "$suffix" -W "$1" -- "$cur_"))
> + local IFS=$'\n'
> + COMPREPLY=($(compgen -P "${2-}" -S "${4- }" -W "$1" -- "${3:-$cur}"))
So is this.
Fixing the above two gives me what I've already sent in $gmane/189683,
so...
^ permalink raw reply
* Re: [PATCH v3 1/4] completion: be nicer with zsh
From: Junio C Hamano @ 2012-02-03 20:28 UTC (permalink / raw)
To: Felipe Contreras; +Cc: Jonathan Nieder, git, SZEDER Gábor
In-Reply-To: <CAMP44s0Fq_BGwcmDM5E1kWNiyoJw6e6Hr=8XaNF6tmQAcdnUmw@mail.gmail.com>
Felipe Contreras <felipe.contreras@gmail.com> writes:
> On Fri, Feb 3, 2012 at 2:17 AM, Junio C Hamano <gitster@pobox.com> wrote:
> ...
>> Here is what I ended up in preparation for queuing the series. I still
>> haven't seen any version of 4/4, but please check $gmane/189683 and see if
>> that matches what you intended. Also I am assuming $gmane/189606 relayed
>> by Jonathan is a squash between your 2 and 3 (which didn't reach me), so
>> please advise if that does not match what you want to have.
>
> This is getting ridiculous, now I sent the patches directly to you, is
> your pobox.com server also silently dropping them for no reason?
Do not blame pobox.com; they have nothing to do with the corruption of
your headers.
The volume of messages on the git mailing list I read on gmane's nntp
interface is much larger than that of my personal git-mail mailbox.
Patches and ideas in their early rounds do not come to my personal
git-mail mailbox (because I asked people not to cc: me such messages
unless I am an area expert, and they have been good to me), but I try to
point people not to go in a wrong direction as early as possible to avoid
wasting time for contributors and reviewers when I can.
So I almost always am on the mailing list "newsgroup" when dealing with
git related mail traffic (which is not 100% of my git time to begin with),
and only after I ran out of messages to process I check my personal
git-mail mailbox "newsgroup". I usually only find "help me" messages and
questions that are addressed directly to me in private, and my standard
response to them is to ask the sender to conduct the business in public on
the list instead. In other words, my personal git-mail mailbox "newsgroup"
is primariliy a back-up mailbox for my purpose. I do not even run
fetchmail that often to poll it, because the latency for it is large due
to the way I work (described above).
You just caught me at the wrong moment when there were much more important
messages on the list (more refers to the volume, not all of them are more
important) and I was working on them (not limited to your issue) from top
to bottom in the mailing list "newsgroup". I however wanted to get the
zsh issue resolved sooner, and because you seemed to have been having so
much trouble with your MUA (I only so 0/4 even for v4), I tried to help
out by sending what I thought is already good, hoping that a message that
only has to say "that looks good, thanks" would be easier to make it to
the list.
All that happened before I got to the back-up git mailbox where you sent
the rest of your v4.
People say "Oops, our mails crossed." and go on without making too much
fuss about it. E-mail communications are asynchronous. Get used to it.
I think your mail breakage, from looking at your mail header, is this:
From: Felipe Contreras <felipe.contreras@gmail.com>
To: git@vger.kernel.org
Cc: Junio C Hamano <gitster@pobox.com>, SZEDER Gábor <szeder@ira.uka.de>, Jonathan Nieder <jrnieder@gmail.com>, Thomas Rast <trast@inf.ethz.ch>, Felipe Contreras <felipe.contreras@gmail.com>, "Shawn O. Pearce" <spearce@spearce.org>>
Subject: [PATCH v4 1/4] completion: work around zsh option propagation bug
Notice the excess '>' after the last address on Cc:?
It's not like this is your first serious submission to the list, so it is
curious why only this time you have been having so much trouble. Perhaps
you have changed your mail set-up lately?
^ permalink raw reply
* Re: [PATCH] t0300-credentials: Word around a solaris /bin/sh bug
From: Junio C Hamano @ 2012-02-03 20:32 UTC (permalink / raw)
To: Jeff King; +Cc: Ben Walton, git
In-Reply-To: <20120203120657.GB31441@sigill.intra.peff.net>
Jeff King <peff@peff.net> writes:
> cat >foo.sh <<\EOF
> #!/bin/sh
> echo my arguments are "$@"
> EOF
>
> cannot have the mechanical replace you mentioned above. It would need:
>
> cat >foo.sh <<EOF
> #!$SHELL_PATH
> echo my arguments are "\$@"
> EOF
>
> or:
>
> {
> echo "#!$SHELL_PATH" &&
> cat <<EOF
> echo my arguments are "$@"
> EOF
> } >foo.sh
>
> When I have hard-coded "#!/bin/sh", my thinking is usually "this is less
> cumbersome to type and to read, and this script-let is so small that
> even Solaris will get it right".
I am toying with the pros-and-cons of
write_script () {
echo "#!$1"
shift
cat
}
so that the above can become
write_script "$SHELL_PATH" >foo.sh <<-EOF
echo my arguments are "\$@"
EOF
without requiring the brain-cycle to waste on the "Is this simple enough
for even Solaris to grok?" guess game. This should also be reusable for
other stuff like $PERL_PATH, I would think.
^ permalink raw reply
* Re: [ANNOUNCE] Git 1.7.9
From: Jakub Narebski @ 2012-02-03 20:55 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vehubpuv7.fsf@alter.siamese.dyndns.org>
On Fri, 3 Feb 2012, Junio C Hamano wrote:
> Jakub Narebski <jnareb@gmail.com> writes:
>>>> RPM build errors:
>>>> Installed (but unpackaged) file(s) found:
>>>> /usr/share/locale/is/LC_MESSAGES/git.mo
>>>>
>>>
>>> I think it should be simply ignored at least for now. I stopped touching
>>> the rpm spec since August last year (the only reason I was running rpmbuild
>>> was to install them on k.org), so I didn't notice.
>>
>> So for the time being something like that would be an acceptable fix?
>
> Except that the patch probably wants to go to git.spec.in, removing that
> installation target would be a good local workaround for now.
O.K., will do.
Anyway this change makes rpmbuild process complete.
> I said "local workaround", meaning that I am not all that interested in
> applying such a patch myself. Somebody who wants to do RPM needs to
> decide what subpackage(s) it should go before we start accepting more po/
> files, and at that time the workaround needs to be reverted.
>
> And hopefully that should happen soonish ;-)
The git-i18n-Icelandic proposal for /usr/share/locale/is/LC_MESSAGES/git.mo
follow the KDE pattern (e.g. kde-i18n-Polish). This might be a place for
translated manpages and other documentation, if there is any.
On the other hand all translations for gitk are in gitk package
(as /usr/share/gitk/lib/msgs/*.msg, not /usr/share/locale/*/LC_MESSAGES/git.mo)
Same for git-gui.
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: [PATCH/RFCv2 (version B)] gitweb: Allow UTF-8 encoded CGI query parameters and path_info
From: Junio C Hamano @ 2012-02-03 21:09 UTC (permalink / raw)
To: Jakub Narebski; +Cc: Michal Kiedrowicz, git
In-Reply-To: <201202031344.55750.jnareb@gmail.com>
Jakub Narebski <jnareb@gmail.com> writes:
> Gitweb tries hard to properly process UTF-8 data, by marking output
> from git commands and contents of files as UTF-8 with to_utf8()
> subroutine. This ensures that gitweb would print correctly UTF-8
> e.g. in 'log' and 'commit' views.
>
> Unfortunately it misses another source of potentially Unicode input,
> namely query parameters. The result is that one cannot search for a
I think two lines should suffice instead of the above two paragraphs.
Gitweb forgot to turn query parameters into UTF-8. This results in
a bug that one cannot search for a
> string containing characters outside US-ASCII. For example searching
> ...
The remainder explains the problem and the solution very well modulo minor
typos.
> Noticed-by: Michał Kiedrowicz <michal.kiedrowicz@gmail.com>
> Signed-off-by: Jakub Narębski <jnareb@gmail.com>
> ---
We can add "Tested-by:" to this now. Will queue.
Thanks.
^ permalink raw reply
* Re: [PATCH] t0300-credentials: Word around a solaris /bin/sh bug
From: Jeff King @ 2012-02-03 21:26 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Ben Walton, git
In-Reply-To: <7v7h03odyo.fsf@alter.siamese.dyndns.org>
On Fri, Feb 03, 2012 at 12:32:15PM -0800, Junio C Hamano wrote:
> I am toying with the pros-and-cons of
>
> write_script () {
> echo "#!$1"
> shift
> cat
> }
>
> so that the above can become
>
> write_script "$SHELL_PATH" >foo.sh <<-EOF
> echo my arguments are "\$@"
> EOF
>
> without requiring the brain-cycle to waste on the "Is this simple enough
> for even Solaris to grok?" guess game. This should also be reusable for
> other stuff like $PERL_PATH, I would think.
I like it. Even better would be:
write_script() {
echo "#!$2" >"$1" &&
cat >>"$1" &&
chmod +x "$1"
}
write_script foo.sh "$SHELL_PATH" <<-\EOF
echo my arguments are "$@"
EOF
-Peff
^ permalink raw reply
* Re: Alternates corruption issue
From: Jeff King @ 2012-02-03 21:29 UTC (permalink / raw)
To: Junio C Hamano
Cc: Jonathan Nieder, Richard Purdie, GIT Mailing-list, Hart, Darren,
Ashfield, Bruce
In-Reply-To: <7v8vkjstq2.fsf@alter.siamese.dyndns.org>
On Fri, Feb 03, 2012 at 09:38:13AM -0800, Junio C Hamano wrote:
> Jeff King <peff@peff.net> writes:
>
> > However, with the ordering change, there is a technically a regression
> > in one case: a random file "foo" next to a repo "foo.git". Saying "git
> > ls-remote foo" used to prefer "foo.git", and will now select the file
> > "foo" only to fail.
>
> Yeah, very true X-<.
>
> > Thanks for noticing. I saw this issue when I was writing the original
> > version of the patch, and meant to revisit it and at least document it
> > in the commit message, but I ended up forgetting.
>
> No, thanks for working on this.
What do you want to do with it, then? Take my patch and ignore the
gitfile issue, or have me refactor it more heavily? I could go either
way.
-Peff
^ permalink raw reply
* [PATCH] gitweb: Deal with HEAD pointing to unborn branch in "heads" view
From: Jakub Narebski @ 2012-02-03 21:33 UTC (permalink / raw)
To: rajesh boyapati; +Cc: git
In-Reply-To: <CA+EqV8y3dhR8+PJbMxMNEsGjDOx6dxtPYjn8kDvAZxCAO7iS5w@mail.gmail.com>
On Mon, 30 Jan 2012, rajesh boyapati wrote:
>
> Thank you for your Suggestions in finding the error in my case.
> Do you have a blog, so that, I can know your updates about gitweb.
No, I don't have a blog, though I might use Git page on Google+ to
announce larger changes.
I am posting this to you to announce partial fix for your problem
in the form of patch to gitweb, which would hopefully made it to
next git version.
> 2012/1/30 Jakub Narebski <jnareb@gmail.com>
>> On Mon, 30 Jan 2012, rajesh boyapati wrote:
>>> 2012/1/28 Jakub Narebski <jnareb@gmail.com>
>>>> On Fri, 27 Jan 2012, rajesh boyapati wrote:
>>>>> my $alternate = 1;
>>>>> for (my $i = $from; $i <= $to; $i++) {
>>>>> my $entry = $headlist->[$i];
>>>>> my %ref = %$entry;
>>>>> my $curr = $ref{'id'} eq $head;
>>>>> if ($alternate) {
>>>>> print "<tr class=\"dark\">\n";
>>>>> } else {
>>>>> print "<tr class=\"light\">\n";
>>>>> }
>>>>> $alternate ^= 1;
>>>>
>>>> Hmmmm... I see that we do not check if $head is defined here before using
>>>> it. This can happen legitimately if we are on yet to be born orphan branch
>>>> (so $head, which should be named $head_at, is undefined) but there exist
>>>> other branches (so $headlist is not empty).
This was simple to fix.
>>>>>>> [2012-01-25 18:50:35,658] ERROR
>>>>>>> com.google.gerrit.httpd.gitweb.GitWebServlet : CGI: [Wed Jan 25
>>>>>>> 18:50:35 2012] gitweb.cgi: Use of uninitialized value $commit_id
>>>>>>> in open at /usr/lib/cgi-bin/gitweb.cgi line 2817.
>>>>> sub parse_commits {
>>>>> my ($commit_id, $maxcount, $skip, $filename, @args) = @_;
>>>>> my @cos;
>>>>>
>>>>> $maxcount ||= 1;
>>>>> $skip ||= 0;
>>>>>
>>>>> local $/ = "\0";
>>>>>
>>>>> open my $fd, "-|", git_cmd(), "rev-list",
>>>>> "--header",
>>>>> @args,
>>>>> ("--max-count=" . $maxcount),
>>>>> ("--skip=" . $skip),
>>>>> @extra_options,
>>>>> $commit_id,
>>>>> "--",
>>>>> ($filename ? ($filename) : ())
>>>>> or die_error(500, "Open git-rev-list failed");
But I was not able to fix this, at least not currently. I wrote a failing
test case for "commit" and similar views on unborn HEAD... but they fail
_without_ error message like the one quoted.
I'd have to go slower route of examining gitweb code in how it deals with
"invalid" HEAD (i.e. HEAD not pointing to commit, being on unborn branch).
>>> For my git projects on gerrit, our main branch name is "base".
>>> We don't have any code on "master" branch.
>>> May be the $HEAD is looking for master branch(or checked out branch in git
>>> project).--> In our case, "master" is an empty branch.
>>> Also, In the git projects, the HEAD file is pointing to "ref:
>>> refs/heads/master".
>>> So, I think that's the reason for errors.
>>>
>>> How can I make $HEAD to point to a branch other than "master"?.
>>> a) I can do this by pointing HEAD file in git projects to other branch
>> [...]
>>> b) Is there any way, other than doing above step (a) ?.
>>> I mean I don't want to have a code on "master" branch and also I
>>> don't want to point HEAD file in git projects to some other branch.
>>> Do I need to make any modifications to "gitweb.cgi" for this?
>>
>> Now that I know the source of this error, I can write test case
>> for it, and fix it. I'll try to do it soon.
>>
>> So finally what you would need for (b) is just upgrade gitweb.
And here is the patch:
-- >8 ------------ >8 ---
From: Jakub Narebski <jnareb@gmail.com>
Subject: [PATCH] gitweb: Deal with HEAD pointing to unborn branch in "heads"
view
Gitweb has problems if HEAD points to an unborn branch, with no
commits on it yet, but there are other branches present (so it is not
newly initialized repository).
This can happen if non-bare repository (with default 'master' branch)
is updated not via committing but by other means like push to it, or
Gerrit. It can happen also just after running "git checkout --orphan
<new branch>" but before creating any new commit on this branch.
This commit adds test and fixes the issue of being on unborn branch
(of HEAD not pointing to a commit) in "heads" view, and also in
"summary" view -- which includes "heads" excerpt as subview.
While at it rename local variable $head to $head_at, as it points to
current commit rather than current branch name (HEAD contents).
Reported-by: rajesh boyapati <boyapatisrajesh@gmail.com>
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
---
gitweb/gitweb.perl | 4 ++--
t/t9500-gitweb-standalone-no-errors.sh | 9 +++++++++
2 files changed, 11 insertions(+), 2 deletions(-)
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index 9cf7e71..1f0ec12 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -5570,7 +5570,7 @@ sub git_tags_body {
sub git_heads_body {
# uses global variable $project
- my ($headlist, $head, $from, $to, $extra) = @_;
+ my ($headlist, $head_at, $from, $to, $extra) = @_;
$from = 0 unless defined $from;
$to = $#{$headlist} if (!defined $to || $#{$headlist} < $to);
@@ -5579,7 +5579,7 @@ sub git_heads_body {
for (my $i = $from; $i <= $to; $i++) {
my $entry = $headlist->[$i];
my %ref = %$entry;
- my $curr = $ref{'id'} eq $head;
+ my $curr = defined $head_at && $ref{'id'} eq $head_at;
if ($alternate) {
print "<tr class=\"dark\">\n";
} else {
diff --git a/t/t9500-gitweb-standalone-no-errors.sh b/t/t9500-gitweb-standalone-no-errors.sh
index 0f771c6..81246a6 100755
--- a/t/t9500-gitweb-standalone-no-errors.sh
+++ b/t/t9500-gitweb-standalone-no-errors.sh
@@ -739,4 +739,13 @@ test_expect_success \
'echo "\$projects_list_group_categories = 1;" >>gitweb_config.perl &&
gitweb_run'
+# ----------------------------------------------------------------------
+# unborn branches
+
+test_expect_success \
+ 'unborn HEAD: "summary" page (with "heads" subview)' \
+ 'git checkout orphan_branch || git checkout --orphan orphan_branch &&
+ test_when_finished "git checkout master" &&
+ gitweb_run "p=.git;a=summary"'
+
test_done
--
1.7.9
^ permalink raw reply related
* Re: Push from an SSH Terminal
From: Jeff King @ 2012-02-03 21:35 UTC (permalink / raw)
To: Feanil Patel; +Cc: git
In-Reply-To: <CAG94OYxX5foffvaFLQv7=wXguGC2TLgccdDFrC+ERzv_gXZ=ug@mail.gmail.com>
On Fri, Feb 03, 2012 at 10:50:02AM -0500, Feanil Patel wrote:
> I tried looking for an answer to my problem online without much luck,
> perhaps you can help me. I'm SSHed from my laptop(Comp A) over to a
> computer(Comp B) that has my git repo on it. I made some changes and
> comitted them. Now I want to push them to my other server(Comp C). The
> repository is password protected so if I'm physically at Comp B, I get
> a gui prompt for my username and password. However Comp A does not
> have X Forwarding setup to Comp B so I can't get the gui interface for
> the username and password when I try to do the push. Is there an
> alternative way to provide my credentials when doing a git push that
> does not require a gui?
Git should prompt you on the terminal (i.e., the ssh session) if it
needs credentials. If it is not, and the terminal is accessible, it
might be a bug. There were some fixes around this area that went into
1.7.9; you might try using that version.
Also, 1.7.9 ships with support for credential helper scripts, which can
help you avoid putting in your password less frequently (see "git help
credentials" in git 1.7.9).
-Peff
^ permalink raw reply
* Re: Push from an SSH Terminal
From: Jeff King @ 2012-02-03 21:36 UTC (permalink / raw)
To: Neal Groothuis; +Cc: Feanil Patel, git
In-Reply-To: <34592.38.96.167.131.1328289027.squirrel@mail.lo-cal.org>
On Fri, Feb 03, 2012 at 12:10:27PM -0500, Neal Groothuis wrote:
> > On Fri, Feb 3, 2012 at 11:21 AM, Neal Groothuis <ngroot@lo-cal.org> wrote:
> >>> The
> >>> repository is password protected so if I'm physically at Comp B, I get
> >>> a gui prompt for my username and password. However Comp A does not
> >>> have X Forwarding setup to Comp B so I can't get the gui interface for
> >>> the username and password when I try to do the push. Â Is there an
> >>> alternative way to provide my credentials when doing a git push that
> >>> does not require a gui?
> >>
> >> What protocol are you using to access the repository on Comp C?
> >>
> > I'm pulling and pushing over HTTP from Comp C.
>
> Check to see if the GIT_ASKPASS and/or SSH_ASKPASS environment variables
> are set, and if the core.askpass config variable is set. If any of these
> are set, unset them. Git should fall back to a simple password prompt.
Hmm, yeah that is likely the problem. I was thinking git would fall back
to asking on the terminal, but it does not. We probably should.
-Peff
^ permalink raw reply
* [PATCH] git.spec: Workaround localized messages not put in any RPM
From: Jakub Narebski @ 2012-02-03 21:49 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <201202032155.26532.jnareb@gmail.com>
Currently building git RPM from tarball results in the following
error:
RPM build errors:
Installed (but unpackaged) file(s) found:
/usr/share/locale/is/LC_MESSAGES/git.mo
This is caused by the fact that localized messages do not have their
place in some RPM package. Let's postpone decision where they should
be put (be it git-i18n-Icelandic, or git-i18n, or git package itself)
for later by removing locale files at the end of install phase.
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
---
git.spec.in | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/git.spec.in b/git.spec.in
index c562c62..b93df10 100644
--- a/git.spec.in
+++ b/git.spec.in
@@ -134,6 +134,7 @@ find $RPM_BUILD_ROOT -type f -name perllocal.pod -exec rm -f {} ';'
%else
rm -rf $RPM_BUILD_ROOT%{_mandir}
%endif
+rm -rf $RPM_BUILD_ROOT%{_datadir}/locale
mkdir -p $RPM_BUILD_ROOT%{_sysconfdir}/bash_completion.d
install -m 644 -T contrib/completion/git-completion.bash $RPM_BUILD_ROOT%{_sysconfdir}/bash_completion.d/git
--
1.7.9
^ permalink raw reply related
* Re: [PATCH] t0300-credentials: Word around a solaris /bin/sh bug
From: Junio C Hamano @ 2012-02-03 21:50 UTC (permalink / raw)
To: Jeff King; +Cc: Ben Walton, git
In-Reply-To: <20120203212604.GA1890@sigill.intra.peff.net>
Jeff King <peff@peff.net> writes:
>> without requiring the brain-cycle to waste on the "Is this simple enough
>> for even Solaris to grok?" guess game. This should also be reusable for
>> other stuff like $PERL_PATH, I would think.
>
> I like it. Even better would be:
>
> write_script() {
> echo "#!$2" >"$1" &&
> cat >>"$1" &&
> chmod +x "$1"
> }
>
> write_script foo.sh "$SHELL_PATH" <<-\EOF
> echo my arguments are "$@"
> EOF
I first thought that the order of parameters were unusual, but with that
order, you could even go something fancier like:
write_script () {
case "$#" in
1) case "$1" in
*.perl | *.pl) echo "#!$PERL_PATH" ;;
*) echo "#!$SHELL_PATH" ;;
esac
2) echo "#!$2" ;;
*) BUG ;;
esac >"$1" &&
cat >>"$1" &&
chmod +x "$1"
}
write_script foo.sh
write_script bar.perl
write_script pre-receive /no/frobnication/today
The tongue-in-cheek comment aside, I think ${2-"$SHELL_PATH"} or some form
of fallback would be a good idea in any case, as 99% of the time what we
write in the test scripts is a shell script.
Also "chmod +x" is a very good idea.
^ permalink raw reply
* Re: Alternates corruption issue
From: Junio C Hamano @ 2012-02-03 21:51 UTC (permalink / raw)
To: Jeff King
Cc: Jonathan Nieder, Richard Purdie, GIT Mailing-list, Hart, Darren,
Ashfield, Bruce
In-Reply-To: <20120203212906.GB1890@sigill.intra.peff.net>
Jeff King <peff@peff.net> writes:
>> No, thanks for working on this.
>
> What do you want to do with it, then? Take my patch and ignore the
> gitfile issue, or have me refactor it more heavily? I could go either
> way.
How about queuing it as is in next and see if anybody screams loudly
enough so that we can fix-up if necessary in-tree?
^ permalink raw reply
* Re: Alternates corruption issue
From: Jeff King @ 2012-02-03 21:53 UTC (permalink / raw)
To: Junio C Hamano
Cc: Jonathan Nieder, Richard Purdie, GIT Mailing-list, Hart, Darren,
Ashfield, Bruce
In-Reply-To: <7vmx8zmvq2.fsf@alter.siamese.dyndns.org>
On Fri, Feb 03, 2012 at 01:51:33PM -0800, Junio C Hamano wrote:
> Jeff King <peff@peff.net> writes:
>
> >> No, thanks for working on this.
> >
> > What do you want to do with it, then? Take my patch and ignore the
> > gitfile issue, or have me refactor it more heavily? I could go either
> > way.
>
> How about queuing it as is in next and see if anybody screams loudly
> enough so that we can fix-up if necessary in-tree?
Sounds good to me. Jonathan might be interested in building on top of
it, too.
-Peff
^ permalink raw reply
* Re: [PATCH] t0300-credentials: Word around a solaris /bin/sh bug
From: Jeff King @ 2012-02-03 21:55 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Ben Walton, git
In-Reply-To: <7vr4ybmvrq.fsf@alter.siamese.dyndns.org>
On Fri, Feb 03, 2012 at 01:50:33PM -0800, Junio C Hamano wrote:
> > write_script foo.sh "$SHELL_PATH" <<-\EOF
> > echo my arguments are "$@"
> > EOF
>
> I first thought that the order of parameters were unusual, but with that
> order, you could even go something fancier like:
>
> write_script () {
> case "$#" in
> 1) case "$1" in
> *.perl | *.pl) echo "#!$PERL_PATH" ;;
> *) echo "#!$SHELL_PATH" ;;
> esac
> 2) echo "#!$2" ;;
> *) BUG ;;
> esac >"$1" &&
> cat >>"$1" &&
> chmod +x "$1"
> }
>
Nice. I was going to suggest a wrapper like "write_sh_script" so you
didn't have to spell out $SHELL_PATH, but I think the auto-detection
makes sense (and falling back to shell makes even more sense, as that
covers 99% of the cases anyway).
-Peff
^ permalink raw reply
* Re: [PATCH] t0300-credentials: Word around a solaris /bin/sh bug
From: Ben Walton @ 2012-02-03 22:00 UTC (permalink / raw)
To: Jeff King, Junio C Hamano; +Cc: git
In-Reply-To: <20120203215507.GB3472@sigill.intra.peff.net>
Excerpts from Jeff King's message of Fri Feb 03 16:55:07 -0500 2012:
> > write_script () {
> > case "$#" in
> > 1) case "$1" in
> > *.perl | *.pl) echo "#!$PERL_PATH" ;;
> > *) echo "#!$SHELL_PATH" ;;
> > esac
> > 2) echo "#!$2" ;;
> > *) BUG ;;
> > esac >"$1" &&
> > cat >>"$1" &&
> > chmod +x "$1"
> > }
> >
>
> Nice. I was going to suggest a wrapper like "write_sh_script" so you
> didn't have to spell out $SHELL_PATH, but I think the auto-detection
> makes sense (and falling back to shell makes even more sense, as that
> covers 99% of the cases anyway).
This looks like a very nice, general purpose, solution to the problem.
Thanks
-Ben
--
Ben Walton
Systems Programmer - CHASS
University of Toronto
C:416.407.5610 | W:416.978.4302
^ permalink raw reply
* Re: Push from an SSH Terminal
From: Jeff King @ 2012-02-03 22:13 UTC (permalink / raw)
To: Neal Groothuis; +Cc: Feanil Patel, git
In-Reply-To: <20120203213654.GD1890@sigill.intra.peff.net>
On Fri, Feb 03, 2012 at 04:36:54PM -0500, Jeff King wrote:
> > Check to see if the GIT_ASKPASS and/or SSH_ASKPASS environment variables
> > are set, and if the core.askpass config variable is set. If any of these
> > are set, unset them. Git should fall back to a simple password prompt.
>
> Hmm, yeah that is likely the problem. I was thinking git would fall back
> to asking on the terminal, but it does not. We probably should.
We should probably do this:
[1/2]: prompt: clean up strbuf usage
[2/2]: prompt: fall back to terminal if askpass fails
-Peff
^ permalink raw reply
* [PATCH 1/2] prompt: clean up strbuf usage
From: Jeff King @ 2012-02-03 22:14 UTC (permalink / raw)
To: Neal Groothuis; +Cc: Feanil Patel, git
In-Reply-To: <20120203213654.GD1890@sigill.intra.peff.net>
The do_askpass function inherited a few bad habits from the
original git_getpass. One, there's no need to strbuf_reset a
buffer which was just initialized. And two, it's a good
habit to use strbuf_detach to claim ownership of a buffer's
string (even though in this case the owning buffer goes out
of scope, so it's effectively the same thing).
Signed-off-by: Jeff King <peff@peff.net>
---
Neither is a big deal, but just some style cleanups while I was in the
area.
prompt.c | 3 +--
1 files changed, 1 insertions(+), 2 deletions(-)
diff --git a/prompt.c b/prompt.c
index 72ab9de..64f817b 100644
--- a/prompt.c
+++ b/prompt.c
@@ -21,7 +21,6 @@ static char *do_askpass(const char *cmd, const char *prompt)
if (start_command(&pass))
exit(1);
- strbuf_reset(&buffer);
if (strbuf_read(&buffer, pass.out, 20) < 0)
die("failed to get '%s' from %s\n", prompt, cmd);
@@ -32,7 +31,7 @@ static char *do_askpass(const char *cmd, const char *prompt)
strbuf_setlen(&buffer, strcspn(buffer.buf, "\r\n"));
- return buffer.buf;
+ return strbuf_detach(&buffer, NULL);
}
char *git_prompt(const char *prompt, int flags)
--
1.7.9.rc1.28.gf4be5
^ permalink raw reply related
* [PATCH 2/2] prompt: fall back to terminal if askpass fails
From: Jeff King @ 2012-02-03 22:16 UTC (permalink / raw)
To: Neal Groothuis; +Cc: Feanil Patel, git
In-Reply-To: <20120203213654.GD1890@sigill.intra.peff.net>
The current askpass code simply dies if calling an askpass
helper fails. Worse, in some failure modes it doesn't even
print an error (if start_command fails, then it prints its
own error; if reading fails, we print an error; but if the
command exits non-zero, finish_command fails and we print
nothing!).
Let's be more kind to the user by printing an error message
when askpass doesn't work out, and then falling back to the
terminal (which also may fail, of course, but we die already
there with a nice message).
While we're at it, let's clean up the existing error
messages a bit. Now that our prompts are very long and
contain quotes and colons themselves, our error messages are
hard to read.
So the new failure modes look like:
[before, with a terminal]
$ GIT_ASKPASS=false git push
$ echo $?
128
[before, with no terminal, and we must give up]
$ setsid git push
fatal: could not read 'Password for 'https://peff@github.com': ': No such device or address
[after, with a terminal]
$ GIT_ASKPASS=false git push
error: unable to read askpass response from 'false'
Password for 'https://peff@github.com':
[after, with no terminal, and we must give up]
$ GIT_ASKPASS=false setsid git push
error: unable to read askpass response from 'false'
fatal: could not read Password for 'https://peff@github.com': No such device or address
Signed-off-by: Jeff King <peff@peff.net>
---
Arguably, the terminal-failure error message shouldn't even bother
reporting errno. I can't imagine it failing for any reason other than
ENODEV, and the message would probably be less confusing as:
fatal: could not prompt on terminal for Password for...
prompt.c | 24 +++++++++++++++++-------
1 files changed, 17 insertions(+), 7 deletions(-)
diff --git a/prompt.c b/prompt.c
index 64f817b..d851807 100644
--- a/prompt.c
+++ b/prompt.c
@@ -9,6 +9,7 @@ static char *do_askpass(const char *cmd, const char *prompt)
struct child_process pass;
const char *args[3];
static struct strbuf buffer = STRBUF_INIT;
+ int err = 0;
args[0] = cmd;
args[1] = prompt;
@@ -19,15 +20,21 @@ static char *do_askpass(const char *cmd, const char *prompt)
pass.out = -1;
if (start_command(&pass))
- exit(1);
+ return NULL;
if (strbuf_read(&buffer, pass.out, 20) < 0)
- die("failed to get '%s' from %s\n", prompt, cmd);
+ err = 1;
close(pass.out);
if (finish_command(&pass))
- exit(1);
+ err = 1;
+
+ if (err) {
+ error("unable to read askpass response from '%s'", cmd);
+ strbuf_release(&buffer);
+ return NULL;
+ }
strbuf_setlen(&buffer, strcspn(buffer.buf, "\r\n"));
@@ -36,7 +43,7 @@ static char *do_askpass(const char *cmd, const char *prompt)
char *git_prompt(const char *prompt, int flags)
{
- char *r;
+ char *r = NULL;
if (flags & PROMPT_ASKPASS) {
const char *askpass;
@@ -47,12 +54,15 @@ char *git_prompt(const char *prompt, int flags)
if (!askpass)
askpass = getenv("SSH_ASKPASS");
if (askpass && *askpass)
- return do_askpass(askpass, prompt);
+ r = do_askpass(askpass, prompt);
}
- r = git_terminal_prompt(prompt, flags & PROMPT_ECHO);
if (!r)
- die_errno("could not read '%s'", prompt);
+ r = git_terminal_prompt(prompt, flags & PROMPT_ECHO);
+ if (!r) {
+ /* prompts already contain ": " at the end */
+ die("could not read %s%s", prompt, strerror(errno));
+ }
return r;
}
--
1.7.9.rc1.28.gf4be5
^ permalink raw reply related
* Re: [PATCH] t0300-credentials: Word around a solaris /bin/sh bug
From: Junio C Hamano @ 2012-02-03 22:45 UTC (permalink / raw)
To: Jeff King; +Cc: Ben Walton, git
In-Reply-To: <20120203215507.GB3472@sigill.intra.peff.net>
Jeff King <peff@peff.net> writes:
>> 2) echo "#!$2" ;;
>> *) BUG ;;
>> esac >"$1" &&
>> cat >>"$1" &&
>> chmod +x "$1"
>> }
>>
>
> Nice. I was going to suggest a wrapper like "write_sh_script" so you
> didn't have to spell out $SHELL_PATH, but I think the auto-detection
> makes sense (and falling back to shell makes even more sense, as that
> covers 99% of the cases anyway).
Let's not over-engineer this and stick to the simple-stupid-sufficient.
Something like this?
t/test-lib.sh | 9 +++++++++
1 files changed, 9 insertions(+), 0 deletions(-)
diff --git a/t/test-lib.sh b/t/test-lib.sh
index bdd9513..1b9c461 100644
--- a/t/test-lib.sh
+++ b/t/test-lib.sh
@@ -379,6 +379,15 @@ test_config () {
git config "$@"
}
+# Prepare a script to be used in the test
+write_script () {
+ {
+ echo "#!${2-"$SHELL_PATH"}"
+ cat
+ } >"$1" &&
+ chmod +x "$1"
+}
+
# Use test_set_prereq to tell that a particular prerequisite is available.
# The prerequisite can later be checked for in two ways:
#
^ permalink raw reply related
* Re: Git performance results on a large repository
From: Sam Vilain @ 2012-02-03 22:40 UTC (permalink / raw)
To: Joshua Redstone
Cc: Ævar Arnfjörð Bjarmason, git@vger.kernel.org
In-Reply-To: <CB5179E9.3B751%joshua.redstone@fb.com>
Joshua,
You have an interesting use case.
If I were you I'd consider investigating the git fast-import protocol.
It has become bi–directional, and is essentially socket access to a git
repository with read and transactional update capability. With a few
more commands implemented, it may even be capable of providing all
functionality required for command–line git use.
It is already possible that the ".git" directory can be a file: this
case is used for submodules in git 1.7.8 and higher. For this use case,
there would be an extra field to the ".git" file which is created. It
would indicate the hostname (and port) to connect its internal
'fast-import' stream to. 'clone' would consist of creating this file,
and then getting the server to stream the objects from its pack to the
client.
With the hard–working part of git on the other end of a network service,
you could back it by a re–implementation of git which is written to be
distributed in Hadoop. There are at least two similar implementations
of git that are like this: one for cassandra which was written by github
as a research project, and Google's implementation on top of their
BigTable/GFS/whatever. As the git object storage model is write–only
and content–addressed, it should git this kind of scaling well.
There have also been designs at various times for sparse check–outs; ie
check–outs where you don't check out the root of the repository but a
sub–tree.
With both of these features, clients could easily check out a small part
of the repository very quickly. This is probably the only case which
SVN still does better than git at, which is a particular blocker for use
cases like repositories with large binaries in them and for projects
such as the one you have (another one with a similar problem was KDE,
where their projects moved around the repository a lot, and refactoring
touched many projects simultaneously at times).
It's a large undertaking, alright.
Sam,
just another git community propeller–head.
On 2/3/12 9:00 AM, Joshua Redstone wrote:
> Hi Ævar,
>
>
> Thanks for the comments. I've included a bunch more info on the test repo
> below. It is based on a growth model of two of our current repositories
> (I.e., it's not a perforce import). We already have some of the easily
> separable projects in separate repositories, like HPHP. If we could
> split our largest repos into multiple ones, that would help the scaling
> issue. However, the code in those repos is rather interdependent and we
> believe it'd hurt more than help to split it up, at least for the
> medium-term future. We derive a fair amount of benefit from the code
> sharing and keeping things together in a single repo, so it's not clear
> when it'd make sense to get more aggressive splitting things up.
>
> Some more information on the test repository: The working directory is
> 9.5 GB, the median file size is 2 KB. The average depth of a directory
> (counting the number of '/'s) is 3.6 levels and the average depth of a
> file is 4.6. More detailed histograms of the repository composition is
> below:
>
> ------------------------
>
> Histogram of depth of every directory in the repo (dirs=`find . -type d` ;
> (for dir in $dirs; do t=${dir//[^\/]/}; echo ${#t} ; done) |
> ~/tmp/histo.py)
> * The .git directory itself has only 161 files, so although included,
> doesn't affect the numbers significantly)
>
> [0.0 - 1.3): 271
> [1.3 - 2.6): 9966
> [2.6 - 3.9): 56595
> [3.9 - 5.2): 230239
> [5.2 - 6.5): 67394
> [6.5 - 7.8): 22868
> [7.8 - 9.1): 6568
> [9.1 - 10.4): 420
> [10.4 - 11.7): 45
> [11.7 - 13.0]: 21
> n=394387 mean=4.671830, median=5.000000, stddev=1.272658
>
>
> Histogram of depth of every file in the repo (files=`git ls-files` ; (for
> file in $files; do t=${file//[^\/]/}; echo ${#t} ; done) | ~/tmp/histo.py)
> * 'git ls-files' does not prefix entries with ./, like the 'find' command
> above, does, hence why the average appears to be the same as the directory
> stats
>
> [0.0 - 1.3]: 1274
> [1.3 - 2.6]: 35353
> [2.6 - 3.9]: 196747
> [3.9 - 5.2]: 786647
> [5.2 - 6.5]: 225913
> [6.5 - 7.8]: 77667
> [7.8 - 9.1]: 22130
> [9.1 - 10.4]: 1599
> [10.4 - 11.7]: 164
> [11.7 - 13.0]: 118
> n=1347612 mean=4.655750, median=5.000000, stddev=1.278399
>
>
> Histogram of file sizes (for first 50k files - this command takes a
> while): files=`git ls-files` ; (for file in $files; do stat -c%s $file ;
> done) | ~/tmp/histo.py
>
> [ 0.0 - 4.7): 0
> [ 4.7 - 22.5): 2
> [ 22.5 - 106.8): 0
> [ 106.8 - 506.8): 0
> [ 506.8 - 2404.7): 31142
> [ 2404.7 - 11409.9): 17837
> [ 11409.9 - 54137.1): 942
> [ 54137.1 - 256866.9): 53
> [ 256866.9 - 1218769.7): 18
> [ 1218769.7 - 5782760.0]: 5
> n=49999 mean=3590.953239, median=1772.000000, stddev=42835.330259
>
> Cheers,
> Josh
>
>
>
>
>
>
> On 2/3/12 9:56 AM, "Ævar Arnfjörð Bjarmason"<avarab@gmail.com> wrote:
>
>> On Fri, Feb 3, 2012 at 15:20, Joshua Redstone<joshua.redstone@fb.com>
>> wrote:
>>
>>> We (Facebook) have been investigating source control systems to meet our
>>> growing needs. We already use git fairly widely, but have noticed it
>>> getting slower as we grow, and we want to make sure we have a good story
>>> going forward. We're debating how to proceed and would like to solicit
>>> people's thoughts.
>>
>> Where I work we also have a relatively large Git repository. Around
>> 30k files, a couple of hundred thousand commits, clone size around
>> half a GB.
>>
>> You haven't supplied background info on this but it really seems to me
>> like your testcase is converting something like a humongous Perforce
>> repository directly to Git.
>>
>> While you /can/ do this it's not a good idea, you should split up
>> repositories at the boundaries code or data doesn't directly cross
>> over, e.g. there's no reason why you need HipHop PHP in the same
>> repository as Cassandra or the Facebook chat system, is there?
>>
>> While Git could better with large repositories (in particular applying
>> commits in interactive rebase seems to be to slow down on bigger
>> repositories) there's only so much you can do about stat-ing 1.3
>> million files.
>>
>> A structure that would make more sense would be to split up that giant
>> repository into a lot of other repositories, most of them probably
>> have no direct dependencies on other components, but even those that
>> do can sometimes just use some other repository as a submodule.
>>
>> Even if you have the requirement that you'd like to roll out
>> *everything* at a certain point in time you can still solve that with
>> a super-repository that has all the other ones as submodules, and
>> creates a tag for every rollout or something like that.
>
> N�����r��y���b�X��ǧv�^�){.n�+����ا�\x17��ܨ}���Ơz�&j:+v���\a����zZ+��+zf���h���~����i���z�\x1e�w���?����&�)ߢ^[fl===
^ permalink raw reply
* Re: [PATCH v4 02/13] column: add API to print items in columns
From: Junio C Hamano @ 2012-02-03 22:55 UTC (permalink / raw)
To: Nguyễn Thái Ngọc Duy; +Cc: git
In-Reply-To: <1328276078-27955-3-git-send-email-pclouds@gmail.com>
Nguyễn Thái Ngọc Duy <pclouds@gmail.com> writes:
> +struct string_list_item *add_cell_to_list(struct string_list *list,
> + int mode,
> + const char *string)
> +{
> + if (mode & COL_ENABLED)
> + return string_list_append(list, string);
> + return NULL;
> +}
> +
> +void print_cell(struct string_list *list, int mode, const char *string)
> +{
> + if (!add_cell_to_list(list, mode, string))
> + printf("%s\n", string);
> +}
I find these two functions showing an extremely bad taste in the code
design. "If we for some reason fail to add the string to the list, we
fallback to print it straight away" is the natural reading of this code,
but that is absolutly not the impression the author of this piece of
crap^Wcode wanted to give to its readers.
Am I being too ascestically perfectionist?
^ permalink raw reply
* Re: Git performance results on a large repository
From: Sam Vilain @ 2012-02-03 22:57 UTC (permalink / raw)
To: Joshua Redstone
Cc: Ævar Arnfjörð Bjarmason, git@vger.kernel.org
In-Reply-To: <4F2C6276.1070100@vilain.net>
On 2/3/12 2:40 PM, Sam Vilain wrote:
> As the git object storage model is write–only and content–addressed,
> it should git this kind of scaling well.
^^^
Could have sworn I typed 'suit' there. My fingers have auto–correct ;-)
Sam
^ 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