Re: [PATCH v9 0/4] worktree: teach "add" to check out existing branches

On 04/27, Eric Sunshine wrote: > On Tue, Apr 24, 2018 at 5:56 PM, Thomas Gummerer wrote: > > Thanks Eric for the review and the suggestions on the previous round. > > > > Changes since the previous round: > > > > - UNLEAK new_branch after it was xstrndup'd > > - update the

Re: [PATCH 2/6] sequencer: learn about the special "fake root commit" handling

On Fri, Apr 27, 2018 at 3:31 PM, Johannes Schindelin wrote: > When an interactive rebase wants to recreate a root commit, it > - first creates a new, empty root commit, > - checks it out, > - converts the next `pick` command so that it amends the empty root > commit

Re: [PATCH 3/6] rebase -i --root: let the sequencer handle even the initial part

On Fri, Apr 27, 2018 at 3:31 PM, Johannes Schindelin wrote: > In this developer's earlier attempt to accelerate interactive rebases by > converting large parts from Unix shell script into portable, performant > C, the --root handling was specifically excluded (to

Re: [RFC PATCH] checkout: Force matching mtime between files

On Fri, Apr 27, 2018 at 11:08 PM, Elijah Newren wrote: > On Fri, Apr 27, 2018 at 10:03 AM, Duy Nguyen wrote: >> On Wed, Apr 25, 2018 at 5:18 PM, Marc Branchaud wrote: >>> >>> * In a "file checkout" ("git checkout -- path/to/file"), $1

Re: git merge banch w/ different submodule revision

On Fri, Apr 27, 2018 at 5:24 PM, Elijah Newren wrote: > I would expect that a different example involving non-linear history > would behave the same, if both sides update the submodule in a fashion > that is just fast-forwarding and one commit contains the other in its >

Re: [RFC PATCH] checkout: Force matching mtime between files

On Fri, Apr 27, 2018 at 11:08 PM, Marc Branchaud wrote: >> On Wed, Apr 25, 2018 at 5:18 PM, Marc Branchaud >> This is a limitation of the current post-checkout hook. $3==0 from the >> hook lets us know this is not a branch switch, but it does not

Re: branch --contains / tag --merged inconsistency

SZEDER Gábor writes: > The commit pointed to by the tag Pacemaker-0.6.1 and its parent have a > serious clock skew, i.e. they are a few months older than their parents: > [...] > (branch|tag|describe|...) (--contains|--merged) use the commit timestamp > information as a

Re: Fetching tags overwrites existing tags

On Fri, Apr 27, 2018 at 12:08 PM, Wink Saville wrote: > On Thu, Apr 26, 2018 at 4:24 PM, Junio C Hamano wrote: >> Junio C Hamano writes: >> >> >> Hence (1) we should detect and error out when --prefix-tags is used >> with mirror fetch near

Re: Branch deletion question / possible bug?

On Fri, Apr 27, 2018 at 5:29 PM, Tang (US), Pik S wrote: > Hi, > > I discovered that I was able to delete the feature branch I was in, due to > some fat fingering on my part and case insensitivity. I never realized this > could be done before. A quick google search did

Re: [PATCH v6 11/11] Remove obsolete script to convert grafts to replace refs

