* Re: Git repository mesh?
From: Nguyen Thai Ngoc Duy @ 2009-11-25 8:00 UTC (permalink / raw)
To: Matthieu Moy; +Cc: Git Mailing List
In-Reply-To: <vpqaaybf37f.fsf@bauges.imag.fr>
On Wed, Nov 25, 2009 at 2:55 PM, Matthieu Moy
<Matthieu.Moy@grenoble-inp.fr> wrote:
> Nguyen Thai Ngoc Duy <pclouds@gmail.com> writes:
>
>> Never used Mercurial but the idea of "git in" and "git out" to see how
>> many commits ahead/behind would be nice.
>
> In Git, you'd run "git fetch" to get everything locally, and then
>
> git log ..origin/master => what origin/master has that you don't
> git log origin/master.. => what you have that origin/master doesn't
>
> (and you can define aliases for that)
But I have many origins (any repository could be origin). "git status"
also have this kind of information, but only for "origin".
--
Duy
^ permalink raw reply
* Re: Git repository mesh?
From: Matthieu Moy @ 2009-11-25 7:55 UTC (permalink / raw)
To: Nguyen Thai Ngoc Duy; +Cc: Git Mailing List
In-Reply-To: <fcaeb9bf0911242007t1294bddej87b48691ea283e21@mail.gmail.com>
Nguyen Thai Ngoc Duy <pclouds@gmail.com> writes:
> Never used Mercurial but the idea of "git in" and "git out" to see how
> many commits ahead/behind would be nice.
In Git, you'd run "git fetch" to get everything locally, and then
git log ..origin/master => what origin/master has that you don't
git log origin/master.. => what you have that origin/master doesn't
(and you can define aliases for that)
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
^ permalink raw reply
* Re: Private remote repo setup
From: Johannes Sixt @ 2009-11-25 6:37 UTC (permalink / raw)
To: Derek D; +Cc: git
In-Reply-To: <loom.20091124T195818-835@post.gmane.org>
Derek D schrieb:
> 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
^
This looks like you were root when you ran the command.
> 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?
I guess that user does not have sufficient permissions to peek inside
/opt/apps/git-test.
-- Hannes
^ permalink raw reply
* Git repository mesh?
From: Nguyen Thai Ngoc Duy @ 2009-11-25 4:07 UTC (permalink / raw)
To: Git Mailing List
Hi,
I work on a few machines so I have repositories on all of them. One
repository can pull from or push to any other repositories (in case of
push, it pushes on remote branches). I avoid a central repository
because it's quite inconvenient when you just need to push some
changes to a machine, you have to push it to the central repository
then pull from that (and if the central repository is on WAN, double
inconvenient). Maybe this model is just plain wrong, but it'd be fun
to see if Git can work with this model.
The first thing that annoys me is remote repository management.
Everytime I add a new repository to the mesh, I need to update .config
of all repositories. Putting part of $GIT_DIR/config into working
directory may help (though there will be security concerns, perhaps
only remote.* should be allowed in in-tree config file). Next thing is
sometimes I want to see how many commits ahead/behind other
repositories, from a repository. "git status" does not help much.
Never used Mercurial but the idea of "git in" and "git out" to see how
many commits ahead/behind would be nice.
Has anyone done something like this? Any suggestions?
--
Duy
^ permalink raw reply
* Re: [PATCH] gitweb.js: Harden setting blamed commit info in incremental blame
From: Stephen Boyd @ 2009-11-25 4:01 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <200911250145.16472.jnareb@gmail.com>
Jakub Narebski wrote:
>
> 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...
Interesting. I don't have time to look into this until early December,
but if it's still around then I'll take a look. I wonder if IE6 or IE7
works (I don't think everyone is on version 8 yet).
^ permalink raw reply
* [PATCHv2 2/2] gitweb.js: fix padLeftStr() and its usage
From: Stephen Boyd @ 2009-11-25 3:51 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano, Jakub Narebski
In-Reply-To: <1258659887-5244-3-git-send-email-bebarino@gmail.com>
It seems that in Firefox-3.5 inserting with javascript inserts the
literal instead of a space. Fix this by inserting the unicode
representation for instead.
Also fix the off-by-one error in the padding calculation that was
causing one less space to be inserted than was requested by the caller.
Signed-off-by: Stephen Boyd <bebarino@gmail.com>
Cc: Jakub Narebski <jnareb@gmail.com>
---
Fixed the commit message and squashed in the off-by-one bug.
gitweb/gitweb.js | 10 +++++-----
1 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/gitweb/gitweb.js b/gitweb/gitweb.js
index 02454d8..9214497 100644
--- a/gitweb/gitweb.js
+++ b/gitweb/gitweb.js
@@ -31,19 +31,19 @@
/**
* pad number N with nonbreakable spaces on the left, to WIDTH characters
- * example: padLeftStr(12, 3, ' ') == ' 12'
- * (' ' is nonbreakable space)
+ * example: padLeftStr(12, 3, '\u00A0') == '\u00A012'
+ * ('\u00A0' is nonbreakable space)
*
* @param {Number|String} input: number to pad
* @param {Number} width: visible width of output
- * @param {String} str: string to prefix to string, e.g. ' '
+ * @param {String} str: string to prefix to string, e.g. '\u00A0'
* @returns {String} INPUT prefixed with (WIDTH - INPUT.length) x STR
*/
function padLeftStr(input, width, str) {
var prefix = '';
width -= input.toString().length;
- while (width > 1) {
+ while (width > 0) {
prefix += str;
width--;
}
@@ -158,7 +158,7 @@ function updateProgressInfo() {
if (div_progress_info) {
div_progress_info.firstChild.data = blamedLines + ' / ' + totalLines +
- ' (' + padLeftStr(percentage, 3, ' ') + '%)';
+ ' (' + padLeftStr(percentage, 3, '\u00A0') + '%)';
}
if (div_progress_bar) {
--
1.6.6.rc0
^ permalink raw reply related
* [PATCH 2/2] Documentation for format-patch --notmuch.
From: Jed Brown @ 2009-11-25 2:50 UTC (permalink / raw)
To: git; +Cc: madcoder, Jed Brown
In-Reply-To: <1259117447-23052-1-git-send-email-jed@59A2.org>
---
Documentation/git-format-patch.txt | 7 +++++++
1 files changed, 7 insertions(+), 0 deletions(-)
diff --git a/Documentation/git-format-patch.txt b/Documentation/git-format-patch.txt
index f1fd0df..aaa472d 100644
--- a/Documentation/git-format-patch.txt
+++ b/Documentation/git-format-patch.txt
@@ -171,6 +171,13 @@ will want to ensure that threading is disabled for `git send-email`.
to any configured headers, and may be used multiple times.
For example, `--add-header="Organization: git-foo"`
+--notmuch=<expr>::
+ Generate headers appropriate for a reply to a notmuch search for the
+ given expression. Usually an expression of the form id:<Message-ID>
+ will be used to match an exact message. The reply will set
+ In-Reply-To, References, To, Cc, Bcc, and possibly other headers
+ (depending on notmuch configuration).
+
--cover-letter::
In addition to the patches, generate a cover letter file
containing the shortlog and the overall diffstat. You can
--
1.6.5.3
^ permalink raw reply related
* [PATCH 1/2] Added the --notmuch option to git format-patch.
From: Jed Brown @ 2009-11-25 2:50 UTC (permalink / raw)
To: git; +Cc: madcoder, Jed Brown
In-Reply-To: <87d4375ne0.fsf@59A2.org>
The typical use case for this is
git format-patch --notmuch id:<MESSAGE-ID>
which will format your patch with all threading, references, and To, Cc
fields appropriate for a reply to the given message.
---
builtin-log.c | 61 +++++++++++++++++++++++++++++++++++++++++++++++++++++---
1 files changed, 57 insertions(+), 4 deletions(-)
diff --git a/builtin-log.c b/builtin-log.c
index 33fa6ea..9a44955 100644
--- a/builtin-log.c
+++ b/builtin-log.c
@@ -754,6 +754,53 @@ static const char *clean_message_id(const char *msg_id)
return xmemdupz(a, z - a);
}
+static int get_notmuch_reply(struct strbuf *buf, struct string_list *ref_message_ids, const char *query)
+{
+ struct child_process notmuch;
+ struct strbuf notmuch_out;
+ char *p, *other_headers, *rstart;
+ ssize_t len;
+ const char *argv[] = {"notmuch", "reply", "--format=headers-only", query, NULL};
+
+ memset(¬much, 0, sizeof(notmuch));
+
+ notmuch.argv = argv;
+ notmuch.no_stdin = 1;
+ notmuch.out = -1;
+
+ if (start_command(¬much))
+ return error("could not run notmuch.");
+
+ strbuf_init(¬much_out, 4096);
+ len = strbuf_read(¬much_out, notmuch.out, 4096);
+ close(notmuch.out);
+
+ if (finish_command(¬much) || !len || len < 0)
+ return error("notmuch did not return any headers");
+
+ /* Harvest the referenced message IDs, all on the first line */
+ p = notmuch_out.buf;
+
+ if (!strncmp(p, "References: ", sizeof("References: ")))
+ return error("notmuch response malformed");
+
+ other_headers = strstr(p, "To: ");
+ if (!other_headers)
+ return error("notmuch provided no other headers");
+
+ while ((rstart = strchr(p, '<')) && (p = strchr(rstart, '>')) && p < other_headers-1) {
+ if (!p)
+ error("notmuch returned malformed references");
+ p++;
+ *p++ = 0;
+ string_list_append(clean_message_id(rstart), ref_message_ids);
+ }
+ /* Add everything after the first line */
+ strbuf_addstr(buf, other_headers);
+ strbuf_release(¬much_out);
+ return 0;
+}
+
static const char *set_outdir(const char *prefix, const char *output_directory)
{
if (output_directory && is_absolute_path(output_directory))
@@ -893,7 +940,7 @@ int cmd_format_patch(int argc, const char **argv, const char *prefix)
int boundary_count = 0;
int no_binary_diff = 0;
struct commit *origin = NULL, *head = NULL;
- const char *in_reply_to = NULL;
+ const char *in_reply_to = NULL, *notmuch = NULL;
struct patch_ids ids;
char *add_signoff = NULL;
struct strbuf buf = STRBUF_INIT;
@@ -940,6 +987,8 @@ int cmd_format_patch(int argc, const char **argv, const char *prefix)
PARSE_OPT_NONEG, cc_callback },
OPT_STRING(0, "in-reply-to", &in_reply_to, "message-id",
"make first mail a reply to <message-id>"),
+ OPT_STRING(0, "notmuch", ¬much, "query",
+ "make first mail a reply to messages matched by <query>"),
{ OPTION_CALLBACK, 0, "attach", &rev, "boundary",
"attach the patch", PARSE_OPT_OPTARG,
attach_callback },
@@ -1015,8 +1064,6 @@ int cmd_format_patch(int argc, const char **argv, const char *prefix)
strbuf_addch(&buf, '\n');
}
- rev.extra_headers = strbuf_detach(&buf, NULL);
-
if (start_number < 0)
start_number = 1;
@@ -1135,12 +1182,18 @@ int cmd_format_patch(int argc, const char **argv, const char *prefix)
numbered = 1;
if (numbered)
rev.total = total + start_number - 1;
- if (in_reply_to || thread || cover_letter)
+ if (in_reply_to || thread || cover_letter || notmuch)
rev.ref_message_ids = xcalloc(1, sizeof(struct string_list));
if (in_reply_to) {
const char *msgid = clean_message_id(in_reply_to);
string_list_append(msgid, rev.ref_message_ids);
}
+ if (notmuch) {
+ get_notmuch_reply(&buf, rev.ref_message_ids, notmuch);
+ }
+
+ rev.extra_headers = strbuf_detach(&buf, NULL);
+
rev.numbered_files = numbered_files;
rev.patch_suffix = fmt_patch_suffix;
if (cover_letter) {
--
1.6.5.3
^ permalink raw reply related
* git send-email --notmuch expr
From: Jed Brown @ 2009-11-25 2:49 UTC (permalink / raw)
To: git, Pierre Habouzit
Notmuch is a new mail system with fast indexing and tagging, see
notmuchmail.org. It has a command-line tool to build replies to emails,
and I wrote a patch to format-patch that enables
git format-patch --notmuch EXPR
where EXPR is any notmuch query, but usually id:<Message-ID> to match a
specific message. This will set up several headers, notably
In-Reply-To, References, To, Cc, Bcc. This works great, and the the
patch follows this message.
But I really want
git send-email --notmuch EXPR
This sort-of works, but the interactive part prompts for the various
headers (even though format-patch supplies them), and then duplicates
the To header (both the possibly empty field the user provided, plus the
one coming from format-patch). I had a brief look at
git-send-email.perl, and I'm a little confused.
} elsif (/^(?:To|Cc|Bcc):/i) {
print "To/Cc/Bcc fields are not interpreted yet, they have been ignored\n";
next;
}
This regex doesn't match these headers (is the leading ?: a typo?) so
there is no warning. But it's important that these headers *not* be
ignored, getting them set automatically is a key feature of the
--notmuch option. I'm having trouble discerning whether I would cause
problems by just using these headers coming out of format-patch.
Presumably there was a reason why they were (intended to be) explicitly
ignored, and my poor perl skills are not helping. Could someone
enlighten me?
Jed
^ permalink raw reply
* Re: commit --quiet option
From: bill lam @ 2009-11-25 2:06 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vtywj76k4.fsf@alter.siamese.dyndns.org>
On Tue, 24 Nov 2009, Junio C Hamano wrote:
> bill lam <cbill.lam@gmail.com> writes:
>
> > In git version 1.6.6.rc0.15.g4fa8a0 using the --quiet option it still
> > show some output. Is that intended? Specifically I would like to
> > exclude message about the untracked files when using --quite option.
>
> Given that you are getting "you told me to make a commit without preparing
> anything to commit" error message, I think it can be argued in both ways.
>
> $ git commit -q -uno -m 'meaningless message'
>
> would omit the listing of Untracked files; a better alternative, depending
> on what are listed in the section (I take "a123" is an example made-up for
> reproduction recipe, and you are probably getting something like 'foo.bak'
> in real life), might be to update your .gitignore, though.
That git-commit is intended to run inside a cron job for backup from
home folder and .files, so 'commit' is better than 'meaningless
message'. .gitignore is already maintained however those 'a123' is a
real life example, they are artifacts of '3m post-it' files because I
rarely use clipboard (c-ins/c-ins) to copy text from one application
into another.
Thanks for tips on -uno option.
--
regards,
====================================================
GPG key 1024D/4434BAB3 2008-08-24
gpg --keyserver subkeys.pgp.net --recv-keys 4434BAB3
^ permalink raw reply
* Re: [PATCH] t1200: fix a timing dependent error
From: Junio C Hamano @ 2009-11-25 1:14 UTC (permalink / raw)
To: Nanako Shiraishi; +Cc: git, Stephen Boyd, Junio C Hamano
In-Reply-To: <20091125080808.6117@nanako3.lavabit.com>
Nanako Shiraishi <nanako3@lavabit.com> writes:
> 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.
Ahh, I actually saw this breakage once, suspected it would be something
like that, but didn't have enough energy/time to dig into it myself.
Thanks.
^ permalink raw reply
* Re: [PATCH] gitweb.js: Harden setting blamed commit info in incremental blame
From: Jakub Narebski @ 2009-11-25 1:13 UTC (permalink / raw)
To: Nanako Shiraishi; +Cc: Stephen Boyd, git
In-Reply-To: <20091125100104.6117@nanako3.lavabit.com>
On Wed, 25 Nov 2009, Nanako Shiraishi wrote:
> 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)?
No, it replaces neither first patch of Stephen's two patch series that
started this thread, namely "gitweb.js: fix null object exception in
initials calculation" (which is about initials of committer... if they
exist), nor the follow-up fix of off-by-one bug in padLeftStr.
This is fix of an independent issue (even if it occurs only in IE8).
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: [PATCH] shortlog: respect commit encoding
From: Junio C Hamano @ 2009-11-25 1:12 UTC (permalink / raw)
To: Uwe Kleine-König; +Cc: git, Jiri Kosina
In-Reply-To: <1259075555-7831-1-git-send-email-u.kleine-koenig@pengutronix.de>
Uwe Kleine-König <u.kleine-koenig@pengutronix.de> writes:
> Before this change the author was taken from the raw commit without
> reencoding.
I see people often begin with "before this change" and stop the log
message after making a statement of a fact. I mildly dislike this style,
especially when the resulting message does not state that it is bad (and
if necessary why it is bad) nor state in what way the code after the
change is good.
Don't take the author name information without re-encoding
from the raw commit object buffer.
is easier to read, at least for me.
> 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 "))
What is this hunk for?
> @@ -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, &ufbuf, &ctx);
> + buffer = ufbuf.buf;
> +
> + } else if (*buffer)
> buffer++;
> +
You probably wanted to add an extra pair of {} around this "else
if" clause instead, not the earlier one.
Otherwise the change looks good from my cursory look.
> 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
> +}
A bad use of "$@" that expands to $# individual words; you meant
to say "$*".
Could we please have the following inside its own test, so that
any failure while preparing the test data is caught as an error?
> +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'
t3900-i18n-commit already uses 8859-1 so if it is not too much to
ask, it would be much nicer to have these test work between UTF-8
and 8859-1, not -15.
That way, I do not have to worry about breaking tests for people
who were able to run existing iconv tests because they do not have
working 8859-15.
Thanks
^ permalink raw reply
* Re: [PATCH] mailinfo: remove [PATCH...] prefix from Subject regardless of length
From: Junio C Hamano @ 2009-11-25 1:10 UTC (permalink / raw)
To: Jim Meyering; +Cc: git list
In-Reply-To: <874ookp4u8.fsf@meyering.net>
Jim Meyering <meyering@redhat.com> writes:
> Before this change, a [...] prefix would be removed only as long as
> its length did not exceed 2/3 of the subject length. Now, when the
> bracketed quantity starts with PATCH, it is removed unconditionally.
> Otherwise, the existing behavior remains unchanged.
Thanks, I think this is a good idea in general, but have two comments.
- I am not sure how this should play with 17635fc (mailinfo: -b option
keeps [bracketed] strings that is not a [PATCH] marker, 2009-07-15).
- Regardless of interaction with 17635fc, Things like [RFC PATCH]
[SECURITY PATCH] might want a similar treatment.
^ permalink raw reply
* Re: commit --quiet option
From: Junio C Hamano @ 2009-11-25 1:10 UTC (permalink / raw)
To: bill lam; +Cc: git
In-Reply-To: <20091124051622.GB18003@debian.b2j>
bill lam <cbill.lam@gmail.com> writes:
> In git version 1.6.6.rc0.15.g4fa8a0 using the --quiet option it still
> show some output. Is that intended? Specifically I would like to
> exclude message about the untracked files when using --quite option.
Given that you are getting "you told me to make a commit without preparing
anything to commit" error message, I think it can be argued in both ways.
$ git commit -q -uno -m 'meaningless message'
would omit the listing of Untracked files; a better alternative, depending
on what are listed in the section (I take "a123" is an example made-up for
reproduction recipe, and you are probably getting something like 'foo.bak'
in real life), might be to update your .gitignore, though.
> $ git commit -q -m commit
> # On branch master
> # Changed but not updated:
> # (use "git add <file>..." to update what will be committed)
> # (use "git checkout -- <file>..." to discard changes in working directory)
> #
> # modified: .git-completion.bash
> # modified: bin/mirrorgit
> #
> # Untracked files:
> # (use "git add <file>..." to include in what will be committed)
> #
> # a123
> no changes added to commit (use "git add" and/or "git commit -a")
>
> --
> regards,
> ====================================================
> GPG key 1024D/4434BAB3 2008-08-24
> gpg --keyserver subkeys.pgp.net --recv-keys 4434BAB3
^ permalink raw reply
* 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
* [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/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
* 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
* [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: [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
* 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: 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
* 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: 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
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