* Re: [PATCH 0/3] read-tree cleanups
From: Junio C Hamano @ 2011-09-21 12:14 UTC (permalink / raw)
To: Michael J Gruber; +Cc: git
In-Reply-To: <4E799799.8060106@drmicha.warpmail.net>
Michael J Gruber <git@drmicha.warpmail.net> writes:
> Uhm, I forgot about the dont-cc-jc-in-rc policy, sorry. This is not a
> late-minute regression fix and can wait.
Thanks but that is not a policy; merely my preference. It also is a bit
unnecessarily stronger than my actual preferences, which is
(1) I do not want to see a patch sent "To:" me as the maintainer the
first round of a new, undiscussed patch, as if it is ready for
inclusion, at any time, not just during rc.
(2) I do appreciate a patch sent "Cc:" me as a member of the development
community patches for discussion, especially to areas in which I am
an area expert, at any time, including during rc.
^ permalink raw reply
* Re: Worktree vs. working copy
From: Junio C Hamano @ 2011-09-20 21:45 UTC (permalink / raw)
To: Carlos Martín Nieto
Cc: Ramkumar Ramachandra, git, Nguyễn Thái Ngọc Duy,
Michael Haggerty
In-Reply-To: <1316550362.8701.32.camel@centaur.lab.cmartin.tk>
Carlos Martín Nieto <cmn@elego.de> writes:
> Subject: [PATCH] Remove 'working copy' from the documentation and C code
>
> The git term is 'working tree', so replace the most public references
> to 'working copy'.
>
> Signed-off-by: Carlos Martín Nieto <cmn@elego.de>
Thanks.
"working tree" is a term used to collectively call the whole, and I think
all the places in your patch read better with "working tree".
People with background from other systems refer to one particular file in
the working tree as "working copy", I think, but...
> core.fileMode::
> If false, the executable bit differences between the index and
> - the working copy are ignored; useful on broken filesystems like FAT.
> + the working tree are ignored; useful on broken filesystems like FAT.
... this compares "the index and the working tree", meaning each path in
the index and the corresponding file in the working tree (both are taken
as a _collection_), so this rewrite makes perfect sense. The same for
the description for trustctime.
> @@ -292,7 +292,7 @@ core.ignoreStat::
> If true, commands which modify both the working tree and the index
> will mark the updated paths with the "assume unchanged" bit in the
> index. These marked files are then assumed to stay unchanged in the
> - working copy, until you mark them otherwise manually - Git will not
> + working tree, until you mark them otherwise manually - Git will not
This again is "paths in the" working tree, and the term is used as a
collection (good). The same for "git-svn" manpage.
> diff --git a/diff-lib.c b/diff-lib.c
> index 9c29293..c7d33d7 100644
> --- a/diff-lib.c
> +++ b/diff-lib.c
> @@ -289,7 +289,7 @@ static void show_new_file(struct rev_info *revs,
>
> /*
> * New file in the index: it might actually be different in
> - * the working copy.
> + * the working tree.
> */
We are looking at one path, and wondering if it is different "in the"
working tree---again used as a collection (it would have said "it might
actually be different from the working copy" if it referred to an instance
in the collection). The same for the comment in merge-recursive.c.
^ permalink raw reply
* Re: [PATCH di/fast-import-deltified-tree] Windows: define S_ISUID properly
From: Junio C Hamano @ 2011-09-21 12:08 UTC (permalink / raw)
To: Dmitry Ivankov; +Cc: git, Johannes Sixt
In-Reply-To: <loom.20110921T092135-714@post.gmane.org>
Dmitry Ivankov <divanorama@gmail.com> writes:
> Johannes Sixt <j.sixt <at> viscovery.net> writes:
>>
>> From: Johannes Sixt <j6t <at> kdbg.org>
>>
>> 8fb3ad76 (fast-import: prevent producing bad delta) introduced the first
>> use of S_ISUID. Since before this commit the value was irrelevant, we had
>> only a dummy definition in mingw.h. But beginning with this commit the
>> macro must expand to a reasonable value. Make it so.
>> #define S_ISVTX 0
>> ...
> Ow, it's awkward that the issue was discussed in [1] but slipped and nobody
> noticed, especially me being a patch sender.
>
> If we choose patch from [1] I'd also change a comment to smth like
> /*
> * We abuse the 04000 bit on directories to mean "do not delta".
> * It is a S_ISUID bit on setuid platforms and an unused bit on
> * non-setuid platforms supported in git. In either case git ignores
> * the bit, so it's safe to abuse it locally.
> */
>
> [1] http://thread.gmane.org/gmane.comp.version-control.git/179223/focus=179762
I think that the fix from Jonathan to stop abusing S_ISUID is much more
preferrable; the Windows platform shouldn't have to worry about this.
And it would be even better to use a value that does not overlap with the
usual bits for do-not-delta bit if possible.
^ permalink raw reply
* Re: Bug: git log --numstat counts wrong
From: Junio C Hamano @ 2011-09-21 12:24 UTC (permalink / raw)
To: Alexander Pepper; +Cc: git
In-Reply-To: <D3CF0A47-64DA-4EBB-9DCD-D2D714596C50@inf.fu-berlin.de>
Alexander Pepper <pepper@inf.fu-berlin.de> writes:
> $ git log --numstat 48a07e7e533f507228e8d1c99d4d48e175e14260
> [...]
> 11 10 src/java/voldemort/server/storage/StorageService.java
Didn't we update it this already? I seem to get 10/9 here not 11/10.
^ permalink raw reply
* Re: [PATCH di/fast-import-deltified-tree] Windows: define S_ISUID properly
From: Junio C Hamano @ 2011-09-21 12:07 UTC (permalink / raw)
To: Dmitry Ivankov; +Cc: git, Johannes Sixt
In-Reply-To: <loom.20110921T092135-714@post.gmane.org>
Dmitry Ivankov <divanorama@gmail.com> writes:
> Johannes Sixt <j.sixt <at> viscovery.net> writes:
>>
>> From: Johannes Sixt <j6t <at> kdbg.org>
>>
>> 8fb3ad76 (fast-import: prevent producing bad delta) introduced the first
>> use of S_ISUID. Since before this commit the value was irrelevant, we had
>> only a dummy definition in mingw.h. But beginning with this commit the
>> macro must expand to a reasonable value. Make it so.
>> #define S_ISVTX 0
>> ...
> Ow, it's awkward that the issue was discussed in [1] but slipped and nobody
> noticed, especially me being a patch sender.
>
> If we choose patch from [1] I'd also change a comment to smth like
> /*
> * We abuse the 04000 bit on directories to mean "do not delta".
> * It is a S_ISUID bit on setuid platforms and an unused bit on
> * non-setuid platforms supported in git. In either case git ignores
> * the bit, so it's safe to abuse it locally.
> */
>
> [1] http://thread.gmane.org/gmane.comp.version-control.git/179223/focus=179762
I think that the fix from Jonathan to stop abusing S_ISUID is much more
preferrable; the Windows platform shouldn't have to worry about this.
And it would be even better to use a value that does not overlap with the
usual bits for do-not-delta bit if possible.
^ permalink raw reply
* Re: git checkout under 1.7.6 does not properly list untracked files and aborts
From: Nguyen Thai Ngoc Duy @ 2011-09-21 10:31 UTC (permalink / raw)
To: Michael J Gruber; +Cc: Joshua Jensen, git@vger.kernel.org
In-Reply-To: <20110921102834.GA21353@duynguyen-vnpc>
On Wed, Sep 21, 2011 at 8:28 PM, Nguyen Thai Ngoc Duy <pclouds@gmail.com> wrote:
> I was afraid some logic had gone horribly wrong. Turns out I did not
> catch up with unpack_trees() coding style and drop the error messages
> so "git checkout" in this case becomes "git checkout -q".
Gaah.. if I did read Joshua's problem description, it would not need
to worry about the logic. He said it returned error code correctly.
Silly me.
--
Duy
^ permalink raw reply
* Re: git checkout under 1.7.6 does not properly list untracked files and aborts
From: Nguyen Thai Ngoc Duy @ 2011-09-21 10:28 UTC (permalink / raw)
To: Michael J Gruber; +Cc: Joshua Jensen, git@vger.kernel.org
In-Reply-To: <4E79AB5F.5020809@drmicha.warpmail.net>
On Wed, Sep 21, 2011 at 11:16:15AM +0200, Michael J Gruber wrote:
> Thanks. I can confirm that with the above patch, the code compiles and
> fails my test. So it's the earlier of the two commits which introduces this.
I was afraid some logic had gone horribly wrong. Turns out I did not
catch up with unpack_trees() coding style and drop the error messages
so "git checkout" in this case becomes "git checkout -q".
This patch should fix it. Need another look before I submit a real
patch though.
diff --git a/unpack-trees.c b/unpack-trees.c
index cc616c3..79e9e88 100644
--- a/unpack-trees.c
+++ b/unpack-trees.c
@@ -1102,12 +1102,10 @@ int unpack_trees(unsigned len, struct tree_desc *t, struct unpack_trees_options
*/
if (ce->ce_flags & CE_ADDED &&
verify_absent(ce, ERROR_WOULD_LOSE_UNTRACKED_OVERWRITTEN, o))
- return -1;
+ goto return_failed;
- if (apply_sparse_checkout(ce, o)) {
- ret = -1;
- goto done;
- }
+ if (apply_sparse_checkout(ce, o))
+ goto return_failed;
if (!ce_skip_worktree(ce))
empty_worktree = 0;
^ permalink raw reply related
* Re: mac osx
From: Sverre Rabbelier @ 2011-09-21 9:44 UTC (permalink / raw)
To: tom smitts
In-Reply-To: <loom.20110921T002437-246@post.gmane.org>
Heya,
[bcc: git list, let's take this off-list, but I do want the record to
show that I do not think this is the way we should communicate on this
list]
On Wed, Sep 21, 2011 at 00:40, tom smitts <tomsmitts@ymail.com> wrote:
> Do the git maintainers really think any mac users have
> a clue which git install package to download? You
> put some arcane chipset designation in the package
> name! Why make mac installers at all? Mac users
> know their operating system number, e.g. 10.6.7,
> and that's all. I doubt Windows users know any better.
> And I doubt you can find anywhere on a mac that says
> i386 or whatever the heck the other dumb
> designation is.
What value does writing your email in this way add? Wouldn't it be
much more productive if instead you had written something like this:
> Hi, I noticed that the mac installers (found here [0]) include a
> chipset designation (such as i386 or x86_64). In my experience,
> Mac users (as well as Windows users) are not familiar with these
> terms, and will not know which to choose. It would perhaps be
> better to rename the package to have a 32bit or 64bit suffix instead,
> which these users are more likely to know.
> If this is the wrong place to report this issue, please feel free to
> forward this to the appropriate person.
>
> Thanks
>
> http://code.google.com/p/git-osx-installer/downloads/list
As you can see it's about as long as your reply, but a lot less
aggressive. It conveys the same information (the current package
naming is sub-optimal), but does so in a much friendlier way.
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* Re: [PATCH 3/3] git-read-tree.txt: correct sparse-checkout and skip-worktree description
From: Nguyen Thai Ngoc Duy @ 2011-09-21 9:39 UTC (permalink / raw)
To: Michael J Gruber; +Cc: git, Joshua Jensen, Junio C Hamano
In-Reply-To: <4E79AF57.3010300@drmicha.warpmail.net>
On Wed, Sep 21, 2011 at 7:33 PM, Michael J Gruber
<git@drmicha.warpmail.net> wrote:
>>> In hindsight, it would have been much better to have a "sparse-ignore"
>>> or "sparse-skip" file so that an empty file would mean a full checkout,
>>> and the file logic would be analogous to that of .gitignore, excludes
>>> and skip-worktree.
>>
>> .gitignore works towards excluding files. No rule means no excluding.
>> sparse-checkout file works towards including files, no rule means no
>> inclusion.
>
> Sure, but with a "sparse-skip" rather than "sparse-checkout", we would
> not even need an additional config variable, and the skip-worktree
> centered explanations would follow the same logic (no need for the
> additional negation) as the ignore files and the new sparse-skip file.
I'll kill that config variable some day when sparse checkout code has
no overhead over normal case ("include all").
--
Duy
^ permalink raw reply
* Re: mac osx
From: Sverre Rabbelier @ 2011-09-21 9:34 UTC (permalink / raw)
To: Kyle Neath, Tim Harper; +Cc: tom smitts, git
In-Reply-To: <CAFcyEtiexmE0WMif-eGHe5xMoYv7-8mdXos1qbQBH3g04z0sAg@mail.gmail.com>
Heya,
[+timcharper, owner of the git-osx-installer project]
On Wed, Sep 21, 2011 at 05:40, Kyle Neath <kneath@gmail.com> wrote:
> On Tue, Sep 20, 2011 at 3:40 PM, tom smitts <tomsmitts@ymail.com> wrote:
>> Do the git maintainers really think any mac users have
>> a clue which git install package to download? You
>> put some arcane chipset designation in the package
>> name! Why make mac installers at all? Mac users
>> know their operating system number, e.g. 10.6.7,
>> and that's all. I doubt Windows users know any better.
>> And I doubt you can find anywhere on a mac that says
>> i386 or whatever the heck the other dumb
>> designation is.
>
> Yikes! That's definitely not good. I'll see what we can do about updating
> git-scm.com to point to a more reasonable installer for OSX. I haven't clicked
> that link in a long time and had no idea it was so confusing.
>
> I've created an issue so we can track it, if you'd like to follow along:
> https://github.com/schacon/gitscm/issues/16
>
> Kyle Neath
> Director of Design, GitHub
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* Re: [PATCH 3/3] git-read-tree.txt: correct sparse-checkout and skip-worktree description
From: Michael J Gruber @ 2011-09-21 9:33 UTC (permalink / raw)
To: Nguyen Thai Ngoc Duy; +Cc: git, Joshua Jensen, Junio C Hamano
In-Reply-To: <CACsJy8BrBsBM-DwC_CkYrrpFU6aTqpcohWDPxTnRhMEX+w3Nug@mail.gmail.com>
Nguyen Thai Ngoc Duy venit, vidit, dixit 21.09.2011 11:26:
> On Wed, Sep 21, 2011 at 5:48 PM, Michael J Gruber
> <git@drmicha.warpmail.net> wrote:
>> The description of .git/info/sparse-checkout and
>> skip-worktree is exactly the opposite of what is true, which is:
>>
>> If a file matches a pattern in sparse-checkout, then (it is to be
>> checked out and therefore) skip-worktree is unset for that file;
>> otherwise, it is set (so that it is not checked out).
>>
>> Currently, the opposite is documented, and (consistently) read-tree's
>> behavior with respect to bit flips is descibed incorrectly.
>>
>> Fix it.
>
> Ack.
>
>> In hindsight, it would have been much better to have a "sparse-ignore"
>> or "sparse-skip" file so that an empty file would mean a full checkout,
>> and the file logic would be analogous to that of .gitignore, excludes
>> and skip-worktree.
>
> .gitignore works towards excluding files. No rule means no excluding.
> sparse-checkout file works towards including files, no rule means no
> inclusion.
Sure, but with a "sparse-skip" rather than "sparse-checkout", we would
not even need an additional config variable, and the skip-worktree
centered explanations would follow the same logic (no need for the
additional negation) as the ignore files and the new sparse-skip file.
Also, I'm not sure whether more sparse users say "I want only that
subdir." than "I don't want that subdir."
But it's there to stay, of course.
Cheers,
Michael
^ permalink raw reply
* Re: [PATCH 3/3] git-read-tree.txt: correct sparse-checkout and skip-worktree description
From: Nguyen Thai Ngoc Duy @ 2011-09-21 9:26 UTC (permalink / raw)
To: Michael J Gruber; +Cc: git, Joshua Jensen, Junio C Hamano
In-Reply-To: <31152a2ddb83e37be1efce1d0cd742b71ea3efdd.1316590874.git.git@drmicha.warpmail.net>
On Wed, Sep 21, 2011 at 5:48 PM, Michael J Gruber
<git@drmicha.warpmail.net> wrote:
> The description of .git/info/sparse-checkout and
> skip-worktree is exactly the opposite of what is true, which is:
>
> If a file matches a pattern in sparse-checkout, then (it is to be
> checked out and therefore) skip-worktree is unset for that file;
> otherwise, it is set (so that it is not checked out).
>
> Currently, the opposite is documented, and (consistently) read-tree's
> behavior with respect to bit flips is descibed incorrectly.
>
> Fix it.
Ack.
> In hindsight, it would have been much better to have a "sparse-ignore"
> or "sparse-skip" file so that an empty file would mean a full checkout,
> and the file logic would be analogous to that of .gitignore, excludes
> and skip-worktree.
.gitignore works towards excluding files. No rule means no excluding.
sparse-checkout file works towards including files, no rule means no
inclusion.
--
Duy
^ permalink raw reply
* Bug: git log --numstat counts wrong
From: Alexander Pepper @ 2011-09-21 9:03 UTC (permalink / raw)
To: git
Hello there.
I already reported some similar bug with git log --numstat to this mailinglist (see http://www.spinics.net/lists/git/msg163358.html ). Back then empty lines seems to be the issue, but the bug was never fixed.
I found another case, where git log --numstat counts wrong. This time git log --numstat yields bigger numbers than diffstat.
Minimal example:
$ git clone https://github.com/voldemort/voldemort.git
$ cd voldemort/
$ git show 48a07e7e533f507228e8d1c99d4d48e175e14260 -- src/java/voldemort/server/storage/StorageService.java | diffstat
StorageService.java | 19 ++++++++++---------
1 file changed, 10 insertions(+), 9 deletions(-)
$ git log --numstat 48a07e7e533f507228e8d1c99d4d48e175e14260
[...]
11 10 src/java/voldemort/server/storage/StorageService.java
So git log --numstat claimes that 11 lines where added, where diffstat only counts 10! A closer look inside the StorageService.java reveals no empty lines.
My system:
* Mac osx 10.6.8
* git 1.7.5.4 (but also check with a self compiled 1.7.6.1)
Can you confirm that this is a bug? If so, are there plans to fix it in the future?
Greetings from Berlin
Alex
^ permalink raw reply
* Re: git checkout under 1.7.6 does not properly list untracked files and aborts
From: Michael J Gruber @ 2011-09-21 9:16 UTC (permalink / raw)
To: Nguyen Thai Ngoc Duy; +Cc: Joshua Jensen, git@vger.kernel.org
In-Reply-To: <20110921085842.GA29768@duynguyen-vnpc>
Nguyen Thai Ngoc Duy venit, vidit, dixit 21.09.2011 10:58:
> On Wed, Sep 21, 2011 at 10:28:59AM +0200, Michael J Gruber wrote:
>> So, I bisected it. The first bad commit is
>>
>> 9037026 (unpack-trees: fix sparse checkout's "unable to match
>> directories", 2010-11-27)
>>
>> although the real culprit may be its predecessor
>>
>> 2431afb (unpack-trees: move all skip-worktree checks back to
>> unpack_trees(), 2010-11-27)
>>
>> which does not compile:
>>
>> CC unpack-trees.o
>> unpack-trees.c: In function 'mark_new_skip_worktree':
>> unpack-trees.c:852:75: error: 'o' undeclared (first use in this function)
>> unpack-trees.c:852:75: note: each undeclared identifier is reported only
>> once for each function it appears in
>> make: *** [unpack-trees.o] Error 1
>
> This may help
>
> --8<--
> diff --git a/unpack-trees.c b/unpack-trees.c
> index a6518db..a239af7 100644
> --- a/unpack-trees.c
> +++ b/unpack-trees.c
> @@ -245,13 +245,13 @@ static int check_updates(struct unpack_trees_options *o)
> static int verify_uptodate_sparse(struct cache_entry *ce, struct unpack_trees_options *o);
> static int verify_absent_sparse(struct cache_entry *ce, enum unpack_trees_error_types, struct unpack_trees_options *o);
>
> -static int will_have_skip_worktree(const struct cache_entry *ce, struct unpack_trees_options *o)
> +static int will_have_skip_worktree(const struct cache_entry *ce, struct exclude_list *el)
> {
> const char *basename;
>
> basename = strrchr(ce->name, '/');
> basename = basename ? basename+1 : ce->name;
> - return excluded_from_list(ce->name, ce_namelen(ce), basename, NULL, o->el) <= 0;
> + return excluded_from_list(ce->name, ce_namelen(ce), basename, NULL, el) <= 0;
> }
>
> static int apply_sparse_checkout(struct cache_entry *ce, struct unpack_trees_options *o)
> @@ -849,7 +849,7 @@ static void mark_new_skip_worktree(struct exclude_list *el,
> if (select_flag && !(ce->ce_flags & select_flag))
> continue;
>
> - if (!ce_stage(ce) && will_have_skip_worktree(ce, o))
> + if (!ce_stage(ce) && will_have_skip_worktree(ce, el))
> ce->ce_flags |= skip_wt_flag;
> else
> ce->ce_flags &= ~skip_wt_flag;
> --8<--
>
>> Duy, sorry for prodding you again.
>
> No problem (and sorry for breaking the build). I'll also have a look
> at this problem.
Thanks. I can confirm that with the above patch, the code compiles and
fails my test. So it's the earlier of the two commits which introduces this.
Michael
^ permalink raw reply
* Re: git checkout under 1.7.6 does not properly list untracked files and aborts
From: Nguyen Thai Ngoc Duy @ 2011-09-21 8:58 UTC (permalink / raw)
To: Michael J Gruber; +Cc: Joshua Jensen, git@vger.kernel.org
In-Reply-To: <4E79A04B.7080607@drmicha.warpmail.net>
On Wed, Sep 21, 2011 at 10:28:59AM +0200, Michael J Gruber wrote:
> So, I bisected it. The first bad commit is
>
> 9037026 (unpack-trees: fix sparse checkout's "unable to match
> directories", 2010-11-27)
>
> although the real culprit may be its predecessor
>
> 2431afb (unpack-trees: move all skip-worktree checks back to
> unpack_trees(), 2010-11-27)
>
> which does not compile:
>
> CC unpack-trees.o
> unpack-trees.c: In function 'mark_new_skip_worktree':
> unpack-trees.c:852:75: error: 'o' undeclared (first use in this function)
> unpack-trees.c:852:75: note: each undeclared identifier is reported only
> once for each function it appears in
> make: *** [unpack-trees.o] Error 1
This may help
--8<--
diff --git a/unpack-trees.c b/unpack-trees.c
index a6518db..a239af7 100644
--- a/unpack-trees.c
+++ b/unpack-trees.c
@@ -245,13 +245,13 @@ static int check_updates(struct unpack_trees_options *o)
static int verify_uptodate_sparse(struct cache_entry *ce, struct unpack_trees_options *o);
static int verify_absent_sparse(struct cache_entry *ce, enum unpack_trees_error_types, struct unpack_trees_options *o);
-static int will_have_skip_worktree(const struct cache_entry *ce, struct unpack_trees_options *o)
+static int will_have_skip_worktree(const struct cache_entry *ce, struct exclude_list *el)
{
const char *basename;
basename = strrchr(ce->name, '/');
basename = basename ? basename+1 : ce->name;
- return excluded_from_list(ce->name, ce_namelen(ce), basename, NULL, o->el) <= 0;
+ return excluded_from_list(ce->name, ce_namelen(ce), basename, NULL, el) <= 0;
}
static int apply_sparse_checkout(struct cache_entry *ce, struct unpack_trees_options *o)
@@ -849,7 +849,7 @@ static void mark_new_skip_worktree(struct exclude_list *el,
if (select_flag && !(ce->ce_flags & select_flag))
continue;
- if (!ce_stage(ce) && will_have_skip_worktree(ce, o))
+ if (!ce_stage(ce) && will_have_skip_worktree(ce, el))
ce->ce_flags |= skip_wt_flag;
else
ce->ce_flags &= ~skip_wt_flag;
--8<--
> Duy, sorry for prodding you again.
No problem (and sorry for breaking the build). I'll also have a look
at this problem.
^ permalink raw reply related
* Re: git checkout under 1.7.6 does not properly list untracked files and aborts
From: Michael J Gruber @ 2011-09-21 8:28 UTC (permalink / raw)
Cc: Joshua Jensen, git@vger.kernel.org, Nguyen Thai Ngoc Duy
In-Reply-To: <4E7996AA.4040909@drmicha.warpmail.net>
Michael J Gruber venit, vidit, dixit 21.09.2011 09:47:
> Interesting. So, it is related to sparse, it seems, and there is also a
> mistake in the documentation (which contradicts itself, btw). With your
> script, since all files are requested to be checked out ('*'), none
> should have skip-worktree set, and the result should be the same as with
> my version. But I get this:
>
> Initialized empty Git repository in /tmp/t/utest/.git/
> [master (root-commit) 5929c8b] a
> 1 files changed, 1 insertions(+), 0 deletions(-)
> create mode 100644 a
> [master 60ad69e] 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
> untracked
>
> That is probably the same output as for you. The final "git checkout
> master" errored out without doing anything and without message. I'll
> send a few cleanups now, and do some bisecting and thinking later;
> though there are people whose sparse-knowledge is way less sparse than
> mine ;)
So, I bisected it. The first bad commit is
9037026 (unpack-trees: fix sparse checkout's "unable to match
directories", 2010-11-27)
although the real culprit may be its predecessor
2431afb (unpack-trees: move all skip-worktree checks back to
unpack_trees(), 2010-11-27)
which does not compile:
CC unpack-trees.o
unpack-trees.c: In function 'mark_new_skip_worktree':
unpack-trees.c:852:75: error: 'o' undeclared (first use in this function)
unpack-trees.c:852:75: note: each undeclared identifier is reported only
once for each function it appears in
make: *** [unpack-trees.o] Error 1
So, this problem was introduced after v1.7.3.2. Given the extent of
those two commits, I can't help further (but your proposed fix may be fine).
Duy, sorry for prodding you again. My bisect script was (based on
Joshua's, based on mine):
#!/bin/sh
GIT_EXEC_DIR=~/src/git
PATH=$GIT_EXEC_DIR:$PATH
export GIT_EXEC_DIR
d=/tmp/t/utest
rm -Rf $d || exit 1
mkdir $d || exit 1
cd $d || 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
git checkout side
echo untracked>b
git checkout master 2>&1 | grep "would be"
Hope this helps.
Michael
^ permalink raw reply
* Re: [PATCH 0/3] read-tree cleanups
From: Michael J Gruber @ 2011-09-21 7:51 UTC (permalink / raw)
Cc: git, Junio C Hamano
In-Reply-To: <cover.1316590874.git.git@drmicha.warpmail.net>
Michael J Gruber venit, vidit, dixit 21.09.2011 09:48:
> These are a few cleanups I noticed while checking Joshua's sparse checkout
> problem when swithcing branches with a dirty sparse tree.
> They are independent of a possible fix.
>
> Michael J Gruber (3):
> unpack-trees: print "Aborting" to stderr
> git-read-tree.txt: language and typography fixes
> git-read-tree.txt: correct sparse-checkout and skip-worktree
> description
>
> Documentation/git-read-tree.txt | 48 +++++++++++++++++++-------------------
> unpack-trees.c | 2 +-
> 2 files changed, 25 insertions(+), 25 deletions(-)
>
Uhm, I forgot about the dont-cc-jc-in-rc policy, sorry. This is not a
late-minute regression fix and can wait.
Michael
^ permalink raw reply
* [PATCH 3/3] git-read-tree.txt: correct sparse-checkout and skip-worktree description
From: Michael J Gruber @ 2011-09-21 7:48 UTC (permalink / raw)
To: git; +Cc: Joshua Jensen, Junio C Hamano
In-Reply-To: <cover.1316590874.git.git@drmicha.warpmail.net>
The description of .git/info/sparse-checkout and
skip-worktree is exactly the opposite of what is true, which is:
If a file matches a pattern in sparse-checkout, then (it is to be
checked out and therefore) skip-worktree is unset for that file;
otherwise, it is set (so that it is not checked out).
Currently, the opposite is documented, and (consistently) read-tree's
behavior with respect to bit flips is descibed incorrectly.
Fix it.
In hindsight, it would have been much better to have a "sparse-ignore"
or "sparse-skip" file so that an empty file would mean a full checkout,
and the file logic would be analogous to that of .gitignore, excludes
and skip-worktree.
Signed-off-by: Michael J Gruber <git@drmicha.warpmail.net>
---
Documentation/git-read-tree.txt | 8 ++++----
1 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/Documentation/git-read-tree.txt b/Documentation/git-read-tree.txt
index 0004f4b..1bd0317 100644
--- a/Documentation/git-read-tree.txt
+++ b/Documentation/git-read-tree.txt
@@ -389,12 +389,12 @@ directory update. `$GIT_DIR/info/sparse-checkout` is used to
define the skip-worktree reference bitmap. When 'git read-tree' needs
to update the working directory, it resets the skip-worktree bit in the index
based on this file, which uses the same syntax as .gitignore files.
-If an entry matches a pattern in this file, skip-worktree will be
-set on that entry. Otherwise, skip-worktree will be unset.
+If an entry matches a pattern in this file, skip-worktree will not be
+set on that entry. Otherwise, skip-worktree will be set.
Then it compares the new skip-worktree value with the previous one. If
-skip-worktree turns from unset to set, it will add the corresponding
-file back. If it turns from set to unset, that file will be removed.
+skip-worktree turns from set to unset, it will add the corresponding
+file back. If it turns from unset to set, that file will be removed.
While `$GIT_DIR/info/sparse-checkout` is usually used to specify what
files are in, you can also specify what files are _not_ in, using
--
1.7.7.rc0.469.g9eb94
^ permalink raw reply related
* [PATCH 1/3] unpack-trees: print "Aborting" to stderr
From: Michael J Gruber @ 2011-09-21 7:48 UTC (permalink / raw)
To: git; +Cc: Joshua Jensen, Junio C Hamano
In-Reply-To: <cover.1316590874.git.git@drmicha.warpmail.net>
display_error_msgs() prints all the errors to stderr already (if any),
followed by "Aborting" (if any) to stdout. Make the latter go to stderr
instead.
Signed-off-by: Michael J Gruber <git@drmicha.warpmail.net>
---
unpack-trees.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/unpack-trees.c b/unpack-trees.c
index 670b464..237aed8 100644
--- a/unpack-trees.c
+++ b/unpack-trees.c
@@ -159,7 +159,7 @@ static void display_error_msgs(struct unpack_trees_options *o)
string_list_clear(rejects, 0);
}
if (something_displayed)
- printf("Aborting\n");
+ fprintf(stderr, "Aborting\n");
}
/*
--
1.7.7.rc0.469.g9eb94
^ permalink raw reply related
* [PATCH 2/3] git-read-tree.txt: language and typography fixes
From: Michael J Gruber @ 2011-09-21 7:48 UTC (permalink / raw)
To: git; +Cc: Joshua Jensen, Junio C Hamano
In-Reply-To: <cover.1316590874.git.git@drmicha.warpmail.net>
Fix a few missing articles and such, and mark-up 'commands' and `files`
appropriately.
Signed-off-by: Michael J Gruber <git@drmicha.warpmail.net>
---
Documentation/git-read-tree.txt | 40 +++++++++++++++++++-------------------
1 files changed, 20 insertions(+), 20 deletions(-)
diff --git a/Documentation/git-read-tree.txt b/Documentation/git-read-tree.txt
index c45d53c..0004f4b 100644
--- a/Documentation/git-read-tree.txt
+++ b/Documentation/git-read-tree.txt
@@ -47,7 +47,7 @@ OPTIONS
-i::
Usually a merge requires the index file as well as the
- files in the working tree are up to date with the
+ files in the working tree to be up to date with the
current head commit, in order not to lose local
changes. This flag disables the check with the working
tree and is meant to be used when creating a merge of
@@ -71,21 +71,21 @@ OPTIONS
--aggressive::
Usually a three-way merge by 'git read-tree' resolves
the merge for really trivial cases and leaves other
- cases unresolved in the index, so that Porcelains can
+ cases unresolved in the index, so that porcelains can
implement different merge policies. This flag makes the
- command to resolve a few more cases internally:
+ command resolve a few more cases internally:
+
* when one side removes a path and the other side leaves the path
unmodified. The resolution is to remove that path.
* when both sides remove a path. The resolution is to remove that path.
-* when both sides adds a path identically. The resolution
+* when both sides add a path identically. The resolution
is to add that path.
--prefix=<prefix>/::
Keep the current index contents, and read the contents
- of named tree-ish under directory at `<prefix>`. The
+ of the named tree-ish under the directory at `<prefix>`. The
original index file cannot have anything at the path
- `<prefix>` itself, and have nothing in `<prefix>/`
+ `<prefix>` itself, nor anything in the `<prefix>/`
directory. Note that the `<prefix>/` value must end
with a slash.
@@ -379,15 +379,15 @@ have finished your work-in-progress), attempt the merge again.
Sparse checkout
---------------
-"Sparse checkout" allows to sparsely populate working directory.
-It uses skip-worktree bit (see linkgit:git-update-index[1]) to tell
-Git whether a file on working directory is worth looking at.
+"Sparse checkout" allows populating the working directory sparsely.
+It uses the skip-worktree bit (see linkgit:git-update-index[1]) to tell
+Git whether a file in the working directory is worth looking at.
-"git read-tree" and other merge-based commands ("git merge", "git
-checkout"...) can help maintaining skip-worktree bitmap and working
+'git read-tree' and other merge-based commands ('git merge', 'git
+checkout'...) can help maintaining the skip-worktree bitmap and working
directory update. `$GIT_DIR/info/sparse-checkout` is used to
-define the skip-worktree reference bitmap. When "git read-tree" needs
-to update working directory, it will reset skip-worktree bit in index
+define the skip-worktree reference bitmap. When 'git read-tree' needs
+to update the working directory, it resets the skip-worktree bit in the index
based on this file, which uses the same syntax as .gitignore files.
If an entry matches a pattern in this file, skip-worktree will be
set on that entry. Otherwise, skip-worktree will be unset.
@@ -397,18 +397,18 @@ skip-worktree turns from unset to set, it will add the corresponding
file back. If it turns from set to unset, that file will be removed.
While `$GIT_DIR/info/sparse-checkout` is usually used to specify what
-files are in. You can also specify what files are _not_ in, using
-negate patterns. For example, to remove file "unwanted":
+files are in, you can also specify what files are _not_ in, using
+negate patterns. For example, to remove the file `unwanted`:
----------------
*
!unwanted
----------------
-Another tricky thing is fully repopulating working directory when you
+Another tricky thing is fully repopulating the working directory when you
no longer want sparse checkout. You cannot just disable "sparse
-checkout" because skip-worktree are still in the index and you working
-directory is still sparsely populated. You should re-populate working
+checkout" because skip-worktree bits are still in the index and your working
+directory is still sparsely populated. You should re-populate the working
directory with the `$GIT_DIR/info/sparse-checkout` file content as
follows:
@@ -416,8 +416,8 @@ follows:
*
----------------
-Then you can disable sparse checkout. Sparse checkout support in "git
-read-tree" and similar commands is disabled by default. You need to
+Then you can disable sparse checkout. Sparse checkout support in 'git
+read-tree' and similar commands is disabled by default. You need to
turn `core.sparseCheckout` on in order to have sparse checkout
support.
--
1.7.7.rc0.469.g9eb94
^ permalink raw reply related
* [PATCH 0/3] read-tree cleanups
From: Michael J Gruber @ 2011-09-21 7:48 UTC (permalink / raw)
To: git; +Cc: Joshua Jensen, Junio C Hamano
In-Reply-To: <4E7996AA.4040909@drmicha.warpmail.net>
These are a few cleanups I noticed while checking Joshua's sparse checkout
problem when swithcing branches with a dirty sparse tree.
They are independent of a possible fix.
Michael J Gruber (3):
unpack-trees: print "Aborting" to stderr
git-read-tree.txt: language and typography fixes
git-read-tree.txt: correct sparse-checkout and skip-worktree
description
Documentation/git-read-tree.txt | 48 +++++++++++++++++++-------------------
unpack-trees.c | 2 +-
2 files changed, 25 insertions(+), 25 deletions(-)
--
1.7.7.rc0.469.g9eb94
^ permalink raw reply
* Re: git checkout under 1.7.6 does not properly list untracked files and aborts
From: Michael J Gruber @ 2011-09-21 7:47 UTC (permalink / raw)
To: Joshua Jensen; +Cc: git@vger.kernel.org
In-Reply-To: <4E78DACF.3030200@workspacewhiz.com>
Joshua Jensen venit, vidit, dixit 20.09.2011 20:26:
> ----- 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
Interesting. So, it is related to sparse, it seems, and there is also a
mistake in the documentation (which contradicts itself, btw). With your
script, since all files are requested to be checked out ('*'), none
should have skip-worktree set, and the result should be the same as with
my version. But I get this:
Initialized empty Git repository in /tmp/t/utest/.git/
[master (root-commit) 5929c8b] a
1 files changed, 1 insertions(+), 0 deletions(-)
create mode 100644 a
[master 60ad69e] 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
untracked
That is probably the same output as for you. The final "git checkout
master" errored out without doing anything and without message. I'll
send a few cleanups now, and do some bisecting and thinking later;
though there are people whose sparse-knowledge is way less sparse than
mine ;)
Michael
^ permalink raw reply
* Re: [PATCH di/fast-import-deltified-tree] Windows: define S_ISUID properly
From: Dmitry Ivankov @ 2011-09-21 7:38 UTC (permalink / raw)
To: git
In-Reply-To: <4E798538.7070106@viscovery.net>
Johannes Sixt <j.sixt <at> viscovery.net> writes:
>
> From: Johannes Sixt <j6t <at> kdbg.org>
>
> 8fb3ad76 (fast-import: prevent producing bad delta) introduced the first
> use of S_ISUID. Since before this commit the value was irrelevant, we had
> only a dummy definition in mingw.h. But beginning with this commit the
> macro must expand to a reasonable value. Make it so.
>
> We do not change S_ISGID from the value 0 because it is used in path.c
> (via FORCE_DIR_SET_GID) to set the mode on directories in a manner that
> is not supported on Windows, and 0 is the right value in this case.
>
> Signed-off-by: Johannes Sixt <j6t <at> kdbg.org>
> ---
> compat/mingw.h | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/compat/mingw.h b/compat/mingw.h
> index 547568b..e2c89d6 100644
> --- a/compat/mingw.h
> +++ b/compat/mingw.h
> @@ -22,7 +22,7 @@ typedef int socklen_t;
> #define S_IWOTH 0
> #define S_IXOTH 0
> #define S_IRWXO (S_IROTH | S_IWOTH | S_IXOTH)
> -#define S_ISUID 0
> +#define S_ISUID 04000
> #define S_ISGID 0
> #define S_ISVTX 0
>
Ow, it's awkward that the issue was discussed in [1] but slipped and nobody
noticed, especially me being a patch sender.
If we choose patch from [1] I'd also change a comment to smth like
/*
* We abuse the 04000 bit on directories to mean "do not delta".
* It is a S_ISUID bit on setuid platforms and an unused bit on
* non-setuid platforms supported in git. In either case git ignores
* the bit, so it's safe to abuse it locally.
*/
[1] http://thread.gmane.org/gmane.comp.version-control.git/179223/focus=179762
^ permalink raw reply
* Re: [PATCH] bisect: fix exiting when checkout failed in bisect_start()
From: Jon Seymour @ 2011-09-21 6:42 UTC (permalink / raw)
To: Christian Couder; +Cc: Junio C Hamano, git, Joel Kaasinen
In-Reply-To: <20110921051725.5255.6756.chriscool@tuxfamily.org>
On Wed, Sep 21, 2011 at 3:17 PM, Christian Couder
<chriscool@tuxfamily.org> wrote:
> Commit 4796e823 ("bisect: introduce --no-checkout support into porcelain." Aug 4 2011)
> made checking out the branch where we started depends on the "checkout" mode. But
> unfortunately it lost the "|| exit" part after the checkout command.
>
> As it makes no sense to continue if the checkout failed and as people have already
> complained that the error message given when we just exit in this case is not clear, see:
>
> http://thread.gmane.org/gmane.comp.version-control.git/180733/
>
> this patch adds a "|| die <hopefully clear message>" part after the checkout command.
>
> Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
> ---
> git-bisect.sh | 3 ++-
> 1 files changed, 2 insertions(+), 1 deletions(-)
>
> diff --git a/git-bisect.sh b/git-bisect.sh
> index e0ca3fb..5fb4291 100755
> --- a/git-bisect.sh
> +++ b/git-bisect.sh
> @@ -129,7 +129,8 @@ bisect_start() {
> start_head=$(cat "$GIT_DIR/BISECT_START")
> if test "z$mode" != "z--no-checkout"
> then
> - git checkout "$start_head" --
> + git checkout "$start_head" -- ||
> + die "$(eval_gettext "Checking out '\$start_head' failed. Try 'git bisect reset <validbranch>'.")"
> fi
> else
> # Get rev from where we start.
> --
> 1.7.7.rc0.72.g4b5ea.dirty
>
>
Thanks. Looks good to me.
Acked-by: Jon Seymour <jon.seymour@gmal.com>
^ permalink raw reply
* [PATCH di/fast-import-deltified-tree] Windows: define S_ISUID properly
From: Johannes Sixt @ 2011-09-21 6:33 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Git Mailing List, msysGit
From: Johannes Sixt <j6t@kdbg.org>
8fb3ad76 (fast-import: prevent producing bad delta) introduced the first
use of S_ISUID. Since before this commit the value was irrelevant, we had
only a dummy definition in mingw.h. But beginning with this commit the
macro must expand to a reasonable value. Make it so.
We do not change S_ISGID from the value 0 because it is used in path.c
(via FORCE_DIR_SET_GID) to set the mode on directories in a manner that
is not supported on Windows, and 0 is the right value in this case.
Signed-off-by: Johannes Sixt <j6t@kdbg.org>
---
compat/mingw.h | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/compat/mingw.h b/compat/mingw.h
index 547568b..e2c89d6 100644
--- a/compat/mingw.h
+++ b/compat/mingw.h
@@ -22,7 +22,7 @@ typedef int socklen_t;
#define S_IWOTH 0
#define S_IXOTH 0
#define S_IRWXO (S_IROTH | S_IWOTH | S_IXOTH)
-#define S_ISUID 0
+#define S_ISUID 04000
#define S_ISGID 0
#define S_ISVTX 0
--
1.7.7.rc2.1135.gf321f
^ permalink raw reply related
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