* Re: checkout from neighbour branch undeletes a path?
From: Peter Vereshagin @ 2012-11-13 18:34 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Peter Vereshagin, git
In-Reply-To: <7v8va5fo7g.fsf@alter.siamese.dyndns.org>
Hello.
2012/11/13 08:43:31 -0800 Junio C Hamano <gitster@pobox.com> => To Peter Vereshagin :
JCH> Peter Vereshagin <peter@vereshagin.org> writes:
JCH>
JCH> > Am wondering if 'checkout branch path' undeletes the files?
JCH>
JCH> "git checkout branch path" (by the way, "branch" does not have to be
JCH> a branch name; any commit object name would do, like "git checkout
JCH> HEAD^^ hello.c") is a way to check out named path(s) out of the
JCH> named commit.
JCH>
JCH> If the commit "branch" has "path" in it, its contents are checked
JCH> out to "path" in your current working tree (and the entry in the
JCH> index updated to match it).
JCH>
JCH> If you happen to have removed "path" in your current working tree
JCH> before running that command, it might look as if there is some
JCH> undelete going on, but that is a wrong way to look at things. The
JCH> version of "path" in the "branch" may or may not be similar to what
JCH> you have removed earlier.
JCH>
Hello.
I solved my problem by mean of 'git rm' instead of 'rm'.
I knew what you said here. Shortly, the difference for my case was:
- I check out the pathdir from the commit in which the pathdir/file00 was
already removed.
- The current branch 'branch01' has no idea the file00 was removed. But I
removed file00 and this is what 'branch01' assumes when I commit n ext time.
But git assumes I need 'file00' although it doesn't exist in the commit I
checkout path from. It doesn't exist by itself before I checkout that path
neither.
How can I know which one of the 'file00' versions is being checked out: the one
that did exist in the 'branch00' (the where I checkout path from) before I
removed it or the one existing in HEAD but not in the work-tree? And why this
and not that?
If it is the one that exists in a current branch but was deleted from trhe
work-tree [d4f7c70] than why it is being checked out not from the commit
supplied as an argument to git?
If it is the one that existed [c3e78ff] before the commit I checkout path from
than why it is being checked out while it doesn't exist in that commit already?
Thank you.
--
Peter Vereshagin <peter@vereshagin.org> (http://vereshagin.org) pgp: A0E26627
^ permalink raw reply
* Re: What's cooking in git.git (Oct 2012, #09; Mon, 29)
From: Ramsay Jones @ 2012-11-13 18:47 UTC (permalink / raw)
To: Jeff King; +Cc: Chris Rorvick, git
In-Reply-To: <20121111174136.GC13188@sigill.intra.peff.net>
Jeff King wrote:
> On Sat, Nov 10, 2012 at 06:33:38PM +0000, Ramsay Jones wrote:
>
>>> We should probably wrap it. I'm planning to queue this on top of Chris's
>>> patch:
>>
>> Unfortunately, I haven't had time yet to test this patch. (Early this week, I
>> went into hospital for a "minor" surgical procedure - I have not yet fully
>> recovered). The patch looks good and I don't anticipate any problems. I will
>> hopefully test it soon (I see it's in pu now) and let you know.
>
> Thanks. I merged it to "next" on Friday, so we will see if anybody
> screams. But please take your time and recover. Git will wait. :)
I have tested this patch and, as expected, it fixes things up for me.
(To be more precise: the current next branch works, but if I revert
commit c2b3af05, then t9604-cvsimport-timestamps.sh fails in the
same way as before!)
Thanks!
ATB,
Ramsay Jones
^ permalink raw reply
* Re: [regression] Newer gits cannot clone any remote repos
From: Ramsay Jones @ 2012-11-13 18:55 UTC (permalink / raw)
To: Douglas Mencken; +Cc: git
In-Reply-To: <CACYvZ7jPd0_XD6YVdfJ2AnKRnKewmzX4uu7w3zt+_gK+qU49gQ@mail.gmail.com>
Douglas Mencken wrote:
> *Any* git clone fails with:
>
> fatal: premature end of pack file, 106 bytes missing
> fatal: index-pack failed
>
> At first, I tried 1.8.0, and it failed. Then I tried to build 1.7.10.5
> then, and it worked. Then I tried 1.7.12.2, but it fails the same way
> as 1.8.0.
> So I decided to git bisect.
>
> b8a2486f1524947f232f657e9f2ebf44e3e7a243 is the first bad commit
> ``index-pack: support multithreaded delta resolving''
This looks like the same problem I had on cygwin, which lead to
commit c0f86547c ("index-pack: Disable threading on cygwin", 26-06-2012).
I didn't notice which platform you are on, but maybe you also have a
thread-unsafe pread()? Could you try re-building git with the
NO_THREAD_SAFE_PREAD build variable set?
HTH.
ATB,
Ramsay Jones
^ permalink raw reply
* Re: [PATCH nd/wildmatch] Correct Git's version of isprint and isspace
From: "Jan H. Schönherr" @ 2012-11-13 18:58 UTC (permalink / raw)
To: Nguyễn Thái Ngọc Duy; +Cc: git, Junio C Hamano, rene.scharfe
In-Reply-To: <1352803572-14547-1-git-send-email-pclouds@gmail.com>
Hi.
Am 13.11.2012 11:46, schrieb Nguyễn Thái Ngọc Duy:
> Git's ispace does not include 11 and 12. Git's isprint includes
> control space characters (10-13). According to glibc-2.14.1 on C
> locale on Linux, this is wrong. This patch fixes it.
>
> Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
> ---
> I wrote a small C program to compare the result of all is* functions
> that Git replaces against the libc version. These are the only ones that
> differ. Which matches what Jan Schönherr commented.
>
> ctype.c | 6 +++---
> git-compat-util.h | 11 ++++++-----
> 2 files changed, 9 insertions(+), 8 deletions(-)
>
> diff --git a/ctype.c b/ctype.c
> index 0bfebb4..71311a3 100644
> --- a/ctype.c
> +++ b/ctype.c
> @@ -14,11 +14,11 @@ enum {
> P = GIT_PATHSPEC_MAGIC, /* other non-alnum, except for ] and } */
> X = GIT_CNTRL,
> U = GIT_PUNCT,
> - Z = GIT_CNTRL | GIT_SPACE
> + Z = GIT_CNTRL_SPACE
> };
>
> -const unsigned char sane_ctype[256] = {
> - X, X, X, X, X, X, X, X, X, Z, Z, X, X, Z, X, X, /* 0.. 15 */
> +const unsigned int sane_ctype[256] = {
> + X, X, X, X, X, X, X, X, X, Z, Z, Z, Z, Z, X, X, /* 0.. 15 */
> X, X, X, X, X, X, X, X, X, X, X, X, X, X, X, X, /* 16.. 31 */
> S, P, P, P, R, P, P, P, R, R, G, R, P, P, R, P, /* 32.. 47 */
> D, D, D, D, D, D, D, D, D, D, P, P, P, P, P, G, /* 48.. 63 */
An alternative to switching from 1-byte to 4-byte values (don't we have
a 2-byte datatype?), would be to free up GIT_CNTRL and simply do:
#define iscntrl(x) ((x) < 0x20)
> diff --git a/git-compat-util.h b/git-compat-util.h
> index 02f48f6..4ed3f94 100644
> --- a/git-compat-util.h
> +++ b/git-compat-util.h
[...]
> @@ -483,9 +483,10 @@ extern const unsigned char sane_ctype[256];
> #define GIT_PATHSPEC_MAGIC 0x20
> #define GIT_CNTRL 0x40
> #define GIT_PUNCT 0x80
> -#define sane_istest(x,mask) ((sane_ctype[(unsigned char)(x)] & (mask)) != 0)
> +#define GIT_SPACE 0x100
> +#define sane_istest(x,mask) ((sane_ctype[(unsigned int)(x)] & (mask)) != 0)
That should better be left "(unsigned char)"? We might access values after the
array otherwise.
(That said, it wasn't really correct before either, when there really is a
possibility that x >= 0x100.)
Regards
Jan
PS: It looks like my isprint() version was given precedence over your
isprint() version during the merge into next. That should also be sorted out,
but I've no idea which one is actually better: two comparisons versus one
cache lookup and a bitop... (though my guess is that comparisons are cheaper,
but then we should also convert isdigit()...)
^ permalink raw reply
* Re: [PATCH nd/wildmatch] Correct Git's version of isprint and isspace
From: René Scharfe @ 2012-11-13 19:14 UTC (permalink / raw)
To: Nguyễn Thái Ngọc Duy; +Cc: git, Junio C Hamano, schnhrr
In-Reply-To: <1352803572-14547-1-git-send-email-pclouds@gmail.com>
Am 13.11.2012 11:46, schrieb Nguyễn Thái Ngọc Duy:
> Git's isprint includes
> control space characters (10-13). According to glibc-2.14.1 on C
> locale on Linux, this is wrong. This patch fixes it.
isprint() is not in master, yet. Can we perhaps still introduce it in
such a way that we never have an incorrect version in master's history?
And could you please update test-ctype.c to match the change to
isspace()? The tests there just documented the status quo before I made
changes to ctype.c long ago, so it's definitions are just as correct (or
wrong) as the original implementation.
Thanks,
René
^ permalink raw reply
* Re: [PATCH nd/wildmatch] Correct Git's version of isprint and isspace
From: René Scharfe @ 2012-11-13 19:15 UTC (permalink / raw)
To: Nguyễn Thái Ngọc Duy, Linus Torvalds
Cc: git, Junio C Hamano, schnhrr
In-Reply-To: <1352803572-14547-1-git-send-email-pclouds@gmail.com>
Am 13.11.2012 11:46, schrieb Nguyễn Thái Ngọc Duy:
> Git's ispace does not include 11 and 12. [...]
> According to glibc-2.14.1 on C locale on Linux, this is wrong.
11 and 12 being vertical tab (\v) and form-feed (\f). This lack goes
back to the introduction of git's own character classifier macros seven
years ago in 4546738b (Unlocalized isspace and friends).
Linus, do you remember if you left them out on purpose?
Thanks,
René
^ permalink raw reply
* [PATCH] send-email: stop asking when we have an ident
From: Felipe Contreras @ 2012-11-13 19:19 UTC (permalink / raw)
To: git
Cc: Jeff King, Junio C Hamano, Thomas Rast, Jonathan Nieder,
Stephen Boyd, Felipe Contreras 2nd, Felipe Contreras
From: Felipe Contreras 2nd <felipe.contreras+2@gmail.com>
Currently we keep getting questions even when the user has properly
configured his full name and password:
Who should the emails appear to be from?
[Felipe Contreras <felipe.contreras@gmail.com>]
And once a question pops up, other questions are turned on. This is
annoying.
The reason this is safe is because currently the script fails completely
when the autohor (or committer) is not correct, so we won't even be
reaching this point in the code.
The scenarios, and the current situation:
1) No information at all, no fully qualified domain name
fatal: empty ident name (for <felipec@nysa.(none)>) not allowed
2) Only full name
fatal: unable to auto-detect email address (got 'felipec@nysa.(none)')
3) Full name + fqdm
Who should the emails appear to be from?
[Felipe Contreras <felipec@nysa.felipec.org>]
4) Full name + EMAIL
Who should the emails appear to be from?
[Felipe Contreras <felipe.contreras@gmail.com>]
5) User configured
6) GIT_COMMITTER
7) GIT_AUTHOR
All these are the same as 4)
After this patch:
1) 2) won't change: git send-email would still die
4) 5) 6) 7) will change: git send-email won't ask the user
This is good, that's what we would expect, because the identity is
explicit.
3) will change: git send-email won't ask the user
This is bad, because we will try with an address such as
'felipec@nysa.felipec.org', which is most likely not what the user
wants, but the user will get warned by default, and if not, most likley
the sending won't work, which the user can easily fix.
The worst possible scenario is that such a mail address does work, and
the user sends an email from that addres unintentionally, when in fact
the user expected to correct that address in the propmpt.
This is a very, very, very unlikely scenario, with many dependencies:
1) No configured user.name/user.email
2) No specified $EMAIL
3) No configured sendemail.from
4) No specified --from argument
5) A fully qualified domain name
6) A full name in the geckos field
7) A sendmail configuration that allows sending from this domain name
8) confirm=never, or
8.1) confirm configuration not hitting, or
8.2) Getting the error, not being aware of it
9) The user expecting to correct this address in the prompt
In a more likely scenario where 7) is not the case (can't send from
nysa.felipec.org), the user will simply see the mail was not sent
properly, and fix the problem.
The much more likely scenario though, is where 5) is not the case
(nysa.(none)), and git send-email will fail right away like it does now.
So the likelyhood of this affecting anybody seriously is very very slim,
and the chances of this affecting somebody slightly are still very
small. The vast majority, if not all, of git users won't be affected
negatively, and a lot will benefit from this.
Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
---
git-send-email.perl | 7 +------
1 file changed, 1 insertion(+), 6 deletions(-)
diff --git a/git-send-email.perl b/git-send-email.perl
index aea66a0..503e551 100755
--- a/git-send-email.perl
+++ b/git-send-email.perl
@@ -748,16 +748,11 @@ if (!$force) {
}
}
-my $prompting = 0;
if (!defined $sender) {
$sender = $repoauthor || $repocommitter || '';
- $sender = ask("Who should the emails appear to be from? [$sender] ",
- default => $sender,
- valid_re => qr/\@.*\./, confirm_only => 1);
- print "Emails will be sent from: ", $sender, "\n";
- $prompting++;
}
+my $prompting = 0;
if (!@initial_to && !defined $to_cmd) {
my $to = ask("Who should the emails be sent to (if any)? ",
default => "",
--
1.8.0
^ permalink raw reply related
* Re: [PATCH nd/wildmatch] Correct Git's version of isprint and isspace
From: Johannes Sixt @ 2012-11-13 19:41 UTC (permalink / raw)
To: Nguyễn Thái Ngọc Duy
Cc: git, Junio C Hamano, schnhrr, rene.scharfe
In-Reply-To: <1352803572-14547-1-git-send-email-pclouds@gmail.com>
Am 13.11.2012 11:46, schrieb Nguyễn Thái Ngọc Duy:
> @@ -14,11 +14,11 @@ enum {
> P = GIT_PATHSPEC_MAGIC, /* other non-alnum, except for ] and } */
> X = GIT_CNTRL,
> U = GIT_PUNCT,
> - Z = GIT_CNTRL | GIT_SPACE
> + Z = GIT_CNTRL_SPACE
> };
>
> -const unsigned char sane_ctype[256] = {
> - X, X, X, X, X, X, X, X, X, Z, Z, X, X, Z, X, X, /* 0.. 15 */
> +const unsigned int sane_ctype[256] = {
> + X, X, X, X, X, X, X, X, X, Z, Z, Z, Z, Z, X, X, /* 0.. 15 */
> X, X, X, X, X, X, X, X, X, X, X, X, X, X, X, X, /* 16.. 31 */
> S, P, P, P, R, P, P, P, R, R, G, R, P, P, R, P, /* 32.. 47 */
> D, D, D, D, D, D, D, D, D, D, P, P, P, P, P, G, /* 48.. 63 */
> diff --git a/git-compat-util.h b/git-compat-util.h
> index 02f48f6..4ed3f94 100644
> --- a/git-compat-util.h
> +++ b/git-compat-util.h
> @@ -474,8 +474,8 @@ extern const char tolower_trans_tbl[256];
> #undef ispunct
> #undef isxdigit
> #undef isprint
> -extern const unsigned char sane_ctype[256];
> -#define GIT_SPACE 0x01
> +extern const unsigned int sane_ctype[256];
> +#define GIT_CNTRL_SPACE 0x01
> #define GIT_DIGIT 0x02
> #define GIT_ALPHA 0x04
> #define GIT_GLOB_SPECIAL 0x08
> @@ -483,9 +483,10 @@ extern const unsigned char sane_ctype[256];
> #define GIT_PATHSPEC_MAGIC 0x20
> #define GIT_CNTRL 0x40
> #define GIT_PUNCT 0x80
> -#define sane_istest(x,mask) ((sane_ctype[(unsigned char)(x)] & (mask)) != 0)
> +#define GIT_SPACE 0x100
> +#define sane_istest(x,mask) ((sane_ctype[(unsigned int)(x)] & (mask)) != 0)
> #define isascii(x) (((x) & ~0x7f) == 0)
> -#define isspace(x) sane_istest(x,GIT_SPACE)
> +#define isspace(x) sane_istest(x,GIT_SPACE | GIT_CNTRL_SPACE)
> #define isdigit(x) sane_istest(x,GIT_DIGIT)
> #define isalpha(x) sane_istest(x,GIT_ALPHA)
> #define isalnum(x) sane_istest(x,GIT_ALPHA | GIT_DIGIT)
> @@ -493,7 +494,7 @@ extern const unsigned char sane_ctype[256];
> #define isupper(x) sane_iscase(x, 0)
> #define is_glob_special(x) sane_istest(x,GIT_GLOB_SPECIAL)
> #define is_regex_special(x) sane_istest(x,GIT_GLOB_SPECIAL | GIT_REGEX_SPECIAL)
> -#define iscntrl(x) (sane_istest(x,GIT_CNTRL))
> +#define iscntrl(x) (sane_istest(x,GIT_CNTRL | GIT_CNTRL_SPACE))
> #define ispunct(x) sane_istest(x, GIT_PUNCT | GIT_REGEX_SPECIAL | \
> GIT_GLOB_SPECIAL | GIT_PATHSPEC_MAGIC)
> #define isxdigit(x) (hexval_table[x] != -1)
So we have two properties that overlap:
SSSSSSSSSS
CCCCCCCC
You seem to generate partions:
XXXYYYYYZZZZZ
then assign individual bits to each partition. Now each entry in the
lookup table has only one bit set. Then you define isxxx() to check for
one of the two possible bits:
iscntrl is X or Y
isspace is Y or Z
But shouldn't you just assign one bit for S and another one for C, have
entries in the lookup table with more than one bit set, and check for
only one bit in the isxxx macro?
That way you don't run out of bits as easily as you do with this patch.
-- Hannes
^ permalink raw reply
* Re: [PATCH nd/wildmatch] Correct Git's version of isprint and isspace
From: Linus Torvalds @ 2012-11-13 19:40 UTC (permalink / raw)
To: René Scharfe
Cc: Nguyễn Thái Ngọc Duy, Git Mailing List,
Junio C Hamano, schnhrr
In-Reply-To: <50A29C3A.1070000@lsrfire.ath.cx>
On Tue, Nov 13, 2012 at 11:15 AM, René Scharfe
<rene.scharfe@lsrfire.ath.cx> wrote:
>
> Linus, do you remember if you left them out on purpose?
Umm, no.
I have to wonder why you care? As far as I'm concerned, the only valid
space is space, TAB and CR/LF.
Anything else is *noise*, not space. What's the reason for even caring?
Linus
^ permalink raw reply
* Re: [PATCH nd/wildmatch] Correct Git's version of isprint and isspace
From: Linus Torvalds @ 2012-11-13 19:50 UTC (permalink / raw)
To: René Scharfe
Cc: Nguyễn Thái Ngọc Duy, Git Mailing List,
Junio C Hamano, schnhrr
In-Reply-To: <CA+55aFwsjpOop=4mVkx4e=zw5LH41sD9x-b_WMo4Hvo7ygjEtQ@mail.gmail.com>
On Tue, Nov 13, 2012 at 11:40 AM, Linus Torvalds
<torvalds@linux-foundation.org> wrote:
>
> I have to wonder why you care? As far as I'm concerned, the only valid
> space is space, TAB and CR/LF.
>
> Anything else is *noise*, not space. What's the reason for even caring?
Btw, expanding the whitespace selection may actually be very
counter-productive. It is used primarily for things like removing
extraneous space at the end of lines etc, and for that, the current
selection of SPACE, TAB and LF/CR is the right thing to do.
Adding things like FF etc - that are *technically* whitespace, but
aren't the normal kind of silent whitespace - is potentially going to
change things too much. People might *want* a form-feed in their
messages, for all we know.
So I really object to changing things "just because". There's a reason
we do our own ctype.c: it avoids the crazy crap. It avoids the idiotic
localization issues, and it avoids the ambiguous cases.
So just let it be, unless you have some major real reason to actually
care about a real-world case. And if you do, please explain it. Don't
change things just because.
Linus
^ permalink raw reply
* Re: [regression] Newer gits cannot clone any remote repos
From: Douglas Mencken @ 2012-11-13 19:55 UTC (permalink / raw)
To: Ramsay Jones; +Cc: git
In-Reply-To: <50A2978D.6080805@ramsay1.demon.co.uk>
> Could you try re-building git with the
> NO_THREAD_SAFE_PREAD build variable set?
Yeah! It works!!!
--- evil/Makefile
+++ good/Makefile
@@ -957,6 +957,7 @@
HAVE_PATHS_H = YesPlease
LIBC_CONTAINS_LIBINTL = YesPlease
HAVE_DEV_TTY = YesPlease
+ NO_THREAD_SAFE_PREAD = YesPlease
endif
ifeq ($(uname_S),GNU/kFreeBSD)
NO_STRLCPY = YesPlease
With this, I do have correctly working git clone.
^ permalink raw reply
* Re: What's cooking in git.git (Nov 2012, #03; Tue, 13)
From: Junio C Hamano @ 2012-11-13 20:01 UTC (permalink / raw)
To: Jeff King; +Cc: git
In-Reply-To: <20121113175205.GA26960@sigill.intra.peff.net>
Jeff King <peff@peff.net> writes:
> This is my final "what's cooking" as interim maintainer. I didn't
> graduate anything to master, but I updated my plans for each topic to
> give Junio an idea of where I was.
After exploding the first-parent history between your master..pu
into component topics and recreating one new merge-fix for
nd/wildmatch topic, I think I now know how to rebuild your
integration branches.
I still haven't caught up with the past discussions (and still am
slightly jetlagged), but I think I can take it over from here with
help from contributors.
Thanks.
^ permalink raw reply
* Re: Fwd: [PATCH] Add tcsh-completion support to contrib by using git-completion.bash
From: Marc Khouzam @ 2012-11-13 20:12 UTC (permalink / raw)
To: SZEDER Gábor; +Cc: git, felipe.contreras
In-Reply-To: <20121113111448.GA3817@goldbirke>
Thanks for the review.
On Tue, Nov 13, 2012 at 6:14 AM, SZEDER Gábor <szeder@ira.uka.de> wrote:
> Hi,
>
> On Mon, Nov 12, 2012 at 03:07:46PM -0500, Marc Khouzam wrote:
>> Hi,
>
> [...]
>
>> Signed-off-by: Marc Khouzam <marc.khouzam@gmail.com>
>
> [...]
>
>> Thanks
>>
>> Marc
>>
>> ---
>> contrib/completion/git-completion.bash | 53 +++++++++++++++++++++++++++++++-
>> contrib/completion/git-completion.tcsh | 34 ++++++++++++++++++++
>> 2 files changed, 86 insertions(+), 1 deletions(-)
>> create mode 100755 contrib/completion/git-completion.tcsh
>
> Please have a look at Documentation/SubmittingPatches to see how to
> properly format the commit message, i.e. no greeting and sign-off in
> the commit message part, and the S-o-b line should be the last before
> the '---'.
Sorry about that, since I should have noticed it in the doc.
I will do my best to address all submission issues mentioned
when I post the next version of the patch.
> Your patch seems to be severely line-wrapped. That document also
> contains a few MUA-specific tips to help avoid that.
>
> Other than that, it's a good description of the changes and
> considerations. I agree that this approach seems to be the best from
> the three.
>
>> diff --git a/contrib/completion/git-completion.bash
>> b/contrib/completion/git-completion.bash
>> index be800e0..6d4b57a 100644
>> --- a/contrib/completion/git-completion.bash
>> +++ b/contrib/completion/git-completion.bash
>> @@ -1,4 +1,6 @@
>> -#!bash
>> +#!/bin/bash
>> +# The above line is important as this script can be executed when used
>> +# with another shell such as tcsh
>
> See comment near the end.
Great suggestion below. I removed the above change.
>> + # Set COMP_WORDS to the command-line as bash would.
>> + COMP_WORDS=($1)
>
> That comment is only true for older Bash versions. Since v4 Bash
> splits the command line at characters that the readline library treats
> as word separators when performing word completion. But the
> completion script has functions to deal with both, so this shouldn't
> be a problem.
I've updated the comment to be more general and left the code
the same since it is supported by the script.
>
>> + # Print the result that is stored in the bash variable ${COMPREPLY}
>
> Really? ;)
Removed :)
>> + for i in ${COMPREPLY[@]}; do
>> + echo "$i"
>> + done
>
> There is no need for the loop here to print the array one element per
> line:
>
> local IFS=$'\n'
> echo "${COMPREPLY[*]}"
Better. Thanks.
>> +if [ -n "$1" ] ; then
>> + # If there is an argument, we know the script is being executed
>> + # so go ahead and run the _git_complete_with_output function
>> + _git_complete_with_output "$1" "$2"
>
> Where does the second argument come from? Below you run this script
> as '${__git_tcsh_completion_script} "${COMMAND_LINE}"', i.e. $2 is
> never set. Am I missing something?
This second argument is optional and, if present, will be put in
$COMP_CWORD. If not present, $COMP_CWORD must be computed
from $1. Also see comment above _git_complete_with_output ().
tcsh does not provide me with this information, so I cannot make use of it.
However, I thought it would be more future-proof to allow it for other shells
which may have that information.
It is not necessary for tcsh, so I can remove if you prefer?
>> +# Make the script executable if it is not
>> +if ( ! -x ${__git_tcsh_completion_script} ) then
>> + chmod u+x ${__git_tcsh_completion_script}
>> +endif
>
> Not sure about this. If I source a script to provide completion for a
> command, then I definitely don't expect it to change file permissions.
>
> However, even if the git completion script is not executable, you can
> still run it with 'bash ${__git_tcsh_completion_script}'. This way
> neither the user would need to set permissions, not the script would
> need to set it behind the users back. Furthermore, this would also
> make changing the shebang line unnecessary.
Very nice! Done.
>> +complete git 'p/*/`${__git_tcsh_completion_script} "${COMMAND_LINE}"
>> | sort | uniq`/'
>> +complete gitk 'p/*/`${__git_tcsh_completion_script} "${COMMAND_LINE}"
>> | sort | uniq`/'
>
> Is the 'sort | uniq' really necessary? After the completion function
> returns Bash automatically sorts the elements in COMPREPLY and removes
> any duplicates. Doesn't tcsh do the same? I have no idea about tcsh
> completion.
On my machine, tcsh does not remove duplicates. It does sort the results
but that is done after I've run 'uniq', which is too late. I'm not
happy about this
either, but the other option is to improve git-completion.bash to
avoid duplicates,
which seemed less justified.
> Does the git completion script returns any duplicates at all?
It does. 'help' is returned twice for example.
Also, when completing 'git checkout ' in the git repo, I can see multiple
'todo' branches, as well as 'master', 'pu', 'next', etc.
You can actually try it without tcsh by running my proposed version of
git-completion.bash like this:
cd git/contrib/completion
bash git-completion.bash "git checkout " | sort | uniq --repeated
> Ambigious refs come to mind, but I just checked that refs completion,
> or rather 'git for-each-ref' (the command driving refs completion), is
> kind enough to make any ambigious ref names unique (i.e. a branch and
> a tag with the same name is listed as 'heads/name' and 'tags/name').
I will post a new version of the patch after looking at Felipe's patch for zsh,
which I was not aware of.
Thanks!
Marc
^ permalink raw reply
* [PATCH] gitk - fix a problem with multiline author names
From: Tomo Krajina @ 2012-11-13 20:26 UTC (permalink / raw)
To: git
When commiting with "git-commit" no newline in the author string
is possible. But other git clients don't have the same validations
for the author name. And, it is possible to have a commit like:
commit xxxxxxxx
Merge: aaaaa bbbbb
Author: User Name
<user.name@domain.com>
Date: Thu Nov 8 17:01:02 2012 +0100
Merge branch 'master' of ...
Note that the "Author:" string is split in two lines.
The git-log command work without problems with a commit like this, but
in gitk there is a problem because it splits the headers by a newline
character and that's why the email and time is not correctly parsed
and the history tree below this commit is not shown.
Signed-off-by: Tomo Krajina <tkrajina@gmail.com>
---
gitk-git/gitk | 16 +++++++++-------
1 file changed, 9 insertions(+), 7 deletions(-)
diff --git a/gitk-git/gitk b/gitk-git/gitk
index 6f24f53..87300db 100755
--- a/gitk-git/gitk
+++ b/gitk-git/gitk
@@ -1672,13 +1672,15 @@ proc parsecommit {id contents listed} {
foreach line [split $header "\n"] {
set line [split $line " "]
set tag [lindex $line 0]
- if {$tag == "author"} {
- set audate [lrange $line end-1 end]
- set auname [join [lrange $line 1 end-2] " "]
- } elseif {$tag == "committer"} {
- set comdate [lrange $line end-1 end]
- set comname [join [lrange $line 1 end-2] " "]
- }
+ if {$tag == "author"} {
+ regexp -lineanchor {\nauthor([^<]*)<([^>]*)>\s+([^\n]+)}
$header all auname email audate
+ set auname [string trim $auname]
+ set auname "$auname <$email>"
+ } elseif {$tag == "committer"} {
+ regexp -lineanchor
{\ncommitter([^<]*)<([^>]*)>\s+([^\n]+)} $header all comname email
comdate
+ set comname [string trim $comname]
+ set comname "$comname <$email>"
+ }
}
set headline {}
# take the first non-blank line of the comment as the headline
--
1.7.9.5
^ permalink raw reply related
* git-gui / Warning: "No newline at end of file”
From: Tobias Preuss @ 2012-11-13 20:26 UTC (permalink / raw)
To: git
Hello.
I noticed a problem when working with git-gui which might be a bug.
The issue only affects you when you are visually trying to stage
changes line by line. Here are the steps to reproduce the problem:
1. Initialize a new repository.
2. Create a file with three lines of content each with the word
"Hello". Do not put a new line at the end of the file.
3. Add and commit the file.
4. Edit the same file putting words inbetween the three lines.
5. Open git-gui and try to stage the changes line by line.
The editor will append the warning "No newline at end of file” to the
end of the diff. When you are trying to stage a line an error occurs.
The problem is also illustrated in a question on Stackoverflow [1].
Please let me know if you need more information or if I should send
this problem to some other mailing list.
Thank you, Tobias
____________
[1] http://stackoverflow.com/questions/13223868/how-to-stage-line-by-line-in-git-gui-although-no-newline-at-end-of-file-warnin
^ permalink raw reply
* Re: [regression] Newer gits cannot clone any remote repos
From: Douglas Mencken @ 2012-11-13 20:33 UTC (permalink / raw)
To: Ramsay Jones; +Cc: git
In-Reply-To: <CACYvZ7jMC5xw4LxiuG5m+=grpQEg+wZb_7BaU4Xn-r7ix=S-bw@mail.gmail.com>
By the way, it is the job of autotools to check such stuff, isn't it?
^ permalink raw reply
* Re: [PATCH] send-email: add proper default sender
From: Felipe Contreras @ 2012-11-13 20:35 UTC (permalink / raw)
To: Jeff King; +Cc: git, Thomas Rast, Junio C Hamano, Jonathan Nieder
In-Reply-To: <20121113164845.GD20361@sigill.intra.peff.net>
On Tue, Nov 13, 2012 at 5:48 PM, Jeff King <peff@peff.net> wrote:
> On Tue, Nov 13, 2012 at 10:06:26AM +0100, Felipe Contreras wrote:
>> I think you are the one that is not understanding what I'm saying. But
>> I don't think it matters.
>>
>> This is what I'm saying; the current situation with 'git commit' is
>> not OK, _both_ 'git commit' and 'git send-email' should change.
>
> Perhaps I am being dense, but this is the first time it became apparent
> to me that you are arguing for a change in "git commit".
Miscomunication then. When you mentioned 'it has always been the case
that you can use git without setting
user.*', I directed my comments at git in general, not git send-email.
>> Indeed I would, but there's other people that would benefit from this
>> patch. I'm sure I'm not the only person that doesn't have
>> sendmail.from configured, but does have user.name/user.email, and is
>> constantly typing enter.
>>
>> And the difference is that I'm _real_, the hypothetical user that
>> sends patches with GIT_AUTHOR_NAME/EMAIL is not. I would be convinced
>> otherwise if some evidence was presented that such a user is real
>> though.
>
> Sadly we cannot poll the configuration of every user, nor expect them
> all to pay attention to this discussion on the list. So we cannot take
> the absence of comment from such users as evidence that they do not
> exist.
And we cannot take it as evidence that these users do exist either.
The absence of evidence simply means that... we don't have evidence.
> Instead we must use our judgement about what is being changed,
> and we tend to err on the side of keeping the status quo, since that is
> what the silent majority is busy _not_ complaining about.
Yes, the keyword is *tend*; this wouldn't be first or the last time
that a behavior change happens.
We have to be careful about these changes, but we do them.
> We use the same judgement on the other side, too. Right now your
> evidence is "1 user wants this, 0 users do not".
1 is infinitely greater than 0.
> But we can guess that
> there are other people who would like the intent of your patch, but did
> not care enough or are not active enough on the list to write the patch
> themselves or comment on this thread.
Yes, that would be an educated guess. IMO the fact that people use
GIT_AUTHOR_ variables to send mail is not. There's many ways to
achieve that: sendemail.from, --from, user configuration, $EMAIL,
--compose and From:, etc. each and every one of them much more likely
to be used than GIT_AUTHOR_.
But I'm tired of arguing how extremely unlikely it is that such people
don't exist. Lets agree to disagree. Either way it doesn't matter,
because nobody is proposing a patch that would affect these
hypothetical users.
>> And to balance you need to *measure*, and that means taking into
>> consideration who actually uses the features, if there's any. And it
>> looks to me this is a feature nobody uses.
>
> You said "measure" and then "it looks to me like". What did you measure?
> Did you consider systematic bias in your measurement, like the fact that
> people who are using the feature have no reason to come on the list and
> announce it?
measure != scientific measurement.
I used common sense, because that's the only tool available.
GIT_AUTHOR is plumbing, not very well known, it's cumbersome (you need
to export two variables), it can be easily confused with
GIT_COMMITTER, which wouldn't work on this case. And there's plenty of
tools that much simpler to use, starting with 'git send-email --from',
which is so user friendly it's in the --help. There's absolutely no
reason why anybody would want to use GIT_AUTHOR.
But lets agree to disagree.
>> But listen closely to what you said:
>>
>> > I actually think it would make more sense to drop the prompt entirely and just die when the user has not given us a usable ident.
>>
>> Suppose somebody has a full name, and a fully qualified domain name,
>> and he can receive mails to it directly. Such a user would not need a
>> git configuration, and would not need $EMAIL, or anything.
>>
>> Currently 'git send-email' will throw 'Felipe Contreras
>> <felipec@felipec.org>' which would actually work, but is not explicit.
>>
>> You are suggesting to break that use-case. You are introducing a
>> regression. And this case is realistic, unlike the
>> GIT_AUTHOR_NAME/EMAIL. Isn't it?
>
> Yes, dying would be a regression, in that you would have to configure
> your name via the environment and re-run rather than type it at the
> prompt. You raise a good point that for people who _could_ take the
> implicit default, hitting "enter" is working fine now, and we would lose
> that. I'd be fine with also just continuing to prompt in the implicit
> case.
>
> But that is a much smaller issue to me than having send-email fail to
> respect environment variables and silently use user.*, which is what
> started this whole discussion. And I agree it is worth considering as a
> regression we should avoid.
It might be smaller, I don't think so. A hypothetical user that was
relying on GIT_AUTHOR for whatever reason can switch to 'git
send-email --from' (which is much easier) when they notice the
failure, the same way somebody relying on fqdn would. The difference
is that people with fqdn do exist, and they might be relying on this.
Both are small issues, that I agree with.
But the point is that you seem to be very adamant about _my_
regressions, and not pay much attention about yours.
>> I prefer to concentrate on real issues, but that's just me.
>
> To be honest, I am confused at this point what you actually want. Do you
> think we should take your original patch? I think its regression is too
> great. And I am not sure if you agree or not. You seem to be arguing
> that the regression is not important, yet you simultaneously argue that
> we should be making all ident more strict, which would mean that we
> should indeed take my suggestion and use "git var" instead of preferring
> the config.
No, I was proposing my second patch. That's why I sent a second patch.
But forget it. I don't think it's worth trying to do the right thing
here (make both 'git commit' and 'git send-email' be stricter). I do
think that would be simpler than all the required changes to var, and
better, but that's not my itch atm.
>> > As for whether they exist, what data do you have?
>>
>> What data do _you_ have?
>>
>> When there's no evidence either way, the rational response is to don't
>> believe. That's the default position.
>
> This is not religion. It is a software project.
This has absolutely nothing to with religion, this is rationality. If
you don't want to make a distinction between the different levels at
which we _know_ something, suit yourself.
> In the absence of data,
> the sane thing is not to break existing users.
What you decide to do has absolutely nothing to do with what is true.
These hypothetical users exist, or they don't. I don't have data for
their existence, you don't have data for their non-existence. In the
absence of data the rational response is to don't believe the claim,
and this one is particularly clear because you cannot prove a
negative, so the burden of proof is clearly on your side, as it's
*impossible* for me to prove that there are no users that use certain
feature, and it's very easy for you to do so, as all you need is
*one*.
Presumably you are not interested in fulfilling your burden of proof,
which is fine, you can choose the safest action without proof that
such users exist, but that doesn't change the fact that you don't know
that if they exist or not.
And yet, you continue to say they do exist, and try to win the
argument by means of rhetoric: 'not to break existing users'; they are
not *existing* users, they are hypothetical.
> The burden is on you to
> argue that there is no such breakage.
That's impossible to prove. *Nobody* can prove that people are not
using even the most obscure feature of git.
All you do is make educated guesses, and try to minimize the damage.
>> > Are you aware that the
>> > test suite, for example, relies on setting GIT_AUTHOR_NAME but not
>> > having any user.* config?
>>
>> What tests? My patch doesn't seem to break anything there:
>> % make -C t t9001-send-email.sh
>> # passed all 96 test(s)
>
> My point was that there is at least one known setup that uses only
> environment variables and not a config file, and that the rest of git is
> intended to work with that. It is not a test failure, but t9001.18
> reveals the fact that your change does not handle this situation; we
> continue to prompt under the test suite's configuration. In the proper
> fix, the test needs to be adjusted.
>
> You don't see any test failures with your patch because we do not cover
> the case that you regress (GIT_AUTHOR_EMAIL and user.email both set).
Exactly, but I was not the one that brought the test suite. My patch
is not a problem for our current tests. So this hypothetical user
remains evasive.
>> > When somebody comes on the list and asks why
>> > every git program in the entire system respects GIT_* environment
>> > variables as an override to user.* configuration _except_ for
>> > send-email, what should I say?
>>
>> The same thing you say when somebody comes reporting a bug: "yeah, we
>> should probably fix that".
>
> It is a larger hassle for both the developer and the user to fix the bug
> after the fact,
*If* that happens, which in all likelihood it won't.
> ship a new version, and then have the user upgrade their
> git. Why not just not introduce the bug in the first place?
Because we are spending more time arguing about something that most
likely won't happen.
There's a chance the next time you sit the chair will break because of
a bad leg, but you don't engage in philosophical discussions each time
you are going to sit, you go ahead and sit down, and take your
chances, and 99.9% of the time you would be fine.
>> It's all about proportion. Is it possible that we all are going to die
>> tomorrow because of an asteroid? Sure... but what's the point of
>> worrying about it if it's not likely?
>
> If you want to talk about risk assessment, then the right computation is
> to compare the cost of fixing it now versus the cost of fixing it later
> times the probability of it happening. The development cost is probably
> a little higher later (because we have to refresh ourselves on the
> issue), but the deployment cost is much higher (e.g., users whose
> distros ship a broken version, or who have IT policy that does not let
> them upgrade git as soon as the bug-fix ships).
Times 0.01 (at best), and you get barely nothing.
>> >> That's right, AUTHOR_IDENT would fall back to the default email and full name.
>> >
>> > Yeah, I find that somewhat questionable in the current behavior, and I'd
>> > consider it a bug. Typically we prefer the committer ident when given a
>> > choice (e.g., for writing reflog entries).
>>
>> Yeah, but clearly the intention of the code was to use the committer
>> if the author wasn't available, which is the case here.
>
> Yes. It would make sense to me to respect an explicit committer over an
> implicit author. Though the fact that author is preferred over committer
> is inconsistent with most of the rest of git. I'm undecided whether that
> should be changed.
Indeed. And that's something I won't worry about, because I honestly
believe nobody is using neither GIT_COMMITTER, nor GIT_AUTHOR, and the
fact that nobody has found this breakage only increases my certainty.
>> >> What about after my change?
>> >>
>> >> 6.1) GIT_AUTHOR without anything else
>> >>
>> >> fatal: empty ident name (for <felipec@nysa.(none)>) not allowed
>> >> var GIT_COMMITTER_IDENT: command returned error: 128
>> >
>> > Doesn't that seem like a regression? It used to work.
>>
>> No, this is *before* my change.
>>
>> I's the same bug as 5.1):
>
> Ah, I see. We are loading both, whether or not they end up being used,
> and barfing prematurely on errors. That seems like a bug.
Yes.
>> >> And what about your proposed change?
>> >
>> > Let me be clear that I sent you a "something like this" patch to try to
>> > point you in the right direction. If it has a bug or is incomplete, that
>> > does not mean the direction is wrong, but only that I did not spend very
>> > much time on the patch.
>>
>> It doesn't matter, the idea was to use user_ident_sufficiently_given().
>
> Right. Which it sounds like now agree with me on?
No. I tried the idea, it didn't work.
I saw your patches about
{committer,author}_ident_sufficiently_given(), those might work, but I
don't think they are _needed_. They might be nice though.
>> > I think that respecting the usual ident lookup but disallowing implicit
>> > identities (either totally, or causing them to fallback to prompting) is
>> > the right direction. I agree my patch was not a complete solution. I'm
>> > sorry if it led you astray in terms of implementation, but I also think
>> > I've been very clear in my text about what the behavior should be.
>>
>> I think that is orthogonal to what I'm trying accomplish.
>
> What is it you are trying to accomplish? Eliminating the prompt in some
> cases, as in your original patch? Dealing with implicit identities may
> be orthogonal to your goal, but your original patch is not sufficient,
> as it reverses the precedence of config and environment variables.
No, it doesn't.
Why do you hold on to my first patch? The second patch doesn't have
this issue. It does change the behavior of 'git commit', yeah, but I
think that's a benefit.
You might disagree, but there's no point in going back to discuss the
first patch.
> So you can either:
>
> 1. Reimplement the environment variable lookup that ident.c does,
> leaving implicit ident logic out completely.
>
> 2. Modify ident.c and "git var" to let send-email reuse the logic in
> ident.c, but avoid dropping the prompt when an implicit ident is
> used.
>
> Doing (2) sounds a lot more maintainable to me in the long run.
Or:
3. Change the meaning of the STRICT flag so that the values are
explicit, which has benefits outside 'git send-email'. Yes, this would
change the behavior in 'git commit' and other tools, but it's worth to
investigate these changes, and most likely they would be desirable.
Or:
4. Just stop prompting
I already sent a patch for 4. with all the details of why nobody (or
very few, if any) would be affected negatively.
>> > Don't get me wrong. I think the spirit of your patch is correct, and it
>> > helps some git users. But it also hurts others. And it is not that hard
>> > to do it right.
>>
>> And I disagree, I think it hurts nobody, and I think it's hard to do it right.
>
> I am tired of talking about this. The patch series below took me less
> time to write than I have spent arguing with you. It was not that hard.
>
> [1/6]: ident: make user_ident_explicitly_given private
> [2/6]: ident: keep separate "explicit" flags for author and committer
> [3/6]: var: accept multiple variables on the command line
> [4/6]: var: provide explicit/implicit ident information
> [5/6]: Git.pm: teach "ident" to query explicitness
> [6/6]: send-email: do not prompt for explicit repo ident
I think this adds a lot of code that nobody would use.
The prompt will happen only if:
1) No configured user.name/user.email
2) No specified $EMAIL
3) No configured sendemail.from
4) No specified --from argument
5) A fully qualified domain name
6) A full name in the geckos field
Very, very unlikely.
And if:
* A sendmail configuration doesn't allow sending from this domain name
* The user sees the problem in the confirmation part
Then the user would see a problem anyway, so the prompt is not adding
that much value.
>> Fixing a regression that nobody would notice is not my itch either,
>
> Sorry, but it is part of your itch. The git project is at state A. With
> your patch, we are at a regressed state B.
And that's fine.
> If you then fix it, we are at
> state C. From your perspective, it may be "I do not want to make the fix
> to go from B to C". But from the project's perspective, it is "we do not
> want to go from state A to state B; state C would be acceptable". So
> from the perspective of people who do not care about your feature but do
> care about the regression in state B, it is inextricably linked to your
> itch.
No it's not. It's a conflict of interests. It's only linked as long as
people care about the "regression" in state B. If they realize this
"regression" is irrelevant, then there wouldn't be any problem. This,
is now clear is not going to happen. But I don't think your opinions
define whether or not I have an itch.
>> yet the patch I sent above does it, and it even fixes 'git commit'
>> (IMO). But it's also not good enough.
>
> I do not necessarily agree on "git commit". Moreover, I feel like it is
> a separate issue. My series above _just_ implements the "do not prompt
> when explicit" behavior. It does not deal with git-commit at all, nor
> does it address the author/committer fallback questions. Those can
> easily go on top.
Yes, at the cost of adding a lot of code. If we end up agreeing that
the changes to 'git commit' are desirable (which I hope at some point
we will), then this code would be all for nothing.
I sent another patch series that is very simple[1]. This deals with
the hypothetical GIT_AUTHOR users, but might hit another set of
hypothetical users, but the damage would be very small, and the
possibility of these users existing very low. IOW; very low risk.
I want clarify that this is merely a disagreement to at which level
should we worry about regressions. On one side of the spectrum you
have projects like GNOME, who don't have any problem breaking the
user-experience from one release to the next, I'm not proposing
anything like that. On the other side I think it's you, because I
don't recall encountering anybody with such an extreme position of
never introducing a regression ever if there's absolutely no evidence
that anybody is using certain feature. That's fine, it's your opinion,
I respectfully disagree. Personally, I think the sweet spot is between
the two, far from GNOME, but not quite to the point where no
regressions happen ever. When there's a good chance that very few
people will be hit, and the drawback is small, then it's OK to
introduce regressions. Always keeping in mind that these risk
assessments might be wrong, and there might be more people hit than
expected and/or the problems were greater, but if/when that happens,
*then* we simply deal with it.
Cheers.
[1] http://mid.gmane.org/1352834364-2674-1-git-send-email-felipe.contreras@gmail.com
--
Felipe Contreras
^ permalink raw reply
* Re: What's cooking in git.git (Nov 2012, #03; Tue, 13)
From: Torsten Bögershausen @ 2012-11-13 20:45 UTC (permalink / raw)
To: Jeff King, mlevedahl; +Cc: git, Torsten Bögershausen
In-Reply-To: <20121113175205.GA26960@sigill.intra.peff.net>
> * ml/cygwin-mingw-headers (2012-11-12) 1 commit
> - Update cygwin.c for new mingw-64 win32 api headers
>
> Make git work on newer cygwin.
>
> Will merge to 'next'.
(Sorry for late answer, I managed to test the original patch minutes before Peff merged it to pu)
(And thanks for maintaining git)
Is everybody using cygwin happy with this?
I managed to compile on a fresh installed cygwin,
but failed to compile under 1.7.7, see below.
Is there a way we can achieve to compile git both under "old" and "new" cygwin 1.7 ?
Or is this not worth the effort?
/Torsten
CC compat/cygwin.o
In file included from compat/../git-compat-util.h:90,
from compat/cygwin.c:9:
/usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../../include/w32api/winsock2.h:103:2: warning: #warning "fd_set and associated macros have been defined in sys/types. This may cause runtime problems with W32 sockets"
In file included from /usr/include/sys/socket.h:16,
from compat/../git-compat-util.h:131,
from compat/cygwin.c:9:
/usr/include/cygwin/socket.h:29: error: redefinition of `struct sockaddr'
/usr/include/cygwin/socket.h:41: error: redefinition of `struct sockaddr_storage'
In file included from /usr/include/sys/socket.h:16,
from compat/../git-compat-util.h:131,
from compat/cygwin.c:9:
/usr/include/cygwin/socket.h:59: error: redefinition of `struct linger'
In file included from compat/../git-compat-util.h:131,
from compat/cygwin.c:9:
/usr/include/sys/socket.h:30: error: conflicting types for 'accept'
/usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../../include/w32api/winsock2.h:536: error: previous declaration of 'accept' was here
^ permalink raw reply
* RE: What's cooking in git.git (Nov 2012, #03; Tue, 13)
From: Pyeron, Jason J CTR (US) @ 2012-11-13 20:48 UTC (permalink / raw)
To: git@vger.kernel.org
In-Reply-To: <50A2B14C.9040608@web.de>
[-- Attachment #1: Type: text/plain, Size: 891 bytes --]
> -----Original Message-----
> From: Torsten Bögershausen
> Sent: Tuesday, November 13, 2012 3:45 PM
>
> > * ml/cygwin-mingw-headers (2012-11-12) 1 commit
> > - Update cygwin.c for new mingw-64 win32 api headers
> >
> > Make git work on newer cygwin.
> >
> > Will merge to 'next'.
>
> (Sorry for late answer, I managed to test the original patch minutes
> before Peff merged it to pu)
> (And thanks for maintaining git)
>
> Is everybody using cygwin happy with this?
>
> I managed to compile on a fresh installed cygwin,
> but failed to compile under 1.7.7, see below.
> Is there a way we can achieve to compile git both under "old" and "new"
> cygwin 1.7 ?
> Or is this not worth the effort?
Only supporting the new cygwin would make sense. You have to work hard at using older cygwin environments. I will give it a spin later today or tomorrow.
-Jason
[-- Attachment #2: smime.p7s --]
[-- Type: application/x-pkcs7-signature, Size: 5615 bytes --]
^ permalink raw reply
* Re: [PATCH v3 0/8] Fix GIT_CEILING_DIRECTORIES that contain symlinks
From: David Aguilar @ 2012-11-13 20:50 UTC (permalink / raw)
To: Junio C Hamano
Cc: Michael Haggerty, Jiang Xin, Lea Wiemann, David Reiss,
Johannes Sixt, git, Lars R. Damerow, Jeff King, Marc Jordan
In-Reply-To: <7v4nkuiuhe.fsf@alter.siamese.dyndns.org>
On Mon, Nov 12, 2012 at 9:47 AM, Junio C Hamano <gitster@pobox.com> wrote:
> Michael Haggerty <mhagger@alum.mit.edu> writes:
>
>> The log message of the original commit (0454dd93bf) described the
>> following scenario: a /home partition under which user home directories
>> are automounted, and setting GIT_CEILING_DIRECTORIES=/home to avoid
>> hitting /home/.git, /home/.git/objects, and /home/objects (which would
>> attempt to automount those directories). I believe that this scenario
>> would not be slowed down by my patches.
>>
>> How do you use GIT_CEILING_DIRECTORIES that the proposed changes cause a
>> slowdown?
>
> Yeah, I was also wondering about that.
>
> David?
I double-checked our configuration and all the parent directories
of those listed in GIT_CEILING_DIRECTORIES are local,
so our particular configuration would not have a performance hit.
We do have multiple directories listed there. Some of them share
a parent directory. I'm assuming the implementation is simple and
does not try and avoid repeating the check when the parent dir is
the same across multiple entries.
In any case, it won't be a problem in practice based on my
reading of the current code.
>>> Is there another way to accomplish this without the performance hit?
>>> Maybe something that can be solved with configuration?
>>
>> Without doing the symlink expansion there is no way for git to detect
>> that GIT_CEILING_DIRECTORIES contains symlinks and is therefore
>> ineffective. So the user has no warning about the misconfiguration
>> (except that git runs slowly).
>>
>> On 10/29/2012 02:42 AM, Junio C Hamano wrote:
>>> Perhaps not canonicalize elements on the CEILING list ourselves? If
>>> we make it a user error to put symlinked alias in the variable, and
>>> document it clearly, wouldn't it suffice?
>>
>> There may be no other choice. (That, and fix the test suite in another
>> way to tolerate a $PWD that involves symlinks.)
--
David
^ permalink raw reply
* Re: [regression] Newer gits cannot clone any remote repos
From: Torsten Bögershausen @ 2012-11-13 20:51 UTC (permalink / raw)
To: Ramsay Jones; +Cc: Douglas Mencken, git, Torsten Bögershausen
In-Reply-To: <50A2978D.6080805@ramsay1.demon.co.uk>
On 13.11.12 19:55, Ramsay Jones wrote:
> Douglas Mencken wrote:
>> *Any* git clone fails with:
>>
>> fatal: premature end of pack file, 106 bytes missing
>> fatal: index-pack failed
>>
>> At first, I tried 1.8.0, and it failed. Then I tried to build 1.7.10.5
>> then, and it worked. Then I tried 1.7.12.2, but it fails the same way
>> as 1.8.0.
>> So I decided to git bisect.
>>
>> b8a2486f1524947f232f657e9f2ebf44e3e7a243 is the first bad commit
>> ``index-pack: support multithreaded delta resolving''
>
> This looks like the same problem I had on cygwin, which lead to
> commit c0f86547c ("index-pack: Disable threading on cygwin", 26-06-2012).
>
> I didn't notice which platform you are on, but maybe you also have a
> thread-unsafe pread()? Could you try re-building git with the
> NO_THREAD_SAFE_PREAD build variable set?
>
> HTH.
>
> ATB,
> Ramsay Jones
This is interesting.
I had the same problem on a PowerPC
(Old PowerBook G4 running Linux).
Using NO_THREAD_SAFE_PREAD helped, thanks for the hint.
(After recompiling without NO_THREAD_SAFE_PREAD I could clone
from this machine again, so the problem is not really reproducable)
Are there more people running PowerPC (on the server side) ?
/Torsten
^ permalink raw reply
* Re: [PATCH v3 0/5] push: update remote tags only with force
From: Junio C Hamano @ 2012-11-13 21:20 UTC (permalink / raw)
To: Chris Rorvick
Cc: git, Angelo Borsotti, Drew Northup, Michael Haggerty,
Philip Oakley, Johannes Sixt, Kacper Kornet, Jeff King,
Felipe Contreras
In-Reply-To: <1352693288-7396-1-git-send-email-chris@rorvick.com>
Chris Rorvick <chris@rorvick.com> writes:
> Minor changes since from v2 set. Reposting primarily because I mucked
> up the Cc: list (again) and hoping to route feedback to the appropriate
> audience.
>
> This patch set can be divided into two sets:
>
> 1. Provide useful advice for rejected tag references.
>
> push: return reject reasons via a mask
> push: add advice for rejected tag reference
>
> Recommending a merge to resolve a rejected tag update seems
> nonsensical since the tag does not come along for the ride. These
> patches change the advice for rejected tags to suggest using
> "push -f".
Below, I take that you mean by "tag reference" everything under
refs/tags/ (not limited to "annotated tag objects", but also
lightweight tags).
Given that the second point below is to strongly discourage updating
of existing any tag, it might be even better to advise *not* to push
tags in the first place, instead of destructive "push -f", no?
> 2. Require force when updating tag references, even on a fast-forward.
>
> push: flag updates
> push: flag updates that require force
> push: update remote tags only with force
>
> An email thread initiated by Angelo Borsotti did not come to a
> consensus on how push should behave with regard to tag references.
I think the original motivation of allowing fast-forward updates to
tags was for people who wanted to have "today's recommended version"
tag that can float from day to day. I tend to think that was a
misguided notion and it is better implemented with a tip of a
branch (iow, I personally am OK with the change to forbid tag
updates altogether, without --force).
> I think a key point is that you currently cannot be sure your push
> will not clobber a tag (lightweight or not) in the remote.
"Do not update, only add new" may be a good feature, but at the same
time I have this suspicion that its usefulness may not necessarily
be limited to refs/tags/* hierarchy.
I dunno.
^ permalink raw reply
* Re: [PATCH] update-index/diff-index: use core.preloadindex to improve performance
From: Karsten Blees @ 2012-11-13 21:51 UTC (permalink / raw)
To: Junio C Hamano; +Cc: karsten.blees, Jeff King, git, msysgit, pro-logic
In-Reply-To: <7v4nktfo35.fsf@alter.siamese.dyndns.org>
Am 13.11.2012 17:46, schrieb Junio C Hamano:
> karsten.blees@dcon.de writes:
>
> If anything, "fix your mailer" probably is the policy you are
> looking for, I think.
Well then...I've cloned myself @gmail, I hope this is better.
Just some provoking thoughts...(if I may):
RFC-5322 recommends wrapping lines at 78, and mail relays and gateways are allowed to change message content according to the capabilities of the receiver (RFC-5598). In essence, plaintext mail is completely unsuitable for preformatted text such as source code.
On the other hand, git tries to solve the very problem of distributed source code management, and consistency by strong sha-1 checksums is on the top of the feature list.
It is somehow hard to believe that contributing to git itself should only be possible using the most unreliable of protocols. Don't you trust your own software?
-- >8 --
Subject: [PATCH] update-index/diff-index: use core.preloadindex to improve performance
'update-index --refresh' and 'diff-index' (without --cached) don't honor
the core.preloadindex setting yet. Porcelain commands using these (such as
git [svn] rebase) suffer from this, especially on Windows.
Use read_cache_preload to improve performance.
Additionally, in builtin/diff.c, don't preload index status if we don't
access the working copy (--cached).
Results with msysgit on WebKit repo (2GB in 200k files):
| update-index | diff-index | rebase
----------------+--------------+------------+---------
msysgit-v1.8.0 | 9.157s | 10.536s | 42.791s
+ preloadindex | 9.157s | 10.536s | 28.725s
+ this patch | 2.329s | 2.752s | 15.152s
+ fscache [1] | 0.731s | 1.171s | 8.877s
[1] https://github.com/kblees/git/tree/kb/fscache-v3
Thanks-to: Albert Krawczyk <pro-logic@optusnet.com.au>
Signed-off-by: Karsten Blees <blees@dcon.de>
---
Can also be pulled from: https://github.com/kblees/git/tree/kb/update-diff-index-preload-upstream
More performance figures (for msysgit) can be found in this discussion: https://github.com/pro-logic/git/commit/32c03dd8
builtin/diff-index.c | 8 ++++++--
builtin/diff.c | 12 ++++++++----
builtin/update-index.c | 1 +
3 files changed, 15 insertions(+), 6 deletions(-)
diff --git a/builtin/diff-index.c b/builtin/diff-index.c
index 2eb32bd..1c737f7 100644
--- a/builtin/diff-index.c
+++ b/builtin/diff-index.c
@@ -41,9 +41,13 @@ int cmd_diff_index(int argc, const char **argv, const char *prefix)
if (rev.pending.nr != 1 ||
rev.max_count != -1 || rev.min_age != -1 || rev.max_age != -1)
usage(diff_cache_usage);
- if (!cached)
+ if (!cached) {
setup_work_tree();
- if (read_cache() < 0) {
+ if (read_cache_preload(rev.diffopt.pathspec.raw) < 0) {
+ perror("read_cache_preload");
+ return -1;
+ }
+ } else if (read_cache() < 0) {
perror("read_cache");
return -1;
}
diff --git a/builtin/diff.c b/builtin/diff.c
index 9650be2..198b921 100644
--- a/builtin/diff.c
+++ b/builtin/diff.c
@@ -130,8 +130,6 @@ static int builtin_diff_index(struct rev_info *revs,
usage(builtin_diff_usage);
argv++; argc--;
}
- if (!cached)
- setup_work_tree();
/*
* Make sure there is one revision (i.e. pending object),
* and there is no revision filtering parameters.
@@ -140,8 +138,14 @@ static int builtin_diff_index(struct rev_info *revs,
revs->max_count != -1 || revs->min_age != -1 ||
revs->max_age != -1)
usage(builtin_diff_usage);
- if (read_cache_preload(revs->diffopt.pathspec.raw) < 0) {
- perror("read_cache_preload");
+ if (!cached) {
+ setup_work_tree();
+ if (read_cache_preload(revs->diffopt.pathspec.raw) < 0) {
+ perror("read_cache_preload");
+ return -1;
+ }
+ } else if (read_cache() < 0) {
+ perror("read_cache");
return -1;
}
return run_diff_index(revs, cached);
diff --git a/builtin/update-index.c b/builtin/update-index.c
index 74986bf..ada1dff 100644
--- a/builtin/update-index.c
+++ b/builtin/update-index.c
@@ -593,6 +593,7 @@ struct refresh_params {
static int refresh(struct refresh_params *o, unsigned int flag)
{
setup_work_tree();
+ read_cache_preload(NULL);
*o->has_errors |= refresh_cache(o->flags | flag);
return 0;
}
--
1.8.0.msysgit.0.3.g7d9d98c
--
*** Please reply-to-all at all times ***
*** (do not pretend to know who is subscribed and who is not) ***
*** Please avoid top-posting. ***
The msysGit Wiki is here: https://github.com/msysgit/msysgit/wiki - Github accounts are free.
You received this message because you are subscribed to the Google
Groups "msysGit" group.
To post to this group, send email to msysgit@googlegroups.com
To unsubscribe from this group, send email to
msysgit+unsubscribe@googlegroups.com
For more options, and view previous threads, visit this group at
http://groups.google.com/group/msysgit?hl=en_US?hl=en
^ permalink raw reply related
* Re: [regression] Newer gits cannot clone any remote repos
From: Andreas Schwab @ 2012-11-13 22:36 UTC (permalink / raw)
To: Torsten Bögershausen; +Cc: Ramsay Jones, Douglas Mencken, git
In-Reply-To: <50A2B2DF.1080704@web.de>
Torsten Bögershausen <tboegi@web.de> writes:
> Are there more people running PowerPC (on the server side) ?
I cannot reproduce the problem (on openSUSE 12.2).
Andreas.
--
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
^ permalink raw reply
* bug? git format-patch -M -D then git am fails
From: Joe Perches @ 2012-11-13 22:41 UTC (permalink / raw)
To: git; +Cc: David Miller
If a file is deleted with git rm and a patch
is then generated with git format-patch -M -
^ 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