* Re: What is 'git BRANCH'?
From: Jurko Gospodnetić @ 2008-07-29 22:43 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano
In-Reply-To: <DEBF93FC-BA8D-4513-B4EE-A8648DA1D591@sb.org>
Hi all.
> On Jul 29, 2008, at 3:24 PM, Junio C Hamano wrote:
>
>> Jurko Gospodnetić <jurko.gospodnetic@docte.hr> writes:
>>
>>> Hi.
>>>
>>> I typed in "git BRANCH" by accident and got the error message:
>>> "fatal: cannot handle BRANCH internally".
>>>
>>> What does that mean?
>>>
>>> It is different from the usual "git: 'yada-yada' is not a
>>> git-command. See 'git --help'." message you get when you type in an
>>> incorrect command name.
>>
>> Just a guess; your git is installed on a case-challenged filesystem?
Thank you all for explaining this, and yes - this was detected on
Windows with a NTFS drive set to case-insensitive.
But, if something is running git-branch here... why does this
script/executable/whatever try to check the name it got called with? Why
does it not simply do its work no matter the name it got called with?
If I'm asking something to obvious here - feel free to send me back
to read the code... :-)
Best regards,
Jurko Gospodnetić
^ permalink raw reply
* Re: What is 'git BRANCH'?
From: Junio C Hamano @ 2008-07-29 22:39 UTC (permalink / raw)
To: Jurko Gospodnetić; +Cc: git
In-Reply-To: <7vej5cba6z.fsf@gitster.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> Jurko Gospodnetić <jurko.gospodnetic@docte.hr> writes:
>
>> Hi.
>>
>> I typed in "git BRANCH" by accident and got the error message:
>> "fatal: cannot handle BRANCH internally".
>>
>> What does that mean?
>>
>> It is different from the usual "git: 'yada-yada' is not a
>> git-command. See 'git --help'." message you get when you type in an
>> incorrect command name.
>
> Just a guess; your git is installed on a case-challenged filesystem?
Yeah, that must be it. This can happen on MacOS and Windows, I would
imagine.
-- >8 --
[PATCH] Fail on unknown command sensibly on case-challenged filesystems
The callchain on a case-challenged filesystem when the user runs "git
BRANCH" looks like this:
- main(): git BRANCH
- execv_dashed_external("BRANCH")
- execvp("git-BRANCH")
- main(): git-BRANCH
- prefixcmp("git-BRANCH", "git-")
- handle_internal_command()
struct cmd_struct commands[] does not have "BRANCH"
so it returns, instead of exiting.
When the "git wrapper" execs "git-BRANCH", if your filesystem knows
"branch" and "BRANCH" are different, execvp() would fail and we will see
the familiar error message from the git.c::main().
However, if execvp() succeeds, we feed an unknown command name to
handle_internal_command() and it triggers a different error message.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
git.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/git.c b/git.c
index 37b1d76..c99e769 100644
--- a/git.c
+++ b/git.c
@@ -448,7 +448,7 @@ int main(int argc, const char **argv)
cmd += 4;
argv[0] = cmd;
handle_internal_command(argc, argv);
- die("cannot handle %s internally", cmd);
+ help_unknown_cmd(cmd);
}
/* Look for flags.. */
^ permalink raw reply related
* Re: Git Community Book
From: Daniel Barkalow @ 2008-07-29 22:34 UTC (permalink / raw)
To: Scott Chacon; +Cc: git list
In-Reply-To: <d411cc4a0807290920p62f5d7e1r727a62ef2b4611fc@mail.gmail.com>
On Tue, 29 Jul 2008, Scott Chacon wrote:
> So I wanted to develop a really nice, easy to follow book for Git
> newcomers to learn git quickly and easily. One of the issues I
> remember having when learning Git is that there is a lot of great
> material in the User Guide, Tutorial, Tutorial 2, Everyday Git, etc -
> but they're all huge long documents that are sometimes difficult to
> come back to and remember where you were, and I didn't know which one
> to start with or where to find what I was looking for, etc.
It would be good to include stuff from
http://eagain.net/articles/git-for-computer-scientists/
Maybe only in inspiration, since it doesn't have an obvious license and
it's stylisticly more technical. But it would be nice to have diagrams of
"this is what git thinks of as history", possibly even arranging them like
gitk shows things (older downward, refs pointing in from the side).
In particular, I think it's really useful to show a commit graph with
branching and merging, and introduce refs as movable pointers to commits
in the graph, and local branches as refs that you move and tracking refs
as refs that copy values in other repositories.
I think you can even gloss of details of blobs and trees because they
pretty much work just like files and directories in a filesystem (except
that they take up much less storage in large quantities than you'd think).
The only potentially interesting things are (1) a blob names the inode,
not the dentry, so it's the file contents, not the name, mode, etc; and
(2) the permission bits are just 'x', we've got symlinks, there are no
owner/group or other attributes and "see also Submodules".
But I think that the section:
http://eagain.net/articles/git-for-computer-scientists/#history
should have an equivalent in any git documentation that can have diagrams,
and introducing a history diagram style early means that you can do a
bunch of simple pictures to explain operations like "git checkout -b foo"
or "git reset --hard HEAD^^" or "git checkout origin/master".
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* Re: What is 'git BRANCH'?
From: Kevin Ballard @ 2008-07-29 22:32 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jurko Gospodnetić, git
In-Reply-To: <7vej5cba6z.fsf@gitster.siamese.dyndns.org>
On Jul 29, 2008, at 3:24 PM, Junio C Hamano wrote:
> Jurko Gospodnetić <jurko.gospodnetic@docte.hr> writes:
>
>> Hi.
>>
>> I typed in "git BRANCH" by accident and got the error message:
>> "fatal: cannot handle BRANCH internally".
>>
>> What does that mean?
>>
>> It is different from the usual "git: 'yada-yada' is not a
>> git-command. See 'git --help'." message you get when you type in an
>> incorrect command name.
>
> Just a guess; your git is installed on a case-challenged filesystem?
From what I can tell, this happens when you execute one of the git-*
builtin binaries using a name that doesn't actually match the binary,
case-sensitively. When you type `git BRANCH` on OS X, git matches that
against the git-branch binary and executes it, but argv[0] contains
"git-BRANCH". When this is compared by the git-branch binary to the
list of internal commands, it comes up empty, and the fallback code
(to die with "fatal: cannot handle BRANCH internally") gets executed
instead.
In other words, this is identical to running `/usr/local/libexec/git-
core/git-BRANCH` or to doing something like `exec -a git-BRANCH /usr/
local/libexec/git-core/git-branch` (this example should work on any
filesystem).
-Kevin Ballard
--
Kevin Ballard
http://kevin.sb.org
kevin@sb.org
http://www.tildesoft.com
^ permalink raw reply
* Re: short log and email address
From: René Scharfe @ 2008-07-29 22:30 UTC (permalink / raw)
To: Jon Smirl; +Cc: Johannes Schindelin, Git Mailing List
In-Reply-To: <9e4733910807281157u44c08a59ld3bdc0416e8a1d03@mail.gmail.com>
Jon Smirl schrieb:
> On 7/28/08, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
>> Hi,
>>
>>
>> On Mon, 28 Jul 2008, Jon Smirl wrote:
>>
>> > Using the -e option in shortlog changes the results by spitting things
>> > out by email address instead of leaving them combined by name. That's
>> > probably not what you want. Instead you want everything combined by name
>> > and then display the most recent email address used.
>>
>>
>> What is so wrong with _not_ using -e (since you do not want to see the
>> email address stored in the commit message, and -e would be asking for
>> that _exactly_)?
>
> I wanted -e to give me the most recent email so that I would know how
> to sort the mailmap alias list.
<snip>
> If the name isn't in mailmap, tell them to make a patch adding their
> name or to change their name.
That makes sense if you want to list all contributors in .mailmap...
> If the name is there but the email is not the last one in the list,
> tell them to make a patch rearranging mailmap to reflect their current
> name/email.
... but why would you want to check if they used their respective email
entry that is sorted last in the file? A person might have multiple
current email addresses, e.g. someone could send patches for one
subsystem from work and patches for something else from home, as a hobby.
René
^ permalink raw reply
* Re: What is 'git BRANCH'?
From: Junio C Hamano @ 2008-07-29 22:24 UTC (permalink / raw)
To: Jurko Gospodnetić; +Cc: git
In-Reply-To: <g6o4vi$rap$1@ger.gmane.org>
Jurko Gospodnetić <jurko.gospodnetic@docte.hr> writes:
> Hi.
>
> I typed in "git BRANCH" by accident and got the error message:
> "fatal: cannot handle BRANCH internally".
>
> What does that mean?
>
> It is different from the usual "git: 'yada-yada' is not a
> git-command. See 'git --help'." message you get when you type in an
> incorrect command name.
Just a guess; your git is installed on a case-challenged filesystem?
^ permalink raw reply
* What is 'git BRANCH'?
From: Jurko Gospodnetić @ 2008-07-29 22:18 UTC (permalink / raw)
To: git
Hi.
I typed in "git BRANCH" by accident and got the error message:
"fatal: cannot handle BRANCH internally".
What does that mean?
It is different from the usual "git: 'yada-yada' is not a
git-command. See 'git --help'." message you get when you type in an
incorrect command name.
Just curious...
Best regards,
Jurko Gospodnetić
^ permalink raw reply
* [ANNOUNCE] GitStats development finished (WRT GSoC)
From: Sverre Rabbelier @ 2008-07-29 22:11 UTC (permalink / raw)
To: Git Mailinglist
Cc: Johannes Schindelin, Jakub Narebski, Junio C Hamano,
David Symonds, Shawn O. Pearce, Sam Vilain
Heya,
I leave to the USA this Friday, and because of US tax laws I would
have to pay an insane amount of tax for just 2 weeks of development. I
have agreed with my mentor a while a go that I would finish up GSoC
before I left, that way avoiding having to pay US taxes. (Over here in
the Netherlands I don't have to pay tax over the $4500 because I
didn't make >6000 euro this year, the joys of being a student.) As a
result it is quite clear what GitStats will look like at the end of my
GSoC. I am going to continue working on it though, I am especially
interested in getting the '--follow' part of 'git log' working in such
a way that it can be incorporated into GitStats. As such, here is a
summary of what GitStat is at the moment. From the documentation:
$ cat gitstats-*
syntax: stats.py author <options>
The purpose of the author module is to gather statistics
about authors, and to aggregate this information to provide
information about all the authors of a repo.
Currently the available metrics in the author module are
the following:
* Determine how many changes an author made (making a
distinction between lines added and lines deleted), and
record this per author, for all files in the repository.
It is possible to get this data for one specific author,
(although data for all authors will still be gathered,)
because the result is stored per author.
* Determine how many commits an author made that affected
a specific file. This metric is less granular, but a lot
faster. To retreive the more granular result, one could
simply iterate over the result of the above metric for
each author, and take only the data for the file one is
interested in.
* Aggregate the information from the first metric, adding
up the statistics from each author. This provides a more
general 'file activity' metric and is a nice example of
how an existing metric can be modified to do something
seemingly unrelated.
This module does not define any auxillery functions.
syntax: stats.py branch <options>
The purpose of the branch module is to gather statistics
about branches, or related to branches.
Currently the available metrics in the branch module are
the following:
* Which of the branch head does a commit belong to
What this metric does is walk down the ancestry of the
target commit and increase the 'dilution' by one or each
merge it finds. The exception applies that when following
the 'primary' parent of the merge (e.g., the branch
recorded as the one the merge commit was made on), the
dilution is not increased. As such, if the target commit
is made on a branch, and then later on it's dilution
is calculated, it will have 0 dilution for that branch.
The branch with the lowest dilution is deemed to be the
branch that the commit belongs to most.
Note: In git there is no 'main' branch, as such any and
all branches branches that 'branched off' after the
target commit will also have dilution 0.
It also defines the following auxillery functions:
* Retreive the name of a commit if it is a the head of a
branch. This can be seen as the reverse of 'rev-parse'
for branch heads. This is used internally to provide the
user with a sensible name when telling them which branch
a commit belongs to.
* List all the branches that contain a specific commit,
optionally searching through remote branches as well as
optionally not filtering at all. This is used internally
to not search through branches that do not contain the
target commit.
syntax: stats.py bug <options>
The purpose of the bug module is to gather statistics on
bugfixes within the content, and to aggregate this
information to provide with a report of the last N commits.
Currently the available metrics in the bug module are the
following:
* Determine whether a specific commit is a bugfix based on
other metrics. When one of the metrics is 'positive',
that is, it's return value indicates that the examined
commit is a bugfix, the 'bugfix rating' is increased by
a pre-configured amount. This amount can be specified per
metric, and can be set to '0' to ignore it.
* Aggregate the above metric over the past N commits. Also,
when running the above metric on more than one commit,
cache the result of calls to the git binary so that the
execution time is reduced. This means that the execution
time is not directly proportional to the size of the
repository. (Instead, there is a fixed 'start up' cost,
after which there is a 'per commit' cost, which is
relatively low.)
This module does not define any auxillery functions.
syntax: stats.py commit <options>
The purpose of the commit module is to gather statistics
about commits, or related to commits, with the exception
of things related to diffs (only retrieving the raw diff is
in this module).
Currently the available metrics in the author module are
the following:
* Find all the commits that touched the same paths as the
specified commit. This is implemented by passing the
result of the 'paths touched' auxillary function to the
'commits that touched' auxillary function. See below.
* Retrieve the diff of a commit, either with or without
context, and optionally ignoring whitespace changes. This
method also works for the root commit (by making use of
the '--root' option to 'diff tree'.
* Show only commits of which the commit message, and/or the
commit diff, match a specific regexp. This is a simple
reimplementation of 'git log -S' and 'git log --grep'. It
is preferable to instead use the options native to
'git log', than to use this slower version.
Note: the regexps for the 'commit message' and the
'commit diff' may be different.
It also defines the following auxillary functions:
* Print a commit in a 'readable' way, this is by default
'git log -1 --name-only'. By the way of an environmental
variable ('GIT_STATS_PRETTY_PRINT'), it can be made to
instead use 'git log -1 --prety=oneline' by setting the
variable to 'online'.
* Retrieve all the paths that a specific commit touches,
this is used internally to limit the commits that have
to be searched when looking for a merge. That is done by
passing the output of this method to the one described
below.
* Find all commits that touched a list of files, optionally
treating the paths as relative to the current working
directory.
syntax: stats.py diff <options>
The purpose of the diff module is to gather statistics
about diffs, or related to diffs.
Currently the available metrics in the diff module are the
following:
* Determine whether two commit diffs are equal, optionally
checking whether they are reverts instead. It is also
possible to just look at what lines were changed (and
ignore the actual changes).
* Find all commits that are reverted by the specified
commit by first retrieving the touched files, and then
examining all the commits that that touch the same files.
It also defines the following auxillery functions:
* Parse a raw commit diff and store it on a hunk-by-hunk
basis so that later on it can be examined more carefully
by other tools. Line numbers are optionally included so
that one can use those. For example, by comparing all the
added hunks with the deleted hunks of a second commit,
and vise versa, one can check for (partial) reverts.
syntax: stats.py index <options>
The purpose of the index module is to gather statistics
about the index, or related to the index.
Currently the available metrics in the index module are the
following:
* List all the commits that touch the same files as the
staged files. This can be useful to find out which commit
introduced the bug fixed in this commit (by piping the
output of this method to one that looks at which lines
were touched for example).
It also defines the following auxillery functions:
* Get all the staged changes (optionally ignoring newly
added files). This is used internally to find all the
commits that touched the same files as those that are
currently staged.
syntax: stats.py matcher <options>
The purpose of the matcher module is to compare hunks
within one diff to one another, and determine whether there
is any code being moved around.
Currently the available metrics in the index module are the
following:
* Try to find a match between the hunks in one diff, so
that code moves can be detected. This makes use of the
'diff size calculation' described below.
It also defines the following auxillery functions:
* Calculate the size of a diff, only counting the amount
of lines added, and the amount of lines deleted. This can
be used to determine a best 'interdiff' (the shortest one
is the best one), when searching for two hunks that are
moved around.
syntax: stats.py <subcommand> <arguments>
Available commands:
author Activity for one author, file, or project
branch In how far a commit belongs to a branch
bug Determine whether a commitis a bugfix
commit Basic functionality already present in git
diff Compare two diffs and find reverts
index Find which commits touched the staged files
matcher Try to match hunks in a diff to find moves
test Run the unittests for GitStats
The stats.py module is the main entry point of GitStats,
it dispatches to the commands listed above. When no
arguments are passed, it automatically runs the command
with '--help' so that a usage message is shown for that
command.
Each of the modules it uses as subcommands defines a
'dispatch' function that is called with the users arguments
(with the exception of the first, which is the name of the
command executed). If anything should be returned to the
system, the dispatch method should return this value.
To run properly it requires the git_stats package to be
a subdirectory of the directory it resides in. That is,
your directory tree should be something like this:
.
|-- git_stats
| `-- <listing of all installed modules>
|-- scripts
| `-- <listing of all installed scripts>
|-- t
| `-- <listing of all installed regression tests>
`-- stats.py
syntax: stats.py tests <options>
The purpose of the tests module is to make available the
unittests for GitStats to external programs. It may be
used to run the unittests for GitStats from for example
a shell script. It's output is made to match the git
regression test suite.
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* Re: [PATCH] Make it clear that push can take multiple refspecs
From: Junio C Hamano @ 2008-07-29 22:06 UTC (permalink / raw)
To: Abhijit Menon-Sen; +Cc: git
In-Reply-To: <20080729212808.GA27076@toroid.org>
Abhijit Menon-Sen <ams@toroid.org> writes:
> At 2008-07-29 13:54:35 -0700, gitster@pobox.com wrote:
>>
>> Doesn't this already say you can have zero or more refspecs?
>
> It does, of course, but I've seen more than one question about how to do
> it now, even from people who looked at the manpage, and it seemed to me
> that adding an example wouldn't hurt.
Adding an example would help to certain point, but beyond that certain
point it becomes unnecessary noise that talks the obvious. If you saw the
question asked many times in the real world, that would be a good
indication that this patch falls into the "helpful" category, not "noise".
Will queue.
I wonder if there are other manual pages with <thing>... notation that
benefits from similar changes, though.
Thanks.
^ permalink raw reply
* Re: GIT 1.6.0-rc1
From: Junio C Hamano @ 2008-07-29 22:03 UTC (permalink / raw)
To: Alex Riesen; +Cc: git
In-Reply-To: <20080729211745.GA3879@blimp.local>
Alex Riesen <raa.lkml@gmail.com> writes:
> Junio C Hamano, Tue, Jul 29, 2008 10:36:19 +0200:
>> Junio C Hamano <gitster@pobox.com> writes:
>> >
>> > Ok, I took a deeper look at the codepaths involved. Although it does work
>> > around the issue, I do not think your patch alone is the "correct" one in
>> > the longer term.
>
> Thought so. I just didn't know the code around
>
>> > It needs a bit of explanation, and the explanation won't be exactly
>> > "plain, small and short", unfortunately.
>>
>> Alex, I ran the full test with this, but only on Linux boxes; obviously
>> not on any flavor of Windows. I think it is correct, and the "first line
>> of defence" fix is the same as your patch, so I'd assume it would work for
>> you as well. But extra eyeballs are always appreciated.
>
> Well, it works on Cygwin too. And I had my eyeballs on the code
> (wondered first if it will cause more fs accesses than before: it
> will, in the racy check. Which is correct, AFAICT)
I thought racy check won't even trigger for gitlinks, no?
ce_modified_check_fs() has 3 call sites:
- the call site in ie_match_stat() is protected with is_racy_timestamp()
that is always false for gitlinks;
- the call site in ie_modified() we just took care of in the current
thread;
- the other call site is in ce_smudge_racily_clean_entry(), which is
called from write_index() but it also is protected with
is_racy_timestamp() that is always false for gitlinks.
^ permalink raw reply
* Re: [PATCH] Make it clear that push can take multiple refspecs
From: Abhijit Menon-Sen @ 2008-07-29 21:28 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vbq0gcsxg.fsf@gitster.siamese.dyndns.org>
At 2008-07-29 13:54:35 -0700, gitster@pobox.com wrote:
>
> Doesn't this already say you can have zero or more refspecs?
It does, of course, but I've seen more than one question about how to do
it now, even from people who looked at the manpage, and it seemed to me
that adding an example wouldn't hurt.
-- ams
^ permalink raw reply
* [PATCH 3/5] builtin-help: make it possible to exclude some commands in list_commands()
From: Miklos Vajna @ 2008-07-29 21:25 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vabg0eamk.fsf@gitster.siamese.dyndns.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>
---
On Tue, Jul 29, 2008 at 12:46:59PM -0700, Junio C Hamano <gitster@pobox.com> wrote:
> You require that exclude is a sorted list; this should be documented
> somewhere to avoid future misuses.
This version now adds a comment in load_command_list() about this.
help.c | 27 ++++++++++++---------------
help.h | 14 +++++++++++++-
2 files changed, 25 insertions(+), 16 deletions(-)
diff --git a/help.c b/help.c
index 7a42517..26aa3e0 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,18 +301,11 @@ 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);
+ struct cmdname *ent = xmalloc(sizeof(*ent) + len + 1);
ent->len = len;
memcpy(ent->name, name, 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,16 @@ 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)
+ /* Here we require that exclude is a sorted list. */
+ 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 +555,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 +701,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..3eb8cfb 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[FLEX_ARRAY];
+ } **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
* Re: [PATCH v2] Advertise the ability to abort a commit
From: Anders Melchiorsen @ 2008-07-29 21:19 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vfxpsct3f.fsf@gitster.siamese.dyndns.org>
Junio C Hamano wrote:
> Anders Melchiorsen <mail@cup.kalibalik.dk> writes:
>
>> - die("no commit message? aborting commit.");
>> + die("no commit message. aborting commit.");
> [...]
> If the change _were_ to reword the message to more neutral sounding
> "aborting commit due to missing log message.", and change die() to a
> normal exit, that would be making this not an error. As I already said, I
> am mildly negative, but at least such a change would be internally
> consistent.
>
> I sense that the change from question mark to full stop might be showing
> the desire to go in that direction, but in that case your change from the
> question mark to full stop does not go far enough.
I took the question mark to mean that Git was confused about an empty
message. That does not seem right when Git itself proposes it.
I would be happy to also change it to a normal exit. However, since you do
not like the change, let us just forget about that hunk.
Cheers,
Anders.
^ permalink raw reply
* Re: GIT 1.6.0-rc1
From: Alex Riesen @ 2008-07-29 21:17 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vljzlhyt8.fsf@gitster.siamese.dyndns.org>
Junio C Hamano, Tue, Jul 29, 2008 10:36:19 +0200:
> Junio C Hamano <gitster@pobox.com> writes:
> >
> > Ok, I took a deeper look at the codepaths involved. Although it does work
> > around the issue, I do not think your patch alone is the "correct" one in
> > the longer term.
Thought so. I just didn't know the code around
> > It needs a bit of explanation, and the explanation won't be exactly
> > "plain, small and short", unfortunately.
>
> Alex, I ran the full test with this, but only on Linux boxes; obviously
> not on any flavor of Windows. I think it is correct, and the "first line
> of defence" fix is the same as your patch, so I'd assume it would work for
> you as well. But extra eyeballs are always appreciated.
Well, it works on Cygwin too. And I had my eyeballs on the code
(wondered first if it will cause more fs accesses than before: it
will, in the racy check. Which is correct, AFAICT)
^ permalink raw reply
* Re: [PATCH] Respect crlf attribute even if core.autocrlf has not been set
From: Eyvind Bernhardsen @ 2008-07-29 21:17 UTC (permalink / raw)
To: Dmitry Potapov
Cc: Johannes Schindelin, Avery Pennarun, Joshua Jensen,
Junio C Hamano, git
In-Reply-To: <20080729134619.GB7008@dpotapov.dyndns.org>
On 29. juli. 2008, at 15.46, Dmitry Potapov wrote:
> On Fri, Jul 25, 2008 at 11:05:33PM +0200, Eyvind Bernhardsen wrote:
>
> You clearly want *enforcing* and versioning for you is just means to
> do
> that. Regardless, what is the best way to achieve that, the *main*
> question is whether we want this enforcing and if yet then in what
> form
> and to what degree...
The versioning has nothing to do with the enforcing per se, it just
makes it possible to convert a repository with CRLFs to one that's LF-
only without having to rewrite history. See below.
>>> If we had core.autocrlf=input as default then clueless users will
>>> not
>>> checkin files with the incorrect ending. But there is an objection
>>> to
>>> that -- you penalize those who always have good endings. And even
>>> the
>>> fact that is merely default value that you can easily change to
>>> false
>>> does not convince everyone.
>>
>> That is an excellent argument for why setting "autocrlf=true" by
>> default on Windows was a bad idea. Thanks! :)
>
> I am sorry, but I don't see connection here.
My point was that autocrlf penalises Windows users just as much as it
does Linux users, so why should it be turned on by default on
Windows? But I've promised not to complain any more about this until
I have cold, hard code to back me up.
> Again, why should people who do not use Windows and other CR-damaged
> tools be penalized? No one can prevent me from putting in *my* own
> repository whatever I want anyway. Thus, if we agreed having this
> conversion/check is useful, remaining questions are:
> 1. whether this check should be possible to turn off
> 2. whether this check should be turned off by default for people
> who use Git on other system than Windows?
> The current status is:
> 1. Yes, it is possible to turn of this conversion
> 2. It is turned off by default for anyone but MSYS/GIT users.
>
> And the main argument for having that in this way is that people
> with LF
> text files should be unnecessary penalized for Windows being
> different.
I know, but my point is that I don't like to be unnecessarily
penalised any more when I am using Windows than when I'm using Linux
or OS X. I would like the default to be "no conversion", and for
conversion to be enabled not based on platform, but as a policy
decision on the repositories where it actually matters.
You can have anything you like in _your_ repository, of course, but if
you're not publishing it anywhere, who cares what your line endings
are? Your line endings only matter when you publish. That's why I
want a setting that is propagated: so that when you clone a repository
with a LF-only policy, Git knows what to do.
>> As you say, the reason I want the setting to be per-repository is
>> that
>> I don't think the cost is worthwhile for every repository.
>
> Side note: Personally, I am not very concerned about this cost, but
> some
> people are...
Yeah :)
I think the real penalty is that with autocrlf enabled, Git no longer
stores exactly what I committed.
>> The case
>> where it _is_ worthwhile is when the repository will be shared
>> between
>> Windows users and Linux users, and the Windows users want CRLFs in
>> their working directories. I think it's worthwhile to actually make
>> Git work right in that case.
>
> Windows users who want CRLF should set autocrlf=true
> Windows users who prefer LF should set autocrlf=input
> Non-Windows users who copy file directly from Windows should also
> set autocrlf=input
> All other users who do not touch Windows may have autocrlf=false.
>
> Files that do not need conversion (such as *.bat) should be marked as
> "-crlf" in .gitattributes.
Yes, and I see you checked that "crlf=input" does actually work when
you want LF-only, sorry about that. The syntax is _horrible_, though.
> Of course, those who are very careful and have good editors can set
> autocrlf=false even on Windows...
Right, or who know that the repository they're using will only be
shared with other Windows users. But with "autocrlf=false" in their
config, they would have to remember to set "autocrlf=true" in .git/
config in any new repositories they want to share with Linux users.
I'd like to make that per-repository configuration automatic.
>> As a side note, there's a lot of complaining about the cost of
>> enforcing LF-only input, but I can't remember seeing any actual
>> numbers. Is it really that bad?
>
> No, it is not bad. In most practical cases, you will not notice any
> difference. I've posted some numbers in this thread. You can find
> them here:
> http://article.gmane.org/gmane.comp.version-control.git/89908
Oh, thanks! I missed that post, and I agree that those numbers don't
look particularly worrying.
[...]
>>> but there are people who do not want to pay any price for
>>> conversion.
>>> Currently, "core.autocrlf=false" means to do nothing about end-of-
>>> lines,
>>> and even to ignore setting in .gitattributes. Should it be
>>> possible to
>>> disable *any* conversion on checkin and checkout? Should this be
>>> that
>>> value be the default, which most users use?
>>
>> Well, there's no reason why Git repositories used only on Windows
>> machines shouldn't store CRLFs, so why should all msysgit users pay
>> the cost on every checkin _and_ checkout?
>
> 1. You may want to use on other platforms later. In any case, it makes
> much sense to have the default that compatible with other systems.
This is why I want the setting to be versioned. If you decide to
share with other platforms later, you just enable the setting and "git
commit -a" (untested! Recursive touching is probably required
first). No history has to be rewritten, and new checkouts will work
properly (as will old checkouts, but for a slightly different value of
"properly").
> 2. Conversion cost is not significant (I suppose much less than gzip
> compression used for all objects) and it also saves some space.
> 3. Internally, Git considers only LF as true end of line. CR is just
> like an extra space before end-of-line. Is any good reason to have
> it inside of your repo anyway?
Internally, Git doesn't really care, does it? The only reason to keep
the line endings I committed is "because that's what I committed", but
I think it's quite a good reason.
> 4. This is what other VCSes do on Windows. CVS converts all text files
> on checkin. SVN does the same for files having svn:eol-style=native.
Heh. Where I work, we hacked CVS for Windows to get away from that
behaviour :)
> In fact, if you read the discussion we had here some time ago, you may
> find some other arguments too.
Yep, but I think I'm doing this backwards. Instead of rehashing old
arguments, I need to implement something that does what I want and let
the list decide if it's useful or not.
>> This is the reason the setting needs to be a per-repository policy
>> and
>> not a user configuration;
>
> What exactly?
>
>
>> users should not be able to configure away
>> correctness,
>
> Why not? *Every* user has him/her own repository, so he/she can do
> *anything* with it, in principle.
>
>> but they shouldn't be penalised unnecessarily for it,
>> either.
>
> The problem is how to determine when it is necessary and when it is
> not. If I never commit with wrong EOLs, I don't think it is necessary
> for me to have this conversion... On the other hand, I don't mind
> having
> this check as default. It does not really bother me much, and if I
> can
> turn it off, it is fine with me. But I suppose other people may feel
> differently about this issue.
Well, what I want is to be able to say "it is necessary to do eol
conversion in this repository", allowing the default to be "don't do
eol conversion" on Windows, too. For a setting like that to be
useful, it has to be propagated when the repository is cloned.
I want it to be versioned because you might want to change it without
messing with the content that's already in the repository. This is
actually my main motivation, since I have lots of CRLF-infused CVS
history to deal with.
It should apply on Linux as well as Windows because there is always
the chance that a user will manage to commit a CRLF on Linux (a
colleague of mine once complained that CVS on Linux doesn't do eol
conversion; he edited files on Windows, but checked them in on
Linux). It would probably be okay to have a setting that turns all
conversion off, but wouldn't that be kind of rude?
Thanks, all, for your help in getting my ideas straight; now to find
out if I'm coder enough to implement them. If not, I'll just stick
with setting "autocrlf=false" on Windows and stop whining.
--
Eyvind Bernhardsen
^ permalink raw reply
* Re: [PATCH] `git submodule add` now requires a <path>
From: Junio C Hamano @ 2008-07-29 20:58 UTC (permalink / raw)
To: Abhijit Menon-Sen; +Cc: git
In-Reply-To: <1217361196-25143-1-git-send-email-ams@toroid.org>
Thanks.
^ permalink raw reply
* Re: [PATCH] Make it clear that push can take multiple refspecs
From: Junio C Hamano @ 2008-07-29 20:54 UTC (permalink / raw)
To: Abhijit Menon-Sen; +Cc: git, gitster
In-Reply-To: <1217362159-25440-1-git-send-email-ams@toroid.org>
Abhijit Menon-Sen <ams@toroid.org> writes:
> Signed-off-by: Abhijit Menon-Sen <ams@toroid.org>
> ---
> Documentation/git-push.txt | 10 ++++++++--
> 1 files changed, 8 insertions(+), 2 deletions(-)
>
> diff --git a/Documentation/git-push.txt b/Documentation/git-push.txt
> index 94d07ab..b8c55dd 100644
> --- a/Documentation/git-push.txt
> +++ b/Documentation/git-push.txt
> @@ -10,7 +10,8 @@ SYNOPSIS
> --------
> [verse]
> 'git push' [--all] [--dry-run] [--tags] [--receive-pack=<git-receive-pack>]
> - [--repo=all] [-f | --force] [-v | --verbose] [<repository> <refspec>...]
Doesn't this already say you can have zero or more refspecs?
^ permalink raw reply
* Re: [PATCH v2] Advertise the ability to abort a commit
From: Junio C Hamano @ 2008-07-29 20:51 UTC (permalink / raw)
To: Anders Melchiorsen; +Cc: git
In-Reply-To: <1217362342-30370-1-git-send-email-mail@cup.kalibalik.dk>
Anders Melchiorsen <mail@cup.kalibalik.dk> writes:
> diff --git a/builtin-commit.c b/builtin-commit.c
> index 9a11ca0..75eeb4b 100644
> --- a/builtin-commit.c
> +++ b/builtin-commit.c
> @@ -555,6 +555,7 @@ static int prepare_to_commit(const char *index_file, const char *prefix)
> fprintf(fp,
> "\n"
> "# Please enter the commit message for your changes.\n"
> + "# To abort the commit, use an empty commit message.\n"
> "# (Comment lines starting with '#' will ");
> if (cleanup_mode == CLEANUP_ALL)
> fprintf(fp, "not be included)\n");
Thanks. This sounds like a helpful message.
> @@ -1003,7 +1004,7 @@ int cmd_commit(int argc, const char **argv, const char *prefix)
> stripspace(&sb, cleanup_mode == CLEANUP_ALL);
> if (sb.len < header_len || message_is_empty(&sb, header_len)) {
> rollback_index_files();
> - die("no commit message? aborting commit.");
> + die("no commit message. aborting commit.");
> }
> strbuf_addch(&sb, '\0');
> if (is_encoding_utf8(git_commit_encoding) && !is_utf8(sb.buf))
Sorry but I do not see a point in this hunk.
I am somewhere between neutral to mildly negative about changing "Abort
with error and do not create a commit if there is no message" to "Do not
create a commit if there is no message, and this condition is not an
error". I further think the new message at the top is very helpful to the
end users, with the understanding that users who changed their mind after
running "git commit" _can_ deliberately trigger this _error condition_ to
prevent commit from happening. I also agree this ability to trigger an
error can be called a feature.
This still calls die(), which means this is still an error condition. I
do not see a point in changing that question mark (which hints "perhaps
you made a mistake, and that is the reason we are aborting") to a full
stop. I think the current question mark is more helpful to people who did
not pay close attention to the new message at the top.
If the change _were_ to reword the message to more neutral sounding
"aborting commit due to missing log message.", and change die() to a
normal exit, that would be making this not an error. As I already said, I
am mildly negative, but at least such a change would be internally
consistent.
I sense that the change from question mark to full stop might be showing
the desire to go in that direction, but in that case your change from the
question mark to full stop does not go far enough.
^ permalink raw reply
* [PATCH v2] Advertise the ability to abort a commit
From: Anders Melchiorsen @ 2008-07-29 20:12 UTC (permalink / raw)
To: git; +Cc: Anders Melchiorsen
In-Reply-To: <1217359925-30130-1-git-send-email-mail@cup.kalibalik.dk>
This treats aborting a commit more like a feature.
Signed-off-by: Anders Melchiorsen <mail@cup.kalibalik.dk>
---
Now includes updates to test file.
Incidentally, this change was proposed by pasky in #git.
builtin-commit.c | 3 ++-
t/t7502-commit.sh | 7 ++++---
2 files changed, 6 insertions(+), 4 deletions(-)
diff --git a/builtin-commit.c b/builtin-commit.c
index 9a11ca0..75eeb4b 100644
--- a/builtin-commit.c
+++ b/builtin-commit.c
@@ -555,6 +555,7 @@ static int prepare_to_commit(const char *index_file, const char *prefix)
fprintf(fp,
"\n"
"# Please enter the commit message for your changes.\n"
+ "# To abort the commit, use an empty commit message.\n"
"# (Comment lines starting with '#' will ");
if (cleanup_mode == CLEANUP_ALL)
fprintf(fp, "not be included)\n");
@@ -1003,7 +1004,7 @@ int cmd_commit(int argc, const char **argv, const char *prefix)
stripspace(&sb, cleanup_mode == CLEANUP_ALL);
if (sb.len < header_len || message_is_empty(&sb, header_len)) {
rollback_index_files();
- die("no commit message? aborting commit.");
+ die("no commit message. aborting commit.");
}
strbuf_addch(&sb, '\0');
if (is_encoding_utf8(git_commit_encoding) && !is_utf8(sb.buf))
diff --git a/t/t7502-commit.sh b/t/t7502-commit.sh
index 4f2682e..f111263 100755
--- a/t/t7502-commit.sh
+++ b/t/t7502-commit.sh
@@ -142,6 +142,7 @@ test_expect_success 'cleanup commit messages (strip,-F)' '
echo "sample
# Please enter the commit message for your changes.
+# To abort the commit, use an empty commit message.
# (Comment lines starting with '#' will not be included)" >expect
test_expect_success 'cleanup commit messages (strip,-F,-e)' '
@@ -149,7 +150,7 @@ test_expect_success 'cleanup commit messages (strip,-F,-e)' '
echo >>negative &&
{ echo;echo sample;echo; } >text &&
git commit -e -F text -a &&
- head -n 4 .git/COMMIT_EDITMSG >actual &&
+ head -n 5 .git/COMMIT_EDITMSG >actual &&
test_cmp expect actual
'
@@ -162,7 +163,7 @@ test_expect_success 'author different from committer' '
echo >>negative &&
git commit -e -m "sample"
- head -n 7 .git/COMMIT_EDITMSG >actual &&
+ head -n 8 .git/COMMIT_EDITMSG >actual &&
test_cmp expect actual
'
@@ -181,7 +182,7 @@ test_expect_success 'committer is automatic' '
# must fail because there is no change
test_must_fail git commit -e -m "sample"
) &&
- head -n 8 .git/COMMIT_EDITMSG | \
+ head -n 9 .git/COMMIT_EDITMSG | \
sed "s/^# Committer: .*/# Committer:/" >actual &&
test_cmp expect actual
'
--
1.5.6.4
^ permalink raw reply related
* [PATCH] Make it clear that push can take multiple refspecs
From: Abhijit Menon-Sen @ 2008-07-29 20:09 UTC (permalink / raw)
To: git; +Cc: gitster
Signed-off-by: Abhijit Menon-Sen <ams@toroid.org>
---
Documentation/git-push.txt | 10 ++++++++--
1 files changed, 8 insertions(+), 2 deletions(-)
diff --git a/Documentation/git-push.txt b/Documentation/git-push.txt
index 94d07ab..b8c55dd 100644
--- a/Documentation/git-push.txt
+++ b/Documentation/git-push.txt
@@ -10,7 +10,8 @@ SYNOPSIS
--------
[verse]
'git push' [--all] [--dry-run] [--tags] [--receive-pack=<git-receive-pack>]
- [--repo=all] [-f | --force] [-v | --verbose] [<repository> <refspec>...]
+ [--repo=all] [-f | --force] [-v | --verbose]
+ [<repository> <refspec>...]
DESCRIPTION
-----------
@@ -33,7 +34,8 @@ OPTIONS
The canonical format of a <refspec> parameter is
`+?<src>:<dst>`; that is, an optional plus `+`, followed
by the source ref, followed by a colon `:`, followed by
- the destination ref.
+ the destination ref. Any number of <refspec> parameters
+ may be specified.
+
The <src> side represents the source branch (or arbitrary
"SHA1 expression", such as `master~4` (four parents before the
@@ -180,6 +182,10 @@ git push origin :experimental::
Find a ref that matches `experimental` in the `origin` repository
(e.g. `refs/heads/experimental`), and delete it.
+git push origin master master:other::
+ Find a ref that matches `master` in the source repository and in
+ the `origin` repository update refs `master` and `other` to it.
+
git push origin master:satellite/master::
Find a ref that matches `master` in the source repository
(most likely, it would find `refs/heads/master`), and update
--
1.6.0.rc0.43.g2aa74
^ permalink raw reply related
* Re: Git Community Book
From: Junio C Hamano @ 2008-07-29 19:57 UTC (permalink / raw)
To: Scott Chacon; +Cc: Petr Baudis, git list
In-Reply-To: <d411cc4a0807291234q794344e0oee09f6164286ffd1@mail.gmail.com>
"Scott Chacon" <schacon@gmail.com> writes:
> The book is basically a fork of all three of the guides I mentioned
> (User Manual and both Tutorials), and with the scope and goals I
> currently have in mind, will not be kept in sync - it's just not going
> to be possible. I think in the end, the goals of the texts are so
> very different that sections it will simply not make sense to try to
> keep them in sync in some sort of automated fashion. That's one of
> the reasons why I choose Markdown - I saw no need to use asciidoc, as
> the book will not be shipped around with Git or built using the same
> processes, and I had no need for the advantages of asciidoc in my
> project. I don't think it makes much sense to have the book be a man
> page at all.
>
> However, I will watch the manual and guides and try to incorporate
> changes to them as appropriate, and I will likely have some updates to
> them myself as I've been more closely scrutinizing them.
If that is the approach you decided for your book, I am Ok with that.
Not that you need my blessing to do your own book. It was unclear what
your goals were, and if one of the goals were to keep the hassle of
maintaining shared materials in both manuals up-to-date, choice of
markdown seemed suboptimal to me, hence my comments.
Thanks.
... /me goes back to work after lunch break ...
^ permalink raw reply
* [PATCH] `git submodule add` now requires a <path>
From: Abhijit Menon-Sen @ 2008-07-29 19:53 UTC (permalink / raw)
To: git; +Cc: gitster
Signed-off-by: Abhijit Menon-Sen <ams@toroid.org>
---
Documentation/user-manual.txt | 8 ++++----
1 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/Documentation/user-manual.txt b/Documentation/user-manual.txt
index c5641af..00256ca 100644
--- a/Documentation/user-manual.txt
+++ b/Documentation/user-manual.txt
@@ -3458,7 +3458,7 @@ $ cd super
$ git init
$ for i in a b c d
do
- git submodule add ~/git/$i
+ git submodule add ~/git/$i $i
done
-------------------------------------------------
@@ -3471,10 +3471,10 @@ $ ls -a
. .. .git .gitmodules a b c d
-------------------------------------------------
-The `git-submodule add` command does a couple of things:
+The `git-submodule add <repo> <path>` command does a couple of things:
-- It clones the submodule under the current directory and by default checks out
- the master branch.
+- It clones the submodule from <repo> to the given <path> under the
+ current directory and by default checks out the master branch.
- It adds the submodule's clone path to the linkgit:gitmodules[5] file and
adds this file to the index, ready to be committed.
- It adds the submodule's current commit ID to the index, ready to be
--
1.6.0.rc0.43.g2aa74
^ permalink raw reply related
* Re: [PATCH] Modify mingw_main() workaround to avoid link errors
From: Steffen Prohaska @ 2008-07-29 19:46 UTC (permalink / raw)
To: Johannes Sixt; +Cc: git, Junio C Hamano
In-Reply-To: <1217320426.488ed5ea47384@webmail.nextra.at>
On Jul 29, 2008, at 10:33 AM, Johannes Sixt wrote:
> Zitat von Steffen Prohaska <prohaska@zib.de>:
>
>>
>> On Jul 27, 2008, at 9:24 PM, Johannes Sixt wrote:
>>
>>> Zitat von Steffen Prohaska <prohaska@zib.de>:
>>>
>>>>
>>>> On Jul 26, 2008, at 10:37 PM, Johannes Sixt wrote:
>>>>
>>>>> Zitat von Steffen Prohaska <prohaska@zib.de>:
>>>>>> With MinGW's
>>>>>>
>>>>>> gcc.exe (GCC) 3.4.5 (mingw special)
>>>>>> GNU ld version 2.17.50 20060824
>>>>>>
>>>>>> the old define caused link errors:
>>>>>>
>>>>>> git.o: In function `main':
>>>>>> C:/msysgit/git/git.c:500: undefined reference to `mingw_main'
>>>>>> collect2: ld returned 1 exit status
>>>>>>
>>>>>> The modified define works.
>>>>>
>>>>> I have the same tools, but not this error. ???
>>>>
>>>> I cleaned my work tree and built several times but did not
>>>> find out what exactly is causing the error. So I came up
>>>> with the modified define, which declares the static
>>>> mingw_main in global scope. I have no clue why I see the
>>>> error that you don't have.
>>>
>>> Neither do I. But a strange line number you have there. In 01d9b2d
>>> (from
>>> mingw.git) I have 'exit(1)' in line 500 of git.c.
>>
>> I have the same in line 500. I am still wondering what this could
>> mean. But I do not yet now :-(
>
> Can you try 'make -k' and see whether you have a similar problem
> with the
> non-builtins that have their own main()?
With your master 01d9b2d:
$ make -k
LINK git.exe
git.o: In function `main':
C:/msysgit/git/git.c:500: undefined reference to `mingw_main'
collect2: ld returned 1 exit status
make: *** [git.exe] Error 1
LINK git-hash-object.exe
hash-object.o: In function `main':
C:/msysgit/git/hash-object.c:114: undefined reference to `mingw_main'
collect2: ld returned 1 exit status
make: *** [git-hash-object.exe] Error 1
LINK git-index-pack.exe
index-pack.o: In function `main':
C:/msysgit/git/index-pack.c:974: undefined reference to `mingw_main'
collect2: ld returned 1 exit status
make: *** [git-index-pack.exe] Error 1
LINK git-merge-index.exe
merge-index.o: In function `main':
C:/msysgit/git/merge-index.c:120: undefined reference to `mingw_main'
collect2: ld returned 1 exit status
make: *** [git-merge-index.exe] Error 1
LINK git-merge-tree.exe
merge-tree.o: In function `main':
C:/msysgit/git/merge-tree.c:346: undefined reference to `mingw_main'
collect2: ld returned 1 exit status
make: *** [git-merge-tree.exe] Error 1
LINK git-mktag.exe
mktag.o: In function `main':
C:/msysgit/git/mktag.c:144: undefined reference to `mingw_main'
collect2: ld returned 1 exit status
make: *** [git-mktag.exe] Error 1
LINK git-mktree.exe
mktree.o: In function `main':
C:/msysgit/git/strbuf.h:73: undefined reference to `mingw_main'
collect2: ld returned 1 exit status
make: *** [git-mktree.exe] Error 1
LINK git-pack-redundant.exe
pack-redundant.o: In function `main':
C:/msysgit/git/pack-redundant.c:181: undefined reference to `mingw_main'
collect2: ld returned 1 exit status
make: *** [git-pack-redundant.exe] Error 1
LINK git-patch-id.exe
patch-id.o: In function `main':
C:/msysgit/git/patch-id.c:80: undefined reference to `mingw_main'
collect2: ld returned 1 exit status
make: *** [git-patch-id.exe] Error 1
LINK git-receive-pack.exe
receive-pack.o: In function `main':
C:/msysgit/git/receive-pack.c:386: undefined reference to `mingw_main'
collect2: ld returned 1 exit status
make: *** [git-receive-pack.exe] Error 1
LINK git-show-index.exe
show-index.o: In function `main':
C:/msysgit/git/show-index.c:64: undefined reference to `mingw_main'
collect2: ld returned 1 exit status
make: *** [git-show-index.exe] Error 1
LINK git-unpack-file.exe
unpack-file.o: In function `main':
C:/msysgit/git/unpack-file.c:19: undefined reference to `mingw_main'
collect2: ld returned 1 exit status
make: *** [git-unpack-file.exe] Error 1
LINK git-update-server-info.exe
update-server-info.o: In function `main':
C:/msysgit/git/update-server-info.c:20: undefined reference to
`mingw_main'
collect2: ld returned 1 exit status
make: *** [git-update-server-info.exe] Error 1
LINK git-upload-pack.exe
upload-pack.o: In function `main':
C:/msysgit/git/upload-pack.c:180: undefined reference to `mingw_main'
collect2: ld returned 1 exit status
make: *** [git-upload-pack.exe] Error 1
LINK git-var.exe
var.o: In function `main':
C:/msysgit/git/var.c:51: undefined reference to `mingw_main'
collect2: ld returned 1 exit status
make: *** [git-var.exe] Error 1
make: Target `all' not remade because of errors.
SUBDIR git-gui
SUBDIR gitk-git
make[1]: Nothing to be done for `all'.
SUBDIR perl
mkdir -p blib/lib
rm -f blib/lib/Git.pm; cp Git.pm blib/lib/
rm -f blib/lib/Error.pm
SUBDIR templates
LINK test-chmtime.exe
test-chmtime.o: In function `main':
C:/msysgit/git/test-chmtime.c:50: undefined reference to `mingw_main'
collect2: ld returned 1 exit status
make: *** [test-chmtime.exe] Error 1
LINK test-date.exe
test-date.o: In function `main':
C:/msysgit/git/test-date.c:3: undefined reference to `mingw_main'
collect2: ld returned 1 exit status
make: *** [test-date.exe] Error 1
LINK test-delta.exe
test-delta.o: In function `main':
C:/msysgit/git/test-delta.c:67: undefined reference to `mingw_main'
collect2: ld returned 1 exit status
make: *** [test-delta.exe] Error 1
LINK test-sha1.exe
test-sha1.o: In function `main':
C:/msysgit/git/test-sha1.c:14: undefined reference to `mingw_main'
collect2: ld returned 1 exit status
make: *** [test-sha1.exe] Error 1
LINK test-match-trees.exe
test-match-trees.o: In function `main':
C:/msysgit/git/test-match-trees.c:23: undefined reference to
`mingw_main'
collect2: ld returned 1 exit status
make: *** [test-match-trees.exe] Error 1
LINK test-parse-options.exe
test-parse-options.o: In function `main':
C:/msysgit/git/test-parse-options.c:21: undefined reference to
`mingw_main'
collect2: ld returned 1 exit status
make: *** [test-parse-options.exe] Error 1
LINK test-path-utils.exe
test-path-utils.o: In function `main':
C:/msysgit/git/test-path-utils.c:8: undefined reference to `mingw_main'
collect2: ld returned 1 exit status
make: *** [test-path-utils.exe] Error 1
make: Target `all' not remade because of errors.
Steffen
^ permalink raw reply
* Re: [PATCH 4/5] builtin-merge: allow using a custom strategy
From: Junio C Hamano @ 2008-07-29 19:47 UTC (permalink / raw)
To: Miklos Vajna; +Cc: git
In-Reply-To: <722d66a5a897b694f374aa96bd58aff01a2a5932.1217344803.git.vmiklos@frugalware.org>
Miklos Vajna <vmiklos@frugalware.org> writes:
> 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().
>
> If an invalid strategy is supplied, like -s foobar, then git-merge would
> list all git-merge-* commands. This is not perfect, since for example
> git-merge-index is not a valid strategy.
> ...
> + 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);
> + }
This feels overly wasteful. Granted, this is not a performance critical
codepath, but you list all commands that begin with "git-merge-" in
is_git_command(), only to discard it and then iterate over 140+ main_cmds
list only to cull the ones whose name do not appear in the strategies
list.
Perhaps this shows that changing the function is_git_command() is a wrong
approach (for one thing, with the custom prefix, it is not about "Is it a
git command" anymore). Wouldn't it be easier to read if you did this part
like this instead?
* make load_command_list capable of loading into a "struct cmdnames" (or
pair if you want) supplied by the caller;
* use it to grab all commands whose name begin with "git-merge-" here;
* Check if name appears in that list; if it doesn't, you already have the
list of commands that could be merge strategy for error reporting.
If you also update list_commands() not to run load_command_list() itself
but take caller-supplied list of commands, then the API would become much
cleaner. The caller would not be limited to "filter with prefix" anymore.
Hmm?
^ permalink raw reply
* Re: [PATCH 3/5] builtin-help: make it possible to exclude some commands in list_commands()
From: Junio C Hamano @ 2008-07-29 19:46 UTC (permalink / raw)
To: Miklos Vajna; +Cc: git
In-Reply-To: <5ad105819efb1c905bd01db3d08eb3422d283b3b.1217344803.git.vmiklos@frugalware.org>
Miklos Vajna <vmiklos@frugalware.org> writes:
> 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.
You require that exclude is a sorted list; this should be documented
somewhere to avoid future misuses.
There is no need for adding extra qsort() anywhere in the patchset because
the only user you are adding is in the next patch that sends a subset of
the commands in main_cmds in the order they are found in the list, and
main_cmds is already sorted.
^ 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