* Re: [PATCH di/fast-import-deltified-tree] Windows: define S_ISUID properly
From: Junio C Hamano @ 2011-09-21 15:13 UTC (permalink / raw)
To: Dmitry Ivankov; +Cc: Junio C Hamano, git, Johannes Sixt
In-Reply-To: <CA+gfSn8VaTLcrLqb3HGJpjL5WJMHZz4kPPUtyeHPCsdmO5iU8g@mail.gmail.com>
Dmitry Ivankov <divanorama@gmail.com> writes:
>> 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.
>
> Depends on what is a usual bit. I'll use linux defines for mode bits.
Failed -- was too subtle to extract a hoped-for response "come to think of
it we should have done it as a separate field in the structure".
^ permalink raw reply
* Re: mac osx
From: Scott Chacon @ 2011-09-21 14:58 UTC (permalink / raw)
To: Timothy Harper; +Cc: Sverre Rabbelier, Kyle Neath, tom smitts, git
In-Reply-To: <F4C226A7-768D-4913-A6C1-12411FBA212C@gmail.com>
Hey,
On Wed, Sep 21, 2011 at 5:52 AM, Timothy Harper <timcharper@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"
Honestly this doesn't help much. I think the point is that these
numbers or machs are not in any of the docs or ads I can think of for
macs. I feel pretty stupid admitting this to this list, but I
honestly don't know which macs are 32 bit - I assume the MBP is 64,
but if someone challenged me I'm not sure I could really defend it.
Not that I'm the smartest guy in the world, but I have been using *NIX
for a long damn time - it's just that Apple doesn't really use that as
much of a selling point - it's not like the old days when nerds like
us would buy the CPU at the store and it said "64-bit" on it - you buy
a mac, maybe you know it's a Core Duo or i5/i7 but how are you
supposed to know that means 64-bit? I suppose a real geek would, and
maybe I've fallen out of that category somehow, but honestly chipset
has been so unimportant these days when compared to disk type and
speed (SSD, etc), memory size, etc - I just don't follow the
incremental improvements anymore.
Even I don't really keep up with the chipset specs to know - I can't
imagine anyone using the dmg installer instead of brew would have the
slightest idea what 64-bit even means. And in our defense, the march
is nowhere on this entire tech spec page for a MBP:
http://www.apple.com/macbookpro/specs.html
So maybe you care enough to see that the chipset is an i7, so you
google it and end up on the intel i7 page:
http://www.intel.com/content/www/us/en/processors/core/core-i7-processor.html
Nope, no march there either. I had to specifically find the wikipedia
page for the processor which lists it:
http://en.wikipedia.org/wiki/Intel_Core#Core_i7
And 3/4 of the way down a huge page and only as a passing reference.
The point being - almost nobody that clicks on the DMG link from the
git-scm website is going to know what bit architecture they're running
on.
> 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.
>
I link to the featured downloads from git-scm.com front page as the
huge mac icon - I assume that's where most people land when they're
looking for a mac installer. And on that page you have "Leopard" and
"Snow Leopard" on each download, which is WAY more common for people
to know. What I should probably do is have a dropdown thingy on
git-scm that asks you what kind of mac you have and what OS you are
running (whatever I can't get from the browser info) and just
auto-download the right one so they never have to see the google
downloads page. That would, however, take Google having an api or me
scraping that page, which I'll have to look into.
Scott
^ permalink raw reply
* Re: Bug: git log --numstat counts wrong
From: Alexander Pepper @ 2011-09-21 14:23 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.
Besides master I tried some other branches. Current 'maint' (cd2b8ae9), 'master' (4b5eac7f) and v1.7.7-rc0 (a452d148) are still counting wrong, but 'next' (3be2039f) and 'pu' (b4bcbace) do count correctly.
I'll have a closer look with the 'next' branch if all counts are correct now.
^ permalink raw reply
* Re: [PATCH di/fast-import-deltified-tree] Windows: define S_ISUID properly
From: Dmitry Ivankov @ 2011-09-21 13:44 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Johannes Sixt
In-Reply-To: <7vfwjq2hoo.fsf@alter.siamese.dyndns.org>
On Wed, Sep 21, 2011 at 6:08 PM, Junio C Hamano <gitster@pobox.com> wrote:
> 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.
Depends on what is a usual bit. I'll use linux defines for mode bits.
There are S_ISVTX, S_ISUID completely unused in git, S_ISGID is used somehow.
9 lower rwx bits are used as well as S_IFREG and S_IFDIR. Remaining are S_IFIFO
(used somehow), S_IFCHR (part of GITLNK).
S_ISUID in fast-import input stream isn't accepted, so the only danger
is it may come
from a tree object (but not yet, git-fsck doesn't allow it). Or if
there appears a platform
with different S_I{F,S}* definitions, which will break more git parts
than just fast-import.
I remember there was a thread concerning platform vs git-core mode
bits. I'd just use
hard-coded 04000 bit in fast-import as a hot-fix and leave the rest
for the bits topic.
With S_ISUID in a comment near 04000 it'll be a grep-able hard-coded
constant, so
it should be ok.
^ permalink raw reply
* 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
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