* Re: [PATCH 0/3] git-mergetool/difftool: TortoiseMerge and (g)vimdiff for Windows
From: Johannes Schindelin @ 2009-04-05 13:52 UTC (permalink / raw)
To: Markus Heidelberg
Cc: Junio C Hamano, git, msysgit, David Aguilar, Charles Bailey
In-Reply-To: <200904051440.33154.markus.heidelberg@web.de>
Hi,
On Sun, 5 Apr 2009, Markus Heidelberg wrote:
> Patches 2/3 and 3/3 are already in 'da/difftool' in 'pu'. This series is
> based on 'master', now they can be applied to 4msysgit.git.
Thanks, they are in, as branch 'tortoisemerge'.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH 1/4] sha1-lookup: add new "sha1_pos" function to efficiently lookup sha1
From: Jeff King @ 2009-04-05 14:41 UTC (permalink / raw)
To: Sverre Rabbelier
Cc: Christian Couder, Junio C Hamano, git, Johannes Schindelin
In-Reply-To: <fabb9a1e0904050317o1399118erb15ddf86d0fe6c3c@mail.gmail.com>
On Sun, Apr 05, 2009 at 12:17:32PM +0200, Sverre Rabbelier wrote:
> On Sat, Apr 4, 2009 at 22:59, Christian Couder <chriscool@tuxfamily.org> wrote:
> > + if (lo <= mi && mi < hi)
> > + break;
> > + die("oops");
>
> That's going to be an official git error message? Why not make it "The
> fatal error oops has occured, press ctrl-c to lose all your work, or
> press any other key to do the same"?
From my cursory reading of the code, this is a "cannot happen"
assertion (and there is one a few lines below, too):
+ die("oops");
+ }
+ }
+ if (18 <= ofs)
+ die("cannot happen -- lo and hi are identical");
+ }
I don't think we have an established style for such assertions. In
theory, users never see it, but the whole point of it being there is
that they _might_. :) One could use the "assert" macro, though I think
its output is just as cryptic to end users. I usually do
die("BUG: <something that makes a little bit of sense to the user>");
some examples of which you can see via "git grep BUG:".
Of course, "binary search on fire?" would probably work, too.
-Peff
^ permalink raw reply
* Re: [PATCH 1/4] sha1-lookup: add new "sha1_pos" function to efficiently lookup sha1
From: Sverre Rabbelier @ 2009-04-05 14:42 UTC (permalink / raw)
To: Jeff King; +Cc: Christian Couder, Junio C Hamano, git, Johannes Schindelin
In-Reply-To: <20090405144111.GB2076@sigill.intra.peff.net>
Heya,
On Sun, Apr 5, 2009 at 16:41, Jeff King <peff@peff.net> wrote:
> some examples of which you can see via "git grep BUG:".
>
> Of course, "binary search on fire?" would probably work, too.
Right, I'm thinking anything that makes it easier to find out what
went wrong later on would be better than just "oops".
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* Re: [question] how can i verify whether a local branch is tracking a remote branch?
From: Jeff King @ 2009-04-05 14:44 UTC (permalink / raw)
To: Paolo Ciarrocchi; +Cc: git
In-Reply-To: <4d8e3fd30904050332w394cccbaq5b82d2a53ed357a3@mail.gmail.com>
On Sun, Apr 05, 2009 at 12:32:29PM +0200, Paolo Ciarrocchi wrote:
> is there a way to verify, using the UI, whether a local branch is
> tracking a remote branch?
Do you mean "whether it is tracking any branch", or "whether the branch
is is tracking is remote"?
If the former, then I think if one of branch.$branch.{merge,rebase}
is set, it is tracking something. The tracked thing is remote unless
branch.$branch.remote is ".".
-Peff
^ permalink raw reply
* Re: [PATCH 7/7] user-manual: simplify the user configuration
From: Jay Soffian @ 2009-04-05 15:11 UTC (permalink / raw)
To: Felipe Contreras; +Cc: git, Junio C Hamano
In-Reply-To: <94a0d4530904050214y256cc0d3icc1843cfd148d69d@mail.gmail.com>
On Sun, Apr 5, 2009 at 5:14 AM, Felipe Contreras
<felipe.contreras@gmail.com> wrote:
=> Ok, I forgot to explain this again the commit message of this
> particular patch, but it's described in the patch series description.
>
> The previous patch adds a 'Getting Started' section that explains
> exactly that; you can edit ~/.gitconfig.
>
> So that concern is already addressed.
Doh, sorry. Thanks for the explanation.
j.
^ permalink raw reply
* Re: error in rewriting author history with filter-branch --env-filter
From: Adam Mercer @ 2009-04-05 15:52 UTC (permalink / raw)
To: Mike Hommey; +Cc: GIT
In-Reply-To: <20090405072158.GA3881@glandium.org>
On Sun, Apr 5, 2009 at 02:21, Mike Hommey <mh@glandium.org> wrote:
> You need a white space between "ram" and ].
Thanks! I knew it would be something stupid!
Cheers
Adam
^ permalink raw reply
* Re: non-ascii filenames issue
From: Jay Soffian @ 2009-04-05 16:23 UTC (permalink / raw)
To: John Tapsell; +Cc: Teemu Likonen, git
In-Reply-To: <43d8ce650904050351p72590d52l8861b3901f95201a@mail.gmail.com>
On Sun, Apr 5, 2009 at 6:51 AM, John Tapsell <johnflux@gmail.com> wrote:
> Unfortunately not, because for some absolutely crazy reason
Bzzt. http://article.gmane.org/gmane.comp.version-control.git/50830
And, as always, patches welcomed.
j.
^ permalink raw reply
* [PATCH] bash completion: Update 'git am' options
From: Todd Zullinger @ 2009-04-05 16:33 UTC (permalink / raw)
To: git, Junio C Hamano, Shawn O. Pearce
This adds --committer-date-is-author-date, --ignore-date, and --no-utf8
options. The --binary option is removed, as it was made a no-op by
cb3a160. The option list is also sorted alphabetically.
---
contrib/completion/git-completion.bash | 3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash
index e72ce24..d3d8203 100755
--- a/contrib/completion/git-completion.bash
+++ b/contrib/completion/git-completion.bash
@@ -646,7 +646,8 @@ _git_am ()
;;
--*)
__gitcomp "
- --signoff --utf8 --binary --3way --interactive
+ --3way --committer-date-is-author-date --ignore-date
+ --interactive --keep --no-utf8 --signoff --utf8
--whitespace=
"
return
--
1.6.2.2
--
Todd OpenPGP -> KeyID: 0xBEAF0CE3 | URL: www.pobox.com/~tmz/pgp
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Formerly we suffered from crimes; now we suffer from laws.
-- Publius Cornelius Tacitus, Roman historian, AD 56 - c. 120
^ permalink raw reply related
* Re: [msysGit] [PATCH] mergetool-lib: make (g)vimdiff workable under Windows
From: Junio C Hamano @ 2009-04-05 18:41 UTC (permalink / raw)
To: markus.heidelberg
Cc: Johannes Schindelin, git, David Aguilar, Charles Bailey, msysgit
In-Reply-To: <200904051232.19939.markus.heidelberg@web.de>
Markus Heidelberg <markus.heidelberg@web.de> writes:
> Junio, is this something for maint? I'm not sure, since this problem
> only occurs on Windows and 'maint' isn't interesting for msysgit ATM.
I am not Dscho (nor J6t) but the last time I asked him about some other
"This makes it work better on Windows" patch, the conclusion was "only
Windows has issues and msysgit does not use 'maint'", which I agreed to be
a sensible answer for an undermanned and still-on bleeding edge project
like msysgit.
I don't mind a trivial backport for only mergetool part to the tip of
'master' (because difftool is not in master) that later makes me deal with
a small merge conflict when the refactoring topic hits master. Or Dscho
can apply such a backport and carry it as a msysgit-only patch until my
'master' is updated with the refactoring topic (at which point the
tentative patch needs to be dropped). Either would work fine with me.
^ permalink raw reply
* Re: [PATCH] Add custom memory allocator to MinGW and MacOS builds
From: Marius Storm-Olsen @ 2009-04-05 18:43 UTC (permalink / raw)
To: Johannes Sixt; +Cc: mstormo, msysgit, patthoyts, git
In-Reply-To: <200904040835.24377.j6t@kdbg.org>
Johannes Sixt said the following on 04.04.2009 08:35:
> On Samstag, 4. April 2009, Marius Storm-Olsen wrote:
>> Pat Thoyts said the following on 03.04.2009 23:12:
>>> The difference on Windows Vista is that the low fragmentation
>>> heap is the default memory allocator. On Windows XP you need to
>>> enable it specifically for an application. So a possible
>>> alternative to this is just to enable the low fragmentation
>>> heap. (done via GetProcessHeaps and HeapSetInformation Win32
>>> API calls).
>> I know about the low-fragmentation heap, but given that it was
>> only supported on XP and up (and given that I also had MacOSX in
>> mind when considering a custom allocator; see MacOSX got 12%
>> itself ;-), I didn't even consider it. Thanks for clearing up the
>> differences on the Vista and XP benchmarks though! Makes sense.
>
> Wouldn't a GetProcessHeaps/HeapSetInformation solution add much
> less code, even with a runtime check whether the feature is
> supported?
It certainly would, if you'd also like to simply ignore the extra
benefit to MacOSX, which was a not-so-bad additional 12%. However, I
and several of my colleagues also use Git on Mac and see that any
improvement in the performance there would also be welcome. So, I went
with the custom allocator approach, instead of just looking into XP.
There might also be other platforms which could benefit from such a
custom allocator, so I figured that there were many positive sides to
this, rather than just going for the Low Fragmentation Heap on Windows.
> The improvement that you observed is in a rather special area
> (repack). How is the improvment in day-to-day tools:
>
> - procelains used on command line: git-status, git-add, git-commit,
> git-diff, git-log, perhaps even local git-fetch.
>
> - plumbing used by guis: git-diff-files, git-diff-tree, git-log,
> git-rev-parse
>
> - I'm not even mentioning git-am, git-rebase, because here the time
> sink is the fork emulation.
>
> I doubt that the improvement is equally great, and it will perhaps
> vanish in the noise. 7000+ LOC is a bit much in this case, don't
> you think so?
I went with repack because it's a lot of data munging, and not so high
IO. Clearly more I/O intensive git operations would not benefit as
much as repack. But the goal in this patch was not to speed up I/O.
Obviously there are things that can be, and should be done for the I/O
side too, but that's a separate subject.
I don't see the 7000+ LOC as such a big deal, given that they are all
neatly tucked away in a compat subdirectory. They don't even add any
additional sourcecode to the codepaths, since you just link with it.
Given the benefits, even 5% better than the Low-Frag case for
single-threaded cases (which is the most dominant in git anyways), it
think it's reason enough to include it. The 12% boost on Mac should
also underline this.
Running 'git blame' on one of the files in my repos gives me this result:
XP
Without nedmalloc: 11.218sec
With nedmalloc : 9.514sec (18% speedup)
OSX
Without nedmalloc: 15.046sec
With nedmalloc : 13.957sec (8% speedup)
I'll take those speedups any day :-)
> BTW, I assume that the Boost license is compatible with GPL. But
> did you check that?
Of course I did, you'll find it under
http://www.fsf.org/licensing/licenses/index_html#GPLCompatibleLicenses
--
.marius
^ permalink raw reply
* Re: [PATCH 1/4] sha1-lookup: add new "sha1_pos" function to efficiently lookup sha1
From: Junio C Hamano @ 2009-04-05 18:59 UTC (permalink / raw)
To: Sverre Rabbelier; +Cc: Christian Couder, git, Johannes Schindelin
In-Reply-To: <fabb9a1e0904050317o1399118erb15ddf86d0fe6c3c@mail.gmail.com>
Sverre Rabbelier <srabbelier@gmail.com> writes:
> On Sat, Apr 4, 2009 at 22:59, Christian Couder <chriscool@tuxfamily.org> wrote:
>> + if (lo <= mi && mi < hi)
>> + break;
>> + die("oops");
>
> That's going to be an official git error message? Why not make it "The
It's not "going to be", but "has been so for the last two years since
5d23e13".
It is an assert, and I think Peff's die("BUG: ...") would be a good idea.
^ permalink raw reply
* Re: Performance issue: initial git clone causes massive repack
From: Nicolas Sebrecht @ 2009-04-05 19:02 UTC (permalink / raw)
To: Robin H. Johnson; +Cc: Git Mailing List
In-Reply-To: <20090405070412.GB869@curie-int>
On Sun, Apr 05, 2009 at 12:04:12AM -0700, Robin H. Johnson wrote:
> Before I answer the rest of your post, I'd like to note that the matter
> of which choice between single-repo, repo-per-package, repo-per-category
> has been flogged to death within Gentoo.
>
> I did not come to the Git mailing list to rehash those choices. I came
> here to find a solution to the performance problem.
I understand. I know two ways to resolve this:
- by resolving the performance problem itself,
- by changing the workflow to something more accurate and more suitable
against the facts.
My point is that going from a centralized to a decentralized SCM
involves breacking strongly how developers and maintainers work. What
you're currently suggesting is a way to work with Git in a centralized
way. This sucks. To get the things right with Git I would avoid shared
and global repositories. Gnome is doing it this way:
http://gitorious.org/projects/gnome-svn-hooks/repos/mainline/trees/master
> The GSoC 2009 ideas contain a potential project for caching the
> generated packs, which, while having value in itself, could be partially
> avoided by sending suitable pre-built packs (if they exist) without any
> repacking.
Right. It could be an option to wait and see if the GSoC gives
something.
> Also, I should note that working on the tree isn't the only reason to
> have the tree checked out. While the great majority of Gentoo users have
> their trees purely from rsync, there is nothing stopping you from using
> a tree from CVS (anonCVS for the users, master CVS server for the
> developers).
>
> A quick bit of stats run show that while some developers only touch a
> few packages, there are at least 200 developers that have done a major
> change to 100 or more packages.
That's a point that has to be reconsidered. Not the fact that at least
200 developers work on over 100 packages (this is really not an issue)¹
but the fact that they do that directly on the main repo/server. The
good way to achieve this is to send his work to the maintainer². The main
issue is a better code reviewing.
1. Some or all repo-per-category can be tracked with a simple script.
2. Maintainers could be - or not be - the same developers as today.
Adding a layer of maintainers in charge of EAPI review (for example) up
to the packages-maintainers could help in fixing a lot of portage issues
and would avoid "simple developers" to do crap on the main repo(s) that
users download.
> And per-package numbers, because we DID do an experimental conversion,
> last year, although the packs might not have been optimal:
> - ~410MiB of content (w/ 4kb inodes)
> - 4.7GiB of Git total overhead, with a breakdown:
> - 1.9GiB in inode waste
> - 2.8GiB in packs
Ok.
> > One repo per category could be a good compromise assuming one seperate
> > branch per package, then.
> Other downsides to repo-per-category and repo-per-package:
Let's forget a repo-per-package.
> - Raises difficulty in adding a new package/category.
> You cannot just do 'mkdir && vi ... && git add && git commit' anymore.
Right, but categories are not evolving that much.
> - The name of the directory for both of the category AND the package are not
> specified in the ebuild, as such, unless they are checked out to the right
> location, you will get breakage (definitely in the package name, and
> about 10% of the time with categories).
Of course. Quite franckly, it's recoverable without pain.
A repo-per-category local workflow would be:
$ git branch
master
* next
package_one
package_two
[...]
$ tree -a
|-- .git
| |-- [...]
| [...]
|-- package_one
| |-- ChangeLog
| |-- Manifest
| |-- metadata.xml
| |-- package_one-0.4.ebuild
| `-- package_one-0.5.ebuild
|-- package_two
| |-- ChangeLog
| |-- Manifest
| |-- files
| | |-- package_two.confd
| | `-- package_two.rc
| |-- metadata.xml
| `-- package_two-0.7-r3.ebuild
[...]
$ git checkout package_one
$ tree -a
|-- .git
| |-- [...]
| [...]
`-- package_one
|-- ChangeLog
|-- Manifest
|-- metadata.xml
|-- package_one-0.4.ebuild
`-- package_one-0.5.ebuild
$ <hack, hack, hack>
$ git checkout next
$ git merge package_one
> - Does NOT present a good base for anybody wanting to branch the entire
> tree themselves.
Scriptable.
> We're already on track to drop the CVS $Header$, and thereafter, some of the
> ebuilds are already on track to be smaller. Here's our prototype dev-perl/Sub-Name-0.04.
> ====
> # Copyright 1999-2009 Gentoo Foundation
> # Distributed under the terms of the GNU General Public License v2
> MODULE_AUTHOR=XMATH
> inherit perl-module
> DESCRIPTION="(re)name a sub"
> LICENSE="|| ( Artistic GPL-2 )"
> SLOT="0"
> KEYWORDS="~amd64 ~x86"
> IUSE=""
> SRC_TEST=do
> ====
>
> We can have all the CPAN packages from CPAN author XMATH, with changing
> only the DESCRIPTION string. KEYWORDS then just changes over the package
> lifespan.
Sounds good.
--
Nicolas Sebrecht
^ permalink raw reply
* Re: [RFC/PATCH 0/2] New 'stage' command
From: Junio C Hamano @ 2009-04-05 19:02 UTC (permalink / raw)
To: Felipe Contreras; +Cc: git
In-Reply-To: <1238939331-10152-1-git-send-email-felipe.contreras@gmail.com>
Felipe Contreras <felipe.contreras@gmail.com> writes:
> This is the list of actions I've mapped:
>
> * add: git stage = git stage add (git add)
> * rm: (git rm --cached)
> * diff: (git rm --cached)
> * import: stage all files; modified, deleted, new
> * ls: (git ls-files --stage)
I do not think these are good ideas at all, as it just spreads more
confusion, not less.
^ permalink raw reply
* Re: [PATCH] bash completion: Update 'git am' options
From: Junio C Hamano @ 2009-04-05 19:04 UTC (permalink / raw)
To: Todd Zullinger; +Cc: git, Shawn O. Pearce
In-Reply-To: <20090405163338.GA17135@inocybe.teonanacatl.org>
Thanks.
^ permalink raw reply
* Re: [PATCH 1/4] sha1-lookup: add new "sha1_pos" function to efficiently lookup sha1
From: Sverre Rabbelier @ 2009-04-05 19:06 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Christian Couder, git, Johannes Schindelin
In-Reply-To: <7vvdpjrkp0.fsf@gitster.siamese.dyndns.org>
Heya,
On Sun, Apr 5, 2009 at 20:59, Junio C Hamano <gitster@pobox.com> wrote:
> It's not "going to be", but "has been so for the last two years since
> 5d23e13".
Ah, I did not see that earlier, as I read and commented-on this patch
before reading 3/4.
> It is an assert, and I think Peff's die("BUG: ...") would be a good idea.
As long as the <something that makes sense to the user> does indeed
make sense, right :).
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* Re: Performance issue: initial git clone causes massive repack
From: Shawn O. Pearce @ 2009-04-05 19:17 UTC (permalink / raw)
To: Nicolas Sebrecht; +Cc: Robin H. Johnson, Git Mailing List
In-Reply-To: <20090405190213.GA12929@vidovic>
Nicolas Sebrecht <nicolas.s-dev@laposte.net> wrote:
> On Sun, Apr 05, 2009 at 12:04:12AM -0700, Robin H. Johnson wrote:
> > The GSoC 2009 ideas contain a potential project for caching the
> > generated packs, which, while having value in itself, could be partially
> > avoided by sending suitable pre-built packs (if they exist) without any
> > repacking.
>
> Right. It could be an option to wait and see if the GSoC gives
> something.
Another option is to use rsync:// for initial clones.
Tell new developers that their initial command sequence to
(efficiently) get the base tree is:
git clone rsync://git.gentoo.org/tree.git
cd tree
git config remote.origin.url git://git.gentoo.org/tree.git
rsync should be more efficient at dragging 1.6GiB over the network,
as its only streaming the files. But it may fall over if the server
has a lot of loose objects; many more small files to create.
One way around that would be to use two repositories on the server;
a historical repository that is fully packed and contains the full
history, and a bleeding edge repository that users would normally
work against:
git clone rsync://git.gentoo.org/fully-packed-tree.git tree
cd tree
git config remote.origin.url git://git.gentoo.org/tree.git
git pull
Then every so often (e.g. once a Gentoo release cycle, so once
a year) pull the bleeding edge repository into the fully packed
repository. That will introduce a single new pack file, so the
fully packed repository grows at a rate of 2 inodes/year, and is
still very efficient to rsync on initial clones.
That caching GSoC project may help, but didn't I see earlier in
this thread that you have >4.8 million objects in your repository?
Any proposals on that project would still have Git malloc()'ing
data per object; its ~80 bytes per object needed so that's a data
segment of 384+ MiB, per concurrent clone client.
--
Shawn.
^ permalink raw reply
* Re: [PATCH 1/4] sha1-lookup: add new "sha1_pos" function to efficiently lookup sha1
From: Felipe Contreras @ 2009-04-05 19:19 UTC (permalink / raw)
To: Junio C Hamano
Cc: Sverre Rabbelier, Christian Couder, git, Johannes Schindelin
In-Reply-To: <7vvdpjrkp0.fsf@gitster.siamese.dyndns.org>
On Sun, Apr 5, 2009 at 9:59 PM, Junio C Hamano <gitster@pobox.com> wrote:
> U3ZlcnJlIFJhYmJlbGllciA8c3JhYmJlbGllckBnbWFpbC5jb20+IHdyaXRlczoNCg0KPiBPbiBT
> YXQsIEFwciA0LCAyMDA5IGF0IDIyOjU5LCBDaHJpc3RpYW4gQ291ZGVyIDxjaHJpc2Nvb2xAdHV4
> ZmFtaWx5Lm9yZz4gd3JvdGU6DQo+PiArIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg
> IMKgIMKgIMKgIMKgIGlmIChsbyA8PSBtaSAmJiBtaSA8IGhpKQ0KPj4gKyDCoCDCoCDCoCDCoCDC
> oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBicmVhazsNCj4+ICsg
> wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgZGllKCJvb3BzIik7
> DQo+DQo+IFRoYXQncyBnb2luZyB0byBiZSBhbiBvZmZpY2lhbCBnaXQgZXJyb3IgbWVzc2FnZT8g
> V2h5IG5vdCBtYWtlIGl0ICJUaGUNCg0KSXQncyBub3QgImdvaW5nIHRvIGJlIiwgYnV0ICJoYXMg
> YmVlbiBzbyBmb3IgdGhlIGxhc3QgdHdvIHllYXJzIHNpbmNlDQo1ZDIzZTEzIi4NCg0KSXQgaXMg
> YW4gYXNzZXJ0LCBhbmQgSSB0aGluayBQZWZmJ3MgZGllKCJCVUc6IC4uLiIpIHdvdWxkIGJlIGEg
> Z29vZCBpZGVhLg0K
Huh?
--
Felipe Contreras
^ permalink raw reply
* Re: [RFC/PATCH 0/2] New 'stage' command
From: Felipe Contreras @ 2009-04-05 19:28 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vmyausz3h.fsf@gitster.siamese.dyndns.org>
On Sun, Apr 5, 2009 at 10:02 PM, Junio C Hamano <gitster@pobox.com> wrote:
> Felipe Contreras <felipe.contreras@gmail.com> writes:
>
>> This is the list of actions I've mapped:
>>
>> * add: git stage = git stage add (git add)
>> * rm: (git rm --cached)
>> * diff: (git rm --cached)
>> * import: stage all files; modified, deleted, new
>> * ls: (git ls-files --stage)
>
> I do not think these are good ideas at all, as it just spreads more
> confusion, not less.
Do you agree that there's already a lot of confusion? (stage, cache,
index, etc.)
And do you agree that many git newbies don't use the stage? Actually
most of them don't even know what it is, and just do "git commit -a".
If so, how do you think these issues should be handled?
--
Felipe Contreras
^ permalink raw reply
* Re: non-ascii filenames issue
From: Junio C Hamano @ 2009-04-05 19:29 UTC (permalink / raw)
To: Jay Soffian; +Cc: John Tapsell, Teemu Likonen, git
In-Reply-To: <76718490904050923j105e383dsf650afa0a0687858@mail.gmail.com>
Jay Soffian <jaysoffian@gmail.com> writes:
> On Sun, Apr 5, 2009 at 6:51 AM, John Tapsell <johnflux@gmail.com> wrote:
>> Unfortunately not, because for some absolutely crazy reason
>
> Bzzt. http://article.gmane.org/gmane.comp.version-control.git/50830
I do not think the message gives enough information on the issue, as "a
pathname is a slash separated sequence of path components terminated with
a NUL, and a path component is an uninterpreted sequence of bytes
excluding NUL and slash" is simply a UNIX tradition the original git
design took as _given_, so the "some absolutely crazy reason" comment does
not even deserve refuting.
There is _no_ reason, crazy or otherwise. If you start from "a pathname
is an uninterpreted sequence of bytes" tradition, it is a design parameter
and "how things are", and you simply do not argue with them. And the
message you quoted doesn't, either.
Side note: I am not saying that we should not ever change that
particular design parameter. I am just explaining why 50830 is
not a good counterargument to quote against the "some absolutely
crazy reason" accusation.
> And, as always, patches welcomed.
Before patches, you need a sound design and justification.
At least you need to consider the following (the early ones are easier):
- Do we unify them to some canonical encoding internally and do the
matching in the canonical space? What's the internal representation
(presumably UTF-8)?
- How should a user tell the pathname conversion rules between the
internal repreasentation and the filesystem representation to git? A
config variable per a repository?
- How should this interact with patch+apply dataflow (including "rebase"
without -i/-m)? Should pathnames in diffs be in canonical form?
- How should this interact with case challenged and/or unicode corrupting
filesystems such as NTFS and HFSplus whose creat(), readdir(), and
stat() contradict with each other?
- What should happen when the pathname in the canonical representation
recorded in the history cannot be externalized on a particular
filesystem? Does it gracefully degenerate and give some escape hatch,
and if so how?
^ permalink raw reply
* Re: [PATCH 1/4] sha1-lookup: add new "sha1_pos" function to efficiently lookup sha1
From: Felipe Contreras @ 2009-04-05 19:30 UTC (permalink / raw)
To: Teemu Likonen; +Cc: Junio C Hamano, git
In-Reply-To: <87vdpi29a4.fsf@iki.fi>
On Sun, Apr 5, 2009 at 10:24 PM, Teemu Likonen <tlikonen@iki.fi> wrote:
> On 2009-04-05 22:19 (+0300), Felipe Contreras wrote:
>
>> On Sun, Apr 5, 2009 at 9:59 PM, Junio C Hamano <gitster@pobox.com> wrote:
>>> U3ZlcnJlIFJhYmJlbGllciA8c3JhYmJlbGllckBnbWFpbC5jb20+IHdyaXRlczoNCg0KPiBPbiBT
> [...]
>> Huh?
>
> Base64 transfer encoding:
>
> Content-Type: text/plain; charset=utf-8
> Content-Transfer-Encoding: base64
Yeah, I know, but apparently Gmail doesn't support it.
--
Felipe Contreras
^ permalink raw reply
* Re: [PATCH 1/4] sha1-lookup: add new "sha1_pos" function to efficiently lookup sha1
From: Reece Dunn @ 2009-04-05 19:31 UTC (permalink / raw)
To: Felipe Contreras
Cc: Junio C Hamano, Sverre Rabbelier, Christian Couder, git,
Johannes Schindelin
In-Reply-To: <94a0d4530904051219q7d9ed028jd6e05f541d7c12b5@mail.gmail.com>
2009/4/5 Felipe Contreras <felipe.contreras@gmail.com>:
> On Sun, Apr 5, 2009 at 9:59 PM, Junio C Hamano <gitster@pobox.com> wrote:
>> U3ZlcnJlIFJhYmJlbGllciA8c3JhYmJlbGllckBnbWFpbC5jb20+IHdyaXRlczoNCg0KPiBPbiBT
>> YXQsIEFwciA0LCAyMDA5IGF0IDIyOjU5LCBDaHJpc3RpYW4gQ291ZGVyIDxjaHJpc2Nvb2xAdHV4
>> ZmFtaWx5Lm9yZz4gd3JvdGU6DQo+PiArIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKg
>> IMKgIMKgIMKgIMKgIGlmIChsbyA8PSBtaSAmJiBtaSA8IGhpKQ0KPj4gKyDCoCDCoCDCoCDCoCDC
>> oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCBicmVhazsNCj4+ICsg
>> wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgZGllKCJvb3BzIik7
>> DQo+DQo+IFRoYXQncyBnb2luZyB0byBiZSBhbiBvZmZpY2lhbCBnaXQgZXJyb3IgbWVzc2FnZT8g
>> V2h5IG5vdCBtYWtlIGl0ICJUaGUNCg0KSXQncyBub3QgImdvaW5nIHRvIGJlIiwgYnV0ICJoYXMg
>> YmVlbiBzbyBmb3IgdGhlIGxhc3QgdHdvIHllYXJzIHNpbmNlDQo1ZDIzZTEzIi4NCg0KSXQgaXMg
>> YW4gYXNzZXJ0LCBhbmQgSSB0aGluayBQZWZmJ3MgZGllKCJCVUc6IC4uLiIpIHdvdWxkIGJlIGEg
>> Z29vZCBpZGVhLg0K
>
> Huh?
I think Junio is trying to learn base64 :)!
This is what `base64 -d` gives:
Sverre Rabbelier <srabbelier@gmail.com> writes:
> On Sat, Apr 4, 2009 at 22:59, Christian Couder <chriscool@tuxfamily.org> wrote:
>> + if (lo <= mi && mi < hi)
>> + break;
>> + die("oops");
>
> That's going to be an official git error message? Why not make it "The
It's not "going to be", but "has been so for the last two years since
5d23e13".
It is an assert, and I think Peff's die("BUG: ...") would be a good idea.
^ permalink raw reply
* Re: [RFC/PATCH 0/2] New 'stage' command
From: Junio C Hamano @ 2009-04-05 19:33 UTC (permalink / raw)
To: Felipe Contreras; +Cc: git
In-Reply-To: <94a0d4530904051228m4e57ec90y810dded41f47e443@mail.gmail.com>
Felipe Contreras <felipe.contreras@gmail.com> writes:
> On Sun, Apr 5, 2009 at 10:02 PM, Junio C Hamano <gitster@pobox.com> wrote:
>> Felipe Contreras <felipe.contreras@gmail.com> writes:
>>
>>> This is the list of actions I've mapped:
>>>
>>> * add: git stage = git stage add (git add)
>>> * rm: (git rm --cached)
>>> * diff: (git rm --cached)
>>> * import: stage all files; modified, deleted, new
>>> * ls: (git ls-files --stage)
>>
>> I do not think these are good ideas at all, as it just spreads more
>> confusion, not less.
>
> Do you agree that there's already a lot of confusion? (stage, cache,
> index, etc.)
>
> And do you agree that many git newbies don't use the stage? Actually
> most of them don't even know what it is, and just do "git commit -a".
>
> If so, how do you think these issues should be handled?
Perhaps not spreading "stage" even wider? That is the newest confusing
term that caused the most harm.
^ permalink raw reply
* [RFC/PATCH 0/2] Re: New 'stage' command
From: Nicolas Sebrecht @ 2009-04-05 19:34 UTC (permalink / raw)
To: Felipe Contreras; +Cc: Junio C Hamano, git
In-Reply-To: <94a0d4530904051228m4e57ec90y810dded41f47e443@mail.gmail.com>
On Sun, Apr 05, 2009 at 10:28:24PM +0300, Felipe Contreras wrote:
> > I do not think these are good ideas at all, as it just spreads more
> > confusion, not less.
Agreed.
> Do you agree that there's already a lot of confusion? (stage, cache,
> index, etc.)
>
> And do you agree that many git newbies don't use the stage? Actually
> most of them don't even know what it is, and just do "git commit -a".
>
> If so, how do you think these issues should be handled?
Read the documentation? Read tutorials?
--
Nicolas Sebrecht
^ permalink raw reply
* Re: [PATCH] bash completion: add git-difftool
From: Shawn O. Pearce @ 2009-04-05 19:43 UTC (permalink / raw)
To: David Aguilar; +Cc: gitster, git
In-Reply-To: <1238671857-8811-1-git-send-email-davvid@gmail.com>
David Aguilar <davvid@gmail.com> wrote:
> This adds completion for difftool's --tool flag.
> The known diff tool names were also consolidated into
> a single variable.
Looks good to me. I see Junio has it slated in pu currently.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
--
Shawn.
^ permalink raw reply
* Re: Performance issue: initial git clone causes massive repack
From: Jeff King @ 2009-04-05 19:57 UTC (permalink / raw)
To: Robin H. Johnson; +Cc: Git Mailing List
In-Reply-To: <20090404220743.GA869@curie-int>
On Sat, Apr 04, 2009 at 03:07:43PM -0700, Robin H. Johnson wrote:
> During an initial clone, I see that git-upload-pack invokes
> pack-objects, despite the ENTIRE repository already being packed - no
> loose objects whatsoever. git-upload-pack then seems to buffer in
> memory.
We need to run pack-objects even if the repo is fully packed because we
don't know what's _in_ the existing pack (or packs). In particular we
want to:
- combine multiple packs into a single pack; this is more efficient on
the network, because you can find more deltas, and I believe is
required because the protocol sends only a single pack.
- cull any objects which are not actually part of the reachability
chain from the refs we are sending
If no work needs to be done for either case, then pack-objects should
basically just figure that out and then send the existing pack (the
expensive bit is doing deltas, and we don't consider objects in the same
pack for deltas, as we know we have already considered that during the
last repack). It does mmap the whole pack, so you will see your virtual
memory jump, but nothing should require the whole pack being in memory
at once.
pack-objects streams the output to upload-pack, which should only ever
have an 8K buffer of it in memory at any given time.
At least that is how it is all supposed to work, according to my
understanding. So if you are seeing very high memory usage, I wonder if
there is a bug in pack-objects or upload-pack that can be fixed.
Maybe somebody more knowledgeable than me about packing can comment.
> During 'remote: Counting objects: 4886949, done.', git-upload-pack peaks at
> 2474216KB VSZ and 1143048KB RSS.
> Shortly thereafter, we get 'remote: Compressing objects: 0%
> (1328/1994284)', git-pack-objects with ~2.8GB VSZ and ~1.8GB RSS. Here,
> the CPU burn also starts. On our test server machine (w/ git 1.6.0.6),
> it takes about 200 minutes walltime to finish the pack, IFF the OOM
> doesn't kick in.
Have you tried with a more recent git to see if it is any better? There
have been a number of changes since 1.6.0.6, although it looks like
mostly dealing with better recovery from corrupted packs.
> Given that the repo is entirely packed already, I see no point in doing
> this.
>
> For the initial clone, can the git-upload-pack algorithm please send
> existing packs, and only generate a pack containing the non-packed
> items?
I believe that would require a change to the protocol to allow multiple
packs. However, it may be possible to munge the pack header in such a
way that you basically concatenate multiple packs. You would still want
to peek in the big pack to try deltas from the non-packed items, though.
I think all of this falls into the realm of the GSOC pack caching project.
There have been other discussions on the list, so you might want to look
through those for something useful.
-Peff
^ 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