* Confused about tracking git master
From: Seth Falcon @ 2006-04-18 18:08 UTC (permalink / raw)
To: git
Hi,
I'm tracking git and somehow getting confused about how to get
updates.
To start, I did: git clone git://git.kernel.org/pub/scm/git/git.git
To get updates, I _think_ all I have to do is 'git pull'. Doing so I
get:
Unpacking 157 objects
100% (157/157) done
* refs/heads/todo: same as branch 'todo' of git://git.kernel.org/pub/scm/git/git
* refs/heads/maint: same as branch 'maint' of git://git.kernel.org/pub/scm/git/git
* refs/heads/origin: same as branch 'master' of git://git.kernel.org/pub/scm/git/git
* refs/heads/pu: does not fast forward to branch 'pu' of git://git.kernel.org/pub/scm/git/git;
not updating.
Then when I do git whatchanged, the last change is on Saturday the
15th. I'm figuring there has probably been at least one commit since
then? So I tried 'git checkout origin' and then repeated the
whatchanged call and see:
diff-tree 2855d58... (from bb99661...)
Author: Junio C Hamano <junkio@cox.net>
Date: Mon Apr 17 17:46:07 2006 -0700
Is there a step I'm missing? Or am I just misunderstanding what to
expect? Clarification on either of those would be appreciated.
Thanks,
+ seth
^ permalink raw reply
* Re: GIT_OBJECT_DIRECTORY
From: Sam Ravnborg @ 2006-04-18 18:07 UTC (permalink / raw)
To: J?rn Engel; +Cc: Linus Torvalds, git
In-Reply-To: <20060418175853.GA25688@wohnheim.fh-wedel.de>
On Tue, Apr 18, 2006 at 07:58:53PM +0200, J?rn Engel wrote:
>
> > git clone git://git.kernel.org/... foo/
>
> Is it possible for non-owners of a kernel.org account to do this?
Yes - everyone can do so.
I never use rsync myself anymore.
Sam
^ permalink raw reply
* [RESEND] [PATCH] fix gitk with lots of tags
From: Jim Radford @ 2006-04-18 18:06 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Paul Mackerras, Git Mailing List
In-Reply-To: <20060406203637.GA15009@blackbean.org>
Hi Junio,
I've gotten no reposnse from Paul on this patch[1]. If it seems ok to
you, would you mind putting it in your queue for him? I hate to see
gitk die with "argument list too long" messages. They're so 640k.
Thanks,
-Jim
[1] Maybe he judges people by the color of their IP address?
Then again, he could just be busy.
---
This fix allow gitk to be used on repositories with lots of tags. It
bypasses git-rev-parse and passes its arguments to git-rev-list
directly to avoid tcl's argument list length restrictions.
Signed-Off-By: Jim Radford <radford@blackbean.org>
diff --git a/gitk b/gitk
index 26fa79a..40672fb 100755
--- a/gitk
+++ b/gitk
@@ -17,19 +17,11 @@ proc gitdir {} {
}
proc parse_args {rargs} {
- global parsed_args
-
- if {[catch {
- set parse_args [concat --default HEAD $rargs]
- set parsed_args [split [eval exec git-rev-parse $parse_args] "\n"]
- }]} {
- # if git-rev-parse failed for some reason...
- if {$rargs == {}} {
- set rargs HEAD
- }
- set parsed_args $rargs
+ if {$rargs == {}} {
+ return HEAD
+ } else {
+ return $rargs
}
- return $parsed_args
}
proc start_rev_list {rlargs} {
^ permalink raw reply related
* Re: GIT_OBJECT_DIRECTORY
From: Jörn Engel @ 2006-04-18 17:58 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0604180822470.3701@g5.osdl.org>
On Tue, 18 April 2006 08:25:47 -0700, Linus Torvalds wrote:
> On Tue, 18 Apr 2006, Jörn Engel wrote:
> >
> > $ git clone rsync://rsync.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git foo
> > [ stored >200M of data under foo/.git/objects ]
> >
> > The above looks as if new objects are not stored under
> > /home/joern/.git, as specified by GIT_OBJECT_DIRECTORY.
>
> The "rsync" protocol really doesn't honor git rules. It's basically just a
> big recursive copy, and it will copy things from the place they were
> before.
>
> I suspect that if you had used a real git-aware protocol instead, you'd
> have been fine, ie
>
> git clone git://git.kernel.org/... foo/
Is it possible for non-owners of a kernel.org account to do this?
> would probably work. (I say "probably", because very few people likely use
> GIT_OBJECT_DIRECTORY, and it makes a lot less sense with pack-files than
> it did originally, so it's not getting any testing).
Well, .git/objects for your kernel still consumes 121M. It's not
gigabytes but I still wouldn't want too many copies of that lying
around. Right now, I already feel slightly motivated to move the
whole content-addressable idea into the kernel. It has disadvantages,
but the effect on disk- and pagecache-footprint for people like me
would come in handy.
Jörn
--
The cheapest, fastest and most reliable components of a computer
system are those that aren't there.
-- Gordon Bell, DEC labratories
^ permalink raw reply
* Re: Log message printout cleanups
From: Junio C Hamano @ 2006-04-18 16:48 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0604180854550.3701@g5.osdl.org>
Linus Torvalds <torvalds@osdl.org> writes:
> Junio, I just tested the "master" branch, and "git log --stat" doesn't
> work there.
Ahhhh.
> opt.diffopt.output_format = DIFF_FORMAT_PATCH;
> - if (opt.diffopt.output_format == DIFF_FORMAT_PATCH)
> + if (opt.diffopt.output_format == DIFF_FORMAT_PATCH ||
> + opt.diffopt.output_format == DIFF_FORMAT_DIFFSTAT)
> opt.diffopt.recursive = 1;
When pointed out in a patch from, it looks so obvious. *BLUSH*
Thanks.
^ permalink raw reply
* Re: Log message printout cleanups
From: Linus Torvalds @ 2006-04-18 16:06 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0604180827040.3701@g5.osdl.org>
On Tue, 18 Apr 2006, Linus Torvalds wrote:
>
> But this all looks very nice. I agree that "git log --stat" is a very nice
> way to look at the log, much better than "git-whatchanged". And the thing
> that has really fallen out of this all is how you can do
>
> git log --stat --full-diff drivers/pci/
>
> which git-whatchanged historically didn't support (of course, now it
> does, but you're right, the new "git log" is so nice that I'm starting to
> teach myself not to use "git whatchanged" any more).
Junio, I just tested the "master" branch, and "git log --stat" doesn't
work there. You may _think_ it works because you've tested it on the git
tree, were it looks like it is working, but it's missing setting
"recursive", so it won't actually go into any subdirectories (so it mostly
works for git itself which has most stuff in the top-level directory, but
it almost completely doesn't work for linux)
"git log -r --stat" works, so it's really just a missing that.
Something like this (this is master, not "next").
"next" actually has the same bug, but there it is hidden because "git log"
sets recursive automatically. Which may or may not be appropriate. It
might be worthwhile to fix it properly in "next" too (there the same
if (...output_format == DIFF_FORMAT_PATCH)
...recursive = 1;
is in revision.c: setup_revisions()).
Linus
----
diff --git a/git.c b/git.c
index 140ed18..f98c9ba 100644
--- a/git.c
+++ b/git.c
@@ -344,7 +344,8 @@ static int cmd_log(int argc, const char
opt.ignore_merges = 0;
if (opt.dense_combined_merges)
opt.diffopt.output_format = DIFF_FORMAT_PATCH;
- if (opt.diffopt.output_format == DIFF_FORMAT_PATCH)
+ if (opt.diffopt.output_format == DIFF_FORMAT_PATCH ||
+ opt.diffopt.output_format == DIFF_FORMAT_DIFFSTAT)
opt.diffopt.recursive = 1;
if (!full_diff && rev.prune_data)
diff_tree_setup_paths(rev.prune_data, &opt.diffopt);
^ permalink raw reply related
* Re: Log message printout cleanups
From: Linus Torvalds @ 2006-04-18 15:37 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vd5ffig70.fsf@assigned-by-dhcp.cox.net>
On Mon, 17 Apr 2006, Junio C Hamano wrote:
>
> I think this does what both of us want. One thing I noticed is
> that log-tree-diff-flush does "---\n" under --patch-with-stat
> but not under --stat; I matched that here.
Looks very nice now. Thanks.
My only slight complaint is that I think it should be possible to do
git log --cc --stat
to get both patches and stat, but that doesn't work. You have to write
git log --cc --patch-with-stat
to get both ;/
But that's just a small (and unimportant) detail.
Here's another really small detail: with merges, there's two newlines
between the diffstat and the diff. That bug doesn't show up with regular
commits.
But this all looks very nice. I agree that "git log --stat" is a very nice
way to look at the log, much better than "git-whatchanged". And the thing
that has really fallen out of this all is how you can do
git log --stat --full-diff drivers/pci/
which git-whatchanged historically didn't support (of course, now it
does, but you're right, the new "git log" is so nice that I'm starting to
teach myself not to use "git whatchanged" any more).
Linus
^ permalink raw reply
* Re: GIT_OBJECT_DIRECTORY
From: Linus Torvalds @ 2006-04-18 15:25 UTC (permalink / raw)
To: Jörn Engel; +Cc: git
In-Reply-To: <20060418133847.GC4720@wohnheim.fh-wedel.de>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 805 bytes --]
On Tue, 18 Apr 2006, Jörn Engel wrote:
>
> $ git clone rsync://rsync.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git foo
> [ stored >200M of data under foo/.git/objects ]
>
> The above looks as if new objects are not stored under
> /home/joern/.git, as specified by GIT_OBJECT_DIRECTORY.
The "rsync" protocol really doesn't honor git rules. It's basically just a
big recursive copy, and it will copy things from the place they were
before.
I suspect that if you had used a real git-aware protocol instead, you'd
have been fine, ie
git clone git://git.kernel.org/... foo/
would probably work. (I say "probably", because very few people likely use
GIT_OBJECT_DIRECTORY, and it makes a lot less sense with pack-files than
it did originally, so it's not getting any testing).
Linus
^ permalink raw reply
* Re: [PATCH] git-rev-list: fix --header
From: Johannes Schindelin @ 2006-04-18 14:50 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vhd4rlw0m.fsf@assigned-by-dhcp.cox.net>
Hi,
On Mon, 17 Apr 2006, Junio C Hamano wrote:
> Still undecided. As you say it is an easy change, so I'd rather
> leave the behaviour as before for now.
Okay, I'd say go with the shorter (your) solution.
Ciao,
Dscho
^ permalink raw reply
* Re: GIT_OBJECT_DIRECTORY
From: Jörn Engel @ 2006-04-18 14:16 UTC (permalink / raw)
To: linux; +Cc: git
In-Reply-To: <20060418141050.7941.qmail@science.horizon.com>
On Tue, 18 April 2006 10:10:50 -0400, linux@horizon.com wrote:
>
> Just to cover the obvious "is it plugged in?" questions, did you
> also "export GIT_OBJECT_DIRECTORY"? That is, what does
> env | grep GIT_OBJECT_DIRECTORY
> produce?
$ env | grep GIT_OBJECT_DIRECTORY
GIT_OBJECT_DIRECTORY=/home/joern/.git
And maybe for the record, I just the debian unstable package:
$ git --version
git version 1.2.1
Jörn
--
Anything that can go wrong, will.
-- Finagle's Law
^ permalink raw reply
* Re: GIT_OBJECT_DIRECTORY
From: linux @ 2006-04-18 14:10 UTC (permalink / raw)
To: joern; +Cc: git
Just to cover the obvious "is it plugged in?" questions, did you
also "export GIT_OBJECT_DIRECTORY"? That is, what does
env | grep GIT_OBJECT_DIRECTORY
produce?
^ permalink raw reply
* GIT_OBJECT_DIRECTORY
From: Jörn Engel @ 2006-04-18 13:38 UTC (permalink / raw)
To: git
Hi!
I recently noticed GIT_OBJECT_DIRECTORY in the git manpage and wanted
to play with it. But it looks as if it doesn't work, the
documentation is wrong/insufficient or I can't properly read the
documentation. So let me figure out, which one it is.
$ set | grep GIT_OBJECT_DIRECTORY
GIT_OBJECT_DIRECTORY=/home/joern/.git
$ ls -l /home/joern/.git
total 288
drwxrwxr-x 2 joern joern 4096 Apr 16 01:22 0f
[...]
$ git clone rsync://rsync.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git foo
[ stored >200M of data under foo/.git/objects ]
The above looks as if new objects are not stored under
/home/joern/.git, as specified by GIT_OBJECT_DIRECTORY. The manpage
tells me:
GIT_OBJECT_DIRECTORY
If the object storage directory is specified via this environ-
ment variable then the sha1 directories are created underneath -
otherwise the default $GIT_DIR/objects directory is used.
And I would interpret this as "store all new objects under
/home/joern/.git". So far, things don't seem to imply me being too
stupid. What went wrong?
Jörn
--
Why do musicians compose symphonies and poets write poems?
They do it because life wouldn't have any meaning for them if they didn't.
That's why I draw cartoons. It's my life.
-- Charles Shultz
^ permalink raw reply
* Re: [PATCH 1/7] cleanups: Fix resource leak and buffer overrun in daemon.c
From: Serge E. Hallyn @ 2006-04-18 13:11 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vu08rkhey.fsf@assigned-by-dhcp.cox.net>
Quoting Junio C Hamano (junkio@cox.net):
> "Serge E. Hallyn" <serue@us.ibm.com> writes:
>
> > Address two reports from an automatic code analyzer:
> >
> > 1. In logreport, it is possible to write \0 one
> > character past the end of buf[].
>
> I am perhaps slower than I usually am today, but it seems to me
> that the code caps msglen to (maxlen-1) and then adds that to
> buflen.
>
> Now, maxlen is (sizeof(buf)-buflen-1), so that means after
> the "buflen += msglen" happens, buflen is at most:
>
> buflen + (sizeof(buf)-buflen-1) - 1
> = sizeof(buf) - 2
>
> And then "buf[buflen++] = '\n'; buf[buflen] = '\0'" happens.
> '\n' is written at sizeof(buf)-2 (or lower index than that) and
> '\0' is written at sizeof(buf)-1 (or lower). I am unsure how it
> steps beyond the end...
Argh, I had to pull out a sheet of paper, but you are right. I
misread, and the warning must be about the case where the
snprint "[%ld] " prints out 1023 characters.
> > 2. In socksetup, socklist can be leaked when returning
> > if set_reuse_addr(). Note: dunno why this case returns...
>
> I am not sure why this part returns either. It appears to me
> that it should just keep going just like the cases where
> bind/listen fails.
Then perhaps the following is more appropriate.
thanks,
-serge
From: Serge E. Hallyn <serue@us.ibm.com>
Subject: [PATCH] socksetup: don't return on set_reuse_addr() error
The set_reuse_addr() error case was the only error case in
socklist() where we returned rather than continued. Not sure
why. Either we must free the socklist, or continue. This patch
continues on error.
Signed-off-by: Serge E. Hallyn <serue@us.ibm.com>
---
daemon.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
b589029e3187eed51c3fe6a2715f51bea2159786
diff --git a/daemon.c b/daemon.c
index a1ccda3..776749e 100644
--- a/daemon.c
+++ b/daemon.c
@@ -535,7 +535,7 @@ static int socksetup(int port, int **soc
if (set_reuse_addr(sockfd)) {
close(sockfd);
- return 0; /* not fatal */
+ continue;
}
if (bind(sockfd, ai->ai_addr, ai->ai_addrlen) < 0) {
--
1.2.5
^ permalink raw reply related
* Re: [PATCH] Handle branch names with slashes
From: Karl Hasselström @ 2006-04-18 11:07 UTC (permalink / raw)
To: Yann Dirson; +Cc: Catalin Marinas, git
In-Reply-To: <20060412191655.GD27397@nowhere.earth>
On 2006-04-12 21:16:55 +0200, Yann Dirson wrote:
> Is this still being worked on?
I haven't worked any more on the slashes-in-branch-names patch, but I
have been using it myself, and it works for me. Getting that fancy new
test suite to excercise it would be a really good next step . . .
--
Karl Hasselström, kha@treskal.com
www.treskal.com/kalle
^ permalink raw reply
* [BUG] gitk draws a wrong line
From: Uwe Zeisberger @ 2006-04-18 10:40 UTC (permalink / raw)
To: git
Hallo,
I'm using 1.3.0.rc4.g2855d in Linus Linux tree. When doing
$ gitk v2.6.16..v2.6.17-rc1
and then going to commit 10c2df65060e1ab57b2f75e0749de0ee9b8f4810,
I see a small superfluous line between the two commits under 10c2df.
But still worse, if I select the line going down from 10c2df and then
select it's parent (i.e c76b6b) I get a big line ending in the commit
descriptions and four lines ending in midair.
See screenshots at
http://www.informatik.uni-freiburg.de/~zeisberg/bug-gitk/
Best regards
Uwe
--
Uwe Zeisberger
cat /*dev/null; echo 'Hello World!';
cat > /dev/null <<*/
() { } int main() { printf("Hello World!\n");}
/* */
^ permalink raw reply
* Re: [PATCH] git-svnimport symlink support
From: smurf @ 2006-04-18 9:11 UTC (permalink / raw)
To: Junio C Hamano
Cc: Karl Hasselström, Martin Langhoff, Herbert Valerio Riedel,
git
In-Reply-To: <7v3bgcngqc.fsf@assigned-by-dhcp.cox.net>
[-- Attachment #1: Type: text/plain, Size: 154 bytes --]
Hi,
Junio C Hamano:
> Karl, Martin, Smurf, Comments?
OK with me.
--
Matthias Urlichs | {M:U} IT Design @ m-u-it.de | smurf@smurf.noris.de
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 191 bytes --]
^ permalink raw reply
* What's in git.git
From: Junio C Hamano @ 2006-04-18 8:44 UTC (permalink / raw)
To: git
In-Reply-To: <7vodz4tx4s.fsf@assigned-by-dhcp.cox.net>
* The 'master' branch has these since the last announcement.
- Update xdiff (Davide Libenzi)
- Add diff --stat and --patch-with-stat (Johannes Schindelin)
- Miscellaneous fixes (A Large Angry SCM, Linus, Serge
E. Hallyn, Yann Dirson, me)
- Fix rev-list --boundary (me)
- Update gitk (Paul Mackerras)
* The 'next' branch, in addition, has these.
- Common option parsing for "git log --diff" and friends (Linus)
- Log message printout cleanups (Linus)
- Log/show/whatchanged commands are now built-in (Linus and me)
- Similarity fingerprint (Geert Bosch)
- Define "log --stat" to be "stat with first parent" (Linus and me)
The commits on the lt/logopt branch (part of "next" branch) are
proving to be more stable and safe enough to use. It cleans up
the code quote a lot,
I'm really resisting the temptation to merge these before 1.3.0.
There is a slight output format change from diff-tree --pretty;
while I would not expect no Porcelains is affected in practice,
technically this is a backward incompatible change, so...
Anyway, they will be merged immediately after the big release.
^ permalink raw reply
* Re: Log message printout cleanups
From: Junio C Hamano @ 2006-04-18 5:52 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0604171751540.3701@g5.osdl.org>
Linus Torvalds <torvalds@osdl.org> writes:
> There's actually something _wrong_ with "git log --stat".
>
> What happens is that "git log" will enable "rev.combine_merges" by
> default, and that means that together with "--stat" ignoring merges by
> default, it will _instead_ generate a "--cc" diff for that merge.
>
> I'll leave that up to you, I'm getting pretty fed up with "git log" right
> now ;)
The primary problem is that the code in "next" was before the
"fancy diffstat for combined" work by Johannes; it punts and
always shows the patch output even when stat is asked for.
I think this does what both of us want. One thing I noticed is
that log-tree-diff-flush does "---\n" under --patch-with-stat
but not under --stat; I matched that here.
-- >8 --
combine-diff: show diffstat with the first parent.
Even under combine-diff, asking for stat (either with --stat or
--patch-with-stat) gives you diffstat for the first parent.
While the combined patch is useful to highlight the complexity
and interaction of the parts touched by all branches when
reviewing a merge commit, diffstat is a tool to assess the
extent of damage the merge brings in, and showing stat with the
first parent is more sensible than clever per-parent diffstat.
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
combine-diff.c | 24 +++++++++++++++++++-----
1 files changed, 19 insertions(+), 5 deletions(-)
diff --git a/combine-diff.c b/combine-diff.c
index aef9006..27f6f57 100644
--- a/combine-diff.c
+++ b/combine-diff.c
@@ -831,10 +831,11 @@ void show_combined_diff(struct combine_d
case DIFF_FORMAT_NAME:
show_raw_diff(p, num_parent, rev);
return;
-
- default:
case DIFF_FORMAT_PATCH:
show_patch_diff(p, num_parent, dense, rev);
+ return;
+ default:
+ return;
}
}
@@ -847,10 +848,13 @@ void diff_tree_combined_merge(const unsi
struct commit_list *parents;
struct combine_diff_path *p, *paths = NULL;
int num_parent, i, num_paths;
+ int do_diffstat;
+ do_diffstat = (opt->output_format == DIFF_FORMAT_DIFFSTAT ||
+ opt->with_stat);
diffopts = *opt;
- diffopts.output_format = DIFF_FORMAT_NO_OUTPUT;
diffopts.with_raw = 0;
+ diffopts.with_stat = 0;
diffopts.recursive = 1;
/* count parents */
@@ -864,14 +868,24 @@ void diff_tree_combined_merge(const unsi
parents;
parents = parents->next, i++) {
struct commit *parent = parents->item;
+ /* show stat against the first parent even
+ * when doing combined diff.
+ */
+ if (i == 0 && do_diffstat)
+ diffopts.output_format = DIFF_FORMAT_DIFFSTAT;
+ else
+ diffopts.output_format = DIFF_FORMAT_NO_OUTPUT;
diff_tree_sha1(parent->object.sha1, commit->object.sha1, "",
&diffopts);
diffcore_std(&diffopts);
paths = intersect_paths(paths, i, num_parent);
- if (diffopts.with_stat && rev->loginfo)
- show_log(rev, rev->loginfo, "---\n");
+ if (do_diffstat && rev->loginfo)
+ show_log(rev, rev->loginfo,
+ opt->with_stat ? "---\n" : "\n");
diff_flush(&diffopts);
+ if (opt->with_stat)
+ putchar('\n');
}
/* find out surviving paths */
^ permalink raw reply related
* Re: Log message printout cleanups
From: Linus Torvalds @ 2006-04-18 0:57 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Johannes Schindelin, git
In-Reply-To: <7v7j5nk9bf.fsf@assigned-by-dhcp.cox.net>
On Mon, 17 Apr 2006, Junio C Hamano wrote:
>
> These days I find myself running "git log --stat" more often
> than "git whatchanged"; it looks so much nicer ;-).
>
> Thanks for a job well done.
There's actually something _wrong_ with "git log --stat".
What happens is that "git log" will enable "rev.combine_merges" by
default, and that means that together with "--stat" ignoring merges by
default, it will _instead_ generate a "--cc" diff for that merge.
I think that behaviour was introduced by the "--stat" code by Dscho, and
not by my rewrite.
You can see it on the kernel archive on commit 88dd9c16, for example:
git log --stat 88dd9c16
will make it pretty obvious what I'm talking about.
I still haven't looked a lot at what the diffstat code does, so I don't
know what the obvious fix is. Maybe setting "ignore_merges". And maybe
just making the diffstat thing do the right thing for merges.
I'll leave that up to you, I'm getting pretty fed up with "git log" right
now ;)
Linus
^ permalink raw reply
* Re: Log message printout cleanups
From: Linus Torvalds @ 2006-04-18 0:43 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Johannes Schindelin
In-Reply-To: <7vejzvka09.fsf@assigned-by-dhcp.cox.net>
On Mon, 17 Apr 2006, Junio C Hamano wrote:
>
> Showing stat from the first parent makes --stat inconsistent
> from what the "fake diff" shows, but I think it is a sensible
> thing to do.
It might actually be even more than sensible: it's a huge hint especially
for users of "--cc" (or even --combined) that the diff we show really
isn't all there is to the merge. So having the "full" diffstat is not just
usually what you want to see, it's probably also a really good hint for
people who otherwise might not realize that our combined diffs have
skipped all the common parts.
Btw, I just noticed that I broke "--pretty=oneline" AGAIN. That thing is
very special, since pretty_print_commit() will _remove_ the newline at the
end of it, so we want to have an extra separator between the things.
I added a honking big comment this time, so that (a) I don't forget this
_again_ (I broke "oneline" several times during this printout cleanup),
and so that people can understand _why_ the code does what it does.
Now, arguably the alternate fix is to always have the '\n' at the end in
pretty-print-commit, but git-rev-list depends on the current behaviour
(but we could have git-rev-list remove it, whatever).
With the big comment, the code hopefully doesn't get broken again. And now
things like
git log --pretty=oneline --cc --patch-with-stat
works (even if that is admittedly a totally insane combination: if you
want the patch, having the "oneline" log format is just crazy, but hey,
it _works_. Even insane people are people).
Linus
---
diff --git a/log-tree.c b/log-tree.c
index c0a4432..9634c46 100644
--- a/log-tree.c
+++ b/log-tree.c
@@ -10,6 +9,7 @@ void show_log(struct rev_info *opt, stru
struct commit *commit = log->commit, *parent = log->parent;
int abbrev = opt->diffopt.abbrev;
int abbrev_commit = opt->abbrev_commit ? opt->abbrev : 40;
+ const char *extra;
int len;
opt->loginfo = NULL;
@@ -19,8 +19,17 @@ void show_log(struct rev_info *opt, stru
}
/*
- * Whitespace between commit messages, unless we are oneline
+ * The "oneline" format has several special cases:
+ * - The pretty-printed commit lacks a newline at the end
+ * of the buffer, but we do want to make sure that we
+ * have a newline there. If the separator isn't already
+ * a newline, add an extra one.
+ * - unlike other log messages, the one-line format does
+ * not have an empty line between entries.
*/
+ extra = "";
+ if (*sep != '\n' && opt->commit_format == CMIT_FMT_ONELINE)
+ extra = "\n";
if (opt->shown_one && opt->commit_format != CMIT_FMT_ONELINE)
putchar('\n');
opt->shown_one = 1;
@@ -39,7 +48,7 @@ void show_log(struct rev_info *opt, stru
* And then the pretty-printed message itself
*/
len = pretty_print_commit(opt->commit_format, commit, ~0u, this_header, sizeof(this_header), abbrev);
- printf("%s%s", this_header, sep);
+ printf("%s%s%s", this_header, extra, sep);
}
int log_tree_diff_flush(struct rev_info *opt)
^ permalink raw reply related
* Re: Log message printout cleanups
From: Junio C Hamano @ 2006-04-18 0:37 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <7vejzvka09.fsf@assigned-by-dhcp.cox.net>
Linus Torvalds <torvalds@osdl.org> writes:
> I realize that Dscho has been looking at some much "fancier" merge
> diffstats, but I really do believe that the "what got merged" difference
> to the original branch (ie parent 1) is what you want in practice.
These days I find myself running "git log --stat" more often
than "git whatchanged"; it looks so much nicer ;-).
Thanks for a job well done.
^ permalink raw reply
* Academic Qualifications available from prestigious NON-ACCREDITED universities
From: Spencer Morris @ 2006-04-18 2:28 UTC (permalink / raw)
To: git
NO ONE is turned down.
According to the U.S. Census Bureau, with the following degrees,
here's how much you can expect to make in your lifetime:
High School Diploma: $1,100,000
Bachelor's Degree: $2,100,000
Master's Degree: $2,500,000
Doctorate: $4,400,000
You Need a Better Degree, and we can Help!
Obtain degrees from Prestigious non-accredited
Universities based on you life experience.
NO ONE is turned down.
Call Now 7 days a week.
"1-718-504-5376"
^ permalink raw reply
* Re: Log message printout cleanups
From: Junio C Hamano @ 2006-04-18 0:22 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git, Johannes Schindelin
In-Reply-To: <Pine.LNX.4.64.0604171647380.3701@g5.osdl.org>
Linus Torvalds <torvalds@osdl.org> writes:
> I suspect it would be better to just have the _first_
> diffstat, and always make the merge diffstat be the one for "result
> against first parent".
>
> I realize that Dscho has been looking at some much "fancier" merge
> diffstats, but I really do believe that the "what got merged" difference
> to the original branch (ie parent 1) is what you want in practice.
>
> Anyway, that's a totally separate issue, I'll let you guys fight that out.
I agree with your opinion 100% from usability point of view,
although I admit one of the fancier format was suggested by me.
Showing stat from the first parent makes --stat inconsistent
from what the "fake diff" shows, but I think it is a sensible
thing to do. The purpose of two are different in that (1) stat
is a way to see the extent of damage to what you had before you
merged, and (2) --cc is a way to see how complex the merge was,
to spot obvious merge mistakes and sanity check the merge at the
contents level.
^ permalink raw reply
* Re: Log message printout cleanups
From: Linus Torvalds @ 2006-04-17 23:59 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Git Mailing List, Johannes Schindelin
In-Reply-To: <7vodyzkehq.fsf@assigned-by-dhcp.cox.net>
On Mon, 17 Apr 2006, Junio C Hamano wrote:
>
> I like the new cmd_log_wc() loop very much; I was planning to do
> this myself, but I was too slow ;-).
>
> Thanks.
Here's a further patch on top of the previous one with cosmetic
improvements (no "real" code changes, just trivial updates):
- it gets the "---" before a diffstat right, including for the combined
merge case. Righ now the logic is that we always use "---" when we have
a diffstat, and an empty line otherwise. That's how I visually prefer
it, but hey, it can be tweaked later.
- I made "diff --cc/combined" add the "---/+++" header lines too. The
thing won't be mistaken for a valid diff, since the "@@" lines have too
many "@" characters (three or more), but it just makes it visually
match a real diff, which at least to me makes a big difference in
readability. Without them, it just looks very "wrong".
I guess I should have taken the filename from each individual entry
(and had one "---" file per parent), but I didn't even bother to try to
see how that works, so this was the simple thing.
With this, doing a
git log --cc --patch-with-stat
looks quite readable, I think. The only nagging issue - as far as I'm
concerned - is that diffstats for merges are pretty questionable the way
they are done now. I suspect it would be better to just have the _first_
diffstat, and always make the merge diffstat be the one for "result
against first parent".
I realize that Dscho has been looking at some much "fancier" merge
diffstats, but I really do believe that the "what got merged" difference
to the original branch (ie parent 1) is what you want in practice.
Anyway, that's a totally separate issue, I'll let you guys fight that out.
Linus
---
diff --git a/combine-diff.c b/combine-diff.c
index b4fa9c9..aef9006 100644
--- a/combine-diff.c
+++ b/combine-diff.c
@@ -585,6 +585,16 @@ static void reuse_combine_diff(struct sl
sline->p_lno[i] = sline->p_lno[j];
}
+static void dump_quoted_path(const char *prefix, const char *path)
+{
+ fputs(prefix, stdout);
+ if (quote_c_style(path, NULL, NULL, 0))
+ quote_c_style(path, NULL, stdout, 0);
+ else
+ printf("%s", path);
+ putchar('\n');
+}
+
static int show_patch_diff(struct combine_diff_path *elem, int num_parent,
int dense, struct rev_info *rev)
{
@@ -692,12 +702,7 @@ static int show_patch_diff(struct combin
if (rev->loginfo)
show_log(rev, rev->loginfo, "\n");
- printf("diff --%s ", dense ? "cc" : "combined");
- if (quote_c_style(elem->path, NULL, NULL, 0))
- quote_c_style(elem->path, NULL, stdout, 0);
- else
- printf("%s", elem->path);
- putchar('\n');
+ dump_quoted_path(dense ? "diff --cc " : "diff --combined ", elem->path);
printf("index ");
for (i = 0; i < num_parent; i++) {
abb = find_unique_abbrev(elem->parent[i].sha1,
@@ -728,6 +733,8 @@ static int show_patch_diff(struct combin
}
putchar('\n');
}
+ dump_quoted_path("--- a/", elem->path);
+ dump_quoted_path("+++ b/", elem->path);
dump_sline(sline, cnt, num_parent);
}
free(result);
@@ -861,6 +868,9 @@ void diff_tree_combined_merge(const unsi
&diffopts);
diffcore_std(&diffopts);
paths = intersect_paths(paths, i, num_parent);
+
+ if (diffopts.with_stat && rev->loginfo)
+ show_log(rev, rev->loginfo, "---\n");
diff_flush(&diffopts);
}
diff --git a/log-tree.c b/log-tree.c
index c0a4432..9e54164 100644
--- a/log-tree.c
+++ b/log-tree.c
@@ -1,4 +1,3 @@
-
#include "cache.h"
#include "diff.h"
#include "commit.h"
@@ -55,7 +54,7 @@ int log_tree_diff_flush(struct rev_info
}
if (opt->loginfo && !opt->no_commit_id)
- show_log(opt, opt->loginfo, "\n");
+ show_log(opt, opt->loginfo, opt->diffopt.with_stat ? "---\n" : "\n");
diff_flush(&opt->diffopt);
return 1;
}
^ permalink raw reply related
* Re: Log message printout cleanups
From: Junio C Hamano @ 2006-04-17 22:45 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0604171149330.3701@g5.osdl.org>
Linus Torvalds <torvalds@osdl.org> writes:
> On Sun, 16 Apr 2006, Junio C Hamano wrote:
>>
>> In the mid-term, I am hoping we can drop the generate_header()
>> callchain _and_ the custom code that formats commit log in-core,
>> found in cmd_log_wc().
>
> Ok, this was nastier than expected, just because the dependencies between
> the different log-printing stuff were absolutely _everywhere_, but here's
> a patch that does exactly that.
I like the new cmd_log_wc() loop very much; I was planning to do
this myself, but I was too slow ;-).
Thanks.
^ 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