* Re: Bug: git log --numstat counts wrong
From: Alexander Pepper @ 2011-09-21 13:40 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vr53a2icn.fsf@alter.siamese.dyndns.org>
Am 21.09.2011 um 14:24 schrieb Junio C Hamano:
>> $ 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.
I just compiled git fresh from the master (4b5eac7f) and the issue is still active there:
$ ../git/git --version
git version 1.7.7.rc0.72.g4b5ea
$ ../git/git log --numstat 48a07e7e533f507228e8d1c99d4d48e175e14260
[...]
11 10 src/java/voldemort/server/storage/StorageService.java
Should I check another branch?
^ permalink raw reply
* Re: mac osx
From: Timothy Harper @ 2011-09-21 12:52 UTC (permalink / raw)
To: Sverre Rabbelier; +Cc: Kyle Neath, tom smitts, git
In-Reply-To: <CAGdFq_h0VqbZ5W3QVwoQWT63znhpePDFCRE+-n1TqPNztREwkA@mail.gmail.com>
On Sep 21, 2011, at 04:34, Sverre Rabbelier wrote:
> 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!
Good point, I'll update the description to include "32-bit" and "64-bit"
>>> Why make mac installers at all?
Why, to install git on the mac, of course. Previous to Xcode 4.0, it wasn't included. It still has value for those that want git on their machine but haven't downloaded and installed the 4gb Xcode package.
>>> Mac users
>>> know their operating system number, e.g. 10.6.7,
>>> and that's all.
I am a mac user. I know much more than the operating system number.
>>> I doubt Windows users know any better.
Fair enough.
>>> And I doubt you can find anywhere on a mac that says
>>> i386 or whatever the heck the other dumb
>>> designation is.
Sure you can. For example:
timcharper@timtheenchanter:~/Desktop $ file /bin/bash
/bin/bash: Mach-O universal binary with 2 architectures
/bin/bash (for architecture x86_64): Mach-O 64-bit executable x86_64
/bin/bash (for architecture i386): Mach-O executable i386
That "dumb designation" is the march (machine architecture). It's a standard to label packages that way in the unix packaging world. I suppose many of us have just grown up knowing that from our experience compiling software.
Based on the way you've approached your complaining, I get the impression you aren't one of those linux users. Perhaps take a deep breath and take some valium for more tact next time? We're volunteers here. I'm trying to make your life better, not more miserable than it already 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
Kyle, I'll put 32-bit and 64-bit in the description. Somebody mentioned linking to the featured download list as well in that issue, that's a good recommendation.
> --
> Cheers,
>
> Sverre Rabbelier
Cheers! Be happy! Go pet a puppy!
Tim
^ permalink raw reply
* Re: Possible timestamp problems with diff-files?
From: Marc Strapetz @ 2011-09-21 12:58 UTC (permalink / raw)
To: Jeff King; +Cc: git
In-Reply-To: <20110920175458.GA3776@sigill.intra.peff.net>
On 20.09.2011 19:54, Jeff King wrote:
> 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?
My point is that "git diff-files --quiet" seems to returns 1 and when
invoked a short time later (without modifying working tree or invoking
any other Git command) it returns 0. This would indicate a bug in Git, I
guess. I think we can add more debug logging to our client to track down
that problem. However, to do that I'd need some input on what to log?
--
Best regards,
Marc Strapetz
=============
syntevo GmbH
http://www.syntevo.com
http://blog.syntevo.com
^ permalink raw reply
* [PATCH] patch-id.c: use strbuf instead of a fixed buffer
From: Michael Schubert @ 2011-09-21 12:42 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Andrew Pimlott, git, Jeff King
In-Reply-To: <7vehzb5602.fsf@alter.siamese.dyndns.org>
get_one_patchid() uses a rather dumb heuristic to determine if the
passed buffer is part of the next commit. Whenever the first 40 bytes
are a valid hexadecimal sha1 representation, get_one_patchid() returns
next_sha1.
Once the current line is longer than the fixed buffer, this will break
(provided the additional bytes make a valid hexadecimal sha1). As a result
patch-id returns incorrect results. Instead, user strbuf and read one
line at a time.
Helped-by: Jeff King <peff@peff.net>
Signed-off-by: Michael Schubert <mschub@elegosoft.com>
---
builtin/patch-id.c | 10 ++++++----
1 files changed, 6 insertions(+), 4 deletions(-)
diff --git a/builtin/patch-id.c b/builtin/patch-id.c
index f821eb3..3cfe02d 100644
--- a/builtin/patch-id.c
+++ b/builtin/patch-id.c
@@ -56,13 +56,13 @@ static int scan_hunk_header(const char *p, int *p_before, int *p_after)
return 1;
}
-static int get_one_patchid(unsigned char *next_sha1, git_SHA_CTX *ctx)
+static int get_one_patchid(unsigned char *next_sha1, git_SHA_CTX *ctx, struct strbuf *line_buf)
{
- static char line[1000];
int patchlen = 0, found_next = 0;
int before = -1, after = -1;
- while (fgets(line, sizeof(line), stdin) != NULL) {
+ while (strbuf_getwholeline(line_buf, stdin, '\n') != EOF) {
+ char *line = line_buf->buf;
char *p = line;
int len;
@@ -133,14 +133,16 @@ static void generate_id_list(void)
unsigned char sha1[20], n[20];
git_SHA_CTX ctx;
int patchlen;
+ struct strbuf line_buf = STRBUF_INIT;
git_SHA1_Init(&ctx);
hashclr(sha1);
while (!feof(stdin)) {
- patchlen = get_one_patchid(n, &ctx);
+ patchlen = get_one_patchid(n, &ctx, &line_buf);
flush_current_id(patchlen, sha1, &ctx);
hashcpy(sha1, n);
}
+ strbuf_release(&line_buf);
}
static const char patch_id_usage[] = "git patch-id < patch";
--
1.7.7.rc2.365.g55c1f
^ permalink raw reply related
* 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
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