* 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: 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: [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
* [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
* 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
* 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
* 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: [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
* [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
* [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 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
* 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
* 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
* 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: 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: [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: [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: 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: 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: 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: 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: Possible timestamp problems with diff-files?
From: Jeff King @ 2011-09-20 17:54 UTC (permalink / raw)
To: Marc Strapetz; +Cc: git
In-Reply-To: <4E786B5D.40601@syntevo.com>
On Tue, Sep 20, 2011 at 12:30:53PM +0200, Marc Strapetz wrote:
> 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)?
diff-files is scriptable plumbing, which means it is up to the script
writer to decide exactly when the index should be refreshed with respect
to the working tree files (because doing so could be kind of expensive,
as it needs to stat every file in the working tree). Have you tried
running "git update-index --refresh" just before your diff-files?
-Peff
^ permalink raw reply
* Re: git checkout under 1.7.6 does not properly list untracked files and aborts
From: Joshua Jensen @ 2011-09-20 18:26 UTC (permalink / raw)
To: Michael J Gruber; +Cc: git@vger.kernel.org
In-Reply-To: <4E78ACE2.60306@drmicha.warpmail.net>
----- Original Message -----
From: Michael J Gruber
Date: 9/20/2011 9:10 AM
> 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
> ---%<---
>
> Does this test reproduce your problem on msysgit?
As listed, your script produces the same results on msysGit.
It appears the issue is related to sparse checkouts:
---%<---
#!/bin/sh
rm -Rf utest || exit 1
mkdir utest || exit 1
cd utest || exit 1
git init
git config core.sparseCheckout true
echo *>.git/info/sparse-checkout
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
---%<---
-Josh
^ permalink raw reply
* git patch-id fails on long lines
From: Andrew Pimlott @ 2011-09-20 18:07 UTC (permalink / raw)
To: git
In patch-id.c, get_one_patchid uses a fixed 1000-char buffer to read a line.[1]
This causes incorrect results on longer lines. Pasted below is a git commit
(from git show) that demonstrates the problem. The result of running git
patch-id on this commit is:
9220f380851be9cab1a760430e3be096dcbee8c6 9b96b6fde8f7df791a1490ae18e1fa75fbab3262
74b8ede07628a574fd586624e0c77a4b6c9967e0 aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
The commit:
commit 9b96b6fde8f7df791a1490ae18e1fa75fbab3262
Author: Andrew Pimlott <andrew@pimlott.net>
Date: Tue Sep 20 10:53:25 2011 -0700
2
diff --git a/a b/a
index e69de29..2e6adac 100644
--- a/a
+++ b/a
@@ -0,0 +1 @@
+aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
diff --git a/b b/b
index e69de29..1425fcc 100644
--- a/b
+++ b/b
@@ -0,0 +1 @@
+b
Andrew
[1] https://github.com/git/git/blob/master/builtin/patch-id.c
^ permalink raw reply related
* Re: [RFC/PATCHv2] git-web--browse: avoid the use of eval
From: Jeff King @ 2011-09-20 18:49 UTC (permalink / raw)
To: Chris Packham; +Cc: Junio C Hamano, git, chriscool, jepler
In-Reply-To: <4E78572E.6030105@gmail.com>
On Tue, Sep 20, 2011 at 09:04:46PM +1200, Chris Packham wrote:
> > Although other projects do use "cc" in the commit message, I think we
> > don't usually bother adding this noise in the git project. The cc
> > headers in your email are enough.
>
> That's more for git send-email's benefit than anything else. I'm working
> on a laptop with a touchpad (and a cat) so the less switching between
> editor and MUA the better. Any better suggestions for tracking Cc's for
> git send-email?
It would depend on your workflow, I think. You can use --cc to add
headers to format-patch. You could get very fancy and store them in
git-notes or somewhere else, and then pull them in with send-email's
cc-cmd option. But I suspect you just want to stick them in the commit
message one time and then have it used each time.
If put them after the double-dash line in your commit message, like:
subject
body
---
cc: whoever
Then that will be included verbatim in the mail by format-patch,
send-email will respect the cc line, and those lines will be dropped by
"git am" when Junio applies the patch (they are still a slight noise to
readers of the mail, but at least they don't make it into the commit
history).
> The example in t/README has has a copyright notice which is why I put
> one in but I don't consider the test (or the fix itself) to actually be
> copyrightable. If I wasn't creating a new file I wouldn't have bothered
> putting anything in (other than the testcase).
Yeah, that's why I said I don't know if we have a policy. We clearly
have a lot of copyright statements, but they are all horribly out of
date. I was hoping Junio might weigh in.
-Peff
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox