Re: [PATCH v4 5/6] get_short_oid: sort ambiguous objects by type, then SHA-1

Ævar Arnfjörð Bjarmason writes: > diff --git a/sha1-name.c b/sha1-name.c > index 9d7bbd3e96..46d8b1afa6 100644 > --- a/sha1-name.c > +++ b/sha1-name.c > @@ -409,6 +437,8 @@ static int get_short_oid(const char *name, int len, > struct object_id *oid, > status =

Re: [PATCH] fast-export: avoid NULL pointer arithmetic

Junio C Hamano writes: > René Scharfe writes: > >>> But it somehow feels backwards in spirit to me, as the reason why we >>> use "void *" there in the decoration field is because we expect that >>> we'd have a pointer to some struture most of the time, and we

Re: [PATCH v2] pack-format.txt: more details on pack file format

Nguyễn Thái Ngọc Duy writes: > +Both ofs-delta and ref-delta store the "delta" against another > +object. The difference between them is, ref-delta directly encodes > +20-byte base object name. If the base object is in the same pack, > +ofs-delta encodes the offset of the

Re: [PATCH] apply: clarify "-p" documentation

Jeff King writes: > How about this? > > -- >8 -- > Subject: [PATCH] apply: clarify "-p" documentation > > We're not really removing slashes, but slash-separated path > components. Let's make that more clear. > > Reported-by: kelly elton > Signed-off-by:

Re: [PATCH 1/2] t5516-fetch-push: fix 'push with dry-run' test

SZEDER Gábor writes: > In a while-at-it cleanup replacing a 'cd dir && <...> && cd ..' with a > subshell, commit 28391a80a9 (receive-pack: allow deletion of corrupt > refs, 2007-11-29) also moved the assignment of the $old_commit > variable to that subshell. This variable,

Re: [PATCH v4 2/6] sha1-array.h: align function arguments

Junio C Hamano writes: > Jeff King writes: > >> On Thu, May 10, 2018 at 12:42:59PM +, Ævar Arnfjörð Bjarmason wrote: >> >>> The arguments weren't lined up with the opening parenthesis. Fixes up >>> code added in aae0caf19e ("sha1-array.h: align function

Re: [PATCH v4 2/6] sha1-array.h: align function arguments

Jeff King writes: > On Thu, May 10, 2018 at 12:42:59PM +, Ævar Arnfjörð Bjarmason wrote: > >> The arguments weren't lined up with the opening parenthesis. Fixes up >> code added in aae0caf19e ("sha1-array.h: align function arguments", >> 2018-04-30). > > I think that's this

Re: Regression in patch add?

Phillip Wood writes: > Yes, I think it probably makes sense to do that. Originally I didn't > count empty lines as context lines in case the user accidentally added > some empty lines at the end of the hunk but if 'git apply' does then I > think 'git add -p' should as

Re: [Best Practices Request] clean/smudge configuration

"Randall S. Becker" writes: > What if we create a ../.gitconfig like ../.gitattributes, that is loaded > before .git/config? You should not forget one of the two reasons why clean/smudge/diff etc. drivers must be given with a step of redirection, split between attributes

Re: [PATCH] fast-export: avoid NULL pointer arithmetic

René Scharfe writes: >> But it somehow feels backwards in spirit to me, as the reason why we >> use "void *" there in the decoration field is because we expect that >> we'd have a pointer to some struture most of the time, and we have >> to occasionally store a small integer there.

Re: [PATCH v2] add status config and command line options for rename detection

Elijah Newren writes: >> Note: I removed the --no-breaks command line option from the original patch >> as >> it will no longer be needed once the default has been changed [1] to turn it >> off. >> >> [1] >>

Re: [PATCH 0/1] Fix UX issue with commit-graph.lock

Derrick Stolee writes: >> Also, can't we tell why we failed to acquire the lock at step #1? >> Do we only get a NULL that says "I am not telling you why, but we >> failed to lock"? > > To tell why we failed to acquire the lock, we could inspect > "errno". However, this requires

Re: [GSoC] Info: Week 02 Blog Post

On Thu, May 10, 2018 at 11:35 PM, Stefan Beller wrote: > Hi Pratik, Hi Stefan, > On Wed, May 9, 2018 at 8:07 PM, Pratik Karki wrote: >> Hi, >> >> The week 02 blog post[1] is live. This post is part I out of II and this >> time it will be biweekly.

Re: [PATCH 0/2] Submodule merging: i18n, verbosity

Hi Elijah, On Thu, May 10, 2018 at 5:04 PM, Elijah Newren wrote: > On Thu, May 10, 2018 at 2:19 PM, Stefan Beller wrote: >> Leif wrote: >>> Sure, let me know what to use instead and I’ll update and resubmit the >>> patch. >>> Sure, but `MERGE_WARNING`

Re: [PATCH 0/2] Submodule merging: i18n, verbosity

On Thu, May 10, 2018 at 2:19 PM, Stefan Beller wrote: > Leif wrote: >> Sure, let me know what to use instead and I’ll update and resubmit the patch. >> Sure, but `MERGE_WARNING` prefixes all the messages with "Failed to >> merge submodule“. > > I thought about replying and

Re: [PATCH] sha1dc: fix for compiling on AIX using IBM XLC compiler

(cc-ing Marc Stevens for real this time. Sorry for the noise) Ævar Arnfjörð Bjarmason wrote: > On Wed, May 09 2018, jens persson wrote: >> Hello, first patch. I'm having trouble compiling on AIX using IBMs >> compiler, leading to >> unusable binaries. The following patch solved the problem for

Re: [PATCH v2] mailmap: update brian m. carlson's email address

On Wed, May 09, 2018 at 12:33:59PM +0530, Kaartic Sivaraam wrote: > On Wednesday 09 May 2018 05:49 AM, brian m. carlson wrote: > > Correct, it doesn't. In my case, I was using --pretty='%aN <%aE>', > > which is how I noticed it in the first place. > > So, how about updating the commit message to

Re: [PATCH v4 00/13] object store: alloc

On Thu, May 10, 2018 at 1:56 PM, Jonathan Tan wrote: > On Thu, 10 May 2018 10:32:09 -0700 > Stefan Beller wrote: > >> > - I would call them release_commit() and release_tag(), to match >> >strbuf_release(). >> >> Why not commit_release and

Re: [PATCH v2] add status config and command line options for rename detection

Hi Ben, On Thu, May 10, 2018 at 12:09 PM, Ben Peart wrote: > On 5/10/2018 12:19 PM, Elijah Newren wrote: >> On Thu, May 10, 2018 at 7:16 AM, Ben Peart >> wrote: > Given the example perf impact is arbitrary (the actual example that > triggered this

[PATCH] submodule: port submodule subcommand 'foreach' from shell to C

From: Prathamesh Chavan This aims to make git-submodule foreach a builtin. 'foreach' is ported to the submodule--helper, and submodule--helper is called from git-submodule.sh. Helped-by: Brandon Williams Mentored-by: Christian Couder

[PATCH 2/2] merge-recursive: i18n submodule merge output and respect verbosity

The submodule merge code now uses the output() function that is used by all the rest of the merge-recursive-code. This allows for respecting internationalisation as well as the verbosity setting. Signed-off-by: Stefan Beller --- merge-recursive.c | 33

[PATCH 1/2] submodule.c: move submodule merging to merge-recursive.c

In a later patch we want to improve submodule merging by using the output() function in merge-recursive.c for submodule merges to deliver a consistent UI to users. To do so we could either make the output() function globally available so we can use it in submodule.c#merge_submodule(), or we could

[PATCH 0/2] Submodule merging: i18n, verbosity

Leif wrote: > Sure, let me know what to use instead and I’ll update and resubmit the patch. > Sure, but `MERGE_WARNING` prefixes all the messages with "Failed to > merge submodule“. I thought about replying and coming up with good reasons, but I wrote some patches instead. They can also be found

Re: [PATCH v4 00/13] object store: alloc

On Thu, 10 May 2018 10:32:09 -0700 Stefan Beller wrote: > > - I would call them release_commit() and release_tag(), to match > >strbuf_release(). > > Why not commit_release and tag_release to also have the same order > of words as in strbuf_release ? At this point in

Re: [PATCH 00/12] Integrate commit-graph into fsck, gc, and fetch

On 10 May 2018 at 21:22, Stefan Beller wrote: > On Thu, May 10, 2018 at 12:05 PM, Martin Ågren wrote: >> I hope to find time to do some more hands-on testing of this to see that >> errors actually do get caught. > Packfiles and loose objects are

Re: [PATCH 1/1] Warn about fast-forwarding of submodules during merge

Hi Stefan, Am 10. Mai 2018 um 20:49:39, Stefan Beller (sbel...@google.com(mailto:sbel...@google.com)) schrieb: > On Thu, May 10, 2018 at 11:26 AM, Leif Middelschulte > wrote: > > From: Leif Middelschulte > > Hi Leif! > > thanks for following up with a patch! sure, thanks for the quick review. >

Re: Git case-sensitivity bug

Hey Cliff, On Thu, May 10, 2018 at 12:46 PM Cliff wrote: > I believe I have discovered a bug with git tools. > If you create a git branch, you can refer to that branch with > case-insensitive alterations and it will track as the same branch. This comes up on the list

RE: [Best Practices Request] clean/smudge configuration

On May 9, 2018 6:39 PM, Bryan Turner wrote: > On Wed, May 9, 2018 at 3:09 PM Randall S. Becker > > wrote: > > > The question: what is the best practice for versioning the parts of > > clean/smudge filters that are in .git/config given that only some > > users in my

[PATCH v2 3/4] object.c: free replace map in raw_object_store_clear

The replace map for objects was missed to free in the object store in the conversion of c1274495 ("replace-object: eliminate replace objects prepared flag", 2018-04-11). We also missed to free the replaced objects that are put into the replace map in that whole series. Signed-off-by: Stefan

[PATCH v2 4/4] replace-object.c: remove the_repository from prepare_replace_object

This was missed in 5982da9d2ce (replace-object: allow prepare_replace_object to handle arbitrary repositories, 2018-04-11) Technically the code works correctly as the replace_map is the same size in different repositories, however it is hard to read. So convert the code to the familiar pattern of

[PATCH v2 0/4] Fix mem leaks of recent object store conversions.

This series replaces the two commits that were queued on sb/object-store-replace, fixing memory leaks that were recently introduced. Compared to v1, I merged the two independent series from yesterday, rewrote the commit message to clear up Junios confusion and addresses Peffs comments for the

[PATCH v2 2/4] packfile.h: remove all extern keywords

Per our coding guidelines we prefer to only use the extern keyword when needed. Signed-off-by: Stefan Beller --- packfile.h | 80 +++--- 1 file changed, 40 insertions(+), 40 deletions(-) diff --git a/packfile.h b/packfile.h

[PATCH v2 1/4] packfile: close and free packs upon releasing an object store

In d0b59866223 (object-store: close all packs upon clearing the object store, 2018-03-23), we made sure to close all packfiles on releasing an object store, but we also have to free the memory of the closed packs. Signed-off-by: Stefan Beller --- Notes: > Should that

Re: [PATCH] fast-export: avoid NULL pointer arithmetic

Am 10.05.2018 um 12:51 schrieb Junio C Hamano: > René Scharfe writes: > >> The standard says about uintptr_t that "any valid pointer to void can >> be converted to this type, then converted back to pointer to void, and >> the result will compare equal to the original pointer". So

Git case-sensitivity bug

I believe I have discovered a bug with git tools. If you create a git branch, you can refer to that branch with case-insensitive alterations and it will track as the same branch. If I create branch "test" I cannot then create branch "Test" because the same name is already used. However, git

[PATCH v2 1/3] refs.c: refer to "object ID", not "sha1", in error messages

We have two error messages that complain about the "sha1". Because we are about to touch one of these sites and add some tests, let's first modernize the messages to say "object ID" instead. While at it, make the second one use `error()` instead of `warning()`. After printing the message, we do

[PATCH v2 0/3] refs: handle zero oid for pseudorefs

On 7 May 2018 at 12:05, Martin Ågren wrote: > On 7 May 2018 at 09:39, Michael Haggerty wrote: >> Thanks for the patch. This looks good to me. But it it seems that the >> test coverage related to pseudorefs is still not great. Ideally, all of >> the

[PATCH v2 2/3] t1400: add tests around adding/deleting pseudorefs

I have not been able to find any tests around adding pseudorefs using `git update-ref`. Add some as outlined in this table (original design by Michael Haggerty; modified and extended by me): Pre-update value | ref-update old OID | Expected result

[PATCH v2 3/3] refs: handle zero oid for pseudorefs

According to the documentation, it is possible to "specify 40 '0' or an empty string as to make sure that the ref you are creating does not exist." But in the code for pseudorefs, we do not implement this, as demonstrated by the failing tests added in the previous commit. If we fail to read the

Bug: Untracked file deleted by git-stash

I stumbled upon the following issue with git 2.11.0 on Debian 9. When a tracked file is removed and a directory with the same name is created, git-stash would delete the directory with all its contents. No warning is displayed and git stores no information about the deleted content (as far as I

Re: [PATCH 00/12] Integrate commit-graph into fsck, gc, and fetch

On Thu, May 10, 2018 at 12:05 PM, Martin Ågren wrote: > On 10 May 2018 at 19:34, Derrick Stolee wrote: > >> Commits 01-07 focus on the 'git commit-graph verify' subcommand. These >> are ready for full, rigorous review. > > I don't know about "full"

Re: [PATCH 00/12] Integrate commit-graph into fsck, gc, and fetch

On Thu, May 10 2018, Derrick Stolee wrote: > The behavior in this patch series does the following: > > 1. Near the end of 'git gc', run 'git commit-graph write'. The location >of this code assumes that a 'git gc --auto' has not terminated early >due to not meeting the auto threshold. > >

[RFC PATCH v2] Implement --first-parent for git rev-list --bisect.

This will enable users to implement bisecting on first parents which can be useful for when the commits from a feature branch that we want to merge are not always tested. Signed-off-by: Tiago Botelho --- This patch is based on pu so that it can be on top of

Re: [PATCH v2] add status config and command line options for rename detection

On 5/10/2018 12:19 PM, Elijah Newren wrote: Hi Ben, On Thu, May 10, 2018 at 7:16 AM, Ben Peart wrote: After performing a merge that has conflicts, git status will by default attempt to detect renames which causes many objects to be examined. In a virtualized repo,

Re: [PATCH 00/12] Integrate commit-graph into fsck, gc, and fetch

On 10 May 2018 at 19:34, Derrick Stolee wrote: > Commits 01-07 focus on the 'git commit-graph verify' subcommand. These > are ready for full, rigorous review. I don't know about "full" and "rigorous", but I tried to offer my thoughts. A lingering feeling I have is that

Re: Is rebase --force-rebase any different from rebase --no-ff?

Hi, If that's indeed true (as far as I could see that, still can be mistaken), then as a git user, not developer, I'd stick to --no-ff, because it's the more intuitive naming. Just 5¢. --- Best Regards, Ilya Kantor On Thu, May 10, 2018 at 9:34 PM, Marc Branchaud wrote: >

Re: [PATCH 1/1] Warn about fast-forwarding of submodules during merge

On Thu, May 10, 2018 at 11:26 AM, Leif Middelschulte wrote: > From: Leif Middelschulte Hi Leif! thanks for following up with a patch! > Warn the user about an automatically fast-forwarded submodule. The silent > merge > behavior was

Re: Is rebase --force-rebase any different from rebase --no-ff?

On 2018-05-09 03:46 PM, Ilya Kantor wrote: I tried to compare --force-rebase VS --no-ff for the following repository: http://jmp.sh/E7TRjcL There's no difference in the resulf of: git rebase --force-rebase 54a4 git rebase --no-ff 54a4 (rebases all 3 commits of feature) Also, there's no

Re: [PATCH 2/2] replace-object.c: remove the_repository from prepare_replace_object

> Using `git grep` I see 230 instances of 'xmalloc' and 261 instances of > 'xcalloc'. After the Coccinelle transformation, these are down to 194 and > 190, respectively, because the rest allocate in the same line as the > definition. It's worth thinking about the macro pattern for those cases.

Re: bug: SHA1 calculation on PPC machines when built with gcc older than 4.6

On Thu, May 10, 2018 at 8:11 PM, Ken Cunningham wrote: > Some vintage Apple PPC machines build a non-funtional version of git as of > git 13.1 when using the stock gcc compilers that are installed with the OS; > the SHA1 calculations are faulty. This can be

Re: [PATCH 04/12] commit-graph: verify fanout and lookup table

On 10 May 2018 at 19:34, Derrick Stolee wrote: > While running 'git commit-graph verify', verify that the object IDs > are listed in lexicographic order and that the fanout table correctly > navigates into that list of object IDs. > > Signed-off-by: Derrick Stolee

[PATCH 1/1] Warn about fast-forwarding of submodules during merge

From: Leif Middelschulte Warn the user about an automatically fast-forwarded submodule. The silent merge behavior was introduced by commit 68d03e4a6e44 ("Implement automatic fast-forward merge for submodules", 2010-07-07)). Signed-off-by: Leif Middelschulte

[PATCH 0/1] warn about auto fast-forwarded submodules during merges

From: Leif Middelschulte Warn the user during merges about automatically fast-forwarded submodules. This is just informational and does *not* change behavior otherwise. It is a follow up to Elijah Newren's suggestion[0] to provide the attached patch. [0]

Re: [PATCH 02/12] commit-graph: verify file header information

On 10 May 2018 at 19:34, Derrick Stolee wrote: > During a run of 'git commit-graph verify', list the issues with the > header information in the commit-graph file. Some of this information > is inferred from the loaded 'struct commit_graph'. Some header > information is

Re: [PATCH 01/12] commit-graph: add 'verify' subcommand

On 10 May 2018 at 19:34, Derrick Stolee wrote: > In case the commit-graph file becomes corrupt, we need a way to > verify its contents match the object database. In the manner of s/verify its/verify that its/ might read better. > 'git fsck' we will implement a 'git

bug: SHA1 calculation on PPC machines when built with gcc older than 4.6

Some vintage Apple PPC machines build a non-funtional version of git as of git 13.1 when using the stock gcc compilers that are installed with the OS; the SHA1 calculations are faulty. This can be repaired with a simple patch (attached). Stock vintage Apple PPC machines come with gcc-4.0 or

Re: Regression in patch add?

On 10/05/18 15:11, Oliver Joseph Ash wrote: > You found the problem Phillip! My editor was trimming trailing white space, > which breaks the context line. I'm glad we found the source of the problem (and that it wasn't some obscure bug) > I had tried to use an alternative editor to account for

Re: [GSoC] Info: Week 02 Blog Post

Hi Pratik, On Wed, May 9, 2018 at 8:07 PM, Pratik Karki wrote: > Hi, > > The week 02 blog post[1] is live. This post is part I out of II and this > time it will be biweekly. The part II of will come in 2-3 days which > will describe the current `git-rebase.sh`. Cool

[PATCH v2] commit-graph: fix UX issue when .lock file exists

We use the lockfile API to avoid multiple Git processes from writing to the commit-graph file in the .git/objects/info directory. In some cases, this directory may not exist, so we check for its existence. The existing code does the following when acquiring the lock: 1. Try to acquire the lock.

[PATCH 09/12] commit-graph: add '--reachable' option

When writing commit-graph files, it can be convenient to ask for all reachable commits (starting at the ref set) in the resulting file. This is particularly helpful when writing to stdin is complicated, such as a future integration with 'git gc' which will call 'git commit-graph write --reachable'

[PATCH 10/12] gc: automatically write commit-graph files

The commit-graph file is a very helpful feature for speeding up git operations. In order to make it more useful, write the commit-graph file by default during standard garbage collection operations. Add a 'gc.commitGraph' config setting that triggers writing a commit-graph file after any

[PATCH 05/12] commit: force commit to parse from object database

In anticipation of verifying commit-graph file contents against the object database, create parse_commit_internal() to allow side-stepping the commit-graph file and parse directly from the object database. Most consumers expect that if a commit exists in the commit-graph, then the commit was

[PATCH 11/12] fetch: compute commit-graph by default

During a call to 'git fetch', we expect new commits and updated refs. Use these updated refs to add the new commits to the commit-graph file, automatically providing performance benefits in other calls. Use 'fetch.commitGraph' config setting to enable or disable this behavior. Defaults to false

[PATCH 08/12] fsck: verify commit-graph

If core.commitGraph is true, verify the contents of the commit-graph during 'git fsck' using the 'git commit-graph verify' subcommand. Run this check on all alternates, as well. We use a new process for two reasons: 1. The subcommand decouples the details of loading and verifying a

[PATCH 03/12] commit-graph: parse commit from chosen graph

Before verifying a commit-graph file against the object database, we need to parse all commits from the given commit-graph file. Create parse_commit_in_graph_one() to target a given struct commit_graph. Signed-off-by: Derrick Stolee --- commit-graph.c | 18

[PATCH 06/12] commit-graph: load a root tree from specific graph

When lazy-loading a tree for a commit, it will be important to select the tree from a specific struct commit_graph. Create a new method that specifies the commit-graph file and use that in get_commit_tree_in_graph(). Signed-off-by: Derrick Stolee --- commit-graph.c | 10

[PATCH 07/12] commit-graph: verify commit contents against odb

When running 'git commit-graph verify', compare the contents of the commits that are loaded from the commit-graph file with commits that are loaded directly from the object database. This includes checking the root tree object ID, commit date, and parents. Parse the commit from the graph during

[PATCH 04/12] commit-graph: verify fanout and lookup table

While running 'git commit-graph verify', verify that the object IDs are listed in lexicographic order and that the fanout table correctly navigates into that list of object IDs. Signed-off-by: Derrick Stolee --- commit-graph.c | 33 + 1

[PATCH 12/12] commit-graph: update design document

The commit-graph feature is now integrated with 'fsck' and 'gc', so remove those items from the "Future Work" section of the commit-graph design document. Also remove the section on lazy-loading trees, as that was completed in an earlier patch series. Signed-off-by: Derrick Stolee

[PATCH 02/12] commit-graph: verify file header information

During a run of 'git commit-graph verify', list the issues with the header information in the commit-graph file. Some of this information is inferred from the loaded 'struct commit_graph'. Some header information is checked as part of load_commit_graph_one(). Signed-off-by: Derrick Stolee

[PATCH 01/12] commit-graph: add 'verify' subcommand

In case the commit-graph file becomes corrupt, we need a way to verify its contents match the object database. In the manner of 'git fsck' we will implement a 'git commit-graph verify' subcommand to report all issues with the file. Add the 'verify' subcommand to the 'commit-graph' builtin and its

[PATCH 00/12] Integrate commit-graph into fsck, gc, and fetch

The commit-graph feature is not useful to end users until the commit-graph file is maintained automatically by Git during normal upkeep operations. One natural place to trigger this write is during 'git gc'. Before automatically generating a commit-graph, we need to be able to verify the contents

Re: [PATCH v4 00/13] object store: alloc

On Thu, May 10, 2018 at 10:16 AM, Jonathan Tan wrote: > On Wed, 9 May 2018 17:40:11 -0700 > Stefan Beller wrote: > >> if (obj->type == OBJ_TREE) >> - release_tree_node((struct tree*)obj); >> +

Re: [PATCH 1/2] object.c: free replace map in raw_object_store_clear

Hi Junio, On Thu, May 10, 2018 at 3:16 AM, Junio C Hamano wrote: > Stefan Beller writes: > >> The replace map for objects was missed to free in the object store in >> the conversion of 174774cd519 (Merge branch 'sb/object-store-replace', >> 2018-05-08) > >

Re: [PATCH 1/9] Add and use generic name->id mapping code for color slot parsing

On Thu, May 10, 2018 at 7:19 AM, Nguyễn Thái Ngọc Duy wrote: > 7 files changed, 82 insertions(+), 112 deletions(-) Nice! > > +static const char *color_branch_slots[] = { > + [BRANCH_COLOR_RESET]= "reset", In 512f41cfac5 (clean.c: use designated initializer,

Re: [PATCH v4 00/13] object store: alloc

On Wed, 9 May 2018 17:40:11 -0700 Stefan Beller wrote: > if (obj->type == OBJ_TREE) > - release_tree_node((struct tree*)obj); > + free_tree_buffer((struct tree*)obj); > else if (obj->type == OBJ_COMMIT) > -

Re: [PATCH v2] pack-format.txt: more details on pack file format

On Thu, May 10, 2018 at 8:09 AM, Nguyễn Thái Ngọc Duy wrote: > The current document mentions OBJ_* constants without their actual > values. A git developer would know these are from cache.h but that's > not very friendly to a person who wants to read this file to implement > a

Re: [PATCH] repository: fix free problem with repo_clear(the_repository)

Hi Junio, On Thu, May 10, 2018 at 2:27 AM, Junio C Hamano wrote: > Stefan Beller writes: > >> So this would go with the latest sb/object-store-alloc ? >> >> My impression was that we never call repo_clear() on >> the_repository, which would allow us to

Re: [PATCH v2] add status config and command line options for rename detection

Hi Ben, On Thu, May 10, 2018 at 7:16 AM, Ben Peart wrote: > After performing a merge that has conflicts, git status will by default > attempt > to detect renames which causes many objects to be examined. In a virtualized > repo, those objects do not exist locally so

Re: [PATCH v4 6/6] get_short_oid: document & warn if we ignore the type selector

On Thu, May 10, 2018 at 12:03:22PM -0400, Jeff King wrote: > And finally, your 06fa example for me shows behavior that's either > buggy, or I'm just confused. I get: > > $ git rev-parse 06fa^{blob} > error: short SHA1 06fa is ambiguous > hint: The candidates are: > hint: 06fa2b7c2b tag

Re: [PATCH v4 6/6] get_short_oid: document & warn if we ignore the type selector

On Thu, May 10, 2018 at 12:03:22PM -0400, Jeff King wrote: > But some cases _don't_ issue an error. For example, try this: > > $ git log ..06faf > > which returns an empty output! We return the single matching tree, even > though the ".." triggers the commit hint. The revision machinery just

Re: [PATCH v4 0/6] get_short_oid UI improvements

On Thu, May 10, 2018 at 12:42:57PM +, Ævar Arnfjörð Bjarmason wrote: > This is like v3 except all the patches to the peel syntax & docs have > been dropped, which were controversial. > > I think it's worthwhile to re-work that, but I don't have time for > that now, so I'm submitting this.

Re: [PATCH v4 6/6] get_short_oid: document & warn if we ignore the type selector

On Thu, May 10, 2018 at 12:43:03PM +, Ævar Arnfjörð Bjarmason wrote: > The SHA1 prefix 06fa currently matches no blobs in git.git. When > disambiguating short SHA1s we've been quietly ignoring the user's type > selector as a fallback mechanism, this was intentionally added in > 1ffa26c461

Re: [PATCH v3 13/13] alloc: allow arbitrary repositories for alloc functions

On Wed, May 9, 2018 at 9:20 PM, Stefan Beller wrote: > On Wed, May 9, 2018 at 10:18 AM, Duy Nguyen wrote: >> >> If you want to reproduce, this is what I used to test this with. >> >> https://gist.github.com/pclouds/86a2df6c28043f1b6fa3d4e72e7a1276 > > This

Re: [PATCH v4 5/6] get_short_oid: sort ambiguous objects by type, then SHA-1

On Thu, May 10, 2018 at 12:43:02PM +, Ævar Arnfjörð Bjarmason wrote: > Now we'll instead show: > > hint: e8f2650052 tag v2.17.0 > hint: e8f21caf94 commit 2013-06-24 - bash prompt: print unique detached > HEAD abbreviated object name > hint: e8f26250fa commit 2017-02-03 -

[PATCH v2] pack-format.txt: more details on pack file format

The current document mentions OBJ_* constants without their actual values. A git developer would know these are from cache.h but that's not very friendly to a person who wants to read this file to implement a pack file parser. Similarly, the deltified representation is not documented at all (the

Re: [PATCH v4 2/6] sha1-array.h: align function arguments

On Thu, May 10, 2018 at 12:42:59PM +, Ævar Arnfjörð Bjarmason wrote: > The arguments weren't lined up with the opening parenthesis. Fixes up > code added in aae0caf19e ("sha1-array.h: align function arguments", > 2018-04-30). I think that's this patch. :) Presumably you meant 910650d2f8

Re: [PATCH v4 3/6] git-p4: change "commitish" typo to "committish"

On 10 May 2018 at 13:43, Ævar Arnfjörð Bjarmason wrote: > This was the only occurrence of "commitish" in the tree, but as the > log will reveal we've had others in the past. Fixes up code added in > 00ad6e3182 ("git-p4: work with a detached head", 2015-11-21). > > Signed-off-by:

Re: [PATCH] t5310-pack-bitmaps: make JGit tests work with GIT_TEST_SPLIT_INDEX

On Thu, May 10, 2018 at 4:34 PM, Jeff King wrote: > On Thu, May 10, 2018 at 03:58:52PM +0200, SZEDER Gábor wrote: >> Since testing bitmaps doesn't need a worktree in the first place, >> let's just create bare clones for the two JGit tests, so the cloned >> won't have an index, and

Re: [PATCH 2/2] replace-object.c: remove the_repository from prepare_replace_object

On 5/10/2018 7:56 AM, Jeff King wrote: On Thu, May 10, 2018 at 07:23:13PM +0900, Junio C Hamano wrote: This one was doing ptr = xmalloc(sizeof(*another_ptr)) and it was OK because ptr and another_ptr happened to be of the same type. I wonder if we are making it safer, or making it

Re: [PATCH] t5310-pack-bitmaps: make JGit tests work with GIT_TEST_SPLIT_INDEX

On Thu, May 10, 2018 at 03:58:52PM +0200, SZEDER Gábor wrote: > The two JGit tests 'we can read jgit bitmaps' and 'jgit can read our > bitmaps' in 't5310-pack-bitmaps.sh' fail when run with > GIT_TEST_SPLIT_INDEX=YesPlease. Both tests create a clone of the test > repository to check bitmap

[PATCH] apply: clarify "-p" documentation

On Fri, Apr 27, 2018 at 12:40:05PM -0500, kelly elton wrote: > > -p > > Remove leading slashes from traditional diff paths. The default is 1. > > This suggests to me the following outcomes: > 1) home/user/repos/myrepo with -p1 becomes home/user/repos/myrepo > 2) home/user/repos/myrepo with -p2

