* Re: [RFC/PATCH v2] merge-base: teach "git merge-base" to accept more than 2 arguments
From: Johannes Schindelin @ 2008-07-27 14:38 UTC (permalink / raw)
To: Christian Couder; +Cc: git, Junio C Hamano, Miklos Vajna
In-Reply-To: <20080727053324.b54fe48e.chriscool@tuxfamily.org>
Hi,
On Sun, 27 Jul 2008, Christian Couder wrote:
> diff --git a/builtin-merge-base.c b/builtin-merge-base.c
> index 1cb2925..f2c9756 100644
> --- a/builtin-merge-base.c
> +++ b/builtin-merge-base.c
> @@ -38,15 +48,22 @@ int cmd_merge_base(int argc, const char **argv, const char *prefix)
> usage(merge_base_usage);
> argc--; argv++;
> }
> - if (argc != 3)
> + if (argc < 3)
> usage(merge_base_usage);
> - if (get_sha1(argv[1], rev1key))
> - die("Not a valid object name %s", argv[1]);
> - if (get_sha1(argv[2], rev2key))
> - die("Not a valid object name %s", argv[2]);
> - rev1 = lookup_commit_reference(rev1key);
> - rev2 = lookup_commit_reference(rev2key);
> - if (!rev1 || !rev2)
> +
> + rev1 = get_commit_reference(argv[1]);
> + if (!rev1)
> return 1;
Why do you special case rev1? Is it so special? Just handle it together
with all of the other arguments!
IOW have one commit array, and do not call it "prev".
> - return show_merge_base(rev1, rev2, show_all);
> + argc--; argv++;
> +
> + do {
> + struct commit *rev2 = get_commit_reference(argv[1]);
> + if (!rev2)
> + return 1;
> + ALLOC_GROW(prev2, prev2_nr + 1, prev2_alloc);
> + prev2[prev2_nr++] = rev2;
> + argc--; argv++;
> + } while (argc > 1);
Now, this is ugly. You know beforehand the _exact_ number of arguments,
and yet you dynamically grow the array? Also, why do you use a do { }
while(), when a for () would be much, much clearer?
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?
Ciao,
Dscho
^ permalink raw reply
* Re: [RFC/PATCH v2] merge-base: teach "git merge-base" to accept more than 2 arguments
From: Jakub Narebski @ 2008-07-27 15:02 UTC (permalink / raw)
To: Christian Couder; +Cc: git, Junio C Hamano, Johannes Schindelin, Miklos Vajna
In-Reply-To: <20080727053324.b54fe48e.chriscool@tuxfamily.org>
Christian Couder <chriscool@tuxfamily.org> writes:
> Before this patch "git merge-base" accepted only 2 arguments, so
> only merge bases between 2 references could be computed.
> +'git-merge-base' finds as good common ancestors as possible between
> +the first commit and the other commits. The default behavior is to
> +output only one as good as possible common ancestor, called a merge
> +base.
> +
> +For example, given two commits A and B, `git merge-base A B` will
> +output a commit which is reachable from both A and B through the
> +parent relationship.
> +
> +Given three commits A, B and C, `git merge-base A B C` will output a
> +commit which is reachable through the parent relationship from both A
> +and B, or from both A and C.
I don't understand this complication. Isn't merge base (merge bases)
for commits A, B and C simply least common ancestor (or ancestors)
of commits A, B and C (with commits being included as their own
ancestors)?
What are the results of "git merge-base" and "git merge-base --all"
in the following situations?
For two commits:
.---.---*---.---.---A
\
\-.---B
.---m-----b---.---.---A
\ \ /
\ X
\ / \
\-a---.---.---B
For three commits:
.---.---1---2---.---.---A
\ \
\ \-.---B
\
\---.---.---C
/-.---.---A
/
.---.---1---2---.---.---B
\
\-.---.---.---C
--
Jakub Narebski
Poland
ShadeHawk on #git
^ permalink raw reply
* Re: Running git gui on Windows.
From: Shawn O. Pearce @ 2008-07-27 15:02 UTC (permalink / raw)
To: Jurko Gospodnetiii; +Cc: git
In-Reply-To: <g6huoj$9rh$1@ger.gmane.org>
Jurko Gospodnetiii <jurko.gospodnetic@docte.hr> wrote:
>> Is there a way to run git gui on Windows so it does not block the
>> calling process?
In traditional UNIX shells this is "git gui &", requesting that the
shell background the process, but still monitor it for exit status.
On Windows there is no such easy concept.
> I now realized my question did not say exactly what I intended it to.
> I know I can start 'git gui' using:
>
> start "" /b cmd /c git gui
>
> from the command prompt and get the desired effect. I was wondering
> why git gui does not do this in the first place and whether it could be
> modified so that this is the default behaviour?
git-gui and gitk won't automatically background themselves, as they
are primarily developed on UNIX and have a UNIX like interface to
them, including backgrounding behavior.
We could add a -f flag to git-gui, such that "git gui -f" causes it
to fork+exec a new wish process, completely disconnecting it from the
calling shell. (-f stolen from OpenSSH's ssh -f host xterm example)
I'd accept a patch for it, but its not high on my list of things to
write and debug myself.
--
Shawn.
^ permalink raw reply
* Re: [RFC/PATCH v2] merge-base: teach "git merge-base" to accept more than 2 arguments
From: Miklos Vajna @ 2008-07-27 15:28 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Christian Couder, git, Junio C Hamano
In-Reply-To: <alpine.DEB.1.00.0807271631470.5526@eeepc-johanness>
[-- Attachment #1: Type: text/plain, Size: 676 bytes --]
On Sun, Jul 27, 2008 at 04:38:05PM +0200, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> 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?
get_octopus_merge_bases() takes a commit_list, and tries to figure out
the common bases of those commits.
get_merge_bases_many(), which is used by reduce_heads() takes a commit
and a commit_list, and counts the bases of the heads against the commit
specified as the first parameter.
I think get_merge_bases_many() could be even static, it is not really
interesting for anything else than reduce_heads() at the moment.
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: Official Git Homepage change? Re: git-scm.com
From: Johannes Schindelin @ 2008-07-27 15:53 UTC (permalink / raw)
To: Petr Baudis; +Cc: Junio C Hamano, Scott Chacon, git
In-Reply-To: <20080727122236.GY10151@machine.or.cz>
Hi,
On Sun, 27 Jul 2008, Petr Baudis wrote:
> (ii) The tone on the mailing list seems frequently unnecessarily
> harsh.
I heard this a lot of times now. I think it is not "harsh", but "direct".
There is nobody saying "you are a bloody fool". At least not in the first
response, and certainly not without explaining why.
Sure, I, for one, am not overly polite. I do not start my mail with "It
is such a nice thing that you decided to provide a patch. I am certain
that you know C pretty well, but there _might_ be a few _tiny_
improvements, would you indulge with me to let them lay out in front of
you?"
I do not do that because it goes without saying in Open Source that I
would not _bother_ to reply if I was not interested. And it Just Wastes
My Time.
Maybe I should start my mails with "Disclaimer: I only reply to you
because I am interested in your patch."
Ciao,
Dscho
^ permalink raw reply
* [PATCH 1/3] git-gui: Adapt discovery of oguilib to execdir 'libexec/git-core'
From: Steffen Prohaska @ 2008-07-27 16:49 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: git, Johannes Sixt, Steffen Prohaska
In-Reply-To: <1217177383-25272-1-git-send-email-prohaska@zib.de>
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.
Signed-off-by: Steffen Prohaska <prohaska@zib.de>
---
git-gui/git-gui.sh | 4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
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]
set oguimsg [file join $oguilib msgs]
} elseif {[string match @@* $oguirel]} {
--
1.6.0.rc0.79.gb0320
^ permalink raw reply related
* [PATCH 2/3] git-gui (Windows): Switch to relative discovery of oguilib
From: Steffen Prohaska @ 2008-07-27 16:49 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: git, Johannes Sixt, Steffen Prohaska
In-Reply-To: <1217177383-25272-2-git-send-email-prohaska@zib.de>
Instead of using an absolute path, git-gui can discover its
gui library using a relative path from execdir. We want to
use the relative path discovery on MinGW to avoid issues
with translation of absolute paths.
Signed-off-by: Steffen Prohaska <prohaska@zib.de>
---
git-gui/Makefile | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/git-gui/Makefile b/git-gui/Makefile
index b19fb2d..ec4b33e 100644
--- a/git-gui/Makefile
+++ b/git-gui/Makefile
@@ -156,6 +156,7 @@ endif
ifneq (,$(findstring MINGW,$(uname_S)))
NO_MSGFMT=1
GITGUI_WINDOWS_WRAPPER := YesPlease
+ GITGUI_RELATIVE := 1
endif
ifdef GITGUI_MACOSXAPP
--
1.6.0.rc0.79.gb0320
^ permalink raw reply related
* [PATCH 0/3] git-gui (Windows): Adapt to new execdir 'libexec/git-core'
From: Steffen Prohaska @ 2008-07-27 16:49 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: git, Johannes Sixt
After moving the dashed programs, including git-gui, to execdir
'libexec/git-core', we have problems running git-gui from
msysgit.
The following patch series solves the problems. I am not sure
however if it is the less intrusive solution. Maybe the series
needs further discussion before applying it. Personally, I think
the patches are good enough.
Note that you also need the branch 'spr/installer' in msysgit to
build an installer.
[PATCH 1/3] git-gui: Adapt discovery of oguilib to execdir 'libexec/git-core'
[PATCH 2/3] git-gui (Windows): Switch to relative discovery of oguilib
[PATCH 3/3] git-gui (Windows): Change wrapper to execdir 'libexec/git-core'
^ permalink raw reply
* [PATCH 3/3] git-gui (Windows): Change wrapper to execdir 'libexec/git-core'
From: Steffen Prohaska @ 2008-07-27 16:49 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: git, Johannes Sixt, Steffen Prohaska
In-Reply-To: <1217177383-25272-3-git-send-email-prohaska@zib.de>
git-gui needs bindir in PATH to be able to run 'git'. bindir
however is not necessarily in PATH if started directly through a
Windows shortcut. Therefore, we used to add the directory
git-gui is located in. But with the new 'libexec/git-core'
layout this directory is no longer identical to bindir.
This commit modifies the wrapper script to discover the bindir
and add it to PATH.
Signed-off-by: Steffen Prohaska <prohaska@zib.de>
---
git-gui/windows/git-gui.sh | 11 +++++++----
1 files changed, 7 insertions(+), 4 deletions(-)
diff --git a/git-gui/windows/git-gui.sh b/git-gui/windows/git-gui.sh
index 98f32c0..53c3a94 100644
--- a/git-gui/windows/git-gui.sh
+++ b/git-gui/windows/git-gui.sh
@@ -8,9 +8,12 @@ if { $argc >=2 && [lindex $argv 0] == "--working-dir" } {
incr argc -2
}
-set gitguidir [file dirname [info script]]
-regsub -all ";" $gitguidir "\\;" gitguidir
-set env(PATH) "$gitguidir;$env(PATH)"
-unset gitguidir
+set bindir [file dirname \
+ [file dirname \
+ [file dirname [info script]]]]
+set bindir [file join $bindir bin]
+regsub -all ";" $bindir "\\;" bindir
+set env(PATH) "$bindir;$env(PATH)"
+unset bindir
source [file join [file dirname [info script]] git-gui.tcl]
--
1.6.0.rc0.79.gb0320
^ permalink raw reply related
* Re: [PATCH] make sure parsed wildcard refspec ends with slash
From: Daniel Barkalow @ 2008-07-27 17:20 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jeff King, git
In-Reply-To: <7vsktv3l9k.fsf_-_@gitster.siamese.dyndns.org>
On Sat, 26 Jul 2008, Junio C Hamano wrote:
> A wildcard refspec is internally parsed into a refspec structure with src
> and dst strings. Many parts of the code assumed that these do not include
> the trailing "/*" when matching the wildcard pattern with an actual ref we
> see at the remote. What this meant was that we needed to make sure not
> just that the prefix matched, and also that a slash followed the part that
> matched.
>
> But a codepath that scans the result from ls-remote and finds matching
> refs forgot to check the "matching part must be followed by a slash" rule.
> This resulted in "refs/heads/b1" from the remote side to mistakenly match
> the source side of "refs/heads/b/*:refs/remotes/b/*" refspec.
>
> Worse, the refspec crafted internally by "git-clone", and a hardcoded
> preparsed refspec that is used to implement "git-fetch --tags", violated
> this "parsed widcard refspec does not end with slash" rule; simply adding
> the "matching part must be followed by a slash" rule then would have
> broken codepaths that use these refspecs.
>
> This commit changes the rule to require a trailing slash to parsed
> wildcard refspecs. IOW, "refs/heads/b/*:refs/remotes/b/*" is parsed as
> src = "refs/heads/b/" and dst = "refs/remotes/b/". This allows us to
> simplify the matching logic because we only need to do a prefixcmp() to
> notice "refs/heads/b/one" matches and "refs/heads/b1" does not.
>
> Signed-off-by: Junio C Hamano <gitster@pobox.com>
> ---
> Junio C Hamano <gitster@pobox.com> writes:
>
> > I have a nagging suspicion that it might be a simpler and cleaner change
> > to change parse_refspec_internal() to keep the trailing slash, instead of
> > dropping it. Then the check you added is not needed (the trailing slash
> > guarantees that the pattern matches at the hierarchy boundary), neither
> > any of the change in this patch.
>
> This is the other variant, and it turns out that I was right. Among the
> 64-18 = 46 new lines, 30 are from the new test file. Two existing
> "matching part is followed by '/'" tests are removed.
Yeah, the first version of this code included the '/', by virtue of having
the '/' not be required in the refspec (i.e., you could have
"refs/heads/b*"); when you told me that refspecs needed to have a '/'
before the '*', I thought that it would be easiest to not include the '/',
since it was redundant, but, in retrospect, I'm not too surprised that it
simplifies things to include it.
Acked-by: Daniel Barkalow <barkalow@iabervon.org>
> remote.c | 52 +++++++++++++++++++++++++++++++----------------
> t/t5513-fetch-track.sh | 30 +++++++++++++++++++++++++++
> 2 files changed, 64 insertions(+), 18 deletions(-)
>
> diff --git a/remote.c b/remote.c
> index 0d6020b..f61a3ab 100644
> --- a/remote.c
> +++ b/remote.c
> @@ -427,6 +427,28 @@ static void read_config(void)
> alias_all_urls();
> }
>
> +/*
> + * We need to make sure the tracking branches are well formed, but a
> + * wildcard refspec in "struct refspec" must have a trailing slash. We
> + * temporarily drop the trailing '/' while calling check_ref_format(),
> + * and put it back. The caller knows that a CHECK_REF_FORMAT_ONELEVEL
> + * error return is Ok for a wildcard refspec.
> + */
> +static int verify_refname(char *name, int is_glob)
> +{
> + int result, len = -1;
> +
> + if (is_glob) {
> + len = strlen(name);
> + assert(name[len - 1] == '/');
> + name[len - 1] = '\0';
> + }
> + result = check_ref_format(name);
> + if (is_glob)
> + name[len - 1] = '/';
> + return result;
> +}
> +
Maybe check_ref_format() ought to have a return for "this is valid as a
directory rather than a single ref", and that would be allowed with globs?
I'm not too fond of temporarily changing strings for testing. Also, this
design (while it matches the current code), means that check_ref_format()
sees one fewer level than the refs that match will actually have, which is
a little confusing.
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* Cleaning up log messages
From: Jon Smirl @ 2008-07-27 17:50 UTC (permalink / raw)
To: Git Mailing List
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 KH <greg@kroah.com>
Author: Greg KH <greg@press.(none)>
Author: gregkh@suse.de <gregkh@suse.de>
Author: Greg Kroah-Hartman <gregkh@suse>
Author: Greg Kroah-Hartman <gregkh@suse.de>
Author: Greg Kroah-Hartman <greg@kroah.com>
I don't see an obvious way to do this with git, but it would be neat
to have a 'clean' option on git log that would take each email address
(author, signed-off, acked, etc) and map it through a table which
would convert old email addresses in to the current one and also
standardize the formatting of the names. A cleaned log would be
altered on display, but just don't clean it if you want the original.
Of course this initial map would need to be built by hand. New commits
could be checked against the map and the mapped updated if the person
really has a new email address. Checking new commits against the map
would help clean things up going forward. checkpatch.pl could also
validate against the mapping file.
No pressing need to for this, it would just be a nice toy.
--
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply
* Re: Bizarre missing changes (git bug?)
From: Roman Zippel @ 2008-07-27 17:50 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Tim Harper, git
In-Reply-To: <alpine.LFD.1.10.0807261249430.4188@nehalem.linux-foundation.org>
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.
> 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.
Let's take a different example. Look at kernel/sched_rt.c with git-log,
--full-history shows an extra commit of a patch which was committed and
merged twice, but there is no information how this other patch was merged.
If you have giggle installed, you'll see that commit as a loose end.
(I have git version 1.5.6.2 installed in case it matters.)
> That said, we currently simplify merges the simple and stupid way, and
> I've hinted several times on this mailing list that there is a better way
> to do it (last time it was the discussion about "filter-branch".
>
> In fact, if you google for
>
> filter-branch full-history
>
> you'll find some of the discussion. In order to make --full-history useful
> as a default, we'd need to do an after-the-fact merge cleanup (ie remove
> lines of development that are later found to really be totally
> uninteresting), but that is *hard*.
I played a little with it in the ruby script below, which produces a
complete connected graph of all content nodes and which have been merged
into the head, e.g. for sched_rt.c it produces that extra commit merge.
The script basically eliminates all empty merges. As input to the script I
used "git log --parents --name-only --full-history kernel/sched_rt.c |
grep -e ^commit -e ^kernel", which seems to produce the same amount of
commits as "gitk --full-history ...".
The main function is to check, whether one parent of a commit is an
ancestor of another parent, so that this path can be eliminated. I tried
it with other paths and too simple implementations quickly lead to
exponential behaviour. :) It probably also shouldn't be recursive, I had
to increase the stack limit, otherwise I got stack exceptions.
Otherwise it seems to work fine, it wasn't that hard :-)
The ruby syntax shouldn't be too hard too read, the nonobvious thing is
maybe that '$' marks global variables.
bye, Roman
#! /usr/bin/ruby
$parent = Hash.new
$content = Hash.new
$result = Hash.new
commit = nil
head = nil
while l = $stdin.gets
a = l.split(" ")
if a[0] == "commit"
commit = a[1]
head = commit unless head
$parent[commit] = a[2..-1]
else
$content[commit] = true
end
end
$parent_check = Hash.new
$parent_cache = Hash.new
def commit_has_parent?(commit, commit2)
if $parent_check[commit]
print "parent loop for #{commit} (#{commit2})?\n"
p $parent_check
return false
end
return $parent_cache[commit] if $parent_cache.has_key?(commit)
$parent_check[commit] = true
res = false
if $content[commit] > $content[commit2]
$parent[commit].each do |parent|
if parent == commit2 || commit_has_parent?(parent, commit2)
res = true
break;
end
end
end
$parent_cache[commit] = res
$parent_check.delete(commit)
$parent_cache.clear if $parent_check.empty?
return res
end
def check_commit(commit)
return $result[commit] if $result.has_key? commit
a = Array.new
$parent[commit].each do |parent|
parent = check_commit(parent)
if parent
a.each_index do |i|
if a[i] == parent || commit_has_parent?(a[i], parent)
parent = nil
break
elsif commit_has_parent?(parent, a[i])
a[i] = parent
parent = nil
break
end
end
end
a.push(parent) if parent
end
$parent[commit] = a
$content[commit] = true if a.size > 1
if $content[commit]
$result[commit] = commit
max = 1
a.each do |parent|
max = $content[parent] + 1 if max <= $content[parent]
end
$content[commit] = max
else
$result[commit] = a[0]
end
return $result[commit]
end
check_commit(head)
#p $result
#p $parent
p $content.keys.size
$content.each_key do |commit|
p [ commit, $parent[commit] ]
commit = $parent[commit][0]
end
^ permalink raw reply
* Re: Cleaning up log messages
From: Johannes Schindelin @ 2008-07-27 18:01 UTC (permalink / raw)
To: Jon Smirl; +Cc: Git Mailing List
In-Reply-To: <9e4733910807271050y7fb5f77coec05bd68421baaab@mail.gmail.com>
Hi,
On Sun, 27 Jul 2008, Jon Smirl wrote:
> 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 KH <greg@kroah.com>
> Author: Greg KH <greg@press.(none)>
> Author: gregkh@suse.de <gregkh@suse.de>
> Author: Greg Kroah-Hartman <gregkh@suse>
> Author: Greg Kroah-Hartman <gregkh@suse.de>
> Author: Greg Kroah-Hartman <greg@kroah.com>
>
> I don't see an obvious way to do this with git, but it would be neat
> to have a 'clean' option on git log that would take each email address
> (author, signed-off, acked, etc) and map it through a table which
> would convert old email addresses in to the current one and also
> standardize the formatting of the names.
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)
Ciao,
Dscho
^ 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 18:11 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Christian Couder, git, Miklos Vajna
In-Reply-To: <alpine.DEB.1.00.0807271631470.5526@eeepc-johanness>
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.
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.
^ permalink raw reply
* Re: Cleaning up log messages
From: Jon Smirl @ 2008-07-27 18:16 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Git Mailing List
In-Reply-To: <alpine.DEB.1.00.0807272000270.5526@eeepc-johanness>
On 7/27/08, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> Hi,
>
>
> On Sun, 27 Jul 2008, Jon Smirl wrote:
>
> > 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 KH <greg@kroah.com>
> > Author: Greg KH <greg@press.(none)>
> > Author: gregkh@suse.de <gregkh@suse.de>
> > Author: Greg Kroah-Hartman <gregkh@suse>
> > Author: Greg Kroah-Hartman <gregkh@suse.de>
> > Author: Greg Kroah-Hartman <greg@kroah.com>
> >
> > I don't see an obvious way to do this with git, but it would be neat
> > to have a 'clean' option on git log that would take each email address
> > (author, signed-off, acked, etc) and map it through a table which
> > would convert old email addresses in to the current one and also
> > standardize the formatting of the names.
>
>
> 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?
--
Jon Smirl
jonsmirl@gmail.com
^ 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
* 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: 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: 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: 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: 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: [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: 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] 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
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