* Re: git and time
From: Robin Rosenberg @ 2006-09-28 20:36 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Matthew L Foster, Rogan Dawes, git
In-Reply-To: <Pine.LNX.4.64.0609281003070.3952@g5.osdl.org>
torsdag 28 september 2006 19:11 skrev Linus Torvalds:
> 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.
I'd think of it as comment, about as (un)reliable as the author field or the
descriptive free-form comment people enter when they commit. It's not even
necessarily the local system time if GIT_AUTHOR_DATE has been set.
-- robin
^ permalink raw reply
* Re: Notes on Using Git with Subprojects
From: A Large Angry SCM @ 2006-09-28 20:30 UTC (permalink / raw)
To: Martin Waitz; +Cc: Shawn Pearce, Daniel Barkalow, git
In-Reply-To: <20060928073706.GE8056@admingilde.org>
Martin Waitz wrote:
> On Wed, Sep 27, 2006 at 09:58:43AM -0700, A Large Angry SCM wrote:
>> This means that modules are not separate, stand alone projects but,
>> rather, just a sub part of your bigger project. Very useful and
>> applicable in some situations but other situations want/need separate,
>> stand alone subprojects.
>
> you can do everything with the submodule which would be possible with
> a normal GIT repository. And you can always clone it into an directory
> which is not controlled by a parent project.
>
> I really think that this is an very important property of a submodule.
I must be missing something.
I just read you original message in the (sub)thread again and you said:
* the .git/refs/heads directory of the submodule gets stored in
.gitmodule/<modulename> inside the parent project
If the submodule refs in the parent are a _copy_, then work performed in
the submodule outside of the parent will be lost when the parent is in
control of the submodule again.
If the submodule refs in the parent are the actual submodule refs then
the submodule is not independent of the parent.
If the submodule refs in the parent are a symlink to the refs in the
submodule, then the parent has no control over which version of the
submodule it gets on the next checkout since the submodule can update
the ref.
[...]
> One use-case which may be important here:
>
> The submodule has two different branches which got forked and are not
> intended to be merged again. At some point in time the parent project
> wants to switch from one branch of the submodule to another branch.
> If a user still has modifications in the old branch and wants to
> update the parent project then it is important to know if the local
> modifications and those coming from the parent have to be merged or
> should stay in different branches.
> If the parent is switching branches there should only be some warning
> if the user still has modifications in the old branch, giving him the
> chance to port the modifications to the other branch.
Again, this is leading me to believe that the submodule is not
independent of the parent.
^ permalink raw reply
* Re: Notes on Using Git with Subprojects
From: Jeff King @ 2006-09-28 20:16 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>
On Wed, Sep 27, 2006 at 02:05:28PM -0700, Junio C Hamano wrote:
> 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.
Keep in mind that it might not be an attempt to avoid checking out part
of the tree, but rather importing part of the tree (the subproject) into
your repository at all (to save space, download time, etc). So unless
you're also proposing sparse repos, I think this still might be a
subproject issue.
-Peff
^ permalink raw reply
* [PATCH] git-format-patch: fix bug using -o in subdirectories
From: Matthias Lederhofer @ 2006-09-28 19:55 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vzmckufu0.fsf@assigned-by-dhcp.cox.net>
This was introduced by me in commit v1.4.2.1-gc08e524.
Signed-off-by: Matthias Lederhofer <matled@gmx.net>
---
Junio C Hamano <junkio@cox.net> wrote:
> "Nguyen Thai Ngoc Duy" <pclouds@gmail.com> writes:
>
> > This patch works great. I assume you forgot it?
>
> Thanks for reminding.
Argh, there is a bug. When prefix is not NULL and -o is specified
git-format-patch fails:
~/src/git/a% ../git-format-patch -o ./b HEAD~1
fatal: Two output directories?
---
builtin-log.c | 5 +++--
1 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/builtin-log.c b/builtin-log.c
index 130b53a..9d1ceae 100644
--- a/builtin-log.c
+++ b/builtin-log.c
@@ -270,8 +270,6 @@ 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
@@ -350,6 +348,9 @@ int cmd_format_patch(int argc, const cha
if (!rev.diffopt.output_format)
rev.diffopt.output_format = DIFF_FORMAT_DIFFSTAT | DIFF_FORMAT_PATCH;
+ if (!output_directory)
+ output_directory = prefix;
+
if (output_directory) {
if (use_stdout)
die("standard output, or directory, which one?");
--
1.4.2.1.ge767
^ permalink raw reply related
* Re: git and time
From: Shawn Pearce @ 2006-09-28 19:50 UTC (permalink / raw)
To: Matthew L Foster; +Cc: Johannes Schindelin, Linus Torvalds, Rogan Dawes, git
In-Reply-To: <20060928194316.42986.qmail@web51004.mail.yahoo.com>
Matthew L Foster <mfoster167@yahoo.com> wrote:
> --- Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
>
> > On Thu, 28 Sep 2006, Matthew L Foster wrote:
> >
> > > It should be possible to export git data, through say a web interface,
> > > in a such a way that local time order is consistent with commit order.
> >
> > Why?
>
> - So exported data is never/rarely in an inconsistent state with respect to commit order and local
> time order (data integrity).
Pick one. You can't have "never" and "rarely".
> - To encourage people to care about/prefer local commit time rather than remote creation/emailed
> time
Why? In general I don't care about time in Git. Maybe I care about
when I authored something if my wife wants to know why I was up until
6 am the night before ("Look honey, I was coding until 6:00 am! See
the commit!") but otherwise I don't find time to be that interesting.
Then again I don't find time in the real world that intersting
either. I'm either where I'm supposed to be or I'm not and I'll
get there when I get there.
> - So people that user repo X, or binaries from repo X, know when bug fix Y/fancy new feature Z was
> committed/merged locally
Track it by version, not timestamp. Know what commit or tag SHA1
was used to produce that binary. Ask GIT if the fix is in that
SHA1 ancestory or not. I've already said that on this thread.
> - In many situations "history" is incomplete without local commit time. If a company has a new
> driver they would probably prefer to know when the main kernel repo has it, not when they
> created/emailed it or when a remote repo committed it.
I think they care more about what release of the kernel will have
that driver. That can easily be determined by the DAG and by
understanding what branch(es) will wind up in the next release and
doing simple math: "Lets see, current release is version 2.6.9000,
so it will be in 2.6.9001."
--
Shawn.
^ permalink raw reply
* Re: git and time
From: Matthew L Foster @ 2006-09-28 19:43 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Linus Torvalds, Rogan Dawes, git
In-Reply-To: <Pine.LNX.4.63.0609281941570.14200@wbgn013.biozentrum.uni-wuerzburg.de>
--- Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> On Thu, 28 Sep 2006, Matthew L Foster wrote:
>
> > It should be possible to export git data, through say a web interface,
> > in a such a way that local time order is consistent with commit order.
>
> Why?
- So exported data is never/rarely in an inconsistent state with respect to commit order and local
time order (data integrity).
- To encourage people to care about/prefer local commit time rather than remote creation/emailed
time
- So people that user repo X, or binaries from repo X, know when bug fix Y/fancy new feature Z was
committed/merged locally
- In many situations "history" is incomplete without local commit time. If a company has a new
driver they would probably prefer to know when the main kernel repo has it, not when they
created/emailed it or when a remote repo committed it.
-Matt
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
^ permalink raw reply
* partial svnimport [was: Re: [PATCH] git-svnimport: Parse log message for Signed-off-by: lines]
From: Sasha Khapyorsky @ 2006-09-28 19:44 UTC (permalink / raw)
To: Matthias Urlichs; +Cc: Junio C Hamano, git
In-Reply-To: <20060906153314.GE6999@kiste.smurf.noris.de>
Hi,
On 17:33 Wed 06 Sep , Matthias Urlichs wrote:
> Hi,
>
> Sasha Khapyorsky:
> > At least I didn't succeed with reversed layout. With option
> > -T <trunk>/$project import works but only for trunk branch, attempts
> > to specify branch as -b <branches> or -b <branches>/$project don't help,
> > the same is with tags.
> >
> That's true. The problem is that it wants the tag or branch name as the
> last component of the path.
>
> A more generic solution would be to use wildcards in the branch/tag
> specification, to allow more than one wildcard, and to be able to
> specify the exact form of the branch or tag name on the git side.
Or perhaps just to specify path of the project (or sub-project) after
trunk/branches*/ . Like in this patch:
diff --git a/git-svnimport.perl b/git-svnimport.perl
index 988514e..86a6e8a 100755
--- a/git-svnimport.perl
+++ b/git-svnimport.perl
@@ -31,7 +31,8 @@ die "Need SVN:Core 1.2.1 or better" if $
$ENV{'TZ'}="UTC";
our($opt_h,$opt_o,$opt_v,$opt_u,$opt_C,$opt_i,$opt_m,$opt_M,$opt_t,$opt_T,
- $opt_b,$opt_r,$opt_I,$opt_A,$opt_s,$opt_l,$opt_d,$opt_D,$opt_S,$opt_F);
+ $opt_b,$opt_r,$opt_I,$opt_A,$opt_s,$opt_l,$opt_d,$opt_D,$opt_S,$opt_F,
+ $opt_P);
sub usage() {
print STDERR <<END;
@@ -39,17 +40,19 @@ Usage: ${\basename $0} # fetch/updat
[-o branch-for-HEAD] [-h] [-v] [-l max_rev]
[-C GIT_repository] [-t tagname] [-T trunkname] [-b branchname]
[-d|-D] [-i] [-u] [-r] [-I ignorefilename] [-s start_chg]
- [-m] [-M regex] [-A author_file] [-S] [-F] [SVN_URL]
+ [-m] [-M regex] [-A author_file] [-S] [-F] [-P project] [SVN_URL]
END
exit(1);
}
-getopts("A:b:C:dDFhiI:l:mM:o:rs:t:T:Suv") or usage();
+getopts("A:b:C:dDFhiI:l:mM:o:rs:t:T:SP:uv") or usage();
usage if $opt_h;
my $tag_name = $opt_t || "tags";
my $trunk_name = $opt_T || "trunk";
my $branch_name = $opt_b || "branches";
+my $project_name = $opt_P || "";
+$project_name = "/" . $project_name if ($project_name);
@ARGV == 1 or @ARGV == 2 or usage();
@@ -356,11 +359,11 @@ sub revert_split_path($$) {
my $svnpath;
$path = "" if $path eq "/"; # this should not happen, but ...
if($branch eq "/") {
- $svnpath = "$trunk_name/$path";
+ $svnpath = "$trunk_name$project_name/$path";
} elsif($branch =~ m#^/#) {
- $svnpath = "$tag_name$branch/$path";
+ $svnpath = "$tag_name$branch$project_name/$path";
} else {
- $svnpath = "$branch_name/$branch/$path";
+ $svnpath = "$branch_name/$branch$project_name/$path";
}
$svnpath =~ s#/+$##;
@@ -864,6 +867,20 @@ # }
print "DONE: $revision $dest $cid\n" if $opt_v;
}
+sub project_path($$)
+{
+ my ($path, $project) = @_;
+
+ $path = "/".$path unless ($path =~ m#^\/#) ;
+ return $1 if ($path =~ m#^$project\/(.*)$#);
+
+ $path =~ s#\.#\\\.#g;
+ $path =~ s#\+#\\\+#g;
+ return "/" if ($project =~ m#^$path.*$#);
+
+ return undef;
+}
+
sub commit_all {
# Recursive use of the SVN connection does not work
local $svn = $svn2;
@@ -883,6 +900,10 @@ sub commit_all {
while(my($path,$action) = each %$changed_paths) {
($branch,$path) = split_path($revision,$path);
next if not defined $branch;
+ if ($project_name) {
+ $path = project_path($path, $project_name);
+ next if not defined $path;
+ }
$done{$branch}{$path} = $action;
}
while(($branch,$changed_paths) = each %done) {
(will submit if above is acceptable)
> All of this should be specified in the repository's git config file,
> not on the command line.
It is for incremental imports? So we will not need to reproduce exact
command line for each git-svnimport run? Good idea.
Sasha
^ permalink raw reply related
* [PATCH] http/ftp: optionally ask curl to not use EPSV command
From: Sasha Khapyorsky @ 2006-09-28 19:26 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
If GIT_CURL_FTP_NO_EPSV environment variable is defined, disable using
of EPSV ftp command (PASV will be used instead). This is helpful with
some "poor" ftp servers which doesn't support EPSV mode.
Signed-off-by: Sasha Khapyorsky <sashak@voltaire.com>
---
http.c | 3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/http.c b/http.c
index 6c1937b..a966e6d 100644
--- a/http.c
+++ b/http.c
@@ -196,6 +196,9 @@ #endif
curl_easy_setopt(result, CURLOPT_USERAGENT, GIT_USER_AGENT);
+ if (getenv("GIT_CURL_FTP_NO_EPSV"))
+ curl_easy_setopt(result, CURLOPT_FTP_USE_EPSV, 0);
+
return result;
}
--
1.4.2.1
^ permalink raw reply related
* Re: git and time
From: Matthew L Foster @ 2006-09-28 19:18 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Rogan Dawes, git
In-Reply-To: <Pine.LNX.4.64.0609281043380.3952@g5.osdl.org>
--- Linus Torvalds <torvalds@osdl.org> wrote:
> - it means that the -same- exact project, when looked at frm two
> different sites that mirror it, have totally different times. In other
> words, the times have become pointless for something like gitweb.
Mirrored git repos probably should use the same timestamp, e.g. the "master" or "private" git
server's local time. Replicated repos have a delay compared to when you made changes in your
private repo, that is ok, replication is not what makes commit order inconsistent with time, it's
the act of pulling/merging from a server with misconfigured time and gitweb.cgi trusting "creation
time", right? Or is replication the same thing as merging/pulling?
-Matt
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
^ permalink raw reply
* Re: [PATCH] --stat: ensure at least one '-' for deletions, and one '+' for additions
From: Johannes Schindelin @ 2006-09-28 19:14 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v1wpvvrww.fsf@assigned-by-dhcp.cox.net>
Hi,
On Thu, 28 Sep 2006, Junio C Hamano wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>
> > 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?
No, it is very much a mathematical constraint: we are going to divide by
(max_change - 1), which is 0 or -1 in said cases. In _both_ cases, "it"
happens to be what we actually want. (Okay, in reality we should check for
width > 0, but I think width == 0 would not make _any_ sense.)
> 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.
That is right.
However, I would argue it's actually an improvement. If you have as many
additions as deletions, there should be an equal number of '-' and '+'.
After all, the integer number of symbols is just an approximation anyway.
Ciao,
Dscho
^ permalink raw reply
* Fix approxidate() to understand more extended numbers
From: Linus Torvalds @ 2006-09-28 19:14 UTC (permalink / raw)
To: Junio C Hamano, Git Mailing List
In-Reply-To: <Pine.LNX.4.64.0609281211260.3952@g5.osdl.org>
You can now say "5:35 PM yesterday", and approxidate() gets the right answer.
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
---
Useful? Of course. In a sick and twisted sort of way.
Try to say "yesterday at 5 PM" before and after this. It _really_ was
confused before.
diff --git a/date.c b/date.c
index 4ff6604..db4c185 100644
--- a/date.c
+++ b/date.c
@@ -598,6 +598,32 @@ static void date_tea(struct tm *tm, int
date_time(tm, 17);
}
+static void date_pm(struct tm *tm, int *num)
+{
+ int hour = *num;
+ *num = 0;
+
+ if (hour > 0 && hour < 12) {
+ tm->tm_hour = hour;
+ tm->tm_min = 0;
+ tm->tm_sec = 0;
+ }
+ if (tm->tm_hour > 0 && tm->tm_hour < 12)
+ tm->tm_hour += 12;
+}
+
+static void date_am(struct tm *tm, int *num)
+{
+ int hour = *num;
+ *num = 0;
+
+ if (hour > 0 && hour < 12) {
+ tm->tm_hour = hour;
+ tm->tm_min = 0;
+ tm->tm_sec = 0;
+ }
+}
+
static const struct special {
const char *name;
void (*fn)(struct tm *, int *);
@@ -606,6 +632,8 @@ static const struct special {
{ "noon", date_noon },
{ "midnight", date_midnight },
{ "tea", date_tea },
+ { "PM", date_pm },
+ { "AM", date_am },
{ NULL }
};
@@ -717,6 +745,18 @@ static const char *approxidate_digit(con
char *end;
unsigned long number = strtoul(date, &end, 10);
+ switch (*end) {
+ case ':':
+ case '.':
+ case '/':
+ case '-':
+ if (isdigit(end[1])) {
+ int match = match_multi_number(number, *end, date, end, tm);
+ if (match)
+ return date + match;
+ }
+ }
+
*num = number;
return end;
}
^ permalink raw reply related
* [PATCH] do not discard constness in interp_set_entry value argument
From: Alex Riesen @ 2006-09-28 19:12 UTC (permalink / raw)
To: git; +Cc: Jon Loeliger, Junio C Hamano
Signed-off-by: Alex Riesen <raa.lkml@gmail.com>
---
Actually, both of the struct interp's fields could be made const,
if not this interp_set_entry. And even then it could just return
the old value of ->value casting away its constness. I.e.:
struct interp
{
const char *name;
const char *value;
};
static inline char *interp_set_entry(struct interp *table, int slot, const char *value)
{
char *oldval = (char *)table[slot].value;
table[slot].value = newval;
return oldval;
}
The caller can than decide if it should be freed. This leaves
compiler with a chance to optimize something.
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
* Clean up approxidate() in preparation for fixes
From: Linus Torvalds @ 2006-09-28 19:12 UTC (permalink / raw)
To: Junio C Hamano, Git Mailing List
Our approxidate cannot handle simple times like "5 PM yesterday", and to
fix that, we will need to add some logic for number handling. This just
splits that out into a function of its own (the same way the _real_ date
parsing works).
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
---
This should change no code what-so-ever, just split it up in preparation
for the next patch..
diff --git a/date.c b/date.c
index e387dcd..4ff6604 100644
--- a/date.c
+++ b/date.c
@@ -712,6 +712,15 @@ static const char *approxidate_alpha(con
return end;
}
+static const char *approxidate_digit(const char *date, struct tm *tm, int *num)
+{
+ char *end;
+ unsigned long number = strtoul(date, &end, 10);
+
+ *num = number;
+ return end;
+}
+
unsigned long approxidate(const char *date)
{
int number = 0;
@@ -731,9 +740,7 @@ unsigned long approxidate(const char *da
break;
date++;
if (isdigit(c)) {
- char *end;
- number = strtoul(date-1, &end, 10);
- date = end;
+ date = approxidate_digit(date-1, &tm, &number);
continue;
}
if (isalpha(c))
^ permalink raw reply related
* Re: [PATCH] gitweb: tree view: hash_base and hash are now context sensitive
From: Luben Tuikov @ 2006-09-28 18:52 UTC (permalink / raw)
To: ltuikov, Junio C Hamano, Jakub Narebski; +Cc: git, ltuikov
In-Reply-To: <20060927225342.7695.qmail@web31801.mail.mud.yahoo.com>
--- Luben Tuikov <ltuikov@yahoo.com> wrote:
> --- Junio C Hamano <junkio@cox.net> wrote:
> > Luben Tuikov <ltuikov@yahoo.com> writes:
> >
> > > --- Jakub Narebski <jnareb@gmail.com> wrote:
> > >> I think that this need some thinking over. For blob we have two
> > >> "base" objects: tree which have specified blob, and commit which
> > >> have tree which have specified blob. We might want to specify
> > >> that all hash*base are to the commit-ish.
> > >
> > > Agreed, we should always refer to the commit-ish, for obvious
> > > reasons.
> > >
> > > This patch doesn't make this decision though. It simply
> > > sets hash_base to HEAD if not defined.
> > >
> > > Now, since "git-ls-tree" works on both commit-ish and
> > > tree-ish, we are ok.
> >
> > I think so, too. Jakub?
>
> Status? I see Jakub hasn't objected, and it is really important
> for us to be able to link to "latest" binary blob -- for example
> a PDF spec file.
Junio,
What are the objections to this patch?
Thanks,
Luben
^ permalink raw reply
* Re: git-clone does not work if run in /temp
From: Timur Tabi @ 2006-09-28 18:48 UTC (permalink / raw)
To: Git Mailing List
In-Reply-To: <451C1635.9090608@freescale.com>
Timur Tabi wrote:
> If the current directory is '/temp', then git-clone fails:
Update: I just noticed I have a directory called "http:" (yes, with the colon) in my /temp directory, and that was causing the problem.
I still think this is a bug in git, though. If I have time, I'll try to fix it myself.
--
Timur Tabi
Linux Kernel Developer @ Freescale
^ permalink raw reply
* [PATCH] fix daemon.c compilation for NO_IPV6=1
From: Alex Riesen @ 2006-09-28 18:48 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano
Signed-off-by: Alex Riesen <raa.lkml@gmail.com>
---
Just a typo.
diff --git a/daemon.c b/daemon.c
index fc3951c..ad84928 100644
--- a/daemon.c
+++ b/daemon.c
@@ -834,7 +834,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;
^ permalink raw reply related
* git-clone does not work if run in /temp
From: Timur Tabi @ 2006-09-28 18:36 UTC (permalink / raw)
To: Git Mailing List
If the current directory is '/temp', then git-clone fails:
$ git clone http://git.kernel.org/pub/scm/linux/kernel/git/paulus/powerpc.git powerpc
ssh: /temp/http: Name or service not known
fatal: unexpected EOF
fetch-pack from '/temp/http:/git.kernel.org/pub/scm/linux/kernel/git/paulus/powerpc.git/.git' failed.
If I switch to /tmp and run git-clone again, it works.
--
Timur Tabi
Linux Kernel Developer @ Freescale
^ permalink raw reply
* Re: [PATCH] gitweb: Remove excessively redundant entries from git_difftree_body
From: Luben Tuikov @ 2006-09-28 18:28 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vmz8k7nhc.fsf@assigned-by-dhcp.cox.net>
--- Junio C Hamano <junkio@cox.net> wrote:
> We lost blobdiff from commitdiff page with this patch, which I
> think it probably is a good change. We can say "when we display
> a pathname you can click it to get the blob or tree".
I think so too.
> By the way, just like your "blob" and "tree" link removal, I
> think we can lose "commit" link in shortlog. The list looks
> rather cluttered with three links; we could replace it with
> "snapshot" link if we wanted to.
I agree.
Luben
> I am neutral about doing that for long log pages. The commit
> titles are links there as well, but they do not look like "one
> of the columns that can be clicked in a single line per row
> table" as in shortlog page. The page could also get "snapshot"
> links.
>
>
>
>
>
^ permalink raw reply
* Re: git and time
From: apodtele @ 2006-09-28 18:21 UTC (permalink / raw)
To: git
On Thu, 28 Sep 2006, Matthew L Foster wrote:
>
> It should be possible to export git data, through say a web interface,
> in a such a way that local time order is consistent with commit order.
You are proposing to sort your genealogy tree by your ancestor's birthdays...
Yeah, that is really cool and useful too! Look ma! The order is pretty random!
^ permalink raw reply
* Re: git-push of new, tiny branch doing more work than necessary?
From: Carl Worth @ 2006-09-28 18:10 UTC (permalink / raw)
To: Andy Whitcroft; +Cc: Johannes Schindelin, git
In-Reply-To: <45139379.4040602@shadowen.org>
[-- Attachment #1: Type: text/plain, Size: 1077 bytes --]
On Fri, 22 Sep 2006 08:40:41 +0100, Andy Whitcroft wrote:
> I hope this started working again because we fixed it this time. Two
> bugs were fixed in this area. First any branch names over about 40
> characters in length were being ignored completely due to a validation
> bug. Second in an attempt to ensure we didn't bust the 900 entry
> command line limit for rev-list we were restricting ourselves to 16
> remote refs as possible bases. master now has these changes in it and I
> am no longer seeing this behavior.
Aha! Thanks.
It doesn't appear I had the 40-character ref problem, nor was I
exceeding the 900 ref limit. But I was definitely well over the 16 ref
limit.
> >> git version 1.4.2.rc2.gef1d9
> >
> > Please try a more recent version (yours is from Jul 27).
I updated as soon as I got your reply, but just waited until I hit a
repeat of the use case today, (I was just too lazy to try to roll
things back and duplicate the exact same conditions).
Sure enough, things seem to be much better now (git version
1.4.2.1.g16fd), so thanks for the fix.
-Carl
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: git and time
From: Linus Torvalds @ 2006-09-28 18:01 UTC (permalink / raw)
To: Matthew L Foster; +Cc: Rogan Dawes, git
In-Reply-To: <20060928173350.95443.qmail@web51004.mail.yahoo.com>
On Thu, 28 Sep 2006, Matthew L Foster wrote:
>
> It should be possible to export git data, through say a web interface,
> in a such a way that local time order is consistent with commit order.
I really don't think the thing you ask for exists.
Don't get me wrong. You _can_ have a local time for each commit that
tracks "when did this commit show up in this particular branch". Git
already supports that, even if gitweb cannot show it, and in fact showing
it would be very hard (since the exact same commit can often exist in
multiple different branches, you'd have to show multiple times: in Junios
"git" tree you often have a commit that showed up in the "next" branch
three weeks ago, but in the "master" branch only yesterday).
The _problem_ with this is that it makes the whole concept of time
meaningless. It's pointless. You can do it, but I guarantee you that once
you actually use it for a while, you'll want to go back. There are several
reasons for that:
- it means that the -same- exact project, when looked at frm two
different sites that mirror it, have totally different times. In other
words, the times have become pointless for something like gitweb.
- it means that all times will be seriously "compressed", in that you'll
find hundreds (or thousands) of commits that just have the same
timestamp. You could try to "spread them out" by just making up some
totally arbitrary mapping function, but that would basically have
absolutely no basis in anything that has any relationship to "reality"
So it just doesn't make any sense.
The only thing that makes sense is that in your private repository (that
is _not_ exported to others through "gitweb" or something like that), you
can ask yourself the question:
"What did my tree look like yesterday before I went out for a
beer, and came back drunk as a toad, and screwed everything up?"
And the thing is, you can do that already. Just say
git log "master@{18 hours ago}"
and git will hopefully show you (assuming you had enabled ref-logging as
described earlier in this thread) exactly what you wanted.
See?
But it does not make sense in _any_ other setting. Certainly not gitweb.
Linus
^ permalink raw reply
* Re: git and time
From: Matthew L Foster @ 2006-09-28 17:30 UTC (permalink / raw)
To: Tom Prince
In-Reply-To: <20060928170110.GD3650@socrates.priv>
--- Tom Prince <tom.prince@ualberta.net> wrote:
> On Thu, Sep 28, 2006 at 09:55:08AM -0700, Matthew L Foster wrote:
> >
> > --- 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
>
> The point is, it DOES NOT rely on anyone's clock being set correctly.
gitweb.cgi does. It should be possible to export git data, through say a web interface, in a such
a way that local time order is consistent with commit order.
[responding to Linus' mail here:] I understand that git doesn't care about time internally as it
treats it as a random number for people to care about or not on their own, I am only saying that
local time is more likely to be cared about than disparate remote creation times.
-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: Johannes Schindelin @ 2006-09-28 17:42 UTC (permalink / raw)
To: Matthew L Foster; +Cc: Linus Torvalds, Rogan Dawes, git
In-Reply-To: <20060928173350.95443.qmail@web51004.mail.yahoo.com>
On Thu, 28 Sep 2006, Matthew L Foster wrote:
> It should be possible to export git data, through say a web interface,
> in a such a way that local time order is consistent with commit order.
Why?
^ permalink raw reply
* Re: git and time
From: Matthew L Foster @ 2006-09-28 17:33 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Rogan Dawes, git
In-Reply-To: <Pine.LNX.4.64.0609281003070.3952@g5.osdl.org>
> 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!
I understand that git doesn't care about time internally as it treats it as a random number for
people to care about or not on their own, I am only saying that local time is more likely to be
cared about than disparate remote creation times.
It should be possible to export git data, through say a web interface, in a such a way that local
time order is consistent with commit order.
-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: 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
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