* Re: Git 1.7.6: Sparse checkouts do not work with directory exclusions
From: Joshua Jensen @ 2011-09-20 15:22 UTC (permalink / raw)
To: Nguyen Thai Ngoc Duy; +Cc: git@vger.kernel.org
In-Reply-To: <CACsJy8CDtswtPJVt-T911_1y0WqShonvcCbXhFtWu2zjEqLa4A@mail.gmail.com>
----- Original Message -----
From: Nguyen Thai Ngoc Duy
Date: 9/20/2011 4:09 AM
> On Tue, Sep 20, 2011 at 8:03 AM, Joshua Jensen
> <jjensen@workspacewhiz.com> wrote:
>> Sometime after Git 1.7.3.2, sparse checkouts stopped working for me. My
>> sparse-checkout file looks something like:
>>
>> *
>> !DirA/
>> !DirB/
>> DirC/
> Confirmed. It got me wonder why the negated pattern tests did not
> catch this. Turns out this works:
>
> /*
> !DirA/
> !DirB/
> DirC
>
> This is my theory why yours does not work: negated patterns !DirA and
> !DirB excludes both directories, but git still descends in them
> because you may have other patterns that re-include parts of
> DirA/DirB, for example:
>
> DirA/DirD
> !DirA
>
> When it's in DirA/DirB, "*" tells git to match everything (equivalent
> "DirA/*" and "DirB/*"), so it matches all entries in DirA/DirB again,
> essentially reverting "!DirA" and "!DirB" effects.
>
> By using "/*" instead of "*", we tell git to just match entries at top
> level, not all levels.
>
> I think it makes sense, but it's a bit tricky.
I can confirm this fix works for me, but it is certainly tricky. IMO,
it should either be documented or some kind of fix should be added to a
future version of Git to allow * by itself to work again.
>> and describe why those lines were removed?
> Quotes from 9e08273: "The commit provided a workaround for matching
> directories in index. But it is no longer needed."
Yeah, I saw that, but it made little sense to me, especially since it
seems to break a behavior that worked before.
Thanks!
Josh
^ permalink raw reply
* Re: git checkout under 1.7.6 does not properly list untracked files and aborts
From: Michael J Gruber @ 2011-09-20 15:10 UTC (permalink / raw)
To: Joshua Jensen; +Cc: git@vger.kernel.org
In-Reply-To: <4E779BA4.8070109@workspacewhiz.com>
Joshua Jensen venit, vidit, dixit 19.09.2011 21:44:
> ----- Original Message -----
> From: Joshua Jensen
> Date: 9/9/2011 2:04 PM
>> This may be an msysGit 1.7.6 issue, as that is what I am using. It
>> also occurs in msysGit 1.7.5, but I am almost certain it did not
>> happen in msysGit 1.7.2.
>>
>> Given an untracked file in the working directory that has been added
>> to an alternate branch, when switching to that alternate branch, 'git
>> checkout' exits with an error code but does not print anything to the
>> console. It should print an untracked file error.
>>
>> I have been trying to track this down in code. The point where the
>> error messages are printed, display_error_msgs, is never hit.
> Okay, so I've tracked this down, but I am unsure what the correct fix is.
>
> In unpack-trees.c's unpack_trees() function, there are some lines that read:
>
> if (ce->ce_flags & CE_ADDED &&
> verify_absent(ce, ERROR_WOULD_LOSE_UNTRACKED_OVERWRITTEN, o))
> return -1;
>
> If the 'return -1' is changed to 'goto return_failed', then a proper
> error message appears:
>
> error: The following untracked working tree files would be
> overwritten by checkout:
> one/file/listed/here.txt
> Please move or remove them before you can switch branches.
> Aborting
>
> The thing is, there are multiple files that would be overwritten by
> checkout, and I believe an older version of Git showed me the entire
> list before aborting.
>
> What would be the proper fix here? What am I doing wrong?
Can you provide a simple test case, such as this one:
---%<---
#!/bin/sh
rm -Rf utest || exit 1
mkdir utest || exit 1
cd utest || exit 1
git init
echo tracked >a
git add a
git commit -m a a
git branch side
echo tracked >b
git add b
git commit -m b
cat b
git checkout side
cat b
echo untracked >b
cat b
git checkout master
cat b
---%<---
With 1.7.6 and current next this gives (Linux):
Initialized empty Git repository in /tmp/t/utest/.git/
[master (root-commit) b462c80] a
1 files changed, 1 insertions(+), 0 deletions(-)
create mode 100644 a
[master 22d8f2f] b
1 files changed, 1 insertions(+), 0 deletions(-)
create mode 100644 b
tracked
Switched to branch 'side'
cat: b: No such file or directory
untracked
error: The following untracked working tree files would be overwritten
by checkout:
b
Please move or remove them before you can switch branches.
Aborting
untracked
Does this test reproduce your problem on msysgit?
Michael
^ permalink raw reply
* Re: [ANNOUNCE] Git User's Survey 2011
From: Jakub Narebski @ 2011-09-20 15:04 UTC (permalink / raw)
To: Michael J Gruber; +Cc: git
In-Reply-To: <4E78A667.8050805@drmicha.warpmail.net>
Dnia wtorek 20. września 2011 16:42, Michael J Gruber napisał:
> Jakub Narebski venit, vidit, dixit 19.09.2011 21:10:
> > On Mon, 5 Sep 2011, Michael J Gruber wrote:
> > > I've made a few last minute minor edits on the wiki (language-wise) and
> > > linked to it from identi.ca, twitter and g+. Hope that's alright.
[...]
> > Unfortunately when I had free time and got to correcting the survey,
> > Git Wiki was down already, and it stays unfortunately down till now.
> > When it is up, I'll review your corrections and fix survey
> > appropriately... well, if it will get up before survey closing.
>
> Those were only about the intro paragraph on the wiki, not about the
> content of the survey. Don't worry ;)
You had me worry (especially that I got one minor language-wise fixup,
"commit" -> "a commit")... ;-)
> > > Let the results come in!
> >
> > 3500+ responses and counting...
> >
>
> Yeah!
And that even without GitHub announcing it (yes, I send request, and
resent it yesterday via email rather than GitHub IM system), or
announcement on Git Homepage (Scott is hard to reach...).
> Michael
>
> P.S.: I don't remember what year I filled in my first survey. Can we
> have an answer "3+" next time...
Well, there is "I don't remember, but I have participated in the past"
answer... and you can select it _in addition_ to marking years that
you are sure about.
--
Jakub Narębski
^ permalink raw reply
* Re: maybe I missed the announcement, but...
From: Jakub Narebski @ 2011-09-20 14:55 UTC (permalink / raw)
To: Randal L. Schwartz; +Cc: git
In-Reply-To: <8639frs3bf.fsf@red.stonehenge.com>
merlyn@stonehenge.com (Randal L. Schwartz) writes:
> dhcp:~ +% host git.kernel.org
> Host git.kernel.org not found: 3(NXDOMAIN)
All kernel.org pages are down for maintenance, see
http://kernel.org
> Is there a replacement?
On Gitster's Blog (blog of Junio Hamano) there is "Fun with
url.$that.insteadOf" article showing more or less temporarily
workaround:
http://git-blame.blogspot.com/2011/09/fun-with-urlthatinsteadof.html
HTH
--
Jakub Narębski
^ permalink raw reply
* Re: [ANNOUNCE] Git User's Survey 2011
From: Michael J Gruber @ 2011-09-20 14:42 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <201109192110.30763.jnareb@gmail.com>
Jakub Narebski venit, vidit, dixit 19.09.2011 21:10:
> On Mon, 5 Sep 2011, Michael J Gruber wrote:
>> Jakub Narebski venit, vidit, dixit 05.09.2011 02:43:
>
>>> We would like to ask you a few questions about your use of the Git
>>> version control system. This survey is mainly to understand who is
>>> using Git, how and why.
>>>
>>> The results will be published to the Git wiki on the GitSurvey2011
>>> page (https://git.wiki.kernel.org/index.php/GitSurvey2011) and
>>> discussed on the git mailing list.
>>
>> Jakub, thanks for your work!
>>
>> I've made a few last minute minor edits on the wiki (language-wise) and
>> linked to it from identi.ca, twitter and g+. Hope that's alright.
>
> Thank you for announcing it via microblogging / social network sites.
> I really appreciate spreading the word about Git User's Survey 2011.
>
> Unfortunately when I had free time and got to correcting the survey,
> Git Wiki was down already, and it stays unfortunately down till now.
> When it is up, I'll review your corrections and fix survey
> appropriately... well, if it will get up before survey closing.
Those were only about the intro paragraph on the wiki, not about the
content of the survey. Don't worry ;)
>> Let the results come in!
>
> 3500+ responses and counting...
>
Yeah!
Michael
P.S.: I don't remember what year I filled in my first survey. Can we
have an answer "3+" next time...
^ permalink raw reply
* Re: [PATCH 0/8] fast-import: cache oe more often
From: Jonathan Nieder @ 2011-09-20 14:39 UTC (permalink / raw)
To: Dmitry Ivankov
Cc: Junio C Hamano, git, Shawn O. Pearce, David Barr,
Sverre Rabbelier
In-Reply-To: <CA+gfSn-nh4BhCPf6m8+EN0zo=BuhxRNLcLBx7ynRWPA=GxfDyg@mail.gmail.com>
Dmitry Ivankov wrote:
> The next step would be to replace sha1 with struct object_entry* in fast-import.
> So it'll be in struct tree_entry (twice, for each of versions[2]),
> branch, tag, hash_list (used to store merge from lists), last_object.
> Then some fields will be deleted as they can be accessed from
> object_entry:
> last_object->depth
> last_object->offset
> tree_content->delta_depth
> branch,tag->pack_id
>
> And it all even slightly decreased memory consumption (checked some
> time ago, but think it's still true).
Yes, that sounds interesting, so:
[...]
> In short, if there is nothing bad with this patchset, it'll be
> absolutely natural one after switch to oe instead of sha1, but it's
> put before to split the big series. And of course this part may have a
> small speedup of it's own. If it's not too good to be accepted on it's
> own, I'll just include it into future series depending on it.
It would be indeed be more natural to review a single series that
combines this preparation with the change it prepares for. (And the
change descriptions should explain on their own why they are
individually justified or what project they are contributing towards.)
My question was actually about this last point you made in the
second-to-last sentence: have you measured the speedup produced by the
patches you already sent? I didn't think carefully about it, but my
first thought was that it might slow things down as the internal hash
tables (which still seem to be fixed-size in mainline git) start to
fill up.
^ permalink raw reply
* Re: Git 1.7.6: Sparse checkouts do not work with directory exclusions
From: Michael J Gruber @ 2011-09-20 14:38 UTC (permalink / raw)
To: Joshua Jensen; +Cc: git@vger.kernel.org, Nguyen Thai Ngoc Duy
In-Reply-To: <4E77BC36.7060005@workspacewhiz.com>
Joshua Jensen venit, vidit, dixit 20.09.2011 00:03:
> Sometime after Git 1.7.3.2, sparse checkouts stopped working for me. My
> sparse-checkout file looks something like:
>
> *
> !DirA/
> !DirB/
> DirC/
>
> I have restored some lines of code that were removed in November 2010.
> This resolves the sparse checkout issue for me, but my guess is the
> solution is not implemented properly.
>
> Can anyone confirm the issue and describe why those lines were removed?
>
> Thanks.
>
> Josh
>
> ---
> dir.c | 5 ++++-
> 1 files changed, 4 insertions(+), 1 deletions(-)
>
> diff --git a/dir.c b/dir.c
> index 6e4494e..3f057b6 100644
> --- a/dir.c
> +++ b/dir.c
> @@ -507,7 +507,10 @@ int excluded_from_list(const char *pathname,
> int to_exclude = x->to_exclude;
>
> if (x->flags & EXC_FLAG_MUSTBEDIR) {
> - if (*dtype == DT_UNKNOWN)
> + if (!prefixcmp(pathname, exclude) &&
> + pathname[x->patternlen] == '/')
> + return to_exclude;
> + else if (*dtype == DT_UNKNOWN)
> *dtype = get_dtype(NULL, pathname, pathlen);
> if (*dtype != DT_DIR)
> continue;
That code was in git only between
c84de70 (excluded_1(): support exclude files in index, 2009-08-20)
and
9e08273 (Revert "excluded_1(): support exclude files in index", 2010-11-27)
i.e. after v1.6.4 and before v1.7.3.2
Ccing Duy who will know more.
Michael
^ permalink raw reply
* Re: maybe I missed the announcement, but...
From: Randal L. Schwartz @ 2011-09-20 14:36 UTC (permalink / raw)
To: Carlos Martín Nieto; +Cc: git
In-Reply-To: <1316528864.8701.17.camel@centaur.lab.cmartin.tk>
>>>>> "Carlos" == Carlos Martín Nieto <cmn@elego.de> writes:
Carlos> From Junio's latest "What's cooking"[0]
Ahh, the famous "buried lead". :)
--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<merlyn@stonehenge.com> <URL:http://www.stonehenge.com/merlyn/>
Smalltalk/Perl/Unix consulting, Technical writing, Comedy, etc. etc.
See http://methodsandmessages.posterous.com/ for Smalltalk discussion
^ permalink raw reply
* Re: maybe I missed the announcement, but...
From: Carlos Martín Nieto @ 2011-09-20 14:27 UTC (permalink / raw)
To: Randal L. Schwartz; +Cc: git
In-Reply-To: <8639frs3bf.fsf@red.stonehenge.com>
[-- Attachment #1: Type: text/plain, Size: 705 bytes --]
On Tue, 2011-09-20 at 07:20 -0700, Randal L. Schwartz wrote:
> dhcp:~ +% host git.kernel.org
> Host git.kernel.org not found: 3(NXDOMAIN)
>
> Is there a replacement?
From Junio's latest "What's cooking"[0]
With maint, master, next, pu and todo:
url = git://repo.or.cz/alt-git.git
url = https://code.google.com/p/git-core/
With only maint and master:
url = git://git.sourceforge.jp/gitroot/git-core/git.git
url = git://git-core.git.sourceforge.net/gitroot/git-core/git-core
With all the topics and integration branches:
url = https://github.com/gitster/git
Aren't DVCS wonderful? :)
[0] http://article.gmane.org/gmane.comp.version-control.git/181436
cmn
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 490 bytes --]
^ permalink raw reply
* maybe I missed the announcement, but...
From: Randal L. Schwartz @ 2011-09-20 14:20 UTC (permalink / raw)
To: git
dhcp:~ +% host git.kernel.org
Host git.kernel.org not found: 3(NXDOMAIN)
Is there a replacement?
--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<merlyn@stonehenge.com> <URL:http://www.stonehenge.com/merlyn/>
Smalltalk/Perl/Unix consulting, Technical writing, Comedy, etc. etc.
See http://methodsandmessages.posterous.com/ for Smalltalk discussion
^ permalink raw reply
* [PATCH v3] Documentation/git-update-index: refer to 'ls-files'
From: Stefan Naewe @ 2011-09-20 13:11 UTC (permalink / raw)
To: gitster, git; +Cc: Stefan Naewe
'ls-files' refers to 'update-index' to show how the 'assume unchanged'
bit can be seen. This makes the connection 'bi-directional'.
Signed-off-by: Stefan Naewe <stefan.naewe@gmail.com>
---
The commit message in v2 of this got truncated somehow.
Documentation/git-update-index.txt | 5 ++++-
1 files changed, 4 insertions(+), 1 deletions(-)
diff --git a/Documentation/git-update-index.txt b/Documentation/git-update-index.txt
index d393129..cb1dd7b 100644
--- a/Documentation/git-update-index.txt
+++ b/Documentation/git-update-index.txt
@@ -276,6 +276,8 @@ unchanged". Note that "assume unchanged" bit is *not* set if
the index (use `git update-index --really-refresh` if you want
to mark them as "assume unchanged").
+To see which files have the "assume unchanged" bit set, use
+`git ls-files -v` (see linkgit:git-ls-files[1]).
Examples
--------
@@ -363,7 +365,8 @@ ctime for marking files processed) (see linkgit:git-config[1]).
SEE ALSO
--------
linkgit:git-config[1],
-linkgit:git-add[1]
+linkgit:git-add[1],
+linkgit:git-ls-files[1]
GIT
---
--
1.7.7.rc2
^ permalink raw reply related
* [PATCH v2] Documentation/git-update-index: refer to 'ls-files'
From: Stefan Naewe @ 2011-09-20 12:32 UTC (permalink / raw)
To: git; +Cc: Stefan Naewe
Signed-off-by: Stefan Naewe <stefan.naewe@gmail.com>
---
Documentation/git-update-index.txt | 5 ++++-
1 files changed, 4 insertions(+), 1 deletions(-)
diff --git a/Documentation/git-update-index.txt b/Documentation/git-update-index.txt
index d393129..cb1dd7b 100644
--- a/Documentation/git-update-index.txt
+++ b/Documentation/git-update-index.txt
@@ -276,6 +276,8 @@ unchanged". Note that "assume unchanged" bit is *not* set if
the index (use `git update-index --really-refresh` if you want
to mark them as "assume unchanged").
+To see which files have the "assume unchanged" bit set, use
+`git ls-files -v` (see linkgit:git-ls-files[1]).
Examples
--------
@@ -363,7 +365,8 @@ ctime for marking files processed) (see linkgit:git-config[1]).
SEE ALSO
--------
linkgit:git-config[1],
-linkgit:git-add[1]
+linkgit:git-add[1],
+linkgit:git-ls-files[1]
GIT
---
--
1.7.7.rc2
^ permalink raw reply related
* [PATCH] Documentation/git-update-index: refer to 'ls-files'
From: Stefan Naewe @ 2011-09-20 12:23 UTC (permalink / raw)
To: git; +Cc: Stefan Naewe
'ls-files' refers to 'update-index' to show how the 'assume unchanged'
can be seen. This makes the connection 'bi-directional'.
Signed-off-by: Stefan Naewe <stefan.naewe@gmail.com>
---
Documentation/git-update-index.txt | 5 ++++-
1 files changed, 4 insertions(+), 1 deletions(-)
diff --git a/Documentation/git-update-index.txt b/Documentation/git-update-index.txt
index d393129..169941a 100644
--- a/Documentation/git-update-index.txt
+++ b/Documentation/git-update-index.txt
@@ -276,6 +276,8 @@ unchanged". Note that "assume unchanged" bit is *not* set if
the index (use `git update-index --really-refresh` if you want
to mark them as "assume unchanged").
+To see which files have the "assume unchanged" bit set, use
+`git ls-files -v` (see linkgit:git-update-index[1]).
Examples
--------
@@ -363,7 +365,8 @@ ctime for marking files processed) (see linkgit:git-config[1]).
SEE ALSO
--------
linkgit:git-config[1],
-linkgit:git-add[1]
+linkgit:git-add[1],
+linkgit:git-update-index[1]
GIT
---
--
1.7.7.rc2
^ permalink raw reply related
* Re: [PATCH v2] post-receive-email: explicitly set Content-Type header
From: Jakub Narebski @ 2011-09-20 12:23 UTC (permalink / raw)
To: zapped; +Cc: Johannes Sixt, git
In-Reply-To: <20110920104256.GA11656@zapped.homeip.net>
Shumkin Alexey <zapped@mail.ru> writes:
> [ resent to mailing list ]
> On Tue, Sep 20, 2011 at 11:32:54AM +0200, Johannes Sixt wrote:
> > Am 9/20/2011 10:07, schrieb Alexey Shumkin:
[...]
> > > +# hooks.emailcharset
> > > +# The charset used in Content-Type header. UTF-8, if not
> > > specified.
> >
> > How can you be sure that the output produced by git log etc. that are
> > used in the script are in the encoding specified by this variable?
> > IOW, wouldn't log.outputencoding be the better choice to use in the
> > Content-Type header?
>
> Yes, you're right, we cannot be sure in UTF-8 encoding of output
> and using i18n.logoutputencoding would be a better choice
> instead of new config variable.
>
> But at the present
> 1. post-send-mail uses description file of a repo
> 2. gitweb also uses this file and AFAIK it assumes one to be in UTF-8
> (I do not know whether it can be changed there but I tested gitweb once long
> time ago)
I have thought that gitweb uses '--encoding=utf8' explicitly, but as I
have checked it uses this only for git-format-patch invocation in
'patch' / 'patches' views. Should be fixed.
--
Jakub Narębski
^ permalink raw reply
* Re: How to see 'assume-unchanged' information
From: Stefan Näwe @ 2011-09-20 12:06 UTC (permalink / raw)
To: Nguyen Thai Ngoc Duy; +Cc: git@vger.kernel.org
In-Reply-To: <CACsJy8B1jPmkLB8xq86Ji52G=zGn+3K1_meL5K2T-spDpagL6A@mail.gmail.com>
Am 20.09.2011 14:02, schrieb Nguyen Thai Ngoc Duy:
> On Tue, Sep 20, 2011 at 9:36 PM, Stefan Näwe
> <stefan.naewe@atlas-elektronik.com> wrote:
>> Hi there.
>>
>> Is it somehow possible to see which files have the 'assume unchanged'
>> bit set ?
>
> git ls-files -v
Oh..how obvious...
Someone should update the manpage of 'update-index' to refer to 'ls-files'...
Maybe I find some time for that.
Thx,
Stefan
--
----------------------------------------------------------------
/dev/random says: Send $20 and I will double your IQ or no money back.
python -c "print '73746566616e2e6e616577654061746c61732d656c656b74726f6e696b2e636f6d'.decode('hex')"
^ permalink raw reply
* Re: How to see 'assume-unchanged' information
From: Nguyen Thai Ngoc Duy @ 2011-09-20 12:02 UTC (permalink / raw)
To: Stefan Näwe; +Cc: git@vger.kernel.org
In-Reply-To: <4E787AD3.2000208@atlas-elektronik.com>
On Tue, Sep 20, 2011 at 9:36 PM, Stefan Näwe
<stefan.naewe@atlas-elektronik.com> wrote:
> Hi there.
>
> Is it somehow possible to see which files have the 'assume unchanged'
> bit set ?
git ls-files -v
--
Duy
^ permalink raw reply
* How to see 'assume-unchanged' information
From: Stefan Näwe @ 2011-09-20 11:36 UTC (permalink / raw)
To: git@vger.kernel.org
Hi there.
Is it somehow possible to see which files have the 'assume unchanged'
bit set ?
Thx,
Stefan
--
----------------------------------------------------------------
/dev/random says: To be, or not to be, those are the parameters.
python -c "print '73746566616e2e6e616577654061746c61732d656c656b74726f6e696b2e636f6d'.decode('hex')"
^ permalink raw reply
* [PATCH] contrib/hooks: adapt default Debian install location for contrib hooks
From: Gerrit Pape @ 2011-09-20 11:19 UTC (permalink / raw)
To: git, Junio C Hamano
Placing the contrib hooks into /usr/share/doc/ wasn't a good idea in the
first place. According to the Debian policy they should be located in
/usr/share/git-core/, so let's put them there.
Thanks to Bill Allombert for reporting this through
http://bugs.debian.org/640949
Signed-off-by: Gerrit Pape <pape@smarden.org>
---
contrib/hooks/post-receive-email | 4 ++--
templates/hooks--post-receive.sample | 2 +-
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/contrib/hooks/post-receive-email b/contrib/hooks/post-receive-email
index fa6d41a..ba077c1 100755
--- a/contrib/hooks/post-receive-email
+++ b/contrib/hooks/post-receive-email
@@ -11,11 +11,11 @@
# will have put this somewhere standard. You should make this script
# executable then link to it in the repository you would like to use it in.
# For example, on debian the hook is stored in
-# /usr/share/doc/git-core/contrib/hooks/post-receive-email:
+# /usr/share/git-core/contrib/hooks/post-receive-email:
#
# chmod a+x post-receive-email
# cd /path/to/your/repository.git
-# ln -sf /usr/share/doc/git-core/contrib/hooks/post-receive-email hooks/post-receive
+# ln -sf /usr/share/git-core/contrib/hooks/post-receive-email hooks/post-receive
#
# This hook script assumes it is enabled on the central repository of a
# project, with all users pushing only to it and not between each other. It
diff --git a/templates/hooks--post-receive.sample b/templates/hooks--post-receive.sample
index 7a83e17..e48346e 100755
--- a/templates/hooks--post-receive.sample
+++ b/templates/hooks--post-receive.sample
@@ -12,4 +12,4 @@
# see contrib/hooks/ for a sample, or uncomment the next line and
# rename the file to "post-receive".
-#. /usr/share/doc/git-core/contrib/hooks/post-receive-email
+#. /usr/share/git-core/contrib/hooks/post-receive-email
--
1.7.5.4
^ permalink raw reply related
* Re: [PATCH v2] post-receive-email: explicitly set Content-Type header
From: Johannes Sixt @ 2011-09-20 11:10 UTC (permalink / raw)
To: zapped; +Cc: git, Junio C Hamano
In-Reply-To: <20110920104256.GA11656@zapped.homeip.net>
Am 9/20/2011 12:42, schrieb Shumkin Alexey:
> On Tue, Sep 20, 2011 at 11:32:54AM +0200, Johannes Sixt wrote:
>> Am 9/20/2011 10:07, schrieb Alexey Shumkin:
>>> +# hooks.emailcharset
>>> +# The charset used in Content-Type header. UTF-8, if not
>>> specified.
>>
>> How can you be sure that the output produced by git log etc. that are
>> used in the script are in the encoding specified by this variable?
>> IOW, wouldn't log.outputencoding be the better choice to use in the
>> Content-Type header?
> Yes, you're right, we cannot be sure in UTF-8 encoding of output
> and using i18n.logoutputencoding would be a better choice
> instead of new config variable.
>
> But at the present
> 1. post-send-mail uses description file of a repo
> 2. gitweb also uses this file and AFAIK it assumes one to be in UTF-8
> (I do not know whether it can be changed there but I tested gitweb once long
> time ago)
> 3. So if i18n.logoutputencoding is not UTF-8 we get a message composed
> with mixed encodings. This fact oblidge us to encode headers
> (as quoted printable at least) and synchronize body message that contain
> repo description (in UTF-8) and diffstat (in i18n.logoutputencoding).
> This is a more complicated task for a shell script
> than just specifying Content-Type header (may be git-send-email suits here?)
In this case, it may make sense to have a separate setting, but you should
call git like this:
git -c "i18n.logoutputencoding=$emailcharset" show ...
git -c "i18n.logoutputencoding=$emailcharset" rev-list --pretty ...
-- Hannes
^ permalink raw reply
* Re: Worktree vs. working copy
From: Ramkumar Ramachandra @ 2011-09-20 10:56 UTC (permalink / raw)
To: Carlos Martín Nieto
Cc: git, Nguyễn Thái Ngọc Duy, Michael Haggerty
In-Reply-To: <1316505022.13996.12.camel@bee.lab.cmartin.tk>
Hi Carlos,
Carlos Martín Nieto writes:
> [...]
> $ git grep 'worktree' | wc -l
> 412
> $ git grep 'working copy' | grep -v ^git-cvsserver | wc -l
> 32
> [...]
You might like to refer to a related discussion [1].
[1]: http://thread.gmane.org/gmane.comp.version-control.git/159287/focus=160083
-- Ram
^ permalink raw reply
* Re: Worktree vs. working copy
From: Nguyen Thai Ngoc Duy @ 2011-09-20 10:48 UTC (permalink / raw)
To: Michael Haggerty; +Cc: Carlos Martín Nieto, git
In-Reply-To: <4E786D7A.8020503@alum.mit.edu>
On Tue, Sep 20, 2011 at 8:39 PM, Michael Haggerty <mhagger@alum.mit.edu> wrote:
> On 09/20/2011 09:50 AM, Carlos Martín Nieto wrote:
>> I've noticed that in some places in git.git, the term 'working copy' is
>> used. Mostly it's in git-cvsserver which I guess it's fine, but the
>> git-config man page talks about the 'working copy' in three places.
>>
>> $ git grep 'worktree' | wc -l
>> 412
>> $ git grep 'working copy' | grep -v ^git-cvsserver | wc -l
>> 32
>
> Please note that the string "worktree" mostly appears in code
> (presumably as variable names) and in the names of options. In text,
> "working tree" is far more common..
And probably the oldest. It was mentioned in the first version of git
glossary back in 2005, da13981, [PATCH] Add GIT glossary.
--
Duy
^ permalink raw reply
* Re: [PATCH v2] post-receive-email: explicitly set Content-Type header
From: Shumkin Alexey @ 2011-09-20 10:42 UTC (permalink / raw)
To: Johannes Sixt; +Cc: git
In-Reply-To: <4E785DC6.80105@viscovery.net>
[ resent to mailing list ]
On Tue, Sep 20, 2011 at 11:32:54AM +0200, Johannes Sixt wrote:
> Am 9/20/2011 10:07, schrieb Alexey Shumkin:
> > Some email clients (e.g. claws-mail) incorrectly display
> > message body when there is no Content-Type header and charset
> > explicitly defined.
> > So, set explicitly Content-Type header and charset
> > can be defined with hooks.emailcharset config variable.
>
> Please write full sentences with complete punctuation and capitalization.
> Perhaps you meant to say:
>
> Some email clients (e.g. claws-mail) display the message body
> incorrectly when the charset is not defined explicitly in a
> Content-Type header. Insert a Content-Type header in the message.
>
> The charset can be defined with the config variable
> hooks.emailcharset.
Thanks for the correction. English is not my native language
(although it is not for you, too, I guess :) ).
I read it and take on ear fine but I have no enough practice to write on it.
> > +# hooks.emailcharset
> > +# The charset used in Content-Type header. UTF-8, if not
> > specified.
>
> How can you be sure that the output produced by git log etc. that are
> used in the script are in the encoding specified by this variable?
> IOW, wouldn't log.outputencoding be the better choice to use in the
> Content-Type header?
Yes, you're right, we cannot be sure in UTF-8 encoding of output
and using i18n.logoutputencoding would be a better choice
instead of new config variable.
But at the present
1. post-send-mail uses description file of a repo
2. gitweb also uses this file and AFAIK it assumes one to be in UTF-8
(I do not know whether it can be changed there but I tested gitweb once long
time ago)
3. So if i18n.logoutputencoding is not UTF-8 we get a message composed
with mixed encodings. This fact oblidge us to encode headers
(as quoted printable at least) and synchronize body message that contain
repo description (in UTF-8) and diffstat (in i18n.logoutputencoding).
This is a more complicated task for a shell script
than just specifying Content-Type header (may be git-send-email suits here?)
So that was a quick solution for me :)
^ permalink raw reply
* Re: Worktree vs. working copy
From: Michael Haggerty @ 2011-09-20 10:39 UTC (permalink / raw)
To: Carlos Martín Nieto; +Cc: git
In-Reply-To: <1316505022.13996.12.camel@bee.lab.cmartin.tk>
On 09/20/2011 09:50 AM, Carlos Martín Nieto wrote:
> I've noticed that in some places in git.git, the term 'working copy' is
> used. Mostly it's in git-cvsserver which I guess it's fine, but the
> git-config man page talks about the 'working copy' in three places.
>
> $ git grep 'worktree' | wc -l
> 412
> $ git grep 'working copy' | grep -v ^git-cvsserver | wc -l
> 32
Please note that the string "worktree" mostly appears in code
(presumably as variable names) and in the names of options. In text,
"working tree" is far more common than either:
$ git grep -i 'worktree' -- '*.txt' | wc -l
50
$ git grep -i 'working copy' -- '*.txt' | wc -l
6
$ git grep -i 'working tree' -- '*.txt' | wc -l
330
Michael
--
Michael Haggerty
mhagger@alum.mit.edu
http://softwareswirl.blogspot.com/
^ permalink raw reply
* Possible timestamp problems with diff-files?
From: Marc Strapetz @ 2011-09-20 10:30 UTC (permalink / raw)
To: git
For our Git client, we are invoking
git diff-files--quiet --ignore-submodules
immediately after a commit of *all* changes. Hence, the expected exit
code would be 0 (because there are no changes). A user has now reported
that for commits with many changes, exit code is sometimes 1. For the
last incident, the commit was started at 15:24:11,820 and finished at
15:24:12,329, diff-files was invoked at 15:24:12,455 and failed with
exit code 1 at 15:24:21,394. A subsequent diff-files succeeded, so I'm
wondering now, if that could be a timestamp problem (maybe related to
the Index)?
Note that there are a couple of threads running in the client itself, so
I guess actual running time of diff-files was much shorter than 9
seconds and chances are that some parts of diff-files were run in the
same second 15:24:12.
System configuration is:
Linux splitter 2.6.38-11-server #48-Ubuntu SMP Fri Jul 29 19:20:32 UTC
2011 x86_64 x86_64 x86_64 GNU/Linux
git version 1.7.4.1
--
Best regards,
Marc Strapetz
=============
syntevo GmbH
http://www.syntevo.com
http://blog.syntevo.com
^ permalink raw reply
* Re: [PATCH] Prevent users from adding the file that has all-zero SHA-1
From: Nguyen Thai Ngoc Duy @ 2011-09-20 10:13 UTC (permalink / raw)
To: Ramkumar Ramachandra; +Cc: git
In-Reply-To: <CALkWK0n9kJtUPrpxTmtfH7kVd7CksULjt7bo3cFhOrS_NBVbMw@mail.gmail.com>
2011/9/20 Ramkumar Ramachandra <artagnon@gmail.com>:
> Hi Nguyễn,
>
> Nguyễn Thái Ngọc Duy writes:
>> This particular SHA-1 has special meaning to git, very much like NULL
>> in C. If a user adds a file that has this SHA-1, unexpected things can
>> happen.
>> [...]
>
> Interesting patch. Is it possible to write some sort of testcase?
Naah. I tested it by explicitly clear the result hash, just before it
gets to my changes, then do "git add <blah>".
--
Duy
^ 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