* [PATCH v2 5/5] t5710: add testcase for multi-level relative alternates
From: Wang Hui @ 2011-09-06 10:24 UTC (permalink / raw)
To: gitster, git, tali
In-Reply-To: <1315304645-12009-5-git-send-email-Hui.Wang@windriver.com>
From: Hui Wang <Hui.Wang@windriver.com>
Since we removed "relative alternates only possible for current dir"
limitation, it is needed to change an existing testcase to make it
pass for the relative path at the second level alternates.
Add a new testcase to make it pass when it work at a 5-level relative
alternates repository and make it fail when it work at a 6-level
relative alternates repository.
Signed-off-by: Hui Wang <Hui.Wang@windriver.com>
---
t/t5710-info-alternate.sh | 21 +++++++++++++++++++--
1 files changed, 19 insertions(+), 2 deletions(-)
diff --git a/t/t5710-info-alternate.sh b/t/t5710-info-alternate.sh
index ef7127c..a606a94 100755
--- a/t/t5710-info-alternate.sh
+++ b/t/t5710-info-alternate.sh
@@ -102,9 +102,26 @@ test_valid_repo'
cd "$base_dir"
test_expect_success \
- 'that relative alternate is only possible for current dir' '
+ 'that relative alternate is possible for none current dir' '
cd D &&
- ! (test_valid_repo)
+ test_valid_repo
+'
+
+cd "$base_dir"
+
+test_expect_success 'allow maxium 5 level relative alternate' \
+'echo "" > A/.git/objects/info/alternates &&
+echo "../../../A/.git/objects" > B/.git/objects/info/alternates &&
+echo "../../../B/.git/objects" > C/.git/objects/info/alternates &&
+echo "../../../C/.git/objects" > D/.git/objects/info/alternates &&
+echo "../../../D/.git/objects" > E/.git/objects/info/alternates &&
+echo "../../../E/.git/objects" > F/.git/objects/info/alternates &&
+echo "../../../F/.git/objects" > G/.git/objects/info/alternates &&
+cd F &&
+test_valid_repo &&
+cd ../G &&
+git fsck --full > fsck.err 2>&1 &&
+test `wc -l < fsck.err` != 0
'
cd "$base_dir"
--
1.6.3.1
^ permalink raw reply related
* [PATCH v2 2/5] sha1_file: remove a buggy value setting
From: Wang Hui @ 2011-09-06 10:24 UTC (permalink / raw)
To: gitster, git, tali
In-Reply-To: <1315304645-12009-2-git-send-email-Hui.Wang@windriver.com>
From: Hui Wang <Hui.Wang@windriver.com>
The ent->base[] is a character array, it has pfxlen characters from
position 0 to (pfxlen-1) to contain an alt object dir name, the
position pfxlen should be the string terminating character '\0' and
is deliberately set to '\0' at the previous code line. The position
(pfxlen+1) is given to ent->name.
>From above analysis, there is no reason to set ent->base[pfxlen] to
'/' at the end of this function, first it doesn't make sense to append
a '/' at the end of a dir name, second if you are not lucky that the
ent->base[pfxlen+1] is not 0, you will get a wrong alt object dir
name.
Signed-off-by: Hui Wang <Hui.Wang@windriver.com>
---
sha1_file.c | 2 --
1 files changed, 0 insertions(+), 2 deletions(-)
diff --git a/sha1_file.c b/sha1_file.c
index d12a675..5940d84 100644
--- a/sha1_file.c
+++ b/sha1_file.c
@@ -304,8 +304,6 @@ static int link_alt_odb_entry(const char * entry, int len, const char * relative
/* recursively add alternates */
read_info_alternates(ent->base, depth + 1);
- ent->base[pfxlen] = '/';
-
return 0;
}
--
1.6.3.1
^ permalink raw reply related
* [PATCH v2 0/5] sha1_file: remove only current repository can have relative path limitation
From: Wang Hui @ 2011-09-06 10:24 UTC (permalink / raw)
To: gitster, git, tali
Hi Junio & Martin,
In the V1, Junio said we should investigate why the limitation is originally
designed. This limitation is introduced by Martin in the 2006, so add him
at this time, hope he can share some information and knowledge for this
question although he is not seen in the maillist recently.
Below is my investigation:
In the link_alt_odb_entry(), each alt object path will be added to the struct
alternate_object_database and linked to a list, but we don't permit a same dir
is added twice, otherwise it will easily introduce lots of trouble like
dead-loop reference. To compare if two directories are same, original design
is using memcmp() to directly compare directory path names, this method can't
give a accurate result if paths include .. and multiple slash, e.g. ../../a
and ../../b/../a is the same dir, but this method will report they are
different. Knowing the reason, i implement a new direcotry comparison function
to replace the old one, then we can safely remove multi-level relative
alternates limitation now.
0001 is a simple cleanup patch, has no relation with multi-level relative
limitation.
0002 is a bug fix, has no relation with multi-level relative limitation.
Without this fix, all tests under t/ can work well so far, this is because we
are lucky that the ent->base[pfxlen+1] is 0, if it is not 0, we will see lots
of fails. After apply this fix, it is safe now.
0003 introduce a new directory comparison function to replace the old one.
0004 remove the multi-level relative alternates limitation
0005 change and add testcase to validate multi-level relative alternates.
after apply those 5 patches, all testcase under t can pass.
Hui Wang (5):
sha1_file cleanup: remove redundant variable check
sha1_file: remove a buggy value setting
sha1_file: improve directories comparison method
sha1_file: remove relative entries limitation
t5710: add testcase for multi-level relative alternates
abspath.c | 26 ++++++++++++++++++++++++++
cache.h | 1 +
sha1_file.c | 22 +++++++---------------
t/t5710-info-alternate.sh | 21 +++++++++++++++++++--
4 files changed, 53 insertions(+), 17 deletions(-)
^ permalink raw reply
* Re: [PATCH 2/2] Support sizes >=2G in various config options accepting 'g' sizes.
From: Johannes Sixt @ 2011-09-06 10:22 UTC (permalink / raw)
To: Nix; +Cc: Clemens Buchacher, Sverre Rabbelier, git
In-Reply-To: <87ty8qjaof.fsf@spindle.srvr.nix>
Am 9/6/2011 11:13, schrieb Nix:
> ... amounts to writing our own strtol()
> specifically for this one case, to see if the parsed number is
> too long.
Why so? strtol() can report overflow:
RETURN VALUE
...
If the correct value is outside the range of representable values,
{LONG_MIN}, {LONG_MAX}, {LLONG_MIN}, or {LLONG_MAX} shall be returned
(according to the sign of the value), and errno set to [ERANGE].
-- Hannes
^ permalink raw reply
* user permission / authority
From: ian @ 2011-09-06 10:13 UTC (permalink / raw)
To: git
I could not find user permission or authority level. Thatis, I can restrict a
user not to use the 'commit' function for example. Seems that everyone
having GIT & TortoiseGIT can do any of the functions. Is there a way (or any
other GUI)that enables these restrictions by user?
--
View this message in context: http://git.661346.n2.nabble.com/user-permission-authority-tp6763296p6763296.html
Sent from the git mailing list archive at Nabble.com.
^ permalink raw reply
* Re: Git commit generation numbers
From: Ramkumar Ramachandra @ 2011-09-06 10:02 UTC (permalink / raw)
To: Git List
Cc: Linus Torvalds, Jeff King, Jakub Narebski, david, Nicolas Pitre,
George Spelvin, Anthony Van de Gejuchte, Phil Hord, Shawn Pearce,
Felipe Contreras
In-Reply-To: <CAMP44s2F429MG5DeRAULnSgNkCwrVGPfC2HeFw=iHXPXjkw0yA@mail.gmail.com>
Hi,
First, let me start out by saying that I'm a fairly new contributor to
Git, and I'm far less experienced than the other people on this
thread. I've read through all the discussions time and again, and
thought about the problem for some time now - I can't say I understand
it as fully as many of you do, but I think I may have a slightly
different perspective to offer.
In what way is Git fundamentally different from Subversion? It's the
simplicity of the data model. From the simplest building block, a
key-value store, we have been able to compose and build things on top
of it. The reason we built centralized version control systems
earlier is because it was *easier* to address the composition
problems. We dumped all related repository and problems into one
central server. With so much information in one place, things are
tightly coupled and problems are easier to solve. Still not
convinced? What's the weakest component in Git today? Undoubtedly
submodules. Ofcourse, a large part of the reason is that many people
don't use submodules, and hence it doesn't improve -- but it's
actually a circular problem. People don't use submodules, because
it's so featureless and hard to develop. Why is it so hard? Back to
the fundamental problem of composition from simple building blocks.
In submodules, we have to take entire DAGs and build a composite DAG.
The key pieces of information are deep inside Git's fundamnetals:
Gitlinks. Other projects try like Gitslave try to attack the problem
on a more superficial level, but they all hit a barrier when they
discover that they can't compose big blocks of data: you need simple
building blocks to compose.
It's the same story with C (and now, Haskell). Why does everyone like
C so much? Because it only provides fundamental building blocks and
gives people the freedom to compose the way they like. It doesn't
provide big "template blocks" like Java, because they tend to be
restrictive in the long run. Sure, Java is easier to start out with,
but people soon realize that big blocks can't compose.
More than arguing about backward compatibility, and about how older
versions of Git commits won't have generation numbers, I think this is
what we should be focusing on. Sure, it'll additionally make sense to
put in a cache to speed things up now, but we need to think about what
Git will be 10~15 years from now. The fundamental pieces of
information required for composition must be present in the
fundamental building blocks.
The real question we should be asking is: "Should Git have had commit
generation numbers in 2005?". If the answer is "yes", we should put
them in now before it becomes even harder, bending over backwards for
backward compatibility if necessary. Otherwise, we'll regret this
decision 10~15 years later, when we're faced with deeper issues. If
you want a concrete example, think about how you'd compose DAGs
together (again, the submodules problem): where is the information
required to prune each DAG and compose?
I wish I could write this in myself, but I'm afraid I don't have the
engineering skill yet. I'll be happy to contribute whatever little I
can, and participate in the review process.
Thanks.
-- Ram
^ permalink raw reply
* Re: "Your local changes ... would be overwritten" bug
From: Hannu Koivisto @ 2011-09-06 9:46 UTC (permalink / raw)
To: git
In-Reply-To: <20110906073436.GA28490@ecki>
Clemens Buchacher <drizzd@aon.at> writes:
> Could you set a breakpoint in add_rejected_path and send us the
> backtrace? Like this:
Since the binary from the package doesn't come with debug
information, I built the latest git master (1.7.7.rc0.72.g4b5ea)
and it turns out the problem cannot be reproduced with this version
anymore. I guess I should have tried that right away. Sorry for
the noise.
--
Hannu
^ permalink raw reply
* Re: [PATCH 1/2] Add strtoimax() compatibility function.
From: Nix @ 2011-09-06 9:14 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v62l6b3bt.fsf@alter.siamese.dyndns.org>
On 6 Sep 2011, Junio C. Hamano spake thusly:
> Nix <nix@esperi.org.uk> writes:
>
>> Since systems that omit strtoumax() will likely omit strtomax() too,
>> and likewise for strtoull() and strtoll(), we also adjust the
>> compatibility #defines from NO_STRTOUMAX to NO_STRTOMAX and from
>> NO_STRTOULL to NO_STRTOLL, and have them cover both the signed and
>> unsigned functions.
>
> What would happen to people who know their systems lack strtoumax and have
> happily using NO_STRTOUMAX in their config.mak already? Do their build
> suddenly start breaking after this patch is applied and they all have to
> adjust to the new name?
Uh. Yeah. Oops.
> Even though "no strtoumax() likely means no strtoimax()" may be a good
> heuristics, I am not sure what we would gain by renaming these Makefile
> variables. Can't you get the same effect by making existing NO_STRTOUMAX
> imply not having strtoimax(), and if you did so, wouldn't it be much less
> likely that you would break existing people's build?
Yes, but I thought that might be too confusing (and having four
variables for this one case seemed ridiculous). I'm happy to rename it
back.
--
NULL && (void)
^ permalink raw reply
* Re: [PATCH 2/2] Support sizes >=2G in various config options accepting 'g' sizes.
From: Nix @ 2011-09-06 9:13 UTC (permalink / raw)
To: Clemens Buchacher; +Cc: Sverre Rabbelier, git
In-Reply-To: <20110906074421.GB28490@ecki>
On 6 Sep 2011, Clemens Buchacher uttered the following:
> On Mon, Sep 05, 2011 at 02:56:10PM +0100, Nix wrote:
>>
>> Well, we're parsing longs, not ints. If sizeof(long)>sizeof(int), or we
>> have long long and sizeof(long long)>sizeof(int), then we can always
>> detect overflows when saving into the appropriate type: but if we don't
>> have long long, or if we have neither strto(u)ll() nor strto[ui]max(),
>> we could only detect overflow by looking at the raw text string and
>> checking it by hand to see if it would fit. I judged this pointless
>> extra complexity for a very rare edge case (machines with neither
>> strot(u)ll() nor strto[ui]max() are generally quite old and people
>> aren't going to be specifying sizes in gigabytes on such machines
>> anyway.)
>
> Is this also true for Windows and other platforms?
There, uintmax_t is 'long long' and is longer than 'long', let alone
'int', so this holds there too, or should.
> And I don't think it's about whether or not people are likely to
> specify sizes in gigabytes on old machines. People are bound to
> blindly copy configuration files from one machine to another. In
> any case, my expectation would be for the configuration options to
> do what I tell them, or error out if they do not make sense.
Yeah, and we do that whenever practically possible: but fixing
this for the case that int/long is the largest available type
(which among other things implies that we're not using GCC or
any other C99 compiler or any of the myriad C89 compilers that
implmented 'long long') amounts to writing our own strtol()
specifically for this one case, to see if the parsed number is
too long. And that is probably a maintenance burden too far.
The failure mode if you put a huge number in on such a platform is
better than it used to be, too, especially for core.bigfilethreshold. We
used to get a negative number that was latched to zero, which then
disabled compression entirely (I had an 83Mb pack turn itself into an
837Mb one when that happened). Now we get a number that, while positive,
is less positive than we expect, but still likely up in the hundreds of
millions.
--
NULL && (void)
^ permalink raw reply
* Re: Dropping '+' from fetch = +refs/heads/*:refs/remotes/origin/*?
From: Michael J Gruber @ 2011-09-06 7:51 UTC (permalink / raw)
To: Matthieu Moy; +Cc: Shawn Pearce, Jeff King, Junio C Hamano, git
In-Reply-To: <vpqvct69l2e.fsf@bauges.imag.fr>
Matthieu Moy venit, vidit, dixit 06.09.2011 09:39:
> Shawn Pearce <spearce@spearce.org> writes:
>
>> Again, the repository owner would notice on their next push, and
>> notify people the repository is not to be trusted.
>
> For simple attack, yes. But if the server is compromised, you can't
> trust it anymore to error out on non-fast-forward. I don't think it
> would be very complex to write a modified Git server that would come
> back to the official history before a push, and re-introduce faulty
> commits right after. pushers wouldn't notice, and fetchers would get
> compromised history.
Exactly. Even on fetch, it could serve different histories depending on
the ip so that the pusher does not notice when fetching from the same ip.
> OTOH, non-fast-forward fetches can be reliably detected client-side, and
> I like being able to think "whatever the server does, I don't care
> because I'm using Git".
reflog based warnings should provide a sane default. We could amend the
update hook for those who want to allow/deny specific branches to
rewind, or make receiveDeny... branch.-specific, if the multiple
refspecs approach is too complicated.
Michael
^ permalink raw reply
* Re: git push output goes into stderr
From: Clemens Buchacher @ 2011-09-06 7:49 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Lynn Lin, git
In-Reply-To: <7v8vq3ztym.fsf@alter.siamese.dyndns.org>
On Sun, Sep 04, 2011 at 05:57:53PM -0700, Junio C Hamano wrote:
> Lynn Lin <lynn.xin.lin@gmail.com> writes:
>
> > When I create a local branch and then push it to remote. I find that
> > the output without error goes into stderr, is this expected?
>
> Progress output are sent to the stderr stream.
But it's not only progress output that goes to stderr in case of
git push. Even the summary written in tranport_print_push_status
goes to stderr, unless we specify git push --porcelain. Can't we
let that part of the output go to stdout unconditionally?
Clemens
^ permalink raw reply
* Re: [BUG] git bisect start fails when stale bisect data is left behind
From: Christian Couder @ 2011-09-06 7:48 UTC (permalink / raw)
To: Joel Kaasinen; +Cc: git
In-Reply-To: <CAC6WLetwT9UvBY_=Nf38hhkyU1mhmdWHWqscf3ebba1WRGS1LQ@mail.gmail.com>
Hi,
On Mon, Sep 5, 2011 at 1:15 PM, Joel Kaasinen <joel@zenrobotics.com> wrote:
> Hi,
>
> Just bumped into a weird bug: bisect refused to start. It seems some
> previous bisect had left around state that referred to a
> now-nonexistent branch.
>
> How to reproduce:
> $ echo foo > .git/BISECT_START
> $ git bisect start HEAD HEAD^
>
> Fails with "fatal: invalid reference:" on git 1.7.6.
Yeah, it looks like a very old behavior.
I'd suggest a simple improvement in the error message like this:
diff --git a/git-bisect.sh b/git-bisect.sh
index c21e33c..bd7155b 100755
--- a/git-bisect.sh
+++ b/git-bisect.sh
@@ -67,7 +67,8 @@ bisect_start() {
then
# Reset to the rev from where we started.
start_head=$(cat "$GIT_DIR/BISECT_START")
- git checkout "$start_head" -- || exit
+ git checkout "$start_head" -- ||
+ die "Could not checkout previous start point
'$start_head'. Try 'git bisect reset <branch>' first."
else
# Get rev from where we start.
case "$head" in
If there is no objection I will provide a proper patch.
Thanks,
Christian.
^ permalink raw reply related
* Re: [PATCH 2/2] Support sizes >=2G in various config options accepting 'g' sizes.
From: Clemens Buchacher @ 2011-09-06 7:44 UTC (permalink / raw)
To: Nix; +Cc: Sverre Rabbelier, git
In-Reply-To: <87ty8rm6th.fsf@spindle.srvr.nix>
On Mon, Sep 05, 2011 at 02:56:10PM +0100, Nix wrote:
>
> Well, we're parsing longs, not ints. If sizeof(long)>sizeof(int), or we
> have long long and sizeof(long long)>sizeof(int), then we can always
> detect overflows when saving into the appropriate type: but if we don't
> have long long, or if we have neither strto(u)ll() nor strto[ui]max(),
> we could only detect overflow by looking at the raw text string and
> checking it by hand to see if it would fit. I judged this pointless
> extra complexity for a very rare edge case (machines with neither
> strot(u)ll() nor strto[ui]max() are generally quite old and people
> aren't going to be specifying sizes in gigabytes on such machines
> anyway.)
Is this also true for Windows and other platforms?
And I don't think it's about whether or not people are likely to
specify sizes in gigabytes on old machines. People are bound to
blindly copy configuration files from one machine to another. In
any case, my expectation would be for the configuration options to
do what I tell them, or error out if they do not make sense.
Clemens
^ permalink raw reply
* Re: Dropping '+' from fetch = +refs/heads/*:refs/remotes/origin/*?
From: Matthieu Moy @ 2011-09-06 7:39 UTC (permalink / raw)
To: Shawn Pearce; +Cc: Jeff King, Junio C Hamano, Michael J Gruber, git
In-Reply-To: <CAJo=hJtuUe1ajjW9dNU4JzjE+P94a42W7ZvC+iQBQTeGXVvS8Q@mail.gmail.com>
Shawn Pearce <spearce@spearce.org> writes:
> Again, the repository owner would notice on their next push, and
> notify people the repository is not to be trusted.
For simple attack, yes. But if the server is compromised, you can't
trust it anymore to error out on non-fast-forward. I don't think it
would be very complex to write a modified Git server that would come
back to the official history before a push, and re-introduce faulty
commits right after. pushers wouldn't notice, and fetchers would get
compromised history.
OTOH, non-fast-forward fetches can be reliably detected client-side, and
I like being able to think "whatever the server does, I don't care
because I'm using Git".
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
^ permalink raw reply
* Re: "Your local changes ... would be overwritten" bug
From: Clemens Buchacher @ 2011-09-06 7:34 UTC (permalink / raw)
To: Hannu Koivisto; +Cc: git
In-Reply-To: <8362l73qi6.fsf@kalahari.s2.org>
Hi,
On Mon, Sep 05, 2011 at 07:25:53PM +0300, Hannu Koivisto wrote:
>
> I have a problem where "git checkout origin/another-branch" in master
> should remove a set of files but instead I get:
>
> error: Your local changes to the following files would be overwritten by checkout:
> file1
> file2
> ...
> Please, commit your changes or stash them before you can switch branches.
> Aborting
Could you set a breakpoint in add_rejected_path and send us the
backtrace? Like this:
$ gdb --args git checkout origin/another-branch
>> break add_rejected_path
>> r
... wait for break ...
>> bt
Thanks,
Clemens
^ permalink raw reply
* Re: Linux 3.1-rc5
From: Michael J Gruber @ 2011-09-06 7:23 UTC (permalink / raw)
To: Mauro Carvalho Chehab; +Cc: Linus Torvalds, Linux Kernel Mailing List, git
In-Reply-To: <4E65307F.5020103@redhat.com>
Mauro Carvalho Chehab venit, vidit, dixit 05.09.2011 22:26:
> Em 04-09-2011 20:27, Linus Torvalds escreveu:
>
>> One thing to note: If you just do
>>
>> git pull https://github.com/torvalds/linux.git
>>
>> you probably won't get the tags, since it's not your origin branch. So do
>>
>> git fetch --tags<...>
>>
>> too, so that you get not only the actual changes, but the tag that you
>> can verify too.
>>
>
> It would be great if "git remote update" could also verify the tag
> signature (if present), as most of us just do a "git remote update".
...when you should "git fetch --all" ;)
> Maybe an extra parameter for git config remote.tagopt?
>
> Ok, if in doubt, we can always use git tag -v <new tag>, but doing
> it automagically would help us to detect if a git tag got mangled
> by some at the moment we update our trees, with seems to be
> a good idea.
The update hook (if you want to reject falsified tags) or post-update
hook (if you want to be warned) is the perfect place for this. It would
be worth amending the standard update hook, me thinks, after removing
its insisting on a project description, and maybe switching the defaults.
Michael
^ permalink raw reply
* Re: [PATCH] send-email: add option -h
From: Clemens Buchacher @ 2011-09-06 6:32 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vk49mbvlk.fsf@alter.siamese.dyndns.org>
On Mon, Sep 05, 2011 at 01:08:39PM -0700, Junio C Hamano wrote:
> Clemens Buchacher <drizzd@aon.at> writes:
>
> > Most other git commands print a synopsis when passed -h. Make
> > send-email do the same.
> >
> > Signed-off-by: Clemens Buchacher <drizzd@aon.at>
> > ...
> > +my $help;
> > +my $rc = GetOptions("help|H|h" => \$help,
>
> I do not think what the patch aims to do is wrong per-se, but
>
> $ git send-email --help
>
> already shows the full documentation, and I find it is misleading to say
> "help|H|h" here to pretend as if a long-help is triggered with this
> command. For that matter, do we have any other place that accept -H for
> help?
>
> IOW, shouldn't this line be this instead?
>
> > +my $rc = GetOptions("h" => \$help,
Sure. I was just copy-pasting from git-svn.perl. And in fact I
_was_ confused by the fact that it also seemed to allow --help, but
in fact did not handle that case any different.
Just found a few more places, so how about this on top?
-->8--
From: Clemens Buchacher <drizzd@aon.at>
Date: Tue, 6 Sep 2011 08:27:13 +0200
Subject: [PATCH] use -h for synopsis and --help for manpage consistently
The "git cmd --help" syntax is translated into "git help cmd" by
git.c. Do not pretend to handle such cases in any individual
commands.
Signed-off-by: Clemens Buchacher <drizzd@aon.at>
---
git-cvsserver.perl | 4 ++--
git-pull.sh | 2 +-
git-send-email.perl | 2 +-
git-svn.perl | 2 +-
4 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/git-cvsserver.perl b/git-cvsserver.perl
index 1b8bff2..6c5185e 100755
--- a/git-cvsserver.perl
+++ b/git-cvsserver.perl
@@ -109,14 +109,14 @@ my $usage =
" --strict-paths : Don't allow recursing into subdirectories\n".
" --export-all : Don't check for gitcvs.enabled in config\n".
" --version, -V : Print version information and exit\n".
- " --help, -h, -H : Print usage information and exit\n".
+ " -h : Print usage information and exit\n".
"\n".
"<directory> ... is a list of allowed directories. If no directories\n".
"are given, all are allowed. This is an additional restriction, gitcvs\n".
"access still needs to be enabled by the gitcvs.enabled config option.\n".
"Alternately, one directory may be specified in GIT_CVSSERVER_ROOT.\n";
-my @opts = ( 'help|h|H', 'version|V',
+my @opts = ( 'h', 'version|V',
'base-path=s', 'strict-paths', 'export-all' );
GetOptions( $state, @opts )
or die $usage;
diff --git a/git-pull.sh b/git-pull.sh
index 63da37b..f08372a 100755
--- a/git-pull.sh
+++ b/git-pull.sh
@@ -120,7 +120,7 @@ do
--d|--dr|--dry|--dry-|--dry-r|--dry-ru|--dry-run)
dry_run=--dry-run
;;
- -h|--h|--he|--hel|--help|--help-|--help-a|--help-al|--help-all)
+ -h)
usage
;;
*)
diff --git a/git-send-email.perl b/git-send-email.perl
index 4ac6931..734356a 100755
--- a/git-send-email.perl
+++ b/git-send-email.perl
@@ -276,7 +276,7 @@ $SIG{INT} = \&signal_handler;
# needing, first, from the command line:
my $help;
-my $rc = GetOptions("help|H|h" => \$help,
+my $rc = GetOptions("h" => \$help,
"sender|from=s" => \$sender,
"in-reply-to=s" => \$initial_reply_to,
"subject=s" => \$initial_subject,
diff --git a/git-svn.perl b/git-svn.perl
index 89f83fd..a019f55 100755
--- a/git-svn.perl
+++ b/git-svn.perl
@@ -294,7 +294,7 @@ read_git_config(\%opts);
if ($cmd && ($cmd eq 'log' || $cmd eq 'blame')) {
Getopt::Long::Configure('pass_through');
}
-my $rv = GetOptions(%opts, 'help|H|h' => \$_help, 'version|V' => \$_version,
+my $rv = GetOptions(%opts, 'h' => \$_help, 'version|V' => \$_version,
'minimize-connections' => \$Git::SVN::Migration::_minimize,
'id|i=s' => \$Git::SVN::default_ref_id,
'svn-remote|remote|R=s' => sub {
--
1.7.6.1
^ permalink raw reply related
* Re: [PATCH 1/2] Add strtoimax() compatibility function.
From: Junio C Hamano @ 2011-09-06 6:19 UTC (permalink / raw)
To: Nix; +Cc: git
In-Reply-To: <1315223155-4218-1-git-send-email-nix@esperi.org.uk>
Nix <nix@esperi.org.uk> writes:
> Since systems that omit strtoumax() will likely omit strtomax() too,
> and likewise for strtoull() and strtoll(), we also adjust the
> compatibility #defines from NO_STRTOUMAX to NO_STRTOMAX and from
> NO_STRTOULL to NO_STRTOLL, and have them cover both the signed and
> unsigned functions.
What would happen to people who know their systems lack strtoumax and have
happily using NO_STRTOUMAX in their config.mak already? Do their build
suddenly start breaking after this patch is applied and they all have to
adjust to the new name?
Even though "no strtoumax() likely means no strtoimax()" may be a good
heuristics, I am not sure what we would gain by renaming these Makefile
variables. Can't you get the same effect by making existing NO_STRTOUMAX
imply not having strtoimax(), and if you did so, wouldn't it be much less
likely that you would break existing people's build?
^ permalink raw reply
* Re: [PATCH 3/3] push: old receive-pack does not understand --quiet
From: Michael J Gruber @ 2011-09-06 6:03 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Clemens Buchacher, git, tobiasu
In-Reply-To: <7vwrdmbx76.fsf@alter.siamese.dyndns.org>
Junio C Hamano venit, vidit, dixit 05.09.2011 21:34:
> Michael J Gruber <git@drmicha.warpmail.net> writes:
>
>> Being cc'ed makes me feel guilty but I don't know what for...
>
> No guilt involved. 28d836c (test: allow running the tests under "prove",
> 2010-10-14) made you a good _suspect_ for having more clues than I do to
> resolve it, iow, it was asking for help, not pointing any finger.
I plead non-guilty on the account of "prove-clue". All evidence to the
contrary is fabricated ;)
> Anyhow, thanks for a quick workaround, even though I still do not
> understand what the issue is (that is, what is wrong with the
> t/lib-terminal helper).
Seriously, I use prove as my standard target because I prefer its output
for parallel tests, but I have no idea how to debug the test output
(which TAP wants to parse). I've made sure that my workaround works with
and without the httpd runs, and with -j1 and -j8. My blackbox
understanding tells me that a subtest counter used to be increased and
the respective output quelled - maybe by a lib*.sh which used to be
sourced after lib-terminal.sh, because after rearranging the output is
there.
Michael
^ permalink raw reply
* Re: [tig: PATCH] Decorate replaced commits
From: Jonas Fonseca @ 2011-09-06 2:50 UTC (permalink / raw)
To: Michael J Gruber; +Cc: git
In-Reply-To: <f2c76a759d9e39c32b90033cb64f677b7a2602d8.1314608820.git.git@drmicha.warpmail.net>
On Mon, Aug 29, 2011 at 05:08, Michael J Gruber
<git@drmicha.warpmail.net> wrote:
> Decorate replaced commits by "replaced" analogous to git.git's
> 5267d29 (log: decorate "replaced" on to replaced commits, 2011-08-19).
Thanks.
> Should probably follow this up with graft decorations.
Yes, that'd be great.
--
Jonas Fonseca
^ permalink raw reply
* Re: "Your local changes ... would be overwritten" bug
From: Andrew Ardill @ 2011-09-05 23:37 UTC (permalink / raw)
To: Vijay Lakshminarayanan; +Cc: Matthieu Moy, Hannu Koivisto, git
In-Reply-To: <87wrdmrgbs.fsf@gmail.com>
I can not reproduce on msysgit version 1.7.6.msysgit.0, for what it is worth.
Regards,
Andrew Ardill
On 6 September 2011 04:31, Vijay Lakshminarayanan <laksvij@gmail.com> wrote:
> Matthieu Moy <Matthieu.Moy@grenoble-inp.fr> writes:
>
>> Hannu Koivisto <azure@iki.fi> writes:
>>
>>> The following script can be used to reproduce the problem:
>>
>> [...]
>>
>> I cannot reproduce on Linux.
>
> I can't either.
>
>>> I'm running Cygwin git 1.7.5.1 in Windows XP.
>
> I'm running cygwin git 1.7.5.1 in Windows Vista.
>
> $ mkdir temp
> d temp
> git init
> echo foo > testfile
> git add testfile
> git commit -m "test1"
> echo foo > testfile2
> chmod +x testfile2
> git add testfile2
> git commit -m "test2"
> mkdir foo
> cd foo
> git co master~1
>
> vijay@balrog ~/foo
> $ cd temp
>
> vijay@balrog ~/foo/temp
> $ git init
> Initialized empty Git repository in /home/vijay/foo/temp/.git/
>
> vijay@balrog ~/foo/temp
> $ echo foo > testfile
>
> vijay@balrog ~/foo/temp
> $ git add testfile
>
> vijay@balrog ~/foo/temp
> $ git commit -m "test1"
> [master (root-commit) 7564449] test1
> 1 files changed, 1 insertions(+), 0 deletions(-)
> create mode 100644 testfile
>
> vijay@balrog ~/foo/temp
> $ echo foo > testfile2
>
> vijay@balrog ~/foo/temp
> $ chmod +x testfile2
>
> vijay@balrog ~/foo/temp
> $ git add testfile2
>
> vijay@balrog ~/foo/temp
> $ git commit -m "test2"
> [master 9675b55] test2
>
> 1 files changed, 1 insertions(+), 0 deletions(-)
> create mode 100755 testfile2
>
> vijay@balrog ~/foo/temp
> $ mkdir foo
>
> vijay@balrog ~/foo/temp
> $ cd foo
>
> vijay@balrog ~/foo/temp/foo
> $ git co master~1
> git: 'co' is not a git command. See 'git --help'.
>
> Did you mean one of these?
> commit
> clone
> log
>
> vijay@balrog ~/foo/temp/foo
> $ git checkout master~1
> Note: checking out 'master~1'.
>
> You are in 'detached HEAD' state. You can look around, make experimental
> changes and commit them, and you can discard any commits you make in this
> state without impacting any branches by performing another checkout.
>
> If you want to create a new branch to retain commits you create, you may
> do so (now or later) by using -b with the checkout command again. Example:
>
> git checkout -b new_branch_name
>
> HEAD is now at 7564449... test1
>
>> Probably a dumb question (from a non-windows-user), but why not use the
>> native Git for windows?
>
> Do you mean msysgit? As a GNU/Linux user, I probably don't need to
> explain the luxuries a bash prompt gives you. In this scenario, cygwin
> is the closest approximation on Windows system.
>
> msysgit comes with its own bash shell etc (which is good) but rather
> than go that integration route, it's much simpler to have git working
> within cygwin when you're already used to it.
>
> Cheers
> ~vijay
> --
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply
* [PATCH] http: remove extra newline in error message
From: Jonathan Nieder @ 2011-09-05 22:29 UTC (permalink / raw)
To: git; +Cc: Tay Ray Chuan, Junio C Hamano
In-Reply-To: <20110905222202.GA32071@elie>
There is no need for a blank line between the detailed error message
and the later "fatal: HTTP request failed" notice. Keep the newline
written by error() itself and eliminate the extra one.
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
---
> I ran into this error today
Here's a patch for a simpler buglet noticed at the same time.
http.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/http.c b/http.c
index dec3c60a..fb3465f5 100644
--- a/http.c
+++ b/http.c
@@ -913,7 +913,7 @@ int http_error(const char *url, int ret)
{
/* http_request has already handled HTTP_START_FAILED. */
if (ret != HTTP_START_FAILED)
- error("%s while accessing %s\n", curl_errorstr, url);
+ error("%s while accessing %s", curl_errorstr, url);
return ret;
}
--
1.7.6
^ permalink raw reply related
* [RFC/PATCH git] http: avoid empty error messages for some curl errors
From: Jonathan Nieder @ 2011-09-05 22:22 UTC (permalink / raw)
To: git; +Cc: Tay Ray Chuan
When asked to fetch over SSL without a valid
/etc/ssl/certs/ca-certificates.crt file, "git fetch" writes
error: while accessing https://github.com/torvalds/linux.git/info/refs
which is a little disconcerting. Better to fall back to
curl_easy_strerror(result) when the error string is empty, like the
curl utility does:
error: Problem with the SSL CA cert (path? access rights?) while
accessing https://github.com/torvalds/linux.git/info/refs
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
---
Hi,
I ran into this error today because this machine has no certs enabled.
I'm not thrilled with the following patch because the error string
buffer is not cleared very often so it seems possible for it to be
not empty but stale at the relevant moment. I would be happier if we
could rely on libcurl always filling the error buffer on errors.
What do you think?
Jonathan
http.c | 7 ++++++-
1 files changed, 6 insertions(+), 1 deletions(-)
diff --git a/http.c b/http.c
index a59cac45..dec3c60a 100644
--- a/http.c
+++ b/http.c
@@ -851,8 +851,13 @@ static int http_request(const char *url, void *result, int target, int options)
init_curl_http_auth(slot->curl);
ret = HTTP_REAUTH;
}
- } else
+ } else {
+ if (!curl_errorstr[0])
+ strlcpy(curl_errorstr,
+ curl_easy_strerror(results.curl_result),
+ sizeof(curl_errorstr));
ret = HTTP_ERROR;
+ }
} else {
error("Unable to start HTTP request for %s", url);
ret = HTTP_START_FAILED;
--
1.7.6
^ permalink raw reply related
* Re: Dropping '+' from fetch = +refs/heads/*:refs/remotes/origin/*?
From: Shawn Pearce @ 2011-09-05 21:14 UTC (permalink / raw)
To: Jeff King; +Cc: Junio C Hamano, Michael J Gruber, git
In-Reply-To: <20110905205735.GA5578@sigill.intra.peff.net>
On Mon, Sep 5, 2011 at 13:57, Jeff King <peff@peff.net> wrote:
> On Mon, Sep 05, 2011 at 01:53:42PM -0700, Shawn O. Pearce wrote:
>
>> > Sure. I'm totally open to the idea of making the non-fast-forward
>> > warning more obvious. Suggestions for wording (though I am tempted by
>> > "HEY STUPID" above ;) )?
>>
>> I'm not suggesting all non-fast-forward should issue a bigger warning.
>> pu updates daily with a non-fast-forward. That isn't useful.
>>
>> But if the local reflog hints that this reference almost never does a
>> non-fast-forward, and then it does, that should be a big warning.
>
> Right. What I mean is, what should the bigger warning look like?
Its a bikeshed. I refuse to paint bikesheds. :-)
> Also, you suggested caching to avoid looking through the whole reflog
> each time. I think you could probably just sample the last 10 or so
> reflog entries to get an idea.
Good point. 10 or so last records might be representative of the
branch's recent behavior, which is all that matters to the user who
wants this warning.
--
Shawn.
^ permalink raw reply
* Re: Dropping '+' from fetch = +refs/heads/*:refs/remotes/origin/*?
From: Jeff King @ 2011-09-05 20:57 UTC (permalink / raw)
To: Shawn Pearce; +Cc: Junio C Hamano, Michael J Gruber, git
In-Reply-To: <CAJo=hJtvU+ujYBMvrgVJpBdaTUq+NOsQwVFkL-A4pHv-CRPdDg@mail.gmail.com>
On Mon, Sep 05, 2011 at 01:53:42PM -0700, Shawn O. Pearce wrote:
> > Sure. I'm totally open to the idea of making the non-fast-forward
> > warning more obvious. Suggestions for wording (though I am tempted by
> > "HEY STUPID" above ;) )?
>
> I'm not suggesting all non-fast-forward should issue a bigger warning.
> pu updates daily with a non-fast-forward. That isn't useful.
>
> But if the local reflog hints that this reference almost never does a
> non-fast-forward, and then it does, that should be a big warning.
Right. What I mean is, what should the bigger warning look like?
Also, you suggested caching to avoid looking through the whole reflog
each time. I think you could probably just sample the last 10 or so
reflog entries to get an idea.
-Peff
^ 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