* Re: git and time
From: Junio C Hamano @ 2006-09-28 17:28 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git, Matthew L Foster
In-Reply-To: <Pine.LNX.4.64.0609281003070.3952@g5.osdl.org>
Linus Torvalds <torvalds@osdl.org> writes:
> On Thu, 28 Sep 2006, Matthew L Foster wrote:
>>
>> I am not saying git should "police any one else's clocks", I am saying git should be designed or
>> configured in such a way, using local time, that it obviates the current reliance on everyone
>> else's clock being set correctly.
>
> Matt!
>
> THERE IS NO SUCH RELIANCE! NONE.
>
> Trust me. When we say that git ignores time, WE MEAN IT. Git does not rely
> on time, git does not use time, git does not CARE!
>
> Please stop looking at gitweb _immediately_. If you think time has some
> meaning for git, stop. It doesn't. We've told you over and over and over
> again that there is absolutely _zero_ reliance on everybody else's clock
> being set correctly. The damn clock could go _backwards_, or make huge
> jumping purple leaps of imagination, and git wouldn't care.
I think Matthew means (by "relying") that everybody's clock must
be set correctly in order for us to show the commits in gitweb
or rev-list output so that their timestamps are monotonically
decreasing (because we list things from newer to older). I
sympathise.
We order things by causality (i.e. ancestry order), but that
unfortunately (!!) happens to match timestamp order for simple
history made on a single machine. This can easily lead to such
a misunderstanding that we are somehow trying to show things in
linear time order, hence we subscribe to the notion of global,
uniform and monotonic time.
Of course, we don't.
^ permalink raw reply
* Re: git and time
From: Linus Torvalds @ 2006-09-28 17:11 UTC (permalink / raw)
To: Matthew L Foster; +Cc: Rogan Dawes, git
In-Reply-To: <20060928165509.77413.qmail@web51001.mail.yahoo.com>
On Thu, 28 Sep 2006, Matthew L Foster wrote:
>
> I am not saying git should "police any one else's clocks", I am saying git should be designed or
> configured in such a way, using local time, that it obviates the current reliance on everyone
> else's clock being set correctly.
Matt!
THERE IS NO SUCH RELIANCE! NONE.
Trust me. When we say that git ignores time, WE MEAN IT. Git does not rely
on time, git does not use time, git does not CARE!
Please stop looking at gitweb _immediately_. If you think time has some
meaning for git, stop. It doesn't. We've told you over and over and over
again that there is absolutely _zero_ reliance on everybody else's clock
being set correctly. The damn clock could go _backwards_, or make huge
jumping purple leaps of imagination, and git wouldn't care.
The time that git records is purely a random number. It's a random number
that _humans_ can choose to care about or not, and it's a random number
that git itself uses only in the sense of "ok, I've got two equal choices,
let's toss a coin to select which one I'll look at next", BUT IT IS A
RANDOM NUMBER.
Please.
Download a local git archive, and run "gitk" on that archive. Then _hide_
the time column (just so that it doesn't confuse you), and then _look_ at
the leftmost column which shows the CAUSALITY DAG!
THAT is what git actually cares about. It's the _only_ thing that git
cares about. Git cares about _causality_, not time. Nothing else matters.
Really. Truly, pretty please, I promise you, cross my heart and hope to
die! Scouts honor. Lock it up and throw away the key. It's TRUE.
Linus
^ permalink raw reply
* Re: [PATCH] --stat: ensure at least one '-' for deletions, and one '+' for additions
From: Junio C Hamano @ 2006-09-28 17:10 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <Pine.LNX.4.63.0609281735040.14200@wbgn013.biozentrum.uni-wuerzburg.de>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> The number of '-' and '+' is still linear. The idea is that
> scaled-length := floor(a * length + b) with the following constraints: if
> length == 1, scaled-length == 1, and the combined length of plusses
> and minusses should not be larger than the width by a small margin. Thus,
>
> a + b == 1
>
> and
> a * max_plusses + b + a * max_minusses + b = width + 1
>
> The solution is
>
> a * x + b = ((width - 1) * (x - 1) + max_change - 1)
> / (max_change - 1)
>
> Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Nice looking math in the log message aside,...
> diff --git a/diff.c b/diff.c
> index 98c29bf..53c30bd 100644
> --- a/diff.c
> +++ b/diff.c
> @@ -640,9 +640,12 @@ const char mime_boundary_leader[] = "---
> static int scale_linear(int it, int width, int max_change)
> {
> /*
> - * round(width * it / max_change);
> + * make sure that at least one '-' is printed if there were deletions,
> + * and likewise for '+'.
> */
> - return (it * width * 2 + max_change) / (max_change * 2);
> + if (max_change < 2)
> + return it;
> + return ((it - 1) * (width - 1) + max_change - 1) / (max_change - 1);
> }
This does not feel right. Maybe the first conditional is to see
if it is less than 2, not max_change?
> static void show_name(const char *prefix, const char *name, int len,
> @@ -774,9 +777,9 @@ static void show_stats(struct diffstat_t
> dels += del;
>
> if (width <= max_change) {
> - total = scale_linear(total, width, max_change);
> add = scale_linear(add, width, max_change);
> - del = total - add;
> + del = scale_linear(del, width, max_change);
> + total = add + del;
> }
> show_name(prefix, name, len, reset, set);
> printf("%5d ", added + deleted);
The original was written a bit differently because it used
round() not floor(), and avoided the case of both ends end up
rounding up.
This version of scale_linear() rounds down so you can get away
with this without busting the total width.
But think about the case where width=7, max_change=10, 5
lines are added and 5 lines are removed.
The original makes total 7 to use full width, and gives 4 pluses
and 3 minuses, which is not quite right when your eyes notice
that they are not of equal length, but it makes it to use the
full width. I think this version gives 3 pluses and minuses,
and does not use the full width. However, if you have a file
that adds 10 without removing, it will be drawn as 7 pluses. In
other words, the line drawn for a new file that is 10 lines
long, and the line for a modified file that added 5 lines and
removed 5 lines, are drawn differently.
I _think_ the graph length is reasonably long enough that the
actual differences coming from rounding (3 vs 4 in the above
description for the current implementation) is less annoying
than the total number of pluses and minuses not lining up for
two files that had both 10 changes, one (add=10,del=0) and the
other (add=5,del=5). Illustration.
Compute total and add, make del=total-add:
foo | 10 ++++---
bar | 10 +++++++
Compute add and del independently:
foo | 10 +++---
bar | 10 +++++++
So I'd suggest either force the width to even number (if odd
drop one), of keep the current del=total-add.
How about doing something like this instead?
- first scale the total but make sure there is one column for
each of non-zero add and delete;
- scale add but make sure it is at least one if non-zero;
- del is the remainder of total after add is taken, but if
there are too many adds than dels, that can become zero. In
that case adjust by giving one column from add to del.
diff --git a/diff.c b/diff.c
index 3fd7a52..9b9a6d8 100644
--- a/diff.c
+++ b/diff.c
@@ -684,9 +684,15 @@ static void show_stats(struct diffstat_t
dels += del;
if (width <= max_change) {
- total = scale_linear(total, width, max_change);
- add = scale_linear(add, width, max_change);
+ int fl = !!add + !!del;
+ total = scale_linear(total, width-fl, max_change) + fl;
+ if (add)
+ add = scale_linear(add, width-fl, max_change) + 1;
del = total - add;
+ if (!del && deleted) {
+ add--;
+ del++;
+ }
}
show_name(prefix, name, len, reset, set);
printf("%5d ", added + deleted);
^ permalink raw reply related
* Re: git and time
From: Matthew L Foster @ 2006-09-28 16:55 UTC (permalink / raw)
To: Rogan Dawes; +Cc: git
In-Reply-To: <451BEA60.9050306@dawes.za.net>
--- Rogan Dawes <discard@dawes.za.net> wrote:
> I just don't think that any of the kernel developers feel the need to
> police any one else's clocks . . . they're more interested in the
> contents of the patch.
I am not saying git should "police any one else's clocks", I am saying git should be designed or
configured in such a way, using local time, that it obviates the current reliance on everyone
else's clock being set correctly.
-Matt
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
^ permalink raw reply
* Re: git and time
From: Linus Torvalds @ 2006-09-28 16:53 UTC (permalink / raw)
To: apodtele; +Cc: git
In-Reply-To: <d620685f0609271749p30da81d6p25cb759bf793d327@mail.gmail.com>
On Wed, 27 Sep 2006, apodtele wrote:
>
> Shall we summarize? Time is a very important concept in physics.
Actually, even in physics (or very _much_ in physics), time doesn't
follow the nice procession that Matthew is kind of asking for.
In physics, particles can go backwards in time or forwards in time (the
_likelihood_ that a photon moves at exactly the speed of light is higher,
but on a quantum scale, strange things happen).
And everybody should by now know what relativity says: time does not
impose an "ordering" of events outside of the so-called "cone of light".
There is only an ordering imposed by _causality_, not by time.
That, btw, is very similar to git. The only _true_ ordering in git is
causality. Time itself tends to have certain properties that makes it
_look_ like it is about causality, but in real life there is just a strong
correlation.
Nature is sometimes stranger than our everyday experiences would have us
believe. And "time" is a hell of a lot more complicated than just a global
one-dimensional entity, steadily ticking away.
Linus
^ permalink raw reply
* Re: git and time
From: apodtele @ 2006-09-28 16:50 UTC (permalink / raw)
To: git
Matthew wrote:
> No. I merely think git should try harder to ensure that commit order is consistent
> with time order
Matthew doesn't seem to grasp the idea that commit order is
conceptually MORE fundamental than time, NOT LESS. Hence, the time
shall not dictate the order for git. If anything, git may try harder
to ensure that time is consistent with order, not vise versa. :)
^ permalink raw reply
* Re: [PATCH] Contributed bash completion support for core Git tools.
From: Shawn Pearce @ 2006-09-28 16:28 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v64f8vueh.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> wrote:
> Shawn Pearce <spearce@spearce.org> writes:
>
> > I'm not sure there are too many other things to hook into bash in
> > addition to completion so contrib/completion/git-completion.bash may
> > be the better location, assuming it doesn't graduate out of contrib/.
>
> Just so that we do not forget, I applied this (and your
> follow-up patch).
Thanks. I was starting to wonder about that patch set and was
probably going to send a reminder next week. Now I don't have to.
:-)
--
Shawn.
^ permalink raw reply
* Re: [PATCH] format-patch: use cwd as default output directory
From: Junio C Hamano @ 2006-09-28 16:16 UTC (permalink / raw)
To: Nguyen Thai Ngoc Duy; +Cc: git
In-Reply-To: <fcaeb9bf0609280325l1e88e9u75e8eac122e05e60@mail.gmail.com>
"Nguyen Thai Ngoc Duy" <pclouds@gmail.com> writes:
> This patch works great. I assume you forgot it?
Thanks for reminding.
^ permalink raw reply
* Re: [PATCH] Contributed bash completion support for core Git tools.
From: Junio C Hamano @ 2006-09-28 16:16 UTC (permalink / raw)
To: Shawn Pearce; +Cc: git
In-Reply-To: <20060918011855.GA19955@spearce.org>
Shawn Pearce <spearce@spearce.org> writes:
> I'm not sure there are too many other things to hook into bash in
> addition to completion so contrib/completion/git-completion.bash may
> be the better location, assuming it doesn't graduate out of contrib/.
Just so that we do not forget, I applied this (and your
follow-up patch).
^ permalink raw reply
* Re: daemon.c fails to build on Darwin
From: Junio C Hamano @ 2006-09-28 16:15 UTC (permalink / raw)
To: Randal L. Schwartz; +Cc: git
In-Reply-To: <86ejtw3sbv.fsf@blue.stonehenge.com>
merlyn@stonehenge.com (Randal L. Schwartz) writes:
> If this is obvious, can someone fix it? If not, I'll try to sort it out later
> tonight.
>
> gcc -o daemon.o -c -g -O2 -Wall -I/sw/include -I/opt/local/include -DSHA1_HEADER='<openssl/sha.h>' -DNO_STRLCPY daemon.c
> daemon.c: In function 'fill_in_extra_table_entries':
> daemon.c:460: error: 'HOST_NAME_MAX' undeclared (first use in this function)
> daemon.c:460: error: (Each undeclared identifier is reported only once
> daemon.c:460: error: for each function it appears in.)
> daemon.c:460: warning: unused variable 'addrbuf'
> make: *** [daemon.o] Error 1
>
> This is with 2d5b459107cf07bbb307cfb196c2007c497a6dd2.
Sorry about that. Johannes sent a fix which I'll apply.
From: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Subject: [PATCH/RFC] daemon: default to 256 for HOST_NAME_MAX if it is not defined
Date: Thu, 28 Sep 2006 12:00:35 +0200 (CEST)
Message-ID: <Pine.LNX.4.63.0609281200200.14200@wbgn013.biozentrum.uni-wuerzburg.de>
Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
---
... or should we make it wider available, by putting it into
cache.h?
daemon.c | 4 ++++
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/daemon.c b/daemon.c
index 5335d21..fc3951c 100644
--- a/daemon.c
+++ b/daemon.c
@@ -15,6 +15,10 @@ #include "cache.h"
#include "exec_cmd.h"
#include "interpolate.h"
+#ifndef HOST_NAME_MAX
+#define HOST_NAME_MAX 256
+#endif
+
static int log_syslog;
static int verbose;
static int reuseaddr;
--
1.4.2.1.g430572-dirty
^ permalink raw reply related
* Re: [PATCH] svnimport add support for parsing From lines for author
From: Junio C Hamano @ 2006-09-28 16:10 UTC (permalink / raw)
To: Andy Whitcroft; +Cc: git
In-Reply-To: <451BAACE.70005@shadowen.org>
Andy Whitcroft <apw@shadowen.org> writes:
> This one didn't make it onto the git.git whats next page. Not sure of
> protocol in these matters, so I'll just ask. Has this been rejected or
> forgotten?
Asking is always good. It was forgotten.
^ permalink raw reply
* Re: git and time
From: Junio C Hamano @ 2006-09-28 16:05 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0609281029300.9349@xanadu.home>
Nicolas Pitre <nico@cam.org> writes:
>> Nicolas Pitre <nico@cam.org> writes:
>>
>> > SYNOPSIS
>> >
>> > git-local-arrival <committish>
>> >
>> > DESCRIPTION
>> >
>> > The command displays the time when given commit appeared in the
>> > local repository.
>>
>> This should be certainly doable, but local-arrival may not be
>> interesting if the repository has more than one branches. Maybe
>>
>> git-local-arrival <committish> [<branch>]
>>
>> which defaults to the current branch?
>
> Indeed. I didn't mention it initially because it is really easy to do
> once you have it working for the current branch. The technical
> challenge is about making it efficient to find out which reflog entry
> with a path to given commit is the oldest.
Perhaps bisect it like this. This assumes you never rewind the
branch in question and the tip already contains the commit in
question.
-- >8 --
#!/bin/sh
. git-sh-setup
commit=`git rev-parse "$1"` &&
branch="${2-`git symbolic-ref HEAD`} || exit
contains () {
contains=`git merge-base --all $1 $commit`
case "$LF$contains$LF" in
*"$LF$contains$LF"*)
: ;;
*)
false ;;
esac
}
LF='
'
script='{
s/ .*//
p
}' ;# strip things after TAB if a TAB exists
reflog="$GIT_DIR/logs/refs/heads/$branch";
lo=1;
hi=`wc -l <$reflog`
ld=$hi
while expr "$lo" \< "$hi" >/dev/null
do
mi=`expr \( $hi \+ $lo \) / 2`
line=`sed -ne "$mi$script" "$reflog"`
to=`expr "$line" : '[^ ]* \([^ ]*\) '`
if contains $to
then
ld=$hi
hi=$mi
else
lo=`expr "$mi" + 1`
fi
done
case "$ld" in
'')
echo >&2 Oops
exit 1;;
?*)
line=`sed -ne "$ld$script" "$reflog"`
time=`expr "$line" : '.*> \([0-9]*\) '`
zone=`expr "$line" : '.*> [0-9]* \(.[0-9][0-9][0-9][0-9]\)$'`
echo "$time $zone"
esac
^ permalink raw reply
* Re: daemon.c fails to build on Darwin
From: Shawn Pearce @ 2006-09-28 16:06 UTC (permalink / raw)
To: Randal L. Schwartz; +Cc: git
In-Reply-To: <86ejtw3sbv.fsf@blue.stonehenge.com>
"Randal L. Schwartz" <merlyn@stonehenge.com> wrote:
>
> If this is obvious, can someone fix it? If not, I'll try to sort it out later
> tonight.
>
> gcc -o daemon.o -c -g -O2 -Wall -I/sw/include -I/opt/local/include -DSHA1_HEADER='<openssl/sha.h>' -DNO_STRLCPY daemon.c
> daemon.c: In function 'fill_in_extra_table_entries':
> daemon.c:460: error: 'HOST_NAME_MAX' undeclared (first use in this function)
> daemon.c:460: error: (Each undeclared identifier is reported only once
> daemon.c:460: error: for each function it appears in.)
> daemon.c:460: warning: unused variable 'addrbuf'
> make: *** [daemon.o] Error 1
>
> This is with 2d5b459107cf07bbb307cfb196c2007c497a6dd2.
According to pickaxe it was dd4676299dde0a4c6f8a471e6353170f86a78c8a.
Looks like HOST_NAME_MAX isn't defined on Darwin. Looking at how
daemon.c is using it this just needs to be defined to a suitable
length if its not already defined. Sort of like PATH_MAX on some
other systems...
--
Shawn.
^ permalink raw reply
* Re: daemon.c fails to build on Darwin
From: Alex Riesen @ 2006-09-28 16:01 UTC (permalink / raw)
To: Randal L. Schwartz; +Cc: git, Junio C Hamano
In-Reply-To: <86ejtw3sbv.fsf@blue.stonehenge.com>
[-- Attachment #1: Type: text/plain, Size: 252 bytes --]
On 28 Sep 2006 08:48:36 -0700, Randal L. Schwartz <merlyn@stonehenge.com> wrote:
>
> If this is obvious, can someone fix it? If not, I'll try to sort it out later
> tonight.
>
I used the patch attached.
BTW, could we please _use_ the const keyword?
[-- Attachment #2: fix-daemon-no-ipv6.patch --]
[-- Type: text/x-diff, Size: 1567 bytes --]
diff --git a/daemon.c b/daemon.c
index 5335d21..8b54c63 100644
--- a/daemon.c
+++ b/daemon.c
@@ -830,7 +830,7 @@ #endif
#else /* NO_IPV6 */
-static int socksetup(char *lisen_addr, int listen_port, int **socklist_p)
+static int socksetup(char *listen_addr, int listen_port, int **socklist_p)
{
struct sockaddr_in sin;
int sockfd;
diff --git a/git-compat-util.h b/git-compat-util.h
index 7ed18e1..a5429d1 100755
--- a/git-compat-util.h
+++ b/git-compat-util.h
@@ -33,6 +33,10 @@ #ifndef PATH_MAX
#define PATH_MAX 4096
#endif
+#ifndef HOST_NAME_MAX
+#define HOST_NAME_MAX 256
+#endif
+
#ifdef __GNUC__
#define NORETURN __attribute__((__noreturn__))
#else
diff --git a/interpolate.c b/interpolate.c
index 62701d8..5d9d188 100644
--- a/interpolate.c
+++ b/interpolate.c
@@ -8,10 +8,10 @@ #include "git-compat-util.h"
#include "interpolate.h"
-void interp_set_entry(struct interp *table, int slot, char *value)
+void interp_set_entry(struct interp *table, int slot, const char *value)
{
char *oldval = table[slot].value;
- char *newval = value;
+ char *newval = NULL;
if (oldval)
free(oldval);
diff --git a/interpolate.h b/interpolate.h
index a55fb8e..190a180 100644
--- a/interpolate.h
+++ b/interpolate.h
@@ -16,7 +16,7 @@ struct interp {
char *value;
};
-extern void interp_set_entry(struct interp *table, int slot, char *value);
+extern void interp_set_entry(struct interp *table, int slot, const char *value);
extern void interp_clear_table(struct interp *table, int ninterps);
extern int interpolate(char *result, int reslen,
^ permalink raw reply related
* daemon.c fails to build on Darwin
From: Randal L. Schwartz @ 2006-09-28 15:48 UTC (permalink / raw)
To: git
If this is obvious, can someone fix it? If not, I'll try to sort it out later
tonight.
gcc -o daemon.o -c -g -O2 -Wall -I/sw/include -I/opt/local/include -DSHA1_HEADER='<openssl/sha.h>' -DNO_STRLCPY daemon.c
daemon.c: In function 'fill_in_extra_table_entries':
daemon.c:460: error: 'HOST_NAME_MAX' undeclared (first use in this function)
daemon.c:460: error: (Each undeclared identifier is reported only once
daemon.c:460: error: for each function it appears in.)
daemon.c:460: warning: unused variable 'addrbuf'
make: *** [daemon.o] Error 1
This is with 2d5b459107cf07bbb307cfb196c2007c497a6dd2.
--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<merlyn@stonehenge.com> <URL:http://www.stonehenge.com/merlyn/>
Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.
See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!
^ permalink raw reply
* Re: Notes on Using Git with Subprojects
From: Johannes Schindelin @ 2006-09-28 15:39 UTC (permalink / raw)
To: Shawn Pearce
Cc: A Large Angry SCM, Jeff King, Martin Waitz, Daniel Barkalow, git
In-Reply-To: <20060928035238.GC22897@spearce.org>
Hi,
On Wed, 27 Sep 2006, Shawn Pearce wrote:
> A Large Angry SCM <gitzilla@gmail.com> wrote:
> > Jeff King wrote:
> > [...]
> > >One thing that I believe some people have requested for subprojects is
> > >to avoid downloading files/history for subprojects you're not interested
> > >in. I think this could be faciliated in this scheme by only cloning the
> > >heads of the subprojects you're interested in (there would need to be
> > >special machinery to handle this at the root level if we want to allow
> > >making root commits without necessarily having all of the subprojects).
> >
> > In what I'm suggesting, commits are local to a project's working
> > directory repository and are pushed somewhere else to be recorded long
> > term. Since projects are stand alone, possibly with dependencies,
> > working on a (sub)project without having other associated (sub)projects
> > is accomplished by checking it out.
> >
> > >A first step to this would be an argument to git-clone to allow cloning
> > >only a subset of refs.
> >
> > Something like this?
> >
> > git-init-db
> > git-fetch <repository> <refspecs>
>
> More like:
>
> git-init-db
> git-fetch --keep <repository> <refspecs>
>
> but yes. :-)
You are missing the remotes/ information:
git-repo-config remote.origin.url <repository>
for spec in <refspecs>; do
git-repo-config remote.origin.fetch $spec ^$
done
Ciao,
Dscho
^ permalink raw reply
* [PATCH] --stat: ensure at least one '-' for deletions, and one '+' for additions
From: Johannes Schindelin @ 2006-09-28 15:37 UTC (permalink / raw)
To: git, junkio
The number of '-' and '+' is still linear. The idea is that
scaled-length := floor(a * length + b) with the following constraints: if
length == 1, scaled-length == 1, and the combined length of plusses
and minusses should not be larger than the width by a small margin. Thus,
a + b == 1
and
a * max_plusses + b + a * max_minusses + b = width + 1
The solution is
a * x + b = ((width - 1) * (x - 1) + max_change - 1)
/ (max_change - 1)
Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
---
While testing this, I hit a bug which was hard to squash: commit
v1.3.3~14 _always_ showed no minusses and plusses in the diffstat.
Until I realized that the offending diffstat was in the commit
_message_ :-)
diff.c | 11 +++++++----
1 files changed, 7 insertions(+), 4 deletions(-)
diff --git a/diff.c b/diff.c
index 98c29bf..53c30bd 100644
--- a/diff.c
+++ b/diff.c
@@ -640,9 +640,12 @@ const char mime_boundary_leader[] = "---
static int scale_linear(int it, int width, int max_change)
{
/*
- * round(width * it / max_change);
+ * make sure that at least one '-' is printed if there were deletions,
+ * and likewise for '+'.
*/
- return (it * width * 2 + max_change) / (max_change * 2);
+ if (max_change < 2)
+ return it;
+ return ((it - 1) * (width - 1) + max_change - 1) / (max_change - 1);
}
static void show_name(const char *prefix, const char *name, int len,
@@ -774,9 +777,9 @@ static void show_stats(struct diffstat_t
dels += del;
if (width <= max_change) {
- total = scale_linear(total, width, max_change);
add = scale_linear(add, width, max_change);
- del = total - add;
+ del = scale_linear(del, width, max_change);
+ total = add + del;
}
show_name(prefix, name, len, reset, set);
printf("%5d ", added + deleted);
--
1.4.2.1.g89d5d-dirty
^ permalink raw reply related
* Re: git and time
From: Rogan Dawes @ 2006-09-28 15:29 UTC (permalink / raw)
To: Matthew L Foster; +Cc: git
In-Reply-To: <20060928145027.26643.qmail@web51011.mail.yahoo.com>
Matthew L Foster wrote:
> --- Theodore Tso <tytso@mit.edu> wrote:
>
>> In git, we believe that all repositories are equal, and that any sense
>> that a particular repository is the "master" or the "mainline" is
>> strictly speaking, a matter of convention. What Matthew I think is
>> asking for is direct support in git for that notion.
>
> No. I merely think git should try harder to ensure that commit order is consistent with time
> order, it really should (somehow) be impossible for git and gitweb.cgi to have commit dates ~2
> days in the future. I think replication is a separate issue. In a distributed system the only
> "time" that makes any sense or is the most relevant in many situations and most importantly is the
> only thing that can be semi-trusted is local time. "Creation date" is basically just random text
> someone entered, there is no guarantee and you are tempting inconsistent time order. And git
> shouldn't be so fragile as to need each and every git server to have time set semi-correctly, but
> I guess it's a bigger deal to non-developers as we actually use time and also believe even web
> interfaces should have consistency and integrity.
>
> -Matt
>
See, the confusion here seems to be that you think that not caring about
the time attached to a commit for anything more than a heuristic makes
git fragile.
I think that the rest of the git developers prefer to see this as a
feature that makes git more robust in the face of something that they
might not have any control over (or desire to control).
That said, if *you* are managing a repository, it shouldn't be difficult
to enforce the kind of rule that you are asking for. Simply implement a
pre-commit hook that checks all commits that will be added to *your*
repo to make sure that time is monotonically increasing from the last
commit, and that it does not pass "now".
So if you receive a commit from a developer that violates this rule, you
can send the commit back to them with a request to fix their system
time, and recreate the patch/series.
I just don't think that any of the kernel developers feel the need to
police any one else's clocks . . . they're more interested in the
contents of the patch.
Regards,
Rogan
^ permalink raw reply
* Re: Notes on Using Git with Subprojects
From: Michael S. Tsirkin @ 2006-09-28 15:02 UTC (permalink / raw)
To: Junio C Hamano
Cc: skimo, Martin Waitz, A Large Angry SCM, Shawn Pearce,
Daniel Barkalow, git, Josh Triplett, Jamey Sharp
In-Reply-To: <7vhcyt81gn.fsf@assigned-by-dhcp.cox.net>
Quoting r. Junio C Hamano <junkio@cox.net>:
> Avoiding checking out parts of the project tree that you do not
> care about while you work on such a single large project is
> another interesting and useful area to think about, but I would
> say at that point it is not about subproject at all -- it is
> about working in a sparsely populated working tree of a single
> project.
I agree completely - at least as far as I'm concerned, working in
a sparsely populated working tree is what it's all about.
For example, sometimes I am just editing documentation and
it would be nice
It's easy to check out just a subdirectory the first time:
>git checkout master `git-ls-tree -r --name-only master subdirectory`
>echo ref: refs/heads/master > .git/HEAD
but when you try a pull/rebase git will check out all of the tree.
Is there some way to avoid this?
--
MST
^ permalink raw reply
* Re: git and time
From: Matthew L Foster @ 2006-09-28 14:50 UTC (permalink / raw)
To: Theodore Tso, Sean
Cc: Matthew L Foster, Junio C Hamano, Linus Torvalds,
Andreas Ericsson, git, Jeff King, Jakub Narebski
In-Reply-To: <20060928131710.GE7469@thunk.org>
--- Theodore Tso <tytso@mit.edu> wrote:
> In git, we believe that all repositories are equal, and that any sense
> that a particular repository is the "master" or the "mainline" is
> strictly speaking, a matter of convention. What Matthew I think is
> asking for is direct support in git for that notion.
No. I merely think git should try harder to ensure that commit order is consistent with time
order, it really should (somehow) be impossible for git and gitweb.cgi to have commit dates ~2
days in the future. I think replication is a separate issue. In a distributed system the only
"time" that makes any sense or is the most relevant in many situations and most importantly is the
only thing that can be semi-trusted is local time. "Creation date" is basically just random text
someone entered, there is no guarantee and you are tempting inconsistent time order. And git
shouldn't be so fragile as to need each and every git server to have time set semi-correctly, but
I guess it's a bigger deal to non-developers as we actually use time and also believe even web
interfaces should have consistency and integrity.
-Matt
-Matt
-Matt
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
^ permalink raw reply
* Re: git and time
From: Nicolas Pitre @ 2006-09-28 14:34 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vfyec63jx.fsf@assigned-by-dhcp.cox.net>
On Wed, 27 Sep 2006, Junio C Hamano wrote:
> Nicolas Pitre <nico@cam.org> writes:
>
> > SYNOPSIS
> >
> > git-local-arrival <committish>
> >
> > DESCRIPTION
> >
> > The command displays the time when given commit appeared in the
> > local repository.
>
> This should be certainly doable, but local-arrival may not be
> interesting if the repository has more than one branches. Maybe
>
> git-local-arrival <committish> [<branch>]
>
> which defaults to the current branch?
Indeed. I didn't mention it initially because it is really easy to do
once you have it working for the current branch. The technical
challenge is about making it efficient to find out which reflog entry
with a path to given commit is the oldest.
Nicolas
^ permalink raw reply
* Re: What's in git.git
From: Johannes Schindelin @ 2006-09-28 13:27 UTC (permalink / raw)
To: Petr Baudis; +Cc: Junio C Hamano, git
In-Reply-To: <20060928093623.GJ20017@pasky.or.cz>
Hi,
On Thu, 28 Sep 2006, Petr Baudis wrote:
> Dear diary, on Thu, Sep 28, 2006 at 09:39:11AM CEST, I got a letter
> where Junio C Hamano <junkio@cox.net> said that...
>
> > + Git.pm lost Git.xs; its remnant still remains, though.
> > Notably, we still compile x86_64 with -fPIC, and the top
> > level Makefile has {BASIC,ALL}_{CFLAGS,LDFLAGS} distinction
> > and INSTALL talks about perl/blib/arch/auto. I am torn
> > between removing these and keeping them; on one hand, they
> > are not needed and makes new developers wonder what the
> > distinction between BASIC and ALL are. On the other hand,
> > we may eventually would want to reintroduce Git.xs in the
> > future and keeping them might help us. But on the third
> > hand ;-), we can always resurrect it from the repository and
> > that is the point of using git to keep track of the project,
> > so removing them might not be such a big deal. I'd like to
> > decide between this two and push it out to 'master' before
> > doing the -rc1.
>
> FWIW, I'd say kill it all (perhaps except BASIC_*, I don't know about
> that one) - we indeed can easily resurrect this, and that was the
> presumption with which I've killed the rest of Git.xs. There's no point
> in keeping legacy cruft around when we can take it back from the
> history.
>
> Perhaps we could throw a note to perl/Makefile saying
>
> # If you are thinking about adding Git.xs support, please note
> # that we have already been there before - see the #next branch
> # history for more-or-less working one already added, and also
> # the reason why it was removed for now.
>
> so that noone wastes their time.
Having ranted so often about Git.xs, I feel like I have to apologize. It
would be a better idea (IMHO) to put an effort into having the _option_ to
use Git.xs, since it is so much more efficient. If it is a strict opt-in,
I think it could remain in "next", and it would be much more likely that
people took up the ball and worked towards libifying git.
Ciao,
Dscho
^ permalink raw reply
* Re: git and time
From: Theodore Tso @ 2006-09-28 13:17 UTC (permalink / raw)
To: Sean
Cc: Matthew L Foster, Junio C Hamano, Linus Torvalds,
Andreas Ericsson, git, Jeff King, Jakub Narebski
In-Reply-To: <20060927220404.8e216945.seanlkml@sympatico.ca>
On Wed, Sep 27, 2006 at 10:04:04PM -0400, Sean wrote:
> > I actually understand that and agree. All I've been saying is it
> > (git or gitweb.cgi) should prefer the local timestamp rather than
> > any "remote" timestamps for no other reason than to minimize the
> > possibility of timestamps being grossly inaccurate.
>
> But any local time stamp would be a _lie_. The time stamp in the
> commit records when it was actually created. And as Junio has
> pointed out, hundreds of commits will typically arrive in a repo at
> the exact same time. Your suggestion would have them all showing
> the exact same time. That's not helpful, and it loses important
> factual information.
There are two issues here. Could a git tree record the local time
that each commit entered the repository? Sure. Someone who wanted to
hack up git so that it created a local db file associating the SHA
hash name of the commit with when it arrived in its local repository.
It would not be part of the "true" git repository information, and it
could be something which is optional in the sense that if the
information is lost, it's not the end of the world, vis-a-vis correct
git functioning.
The second question, though, is would it be *useful*? Presumably this
would be an option, so the user could request to see the time when a
commit hit a particular repository, as well as when the commit was
first created --- or perhaps both.
The problem though is that this could easily get confusing, since it
adds a distinction (which repository am I talking to?) which normally
doesn't exist in git. And it forces us to make explicit things that
normally are kept hidden --- such as whether or not Linus does his
work directly on the git tree which is exposed by master.kernel.org,
or whether he does the work on his own local tree, and then pushes the
changes to master.kernel.org.
In git, we believe that all repositories are equal, and that any sense
that a particular repository is the "master" or the "mainline" is
strictly speaking, a matter of convention. What Matthew I think is
asking for is direct support in git for that notion.
So it *could* be done, but whether or not it is a good idea or worth
the complexity is a different question. One could imagine a
completely different protocol, which exported the contents of the
hypothetical db database described above. So for maintainers that
were *important*, and who were willing to make this information
available, given a particular SHA hash of a commit, one could ask the
question, "when did this commit first eneter your repository"?
Matthew seems hung up on on desperately wanting to know this
information as it relates to a particular repository --- Linus's.
This is in fact different from when the commit hit the repository
which is master.kernel.org which is why the local commit times on
master.kernel.org wouldn't be useful.
HOWEVER, if it was judged important enough, and worth the complexity
that it would add to git, the ability to track when a commit entered a
particular repository and the ability to export it via some kind of
web interface certainly be implemented. Linus would then have to
decide whether this was information he felt like making available to
inquisitive seekers wanting to know this sort of info.
- Ted
^ permalink raw reply
* Re: [PATCH] svnimport add support for parsing From lines for author
From: Andy Whitcroft @ 2006-09-28 10:58 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vfyedj2j2.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
> Andy Whitcroft <apw@shadowen.org> writes:
>
>>>> Now that we have support for parsing Signed-off-by: for author
>>>> information it makes sense to handle From: as well.
>>> I take that you are referring to Sasha's change in ae35b304; I
>>> asked for actual svn users for ACK/NACK but I did not hear any.
>>> Can I understand that you use svnimport for real projects and
>>> are happy with Sasha's change? --- that would be an ack that
>>> would help me sleep better ;-).
>> Heh. Yeah I am tracking a small SVN repository which is using the
>> kernel DCO. we have From:/S-o-b: much as akpm uses in -mm. This was
>> the result of seeing that change and wanting to see if it would pick up
>> our sign-offs. It only seemed deficient in From: handling :). It seems
>> to work well in practice for me.
>
> Thanks.
>
>>> I also wonder instead of piling up custom flags if it is better
>>> to let match-and-extract pattern be specified from the command
>>> line.
>> I did look at reusing the -S flag, such that -S would be S-o-b: handling
>> and -SS would be S-o-b: and From:, but this script is currently using
>> the old getopt implementation which doesn't record repeats.
>>
>> So you're proposing something more like:
>>
>> git svn-import -S "Signed-off-by:" -S "From:" ...
>>
>> Again, we'll have to update the options handling to get that kind of
>> behaviour. How would you feel about -SS in this context.
>
> It was more of an idle speculation than a serious proposal. I
> do not think there are too many different ways to record the
> authorship information, so having just two hardwired patterns -F
> and -S would be sufficient. If there were, then string of -S
> options that specify the header-looking strings or match
> patterns would have made more sense.
This one didn't make it onto the git.git whats next page. Not sure of
protocol in these matters, so I'll just ask. Has this been rejected or
forgotten?
:)
-apw
^ permalink raw reply
* Re: [PATCH] format-patch: use cwd as default output directory
From: Nguyen Thai Ngoc Duy @ 2006-09-28 10:25 UTC (permalink / raw)
To: git, Junio C Hamano
In-Reply-To: <20060922111201.GA10124@moooo.ath.cx>
This patch works great. I assume you forgot it?
On 9/22/06, Matthias Lederhofer <matled@gmx.net> wrote:
> ---
> Nguyen Thai Ngoc Duy <pclouds@gmail.com> wrote:
> > git format-patch in subdir generates files in topdir instead of
> > current dir as documented in its man page
> Here is a patch for this.
> ---
> builtin-log.c | 2 ++
> 1 files changed, 2 insertions(+), 0 deletions(-)
>
> diff --git a/builtin-log.c b/builtin-log.c
> index fbc58bb..130b53a 100644
> --- a/builtin-log.c
> +++ b/builtin-log.c
> @@ -270,6 +270,8 @@ int cmd_format_patch(int argc, const cha
>
> rev.extra_headers = extra_headers;
>
> + output_directory = prefix;
> +
> /*
> * Parse the arguments before setup_revisions(), or something
> * like "git fmt-patch -o a123 HEAD^.." may fail; a123 is
> --
> 1.4.2.1.ge767
>
>
--
Duy
^ 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