* Re: git init --bare --shared=group
From: Johannes Schindelin @ 2009-11-24 13:25 UTC (permalink / raw)
To: Eric Schaefer; +Cc: Git Mailing List
In-Reply-To: <34f8975d0911240505k4727fef2n8ef0efd3533aef1e@mail.gmail.com>
Hi,
On Tue, 24 Nov 2009, Eric Schaefer wrote:
> according to 'git help init' would --shared=group "Make the repository
> group-writable".
> I extracted a bare repo out of my local repo and scp'ed it to the
> server. There I did a 'git init --bare --shared=group'. It created the
> branches dir (there were no branches yet) and the config file and set
> the correct permissions. But it did not do so with the existsing files
> and dirs. Is it suffient to 'chmod -R g+ws .' or is there anything
> else to do to make the repo writeable for my group?
That should be enough, if all files and directories belong to the correct
group. Otherwise, you should 'chown -R .group .', too.
Ciao,
Dscho
^ permalink raw reply
* [PATCH] shortlog: respect commit encoding
From: Uwe Kleine-König @ 2009-11-24 15:12 UTC (permalink / raw)
To: git; +Cc: Jiri Kosina
In-Reply-To: <20091111141342.GA1849@pengutronix.de>
Before this change the author was taken from the raw commit without
reencoding.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Cc: Jiri Kosina <jkosina@suse.cz>
---
builtin-shortlog.c | 25 +++++++++++++++----------
t/t4201-shortlog.sh | 24 ++++++++++++++++++++++++
2 files changed, 39 insertions(+), 10 deletions(-)
diff --git a/builtin-shortlog.c b/builtin-shortlog.c
index 8aa63c7..050bda8 100644
--- a/builtin-shortlog.c
+++ b/builtin-shortlog.c
@@ -139,14 +139,19 @@ static void read_from_stdin(struct shortlog *log)
void shortlog_add_commit(struct shortlog *log, struct commit *commit)
{
const char *author = NULL, *buffer;
+ struct strbuf buf = STRBUF_INIT;
+ struct strbuf ufbuf = STRBUF_INIT;
+ struct pretty_print_context ctx = {0};
- buffer = commit->buffer;
+ pretty_print_commit(CMIT_FMT_RAW, commit, &buf, &ctx);
+
+ buffer = buf.buf;
while (*buffer && *buffer != '\n') {
const char *eol = strchr(buffer, '\n');
- if (eol == NULL)
+ if (eol == NULL) {
eol = buffer + strlen(buffer);
- else
+ } else
eol++;
if (!prefixcmp(buffer, "author "))
@@ -157,20 +162,20 @@ void shortlog_add_commit(struct shortlog *log, struct commit *commit)
die("Missing author: %s",
sha1_to_hex(commit->object.sha1));
if (log->user_format) {
- struct strbuf buf = STRBUF_INIT;
struct pretty_print_context ctx = {0};
ctx.abbrev = DEFAULT_ABBREV;
ctx.subject = "";
ctx.after_subject = "";
ctx.date_mode = DATE_NORMAL;
- pretty_print_commit(CMIT_FMT_USERFORMAT, commit, &buf, &ctx);
- insert_one_record(log, author, buf.buf);
- strbuf_release(&buf);
- return;
- }
- if (*buffer)
+ pretty_print_commit(CMIT_FMT_USERFORMAT, commit, &ufbuf, &ctx);
+ buffer = ufbuf.buf;
+
+ } else if (*buffer)
buffer++;
+
insert_one_record(log, author, !*buffer ? "<none>" : buffer);
+ strbuf_release(&ufbuf);
+ strbuf_release(&buf);
}
static void get_from_rev(struct rev_info *rev, struct shortlog *log)
diff --git a/t/t4201-shortlog.sh b/t/t4201-shortlog.sh
index 405b971..118204b 100755
--- a/t/t4201-shortlog.sh
+++ b/t/t4201-shortlog.sh
@@ -51,5 +51,29 @@ git log HEAD > log
GIT_DIR=non-existing git shortlog -w < log > out
test_expect_success 'shortlog from non-git directory' 'test_cmp expect out'
+iconvfromutf8toiso885915() {
+ printf "%s" "$@" | iconv -f UTF-8 -t ISO-8859-15
+}
+
+git reset --hard "$commit"
+git config --unset i18n.commitencoding
+echo 2 > a1
+git commit --quiet -m "set a1 to 2 and some non-ASCII chars: Äßø" --author="Jöhännës \"Dschö\" Schindëlin <Johannes.Schindelin@gmx.de>" a1
+
+git config i18n.commitencoding "ISO-8859-15"
+echo 3 > a1
+git commit --quiet -m "$(iconvfromutf8toiso885915 "set a1 to 3 and some non-ASCII chars: áæï")" --author="$(iconvfromutf8toiso885915 "Jöhännës \"Dschö\" Schindëlin <Johannes.Schindelin@gmx.de>")" a1
+git config --unset i18n.commitencoding
+
+git shortlog HEAD~2.. > out
+
+cat > expect << EOF
+Jöhännës "Dschö" Schindëlin (2):
+ set a1 to 2 and some non-ASCII chars: Äßø
+ set a1 to 3 and some non-ASCII chars: áæï
+
+EOF
+
+test_expect_success 'shortlog encoding' 'test_cmp expect out'
test_done
--
1.6.5.3
^ permalink raw reply related
* more problems with commit encoding [Was: [PATCH] shortlog: respect commit encoding]
From: Uwe Kleine-König @ 2009-11-24 16:08 UTC (permalink / raw)
To: git; +Cc: Jiri Kosina
In-Reply-To: <1259075555-7831-1-git-send-email-u.kleine-koenig@pengutronix.de>
Hello,
On Tue, Nov 24, 2009 at 04:12:35PM +0100, Uwe Kleine-König wrote:
> Before this change the author was taken from the raw commit without
> reencoding.
while at it, userformats have the same problem:
linux-2.6$ for rev in b71a8eb bc9be01; do git show --format=%an $rev | head -n1; git show $rev | grep Auth; done
Uwe Kleine-K�nig
Author: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Uwe Kleine-König
Author: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
That is, git show correctly reencodes its output for b71a8eb, but only
without --format=...
(The patches above are in linux-next.)
And now take this (assuming locale and commitencoding are utf-8):
git init
git config user.name 'Jöhännës Dschö'
echo spam > ham
git add ham
git commit -m 'initial commit'
git branch branch
echo more spam > ham
git add ham
git commit -m "Commitlog matching '\nencoding:'
encoding: latin1
"
git checkout branch
echo much more spam > ham
git add ham
git commit -C master
git show | grep Author:
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-König |
Industrial Linux Solutions | http://www.pengutronix.de/ |
^ permalink raw reply
* insecurity in verify-tag?
From: David Roundy @ 2009-11-24 16:56 UTC (permalink / raw)
To: git
[-- Attachment #1: Type: text/plain, Size: 2070 bytes --]
I've just been looking at the code and I see what looks like a (minor)
security hole in the verify-tag feature. In particular, the tag
verification code doesn't check that the tag is signed by the same
user that created the tag. To be fair, gpg does output the identity
of the key that created the signature as well as the key used to
create the signature, so an astute user could detect that some
shenanigans is going on.
An attack would simply require getting one's own public key into the
keyring of a user. This probably wouldn't be very easy at the moment,
but if people were to actually use encrypted email (and if they set
their mail agents to download public keys), it might require no more
then sending a signed email to a mailing list.
Of course, you'd also somehow have to trick them into pulling (or
cloning) your corrupt tag, which probably requires compromising a
server (or mirror) somewhere. But of course, the whole point of
signing tags is to eliminate precisely this danger.
What should be done about this? First, there ought to be a feature to
limit git verify-tag to use a specific keyring. Maybe there is an
environment variable, and it's just not documented in the man page?
It would also seem like a good idea to at a minimum check that the
name/email associated with the signature is the same as that of the
tagger. This doesn't gain you *too* much, since an attacker can
always create his own key with any name and email he likes, but at
least it means that users could feel safe adding keys to their public
keyring, as long as those keys have reasonable names/emails associated
with them, and as long as they run git show on a tag before trusting
that that tag came from a particular person. i.e. it seems reasonable
for me to expect that if I run:
$ git show v1.0
tag v1.0
Tagger: Linus Torvalds ...
...
[user carefully reads the Tagger line...]
$ git verify-tag v1.0 && make
That I won't be running make on a repository that wasn't signed by a
key that at least *claims* to belong to Linus Torvalds.
Thoughts?
--
David Roundy
[-- Attachment #2: tagtest.txt --]
[-- Type: text/plain, Size: 1496 bytes --]
mkdir temp
cd temp
git init
Initialized empty Git repository in /tmp/temp/.git/
date > foo
git add foo
export GIT_AUTHOR_NAME="Someone else"
export GIT_AUTHOR_EMAIL="notme@example.com"
export GIT_COMMITTER_NAME="Linus Torvalds"
export GIT_COMMITTER_EMAIL="linus@example.com"
git commit -m 'hello world'
Created initial commit dc3b7e9: hello world
1 files changed, 1 insertions(+), 0 deletions(-)
create mode 100644 foo
git tag -u droundy -m foo v1.0
gpg: Invalid passphrase; please try again ...
gpg: Invalid passphrase; please try again ...
git verify-tag v1.0
gpg: Signature made Tue 24 Nov 2009 11:41:49 AM EST using DSA key ID D3D5BCEC
gpg: Good signature from "David Roundy <roundyd@physics.oregonstate.edu>"
gpg: aka "David Roundy <droundy@darcs.net>"
gpg: aka "David Roundy <droundy@abridgegame.org>"
gpg: aka "David Roundy <daveroundy@gmail.com>"
git show v1.0
tag v1.0
Tagger: Linus Torvalds <linus@example.com>
Date: Tue Nov 24 11:41:49 2009 -0500
foo
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
iEYEABECAAYFAksMDM0ACgkQQ6uZI9PVvOyXFQCgoc4UYfNFYzVH4HduLdh9VUc/
NSkAn05yr/ARnWGUC8I/OmjhZJEjG5Oa
=ro48
-----END PGP SIGNATURE-----
commit dc3b7e9f8f5c49bdfe8816abdb4bb392c30e3ef5
Author: Someone else <notme@example.com>
Date: Tue Nov 24 11:41:49 2009 -0500
hello world
diff --git a/foo b/foo
new file mode 100644
index 0000000..c1857fa
--- /dev/null
+++ b/foo
@@ -0,0 +1 @@
+Tue Nov 24 11:41:49 EST 2009
^ permalink raw reply related
* Re: [PATCH] t/gitweb-lib: Split HTTP response with non-GNU sed
From: Jakub Narebski @ 2009-11-24 16:59 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Brian Gernhardt, Git List
In-Reply-To: <7vocmtyu3v.fsf@alter.siamese.dyndns.org>
On Mon, 23 Nov 2009, Junio C Hamano wrote:
> Brian Gernhardt <brian@gernhardtsoftware.com> writes:
>
> > Recognizing \r in a regex is something GNU sed will do, but other sed
> > implementation's won't. (Found with BSD sed on OS X.) So use a
> > literal carriage return instead.
[...]
> > diff --git a/t/gitweb-lib.sh b/t/gitweb-lib.sh
> > index 32b841d..35dda58 100644
> > --- a/t/gitweb-lib.sh
> > +++ b/t/gitweb-lib.sh
> > @@ -52,8 +52,8 @@ gitweb_run () {
> > rm -f gitweb.log &&
> > perl -- "$SCRIPT_NAME" \
> > >gitweb.output 2>gitweb.log &&
> > - sed -e '/^\r$/q' <gitweb.output >gitweb.headers &&
> > - sed -e '1,/^\r$/d' <gitweb.output >gitweb.body &&
> > + sed -e '/^
> > $/q' <gitweb.output >gitweb.headers &&
> > + sed -e '1,/^
> > $/d' <gitweb.output >gitweb.body &&
> > if grep '^[[]' gitweb.log >/dev/null 2>&1; then false; else
> > true; fi
> > # gitweb.log is left for debugging
If we were to do it this way, I would prefer to set and then use
'cr' or 'crlf' variable (in sed expression).
>
> I'd actually prefer not having to deal with this issue. How about doing
> something like this instead?
>
> t/gitweb-lib.sh | 14 ++++++++++++--
> 1 files changed, 12 insertions(+), 2 deletions(-)
>
> diff --git a/t/gitweb-lib.sh b/t/gitweb-lib.sh
> index 32b841d..3121950 100644
> --- a/t/gitweb-lib.sh
> +++ b/t/gitweb-lib.sh
> @@ -52,8 +52,18 @@ gitweb_run () {
> rm -f gitweb.log &&
> perl -- "$SCRIPT_NAME" \
> >gitweb.output 2>gitweb.log &&
> - sed -e '/^\r$/q' <gitweb.output >gitweb.headers &&
> - sed -e '1,/^\r$/d' <gitweb.output >gitweb.body &&
> + perl -w -e '
"perl", or "$PERL", or "$PERL_PATH"?
> + open O, ">gitweb.headers";
Well, modern Perl would use here
+ open my $fh, ">", "gitweb.headers";
But it is not that important here.
> + while (<>) {
> + print O;
> + last if (/^\r$/ || /^$/);
> + }
> + open O, ">gitweb.body";
> + while (<>) {
> + print O;
> + }
> + close O;
> + ' gitweb.output &&
> if grep '^[[]' gitweb.log >/dev/null 2>&1; then false; else true; fi
>
> # gitweb.log is left for debugging
>
This is a good solution. We test Perl script anyway (so Perl is required
for running this test), and this way we can do this portably and in one
pass (one fork).
--
Jakub Narebski
Poland
^ permalink raw reply
* Git over cvs
From: Michael J Gruber @ 2009-11-24 17:07 UTC (permalink / raw)
To: Git Mailing List
Hi there,
I got so annoyed by (my own incompetence using) cvs on mozdev that I got
myself to use git cvsimport/cvsexportcommit now, just shortly before it
gets obsoleted by the new shiny remote helpers, and knowing how many
failing tests we have for it now.
Setting up a convenient roundtrip with minimal exposure to cvs required
collecting some scattered info. I thought this makes a good first blog
entry (the one after the zeroth) for reference, so in case anyone is
interested:
http://grubix.blogspot.com/2009/11/git-over-cvs.html
I guess it does require some acquaintance with Git, that's intentional.
(In short it uses the combined work tree, -W approach.)
Cheers,
Michael
P.S.: There's AdSense on there. I assume you block it anyway using
NoScript, AdBlock etc. if you don't like it.
^ permalink raw reply
* git tag listing order
From: Peter van der Does @ 2009-11-24 15:56 UTC (permalink / raw)
To: git
I'm using git 1.6.5.3 on Ubuntu and was wondering if there is a way to
list tags in order of when they were added to the tree, instead of
alphabetical?
--
Peter van der Does
GPG key: E77E8E98
Twitter: @petervanderdoes
git Ubuntu Packages:
http://blog.avirtualhome.com/git-packages-for-ubuntu/
^ permalink raw reply
* Re: [PATCH] send-email: new 'add-envelope' option
From: Felipe Contreras @ 2009-11-24 17:28 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jeff King, git
In-Reply-To: <7v7htice04.fsf@alter.siamese.dyndns.org>
On Mon, Nov 23, 2009 at 1:54 AM, Junio C Hamano <gitster@pobox.com> wrote:
> Felipe Contreras <felipe.contreras@gmail.com> writes:
>> a) --add-envelope: add the sender envelope, by default it would be the
>> 'from' address, but could be overridden by --envelope-sender.
>
> I do not think the latter half of this description makes much sense, as
> the existing --envelope-sender=<this-address> alone already says "add this
> envelope sender".
--envelope-sender=foo@bar.com would imply --add-envelope.
> It is unfortunate that we cannot sanely have an option that takes an
> optional string argument from the command line. Ideally, if we can
> specify --envelope-sender without any argument, we could make it to mean
> "pretend as if the 'from' address is given to this option", but that would
> make the command line pasing ambiguous, so we would need an extra option
> like this one. "--envelope-sender=from" might be a more intuitive way to
> say this, though.
I agree, but --envelope-sender=from looks a bit strange to me.
>> b) --envelope-sender="" or "auto": this would require minimal changes
>> but looks a bita strange.
>
> An explicit empty string does look very strange, but I do not think a
> magic word like "auto" (or "from") that cannot sanely be your envelope
> sender address is a bad idea.
I think "auto" is the least worst option right now.
>> Any thoughts?
>
> It is much easier to work on the configuration front, by the way, and I
> expect people who regularly interact with multiple projects to appreciate
> this feature would configure their send-email once and forget about it, so
> the command line clunkiness might not be such a big issue.
>
> A user who works with more than one projects with different identity known
> to each project would use $HOME/.gitconfig and send-email configuration
> identity feature to set "sendemail.<identity>.from" and friends in there,
> while setting sendemail.identity configuration in .git/config for each
> project, so being able to say "use whatever 'from' as the envelope sender"
> once in $HOME/.gitconfig would be convenient.
>
> So I could have in $HOME/.gitconfig:
>
> [sendemail]
> ; used as a boolean to say "use from"
> envelopesender
> [sendemail.git]
> from = Junio C Hamano <gitster@pobox.com>
> to = git mailing list <git@vger.kernel.org>
> [sendemail.frotz]
> from = Junio C Hamano <frotzster@example.xz>
> to = frotz mailing list <frotz@example.xz>
>
> and then in my {git,frotz}.git/.git/config would have
>
> [sendemail] [sendemail]
> identity = git identity = frotz
>
> respectively. Without your patch, in $HOME/.gitconfig, I wouldn't have
> the global sendemail.envelopesender but have separate individual
> configuration variables sendemail.{git,frotz}.envelopesender defined.
I also thought about having an identity (profile) for sendmail; it
would be very useful to specify the smtp server, aliases file, and
from address that multiple repositories can share and can be easily
changed (working for my company vs working for myself).
However, even in this case I would like to have a global option to add
the sender automatically from the 'from' address.
--
Felipe Contreras
^ permalink raw reply
* Re: [PATCH RFC] git-send-email --expand-aliases
From: Alex Chiang @ 2009-11-24 18:46 UTC (permalink / raw)
To: Catalin Marinas; +Cc: Karl Wiberg, Junio C Hamano, git
In-Reply-To: <b0943d9e0911240243m13730f0bw34f2f18cf41f9079@mail.gmail.com>
* Catalin Marinas <catalin.marinas@gmail.com>:
> 2009/11/24 Karl Wiberg <kha@treskal.com>:
> > On Tue, Nov 24, 2009 at 1:45 AM, Alex Chiang <achiang@hp.com> wrote:
> >> * Junio C Hamano <gitster@pobox.com>:
> >> > I imagine the internal implementation of stg mail would work
> >> > something like:
> >> >
> >> > prepare messages to send out
> >> > call git-send-email and have it send them
> >> >
> >> > What am I missing?
> >>
> >> Your suggestion is much better. I'll take a closer look at StGit and
> >> see how feasible it is.
> >>
> >> Unless Catalin has strong objections?
> >
> > I think that sounds like a splendid idea. It would be interesting to
> > see just how thin a wrapper around git send-email (and format-patch)
> > stg mail could become, without sacrificing features anyone actually
> > uses. The main complication could be stg mail's templates.
> >
> > Catalin, how wedded are you to those? ;-)
>
> Historically, I think "stg mail" was implemented before git-send-email
> existed. It was also a good way to check who's using stgit for sending
> patches :-) (the message-id).
Heh, I like looking at that too. ;)
> If there are no other users of the stg mail templates, I'm happy to
> let them go. Otherwise, we can replace the sendmail with
> git-send-email in stgit.
>
> It seems that git-format-patch and git-send-email have all the
> features stgit has. We would need to keep some of the interactive
> options like --edit-cover and --edit-patches since we use
> git-format-patch and git-send-email in one go.
So, is this something you (or Karl) plan on doing? Or should I
take a crack at it?
I don't mind doing the work, but it will definitely take me
longer than it would take you.
All I was doing was trying to get stg mail to understand my mutt
aliases. ;)
Thanks,
/ac
^ permalink raw reply
* Re: git tag listing order
From: Jeff King @ 2009-11-24 19:00 UTC (permalink / raw)
To: Peter van der Does; +Cc: git
In-Reply-To: <20091124105609.0980e796@montecarlo.grandprix.int>
On Tue, Nov 24, 2009 at 10:56:09AM -0500, Peter van der Does wrote:
> I'm using git 1.6.5.3 on Ubuntu and was wondering if there is a way to
> list tags in order of when they were added to the tree, instead of
> alphabetical?
You can use for-each-ref with its sort option:
git for-each-ref --sort=taggerdate --format='%(refname:short)' refs/tags
Though note that unannotated tags will have no taggerdate, and will all
sort to the front of the list. To exclude them, I think you'd have to
use a special format to grep and sort yourself. Something like:
git for-each-ref \
--format='%(taggerdate:iso8601) %(refname:short)' refs/tags |
grep -v '^ ' |
sort |
cut -d' ' -f4-
-Peff
^ permalink raw reply
* Private remote repo setup
From: Derek D @ 2009-11-24 19:04 UTC (permalink / raw)
To: git
Hi all, I am new to Git and I am getting quite frustrated with setting a repo
on my server so that people with Windows machines can ssh to it and contribute.
This is what I am doing:
On the server:
#git --bare init
Initialized empty Git repository in /opt/apps/git-test/
In tortoiseGIT I go to git clone, provide correct url:
ssh://user@domain/opt/apps/git-test/
tortoiseGIT asks me for a password, I provide it, it's correct, the repository
gets created on the local machine and...
fatal: '/opt/apps/git-test': unable to chdir or not a git archive
Initialized empty Git repository in C:/path/.git/
fatal: The remote end hung up unexpectedly
Failed
What happened there?
^ permalink raw reply
* Re: [PATCH RFC] git-send-email --expand-aliases
From: Karl Wiberg @ 2009-11-24 19:08 UTC (permalink / raw)
To: Alex Chiang; +Cc: Catalin Marinas, Junio C Hamano, git
In-Reply-To: <20091124184629.GB27418@ldl.fc.hp.com>
On Tue, Nov 24, 2009 at 7:46 PM, Alex Chiang <achiang@hp.com> wrote:
> * Catalin Marinas <catalin.marinas@gmail.com>:
>
> > If there are no other users of the stg mail templates, I'm happy
> > to let them go. Otherwise, we can replace the sendmail with
> > git-send-email in stgit.
> >
> > It seems that git-format-patch and git-send-email have all the
> > features stgit has. We would need to keep some of the interactive
> > options like --edit-cover and --edit-patches since we use
> > git-format-patch and git-send-email in one go.
>
> So, is this something you (or Karl) plan on doing? Or should I take
> a crack at it?
I wasn't planning to do it, at least. I haven't had much time for
StGit lately, but when I do there are other things I was planning to
fix before this.
If you feel like trying, please go ahead. I'll be happy to assist.
> I don't mind doing the work, but it will definitely take me longer
> than it would take you.
>
> All I was doing was trying to get stg mail to understand my mutt
> aliases. ;)
Yeah, sorry about that. ;-)
Seriously, though, doing just what you started out wanting to do would
be fine too. If you decide to do the larger project, it shouldn't be
because we made you feel you had to.
--
Karl Wiberg, kha@treskal.com
subrabbit.wordpress.com
www.treskal.com/kalle
^ permalink raw reply
* Re: git tag listing order
From: Peter van der Does @ 2009-11-24 19:24 UTC (permalink / raw)
To: git
In-Reply-To: <20091124185947.GA24409@coredump.intra.peff.net>
On Tue, 24 Nov 2009 14:00:23 -0500
Jeff King <peff@peff.net> wrote:
> On Tue, Nov 24, 2009 at 10:56:09AM -0500, Peter van der Does wrote:
>
> > I'm using git 1.6.5.3 on Ubuntu and was wondering if there is a way
> > to list tags in order of when they were added to the tree, instead
> > of alphabetical?
>
> You can use for-each-ref with its sort option:
>
> git for-each-ref --sort=taggerdate --format='%(refname:short)'
> refs/tags
>
> Though note that unannotated tags will have no taggerdate, and will
> all sort to the front of the list. To exclude them, I think you'd
> have to use a special format to grep and sort yourself. Something
> like:
>
> git for-each-ref \
> --format='%(taggerdate:iso8601) %(refname:short)' refs/tags |
> grep -v '^ ' |
> sort |
> cut -d' ' -f4-
>
> -Peff
> --
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
Thanks for the info, just what I was looking for.
--
Peter van der Does
GPG key: E77E8E98
Twitter: @petervanderdoes
git Ubuntu Packages:
http://blog.avirtualhome.com/git-packages-for-ubuntu/
^ permalink raw reply
* Re: [PATCH] git-count-objects: Fix a disk-space under-estimate on Cygwin
From: Ramsay Jones @ 2009-11-24 20:07 UTC (permalink / raw)
To: Junio C Hamano; +Cc: GIT Mailing-list
In-Reply-To: <7veinrnym4.fsf@alter.siamese.dyndns.org>
Junio C Hamano wrote:
> Ramsay Jones <ramsay@ramsay1.demon.co.uk> writes:
>
>> I haven't tried this patch, but I think you may need to add something like
>> the following (*not tested*):
>>
>> --- >8 ---
>> diff --git a/compat/cygwin.c b/compat/cygwin.c
>> index b4a51b9..7e9edec 100644
>> --- a/compat/cygwin.c
>> +++ b/compat/cygwin.c
>> @@ -53,6 +53,7 @@ static int do_stat(const char *file_name, struct stat *buf, stat_fn_t cygstat)
>> buf->st_size = (off_t)fdata.nFileSizeLow;
>> #endif
>> buf->st_blocks = size_to_blocks(buf->st_size);
>> + buf->st_blksize = 512;
>> filetime_to_timespec(&fdata.ftLastAccessTime, &buf->st_atim);
>> filetime_to_timespec(&fdata.ftLastWriteTime, &buf->st_mtim);
>> filetime_to_timespec(&fdata.ftCreationTime, &buf->st_ctim);
>> --- >8 ---
>
> Doesn't this contradict with everything you said?
Err... no :-D
Note that my suggested addition to your patch is in the core.filemode == false
code path, and so does not affect the "disk-space under-estimate" problem at all.
[To be clear: the "disk-space under-estimate" problem only happens when
core.filemode == true and the regular cygwin lstat()/stat() functions are used.
When core.filemode == false, the code in compat/cygwin.c (namely cygwin_lstat()
and cygwin_stat()) will (most likely) be called instead. These functions use
WIN32 api calls to implement equivalent, but presumably faster, versions of the
stat functions]
> You are forcing st_blksize to 512 but still return the same old st_blocks;
> I do not understand what that would achieve.
Well, as I said, I haven't tested your patch, or my suggested addition, so I could
well be wrong... but what I aimed to achieve was to:
- avoid "undefined behaviour" in on_disk_bytes(), since the value in
st_blksize would otherwise be undefined (ie whatever happened to be
on the stack-frame of the count_objects() function).
- initialize the st_blksize field with a value consistent with the
st_blocks field, which is derived from the st_size field, as the
number of 512-byte blocks. (see the context line just before the
+ line in the above diff, along with the size_to_blocks macro)
- return the same answer from this code as before.
Note that the answer returned from this core.filemode == false code path
is different to the core.filemode == true code path. Which is why I *slightly*
prefer my original patch.
HTH.
ATB,
Ramsay Jones
^ permalink raw reply
* git-subtree: directory mismatch
From: Marc Fournier @ 2009-11-24 19:53 UTC (permalink / raw)
To: Avery Pennarun; +Cc: git
Hi,
I've come across this weird behaviour using git-subtree: when updating a
directory created by git-subtree, the content of some (almost) random
neighbour directory gets replaced, instead of the directory specified by
"git-subtree --prefix".
mkdir /tmp/testrepo
cd /tmp/testrepo
git init .
mkdir -p modules/cognac/{manifests,files}
mkdir -p modules/cognac/manifests/{classes,definitions}
touch modules/cognac/README modules/cognac/manifests/classes/foo.pp
modules/cognac/manifests/definitions/bar.pp modules/cognac/files/blabla
git add modules/
git commit -m "test"
git remote add mapserver git://github.com/camptocamp/puppet-mapserver.git
git remote update
git-subtree add --prefix modules/mapserver 97f5985b # an older commit
# So far so good, I have 2 subdirectories in modules/ with completely
# different content.
# Then, the content of modules/cognac/ gets completely replaced by the
# content of HEAD from git://github.com/camptocamp/puppet-mapserver.git.
# modules/mapserver still contains the content of commit 97f5985b.
git-subtree pull --prefix modules/mapserver mapserver master
>From git://github.com/camptocamp/puppet-mapserver
* branch master -> FETCH_HEAD
Removing modules/cognac/files/blabla
Removing modules/cognac/manifests/classes/foo.pp
Removing modules/cognac/manifests/definitions/bar.pp
Merge made by subtree.
modules/cognac/files/apt-preferences | 3 +
modules/cognac/files/epsg.C2C | 5445 ++++++++++++++++++++
modules/cognac/files/epsg.legacy | 5445 ++++++++++++++++++++
modules/cognac/files/epsg.minimal | 14 +
modules/cognac/files/etc/apt/preferences-20070910 | 3 +
modules/cognac/files/etc/apt/preferences-20080225 | 35 +
modules/cognac/files/etc/apt/preferences-v5-2 | 35 +
modules/cognac/manifests/classes/epsg.pp | 21 +
.../cognac/manifests/classes/mapserver-debian.pp | 82 +
modules/cognac/manifests/classes/v5.pp | 46 +
modules/cognac/manifests/init.pp | 8 +
11 files changed, 11137 insertions(+), 0 deletions(-)
create mode 100644 modules/cognac/files/apt-preferences
delete mode 100644 modules/cognac/files/blabla
create mode 100755 modules/cognac/files/epsg.C2C
create mode 100755 modules/cognac/files/epsg.legacy
create mode 100644 modules/cognac/files/epsg.minimal
create mode 100644 modules/cognac/files/etc/apt/preferences-20070910
create mode 100644 modules/cognac/files/etc/apt/preferences-20080225
create mode 100644 modules/cognac/files/etc/apt/preferences-v5-2
create mode 100644 modules/cognac/manifests/classes/epsg.pp
delete mode 100644 modules/cognac/manifests/classes/foo.pp
create mode 100644 modules/cognac/manifests/classes/mapserver-debian.pp
create mode 100644 modules/cognac/manifests/classes/v5.pp
delete mode 100644 modules/cognac/manifests/definitions/bar.pp
create mode 100644 modules/cognac/manifests/init.pp
I was not able to reproduce this bug in any of the following cases:
- if the README file wasn't empty
- if modules/cognac is renamed to something else
- if modules/cognac doesn't have the same sub-directories than
modules/mapserver
This bug happens using git 1.5.5.6 as well as 1.6.5. It seems to happen
when git-subtree calls "git merge -s subtree".
Maybe something is broken in this puppet-mapserver.git repository I use ?
I've encountered the same problem with other directories too.
Any idea ?
Thanks !
Marc
^ permalink raw reply
* Re: Android needs repo, Chrome needs gclient. Neither work. What does that say about git?
From: Daniel Barkalow @ 2009-11-24 20:45 UTC (permalink / raw)
To: Adrian May; +Cc: tytso, git, chromium-discuss
In-Reply-To: <65e170e70911231948l3b032dbeu7c99b65ce3ec97ff@mail.gmail.com>
On Tue, 24 Nov 2009, Adrian May wrote:
> > If you don't have bolt-on scripts, and you move that into the the core
> > SCM, then you force *all* projects to use whatever workflow was
> > decided as being the One True Way of doing things as seen by the SCM
> > designer. So the question is whether the SCM *should* regiment all
> > projects into following the SCM's designers idea of the One True
> > Workflow.
>
> Of course I'd want the workflow configurable by whoever controls the
> main repository. I couldn't possibly suggest that all git projects
> need the same workflow. The number of developers can vary by five
> orders of magnitude - that calls for different workflow models.
>
> > Git's approach is to say that it will be fairly flexible about
> > dictating workflow --- who pushs to whom; whether there is a single
> > "star" repository topology, or something that is more flexible, etc.
> > You seem to hate this flexibility, because it makes life harder until
> > you set up these bolt-on scripts. But that's what many of us like
> > about git; that it doesn't force us (the project lead) into a single
> > way of doing things.
>
> Leaving aside topology, I suppose we can agree that the subject
> divides into two aspects: offering the developer some optional tools,
> and asserting control over what gets commited to the official repo.
> Perhaps we can also agree that the former belongs under the control of
> the developer and the latter should be in the PM's hands. You seem to
> have opinions about which of these two aspects is more or less
> important, and to what extent git suffices, but I don't. I assume that
> the project manager has his own opinions about both aspects and I'm
> observing two big projects that independantly have augmented git's
> features with their own scripts. Their docs talk about both aspects,
> especially repo's, but they are entirely implemented in
> developer-overridable scripts. So any repo functions to do with the
> second aspect are either features that git needs to grow, or bits of
> the git manual that the repo designer didn't read. I'd kinda like to
> know which.
Repo (and gclient, which claims to be for SVN) seems to be mostly about
the fact that nothing really handles submodules (independant projects that
are also parts of larger projects) well. This is a known flaw with git,
but it's unclear as to whether repo does better. It's probably best to let
them work out a set of semantics which a real-world, full-scale project is
happy with, and consider adopting it for native submodules when there's
real-world positive experience behind it.
The other main thing I see repo doing is interfacing with gerrit, where
your pushes get redirected, and there are a million review branches you
can find on a web site, and where the server for a push is different from
the best server for a mainline fetch. Some of this is probably worth
having natively, but there's still the case of wanting to fetch a review
branch based on understanding stuff about gerrit. This is similar to
wanting to get a SVN revision out of bugzilla; you really want a tool
that's particular to the integration of the systems you're using, not
stuff built into your version control system. That said, if the submodule
stuff were taken care of, Google could provide a git-review program, and
do everything within the "git ..." wrapper instead of as an outer script.
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* What is the best way to synchronize two *bare* repositories with each other?
From: Liebich, Wolfgang @ 2009-11-24 21:19 UTC (permalink / raw)
To: git@vger.kernel.org
Hi,
Let's say I have two bare git repositories, bareA and bareB.
I also have a third non-bare repo, lets call it workA. Coworkers also have their working repositories, they all
synchronize back to repoA.
My work repo can only synchronize directly with repoB.
What is the best way to keep repoA and repoB synchronized to each other?
I solved that by defining (in the "config" file of repoB) a remote section for repoA,
and I "fetch" from repoA by issuing "git remote update repoA", and I push back via
"git push --all repoA".
This strange setup is necessary because of the security setup (my home development machine is not directly
connected with the company intranet).
Is this a good way to solve that problem, or are there better methods?
Ciao,
- Wolfgang
^ permalink raw reply
* Re: git-subtree: directory mismatch
From: Avery Pennarun @ 2009-11-24 21:48 UTC (permalink / raw)
To: Marc Fournier; +Cc: git
In-Reply-To: <20091124195353.GA16627@lonquimay.wrk.lsn.camptocamp.com>
On Tue, Nov 24, 2009 at 2:53 PM, Marc Fournier
<marc.fournier@camptocamp.com> wrote:
> I was not able to reproduce this bug in any of the following cases:
> - if the README file wasn't empty
> - if modules/cognac is renamed to something else
> - if modules/cognac doesn't have the same sub-directories than
> modules/mapserver
>
> This bug happens using git 1.5.5.6 as well as 1.6.5. It seems to happen
> when git-subtree calls "git merge -s subtree".
Yup. This is basically a bug in "git merge -s subtree": it guesses
which subtree to merge into, rather than actually taking a prefix
parameter. I've been meaning to either submit a patch for this, or
find a way to work around it.
This doesn't usually happen once your project is relatively mature
(ie. doesn't have blank or "default" template files in it) since then
the auto-guessing gets more reliable. But there's no good reason to
do the auto-guessing, so it would be best to do this "properly."
Sorry that I haven't had time to fix it yet...
Avery
^ permalink raw reply
* Re: [PATCH] git-count-objects: Fix a disk-space under-estimate on Cygwin
From: Junio C Hamano @ 2009-11-24 22:08 UTC (permalink / raw)
To: Ramsay Jones; +Cc: Junio C Hamano, GIT Mailing-list
In-Reply-To: <4B0C3D0D.60309@ramsay1.demon.co.uk>
Ramsay Jones <ramsay@ramsay1.demon.co.uk> writes:
> Err... no :-D
>
> Note that my suggested addition to your patch is in the core.filemode == false
> code path, and so does not affect the "disk-space under-estimate" problem at all.
>
> [To be clear: the "disk-space under-estimate" problem only happens when
> core.filemode == true and the regular cygwin lstat()/stat() functions are used.
> When core.filemode == false, the code in compat/cygwin.c (namely cygwin_lstat()
> and cygwin_stat()) will (most likely) be called instead. These functions use
> WIN32 api calls to implement equivalent, but presumably faster, versions of the
> stat functions]
>
>> You are forcing st_blksize to 512 but still return the same old st_blocks;
>> I do not understand what that would achieve.
>
> Well, as I said, I haven't tested your patch, or my suggested addition, so I could
> well be wrong... but what I aimed to achieve was to:
>
> - avoid "undefined behaviour" in on_disk_bytes(), since the value in
> st_blksize would otherwise be undefined (ie whatever happened to be
> on the stack-frame of the count_objects() function).
> - initialize the st_blksize field with a value consistent with the
> st_blocks field, which is derived from the st_size field, as the
> number of 512-byte blocks. (see the context line just before the
> + line in the above diff, along with the size_to_blocks macro)
> - return the same answer from this code as before.
Ah, sorry, so then I misread your comment. size_to_blocks() in
compat/cygwin.c counts blocks in 512 (I just checked) and you are applying
the reverse.
But you are right. If the emulation used on cygwin is _not_ doing the
"blocks * blksize is close to size" thing that is not POSIX but you saw in
your experiment on NTFS, and if we need your follow-up patch to make it do
so, there is no point in using my patch.
> Note that the answer returned from this core.filemode == false code path
> is different to the core.filemode == true code path. Which is why I *slightly*
> prefer my original patch.
Thanks for a clarification. I've already queued both to 'next', but I
will revert mine and make your patch graduate to 'master'.
^ permalink raw reply
* Re: [PATCH v3] remote-curl.c: fix rpc_out()
From: Shawn O. Pearce @ 2009-11-24 22:43 UTC (permalink / raw)
To: Tay Ray Chuan
Cc: git, Junio C Hamano, Sverre Rabbelier, Johannes Schindelin,
paulfred
In-Reply-To: <20091124103130.e1bdf09f.rctay89@gmail.com>
Tay Ray Chuan <rctay89@gmail.com> wrote:
> Remove the extraneous semicolon (';') at the end of the if statement
> that allowed the code in its block to execute regardless of the
> condition.
>
> This fixes pushing to a smart http backend with chunked encoding.
>
> Signed-off-by: Tay Ray Chuan <rctay89@gmail.com>
Acked-by: Shawn O. Pearce <spearce@spearce.org>
Thanks for the fix, I can't believe I made this typo. :-(
> - if (max < avail);
> + if (max < avail)
> avail = max;
--
Shawn.
^ permalink raw reply
* [PATCH] t1200: fix a timing dependent error
From: Nanako Shiraishi @ 2009-11-24 23:08 UTC (permalink / raw)
To: git; +Cc: Stephen Boyd, Junio C Hamano
The fourth test of show-branch in t1200 test was failing but only
sometimes. It only failed when two commits created in an earlier
test had different timestamps. When they were created within the
same second, the actual output matched the expected output.
Fix this by using test_tick to force reliable timestamps and update
the expected output so it does not to depend on the commits made in
the same sacond.
Signed-off-by: Nanako Shiraishi <nanako3@lavabit.com>
---
diff --git a/Documentation/gitcore-tutorial.txt b/Documentation/gitcore-tutorial.txt
index b7380b0..e237394 100644
--- a/Documentation/gitcore-tutorial.txt
+++ b/Documentation/gitcore-tutorial.txt
@@ -1186,9 +1186,9 @@ $ git show-branch
* [master] Some fun.
! [mybranch] Some work.
--
- + [mybranch] Some work.
* [master] Some fun.
-*+ [mybranch^] Initial commit
+ + [mybranch] Some work.
+*+ [master^] Initial commit
------------
Now we are ready to experiment with the merge by hand.
diff --git a/t/t1200-tutorial.sh b/t/t1200-tutorial.sh
index 6bf8475..238c2f1 100755
--- a/t/t1200-tutorial.sh
+++ b/t/t1200-tutorial.sh
@@ -47,7 +47,8 @@ test_expect_success 'tree' '
'
test_expect_success 'git diff-index -p HEAD' '
- tree=$(git write-tree)
+ test_tick &&
+ tree=$(git write-tree) &&
commit=$(echo "Initial commit" | git commit-tree $tree) &&
git update-ref HEAD $commit &&
git diff-index -p HEAD > diff.output &&
@@ -113,12 +114,14 @@ test_expect_success 'git branch' '
test_expect_success 'git resolve now fails' '
git checkout mybranch &&
echo "Work, work, work" >>hello &&
+ test_tick &&
git commit -m "Some work." -i hello &&
git checkout master &&
echo "Play, play, play" >>hello &&
echo "Lots of fun" >>example &&
+ test_tick &&
git commit -m "Some fun." -i hello example &&
test_must_fail git merge -m "Merge work in mybranch" mybranch
@@ -141,6 +144,7 @@ cat > show-branch.expect << EOF
EOF
test_expect_success 'git show-branch' '
+ test_tick &&
git commit -m "Merge work in mybranch" -i hello &&
git show-branch --topo-order --more=1 master mybranch \
> show-branch.output &&
@@ -201,9 +205,9 @@ cat > show-branch4.expect << EOF
* [master] Some fun.
! [mybranch] Some work.
--
- + [mybranch] Some work.
* [master] Some fun.
-*+ [mybranch^] Initial commit
+ + [mybranch] Some work.
+*+ [master^] Initial commit
EOF
test_expect_success 'git show-branch (part 4)' '
--
Nanako Shiraishi
http://ivory.ap.teacup.com/nanako3/
^ permalink raw reply related
* Re: git-subtree: directory mismatch
From: Nanako Shiraishi @ 2009-11-24 23:08 UTC (permalink / raw)
To: Avery Pennarun; +Cc: Marc Fournier, git
In-Reply-To: <32541b130911241348s21e21fb8n12edf374e6a3c309@mail.gmail.com>
Quoting Avery Pennarun <apenwarr@gmail.com>
> Yup. This is basically a bug in "git merge -s subtree": it guesses
> which subtree to merge into, rather than actually taking a prefix
> parameter. I've been meaning to either submit a patch for this, or
> find a way to work around it.
Probably you can save time by using what was already done
http://thread.gmane.org/gmane.comp.version-control.git/76650/focus=89021
--
Nanako Shiraishi
http://ivory.ap.teacup.com/nanako3/
^ permalink raw reply
* Re: [PATCH/RFC 0/3] git rerere unresolve file
From: Nanako Shiraishi @ 2009-11-24 23:40 UTC (permalink / raw)
To: Johannes Sixt; +Cc: Junio C Hamano, git
In-Reply-To: <200911221519.55658.j6t@kdbg.org>
Quoting Johannes Sixt <j6t@kdbg.org>
> On Sonntag, 22. November 2009, Junio C Hamano wrote:
> [snip]
>> * Then the user tells rerere that "this is the corrected resolution",
>> perhaps
>>
>> $ git rerere update Documentation/git-commit.txt
>>
>> This will
>>
>> - Internally recompute the original conflicted state, i.e. run
>> "checkout --conflict=merge Documentation/git-commit.txt" in-core;
>>
>> - feed it to rerere.c::handle_file() to learn the conflict hash;
>>
>> - read the user's updated resolution from the work tree, and update
>> "postimage" with it.
>>
>> ...
>>
>> The "forget" subcommand may be useful, but the real implementation should
>> be the first half of the "update", iow, recreate conflict in-core in order
>> to compute the conflict hash, and drop existing "postimage", without
>> replacing it from the work tree. We should leave it up to the user using
>> "checkout --conflict" to reproduce the conflict in the work tree.
>
> Thank you for your elaborate feedback and the guidelines about how to move
> forward.
>
> I actually think that 'forget' should be the primary subcommand. Because after
> the postimage was purged, the next implicit or explicit 'git rerere' will
> record the resolution anyway. I'll see what I can do.
>
> -- Hannes
I think 'forget' should be the primary interface to this new feature too. If I mistakenly recorded an incorrect merge in the past and I'm trying to do a better job this time, I wouldn't be confident enough to be able to say 'update' to mark the attempt I made this time, and it may take more than one attempts for me to reach a good result. Running 'forget' once will let me retry until I run 'rerere' again.
--
Nanako Shiraishi
http://ivory.ap.teacup.com/nanako3/
^ permalink raw reply
* [PATCH] gitweb.js: Harden setting blamed commit info in incremental blame
From: Jakub Narebski @ 2009-11-25 0:45 UTC (permalink / raw)
To: Stephen Boyd; +Cc: git
In-Reply-To: <200911211556.52175.jnareb@gmail.com>
On Sat, 21 Nov 2009, Jakub Narebski wrote:
> On Sat, 21 Nov 2009, Jakub Narebski wrote:
>
> > * Testing it with IE8 (Internet Explorer 8.0.6001.18702) page loading stops
> > at 0%, at the very beginning on startBlame() function
> >
> > IE8 shows that it finds the following errors:
> >
> > * "firstChild is null or not an object"
> > line: 565, char:4
> >
> > a_sha1.firstChild.data = commit.sha1.substr(0, 8);
> >
> > It might be caused by the fact that firstChild for this case should be
> > text node containing of pure whitespace:
> > <a href=""> </a>
> > Perhaps IE8 simplifies it in "compatibility view" mode
>
> This bug (be it in gitweb.js or in IE8) is fixed by the following patch:
>
> -- 8< --
> diff --git i/gitweb/gitweb.js w/gitweb/gitweb.js
> index 200ec5a..c1e425c 100644
> --- i/gitweb/gitweb.js
> +++ w/gitweb/gitweb.js
> @@ -562,7 +562,12 @@ function handleLine(commit, group) {
> td_sha1.rowSpan = group.numlines;
>
> a_sha1.href = projectUrl + 'a=commit;h=' + commit.sha1;
> - a_sha1.firstChild.data = commit.sha1.substr(0, 8);
> + if (a_sha1.firstChild) {
> + a_sha1.firstChild.data = commit.sha1.substr(0, 8);
> + } else {
> + a_sha1.appendChild(
> + document.createTextNode(commit.sha1.substr(0, 8)));
> + }
> if (group.numlines >= 2) {
> var fragment = document.createDocumentFragment();
> var br = document.createElement("br");
> -- >8 --
Below the same patch is in the form of a proper commit; although the title
(subject) of this commit could be better...
> > * "Unspecified error" (twice)
> > line: 777, char:2
> >
> > if (xhr.readyState === 3 && xhr.status !== 200) {
> > return;
> > }
> >
> > I don't know what might be the source of error here; I suspect that the
> > error position mentioned by IE8 is bogus.
>
> But I have no idea how to fix this. "Unspecified error" isn't very
> helpful...
Debugging this is serious PITA. After fix below it appears that this bug
is some intermittent bug, depending on XMLHttpRequest timing. It more
often than not (at least when I tried to debug it using build-in IE8
debugger) works correctly for the folowing files: README, GIT-VERSION-GEN,
revision.c (once even it did fail when first running for given file, and
then running correctly when reloading from debugger; fun it is not).
It does consistently fail for gitweb/gitweb.perl... but when I tried
to debug it IE8 would hang up when trying to use debugger (with around
600MB available RAM). Perhaps somebody else would have more luck...
-- >8 --
Subject: [PATCH] gitweb.js: Harden setting blamed commit info in incremental blame
Internet Explorer 8 stops at beginning of blame filling
with the following bug
"firstChild is null or not an object"
at this line
a_sha1.firstChild.data = commit.sha1.substr(0, 8);
It is (probably) caused by the fact that while a_sha1 element,
which looks like this
<a href=""> </a>
has firstChild which is text node containing only whitespace (single
space character) in other web browsers (Firefox 3.5, Opera 10,
Google Chrome 3.0), IE8 simplifies DOM, removing trailing/leading
whitespace.
Protect against this bug by creating text element if it does not
exist.
Found-by: Stephen Boyd <bebarino@gmail.com>
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
---
gitweb/gitweb.js | 7 ++++++-
1 files changed, 6 insertions(+), 1 deletions(-)
diff --git a/gitweb/gitweb.js b/gitweb/gitweb.js
index 200ec5a..c1e425c 100644
--- a/gitweb/gitweb.js
+++ b/gitweb/gitweb.js
@@ -562,7 +562,12 @@ function handleLine(commit, group) {
td_sha1.rowSpan = group.numlines;
a_sha1.href = projectUrl + 'a=commit;h=' + commit.sha1;
- a_sha1.firstChild.data = commit.sha1.substr(0, 8);
+ if (a_sha1.firstChild) {
+ a_sha1.firstChild.data = commit.sha1.substr(0, 8);
+ } else {
+ a_sha1.appendChild(
+ document.createTextNode(commit.sha1.substr(0, 8)));
+ }
if (group.numlines >= 2) {
var fragment = document.createDocumentFragment();
var br = document.createElement("br");
--
1.6.5.3
^ permalink raw reply related
* Re: [PATCH] gitweb.js: Harden setting blamed commit info in incremental blame
From: Nanako Shiraishi @ 2009-11-25 1:01 UTC (permalink / raw)
To: Jakub Narebski; +Cc: Stephen Boyd, git
In-Reply-To: <200911250145.16472.jnareb@gmail.com>
Quoting Jakub Narebski <jnareb@gmail.com>
> On Sat, 21 Nov 2009, Jakub Narebski wrote:
>
> Below the same patch is in the form of a proper commit; although the title
> (subject) of this commit could be better...
Does this replace the first of the previous two-patch series? Is Stephen's second patch still needed (with his fix)?
Quoting Stephen Boyd <bebarino@gmail.com>
> Jakub Narebski wrote:
>> I have tested gitweb with both of your patches applied, serving gitweb
>> as CGI script using Apache 2.0.54 on Linux, and viewing from separate
>> computer on MS Windows XP, with the following results:
>>
>> * For the following browsers blame_incremental view on gitweb/gitweb.perl
>> file produces correct output, but for progress info which instead of
>> ( 1%) -> ( 29%) -> (100%) looks more like ( 1%) -> (29%) -> (100%)
>
> This is due to an off-by-one error in the while loop. This should fix
> it. I'll probably squash this into patch 2 and resend.
>
> --->8----
>
> diff --git a/gitweb/gitweb.js b/gitweb/gitweb.js
> index 30597dd..9214497 100644
> --- a/gitweb/gitweb.js
> +++ b/gitweb/gitweb.js
> @@ -43,7 +43,7 @@ function padLeftStr(input, width, str) {
> var prefix = '';
>
> width -= input.toString().length;
> - while (width > 1) {
> + while (width > 0) {
> prefix += str;
> width--;
> }
--
Nanako Shiraishi
http://ivory.ap.teacup.com/nanako3/
^ 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