* git-completion.tcsh and git-completion.zsh are broken?
From: Manlio Perillo @ 2013-01-09 19:17 UTC (permalink / raw)
To: git@vger.kernel.org
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi.
I have finally resolved all the problems with my path completion in
git-completion.bash and, in order to avoid regressions, I'm checking the
git-completion.zsh and git-completion.tcsh scripts, since they use the
bash completion support.
I have installed (Debian 6.0.6):
* zsh 4.3.10 (i686-pc-linux-gnu)
* tcsh 6.17.02 (Astron) 2010-05-12 (i586-intel-linux)
options wide,nls,dl,al,kan,rh,nd,color,filec
Note that I'm using my modified git-completion.bash script.
zsh compatibility support in git-completion.bash seems to "work" (I just
get a segmentation fault ...), however I have problems with the .zsh and
.tcsh scripts.
$zsh
synapsis% source contrib/completion/git-completion.zsh
(anon):6: command not found: ___main
_git:11: command not found: _default
I have disabled compinit autoload (since, I don't know how, it is able
to find the git completion script)
$tcsh
synapsis:~/projects/git/contrib/git> source ~/.git-completion.tcsh
synapsis:~/projects/git/contrib/git> git show HEAD:<TAB>
does not show the file list for the tree object in the HEAD
another problem is that a space is added after a directory name.
Another problem with zsh:
$zsh
synapsis% git show HEAD:<TAB>569GPXZims
I don't know where that 569GPXZims came from.
Can someone else confirm these problems?
Thanks Manlio
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAlDtwjcACgkQscQJ24LbaURpuACfVQnoBC3tzvxB0JYxQ5aL3rmN
8GEAnA7OjVtPqz+aq/PGtNtTHWgFqhKK
=3UdZ
-----END PGP SIGNATURE-----
^ permalink raw reply
* Re: t7400 broken on pu (Mac OS X)
From: Junio C Hamano @ 2013-01-09 19:16 UTC (permalink / raw)
To: Torsten Bögershausen; +Cc: git, Nguyễn Thái Ngọc Duy
In-Reply-To: <50EDBA37.30205@web.de>
Torsten Bögershausen <tboegi@web.de> writes:
> The current pu fails on Mac OS, case insensitive FS.
>
>
> Bisecting points out
> commit 3f28e4fafc046284657945798d71c57608bee479
> [snip]
> Date: Sun Jan 6 13:21:07 2013 +0700
Next time do not [snip] but please find the author address there,
and Cc such a report.
I think this topic is planned to be rerolled anyway, and your report
would be a valuable input while doing so.
Thanks.
^ permalink raw reply
* Re: [PATCH 16/19] reset [--mixed] --quiet: don't refresh index
From: Junio C Hamano @ 2013-01-09 19:12 UTC (permalink / raw)
To: Martin von Zweigbergk; +Cc: Jeff King, git
In-Reply-To: <CANiSa6joBuAJVHkMfNbVMHFJ6BFOh7sGRw_txRO81CKudRwsfA@mail.gmail.com>
Martin von Zweigbergk <martinvonz@gmail.com> writes:
>> We have never been very clear about which commands refresh the index.
>
> Yes, git-reset's documentation doesn't mention it.
>
>> Since "reset" is about manipulating the index, I'd expect it to be
>> refreshed afterwards. On the other hand, since we have never guaranteed
>> anything, perhaps a careful script should always use "git update-index
>> --refresh".
>
> Since "git diff-files" is a plumbing command, users of it to a
> hopefully a bit more careful than regular users, but you never know.
>
>> I would not be too surprised if some of our own scripts are
>> not that careful, though.
>
> I didn't find any, but I might have missed something.
contrib/examples/ have some, but looking at it makes me realize that
we have been fairly careful to avoid using "git reset" which is a
Porcelain.
And as a Porcelain, I would rather expect it to leave the resulting
index refreshed.
^ permalink raw reply
* Re: [PATCH 16/19] reset [--mixed] --quiet: don't refresh index
From: Martin von Zweigbergk @ 2013-01-09 18:43 UTC (permalink / raw)
To: Jeff King; +Cc: git, Junio C Hamano
In-Reply-To: <20130109170119.GA5332@sigill.intra.peff.net>
On Wed, Jan 9, 2013 at 9:01 AM, Jeff King <peff@peff.net> wrote:
> On Wed, Jan 09, 2013 at 12:16:13AM -0800, Martin von Zweigbergk wrote:
>
>> "git reset [--mixed]" without --quiet refreshes the index in order to
>> display the "Unstaged changes after reset". When --quiet is given,
>> that output is suppressed, removing the need to refresh the index.
>> Other porcelain commands that care about a refreshed index should
>> already be refreshing it, so running e.g. "git reset -q && git diff"
>> is still safe.
>
> Hmm. But "git reset -q && git diff-files" would not be?
Right. Actually, "git reset -q && git diff" was perhaps not a good
example, because its analogous plumbing command would be "git reset -q
&& git diff-files -p", which is also safe. But, as you say, "git reset
-q && git diff-files" (without -p) might list files for which only the
stat information has changed.
> We have never been very clear about which commands refresh the index.
Yes, git-reset's documentation doesn't mention it.
> Since "reset" is about manipulating the index, I'd expect it to be
> refreshed afterwards. On the other hand, since we have never guaranteed
> anything, perhaps a careful script should always use "git update-index
> --refresh".
Since "git diff-files" is a plumbing command, users of it to a
hopefully a bit more careful than regular users, but you never know.
> I would not be too surprised if some of our own scripts are
> not that careful, though.
I didn't find any, but I might have missed something.
Regardless, this patch was tangential. The goal of this series can be
achieved independently of this patch, so if it's too risky, we can
drop easily drop it.
Also, even though it does make "git reset -q" faster, I'm not sure how
important that is in practice. Most use cases would probably refresh
the index afterwards anyway. In such cases, the improvement on warm
cache would still be there, but the relative improvement in the cold
cache case would be pretty much gone (since the entire tree would be
stat'ed by the following refresh anyway).
Martin
^ permalink raw reply
* t7400 broken on pu (Mac OS X)
From: Torsten Bögershausen @ 2013-01-09 18:43 UTC (permalink / raw)
To: git; +Cc: Torsten Bögershausen
The current pu fails on Mac OS, case insensitive FS.
Bisecting points out
commit 3f28e4fafc046284657945798d71c57608bee479
[snip]
Date: Sun Jan 6 13:21:07 2013 +0700
Convert add_files_to_cache to take struct pathspec
And I veryfied that the preceeding commit 05647d2d8a5dc456d1f4ef73
is OK.
It fails here:
not ok 38 - gracefully add submodule with a trailing slash
A run of a modified t7400 looks like this:
Is there anything more, that I can do to debug this?
[snip]
ok 37 - do not add files from a submodule
expecting success:
git reset --hard &&
echo 1 >&2 &&
git commit -m "commit subproject" init &&
echo 2 >&2 &&
(cd init &&
echo 3 >&2 &&
echo b > a) &&
echo 4 >&2 &&
git add init/ &&
echo 5 >&2 &&
git diff --exit-code --cached init &&
echo 6 >&2 &&
commit=$(cd init &&
echo 7 >&2 &&
git commit -m update a >/dev/null &&
echo 8 >&2 &&
git rev-parse HEAD) &&
echo 9 >&2 &&
git add init/ &&
echo 10 >&2 &&
test_must_fail git diff --exit-code --cached init &&
echo 11 >&2 &&
test $commit = $(git ls-files --stage |
sed -n "s/^160000 \([^ ]*\).*/\1/p")
HEAD is now at 57f2622 super commit 1
1
[second 1b8c63f] commit subproject
Author: A U Thor <author@example.com>
1 file changed, 1 insertion(+), 1 deletion(-)
2
3
4
5
6
7
8
9
10
test_must_fail: command succeeded: git diff --exit-code --cached init
not ok 38 - gracefully add submodule with a trailing slash
^ permalink raw reply
* Re: git branch case insensitivity (Possible bug)
From: Johannes Sixt @ 2013-01-09 18:34 UTC (permalink / raw)
To: Alexander Gallego; +Cc: Andreas Ericsson, git
In-Reply-To: <CAL+iW2-eTtMnn65HN9zeFBFXubgkCA7RwVRZjkq7+tRpPk1TGg@mail.gmail.com>
Am 09.01.2013 18:03, schrieb Alexander Gallego:
> On Wed, Jan 9, 2013 at 10:52 AM, Andreas Ericsson <ae@op5.se> wrote:
>> [about case-insensitivity of HFS+ and branch names]
>> If you said "yes" to all of the above, this is a filesystem "feature",
>> courtesy of (cr)Apple, and you're screwed.
>>
>> You can work around it by running "git pack-refs" every time you create
>> a branch or a tag though.
>
> Thanks for the tips. I'll be sure to use this.
Naah... that's unworkable. I'm sure the Andreas meant the suggestion
tongue-in-cheek. The important part of his reply is "you're screwed".
-- Hannes
^ permalink raw reply
* Re: [PATCH v2 03/10] mailmap: remove email copy and length limitation
From: Junio C Hamano @ 2013-01-09 17:56 UTC (permalink / raw)
To: Antoine Pelisse; +Cc: git
In-Reply-To: <7vfw2a6yh5.fsf@alter.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> Antoine Pelisse <apelisse@gmail.com> writes:
>
>>> +static struct string_list_item *lookup_prefix(struct string_list *map,
>>> + const char *string, size_t len)
>>> +{
>>> + int i = string_list_find_insert_index(map, string, 1);
>>> + if (i < 0) {
>>> + /* exact match */
>>> + i = -1 - i;
>>> + /* does it match exactly? */
>>> + if (!map->items[i].string[len])
>>> + return &map->items[i];
>>
>> I'm not sure the condition above is necessary, as I don't see why an
>> exact match would not be an exact match.
>
> You have a overlong string "ABCDEFG", but you only want to look for
> "ABCDEF", i.e. len=6. The string_list happens to have an existing
> string "ABCDEFG". The insert-index function will report an exact
> match, but that does not mean you found what you are looking for.
To put it another way, we can further clarify the situation by
rewording the comment "Does it match exactly?", perhaps like this
if (i < 0) {
/* exact match */
i = -1 - i;
if (!string[len])
return &map->items[i];
/*
* It matched exactly even to the cruft at the end
* of the string, so it is not really a match.
*/
}
^ permalink raw reply
* Re: git branch case insensitivity (Possible bug)
From: Joshua Jensen @ 2013-01-09 17:47 UTC (permalink / raw)
To: Andreas Ericsson; +Cc: Alexander Gallego, git
In-Reply-To: <50ED925B.2060402@op5.se>
----- Original Message -----
From: Andreas Ericsson
Date: 1/9/2013 8:52 AM
>
> Are you using Mac OSX?
> Are you using the HFS+ filesystem shipped with it?
> Did you use the filesystem's default settings rather than reinstall your
> system with sensible settings?
>
> If you said "yes" to all of the above, this is a filesystem "feature",
> courtesy of (cr)Apple, and you're screwed.
>
> You can work around it by running "git pack-refs" every time you create
> a branch or a tag though.
There are two popular default file systems that are case preserving,
case insensitive. One is on Mac. One is on Windows.
Since Git relies on file system behavior to store the equivalent of
database entries like these refs, it cannot give a consistent user
experience across platforms or even file systems within platforms.
That sounds like a bug in Git to me.
Perhaps pack-refs should be run automatically by any internal command
that updates a ref to ensure a non-confusing, consistent user experience.
Further, if refs are no longer entries on the disk, then this nasty
namespacing issue goes away.
User A:
$ git branch render
$ git push
User B:
$ git pull
$ git branch render/myfeature
render/myfeature can't be created, because Git assumes a filesystem
structure. The render namespace is locked out forever.
-Josh
^ permalink raw reply
* Re: [PATCH v2 03/10] mailmap: remove email copy and length limitation
From: Junio C Hamano @ 2013-01-09 17:46 UTC (permalink / raw)
To: Antoine Pelisse; +Cc: git
In-Reply-To: <CALWbr2wp7rV7Vh0=gwmWaZE5hLHQNL+UciDsL+z-1GyhS9pTkQ@mail.gmail.com>
Antoine Pelisse <apelisse@gmail.com> writes:
>> +static struct string_list_item *lookup_prefix(struct string_list *map,
>> + const char *string, size_t len)
>> +{
>> + int i = string_list_find_insert_index(map, string, 1);
>> + if (i < 0) {
>> + /* exact match */
>> + i = -1 - i;
>> + /* does it match exactly? */
>> + if (!map->items[i].string[len])
>> + return &map->items[i];
>
> I'm not sure the condition above is necessary, as I don't see why an
> exact match would not be an exact match.
You have a overlong string "ABCDEFG", but you only want to look for
"ABCDEF", i.e. len=6. The string_list happens to have an existing
string "ABCDEFG". The insert-index function will report an exact
match, but that does not mean you found what you are looking for.
For the particular case of "looking up e-mail from a string-list
used for the mailmap, using a string that potentially has an extra
'>' at the end", it may not be an issue (i.e. your overlong string
would be "ABCDEF>", and the string-list used for the mailmap will
not have an entry that ends with '>'), but it is likely that people
will try to mimic this function or try to generalize and move it to
strbuf.c and at that point, such a special case condition will no
longer hold and the bug will manifest itself. Being defensive like
the above is a way to avoid that.
^ permalink raw reply
* Re: Enabling scissors by default?
From: Junio C Hamano @ 2013-01-09 17:40 UTC (permalink / raw)
To: Jeff King; +Cc: Phillip Susi, git
In-Reply-To: <20130109171011.GB5332@sigill.intra.peff.net>
Jeff King <peff@peff.net> writes:
> On Tue, Jan 08, 2013 at 03:36:09PM -0800, Junio C Hamano wrote:
>
>> You could introduce a new configuration variable "am.scissors" and
>> personally turn it on, though. Setting that variable *does* count
>> as the user explicitly asking for it.
>
> I think we have mailinfo.scissors already.
Oh, spoiler. I was hoping that I could entice new people into doing
a little digging on their own X-<.
>> > I often see patches being tweaked in response to feedback and
>> > resubmitted, usually with a description of what has changed since the
>> > previous version. Such descriptions don't need to be in the change
>> > log when it is finally applied and seem a perfect use of scissors.
>>
>> Putting such small logs under "---" line is the accepted practice.
>
> Maybe it is just me, but I find the scissors form more readable, because
> the "cover letter" material often serves to introduce and give context
> to the patch (e.g., "Thanks for your feedback. I've tried to do X, and
> it came out well. Here's the patch." serves as an introduction, and
> logically comes before the commit message itself).
>
> That does not say anything one way or another about how dangerous or not
> it might be to enable scissors by default. Just my two cents that I like
> the scissors style for patches that come as part of a discussion (and I
> prefer the "---" style when making comments on the contents of a patch;
> i.e., when the comments make more sense to be read after reading the
> commit message to understand what the patch does).
Yes, scissors have their uses, namely when presenting a patch in a
discussion context. Otherwise we wouldn't have introduced it in the
first place.
But the "desription of what has changed since the previous version"
use case I was responding to is where the space below "---" is meant
to be used from very early days of Git (the convention established
on the kernel list).
^ permalink raw reply
* Re: [PATCH v2 03/10] mailmap: remove email copy and length limitation
From: Antoine Pelisse @ 2013-01-09 17:35 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <1357603821-8647-4-git-send-email-gitster@pobox.com>
> +static struct string_list_item *lookup_prefix(struct string_list *map,
> + const char *string, size_t len)
> +{
> + int i = string_list_find_insert_index(map, string, 1);
> + if (i < 0) {
> + /* exact match */
> + i = -1 - i;
> + /* does it match exactly? */
> + if (!map->items[i].string[len])
> + return &map->items[i];
I'm not sure the condition above is necessary, as I don't see why an
exact match would not be an exact match.
We have to trust the cmp function (that mailmap sets itself) to not
return 0 when the lengths are different.
> + }
> +
> + /*
> + * i is at the exact match to an overlong key, or
> + * location the possibly overlong key would be inserted,
> + * which must be after the real location of the key.
> + */
> + while (0 <= --i && i < map->nr) {
> + int cmp = strncasecmp(map->items[i].string, string, len);
> + if (cmp < 0)
> + /*
> + * "i" points at a key definitely below the prefix;
> + * the map does not have string[0:len] in it.
> + */
> + break;
> + else if (!cmp && !map->items[i].string[len])
> + /* found it */
> + return &map->items[i];
> + /*
> + * otherwise, the string at "i" may be string[0:len]
> + * followed by a string that sorts later than string[len:];
> + * keep trying.
> + */
> + }
> + return NULL;
> +}
> +
I've tried to think about nasty use cases but everything seems fine.
^ permalink raw reply
* Re: Enabling scissors by default?
From: Jeff King @ 2013-01-09 17:10 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Phillip Susi, git
In-Reply-To: <7vr4lvb63a.fsf@alter.siamese.dyndns.org>
On Tue, Jan 08, 2013 at 03:36:09PM -0800, Junio C Hamano wrote:
> You could introduce a new configuration variable "am.scissors" and
> personally turn it on, though. Setting that variable *does* count
> as the user explicitly asking for it.
I think we have mailinfo.scissors already.
> > I often see patches being tweaked in response to feedback and
> > resubmitted, usually with a description of what has changed since the
> > previous version. Such descriptions don't need to be in the change
> > log when it is finally applied and seem a perfect use of scissors.
>
> Putting such small logs under "---" line is the accepted practice.
Maybe it is just me, but I find the scissors form more readable, because
the "cover letter" material often serves to introduce and give context
to the patch (e.g., "Thanks for your feedback. I've tried to do X, and
it came out well. Here's the patch." serves as an introduction, and
logically comes before the commit message itself).
That does not say anything one way or another about how dangerous or not
it might be to enable scissors by default. Just my two cents that I like
the scissors style for patches that come as part of a discussion (and I
prefer the "---" style when making comments on the contents of a patch;
i.e., when the comments make more sense to be read after reading the
commit message to understand what the patch does).
-Peff
^ permalink raw reply
* Re: git branch case insensitivity (Possible bug)
From: Alexander Gallego @ 2013-01-09 17:03 UTC (permalink / raw)
To: Andreas Ericsson; +Cc: git
In-Reply-To: <50ED925B.2060402@op5.se>
On Wed, Jan 9, 2013 at 10:52 AM, Andreas Ericsson <ae@op5.se> wrote:
> On 01/09/2013 04:46 PM, Alexander Gallego wrote:
>> Hello,
>>
>> Here is a pastebin where I've reproduced the steps on a clean git repo.
>>
>> http://pastebin.com/0vQZEat0
>>
>>
>>
>> Brief description of the problem:
>>
>>
>>
>> 1.Basically one creates a local branch call it 'imp_fix' (branch off
>> master --> this doesn't matter)
>> 2.One does work, commit, etc
>> 3.One rebases imp_fix with master via: (inside imp_fix) git rebase master
>> 4.One checks out master via: git checkout master
>> 5.One merges an incorrect name "imp_Fix" (notice the capital F)
>> 6.The expected output is that git would say, silly you --> that branch
>> does not exist.
>> 7. Instead it merges (what I think is incorrectly) imp_fix.
>>
>>
>> Kindly let me know if I can provide more details.
>>
>
> Are you using Mac OSX?
Yes
> Are you using the HFS+ filesystem shipped with it?
Likely. I have not touched the fs settings.
> Did you use the filesystem's default settings rather than reinstall your
> system with sensible settings?
Yup. I use whatever was shipped with it.
> If you said "yes" to all of the above, this is a filesystem "feature",
> courtesy of (cr)Apple, and you're screwed.
>
> You can work around it by running "git pack-refs" every time you create
> a branch or a tag though.
Thanks for the tips. I'll be sure to use this.
> --
> Andreas Ericsson andreas.ericsson@op5.se
> OP5 AB www.op5.se
> Tel: +46 8-230225 Fax: +46 8-230231
>
> Considering the successes of the wars on alcohol, poverty, drugs and
> terror, I think we should give some serious thought to declaring war
> on peace.
^ permalink raw reply
* Re: [PATCH 16/19] reset [--mixed] --quiet: don't refresh index
From: Jeff King @ 2013-01-09 17:01 UTC (permalink / raw)
To: Martin von Zweigbergk; +Cc: git, Junio C Hamano
In-Reply-To: <1357719376-16406-17-git-send-email-martinvonz@gmail.com>
On Wed, Jan 09, 2013 at 12:16:13AM -0800, Martin von Zweigbergk wrote:
> "git reset [--mixed]" without --quiet refreshes the index in order to
> display the "Unstaged changes after reset". When --quiet is given,
> that output is suppressed, removing the need to refresh the index.
> Other porcelain commands that care about a refreshed index should
> already be refreshing it, so running e.g. "git reset -q && git diff"
> is still safe.
Hmm. But "git reset -q && git diff-files" would not be?
We have never been very clear about which commands refresh the index.
Since "reset" is about manipulating the index, I'd expect it to be
refreshed afterwards. On the other hand, since we have never guaranteed
anything, perhaps a careful script should always use "git update-index
--refresh". I would not be too surprised if some of our own scripts are
not that careful, though.
-Peff
^ permalink raw reply
* [PATCH] Makefile: track TCLTK_PATH as it used to be tracked
From: Junio C Hamano @ 2013-01-09 16:55 UTC (permalink / raw)
To: paulus; +Cc: git, Christian Couder
From: Christian Couder <chriscool@tuxfamily.org>
gitk, when bound into the git.git project tree, used to live at the
root level, but in 62ba514 (Move gitk to its own subdirectory,
2007-11-17) it was moved to a subdirectory. The code used to track
changes to TCLTK_PATH (which should cause gitk to be rebuilt to
point at the new interpreter) was left in the main Makefile instead
of being moved to the new Makefile that was created for the gitk
project.
Also add .gitignore file to list build artifacts for the gitk
project.
Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
Paul, this is relative to the tip of your tree, 386befb (gitk:
Display important heads even when there are many, 2013-01-02).
Could you consider applying it?
Also I notice that you have many patches I still do not have
there, and I'd appreciate a "Go ahead and pull from me!".
Thanks.
.gitignore | 2 ++
Makefile | 16 ++++++++++++++--
2 files changed, 16 insertions(+), 2 deletions(-)
create mode 100644 .gitignore
diff --git a/.gitignore b/.gitignore
new file mode 100644
index 0000000..d7ebcaf
--- /dev/null
+++ b/.gitignore
@@ -0,0 +1,2 @@
+/GIT-TCLTK-VARS
+/gitk-wish
diff --git a/Makefile b/Makefile
index e1b6045..5acdc90 100644
--- a/Makefile
+++ b/Makefile
@@ -17,6 +17,16 @@ DESTDIR_SQ = $(subst ','\'',$(DESTDIR))
bindir_SQ = $(subst ','\'',$(bindir))
TCLTK_PATH_SQ = $(subst ','\'',$(TCLTK_PATH))
+### Detect Tck/Tk interpreter path changes
+TRACK_TCLTK = $(subst ','\'',-DTCLTK_PATH='$(TCLTK_PATH_SQ)')
+
+GIT-TCLTK-VARS: FORCE
+ @VARS='$(TRACK_TCLTK)'; \
+ if test x"$$VARS" != x"`cat $@ 2>/dev/null`" ; then \
+ echo 1>&2 " * new Tcl/Tk interpreter location"; \
+ echo "$$VARS" >$@; \
+ fi
+
## po-file creation rules
XGETTEXT ?= xgettext
ifdef NO_MSGFMT
@@ -49,9 +59,9 @@ uninstall::
$(RM) '$(DESTDIR_SQ)$(bindir_SQ)'/gitk
clean::
- $(RM) gitk-wish po/*.msg
+ $(RM) gitk-wish po/*.msg GIT-TCLTK-VARS
-gitk-wish: gitk
+gitk-wish: gitk GIT-TCLTK-VARS
$(QUIET_GEN)$(RM) $@ $@+ && \
sed -e '1,3s|^exec .* "$$0"|exec $(subst |,'\|',$(TCLTK_PATH_SQ)) "$$0"|' <gitk >$@+ && \
chmod +x $@+ && \
@@ -65,3 +75,5 @@ $(ALL_MSGFILES): %.msg : %.po
@echo Generating catalog $@
$(MSGFMT) --statistics --tcl $< -l $(basename $(notdir $<)) -d $(dir $@)
+.PHONY: all install uninstall clean update-po
+.PHONY: FORCE
--
1.8.1.336.g866ceff
^ permalink raw reply related
* Re: Please pull l10n updates
From: Junio C Hamano @ 2013-01-09 16:31 UTC (permalink / raw)
To: Jiang Xin; +Cc: Git List, Ralf Thielow, Christian Stimming, Michael J Gruber
In-Reply-To: <CANYiYbENRCEv93eL5h8AHZtg=gxpGiTLQX2J7R9SdFWdrYFvKA@mail.gmail.com>
Thanks.
^ permalink raw reply
* git interaction between push and auto-gc
From: Bob Lavey @ 2013-01-09 15:56 UTC (permalink / raw)
To: git
Greetings,
We are seeing some unexpected behavior with git that we'd like to better
understand. We are running git 1.7.11.1 on the remote repo server
(CentOS 6.3-x86) and the clients (mostly Windows 7), and we are running
gitolite 3.04 on the server.
At times, our repos can get many unreachable loose objects, and if we
don't clean them up, we will see instances where a push to the remote
repo does not work correctly. This almost always occurs when we try to
delete a remote branch with a "git push origin :branch" call, but this
week we saw two occurrences where a push failed to create a branch (as
well as about a dozen cases where a push failed to delete the branch).
This behavior does not occur for every push, however: I'd guess 10% of
pushes fail.
Here is output from a user's machine:
d:\git\jedi\jedifw>git push origin
configMgrTestBuilder:refs/23s/iq/qbar/user.name@hp.com/jit20073
Counting objects: 59, done.
Delta compression using up to 16 threads.
Compressing objects: 100% (29/29), done.
Writing objects: 100% (30/30), 129.69 KiB, done.
Total 30 (delta 24), reused 1 (delta 0)
Auto packing the repository for optimum performance.
warning: There are too many unreachable loose objects; run 'git prune'
to remove them.
To git@git.boi.hp.com:/jedi/jedifw.git
After a couple of hours, that user was concerned that their branch
hadn't started processing, so they sent an email to support and the
re-pushed. Here are the lines from the gitolite log showing both of
those pushes:
gitolite-2013-01-07.log:2013-01-07.15:57:58 23285 update
jedi/jedifw user.name@hp.com W
refs/23s/iq/qbar/user.name@hp.com/jit20073
0000000000000000000000000000000000000000
2ab0e6626c7a51799179993ea0fdbb829a1ea852
gitolite-2013-01-07.log:2013-01-07.19:57:16 30374 update
jedi/jedifw user.name@hp.com W
refs/23s/iq/qbar/user.name@hp.com/jit20073
0000000000000000000000000000000000000000
2ab0e6626c7a51799179993ea0fdbb829a1ea852
There are no log entries for that branch or that SHA in between those
two lines. My understanding is that both of those lines show a new
branch being created on the remote repo. I'm not sure what happened to
the first push, though: I expected that the branch would have been
created at that time, and subsequent fetches from the remote repo would
show the branch. However, fetches from the remote repo did not show the
branch until after the second push.
We've been running git for about 3 years, and this happened occasionally
when we first started with git, but we always found it was related to a
huge number of unreachable loose objects, which triggered an auto-gc on
the remote repo. When we performed manual gc --aggressive and prune
operations on the remote repo, the problem stopped. It happened this
week because we'd deleted over 4,000 refs/topics branches on
Friday/Saturday, which left a huge number of unreachable loose objects.
Our cleanup script was only pruning objects older than 2.weeks.ago,
and when I pruned objects older than 2.days.ago the problem again stopped.
Is this expected behavior for the interaction between pushes and auto-gc
on the remote repo?
Also, I went through the release notes for the latest versions of git,
and I found this for 1.7.11.6:
* When "git push" triggered the automatic gc on the receiving end, a
message from "git prune" that said it was removing cruft leaked to
the standard output, breaking the communication protocol.
Could that be related to what we're seeing?
Thanks,
Bob Lavey
^ permalink raw reply
* Re: [PATCH] commit: make default of "cleanup" option configurable
From: Junio C Hamano @ 2013-01-09 15:56 UTC (permalink / raw)
To: Ralf Thielow; +Cc: Jonathan Nieder, git
In-Reply-To: <CAN0XMO+t2gu9UKJFVXAxt91-hUUhMqqmMoop88KYp0vo3x6c_g@mail.gmail.com>
Ralf Thielow <ralf.thielow@gmail.com> writes:
> It's actually my own usecase :). The bugtracker I'm using is able
> to create relationships between issues and related commits. It
> expects that a part of the commit message contains the issue number
> in format "#<issueId>". So I need to use a cleanup mode different
> from "default" to keep the commentary.
This is orthogonal to the patch in question, but in your particular
case, I wonder if it is a workable solution to indent #<bugid> in
your message, which won't be stripped away.
I also wonder, as a longer term alternative (which would require a
lot of code auditing and some refactoring), if it is useful to have
an option and/or configuration that lets you configure the "comment
in log message editor" character from the default "#" to something
else. "git -c log.commentchar=% commit" may start the log message
editor with something like this in it:
% Please enter the commit message for your changes. Lines starting
% with '%' will be ignored, and an empty message aborts the commit.
Naturally, setting log.commentchar to "none" would disable stripping
of any commented lines if such a feature existed, and stop issuing
these helpful comments altogether, but still strip excess blank
lines and trailing whitespaces.
I wouldn't seriously suggest it as I am not sure if the usefulness
of such a feature would outweigh the cost of coding it, though; at
least not at this point yet.
^ permalink raw reply
* Re: git branch case insensitivity (Possible bug)
From: Andreas Ericsson @ 2013-01-09 15:52 UTC (permalink / raw)
To: Alexander Gallego; +Cc: git
In-Reply-To: <CAL+iW28LdnNiho4KksLX_S_-+bKX+77GPJ0zqQfkz4JpBJRskw@mail.gmail.com>
On 01/09/2013 04:46 PM, Alexander Gallego wrote:
> Hello,
>
> Here is a pastebin where I've reproduced the steps on a clean git repo.
>
> http://pastebin.com/0vQZEat0
>
>
>
> Brief description of the problem:
>
>
>
> 1.Basically one creates a local branch call it 'imp_fix' (branch off
> master --> this doesn't matter)
> 2.One does work, commit, etc
> 3.One rebases imp_fix with master via: (inside imp_fix) git rebase master
> 4.One checks out master via: git checkout master
> 5.One merges an incorrect name "imp_Fix" (notice the capital F)
> 6.The expected output is that git would say, silly you --> that branch
> does not exist.
> 7. Instead it merges (what I think is incorrectly) imp_fix.
>
>
> Kindly let me know if I can provide more details.
>
Are you using Mac OSX?
Are you using the HFS+ filesystem shipped with it?
Did you use the filesystem's default settings rather than reinstall your
system with sensible settings?
If you said "yes" to all of the above, this is a filesystem "feature",
courtesy of (cr)Apple, and you're screwed.
You can work around it by running "git pack-refs" every time you create
a branch or a tag though.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
Considering the successes of the wars on alcohol, poverty, drugs and
terror, I think we should give some serious thought to declaring war
on peace.
^ permalink raw reply
* git branch case insensitivity (Possible bug)
From: Alexander Gallego @ 2013-01-09 15:46 UTC (permalink / raw)
To: git
Hello,
Here is a pastebin where I've reproduced the steps on a clean git repo.
http://pastebin.com/0vQZEat0
Brief description of the problem:
1.Basically one creates a local branch call it 'imp_fix' (branch off
master --> this doesn't matter)
2.One does work, commit, etc
3.One rebases imp_fix with master via: (inside imp_fix) git rebase master
4.One checks out master via: git checkout master
5.One merges an incorrect name "imp_Fix" (notice the capital F)
6.The expected output is that git would say, silly you --> that branch
does not exist.
7. Instead it merges (what I think is incorrectly) imp_fix.
Kindly let me know if I can provide more details.
For your convenience here is the paste:
agallego@agallego-macpro.local] /tmp
$ git clone git@bitbucket.org/agallego/gitbug
Cloning into 'gitbug'...
warning: You appear to have cloned an empty repository.
[agallego@agallego-macpro.local] /tmp
$ cd gitbug
[agallego@agallego-macpro.local] /tmp/gitbug
$ ls
[agallego@agallego-macpro.local] /tmp/gitbug
$ echo "Trying to reproduce a bug" > README
[agallego@agallego-macpro.local] /tmp/gitbug
$ ls
README
[agallego@agallego-macpro.local] /tmp/gitbug
$ git add .
[agallego@agallego-macpro.local] /tmp/gitbug
$ git commit -am "adding readme"
[master (root-commit) 0bfd62a] adding readme
1 files changed, 1 insertions(+), 0 deletions(-)
create mode 100644 README
[agallego@agallego-macpro.local] /tmp/gitbug
$ git push origin master
Counting objects: 3, done.
Writing objects: 100% (3/3), 230 bytes, done.
Total 3 (delta 0), reused 0 (delta 0)
remote: bb/acl: agallego is allowed. accepted payload.
To git@bitbucket.org:agallego/gitbug
* [new branch] master -> master
[agallego@agallego-macpro.local] /tmp/gitbug
$ git checkout imp_fix
error: pathspec 'imp_fix' did not match any file(s) known to git.
[agallego@agallego-macpro.local] /tmp/gitbug
$ git branch imp_fix
[agallego@agallego-macpro.local] /tmp/gitbug
$ git checkout imp_fix
Switched to branch 'imp_fix'
[agallego@agallego-macpro.local] /tmp/gitbug
$ echo "imp_fix" >> README
[agallego@agallego-macpro.local] /tmp/gitbug
$ git commit -am "step 2, create an imp_fix branch and then merge"
[imp_fix 178c8f3] step 2, create an imp_fix branch and then merge
1 files changed, 1 insertions(+), 0 deletions(-)
[agallego@agallego-macpro.local] /tmp/gitbug
$ ls
README
[agallego@agallego-macpro.local] /tmp/gitbug
$ git rebase master
Current branch imp_fix is up to date.
[agallego@agallego-macpro.local] /tmp/gitbug
$ git checkout master
Switched to branch 'master'
[agallego@agallego-macpro.local] /tmp/gitbug
$ git merge imp_Fix
Merge made by the 'recursive' strategy.
README | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
[agallego@agallego-macpro.local] /tmp/gitbug
$ git push origin master
Counting objects: 6, done.
Delta compression using up to 4 threads.
Compressing objects: 100% (2/2), done.
Writing objects: 100% (4/4), 392 bytes, done.
Total 4 (delta 1), reused 0 (delta 0)
remote: bb/acl: agallego is allowed. accepted payload.
To git@bitbucket.org:agallego/gitbug
0bfd62a..f99f8a1 master -> master
Sincerely,
Alexander Gallego
---*---
------*
* * *
^ permalink raw reply
* Re: [PATCH] commit: make default of "cleanup" option configurable
From: Junio C Hamano @ 2013-01-09 15:40 UTC (permalink / raw)
To: Ralf Thielow; +Cc: Jonathan Nieder, git
In-Reply-To: <CAN0XMO+t2gu9UKJFVXAxt91-hUUhMqqmMoop88KYp0vo3x6c_g@mail.gmail.com>
Ralf Thielow <ralf.thielow@gmail.com> writes:
> When a user uses a script/importer which expects that the "default" option
> is used without setting it explicitly, and then the user changes the default,
> isn't it the users fault if that would break things?
Not necessarily. There are many people who use scripts written by
others, without knowing how they work. You could blame that the
script is broken, but not the poor user of that script.
^ permalink raw reply
* Re: Fwd: git-gui / Warning: "No newline at end of file”
From: Pat Thoyts @ 2013-01-09 14:49 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Tobias Preuss
In-Reply-To: <7vzk0qw8ts.fsf@alter.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
>Tobias Preuss <tobias.preuss@googlemail.com> writes:
>
>> Hello. I never got a response. Did my email pass the distribution
>> list? Best, Tobias
>
>Pat?
>
I did have a brief look at this but I don't have a solution at the
moment. The "\ No newline at end of file" is emitted by git at we don't
appear to handle it well in the lib/diff.tcl apply_range_or_line
function.
>> ---------- Forwarded message ----------
>> From: Tobias Preuss <tobias.preuss@googlemail.com>
>> Date: Tue, Nov 13, 2012 at 9:26 PM
>> Subject: git-gui / Warning: "No newline at end of file”
>> To: git <git@vger.kernel.org>
>>
>>
>> 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
>
--
Pat Thoyts http://www.patthoyts.tk/
PGP fingerprint 2C 6E 98 07 2C 59 C8 97 10 CE 11 E6 04 E0 B9 DD
^ permalink raw reply
* Re: On --depth=funny value
From: Duy Nguyen @ 2013-01-09 14:59 UTC (permalink / raw)
To: Stefan Beller
Cc: Jonathan Nieder, schlotter, Ralf.Wildenhues, git, Junio C Hamano
In-Reply-To: <7vy5g383sy.fsf_-_@alter.siamese.dyndns.org>
On Wed, Jan 9, 2013 at 9:53 AM, Junio C Hamano <gitster@pobox.com> wrote:
> * Make "git fetch" and "git clone" die() when zero or negative
> number is given with --depth=$N, for the following reasons:
> ...
For Stefan when you update the patch. If "git fetch --depth=0" is
considered invalid too as Junio outlined, then the proper place for
the check is transport.c:set_git_option(), not clone.c. It already
catches --depth=random-string. Adding "depth < 1" check should be
trivial. You may want to update builtin/fetch-pack.c too because it
does not share this code.
--
Duy
^ permalink raw reply
* Re: On --depth=funny value
From: Duy Nguyen @ 2013-01-09 14:12 UTC (permalink / raw)
To: Junio C Hamano
Cc: Stefan Beller, Jonathan Nieder, schlotter, Ralf.Wildenhues, git
In-Reply-To: <7vr4lv7x2u.fsf@alter.siamese.dyndns.org>
On Wed, Jan 9, 2013 at 12:19 PM, Junio C Hamano <gitster@pobox.com> wrote:
> Duy Nguyen <pclouds@gmail.com> writes:
>
>> On Wed, Jan 9, 2013 at 9:53 AM, Junio C Hamano <gitster@pobox.com> wrote:
>> ...
>>> * We would like to update "clone --depth=1" to end up with a tip
>>> only repository, but let's not to touch "git fetch" (and "git
>>> clone") and make them send 0 over the wire when the command line
>>> tells them to use "--depth=1" (i.e. let's not do the "off-by-one"
>>> thing).
>>
>> You can't anyway. Depth 0 on the wire is considered invalid by upload-pack.
>
> Yes, that is a good point that we say "if (0 < opt->depth) do the
> shallow thing" everywhere, so 0 is spcial in that sense.
>
> Which suggests that if we wanted to, we could update the fetch side
> to do the off-by-one thing against the current upload-pack when the
> given depth is two or more, and still send 1 when depth=1. When
> talking with an updated upload-pack that advertises exact-shallow
> protocol extension, it can disable that off-by-one for all values of
> depth. That way, the updated client gets history of wrong depth
> only for --depth=1 when talking with the current upload-pack; all
> other cases, it will get history of correct depth.
>
> Hmm?
I haven't checked because frankly I have never run JGit, but are we
sure this off-by-one thing applies to JGit server as well? So far I'm
only aware of three sever implementations: C Git, JGit and Dulwich.
The last one does not support shallow extension so it's out of
question.
--
Duy
^ permalink raw reply
* Failure and unhelpful error message from 'rebase --preserve-merges'
From: Phil Hord @ 2013-01-09 13:19 UTC (permalink / raw)
To: git@vger.kernel.org; +Cc: Neil Horman, Martin von Zweigbergk
In-Reply-To: <50ED63CB.7060108@cisco.com>
Since 90e1818f9a (git-rebase: add keep_empty flag, 2012-04-20)
'git rebase --preserve-merges' fails in a case where it used to
succeed, and it does so with an unhelpful error message.
$ git rebase --preserve-merges master
error: Commit 452524... is a merge but no -m option was given.
fatal: cherry-pick failed
Could not pick 452524f925aecd0439ae5728fca3887292114dd7
I also tried rebase with '-m'
$ git rebase --preserve-merges -m master
but that also failed.
The same commands worked fine for these same commits in v1.7.9
>From 90e1818f9a I figured out that the rebase-interactive
machinery had dropped one of my merges. I normally would not
notice this when using 'git rebase -p' since it does not invoke $EDITOR
by default; but I can see it if I use this:
git -c sequence.editor=cat rebase -p master
With that I see my list of commits, including these:
...
pick 184ec4d WIP: DHCP datastore reporting
# pick 16ca56c Merge ptss into sock-threads
pick 06aea55 WIP: More work normalizing config handlers
...
pick 452524f Merge branch 'ptss' into sock-threads
...
#
# Note that empty commits are commented out
The failure points to the 2nd merge commit, but it is not the merge
commit which was commented out. It is a later merge between the same two
branches. I'm not sure how this is related, yet.
But I now know I can work around the problem with this:
git rebase --keep-empty -p master
I see three problems here, but I don't have any time to go fix them
myself right now.
1. 'rebase -p' should default to --keep-empty since the user will not
be given the opportunity to edit the list to uncomment the missing
commits.
2. 'rebase --interactive -p' should not drop empty merge commits.
3. rebase should not die with a cryptic cherry-pick error message,
although I am not sure what useful thing it could say in this
particular case. Maybe there are other conditions which will cause
this same failure even if 1 and 2 are fixed.
Phil
^ 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