Re: gc and repack ignore .git/*HEAD when checking reachability

Josh Triplett writes: > This could result in data loss, if a user expected that having an object > referenced from those places would protect it from pruning. Yeah, luckily, nobody expects such. I do not think any of our document says nothing other than HEAD like

gc and repack ignore .git/*HEAD when checking reachability

The manpage for git gc says: > git gc tries very hard to be safe about the garbage it collects. In > particular, it will keep not only objects referenced by your current > set of branches and tags, but also objects referenced by the index, > remote-tracking branches, refs saved by git

Re: git branch doesn't allow me to forcibly delete branch which was checked out in a now-deleted worktree dir

On Thu, Jul 07, 2016 at 04:39:26PM -0700, Jacob Keller wrote: On Thu, Jul 7, 2016 at 11:44 AM, Erik Johnson wrote: % git branch -D archive-extracted-xz error: Cannot delete branch 'archive-extracted-xz' checked out at '/home/erik/git/salt/archive-extracted-xz' % test -d

Re: git branch doesn't allow me to forcibly delete branch which was checked out in a now-deleted worktree dir

On Thu, Jul 7, 2016 at 11:44 AM, Erik Johnson wrote: > % git branch -D archive-extracted-xz > error: Cannot delete branch 'archive-extracted-xz' checked out at > '/home/erik/git/salt/archive-extracted-xz' > % test -d /home/erik/git/salt/archive-extracted-xz || echo "directory

Re: [PATCH v3 3/3] correct ce_compare_data() in a middle of a merge

Junio C Hamano writes: > I am however not convinced passing the full SHA-1 is a good > solution. The make_cache_entry() function may be creating a cache > entry to stuff in a non-default index (i.e. not "the_index"), but > its caller does not have a way to tell it which index

Re: [PATCH 2/4] receive-pack: implement advertising and receiving push options

On Thu, Jul 07, 2016 at 03:06:31PM -0700, Stefan Beller wrote: > > The problem is for hosting sites which serve repositories via git-daemon > > from untrusted users who have real shell accounts (e.g., you set up > > git-daemon to run as the "daemon" user serving repositories out of > > people's

Re: [PATCH 2/4] receive-pack: implement advertising and receiving push options

Stefan Beller writes: > No, there is no good objective reason. I added it just after the atomic > flag as that is what I implemented. > > Is there a reason for a particular order of capabilities? I always considered > it a set of strings, i.e. any order is valid and there is

Re: [PATCH 2/4] receive-pack: implement advertising and receiving push options

On Thu, Jul 7, 2016 at 2:56 PM, Jeff King wrote: > On Thu, Jul 07, 2016 at 02:41:37PM -0700, Stefan Beller wrote: > >> >> + /* NEEDSWORK: expose the limitations to be configurable. */ >> >> + int max_options = 32; >> >> + >> >> + /* >> >> + * NEEDSWORK: expose the

Re: [PATCH 2/4] receive-pack: implement advertising and receiving push options

On Thu, Jul 07, 2016 at 02:41:37PM -0700, Stefan Beller wrote: > >> + /* NEEDSWORK: expose the limitations to be configurable. */ > >> + int max_options = 32; > >> + > >> + /* > >> + * NEEDSWORK: expose the limitations to be configurable; > >> + * Once the limit can be

Re: [PATCH 1/4] push options: {pre,post}-receive hook learns about push options

Stefan Beller writes: > But your first patch (2/4) would not yet advertise the capability? > Or advertise and then just ignoring it? As I wrote... >> If I were doing this series, I >> would probably have done 2/4 first without plumbing it through >> (i.e. it is sent and

Re: [PATCH 4/4] add a test for push options

On Thu, Jul 7, 2016 at 1:01 PM, Junio C Hamano wrote: > On Thu, Jul 7, 2016 at 12:51 PM, Junio C Hamano wrote: >> Stefan Beller writes: >> >>> The functions `mk_repo_pair` as well as `test_refs` are borrowed from >>> t5543-atomic-push,

Re: [PATCH 1/4] push options: {pre,post}-receive hook learns about push options

On Thu, Jul 7, 2016 at 1:20 PM, Junio C Hamano wrote: > > What is suboptimal about the structure of the series is that we > won't bisect down to any of the potential bugs in the above code > even if we ever see any bug in the future. > It also does not hint > where push_options

Re: [PATCH 2/4] receive-pack: implement advertising and receiving push options

On Thu, Jul 7, 2016 at 1:37 PM, Junio C Hamano wrote: > >> @@ -207,6 +214,8 @@ static void show_ref(const char *path, const unsigned >> char *sha1) >> "report-status delete-refs side-band-64k quiet"); >> if (advertise_atomic_push) >>

Re: What's cooking in git.git (Jul 2016, #02; Wed, 6)

On Thu, Jul 07, 2016 at 02:21:28PM -0700, Junio C Hamano wrote: > Charles Bailey writes: > > > I just wanted to clarify what was actually fixed. The actual bug that > > was reported and fixed was the fact that 'git grep' (without --cached) > > wasn't searching the contents

Re: What's cooking in git.git (Jul 2016, #02; Wed, 6)

Charles Bailey writes: > I just wanted to clarify what was actually fixed. The actual bug that > was reported and fixed was the fact that 'git grep' (without --cached) > wasn't searching the contents of files in the working tree if the index > entry had the "intent to add"

Re: [PATCH] Makefile: add NEEDS_LIBRT to optionally link with librt

Ronald Wampler writes: > I am not sure if this the correction solution. Another option I > considered was to wrap the EXTLIBS += -lrt is an ifndef NO_RT and only > defining NO_RT for Mac OS X in config.mak.uname. That alternative would make the resulting code noisier/uglier

Re: [PATCH] notes-merge: use O_EXCL to avoid overwriting existing files

Jeff King writes: > Why do we care that the file exists? Should we instead be using the > lockfile code to get exclusive access to it? That would also switch us > to doing the write-to-tempfile-and-rename dance, but that seems like it > would be a good thing. If we hit a write()

Re: [PATCH 3/4] push: accept push options

Stefan Beller writes: > +-L:: > +--push-option:: > + Transmit the given string to the server, which passes them to > + the pre-receive as well as the post-receive hook. Only C strings > + containing no new lines are allowed. This is to affect what happens at the

Re: [PATCH] pack-objects: Use reachability bitmap index when generating non-stdout pack too

On Thu, Jul 07, 2016 at 10:09:17PM +0300, Kirill Smelkov wrote: > Starting from 6b8fda2d (pack-objects: use bitmaps when packing objects) > if a repository has bitmap index, pack-objects can nicely speedup > "Counting objects" graph traversal phase. That however was done only for > case when

[PATCH] Makefile: add NEEDS_LIBRT to optionally link with librt

We unconditionally link with librt, when HAVE_CLOCK_GETTIME is defined. But clock_gettime() has been available in most libc implementations for some time now (e.g., for glibc since version 2.17) and no longer requires linking with librt. Furthermore, commit a6c3c63 (configure.ac: check for

Re: What's cooking in git.git (Jul 2016, #02; Wed, 6)

On Wed, Jul 06, 2016 at 02:39:26PM -0700, Junio C Hamano wrote: > * nd/ita-cleanup (2016-07-01) 3 commits > (merged to 'next' on 2016-07-06 at f15aeba) > + grep: fix grepping for "intent to add" files > + t7810-grep.sh: fix a whitespace inconsistency > + t7810-grep.sh: fix duplicated test

Re: [PATCH 2/4] receive-pack: implement advertising and receiving push options

Stefan Beller writes: > While documenting > this, fix a nit in the `receive.advertiseAtomic` wording. > > receive.advertiseAtomic:: > By default, git-receive-pack will advertise the atomic push > - capability to its clients. If you don't want to this capability >

Re: [PATCH] notes-merge: use O_EXCL to avoid overwriting existing files

On Thu, Jul 07, 2016 at 10:08:30PM +0200, René Scharfe wrote: > Use the open(2) flag O_EXCL to ensure the file doesn't already exist > instead of (racily) calling stat(2) through file_exists(). While at it > switch to xopen() to reduce code duplication and get more consistent > error messages.

Re: [PATCH] am: ignore return value of write_file()

On Thu, Jul 07, 2016 at 10:02:14PM +0200, René Scharfe wrote: > write_file() either returns 0 or dies, so there is no point in checking > its return value. The callers of the wrappers write_state_text(), > write_state_count() and write_state_bool() consequently already ignore > their return

Re: [PATCH 1/4] push options: {pre,post}-receive hook learns about push options

Stefan Beller writes: > As we first want to focus on getting simple strings to work > reliably, we go with the last option for now. OK. > diff --git a/Documentation/githooks.txt b/Documentation/githooks.txt > index d82e912..c875cde 100644 > --- a/Documentation/githooks.txt

[PATCH] .gitattributes: set file type for C files

Set the diff attribute for C source file to "cpp" in order to improve git's ability to determine hunk headers. In particular it helps avoid showing unindented labels in hunk headers. That in turn is useful for git diff -W and git grep -W, which show whole functions now instead of stopping at a

[PATCH] notes-merge: use O_EXCL to avoid overwriting existing files

Use the open(2) flag O_EXCL to ensure the file doesn't already exist instead of (racily) calling stat(2) through file_exists(). While at it switch to xopen() to reduce code duplication and get more consistent error messages. Signed-off-by: Rene Scharfe --- notes-merge.c | 6

[PATCH] am: ignore return value of write_file()

write_file() either returns 0 or dies, so there is no point in checking its return value. The callers of the wrappers write_state_text(), write_state_count() and write_state_bool() consequently already ignore their return values. Stop pretenting we care and make them void. Signed-off-by: Rene

Re: [PATCH 4/4] add a test for push options

On Thu, Jul 7, 2016 at 12:51 PM, Junio C Hamano wrote: > Stefan Beller writes: > >> The functions `mk_repo_pair` as well as `test_refs` are borrowed from >> t5543-atomic-push, with additional hooks installed. >> >> Signed-off-by: Stefan Beller

Re: [PATCH 4/4] add a test for push options

Stefan Beller writes: > The functions `mk_repo_pair` as well as `test_refs` are borrowed from > t5543-atomic-push, with additional hooks installed. > > Signed-off-by: Stefan Beller > --- > t/t5544-push-options.sh | 101 >

[PATCH] pack-objects: Use reachability bitmap index when generating non-stdout pack too

Starting from 6b8fda2d (pack-objects: use bitmaps when packing objects) if a repository has bitmap index, pack-objects can nicely speedup "Counting objects" graph traversal phase. That however was done only for case when resultant pack is sent to stdout, not written into a file. We can teach

[PATCH] Add very verbose porcelain output to status

Tools interacting with Git repositories may need to know the complete state of the working directory. For efficiency, it would be good to have a single command to obtain this information. We already have a `--porcelain` mode intended for tools' consumption, and it only makes sense to enhance this

Re: [PATCH v2 2/2] cache-tree: do not generate empty trees as a result of all i-t-a subentries

Duy Nguyen writes: > I'll deal with that separately. Let's focus on cache-tree only this > time. So how about this on top? I was hoping that you would limit the scope of the test to check if write-tree does the right thing. i.e. not test "git commit", but test "git

Re: [PATCH v3 3/3] correct ce_compare_data() in a middle of a merge

Torsten Bögershausen writes: > This is the callstack: > > merge-recursive.c/add_cacheinfo(unsigned int mode, const unsigned char *sha1, > const char *path, int stage, int refresh, int options) > { > struct cache_entry *ce; > ce = make_cache_entry >

git branch doesn't allow me to forcibly delete branch which was checked out in a now-deleted worktree dir

% git branch -D archive-extracted-xz error: Cannot delete branch 'archive-extracted-xz' checked out at '/home/erik/git/salt/archive-extracted-xz' % test -d /home/erik/git/salt/archive-extracted-xz || echo "directory doesn't exist" directory doesn't exist % git --version git version 2.9.0 I

Re: [PATCH v2 2/2] cache-tree: do not generate empty trees as a result of all i-t-a subentries

On Wed, Jul 06, 2016 at 12:26:19PM -0700, Junio C Hamano wrote: > Nguyễn Thái Ngọc Duy writes: > > > @@ -426,6 +433,15 @@ int cache_tree_update(struct index_state *istate, int > > flags) > > i = update_one(it, cache, entries, "", 0, , flags); > > if (i < 0) > >

Re: [RFC] Questions for "Git User's Survey 2016"

On Thu, Jul 7, 2016 at 8:03 AM, Jakub Narębski wrote: > I am thinking about returning to doing the Git User's Survey, and > I'd like to ask for feedback. Thanks for doing the survey! > > What I'd like to see is how people use Git, which features do they > use and which tools

Re: [PATCH v3 3/3] correct ce_compare_data() in a middle of a merge

On 2016-07-06 16.57, Junio C Hamano wrote: > Torsten Bögershausen writes: > >> At some point inside the merge, Git calls read-cache.c/ce_compare_data(), >> to check if the path named "file" is clean. >> According to the tree information, the path "file" has the sha1 99b633. >>

Re: bug: depth 1 and recursive update of submodules broke in 2.9.0

See the discussion and bug fix at http://thread.gmane.org/gmane.comp.version-control.git/297687/focus=297719 This is a known regression in 2.9.0 and the fix is in the master branch already. (I think Junio will also roll it into 2.9.1) -- To unsubscribe from this list: send the line "unsubscribe

bug: depth 1 and recursive update of submodules broke in 2.9.0

When I try to ```git clone --depth 1 --recursive https://github.com/davidhalter/jedi-vim.git``` in 2.9.0, it fails with the message: ``` Cloning into 'jedi-vim'... remote: Counting objects: 37, done. remote: Compressing objects: 100% (27/27), done. remote: Total 37 (delta 1), reused 16 (delta 0),

Re: [PATCH] am: counteract gender bias

Jakub Narębski writes: > Also, in all (?) other places we use "ours" and "theirs"; it looks like > git-am was a strange exception with "ours" and "his" (also, it was/is > inconsistent in using plural vs singular form). Though perhaps it was > created before the terminology

Re: [PATCH v2 11/17] am: counteract gender bias

Johannes Schindelin writes: > Hi Junio, > > On Thu, 7 Jul 2016, Junio C Hamano wrote: > >> Johannes Schindelin writes: >> >> >> I doubt this kind fo distraction is desirable in the middle of a >> >> seriously heavy series like this one.

Re: [PATCH v2 11/17] am: counteract gender bias

Hi Junio, On Thu, 7 Jul 2016, Junio C Hamano wrote: > Johannes Schindelin writes: > > >> I doubt this kind fo distraction is desirable in the middle of a > >> seriously heavy series like this one. As a standalone clean-up to > >> turn these directly to "their" that

[PATCH v2 0/3] Additional rebase -i tests

This is just another patch series in preparation for the rebase--helper. Relative to v1 of this patch series, - the grammo fix was backed out because it was picked up separately, - two new tests were introduced, one demonstrating a bug, the other one ensuring that the rebase--helper does not

[PATCH v2 1/3] t3404: add a test for the --gpg-sign option

For the upcoming rebase--helper work (which will accelerate the interactive rebase noticably), it is important to verify that the --gpg-sign option is handled properly. Please note that this patch does this on the cheap, by verifying that the expected option is printed in the message of the

[PATCH v2 2/3] rebase -i: demonstrate a bug with --autosquash

When rearranging the edit script, we happily mistake the comment character for a command, and the command for a SHA-1. As a consequence, when we move fixup! and squash! commits, our logic to skip lines with already handled SHA-1s mistakenly skips anything but the first commented-out pick line,

[PATCH v2 3/3] rebase -i: we allow extra spaces after fixup!/squash!

This new test case ensures that we handle commit messages that start with fixup! or squash! followed by more than one space. While we do not generate such messages when committing with --fixup/--squash, it is perfectly legal for users to hand-craft their own fixup messages, and we heed Postel's

Re: [PATCH v2 11/17] am: counteract gender bias

Johannes Schindelin writes: >> I doubt this kind fo distraction is desirable in the middle of a >> seriously heavy series like this one. As a standalone clean-up to >> turn these directly to "their" that everybody would agree on and can >> be merged down quickly to

Re: [PATCH 2/2] t3404: add a test for the --gpg-sign option

Hi Junio, On Wed, 6 Jul 2016, Junio C Hamano wrote: > Johannes Schindelin writes: > > > Okay, so here is the deal: on the development machine where this was > > developed, I do not have gpg installed. So please take this test case just > > to make sure that things

[RFC] Questions for "Git User's Survey 2016"

I am thinking about returning to doing the Git User's Survey, and I'd like to ask for feedback. Thanks to generocity of Survs.com, we have been gifted with premium annual plan (previous surveys always generated quite a large number of responses). This plan will last (at least; it was usually

[PATCH v3 16/16] merge-recursive: flush output buffer even when erroring out

Ever since 66a155b (Enable output buffering in merge-recursive., 2007-01-14), we had a problem: When the merge failed in a fatal way, all regular output was swallowed because we called die() and did not get a chance to drain the output buffers. To fix this, several modifications were necessary:

[PATCH v3 15/16] Ensure that the output buffer is released after calling merge_trees()

The recursive merge machinery accumulates its output in an output buffer, to be flushed at the end of merge_recursive(). At this point, we forgot to release the output buffer. When calling merge_trees() (i.e. the non-recursive part of the recursive merge) directly, the output buffer is never

[PATCH v3 13/16] merge-recursive: write the commit title in one go

In 66a155b (Enable output buffering in merge-recursive., 2007-01-14), we changed the code such that it prints the output in one go, to avoid interfering with the progress output. Let's make sure that the same holds true when outputting the commit title: previously, we used several printf()

[PATCH v3 10/16] merge-recursive: switch to returning errors instead of dying

The recursive merge machinery is supposed to be a library function, i.e. it should return an error when it fails. Originally the functions were part of the builtin "merge-recursive", though, where it was simpler to call die() and be done with error handling. The existing callers were already

[PATCH v3 12/16] merge-recursive: flush output buffer before printing error messages

The data structure passed to the recursive merge machinery has a feature where the caller can ask for the output to be buffered into a strbuf, by setting the field 'buffer_output'. Previously, we simply swallowed the buffered output when showing error messages. With this patch, we show the output

[PATCH v3 04/16] merge-recursive: clarify code in was_tracked()

It can be puzzling to see that was_tracked() asks to get an index entry by name, but does not take a negative return value for an answer. The reason we have to do this is that cache_name_pos() only looks for entries in stage 0, even if nobody asked for any stage in particular. Let's rewrite the

[PATCH v3 06/16] merge_recursive: abort properly upon errors

There are a couple of places where return values indicating errors are ignored. Let's teach them manners. Signed-off-by: Johannes Schindelin --- merge-recursive.c | 10 -- 1 file changed, 8 insertions(+), 2 deletions(-) diff --git a/merge-recursive.c

[PATCH v3 11/16] am -3: use merge_recursive() directly again

Last October, we had to change this code to run `git merge-recursive` in a child process: git-am wants to print some helpful advice when the merge failed, but the code in question was not prepared to return, it die()d instead. We are finally at a point when the code *is* prepared to return

[PATCH v3 08/16] merge-recursive: allow write_tree_from_memory() to error out

It is possible that a tree cannot be written (think: disk full). We will want to give the caller a chance to clean up instead of letting the program die() in such a case. Signed-off-by: Johannes Schindelin --- merge-recursive.c | 4 ++-- 1 file changed, 2

[PATCH v3 05/16] Prepare the builtins for a libified merge_recursive()

Previously, callers of merge_trees() or merge_recursive() expected that code to die() with an error message. This used to be okay because we called those commands from scripts, and had a chance to print out a message in case the command failed fatally (read: with exit code 128). As scripting

[PATCH v3 09/16] merge-recursive: handle return values indicating errors

We are about to libify the recursive merge machinery, where we only die() in case of a bug or memory contention. To that end, we must heed negative return values as indicating errors. This requires our functions to be careful to pass through error conditions in call chains, and for quite a few

[PATCH v3 07/16] merge-recursive: avoid returning a wholesale struct

It is technically allowed, as per C89, for functions' return type to be complete structs (i.e. *not* just pointers to structs). However, it was just an oversight of this developer when converting Python code to C code in 6d297f8 (Status update on merge-recursive in C, 2006-07-08) which introduced

[PATCH v3 03/16] Avoid translating bug messages

While working on the patch series that avoids die()ing in recursive merges, the issue came up that bug reports (i.e. die("BUG: ...") constructs) should never be translated, as the target audience is the Git developer community, not necessarily the current user, and hence a translated message would

[PATCH v3 14/16] merge-recursive: offer an option to retain the output in 'obuf'

Since 66a155b (Enable output buffering in merge-recursive., 2007-01-14), we already accumulate the output in a buffer. The idea was to avoid interfering with the progress output that goes to stderr, which is unbuffered, when we write to stdout, which is buffered. We extend that buffering to allow

[PATCH v3 01/16] Verify that `git pull --rebase` shows the helpful advice when failing

Signed-off-by: Johannes Schindelin --- t/t5520-pull.sh | 30 ++ 1 file changed, 30 insertions(+) diff --git a/t/t5520-pull.sh b/t/t5520-pull.sh index 5d4880e..217b416 100755 --- a/t/t5520-pull.sh +++ b/t/t5520-pull.sh @@ -255,6 +255,36 @@

[PATCH v3 00/16] Use merge_recursive() directly in the builtin am

This is the second iteration of the long-awaited re-roll of the attempt to avoid spawning merge-recursive from the builtin am and use merge_recursive() directly instead. The *real* reason for the reroll is that I need a libified recursive merge to accelerate the interactive rebase by teaching the

[PATCH v3 02/16] Report bugs consistently

The vast majority of error messages in Git's source code which report a bug use the convention to prefix the message with "BUG:". As part of cleaning up merge-recursive to stop die()ing except in case of detected bugs, let's just make the remainder of the bug reports consistent with the de facto

Re: [PATCH] am: counteract gender bias

Hi Kuba, On Thu, 7 Jul 2016, Jakub Narębski wrote: > Instead of nebulous "fairness" (i.e., be unfair in other direction), > [...] There is nothing nebulous about it. Ciao, Dscho

Re: [PATCH] am: counteract gender bias

Hi Mike, On Thu, 7 Jul 2016, Mike Hommey wrote: > On Thu, Jul 07, 2016 at 01:47:19PM +0200, Johannes Schindelin wrote: > > Since d1c5f2a (Add git-am, applymbox replacement., 2005-10-07), i.e. for > > almost 11 years already, we demonstrated our disrespect to the pioneers > > of software

Re: [PATCH] am: counteract gender bias

W dniu 2016-07-07 o 14:49, Mike Hommey pisze: > On Thu, Jul 07, 2016 at 01:47:19PM +0200, Johannes Schindelin wrote: >> Since d1c5f2a (Add git-am, applymbox replacement., 2005-10-07), i.e. for >> almost 11 years already, we demonstrated our disrespect to the pioneers >> of software development

Re: [PATCH] am: counteract gender bias

On Thu, Jul 07, 2016 at 01:47:19PM +0200, Johannes Schindelin wrote: > Since d1c5f2a (Add git-am, applymbox replacement., 2005-10-07), i.e. for > almost 11 years already, we demonstrated our disrespect to the pioneers > of software development like Ada Lovelace, Grace Hopper and Margaret >

Re: [PATCH v14 21/21] mailmap: use main email address for dturner

Hi, On Wed, 6 Jul 2016, Junio C Hamano wrote: > David Turner writes: > > > Signed-off-by: David Turner > > --- > > .mailmap | 1 + > > 1 file changed, 1 insertion(+) > > > > diff --git a/.mailmap b/.mailmap > > index e5b4126..edcae89 100644 > > ---

[PATCH] am: counteract gender bias

Since d1c5f2a (Add git-am, applymbox replacement., 2005-10-07), i.e. for almost 11 years already, we demonstrated our disrespect to the pioneers of software development like Ada Lovelace, Grace Hopper and Margaret Hamilton, by pretending that each and every software developer is male ("his_tree").

Re: [PATCH v2 11/17] am: counteract gender bias

Hi Junio, On Wed, 6 Jul 2016, Junio C Hamano wrote: > Johannes Schindelin writes: > > > Since d1c5f2a (Add git-am, applymbox replacement., 2005-10-07), i.e. for > > almost 11 years already,... > > ...Let's start changing that by using the variable name "her_tree"

Re: [PATCH v2 02/17] Report bugs consistently

Hi Duy, On Wed, 6 Jul 2016, Duy Nguyen wrote: > On Tue, Jul 5, 2016 at 1:23 PM, Johannes Schindelin > wrote: > > The vast majority of error messages in Git's source code which report a > > bug use the convention to prefix the message with "BUG:". > > > > As part of

Re: [PATCH 2/9] merge-recursive: clarify code in was_tracked()

Hi Junio, On Wed, 6 Jul 2016, Junio C Hamano wrote: > Johannes Schindelin writes: > > > To understand why we're not done yet, the crucial point is *not* that the > > return value encodes the insert position. The crucial point is that > > despite asking for an index

Re: [PATCH v2 00/17] Use merge_recursive() directly in the builtin am

Hi Junio, On Wed, 6 Jul 2016, Junio C Hamano wrote: > Johannes Schindelin writes: > > > This is the second iteration of the long-awaited re-roll of the attempt to > > avoid spawning merge-recursive from the builtin am and use merge_recursive() > > directly instead.