* Re: gitweb tags feed, Re: New version announcements?
From: Jakub Narebski @ 2008-07-24 15:54 UTC (permalink / raw)
To: Julian Phillips; +Cc: Petr Baudis, Jordi Bunster, git, gitster
In-Reply-To: <Pine.LNX.4.64.0807241600190.7093@reaper.quantumfyre.co.uk>
Julian Phillips <julian@quantumfyre.co.uk> writes:
> On Thu, 24 Jul 2008, Petr Baudis wrote:
>> On Thu, Jul 24, 2008 at 10:38:24AM -0400, Jordi Bunster wrote:
>>>
>>> I've been following the git mailing list to stay on top of new releases,
>>> but the traffic got too high.
>>>
>>> Any way that a git-announce list could be created for security fixes and
>>> new releases? Or maybe an RSS feed on the website?
>
> An RSS feed already exists, have a look at http://gitrss.q42.co.uk/.
>
>>> If there's a news file or some-such, I'd be glad to write the code to
>>> convert it to a subscription feed.
> There was a request for RSS feeds some time ago, and I setup the above
> feeds which automatically process the git mailing list traffic -
> haven't bothered to actually monitor if anyone is using them though ;)
If I didn't thank you for this web service (http://gitrss.q42.co.uk/)
thanks, if I did thank yoy, thanks again :-)
I have used this service (to be more exact one of feeds offered by
this service, which basically is very filtered git mailing list feed)
as a source of "News" section for Git project at Ohloh[1]:
http://www.ohloh.net/projects/git
[1] http://www.ohloh.net/projects/git/rss_subscriptions uses
http://gitrss.q42.co.uk/announce.rss)
--
Jakub Narebski
Poland
ShadeHawk on #git
^ permalink raw reply
* Re: [PATCH 6/9] builtin-init-db.c: use parse_options()
From: Olivier Marin @ 2008-07-24 16:15 UTC (permalink / raw)
To: Michele Ballabio; +Cc: git, gitster
In-Reply-To: <1216849332-26813-7-git-send-email-barra_cuda@katamail.com>
Michele Ballabio a écrit :
>
> + const struct option options[] = {
> + OPT_STRING(0, "template", &template_dir, "dir",
> + "directory from which templates will be used"),
Perhaps "path", "path to the template repository" to stay consistent with clone.
> + OPT_BOOLEAN(0, "bare", &bare, "set up a bare repo"),
s/set up/setup/ and s/repo/repository/?
> + { OPTION_CALLBACK, 0, "shared", &shared_repository,
> + "type", "type of shared repository",
What about "permissions", "setup a shared repository"?
> + PARSE_OPT_OPTARG, parse_opt_shared_cb, PERM_GROUP },
Are you sure the default value is really used here?
Also, perhaps we can play it safer by avoiding changing "share_repository"
directly.
$ git init -> shared_repository == PERM_UMASK
$ git init --shared --no-shared -> shared_repository == 0
It works because PERM_UMASK == 0, but it is a side effect. Don't you think?
> + OPT_BIT('q', "quiet", &flags, "be quiet", INIT_DB_QUIET),
OPT__QUIET(&quiet),
if (quiet)
flags |= INIT_DB_QUIET;
to use the same quiet option everywhere?
Just my opinion,
Olivier.
^ permalink raw reply
* Re: [RFC PATCH 00/12] Sparse checkout
From: Avery Pennarun @ 2008-07-24 16:22 UTC (permalink / raw)
To: Nguyen Thai Ngoc Duy; +Cc: Johannes Schindelin, git
In-Reply-To: <fcaeb9bf0807240650v6eab6ad4n63c39973b3b43658@mail.gmail.com>
On 7/24/08, Nguyen Thai Ngoc Duy <pclouds@gmail.com> wrote:
> OK. I am lost here. I do not know how putting sparse prefix and index
> together could fix "it" (I think you meant the index guarding).
I think what Dscho is saying is simply that it's natural to put
information about the currently-checked-out tree in the index, and
unnatural to put it in the config.
If I switch branches, or checkout different versions, or git add, or
git rm, it all affects the index, never the config. The index stores
the attributes of which files are checked out, and can detect whether
those files are different from before. Choosing which subtrees to
check out sounds a lot more like one of those operations than it does
like a configuration change.
Also, I don't know if git supports this right now, but I can imagine
situations where you'd want to have more than one index (and
associated working trees) sharing the exact same .git folder. It
would be fine to share the config between these parallel checkouts,
but you certainly couldn't share the index. And you probably wouldn't
want to check out exactly the same set of subtrees in every working
tree.
The information required to do a checkout is in the index. And
"sparse checkout" is all about checking out :)
Have fun,
Avery
^ permalink raw reply
* Re: Submodules: Publishing a locally created submodule.
From: Sean Estabrooks @ 2008-07-24 16:21 UTC (permalink / raw)
To: Thomas Adam; +Cc: git mailing list
In-Reply-To: <18071eea0807240840g79da962ci8fbc65546d496323@mail.gmail.com>
On Thu, 24 Jul 2008 16:40:43 +0100
"Thomas Adam" <thomas.adam22@gmail.com> wrote:
> Now: I want to make mysubmoduleB a submodule which I can publish to
> the shared repository and when others pull, to see that submodule and
> be able to treat it as such.
Hi Thomas,
Submodules are very much fully formed independent repositories. So the
first step is to create a new Git repo that holds the files you want. Publish
this repo in a public place, presumably the same place you published your
other submodules.
In your supermodule use "git submodule add" to include the new public repo
as a submodule in the directory of your choice. After which you can commit
the change and push it out. Other people will need to do "git submodule update"
to make their repos aware of the new submodule.
HTH,
Sean
^ permalink raw reply
* Re: git-svn does not seems to work with crlf convertion enabled.
From: Avery Pennarun @ 2008-07-24 16:28 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Dmitry Potapov, Alexander Litvinov, git
In-Reply-To: <alpine.DEB.1.00.0807241539400.8986@racer>
On 7/24/08, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> On Thu, 24 Jul 2008, Dmitry Potapov wrote:
> > Practically all Windows editors do not have problems to open and edit
> > files with LF endings, but some of them will write back using CRLF.
>
> 95.23% of all statistics are made up on the spot. I would be surprised if
> that was not the case here.
Without assigning a specific number, Dmitry's experience matches mine.
I haven't seen an editor that can't *read* LF since notepad. But
many of them happily mangle the files.
Of course, notepad is probably at least 50% of the editors most
Windows users actually use, on a per-transaction basis.
Have fun,
Avery
^ permalink raw reply
* Re: [RFC PATCH 00/12] Sparse checkout
From: Johannes Schindelin @ 2008-07-24 16:38 UTC (permalink / raw)
To: Avery Pennarun; +Cc: Nguyen Thai Ngoc Duy, git
In-Reply-To: <32541b130807240922r733dce6aw8b123bbb28c9002@mail.gmail.com>
Hi,
On Thu, 24 Jul 2008, Avery Pennarun wrote:
> [a nice summary about why the index should know the sparse checkout
> prefix]
Thanks.
> Also, I don't know if git supports this right now, but I can imagine
> situations where you'd want to have more than one index (and
> associated working trees) sharing the exact same .git folder.
It is. And I already mentioned it. Note that it can make sense to work
on an index only, without ever touching a working directory.
For example, I do that a lot when importing projects that use
"tarball+patches" for version control.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] Respect crlf attribute in "git add" even if core.autocrlf has not been set
From: Avery Pennarun @ 2008-07-24 16:44 UTC (permalink / raw)
To: Steffen Prohaska
Cc: Johannes Schindelin, Dmitry Potapov, Junio C Hamano,
Git Mailing List
In-Reply-To: <465DE5CD-DA13-42B4-B0D8-961F3D118F59@zib.de>
On 7/24/08, Steffen Prohaska <prohaska@zib.de> wrote:
> Why is it unset? Since 1.5.5, our installer sets core.autocrlf=true
> on Windows. So we *do* set a sane default for Windows users.
Well, if you've been following the thread, not everyone uses msysGit,
and cygwin Git doesn't set autocrlf by default, and changing such
things behind people's backs can be really nasty.
So I can't decide if I mean the following as a joke or not ;)
diff --git a/builtin-init-db.c b/builtin-init-db.c
index 38b4fcb..91b79dd 100644
--- a/builtin-init-db.c
+++ b/builtin-init-db.c
@@ -314,10 +314,19 @@ int init_db(const char *template_dir, unsigned int flags)
}
if (!(flags & INIT_DB_QUIET))
+ {
printf("%s%s Git repository in %s/\n",
reinit ? "Reinitialized existing" : "Initialized empty",
shared_repository ? " shared" : "",
get_git_dir());
+#ifdef _WIN32
+ if (!auto_crlf)
+ printf("WARNING: You're using Windows but core.autocrlf is not set!\n");
+#else
+ if (auto_crlf)
+ printf("WARNING: You're not using Windows but core.autocrlf is set!\n");
+#endif
+ }
return 0;
}
^ permalink raw reply related
* Re: [PATCH] Respect crlf attribute in "git add" even if core.autocrlf has not been set
From: Johannes Schindelin @ 2008-07-24 16:45 UTC (permalink / raw)
To: Steffen Prohaska; +Cc: Dmitry Potapov, Junio C Hamano, Git Mailing List
In-Reply-To: <465DE5CD-DA13-42B4-B0D8-961F3D118F59@zib.de>
Hi,
On Thu, 24 Jul 2008, Steffen Prohaska wrote:
> On Jul 24, 2008, at 4:38 PM, Johannes Schindelin wrote:
>
> >On Thu, 24 Jul 2008, Dmitry Potapov wrote:
> >
> > >On Thu, Jul 24, 2008 at 08:06:29AM +0200, Steffen Prohaska wrote:
> > > >
> > > > I am the maintainer of this project. I know that this project
> > > > needs crlf conversion, because it is a cross-platform project.
> > > > Therefore, I want to force crlf conversion for this specific
> > > > project, even if the user did not configure core.autocrlf=input on
> > > > Unix.
> > >
> > >I suspect that most problems with crlf is caused by Windows users who
> > >have core.autocrlf=false for whatever reason (I suspect without a
> > >good reason in most cases).
> >
> >Almost correct. It is _unset_! And it should be perfectly valid for
> >users not having to set anything there.
>
> Why is it unset? Since 1.5.5, our installer sets core.autocrlf=true
> on Windows. So we *do* set a sane default for Windows users.
As I mentioned earlier, these users use Cygwin's Git. And they do not
update frequently.
> In the projects I am using git, the problematic platform is *Unix*. To
> work around the default on Unix (core.autocrlf=false), I deliver a
> custom script to our developers that verifies the setup on Unix and
> complains if core.autocrlf is not set to "input". Since I do this, I
> haven't seen any further problems.
That is exactly the use case I had in mind for my patch. If we already
bother to mark the files with crlf=input in .gitattributes, then Git could
be so nice to respect it.
However, I see Junio's point: on sane platforms you have to work hard to
get CR-damaged files. And the regular sane platform user should not be
punished for the brain/CR damage a certain monopolist has brought over
this planet.
Ciao,
Dscho
^ permalink raw reply
* git svn throws locale related error when built from source
From: Anton Mostovoy @ 2008-07-24 16:49 UTC (permalink / raw)
To: git
Hi
I built git 1.5.6.3 manually (no package with 1.5.4+ on gutsy), and I am
getting the error below when running 'git svn rebase'.
svn works fine on its own though.
The default locale is set to en_US.UTF-8
svn: error: cannot set LC_ALL locale
svn: error: environment variable LANG is en_US.UTF-8
svn: error: please check that your locale name is correct
I found a workaround that works, but it would be nice to have it work
properly.
$> LANG= git svn rebase"
Thanks in advance.
-Anton
P.s. I am sending this again, because I did not find the message on
http://dir.gmane.org/gmane.comp.version-control.git
^ permalink raw reply
* Re: gitweb tags feed, Re: New version announcements?
From: Pedro Melo @ 2008-07-24 16:51 UTC (permalink / raw)
To: Julian Phillips; +Cc: Petr Baudis, Jordi Bunster, git, gitster
In-Reply-To: <Pine.LNX.4.64.0807241600190.7093@reaper.quantumfyre.co.uk>
Hi,
On Jul 24, 2008, at 4:04 PM, Julian Phillips wrote:
>> On Thu, Jul 24, 2008 at 10:38:24AM -0400, Jordi Bunster wrote:
>>>
>>> Any way that a git-announce list could be created for security
>>> fixes and
>>> new releases? Or maybe an RSS feed on the website?
>
> An RSS feed already exists, have a look at http://gitrss.q42.co.uk/.
Thanks Julian, did not knew these feeds.
You might want to look at the script that generates the announces
feed. It missed the 1.5.6.4 announcement.
http://article.gmane.org/gmane.comp.version-control.git/89148/
match=1.5.6.4
Best regards,
--
Pedro Melo
Blog: http://www.simplicidade.org/notes/
XMPP ID: melo@simplicidade.org
Use XMPP!
^ permalink raw reply
* Re: [PATCH] Respect crlf attribute even if core.autocrlf has not been set
From: Dmitry Potapov @ 2008-07-24 16:53 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Johannes Schindelin, git
In-Reply-To: <7vej5kfs0w.fsf@gitster.siamese.dyndns.org>
On Wed, Jul 23, 2008 at 10:07:43AM -0700, Junio C Hamano wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>
> > However, if you want to avoid CRs to _enter_ the repository, when you have
> > a lot of binary files tracked, you _do_ want to force all repositories to
> > crlf=input.
>
> If you are on a sane system, you do not even want to pay the price of
> conversion.
If you do not have CRLF then there will be no conversion, so you pay only
the price of check. The relative cost of that check obviously depends on
what other operations are. I believe that the worst case for this check
will be when there is no other operations, just re-reading files, so I
did:
# touch all files to force git re-read them...
git ls-files | xargs touch
time git status
Here is the average based on 3 attempts:
0.232s with autocrlf=false
0.265s with autocrlf=input (14% increase)
Of course, without touching files, git-status will take the same time in
both cases (about 0.026s in my testing), and touching all files not very
interesting from the practical point of view.
So, I decided to do something more practical, like applying 100 patches.
Here are my results:
false input
------ -------
7.409s 7.603s
7.592s 7.239s
7.617s 7.402s
------ -------
Average: 7.539s 7.415s
autocrlf=input turned out to be even slightly faster, but the difference
is not statistically significant.
So, though it is obvious that autocrlf=input clearly adds some overhead,
I believe it is negligable in most practical cases as there are much
more expensive operations. And you can always turn autocrlf off, if you
are sure that you never have files with the wrong line ending.
> Only people on systems with CRLF line endings should pay the
> price (because your aim is to convert on such systems).
Unfortunately, it is not so clearly cut. Some people may work on Unix
but share files with Windows using network shares or emails.
> Are we throwing
> that out of the window when the project decides to use gitattributes?
I am not sure that I understand your question. In any case, Dscho's
patch did not change the default, so it did not penalize anyone except
explicitly asked about that by setting crlf on some files. I would like
also to notice that setting crlf on some files (in contrast to unsetting
it!) is rarely necessary in practice if all users have sane settings for
autocrlf.
>
> How about setting autocrlf automatically on mingw/msys/cygwin versions,
> perhaps via templates or a patch to init-db? Would that, combined with
> user education, be a viable alternative?
Perhaps, it is good compromise for now, considering that Windows users
have most troubles with that... I really don't mind seeing 'input' as
default on other platforms, but I won't insist on that.
Dmitry
^ permalink raw reply
* Re: [PATCH v2] t6030 (bisect): work around Mac OS X "ls"
From: Mike Hommey @ 2008-07-24 16:54 UTC (permalink / raw)
To: Jonathan Nieder; +Cc: Christian Couder, git
In-Reply-To: <Pine.GSO.4.62.0807240233310.27074@harper.uchicago.edu>
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset=utf-8, Size: 878 bytes --]
On Thu, Jul 24, 2008 at 02:43:51AM -0500, Jonathan Nieder wrote:
> t6030-bisect-porcelain.sh relies on "ls" exiting with nonzero
> status when asked to list nonexistent files. Unfortunately,
> /bin/ls on Mac OS X 10.3 exits with exit code 0. So look at
> its output instead.
>
> Signed-off-by: Jonathan Nieder <jrnieder@uchicago.edu>
> ---
>
> Mike Hommey wrote:
>
> > On Thu, Jul 24, 2008 at 07:57:26AM +0200, Christian Couder wrote:
> >> Le jeudi 24 juillet 2008, Jonathan Nieder a écrit :
> >>> - test_must_fail ls .git/BISECT_* &&
> >>> + echo .git/BISECT_* | test_must_fail grep BISECT_[^*] &&
> >>
> >> Perhaps the following is simpler:
> >>
> >> + test -z "$(ls .git/BISECT_*)" &&
> >
> > That is still a useless use of ls ;)
>
> It is much better than what I wrote, at least.
But could also be written with echo instead of ls.
Mike
^ permalink raw reply
* Re: git status in clean working dir
From: Jeff King @ 2008-07-24 16:54 UTC (permalink / raw)
To: Ask Bjørn Hansen; +Cc: Junio C Hamano, git, David Bremner
In-Reply-To: <D42305E3-82DA-46C1-B55F-74AD9AD48197@develooper.com>
On Wed, Jul 23, 2008 at 11:56:48PM -0700, Ask Bjørn Hansen wrote:
>> (2) Then why are we even allowing to configure the plumbing to page?
>
> I don't have an opinion on the the appropriateness of paging various
> commands, but to solve the problem of scripts getting tripped up by the
> paging, couldn't the plumping check if STDOUT is a tty and only do the
> paging if so?
>
> (In Perl "page_output(...) if $pager_configured and -t STDOUT")
We already do this, so "git status >/dev/null" produces the correct exit
code. But scripts don't necessarily redirect stdout.
-Peff
^ permalink raw reply
* [PATCH v2] document that git-tag can tag more than heads
From: Jonathan Nieder @ 2008-07-24 16:55 UTC (permalink / raw)
To: Kalle Olavi Niemitalo; +Cc: git
In-Reply-To: <87prp3652z.fsf@Astalo.kon.iki.fi>
After looking the git-tag manpage, someone on #git wondered how
to tag a commit that is not a branch head. This patch changes
the synopsis to say "<commit> | <object>" instead of "<head>" to
address his question.
Samuel Bronson had the idea of putting "<commit> | <object>"
for "<object>" because most tags point to commits (and for the
rest of the manpage, all tags point to commits).
Signed-off-by: Jonathan Nieder <jrnieder@uchicago.edu>
---
Kalle Olavi Niemitalo wrote:
> git-tag does not automatically dereference tag objects that
> point to a commit. So if you want to use "|", then it should be
> "<commit> | <object>".
Nice catch -- thanks.
Documentation/git-tag.txt | 3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/Documentation/git-tag.txt b/Documentation/git-tag.txt
index b8dc88f..046ab35 100644
--- a/Documentation/git-tag.txt
+++ b/Documentation/git-tag.txt
@@ -9,7 +9,8 @@ git-tag - Create, list, delete or verify a tag object signed with GPG
SYNOPSIS
--------
[verse]
-'git tag' [-a | -s | -u <key-id>] [-f] [-m <msg> | -F <file>] <name> [<head>]
+'git tag' [-a | -s | -u <key-id>] [-f] [-m <msg> | -F <file>]
+ <name> [<commit> | <object>]
'git tag' -d <name>...
'git tag' [-n[<num>]] -l [<pattern>]
'git tag' -v <name>...
--
1.5.6.3.549.g8ca11
^ permalink raw reply related
* Re: [PATCH 1/9] builtin-verify-tag.c: use parse_options()
From: Olivier Marin @ 2008-07-24 16:59 UTC (permalink / raw)
To: Michele Ballabio; +Cc: git, gitster
In-Reply-To: <1216849332-26813-2-git-send-email-barra_cuda@katamail.com>
Michele Ballabio a écrit :
>
> if (argc == 1)
> - usage(builtin_verify_tag_usage);
> + usage_with_options(builtin_verify_tag_usage, options);
It seems this is broken since the C rewrite: "git verify-tag -v" just do
nothing instead of printing usage message.
Moving the if() after parse_options() call with s/argc == 1/argc == 0/
should do the trick.
> - if (!strcmp(argv[i], "-v") || !strcmp(argv[i], "--verbose")) {
> - verbose = 1;
> - i++;
> - }
> + argc = parse_options(argc, argv, options, builtin_verify_tag_usage, 0);
Olivier.
^ permalink raw reply
* Re: [PATCH] Respect crlf attribute in "git add" even if core.autocrlf has not been set
From: Dmitry Potapov @ 2008-07-24 17:05 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Steffen Prohaska, Junio C Hamano, Git Mailing List
In-Reply-To: <alpine.DEB.1.00.0807241334340.8986@racer>
On Thu, Jul 24, 2008 at 01:39:34PM +0100, Johannes Schindelin wrote:
>
> Well, seems I will just continue shouting "why did you commit that
> CR-ridden file?" and get shouted back with "why does this §&%&%&!° Git
> tool not fix it for me automatically? Even _Subversion_ can do it."
Actually, no... With Subversion, if you do not have correct auto-props
then every newly added file will have incorrect end-of-lines. So, each
user has to manually add all possible text extensions in the auto-props
section of his/her subversion config file. In practice, it means that
with SVN you have far less problems with EOLs in first few days when
users just existing files, but then the problem reemerge every time when
someone adds a new file... So, it is not much better...
In constrast, Git provides automatic text detection and EOL conversion,
but it is not enabled where it should... at least, on Windows, and for
those who copies file directly from Windows through network shares or by
other means.
Dmitry
^ permalink raw reply
* Re: [PATCH 6/9] builtin-init-db.c: use parse_options()
From: Johannes Schindelin @ 2008-07-24 17:07 UTC (permalink / raw)
To: Olivier Marin; +Cc: Michele Ballabio, git, gitster
In-Reply-To: <4888AAB2.5050007@free.fr>
Hi,
On Thu, 24 Jul 2008, Olivier Marin wrote:
> Michele Ballabio a ??rit :
>
> > + OPT_BOOLEAN(0, "bare", &bare, "set up a bare repo"),
>
> s/set up/setup/
No. "setup" is a noun.
> > + { OPTION_CALLBACK, 0, "shared", &shared_repository,
> > + "type", "type of shared repository",
>
> What about "permissions", "setup a shared repository"?
>
> > + PARSE_OPT_OPTARG, parse_opt_shared_cb, PERM_GROUP },
>
> Are you sure the default value is really used here?
>
> Also, perhaps we can play it safer by avoiding changing "share_repository"
> directly.
I do not see how that would be any safer.
> $ git init -> shared_repository == PERM_UMASK
> $ git init --shared --no-shared -> shared_repository == 0
>
> It works because PERM_UMASK == 0, but it is a side effect. Don't you think?
Then the callback is wrong, too. I think, however, that it is by design,
and correct.
We rely on shared_repository == 0 for non-shared repositories _almost
everywhere_.
> > + OPT_BIT('q', "quiet", &flags, "be quiet", INIT_DB_QUIET),
>
> OPT__QUIET(&quiet),
>
> if (quiet)
> flags |= INIT_DB_QUIET;
>
> to use the same quiet option everywhere?
Why? Doesn't make it more readable, I think. I'd rather have 3 lines
less.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH 1/9] builtin-verify-tag.c: use parse_options()
From: Johannes Schindelin @ 2008-07-24 17:08 UTC (permalink / raw)
To: Olivier Marin; +Cc: Michele Ballabio, git, gitster
In-Reply-To: <4888B4E3.9000504@free.fr>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 751 bytes --]
Hi,
On Thu, 24 Jul 2008, Olivier Marin wrote:
> Michele Ballabio a écrit :
> >
> > if (argc == 1)
> > - usage(builtin_verify_tag_usage);
> > + usage_with_options(builtin_verify_tag_usage, options);
>
> It seems this is broken since the C rewrite: "git verify-tag -v" just do
> nothing instead of printing usage message.
>
> Moving the if() after parse_options() call with s/argc == 1/argc == 0/
> should do the trick.
That would be a bugfix. As such, it belongs into a different commit.
Care to provide a patch?
> > - if (!strcmp(argv[i], "-v") || !strcmp(argv[i], "--verbose")) {
> > - verbose = 1;
> > - i++;
> > - }
> > + argc = parse_options(argc, argv, options, builtin_verify_tag_usage, 0);
Why did you quote this?
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] Respect crlf attribute even if core.autocrlf has not been set
From: Johannes Schindelin @ 2008-07-24 17:14 UTC (permalink / raw)
To: Dmitry Potapov; +Cc: Junio C Hamano, git
In-Reply-To: <20080724165335.GW2925@dpotapov.dyndns.org>
Hi,
On Thu, 24 Jul 2008, Dmitry Potapov wrote:
> If you do not have CRLF then there will be no conversion, so you pay
> only the price of check. The relative cost of that check obviously
> depends on what other operations are. I believe that the worst case for
> this check will be when there is no other operations, just re-reading
> files, so I did:
>
> # touch all files to force git re-read them...
> git ls-files | xargs touch
> time git status
>
> Here is the average based on 3 attempts:
> 0.232s with autocrlf=false
> 0.265s with autocrlf=input (14% increase)
And you tested... on git.git? One of the smallest serious Git users?
If you want to come close to the hard cases (that you would punish with
setting autocrlf = input, not yourself of course), test _at least_ the
Linux kernel.
To come closer you should test on OpenOffice.org or KDE.
Hth,
Dscho
^ permalink raw reply
* Re: [PATCH 01/12] git-grep: read config
From: Jeff King @ 2008-07-24 17:15 UTC (permalink / raw)
To: Nguyễn Thái Ngọc Duy; +Cc: git
In-Reply-To: <20080723145535.GA29053@laptop>
On Wed, Jul 23, 2008 at 09:55:35PM +0700, Nguyễn Thái Ngọc Duy wrote:
>
> Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
The commit message is a bit lacking...what config are we interested in?
-Peff
^ permalink raw reply
* Re: [PATCH 08/12] git-clone: support --path to do sparse clone
From: Jeff King @ 2008-07-24 17:19 UTC (permalink / raw)
To: Nguyễn Thái Ngọc Duy; +Cc: git
In-Reply-To: <20080723145718.GA29134@laptop>
On Wed, Jul 23, 2008 at 09:57:18PM +0700, Nguyễn Thái Ngọc Duy wrote:
> + if (option_sparse_prefix) {
> + git_config_set("core.sparsecheckout", option_sparse_prefix);
> + set_sparse_prefix(option_sparse_prefix);
> + }
> +
As a user, I would expect "sparse clone" to also be sparse on the
fetching. That is, to not even bother fetching tree objects that we are
not going to check out. But that is a whole other can of worms from
local sparseness, so I think it is worth saving for a different series.
So instead I would suggest that this be mentioned in the documentation
for --path, but there doesn't seem to be any.
-Peff
^ permalink raw reply
* Re: gitweb tags feed, Re: New version announcements?
From: Julian Phillips @ 2008-07-24 17:25 UTC (permalink / raw)
To: Pedro Melo; +Cc: Petr Baudis, Jordi Bunster, git, gitster
In-Reply-To: <B7201433-1725-4C3A-85D6-4C036635FD17@simplicidade.org>
On Thu, 24 Jul 2008, Pedro Melo wrote:
> Hi,
>
> On Jul 24, 2008, at 4:04 PM, Julian Phillips wrote:
>> > On Thu, Jul 24, 2008 at 10:38:24AM -0400, Jordi Bunster wrote:
>> > >
>> > > Any way that a git-announce list could be created for security fixes
>> > > and
>> > > new releases? Or maybe an RSS feed on the website?
>>
>> An RSS feed already exists, have a look at http://gitrss.q42.co.uk/.
>
> Thanks Julian, did not knew these feeds.
>
> You might want to look at the script that generates the announces feed. It
> missed the 1.5.6.4 announcement.
>
> http://article.gmane.org/gmane.comp.version-control.git/89148/match=1.5.6.4
Ah ... oops. Some stuff got broken during a system upgrade on the 20th,
and I seem to have missed that mail when trying to fill in the gap (due to
a similar breakage in my personal email system I didn't know it had gone
out :(). Hopefully that won't happen again.
Should be there now. Thanks. :)
--
Julian
---
The advertisement is the most truthful part of a newspaper.
-- Thomas Jefferson
^ permalink raw reply
* [PATCH] index-pack: correctly initialize appended objects
From: Johannes Schindelin @ 2008-07-24 17:32 UTC (permalink / raw)
To: Nicolas Pitre, spearce; +Cc: git, gitster
[-- Attachment #1: Type: TEXT/PLAIN, Size: 1259 bytes --]
From: Björn Steinbrink <B.Steinbrink@gmx.de>
When index-pack completes a thin pack it appends objects to the pack.
Since the commit 92392b4(index-pack: Honor core.deltaBaseCacheLimit when
resolving deltas) such an object can be pruned in case of memory
pressure.
To be able to re-read the object later, a few more fields have to be set.
Noticed by Pierre Habouzit.
Hopefully-signed-off-by: Björn Steinbrink <B.Steinbrink@gmx.de>
Hopefully-reviewed-and-signed-off-by: Nicolas Pitre <nico@cam.org>,
--
This was probably missed in the flurry of patches, scratched
patches, and new patches.
Nico could you have a quick look? (I would ask Shawn, but I know
that he is pretty busy with real world issues.)
diff --git a/index-pack.c b/index-pack.c
index ac20a46..33ba8ef 100644
--- a/index-pack.c
+++ b/index-pack.c
@@ -699,6 +699,9 @@ static struct object_entry *append_obj_to_pack(
write_or_die(output_fd, header, n);
obj[0].idx.crc32 = crc32(0, Z_NULL, 0);
obj[0].idx.crc32 = crc32(obj[0].idx.crc32, header, n);
+ obj[0].hdr_size = n;
+ obj[0].type = type;
+ obj[0].size = size;
obj[1].idx.offset = obj[0].idx.offset + n;
obj[1].idx.offset += write_compressed(output_fd, buf, size, &obj[0].idx.crc32);
hashcpy(obj->idx.sha1, sha1);
^ permalink raw reply related
* sparse fetch, was Re: [PATCH 08/12] git-clone: support --path to do sparse clone
From: Johannes Schindelin @ 2008-07-24 17:41 UTC (permalink / raw)
To: Jeff King; +Cc: Nguyễn Thái Ngọc Duy, git
In-Reply-To: <20080724171952.GB21043@sigill.intra.peff.net>
Hi,
On Thu, 24 Jul 2008, Jeff King wrote:
> As a user, I would expect "sparse clone" to also be sparse on the
> fetching. That is, to not even bother fetching tree objects that we are
> not going to check out. But that is a whole other can of worms from
> local sparseness, so I think it is worth saving for a different series.
I think this is not even worth of a series. Sure, it would have benefits
for those who want sparse checkouts. But it comes for a high price on
everyone else:
- security issues (you'd need to open the git protocol to give you
something else than a ref, _including_ refs that were deleted)
- performance issues (the server would have to do a lot more, faking
commits, or in the alternative serving a gazillion more sessions if the
client does the reconstruction)
... and I am sure there are tons more issues.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH v2] t6030 (bisect): work around Mac OS X "ls"
From: Johannes Schindelin @ 2008-07-24 17:44 UTC (permalink / raw)
To: Mike Hommey; +Cc: Jonathan Nieder, Christian Couder, git
In-Reply-To: <20080724165434.GA26660@glandium.org>
Hi,
On Thu, 24 Jul 2008, Mike Hommey wrote:
> On Thu, Jul 24, 2008 at 02:43:51AM -0500, Jonathan Nieder wrote:
>
> > Mike Hommey wrote:
> >
> > > On Thu, Jul 24, 2008 at 07:57:26AM +0200, Christian Couder wrote:
> > >
> > >> + test -z "$(ls .git/BISECT_*)" &&
> > >
> > > That is still a useless use of ls ;)
> >
> > It is much better than what I wrote, at least.
>
> But could also be written with echo instead of ls.
Sure, but then it looks uglier:
test ".git/BISECT_*" = "$(echo .git/BISECT_*)" &&
and it is much easier to hide a typo there.
And now the big question: is it performance critical? Or is obvious
correctness the highest goal here?
Hth,
Dscho
^ 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