On Wed, Jul 10, 2013 at 9:03 PM, Eric Sunshine wrote:
> +static void check_mailmap(struct string_list *mailmap, const char *contact)
> +{
> + const char *name, *mail;
> + size_t namelen, maillen;
> + struct ident_split ident;
> + char term = null_out ? '\0' : '\n';
> +
> +
On Thu, Jul 11, 2013 at 12:50 PM, Eric Sunshine wrote:
>>> + maybe_flush_or_die(stdout, "contact to stdout");
>>
>> On error this function will print
>>
>> write failure on 'contact to stdout'
>>
>> maybe maybe_flush_or_die(stdout, "write contact to stdout") or
>> something? From i18n point
On Wed, Jul 10, 2013 at 10:31 PM, Duy Nguyen wrote:
> On Thu, Jul 11, 2013 at 2:03 AM, Eric Sunshine
> wrote:
>> +static const struct option check_mailmap_options[] = {
>> + OPT_BOOLEAN(0, "stdin", &use_stdin,
>> + N_("also read contacts from stdin")),
>> + OPT_BOOL
On Thu, Jul 11, 2013 at 2:03 AM, Eric Sunshine wrote:
> +static const struct option check_mailmap_options[] = {
> + OPT_BOOLEAN(0, "stdin", &use_stdin,
> + N_("also read contacts from stdin")),
> + OPT_BOOLEAN('z', NULL, &null_out,
> + N_("null-termi
Hi there,
I've been using git for some time now, and host my remote bare
repositories on my shared hosting account at Dreamhost.com. As a
protective feature on their shared host setup, they enact a policy
that kills processes that consume too much memory. This happens to
git sometimes.
By "some
On Wed, Jul 10, 2013 at 6:36 PM, Brian Gernhardt
wrote:
> I am somewhat stuck on how to fix it. Any ideas?
I don't have anything to reproduce here, but usually I start
investigating this kind of problems by attaching the hung process with
gdb to see the current state (if it's stuck in a specific
Commit adbc0b6b ("cygwin: Use native Win32 API for stat", 30-09-2008)
added a Win32 specific implementation of the stat functions. In order
to handle absolute paths, cygwin mount points and symbolic links, this
implementation may fall back on the standard cygwin l/stat() functions.
Also, the choic
If you are wondering, v1 of this patch was appended to an email
that is part of the "cygwin: Remove the Win32 l/stat() functions"
thread.
Changes from v1:
- add comment in git-compat-util.h to explain the use
of the "fast" stat variants.
- remove the fast_stat() function, along wit
The simple two-commit test-repository created by 'setup' is no longer
needed by any of the tests retrofitted to use check-mailmap. Subsequent,
more complex tests of git-shortlog, git-log, and git-blame functionality
expand the repository by adding five commits. Consolidate the creation
of this seve
This patch series adds builtin command check-mailmap, similar to
check-attr and check-ignore, which allows direct testing of .mailmap
configuration. More importantly, as plumbing accessible to scripts
and other porcelain, check-mailmap publishes the stable, well-tested
.mailmap functionality emplo
With the introduction of check-mailmap, it is now possible to check
.mailmap functionality directly rather than indirectly as a side-effect
of other commands (such as git-shortlog), therefore, do so.
Signed-off-by: Eric Sunshine
---
t/t4203-mailmap.sh | 133 ++
Introduce command check-mailmap, similar to check-attr and check-ignore,
which allows direct testing of .mailmap configuration.
As plumbing accessible to scripts and other porcelain, check-mailmap
publishes the stable, well-tested .mailmap functionality employed by
built-in Git commands. Conseque
Test the command-line interface of check-mailmap. (Actual .mailmap
functionality is already covered by existing tests.)
Signed-off-by: Eric Sunshine
---
t/t4203-mailmap.sh | 50 ++
1 file changed, 50 insertions(+)
diff --git a/t/t4203-mailmap.sh b
V2 corrects a message in the second and the third part.
Ralf Thielow (3):
l10n: de.po: switch from pure German to German+English (part 1)
l10n: de.po: switch from pure German to German+English (part 2)
l10n: de.po: switch from pure German to German+English (part 3)
po/de.po | 1796
On Wed, Jul 10, 2013 at 4:55 AM, Jeff King wrote:
> The pack revindex stores the offsets of the objects in the
> pack in sorted order, allowing us to easily find the on-disk
> size of each object. To compute it, we populate an array
> with the offsets from the sha1-sorted idx file, and then use
>
The newest test in t0008 "streaming support for --stdin", seems to hang
sporadically on my MacBook Pro (running 10.8.4). The hang seems to be related
to running it in parallel with other tests, as I can only reliably cause it by
running with prove and -j 3. However, once that has hung I am ab
Jeff King wrote:
> git rev-list --objects HEAD |
> git cat-file --batch-check='%(objectsize) %(text)'
If anything, I would have expected %(rest), not %(text). This atom is
specific to commands that accept input via stdin (i.e. not log, f-e-r,
branch, or anything else I can think of).
Also, t
On Tue, 9 Jul 2013 20:30:37 -0500
Chanakya Vattikuti wrote:
> I get this error message when trying to create a shared ssh key in
> Mac osx Lion
This problem has nothing to do with Git as it purely is about
transferring a public part of your SSH key to another host.
So try asking on the OS suppor
Jeff King wrote:
> +If `--batch` or `--batch-check` is given, `cat-file` will read objects
> +from stdin, one per line, and print information about them.
> +
> +You can specify the information shown for each object by using a custom
> +``. The `` is copied literally to stdout for each
> +object, wi
Jeff King wrote:
> That does O(n log n) offset comparisons, and profiling shows
> that we spend most of our time in cmp_offset. However, since
> we are sorting on a simple off_t, we can use numeric sorts
> that perform better. A radix sort can run in O(k*n), where k
> is the number of "digits" in o
On Wed, Jul 10, 2013 at 07:55:57AM -0400, Jeff King wrote:
> 5. We use memcpy instead of an open-coded loop to copy the whole array
> at the end. The individual bucket-assignment is still done by
> struct assignment. I haven't timed if memcpy would make a
> difference there.
I ju
The pack revindex stores the offsets of the objects in the
pack in sorted order, allowing us to easily find the on-disk
size of each object. To compute it, we populate an array
with the offsets from the sha1-sorted idx file, and then use
qsort to order it by offsets.
That does O(n log n) offset co
On Wed, Jul 10, 2013 at 7:45 AM, Jeff King wrote:
> The `cat-file --batch-check` command can be used to quickly
> get information about a large number of objects. However, it
> provides a fixed set of information.
>
> This patch adds an optional option to --batch-check
> to allow a caller to spec
A packfile may have up to 2^32-1 objects in it, so the
"right" data type to use is uint32_t. We currently use a
signed int, which means that we may behave incorrectly for
packfiles with more than 2^31-1 objects on 32-bit systems.
Nobody has noticed because having 2^31 objects is pretty
insane. The
If we get an input line to --batch or --batch-check that
looks like "HEAD foo bar", we will currently feed the whole
thing to get_sha1(). This means that to use --batch-check
with `rev-list --objects`, one must pre-process the input,
like:
git rev-list --objects HEAD |
cut -d' ' -f1 |
git ca
This atom is just like %(objectsize), except that it shows
the on-disk size of the object rather than the object's true
size. In other words, it makes the "disk_size" query of
sha1_object_info_extended available via the command-line.
This can be used for rough attribution of disk usage to
particul
The `cat-file --batch-check` command can be used to quickly
get information about a large number of objects. However, it
provides a fixed set of information.
This patch adds an optional option to --batch-check
to allow a caller to specify which items they are interested
in, and in which order to
The regular "git cat-file -p" and "git cat-file blob" code
paths already learned to stream large blobs. Let's do the
same here.
Note that this means we look up the type and size before
making a decision of whether to load the object into memory
or stream (just like the "-p" code path does). That c
We currently use an int to tell us whether --batch parsing
is on, and if so, whether we should print the full object
contents. Let's instead factor this into a struct, filled in
by callback, which will make further batch-related options
easy to add.
Signed-off-by: Jeff King
---
builtin/cat-file.
In modern tests, we typically put output into a file and
compare it with test_cmp. This is nicer than just comparing
via "test", and much shorter than comparing via "test" and
printing a custom message.
Signed-off-by: Jeff King
---
I didn't do the whole file, just the ones of a particular style c
Using sha1_object_info_extended, a caller can find out the
type of an object, its size, and information about where it
is stored. In addition to the object's "true" size, it can
also be useful to know the size that the object takes on
disk (e.g., to generate statistics about which refs consume
spac
The sha1_object_info_extended function expects the caller to
provide a "struct object_info" which contains pointers to
"query" items that will be filled in. The purpose of
providing pointers rather than storing the response directly
in the struct is so that callers can choose not to incur the
expen
Here's a re-roll of the cat-file --batch-disk-sizes series.
The main change is that it replaces the --batch-disk-sizes option with a
format string for --batch-check, syntactically modeled after the
for-each-ref format string.
[01/10]: zero-initialize object_info structs
[02/10]: teach sha1_ob
On Mon, Jul 08, 2013 at 07:07:01PM +0530, Ramkumar Ramachandra wrote:
> > There's also syntax sharing. I don't think each command should have
> > its own syntax. f-e-r already has %(objectsize). If we plan to have a
> > common syntax, perhaps %(disk-size) should be %(objectsize:disk) or
> > someth
On Sun, Jul 07, 2013 at 10:49:46AM -0700, Junio C Hamano wrote:
> Jeff King writes:
>
> > Perhaps we need
> >
> > git cat-file --batch-format="%(disk-size) %(object)"
> >
> > or similar.
>
> I agree with your reasoning. It may be simpler to give an interface
> to ask for which pieces of info
Hi!
I suspect I may have found a problem in the way git-svn uses SVN::Core
that leads to a segmentation fault. That's a hypothesis based on the
following incomplete findings:
git version 1.8.3.2.50.g531c8dd (from recent git maint)
svn, version 1.7.10 (r1485443) (from openSUSE 12.2)
sub
On Mon, Jul 08, 2013 at 01:50:41PM -0700, Brandon Casey wrote:
> > +static void sort_revindex(struct revindex_entry *entries, int n, off_t max)
>
> If 'n' is the number of objects in the pack, shouldn't it be unsigned?
Yes. I inherited that bug from the rest of the revindex code.
> The data typ
On Sun, Jul 07, 2013 at 09:15:41PM +, brian m. carlson wrote:
> On Sun, Jul 07, 2013 at 06:09:49AM -0400, Jeff King wrote:
> > +NOTE: The on-disk size reported is accurate, but care should be taken in
> > +drawing conclusions about which refs or objects are responsible for disk
> > +usage. The
On Mon, Jul 08, 2013 at 02:35:10PM -0700, Brandon Casey wrote:
> > If 'n' is the number of objects in the pack, shouldn't it be unsigned?
> >
> > The data type for struct packed_git.num_objects is uint32_t. Looks
> > like create_pack_revindex uses the wrong datatype when it captures
> > num_objec
On Wed, Jul 10, 2013 at 12:10:55PM +0200, Muhammad Bashir Al-Noimi wrote:
> On Tue, Jul 9, 2013 at 10:47 PM, Muhammad Bashir Al-Noimi
> wrote:
> > Now I've to make some tests because the new version is completely different
> > than the old one so I'll send a feedback soon.
>
>
> Thanks guys, the
On Tue, Jul 9, 2013 at 10:47 PM, Muhammad Bashir Al-Noimi
wrote:
> Now I've to make some tests because the new version is completely different
> than the old one so I'll send a feedback soon.
Thanks guys, the recent git-cola fabulous so I don't need to use the
terminal anymore for git.
As I men
Junio C Hamano writes:
> Thomas Rast writes:
>
>> If you define it that way, the output of
>>
>> git blame -L 4,6; git blame -L /A/,+20
>>
>> is significantly different from
>>
>> git blame -L 4,6 -L /A/,+20
>>
>> Not just in the presentation or any possible coalescing, but in the
>> meaning
Junio C Hamano writes:
> * bp/mediawiki-preview (2013-07-08) 7 commits
> - git-remote-mediawiki: add preview subcommand into git mw
> - git-remote-mediawiki: add git-mw command
> - git-remote-mediawiki: factoring code between git-remote-mediawiki and
> Git::Mediawiki
> - git-remote-mediawiki
On Jul 9, 2013, at 16:09, Junio C Hamano wrote:
* km/svn-1.8-serf-only (2013-07-07) 2 commits
- git-svn: allow git-svn fetching to work using serf
- Git.pm: add new temp_is_locked function
Comments?
Since neither David nor Jonathan have piped in here (they were the two
primarily involved in
44 matches
Mail list logo
