* Re: Bizarre missing changes (git bug?)
From: Roman Zippel @ 2008-07-28 0:00 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Tim Harper, git
In-Reply-To: <alpine.LFD.1.10.0807271613440.3486@nehalem.linux-foundation.org>
Hi,
On Sun, 27 Jul 2008, Linus Torvalds wrote:
> > Why are you dismissing what I wrote without even giving it a second
> > thought? I didn't bother with the initial example, because it's so
> > simple, that it's no real challenge.
>
> Did you try it? It really shouldn't be any simpler than anything else. And
Of course I did:
$ git log --parents --name-only --full-history lib/vsprintf.c | grep -e ^commit | wc -l
5929
This is same amount of commits as for gitk.
$ /usr/bin/time git log --parents --name-only --full-history lib/vsprintf.c | grep -e ^commit -e ^lib | /usr/bin/time ruby ../filter.rb
3.08user 0.14system 0:03.54elapsed 91%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (0major+48230minor)pagefaults 0swaps
20
["72fd4a35a824331d7a0f4168d7576502d95d34b3", ["0a6047eef1c465c38aacfbdab193161b3f0cd144"]]
["06b2a76d25d3cfbd14680021c1d356c91be6904e", ["96e3e18eed3b48f6d4377dee0326a106e8a04569"]]
["1da177e4c3f41524e886b7f1b8a0c1fc7321cac2", []]
["e905914f96e11862b130dd229f73045dad9a34e8", ["f796937a062c7aeb44cd0e75e1586c8543634a7d"]]
["4e57b6817880946a3a78d5d8cad1ace363f7e449", ["8032230694ec56c168a1404c67a54d281536cbed"]]
["4f9d5f4a353440f2265781bfa641587964901861", ["9b706aee7d92d6ac3002547aea12e3eaa0a750ae"]]
["0a6047eef1c465c38aacfbdab193161b3f0cd144", ["e905914f96e11862b130dd229f73045dad9a34e8"]]
["c6b40d16d1cfa1a01158049bb887a9bbe48ef7ba", ["11443ec7d9286dd25663516436a14edfb5f43857"]]
["ea6f3281a145d16ed53e88b0627f78d5cde6068f", ["72fd4a35a824331d7a0f4168d7576502d95d34b3"]]
["11443ec7d9286dd25663516436a14edfb5f43857", ["ea6f3281a145d16ed53e88b0627f78d5cde6068f"]]
["b39a734097d5095d63eb9c709a6aaf965633bb01", ["c6b40d16d1cfa1a01158049bb887a9bbe48ef7ba"]]
["78a8bf69b32980879975f7e31d30386c50bfe851", ["0f9bfa569d46f2346a53a940b2b9e49a38635732"]]
["4d8a743cdd2690c0bc8d1b8cbd02cffb1ead849f", ["78a8bf69b32980879975f7e31d30386c50bfe851"]]
["0fe1ef24f7bd0020f29ffe287dfdb9ead33ca0b2", ["4d8a743cdd2690c0bc8d1b8cbd02cffb1ead849f"]]
["9b706aee7d92d6ac3002547aea12e3eaa0a750ae", ["06b2a76d25d3cfbd14680021c1d356c91be6904e"]]
["0f9bfa569d46f2346a53a940b2b9e49a38635732", ["4f9d5f4a353440f2265781bfa641587964901861"]]
["4277eedd7908a0ca8b66fad46ee76b0ad96e6ef2", ["b39a734097d5095d63eb9c709a6aaf965633bb01"]]
["8032230694ec56c168a1404c67a54d281536cbed", ["1da177e4c3f41524e886b7f1b8a0c1fc7321cac2"]]
["f796937a062c7aeb44cd0e75e1586c8543634a7d", ["4e57b6817880946a3a78d5d8cad1ace363f7e449"]]
["96e3e18eed3b48f6d4377dee0326a106e8a04569", ["4277eedd7908a0ca8b66fad46ee76b0ad96e6ef2"]]
0.12user 0.02system 0:03.64elapsed 3%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (0major+7252minor)pagefaults 0swaps
These are the same 20 commits (with parents) from a simple git-log.
> I dismissed what you wrote because the example you _did_ state was about
> something else entirely (ie apparently some giggle bug that simplifies
> things incorrectly).
I'm trying to get back things to the topic and it's not just giggle, every
tool presents a different version of the history.
> > What did I do wrong that you rebuff me based on this secondary problem
> > (which I'm quite aware of, because it was me who mentioned in first place)
> > and giving the primary problem (which is the missing history) no
> > attention?
>
> It's not missing history. It's all there in --full-history. The default is
> to give a reasonable simplification, and I told you what the
> simplification was, and it's perfectly conceptually fine - AND IT IS MUCH
> MORE EFFICIENT than the alternatives.
>
> So I'm not seeing your point what-so-ever.
That's why I gave you an alternative example, where history is missing.
> - with full-history, you have it all, but it's useless in practice
Could you please specify which full-history you mean, gitk --full-history
or git-log --full-history?
> - without full-history, it's useful in practice
>From a VCS I would still expect nevertheless to present a correct
history not some approximation.
bye, Roman
^ permalink raw reply
* Re: Bizarre missing changes (git bug?)
From: Martin Langhoff @ 2008-07-27 23:25 UTC (permalink / raw)
To: Roman Zippel; +Cc: Linus Torvalds, Tim Harper, git
In-Reply-To: <Pine.LNX.4.64.0807272101470.6791@localhost.localdomain>
On Mon, Jul 28, 2008 at 11:14 AM, Roman Zippel <zippel@linux-m68k.org> wrote:
> Why are you dismissing what I wrote without even giving it a second
> thought? I didn't bother with the initial example, because it's so
> simple, that it's no real challenge.
I can't speak for anyone else, but you do have to keep in mind that a
solution to this has to be rather fast - and I mean fast in git terms,
not in scripting-language-fast terms.
That you can do it Ruby - and I may be able to do it Perl - has little
bearing on what can be done inside the git log machinery with a small
performance penalty.
cheers,
m
--
martin.langhoff@gmail.com
martin@laptop.org -- School Server Architect
- ask interesting questions
- don't get distracted with shiny stuff - working code first
- http://wiki.laptop.org/go/User:Martinlanghoff
^ permalink raw reply
* Re: Bizarre missing changes (git bug?)
From: Linus Torvalds @ 2008-07-27 23:18 UTC (permalink / raw)
To: Roman Zippel; +Cc: Tim Harper, git
In-Reply-To: <Pine.LNX.4.64.0807272101470.6791@localhost.localdomain>
On Mon, 28 Jul 2008, Roman Zippel wrote:
>
> Why are you dismissing what I wrote without even giving it a second
> thought? I didn't bother with the initial example, because it's so
> simple, that it's no real challenge.
Did you try it? It really shouldn't be any simpler than anything else. And
I dismissed what you wrote because the example you _did_ state was about
something else entirely (ie apparently some giggle bug that simplifies
things incorrectly).
> What did I do wrong that you rebuff me based on this secondary problem
> (which I'm quite aware of, because it was me who mentioned in first place)
> and giving the primary problem (which is the missing history) no
> attention?
It's not missing history. It's all there in --full-history. The default is
to give a reasonable simplification, and I told you what the
simplification was, and it's perfectly conceptually fine - AND IT IS MUCH
MORE EFFICIENT than the alternatives.
So I'm not seeing your point what-so-ever.
My point is:
- with full-history, you have it all, but it's useless in practice
- without full-history, it's useful in practice
You never gave any examples otherwise.
Linus
^ permalink raw reply
* Re: git-scm.com
From: Martin Langhoff @ 2008-07-27 23:19 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Petr Baudis, Scott Chacon, git
In-Reply-To: <7vd4kzyoj1.fsf@gitster.siamese.dyndns.org>
On Mon, Jul 28, 2008 at 10:01 AM, Junio C Hamano <gitster@pobox.com> wrote:
> By the way, earlier Scott gave as explanation why he and others around
> GitHub, people who are not very visible on this list, are not interacting
> with us very much --- because they are not "C coders".
Well, I'm not a C coder either ;-) -- plenty of the large contributors
do their work in Perl Python and shell. Granted, I am not very active
lately, but that's because I'm busy on non-git-related (but
git-using!) projects.
And the choice of language has nothing to do with helping people
around. If they care about getting recommendations from list regulars,
anyway. Maintaining a great user-facing website might be their way of
engaging and interacting with us.
cheers,
martin
--
martin.langhoff@gmail.com
martin@laptop.org -- School Server Architect
- ask interesting questions
- don't get distracted with shiny stuff - working code first
- http://wiki.laptop.org/go/User:Martinlanghoff
^ permalink raw reply
* Re: Bizarre missing changes (git bug?)
From: Roman Zippel @ 2008-07-27 23:14 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Tim Harper, git
In-Reply-To: <alpine.LFD.1.10.0807271144520.3486@nehalem.linux-foundation.org>
Hi,
On Sun, 27 Jul 2008, Linus Torvalds wrote:
> > > > Is there a way to change that default?
> > >
> > > Use an alias or something.
> >
> > This doesn't help with the graphical front ends and they only use what git
> > gives them.
>
> And the graphical front-ends is exactly why --full-history cannot be the
> default.
If you mean current gitk style --full-history I agree, the problem is
still that git is hiding too much history with the simplified history...
> > Let's take a different example.
>
> No, let's not.
>
> Unless you can solve that _one_ example efficiently, nothing else matters.
>
> The above example is all you ever need. Make that one work right (and
> efficiently), and everything is fine.
>
> And no, some random ruby code doesn't make any difference what-so-ever.
> There are efficiency constraints here that make any ruby solution be
> unrealistic to begin with.
Why are you dismissing what I wrote without even giving it a second
thought? I didn't bother with the initial example, because it's so
simple, that it's no real challenge.
Did I say anywhere it had to be done in ruby? All I tried was to
demonstrate a possible algorithm to solve the problem. I did time the
execution and compared to the time it took to extract the history it
wasn't significant for such a simple script.
What did I do wrong that you rebuff me based on this secondary problem
(which I'm quite aware of, because it was me who mentioned in first place)
and giving the primary problem (which is the missing history) no
attention?
If you had any questions, I'd be happy to answer them. If you think that
the demonstrated algorithm doesn't work, I'd be glad to know why. If the
algorithm might work, any hint what could be do done to try it for real,
would be great. But I don't get any of this. Why?
bye, Roman
^ permalink raw reply
* Re: git-scm.com
From: Junio C Hamano @ 2008-07-27 22:01 UTC (permalink / raw)
To: Petr Baudis; +Cc: Scott Chacon, git
In-Reply-To: <7v3alv2n46.fsf@gitster.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> Petr Baudis <pasky@suse.cz> writes:
> ...
>> The point here is that the list is awfully long and also can contain
>> a lot of duplicates or people with broken unicode, etc. - it gets hard
>> to maintain, and it makes the about page too long. I would be of course
>> fine with a tiny link at the bottom "(show all contributors)".
>
> Your "incentive to move up" argument suggests otherwise. Even if it takes
> efforts to maintain on somebody's part, it is worth to be inclusive, *IF*
> the purpose of that bottom list is to give credits to people.
>
> The list on the site originally was not utilizing .mailmap and I asked
> Scott to use it to merge duplicate entries, which he did. People whose
> names are misspelled and/or split will now have incentive to tell Scott
> about the problem so that they can clean up *their* own names, and Scott
> can help maintaining .mailmap and feed the changes to me.
>
> This is my ulterior motive behind this suggestion; I can outsource the
> maintenance of .mailmap to people who care about it more than myself.
By the way, earlier Scott gave as explanation why he and others around
GitHub, people who are not very visible on this list, are not interacting
with us very much --- because they are not "C coders".
But maintenance of .mailmap (and Documentation/ area, too, of course) is a
good example of how involvement from non "C coders" would be a helpful and
healthy thing to have in the development process, and why we do not want
to fracture the user community in two.
^ permalink raw reply
* Re: [PATCH 1/3] git-gui: Adapt discovery of oguilib to execdir 'libexec/git-core'
From: Shawn O. Pearce @ 2008-07-27 21:24 UTC (permalink / raw)
To: Steffen Prohaska; +Cc: git, Johannes Sixt
In-Reply-To: <1217177383-25272-2-git-send-email-prohaska@zib.de>
Steffen Prohaska <prohaska@zib.de> wrote:
> The new execdir has is two levels below the root directory, while
> the old execdir 'bin' was only one level below. This commit
> adapts the discovery of oguilib that uses relative paths
> accordingly.
...
> diff --git a/git-gui/git-gui.sh b/git-gui/git-gui.sh
> index 940677c..baccd57 100755
> --- a/git-gui/git-gui.sh
> +++ b/git-gui/git-gui.sh
> @@ -52,7 +52,9 @@ catch {rename send {}} ; # What an evil concept...
> set oguilib {@@GITGUI_LIBDIR@@}
> set oguirel {@@GITGUI_RELATIVE@@}
> if {$oguirel eq {1}} {
> - set oguilib [file dirname [file dirname [file normalize $argv0]]]
> + set oguilib [file dirname \
> + [file dirname \
> + [file dirname [file normalize $argv0]]]]
> set oguilib [file join $oguilib share git-gui lib]
Hmmph. This actually comes up incorrectly on my system. The issue
appears to be `git --exec-path` gives me $prefix/libexec/git-core,
and git-gui installs its library into $prefix/libexec/share, which
is wrong. It should have gone to $prefix/share.
I wonder if this is better. Your other two patches seem fine.
--8<--
[PATCH] git-gui: Correct installation of library to be $prefix/share
We always wanted the library for git-gui to install into the
$prefix/share directory, not $prefix/libexec/share. All of
the files in our library are platform independent and may
be reused across systems, like any other content stored in
the share directory.
Our computation of where our library should install to was broken
when git itself started installing to $prefix/libexec/git-core,
which was one level down from where we expected it to be.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
---
Makefile | 3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/Makefile b/Makefile
index b19fb2d..f72ab6c 100644
--- a/Makefile
+++ b/Makefile
@@ -32,6 +32,9 @@ endif
ifndef gitexecdir
gitexecdir := $(shell git --exec-path)
endif
+ifeq (git-core,$(notdir $(gitexecdir)))
+ gitexecdir := $(patsubst %/,%,$(dir $(gitexecdir)))
+endif
ifndef sharedir
sharedir := $(dir $(gitexecdir))share
--
1.6.0.rc0.182.gb96c7
--
Shawn.
^ permalink raw reply related
* Re: Cleaning up log messages
From: Jon Smirl @ 2008-07-27 20:52 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Git Mailing List
In-Reply-To: <7vsktv17wc.fsf@gitster.siamese.dyndns.org>
On 7/27/08, Junio C Hamano <gitster@pobox.com> wrote:
> "Jon Smirl" <jonsmirl@gmail.com> writes:
>
> > I was playing around with git log for the kernel and observed that
> > there is a lot of noise when trying to do statistics on the number of
> > commits.
> >
> > For example:
> >
> > Author: Greg K-H <gregkh@suse.de>
> > Author: Greg KH <gregkh@suse.de>
> > ...
>
> > Author: Greg Kroah-Hartman <greg@kroah.com>
>
>
> We have had .mailmap since a24e658 (git-shortlog: make the mailmap
> configurable., 2005-10-06); maybe the kernel tree wants a maintainer for
> the .mailmap file?
This seems to be the main problem. There are so many missing entries
from the .mailmap file that I didn't think this feature was
implemented. I'd guestimate that 300-400 needed entries are missing.
I've made a few attempts at writing a script to fix the easy ones but
I don't have a good solution yet.
--
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply
* Re* [RFC/PATCH v2] merge-base: teach "git merge-base" to accept more than 2 arguments
From: Junio C Hamano @ 2008-07-27 20:47 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Christian Couder, git, Miklos Vajna
In-Reply-To: <7vljzn2o51.fsf@gitster.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>
>> BTW I seem to recall that get_merge_bases_many() was _not_ the same as
>> get_merge_octopus(). Could you please remind me what _many() does?
>
> I explained what merge-bases-many gives in a separate message last night
> with pictures.
>
> get_merge_octopus() is a more or less useless function. It is there only
> because the protocol between "merge" and strategies requires that the
> former have to pass _some_ bases to the latter. In fact, the octopus
> strategy implementation completely ignores the heads given by "merge";
> a single set of merge base given from outside is not even useful when you
> build octopus by repeatedly running pairwise three-way merges.
This part may benefit from a bit of clarification, so I'll borrow the
picture from my other message.
o---o---o---o---C
/
/ o---o---o---B
/ /
---1---2---o---o---o---A
Suppose you have this topology, and you are trying to make an octopus
across A, B and C (you are at C and merging A and B into your branch).
The protoccol between "git merge" and merge strategies is for the former
to pass common ancestor(s), '--' and then commits being merged.
I think "merge", both in scripted version and Miklos's C version, gives
"1" because that is the common across all the heads. This choice of merge
base in itself is correct (that is why I said that git_merge_octopus() is
"more or less useless", not "totally pointless"). If an implementation of
strategy that is capable of producing an octopus wanted to merge arbitrary
number of trees using a single merge base in one-go, that is the merge
base it would want to use.
HOWEVER.
The particular implementation of git-merge-octopus does not produce the
final merge in one-go. It iteratively produces pairwise merges. So the
first step might be to come up with a merge between B and C:
o---o---o---o---C
/ :
/ o---o---o---B..(M)
/ /
---1---2---o---o---o---A
and for that, "1" is used as the merge base, not because it is the base
across A, B and C but because it is the base between B and C. For this
merge, A does not matter.
I drew M in parentheses and lines between B and C to it in dotted line
because we actually do _not_ create a real commit --- the only thing we
need is a tree object, in order to proceed to the next step.
Then the final merge result is obtained by merging tree of (M) and A using
their common ancestor. For that, we _could_ still use "1" as the merge
base.
But if you imagine a case where you started from A and M, you would _not_
pick "1" as the merge base; you would rather use "2" which is a better
base for this merge.
That is why git-merge-octopus ignores the merge base given by "merge" but
computes its own.
Side note. If your first step merge is between A and B, then you
would also use "2" as the merge base.
o---o---o---o---C
/
/ o---o---o---B..(M)
/ / :
---1---2---o---o---o---A
The comment at the end of git-merge-octopus talks about "merge reference
commit", that we used to update it to common found in this round, and that
that updating was pointless. After the first round of merge to produce
the tree for M (but without actually creating the commit object M itself),
in order to figure out the merge base used to merge that with A in the
second round, we used to use A and "1" (which was merge base between B and
C). That was pointless --- "merge-base A 1" is guaranteed to give a base
that is no better than either "merge-base A B" or "merge-base A C". So
the current code keeps using the original head (iow, MRC=Ci, because n
this case we are starting from C and merging B and then A into it).
This trickerly was necessary only because we avoided creating the extra
merge commit object M.
Side note. An alternative implementation could have been to
actually record it as a real merge commit M, and then let the
two-commit merge-base compute the base between A and M when
merging A to the result of the previous round, but we avoided
creating M, at the expense of potentially using suboptimal base in
the later rounds.
But we do not have to be that pessimistic. We can instead accumulate the
commits we have merged so far in MRC, and have merge_bases_many() compute
the merge base for the new head being merged and the heads we have
processed so far, which can give a better base than what we currently do.
That is what Christian's patch enables us to do.
In other words, we can do something like this.
git-merge-octopus.sh | 11 ++---------
1 files changed, 2 insertions(+), 9 deletions(-)
diff --git a/git-merge-octopus.sh b/git-merge-octopus.sh
index 645e114..1dadbb4 100755
--- a/git-merge-octopus.sh
+++ b/git-merge-octopus.sh
@@ -61,7 +61,7 @@ do
exit 2
esac
- common=$(git merge-base --all $MRC $SHA1) ||
+ common=$(git merge-base --all $SHA1 $MRC) ||
die "Unable to find common commit with $SHA1"
case "$LF$common$LF" in
@@ -100,14 +100,7 @@ do
next=$(git write-tree 2>/dev/null)
fi
- # We have merged the other branch successfully. Ideally
- # we could implement OR'ed heads in merge-base, and keep
- # a list of commits we have merged so far in MRC to feed
- # them to merge-base, but we approximate it by keep using
- # the current MRC. We used to update it to $common, which
- # was incorrectly doing AND'ed merge-base here, which was
- # unneeded.
-
+ MRC="$MRC $SHA1"
MRT=$next
done
^ permalink raw reply related
* Re: [RFC/PATCH v2] merge-base: teach "git merge-base" to accept more than 2 arguments
From: Johannes Schindelin @ 2008-07-27 20:44 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Christian Couder, git, Miklos Vajna
In-Reply-To: <7vljzn2o51.fsf@gitster.siamese.dyndns.org>
Hi,
On Sun, 27 Jul 2008, Junio C Hamano wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>
> > BTW I seem to recall that get_merge_bases_many() was _not_ the same as
> > get_merge_octopus(). Could you please remind me what _many() does?
>
> I explained what merge-bases-many gives in a separate message last night
> with pictures.
I missed that, alright.
> get_merge_octopus() is a more or less useless function. It is there
> only because the protocol between "merge" and strategies requires that
> the former have to pass _some_ bases to the latter.
Does it? I thought that e.g. merge-recursive accepts an empty set of
merge bases? AFAIR that was the reason why gitk could be merged so well.
> In fact, the octopus strategy implementation completely ignores the
> heads given by "merge"; a single set of merge base given from outside is
> not even useful when you build octopus by repeatedly running pairwise
> three-way merges.
>
> With Christian's git-merge-base enhancement, the big comment at the end
> of git-merge-octopus's main loop can go with a much improved "next"
> merge base computation.
Okay.
Ciao,
Dscho
^ permalink raw reply
* [PATCH] Avoid chdir() in list_commands_in_dir()
From: Johannes Schindelin @ 2008-07-27 20:34 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Miklos Vajna, git
In-Reply-To: <alpine.DEB.1.00.0807272219350.5526@eeepc-johanness>
The function list_commands_in_dir() tried to be lazy and just chdir()
to the directory which entries it listed, so that the check if the
file is executable could be done on dir->d_name.
However, there is no good reason to jump around wildly just to find
all Git commands.
Instead, have a strbuf and construct the full path dynamically.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---
help.c | 12 ++++++++++--
1 files changed, 10 insertions(+), 2 deletions(-)
diff --git a/help.c b/help.c
index 480befe..7af6582 100644
--- a/help.c
+++ b/help.c
@@ -426,17 +426,24 @@ static unsigned int list_commands_in_dir(struct cmdnames *cmds,
int prefix_len = strlen(prefix);
DIR *dir = opendir(path);
struct dirent *de;
+ struct strbuf buf = STRBUF_INIT;
+ int len;
- if (!dir || chdir(path))
+ if (!dir)
return 0;
+ strbuf_addf(&buf, "%s/", path);
+ len = buf.len;
+
while ((de = readdir(dir)) != NULL) {
int entlen;
if (prefixcmp(de->d_name, prefix))
continue;
- if (!is_executable(de->d_name))
+ strbuf_setlen(&buf, len);
+ strbuf_addstr(&buf, de->d_name);
+ if (!is_executable(buf.buf))
continue;
entlen = strlen(de->d_name) - prefix_len;
@@ -449,6 +456,7 @@ static unsigned int list_commands_in_dir(struct cmdnames *cmds,
add_cmdname(cmds, de->d_name + prefix_len, entlen);
}
closedir(dir);
+ strbuf_release(&buf);
return longest;
}
--
1.6.0.rc0.97.ge2309
^ permalink raw reply related
* Re: [PATCH 2/7] builtin-help: change the current directory back in list_commands_in_dir()
From: Johannes Schindelin @ 2008-07-27 20:21 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Miklos Vajna, git
In-Reply-To: <7vwsj7yu1q.fsf@gitster.siamese.dyndns.org>
Hi,
On Sun, 27 Jul 2008, Junio C Hamano wrote:
> Miklos Vajna <vmiklos@frugalware.org> writes:
>
> > That function used to do a chdir() without switching back to the
> > original directory. That was not a problem till this function was used
> > only inside builtin-help, but once other builtins use it as well, this
> > is a problem, for example when the object database path is relative.
>
> Why does it even need to chdir() around to begin with? Doesn't
> opendir() work just fine with relative path as an input?
It is a consequence of list_commands_in_dir() trying to be cute, and not
having to construct the full path for the is_executable() check.
Will post a fix in a few minutes.
Ciao,
Dscho
^ permalink raw reply
* Re: Cleaning up log messages
From: Johannes Schindelin @ 2008-07-27 20:16 UTC (permalink / raw)
To: Jon Smirl; +Cc: Petr Baudis, Git Mailing List
In-Reply-To: <9e4733910807271231s7ff6acf8rf5848cc1a31f3afc@mail.gmail.com>
Hi,
On Sun, 27 Jul 2008, Jon Smirl wrote:
> How do you do it with git log? --pretty overrides the default of medium
>
> --pretty[=<format>]
>
> Pretty-print the contents of the commit logs in a given format,
> where <format> can be one of oneline, short, medium, full, fuller,
> email, raw and format:<string>. When omitted, the format defaults to
> medium.
You get it _almost_ with
$ f='commit %H%nAuthor: %aN <%ae>%nDate: %ad%n%n%s%n%n%b'
$ git log --pretty="format:$f"
The only difference being that the commit message is not indented. If you
really need that, it is easy to add.
But I rather doubt that you need it, as you want to make statistics, and
therefore need to pipe the output into a script anyway.
Ciao,
Dscho
^ permalink raw reply
* Re: Official Git Homepage change? Re: git-scm.com
From: Sverre Rabbelier @ 2008-07-27 20:12 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Petr Baudis, Junio C Hamano, Scott Chacon, git
In-Reply-To: <alpine.DEB.1.00.0807271744180.5526@eeepc-johanness>
On Sun, Jul 27, 2008 at 17:53, Johannes Schindelin
<Johannes.Schindelin@gmx.de> wrote:
> Maybe I should start my mails with "Disclaimer: I only reply to you
> because I am interested in your patch."
That might actually be a good idea, maybe add it as your signature ;). *ducks*
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* Re: [PATCH 2/7] builtin-help: change the current directory back in list_commands_in_dir()
From: Junio C Hamano @ 2008-07-27 20:02 UTC (permalink / raw)
To: Miklos Vajna; +Cc: git
In-Reply-To: <4f2b03391e3f85cf2224f97a2a7765d08707bd73.1217037178.git.vmiklos@frugalware.org>
Miklos Vajna <vmiklos@frugalware.org> writes:
> That function used to do a chdir() without switching back to the
> original directory. That was not a problem till this function was used
> only inside builtin-help, but once other builtins use it as well, this
> is a problem, for example when the object database path is relative.
Why does it even need to chdir() around to begin with? Doesn't opendir()
work just fine with relative path as an input?
^ permalink raw reply
* Re: [PATCH] Make use of stat.ctime configurable
From: Junio C Hamano @ 2008-07-27 19:46 UTC (permalink / raw)
To: Alex Riesen; +Cc: Johannes Schindelin, Linus Torvalds, Johannes Sixt, git
In-Reply-To: <20080726153802.GA16868@blimp.local>
Alex Riesen <raa.lkml@gmail.com> writes:
> because there are situations where it produces too much false
> positives. Like when file system crawlers keep changing it when
> scanning and using the ctime for marking scanned files.
This justification is good and I am very inclined to advocate for its
inclusion in 1.6.0, but any new configuration needs to be in the
documentation.
It appears there is "gui.trustmtime"; shouldn't this be called
"core.trustctime" or something?
^ permalink raw reply
* Re: [PATCH] Make use of stat.ctime configurable
From: Junio C Hamano @ 2008-07-27 19:46 UTC (permalink / raw)
To: Alex Riesen; +Cc: Johannes Schindelin, Linus Torvalds, Johannes Sixt, git
In-Reply-To: <20080726153802.GA16868@blimp.local>
Alex Riesen <raa.lkml@gmail.com> writes:
> because there are situations where it produces too much false
> positives. Like when file system crawlers keep changing it when
> scanning and using the ctime for marking scanned files.
This justification is good and I am very inclined to advocate for its
inclusion in 1.6.0, but any new configuration needs to be in the
documentation.
It appears there is "gui.trustmtime"; shouldn't this be called
"core.trustctime" or something?
^ permalink raw reply
* Re: Cleaning up log messages
From: Jon Smirl @ 2008-07-27 19:31 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Petr Baudis, Git Mailing List
In-Reply-To: <alpine.DEB.1.00.0807272116030.5526@eeepc-johanness>
On 7/27/08, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> Hi,
>
>
> On Sun, 27 Jul 2008, Jon Smirl wrote:
>
> > On 7/27/08, Petr Baudis <pasky@suse.cz> wrote:
> > > On Sun, Jul 27, 2008 at 02:16:30PM -0400, Jon Smirl wrote:
> > > > On 7/27/08, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> > >
> > > > > Something like .mailmap?
> > > > >
> > > > > And to show the mapped author name instead of the committed one, you would
> > > > > use "--pretty=format:%aN"? (Needs 1.6.0-rc0 at least, IIRC)
> > > >
> > > > So we can already do this? Where is a .mailmap for the kernel tree?
> > >
> > > http://repo.or.cz/w/linux-2.6.git?a=blob;f=.mailmap
> > >
> > > ...right there. :-)
> >
> > I updated to 1.6.0-rc0 and this is working. mailmap needs some
> > cleanup. Errors are still in the list, but this is a lot better than
> > it was. That made about 800 'contributors' disappear.
> >
> > Is there a way to do short log and have it map the names?
>
>
> Yes, as of v1.6.0-rc0~58 you can pass --pretty=format: to shortlog.
How do you do it with git log? --pretty overrides the default of medium
--pretty[=<format>]
Pretty-print the contents of the commit logs in a given format,
where <format> can be one of oneline, short, medium, full, fuller,
email, raw and format:<string>. When omitted, the format defaults to
medium.
>
>
> > What about replacing the emails with their current email address?
>
>
> Nope, that was never meant to be done.
>
> Ciao,
> Dscho
>
>
--
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply
* Re: [PATCH] Modify mingw_main() workaround to avoid link errors
From: Johannes Sixt @ 2008-07-27 19:24 UTC (permalink / raw)
To: Steffen Prohaska; +Cc: git, Junio C Hamano
In-Reply-To: <4CCD1862-48FB-412B-80B6-E1B822BF3A87@zib.de>
Zitat von Steffen Prohaska <prohaska@zib.de>:
>
> On Jul 26, 2008, at 10:37 PM, Johannes Sixt wrote:
>
> > Zitat von Steffen Prohaska <prohaska@zib.de>:
> >> With MinGW's
> >>
> >> gcc.exe (GCC) 3.4.5 (mingw special)
> >> GNU ld version 2.17.50 20060824
> >>
> >> the old define caused link errors:
> >>
> >> git.o: In function `main':
> >> C:/msysgit/git/git.c:500: undefined reference to `mingw_main'
> >> collect2: ld returned 1 exit status
> >>
> >> The modified define works.
> >
> > I have the same tools, but not this error. ???
>
> I cleaned my work tree and built several times but did not
> find out what exactly is causing the error. So I came up
> with the modified define, which declares the static
> mingw_main in global scope. I have no clue why I see the
> error that you don't have.
Neither do I. But a strange line number you have there. In 01d9b2d (from
mingw.git) I have 'exit(1)' in line 500 of git.c.
-- Hannes
^ permalink raw reply
* Re: Cleaning up log messages
From: Johannes Schindelin @ 2008-07-27 19:20 UTC (permalink / raw)
To: Jon Smirl; +Cc: Petr Baudis, Git Mailing List
In-Reply-To: <9e4733910807271207o2e18cef1h869c659bd0ae31ba@mail.gmail.com>
Hi,
On Sun, 27 Jul 2008, Jon Smirl wrote:
> On 7/27/08, Petr Baudis <pasky@suse.cz> wrote:
> > On Sun, Jul 27, 2008 at 02:16:30PM -0400, Jon Smirl wrote:
> > > On 7/27/08, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> >
> > > > Something like .mailmap?
> > > >
> > > > And to show the mapped author name instead of the committed one, you would
> > > > use "--pretty=format:%aN"? (Needs 1.6.0-rc0 at least, IIRC)
> > >
> > > So we can already do this? Where is a .mailmap for the kernel tree?
> >
> > http://repo.or.cz/w/linux-2.6.git?a=blob;f=.mailmap
> >
> > ...right there. :-)
>
> I updated to 1.6.0-rc0 and this is working. mailmap needs some
> cleanup. Errors are still in the list, but this is a lot better than
> it was. That made about 800 'contributors' disappear.
>
> Is there a way to do short log and have it map the names?
Yes, as of v1.6.0-rc0~58 you can pass --pretty=format: to shortlog.
> What about replacing the emails with their current email address?
Nope, that was never meant to be done.
Ciao,
Dscho
^ permalink raw reply
* Re: Cleaning up log messages
From: Jon Smirl @ 2008-07-27 19:07 UTC (permalink / raw)
To: Petr Baudis; +Cc: Johannes Schindelin, Git Mailing List
In-Reply-To: <20080727183309.GD32184@machine.or.cz>
On 7/27/08, Petr Baudis <pasky@suse.cz> wrote:
> On Sun, Jul 27, 2008 at 02:16:30PM -0400, Jon Smirl wrote:
> > On 7/27/08, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
>
> > > Something like .mailmap?
> > >
> > > And to show the mapped author name instead of the committed one, you would
> > > use "--pretty=format:%aN"? (Needs 1.6.0-rc0 at least, IIRC)
> >
> > So we can already do this? Where is a .mailmap for the kernel tree?
>
>
> http://repo.or.cz/w/linux-2.6.git?a=blob;f=.mailmap
>
> ...right there. :-)
I updated to 1.6.0-rc0 and this is working. mailmap needs some
cleanup. Errors are still in the list, but this is a lot better than
it was. That made about 800 'contributors' disappear.
Is there a way to do short log and have it map the names? What about
replacing the emails with their current email address?
Random missing entries....
Greg KH
Greg Kroah-Hartman
Hans J Koch
Hans J. Koch
Jean-Christophe Dubois
Jean-Christophe DUBOIS
Miguel Boton
Miguel Botón
--
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply
* Re: Bizarre missing changes (git bug?)
From: Linus Torvalds @ 2008-07-27 18:47 UTC (permalink / raw)
To: Roman Zippel; +Cc: Tim Harper, git
In-Reply-To: <Pine.LNX.4.64.0807270049290.6791@localhost.localdomain>
On Sun, 27 Jul 2008, Roman Zippel wrote:
> Hi,
>
> On Sat, 26 Jul 2008, Linus Torvalds wrote:
>
> > > Is there a way to change that default?
> >
> > Use an alias or something.
>
> This doesn't help with the graphical front ends and they only use what git
> gives them.
And the graphical front-ends is exactly why --full-history cannot be the
default.
We _could_ make it the default for non-graphical ones, if we also say
"--no-merges". But then:
> > To see why it's the default, do a few tests. In particular, try it with
> > gitk on the kernel. Try it on some fairly simple file that doesn't get a
> > lot of churn. Example:
> >
> > gitk lib/vsprintf.c
> >
> > vs
> >
> > gitk --full-history lib/vsprintf.c
> >
> > and if you don't _immediately_ see why --full-history isn't the default,
> > there's likely something wrong with you. One is useful. The other is not.
> >
> > So we absolutely _have_ to simplify merges. There is no question about it.
>
> Well, I don't want that much history.
Right. Nobody does.
> Let's take a different example.
No, let's not.
Unless you can solve that _one_ example efficiently, nothing else matters.
The above example is all you ever need. Make that one work right (and
efficiently), and everything is fine.
And no, some random ruby code doesn't make any difference what-so-ever.
There are efficiency constraints here that make any ruby solution be
unrealistic to begin with.
Linus
^ permalink raw reply
* Re: Cleaning up log messages
From: Junio C Hamano @ 2008-07-27 18:47 UTC (permalink / raw)
To: Jon Smirl; +Cc: Git Mailing List
In-Reply-To: <9e4733910807271050y7fb5f77coec05bd68421baaab@mail.gmail.com>
"Jon Smirl" <jonsmirl@gmail.com> writes:
> I was playing around with git log for the kernel and observed that
> there is a lot of noise when trying to do statistics on the number of
> commits.
>
> For example:
>
> Author: Greg K-H <gregkh@suse.de>
> Author: Greg KH <gregkh@suse.de>
> ...
> Author: Greg Kroah-Hartman <greg@kroah.com>
We have had .mailmap since a24e658 (git-shortlog: make the mailmap
configurable., 2005-10-06); maybe the kernel tree wants a maintainer for
the .mailmap file?
^ permalink raw reply
* Re: git-scm.com
From: Junio C Hamano @ 2008-07-27 18:33 UTC (permalink / raw)
To: Petr Baudis; +Cc: Scott Chacon, git
In-Reply-To: <20080727113707.GC32184@machine.or.cz>
Petr Baudis <pasky@suse.cz> writes:
>> If you are going to list 30 or so top contributors in 8 rows times 4
>> columns, because visually the columns are much more distinct than the
>> rows, it makes the result look more sorted. This is the same reasoning
>> hwo "git help --all" was fixed with 112d0ba (Make "git help" sort git
>> commands in columns, 2005-12-18).
>
> Actually, this is strange for me: I would never think about reading git
> help --all by rows, and I would never think about reading the authors
> list by columns! It's difficult for me to point out why, possibly
> because the authors list has less items per row and the items are longer
> (and multi-word), but that's just a speculation. Maybe cultural
> background (Japanese books are written in columns, right?) plays some
> role too, I don't know.
I do not think the default mode of "ls" output to tty (aka "ls -C") was
invented by/for Japanese people.
>> And for the "giving credit" purpose, I do not think truncating the list at
>> 5 commits or less threshold, as suggested earlier and already done, makes
>> much sense, either.
>
> The point here is that the list is awfully long and also can contain
> a lot of duplicates or people with broken unicode, etc. - it gets hard
> to maintain, and it makes the about page too long. I would be of course
> fine with a tiny link at the bottom "(show all contributors)".
Your "incentive to move up" argument suggests otherwise. Even if it takes
efforts to maintain on somebody's part, it is worth to be inclusive, *IF*
the purpose of that bottom list is to give credits to people.
The list on the site originally was not utilizing .mailmap and I asked
Scott to use it to merge duplicate entries, which he did. People whose
names are misspelled and/or split will now have incentive to tell Scott
about the problem so that they can clean up *their* own names, and Scott
can help maintaining .mailmap and feed the changes to me.
This is my ulterior motive behind this suggestion; I can outsource the
maintenance of .mailmap to people who care about it more than myself.
^ permalink raw reply
* Re: Cleaning up log messages
From: Petr Baudis @ 2008-07-27 18:33 UTC (permalink / raw)
To: Jon Smirl; +Cc: Johannes Schindelin, Git Mailing List
In-Reply-To: <9e4733910807271116q29323664l8d44fdded1de8c8e@mail.gmail.com>
On Sun, Jul 27, 2008 at 02:16:30PM -0400, Jon Smirl wrote:
> On 7/27/08, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> > Something like .mailmap?
> >
> > And to show the mapped author name instead of the committed one, you would
> > use "--pretty=format:%aN"? (Needs 1.6.0-rc0 at least, IIRC)
>
> So we can already do this? Where is a .mailmap for the kernel tree?
http://repo.or.cz/w/linux-2.6.git?a=blob;f=.mailmap
...right there. :-)
Petr "Pasky" Baudis
^ 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