* [RFC/PATCH v3] merge-base: teach "git merge-base" to accept more than 2 arguments
From: Christian Couder @ 2008-07-28 4:50 UTC (permalink / raw)
To: git, Junio C Hamano, Johannes Schindelin; +Cc: Miklos Vajna, Jakub Narebski
Before this patch "git merge-base" accepted only 2 arguments, so
only merge bases between 2 references could be computed.
The purpose of this patch is to make "git merge-base" accept more
than 2 arguments, so that the merge bases between the first given
reference and all the other references can be computed.
This is easily implemented because the "get_merge_bases_many"
function in "commit.c" already implements the needed computation.
Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
---
Documentation/git-merge-base.txt | 27 +++++++++++++++--------
builtin-merge-base.c | 43 ++++++++++++++++++++++++-------------
commit.h | 2 +
3 files changed, 48 insertions(+), 24 deletions(-)
I only changed the code (according to what Dscho asked) not the
documentation in this version as I had not much time and I need
to think more about it.
diff --git a/Documentation/git-merge-base.txt b/Documentation/git-merge-base.txt
index 1a7ecbf..463c230 100644
--- a/Documentation/git-merge-base.txt
+++ b/Documentation/git-merge-base.txt
@@ -8,26 +8,35 @@ git-merge-base - Find as good common ancestors as possible for a merge
SYNOPSIS
--------
-'git merge-base' [--all] <commit> <commit>
+'git merge-base' [--all] <commit> <commit>...
DESCRIPTION
-----------
-'git-merge-base' finds as good a common ancestor as possible between
-the two commits. That is, 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.
+'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.
Given a selection of equally good common ancestors it should not be
relied on to decide in any particular way.
-The 'git-merge-base' algorithm is still in flux - use the source...
-
OPTIONS
-------
--all::
- Output all common ancestors for the two commits instead of
- just one.
+ Output all merge bases for the commits instead of just one. No
+ merge bases in the output should be an ancestor of another
+ merge base in the output. Each common ancestor of the first
+ commit and any of the other commits passed as arguments,
+ should be an ancestor of one of the merge bases in the output.
Author
------
diff --git a/builtin-merge-base.c b/builtin-merge-base.c
index 1cb2925..881363f 100644
--- a/builtin-merge-base.c
+++ b/builtin-merge-base.c
@@ -2,9 +2,11 @@
#include "cache.h"
#include "commit.h"
-static int show_merge_base(struct commit *rev1, struct commit *rev2, int show_all)
+static int show_merge_base(struct commit **rev, int rev_nr, int show_all)
{
- struct commit_list *result = get_merge_bases(rev1, rev2, 0);
+ struct commit_list *result;
+
+ result = get_merge_bases_many(rev[0], rev_nr - 1, rev + 1, 0);
if (!result)
return 1;
@@ -20,13 +22,21 @@ static int show_merge_base(struct commit *rev1, struct commit *rev2, int show_al
}
static const char merge_base_usage[] =
-"git merge-base [--all] <commit-id> <commit-id>";
+"git merge-base [--all] <commit-id> <commit-id>...";
+
+static struct commit *get_commit_reference(const char *arg)
+{
+ unsigned char revkey[20];
+ if (get_sha1(arg, revkey))
+ die("Not a valid object name %s", arg);
+ return lookup_commit_reference(revkey);
+}
int cmd_merge_base(int argc, const char **argv, const char *prefix)
{
- struct commit *rev1, *rev2;
- unsigned char rev1key[20], rev2key[20];
+ struct commit **rev;
int show_all = 0;
+ int rev_nr = 0;
git_config(git_default_config, NULL);
@@ -38,15 +48,18 @@ 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)
- return 1;
- return show_merge_base(rev1, rev2, show_all);
+
+ rev = xmalloc((argc - 1) * sizeof(*rev));
+
+ do {
+ struct commit *r = get_commit_reference(argv[1]);
+ if (!r)
+ return 1;
+ rev[rev_nr++] = r;
+ argc--; argv++;
+ } while (argc > 1);
+
+ return show_merge_base(rev, rev_nr, show_all);
}
diff --git a/commit.h b/commit.h
index 77de962..4829a5c 100644
--- a/commit.h
+++ b/commit.h
@@ -121,6 +121,8 @@ int read_graft_file(const char *graft_file);
struct commit_graft *lookup_commit_graft(const unsigned char *sha1);
extern struct commit_list *get_merge_bases(struct commit *rev1, struct commit *rev2, int cleanup);
+extern struct commit_list *get_merge_bases_many(struct commit *one,
+ int n, struct commit **twos, int cleanup);
extern struct commit_list *get_octopus_merge_bases(struct commit_list *in);
extern int register_shallow(const unsigned char *sha1);
--
1.6.0.rc0.43.g00eb.dirty
^ permalink raw reply related
* New mailmap file for the kernel
From: Jon Smirl @ 2008-07-28 4:45 UTC (permalink / raw)
To: Git Mailing List
[-- Attachment #1: Type: text/plain, Size: 1210 bytes --]
I made a new mailmap file for the kernel. I'll put it out on LKML tomorrow.
It takes a new philosophy, there is an entry for every email address
in the kernel git tree even if the name associated with it is correct.
I wrote a script and did a lot of manual editing to try and make sure
that every one's name was spelled consistently. There are probably
still some mistakes in it.
As a result of this clean up the number of unique contributors to the
kernel fell from 4,284 to 3,821. A total of 463 errors or about 12% of
all name/email pairs. We clearly need to do some validation.
Now that the file has every valid name/email in it is should be
possible to validate the name/email in all new commits. When a new
developer comes along we'll know it since they won't be in the file.
Maybe Linus will send them a welcome message.
If a developer gets a new email address they need to add a new line
with the address and their name being very careful to make it exactly
match their name that is already in the file. If they want to change
their name they need to make sure and change all copies identically.
Any ideas on how to best modify the scripts to achieve validation?
--
Jon Smirl
jonsmirl@gmail.com
[-- Attachment #2: .mailmap.bz2 --]
[-- Type: application/x-bzip2, Size: 69444 bytes --]
^ permalink raw reply
* Re: [PATCH 3/6] builtin-help: make it possible to exclude some commands in list_commands()
From: Junio C Hamano @ 2008-07-28 4:29 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Miklos Vajna, git
In-Reply-To: <7vljzmwvww.fsf@gitster.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>
>>> > +struct cmdnames {
>>> > + int alloc;
>>> > + int cnt;
>>> > + struct cmdname {
>>> > + size_t len;
>>> > + char name[1];
>>> > + } **names;
>>> > +};
>>>
>>> I thought we do this kind of thing using FLEX_ARRAY macro. Is there any
>>> reason its use is not appropriate here?
>>
>> I think that came up in the previous review round: the "name" member _is_
>> NUL-terminated, but could have a ".exe" suffix. The "len" member has the
>> length excluding ".exe".
>
> Sorry, but I do understand what you are trying to explain.
Yuck, stupid typo; s/do/do not/.
^ permalink raw reply
* Re: git-scm.com
From: Tom Werner @ 2008-07-28 3:11 UTC (permalink / raw)
To: git
In-Reply-To: <46a038f90807271619l69c085a7o58f50b7d64b7222d@mail.gmail.com>
On Sun, Jul 27, 2008 at 4:19 PM, Martin Langhoff
<martin.langhoff@gmail.com> wrote:
> 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.
As cofounder of GitHub I'd like to jump in and say a few words. I'm a
huge fan of git. HUGE. But that should already be obvious. We started
GitHub because we saw that git was a tremendously useful tool but was
missing a way to easily and flexibly share your public and private
code with other developers. That simple idea grew into what we now
like to call "Social Code Hosting."
I find it a bit confusing that some here seem to have a strong dislike
for GitHub. It's true that we haven't been active on the developer
list or in the #git channel on freenode, but we are constantly in
#github and have answered a *great* many questions from developers
that are new to git. At the same time, like Martin finally guesses, we
believe that our contribution to the git community is GitHub itself.
We provide free git hosting for over 16,000 open source repositories!
As mentioned earlier in the thread, the Ruby-Git binding that Scott
and I wrote has been open source from the beginning. While we did not
announce it here, we have publicized it in the Ruby circle (where,
presumably, people would most likely find it useful) and in fact there
are currently 28 forks and 138 watchers of the project. We've also
released albino, facebox, and github-services via GitHub. You can see
all the open source stuff we use at GitHub here:
http://github.com/github.
Perhaps it is the commercial aspect of GitHub that offends. The only
reason that GitHub is as featured and polished as it is, is because we
can make money from it. We hope to soon be working on GitHub full
time. There is no way this could have been possible if we did not
offer paid private repositories. A part of being a commercial
operation is making the main product closed source. One might argue
that we could still have GitHub as a service while making the code
open source, but the truth of the matter is that this is not in the
best interest of our future plans for the company.
I don't like the thought of being at odds with the git developer
community at all, and let me be the first to apologize if we've
offended anyone. It certainly is not our intention. Our goal with
GitHub is to help make git even better by offering a service that
helps people streamline their git workflows and discover projects that
may interest them. We're trying to give back to the community how we
know best: by offering kickass git hosting and associated
collaboration tools.
Having had to implement a git-daemon replacement that fit our needs, I
have some ideas on how to improve git-daemon and fetch-pack with
regards to error messages and logging. I'll be sure to bring those up
on this list. One thing you should probably understand about us is
that we're all about getting things done. Which is one reason we
weren't bothering everyone in here when we started GitHub. We like to
design from first principles, see how good we can do, and then get
feedback from the users. If you're a GitHub user (or have a reason why
you are *not* a GitHub user), we'd love to hear your feedback on ways
we can improve!
Tom Preston-Werner
github.com/mojombo
^ permalink raw reply
* Re: [PATCH 3/6] builtin-help: make it possible to exclude some commands in list_commands()
From: Junio C Hamano @ 2008-07-28 3:05 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Miklos Vajna, git
In-Reply-To: <alpine.DEB.1.00.0807280442330.5526@eeepc-johanness>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>> > +struct cmdnames {
>> > + int alloc;
>> > + int cnt;
>> > + struct cmdname {
>> > + size_t len;
>> > + char name[1];
>> > + } **names;
>> > +};
>>
>> I thought we do this kind of thing using FLEX_ARRAY macro. Is there any
>> reason its use is not appropriate here?
>
> I think that came up in the previous review round: the "name" member _is_
> NUL-terminated, but could have a ".exe" suffix. The "len" member has the
> length excluding ".exe".
Sorry, but I do understand what you are trying to explain.
Marking the flexible member at the end as "last_member[FLEX_ARRAY]" is
about a tiny bit of abstracting out how the exact decl syntax should look
like depending on the compiler.
For example, we have:
struct git_attr {
struct git_attr *next;
unsigned h;
int attr_nr;
char name[FLEX_ARRAY];
};
And h is _not_ the length of the name[] (it is a hash to help us find the
entry quickly). Jjust like "len" is not the length of the name[] in your
structure. In other words, marking as "last_member[FLEX_ARRAY]" does not
have anything to do with what other fields you have in the same structure.
Hmm, am I missing a bigger picture somewhere else?
^ permalink raw reply
* Re: [PATCH 3/6] builtin-help: make it possible to exclude some commands in list_commands()
From: Johannes Schindelin @ 2008-07-28 2:43 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Miklos Vajna, git
In-Reply-To: <7vr69ex00x.fsf@gitster.siamese.dyndns.org>
Hi,
On Sun, 27 Jul 2008, Junio C Hamano wrote:
> Miklos Vajna <vmiklos@frugalware.org> writes:
>
> > diff --git a/help.h b/help.h
> > index 0741662..85d3b74 100644
> > --- a/help.h
> > +++ b/help.h
> > @@ -1,7 +1,19 @@
> > #ifndef HELP_H
> > #define HELP_H
> >
> > +struct cmdnames {
> > + int alloc;
> > + int cnt;
> > + struct cmdname {
> > + size_t len;
> > + char name[1];
> > + } **names;
> > +};
>
> I thought we do this kind of thing using FLEX_ARRAY macro. Is there any
> reason its use is not appropriate here?
I think that came up in the previous review round: the "name" member _is_
NUL-terminated, but could have a ".exe" suffix. The "len" member has the
length excluding ".exe".
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH 3/6] builtin-help: make it possible to exclude some commands in list_commands()
From: Junio C Hamano @ 2008-07-28 1:36 UTC (permalink / raw)
To: Miklos Vajna; +Cc: git
In-Reply-To: <9cc2813166c8b20ffb411c3a28ad86665e60033b.1217207602.git.vmiklos@frugalware.org>
Miklos Vajna <vmiklos@frugalware.org> writes:
> diff --git a/help.h b/help.h
> index 0741662..85d3b74 100644
> --- a/help.h
> +++ b/help.h
> @@ -1,7 +1,19 @@
> #ifndef HELP_H
> #define HELP_H
>
> +struct cmdnames {
> + int alloc;
> + int cnt;
> + struct cmdname {
> + size_t len;
> + char name[1];
> + } **names;
> +};
I thought we do this kind of thing using FLEX_ARRAY macro. Is there any
reason its use is not appropriate here?
^ permalink raw reply
* Re: Bizarre missing changes (git bug?)
From: Roman Zippel @ 2008-07-28 1:29 UTC (permalink / raw)
To: Martin Langhoff; +Cc: Linus Torvalds, Tim Harper, git
In-Reply-To: <46a038f90807271625x35c561fdv6dc6b2c312f45fa1@mail.gmail.com>
Hi,
On Mon, 28 Jul 2008, Martin Langhoff wrote:
> 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.
You also have to keep in mind, that I haven't really hacked git before, so
I'm just trying to do something with the data I can somehow extract from
it. I seriously didn't thought that anyone wouldn't understand that the
code example was just a proof of concept.
> 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.
It also has to do with correctness, is performance more important than
correctness?
Part of the problem is, what is the correct history, as which it should be
displayed via the various interfaces by default.
bye, Roman
^ permalink raw reply
* Re: [PATCH] Documentation/git-ls-tree.txt: Add a caveat about prefixing pathspec
From: Junio C Hamano @ 2008-07-28 1:26 UTC (permalink / raw)
To: Petr Baudis; +Cc: git
In-Reply-To: <20080728004604.GF32184@machine.or.cz>
Petr Baudis <pasky@suse.cz> writes:
>> We may throw a dice or go with your version, I don't care *that* much
>> about this change, I just wouldn't make it personally.
>
> What is the status of this patch? :-) Dropped altogether?
Left behind on the far side of oblivion; I do not offhand recall what this
was about, sorry.
^ permalink raw reply
* Re: [PATCH] t/t7001-mv.sh: Propose ability to use git-mv on conflicting entries
From: Junio C Hamano @ 2008-07-28 1:21 UTC (permalink / raw)
To: Petr Baudis; +Cc: git, gitster
In-Reply-To: <7v4p6ayfmw.fsf@gitster.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
>> +# 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.
>
> Yes, I would agree this is a reasonable thing to support. Something like
> this patch, perhaps.
> ...
Just in case if somebody is inclined to test the patch and polish it into
a shape good enough for inclusion...
> @@ -177,7 +177,8 @@ int cmd_mv(int argc, const char **argv, const char *prefix)
> } else
> bad = "Cannot overwrite";
> }
> - } else if (cache_name_pos(src, length) < 0)
> + } else if (((pos = cache_name_pos(src, length)) < 0) &&
> + strcmp(active_cache[-1 - pos]->name, src))
There is a bug here; "-1 - pos" needs to be checked against active_nr
before strcmp().
^ permalink raw reply
* [PATCH 6/6] Add a new test for using a custom merge strategy
From: Miklos Vajna @ 2008-07-28 1:21 UTC (permalink / raw)
To: git
In-Reply-To: <cover.1217207602.git.vmiklos@frugalware.org>
Testing is done by creating a simple git-merge-theirs strategy which is
the opposite of ours. Using this in real merges is not recommended but
it's perfect for our testing needs.
Signed-off-by: Miklos Vajna <vmiklos@frugalware.org>
---
t/t7606-merge-custom.sh | 45 +++++++++++++++++++++++++++++++++++++++++++++
1 files changed, 45 insertions(+), 0 deletions(-)
create mode 100755 t/t7606-merge-custom.sh
diff --git a/t/t7606-merge-custom.sh b/t/t7606-merge-custom.sh
new file mode 100755
index 0000000..f295e56
--- /dev/null
+++ b/t/t7606-merge-custom.sh
@@ -0,0 +1,45 @@
+#!/bin/sh
+
+test_description='git-merge
+
+Testing a custom strategy.'
+
+. ./test-lib.sh
+
+cat > git-merge-theirs << EOF
+#!/bin/sh
+eval git read-tree --reset -u \\\$\$#
+EOF
+chmod +x git-merge-theirs
+PATH=.:$PATH
+export PATH
+
+test_expect_success 'setup' '
+ echo c0 > c0.c &&
+ git add c0.c &&
+ git commit -m c0 &&
+ git tag c0 &&
+ echo c1 > c1.c &&
+ git add c1.c &&
+ git commit -m c1 &&
+ git tag c1 &&
+ git reset --hard c0 &&
+ echo c2 > c2.c &&
+ git add c2.c &&
+ git commit -m c2 &&
+ git tag c2
+'
+
+test_expect_success 'merge c2 with a custom strategy' '
+ git reset --hard c1 &&
+ git merge -s theirs c2 &&
+ test "$(git rev-parse c1)" != "$(git rev-parse HEAD)" &&
+ test "$(git rev-parse c1)" = "$(git rev-parse HEAD^1)" &&
+ test "$(git rev-parse c2)" = "$(git rev-parse HEAD^2)" &&
+ git diff --exit-code &&
+ test -f c0.c &&
+ test ! -f c1.c &&
+ test -f c2.c
+'
+
+test_done
--
1.6.0.rc0.14.g95f8.dirty
^ permalink raw reply related
* [PATCH 4/6] builtin-merge: allow using a custom strategy
From: Miklos Vajna @ 2008-07-28 1:21 UTC (permalink / raw)
To: git
In-Reply-To: <cover.1217207602.git.vmiklos@frugalware.org>
Allow using a custom strategy, as long as it's named git-merge-foo. The
error handling is now done using is_git_command(). The list of available
strategies is now shown by list_commands().
Signed-off-by: Miklos Vajna <vmiklos@frugalware.org>
---
builtin-merge.c | 19 ++++++++++++-------
1 files changed, 12 insertions(+), 7 deletions(-)
diff --git a/builtin-merge.c b/builtin-merge.c
index e78fa18..cdbc692 100644
--- a/builtin-merge.c
+++ b/builtin-merge.c
@@ -22,6 +22,7 @@
#include "log-tree.h"
#include "color.h"
#include "rerere.h"
+#include "help.h"
#define DEFAULT_TWOHEAD (1<<0)
#define DEFAULT_OCTOPUS (1<<1)
@@ -77,7 +78,7 @@ static int option_parse_message(const struct option *opt,
static struct strategy *get_strategy(const char *name)
{
int i;
- struct strbuf err;
+ struct strategy *ret;
if (!name)
return NULL;
@@ -86,12 +87,16 @@ static struct strategy *get_strategy(const char *name)
if (!strcmp(name, all_strategy[i].name))
return &all_strategy[i];
- strbuf_init(&err, 0);
- for (i = 0; i < ARRAY_SIZE(all_strategy); i++)
- strbuf_addf(&err, " %s", all_strategy[i].name);
- fprintf(stderr, "Could not find merge strategy '%s'.\n", name);
- fprintf(stderr, "Available strategies are:%s.\n", err.buf);
- exit(1);
+ if (!is_git_command(name, "git-merge-")) {
+ fprintf(stderr, "Could not find merge strategy '%s'.\n\n", name);
+ list_commands("git-merge-", "strategies");
+ exit(1);
+ }
+
+ ret = xmalloc(sizeof(struct strategy));
+ memset(ret, 0, sizeof(struct strategy));
+ ret->name = xstrdup(name);
+ return ret;
}
static void append_strategy(struct strategy *s)
--
1.6.0.rc0.14.g95f8.dirty
^ permalink raw reply related
* [PATCH 1/6] builtin-help: make is_git_command() usable outside builtin-help
From: Miklos Vajna @ 2008-07-28 1:21 UTC (permalink / raw)
To: git
In-Reply-To: <cover.1217207602.git.vmiklos@frugalware.org>
Other builtins may want to check if a given command is a valid git
command or not as well. Additionally add a new parameter that specifies
a custom prefix, so that the "git-" prefix is no longer hardwired.
Useful for example to limit the search for "git-merge-*".
Signed-off-by: Miklos Vajna <vmiklos@frugalware.org>
---
Makefile | 1 +
help.c | 25 ++++++++++++++-----------
help.h | 6 ++++++
3 files changed, 21 insertions(+), 11 deletions(-)
create mode 100644 help.h
diff --git a/Makefile b/Makefile
index 798a2f2..351afd7 100644
--- a/Makefile
+++ b/Makefile
@@ -355,6 +355,7 @@ LIB_H += git-compat-util.h
LIB_H += graph.h
LIB_H += grep.h
LIB_H += hash.h
+LIB_H += help.h
LIB_H += list-objects.h
LIB_H += ll-merge.h
LIB_H += log-tree.h
diff --git a/help.c b/help.c
index 3cb1962..08188f5 100644
--- a/help.c
+++ b/help.c
@@ -418,11 +418,11 @@ static int is_executable(const char *name)
}
static unsigned int list_commands_in_dir(struct cmdnames *cmds,
- const char *path)
+ const char *path,
+ const char *prefix)
{
unsigned int longest = 0;
- const char *prefix = "git-";
- int prefix_len = strlen(prefix);
+ int prefix_len;
DIR *dir = opendir(path);
struct dirent *de;
struct strbuf buf = STRBUF_INIT;
@@ -430,6 +430,9 @@ static unsigned int list_commands_in_dir(struct cmdnames *cmds,
if (!dir)
return 0;
+ if (!prefix)
+ prefix = "git-";
+ prefix_len = strlen(prefix);
strbuf_addf(&buf, "%s/", path);
len = buf.len;
@@ -460,7 +463,7 @@ static unsigned int list_commands_in_dir(struct cmdnames *cmds,
return longest;
}
-static unsigned int load_command_list(void)
+static unsigned int load_command_list(const char *prefix)
{
unsigned int longest = 0;
unsigned int len;
@@ -469,7 +472,7 @@ static unsigned int load_command_list(void)
const char *exec_path = git_exec_path();
if (exec_path)
- longest = list_commands_in_dir(&main_cmds, exec_path);
+ longest = list_commands_in_dir(&main_cmds, exec_path, prefix);
if (!env_path) {
fprintf(stderr, "PATH not set\n");
@@ -481,7 +484,7 @@ static unsigned int load_command_list(void)
if ((colon = strchr(path, PATH_SEP)))
*colon = 0;
- len = list_commands_in_dir(&other_cmds, path);
+ len = list_commands_in_dir(&other_cmds, path, prefix);
if (len > longest)
longest = len;
@@ -505,7 +508,7 @@ static unsigned int load_command_list(void)
static void list_commands(void)
{
- unsigned int longest = load_command_list();
+ unsigned int longest = load_command_list(NULL);
const char *exec_path = git_exec_path();
if (main_cmds.cnt) {
@@ -551,9 +554,9 @@ static int is_in_cmdlist(struct cmdnames *c, const char *s)
return 0;
}
-static int is_git_command(const char *s)
+int is_git_command(const char *s, const char *prefix)
{
- load_command_list();
+ load_command_list(prefix);
return is_in_cmdlist(&main_cmds, s) ||
is_in_cmdlist(&other_cmds, s);
}
@@ -574,7 +577,7 @@ static const char *cmd_to_page(const char *git_cmd)
return "git";
else if (!prefixcmp(git_cmd, "git"))
return git_cmd;
- else if (is_git_command(git_cmd))
+ else if (is_git_command(git_cmd, NULL))
return prepend("git-", git_cmd);
else
return prepend("git", git_cmd);
@@ -712,7 +715,7 @@ int cmd_help(int argc, const char **argv, const char *prefix)
}
alias = alias_lookup(argv[0]);
- if (alias && !is_git_command(argv[0])) {
+ if (alias && !is_git_command(argv[0], NULL)) {
printf("`git %s' is aliased to `%s'\n", argv[0], alias);
return 0;
}
diff --git a/help.h b/help.h
new file mode 100644
index 0000000..73da8d6
--- /dev/null
+++ b/help.h
@@ -0,0 +1,6 @@
+#ifndef HELP_H
+#define HELP_H
+
+int is_git_command(const char *s, const char *prefix);
+
+#endif /* HELP_H */
--
1.6.0.rc0.14.g95f8.dirty
^ permalink raw reply related
* [PATCH 2/6] builtin-help: make list_commands() a bit more generic
From: Miklos Vajna @ 2008-07-28 1:21 UTC (permalink / raw)
To: git
In-Reply-To: <cover.1217207602.git.vmiklos@frugalware.org>
That function now takes two paramters to control the prefix of the
listed commands, and a second parameter to specify the title of the
table. This can be useful for listing not only all git commands, but
specific ones, like merge strategies.
Signed-off-by: Miklos Vajna <vmiklos@frugalware.org>
---
help.c | 18 ++++++++++--------
help.h | 1 +
2 files changed, 11 insertions(+), 8 deletions(-)
diff --git a/help.c b/help.c
index 08188f5..7a42517 100644
--- a/help.c
+++ b/help.c
@@ -506,23 +506,25 @@ static unsigned int load_command_list(const char *prefix)
return longest;
}
-static void list_commands(void)
+void list_commands(const char *prefix, const char *title)
{
- unsigned int longest = load_command_list(NULL);
+ unsigned int longest = load_command_list(prefix);
const char *exec_path = git_exec_path();
if (main_cmds.cnt) {
- printf("available git commands in '%s'\n", exec_path);
- printf("----------------------------");
- mput_char('-', strlen(exec_path));
+ printf("available %s in '%s'\n", title, exec_path);
+ printf("----------------");
+ mput_char('-', strlen(title) + strlen(exec_path));
putchar('\n');
pretty_print_string_list(&main_cmds, longest);
putchar('\n');
}
if (other_cmds.cnt) {
- printf("git commands available from elsewhere on your $PATH\n");
- printf("---------------------------------------------------\n");
+ printf("%s available from elsewhere on your $PATH\n", title);
+ printf("---------------------------------------");
+ mput_char('-', strlen(title));
+ putchar('\n');
pretty_print_string_list(&other_cmds, longest);
putchar('\n');
}
@@ -702,7 +704,7 @@ int cmd_help(int argc, const char **argv, const char *prefix)
if (show_all) {
printf("usage: %s\n\n", git_usage_string);
- list_commands();
+ list_commands("git-", "git commands");
printf("%s\n", git_more_info_string);
return 0;
}
diff --git a/help.h b/help.h
index 73da8d6..0741662 100644
--- a/help.h
+++ b/help.h
@@ -2,5 +2,6 @@
#define HELP_H
int is_git_command(const char *s, const char *prefix);
+void list_commands(const char *prefix, const char *title);
#endif /* HELP_H */
--
1.6.0.rc0.14.g95f8.dirty
^ permalink raw reply related
* [PATCH 3/6] builtin-help: make it possible to exclude some commands in list_commands()
From: Miklos Vajna @ 2008-07-28 1:21 UTC (permalink / raw)
To: git
In-Reply-To: <cover.1217207602.git.vmiklos@frugalware.org>
The supposed method is to build a list of commands to be excluded using
add_cmdname(), then pass the list as the new exclude parameter. If no
exclude is needed, NULL should be used.
Signed-off-by: Miklos Vajna <vmiklos@frugalware.org>
---
help.c | 24 ++++++++++--------------
help.h | 14 +++++++++++++-
2 files changed, 23 insertions(+), 15 deletions(-)
diff --git a/help.c b/help.c
index 7a42517..318d6d6 100644
--- a/help.c
+++ b/help.c
@@ -9,6 +9,7 @@
#include "common-cmds.h"
#include "parse-options.h"
#include "run-command.h"
+#include "help.h"
static struct man_viewer_list {
struct man_viewer_list *next;
@@ -300,16 +301,9 @@ static inline void mput_char(char c, unsigned int num)
putchar(c);
}
-static struct cmdnames {
- int alloc;
- int cnt;
- struct cmdname {
- size_t len;
- char name[1];
- } **names;
-} main_cmds, other_cmds;
+struct cmdnames main_cmds, other_cmds;
-static void add_cmdname(struct cmdnames *cmds, const char *name, int len)
+void add_cmdname(struct cmdnames *cmds, const char *name, int len)
{
struct cmdname *ent = xmalloc(sizeof(*ent) + len);
@@ -463,7 +457,7 @@ static unsigned int list_commands_in_dir(struct cmdnames *cmds,
return longest;
}
-static unsigned int load_command_list(const char *prefix)
+static unsigned int load_command_list(const char *prefix, struct cmdnames *exclude)
{
unsigned int longest = 0;
unsigned int len;
@@ -502,13 +496,15 @@ static unsigned int load_command_list(const char *prefix)
sizeof(*other_cmds.names), cmdname_compare);
uniq(&other_cmds);
exclude_cmds(&other_cmds, &main_cmds);
+ if (exclude)
+ exclude_cmds(&main_cmds, exclude);
return longest;
}
-void list_commands(const char *prefix, const char *title)
+void list_commands(const char *prefix, const char *title, struct cmdnames *exclude)
{
- unsigned int longest = load_command_list(prefix);
+ unsigned int longest = load_command_list(prefix, exclude);
const char *exec_path = git_exec_path();
if (main_cmds.cnt) {
@@ -558,7 +554,7 @@ static int is_in_cmdlist(struct cmdnames *c, const char *s)
int is_git_command(const char *s, const char *prefix)
{
- load_command_list(prefix);
+ load_command_list(prefix, NULL);
return is_in_cmdlist(&main_cmds, s) ||
is_in_cmdlist(&other_cmds, s);
}
@@ -704,7 +700,7 @@ int cmd_help(int argc, const char **argv, const char *prefix)
if (show_all) {
printf("usage: %s\n\n", git_usage_string);
- list_commands("git-", "git commands");
+ list_commands("git-", "git commands", NULL);
printf("%s\n", git_more_info_string);
return 0;
}
diff --git a/help.h b/help.h
index 0741662..85d3b74 100644
--- a/help.h
+++ b/help.h
@@ -1,7 +1,19 @@
#ifndef HELP_H
#define HELP_H
+struct cmdnames {
+ int alloc;
+ int cnt;
+ struct cmdname {
+ size_t len;
+ char name[1];
+ } **names;
+};
+
int is_git_command(const char *s, const char *prefix);
-void list_commands(const char *prefix, const char *title);
+void list_commands(const char *prefix, const char *title, struct cmdnames *exclude);
+void add_cmdname(struct cmdnames *cmds, const char *name, int len);
+
+extern struct cmdnames main_cmds, other_cmds;
#endif /* HELP_H */
--
1.6.0.rc0.14.g95f8.dirty
^ permalink raw reply related
* [PATCH 5/6] builtin-merge: avoid non-strategy git-merge commands in error message
From: Miklos Vajna @ 2008-07-28 1:21 UTC (permalink / raw)
To: git
In-Reply-To: <cover.1217207602.git.vmiklos@frugalware.org>
If an invalid strategy is supplied, like -s foobar, then git-merge
listed all git-merge-* commands. This is not perfect, since for example
git-merge-index is not a valid strategy.
These are now removed from the output by scanning the list of main
commands; if the git-merge-foo command is listed in the all_strategy
list, then it's shown, otherwise excluded. This does not exclude
commands somewhere else in the PATH, where custom strategies are
expected.
Signed-off-by: Miklos Vajna <vmiklos@frugalware.org>
---
builtin-merge.c | 15 ++++++++++++++-
1 files changed, 14 insertions(+), 1 deletions(-)
diff --git a/builtin-merge.c b/builtin-merge.c
index cdbc692..29826b1 100644
--- a/builtin-merge.c
+++ b/builtin-merge.c
@@ -88,8 +88,21 @@ static struct strategy *get_strategy(const char *name)
return &all_strategy[i];
if (!is_git_command(name, "git-merge-")) {
+ struct cmdnames not_strategies;
+
+ memset(¬_strategies, 0, sizeof(struct cmdnames));
+ for (i = 0; i < main_cmds.cnt; i++) {
+ int j, found = 0;
+ struct cmdname *ent = main_cmds.names[i];
+ for (j = 0; j < ARRAY_SIZE(all_strategy); j++)
+ if (!strncmp(ent->name, all_strategy[j].name, ent->len)
+ && !all_strategy[j].name[ent->len])
+ found = 1;
+ if (!found)
+ add_cmdname(¬_strategies, ent->name, ent->len);
+ }
fprintf(stderr, "Could not find merge strategy '%s'.\n\n", name);
- list_commands("git-merge-", "strategies");
+ list_commands("git-merge-", "strategies", ¬_strategies);
exit(1);
}
--
1.6.0.rc0.14.g95f8.dirty
^ permalink raw reply related
* [PATCH 0/6] Allow custom merge strategies, take 2
From: Miklos Vajna @ 2008-07-28 1:21 UTC (permalink / raw)
To: git
In-Reply-To: <cover.1217037178.git.vmiklos@frugalware.org>
Hi,
This is just a resend of my series, on top of Dscho's "Avoid chdir() in
list_commands_in_dir()" (f5d600e), including the suggestions I received
from Jonathan Nieder and Dscho.
Miklos Vajna (6):
builtin-help: make is_git_command() usable outside builtin-help
builtin-help: make list_commands() a bit more generic
builtin-help: make it possible to exclude some commands in
list_commands()
builtin-merge: allow using a custom strategy
builtin-merge: avoid non-strategy git-merge commands in error message
Add a new test for using a custom merge strategy
Makefile | 1 +
builtin-merge.c | 32 +++++++++++++++++++++------
help.c | 55 ++++++++++++++++++++++++-----------------------
help.h | 19 ++++++++++++++++
t/t7606-merge-custom.sh | 45 ++++++++++++++++++++++++++++++++++++++
5 files changed, 118 insertions(+), 34 deletions(-)
create mode 100644 help.h
create mode 100755 t/t7606-merge-custom.sh
^ permalink raw reply
* Re: [PATCH 1/7] Make is_git_command() usable outside builtin-help
From: Miklos Vajna @ 2008-07-28 1:18 UTC (permalink / raw)
To: Jonathan Nieder; +Cc: git
In-Reply-To: <Pine.GSO.4.62.0807261301300.15728@harper.uchicago.edu>
[-- Attachment #1: Type: text/plain, Size: 707 bytes --]
On Sat, Jul 26, 2008 at 01:12:36PM -0500, Jonathan Nieder <jrnieder@uchicago.edu> wrote:
> On Sat, 26 Jul 2008, Miklos Vajna wrote:
>
> > + if (!prefix)
> > + prefix = "git-";
> > + prefix_len = strlen(prefix);
>
> The whitespace gave me a start: the diff markup moved the prefix_len
> line to the next tab stop, so at first glance it seems there are missing
> braces here. But it is an illusion. (I mention this so others might
> avoid wasting time worrying about it.)
In fact it was a whitespace problem: somehow I used spaces there instead
of a tab. I fixed it locally. (Will send an updated series soon.)
> I like the patch so far. Thanks for the pleasant reading.
:-)
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: [PATCH] t/t7001-mv.sh: Propose ability to use git-mv on conflicting entries
From: Junio C Hamano @ 2008-07-28 1:13 UTC (permalink / raw)
To: Petr Baudis; +Cc: git, gitster
In-Reply-To: <20080727134704.27534.86520.stgit@localhost>
Petr Baudis <pasky@suse.cz> writes:
> I don't really know if it is ok to make "feature requests" like this by
> adding failing testcases...
Of course it depends on who you are. It's not Ok for somebody like you,
who is known to be competent, and certainly it is not Ok to do it on a
command that you know you care more about than I do.
I've neglected builtin-mv.c since its introduction, mostly because I never
say "git mv" myself (in other words, I haven't cared very much how broken
it was. For one thing, its indentation style is peculiar and is hard to
read and maintain).
> +# 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.
Yes, I would agree this is a reasonable thing to support. Something like
this patch, perhaps.
---
builtin-mv.c | 21 ++++++++++++++-------
t/t7001-mv.sh | 21 +++++++++++++++++++++
2 files changed, 35 insertions(+), 7 deletions(-)
diff --git a/builtin-mv.c b/builtin-mv.c
index 4f65b5a..cc9e505 100644
--- a/builtin-mv.c
+++ b/builtin-mv.c
@@ -96,7 +96,7 @@ int cmd_mv(int argc, const char **argv, const char *prefix)
/* Checking */
for (i = 0; i < argc; i++) {
const char *src = source[i], *dst = destination[i];
- int length, src_is_dir;
+ int length, src_is_dir, pos;
const char *bad = NULL;
if (show_only)
@@ -177,7 +177,8 @@ int cmd_mv(int argc, const char **argv, const char *prefix)
} else
bad = "Cannot overwrite";
}
- } else if (cache_name_pos(src, length) < 0)
+ } else if (((pos = cache_name_pos(src, length)) < 0) &&
+ strcmp(active_cache[-1 - pos]->name, src))
bad = "not under version control";
else if (string_list_has_string(&src_for_dst, dst))
bad = "multiple sources for the same target";
@@ -202,7 +203,6 @@ int cmd_mv(int argc, const char **argv, const char *prefix)
for (i = 0; i < argc; i++) {
const char *src = source[i], *dst = destination[i];
enum update_mode mode = modes[i];
- int pos;
if (show_only || verbose)
printf("Renaming %s to %s\n", src, dst);
if (!show_only && mode != INDEX &&
@@ -212,10 +212,17 @@ int cmd_mv(int argc, const char **argv, const char *prefix)
if (mode == WORKING_DIRECTORY)
continue;
- pos = cache_name_pos(src, strlen(src));
- assert(pos >= 0);
- if (!show_only)
- rename_cache_entry_at(pos, dst);
+ if (!show_only) {
+ while (1) {
+ int pos = cache_name_pos(src, strlen(src));
+ if (pos < 0)
+ pos = -1 - pos;
+ if ((active_nr <= pos) ||
+ strcmp(active_cache[pos]->name, src))
+ break;
+ rename_cache_entry_at(pos, dst);
+ }
+ }
}
if (active_cache_changed) {
diff --git a/t/t7001-mv.sh b/t/t7001-mv.sh
index b0fa407..d538f88 100755
--- a/t/t7001-mv.sh
+++ b/t/t7001-mv.sh
@@ -173,6 +173,27 @@ test_expect_success 'git mv should not change sha1 of moved cache entry' '
rm -f dirty dirty2
+cat >expect <<\EOT
+100644 e69de29bb2d1d6434b8b29ae775ad8c2e48c5391 1 staged
+100755 e69de29bb2d1d6434b8b29ae775ad8c2e48c5391 2 staged
+100755 d00491fd7e5bb6fa28c517a0bb32b8b506539d4d 3 staged
+EOT
+
+test_expect_success 'git mv should move all stages of cache entry' '
+ rm -fr .git &&
+ git init &&
+ >staged &&
+ git update-index --index-info <expect &&
+ git ls-files --stage >actual &&
+ test_cmp expect actual &&
+ git mv staged staged-mv &&
+ sed "s/staged/staged-mv/" <expect >expect-2 &&
+ git ls-files --stage >actual &&
+ test_cmp expect-2 actual
+'
+
+rm -f expect expect-2 staged actual staged-mv
+
test_expect_success 'git mv should overwrite symlink to a file' '
rm -fr .git &&
^ permalink raw reply related
* Re: [PATCH] Documentation/git-ls-tree.txt: Add a caveat about prefixing pathspec
From: Petr Baudis @ 2008-07-28 0:46 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <20080722224759.GJ32184@machine.or.cz>
On Wed, Jul 23, 2008 at 12:47:59AM +0200, Petr Baudis wrote:
> On Mon, Jul 21, 2008 at 05:32:20PM -0700, Junio C Hamano wrote:
> > Petr Baudis <pasky@suse.cz> writes:
> >
> > >> commit. E.g.
> > >>
> > >> $ cd some/deep/path
> > >> $ git ls-tree --name-only -r HEAD~20
> > >>
> > >> will list the files in some/deep/path (i.e. where you are) 20
> > >> commits ago, just like running "/bin/ls" there will give you the
> > >> list of files you have right now.
> > >
> > > Frankly, I think this is overdoing it. I'm all for being positive, but
> > > it is obvious why this is good thing when you inspect a root tree and
> > > there's no need to be too wordy about it...
> >
> > I mildly disagree.
>
> We may throw a dice or go with your version, I don't care *that* much
> about this change, I just wouldn't make it personally.
What is the status of this patch? :-) Dropped altogether?
Petr "Pasky" Baudis
^ permalink raw reply
* Re: GIT 1.6.0-rc1
From: Petr Baudis @ 2008-07-28 0:44 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vy73myim5.fsf@gitster.siamese.dyndns.org>
Hi,
On Sun, Jul 27, 2008 at 05:09:38PM -0700, Junio C Hamano wrote:
> Ok, so I tagged and pushed it out. There still is the "git mv" bugfix
> from Pasky that is parked in 'next' but other than that I think this is
> pretty much "it" for 1.6.0 feature-wise.
BTW, it seems that in the end, the bugfix made it to -rc1's master.
(Which is cool. :-)
Petr "Pasky" Baudis
^ permalink raw reply
* Update to "Peer Wire Guidelines" on GitTorrent RFC
From: Sam Vilain @ 2008-07-28 0:30 UTC (permalink / raw)
To: git; +Cc: gittorrent
During the development of GitTorrent, I was being asked questions that
led me to realise that there wasn't a very good overall view of how the
various proposed GitTorrent messages fit together to make fetches work.
So, I've written a whole lot more on this with a few paragraphs which I
hope will pull it all together. If you found the RFC previously
indigestable, try reading:
http://gittorrent.utsl.gen.nz/rfc.html#peer-wire-guidelines
If there are parts which still aren't clear, please ask questions and I
will aim to write more clarification to the specification.
Cheers!
Sam.
^ permalink raw reply
* Re: [PATCH 1/9] Makefile: Do not install a copy of 'git' in $(gitexecdir)
From: A Large Angry SCM @ 2008-07-28 0:18 UTC (permalink / raw)
To: Johannes Sixt; +Cc: Junio C Hamano, git
In-Reply-To: <1216667998-8879-2-git-send-email-johannes.sixt@telecom.at>
Johannes Sixt wrote:
[...]
>
> diff --git a/Makefile b/Makefile
> index 551bde9..cbab4f9 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -1335,6 +1335,7 @@ endif
> '$(DESTDIR_SQ)$(gitexecdir_SQ)/git$X'; \
> fi
> $(foreach p,$(BUILT_INS), $(RM) '$(DESTDIR_SQ)$(gitexecdir_SQ)/$p' && ln '$(DESTDIR_SQ)$(gitexecdir_SQ)/git$X' '$(DESTDIR_SQ)$(gitexecdir_SQ)/$p' ;)
> + $(RM) '$(DESTDIR_SQ)$(gitexecdir_SQ)/git$X'
> ifneq (,$X)
> $(foreach p,$(patsubst %$X,%,$(filter %$X,$(ALL_PROGRAMS) $(BUILT_INS) git$X)), $(RM) '$(DESTDIR_SQ)$(gitexecdir_SQ)/$p';)
> endif
This new action needs to be in a conditional to keep it from removing
the ONLY git executable when bindir and execdir are the same dir.
^ permalink raw reply
* GIT 1.6.0-rc1
From: Junio C Hamano @ 2008-07-28 0:09 UTC (permalink / raw)
To: git
Ok, so I tagged and pushed it out. There still is the "git mv" bugfix
from Pasky that is parked in 'next' but other than that I think this is
pretty much "it" for 1.6.0 feature-wise.
Major parts of the changes since 1.6.0-rc0 consists of documentation and
tests portability; there is nothing surprising nor scary.
Test tarballs and RPMs are also there. Please give it a good beating.
----------------------------------------------------------------
Changes since v1.6.0-rc0 are as follows:
Abhijit Menon-Sen (2):
git-gui: Look for gitk in $PATH, not $LIBEXEC/git-core
Clarify that "git log x.c y.h" lists commits that touch either file
Alex Riesen (1):
Allow pager of diff command be enabled/disabled
Alexander Gavrilov (4):
Fix pre-commit hooks under MinGW/MSYS
Add options to control the search for copies in blame.
Kill the blame back-end on window close.
Add a menu item to invoke full copy detection in blame.
Anders Melchiorsen (1):
Documentation: fix diff.external example
Björn Steinbrink (2):
index-pack.c: correctly initialize appended objects
rev-parse: Add support for the ^! and ^@ syntax
Brad King (1):
git-svn: teach dcommit about svn auto-props
Brandon Casey (7):
t/: Replace diff [-u|-U0] with test_cmp to allow compilation with old diff
t4116-apply-reverse.sh: use $TAR rather than tar
t3200,t7201: replace '!' with test_must_fail
t7502-commit.sh: rearrange test to make more portable
t/t4202-log.sh: add newline at end of file
Teach fsck and prune about the new location of temporary objects
perl/Makefile: update NO_PERL_MAKEMAKER section
Cesar Eduardo Barros (1):
Documentation/git-submodule.txt: fix doubled word
Daniel Barkalow (1):
In perforce, RCS keywords are case-sensitive
Jakub Narebski (1):
gitweb: More about how gitweb gets 'owner' of repository
Johannes Schindelin (9):
Rename .git/rebase to .git/rebase-apply
Rename path_list to string_list
Fix two leftovers from path_list->string_list
Ignore dirty submodule states in "git pull --rebase"
Add test to show that show-branch misses out the 8th column
sort_in_topological_order(): avoid setting a commit flag
builtin-commit: Two trivial style-cleanups
git daemon: avoid waking up too often
Avoid chdir() in list_commands_in_dir()
Johannes Sixt (12):
rebase -i: When an 'edit' stops, mention the commit
Makefile: Do not install a copy of 'git' in $(gitexecdir)
Makefile: Normalize $(bindir) and $(gitexecdir) before comparing
Record the command invocation path early
Fix relative built-in paths to be relative to the command invocation
Allow the built-in exec path to be relative to the command invocation path
Allow add_path() to add non-existent directories to the path
Windows: Make $(gitexecdir) relative
Windows: Make sure argv[0] has a path
Windows: Do not compile git-shell
git-gui: Fix "Stage/Unstage Line" with one line of context.
git-gui: "Stage Line": Treat independent changes in adjacent lines better
Jonathan Nieder (3):
git-diff(1): "--c" -> "--cc" typo fix
document that git-tag can tag more than heads
t6030 (bisect): work around Mac OS X "ls"
Junio C Hamano (13):
Update my e-mail address
Revert "make git-status use a pager"
tests: do not rely on external "patch"
stash save: fix parameter handling
builtin-branch.c: remove unused code in append_ref() callback function
builtin-branch.c: optimize --merged and --no-merged
Documentation: clarify diff --cc
ignore non-existent refs in dwim_log()
tests: propagate $(TAR) down from the toplevel Makefile
Makefile: fix shell quoting
Documentation: clarify how to disable elements in core.whitespace
make sure parsed wildcard refspec ends with slash
GIT 1.6.0-rc1
Lars Hjemli (3):
builtin-branch: remove duplicated code
builtin-branch: factor out merge_filter matching
builtin-branch: fix -v for --[no-]merged
Lee Marlow (2):
bash completion: Add long options for 'git rm'
bash completion: Add completion for 'git help'
Miklos Vajna (2):
builtin-merge: give a proper error message for invalid strategies in config
t7601: extend the 'merge picks up the best result' test
Nikolaj Schumacher (1):
Don't cut off last character of commit descriptions.
Olivier Marin (4):
git-am: remove dash from help message
parse-options: fix segmentation fault when a required value is missing
git am --skip: clean the index while preserving local changes
update test case to protect am --skip behaviour
P. Christeas (1):
svnimport: newer libsvn wants us to ask for the root with "", not "/"
Peter Valdemar Mørch (1):
send-email: find body-encoding correctly
Petr Baudis (4):
git-filter-branch.sh: Allow running in bare repositories
Documentation/git-filter-branch: teach "rm" instead of "update-index --remove"
git-mv: Remove dead code branch
git-mv: Keep moved index entries inact
Philippe Bruhat (1):
mailinfo: better parse email adresses containg parentheses
Pierre Habouzit (4):
builtin-merge: add missing structure initialization
git-submodule: move ill placed shift.
git-checkout: fix command line parsing.
git-checkout: improve error messages, detect ambiguities.
René Scharfe (5):
archive: add write_archive()
archive: move parameter parsing code to archive.c
archive: define MAX_ARGS where it's needed
archive: declare struct archiver where it's needed
archive: allow --exec and --remote without equal sign
SZEDER Gábor (2):
checkout: mention '--' in the docs
bash: offer only paths after '--' for 'git checkout'
Shawn O. Pearce (2):
git-gui: Correct 'Visualize Branches' on Mac OS X to start gitk
fsck: Don't require tmp_obj_ file names are 14 bytes in length
Stephan Beyer (7):
git-am: Add colon before the subject that is printed out as being applied
am --abort: Add to bash-completion and mention in git-rerere documentation
Make non-static functions, that may be static, static
Move launch_editor() from builtin-tag.c to editor.c
editor.c: Libify launch_editor()
git-am: Mention --abort in usage string part of OPTIONS_SPEC
git-reset: Let -q hush "locally modified" messages
Steve Haslam (2):
Propagate -u/--upload-pack option of "git clone" to transport.
Remove references to git-fetch-pack from "git clone" documentation.
Thomas Rast (2):
git-completion.bash: provide completion for 'show-branch'
bash completion: Add long options for 'git describe'
^ permalink raw reply
* 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
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