Re: [PATCH 0/9] completion: avoid hard coding config var list

On Thu, May 10, 2018 at 4:19 PM, Nguyễn Thái Ngọc Duy wrote: > (on top of nd/command-list) Oh.. and it does make use of C99 designated initializer feature. I could go with out it, but since git-clean has used it for some time without anybody complaining, I figure I should take

Re: Missing --relative documentation

On Fri, Apr 27, 2018 at 12:24:26PM -0500, kelly elton wrote: > git format-patch is missing documentation for --relative. > There is also no auto complete(or tab complete, whatever it's called) > for the --relative switch/argument. The missing documentation is due to the ancient d4cb003fff

[PATCH 4/9] help: add --config to list all available config

Sometimes it helps to list all available config vars so the user can search for something they want. The config man page can also be used but it's harder to search if you want to focus on the variable name, for example. Signed-off-by: Nguyễn Thái Ngọc Duy ---

[PATCH 5/9] advice: keep config name in camelCase in advice_config[]

For parsing, we don't really need this because the main config parser will lowercase everything so we can do exact matching. But this array now is also used for printing in `git help --config`. Keep camelCase so we have a nice printout. Signed-off-by: Nguyễn Thái Ngọc Duy ---

[PATCH 8/9] completion: support case-insensitive config vars just a bit

config variable names are technically case-insensitive while this case construct is by default case-sensitive. Moving it to case-insensitive could be a lot more work. Instead let's just accept the form that is more likely to show up in practice. Signed-off-by: Nguyễn Thái Ngọc Duy

[PATCH 9/9] log-tree: allow to customize 'grafted' color

Commit 76f5df305b (log: decorate grafted commits with "grafted" - 2011-08-18) lets us decorate grafted commits but I forgot about the color.decorate.* config. Signed-off-by: Nguyễn Thái Ngọc Duy --- Documentation/config.txt | 3 ++- log-tree.c | 1 + 2 files

[PATCH 0/9] completion: avoid hard coding config var list

This is part of the attempt to automate more in git-completion.bash. This series is about making 'git' binary provide the list of recognized configuration variables and feeding it to git-completion.bash. The approach is less than ideal. Unlike parse-options, we don't have a reliable source for

[PATCH 2/9] grep: keep all colors in an array

This is more inline with how we handle color slots in other code. It also allows us to get the list of configurable color slots later. Signed-off-by: Nguyễn Thái Ngọc Duy --- grep.c | 106 ++--- grep.h | 21 +++- 2

  1   2   >