login
Search
| From | Subject | Date |
|---|---|---|
| Shawn O. Pearce | [JGIT PATCH 0/4] Racy pack directory fixes
I noticed some "racy git" sort of problems with the pack directory.
I suspect JGit read the pack directory while a concurrent `git gc`
was still writing the outputs, leaving JGit missing a large part
of the repository because it never saw the final state. This short
series fixes it.
Unrelated to my other two series already sent today.
Shawn O. Pearce (4):
Avoid unnecessary stat when scanning packs in the objects directory
Make ObjectDirectory last modified time atomically updated with ...
| Jul 25, 3:52 pm 2009 |
| Shawn O. Pearce | [JGIT PATCH 1/4] Avoid unnecessary stat when scanning pa ...
We only care that the pack name exists in the directory at this stage
of processing. Performing a isFile() test against the pack file name
is likely to be slower than checking an in-memory HashSet, since the
OS call has to actually check the inode to determine whether or not
the name is a file, or some other node type. Since we already have
forced the OS to give us a complete listing of the paths, its just
faster to consult that existing list.
Signed-off-by: Shawn O. Pearce ...
| Jul 25, 3:52 pm 2009 |
| Shawn O. Pearce | [JGIT PATCH 4/4] Fix racy condition when a repository is ...
If the filesystem clock granularity is sufficiently large enough it
is possible for a repacking program such as `git repack` to change
the same directory more than once within the same modification time.
If JGit were to scan the directory between changes in the same
clock step it will never see the later edits, because the directory
modification time has not changed.
Instead we now keep track of the last time we read the directory.
If an object cannot be found on disk and the pack directory's ...
| Jul 25, 3:52 pm 2009 |
| Shawn O. Pearce | [JGIT PATCH 3/4] Don't create new pack lists if the dire ...
If we scan the directory and it hasn't changed since the last time we
scanned it, there is no reason to build a new PackList and update the
volatile reference. This just generates unnecessary garbage and may
make it more difficult to detect an unmodified directory.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
---
.../src/org/spearce/jgit/lib/ObjectDirectory.java | 18 ++++++++++++++----
1 files changed, 14 insertions(+), 4 deletions(-)
diff --git ...
| Jul 25, 3:52 pm 2009 |
| Shawn O. Pearce | [JGIT PATCH 2/4] Make ObjectDirectory last modified time ...
By moving the last modified time and the PackFile[] into the same
object and using that object as the atomic access unit we ensure
that the two values change atomically for all readers.
This refactoring step prepares the code so we can later fix a race
condition where the objects directory is modified multiple times in
the same filesystem clock window, but a reader scanned the directory
during that same clock window.
A nice cleanup performed here is to eliminate the null pointer value
from ...
| Jul 25, 3:52 pm 2009 |
| Dan Savilonis | Re: git format-patch from date never set
In the examples of mbox format I have found, the date in the From:
line is generally the same as in the Date: line, albeit in a more
ambiguous format. Further, the the git code treats it as a date and
attempts to set it. It remains at the default date only because
git_committer_info() is called without GIT_COMMITTER_DATE set.
So is the code misleading? Was it designed to just meet the minimal
requirement of having a date-like string to comform to the mbox
format? What's the disadvantage to ...
| Jul 25, 3:49 pm 2009 |
| Dan Savilonis | git format-patch from date never set
git format-patch always sets the date in the From: line to the git
default date, e.g.
From b9ff0ba6f3e228e1a8b67a25bc7be6b1da5ed1f3 Mon Sep 17 00:00:00 2001
The command uses GIT_COMMITTER_DATE as the date, but this env variable
is never set in cmd_format_patch(). Is this a bug or 'feature'?
--
Dan
--
| Jul 25, 2:39 pm 2009 |
| Alex Riesen | Re: git format-patch from date never set
Neither. This is not a date, but a part of "loosely defined" mbox format.
--
| Jul 25, 3:31 pm 2009 |
| Junio C Hamano | Re: git format-patch from date never set
Having it as a fixed date-looking string was to help /etc/magic entry
people may want to invent to detect format-patch output.
--
| Jul 25, 4:03 pm 2009 |
| Shawn O. Pearce | [JGIT PATCH 00/19] More Config class cleanup work
Yet another series to cleanup the Config class and its
implementations to be slightly more useful.
The later part of the series makes Config thread safe and introduces
caching of application-specific model instances as part of the
Config, making it more efficient for code to query for multiple
values at once.
This new caching feature is especially useful for ReceivePack on
the server side, where the values aren't expected to change between
connections, but connections come in at a steady ...
| Jul 25, 11:52 am 2009 |
| Shawn O. Pearce | [JGIT PATCH 01/19] Cleanup nonstandard references to enc ...
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
---
.../org/spearce/jgit/lib/ConcurrentRepackTest.java | 2 +-
.../org/spearce/jgit/revwalk/RevWalkTestCase.java | 3 +--
.../src/org/spearce/jgit/lib/ObjectWriter.java | 2 +-
.../jgit/revwalk/filter/PatternMatchRevFilter.java | 10 ++--------
.../org/spearce/jgit/util/RawSubStringPattern.java | 10 ++--------
5 files changed, 7 insertions(+), 20 deletions(-)
diff --git ...
| Jul 25, 11:52 am 2009 |
| Shawn O. Pearce | [JGIT PATCH 03/19] Make Config.escapeValue a private method
This method is only used by toText() as it generates the
value for an entry in the file. We don't want (or need)
to export it to our subclasses.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
---
.../src/org/spearce/jgit/lib/Config.java | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/org.spearce.jgit/src/org/spearce/jgit/lib/Config.java b/org.spearce.jgit/src/org/spearce/jgit/lib/Config.java
index 76f780f..a2f5c6a 100644
--- ...
| Jul 25, 11:52 am 2009 |
| Shawn O. Pearce | [JGIT PATCH 02/19] Delete incorrect Javadoc from Config' ...
I don't know how this Javadoc got here, but it predates the code
refactor done by Constantine Plotnikov in 2564768e63.
The documentation is incorrect, as the method returns a single string
but the summary line says a list. Since we usually don't document
a private method I'm removing the documentation block rather than
correcting it.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
---
.../src/org/spearce/jgit/lib/Config.java | 11 -----------
1 files changed, 0 ...
| Jul 25, 11:52 am 2009 |
| Robin Rosenberg | Re: [JGIT PATCH 02/19] Delete incorrect Javadoc from Con ...
Why do you think so? The getRawString before his patch did not have any
javadoc. It was added there in that patch.
-- robin
--
| Jul 25, 1:32 pm 2009 |
| Shawn O. Pearce | Re: [JGIT PATCH 02/19] Delete incorrect Javadoc from Con ...
Oh. I failed to look at the history, I just assumed he carried it
over in the refactoring. Well, it still should die.
--
Shawn.
--
| Jul 25, 1:33 pm 2009 |
| Shawn O. Pearce | [JGIT PATCH 04/19] Allow a RemoteConfig to use the more ...
A RemoteConfig can be parsed from any Config type object, not just
the RepositoryConfig object. This change makes it easier to use
other types of Config storage, such as in unit tests.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
---
.../org/spearce/jgit/transport/RemoteConfig.java | 15 ++++++++-------
1 files changed, 8 insertions(+), 7 deletions(-)
diff --git a/org.spearce.jgit/src/org/spearce/jgit/transport/RemoteConfig.java ...
| Jul 25, 11:52 am 2009 |
| Shawn O. Pearce | [JGIT PATCH 08/19] Extract the test specific SystemReade ...
We may need this in tests that don't extend off RepositoryTestCase,
as not all tests require a local Git repository to be created in
the host filesystem.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
---
.../tst/org/spearce/jgit/lib/MockSystemReader.java | 78 ++++++++++++++++++++
.../org/spearce/jgit/lib/RepositoryConfigTest.java | 49 ++++++------
.../org/spearce/jgit/lib/RepositoryTestCase.java | 56 +-------------
3 files changed, 107 insertions(+), 76 deletions(-)
create ...
| Jul 25, 11:52 am 2009 |
| Shawn O. Pearce | [JGIT PATCH 10/19] Test for the config file when creatin ...
If the configuration file already exists then we should assume that
the repository also exists. Rather than computing the file name
we should rely upon the computation done in the constructor, whose
result is held in the RepositoryConfig's file property.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
---
.../src/org/spearce/jgit/lib/Repository.java | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git ...
| Jul 25, 11:52 am 2009 |
| Shawn O. Pearce | [JGIT PATCH 11/19] Remove the map lookup for values in Config
Update operations are already O(N) time in the config file, as we
scan through every entry in the file, in order, looking to see if
it matches the key we need to mutate. As most configurations are
rather small in size the running time is trivial. Doing the same
for lookup simplifies our code considerably.
Applications really want a different type of fast lookup strategy.
Instead of by key lookups they want something like CoreConfig
or RemoteConfig to be cached and quickly obtainable on ...
| Jul 25, 11:52 am 2009 |
| Shawn O. Pearce | [JGIT PATCH 17/19] Move repository config creation fully ...
Rather than having the core properties initialized in two different
locations its cleaner to do all of the setup work here in one place,
in case we need to make any further changes to the repository create
code path.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
---
.../src/org/spearce/jgit/lib/Repository.java | 5 ++---
.../src/org/spearce/jgit/lib/RepositoryConfig.java | 9 ---------
2 files changed, 2 insertions(+), 12 deletions(-)
diff --git ...
| Jul 25, 11:53 am 2009 |
| Shawn O. Pearce | [JGIT PATCH 13/19] Make Config thread safe by using copy ...
It is relatively rare that the Config instance is modified from
application code. When it is, we usually are working on a small
set of values read from .git/config or ~/.gitconfig. Making the
class thread-safe through basic copy-on-write semantics for its
inner collection of entries simplifies the locking and permits us
to optimize for the much more common read path.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
---
.../src/org/spearce/jgit/lib/Config.java | 85 ...
| Jul 25, 11:52 am 2009 |
| Shawn O. Pearce | [JGIT PATCH 15/19] Cache Config subsection names when re ...
Using the SectionParser based cache allows us to read through the
configuration once to produce the set of available subsections,
but then reuse that set in the future. This makes lookups like
"find all remotes" more efficient.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
---
.../src/org/spearce/jgit/lib/Config.java | 42 +++++++++++++++----
1 files changed, 33 insertions(+), 9 deletions(-)
diff --git a/org.spearce.jgit/src/org/spearce/jgit/lib/Config.java ...
| Jul 25, 11:52 am 2009 |
| Shawn O. Pearce | [JGIT PATCH 16/19] Refactor author/committer lookup to u ...
The author and committer don't typically change when processing,
so we can maintain them in a cached entity just like we do with
the TransferConfig and the CoreConfig.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
---
.../org/spearce/jgit/lib/RepositoryConfigTest.java | 29 ++--
.../src/org/spearce/jgit/lib/RepositoryConfig.java | 56 ++------
.../src/org/spearce/jgit/lib/UserConfig.java | 149 ++++++++++++++++++++
3 files changed, 173 insertions(+), 61 deletions(-)
create ...
| Jul 25, 11:52 am 2009 |
| Shawn O. Pearce | [JGIT PATCH 19/19] Use Config cache for fetch and receiv ...
Rather than parsing the fields on each transfer we now parse the
fields once and cache them in the Config object, under a unique
section key for the fetch or receive direction. This permits the
keys to be scanned only once, rather than per-request.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
---
.../jgit/transport/BasePackFetchConnection.java | 21 ++++++++-
.../org/spearce/jgit/transport/ReceivePack.java | 45 ++++++++++++++++----
2 files changed, 55 insertions(+), 11 ...
| Jul 25, 11:53 am 2009 |
| Shawn O. Pearce | [JGIT PATCH 18/19] Use Config SectionParser cache to sto ...
Rather than looking up the boolean each time we start a new connection
in a repository we now cache it in the configuration cache under a key
that is unique to the daemon service.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
---
.../org/spearce/jgit/transport/DaemonService.java | 30 ++++++++++++++++----
1 files changed, 24 insertions(+), 6 deletions(-)
diff --git a/org.spearce.jgit/src/org/spearce/jgit/transport/DaemonService.java ...
| Jul 25, 11:53 am 2009 |
| Shawn O. Pearce | [JGIT PATCH 09/19] Refactor Config hierarchy to make IO ...
Accessing a config file may or may not require IO, e.g. if we are
reading a file that was already loaded from a blob in the repository
then there is no additional IO required. Moving the IO portions out
of the base Config class helps to isolate it to only where we really
know we have to do IO, making it easier to handle the IO conditions.
This makes it easier to deal with test cases for config files, as
we no longer need to perform local disk IO just to test the parse
and formatting ...
| Jul 25, 11:52 am 2009 |
| Shawn O. Pearce | [JGIT PATCH 12/19] Return base values first from Config. ...
C Git's `git config --get-all foo.bar` returns the base configuration
values for foo.bar (aka those found in /etc/gitconfig or ~/.gitconfig)
before the repository specific configuration values for foo.bar. To
better match C Git behavior when processing a multi-value key we must
do the same in our getStringList() method.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
---
.../src/org/spearce/jgit/lib/Config.java | 24 +++++++++++++++----
1 files changed, 19 insertions(+), 5 ...
| Jul 25, 11:52 am 2009 |
| Shawn O. Pearce | [JGIT PATCH 14/19] Support cached application models in ...
The Config.SectionParser acts as a key into a cache of model object
instances, but also knows how to create its model instance if the
cache does not contain the corresponding instance.
Because we don't keep track of which keys were accessed by a parser
when it created its model, we discard the entire cache anytime any
key is modified, forcing all models to reparse on the next access.
Both CoreConfig and TransferConfig are trivial to switch to this
method of access, although the typical get ...
| Jul 25, 11:52 am 2009 |
| Shawn O. Pearce | [JGIT PATCH 05/19] Use type specific sets when creating ...
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
---
.../src/org/spearce/jgit/lib/Repository.java | 5 ++---
.../src/org/spearce/jgit/lib/RepositoryConfig.java | 4 ++--
2 files changed, 4 insertions(+), 5 deletions(-)
diff --git a/org.spearce.jgit/src/org/spearce/jgit/lib/Repository.java b/org.spearce.jgit/src/org/spearce/jgit/lib/Repository.java
index 1076fe1..98a276b 100644
--- a/org.spearce.jgit/src/org/spearce/jgit/lib/Repository.java
+++ ...
| Jul 25, 11:52 am 2009 |
| Shawn O. Pearce | [JGIT PATCH 06/19] Move SystemReader out of RepositoryConfig
Reading basic properties of the JVM has nothing to do with reading
a Git style configuration file for a repository, or for the current
user account. Instead pull all of that logic into its own abstract
class, and provide a default implementation available through a
singleton pattern.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
---
.../org/spearce/jgit/lib/RepositoryConfigTest.java | 11 +---
.../org/spearce/jgit/lib/RepositoryTestCase.java | 9 ++-
...
| Jul 25, 11:52 am 2009 |
| Shawn O. Pearce | [JGIT PATCH 07/19] Correct user config to be of type Fil ...
The user's ~/.gitconfig file is a file, but not a repository specific
file. Since RepositoryConfig has been refactored into base classes
that handle file based configuration, we no longer need to use the
RepositoryConfig type to access ~/.gitconfig.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
---
.../src/org/spearce/jgit/lib/RepositoryConfig.java | 4 ++--
.../src/org/spearce/jgit/util/SystemReader.java | 5 +++--
2 files changed, 5 insertions(+), 4 deletions(-)
diff ...
| Jul 25, 11:52 am 2009 |
| Robin Rosenberg | Re: [JGIT PATCH 09/19] Refactor Config hierarchy to make ...
This one does not apply for the Config class here.
-- robin
--
| Jul 25, 3:54 pm 2009 |
| Shawn O. Pearce | Re: [JGIT PATCH 09/19] Refactor Config hierarchy to make ...
Did you apply with --whitespace=strip or something and fall afoul
of a merge conflict due to changed context?
--
Shawn.
--
| Jul 25, 3:55 pm 2009 |
| Robin Rosenberg | Re: [JGIT PATCH 09/19] Refactor Config hierarchy to make ...
I tried both ways.
Config.java looks (partially) like this:
--------------------------
import java.util.Map;
import java.util.Set;
/**
----------------------------
and the patch looks (partially again) like this:
@@ -55,19 +49,18 @@
import java.util.Map;
import java.util.Set;
+import org.spearce.jgit.errors.ConfigInvalidException;
import org.spearce.jgit.util.StringUtils;
+
/**
----------------
So the import among other things, does not match.
-- robin
--
| Jul 25, 4:34 pm 2009 |
| Shawn O. Pearce | Re: [JGIT PATCH 09/19] Refactor Config hierarchy to make ...
You missed the patch where I added StringUtils. See "[PATCH]
Ensure Config readers handle case insensitive names correctly"
from Friday Jul 24.
--
Shawn.
--
| Jul 25, 4:38 pm 2009 |
| Daniel Barkalow | [PATCH 3/3] git-http-fetch: not a builtin
From: Linus Torvalds <torvalds@linux-foundation.org>
This splits up git-http-fetch so that it isn't built-in.
It also removes the general dependency on curl, because it is no
longer used by any built-in code.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Daniel Barkalow <barkalow@iabervon.org>
---
This is Linus's original patch, except that I actually dropped the -lcurl
and such, since, between this and the beginning of my series, it is
possible.
...
| Jul 25, 10:51 am 2009 |
| Daniel Barkalow | [PATCH 2/3] Use an external program to implement fetchin ...
Use the transport shim mechanism to fetch by http (and ftp, etc).
Signed-off-by: Daniel Barkalow <barkalow@iabervon.org>
---
Makefile | 5 ++
shim-curl.c | 132 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++
transport.c | 136 +----------------------------------------------------------
3 files changed, 138 insertions(+), 135 deletions(-)
create mode 100644 shim-curl.c
diff --git a/Makefile b/Makefile
index 01efc73..d3dd2ed 100644
--- a/Makefile
+++ b/Makefile
@@ ...
| Jul 25, 10:51 am 2009 |
| Daniel Barkalow | [PATCH 1/3] Add support for external programs for handli ...
transport_get() can call transport_shim_init() to have list and
fetch-ref operations handled by running a separate program as:
git shim-<something> <remote> [<url>]
This program then accepts, on its stdin, "list" and "fetch <hex>
<name>" commands; the former prints out a list of available refs and
either their hashes or what they are symreefs to, while the latter
fetches them into the local object database and prints a newline when done.
Signed-off-by: Daniel Barkalow ...
| Jul 25, 10:51 am 2009 |
| Johannes Schindelin | Re: [PATCH 1/3] Add support for external programs for ha ...
Hi,
I wonder if this cannot be integrated into the git-vcs stuff; after all,
they do pretty much the same things, except that the vcs helpers are
pretty dumb, and the shim helpers are not as dumb.
I could imagine that the name of the helper could reveal its capability to
act as a shim helper: git-vcs-shim-http
Ciao,
Dscho
--
| Jul 25, 11:19 am 2009 |
| Linus Torvalds | Re: [PATCH 1/3] Add support for external programs for ha ...
Wonderful.
I tested the series, and now there is (not surprisingly, but I made sure
to test anyway) no difference what-so-ever between NO_CURL and default,
and 'ldd' looks nice.
Plus it looks like that whole "shim" thing is a good idea in general, in
that it allows a much more flexible model for fetching/pushing.
So a very big Acked-by: from me for the series. I didn't test that http:
works with it, but I don't personally even care, so I'd ack it even
without that ;)
Btw, ...
| Jul 25, 11:25 am 2009 |
| Shawn O. Pearce | Re: [PATCH 1/3] Add support for external programs for ha ...
I hate to be a nit, but why this format and not the one that is
produced by `git ls-remote` and the native protocol? I know its
pretty arbitrary either way, but since we already have a history
of using "SHA1 ref\n" why not continue that tradition here?
--
Shawn.
--
| Jul 25, 11:45 am 2009 |
| Daniel Barkalow | Re: [PATCH 1/3] Add support for external programs for ha ...
In the VCS protocol, the SHA1 is generally not known when simply listing
refs, so I didn't have a useless initial field in that protocol; I just
inherited having the line start with the name for this protocol.
In any case, I want to be able to support symrefs, so an extension to the
tradition is required, but putting @<dest> before the name instead of
after is easy enough.
-Daniel
*This .sig left intentionally blank*
--
| Jul 25, 12:09 pm 2009 |
| Linus Torvalds | Re: [PATCH 1/3] Add support for external programs for ha ...
Just in case people wonder _why_, here is a profile from before and after.
Note how big a deal the page faulting, unmapping (TLB flushes etc), and
fork() is (copy_page_range()).
And notice how the biggest user space cost - even after the change - is
do_lookup_x() in the dynamic loader. But before the change it was the very
top entry, and you had things like strcmp and _dl_relocate_object pretty
high too. Not to mention that you got just a lot _more_ munmap's and page
faults:
- ...
| Jul 25, 12:09 pm 2009 |
| Steven Noonan | Re: [PATCH 1/3] Add support for external programs for ha ...
On Sat, Jul 25, 2009 at 12:25 PM, Linus
But more importantly, how fast can your machine compile the kernel?
--
| Jul 25, 2:08 pm 2009 |
| Linus Torvalds | Re: [PATCH 1/3] Add support for external programs for ha ...
Without ccache? One minute. With ccache? 16 seconds.
Linus
--
| Jul 25, 2:14 pm 2009 |
| Michael Bergin | Git Option/Subcommand Processing Library?
Is there a library containing just the option and subcommand
processing code from git? I saw a post about gitopt but can't find a
project with that name. If not is there any problem with me doing
this? Thanks.
- Mike Bergin
--
| Jul 25, 9:28 am 2009 |
| Johannes Schindelin | Re: Git Option/Subcommand Processing Library?
Hi,
The "library" is contained in the files parse-options.[ch] in git.git. I
Not if you abide by the license of git.git, which is GPLv2.
Ciao,
Dscho
--
| Jul 25, 9:32 am 2009 |
| Michael Bergin | Re: Git Option/Subcommand Processing Library?
Thanks for the pointers. I also want to create a generic library for
command facades like git. For that I will probably use git.c as a
guide but to make it generic I would need to add/rearrange code.
GPLv2 works fine for my purposes. I hope this isn't an offensive
question or anything but would releasing just the library under LGPL
be considered?
--
| Jul 25, 12:51 pm 2009 |
| Johannes Schindelin | Re: Git Option/Subcommand Processing Library?
Hi,
You need to ask all authors of all the code you reuse. I, for one, have
no objections.
Ciao,
Dscho
--
| Jul 25, 4:18 pm 2009 |
| Geoffrey Irving | [PATCH] git fast-export: add --no-data option
When using git fast-export and git fast-import to rewrite the history
of a repository with large binary files, almost all of the time is
spent dealing with blobs. This is extremely inefficient if all we want
to do is rewrite the commits and tree structure. --no-data skips the
output of blobs and writes SHA-1s instead of marks, which provides a
massive speedup.
Signed-off-by: Geoffrey Irving <irving@naml.us>
---
I've already done all I need with this change (for now, at least), but
here it ...
| Jul 25, 6:45 am 2009 |
| Johannes Schindelin | Re: [PATCH] git fast-export: add --no-data option
Hi,
ACK. I was looking for such an option recently, and was disappointed that
it was not there yet.
Ciao,
Dscho
--
| Jul 25, 7:28 am 2009 |
| Junio C Hamano | Re: [PATCH] git fast-export: add --no-data option
Shouldn't this be --[no-]data option that defaults to true? Otherwise you
--
| Jul 25, 10:25 am 2009 |
| Johannes Schindelin | Re: [PATCH] git fast-export: add --no-data option
Hi,
Maybe
OPT_NEGBIT(0, "data", &no_data,
"Skip output of blob data", 1),
Hmm?
Ciao,
Dscho
--
| Jul 25, 10:44 am 2009 |
| Robin Rosenberg | Re: [JGIT] Re: blinking test WindowCacheGetTest.testCach ...
Could it be threading-related (cache). I've never seen it on the machine where I build for
the update site and it is a single core machine, but I "this" machine that has two cores it happens, not
as offen as 1/6, but enough to annoy me a bit, perhaps 1/20. If it is related to bad synchronization
it should happen more often the more cores you have.
-- robin
--
| Jul 25, 10:34 am 2009 |
| Shawn O. Pearce | Re: [JGIT] Re: blinking test WindowCacheGetTest.testCach ...
No, its not threading related. I think I at least partially
understand what is going on.
WindowCache's base class, OffsetCache, does evictions by randomly
selecting a starting point in the table, and then scanning at most
evictBatch segments of the table before giving up.
When testCache_TooSmallLimit needs to access another window it must
first evict the current window, as the cache size is set to exactly
1 window in this test.
If the RNG selects the starting point at an empty segment, ...
| Jul 25, 12:42 pm 2009 |
| Shawn O. Pearce | [JGIT PATCH] Fix WindowCacheGetTest.testCache_TooSmallLi ...
Ever since 2d77d30b5f when I rewrote WindowCache we have been seeing
random failures inside of the TooSmallLimit test case.
These test failures have been occurring because the cache contained
more open bytes than it was configured to permit.
The cache was permitted to open more bytes than its configured limit
because the eviction routine was always skipping the last bucket
under some conditions. If the cache table was sized the same as its
evictBatch, which happens for any fairly small ...
| Jul 25, 1:00 pm 2009 |
| Robin Rosenberg | Re: [JGIT PATCH] Fix WindowCacheGetTest.testCache_TooSma ...
We should have a test for that then.
-- robin
--
| Jul 25, 4:25 pm 2009 |
| Shawn O. Pearce | Re: [JGIT PATCH] Fix WindowCacheGetTest.testCache_TooSma ...
We did, this one. :-)
--
Shawn.
--
| Jul 25, 4:30 pm 2009 |
| Martin Koegler | Re: [PATCH/RFC 10/10] gitweb: Create links leading to 'b ...
The same question can be asked for gitweb itself:
Why is it a single perl file and not splited in many different
modules?
mfg Martin Kögler
--
| Jul 25, 3:46 am 2009 |
| Jakub Narebski | Re: [PATCHv2 00/10] gitweb: 'blame' view improvements
Yes, it does. In particular it fixes my mistake about need for in
unquote_maybe in "gitweb: Use "previous" header of git-blame -p in
'blame' view". And that is the only change (except extending commit
message) in a6be48b^..3643cc0.
I see that I forgot to mark "gitweb: Add -partial_query option to href()
subroutine" as RFC; it isn't I think strictly necessary. But that is
why I put it in separate commit: to easy delete it or revert if deemed
not needed.
--
Jakub ...
| Jul 24, 5:10 pm 2009 |
| Junio C Hamano | Re: [PATCH 02/10] gitweb: Mark boundary commits in 'blam ...
"boundary" means that "blame low..hight file" attributed the line to the
"low" commit, not because the commit introduced the line, but because the
user said not to bother digging further.
I had an assumption that in such a bounded blame, lines attributed to the
boundary commit are not very interesting (they belong to a distant stable
past that the user does not care much about, as opposed to more recent
breakages), and that is exactly the same reasoning behind the -b option of
"git blame" ...
| Jul 24, 5:13 pm 2009 |
| Jakub Narebski | Re: [PATCH 02/10] gitweb: Mark boundary commits in 'blam ...
Well, currently 'blame' view in gitweb doesn't allow to limit revision
range from below, i.e. to state "low" commit; it doesn't use 'hpb'
Well, I have thought that only boundary commits can be without previous
[blame] commit, but I noticed that it is not the case: see 04/10. But
some of that remains of my mistaken belief can resonate in commit
message... ;-)
--
Jakub Narebski
Poland
--
| Jul 24, 5:32 pm 2009 |
| Junio C Hamano | Re: [PATCH 02/10] gitweb: Mark boundary commits in 'blam ...
Yes, but I think it is the same thing. The initial import of a tarball,
that is "a distant stable past as opposed to more recent breakages".
--
| Jul 24, 5:39 pm 2009 |
| Jakub Narebski | Re: [PATCHv2/RFC 09/10] gitweb: Incremental blame (proof ...
Note that it is something that we unfortunately would have to deal with,
namely playing catch-up with new features in gitweb's 'blame' view,
"duplicating" quite a bit of code (well, rewriting Perl code in
JavaScript). But this is, I think, unfortunately unavoidable, unless
we move to generating JavaScript code from Perl, e.g. using CGI::Ajax
(something that GWT does with Java and JavaScript).
--
Jakub Narebski
Poland
--
| Jul 25, 12:28 pm 2009 |
| Johannes Sixt | Re: [PATCH] git init: optionally allow a directory argument
This test will require POSIXPERM prerequisite.
-- Hannes
--
| Jul 25, 12:45 am 2009 |
| Alex Scarborough | Re: [PATCH] git init: optionally allow a directory argument
The use case makes sense. This helps make git init be a bit more
consistent
with git clone, which can take a trailing target.
For the code, I would replace the direct use of mkdir with
safe_create_dir.
Otherwise it looks fine.
-Alex Scarborough
--
| Jul 24, 11:41 pm 2009 |
| Daniel Pittman | Re: [PATCH] git init: optionally allow a directory argument
It still surprises me that git doesn't do this, since it is at odds with
almost every other version control system I have on hand or experience with,
other than CVS; Subversion, svk, Bazaar and Mercurial all take a trailing
target argument.
CVS and monotone take an option to specify where; only darcs is like git and
uses the current directory as the target.
So, from where I sit it makes sense to have 'git init foo' create a 'foo'
directory and repository below the current ...
| Jul 24, 8:13 pm 2009 |
| Junio C Hamano | Re: [PATCH] git init: optionally allow a directory argument
Heh, I knew it ;-)
Thanks.
--
| Jul 25, 2:26 am 2009 |
| Junio C Hamano | Re: [PATCH] git init: optionally allow a directory argument
But I have to wonder if we would also want to allow
$ git init --bare project/repo-000.git
when you do not even have "project" directory. After all, we are talking
about people who do not bother "mkdir repo-000.git", so instead of doing
equivalent of "mkdir project/repo-000.git", it would make more sense to do
an equivalent of "mkdir -p project/repo-000.git" instead.
Here is a patch to do so on top of yours, possibly you may want to squash
in.
builtin-init-db.c | 19 ...
| Jul 24, 11:41 pm 2009 |
| Eric Wong | Re: git svn fetches the same revision multiple times for ...
Hi Robert,
Yes, this is a known problem with some repositories and there's no
automatic/easy[1] way to handle it with globbing tags/* or branches/*.
You can try to track each tagged project independently or to setup
individual fetche lines (like the one generated for trunk). in
.git/config for each tag/branch.
[1] - Unfortunately SVN allows way too much freedom and thus ambiguity
in how it treats tags/branches and that doesn't allow mapping those
things to git very easily.
--
Eric ...
| Jul 25, 3:51 am 2009 |
| Nanako Shiraishi | (No subject)
Subject: [PATCH] Documentation/config.txt: a variable can be defined on the section header line
Signed-off-by: Nanako Shiraishi <nanako3@lavabit.com>
---
Quoting Junio C Hamano <gitster@pobox.com>:
> Nanako Shiraishi <nanako3@lavabit.com> writes:
>
>> Isn't this a syntax error?
>>
>> Documentation/config.txt says this.
>
> Even if it were, I think it would be nice to allow it. I'll have to
> re-read Alex's patch, but I thought it was sane. Perhaps we can update
> the ...
| Jul 24, 5:28 pm 2009 |
| Johannes Schindelin | Re: [PATCH 1/2] Make section_name_match start on '[', an ...
Hi,
Is this not unnecessary, given that we only call that function when we
I was a bit surprised that "offset" is not used further in your patch, but
I saw that 2/2 uses it.
So except for the unnecessary test, I like your patches (read: ACK).
Ciao,
Dscho
--
| Jul 25, 7:09 am 2009 |
| Johannes Schindelin | Re: [PATCH 2/2] After renaming a section, print any trai ...
Hi,
Thanks for making me aware of the patches. I just sent out a reply.
Ciao,
Dscho
--
| Jul 25, 7:10 am 2009 |
| Alex Vandiver | Re: [PATCH 1/2] Make section_name_match start on '[', an ...
Yes. However, given that I had changed the calling convention for the
code, (it used to be passed the string starting just _inside_ the
'['), I wanted to make the new calling convention clearer, and catch
any places that were using the old convention.
Yeah, this hunk should probably have gone in 2/2 instead.
- Alex
--
Networking -- only one letter away from not working
--
| Jul 25, 10:18 am 2009 |
| Junio C Hamano | Re: [PATCH 1/2] Make section_name_match start on '[', an ...
It's Ok. I do not think this is performance critical part of the system,
and I'd feel safer with a bit of defensive programming like this,
especially because "git config" that writes (reader is Ok) has
I actually thought about suggesting to squash these two patches into one,
as the change in [1/2] only makes sense in the context of the [2/2], but
decided against it.
I haven't applied (actually, I didn't even notice until this morning) the
small documentation update from Nana. Have any ...
| Jul 25, 10:39 am 2009 |
| Johannes Schindelin | Re: [PATCH 1/2] Make section_name_match start on '[', an ...
Hi,
No need to change anything, Junio already applied your patches.
Ciao,
Dscho
--
| Jul 25, 10:41 am 2009 |
| Eric Wong | Re: git-svn error: RA layer request failed: PROPFIND req ...
Hi Timothy,
Thanks for the bug report and patch, i'll push it out shortly. I'm
curious, do you happen to know which version of Subversion the server
was running? I'm unable to reproduce the problem, but I wouldn't be
surprised if it's only a problem with newere versions. Thanks.
--
Eric Wong
--
| Jul 25, 2:36 am 2009 |
| Thomas Rast | Re: [PATCH] git-add -p: be able to undo a given hunk
I'd rather implement this as part of the generic "worktree/index log"
that was proposed a while back, where any index- or
worktree-overwriting operation that actually discards data would save
the lost state in a special reflog. That way people won't complain
because 'git checkout -p -- $file' <press a> saved their state, but
'git checkout -- $file' didn't, even though they should be equivalent.
--
Thomas Rast
trast@{inf,student}.ethz.ch
--
| Jul 25, 2:35 am 2009 |
| Junio C Hamano | Re: [PATCH] git-add -p: be able to undo a given hunk
Yeah, such a stash entry would be more like "trash can". It is not
"to-be-deleted" but "have been deleted, but you _could_ resurrect".
It may not be a bad idea to do it that way, or perhaps "git checkout -p"
can automatically create such a trash can while undoing the local changes
in the work tree.
--
| Jul 24, 5:54 pm 2009 |
| Pierre Habouzit | Re: [PATCH] git-add -p: be able to undo a given hunk
Very cool idea, it's even better than creating a revert patch.
Note that to undermine the "dirty stash list" effect we could have
quite easily different stash queues if it's badly needed, so it sounds
like a moot point to me.
--
Intersec <http://www.intersec.com>
Pierre Habouzit <pierre.habouzit@intersec.com>
Tél : +33 (0)1 5570 3346
Mob : +33 (0)6 1636 8131
Fax : +33 (0)1 5570 3332
37 Rue Pierre Lhomme
92400 Courbevoie
| Jul 25, 7:48 am 2009 |
| Pierre Habouzit | Re: [PATCH] git-add -p: be able to undo a given hunk
FWIW it's what I was doing so far, and it's not very efficient for many
patterns, you talked about the bit where you want to keep some of the
debug, for this one I used to do that:
while I have meaning full commits to do:
git add -p; commit;
git add -p the things I want to trash and commit
git stash
git reset --hard HEAD~1
git stash apply
That sucks.
Another thing is that: if you have _many_ commits to do, you have to
refuse the same hunks (or worse edit) all over the place. ...
| Jul 25, 7:52 am 2009 |
| Pierre Habouzit | Re: [RFC PATCH v2 2/3] Introduce git-discard
FWIW, as git checkout -- <path> is already doing that, and that
git-discard is clearly something meant as some UI sugar, I would make
that operation a "safe" porcelain by puting the discarded hunks in a
stash.
I'm shamelessly stealing this idea from Jeff, but it's probably an
excellent idea to have a strash¹. It makes git even safer to use,
especially to beginners, to whom we would talk about git-discard instead
of git checkout.
¹: stash-trash
--
Intersec ...
| Jul 25, 7:58 am 2009 |
| Thomas Rast | [RFC PATCH v3 2/5] builtin-add: refactor the meat of int ...
This moves the call setup for 'git add--interactive' to a separate
function, as other users will call it without running
validate_pathspec() first.
Signed-off-by: Thomas Rast <trast@student.ethz.ch>
---
builtin-add.c | 43 +++++++++++++++++++++++++++++--------------
commit.h | 2 ++
2 files changed, 31 insertions(+), 14 deletions(-)
diff --git a/builtin-add.c b/builtin-add.c
index 581a2a1..c422a62 100644
--- a/builtin-add.c
+++ b/builtin-add.c
@@ -131,27 +131,27 @@ static void ...
| Jul 25, 2:29 pm 2009 |
| Thomas Rast | [RFC PATCH v3 0/5] {checkout,reset,stash} --patch
Luckily "reset" is exactly symmetrical to "add", so that's not too
Unfortunately there are some subtleties here. In the 'git checkout
HEAD -- $file' case, we overwrite both worktree and index. So
morally, if you select a hunk for checking out it should be reverse
applied to both, too. However, that may not always be possible.
[One possible change to checkout -p would be to reverse the direction
of hunks as shown. Currently it's more in the "discard" spirit: you
made the change shown ...
| Jul 25, 2:29 pm 2009 |
| Thomas Rast | [RFC PATCH v3 1/5] git-apply--interactive: Refactor patc ...
This makes some aspects of the 'git add -p' loop configurable (within
the code), so that we can later reuse git-add--interactive for other
similar tools.
Most fields are fairly straightforward, but APPLY gets a subroutine
(instead of just a string a la 'apply --cached') so that we can handle
'checkout -p', which will need to atomically apply the patch twice
(index and worktree).
Signed-off-by: Thomas Rast <trast@student.ethz.ch>
---
git-add--interactive.perl | 79 ...
| Jul 25, 2:29 pm 2009 |
| Thomas Rast | [RFC PATCH v3 5/5] Implement 'git stash save --patch'
This adds a hunk-based mode to git-stash. You can select hunks from
the index and the worktree, and git-stash will attempt to build a
stash that reflects these changes.
Internally, we have the problem that we're trying to offer hunks from
one index (the one the user sees) for inclusion in another index (used
to build the stash). We solve this by letting git-add--interactive
write out the hunks to a patch file, and then using git-apply with a
different GIT_INDEX_FILE.
Signed-off-by: Thomas ...
| Jul 25, 2:29 pm 2009 |
| Thomas Rast | [RFC PATCH v3 4/5] Implement 'git checkout --patch'
This introduces a --patch mode for git-checkout. In the index usage
git checkout --patch -- [files...]
it lets the user discard edits from the <files> at the granularity of
hunks (by selecting hunks from 'git diff' and then reverse applying
them to the worktree).
We also accept a revision argument
git checkout --patch <revision> -- [files...]
which offers hunks from the difference between the <revision> and the
worktree. The chosen hunks are then reverse applied to both index ...
| Jul 25, 2:29 pm 2009 |
| Thomas Rast | [RFC PATCH v3 3/5] Implement 'git reset --patch'
This introduces a --patch mode for git-reset. The basic case is
git reset --patch -- [files...]
which acts as the opposite of 'git add --patch -- [files...]': it
offers hunks for *un*staging. Advanced usage is
git reset --patch <revision> -- [files...]
which offers hunks from the diff between <revision> and the index for
reverse application to the index. (That is, the basic case is just
<revision> = HEAD.) This means it can be used to "undo" changes since
<revision> in the index, ...
| Jul 25, 2:29 pm 2009 |
| Eric Wong | Re: [ANNOUNCE] GIT 1.6.4-rc2
We actually try that in Git::SVN::Ra::minimize_url:
sub minimize_url {
my ($self) = @_;
return $self->{url} if ($self->{url} eq $self->{repos_root});
my $url = $self->{repos_root};
my @components = split(m!/!, $self->{svn_path});
my $c = '';
do {
$url .= "/$c" if length $c;
eval { (ref $self)->new($url)->get_latest_revnum };
} while ($@ && ($c = shift @components));
$url;
}
Maybe get_latest_revnum() isn't strong enough of a check for
certain setups and get_log() needs to ...
| Jul 25, 12:22 pm 2009 |
| Mattias Nissler | Re: [ANNOUNCE] GIT 1.6.4-rc2
Well, I simply wasn't aware of this. I've just retried and it turns out
latest git.git works perfectly for me in both restricted and
non-restricted setups. Great work!
Mattias
--
| Jul 25, 1:16 pm 2009 |
| Eric Wong | [PATCH] git svn: make minimize URL more reliable over http(s)
In addition to path-based restrictions, Subversion servers over
http(s) may have access controls implemented via the LimitExcept
directive in Apache. In some cases, LimitExcept may be
(arguably) misconfigured to not allow REPORT requests while
allowing OPTIONS and PROPFIND.
This caused problems with our existing minimize_url logic that
only issued OPTIONS and PROPFIND requests when connecting and
using SVN::Ra::get_latest_revnum. We now call SVN::Ra::get_log
if get_latest_revnum succeeds, ...
| Jul 25, 1:57 pm 2009 |
| Eric Wong | Re: [ANNOUNCE] GIT 1.6.4-rc2
Yes. I think the old default makes more sense, so I'll be reverting
back to it. However, I'll make it possible to override from the
From a93241b082cd6e7344d0e53969b1e66d443fa48b Mon Sep 17 00:00:00 2001
From: Eric Wong <normalperson@yhbt.net>
Date: Sat, 25 Jul 2009 00:00:50 -0700
Subject: [PATCH] git-svn: revert default behavior for --minimize-url
This reverts the --minimize-url behavior change that
appeared recently in commit 0b2af457a49e3b00d47d556d5301934d27909db8
("Fix branch ...
| Jul 25, 3:38 am 2009 |
| Mattias Nissler | Re: [ANNOUNCE] GIT 1.6.4-rc2
Maybe we should rather try to detect whether we have read access to the
repository root and adjust behaviour accordingly? Or at least print a
warning when cloning restricted multi-branch repos, since this just
fails silently (doesn't pick up any branches) when you have minimize_url
enabled.
Mattias
--
| Jul 25, 6:39 am 2009 |
| Eric Wong | [PATCH 2/2] git svn: the branch command no longer needs ...
This was introduced in 0b2af457a49e3b00d47d556d5301934d27909db8
("Fix branch detection when repository root is inaccessible")
but reintroduced in the previous commit.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
---
Also pushed out to git://git.bogomips.org/git-svn along with some
other changes:
# I removed the "-" in "git svn" in the pushed out version of
# "git svn: revert default behavior for --minimize-url"
Eric Wong (4):
git svn: revert default behavior for ...
| Jul 25, 4:10 am 2009 |
| Junio C Hamano | warning: "git am --whitespace=fix" broken in 1.6.4-rc2
I am very sorry that I did not spot this earlier, but 1.6.4-rc2 has a
quite serious bug in "git apply --whitespace=fix" (hence "git am" with the
same option) in that it can lose all the added empty lines when it detects
any trailing spaces. I've sent a fix out already, and am planning to
issue 1.6.4-rc3 this weekend, but in the meantime, please do not use it,
nor any version that contains commit 735c674 (Trailing whitespace and no
newline fix, 2009-07-22).
Unfortunately the commit is included ...
| Jul 25, 1:52 am 2009 |
| Junio C Hamano | Re: [PATCH] Trailing whitespace and no newline fix
This patch does a lot more than what it claims it does.
Try to apply Jakub's 10 patch series with this, with --whitespace=fix, and
notice that the 9th patch gets all the blank lines removed, claiming that
114 lines had whitespace errors, even though there is only one trailing
whitespace.
Here is a fix. I am pissed at myself not spotting this earlier. The
worst part is that it is part of 'maint' and all integration branches
needs fixing.
-- >8 --
From: Junio C Hamano ...
| Jul 25, 1:37 am 2009 |
| Carlos R. Mafra | Re: Performance issue of 'git branch'
Ok, so I killed /usr/sbin/preload and did the tests again. The
results were much more stable, with average 0.40 vs 0.79
(NO_CURL=1 being faster). The pagefaults were pretty stable too,
(40major+654minor vs 12major+401minor).
I will use NO_CURL=1 from now on!
--
| Jul 24, 5:41 pm 2009 |
| Linus Torvalds | Re: Performance issue of 'git branch'
Well, that's what I meant. If I add '-static' to the link flags, I get
/usr/bin/ld: cannot find -lcurl
collect2: ld returned 1 exit status
because I simply don't have a static library version of curl (and if I do
NO_CURL, I fail the link due to not having a static version of zlib).
That's what I meant by "I could install a static version of curl" - I
could install the debug libraries, but it just isn't a normal thing to do
on any modern distribution. The right thing to do really ...
| Jul 24, 7:39 pm 2009 |
| Daniel Barkalow | Re: Performance issue of 'git branch'
I think it's actually easy enough to have a separate binary to handle the
http walking, particularly since I've got code lying around to handle
importing from a foreign VCS with a separate binary that I can just remove
some of the features from.
-Daniel
*This .sig left intentionally blank*
--
| Jul 24, 7:53 pm 2009 |
| Linus Torvalds | Re: Performance issue of 'git branch'
I actually find it interesting that this whole NO_CURL issue is actually a
lot more noticeable for me in the hot-cache case than all the other 'git
branch' issues were.
I went back to a version a few days ago (before all the optimizations),
and on my machine with a hot cache I get (for my kernel repo - I don't
use branches there, but I have an old 'akpm' branch for taking a emailed
patch series from Andrew):
[torvalds@nehalem linux]$ time ~/git/git branch
akpm
* ...
| Jul 25, 11:04 am 2009 |
| Timo Hirvonen | Re: Performance issue of 'git branch'
SELinux is the problem, not curl.
On my Arch Linux machine:
$ ldd bin/git
linux-vdso.so.1 => (0x00007fff42306000)
libcurl.so.4 => /usr/lib/libcurl.so.4 (0x00007f8714532000)
libz.so.1 => /usr/lib/libz.so.1 (0x00007f871431d000)
libcrypto.so.0.9.8 => /usr/lib/libcrypto.so.0.9.8 (0x00007f8713f8f000)
libpthread.so.0 => /lib/libpthread.so.0 (0x00007f8713d74000)
libc.so.6 => /lib/libc.so.6 (0x00007f8713a21000)
librt.so.1 => /lib/librt.so.1 (0x00007f8713819000)
libssl.so.0.9.8 => ...
| Jul 25, 11:57 am 2009 |
| Reece Dunn | Re: Performance issue of 'git branch'
It will depend on the dependencies of curl that are applied. BLFS
(http://www.linuxfromscratch.org/blfs/view/stable/basicnet/curl.html)
list the following dependencies:
pkg-config-0.22
OpenSSL-0.9.8g or GnuTLS-1.6.3
OpenLDAP-2.3.39
libidn-0.6.14
MIT Kerberos V5-1.6 or Heimdal-1.1
krb4
SPNEGO
c-ares
and the dependencies of those packages and so forth.
On Ubuntu 9.04, I get:
$ ldd /usr/bin/git
linux-gate.so.1 => (0xb80ae000)
libcurl-gnutls.so.4 ...
| Jul 25, 12:06 pm 2009 |
| Mike Hommey | Re: Performance issue of 'git branch'
I think it's NSS, the problem, not SELinux. Linus's libcurl is built
against NSS, which is the default on Fedora.
Mike
--
| Jul 25, 1:31 pm 2009 |
| Linus Torvalds | Re: Performance issue of 'git branch'
Well, it kind of doesn't matter. The fact is, libcurl is a bloated
monster, and adds zero to 99% of what git people do.
The fact that apparently sometimes it's less bloated than other times
doesn't really change anything fundamental, does it?
Linus
--
| Jul 25, 2:02 pm 2009 |
| Carlos R. Mafra | Re: Performance issue of 'git branch'
I don't have SELinux, and without curl it takes ~50% less time (on
top of Linus' previous optimizations!).
The time to open() all the libs really sums up to a considerable
fraction (when the total time is low, not when compared to the
huge 6 secs of before)
Without curl:
0.070104
With curl:
0.249764
PS: It is interesting that in my laptop the time required
to open libcurl alone is 20x the total time of 'git branch' for Linus'
in his supercomputer:
open("/usr/lib64/libcurl.so.4", ...
| Jul 25, 2:04 pm 2009 |
| Linus Torvalds | Re: Performance issue of 'git branch'
Btw, does anybody know how/why libdl seems to get linked in too?
We're not doing -ldl, and I'm not seeing any need for it, but it's
definitely there on fedora, at least.
It seems to come from libcrypto. I can get rid of it with NO_OPENSSL, and
that cuts down on the number of system calls in my startup by 16 (getting
rid of both libcrypto and libdl). I wonder if there is some way to get the
optimized openssl sha1 routines _without_ that silly ldl thing.
Linus
--
| Jul 25, 2:13 pm 2009 |
| Johannes Schindelin | Re: Performance issue of 'git branch'
Hi,
OpenSSL allows for so-called engines implementing certain algorithms.
These engines are dynamic libraries, loaded via dlopen().
Ciao,
Dscho
--
| Jul 25, 4:23 pm 2009 |
| Thomas Rast | [PATCH resend] Disable asciidoc 8.4.1+ semantics for `{p ...
asciidoc 8.4.1 changed the semantics of inline backtick quoting so
that they disable parsing of inline constructs, i.e.,
Input: `{plus}`
Pre 8.4.1: +
Post 8.4.1: {plus}
Fix this by defining the asciidoc attribute 'no-inline-literal'
(which, per the 8.4.1 changelog, is the toggle to return to the old
behaviour) when under ASCIIDOC8.
Signed-off-by: Thomas Rast <trast@student.ethz.ch>
---
Junio, can this go in before 1.6.4? Otherwise the docs will not be
rendered right with ...
| Jul 25, 5:06 am 2009 |
| Junio C Hamano | Re: [PATCH resend] Disable asciidoc 8.4.1+ semantics for ...
Thanks. Will queue.
--
| Jul 25, 9:56 am 2009 |
| Shawn O. Pearce | Re: [JGIT PATCH 0/3] Request for help: graph-based UI
They should be usuable inside the SWT-AWT bridge, but that bridge
is really dicey to get working right sometimes. I had a lot of
trouble with it at my prior day-job and am happy I no longer have
to deal with it.
For the most part, SWT and AWT are similar enough in their rendering
that its possible to build most of a layout algorithm to be rendering
API agnostic, and then permit implementation of AWT and SWT backends.
But that still is duplicated effort, vs. straightforward code reuse.
-- ...
| Jul 25, 1:59 pm 2009 |
| Douglas Campos | Re: [JGIT PATCH 0/3] Request for help: graph-based UI
Just a question.. all graphic things that we implement in swing aren't
usable inside eclipse with swt-awt bridge?
On Tue, Jul 21, 2009 at 4:40 PM, Robin
--
Douglas Campos
Theros Consulting
+55 11 7626 5959
+55 11 3020 8168
--
| Jul 25, 1:54 pm 2009 |
| Johannes Schindelin | Re: [JGIT PATCH 0/3] Request for help: graph-based UI
Hi,
Of course, the Graph GUI is Swing...
But I would definitely welcome if somebody made the rendering more
modular, to allow for an SWT backend.
In fact, I think I welcome almost everything people contribute to the
Graph GUI project.
Ciao,
Dscho
--
| Jul 25, 4:20 pm 2009 |
| Pete Wyckoff | [PATCH 1/5] git-p4 stream: remove unused function
This functionality was replaced.
Signed-off-by: Pete Wyckoff <pw@padd.com>
---
contrib/fast-import/git-p4 | 58 --------------------------------------------
1 files changed, 0 insertions(+), 58 deletions(-)
diff --git a/contrib/fast-import/git-p4 b/contrib/fast-import/git-p4
index f415ad0..70fa403 100755
--- a/contrib/fast-import/git-p4
+++ b/contrib/fast-import/git-p4
@@ -950,64 +950,6 @@ class P4Sync(Command):
return branches
- ## Should move this out, doesn't use ...
| Jul 25, 7:23 am 2009 |
| Pete Wyckoff | Re: [PATCH/RFC v2] git-p4: stream from perforce to speed ...
This is definitely good stuff. While I'd like to get Daniel's
native transport code working in my environment, I had a need to
import some big trees quickly from p4 to git. Usually I resort to a
rare big-memory machine to do the git-p4 import, but with your
change, I can use my laptop without going into swap or
out-of-memory.
For the content, I would recommend some changes. Here are some
patches on top of yours:
[PATCH 1/5] git-p4 stream: remove unused function
[PATCH 2/5] ...
| Jul 25, 7:23 am 2009 |
| Pete Wyckoff | [PATCH 4/5] git-p4 stream: check apple file type
Move this check into the function so both callers do it.
And always reset the file contents in the main loop, as
we just ignored this apple file.
Signed-off-by: Pete Wyckoff <pw@padd.com>
---
contrib/fast-import/git-p4 | 11 +++++------
1 files changed, 5 insertions(+), 6 deletions(-)
diff --git a/contrib/fast-import/git-p4 b/contrib/fast-import/git-p4
index 3ab016b..af66026 100755
--- a/contrib/fast-import/git-p4
+++ b/contrib/fast-import/git-p4
@@ -954,6 +954,11 @@ class ...
| Jul 25, 7:24 am 2009 |
| Pete Wyckoff | [PATCH 3/5] git-p4 stream: show relative path in debug m ...
Not repo path, but the one where git will put the file. They're
shorter and allows verifying branchPrefixes too.
Signed-off-by: Pete Wyckoff <pw@padd.com>
---
contrib/fast-import/git-p4 | 11 ++++-------
1 files changed, 4 insertions(+), 7 deletions(-)
diff --git a/contrib/fast-import/git-p4 b/contrib/fast-import/git-p4
index 3a52254..3ab016b 100755
--- a/contrib/fast-import/git-p4
+++ b/contrib/fast-import/git-p4
@@ -954,10 +954,9 @@ class P4Sync(Command):
# - helper for ...
| Jul 25, 7:24 am 2009 |
| Pete Wyckoff | [PATCH 5/5] git-p4 stream: use existing p4CmdList with c ...
Add a callback argrument to iterate over returned contents
rather than replicate the entire function just to do that.
Signed-off-by: Pete Wyckoff <pw@padd.com>
---
contrib/fast-import/git-p4 | 88 +++++++++++++++++++-------------------------
1 files changed, 38 insertions(+), 50 deletions(-)
diff --git a/contrib/fast-import/git-p4 b/contrib/fast-import/git-p4
index af66026..eece984 100755
--- a/contrib/fast-import/git-p4
+++ b/contrib/fast-import/git-p4
@@ -201,7 +201,7 @@ def ...
| Jul 25, 7:25 am 2009 |
| Pete Wyckoff | [PATCH 2/5] git-p4 stream: do not pass branchPrefixes so much
Just set it in self when commit starts and use it everywhere.
This makes the code a bit cleaner, but no functional change
Signed-off-by: Pete Wyckoff <pw@padd.com>
---
contrib/fast-import/git-p4 | 19 ++++++++++---------
1 files changed, 10 insertions(+), 9 deletions(-)
diff --git a/contrib/fast-import/git-p4 b/contrib/fast-import/git-p4
index 70fa403..3a52254 100755
--- a/contrib/fast-import/git-p4
+++ b/contrib/fast-import/git-p4
@@ -953,11 +953,11 @@ class P4Sync(Command):
# ...
| Jul 25, 7:24 am 2009 |
| previous day | today | next day |
|---|---|---|
| July 24, 2009 | July 25, 2009 | July 26, 2009 |
| Greg KH | Og dreams of kernels |
| Jens Axboe | [PATCH 31/33] Fusion: sg chaining support |
| Arnd Bergmann | Re: finding your own dead "CONFIG_" varia |