* [PATCH 2/3] diff --stat: color output.
From: Junio C Hamano @ 2006-09-27 2:40 UTC (permalink / raw)
To: git
Under --color option, diffstat shows '+' and '-' in the graph
the same color as added and deleted lines.
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
* This is unsolicited but while I was touching the vicinity of
the code I thought some people might find it cool.
diff.c | 29 +++++++++++++++++++----------
1 files changed, 19 insertions(+), 10 deletions(-)
diff --git a/diff.c b/diff.c
index 6101365..13aac2d 100644
--- a/diff.c
+++ b/diff.c
@@ -555,17 +555,20 @@ static int scale_linear(int it, int widt
return (it * width * 2 + max_change) / (max_change * 2);
}
-static void show_name(const char *prefix, const char *name, int len)
+static void show_name(const char *prefix, const char *name, int len,
+ const char *reset, const char *set)
{
- printf(" %s%-*s |", prefix, len, name);
+ printf(" %s%s%-*s%s |", set, prefix, len, name, reset);
}
-static void show_graph(char ch, int cnt)
+static void show_graph(char ch, int cnt, const char *set, const char *reset)
{
if (!cnt)
return;
+ printf("%s", set);
while (cnt--)
putchar(ch);
+ printf("%s", reset);
}
static void show_stats(struct diffstat_t* data, struct diff_options *options)
@@ -574,6 +577,7 @@ static void show_stats(struct diffstat_t
int max_change = 0, max_len = 0;
int total_files = data->nr;
int width, name_width;
+ const char *reset, *set, *add_c, *del_c;
if (data->nr == 0)
return;
@@ -592,6 +596,11 @@ static void show_stats(struct diffstat_t
}
/* Find the longest filename and max number of changes */
+ reset = diff_get_color(options->color_diff, DIFF_RESET);
+ set = diff_get_color(options->color_diff, DIFF_PLAIN);
+ add_c = diff_get_color(options->color_diff, DIFF_FILE_NEW);
+ del_c = diff_get_color(options->color_diff, DIFF_FILE_OLD);
+
for (i = 0; i < data->nr; i++) {
struct diffstat_file *file = data->files[i];
int change = file->added + file->deleted;
@@ -649,12 +658,12 @@ static void show_stats(struct diffstat_t
}
if (data->files[i]->is_binary) {
- show_name(prefix, name, len);
+ show_name(prefix, name, len, reset, set);
printf(" Bin\n");
goto free_diffstat_file;
}
else if (data->files[i]->is_unmerged) {
- show_name(prefix, name, len);
+ show_name(prefix, name, len, reset, set);
printf(" Unmerged\n");
goto free_diffstat_file;
}
@@ -680,18 +689,18 @@ static void show_stats(struct diffstat_t
add = scale_linear(add, width, max_change);
del = total - add;
}
- show_name(prefix, name, len);
+ show_name(prefix, name, len, reset, set);
printf("%5d ", added + deleted);
- show_graph('+', add);
- show_graph('-', del);
+ show_graph('+', add, add_c, reset);
+ show_graph('-', del, del_c, reset);
putchar('\n');
free_diffstat_file:
free(data->files[i]->name);
free(data->files[i]);
}
free(data->files);
- printf(" %d files changed, %d insertions(+), %d deletions(-)\n",
- total_files, adds, dels);
+ printf("%s %d files changed, %d insertions(+), %d deletions(-)%s\n",
+ set, total_files, adds, dels, reset);
}
struct checkdiff_t {
--
1.4.2.1.gf80a
^ permalink raw reply related
* [PATCH] gitweb: Escape long title for link tooltips
From: Yasushi SHOJI @ 2006-09-27 2:38 UTC (permalink / raw)
To: git
This is a simple one liner to fix the bug not escaping title string
for link tooltips.
This is not crucial if the commit message is all in ASCII, however, if
you decide to use other encoding, such as UTF-8, tooltips ain't
readable any more.
Signed-off-by: Yasushi SHOJI <yashi@atmark-techno.com>
---
gitweb/gitweb.perl | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index 66be619..67f49df 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -617,7 +617,7 @@ sub format_subject_html {
if (length($short) < length($long)) {
return $cgi->a({-href => $href, -class => "list subject",
- -title => $long},
+ -title => esc_html($long)},
esc_html($short) . $extra);
} else {
return $cgi->a({-href => $href, -class => "list subject"},
--
1.4.2.1.g83915
^ permalink raw reply related
* [PATCH 1/3] diff --stat: allow custom diffstat output width.
From: Junio C Hamano @ 2006-09-27 2:40 UTC (permalink / raw)
To: git; +Cc: Adrian Bunk, Linus Torvalds
This adds two parameters to "diff --stat".
. --stat-width=72 tells that the page should fit on 72-column output.
. --stat-name-width=30 tells that the filename part is limited
to 30 columns.
Without these flags, they default to 80 and 50 as before.
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
* Adrian Bunk on the kernel list wanted ot have "diffstat
-w72", so here it is.
diff.c | 132 ++++++++++++++++++++++++++++++++++++++++++++++------------------
diff.h | 3 +
2 files changed, 97 insertions(+), 38 deletions(-)
diff --git a/diff.c b/diff.c
index 443e248..6101365 100644
--- a/diff.c
+++ b/diff.c
@@ -545,21 +545,63 @@ static void diffstat_consume(void *priv,
x->deleted++;
}
-static const char pluses[] = "++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++";
-static const char minuses[]= "----------------------------------------------------------------------";
const char mime_boundary_leader[] = "------------";
-static void show_stats(struct diffstat_t* data)
+static int scale_linear(int it, int width, int max_change)
+{
+ /*
+ * round(width * it / max_change);
+ */
+ return (it * width * 2 + max_change) / (max_change * 2);
+}
+
+static void show_name(const char *prefix, const char *name, int len)
+{
+ printf(" %s%-*s |", prefix, len, name);
+}
+
+static void show_graph(char ch, int cnt)
+{
+ if (!cnt)
+ return;
+ while (cnt--)
+ putchar(ch);
+}
+
+static void show_stats(struct diffstat_t* data, struct diff_options *options)
{
int i, len, add, del, total, adds = 0, dels = 0;
- int max, max_change = 0, max_len = 0;
+ int max_change = 0, max_len = 0;
int total_files = data->nr;
+ int width, name_width;
if (data->nr == 0)
return;
+ width = options->stat_width ? options->stat_width : 80;
+ name_width = options->stat_name_width ? options->stat_name_width : 50;
+
+ /* Sanity: give at least 5 columns to the graph,
+ * but leave at least 10 columns for the name.
+ */
+ if (width < name_width + 15) {
+ if (25 < name_width)
+ name_width = width - 15;
+ else
+ width = name_width + 15;
+ }
+
+ /* Find the longest filename and max number of changes */
for (i = 0; i < data->nr; i++) {
struct diffstat_file *file = data->files[i];
+ int change = file->added + file->deleted;
+
+ if (0 < (len = quote_c_style(file->name, NULL, NULL, 0))) {
+ char *qname = xmalloc(len + 1);
+ quote_c_style(file->name, qname, NULL, 0);
+ free(file->name);
+ file->name = qname;
+ }
len = strlen(file->name);
if (max_len < len)
@@ -567,54 +609,53 @@ static void show_stats(struct diffstat_t
if (file->is_binary || file->is_unmerged)
continue;
- if (max_change < file->added + file->deleted)
- max_change = file->added + file->deleted;
+ if (max_change < change)
+ max_change = change;
}
+ /* Compute the width of the graph part;
+ * 10 is for one blank at the beginning of the line plus
+ * " | count " between the name and the graph.
+ *
+ * From here on, name_width is the width of the name area,
+ * and width is the width of the graph area.
+ */
+ name_width = (name_width < max_len) ? name_width : max_len;
+ if (width < (name_width + 10) + max_change)
+ width = width - (name_width + 10);
+ else
+ width = max_change;
+
for (i = 0; i < data->nr; i++) {
const char *prefix = "";
char *name = data->files[i]->name;
int added = data->files[i]->added;
int deleted = data->files[i]->deleted;
-
- if (0 < (len = quote_c_style(name, NULL, NULL, 0))) {
- char *qname = xmalloc(len + 1);
- quote_c_style(name, qname, NULL, 0);
- free(name);
- data->files[i]->name = name = qname;
- }
+ int name_len;
/*
* "scale" the filename
*/
- len = strlen(name);
- max = max_len;
- if (max > 50)
- max = 50;
- if (len > max) {
+ len = name_width;
+ name_len = strlen(name);
+ if (name_width < name_len) {
char *slash;
prefix = "...";
- max -= 3;
- name += len - max;
+ len -= 3;
+ name += name_len - len;
slash = strchr(name, '/');
if (slash)
name = slash;
}
- len = max;
-
- /*
- * scale the add/delete
- */
- max = max_change;
- if (max + len > 70)
- max = 70 - len;
if (data->files[i]->is_binary) {
- printf(" %s%-*s | Bin\n", prefix, len, name);
+ show_name(prefix, name, len);
+ printf(" Bin\n");
goto free_diffstat_file;
}
else if (data->files[i]->is_unmerged) {
- printf(" %s%-*s | Unmerged\n", prefix, len, name);
+ show_name(prefix, name, len);
+ printf(" Unmerged\n");
goto free_diffstat_file;
}
else if (!data->files[i]->is_renamed &&
@@ -623,27 +664,34 @@ static void show_stats(struct diffstat_t
goto free_diffstat_file;
}
+ /*
+ * scale the add/delete
+ */
add = added;
del = deleted;
total = add + del;
adds += add;
dels += del;
- if (max_change > 0) {
- total = (total * max + max_change / 2) / max_change;
- add = (add * max + max_change / 2) / max_change;
+ if (max_change < width)
+ ;
+ else {
+ total = scale_linear(total, width, max_change);
+ add = scale_linear(add, width, max_change);
del = total - add;
}
- printf(" %s%-*s |%5d %.*s%.*s\n", prefix,
- len, name, added + deleted,
- add, pluses, del, minuses);
+ show_name(prefix, name, len);
+ printf("%5d ", added + deleted);
+ show_graph('+', add);
+ show_graph('-', del);
+ putchar('\n');
free_diffstat_file:
free(data->files[i]->name);
free(data->files[i]);
}
free(data->files);
printf(" %d files changed, %d insertions(+), %d deletions(-)\n",
- total_files, adds, dels);
+ total_files, adds, dels);
}
struct checkdiff_t {
@@ -1681,6 +1729,14 @@ int diff_opt_parse(struct diff_options *
}
else if (!strcmp(arg, "--stat"))
options->output_format |= DIFF_FORMAT_DIFFSTAT;
+ else if (!strncmp(arg, "--stat-width=", 13)) {
+ options->stat_width = strtoul(arg + 13, NULL, 10);
+ options->output_format |= DIFF_FORMAT_DIFFSTAT;
+ }
+ else if (!strncmp(arg, "--stat-name-width=", 18)) {
+ options->stat_name_width = strtoul(arg + 18, NULL, 10);
+ options->output_format |= DIFF_FORMAT_DIFFSTAT;
+ }
else if (!strcmp(arg, "--check"))
options->output_format |= DIFF_FORMAT_CHECKDIFF;
else if (!strcmp(arg, "--summary"))
@@ -2438,7 +2494,7 @@ void diff_flush(struct diff_options *opt
if (check_pair_status(p))
diff_flush_stat(p, options, &diffstat);
}
- show_stats(&diffstat);
+ show_stats(&diffstat, options);
separator++;
}
diff --git a/diff.h b/diff.h
index b60a02e..e06d0f4 100644
--- a/diff.h
+++ b/diff.h
@@ -69,6 +69,9 @@ struct diff_options {
const char *stat_sep;
long xdl_opts;
+ int stat_width;
+ int stat_name_width;
+
int nr_paths;
const char **paths;
int *pathlens;
--
1.4.2.1.gf80a
^ permalink raw reply related
* Re: [PATCH] perl bindings fix compilation errors
From: Junio C Hamano @ 2006-09-27 2:40 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Andy Whitcroft, git
In-Reply-To: <Pine.LNX.4.63.0609261031430.25371@wbgn013.biozentrum.uni-wuerzburg.de>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> Hi,
>
> On Mon, 25 Sep 2006, Junio C Hamano wrote:
>
>> It is certainly incorrect to say that it is a driver error to
>> git-pull (or git-checkout to switch branches) without running
>> "make clean" first to get rid of perl/Git.c while your Makefile
>> still knows it is a generated file. Our Makefile should be more
>> helpful.
>
> How about this:
The problem is on which branch we would apply this and how long
we will carry it. I suspect you would have to have it forever
and everywhere. After all your bisect can hit a version with
Git.xs and then next build suggested by bisect may be a version
without it. And the user is doing that bisect long after we
release version 47.
The worst part is that the version bisect suggests that does not
have Git.xs may be a version in the past -- which we obviously
cannot apply your patch to.
^ permalink raw reply
* Re: [PATCH] gitweb: tree view: eliminate redundant "blob"
From: Junio C Hamano @ 2006-09-27 2:40 UTC (permalink / raw)
To: Petr Baudis; +Cc: git
In-Reply-To: <20060926160729.GH20017@pasky.or.cz>
Petr Baudis <pasky@suse.cz> writes:
> Dear diary, on Tue, Sep 26, 2006 at 10:54:49AM CEST, I got a letter
> where Jakub Narebski <jnareb@gmail.com> said that...
>> I'd rather not. The fact that the file name and tree name is link,
>> and the fact that commit title and tag title is link is a _convenience_.
>> Not always it is visible (without mouseover) that it is link.
>> And it is _not_ visible in the case of files!
>
> Then that should be fixed.
>
> And directories should have trailing slash in their name in the tree
> listing, for people with non-UNIX background who don't understand the
> ls -l like output.
I am with you on both counts. For the latter, people might
actually like mode string to be changed to pretty pictures,
though.
^ permalink raw reply
* Re: git and time
From: Junio C Hamano @ 2006-09-27 2:31 UTC (permalink / raw)
To: David Lang; +Cc: git
In-Reply-To: <Pine.LNX.4.63.0609261823540.22495@qynat.qvtvafvgr.pbz>
David Lang <dlang@digitalinsight.com> writes:
>>> remember that a pach could be merged to many trees in any order. which
>>> merge date do you want to know about?
>>
>> The date that repository I am looking at with gitweb first had
>> that commit, of course. What other dates did you have in mind?
>
> if that repository is then merged into another one, what date would
> that second one record for that commit? the date it was pulled there?
>
> in many cases this would seem to be useless or distracting information
> (you already display where in the history the merge took place, do you
> really need to attach that date to all changes that arrive from the
> branch?)
Usually, but not on fast forward.
Only when somebody is interested in the particular question
"when did this commit has become part of this branch" it becomes
relevant. And do not get me wrong. I am in principle agreeing
with you that this is an extra information for most of the time
-- I even doubt "when did this commit has become part of this
branch" is all that useful.
^ permalink raw reply
* Re: git and time
From: Linus Torvalds @ 2006-09-27 1:58 UTC (permalink / raw)
To: Matthew L Foster; +Cc: Jeff King, git
In-Reply-To: <20060927002745.15344.qmail@web51005.mail.yahoo.com>
On Tue, 26 Sep 2006, Matthew L Foster wrote:
>
> It's true I don't know much about git, what is the difference between a
> changeset and a snapshot?
Some of it is just semantic, but a lot of it has real user-visible meaning
simply because of the "mental model" difference, so the semantics actually
have some meaning.
A lot of systems think of commits as "what changed", and thus the
"changeset" mentality. A "commit" is just the combination of all changes
that that commit introduced.
Git very fundamentally does not think like that at all.
Git thinks of a commit as a _state_, and the history that led up to that
state. So instead of the commit actually containing pointers to what
changed, it very much contains a pointer directly to the actual state that
was committed (a "tree" in git parlance), and then a set of pointers to
the "parent" commits - the commits that explain where we came from.
Now, in some sense, you can ignore the difference between the two models,
since you'd think that they are totally equivalent: from the git model,
you can always get the "changeset" by just diffing the current state with
the previous state, and conversely from the "changeset" model you can
always get the "current state" by just applying the changeset to the
previous state.
So in that sense, it's just two different ways of looking at exactly the
same thing.
HOWEVER. The fact that git internally thinks in terms of "snapshots" means
that it makes no sense to (for example) record a "file rename". Git
figures it out on its own, by just looking at the state before and after.
The great thing about that is that the exact same logic actually works
even for _unconnected_ states/snapshots, in a way that a "changeset" based
situation would find very hard.
So this is when the otherwise semantic difference actually shows itself.
You can diff between two arbitrary points in time, and git will figure out
renames on its own, without actually ever looking at the changesets in
between (in fact, there may not even _be_ a straight, unbroken chain of
changesets between the two states).
> Are you saying timestamps should be tracked separately or tracked by an
> scm system built on top of git? Does/should git care about the when of a
> snapshot?
Git does record the timestamp, but it records it in the same way it
records the "username" - in that it doesn't really _matter_ to git. It
never actually affects any meaning (well, since you can query for it, it
has a meaning of sorts, but it's strictly limited to any explicit queries,
so if you do "git log --since=2.weeks.ago" it will use the timestamp to
give you what you want, but it doesn't actually affect anything
important).
So think of the timestamps as just comments with a very specific format.
Linus
^ permalink raw reply
* Re: git and time
From: Sean @ 2006-09-27 1:58 UTC (permalink / raw)
To: David Lang; +Cc: Junio C Hamano, git
In-Reply-To: <Pine.LNX.4.63.0609261823540.22495@qynat.qvtvafvgr.pbz>
On Tue, 26 Sep 2006 18:31:59 -0700 (PDT)
David Lang <dlang@digitalinsight.com> wrote:
> if that repository is then merged into another one, what date would that second
> one record for that commit? the date it was pulled there?
Yes of course. The question being posed and answered is.. when did the local
repository first get any specific commit. For the sake of such a question
its merge history and path into the local repository doesn't matter, only
when the commit arrived locallly.
Sean
^ permalink raw reply
* Re: git and time
From: David Lang @ 2006-09-27 1:31 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vk63qnlc2.fsf@assigned-by-dhcp.cox.net>
On Tue, 26 Sep 2006, Junio C Hamano wrote:
> David Lang <dlang@digitalinsight.com> writes:
>
>>> You are right that a "Merged Date:" in gitweb would be useful information to
>>> show for each commit, but it's not straightforward given the design of git.
>>
>> would it?
>>
>> remember that a pach could be merged to many trees in any order. which
>> merge date do you want to know about?
>
> The date that repository I am looking at with gitweb first had
> that commit, of course. What other dates did you have in mind?
>
if that repository is then merged into another one, what date would that second
one record for that commit? the date it was pulled there?
in many cases this would seem to be useless or distracting information (you
already display where in the history the merge took place, do you really need to
attach that date to all changes that arrive from the branch?)
if you have something like
a-b-c-d-e-f-g
\
h------i------j
or worse
a
\
b-----c-d
\ / \
e-f-----g
\
h-i---------j
do you really want the date of j attached to all the changes a-g?
and if this information really is important, wouldn't you want to export the
info out (as j then gets merged into m somewhere else)
David Lang
^ permalink raw reply
* Re: git and time
From: Junio C Hamano @ 2006-09-27 1:34 UTC (permalink / raw)
To: David Lang; +Cc: git
In-Reply-To: <Pine.LNX.4.63.0609261746160.22495@qynat.qvtvafvgr.pbz>
David Lang <dlang@digitalinsight.com> writes:
>> You are right that a "Merged Date:" in gitweb would be useful information to
>> show for each commit, but it's not straightforward given the design of git.
>
> would it?
>
> remember that a pach could be merged to many trees in any order. which
> merge date do you want to know about?
The date that repository I am looking at with gitweb first had
that commit, of course. What other dates did you have in mind?
^ permalink raw reply
* Re: git and time
From: Junio C Hamano @ 2006-09-27 1:11 UTC (permalink / raw)
To: Matthew L Foster; +Cc: git, Jeff King, Jakub Narebski
In-Reply-To: <20060927002745.15344.qmail@web51005.mail.yahoo.com>
Matthew L Foster <mfoster167@yahoo.com> writes:
>> PS Nit: Git doesn't work with changesets, it works with snapshots,
>> building a directed graph of snapshots. Maybe that is the source of your
>> confusion
>
> It's true I don't know much about git, what is the difference
> between a changeset and a snapshot? Are you saying timestamps
> should be tracked separately or tracked by an scm system built
> on top of git? Does/should git care about the when of a
> snapshot?
I do not know what Jeff meant by snapshot vs changeset, so I
would not comment on this part.
> Perhaps my question is directed more toward gitweb.cgi, it
> seems to me the timestamp of when a snapshot was merged into
> this repository should somehow be tracked and that is what
> gitweb.cgi should default to display. For example, if someone
> wants to know if security bugfix X was merged into linus'
> kernel tree they also want to know when that happened, don't
> they?
Each commit object in git records two timestamps. When the
author made that change, and when the change was made into a
commit object in _some_ repository. I _think_ gitweb shows the
latter, but I haven't checked, so Jakub is CC'ed.
What you want to know, when a particular change has become part
of the history of one branch in one repository, is not something
a git commit object records. Enough people wanted to know that
information, so ref-log was introduced. When it is enabled on a
branch, ref-log records when the tip of the branch changed from
what commit to what other commit. But it primarily is meant to
answer this question: "what commit was at the tip of this branch
at time T?"
So if Linus had enabled ref-log in his public repository, and if
gitweb knew to look at ref-log, then gitweb _could_ iterate over
ref-log records for the "master" branch of Linus's repository,
find the earliest one that makes the tip of the "master" branch
a descendant of that security fix X, and report the time of that
change. It could certainly do that.
I have to warn you that this is fairly expensive, and also I
happen to know that Linus does not have ref-log enabled on his
public repository.
Having said that, I doubt the question "when did Linus's tree
saw this security fix X commit?" has much practical value. For
one thing, the time he merges the side branch that has the
security fix and the time he pushes out the resulting mess^Wtree
out to the public repository is different. After pushed out to
the public repository, it takes time for that to mirror out for
public view. From the consumer's point of view, the time it
finishes mirroring out _is_ the only timestamp that matters, but
that mirroing happens outside of git so even if ref-log showed
timestamp from the repository Linus pushes to, it would not
reflect the time the general public first saw "Linus's official
version that contained that fix".
What people would often want to know is "Does v2.6.18-rc5
include that fix?" which is a similar but different question.
This is something gitweb _could_ answer without using ref-log,
and gitk already knows how to answer it.
I somehow thought that it was possible to get "the latest tag
that precedes this commit" (aka "git describe") for each commit
by visiting its commitdiff_plain page, but I do not see it now.
Can somebody tell me if I am hallucinating?
^ permalink raw reply
* Re: git and time
From: Sean @ 2006-09-27 1:07 UTC (permalink / raw)
To: David Lang; +Cc: Matthew L Foster, Jeff King, git
In-Reply-To: <Pine.LNX.4.63.0609261746160.22495@qynat.qvtvafvgr.pbz>
On Tue, 26 Sep 2006 17:47:27 -0700 (PDT)
David Lang <dlang@digitalinsight.com> wrote:
> would it?
>
> remember that a pach could be merged to many trees in any order. which merge
> date do you want to know about?
I *think* it would be useful information to know when it was merged with the
_local_ repository. So in the case of kernel.org gitweb, you'd essentially
be able to find out when _Linus_ received the commit and published it to the
world. Doesn't that sound worthwhile?
Sean
^ permalink raw reply
* Re: git and time
From: David Lang @ 2006-09-27 0:47 UTC (permalink / raw)
To: Sean; +Cc: Matthew L Foster, Jeff King, git
In-Reply-To: <20060926205632.5d487cc9.seanlkml@sympatico.ca>
On Tue, 26 Sep 2006, Sean wrote:
>> It's true I don't know much about git, what is the difference between a changeset and a snapshot?
>> Are you saying timestamps should be tracked separately or tracked by an scm system built on top of
>> git? Does/should git care about the when of a snapshot?
>>
>> Perhaps my question is directed more toward gitweb.cgi, it seems to me the timestamp of when a
>> snapshot was merged into this repository should somehow be tracked and that is what gitweb.cgi
>> should default to display. For example, if someone wants to know if security bugfix X was merged
>> into linus' kernel tree they also want to know when that happened, don't they?
>
> You are right that a "Merged Date:" in gitweb would be useful information to
> show for each commit, but it's not straightforward given the design of git.
would it?
remember that a pach could be merged to many trees in any order. which merge
date do you want to know about?
David Lang
^ permalink raw reply
* Re: git and time
From: Sean @ 2006-09-27 0:56 UTC (permalink / raw)
To: Matthew L Foster; +Cc: Jeff King, git
In-Reply-To: <20060927002745.15344.qmail@web51005.mail.yahoo.com>
On Tue, 26 Sep 2006 17:27:45 -0700 (PDT)
Matthew L Foster <mfoster167@yahoo.com> wrote:
> It's true I don't know much about git, what is the difference between a changeset and a snapshot?
> Are you saying timestamps should be tracked separately or tracked by an scm system built on top of
> git? Does/should git care about the when of a snapshot?
>
> Perhaps my question is directed more toward gitweb.cgi, it seems to me the timestamp of when a
> snapshot was merged into this repository should somehow be tracked and that is what gitweb.cgi
> should default to display. For example, if someone wants to know if security bugfix X was merged
> into linus' kernel tree they also want to know when that happened, don't they?
You are right that a "Merged Date:" in gitweb would be useful information to
show for each commit, but it's not straightforward given the design of git.
Each commit contains the date and time it was first created. Because this value
is used as part of each commits' unique hash value, it can not be changed without
breaking a very fundamental part of Git. This means that Git can not easily
answer the question of which date any particular commit was merged with the
local repository.
To help address this, the "reflog" feature was added (i believe by Shawn Pearce)
which records a local time stamp when pulling in changes from other repositories.
It should be possible to query this log to get the information you desire, but I
don't think it would be efficient enough to do in gitweb unless the values were
cached instead of queried each time.
Sean
^ permalink raw reply
* Re: git and time
From: Matthew L Foster @ 2006-09-27 0:27 UTC (permalink / raw)
To: Jeff King; +Cc: git
In-Reply-To: <20060926233321.GA17084@coredump.intra.peff.net>
> Keep in mind that git doesn't really CARE about timestamps to do most
> operations; it operates on the graph created by parentage. Think of the
> timestamps more as comments; when a commit is created, we comment who
> did it and when, both accordinging to their local information.
>
> -Peff
>
> PS Nit: Git doesn't work with changesets, it works with snapshots,
> building a directed graph of snapshots. Maybe that is the source of your
> confusion
It's true I don't know much about git, what is the difference between a changeset and a snapshot?
Are you saying timestamps should be tracked separately or tracked by an scm system built on top of
git? Does/should git care about the when of a snapshot?
Perhaps my question is directed more toward gitweb.cgi, it seems to me the timestamp of when a
snapshot was merged into this repository should somehow be tracked and that is what gitweb.cgi
should default to display. For example, if someone wants to know if security bugfix X was merged
into linus' kernel tree they also want to know when that happened, don't they?
-Matt
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
^ permalink raw reply
* Re: [PATCH] gitk: Fix nextfile() and add prevfile()
From: Paul Mackerras @ 2006-09-27 0:15 UTC (permalink / raw)
To: OGAWA Hirofumi; +Cc: git, Junio C Hamano
In-Reply-To: <873bae3b5x.fsf_-_@duaron.myhome.or.jp>
OGAWA Hirofumi writes:
> The current nextfile() jumps to last hunk, but I think this is not
> intention, probably, it's forgetting to add "break;". And this
> patch also adds prevfile(), it jumps to previous hunk.
I think your prevfile isn't quite right - I don't think it will do the
right thing if $loc is past the last entry in $difffilestart. Don't
you want the "$ctext yview $prev" after the loop?
Paul.
^ permalink raw reply
* [PATCH] gitweb: extend blame to show links to diff and previous
From: Luben Tuikov @ 2006-09-26 23:45 UTC (permalink / raw)
To: git
[-- Attachment #1: Type: text/plain, Size: 905 bytes --]
git_blame2() now has two more columns, "Prev" and "Diff",
before the "Commit" column, as follows:
Prev Diff Commit Line Data
SHA Diff SHA N ...
...
The "Prev" column shows the SHA of the parent commit,
between which this line changed. Clicking on it shows the
blame of the file as of the parent commit, for that line.
So clicking repeatedly on "Prev" would show you the blame
of that file, from the point of view of the changes
of that particular line whose "Prev" you're clicking on.
The "Diff" column shows "Diff" which is a link to blobdiff
between "Prev" and "Commit" commits _for that line_.
So clicking on "Diff" would show you the blobdiff (HTML)
between the parent commit and this commit which changed
that particular line.
Signed-off-by: Luben Tuikov <ltuikov@yahoo.com>
---
gitweb/gitweb.perl | 18 +++++++++++++++++-
1 files changed, 17 insertions(+), 1 deletions(-)
[-- Attachment #2: 1027985432-blame.txt --]
[-- Type: text/plain, Size: 1738 bytes --]
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index 56638f2..d2519f0 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -2439,7 +2439,7 @@ sub git_blame2 {
print <<HTML;
<div class="page_body">
<table class="blame">
-<tr><th>Commit</th><th>Line</th><th>Data</th></tr>
+<tr><th>Prev</th><th>Diff</th><th>Commit</th><th>Line</th><th>Data</th></tr>
HTML
while (<$fd>) {
/^([0-9a-fA-F]{40}).*?(\d+)\)\s{1}(\s*.*)/;
@@ -2447,6 +2447,8 @@ HTML
my $rev = substr($full_rev, 0, 8);
my $lineno = $2;
my $data = $3;
+ my %pco = parse_commit($full_rev);
+ my $parent = $pco{'parent'};
if (!defined $last_rev) {
$last_rev = $full_rev;
@@ -2455,11 +2457,25 @@ HTML
$current_color = ++$current_color % $num_colors;
}
print "<tr class=\"$rev_color[$current_color]\">\n";
+ # Print the Prev link
+ print "<td class=\"sha1\">";
+ print $cgi->a({-href => href(action=>"blame", hash_base=>$parent, file_name=>$file_name)},
+ esc_html(substr($parent, 0, 8)));
+ print "</td>\n";
+ # Print the Diff (blobdiff) link
+ print "<td>";
+ print $cgi->a({-href => href(action=>"blobdiff", file_name=>$file_name, hash_parent_base=>$parent,
+ hash_base=>$full_rev)},
+ esc_html("Diff"));
+ print "</td>\n";
+ # Print the Commit link
print "<td class=\"sha1\">" .
$cgi->a({-href => href(action=>"commit", hash=>$full_rev, file_name=>$file_name)},
esc_html($rev)) . "</td>\n";
+ # Print the Line number
print "<td class=\"linenr\"><a id=\"l$lineno\" href=\"#l$lineno\" class=\"linenr\">" .
esc_html($lineno) . "</a></td>\n";
+ # Print the Data
print "<td class=\"pre\">" . esc_html($data) . "</td>\n";
print "</tr>\n";
}
--
1.4.2.1.g03d06
^ permalink raw reply related
* Re: git and time
From: Jeff King @ 2006-09-26 23:33 UTC (permalink / raw)
To: Matthew L Foster; +Cc: git
In-Reply-To: <20060926232316.98065.qmail@web51009.mail.yahoo.com>
On Tue, Sep 26, 2006 at 04:23:16PM -0700, Matthew L Foster wrote:
> After seeing how git currently accepts a remote repository's timestamp
> it occurred to me that git should probably instead prefer the time a
> particular changeset was committed to _this_ repository. Perhaps I
If you fetch a commit from a remote repository, it does not get
"committed" to the local repository. It is simply copied. Keep in mind
that the act of making a commit means making an immutable SHA1 object.
If, when you fetched that commit, you changed some aspect of it (like
the timestamp), it would cease to have the same SHA1, and thus the DAG
of your history would differ from the remote end.
During operations where the original commit isn't preserved (e.g.,
applying patches from an email), git applies the current timestamp as
the committer timestamp (but uses the email date as the author
timestamp).
> don't know enough about git but it seems to me the important
> information is when a particular changeset was committed to this
> repository, all other remote/sub/parent repositories' timestamps are
> secondary (or at least should be tracked separately).
That information is not tracked in the commit objects (because they are
never "committed" in the local repository, only copied); however, Shawn's
reflog implementation gives some indication of when each ref changed,
which shows when some (but not all) commits made it into the local
repository.
Keep in mind that git doesn't really CARE about timestamps to do most
operations; it operates on the graph created by parentage. Think of the
timestamps more as comments; when a commit is created, we comment who
did it and when, both accordinging to their local information.
-Peff
PS Nit: Git doesn't work with changesets, it works with snapshots,
building a directed graph of snapshots. Maybe that is the source of your
confusion?
^ permalink raw reply
* Re: git and time
From: Jakub Narebski @ 2006-09-26 23:32 UTC (permalink / raw)
To: git
In-Reply-To: <20060926232316.98065.qmail@web51009.mail.yahoo.com>
Matthew L Foster wrote:
> After seeing how git currently accepts a remote repository's timestamp
> it occurred to me that git should probably instead prefer the time
> a particular changeset was committed to _this_ repository. Perhaps
> I don't know enough about git but it seems to me the important
> information is when a particular changeset was committed to this
> repository, all other remote/sub/parent repositories' timestamps
> are secondary (or at least should be tracked separately).
First, the information you want is contained in reflog. Dates the head tip
got the specified value.
Second, git cannot rewrite commits (and commits contain timestamp) when
fetching commit from remote repository for performance reasons.
Third, git uses timestams as heuristics, but relies on parent information.
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: git and time
From: Johannes Schindelin @ 2006-09-26 23:27 UTC (permalink / raw)
To: Matthew L Foster; +Cc: git
In-Reply-To: <20060926232316.98065.qmail@web51009.mail.yahoo.com>
Hi,
On Tue, 26 Sep 2006, Matthew L Foster wrote:
> After seeing how git currently accepts a remote repository's timestamp
> it occurred to me that git should probably instead prefer the time a
> particular changeset was committed to _this_ repository.
Git accepts it, but does not rely on it. Instead, it relies on
parent-child relations.
Hth,
Dscho
^ permalink raw reply
* git and time
From: Matthew L Foster @ 2006-09-26 23:23 UTC (permalink / raw)
To: git; +Cc: mfoster167
After seeing how git currently accepts a remote repository's timestamp it occurred to me that
git should probably instead prefer the time a particular changeset was committed to _this_
repository. Perhaps I don't know enough about git but it seems to me the important information is
when a particular changeset was committed to this repository, all other remote/sub/parent
repositories' timestamps are secondary (or at least should be tracked separately).
-Matt
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
^ permalink raw reply
* Re: Notes on Using Git with Subprojects
From: A Large Angry SCM @ 2006-09-26 22:45 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <Pine.LNX.4.63.0609270009400.25371@wbgn013.biozentrum.uni-wuerzburg.de>
Johannes Schindelin wrote:
> Hi,
>
> On Tue, 26 Sep 2006, A Large Angry SCM wrote:
>
>> How the state (subproject list, branch names, etc.) is recorded in a
>> parent project is only important to the parent project. The parent
>> project must also know how to interact with with each of its
>> subprojects.
>
> Granted, if you mix VCSes, this is most pragmatic.
>
> But it is also wrong: The whole point in bundling the subprojects together
> is (IMHO) to get the benefits of a VCS for the root project, i.e. for the
> combined states of the subprojects. After all, you want to say "I know
> that this collection of projects at these states compiled and worked
> fine."
>
> And if you let a build system handle the stitching of the subprojects, you
> completely lose these benefits.
Bundling and subproject support are two different things. Bundling is
for convenience. Subprojects are usually the result of a dependency on a
project managed or controlled by some other entity or on some part of
the larger project with radically different development requirements.
Recording which version of a subproject to use is important and my note
failed to discuss it. That I'll remedy over the next several days.
^ permalink raw reply
* Re: Notes on Using Git with Subprojects
From: A Large Angry SCM @ 2006-09-26 22:33 UTC (permalink / raw)
To: Shawn Pearce; +Cc: Daniel Barkalow, git
In-Reply-To: <20060926213003.GA8177@spearce.org>
Shawn Pearce wrote:
> Daniel Barkalow <barkalow@iabervon.org> wrote:
[...]
> I agree entirely.
>
> I have about 30 "subprojects" tacked into one large Git repository
> for this exact reason. In at least 5 of these cases they shouldn't
> be sharing a Git repository as by all rights they are different
> projects.
>
> What I'm doing is sort of like tacking both the Linux kernel and
> glibc into the same Git repository because you might need to change
> and bisect over updates to the system call layer. Insane, yes.
> Probably shouldn't be done; but right now that interface layer
> between several subprojects is still in flux and it makes it rather
> easy to keep everything in sync.
>
> Its annoying to perform commits to the "root project" every time the
> subproject changes. And it brings some complexity when you want to
> talk about merging that root project. But if its automated as part
> of "git commit" and "git merge" (either directly in those tools or
> by hooks users can install) then its probbaly a non issue.
So, for each subproject of a parent project, you want to record branch,
version (commit ID), and directory location. Not quite as easy to do in
a makefile but do-able.
An operation that _needs_ to change more than one project's versioned
state a time should be rare. If you have to do it often, then instead of
subprojects you probably have a partitioning of one project. A
subproject should be independent of its parent projects. A merge of a
parent project should not affect a subproject other than to pick a
particular subproject version.
Your example of the kernel and glibc is an example of sibling projects.
Each one in independent and (some) versions of each project should work
(better or worse) with the other. The root project here shouldn't really
do more than specify which version of the kernel and glibc to use.
^ permalink raw reply
* Re: [PATCH] gitweb: tree view: eliminate redundant "blob"
From: Jakub Narebski @ 2006-09-26 22:30 UTC (permalink / raw)
To: git
In-Reply-To: <efc9af$7ic$1@sea.gmane.org>
Jakub Narebski wrote:
> But some links are hidden. But there is always (or should be always)
> visible, i.e. in default link colors (blue for unvisited), and default
> decoration (underline not only on mouseover - that's mystery meat
> navigation)...
...link that is equivalent to the "invisible" link.
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: [PATCH] gitweb: tree view: eliminate redundant "blob"
From: Jakub Narebski @ 2006-09-26 22:24 UTC (permalink / raw)
To: git
In-Reply-To: <20060926213236.79160.qmail@web31815.mail.mud.yahoo.com>
Luben Tuikov wrote:
> --- Jakub Narebski <jnareb@gmail.com> wrote:
>> This is example of where forefront has it wrong. I'm all for "list" entry
>> to be link to default view, but I'm all against removing clearly marked
>> link to "plain"/"tree" view.
>>
>> And "invisible links" _especially_ if the link is not convenience only
>> (i.e. it is not provided clearly as link somewhere else) is so called
>> "mystery meat navigation" and is one of the most common mistakes in
>> web development.
>>
>> And is not as if "blob |" takes much space...
>
> I think you would agree that gitweb is quite different than what is
> commonly defined as "mystery meat navigation".
If you need to mouseover to discover that a part of webpage is link, it is
mystery meat navigation. Not in it's worst kind (it is quite obvious on
mouseover that that part is link), but still.
> Gitweb is very well thought out interface, and self-contained.
> There isn't much pondering about what and where to click, have newbies
> too.
But some links are hidden. But there is always (or should be always)
visible, i.e. in default link colors (blue for unvisited), and default
decoration (underline not only on mouseover - that's mystery meat
navigation).
> Think about the removal of the redundant "blob" and "tree" as database
> schema normalization if you will. The redundancy is so well defined that
> even applying a simple algorithm to gitweb.perl will discover it.
Redundancy is not always bad. Especially in interface.
> Either that or you can think of it as "shortening" the line.
> Wlg, suppose that I have a file called "blobname" and a directory
> called "treename":
> mode blobname blob | blame | history | raw
> mode treename tree | history
> Is equivalent to
> mode blobname blame | history | raw
> mode treename history
> For any name "blob" and any name "tree".
But then we _must_ (to not have mystery meat navigation) mark "blobname"
and "treename" _clearly_ as links, while using different visual (e.g.
different colors) to clearly distinguish between "blob" entry and "tree"
entry. And no, mode and remaining links (well, "raw") is not enough.
Which is somewhat contradictory. And makes interface somewhat inconsistent
(although removing both "blob" link for blobs and "tree" link for trees is
a step towards consistency).
> Plus the code (gitweb.perl) has less redundancy and overhead.
Redundancy in _interface_ is not always bad. We have a lot of redundancy
(mostly via hidden _convenience_ links) in gitweb interface.
Overhead? What overhead? Creating the page? It's negligible. Size of the
page? It is small enough for current net bandwidths; creation time is
bottleneck (not for "tree" view though), not the bandwidth.
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ 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