* Re: [PATCH] Clarify that '--tags' fetches tags only
From: Michael Witten @ 2011-09-22 0:13 UTC (permalink / raw)
To: Anatol Pomozov; +Cc: git, gitster, computerdruid
In-Reply-To: <1316649176-32352-1-git-send-email-anatol.pomozov@gmail.com>
On Wed, Sep 21, 2011 at 23:52, Anatol Pomozov <anatol.pomozov@gmail.com> wrote:
> + linkgit:git-config[1]. Note that if this option is specified
> + then only tags are fetched, refs under refs/heads/* stay unchanged.
Note that if this option is specified, then only tags
are fetched; refs under refs/heads/* are not changed.
^ permalink raw reply
* [PATCH] Clarify that '--tags' fetches tags only
From: Anatol Pomozov @ 2011-09-21 23:52 UTC (permalink / raw)
To: git, gitster; +Cc: computerdruid, Anatol Pomozov
In-Reply-To: <1314997486-29996-1-git-send-email-anatol.pomozov@gmail.com>
'git fetch --tags' fetches tags only and leaves heads untouched.
Many people are confused by the fact that 'git fetch --tags'
does not fetch heads.
Signed-off-by: Anatol Pomozov <anatol.pomozov@gmail.com>
---
Documentation/fetch-options.txt | 3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/Documentation/fetch-options.txt b/Documentation/fetch-options.txt
index 39d326a..37d2316 100644
--- a/Documentation/fetch-options.txt
+++ b/Documentation/fetch-options.txt
@@ -63,7 +63,8 @@ ifndef::git-pull[]
flag lets all tags and their associated objects be
downloaded. The default behavior for a remote may be
specified with the remote.<name>.tagopt setting. See
- linkgit:git-config[1].
+ linkgit:git-config[1]. Note that if this option is specified
+ then only tags are fetched, refs under refs/heads/* stay unchanged.
--recurse-submodules[=yes|on-demand|no]::
This option controls if and under what conditions new commits of
--
1.7.7.rc0.72.g4b5ea.dirty
^ permalink raw reply related
* Re: Fwd: vcs-svn and friends
From: Jonathan Nieder @ 2011-09-21 23:40 UTC (permalink / raw)
To: Dmitry Ivankov; +Cc: David Michael Barr, Junio C Hamano, git
In-Reply-To: <CA+gfSn9KVN2iDCevd0s+TjYHNupDez8NiKZycP3pgBCkYiraFQ@mail.gmail.com>
Dmitry Ivankov wrote:
>> - 3bba32e9 ("fast-import: allow top directory as an argument for some
>> commands"): I'm not sure what the motivation is --- is this just
>> about the principle of least surprise, or did it come up in practice
>> somewhere?
>
> (to ease one's reading, commands are ls, copy and move top directory)
>
> Haven't seen them in practice. It seemed possible with svn import: if there were
> no branches at start, and then someone did svn mv . trunk. But it
> turns out that my
> svn client doesn't allow such move. So more like a least surprise purpose.
With that information in mind, it sounds like a reasonable change in
principle (though I haven't looked over the code at all). Could you
propose a log message explaining it (both the original motivation and
the actual impact)?
Thanks,
Jonathan
^ permalink raw reply
* Re: [PATCH 1/3] unpack-trees: print "Aborting" to stderr
From: Junio C Hamano @ 2011-09-21 22:40 UTC (permalink / raw)
To: Michael J Gruber; +Cc: git, Joshua Jensen
In-Reply-To: <7v7h511rl9.fsf@alter.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> Forgot to update a test or two that this breaks?
In the meantime I've squashed this in.
t/t7607-merge-overwrite.sh | 1 +
t/t7609-merge-co-error-msgs.sh | 5 +++++
2 files changed, 6 insertions(+), 0 deletions(-)
diff --git a/t/t7607-merge-overwrite.sh b/t/t7607-merge-overwrite.sh
index 72a8731..aa74184 100755
--- a/t/t7607-merge-overwrite.sh
+++ b/t/t7607-merge-overwrite.sh
@@ -107,6 +107,7 @@ error: The following untracked working tree files would be overwritten by merge:
sub
sub2
Please move or remove them before you can merge.
+Aborting
EOF
test_expect_success 'will not overwrite untracked file in leading path' '
diff --git a/t/t7609-merge-co-error-msgs.sh b/t/t7609-merge-co-error-msgs.sh
index c994836..0e4a682 100755
--- a/t/t7609-merge-co-error-msgs.sh
+++ b/t/t7609-merge-co-error-msgs.sh
@@ -32,6 +32,7 @@ error: The following untracked working tree files would be overwritten by merge:
three
two
Please move or remove them before you can merge.
+Aborting
EOF
test_expect_success 'untracked files overwritten by merge (fast and non-fast forward)' '
@@ -56,6 +57,7 @@ Please, commit your changes or stash them before you can merge.
error: The following untracked working tree files would be overwritten by merge:
five
Please move or remove them before you can merge.
+Aborting
EOF
test_expect_success 'untracked files or local changes ovewritten by merge' '
@@ -71,6 +73,7 @@ error: Your local changes to the following files would be overwritten by checkou
rep/one
rep/two
Please, commit your changes or stash them before you can switch branches.
+Aborting
EOF
test_expect_success 'cannot switch branches because of local changes' '
@@ -92,6 +95,7 @@ error: Your local changes to the following files would be overwritten by checkou
rep/one
rep/two
Please, commit your changes or stash them before you can switch branches.
+Aborting
EOF
test_expect_success 'not uptodate file porcelain checkout error' '
@@ -105,6 +109,7 @@ error: Updating the following directories would lose untracked files in it:
rep
rep2
+Aborting
EOF
test_expect_success 'not_uptodate_dir porcelain checkout error' '
^ permalink raw reply related
* Re: [PATCH 1/3] unpack-trees: print "Aborting" to stderr
From: Junio C Hamano @ 2011-09-21 22:02 UTC (permalink / raw)
To: Michael J Gruber; +Cc: git, Joshua Jensen, Junio C Hamano
In-Reply-To: <8b522de3711f339eea264dd7d8e44682af6c4865.1316590874.git.git@drmicha.warpmail.net>
Forgot to update a test or two that this breaks?
^ permalink raw reply
* Re: Possible timestamp problems with diff-files?
From: Junio C Hamano @ 2011-09-21 21:33 UTC (permalink / raw)
To: Marc Strapetz; +Cc: Jeff King, git
In-Reply-To: <4E79DF81.8090605@syntevo.com>
Marc Strapetz <marc.strapetz@syntevo.com> writes:
> 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)?
What peff said already.
If you do not refresh the cached stat information, diff-files may report
"they differ" for a path that is otherwise unchanged without looking at
the contents of such a path to notice that the only difference is the
cached stat information (the whole and only point of having the cached
stat information is to avoid looking at the contents). Also, it may look
at the contents of such a path if it has a reason to suspect that the file
might have changed if it cannot tell from the cached stat information
(look for "racy-git" if you are really interested).
Update the cached stat information before you use plumbing commands in
your script.
^ permalink raw reply
* Re: [PATCH 1/2] sparse checkout: show error messages when worktree shaping fails
From: Junio C Hamano @ 2011-09-21 20:50 UTC (permalink / raw)
To: Nguyễn Thái Ngọc Duy
Cc: git, Michael, J, Gruber, git, Joshua Jensen
In-Reply-To: <1316602259-22576-1-git-send-email-pclouds@gmail.com>
Please add a test when you reroll this, hopefully with help from Joshua.
Thanks.
^ permalink raw reply
* Re: Bug: git log --numstat counts wrong
From: Junio C Hamano @ 2011-09-21 20:35 UTC (permalink / raw)
To: Alexander Pepper; +Cc: git, Tay Ray Chuan
In-Reply-To: <3BF8BA51-4CAA-40A2-8B45-D39AAEE58E6F@inf.fu-berlin.de>
Alexander Pepper <pepper@inf.fu-berlin.de> writes:
> 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.
>
> Current 'maint' (cd2b8ae9), 'master' (4b5eac7f)...
That's a tad old master you seem to have.
Strangely, bisection points at 27af01d5523, which was supposed to be only
about performance and never about correctness. There is something fishy
going on....
^ permalink raw reply
* Re: [PATCH] abspath: increase array size of cwd variable to PATH_MAX
From: Junio C Hamano @ 2011-09-21 20:17 UTC (permalink / raw)
To: Ramsay Jones; +Cc: Wang Hui, git
In-Reply-To: <4E791A40.6040102@ramsay1.demon.co.uk>
Ramsay Jones <ramsay@ramsay1.demon.co.uk> writes:
> Hmm, the subject line says "... increase array size ...", but that is not
> necessarily what this patch is doing! :-D
True; will revert it out of 'next'.
Thanks for noticing.
^ permalink raw reply
* Re: How to use git attributes to configure server-side checks?
From: Junio C Hamano @ 2011-09-21 20:17 UTC (permalink / raw)
To: Michael Haggerty; +Cc: git discussion list
In-Reply-To: <4E7A3BDE.3040301@alum.mit.edu>
Michael Haggerty <mhagger@alum.mit.edu> writes:
> I was thinking of using git attributes to configure a server-side
> "update" hook that does some basic sanity checking before accepting a
> push. I thought I could do something like
>
> ~/.gitattributes:
> *.c whitespace
>
> ~/crappy-vendor-code/.gitattributes:
> # This code doesn't conform to our standards; disable check:
> *.c -whitespace
>
> This would allow fine-grained specification of which checks are applied
> to which files, and ensure that the hook configuration is kept
> synchronized with changes to the content.
>
> What I can't figure out is how a server-side update hook can inquire
> about the gitattributes that were associated with a file *in a
> particular commit*, as opposed to in the current working tree. I would
> like to ask questions like "was the "whitespace" attribute set on file F
> in commit C?"
>
> I see that there is an (undocumented) API involving
> git_attr_set_direction() that seems to let gitattributes to be read out
> of the index instead of the working tree. But I am still confused:
The words "server side" automatically mean that there should be no working
tree, and where there is no working tree there should be no index, so the
direction should not make any difference. The attributes that are used to
help whitespace checks should come from project.git/info/attributes in
such a case [*1*].
As to the actual checking of the pushed contents, your pre-receive hook is
called after all the objects received are placed in the object store, but
before the refs are updated to conclude the push, and you can veto the
push by exiting with non-zero status from the hook. Your hook will get
which ref is being updated from what old commit to what new commit, so you
can either
(1) grab the new commits introduced to the project using rev-list, and
invoke "git show --check" on each and every one of them; or
(2) check only the endpoints, by running "git diff --check" between the
old and new commits. A pushed series may introduce a breakage early
in the series which is corrected later in the series and you would
not catch such a case if you used this method.
[Footnote]
*1* granted, that there are people who make a checkout from their post
update hook, perhaps so that a build robot can be told to work on it or
the web server can deliver individual files. But that is merely a crude
substitute of having a proper "install" procedure. As far as the
"server-side" Git that accepts "git push" is concerned, such a working
tree does not exist.
^ permalink raw reply
* Re: How to use git attributes to configure server-side checks?
From: Jay Soffian @ 2011-09-21 20:02 UTC (permalink / raw)
To: Michael Haggerty; +Cc: git discussion list
In-Reply-To: <4E7A3BDE.3040301@alum.mit.edu>
On Wed, Sep 21, 2011 at 3:32 PM, Michael Haggerty <mhagger@alum.mit.edu> wrote:
> I was thinking of using git attributes to configure a server-side
> "update" hook that does some basic sanity checking before accepting a
> push. I thought I could do something like
>
> ~/.gitattributes:
> *.c whitespace
>
> ~/crappy-vendor-code/.gitattributes:
> # This code doesn't conform to our standards; disable check:
> *.c -whitespace
>
> This would allow fine-grained specification of which checks are applied
> to which files, and ensure that the hook configuration is kept
> synchronized with changes to the content.
I do this by running diff --check. I'm actually doing it via Jenkins +
Gerrit, but it's done against a bare repo, so the idea should work
just the same via a git hook. Here's the code I run in Jenkins in case
it's at all helpful - https://gist.github.com/6b230f9bd8d4d2fd9895
j.
^ permalink raw reply
* How to use git attributes to configure server-side checks?
From: Michael Haggerty @ 2011-09-21 19:32 UTC (permalink / raw)
To: git discussion list
I was thinking of using git attributes to configure a server-side
"update" hook that does some basic sanity checking before accepting a
push. I thought I could do something like
~/.gitattributes:
*.c whitespace
~/crappy-vendor-code/.gitattributes:
# This code doesn't conform to our standards; disable check:
*.c -whitespace
This would allow fine-grained specification of which checks are applied
to which files, and ensure that the hook configuration is kept
synchronized with changes to the content.
What I can't figure out is how a server-side update hook can inquire
about the gitattributes that were associated with a file *in a
particular commit*, as opposed to in the current working tree. I would
like to ask questions like "was the "whitespace" attribute set on file F
in commit C?"
I see that there is an (undocumented) API involving
git_attr_set_direction() that seems to let gitattributes to be read out
of the index instead of the working tree. But I am still confused:
1. The "git check-attr" program doesn't seem to expose the
git_attr_set_direction() functionality.
2. Even if it did, would that be enough? It seems like the update hook
(assuming a bare repository) would have to "git reset" the index to the
commit that it wants to check. Is that allowed? Is the index a scratch
space that the update hook can use however it likes? If so, is there
some kind of locking that would prevent multiple simultaneous pushes
from overwriting each other's index stat, or would the update script
have to implement its own locking scheme?
Am I going about this entirely the wrong way?
Thanks,
Michael
--
Michael Haggerty
mhagger@alum.mit.edu
http://softwareswirl.blogspot.com/
^ permalink raw reply
* Re: [ANNOUNCE] Git User's Survey 2011
From: Scott Chacon @ 2011-09-21 19:25 UTC (permalink / raw)
To: Jakub Narebski; +Cc: Michael J Gruber, git
In-Reply-To: <201109201704.56363.jnareb@gmail.com>
Hey,
2011/9/20 Jakub Narebski <jnareb@gmail.com>:
> And that even without GitHub announcing it (yes, I send request, and
> resent it yesterday via email rather than GitHub IM system), or
> announcement on Git Homepage (Scott is hard to reach...).
>
Sorry about this - we posted on our blog the other day and I'm trying
to put it on the git-scm site now. The old hosting solution was
getting way out of date and hard to deploy to, so requests kept piling
up. I'm moving the site over to Heroku so I can git push to deploy and
the DNS updates are taking forever. When it finally goes through a
bunch of updates will be live, including the Survey announcement and
the temporary removal of several k.org links.
Scott
^ permalink raw reply
* Re: [PATCH 1/2] sparse checkout: show error messages when worktree shaping fails
From: Joshua Jensen @ 2011-09-21 19:15 UTC (permalink / raw)
To: Nguyễn Thái Ngọc Duy; +Cc: git, Junio C Hamano, git
In-Reply-To: <1316602259-22576-1-git-send-email-pclouds@gmail.com>
----- Original Message -----
From: Nguyễn Thái Ngọc Duy
Date: 9/21/2011 4:50 AM
> 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;
Unfortunately, this patch only collects and displays the first untracked
file for me. It does not display all of the files that would be
overwritten (desired behavior, IMHO).
This script illustrates:
#!/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
echo tracked>c
git add b c
git commit -m bc
cat b
git checkout side
cat b
echo untracked>b
echo untracked>c
cat b
git checkout master
cat b
-Josh
^ permalink raw reply
* Re: mac osx
From: Timothy Harper @ 2011-09-21 18:09 UTC (permalink / raw)
To: Scott Chacon; +Cc: Sverre Rabbelier, Kyle Neath, tom smitts, git
In-Reply-To: <CAP2yMaLCu6epGkFOEOsfPgmUodCiBYRePLtewEmny1Z3W5D=QA@mail.gmail.com>
On Sep 21, 2011, at 12:01, Scott Chacon wrote:
> Hey,
>
> On Wed, Sep 21, 2011 at 10:49 AM, Timothy Harper <timcharper@gmail.com> wrote:
>> Ever since installing OS X Lion and Xcode 4.1 it seems I have lost the ability to build targeting Leopard (see /Developer/SDKs/), and haven't looked in to a work around. I have only built packages targeting the Snow Leopard.
>>
>> I see two possible resolutions:
>>
>> A) Tag builds as 32-bit and 64-bit. At git-scm.com (and github), link to the list that only shows 32-bit builds. For 99.9% (pulled-out-of-butt) of people using the installer, this will be just fine. For people who care about 64 bit, if they are motivated they can build own or find it.
>>
>> B) Switch to universal architecture and cause everyone to suffer an addition 30% or so wait while downloading the installer.
>>
>> What do y'all vote for?
>
> I vote for Universal builds. I don't think anyone downloading a DMG
> will care between 6M and 9M - it's still smaller than most YouTube
> videos. Then I can just have people choose their OS version and
> auto-download whatever the latest build is.
Ok, consider it done :). Going forward I will release Universal 32-bit / 64-bit.
>
> Also, fwiw, though this is the first you may have heard about it, I've
> personally had probably 5 or 6 people approach me at conferences and
> trainings and complain about it - or email me as the maintainer of the
> git-scm page to complain. I probably should have brought it up
> sooner, but I've just been so happy you've been doing the builds at
> all, I didn't want to complain :)
>
> Scott
Tim
^ permalink raw reply
* Re: mac osx
From: Scott Chacon @ 2011-09-21 18:01 UTC (permalink / raw)
To: Timothy Harper; +Cc: Sverre Rabbelier, Kyle Neath, tom smitts, git
In-Reply-To: <3509B3CD-8E7E-4097-B7F1-F092E5CF08F5@gmail.com>
Hey,
On Wed, Sep 21, 2011 at 10:49 AM, Timothy Harper <timcharper@gmail.com> wrote:
> Ever since installing OS X Lion and Xcode 4.1 it seems I have lost the ability to build targeting Leopard (see /Developer/SDKs/), and haven't looked in to a work around. I have only built packages targeting the Snow Leopard.
>
> I see two possible resolutions:
>
> A) Tag builds as 32-bit and 64-bit. At git-scm.com (and github), link to the list that only shows 32-bit builds. For 99.9% (pulled-out-of-butt) of people using the installer, this will be just fine. For people who care about 64 bit, if they are motivated they can build own or find it.
>
> B) Switch to universal architecture and cause everyone to suffer an addition 30% or so wait while downloading the installer.
>
> What do y'all vote for?
I vote for Universal builds. I don't think anyone downloading a DMG
will care between 6M and 9M - it's still smaller than most YouTube
videos. Then I can just have people choose their OS version and
auto-download whatever the latest build is.
Also, fwiw, though this is the first you may have heard about it, I've
personally had probably 5 or 6 people approach me at conferences and
trainings and complain about it - or email me as the maintainer of the
git-scm page to complain. I probably should have brought it up
sooner, but I've just been so happy you've been doing the builds at
all, I didn't want to complain :)
Scott
^ permalink raw reply
* Re: mac osx
From: Timothy Harper @ 2011-09-21 17:49 UTC (permalink / raw)
To: Scott Chacon; +Cc: Sverre Rabbelier, Kyle Neath, tom smitts, git
In-Reply-To: <CAP2yMaJz3-iX11vhbrTVasFD1zdwsdiDFKU7z7=an8pBoORk8w@mail.gmail.com>
On Sep 21, 2011, at 09:58, Scott Chacon wrote:
> 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.
At one point, I had a universal binary release (both 32 and 64 bit instructions compiled). The trouble with it was it increased the file size by an additional 3-4 MB (going off memory). So I decided to only release 32 bit versions since they run everywhere, and only a very small fraction of people would care about 64 bit. Later, I had some requests for 64 bit, so I decided to do two separate builds, satisfying those who care about 64 bit while keeping the download size smaller. In almost a year of doing things this way, this is the first complaint I had about 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.
I'm willing to concede your point.
>> 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.
Ever since installing OS X Lion and Xcode 4.1 it seems I have lost the ability to build targeting Leopard (see /Developer/SDKs/), and haven't looked in to a work around. I have only built packages targeting the Snow Leopard.
I see two possible resolutions:
A) Tag builds as 32-bit and 64-bit. At git-scm.com (and github), link to the list that only shows 32-bit builds. For 99.9% (pulled-out-of-butt) of people using the installer, this will be just fine. For people who care about 64 bit, if they are motivated they can build own or find it.
B) Switch to universal architecture and cause everyone to suffer an addition 30% or so wait while downloading the installer.
What do y'all vote for?
Tim
^ permalink raw reply
* Re: [PATCH] abspath: increase array size of cwd variable to PATH_MAX
From: Ramsay Jones @ 2011-09-20 22:57 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Wang Hui, git
In-Reply-To: <7v8vpkbhyv.fsf@alter.siamese.dyndns.org>
Junio C Hamano wrote:
> Wang Hui <Hui.Wang@windriver.com> writes:
>
>> diff --git a/abspath.c b/abspath.c
>> index f04ac18..2ce1db9 100644
>> --- a/abspath.c
>> +++ b/abspath.c
>> @@ -24,7 +24,7 @@ int is_directory(const char *path)
>> const char *real_path(const char *path)
>> {
>> static char bufs[2][PATH_MAX + 1], *buf = bufs[0], *next_buf = bufs[1];
>> - char cwd[1024] = "";
>> + char cwd[PATH_MAX] = "";
>
> Thanks.
>
> This does not make things worse but in the longer term we should move away
> from using PATH_MAX in general.
Hmm, the subject line says "... increase array size ...", but that is not
necessarily what this patch is doing! :-D
Yes, on some platforms PATH_MAX will be larger than 1024 (e.g. 4096 on Linux),
but that is not even true of all POSIX systems. POSIX defines the *minimum*
value of PATH_MAX that systems must support (as #define _POSIX_PATH_MAX) of 255.
[it also requires that POSIX conforming applications must not *require* a value
larger than 255].
However, we don't have to look too far to find systems with much smaller values.
On Cygwin, for example:
$ cat -n junk.c
1 #include <stdio.h>
2 #include <limits.h>
3
4 int main(int argc, char *argv[])
5 {
6 printf("PATH_MAX is %d\n", PATH_MAX);
7 return 0;
8 }
$ gcc -o junk junk.c
$ ./junk
$ PATH_MAX is 260
$
On MinGW the answer is 259.
So, I certainly agree that moving away from PATH_MAX is a good idea, but I'm
not sure I agree that this patch "does not make things worse" ... (I haven't
given it *any* thought!).
[Also, note commits f66cf96, fd55a19, 620e2bb, etc...]
ATB,
Ramsay Jones
^ permalink raw reply
* Re: mac osx
From: Stephen Bash @ 2011-09-21 15:42 UTC (permalink / raw)
To: Scott Chacon
Cc: Sverre Rabbelier, Kyle Neath, tom smitts, git, Timothy Harper
In-Reply-To: <CAP2yMaJz3-iX11vhbrTVasFD1zdwsdiDFKU7z7=an8pBoORk8w@mail.gmail.com>
----- Original Message -----
> From: "Scott Chacon" <schacon@gmail.com>
> Sent: Wednesday, September 21, 2011 10:58:03 AM
> Subject: Re: mac osx
>
> 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.
Perhaps I can shed some light on the subject... (Long time Mac user and developer of software that has to deal with these sorts of issues all the time)
Starting with the hardware: Apple announced the switch to Intel processors in 2005, with the first machines shipping in early 2006 with the Intel Core Duo (i386/32-bit) processors. In August of 2006 they introduced a Xeon-based Mac Pro that used the x86_64/64-bit instruction set. According to Wikipedia [1] by August of 2007 every Mac shipped was based on an x86_64 chip.
Now Apple confused things with the software: Mac OS 10.5 (Leopard) introduced the ability to run 64-bit applications (and access more the 4GB of memory), but the kernel was still 32-bit (I've skimmed some articles about how they did this, but I don't remember the details now). According to this article [2] it wasn't until OS 10.6.4 (Snow Leopard) that Apple actually made the boot default to the 64-bit kernel (but I have first hand experience with commercial software that changes the default back to 32-bit!).
And during all this users were never educated about the difference because many (most?) applications built for Mac ship "universal binaries" with multiple architectures linked into the same file (though there are still a lot that just ship 32-bit). I don't know how much effort it would be to update the Git Makefile for universal builds on Macs (sometimes it's as easy as "-arch i386 -arch x86_64"), but that might be the most "Mac-like" way to go.
For the geeks in the audience if you really want to know:
a) the instruction sets linked in a binary (executable or shared library):
$ file /path/to/binary/of/interest
b) the currently booted kernel architecture:
$ uname -m
c) the currently running architecture set of any application:
Activity Monitor lists in the column "kind": PowerPC, Intel, or Intel (64-bit)
[1] http://en.wikipedia.org/wiki/Apple%E2%80%93Intel_transition
[2] http://macperformanceguide.com/SnowLeopard-64bit.html
HTH,
Stephen
^ permalink raw reply
* Re: mac osx
From: Sverre Rabbelier @ 2011-09-21 15:41 UTC (permalink / raw)
To: Scott Chacon; +Cc: Timothy Harper, Kyle Neath, tom smitts, git
In-Reply-To: <CAP2yMaJz3-iX11vhbrTVasFD1zdwsdiDFKU7z7=an8pBoORk8w@mail.gmail.com>
Heya,
On Wed, Sep 21, 2011 at 16:58, Scott Chacon <schacon@gmail.com> wrote:
> I link to the featured downloads from git-scm.com front page as the
> huge mac icon
You currently link to:
http://code.google.com/p/git-osx-installer/downloads/list?can=3
Which apparently shows all downloads that were at some point featured.
If you link instead to:
http://code.google.com/p/git-osx-installer/downloads/list?q=label:Featured
The list is a lot shorter.
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* 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
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