From: "Johannes Schindelin" The functionality is now implemented as `git replace --convert-graft-file`. A rather late in the day thought: Should this go through the same deprecation dance? I.e. replace the body of the script with the new `git replace

Re: [PATCH 2/2] unpack_trees_options: free messages when done

From: Elijah Newren Hi Elijah, [Since this is leaving the topic of rename-detection in favour of leak-plugging, I'm shortening the cc-list a bit.] > So, instead, I'd like to see something like the below > (built on top of my series): Thanks a lot. I now have the below patch

تمكين سوق ابل

Re: Branch deletion question / possible bug?

From: "Jacob Keller" On Fri, Apr 27, 2018 at 5:29 PM, Tang (US), Pik S wrote: Hi, I discovered that I was able to delete the feature branch I was in, due to some fat fingering on my part and case insensitivity. I never realized this could be

Re: Git Stash Creates sh.exe.stackdump (STATUS_STACK_OVERFLOW)

Hi Derek, On Fri, 16 Feb 2018, Derek Foulk wrote: > An issue has arisen sometime between 2.16.1.windows.1 and 2.16.1.windows.4 in > Git. > > When you execute `git stash` commands (stash/pop/apply?), a sh.exe.stackdump > file is generated that contains the following: > > Exception:

Re: [PATCH v4 04/10] commit: use generations in paint_down_to_common()

Jakub Narebski writes: > Junio C Hamano writes: >> Derrick Stolee writes: [...] >>> +int compare_commits_by_gen_then_commit_date(const void *a_, const void >>> *b_, void *unused) >>> +{ >>> + const struct commit *a = a_, *b = b_;

Re: [PATCH v6 11/11] Remove obsolete script to convert grafts to replace refs

Hi Philip, On Sat, Apr 28, 2018 at 2:04 AM, Philip Oakley wrote: > From: "Johannes Schindelin" >> >> The functionality is now implemented as `git replace >> --convert-graft-file`. > > > A rather late in the day thought: Should this go through

Re: [PATCH 1/6] sequencer: extract helper to update active_cache_tree

Hi Johannes, On Fri, Apr 27, 2018 at 3:30 PM, Johannes Schindelin wrote: > This patch extracts the code from is_index_unchanged() to initialize or > update the index' cache tree (i.e. a tree object reflecting the current > index' top-level tree). > > The new helper

Re: [Bug] git log --show-signature print extra carriage return ^M

Hi Larry, On Tue, 6 Mar 2018, Larry Hunter wrote: > The same ^M is shown in the output of tutorial > > > https://www.geekality.net/2017/08/23/setting-up-gpg-signing-for-gitgithub-on-windows/ > > at item "4. Verify commit was signed" Please understand that it would be helpful if you

Re: [PATCH 2/2] unpack_trees_options: free messages when done

Hi Martin, On Sat, 28 Apr 2018, Martin Ågren wrote: > -->8-- > Subject: merge-recursive: provide pair of `unpack_trees_{start,finish}()` > > Rename `git_merge_trees()` to `unpack_trees_start()` and extract the > call to `discard_index()` into a new function `unpack_trees_finish()`. > As a

Re: [PATCH] http.c: shell command evaluation for extraheader

Hi Colin, On Tue, 6 Mar 2018, Colin Arnott wrote: > On March 5, 2018 1:47 PM, Johannes Schindelin > wrote: > > > As the credential-helper is already intended for sensitive data, and > > as it already allows to interact with a helper, I would strongly > > assume

Re: Branch deletion question / possible bug?

Hi, On Sat, 28 Apr 2018, Philip Oakley wrote: > From: "Jacob Keller" > > On Fri, Apr 27, 2018 at 5:29 PM, Tang (US), Pik S > > wrote: > > > Hi, > > > > > > I discovered that I was able to delete the feature branch I was in, due > > > to some fat

Re: [PATCH v4 4/4] rebase --skip: clean up commit message after a failed fixup/squash

Hi Stefan, On Fri, 27 Apr 2018, Stefan Beller wrote: > On Fri, Apr 27, 2018 at 1:48 PM, Johannes Schindelin > wrote: > > During a series of fixup/squash commands, the interactive rebase builds > > up a commit message with comments. This will be presented to the user

Re: [PATCH v6 06/11] Add a test for `git replace --convert-graft-file`

Hi Gábor, On Sat, 28 Apr 2018, SZEDER Gábor wrote: > > diff --git a/t/t6050-replace.sh b/t/t6050-replace.sh > > index c630aba657e..bed86a0af3d 100755 > > --- a/t/t6050-replace.sh > > +++ b/t/t6050-replace.sh > > @@ -444,4 +444,24 @@ test_expect_success GPG '--graft on a commit with a > >

Re: [PATCH v6 11/11] Remove obsolete script to convert grafts to replace refs

Hi Philip, On Sat, 28 Apr 2018, Philip Oakley wrote: > From: "Johannes Schindelin" > > The functionality is now implemented as `git replace > > --convert-graft-file`. > > A rather late in the day thought: Should this go through the same > deprecation dance? > >

Re: [RFC PATCH] checkout: Force matching mtime between files

On Thu, Apr 26, 2018 at 4:46 PM, Michał Górny wrote: > For the record, we're using this with ebuilds and respective cache files > (which are expensive to generate). We are using separate repository > which combines sources and cache files to keep the development > repository

Re: [PATCH v4 01/10] ref-filter: fix outdated comment on in_commit_list

Derrick Stolee writes: > The in_commit_list() method does not check the parents of > the candidate for containment in the list. Fix the comment > that incorrectly states that it does. > > Reported-by: Jakub Narebski > Signed-off-by: Derrick Stolee

Re: [RFC PATCH v3] Teach remote add the --remote-tags option

In this version I changed "+refs/tags/*:refs/remotes/tags/%s/*" back to "+refs/tags/*:refs/remote-tags/%s/*" as Junio originally suggested. This way don't have remotename collisions as Bryan pointed out. Since I don't like "--prefix-tags" I changed the option to "--remote-tags" but obviously open

Re: [PATCH v4 00/10] Compute and consume generation numbers

Derrick Stolee writes: > As promised, here is the diff from v3. What is this strange string "   " in place of tabs in the interdiff? " " here is Unicode Character 'NO-BREAK SPACE' (U+00A0). Though it doesn't matter for viewing, my newsreader (Gnus from GNU Emacs) thinks

[RFC PATCH v3] Teach remote add the --remote-tags option

When --remote-tags is passed to `git remote add` the tagopt is set to --remote-tags and a second fetch line is added so tags are placed in a separate hierarchy per remote. For example: $ git remote add -f --remote-tags gbenchmark g...@github.com:google/benchmark Updating gbenchmark warning:

Re: [RFC PATCH] checkout: Force matching mtime between files

W dniu sob, 28.04.2018 o godzinie 16∶23 +0200, użytkownik Duy Nguyen napisał: > On Thu, Apr 26, 2018 at 4:46 PM, Michał Górny wrote: > > For the record, we're using this with ebuilds and respective cache files > > (which are expensive to generate). We are using separate

Re: [PATCH 2/2] unpack_trees_options: free messages when done

Hi Martin, On Sat, Apr 28, 2018 at 4:32 AM, Martin Ågren wrote: > From: Elijah Newren > > Hi Elijah, > > [Since this is leaving the topic of rename-detection in favour of > leak-plugging, I'm shortening the cc-list a bit.] > >> So, instead, I'd like to

Re: [RFC PATCH v3] Teach remote add the --remote-tags option

I forgot to mention that I added the code to error out if --remote-tags is used with "tracking" (-t | --track) or mirror: + if ((fetch_tags == TAGS_SET_REMOTE) && mirror) + die(_("specifying --remote-tags makes no sense with --mirror")); + if ((fetch_tags ==

Re: [PATCH v5 0/5] Convert some stash functionality to a builtin

Hello Joel, Since there seems to be interest from GSOC students who want to work on converting builtins, I figured I should finish what I have that works now so they could build on top of it. First of all, I must thank you for submitting this series of patches. It is a great starting point

[PATCH v7 02/12] commit: Let the callback of for_each_mergetag return on error

This is yet another patch to be filed under the keyword "libification". There is one subtle change in behavior here, where a `git log` that has been asked to show the mergetags would now stop reporting the mergetags upon the first failure, whereas previously, it would have continued to the next

[PATCH v7 01/12] argv_array: offer to split a string by whitespace

This is a simple function that will interpret a string as a whitespace delimited list of values, and add those values into the array. Note: this function does not (yet) offer to split by arbitrary delimiters, or keep empty values in case of runs of whitespace, or de-quote Unix shell style. All fo

[PATCH v7 05/12] replace: prepare create_graft() for converting graft files wholesale

When converting all grafts in a graft file to replace refs, and one of them happens to leave the original commit's parents unchanged, we do not want to error out. Instead, we would like to issue a warning. Prepare the create_graft() function for such a use case by adding a `gentle` parameter. If

[PATCH v7 08/12] Deprecate support for .git/info/grafts

The grafts feature was a convenient way to "stitch together" ancient history to the fresh start of linux.git. Its implementation is, however, not up to Git's standards, as there are too many ways where it can lead to surprising and unwelcome behavior. For example, when pushing from a repository

[PATCH v7 07/12] Add a test for `git replace --convert-graft-file`

The proof, as the saying goes, lies in the pudding. So here is a regression test that not only demonstrates what the option is supposed to accomplish, but also demonstrates that it does accomplish it. Signed-off-by: Johannes Schindelin --- t/t6050-replace.sh | 28

[PATCH v7 06/12] replace: introduce --convert-graft-file

This option is intended to help with the transition away from the now-deprecated graft file. Signed-off-by: Johannes Schindelin --- Documentation/git-replace.txt | 11 ++--- builtin/replace.c | 44 ++- 2 files changed,

[PATCH v7 12/12] Remove obsolete script to convert grafts to replace refs

The functionality is now implemented as `git replace --convert-graft-file`. Signed-off-by: Johannes Schindelin --- contrib/convert-grafts-to-replace-refs.sh | 28 --- 1 file changed, 28 deletions(-) delete mode 100755

[PATCH v7 10/12] technical/shallow: stop referring to grafts

Now that grafts are deprecated, we should start to assume that readers have no idea what grafts are. So it makes more sense to make the description of the "shallow" feature stand on its own. Suggested-by: Eric Sunshine Helped-by: Junio Hamano

[PATCH v7 09/12] filter-branch: stop suggesting to use grafts

The graft file is deprecated now, so let's use replace refs in the example in filter-branch's man page instead. Suggested-by: Eric Sunshine Signed-off-by: Johannes Schindelin --- Documentation/git-filter-branch.txt | 2 +- 1 file changed, 1

[PATCH v7 11/12] technical/shallow: describe why shallow cannot use replace refs

It is tempting to do away with commit_graft altogether (in the long haul), now that grafts are deprecated. However, the shallow feature needs a couple of things that the replace refs cannot fulfill. Let's point that out in the documentation. Signed-off-by: Johannes Schindelin

[Re-send PATCH v7 00/12] Deprecate .git/info/grafts

[Resent the cover letter, as I did not see it on public-inbox...] It is fragile, as there is no way for the revision machinery to say "but now I want to traverse the graph ignoring the graft file" e.g. when pushing commits to a remote repository (which, as a consequence, can miss commits). And

Re: [PATCH v4 02/10] commit: add generation number to struct commmit

Derrick Stolee writes: > The generation number of a commit is defined recursively as follows: > > * If a commit A has no parents, then the generation number of A is one. > * If a commit A has parents, then the generation number of A is one > more than the maximum

[PATCH v7 04/12] replace: "libify" create_graft() and callees

File this away as yet another patch in the "libification" category. As with all useful functions, in the next commit we want to use create_graft() from a higher-level function where it would be inconvenient if the called function simply die()s: if there is a problem, we want to let the user know

[PATCH v7 03/12] replace: avoid using die() to indicate a bug

We have the BUG() macro for that purpose. Signed-off-by: Johannes Schindelin --- builtin/replace.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/builtin/replace.c b/builtin/replace.c index 245d3f4164e..e345a5a0f1c 100644 --- a/builtin/replace.c

[PATCH] tests: introduce test_unset_prereq, for debugging

While working on the --convert-graft-file test, I missed that I was relying on the GPG prereq, by using output of test cases that were only run under that prereq. For debugging, it was really convenient to force that prereq to be unmet, but there was no easy way to do that. So I came up with a