* Re: Performance issue: initial git clone causes massive repack
From: Nicolas Pitre @ 2009-04-06 14:19 UTC (permalink / raw)
To: Jon Smirl
Cc: Junio C Hamano, david, Nicolas Sebrecht, Robin H. Johnson,
Git Mailing List, Shawn O. Pearce
In-Reply-To: <9e4733910904060652t6c0f37d9t246b7394e3aad350@mail.gmail.com>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 2515 bytes --]
On Mon, 6 Apr 2009, Jon Smirl wrote:
> On Mon, Apr 6, 2009 at 1:15 AM, Junio C Hamano <gitster@pobox.com> wrote:
> > Nicolas Pitre <nico@cam.org> writes:
> >
> >> What git-pack-objects does in this case is not a full repack. It
> >> instead _reuse_ as much of the existing packs as possible, and only does
> >> the heavy packing processing for loose objects and/or inter pack
> >> boundaryes when gluing everything together for streaming over the net.
> >> If for example you have a single pack because your repo is already fully
> >> packed, then the "packing operation" involved during a clone should
> >> merely copy the existing pack over with no further attempt at delta
> >> compression.
> >
> > One possibile scenario that you still need to spend memory and cycle is if
> > the cloned repository was packed to an excessive depth to cause many of
> > its objects to be in deltified form on insanely deep chains, while cloning
> > send-pack uses a depth that is more reasonable. Then pack-objects invoked
> > by send-pack is not allowed to reuse most of the objects and would end up
> > redoing the delta on them.
>
> That seems broken. You went through all of the trouble to make the
> pack file smaller to reduce transmission time, and then clone undoes
> the work.
And as I already explained, this is indeed not what happens.
> What about making a very simple special case for an initial clone?
There should not be any need for initial clone hacks.
> First thing an initial clone does is copy all of the pack files from
> the server to the client without even looking at them.
This is a no go for reasons already stated many times. There are
security implications (those packs might contain stuff that you didn't
intend to be publically accessible) and there might be efficiency
reasons as well (you might have a shared object store with lots of stuff
unrelated to the particular clone).
The biggest cost right now when cloning a big packed repo is object
enumeration. Any other issues related to memory costs in the GB range
simply has no reason for it, and is mostly due to misconfigurations or
bugs that have to be fixed. Trying to work around the issue by all
sorts of hacks is simply counter productive.
In the case that started this very thread, I suspect that a small
misfeature of some delta caching might be the culprit. I asked Robin H.
Johnson to perform a really simple config addition to his repo and
retest, for which we still haven't seen any results yet.
Nicolas
^ permalink raw reply
* Re: Performance issue: initial git clone causes massive repack
From: Robin H. Johnson @ 2009-04-06 14:20 UTC (permalink / raw)
To: Git Mailing List
In-Reply-To: <alpine.LFD.2.00.0904052336260.6741@xanadu.home>
[-- Attachment #1: Type: text/plain, Size: 2560 bytes --]
Again, I'm about to leave on a trip for a few days (back late Thursday),
but just wanted to comment in on the thread.
On Mon, Apr 06, 2009 at 12:06:00AM -0400, Nicolas Pitre wrote:
> > While my current pack setup has multiple packs of not more than 100MiB
> > each, that was simply for ease of resume with rsync+http tests. Even
> > when I already had a single pack, with every object reachable,
> > pack-objects was redoing the packing.
> In that case it shouldn't have.
I'll retest that part on my return, but I'm pretty sure I did see the
same excess cputime usage.
> > Also, I did another trace, using some other hardware, in a LAN setting, and
> > noticed that git-upload-pack/pack-objects only seems to start output to the
> > network after it reaches 100% in 'remote: Compressing objects:'.
> That's to be expected. Delta compression matches objects which are not
> in the stream order at all. Therefore it is not possible to start
> outputting pack data until this pass is done. Still, this pass should
> not be invoked if your repository is already fully packed into one pack.
So it's seeking around the existing packs before sending?
> Can you confirm this is actually the case?
The most recent tests were with the 15(+ one partial) packs limited to a
max of 100MiB each, because that made resume for rsync/http during the
tests much cleaner.
> > Relatedly, throwing more RAM (6GiB total, vs. the previous 2GiB) at
> > the server in this case cut the 200 wallclock minutes before any
> > sending too place down to 5 minutes.
> Well... here's a wild guess. In the source repository serving clone
> requests, please do:
> git config pack.deltaCacheSize 1
> git config pack.deltaCacheLimit 0
> and try cloning again with a fully packed repository.
I did the multiple pack case quickly, and found that it does still take
a long time in the low memory case. I'll do the test with a single pack
on my return.
> The caching pack project is to address a different issue: mainly to
> bypass the object enumeration cost. In other words, it could allow for
> skipping the "Counting objects" pass, and a tiny bit more. At least in
> theory that's about the main difference. This has many drawbacks as
> well though.
Relatedly, would it be possible to keep a cache of enumerated objects
that was trivially updatable during pushes?
--
Robin Hugh Johnson
Gentoo Linux Developer & Infra Guy
E-Mail : robbat2@gentoo.org
GnuPG FP : 11AC BA4F 4778 E3F6 E4ED F38E B27B 944E 3488 4E85
[-- Attachment #2: Type: application/pgp-signature, Size: 330 bytes --]
^ permalink raw reply
* Re: Performance issue: initial git clone causes massive repack
From: Jon Smirl @ 2009-04-06 14:37 UTC (permalink / raw)
To: Nicolas Pitre
Cc: Junio C Hamano, david, Nicolas Sebrecht, Robin H. Johnson,
Git Mailing List, Shawn O. Pearce
In-Reply-To: <alpine.LFD.2.00.0904060959250.6741@xanadu.home>
On Mon, Apr 6, 2009 at 10:19 AM, Nicolas Pitre <nico@cam.org> wrote:
> On Mon, 6 Apr 2009, Jon Smirl wrote:
>
>> On Mon, Apr 6, 2009 at 1:15 AM, Junio C Hamano <gitster@pobox.com> wrote:
>> > Nicolas Pitre <nico@cam.org> writes:
>> >
>> >> What git-pack-objects does in this case is not a full repack. It
>> >> instead _reuse_ as much of the existing packs as possible, and only does
>> >> the heavy packing processing for loose objects and/or inter pack
>> >> boundaryes when gluing everything together for streaming over the net.
>> >> If for example you have a single pack because your repo is already fully
>> >> packed, then the "packing operation" involved during a clone should
>> >> merely copy the existing pack over with no further attempt at delta
>> >> compression.
>> >
>> > One possibile scenario that you still need to spend memory and cycle is if
>> > the cloned repository was packed to an excessive depth to cause many of
>> > its objects to be in deltified form on insanely deep chains, while cloning
>> > send-pack uses a depth that is more reasonable. Then pack-objects invoked
>> > by send-pack is not allowed to reuse most of the objects and would end up
>> > redoing the delta on them.
>>
>> That seems broken. You went through all of the trouble to make the
>> pack file smaller to reduce transmission time, and then clone undoes
>> the work.
>
> And as I already explained, this is indeed not what happens.
>
>> What about making a very simple special case for an initial clone?
>
> There should not be any need for initial clone hacks.
>
>> First thing an initial clone does is copy all of the pack files from
>> the server to the client without even looking at them.
>
> This is a no go for reasons already stated many times. There are
> security implications (those packs might contain stuff that you didn't
> intend to be publically accessible) and there might be efficiency
> reasons as well (you might have a shared object store with lots of stuff
> unrelated to the particular clone).
How do you deal with dense history packs? These packs take many hours
to make (on a server class machine) and can be half the size of a
regular pack. Shouldn't there be a way to copy these packs intact on
an initial clone? It's ok if these packs are specially marked as being
ok to copy.
>
> The biggest cost right now when cloning a big packed repo is object
> enumeration. Any other issues related to memory costs in the GB range
> simply has no reason for it, and is mostly due to misconfigurations or
> bugs that have to be fixed. Trying to work around the issue by all
> sorts of hacks is simply counter productive.
>
> In the case that started this very thread, I suspect that a small
> misfeature of some delta caching might be the culprit. I asked Robin H.
> Johnson to perform a really simple config addition to his repo and
> retest, for which we still haven't seen any results yet.
>
>
> Nicolas
>
--
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply
* Re: Fetching SHA id's instead of named references?
From: Shawn O. Pearce @ 2009-04-06 14:40 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Klas Lindberg, Git Users List
In-Reply-To: <alpine.DEB.1.00.0904061431020.6619@intel-tinevez-2-302>
Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> On Mon, 6 Apr 2009, Klas Lindberg wrote:
>
> > Is there a way to fetch based on SHA id's instead of named references?
>
> No, out of security concerns; imagine you included some proprietary
> source code by mistake, and undo the damage by forcing a push with a
> branch that does not have the incriminating code. Usually you do not
> control the garbage-collection on the server, yet you still do not want
> other people to fetch "by SHA-1".
>
> BTW this is really a strong reason not to use HTTP push in such
> environments.
Err, you mean http:// and rsync:// fetch, don't you? Because if
you rely on being able to unpublish a ref you have to use only the
native git://, where direct access is otherwise forbidden.
Anyway.
The fetch-pack/upload-pack protocol uses SHA1s in the want commands,
so in theory at the protocol level you can say "git fetch URL SHA1"
and convey your request to the remote peer.
The problem is, upload-pack won't perform a reachability analysis
to determine if a wanted SHA1 is reachable from a current ref.
Instead it requires that the wanted SHA1 is *exactly* referenced
by at least one ref.
I had previously proposed adding a merge base test if SHA1 parses
as a commit, but IIRC Junio rejected the idea, saying it was too
costly to perform on the server.
The thing is, he's right.
There's no reason to perform the reachability test on the server
when you can move it onto the client, and that's exactly what
git-submodule is doing. It fetches everything, and then assumes
its reachable post fetch. Since the client has fetched everything,
the client has the object if its reachable by the server.
If the object is no longer reachable by the server's refs (think
branch rebased) then the object is actually in danger of being GC'd
off of the server's object store. So you already are going to be
playing with fire, even if we added a server side config to permit
fetching of unreachable data. A future "git gc" on that server
repository could suddenly wipe out that data entirely.
Klas, one suggestion might be to make a "refs/heads/world" ref which
has a threaded chain of merges of every commit you ever recorded
in the supermodule, and then you can assume post fetch that the
world is reachable.
E.g. every time you want to record a commit in the manifest file,
also shove it into the world:
C=...commit.to.save... &
W=$(git rev-parse refs/heads/world) &&
git update-ref refs/heads/world \
$(echo Save $C, save the world | git commit-tree $W -p $W -p $C) \
$W &&
git push URL refs/heads/world
One way we get away with this sort of thing in repo is, we only
put SHA1s in our manifest that are published in branches that
won't ever rewind or delete. Hence, its a moot point.
--
Shawn.
^ permalink raw reply
* Re: git diff bug?
From: Michael J Gruber @ 2009-04-06 14:44 UTC (permalink / raw)
To: David Abrahams; +Cc: Jeff King, git
In-Reply-To: <1BF9172A-BE91-4D1C-932A-EB9FD79BA402@boostpro.com>
David Abrahams venit, vidit, dixit 06.04.2009 11:09:
>
> On Apr 3, 2009, at 9:45 PM, Jeff King wrote:
>
>> On Fri, Apr 03, 2009 at 09:10:42PM -0400, David Abrahams wrote:
>>
>>> Please see
>>> http://github.com/techarcana/elisp/commit/63d672c296316c85690085930b05c642b88a9978#diff-2
>>>
>>> Note how the @@ ... @@ clauses are followed by text from the previous
>>> line's comment. Not sure, but this strikes me as a line-ending
>>> issue.
>>> custom.el was originally built on a linux machine; now I'm using a
>>> Mac.
>>
>> This is as designed. The original file ("git show e7dd7db") contains
>> (my
>> numbering seems different than what git produces; it is produced by
>> "nl"
>> which is maybe treating some line endings differently earlier in the
>> file):
>>
>> 102 '(mm-attachment-override-types (quote ("text/x-vcard"
>> "application/pkcs7-mime" "application/x-pkcs7-mime" "application/
>> pkcs7-signature" "application/x-pkcs7-signature" "image/*")) nil nil "
>> 103 Added image/* to display attached images inline")
>> 104 '(mm-discouraged-alternatives (quote ("text/html" "text/
>> richtext" "image/.*")) nil nil "
>> 105 The documentation for this variable says it all")
>> 106 '(mm-inline-text-html-with-images t)
>> 107 '(muse-project-alist (quote (("WikiPlanner" ("~/
>> plans" :default "index" :major-mode planner-mode :visit-link planner-
>> visit-link)))))
>> 108 '(org-agenda-files (quote ("~/organizer.org")))
>>
>> The changed text in your diff starts on 108. So we show 105-107 as
>> context lines. The text after the @@ clause is the "function header";
>> this is equivalent to "-p" in GNU diff. It's basically a guess about
>> the
>> most interesting context to show, and looks alphabetic characters that
>> are left-aligned. In the case of lisp, it really isn't all that
>> interesting (and what looks so weird is that your file contains
>> a lot of
>>
>> "\nSome text"
>>
>> so the text strings are all left-aligned. You can customize the regex
>> used to guess at the function header. See "defining a custom
>> hunk-header" in "git help attributes".
>
> Hmm, so I tried sticking this .gitattributes in my repo
>
> *.el diff=el
> [diff "el"]
> xfuncname = "^(\\(def[a-z]+ .+)$"
>
> and git diff barfed with
>
> "el"] is not a valid attribute name: .gitattributes:2
> "^(\\(def[a-z]+ is not a valid attribute name: .gitattributes:3
>
> What am I missing? I tried googling, but from what turns up for me,
> it doesn't look like anyone else has ever tried to use this feature!
Well, I don't think anayone else has tried putting config lines into
.gitattributes ;)
The "*.el" line goes into .gitattributes (or .git/info/a...), the other
lines are config lines and thus goe into .git/config or .gitconfig.
Michael
^ permalink raw reply
* Re: Submodules can't work recursively because Git implements policy?
From: Klas Lindberg @ 2009-04-06 14:47 UTC (permalink / raw)
To: Finn Arne Gangstad; +Cc: Matthieu Moy, Johannes Schindelin, Git Users List
In-Reply-To: <20090406135618.GA17793@pvv.org>
On Mon, Apr 6, 2009 at 3:56 PM, Finn Arne Gangstad <finnag@pvv.org> wrote:
> Yes, I could not agree more. You may also end up writing some really
> complicated wrappers around git push to get things going (where do you
> push, for example). We made some interesting "concept art" around this
> last year at $dayjob, but decided to drop it.
I don't see how pushing could work at all without recursion.
> Maybe the security concerns could be handled by adding some
> functionality to (quickly) get rid of unwanted commits?
Why not simply allow users with write permissions to "pop" revisions
from the top of the history DAG in a way that actually really deletes
the them? Or at least moves those commits to a separate, locked down
DAG that cannot be read by people without write permissions?
But anyway: If I implement support for fetching SHA keys and full
recursive behaviour in the presence of submodules; would my patches
automatically be rejected because of the rationale for the current
behaviour?
/Klas
^ permalink raw reply
* Re: Performance issue: initial git clone causes massive repack
From: Shawn O. Pearce @ 2009-04-06 14:48 UTC (permalink / raw)
To: Jon Smirl
Cc: Nicolas Pitre, Junio C Hamano, david, Nicolas Sebrecht,
Robin H. Johnson, Git Mailing List
In-Reply-To: <9e4733910904060737k3d1c082fk785cd98cdeb6d73d@mail.gmail.com>
Jon Smirl <jonsmirl@gmail.com> wrote:
>
> How do you deal with dense history packs? These packs take many hours
> to make (on a server class machine) and can be half the size of a
> regular pack. Shouldn't there be a way to copy these packs intact on
> an initial clone? It's ok if these packs are specially marked as being
> ok to copy.
These should be copied as-is.
Basically, object enumeration lists every reachable object, which
should include every object in this pack if its a "dense history
pack". We then start to write out each object. As each object
is written we look to see if it already exists in a pack. It does
(in your dense history pack), so we then look to see if its delta
base is also in the output list (it is), so we send the data as-is.
One of the bigger costs with such clones is building that huge list
of objects needed to send. The primary cost appears to be unpacking
the trees from the "dense history pack", where delta chains are
usually quite long. The GSoC 2009 pack caching project idea is
based on the theory that we should be able to save a list of objects
that are reachable from some fixed point (e.g. a very well known,
stable tag), and avoid needing to read these ancient trees.
But its just a theory. Caching always costs you management
overheads. And it may not save us that much time . And most of
the theory here is based on JGit's performance during packing,
*not* git-core.
I came up with the object list caching idea because JGit's object
enumeration is just pitiful. (Its Java, what do you want, if you
wanted fast, you'd use portable assembler... like git-core does.)
Whether or not its worth applying to git-core is another story
entirely.
--
Shawn.
^ permalink raw reply
* Re: Submodules can't work recursively because Git implements policy?
From: Shawn O. Pearce @ 2009-04-06 14:51 UTC (permalink / raw)
To: Klas Lindberg
Cc: Finn Arne Gangstad, Matthieu Moy, Johannes Schindelin,
Git Users List
In-Reply-To: <33f4f4d70904060747h72019846gca18255bd71adc22@mail.gmail.com>
Klas Lindberg <klas.lindberg@gmail.com> wrote:
> On Mon, Apr 6, 2009 at 3:56 PM, Finn Arne Gangstad <finnag@pvv.org> wrote:
> > Maybe the security concerns could be handled by adding some
> > functionality to (quickly) get rid of unwanted commits?
>
> Why not simply allow users with write permissions to "pop" revisions
> from the top of the history DAG in a way that actually really deletes
> the them? Or at least moves those commits to a separate, locked down
> DAG that cannot be read by people without write permissions?
What, like a secret shadow repository that you move the objects into?
That could be very expensive in terms of disk IO if those objects
are in large packs. You'd need to break the pack apart into the
"ok" and "sekret" parts. Ick.
> But anyway: If I implement support for fetching SHA keys and full
> recursive behaviour in the presence of submodules; would my patches
> automatically be rejected because of the rationale for the current
> behaviour?
See my recent email (like ~10-15 minutes ago). It will be rejected
due to the issue that unreachable objects are subjected to GC and
you'd easily see your repository delete that data on the next "git
gc" invocation. Automatic data destruction is not something that
users come to git for.
--
Shawn.
^ permalink raw reply
* Re: The EGIT Chronicles Issue Volume 3, Issue 1
From: Shawn O. Pearce @ 2009-04-06 15:03 UTC (permalink / raw)
To: Robin Rosenberg; +Cc: git
In-Reply-To: <200904060833.27711.robin.rosenberg.lists@dewire.com>
Robin Rosenberg <robin.rosenberg.lists@dewire.com> wrote:
>
> Most interestingly, some Eclipse developers, i.e. the ones
> that build and contribute to the Eclipse platform, have raised
> interest in Git for source control. We have had an Eclipse
> proposal under development for a while and finally submitted
> EGit for consideration as and Eclipse Technology project. Link:
> http://www.eclipse.org/proposals/egit/
>
> Egit is EPL and BSD licensed which license-wise qualifies it for
> inclusion into the Eclipse project, unlike the nearest competitor
> Mercurial that cannot be bundled with Eclipse due to the GPL.
For pretty much this reason alone, Eclipse is starting to consider
switching from CVS and SVN to Git. Some committers were interested
in a switch to Mecurial, but the GPL license makes it unfriendly
to the project's distribution rules.
> - Shawn's been working on Gerrit2, a code review system built on
> top of JGit, the core of the Eclipse plugin.
Its also sucking up all of my time.
But... its open source, and is gaining (some) momentum in Git
communities that want mandatory code review, but who also want to
avoid the bottleneck of a maintainer / "merge monkey".
Junio made some remark back when I joined Google that Google just
swallows up open source developers whole, and you never hear from
them again. At least half true. Fortunately I am at least able to
open source (EPL if in EGit, BSD if in JGit, else APLv2) everything
that I do while in that big black hole known as Google.
> - Lots of stuff is coming. For example, a few diff engines are
> being considered, a blame implementation has been demonstrated,
> though not fully ready yet. Some simple merge/cherry picking
> capability is included already, but without the diff/patch engine
> it's not as fully automated as one might want yet. Gerrit2 uses
> it though.
The lack of a diff engine is starting to become an issue for me
in Gerrit2. Maybe next month I'll be able to get to it, if someone
doesn't beat me to it first. Gerrit2 users are asking for proper
cherry pick support, not just the path-level-only cr*p we do now.
--
Shawn.
^ permalink raw reply
* [PATCH v2] Documentation: clarify .gitattributes search
From: Jason Merrill @ 2009-04-06 15:03 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7viqlicp1y.fsf@gitster.siamese.dyndns.org>
[-- Attachment #1: Type: text/plain, Size: 1543 bytes --]
Junio C Hamano wrote:
> (2) also wondered why you were confused to think if your home directory
> (for that matter, any higher directory, like /.gitattributes at the
> filesystem root level) that is clearly outside of the project could
> possibly affect what happens inside a project; and
Because it would be useful if it did; specifically, it would be
convenient to be able to say that ChangeLog files use
git-merge-changelog wherever they appear, and not have to repeat that in
all my projects. I didn't really expect it, but thought that maybe it
was designed to work that way.
> (3) was puzzled why you do not have any patch to description of ignore
> files (perhaps you do not even a similar confusion on them).
I hadn't really thought about them, but looking at the documentation now
I see that ignore files have the core.excludesfile config variable to
provide global ignores; there doesn't seem to be anything analogous for
attributes.
> (1) To a long-time git person, "up to the root" is obviously talking
> about the toplevel of the work tree, not "root of the filesystem",
> but is it clear to _you_ (or do you think it would be clear to
> somebody else without much previous exposure to git)?
It seems clear enough, as it would be pointless to say it if it meant
the root of the filesystem.
> (2) If not, I think we should come up with a good wording and use that in
> both. How does the "toplevel of the work tree" sound for that
> purpose?
Sure, I'll use that.
[-- Attachment #2: 0001-Documentation-clarify-.gitattributes-search.patch --]
[-- Type: text/x-patch, Size: 2139 bytes --]
Use the term "toplevel of the work tree" in gitattributes.txt and
gitignore.txt to define the limits of the search for those files.
Signed-off-by: Jason Merrill <jason@redhat.com>
---
Documentation/gitattributes.txt | 6 +++---
Documentation/gitignore.txt | 4 ++--
2 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/Documentation/gitattributes.txt b/Documentation/gitattributes.txt
index 55668e3..b762bba 100644
--- a/Documentation/gitattributes.txt
+++ b/Documentation/gitattributes.txt
@@ -60,9 +60,9 @@ same as in `.gitignore` files; see linkgit:gitignore[5].
When deciding what attributes are assigned to a path, git
consults `$GIT_DIR/info/attributes` file (which has the highest
precedence), `.gitattributes` file in the same directory as the
-path in question, and its parent directories (the further the
-directory that contains `.gitattributes` is from the path in
-question, the lower its precedence).
+path in question, and its parent directories up to the toplevel of the
+work tree (the further the directory that contains `.gitattributes`
+is from the path in question, the lower its precedence).
If you wish to affect only a single repository (i.e., to assign
attributes to files that are particular to one user's workflow), then
diff --git a/Documentation/gitignore.txt b/Documentation/gitignore.txt
index 59321a2..7df3cef 100644
--- a/Documentation/gitignore.txt
+++ b/Documentation/gitignore.txt
@@ -31,8 +31,8 @@ precedence, the last matching pattern decides the outcome):
* Patterns read from a `.gitignore` file in the same directory
as the path, or in any parent directory, with patterns in the
- higher level files (up to the root) being overridden by those in
- lower level files down to the directory containing the file.
+ higher level files (up to the toplevel of the work tree) being overridden
+ by those in lower level files down to the directory containing the file.
These patterns match relative to the location of the
`.gitignore` file. A project normally includes such
`.gitignore` files in its repository, containing patterns for
--
1.6.2.2
^ permalink raw reply related
* Re: Performance issue: initial git clone causes massive repack
From: Nicolas Pitre @ 2009-04-06 15:14 UTC (permalink / raw)
To: Jon Smirl
Cc: Junio C Hamano, david, Nicolas Sebrecht, Robin H. Johnson,
Git Mailing List, Shawn O. Pearce
In-Reply-To: <9e4733910904060737k3d1c082fk785cd98cdeb6d73d@mail.gmail.com>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 3205 bytes --]
On Mon, 6 Apr 2009, Jon Smirl wrote:
> On Mon, Apr 6, 2009 at 10:19 AM, Nicolas Pitre <nico@cam.org> wrote:
> > On Mon, 6 Apr 2009, Jon Smirl wrote:
> >
> >> First thing an initial clone does is copy all of the pack files from
> >> the server to the client without even looking at them.
> >
> > This is a no go for reasons already stated many times. There are
> > security implications (those packs might contain stuff that you didn't
> > intend to be publically accessible) and there might be efficiency
> > reasons as well (you might have a shared object store with lots of stuff
> > unrelated to the particular clone).
>
> How do you deal with dense history packs? These packs take many hours
> to make (on a server class machine) and can be half the size of a
> regular pack. Shouldn't there be a way to copy these packs intact on
> an initial clone? It's ok if these packs are specially marked as being
> ok to copy.
[sigh]
Let me explain it all again.
There is basically two ways to create a new pack: the intelligent way,
and the bruteforce way.
When creating a new pack the intelligent way, what we do is to enumerate
all the needed object and look them up in the object store. When a
particular object is found, we create a record for that object and note
in which pack it is located, at what offset in that pack, how much space
it occupies in its compressed form within that pack, , and if whether it
is a delta or not. When that object is indeed a delta (the majority of
objects usually are) then we also keep a pointer on the record for the
base object for that delta.
Next, for all objects in delta form which base object is also part of
the object enumeration and obviously part of the same pack, we simply
flag those objects as directly reusable without any further processing.
This means that, when those objects are about to be stored in the new
pack, their raw data is simply copied straight from the original pack
using the offset and size noted above. In other words, those objects
are simply never redeltified nor redeflated at all, and all the work
that was previously done to find the best delta match is preserved with
no extra cost.
Of course, when your repository is tightly packed into a single pack,
then all enumerated objects fall into the reusable category and
therefore a copy of the original pack is indeed sent over the wire.
One exception is with older git clients which don't support the delta
base offset encoding, in which case the delta reference encoding is
substituted on the fly with almost no cost (this is btw another reason
why a dumb copy of existing pack may not work universally either). But
in the common case, you might see the above as just the same as if git
did copy the pack file because it really only reads some data from a
pack and immediately writes that data out.
The bruteforce repacking is different because it simply doesn't concern
itself with existing deltas at all. It instead start everything from
scratch and perform the whole delta search all over for all objects.
This is what takes lots of resources and CPU cycles, and as you may
guess, is never used for fetch/clone requests.
Nicolas
^ permalink raw reply
* Re: Performance issue: initial git clone causes massive repack
From: Jon Smirl @ 2009-04-06 15:28 UTC (permalink / raw)
To: Nicolas Pitre
Cc: Junio C Hamano, david, Nicolas Sebrecht, Robin H. Johnson,
Git Mailing List, Shawn O. Pearce
In-Reply-To: <alpine.LFD.2.00.0904061042300.6741@xanadu.home>
On Mon, Apr 6, 2009 at 11:14 AM, Nicolas Pitre <nico@cam.org> wrote:
> On Mon, 6 Apr 2009, Jon Smirl wrote:
>
>> On Mon, Apr 6, 2009 at 10:19 AM, Nicolas Pitre <nico@cam.org> wrote:
>> > On Mon, 6 Apr 2009, Jon Smirl wrote:
>> >
>> >> First thing an initial clone does is copy all of the pack files from
>> >> the server to the client without even looking at them.
>> >
>> > This is a no go for reasons already stated many times. There are
>> > security implications (those packs might contain stuff that you didn't
>> > intend to be publically accessible) and there might be efficiency
>> > reasons as well (you might have a shared object store with lots of stuff
>> > unrelated to the particular clone).
>>
>> How do you deal with dense history packs? These packs take many hours
>> to make (on a server class machine) and can be half the size of a
>> regular pack. Shouldn't there be a way to copy these packs intact on
>> an initial clone? It's ok if these packs are specially marked as being
>> ok to copy.
>
> [sigh]
>
> Let me explain it all again.
>
> There is basically two ways to create a new pack: the intelligent way,
> and the bruteforce way.
>
> When creating a new pack the intelligent way, what we do is to enumerate
> all the needed object and look them up in the object store. When a
> particular object is found, we create a record for that object and note
> in which pack it is located, at what offset in that pack, how much space
> it occupies in its compressed form within that pack, , and if whether it
> is a delta or not. When that object is indeed a delta (the majority of
> objects usually are) then we also keep a pointer on the record for the
> base object for that delta.
>
> Next, for all objects in delta form which base object is also part of
> the object enumeration and obviously part of the same pack, we simply
> flag those objects as directly reusable without any further processing.
> This means that, when those objects are about to be stored in the new
> pack, their raw data is simply copied straight from the original pack
> using the offset and size noted above. In other words, those objects
> are simply never redeltified nor redeflated at all, and all the work
> that was previously done to find the best delta match is preserved with
> no extra cost.
Does this process cause random reads all over a 2GB pack file? Busy
servers can't keep a 2GB pack in memory.
sendfile() the 2GB pack to client is way more efficient. (assuming the
pack is marked as being ok to send).
>
> Of course, when your repository is tightly packed into a single pack,
> then all enumerated objects fall into the reusable category and
> therefore a copy of the original pack is indeed sent over the wire.
> One exception is with older git clients which don't support the delta
> base offset encoding, in which case the delta reference encoding is
> substituted on the fly with almost no cost (this is btw another reason
> why a dumb copy of existing pack may not work universally either). But
> in the common case, you might see the above as just the same as if git
> did copy the pack file because it really only reads some data from a
> pack and immediately writes that data out.
>
> The bruteforce repacking is different because it simply doesn't concern
> itself with existing deltas at all. It instead start everything from
> scratch and perform the whole delta search all over for all objects.
> This is what takes lots of resources and CPU cycles, and as you may
> guess, is never used for fetch/clone requests.
>
>
> Nicolas
>
--
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply
* Re: git diff bug?
From: Jeff King @ 2009-04-06 15:53 UTC (permalink / raw)
To: David Abrahams; +Cc: git
In-Reply-To: <1BF9172A-BE91-4D1C-932A-EB9FD79BA402@boostpro.com>
On Mon, Apr 06, 2009 at 05:09:32AM -0400, David Abrahams wrote:
> Hmm, so I tried sticking this .gitattributes in my repo
>
> *.el diff=el
> [diff "el"]
> xfuncname = "^(\\(def[a-z]+ .+)$"
>
> and git diff barfed with
As Michael explained, the first line goes into .gitattributes, and the
second two go into your .git/config.
The reason is that the first line is describing a property of files
in the repo: "*.el is of type 'el' for diffing". And thus it makes sense
for it to be committed along with the content in the repo.
But the latter two lines are about preference: "here is how _I_ would
like to generate diffs for el files". So they go in your personal config
which is not shipped with the repo. And most likely you would want to
put them not in per-repo config, but in your user config:
$HOME/.gitconfig.
All of that being said, it is obviously a documentation failure if it
didn't explain in which files the various parts go. If you don't mind,
can you skim over the documentation you read one more time and point out
where it led you wrong? Maybe we can make it a little clearer.
-Peff
^ permalink raw reply
* Re: Performance issue: initial git clone causes massive repack
From: Nicolas Pitre @ 2009-04-06 16:14 UTC (permalink / raw)
To: Jon Smirl
Cc: Junio C Hamano, david, Nicolas Sebrecht, Robin H. Johnson,
Git Mailing List, Shawn O. Pearce
In-Reply-To: <9e4733910904060828m414dfe7v66b19f7b4c5b670e@mail.gmail.com>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 970 bytes --]
On Mon, 6 Apr 2009, Jon Smirl wrote:
> On Mon, Apr 6, 2009 at 11:14 AM, Nicolas Pitre <nico@cam.org> wrote:
> > This means that, when those objects are about to be stored in the new
> > pack, their raw data is simply copied straight from the original pack
> > using the offset and size noted above. In other words, those objects
> > are simply never redeltified nor redeflated at all, and all the work
> > that was previously done to find the best delta match is preserved with
> > no extra cost.
>
> Does this process cause random reads all over a 2GB pack file? Busy
> servers can't keep a 2GB pack in memory.
The creation of a new pack follows the same object recency rule as the
ones it copies from, so the various reads should be perfectly
sequential.
> sendfile() the 2GB pack to client is way more efficient. (assuming the
> pack is marked as being ok to send).
Git is not a FTP server. Otherwise we would have stayed with the rsync
protocol.
Nicolas
^ permalink raw reply
* GNU patch: upcoming stable release
From: Andreas Gruenbacher @ 2009-04-06 16:13 UTC (permalink / raw)
To: git
Hello,
I am pleased to announce the next alpha release of GNU patch, available by
anonymous FTP from:
ftp://alpha.gnu.org/gnu/patch/
The code should be feature complete for the next stable release with only a
few minor bugfixes left in the queue. This is your chance to report more
bugs that still need to be addressed. Please expect the next stable release
to happen in about a month's time.
The last stable release dates back to June 2004 with version 2.5.9. I would
like to thank Paul Eggert for his work on GNU patch, and for making his code
repository available for import. A new project has been created on Savannah
with the new code repository and the bug-patch@gnu.org mailing list archive:
http://savannah.gnu.org/projects/patch
A lot of things have accumulated since version 2.5.9. The following user
visible changes have been made:
* A regression test suite has been added ("make check").
* A -m or --merge option has been added which will merge a patch file into
the original files similar to merge(1). See the patch(1) manual page for
documentation.
* Unless a filename has been specified on the command line, look only
for filenames in the patch until one has been found. This prevents
patch from tripping over garbage that isn't a patch. When conforming
to POSIX, this behavior is turned off and patch will ask for a
filename if none is found.
* All reject files have file name headers, which allows to use them
as regular patches.
* When a patch file modifies the same file more than once, patch makes
sure it backs up the original version of the file, rather than any
intermediary versions.
* In the above situation, if there are rejects in more than one of those
patches, the rejects are appended to the same reject file (rather then
overwriting themselves).
* The -r option works correctly even there are rejects in more than one
file. Use the - argument to discard rejects.
* Rejected hunks come out in unified diff format if the input patch was of
that format, otherwise in ordinary context diff form. Use the
--reject-format option to enforce either "context" or "unified" format.
The "diff -p" (--show-c-function) output is preserved.
Changed lines in context format reject files are correctly indicated
with '!' markers as the format defines. Added and removed lines are
still marked with '+' and '-', respectively.
* The file permissions of reject files are no longer set to match the files
they modify. Instead, they retain the default permissions. This is
consistent with reject files to which rejects of multiple files may be
written (-r option).
* The --binary option disables the heuristic for stripping CRs from
line endings in patches. This allows to preserve CRs even in mangled
patches, or in patches generated without the --binary option on non-POSIX
systems.
* Backup files for nonexisting files are now created with default
permissions rather than with mode 0: backup files with mode 0 were
causing problems with applications which do not expect unreadable
files.
* The -B, -Y, and -z options (--prefix, --basename-prefix, --suffix) now
imply the simple version control mode, and can be combined.
* Patch rejects more malformed normal format commands and checks for trailing
garbage. It now recognizes ed commands without addresses.
Please see the project's bug tracker for a list of known issues before
reporting those things again on the mailing list. (Postponed bugs are not
going to be addressed in the next stable release.)
Please email bugs or suggestions to <bug-patch@gnu.org>.
Thanks,
Andreas
^ permalink raw reply
* Re: Fetching SHA id's instead of named references?
From: Klas Lindberg @ 2009-04-06 16:22 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Git Users List
In-Reply-To: <20090406144047.GE23604@spearce.org>
On Mon, Apr 6, 2009 at 4:40 PM, Shawn O. Pearce <spearce@spearce.org> wrote:
> The problem is, upload-pack won't perform a reachability analysis
> to determine if a wanted SHA1 is reachable from a current ref.
> Instead it requires that the wanted SHA1 is *exactly* referenced
> by at least one ref.
I probably just don't understand this properly, so please correct me
as needed. My understanding is that
* git-fetch-pack looks at the local named reference to figure out the
SHA id "X" for the last locally available commit.
* git-upload-pack is given "X" as a delimiter for what to include in
the pack to send back to git-fetch-pack.
So if I have "X" and I know which remote "Y" I want (because someone
told me, or it's in a manifest), why shouldn't I be able to let
git-upload-pack search for "X" from "Y" if that is exactly what it
does anyway for named references? I accept that it may fail because
"X" is not reachable from "Y" (just give me a sensible error message).
> There's no reason to perform the reachability test on the server
> when you can move it onto the client, and that's exactly what
> git-submodule is doing. It fetches everything, and then assumes
> its reachable post fetch. Since the client has fetched everything,
> the client has the object if its reachable by the server.
Except it will not always be available even when it was reachable at
the source. Here's the real world example that forced me to reject the
use of the submodule command for distributed setups:
* Bob is located at site S where he sets up tree A with a submodule
B. He uses "submodule init" to initialize B, which will cause it to be
listed relative to S in A.
* Lisa, at site T, clones A and updates the submodule B. No problem
so far. Her list of submodules is inherited from S and works for
updating B.
* Lisa commits a new version of B and then a new version of A. Then
she asks Kent to merge her changes.
* Kent's clone will also have a submodules list that refers to site S
(and not T). Running "submodule update" after fetching from T fails
even though all the material is available at T, because Git is then
trying to fetch the new revision of B from S.
If you try to work around this by not using "submodule init", then you
get a saner tree that can be worked on in a truly serverless fashion,
like with plain git trees, but you have to implement a CM tool on top.
> If the object is no longer reachable by the server's refs (think
> branch rebased) then the object is actually in danger of being GC'd
> off of the server's object store.
This is alright and I would make sure all the refs I want to keep are
reachable from named references to keep git-gc from chomping stuff in
my local tree.
In the remote tree, the unnamed reference is either available or it
isn't. If someone made an unnamed reference unreachable and then
garbage-collected it, well so be it. Just tell the user that the
reference can't be found and may in fact not exist at all and you're
done. No exhaustive search necessary.
> One way we get away with this sort of thing in repo is, we only
> put SHA1s in our manifest that are published in branches that
> won't ever rewind or delete. Hence, its a moot point.
What is the syntax for that?
Anyway it's not a moot point. I may later want to use that revision of
the manifest to perform a checkout on every component listed by the
manifest. At that point I expect all the work trees to have exactly
the contents they "should" have for that old version of the manifest.
It's all about affordable reproducibility.
/Klas
^ permalink raw reply
* Re: Submodules can't work recursively because Git implements policy?
From: Klas Lindberg @ 2009-04-06 16:29 UTC (permalink / raw)
To: Shawn O. Pearce
Cc: Finn Arne Gangstad, Matthieu Moy, Johannes Schindelin,
Git Users List
In-Reply-To: <20090406145140.GG23604@spearce.org>
On Mon, Apr 6, 2009 at 4:51 PM, Shawn O. Pearce <spearce@spearce.org> wrote:
> What, like a secret shadow repository that you move the objects into?
>
> That could be very expensive in terms of disk IO if those objects
> are in large packs. You'd need to break the pack apart into the
> "ok" and "sekret" parts. Ick.
Well, ok. Just popping then?
Or adding the wrong publication to a forbidden fetch list?
>> But anyway: If I implement support for fetching SHA keys and full
>> recursive behaviour in the presence of submodules; would my patches
>> automatically be rejected because of the rationale for the current
>> behaviour?
>
> See my recent email (like ~10-15 minutes ago). It will be rejected
> due to the issue that unreachable objects are subjected to GC and
> you'd easily see your repository delete that data on the next "git
> gc" invocation. Automatic data destruction is not something that
> users come to git for.
Indeed not. But I don't want to suggest that named references
shouldn't be necessary. Just that it should be possible to fetch based
on the SHA key if that commit is (still) available on the remote end.
BR / Klas
^ permalink raw reply
* Re: [EGIT] [PATCH RFC v1 0/5] Add (static) ignore functionality to EGit
From: Ferry Huberts (Pelagic) @ 2009-04-06 16:46 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: git, Robin Rosenberg
In-Reply-To: <20090405210248.GA23604@spearce.org>
Shawn O. Pearce wrote:
> Ferry Huberts <ferry.huberts@pelagic.nl> wrote:
>> This is the first - early - code that adds ignore functionality to EGit.
>> Currently it reads in all ignore patterns upon workspace startup into an
>> ignore cache. From this cache the ignore state of a resource is evaluated
>> in the same fashion as git does.
>>
>> The code does not yet react to changes in ignore files but I'm planning to add
>> that soon and I can share a lot of code for that.
>>
>> I send this code to receive feedback and to give you insight into what I'm
>> doing with it. I'm new both to EGit programming and Eclipse programming so
>> there might be things that could be done more elegantly :-)
>
> Ok, I finally got a chance to review this series.
>
>
> We really want as much of the Git specific logic as we can in JGit
> under the BSD license. This has already been raised elsewhere in
> this thread.
>
ack.
> JGit and EGit are holding the line on Java 5 support; that means
> that String.isEmpty() must be spelled as String.length() == 0
> (isEmpty was added in Java 6).
ok
>
> Style nit: Don't put /* Constructors */, /* Methods */ or
> / * Public Methods */ comments in code, e.g.
> IgnoreProjectCache l.52-54 or GitIgnoreData l.58-61.
>
ok
> Style nit: Don't assign fields to their default values.
>
> E.g. Exclude.java l.25,33,42,.. these are being set to the
> same value that the JRE sets the field to if the field is not
> explicitly initialized. We find it much easier to read code when
> the defaults are assumed.
>
ok
> Style nit: Don't use "this." to refer to members.
>
> Your IDE should highlight field references differently than
> parameters, and a parameter should never shadow a field name,
> thus "this." is unnecessary and makes the code much more verbose
> to read. E.g. see Exclude.java 's constructor on l.87-108; I can't
> see the forest (the code) due to all the trees (this.) appearing.
>
ok
> IgnoreFileOutside: Ugh, our own implementation of IFile ?
>
> I'm worried about the long-term stability of the IFile API.
> Is it really frozen enough that we can implement it ourselves?
> Of course, this may be moot if much of the code was moved back
> to JGit.
>
when we convert the code to be in jgit we will not use this api.
this will disappear.
> IgnoreRepositoryCache: Why not put this into RepositoryMapping?
>
> Instead of caching it inside a static HashMap of GitIgnoreData,
> wouldn't it be better to put it into RepositoryMapping?
> The TrackOperation for example already has the RepositoryMapping
> handle in scope, saving a few lookup operations, and avoiding
> needing to manage this new additional static HashMap against leaks.
>
ok
>
> I kind of wanted to tie exclude processing (and attribute processing)
> into a TreeWalk, so that we can do an n-way merge against trees and
> working directories by tossing all of their AbstractTreeIterators
> into a single walk, possibly apply a path filter, and let the walk
> handle the per-directory ignore rules as it goes.
>
ok. but I need much more input than that from you on how to go about
moving the code into jgit. If you have ideas on what the rough
architecture should be of the ignore processing in jgit then please let
me know, I don't know that code at all and also don't know the approach
you'd like to take there with its architecture.
I've been thinking on and off about how to free the ignore processing
from eclipse specific apis ever since the egit/jgit issue came up. I
think it's not that hard to do, depending on the approach you'd like to
take.
you talk about TreeWalk. but what is it's prupose, in what context is it
called? etc. You can probably much faster explain that to me than I can
find out from the code (the egit code is much easier to place in context
than the jgit code I think)
> Most of your code seems to be built around the Eclipse IResource
> model, and the idea that it gets called for a single file path
> at a time, which may make it less efficient when we put it into a
> TreeWalk and apply the notion of entering and exiting a subdirectory.
>
the way it works now is more efficient than git itself (most of the
time), since we have a cache of the ignore patterns. I compared traces
of git itself and the plugin against eachother.
>
> OK, that's about all I have for now. Its reasonable, but still an
> early series.
>
yep.
please let's discuss moving it into jgit asap. so that I can complete
the feature.
BTW
In the meantime I've also added ignore preferences to the plugin on
which the user can specify whether the Eclipse Team Ignored Resources
should be taken into account. It defaults to yes. When set to no the
ignore processing complies strict to git behaviour.
looking forward to your input!
Ferry
^ permalink raw reply
* Re: Broken umlaut in my name, again
From: Jeff King @ 2009-04-06 16:47 UTC (permalink / raw)
To: Björn Steinbrink; +Cc: Marius Storm-Olsen, Junio C Hamano, git
In-Reply-To: <20090406114618.GF20356@atjola.homenet>
On Mon, Apr 06, 2009 at 01:46:18PM +0200, Björn Steinbrink wrote:
> On 2009.03.31 17:30:39 +0200, Björn Steinbrink wrote:
> > While it makes no sense to map some email address to an empty one, doing
> > things the other way around can be useful. For example when using
> > filter-branch with an env-filter that employs a mailmap to fix up an
> > import that created such broken commits with empty email addresses.
> >
> > Signed-off-by: Björn Steinbrink <B.Steinbrink@gmx.de>
>
> The umlaut (ö) in my name is broken in the commit that made it into
> git.git --> 5288dd58356e53d61e2b3804fc7d8d23c3a46ab3
The mail you sent that presumably became 5288dd58 looks fine (both the
From and body are properly marked as iso8859-1), and "git am" applies it
correctly here. I wonder if Junio did something unusual while applying.
-Peff
^ permalink raw reply
* Re: [EGIT] [PATCH RFC v1 0/5] Add (static) ignore functionality to EGit
From: Ferry Huberts (Pelagic) @ 2009-04-06 16:51 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: git, Robin Rosenberg
In-Reply-To: <20090405210248.GA23604@spearce.org>
Shawn O. Pearce wrote:
> JGit and EGit are holding the line on Java 5 support; that means
> that String.isEmpty() must be spelled as String.length() == 0
> (isEmpty was added in Java 6).
just looked in the project settings for org.spearce.egit.core and it has
java 1.5 style specified _and_ eclipse does not give me a warning on the
*.isEmpty() calls. Am i missing something here?
^ permalink raw reply
* Re: Fetching SHA id's instead of named references?
From: Nicolas Pitre @ 2009-04-06 16:55 UTC (permalink / raw)
To: Klas Lindberg; +Cc: Shawn O. Pearce, Git Users List
In-Reply-To: <33f4f4d70904060922t5c868ec0x89ed5891cf4b19c2@mail.gmail.com>
On Mon, 6 Apr 2009, Klas Lindberg wrote:
> In the remote tree, the unnamed reference is either available or it
> isn't. If someone made an unnamed reference unreachable and then
> garbage-collected it, well so be it. Just tell the user that the
> reference can't be found and may in fact not exist at all and you're
> done. No exhaustive search necessary.
Why can't you simply fetch the remote from its branch tip and then
figure out / checkout the particular unnamed reference you wish locally?
> I may later want to use that revision of the manifest to perform a
> checkout on every component listed by the manifest. At that point I
> expect all the work trees to have exactly the contents they "should"
> have for that old version of the manifest. It's all about affordable
> reproducibility.
Unlike with CVS/SVN, you don't need anything from the remote if you want
to checkout an old version. In particular, there is no need for you to
only fetch that old version from the remote. You just fetch everything
from the remote and then checkout the particular old version you wish.
There is just no real advantage to limit yourself to some old version
from the remote repository because that's what you want locally. Sure
you might be getting more data than needed, but usually not that much
due to git's good delta compression making extra versions almost free.
Nicolas
^ permalink raw reply
* Re: [EGIT] [PATCH RFC v1 0/5] Add (static) ignore functionality to EGit
From: Shawn O. Pearce @ 2009-04-06 17:03 UTC (permalink / raw)
To: Ferry Huberts (Pelagic); +Cc: git, Robin Rosenberg
In-Reply-To: <49DA3305.7090601@pelagic.nl>
"Ferry Huberts (Pelagic)" <ferry.huberts@pelagic.nl> wrote:
> Shawn O. Pearce wrote:
> > JGit and EGit are holding the line on Java 5 support; that means
> > that String.isEmpty() must be spelled as String.length() == 0
> > (isEmpty was added in Java 6).
>
> just looked in the project settings for org.spearce.egit.core and it has
> java 1.5 style specified _and_ eclipse does not give me a warning on the
> *.isEmpty() calls. Am i missing something here?
Your workspace default JRE must be set to a Java 6. Switch it to
Java 5 in the workspace settings.
--
Shawn.
^ permalink raw reply
* Re: [EGIT] [PATCH RFC v1 0/5] Add (static) ignore functionality to EGit
From: Sverre Rabbelier @ 2009-04-06 17:38 UTC (permalink / raw)
To: Ferry Huberts (Pelagic); +Cc: Shawn O. Pearce, git, Robin Rosenberg
In-Reply-To: <49DA3305.7090601@pelagic.nl>
Heya,
On Mon, Apr 6, 2009 at 18:51, Ferry Huberts (Pelagic)
<ferry.huberts@pelagic.nl> wrote:
> just looked in the project settings for org.spearce.egit.core and it has
> java 1.5 style specified _and_ eclipse does not give me a warning on the
> *.isEmpty() calls. Am i missing something here?
FYI, notice the #since annotation in the JavaDoc [0].
[0] http://java.sun.com/javase/6/docs/api/java/lang/String.html#isEmpty()
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* Re: git diff bug?
From: Matthieu Moy @ 2009-04-06 17:37 UTC (permalink / raw)
To: Jeff King; +Cc: David Abrahams, git
In-Reply-To: <20090406155303.GA3275@sigill.intra.peff.net>
Jeff King <peff@peff.net> writes:
> But the latter two lines are about preference: "here is how _I_ would
> like to generate diffs for el files".
... and they are commands to be executed. If they were in the
repository, and propagated with clone, then doing
git clone git://some.git/repo
cd repo
git diff
would execute arbitrary commands, which wouldn't be acceptable for
security reasons.
--
Matthieu
^ permalink raw reply
* [PATCH] 64-bit fix for date.c.
From: Bernd Ahlers @ 2009-04-06 17:26 UTC (permalink / raw)
To: git
Hello!
This unbreaks the localtime_r call on OpenBSD/sparc64 and removes
the following compiler warning.
"passing arg 1 of `localtime_r' from incompatible pointer type"
---
date.c | 4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/date.c b/date.c
index 1165d30..409a17d 100644
--- a/date.c
+++ b/date.c
@@ -871,13 +871,15 @@ unsigned long approxidate(const char *date)
int number = 0;
struct tm tm, now;
struct timeval tv;
+ time_t time_sec;
char buffer[50];
if (parse_date(date, buffer, sizeof(buffer)) > 0)
return strtoul(buffer, NULL, 10);
gettimeofday(&tv, NULL);
- localtime_r(&tv.tv_sec, &tm);
+ time_sec = tv.tv_sec;
+ localtime_r(&time_sec, &tm);
now = tm;
for (;;) {
unsigned char c = *date;
--
1.6.2.2
^ permalink raw reply related
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