* Re: gitweb, updating 'last changed' column on the project page
From: Jon Smirl @ 2007-11-10 13:05 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <200711101034.47861.jnareb@gmail.com>
On 11/10/07, Jakub Narebski <jnareb@gmail.com> wrote:
> On Saturday, 10 November 2007, Jon Smirl wrote:
> > On 11/10/07, Jon Smirl <jonsmirl@gmail.com> wrote:
> >> On 11/9/07, Jakub Narebski <jnareb@gmail.com> wrote:
> >>> Jon Smirl wrote:
> >>>
> >>>> At http://git.digispeaker.com/ the 'last change' column is not getting updated.
> >>>>
> >>>> mpc5200b.git
> >>>> DigiSpeaker for Freescale MPC5200B.
> >>>> Jon Smirl
> >>>> 5 weeks ago
> >>>> summary | shortlog | log | tree
> >>>>
> >>>> It still says 5 weeks ago, but if I click on the project last change is today.
> >>>>
> >>>> What controls this? I tried running update-server-info
> >>>
> >>> What does
> >>>
> >>> git for-each-ref --format="%(refname):%09%(committer)" --sort=-committerdate
> >>> refs/heads
> >>
> >> [daedalus]$ git for-each-ref --format="%(refname):%09%(committer)" \
> >> --sort=-committerdate refs/heads
> >> refs/heads/m24: Jon Smirl <jonsmirl@gmail.com> 1191362799 -0400
> >> refs/heads/m25: Jon Smirl <jonsmirl@gmail.com> 1191472422 -0400
> >> refs/heads/m26: Jon Smirl <jonsmirl@gmail.com> 1194382038 -0500
> >> refs/heads/m28: Jon Smirl <jonsmirl@gmail.com> 1194385071 -0500
> >> refs/heads/m29: Jon Smirl <jonsmirl@gmail.com> 1194585780 -0500
> >
> > It appears to be using the first head instead of the most recent date.
> It appears to not _sort_ the output by committerdate, as it should with
> '--sort=-committerdate'.
It is sorted by committerdate, the sort is ascending. Did you expect
it to be descending, pick off the last entry instead of the first?
>
> 1442:[gitweb/web!git]$ git for-each-ref --format="%(refname):%09%(committer)" \
> --sort=-committerdate refs/heads
> refs/heads/gitweb/web: Jakub Narebski <jnareb@gmail.com> 1194616779 +0100
> refs/heads/man: Junio C Hamano <junio@hera.kernel.org> 1194602628 +0000
> refs/heads/html: Junio C Hamano <junio@hera.kernel.org> 1194602626 +0000
> refs/heads/origin: Junio C Hamano <gitster@pobox.com> 1194602274 -0800
> [...]
> refs/heads/gitweb-snapshot+navbar: Sven Verdoolaege <skimo@kotnet.org> 1134765981 +0100
>
> 1443:[gitweb/web!git]$ git --version
> git version 1.5.3.5
>
>
> Note that git-for-each-ref with those options returns most recent head
> first, sorting output by date of commit (date of adding to repository)
>
> >>>
> >>> return? Does adding --count select proper branch, with proper update
> >>> date?
> >>
> >> Is it looking for master, and just picking the first branch instead?
>
> Gitweb should not (and I think does not) have 'master' hardcoded
> anywhere. It might use HEAD in some cases you don't want it to...
>
> >>>
> >>> Which gitweb version is this?
> >>
> >> <!-- git web interface version 1.5.3.5.605.g79fa-dirty, (C) 2005-2006,
> >> Kay Sievers <kay.sievers@vrfy.org>, Christian Gierke -->
> >> <!-- git core binaries version 1.5.3.5.605.g79fa-dirty -->
>
> Older version of gitweb used HEAD branch for'last changed' info on
> the projects list page. That is why I asked about gitweb version.
>
> But this is not the case of your problem:
> 1. Your gitweb is new enough to use git-for-each-ref. It use
> git for-each-ref --format="%(committer)" --sort=-committerdate
> --count=1 refs/heads
> 2. Looking at 'heads' view (or 'heads' part of summary view) one can see
> that m29 is current branch (HEAD), and it is most recent.
>
> Strange...
> --
> Jakub Narebski
> Poland
>
--
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply
* Re: `git-send-email' doesn't specify `Content-Type'
From: Björn Steinbrink @ 2007-11-10 12:51 UTC (permalink / raw)
To: Brian Swetland; +Cc: Johannes Schindelin, Ludovic Courtès, git
In-Reply-To: <20071110123505.GA24445@bulgaria>
On 2007.11.10 04:35:05 -0800, Brian Swetland wrote:
> [Björn Steinbrink <B.Steinbrink@gmx.de>]
> > On 2007.11.10 02:14:20 -0800, Brian Swetland wrote:
> > >
> > > The example I have involves a coworker's name which needs non-ascii
> > > characters. They are properly escaped in the From: line generated by
> > > git-format-patch. git-send-email puts the generated From: line at the
> > > top of the body of the email, unescapes it (to utf-8), and proceeds to
> > > send the email with no Content-Type specified.
> >
> > You mean that it converts the header field to utf-8? It doesn't do that
> > here (neither master nor 1.5.3.5) and IIRC that would be invalid anyway,
> > because Content-Type applies to exactly that, content, not headers. Your
> > sample has no non-ASCII characters (or at least I didn't see any), so
> > git-send-email doesn't add a header to specify a charset.
>
> The first line of the patch is a From: field with Arve's name, in
> an (rfc822?) encoded format):
> From: =?utf-8?q?Arve=20Hj=C3=B8nnev=C3=A5g?= <arve@android.com>
>
> The mail generated by git-send-email makes this From: line the first
> line of the *body* of the generated email. This line in the body
> is no longer escaped, the utf8 characters are visible, but the header
> of the message does not have a Content-Type indicating a non-ascii
> encoding.
Ah! Commit author differs from mail sender, didn't think of that. That's
probably the same problem as with the -s option, ie. that git-send-email
only looks at the existing text and not add anything it adds itself when
checking the encoding. Sorry for the noise.
Björn
^ permalink raw reply
* Re: cogito remote branch
From: Michael Dressel @ 2007-11-10 12:35 UTC (permalink / raw)
To: jnareb; +Cc: git
>Michael Dressel wrote:
>> On Fri, 9 Nov 2007, Jon Loeliger wrote:
>>> On Fri, 2007-11-09 at 10:10, MichaelTiloDressel@t-online.de wrote:
>>>
>>>> There are just some features
>>>> which simplify things for me in cogito. E.g. in cogito in the
simplest
>>>> way you don't need to be aware of the index. While with git
>>>> you have to remember to add the changes to the index explicitly
>>>> to get them committed.
>>>
>>> "git commit -a ..." might be useful for you.
>>>
>>> Other lingering cogito-isms you think are lacking in git?
>>
>> Thanks for the hint. I have to use git for a while to understand what
may
>> still be lacking (at least for me, if at all). Off the top of my head
one
>> other difference is that if I do a cg-push the remote (or origin) head
is
>> updated automatically, I think.
Jakub Narebski wrote:
>If you mean that tracking branches are updated on push, this is what
>git also does from some time (perhaps not in released version, so please
>wait or run 'master').
Ok nice. Another thing is that git-push will push all the tracking
branches in refs/remotes/origin.
I was wondering if it was possible to have some cogito like wrapper
scripts (lets say kg-...) for git again which would use the git commands
with some arguments in order to resemble the cogito behavior
even more closely. But it dawned on me that this would most likely end up
in a rather large amount of script code again.
Cheers,
Michael
^ permalink raw reply
* Re: `git-send-email' doesn't specify `Content-Type'
From: Brian Swetland @ 2007-11-10 12:35 UTC (permalink / raw)
To: Björn Steinbrink; +Cc: Johannes Schindelin, Ludovic Courtès, git
In-Reply-To: <20071110122528.GA4977@atjola.homenet>
[-- Attachment #1: Type: text/plain, Size: 1367 bytes --]
[Björn Steinbrink <B.Steinbrink@gmx.de>]
> On 2007.11.10 02:14:20 -0800, Brian Swetland wrote:
> >
> > The example I have involves a coworker's name which needs non-ascii
> > characters. They are properly escaped in the From: line generated by
> > git-format-patch. git-send-email puts the generated From: line at the
> > top of the body of the email, unescapes it (to utf-8), and proceeds to
> > send the email with no Content-Type specified.
>
> You mean that it converts the header field to utf-8? It doesn't do that
> here (neither master nor 1.5.3.5) and IIRC that would be invalid anyway,
> because Content-Type applies to exactly that, content, not headers. Your
> sample has no non-ASCII characters (or at least I didn't see any), so
> git-send-email doesn't add a header to specify a charset.
The first line of the patch is a From: field with Arve's name, in
an (rfc822?) encoded format):
From: =?utf-8?q?Arve=20Hj=C3=B8nnev=C3=A5g?= <arve@android.com>
The mail generated by git-send-email makes this From: line the first
line of the *body* of the generated email. This line in the body
is no longer escaped, the utf8 characters are visible, but the header
of the message does not have a Content-Type indicating a non-ascii
encoding.
Attached are the result of git-format-patch and the actual email
received from git-send-email (mbox format).
Brian
[-- Attachment #2: 0001-hrtimer-Add-timer-back-to-pending-list-if-it-was-re.patch --]
[-- Type: text/x-diff, Size: 1224 bytes --]
>From 3440baaed3b21138f6fc8b80e03769e3903f9c11 Mon Sep 17 00:00:00 2001
From: =?utf-8?q?Arve=20Hj=C3=B8nnev=C3=A5g?= <arve@android.com>
Date: Wed, 7 Nov 2007 22:51:44 -0800
Subject: [PATCH] hrtimer: Add timer back to pending list if it was reactivated and has already expired again.
This avoids problems with timer hardware that does not respond to timers set in the past.
Signed-off-by: Brian Swetland <swetland@android.com>
---
kernel/hrtimer.c | 10 ++++++++--
1 files changed, 8 insertions(+), 2 deletions(-)
diff --git a/kernel/hrtimer.c b/kernel/hrtimer.c
index 22a2514..7c60769 100644
--- a/kernel/hrtimer.c
+++ b/kernel/hrtimer.c
@@ -1149,8 +1149,14 @@ static void run_hrtimer_softirq(struct softirq_action *h)
* If the timer was rearmed on another CPU, reprogram
* the event device.
*/
- if (timer->base->first == &timer->node)
- hrtimer_reprogram(timer, timer->base);
+ if (timer->base->first == &timer->node) {
+ if(hrtimer_reprogram(timer, timer->base)) {
+ __remove_hrtimer(timer, timer->base,
+ HRTIMER_STATE_PENDING, 0);
+ list_add_tail(&timer->cb_entry,
+ &cpu_base->cb_pending);
+ }
+ }
}
}
spin_unlock_irq(&cpu_base->lock);
--
1.5.3.5
[-- Attachment #3: mbox --]
[-- Type: text/plain, Size: 2456 bytes --]
>From swetland@google.com Sat Nov 10 02:04:08 2007
Return-Path: <swetland@google.com>
X-Original-To: swetland@frotz.net
Delivered-To: swetland@frotz.net
Received: from smtp-out.google.com (smtp-out.google.com [216.239.45.13])
by mumble.frotz.net (Postfix) with ESMTP id 1BC002500D
for <swetland@frotz.net>; Sat, 10 Nov 2007 02:04:08 -0800 (PST)
Received: from zps35.corp.google.com (zps35.corp.google.com [172.25.146.35])
by smtp-out.google.com with ESMTP id lAAA5hUj030761;
Sat, 10 Nov 2007 02:05:43 -0800
DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns;
h=received:from:to:cc:subject:date:message-id:x-mailer;
b=g2B628wRsJJahlIpNw3mgNDqOQKNMcUCPOurvqj+3fO6qLH+vpBS0ZwN1lLv6BnC7
w4QLOotDo7t+nI2KgZDVQ==
Received: from bulgaria (bulgaria.corp.google.com [172.18.102.38])
by zps35.corp.google.com with ESMTP id lAAA5e22002202;
Sat, 10 Nov 2007 02:05:42 -0800
Received: by bulgaria (Postfix, from userid 1000)
id 613018F45E; Sat, 10 Nov 2007 02:05:25 -0800 (PST)
From: swetland@google.com
To: swetland@frotz.net
Cc: =?utf-8?q?Arve=20Hj=C3=B8nnev=C3=A5g?= <arve@android.com>
Subject: [PATCH] hrtimer: Add timer back to pending list if it was reactivated and has already expired again.
Date: Sat, 10 Nov 2007 02:05:25 -0800
Message-Id: <1194689125-21319-1-git-send-email-swetland@google.com>
X-Mailer: git-send-email 1.5.3.5
X-SpamProbe: GOOD 0.0000099 b892c7c5c469d044f28ab48846487cf5
X-SpamCheck: OKAY
Status: RO
Content-Length: 983
Lines: 33
From: Arve Hjønnevåg <arve@android.com>
This avoids problems with timer hardware that does not respond to timers set in the past.
Signed-off-by: Brian Swetland <swetland@android.com>
---
kernel/hrtimer.c | 10 ++++++++--
1 files changed, 8 insertions(+), 2 deletions(-)
diff --git a/kernel/hrtimer.c b/kernel/hrtimer.c
index 22a2514..7c60769 100644
--- a/kernel/hrtimer.c
+++ b/kernel/hrtimer.c
@@ -1149,8 +1149,14 @@ static void run_hrtimer_softirq(struct softirq_action *h)
* If the timer was rearmed on another CPU, reprogram
* the event device.
*/
- if (timer->base->first == &timer->node)
- hrtimer_reprogram(timer, timer->base);
+ if (timer->base->first == &timer->node) {
+ if(hrtimer_reprogram(timer, timer->base)) {
+ __remove_hrtimer(timer, timer->base,
+ HRTIMER_STATE_PENDING, 0);
+ list_add_tail(&timer->cb_entry,
+ &cpu_base->cb_pending);
+ }
+ }
}
}
spin_unlock_irq(&cpu_base->lock);
--
1.5.3.5
^ permalink raw reply related
* Re: `git-send-email' doesn't specify `Content-Type'
From: Björn Steinbrink @ 2007-11-10 12:25 UTC (permalink / raw)
To: Brian Swetland; +Cc: Johannes Schindelin, Ludovic Courtès, git
In-Reply-To: <20071110101420.GA21353@bulgaria>
On 2007.11.10 02:14:20 -0800, Brian Swetland wrote:
> [Johannes Schindelin <Johannes.Schindelin@gmx.de>]
> > Hi,
> >
> > On Sat, 10 Nov 2007, Ludovic Court?s wrote:
> >
> > > Apparently, `git-send-email' doesn't specify the email's `Content-Type',
> > > notably its charset, while it should really add something like:
> > >
> > > Content-Type: text/plain; charset=UTF-8
> > >
> > > Or did I miss an option or something?
> >
> > Apparently. There was a thread some days ago, about that very issue.
> > Please find and read it.
>
> The thread I found says that git-send-email should do the right thing if
> there are non-ascii characters, but this does not seem to be the case
> for me.
>
> The example I have involves a coworker's name which needs non-ascii
> characters. They are properly escaped in the From: line generated by
> git-format-patch. git-send-email puts the generated From: line at the
> top of the body of the email, unescapes it (to utf-8), and proceeds to
> send the email with no Content-Type specified.
You mean that it converts the header field to utf-8? It doesn't do that
here (neither master nor 1.5.3.5) and IIRC that would be invalid anyway,
because Content-Type applies to exactly that, content, not headers. Your
sample has no non-ASCII characters (or at least I didn't see any), so
git-send-email doesn't add a header to specify a charset.
Björn
> This behaviour is observed in 1.5.3.5. A sample output from
> git-format-patch follows, which demonstrates the problem:
>
>
> >From 3440baaed3b21138f6fc8b80e03769e3903f9c11 Mon Sep 17 00:00:00 2001
> From: =?utf-8?q?Arve=20Hj=C3=B8nnev=C3=A5g?= <arve@android.com>
> Date: Wed, 7 Nov 2007 22:51:44 -0800
> Subject: [PATCH] hrtimer: Add timer back to pending list if it was reactivated and has already expired again.
>
> This avoids problems with timer hardware that does not respond to timers set in the past.
>
> Signed-off-by: Brian Swetland <swetland@android.com>
> ---
> kernel/hrtimer.c | 10 ++++++++--
> 1 files changed, 8 insertions(+), 2 deletions(-)
>
> diff --git a/kernel/hrtimer.c b/kernel/hrtimer.c
> index 22a2514..7c60769 100644
> --- a/kernel/hrtimer.c
> +++ b/kernel/hrtimer.c
> @@ -1149,8 +1149,14 @@ static void run_hrtimer_softirq(struct softirq_action *h)
> * If the timer was rearmed on another CPU, reprogram
> * the event device.
> */
> - if (timer->base->first == &timer->node)
> - hrtimer_reprogram(timer, timer->base);
> + if (timer->base->first == &timer->node) {
> + if(hrtimer_reprogram(timer, timer->base)) {
> + __remove_hrtimer(timer, timer->base,
> + HRTIMER_STATE_PENDING, 0);
> + list_add_tail(&timer->cb_entry,
> + &cpu_base->cb_pending);
> + }
> + }
> }
> }
> spin_unlock_irq(&cpu_base->lock);
^ permalink raw reply
* Re: [PATCH] Make builtin-tag.c use parse_options.
From: Carlos Rica @ 2007-11-10 12:25 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Pierre Habouzit
In-Reply-To: <7vabpmpr9y.fsf@gitster.siamese.dyndns.org>
2007/11/10, Junio C Hamano <gitster@pobox.com>:
> Carlos Rica <jasampler@gmail.com> writes:
>
> > Also, this removes those tests ensuring that repeated
> > -m options don't allocate memory more than once, because now
> > this is done after parsing options, using the last one
> > when more are given. The same for -F.
>
> The reason for this change is...? Is this because it is
> cumbersome to detect and refuse multiple -m options using the
> parseopt API? If so, the API may be what needs to be fixed.
> Taking the last one and discarding earlier ones feels to me an
> arbitrary choice.
>
> While I freely admit that I do not particularly find the "One -m
> introduces one new line, concatenated to form the final
> paragraph" handling of multiple -m options done by git-commit
> nice nor useful, I suspect that it would make more sense to make
> git-tag and git-commit handle multiple -m option consistently,
> if you are going to change the existing semantics. Since some
> people really seem to like multiple -m handling of git-commit,
> the avenue of the least resistance for better consistency would
> be to accept and concatenate (with LF in between) multiple -m
> options.
>
> With multiple -F, I think erroring out would be the sensible
> thing to do, but some people might prefer concatenation. I do
> not care either way as long as commit and tag behave
> consistently.
A solution not needing memory allocation into the option parser
could be setting a callback running over the repeated option
arguments, passing them to the function one per each call.
Then, the user will be able to decide if he wants the arguments
concatenated or only need one of them and prefers erroring out.
Is this already possible with the current parser or the callback
mode only calls using the last option?
^ permalink raw reply
* Re: [PATCH REPLACEMENT for 2/2] git status: show relative paths when run in a subdirectory
From: Michel Marti @ 2007-11-10 12:08 UTC (permalink / raw)
To: git
In-Reply-To: <Pine.LNX.4.64.0711091529570.4362@racer.site>
Untracked files in the current dir don't include the relative path
to the project-root, but changed/updated files do:
# Changes to be committed:
# (use "git reset HEAD <file>..." to unstage)
#
# new file: ../subdir/hello
#
# Untracked files:
# (use "git add <file>..." to include in what will be committed)
#
# world
With the patch below (on top of your changes), the output becomes
# Changes to be committed:
# (use "git reset HEAD <file>..." to unstage)
#
# new file: hello
#
# Untracked files:
# (use "git add <file>..." to include in what will be committed)
#
# world
Cheers,
- Michel
diff --git a/wt-status.c b/wt-status.c
index 0d25362..2cdc8ce 100644
--- a/wt-status.c
+++ b/wt-status.c
@@ -133,8 +133,8 @@ static void wt_status_print_filepair(struct wt_status *s,
strbuf_init(&onebuf, 0);
strbuf_init(&twobuf, 0);
- one = quote_path(p->one->path, -1, &onebuf, s->prefix);
- two = quote_path(p->two->path, -1, &twobuf, s->prefix);
+ one = quote_path(p->one->path, strlen(p->one->path), &onebuf, s->prefix);
+ two = quote_path(p->two->path, strlen(p->two->path), &twobuf, s->prefix);
color_fprintf(s->fp, color(WT_STATUS_HEADER), "#\t");
switch (p->status) {
@@ -233,7 +233,8 @@ static void wt_status_print_initial(struct wt_status *s)
for (i = 0; i < active_nr; i++) {
color_fprintf(s->fp, color(WT_STATUS_HEADER), "#\t");
color_fprintf_ln(s->fp, color(WT_STATUS_UPDATED), "new file: %s",
- quote_path(active_cache[i]->name, -1,
+ quote_path(active_cache[i]->name,
+ strlen(active_cache[i]->name),
&buf, s->prefix));
}
if (active_nr)
^ permalink raw reply related
* [PATCH] Simplify strchrnul() compat code
From: René Scharfe @ 2007-11-10 11:55 UTC (permalink / raw)
To: Andreas Ericsson, Junio C Hamano
Cc: Pierre Habouzit, Git Mailing List, Johannes Schindelin,
Jakub Narebski
In-Reply-To: <473434ED.50002@op5.se>
From: Andreas Ericsson <ae@op5.se>
strchrnul() was introduced in glibc in April 1999 and included in
glibc-2.1. Checking for that version means the majority of all git
users would get to use the optimized version in glibc. Of the
remaining few some might get to use a slightly slower version
than necessary but probably not slower than what we have today.
Rediffed-against-next-by: Rene Scharfe <rene.scharfe@lsrfire.ath.cx>
---
I agree that we can do without providing a way to use a native
version outside glibc until we actually encounter such a thing.
Makefile | 13 -------------
compat/strchrnul.c | 8 --------
git-compat-util.h | 9 +++++++--
3 files changed, 7 insertions(+), 23 deletions(-)
diff --git a/Makefile b/Makefile
index 4f1d7ca..4a5d2b9 100644
--- a/Makefile
+++ b/Makefile
@@ -30,8 +30,6 @@ all::
#
# Define NO_MEMMEM if you don't have memmem.
#
-# Define NO_STRCHRNUL if you don't have strchrnul.
-#
# Define NO_STRLCPY if you don't have strlcpy.
#
# Define NO_STRTOUMAX if you don't have strtoumax in the C library.
@@ -409,7 +407,6 @@ ifeq ($(uname_S),Darwin)
OLD_ICONV = UnfortunatelyYes
NO_STRLCPY = YesPlease
NO_MEMMEM = YesPlease
- NO_STRCHRNUL = YesPlease
endif
ifeq ($(uname_S),SunOS)
NEEDS_SOCKET = YesPlease
@@ -417,7 +414,6 @@ ifeq ($(uname_S),SunOS)
SHELL_PATH = /bin/bash
NO_STRCASESTR = YesPlease
NO_MEMMEM = YesPlease
- NO_STRCHRNUL = YesPlease
NO_HSTRERROR = YesPlease
ifeq ($(uname_R),5.8)
NEEDS_LIBICONV = YesPlease
@@ -443,7 +439,6 @@ ifeq ($(uname_O),Cygwin)
NO_D_INO_IN_DIRENT = YesPlease
NO_STRCASESTR = YesPlease
NO_MEMMEM = YesPlease
- NO_STRCHRNUL = YesPlease
NO_SYMLINK_HEAD = YesPlease
NEEDS_LIBICONV = YesPlease
NO_FAST_WORKING_DIRECTORY = UnfortunatelyYes
@@ -458,14 +453,12 @@ endif
ifeq ($(uname_S),FreeBSD)
NEEDS_LIBICONV = YesPlease
NO_MEMMEM = YesPlease
- NO_STRCHRNUL = YesPlease
BASIC_CFLAGS += -I/usr/local/include
BASIC_LDFLAGS += -L/usr/local/lib
endif
ifeq ($(uname_S),OpenBSD)
NO_STRCASESTR = YesPlease
NO_MEMMEM = YesPlease
- NO_STRCHRNUL = YesPlease
NEEDS_LIBICONV = YesPlease
BASIC_CFLAGS += -I/usr/local/include
BASIC_LDFLAGS += -L/usr/local/lib
@@ -481,7 +474,6 @@ endif
ifeq ($(uname_S),AIX)
NO_STRCASESTR=YesPlease
NO_MEMMEM = YesPlease
- NO_STRCHRNUL = YesPlease
NO_STRLCPY = YesPlease
NEEDS_LIBICONV=YesPlease
endif
@@ -494,7 +486,6 @@ ifeq ($(uname_S),IRIX64)
NO_SETENV=YesPlease
NO_STRCASESTR=YesPlease
NO_MEMMEM = YesPlease
- NO_STRCHRNUL = YesPlease
NO_STRLCPY = YesPlease
NO_SOCKADDR_STORAGE=YesPlease
SHELL_PATH=/usr/gnu/bin/bash
@@ -705,10 +696,6 @@ ifdef NO_MEMMEM
COMPAT_CFLAGS += -DNO_MEMMEM
COMPAT_OBJS += compat/memmem.o
endif
-ifdef NO_STRCHRNUL
- COMPAT_CFLAGS += -DNO_STRCHRNUL
- COMPAT_OBJS += compat/strchrnul.o
-endif
ifdef THREADED_DELTA_SEARCH
BASIC_CFLAGS += -DTHREADED_DELTA_SEARCH
diff --git a/compat/strchrnul.c b/compat/strchrnul.c
deleted file mode 100644
index 51839fe..0000000
--- a/compat/strchrnul.c
+++ /dev/null
@@ -1,8 +0,0 @@
-#include "../git-compat-util.h"
-
-char *gitstrchrnul(const char *s, int c)
-{
- while (*s && *s != c)
- s++;
- return (char *)s;
-}
diff --git a/git-compat-util.h b/git-compat-util.h
index e72654b..11e6df6 100644
--- a/git-compat-util.h
+++ b/git-compat-util.h
@@ -183,9 +183,14 @@ void *gitmemmem(const void *haystack, size_t haystacklen,
const void *needle, size_t needlelen);
#endif
-#ifdef NO_STRCHRNUL
+#if !defined(__GLIBC__) && !__GLIBC_PREREQ(2, 1)
#define strchrnul gitstrchrnul
-char *gitstrchrnul(const char *s, int c);
+static inline char *gitstrchrnul(const char *s, int c)
+{
+ while (*s && *s != c)
+ s++;
+ return (char *)s;
+}
#endif
extern void release_pack_memory(size_t, int);
^ permalink raw reply related
* Re: cogito remote branch
From: Jakub Narebski @ 2007-11-10 11:52 UTC (permalink / raw)
To: git
In-Reply-To: <Pine.LNX.4.64.0711101217130.4330@castor.milkiway.cos>
Michael Dressel wrote:
> On Fri, 9 Nov 2007, Jon Loeliger wrote:
>> On Fri, 2007-11-09 at 10:10, MichaelTiloDressel@t-online.de wrote:
>>
>>> There are just some features
>>> which simplify things for me in cogito. E.g. in cogito in the simplest
>>> way you don't need to be aware of the index. While with git
>>> you have to remember to add the changes to the index explicitly
>>> to get them committed.
>>
>> "git commit -a ..." might be useful for you.
>>
>> Other lingering cogito-isms you think are lacking in git?
>
> Thanks for the hint. I have to use git for a while to understand what may
> still be lacking (at least for me, if at all). Off the top of my head one
> other difference is that if I do a cg-push the remote (or origin) head is
> updated automatically, I think.
If you mean that tracking branches are updated on push, this is what
git also does from some time (perhaps not in released version, so please
wait or run 'master').
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: cogito remote branch
From: Michael Dressel @ 2007-11-10 11:27 UTC (permalink / raw)
To: Jon Loeliger; +Cc: Johannes Schindelin, Git List
In-Reply-To: <1194625691.1471.3.camel@ld0161-tx32>
On Fri, 9 Nov 2007, Jon Loeliger wrote:
> On Fri, 2007-11-09 at 10:10, MichaelTiloDressel@t-online.de wrote:
> > There are just some features
> > which simplify things for me in cogito. E.g. in cogito in the simplest
> > way you don't need to be aware of the index. While with git
> > you have to remember to add the changes to the index explicitly
> > to get them committed.
> >
> > Cheers,
> > Michael
>
> "git commit -a ..." might be useful for you.
>
> Other lingering cogito-isms you think are lacking in git?
Thanks for the hint. I have to use git for a while to understand what may
still be lacking (at least for me, if at all). Off the top of my head one
other difference is that if I do a cg-push the remote (or origin) head is
updated automatically, I think.
Cheers,
Michael
^ permalink raw reply
* [PATCH 3/3] --format=pretty: avoid calculating expensive expansions twice
From: René Scharfe @ 2007-11-10 11:18 UTC (permalink / raw)
To: Jeff King, Junio C Hamano
Cc: Paul Mackerras, Git Mailing List, Pierre Habouzit,
Johannes Schindelin
In-Reply-To: <20071110004635.GA14992@sigill.intra.peff.net>
As Jeff King remarked, format strings with duplicate placeholders can
be slow to expand, because each instance is calculated anew.
This patch makes use of the fact that format_commit_message() and its
helper functions only ever add stuff to the end of the strbuf. For
certain expensive placeholders, store the offset and length of their
expansion with the strbuf at the first occurrence. Later they
expansion result can simply be copied from there -- no malloc() or
strdup() required.
These certain placeholders are the abbreviated commit, tree and
parent hashes, as the search for a unique abbreviated hash is quite
costly. Here are the times for next (best of three runs):
$ time git log --pretty=format:%h >/dev/null
real 0m0.611s
user 0m0.404s
sys 0m0.204s
$ time git log --pretty=format:%h%h%h%h >/dev/null
real 0m1.206s
user 0m0.744s
sys 0m0.452s
And here those with this patch (and the previous two); the speedup
of the single placeholder case is just noise:
$ time git log --pretty=format:%h >/dev/null
real 0m0.608s
user 0m0.416s
sys 0m0.192s
$ time git log --pretty=format:%h%h%h%h >/dev/null
real 0m0.639s
user 0m0.488s
sys 0m0.140s
Signed-off-by: Rene Scharfe <rene.scharfe@lsrfire.ath.cx>
---
pretty.c | 32 ++++++++++++++++++++++++++++++++
1 files changed, 32 insertions(+), 0 deletions(-)
diff --git a/pretty.c b/pretty.c
index 0c2f83b..ab142b8 100644
--- a/pretty.c
+++ b/pretty.c
@@ -369,8 +369,30 @@ struct format_commit_context {
struct chunk committer;
struct chunk encoding;
size_t body_off;
+
+ /* The following ones are relative to the result struct strbuf. */
+ struct chunk abbrev_commit_hash;
+ struct chunk abbrev_tree_hash;
+ struct chunk abbrev_parent_hashes;
};
+static int add_again(struct strbuf *sb, struct chunk *chunk)
+{
+ if (chunk->len) {
+ strbuf_adddup(sb, chunk->off, chunk->len);
+ return 1;
+ }
+
+ /*
+ * We haven't seen this chunk before. Our caller is surely
+ * going to add it the hard way now. Remember the most likely
+ * start of the to-be-added chunk: the current end of the
+ * struct strbuf.
+ */
+ chunk->off = sb->len;
+ return 0;
+}
+
static void parse_commit_header(struct format_commit_context *context)
{
const char *msg = context->commit->buffer;
@@ -447,15 +469,21 @@ static void format_commit_item(struct strbuf *sb, const char *placeholder,
strbuf_addstr(sb, sha1_to_hex(commit->object.sha1));
return;
case 'h': /* abbreviated commit hash */
+ if (add_again(sb, &c->abbrev_commit_hash))
+ return;
strbuf_addstr(sb, find_unique_abbrev(commit->object.sha1,
DEFAULT_ABBREV));
+ c->abbrev_commit_hash.len = sb->len - c->abbrev_commit_hash.off;
return;
case 'T': /* tree hash */
strbuf_addstr(sb, sha1_to_hex(commit->tree->object.sha1));
return;
case 't': /* abbreviated tree hash */
+ if (add_again(sb, &c->abbrev_tree_hash))
+ return;
strbuf_addstr(sb, find_unique_abbrev(commit->tree->object.sha1,
DEFAULT_ABBREV));
+ c->abbrev_tree_hash.len = sb->len - c->abbrev_tree_hash.off;
return;
case 'P': /* parent hashes */
for (p = commit->parents; p; p = p->next) {
@@ -465,12 +493,16 @@ static void format_commit_item(struct strbuf *sb, const char *placeholder,
}
return;
case 'p': /* abbreviated parent hashes */
+ if (add_again(sb, &c->abbrev_parent_hashes))
+ return;
for (p = commit->parents; p; p = p->next) {
if (p != commit->parents)
strbuf_addch(sb, ' ');
strbuf_addstr(sb, find_unique_abbrev(
p->item->object.sha1, DEFAULT_ABBREV));
}
+ c->abbrev_parent_hashes.len = sb->len -
+ c->abbrev_parent_hashes.off;
return;
case 'm': /* left/right/bottom */
strbuf_addch(sb, (commit->object.flags & BOUNDARY)
--
1.5.3.5.1651.g30bf
^ permalink raw reply related
* Re: [PATCH 07/11] git-fetch: Limit automated tag following to only fetched objects
From: CJ van den Berg @ 2007-11-09 12:12 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Junio C Hamano, git
In-Reply-To: <20071109110631.GG19368@spearce.org>
[-- Attachment #1: Type: text/plain, Size: 849 bytes --]
On Fri, Nov 09, 2007 at 06:06:31AM -0500, Shawn O. Pearce wrote:
> We now redefine the rule to be: "tags are fetched if they refer
> to an object that was just transferred; that is an object that is
> new to your repository". This rule is quite simple to understand,
> you only get a tag if you just got the object it refers to.
With this new rule a retrospectively pushed tag will never be fetched,
right? With our local work flow tags are only ever pushed retrospectively
because the tagged commit has to first pass regression tests. So this would
be a major regression for us.
I think adding a temporal dependency between the pushing and fetching of
branches and tags in this way is likely to cause even more confusing and
apparently random behaviour.
--
CJ van den Berg
mailto:cj@vdbonline.com
xmpp:cj@vdbonline.com
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* [PATCH 2/3] add strbuf_adddup()
From: René Scharfe @ 2007-11-10 11:16 UTC (permalink / raw)
To: Jeff King, Junio C Hamano
Cc: Paul Mackerras, Git Mailing List, Pierre Habouzit,
Johannes Schindelin
In-Reply-To: <20071110004635.GA14992@sigill.intra.peff.net>
Add a new function, strbuf_adddup(), that appends a duplicate of a
part of a struct strbuf to end of the latter.
Signed-off-by: Rene Scharfe <rene.scharfe@lsrfire.ath.cx>
---
strbuf.c | 7 +++++++
strbuf.h | 1 +
2 files changed, 8 insertions(+), 0 deletions(-)
diff --git a/strbuf.c b/strbuf.c
index 536b432..dbd8c4b 100644
--- a/strbuf.c
+++ b/strbuf.c
@@ -106,6 +106,13 @@ void strbuf_add(struct strbuf *sb, const void *data, size_t len)
strbuf_setlen(sb, sb->len + len);
}
+void strbuf_adddup(struct strbuf *sb, size_t pos, size_t len)
+{
+ strbuf_grow(sb, len);
+ memcpy(sb->buf + sb->len, sb->buf + pos, len);
+ strbuf_setlen(sb, sb->len + len);
+}
+
void strbuf_addf(struct strbuf *sb, const char *fmt, ...)
{
int len;
diff --git a/strbuf.h b/strbuf.h
index 21d8944..1391912 100644
--- a/strbuf.h
+++ b/strbuf.h
@@ -101,6 +101,7 @@ static inline void strbuf_addstr(struct strbuf *sb, const char *s) {
static inline void strbuf_addbuf(struct strbuf *sb, struct strbuf *sb2) {
strbuf_add(sb, sb2->buf, sb2->len);
}
+extern void strbuf_adddup(struct strbuf *sb, size_t pos, size_t len);
typedef void (*expand_fn_t) (struct strbuf *sb, const char *placeholder, void *context);
extern void strbuf_expand(struct strbuf *sb, const char *format, const char **placeholders, expand_fn_t fn, void *context);
--
1.5.3.5.1651.g30bf
^ permalink raw reply related
* Re: [PATCH v3] user-manual: add advanced topic "bisecting merges"
From: Steffen Prohaska @ 2007-11-10 11:16 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Benoit Sigoure, Andreas Ericsson, Johannes Sixt
In-Reply-To: <7vsl3emlpc.fsf@gitster.siamese.dyndns.org>
On Nov 10, 2007, at 11:36 AM, Junio C Hamano wrote:
> Steffen Prohaska <prohaska@zib.de> writes:
>
>> ...
>> +A solution is to linearize the history by rebasing the lower
>> +branch on top of the upper, instead of merging. There were no
>
> Hmm. When I wrote it, I did not mean this as a "solution", but
> as an illustration of how a merge heavy history and a linear
> history have impact on bisectability.
I agree. This is what I understood. But later Johannes brought up
the idea of naming it a "solution"; and some others liked this.
We should probably move the discussion to Chapter 5 "Rewriting
history and maintaining patch series". Discussing pros and cons
of merge versus rebase makes more sense there. The discussion
would go right after "Problems with rewriting history". So,
users should be warned not to rebase without thinking about
the consequences. Another advantage is that users should
have learnt more about git when they reach Chapter 5. Hence,
it should be easier to follow the discussion.
> So it is more like...
>
> On the other hand, if you did not merge at C but rebased the
> history between Z to B on top of A, you would have get this
> linear history [illustration here]. Bisecting between Z and
> D* would hit a single culprit commit Y* instead. This tends
> to be easier to understand why it is broken.
I'll take this...
> For this reason, many experienced git users, even when they are
> working on an otherwise merge-heavy project, keep the histories
> linear by rebasing their work on top of public upstreams before
> publishing (when able). An extreme example: merges from a few
> top-level lieutenants to Linus in the kernel, e.g. David Miller,
> are known to _almost always_ fast-forward for Linus.
>
> IOW, the description is to mildly encourage private rebasing to
> keep the job of later bisecting (for potentially others) easier.
> I realize I originally wrote as if C (merge) was made by the
> same person as the person who ends up bisecting, but that is
> not necessarily the case. Keeping the history without needless
> merges tend to make _other_ people's lives simpler.
>
> And after encouraging the private rebasing, I would continue
> like...
>
> But if you already made a merge C instead of rebasing, all
> is not lost. In the illustrated case, you can easily rebase
> one parent branch on top of the other after the fact, just
> to understand the history and to make the history more
> easily bisectable.
s/more easily bisectable/easier to bisect/ ?
> Even though the published history should
> not be rewound without consent with others in the project,
> nobody gets hurt if you rebased to create alternate history
> privately. After understanding the breakage and coming up
> with a fix on top of D*, you can discard that rebased
> history, and apply the same fix on top of D, as D* and D
> should have the identical trees.
... and will prepare PATCH v4.
Steffen
^ permalink raw reply
* [PATCH 1/3] --pretty=format: parse commit message only once
From: René Scharfe @ 2007-11-10 11:14 UTC (permalink / raw)
To: Jeff King, Junio C Hamano
Cc: Paul Mackerras, Git Mailing List, Pierre Habouzit,
Johannes Schindelin
In-Reply-To: <20071110004635.GA14992@sigill.intra.peff.net>
As Jeff King pointed out, some placeholder expansions are related to
each other: the steps to calculate one go most of the way towards
calculating the other, too.
This patch makes format_commit_message() parse the commit message
only once, remembering the position of each item. This speeds up
handling of format strings containing multiple placeholders from the
set %s, %a*, %c*, %e, %b.
Here are the timings for the git version in next. The first one is
to estimate the overhead of the caching, the second one is taken
from http://svn.tue.mpg.de/tentakel/trunk/tentakel/Makefile as an
example of a format string found in the wild. The times are the
fastest of three consecutive runs in each case:
$ time git log --pretty=format:%e >/dev/null
real 0m0.381s
user 0m0.340s
sys 0m0.024s
$ time git log --pretty=format:"* %cd %cn%n%n%s%n%b" >/dev/null
real 0m0.623s
user 0m0.556s
sys 0m0.052s
And here the times with this patch:
$ time git log --pretty=format:%e >/dev/null
real 0m0.385s
user 0m0.332s
sys 0m0.040s
$ time git log --pretty=format:"* %cd %cn%n%n%s%n%b" >/dev/null
real 0m0.563s
user 0m0.504s
sys 0m0.048s
Signed-off-by: Rene Scharfe <rene.scharfe@lsrfire.ath.cx>
---
pretty.c | 124 +++++++++++++++++++++++++++++++++++++++++---------------------
1 files changed, 82 insertions(+), 42 deletions(-)
diff --git a/pretty.c b/pretty.c
index 9fbd73f..0c2f83b 100644
--- a/pretty.c
+++ b/pretty.c
@@ -354,14 +354,67 @@ static void format_person_part(struct strbuf *sb, char part,
}
}
-static void format_commit_item(struct strbuf *sb, const char *placeholder,
- void *context)
+struct chunk {
+ size_t off;
+ size_t len;
+};
+
+struct format_commit_context {
+ const struct commit *commit;
+
+ /* These offsets are relative to the start of the commit message. */
+ int commit_header_parsed;
+ struct chunk subject;
+ struct chunk author;
+ struct chunk committer;
+ struct chunk encoding;
+ size_t body_off;
+};
+
+static void parse_commit_header(struct format_commit_context *context)
{
- const struct commit *commit = context;
- struct commit_list *p;
+ const char *msg = context->commit->buffer;
int i;
enum { HEADER, SUBJECT, BODY } state;
+
+ for (i = 0, state = HEADER; msg[i] && state < BODY; i++) {
+ int eol;
+ for (eol = i; msg[eol] && msg[eol] != '\n'; eol++)
+ ; /* do nothing */
+
+ if (state == SUBJECT) {
+ context->subject.off = i;
+ context->subject.len = eol - i;
+ i = eol;
+ }
+ if (i == eol) {
+ state++;
+ /* strip empty lines */
+ while (msg[eol + 1] == '\n')
+ eol++;
+ } else if (!prefixcmp(msg + i, "author ")) {
+ context->author.off = i + 7;
+ context->author.len = eol - i - 7;
+ } else if (!prefixcmp(msg + i, "committer ")) {
+ context->committer.off = i + 10;
+ context->committer.len = eol - i - 10;
+ } else if (!prefixcmp(msg + i, "encoding ")) {
+ context->encoding.off = i + 9;
+ context->encoding.len = eol - i - 9;
+ }
+ i = eol;
+ }
+ context->body_off = i;
+ context->commit_header_parsed = 1;
+}
+
+static void format_commit_item(struct strbuf *sb, const char *placeholder,
+ void *context)
+{
+ struct format_commit_context *c = context;
+ const struct commit *commit = c->commit;
const char *msg = commit->buffer;
+ struct commit_list *p;
/* these are independent of the commit */
switch (placeholder[0]) {
@@ -429,45 +482,28 @@ static void format_commit_item(struct strbuf *sb, const char *placeholder,
}
/* For the rest we have to parse the commit header. */
- for (i = 0, state = HEADER; msg[i] && state < BODY; i++) {
- int eol;
- for (eol = i; msg[eol] && msg[eol] != '\n'; eol++)
- ; /* do nothing */
+ if (!c->commit_header_parsed)
+ parse_commit_header(c);
- if (state == SUBJECT) {
- if (placeholder[0] == 's') {
- strbuf_add(sb, msg + i, eol - i);
- return;
- }
- i = eol;
- }
- if (i == eol) {
- state++;
- /* strip empty lines */
- while (msg[eol + 1] == '\n')
- eol++;
- } else if (!prefixcmp(msg + i, "author ")) {
- if (placeholder[0] == 'a') {
- format_person_part(sb, placeholder[1],
- msg + i + 7, eol - i - 7);
- return;
- }
- } else if (!prefixcmp(msg + i, "committer ")) {
- if (placeholder[0] == 'c') {
- format_person_part(sb, placeholder[1],
- msg + i + 10, eol - i - 10);
- return;
- }
- } else if (!prefixcmp(msg + i, "encoding ")) {
- if (placeholder[0] == 'e') {
- strbuf_add(sb, msg + i + 9, eol - i - 9);
- return;
- }
- }
- i = eol;
+ switch (placeholder[0]) {
+ case 's':
+ strbuf_add(sb, msg + c->subject.off, c->subject.len);
+ return;
+ case 'a':
+ format_person_part(sb, placeholder[1],
+ msg + c->author.off, c->author.len);
+ return;
+ case 'c':
+ format_person_part(sb, placeholder[1],
+ msg + c->committer.off, c->committer.len);
+ return;
+ case 'e':
+ strbuf_add(sb, msg + c->encoding.off, c->encoding.len);
+ return;
+ case 'b':
+ strbuf_addstr(sb, msg + c->body_off);
+ return;
}
- if (msg[i] && placeholder[0] == 'b') /* body */
- strbuf_addstr(sb, msg + i);
}
void format_commit_message(const struct commit *commit,
@@ -505,7 +541,11 @@ void format_commit_message(const struct commit *commit,
"m", /* left/right/bottom */
NULL
};
- strbuf_expand(sb, format, placeholders, format_commit_item, (void *)commit);
+ struct format_commit_context context;
+
+ memset(&context, 0, sizeof(context));
+ context.commit = commit;
+ strbuf_expand(sb, format, placeholders, format_commit_item, &context);
}
static void pp_header(enum cmit_fmt fmt,
--
1.5.3.5.1651.g30bf
^ permalink raw reply related
* Re: [PATCH 2/2] --pretty=format: on-demand format expansion
From: René Scharfe @ 2007-11-10 11:12 UTC (permalink / raw)
To: Jeff King
Cc: Junio C Hamano, Paul Mackerras, Git Mailing List, Pierre Habouzit,
Johannes Schindelin
In-Reply-To: <20071110004635.GA14992@sigill.intra.peff.net>
Jeff King schrieb:
> On Sat, Nov 10, 2007 at 12:16:30AM +0100, René Scharfe wrote:
>
>>> A partial patch on top of yours is below (it caches commit and tree
>>> abbreviations; parent abbreviations and person-parsing are probably
>>> worth doing). Some timings:
>> ... but I object to the choice of items to cache. Are there real-world
>> formats containing the same placeholder twice or even more often?
>
> My choice of items was more "here is what I am talking about" and not
> "this is the best set of items."
>
> As for what real-world workloads are like, part of the _point_ of
> --pretty=format: is for one-off formats that users use in their
> workflow. So yes, I have used formats that repeat specifiers, but they
> are probably not common.
Hmm, OK.
> The point of my timings was to show not only that we sped up that
> uncommon case, but that there was negligible cost to the common case.
> And since we don't know what formats users will provide, it makes sense
> not to have lousy performance on the uncommon.
My suspicion was that it's more like "never used" rather than
"uncommon". Since you're a duplicate placeholder user, it's not "never"
any more. :)
>> There is probably more to gain from the interdependencies of different
>> placeholders. The patch below attempts to avoid parsing the commit
>> twice, by saving pointers to the different parts.
>
> Looks sane, although I don't see any reason this couldn't just go on top
> of my patch, and then we can speed up both cases.
Yes, the two are independent. I don't like the malloc()'s in your
patch, though, and have cooked up a different one on top of a cleaned up
version of mine. It plays the dirty trick of reading expansions of
repeated placeholders from the strbuf..
René
^ permalink raw reply
* Re: [PATCH] Make GIT_INDEX_FILE apply to git-commit
From: Junio C Hamano @ 2007-11-10 10:39 UTC (permalink / raw)
To: Remi Vanicat; +Cc: git
In-Reply-To: <87abpml8rx.dlv@vanicat.homelinux.org>
Sounds sensible. Tests?
^ permalink raw reply
* Re: [PATCH v3] user-manual: add advanced topic "bisecting merges"
From: Junio C Hamano @ 2007-11-10 10:36 UTC (permalink / raw)
To: Steffen Prohaska; +Cc: git, Benoit Sigoure, Andreas Ericsson, Johannes Sixt
In-Reply-To: <119468808499-git-send-email-prohaska@zib.de>
Steffen Prohaska <prohaska@zib.de> writes:
> ...
> +A solution is to linearize the history by rebasing the lower
> +branch on top of the upper, instead of merging. There were no
Hmm. When I wrote it, I did not mean this as a "solution", but
as an illustration of how a merge heavy history and a linear
history have impact on bisectability. So it is more like...
On the other hand, if you did not merge at C but rebased the
history between Z to B on top of A, you would have get this
linear history [illustration here]. Bisecting between Z and
D* would hit a single culprit commit Y* instead. This tends
to be easier to understand why it is broken.
For this reason, many experienced git users, even when they are
working on an otherwise merge-heavy project, keep the histories
linear by rebasing their work on top of public upstreams before
publishing (when able). An extreme example: merges from a few
top-level lieutenants to Linus in the kernel, e.g. David Miller,
are known to _almost always_ fast-forward for Linus.
IOW, the description is to mildly encourage private rebasing to
keep the job of later bisecting (for potentially others) easier.
I realize I originally wrote as if C (merge) was made by the
same person as the person who ends up bisecting, but that is
not necessarily the case. Keeping the history without needless
merges tend to make _other_ people's lives simpler.
And after encouraging the private rebasing, I would continue
like...
But if you already made a merge C instead of rebasing, all
is not lost. In the illustrated case, you can easily rebase
one parent branch on top of the other after the fact, just
to understand the history and to make the history more
easily bisectable. Even though the published history should
not be rewound without consent with others in the project,
nobody gets hurt if you rebased to create alternate history
privately. After understanding the breakage and coming up
with a fix on top of D*, you can discard that rebased
history, and apply the same fix on top of D, as D* and D
should have the identical trees.
^ permalink raw reply
* Re: `git-send-email' doesn't specify `Content-Type'
From: Brian Swetland @ 2007-11-10 10:14 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Ludovic Courtès, git
In-Reply-To: <Pine.LNX.4.64.0711100052290.4362@racer.site>
[Johannes Schindelin <Johannes.Schindelin@gmx.de>]
> Hi,
>
> On Sat, 10 Nov 2007, Ludovic Court?s wrote:
>
> > Apparently, `git-send-email' doesn't specify the email's `Content-Type',
> > notably its charset, while it should really add something like:
> >
> > Content-Type: text/plain; charset=UTF-8
> >
> > Or did I miss an option or something?
>
> Apparently. There was a thread some days ago, about that very issue.
> Please find and read it.
The thread I found says that git-send-email should do the right thing if
there are non-ascii characters, but this does not seem to be the case
for me.
The example I have involves a coworker's name which needs non-ascii
characters. They are properly escaped in the From: line generated by
git-format-patch. git-send-email puts the generated From: line at the
top of the body of the email, unescapes it (to utf-8), and proceeds to
send the email with no Content-Type specified.
This behaviour is observed in 1.5.3.5. A sample output from
git-format-patch follows, which demonstrates the problem:
>From 3440baaed3b21138f6fc8b80e03769e3903f9c11 Mon Sep 17 00:00:00 2001
From: =?utf-8?q?Arve=20Hj=C3=B8nnev=C3=A5g?= <arve@android.com>
Date: Wed, 7 Nov 2007 22:51:44 -0800
Subject: [PATCH] hrtimer: Add timer back to pending list if it was reactivated and has already expired again.
This avoids problems with timer hardware that does not respond to timers set in the past.
Signed-off-by: Brian Swetland <swetland@android.com>
---
kernel/hrtimer.c | 10 ++++++++--
1 files changed, 8 insertions(+), 2 deletions(-)
diff --git a/kernel/hrtimer.c b/kernel/hrtimer.c
index 22a2514..7c60769 100644
--- a/kernel/hrtimer.c
+++ b/kernel/hrtimer.c
@@ -1149,8 +1149,14 @@ static void run_hrtimer_softirq(struct softirq_action *h)
* If the timer was rearmed on another CPU, reprogram
* the event device.
*/
- if (timer->base->first == &timer->node)
- hrtimer_reprogram(timer, timer->base);
+ if (timer->base->first == &timer->node) {
+ if(hrtimer_reprogram(timer, timer->base)) {
+ __remove_hrtimer(timer, timer->base,
+ HRTIMER_STATE_PENDING, 0);
+ list_add_tail(&timer->cb_entry,
+ &cpu_base->cb_pending);
+ }
+ }
}
}
spin_unlock_irq(&cpu_base->lock);
--
1.5.3.5
^ permalink raw reply related
* [PATCH] Make GIT_INDEX_FILE apply to git-commit
From: Remi Vanicat @ 2007-11-10 10:00 UTC (permalink / raw)
To: git
Currently, when committing, git-commit ignore the value of
GIT_INDEX_FILE, and always use $GIT_DIR/index. This patch
fix it.
Signed-off-by: Rémi Vanicat <vanicat@debian.org>
---
git-commit.sh | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/git-commit.sh b/git-commit.sh
index fcb8443..6490045 100755
--- a/git-commit.sh
+++ b/git-commit.sh
@@ -26,7 +26,7 @@ refuse_partial () {
}
TMP_INDEX=
-THIS_INDEX="$GIT_DIR/index"
+THIS_INDEX="${GIT_INDEX_FILE:-$GIT_DIR/index}"
NEXT_INDEX="$GIT_DIR/next-index$$"
rm -f "$NEXT_INDEX"
save_index () {
--
1.5.3.5
^ permalink raw reply related
* Re: linux-2.6 clone with CygWin git
From: Andreas Ericsson @ 2007-11-10 9:50 UTC (permalink / raw)
To: Pascal Obry; +Cc: Medve Emilian, git
In-Reply-To: <473495E1.3080305@obry.net>
Pascal Obry wrote:
> David Brown a écrit :
>> It's because of the case-insensitive nature of the filesystem. The kernel
>> contains both an xt_connmark.h and an xt_CONNMARK.h file, that are
>> different. But only one exists on Windows, so git sees the first one it
>> wrote as having been modified.
>
> Probably not something for the list... but if you ask me this is just
> bad practice anyway. Casing has no semantic, it is nonsense to have two
> files with the same name with different casing!
>
You're right, it's not something for this list. Try arguing your case at
the linux kernel mailing list.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* [PATCH v3] user-manual: add advanced topic "bisecting merges"
From: Steffen Prohaska @ 2007-11-10 9:48 UTC (permalink / raw)
To: git
Cc: Junio C Hamano, Benoit Sigoure, Andreas Ericsson, Johannes Sixt,
Steffen Prohaska
In-Reply-To: <217E7104-312D-4D0C-BC66-C4829779C216@zib.de>
This commits adds a discussion of the challenge of bisecting
merge commits to the user manual. The original author is
Junio C Hamano <gitster@pobox.com>, who posted the text to
the mailing list:
<http://marc.info/?l=git&m=119403257315527&w=2>.
The text from the email is slightly adapted for the manual.
The discussion is added to "Exploring git history" in a
sub-section titled "Advanced topics". The discussion requires
detailed knowledge about git. It is assumed that the reader will
skip advanced topics on first reading. At least the text suggest
to do so.
The text includes suggestions and fixed by
Ralf Wildenhues <Ralf.Wildenhues@gmx.de>,
Benoit Sigoure <tsuna@lrde.epita.fr>,
Johannes Sixt <j.sixt@viscovery.net>.
Signed-off-by: Steffen Prohaska <prohaska@zib.de>
---
Documentation/user-manual.txt | 104 +++++++++++++++++++++++++++++++++++++++++
1 files changed, 104 insertions(+), 0 deletions(-)
Next try.
The text now contains an introductory paragraph, proposes rebase as a
'solution', and recommends to throw away the rebased branch.
Steffen
diff --git a/Documentation/user-manual.txt b/Documentation/user-manual.txt
index d99adc6..2f4c314 100644
--- a/Documentation/user-manual.txt
+++ b/Documentation/user-manual.txt
@@ -934,6 +934,110 @@ Figuring out why this works is left as an exercise to the (advanced)
student. The gitlink:git-log[1], gitlink:git-diff-tree[1], and
gitlink:git-hash-object[1] man pages may prove helpful.
+[[history-advanced-topics]]
+Advanced topics
+---------------
+This section covers advanced topics that typically require more
+knowledge about git than the manual presented to this point.
+
+You may want to skip the section on first reading, and come back
+later when you have a better understanding of git.
+
+[[bisect-merges]]
+Why bisecting merge commits can be harder than bisecting linear history
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+This section discusses how gitlink:git-bisect[1] plays
+with differently shaped histories. If you did not yet
+publish a branch you can use either gitlink:git-merge[1] or
+gitlink:git-rebase[1] to integrate changes from a second
+branch. The two approaches create differently shaped
+histories. This section discusses the implications on
+gitlink:git-bisect[1]. If the history is already published
+temporarily rebasing can still be helpful for bisecting.
+
+The following text is based upon an email by Junio C. Hamano to
+the git mailing list
+(link:http://marc.info/?l=git&m=119403257315527&w=2[link:http://marc.info/?l=git&m=119403257315527&w=2]).
+It was slightly adapted for this manual.
+
+Using gitlink:git-bisect[1] on a history with merges can be challenging.
+Bisecting through merges is not a
+technical problem. The real problem is what to do when the
+culprit turns out to be a merge commit. How to spot what really
+is wrong, and figure out how to fix. The problem is not for the
+tool but for the human, and it is real.
+
+Imagine this history.
+
+................................................
+ ---Z---o---X---...---o---A---C---D
+ \ /
+ o---o---Y---...---o---B
+................................................
+
+Suppose that on the upper development line, the meaning of one
+of the functions that existed at Z was changed at commit X. The
+commits from Z leading to A change both the function's
+implementation and all calling sites that existed at Z, as well
+as new calling sites they add, to be consistent. There is no
+bug at A.
+
+Suppose that in the meantime the lower development line somebody
+added a new calling site for that function at commit Y. The
+commits from Z leading to B all assume the old semantics of that
+function and the callers and the callee are consistent with each
+other. There is no bug at B, either.
+
+You merge to create C. There is no textual conflict with this
+three way merge, and the result merges cleanly. You bisect
+this, because you found D is bad and you know Z was good. Your
+bisect will find that C (merge) is broken. Understandably so,
+as at C, the new calling site of the function added by the lower
+branch is not converted to the new semantics, while all the
+other calling sites that already existed at Z would have been
+converted by the merge. The new calling site has semantic
+adjustment needed, but you do not know that yet. You need to
+find out that that is the cause of the breakage by looking at the
+merge commit C and the history leading to it.
+
+How would you do that?
+
+Both "git diff A C" and "git diff B C" would be an enormous patch.
+Each of them essentially shows the whole change on each branch
+since they diverged. The developers may have well behaved to
+create good commits that follow the "commit small, commit often,
+commit well contained units" mantra, and each individual commit
+leading from Z to A and from Z to B may be easy to review and
+understand, but looking at these small and easily reviewable
+steps alone would not let you spot the breakage. You need to
+have a global picture of what the upper branch did (and
+among many, one of them is to change the semantics of that
+particular function) and look first at the huge "diff A C"
+(which shows the change the lower branch introduces), and see if
+that huge change is consistent with what have been done between
+Z and A.
+
+A solution is to linearize the history by rebasing the lower
+branch on top of the upper, instead of merging. There were no
+textual conflicts in the original three way merge. So there
+should not be conflicts during rebase either. Now the bug becomes
+much easier to find and understand. Your history would instead
+be:
+
+................................................................
+ ---Z---o---X--...---o---A---o---o---Y*--...---o---B*--D*
+................................................................
+
+and there is a single commit Y* between A and B* that introduced
+the new calling site that still uses the old semantics of the
+function, even though that was already modified at X. "git show
+Y*" will be a much smaller patch than "git diff A C" and it is
+much easier to deal with.
+
+Now that you know what caused the error (and how to fix it),
+throw away the rebased branch, and commit a fix on top of D.
+
+
[[Developing-with-git]]
Developing with git
===================
--
1.5.3.5.578.g886d
^ permalink raw reply related
* Re: [PATCH] Make builtin-tag.c use parse_options.
From: Junio C Hamano @ 2007-11-10 9:41 UTC (permalink / raw)
To: Kristian Høgsberg; +Cc: git, Carlos Rica
In-Reply-To: <7vhcjuo3h9.fsf@gitster.siamese.dyndns.org>
This is an updated patch to the test script...
t/t7501-commit.sh | 69 +++++++++++++++++++++++++++++++++++++++++++++++++++++
1 files changed, 69 insertions(+), 0 deletions(-)
diff --git a/t/t7501-commit.sh b/t/t7501-commit.sh
index b151b51..4dc35bd 100644
--- a/t/t7501-commit.sh
+++ b/t/t7501-commit.sh
@@ -163,4 +163,73 @@ test_expect_success 'partial commit that involves removal (3)' '
'
+author="The Real Author <someguy@his.email.org>"
+test_expect_success 'amend commit to fix author' '
+
+ oldtick=$GIT_AUTHOR_DATE &&
+ test_tick &&
+ git reset --hard &&
+ git cat-file -p HEAD |
+ sed -e "s/author.*/author $author $oldtick/" \
+ -e "s/^\(committer.*> \).*$/\1$GIT_COMMITTER_DATE/" > \
+ expected &&
+ git commit --amend --author="$author" &&
+ git cat-file -p HEAD > current &&
+ diff expected current
+
+'
+
+test_expect_success 'sign off (1)' '
+
+ echo 1 >positive &&
+ git add positive &&
+ git commit -s -m "thank you" &&
+ git cat-file commit HEAD | sed -e "1,/^\$/d" >actual &&
+ (
+ echo thank you
+ echo
+ git var GIT_COMMITTER_IDENT |
+ sed -e "s/>.*/>/" -e "s/^/Signed-off-by: /"
+ ) >expected &&
+ diff -u expected actual
+
+'
+
+test_expect_success 'sign off (2)' '
+
+ echo 2 >positive &&
+ git add positive &&
+ existing="Signed-off-by: Watch This <watchthis@example.com>" &&
+ git commit -s -m "thank you
+
+$existing" &&
+ git cat-file commit HEAD | sed -e "1,/^\$/d" >actual &&
+ (
+ echo thank you
+ echo
+ echo $existing
+ git var GIT_COMMITTER_IDENT |
+ sed -e "s/>.*/>/" -e "s/^/Signed-off-by: /"
+ ) >expected &&
+ diff -u expected actual
+
+'
+
+test_expect_success 'multiple -m' '
+
+ >negative &&
+ git add negative &&
+ git commit -m "one" -m "two" -m "three" &&
+ git cat-file commit HEAD | sed -e "1,/^\$/d" >actual &&
+ (
+ echo one
+ echo
+ echo two
+ echo
+ echo three
+ ) >expected &&
+ diff -u expected actual
+
+'
+
test_done
^ permalink raw reply related
* Re: gitweb, updating 'last changed' column on the project page
From: Jakub Narebski @ 2007-11-10 9:34 UTC (permalink / raw)
To: Jon Smirl; +Cc: git
In-Reply-To: <9e4733910711092210o65759276sd6970af5d29f2f32@mail.gmail.com>
On Saturday, 10 November 2007, Jon Smirl wrote:
> On 11/10/07, Jon Smirl <jonsmirl@gmail.com> wrote:
>> On 11/9/07, Jakub Narebski <jnareb@gmail.com> wrote:
>>> Jon Smirl wrote:
>>>
>>>> At http://git.digispeaker.com/ the 'last change' column is not getting updated.
>>>>
>>>> mpc5200b.git
>>>> DigiSpeaker for Freescale MPC5200B.
>>>> Jon Smirl
>>>> 5 weeks ago
>>>> summary | shortlog | log | tree
>>>>
>>>> It still says 5 weeks ago, but if I click on the project last change is today.
>>>>
>>>> What controls this? I tried running update-server-info
>>>
>>> What does
>>>
>>> git for-each-ref --format="%(refname):%09%(committer)" --sort=-committerdate
>>> refs/heads
>>
>> [daedalus]$ git for-each-ref --format="%(refname):%09%(committer)" \
>> --sort=-committerdate refs/heads
>> refs/heads/m24: Jon Smirl <jonsmirl@gmail.com> 1191362799 -0400
>> refs/heads/m25: Jon Smirl <jonsmirl@gmail.com> 1191472422 -0400
>> refs/heads/m26: Jon Smirl <jonsmirl@gmail.com> 1194382038 -0500
>> refs/heads/m28: Jon Smirl <jonsmirl@gmail.com> 1194385071 -0500
>> refs/heads/m29: Jon Smirl <jonsmirl@gmail.com> 1194585780 -0500
>
> It appears to be using the first head instead of the most recent date.
It appears to not _sort_ the output by committerdate, as it should with
'--sort=-committerdate'.
1442:[gitweb/web!git]$ git for-each-ref --format="%(refname):%09%(committer)" \
--sort=-committerdate refs/heads
refs/heads/gitweb/web: Jakub Narebski <jnareb@gmail.com> 1194616779 +0100
refs/heads/man: Junio C Hamano <junio@hera.kernel.org> 1194602628 +0000
refs/heads/html: Junio C Hamano <junio@hera.kernel.org> 1194602626 +0000
refs/heads/origin: Junio C Hamano <gitster@pobox.com> 1194602274 -0800
[...]
refs/heads/gitweb-snapshot+navbar: Sven Verdoolaege <skimo@kotnet.org> 1134765981 +0100
1443:[gitweb/web!git]$ git --version
git version 1.5.3.5
Note that git-for-each-ref with those options returns most recent head
first, sorting output by date of commit (date of adding to repository)
>>>
>>> return? Does adding --count select proper branch, with proper update
>>> date?
>>
>> Is it looking for master, and just picking the first branch instead?
Gitweb should not (and I think does not) have 'master' hardcoded
anywhere. It might use HEAD in some cases you don't want it to...
>>>
>>> Which gitweb version is this?
>>
>> <!-- git web interface version 1.5.3.5.605.g79fa-dirty, (C) 2005-2006,
>> Kay Sievers <kay.sievers@vrfy.org>, Christian Gierke -->
>> <!-- git core binaries version 1.5.3.5.605.g79fa-dirty -->
Older version of gitweb used HEAD branch for'last changed' info on
the projects list page. That is why I asked about gitweb version.
But this is not the case of your problem:
1. Your gitweb is new enough to use git-for-each-ref. It use
git for-each-ref --format="%(committer)" --sort=-committerdate
--count=1 refs/heads
2. Looking at 'heads' view (or 'heads' part of summary view) one can see
that m29 is current branch (HEAD), and it is most recent.
Strange...
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: [PATCH] Make builtin-tag.c use parse_options.
From: Junio C Hamano @ 2007-11-10 9:26 UTC (permalink / raw)
To: Kristian Høgsberg; +Cc: git, Carlos Rica
In-Reply-To: <7vabpmpr9y.fsf@gitster.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> While I freely admit that I do not particularly find the "One -m
> introduces one new line, concatenated to form the final
> paragraph" handling of multiple -m options done by git-commit
> nice nor useful, I suspect that it would make more sense to make
> git-tag and git-commit handle multiple -m option consistently,
> if you are going to change the existing semantics. Since some
> people really seem to like multiple -m handling of git-commit,
> the avenue of the least resistance for better consistency would
> be to accept and concatenate (with LF in between) multiple -m
> options.
>
> With multiple -F, I think erroring out would be the sensible
> thing to do, but some people might prefer concatenation. I do
> not care either way as long as commit and tag behave
> consistently.
Alas, this exposes a regression in kh/commit series.
t/t7501-commit.sh | 23 +++++++++++++++++++++++
1 files changed, 23 insertions(+), 0 deletions(-)
diff --git a/t/t7501-commit.sh b/t/t7501-commit.sh
index 1b444d4..bf5dd86 100644
--- a/t/t7501-commit.sh
+++ b/t/t7501-commit.sh
@@ -178,4 +178,27 @@ test_expect_success 'amend commit to fix author' '
diff expected current
'
+
+test_expect_success 'sign off' '
+
+ >positive &&
+ git add positive &&
+ git commit -s -m "thank you" &&
+ actual=$(git cat-file commit HEAD | sed -ne "s/Signed-off-by: //p") &&
+ expected=$(git var GIT_COMMITTER_IDENT | sed -e "s/>.*/>/") &&
+ test "z$actual" = "z$expected"
+
+'
+
+test_expect_success 'multiple -m' '
+
+ >negative &&
+ git add negative &&
+ git commit -m "one" -m "two" -m "three" &&
+ actual=$(git cat-file commit HEAD | sed -e "1,/^\$/d") &&
+ expected=$(echo one; echo; echo two; echo; echo three) &&
+ test "z$actual" = "z$expected"
+
+'
+
test_done
^ permalink raw reply related
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