Re: [RFC PATCH v2] revision: new rev^-n shorthand for rev^n..rev

From: "Junio C Hamano" "Philip Oakley" writes: From: "Vegard Nossum" I use rev^..rev daily, and I'm surely not the only one. Not everyone knows the 'trick' and may not use it daily. Consider stating what it is useful for

Re: git-gui, was Re: [PATCH v2 6/6] git-gui: Update Japanese information

Junio C Hamano writes: > Vasco Almeida writes: > >> I have sent some git-gui patches on May this year and I think it will >> add value to accepted them at some point: > > Yeah, they may be of value, but the thing is, I am not really in the > position to

Re: [PATCH] unpack_sha1_header(): detect malformed object header

On Sun, Sep 25, 2016 at 09:29:04PM -0700, Junio C Hamano wrote: > To correct this, do these three things: > > - rename unpack_sha1_header() to unpack_sha1_short_header() and >have unpack_sha1_header_to_strbuf() keep calling that as its >helper function. This will detect and report zlib

Re: Stack read out-of-bounds in parse_sha1_header_extended using git 2.10.0

On Sun, Sep 25, 2016 at 05:10:31PM -0700, Junio C Hamano wrote: > Gustavo Grieco writes: > > > We found a stack read out-of-bounds parsing object files using git 2.10.0. > > It was tested on ArchLinux x86_64. To reproduce, first recompile git with > > ASAN support and

RE: git-upload-pack hangs

> -Original Message- > From: Jason Pyeron > Sent: Monday, September 26, 2016 01:51 > > git is hanging on clone. I am runnig (cygwin) git 2.8.3 on > IIS7 (windows server 2012 R2). > > Where can I start to perform additional debugging? > Reading this thread, it seems plausible as a

BUG: Git blame provides incorrect previous commit if the line is uncommitted

This is the first time I've reported a bug with Git so please forgive me if this isn't the right place, format, etc. If git blame --porcelain (or --line-porcelain or --incremental) is run on a file that has uncommitted changes any uncommitted lines have the wrong previous sha. Instead of the sha

Re: [PATCH 04/10] get_short_sha1: peel tags when looking for treeish

On Mon, Sep 26, 2016 at 07:59:48AM -0400, Jeff King wrote: > Subject: Re: [PATCH 04/10] get_short_sha1: peel tags when looking for treeish > > The treeish disambiguation function tries to peel tags, but > it does so by calling: Probably the subject should be "parse tags when...". We already try

Re: Changing the default for "core.abbrev"?

On Mon, Sep 26, 2016 at 08:33:52AM +0200, Matthieu Moy wrote: > Junio C Hamano writes: > > > I am not opposed to bump the default to 12 or whatever, but I > > suspect any lengthening today may need to be accompanied by a tool > > support that finds the set of objects that are

[PATCH 08/10] sha1_array: let callbacks interrupt iteration

The callbacks for iterating a sha1_array must have a void return. This is unlike our usual for_each semantics, where a callback may interrupt iteration and have its value propagated. Let's switch it to the usual form, which will enable its use in more places (e.g., where we are replacing an

[PATCH 04/10] get_short_sha1: peel tags when looking for treeish

The treeish disambiguation function tries to peel tags, but it does so by calling: deref_tag(lookup_object(sha1), ...); This will only work if we have previously looked at the tag and created a "struct tag" for it. Since parsing revision arguments typically happens before anything else, this

[PATCH 10/10] get_short_sha1: list ambiguous objects on error

When the user gives us an ambiguous short sha1, we print an error and refuse to resolve it. In some cases, the next step is for them to feed us more characters (e.g., if they were retyping or cut-and-pasting from a full sha1). But in other cases, that might be all they have. For example, an old

[PATCH 06/10] get_short_sha1: NUL-terminate hex prefix

We store the hex prefix in a 40-byte buffer with the prefix itself followed by 40-minus-len "x" characters. These x's serve no purpose, and the lack of NUL termination makes the prefix string annoying to use. Let's just terminate it. Note that this is in contrast to the binary prefix, which

[PATCH 05/10] get_short_sha1: refactor init of disambiguation code

The disambiguation machinery has two callers: get_short_sha1 and for_each_abbrev. Both need to repeat much of the same setup: declaring buffers, sanity-checking lengths, preparing the prefixes, etc. Let's pull that into a single init function so we can avoid repeating ourselves. Pulling the

[PATCH 07/10] get_short_sha1: mark ambiguity error for translation

This is a human-readable message, and there's no reason it should not be translated. While we're at it, let's drop the period from the end, which is not our usual style. Signed-off-by: Jeff King --- sha1_name.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git

[PATCH 09/10] for_each_abbrev: drop duplicate objects

If an object appears multiple times in the object database (e.g., in both loose and packed form, or in two separate packs), the disambiguation machinery may see it more than once. The get_short_sha1() function handles this already, but for_each_abbrev() blindly fires the callback for each instance

[PATCH 03/10] get_sha1: propagate flags to child functions

The get_sha1() function is actually implementation by many sub-functions, but we do not always pass our flags around to all of those functions. As a result, we may forget that our caller asked us to resolve with GET_SHA1_QUIETLY and output messages. The two triggerable cases are: 1. Resolving

[PATCH 02/10] get_sha1: avoid repeating ourselves via ONLY_TO_DIE

When the revision code cannot parse an argument like "HEAD:foo", it will call maybe_die_on_misspelt_object_name(), which re-runs get_sha1() with an extra ONLY_TO_DIE flag. We then spend more effort to generate a better error message. Unfortunately, a side effect is that our second call may repeat

[PATCH 01/10] get_sha1: detect buggy calls with multiple disambiguators

The get_sha1() family of functions takes a flags field, but some of the flags are mutually exclusive. In particular, we can only handle one disambiguating function, and the flags quietly override each other. Let's instead detect these as programming bugs. Technically some of the flags are

[PATCH 0/10] helping people resolve ambiguous sha1s

On Sun, Sep 25, 2016 at 09:45:18PM -0700, Junio C Hamano wrote: > On Sun, Sep 25, 2016 at 9:34 PM, Jeff King wrote: > > > > An easier (but less automatic) tool would be to improve our error > > message for the ambiguous case, and actually report details of the > > candidates. I'm

Re: Request: Extra case for %G? format

Alex venit, vidit, dixit 25.09.2016 08:05: > Hello all, > > Could the %G? format differentiate between an unsigned commit and a > signed commit that you're missing a public key for? > > If `git show --format=%GG --no-patch ' produces an output like > the following: > > gpg: Signature made

Re: Changing the default for "core.abbrev"?

On Mon, Sep 26, 2016 at 3:39 AM, Linus Torvalds wrote: > > The kernel, these days, is at roughly 5 million objects, and while the > seven hex digits are still often enough for uniqueness (and git will > always add digits *until* it is unique), it's long been at the

git-upload-pack hangs

git is hanging on clone. I am runnig (cygwin) git 2.8.3 on IIS7 (windows server 2012 R2). Where can I start to perform additional debugging? Selected items I have read, but they did not help: http://unix.stackexchange.com/questions/98959/git-upload-pack-hangs-indefinitely

Re: Changing the default for "core.abbrev"?

Junio C Hamano writes: > I am not opposed to bump the default to 12 or whatever, but I > suspect any lengthening today may need to be accompanied by a tool > support that finds the set of objects that are reachable from a > commit whose names begin with non-unique

<    1   2