* 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: 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: [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: 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: 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
* 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: [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
* [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
* [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 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 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
* 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
* 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: 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: 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: [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: Running git gui on Windows.
From: Jurko Gospodnetić @ 2008-07-27 13:55 UTC (permalink / raw)
To: git
In-Reply-To: <g6hubi$8op$1@ger.gmane.org>
Hi.
> Is there a way to run git gui on Windows so it does not block the
> calling process?
>
> For example, when I run 'git gui' from the Windows Command Prompt, I
> would like to be able to continue using that same command prompt and not
> have it blocked until I exit the started git gui process.
>
> I am using msysgit on Windows XP SP3 and 'git --version' states 'git
> version 1.5.6.1.1071.g76fb'.
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?
Best regards,
Jurko Gospodnetić
^ permalink raw reply
* Running git gui on Windows.
From: Jurko Gospodnetić @ 2008-07-27 13:48 UTC (permalink / raw)
To: git
Hi.
Is there a way to run git gui on Windows so it does not block the
calling process?
For example, when I run 'git gui' from the Windows Command Prompt, I
would like to be able to continue using that same command prompt and not
have it blocked until I exit the started git gui process.
I am using msysgit on Windows XP SP3 and 'git --version' states 'git
version 1.5.6.1.1071.g76fb'.
Many thanks.
Best regards,
Jurko Gospodnetić
^ permalink raw reply
* [PATCH] t/t7001-mv.sh: Propose ability to use git-mv on conflicting entries
From: Petr Baudis @ 2008-07-27 13:47 UTC (permalink / raw)
To: git; +Cc: gitster
In-Reply-To: <20080727134142.GA10151@machine.or.cz>
Currently, git-mv will declare "not under source control" on an attempt
to move a conflicted index entry. This patch adds an expect_failure
testcase for this case, since this is an artificial restriction. (However,
the scenario is not critical enough for the author to fix right now.)
Signed-off-by: Petr Baudis <pasky@suse.cz>
---
I don't really know if it is ok to make "feature requests" like this by
adding failing testcases...
t/t7001-mv.sh | 27 +++++++++++++++++++++++++++
1 files changed, 27 insertions(+), 0 deletions(-)
diff --git a/t/t7001-mv.sh b/t/t7001-mv.sh
index 7e47931..241e9a2 100755
--- a/t/t7001-mv.sh
+++ b/t/t7001-mv.sh
@@ -173,6 +173,33 @@ test_expect_success 'git mv should not change sha1 of moved cache entry' '
rm -f dirty dirty2
+cat >multistage <<EOT
+100644 e69de29bb2d1d6434b8b29ae775ad8c2e48c5391 1 staged
+100755 e69de29bb2d1d6434b8b29ae775ad8c2e48c5391 2 staged
+100755 d00491fd7e5bb6fa28c517a0bb32b8b506539d4d 3 staged
+EOT
+
+# Rationale: I cannot git mv around a conflicted file. This is unnecessary
+# restriction in case another part of conflict resolution requires me to
+# move the file around.
+test_expect_failure 'git mv should move all stages of cache entry' '
+
+ rm -fr .git &&
+ git init &&
+ # git mv requires object to exist in working tree (bug?)
+ touch staged &&
+ git update-index --index-info <multistage &&
+ git ls-files --stage >lsf_output &&
+ test_cmp multistage lsf_output &&
+ git mv staged staged-mv &&
+ sed "s/staged/staged-mv/" <multistage >multistage-mv &&
+ git ls-files --stage >lsf_output &&
+ test_cmp multistage-mv lsf_output
+
+'
+
+rm -f multistage multistage-mv lsf_output staged
+
test_expect_failure 'git mv should overwrite symlink to a file' '
rm -fr .git &&
^ permalink raw reply related
* Re: [PATCHv2] git-mv: Keep moved index entries inact
From: Petr Baudis @ 2008-07-27 13:41 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v8wvpm9cl.fsf@gitster.siamese.dyndns.org>
On Fri, Jul 25, 2008 at 11:46:02PM -0700, Junio C Hamano wrote:
> Thanks. I think I've managed to fix the rename_index_entry_at() in a
> satisfactory way, and also made builtin-mv to allow "mv -f symlink file"
> and "mv -f file symlink".
Oh, sorry, I didn't realize there were still problems with the original
one, I would try it on my own in that case.
> So my take on the above test piece is that after:
>
> >moved
> mkdir dir
> >dir/file
> ln -s dir symlink
> git add moved dir symlink
>
> This should fail, as it is an overwrite:
>
> git mv moved symlink
>
> and with "-f", the command should simply remove symlink and replace it
> with a regular file whose contents come from the original "moved".
>
> IOW, what a symlink points at should not matter.
You convinced me, yes. (Especially since I started actually using
symlinks in some of my projects very recently and this would be the
exact semantic I would eventually expect as well.)
--
Petr "Pasky" Baudis
As in certain cults it is possible to kill a process if you know
its true name. -- Ken Thompson and Dennis M. Ritchie
^ permalink raw reply
* Re: Official Git Homepage change? Re: git-scm.com
From: Petr Baudis @ 2008-07-27 12:35 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Scott Chacon, git
In-Reply-To: <7v4p6dnv5k.fsf@gitster.siamese.dyndns.org>
On Fri, Jul 25, 2008 at 09:09:43PM -0700, Junio C Hamano wrote:
> For me personally, pages outside the wiki have never felt like "the
> official git homepage", not because the contents you prepared were
> inadequate, but because I did not see much community participation to help
> enrich it.
I agree; I think this might have been in part because the Wiki was so
easy to use and change; I did receive some patches, but not any
overwhelming amount.
> So I wish the new site success, but the definition of success from my
> point of view is not how many random visitors it will attract, but how
> well the site makes the contributors (both to git software itself, and to
> the site's contents) feel welcomed. Maybe in time it will become
> successful enough by _my_ definition of success, and I may recommend
> kernel.org folks to point at it from http://git.kernel.org/ (link with
> text "overview") if/when that happens, and I may start mentioning them in
> the "Note". We'll see.
The question is, however,is whether to make the _current_ overview link
target simply alias at the new site _now_, though. :-) It seems to be
a waste to maintain two websites in parallel, as well as actively harmful
and confusing for people interested in Git, as I tried to explain in
my other mail. That's why this subthread was born.
> > The negatives section writeup is longer, but in fact I think the
> > positives win here; I also have a bit of bad conscience about not giving
> > git.or.cz the amount of time it would deserve...
>
> Let me thank you for maintaining not just git.or.cz/ but also repo.or.cz/
> and the wiki.
Thanks, I appreciate this, though pretty much all of this sort of popped
up simply because I had root access to a bored server. ;-) Especially
wrt. the wiki, I think it's mainly Jakub Narebski who is keeping it
together content-wise and keeps bugging me if it falls apart
technically.
--
Petr "Pasky" Baudis
As in certain cults it is possible to kill a process if you know
its true name. -- Ken Thompson and Dennis M. Ritchie
^ permalink raw reply
* Re: Official Git Homepage change? Re: git-scm.com
From: Petr Baudis @ 2008-07-27 12:22 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Johannes Schindelin, Scott Chacon, git
In-Reply-To: <7v8wvok3f6.fsf@gitster.siamese.dyndns.org>
On Sat, Jul 26, 2008 at 09:37:01AM -0700, Junio C Hamano wrote:
> Petr Baudis <pasky@suse.cz> writes:
>
> > I don't know if this should have any immediate effect on how we
> > develop Git etc., but I think it is good to be aware of the fact that
> > silently, huge amount of "dark mass" Git projects is accumulating and
> > that Git is making headways in areas many of us were little aware of.
>
> The developer community and "dark matter" community are totally separate
> entities that do not interact with each other very much, and they will go
> their separate ways? I think it is inevitable for any project once it
> becomes popular enough.
I don't think this is inevitable. I think we are getting into this
position two few simple reasons:
(i) The traffic on the main list is simply too high for regular users
to keep up with. If we care to get more in touch with our users,
the solution might be to spread the word about the Git Users Google
Group more, and monitor it more actively.
(ii) The tone on the mailing list seems frequently unnecessarily
harsh. This was mentioned by some of the "dark matter" people (not Scott
himself) as the reason why didn't they announce their work on the
mailing list; fear of being flamed. Especially at the beginning of
summer when I "returned" after quite a while of inactivity, I perceived
this rather unfriendly tone rather strongly as well (not at me
personally, but reading replies to other people's contributions), though
I got kind of used to it quickly again. If we care to encourage postings
by "external" developers to the mailing list, we should keep the usual
strength of our criticism, but try to make the tone more encouraging.
> Where does this observation lead us in this "Official" git homepage
> discussion? Perhaps the conclusion would be that there does not have to
> be any _single_ official home? I dunno.
That is not good idea; this would only split the community further,
*and* create confusion as some people would be directed to homepage A,
others to homepage B, each would have its resources kept up-to-date
in different manner, ...
Also, we need someplace to link at from git itself:
README:Many Git online resources are accessible from http://git.or.cz/
gitweb/gitweb.perl:our $logo_url = "http://git.or.cz/";
In case of README, we could add another link easily, in case of gitweb,
much less so.
This ultimately comes down to what address would *you* write on
a piece of paper if someone walked to you on say, some conference
and asked you "I like Git, where can I learn more?" Or you could start
explaining how Git does not have a single homepage and start writing
multiple URLs noting the differences. Would that make good impression?
--
Petr "Pasky" Baudis
As in certain cults it is possible to kill a process if you know
its true name. -- Ken Thompson and Dennis M. Ritchie
^ permalink raw reply
* Re: git-scm.com
From: Petr Baudis @ 2008-07-27 11:37 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Scott Chacon, git
In-Reply-To: <7vsktwfu5z.fsf@gitster.siamese.dyndns.org>
On Sat, Jul 26, 2008 at 10:10:32AM -0700, Junio C Hamano wrote:
> "Scott Chacon" <schacon@gmail.com> writes:
>
> > On Fri, Jul 25, 2008 at 4:47 PM, Junio C Hamano <gitster@pobox.com> wrote:
> >> ...
> >> I find a tabular list like this list easier to read if it were sorted like
> >> this:
> >>
> >> A D G
> >> B E H
> >> C F
> >> ...
> >
> > I fixed the things you mentioned here, except for the list ordering,
> > only because I kinda think you big contributors should be at the top
> > there,...
>
> 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.
> The purpose of the list would most likely not to find somebody with high
> activity to contact for help (you would use the top list that is sorted by
> the commit count for that kind of thing). It would primarily be to give
> credit to everybody, and perhaps so that people on the contributor list
> can point at their own name and say "I helped them", or find somebody else
> they happen to know in the list.
>
> When a contributor used to have 8 commits and then adds 2 commits, that
> would move the name in the list by a dozen places or so with the current
> set of contributors. It would be much easier to locate one's own name
> among a huge list if the names are alphabetically sorted, not by commit
> count. When more people start to contribute, your name does not move so
> drastically. If you are Adam, you are likely to find yourself near the
> beginning of the list, if you are Scott, you are likely to find yourself
> near one fourth from the end of the list.
I don't think locating is any issue; the find function of browser is
very easy to use nowadays. I guess the purpose of the list would be
to show "I helped them this much" (i.e. "I'm high on the list"). I think
this would actually motivate contributors to move up in the ladder -
people are competitive; you might get wary about this kind of
motivation, but I believe that it is no bad thing, inherently. Heck, I
admit it does motivate even me a little, safely in the "Primary Authors"
section. :-) (These guys with their tools merged into git have unfair
advantage! You should add up also, uh, git-homepage, cogito and, um...
repo.git! *baby cry*</vanity>)
> 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)".
--
Petr "Pasky" Baudis
As in certain cults it is possible to kill a process if you know
its true name. -- Ken Thompson and Dennis M. Ritchie
^ permalink raw reply
* Re: [RFC] Git User's Survey 2008
From: Nguyen Thai Ngoc Duy @ 2008-07-27 11:24 UTC (permalink / raw)
To: Jakub Narebski; +Cc: Stephan Beyer, Robin Rosenberg, Johannes Schindelin, git
In-Reply-To: <200807261734.35239.jnareb@gmail.com>
On 7/26/08, Jakub Narebski <jnareb@gmail.com> wrote:
> On Thu, 24 July 2008, Jakub Narębski wrote:
>
> > On Thu, 24 July 2008, Stephan Beyer wrote:
> >> Jakub Narebski wrote:
> >>> Dnia środa 23. lipca 2008 16:54, Robin Rosenberg napisał
> >>>> onsdagen den 23 juli 2008 15.18.40 skrev Johannes Schindelin:
> >>>>> On Wed, 23 Jul 2008, Jakub Narebski wrote:
> >>>>>> On Wed, 23 Jul 2008, Johannes Schindelin wrote:
> >>>>>>> On Wed, 23 Jul 2008, Jakub Narebski wrote:
> >>>>>>>
> >>>>>>>> 04. Which programming languages you are proficient with?
> >>>>>>>> (The choices include programming languages used by git)
> >>>>>>>> (zero or more: multiple choice)
> >>>>>>>> - C, shell, Perl, Python, Tcl/Tk
> >>>>>>>> + (should we include other languages, like C++, Java, PHP,
> >>>>>>>> Ruby,...?)
> >> [...]
> >
>
> > If we want to provide larger number of programming languages to
> > chose from (with "other" as fallback), we could take for example
> > top 10 from the TIOBE index, or similar sites:
> > http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html (for July 2008)
> > http://lui.arbingersys.com/index.html (Language Usage Indicators, Jul 10, 2008)
> >
> > This would bring 'Visual Basic', and perhaps 'Assembly' and 'Lisp'
> > to the list of choices.
>
>
> Perhaps also consider GitHub's list of most popular languages
> http://github.com/blog/99-popular-languages
> (as mentioned in Petr 'Pasky' Baudis somewhere in git-scm.com thread)
> to take into account git popularity among web developers.
>
> This would add 'ERB' (or is it just subset of 'Ruby' as eRuby
> implementation?), and 'Common Lisp' (if 'Common Lisp', then
> probably also 'Scheme'/'Guile').
I have an impression that this 'erb' is a file extension for html file
with embedding ruby, used in ruby on rails. If so it's not worth
adding. If you are going to add Scheme, please remove Guile or you
have to list other Scheme implementations too.
> There is always free-form 'other'...
>
> --
> Jakub Narebski
> Poland
> --
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
--
Duy
^ permalink raw reply
* [PATCH] Documentation: clarify diff.external limitations
From: Anders Melchiorsen @ 2008-07-27 11:12 UTC (permalink / raw)
To: git; +Cc: gitster, Anders Melchiorsen
The diff.external examples pass a flag to gnu-diff, but that is not
actually supported.
Without the flag, diff will still complain about an extra operand
because git is passing 7 parameters to the external command.
Both of these are fixed by suggesting a diff-wrapper and pointing to
the description of the parameters passed.
Signed-off-by: Anders Melchiorsen <mail@cup.kalibalik.dk>
---
Documentation/config.txt | 10 ++++++----
Documentation/git-config.txt | 2 +-
2 files changed, 7 insertions(+), 5 deletions(-)
diff --git a/Documentation/config.txt b/Documentation/config.txt
index 798b551..1a13abc 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -92,7 +92,7 @@ Example
# Our diff algorithm
[diff]
- external = "/usr/local/bin/gnu-diff -u"
+ external = /usr/local/bin/diff-wrapper
renames = true
[branch "devel"]
@@ -563,9 +563,11 @@ diff.autorefreshindex::
diff.external::
If this config variable is set, diff generation is not
performed using the internal diff machinery, but using the
- given command. Note: if you want to use an external diff
- program only on a subset of your files, you might want to
- use linkgit:gitattributes[5] instead.
+ given command. Can be overridden with the `GIT_EXTERNAL_DIFF'
+ environment variable. The command is called with parameters
+ as described under "git Diffs" in linkgit:git[1]. Note: if
+ you want to use an external diff program only on a subset of
+ your files, you might want to use linkgit:gitattributes[5] instead.
diff.renameLimit::
The number of files to consider when performing the copy/rename
diff --git a/Documentation/git-config.txt b/Documentation/git-config.txt
index 697824c..28e1861 100644
--- a/Documentation/git-config.txt
+++ b/Documentation/git-config.txt
@@ -222,7 +222,7 @@ Given a .git/config like this:
; Our diff algorithm
[diff]
- external = "/usr/local/bin/gnu-diff -u"
+ external = /usr/local/bin/diff-wrapper
renames = true
; Proxy settings
--
1.5.4.3
^ permalink raw reply related
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