* Re: [RFC/PATCH 0/2] Commits with ancient timestamps
From: Junio C Hamano @ 2012-02-03 18:01 UTC (permalink / raw)
To: Thomas Rast; +Cc: git, Han-Wen Nienhuys
In-Reply-To: <87mx90yz5y.fsf@thomas.inf.ethz.ch>
Thomas Rast <trast@inf.ethz.ch> writes:
> Doing this just makes me wonder how important exactly the 1970-1975
> range is. Is there a notable software history from that era that can be
> recovered?
That is not really a valid question. People who wrote private stuff in
that era deserve to be users of Git, too.
> (Your [1/2] does not seem to parse negative offsets from the unix epoch,
> so anything before 1970 is still out.)
Yes, pre-epoch timestamps are also useful for projects like US
Constitution.
http://thread.gmane.org/gmane.comp.version-control.git/152433/focus=152725
For that, we would need to use and pass around time_t (or intmax_t if we
follow the reason why originally Linus chose to avoid time_t) throughout
the codebase. If you actually write commit objects that record pre-epoch
timestamps, however, they will become unreadable by the current versions
of Git (as they would not understand such a negative raw timestamp).
In any case, that is a goal for a much longer term.
But even after such a change happens, you still need a way for Git to
replay a raw timestamp stored in commit objects without regressing the
parse_date() interface too much. These two patches show one way to do so
with minimum disruption.
As an added bonus, with the second patch, the way to spell a raw timestamp
happens to become compatible with how GNU date accepts one, i.e.
$ date -d @1000000000
even though we do not have to encourage the use of this notation by humans,
tools and script writers may find it useful.
^ permalink raw reply
* Re: [PATCH, RFC] Fix build problems related to profile-directed optimization
From: Theodore Tso @ 2012-02-03 18:19 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Theodore Tso, git, Andi Kleen, Clemens Buchacher
In-Reply-To: <7vr4ycsbga.fsf@alter.siamese.dyndns.org>
On Feb 3, 2012, at 1:00 AM, Junio C Hamano wrote:
>
> * I am happy that this version handles this well:
>
> $ make PROFILE=BUILD install
>
> even though you did not advertise as such in INSTALL ;-).
I can mention it, although it will mean adding more verbiage about profile-directed optimization into the INSTALL.
My assumption was that people who did this would usually be installing into --prefix=/usr as root, but there certainly will be anal people like myself who want to install profile-optimized binaries into ~/bin. :-)
> * However, I think "clean" target should remove *.gcda unconditionally.
>
> $ make PROFILE=BUILD install ; make clean ; git clean -n -x | grep gcda
Will fix.
> * Running "make PROFILE=BUILD install" immediately after another one,
> without "make clean" in between, resulted in full rebuild and test
> before the second "install", which somewhat surprised me. I however do
> not think this is a big show-stopper problem.
Hmm… that surprises me too. If
make PROFILE=BUILD all
make PROFILE=BUILD install
works correctly, I don't understand why a second "make PROFILE=BUILD install" issued after the above sequence would result in complete rebuild and test pass, unless something in the "make install" rules is modifying the build tree as a side-effect of the install pass, which I'd argue is a bug. I'll take a look at it.
-- Ted
^ permalink raw reply
* Re: How best to handle multiple-authorship commits in GIT?
From: Junio C Hamano @ 2012-02-03 18:27 UTC (permalink / raw)
To: David Howells; +Cc: Valerie Aurora, git@vger.kernel.org, Rusty Russell
In-Reply-To: <4681.1328276820@redhat.com>
David Howells <dhowells@redhat.com> writes:
> Valerie Aurora <valerie.aurora@gmail.com> wrote:
>
>> And for a complete (meaningful) rewrite such as David has done, he
>> changes the commit authorship and adds a Signed-off-by for the
>> original author.
>
> Val[*] hasn't signed off all her patches, and indeed I've merged together some
> patches that she has signed off and some she hasn't. I can't simply add
> Signed-off-by her without her permission. However, if she's willing for me to
> add such lines, then I can do so.
>
>> Signed-off-by: Some Upstream Author
>> Signed-off-by: Maintainer or Merger (rewrote error handling)
>
> And if the changes are more than can be put in what's left of the line? I
> would've thought it would make more sense to do something like:
>
> Signed-off-by: Valerie Aurora <valerie.aurora@gmail.com> (Original author)
> Signed-off-by: David Howells <dhowells@redhat.com> (Further development)
>
> David
That all sounds sensible.
I personally think the "recognition" factor Valerie alluded to in one of
her earlier message is a real and important issue, but I do not think
adding arbitrary number of "author" headers to the commit object would
help very much to solve it, for various reasons:
* While we made it easy to run "git shortlog -s -n --since=3.months" and
congratulate himself with "I now am the third most active person!" for
anybody, Git itself does not ship an equally easy way to analyze other
kinds of contributions to your project. I am merely a bystander, but
if I recall correctly, there were discussions on how to recognize
contributions by bug-reporters and testers using the history stored in
Git on the kernel list. The types of contribution you would want to
recognize however would be different from project to project. For that
kind of analysis, you would be better off doing something like what
lwn.net does, mining the text from the message part of the log.
* Even if we limit the issue to "who wrote X" (replace X with the name of
any piece of software), taking "author" field as anything more than an
approximation would be asking for a trouble. Not all patches are of
equal impact and importance.
* You would also have to think about how you would present "git shortlog"
output if you updated Git to record more than one "author" field in the
commit header. If Valerie wrote 27 patches by herself, 33 patches
together with you sitting next to each other, 17 patches with somebody
else, how would the entries for her, you and the third person look
like? Or would combinations of "Valerie & David", "Valerie & the
third person", etc. have separate entries in the output?
In short, I would say that you should take the name recorded in the
"author" field nothing more than the primary contact for a particular
commit to be used in case others have question on it later.
^ permalink raw reply
* Re: [PATCH, RFC] Fix build problems related to profile-directed optimization
From: Andi Kleen @ 2012-02-03 18:39 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Ted Ts'o, git, Clemens Buchacher
In-Reply-To: <7vr4ycsbga.fsf@alter.siamese.dyndns.org>
Thanks everyone for improving this.
I should add that any improvements will depend on your compiler version.
I would also expect better numbers when combined with LTO in gcc 4.7,
but haven't tried so far.
BTW it would be really nice to figure out a subset of the test suite
that runs faster and gives similar speedup like the full one.
-Andi
--
ak@linux.intel.com -- Speaking for myself only
^ permalink raw reply
* Re: Problem pushing to a Novell share
From: Junio C Hamano @ 2012-02-03 19:33 UTC (permalink / raw)
To: git; +Cc: Rüdiger Kessel
In-Reply-To: <CAJ4nRM2+u9OcLgJBN7+_rv1OiXETGNhozAfvYtj=hVNTfCMxhQ@mail.gmail.com>
[jc: just forwarding to the list --- the msysgit list might have been a
better place to forward to, but I know msysgit folks read this list too,
so...]
Rüdiger Kessel <ruediger.kessel@gmail.com> writes:
I have confimed that it is not a mingw problem. Direct calls to
CreateFile() in kernel32.dll show the same behaviour.
On a Novel share I get Error 80 "File exists" if a directory does not
exist, while I get Error 3 "Path not found" on a local drive
2012/2/3 Rüdiger Kessel <ruediger.kessel@gmail.com>:
Well, it is a Novell bug, but what can we do?
I studied it in detail and open() sets errno=EEXIST if the directory
is missing on a Novell share causing git_mkstemp_mode looping 16k
times and never creates the dir.
The correct errno would be ENOENT, but that not what the systems is sending.
So it is either using stat on the directory before trying to create
the tmp-file or GIT cannot be used with Novell shares. What is it
going to be?
Protocolling the mkdir error handling I saw that git creates quite a
number of new directories this way. Therefore my pessimistic approach
might be too costly at the end.
^ permalink raw reply
* Re: [ANNOUNCE] Git 1.7.9
From: Junio C Hamano @ 2012-02-03 19:41 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <201202031352.10279.jnareb@gmail.com>
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.
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 ;-)
^ permalink raw reply
* Re: How best to handle multiple-authorship commits in GIT?
From: Valerie Aurora @ 2012-02-03 19:49 UTC (permalink / raw)
To: David Howells; +Cc: git@vger.kernel.org, Rusty Russell
In-Reply-To: <4681.1328276820@redhat.com>
On Fri, Feb 3, 2012 at 5:47 AM, David Howells <dhowells@redhat.com> wrote:
> Valerie Aurora <valerie.aurora@gmail.com> wrote:
>
>> And for a complete (meaningful) rewrite such as David has done, he
>> changes the commit authorship and adds a Signed-off-by for the
>> original author.
>
> Val[*] hasn't signed off all her patches, and indeed I've merged together some
> patches that she has signed off and some she hasn't. I can't simply add
> Signed-off-by her without her permission. However, if she's willing for me to
> add such lines, then I can do so.
Cc me on the next posting and I'll review and add my Signed-off-by if
it's missing anywhere it should be? Or send them privately, whichever
you prefer.
-VAL
^ permalink raw reply
* Re: [PATCH, RFC] Fix build problems related to profile-directed optimization
From: Junio C Hamano @ 2012-02-03 19:58 UTC (permalink / raw)
To: Theodore Tso; +Cc: git, Andi Kleen, Clemens Buchacher
In-Reply-To: <BEE56B27-1C86-4C26-A584-3FF179B7A3D6@mit.edu>
Theodore Tso <tytso@MIT.EDU> writes:
> On Feb 3, 2012, at 1:00 AM, Junio C Hamano wrote:
>
>>
>> * I am happy that this version handles this well:
>>
>> $ make PROFILE=BUILD install
>>
>> even though you did not advertise as such in INSTALL ;-).
>
> I can mention it, although it will mean adding more verbiage about
> profile-directed optimization into the INSTALL.
Oh, sorry, I didn't mean it that way. Please read it as: "Something that
is a natural thing for people to expect after reading what is in INSTALL
works correctly. Yay! Thanks."
^ permalink raw reply
* 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
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