Re: [PATCHv5 7/7] builtin/describe.c: describe a blob

Stefan Beller writes: > ... > fixed. > ... > fixed the text... > ... > I am not fully convinced all descriptions are in recent history, but I > tend to agree that most are, so probably the trade off is a wash. So what do we want with this topic? I think the "teach 'git log'

Re: [PATCH v3 0/4] Hash abstraction

Junio C Hamano writes: > "brian m. carlson" writes: > >> This is a series proposing a basic abstraction for hash functions. >> >> The full description of the series can be found here: >>

Re: [PATCH 1/2] Git/Packet.pm: rename packet_required_key_val_read()

On Wed, Nov 22, 2017 at 7:28 AM, Junio C Hamano wrote: > Jonathan Nieder writes: > This comment doesn't tell me how to use the function. How do I detect whether it successfully read a line? What do the return values represent? What happens

Re: [PATCH 1/2] Git/Packet.pm: rename packet_required_key_val_read()

Junio C Hamano wrote: > Jonathan Nieder writes: >> Junio C Hamano wrote: >>> Jonathan Nieder writes: This comment doesn't tell me how to use the function. How do I detect whether it successfully read a line? What do the return values

Re: [PATCH 1/2] Git/Packet.pm: rename packet_required_key_val_read()

Jonathan Nieder writes: >>> This comment doesn't tell me how to use the function. How do I detect >>> whether it successfully read a line? What do the return values >>> represent? What happens if the line it read doesn't match the key? >> >> Would this work for both of

Re: [PATCH] defer expensive load_ref_decorations until needed

Junio C Hamano writes: > Other than that, I like what this patch attempts to do. A nicely > identified low-hanging fruit ;-). Having said that, this will have a bad interaction with another topic in flight: <20171121213341.13939-1-rafa.al...@gmail.com> Perhaps this should

Re: [PATCH v3 5/5] Testing: provide tests requiring them with ellipses after SHA-1 values

"Philip Oakley" writes: > From: "Junio C Hamano" >> Ann T Ropea writes: >> >>> *1* We are being overly generous in t4013-diff-various.sh because we do >>> not want to destroy/take apart the here-document. Given that all this a >>>

Re: [RFC PATCH v2 0/2] bisect: add a single command for editing logs

Adam Dinwoodie writes: > - It's possible to start a bisect session with a command like `git > bisect @ @~10`. This will lead to the bisect log including the `@` > and `@~10` literally, and the interpretation of those values changes > depending on the current HEAD. As

Re: [PATCH v5 00/10] Partial clone part 2: fsck and promisors

Jeff Hostetler writes: > From: Jeff Hostetler > > This is V5 of part 2 of partial clone. This assumes V5 of part 1 > is already present. V5 includes minor cleanup over V4 and better > separates the --exclude-promisor-objects and --missing

Re: [PATCH v5 0/6] Partial clone part 1: object filtering

Jonathan Tan writes: >> Jeff Hostetler (6): >> dir: allow exclusions from blob in addition to file >> oidmap: add oidmap iterator methods >> oidset: add iterator methods to oidset >> list-objects: filter objects in traverse_commit_list >> rev-list: add

Re: [PATCH 1/3] Documentation: allow overriding timestamps of generated asciidoc

Anders Kaseorg wrote: > On Tue, 21 Nov 2017, Jonathan Nieder wrote: >> http://asciidoc.org/CHANGELOG.html is stale but asciidoc still seems >> to be getting changes at https://github.com/asciidoc/asciidoc. I >> wonder how difficult it would be to add any required SOURCE_DATE_EPOCH >> support

Re: [PATCH 1/2] Git/Packet.pm: rename packet_required_key_val_read()

Junio C Hamano wrote: > Jonathan Nieder writes: >> Christian Couder wrote: >>> +# Read a text line and check that it is in the form "key=value" >>> +sub packet_key_val_read { >> >> This comment doesn't tell me how to use the function. How do I detect >> whether it

Re: [PATCH 1/3] Documentation: allow overriding timestamps of generated asciidoc

Anders Kaseorg writes: > That should make this Git patch unnecessary. (You’re of course still > welcome to take it if you think build reproducibility with old AsciiDoc > versions is worthwhile.) Thanks. I've queued these three only so that I won't lose track, but will not

Re: [PATCH] defer expensive load_ref_decorations until needed

Phil Hord writes: > With many thousands of references, a simple `git rev-parse HEAD` may take > more than a second to return because it first loads all the refs into > memory even though it will never use them. > > Defer loading any references until we actually need them. >

Re: [PATCH] stash: Learn to parse -m/--message like commit does

Phil Hord writes: > `git stash push -m foo` uses "foo" as the message for the stash. But > `git stash push -m"foo"` does not parse successfully. Similarly > `git stash push --message="My stash message"` also fails. Nothing > in the documentation suggests this syntax should

Re: doc: prefer 'stash push' over 'stash save'

Jonathan Nieder writes: > Phil Hord wrote: > >> Although `git stash save` was deprecated recently, some parts of the >> documentation still refer to it instead of `push`. >> >> Signed-off-by: Phil Hord >> --- >> Documentation/git-stash.txt | 4 ++-- >>

Re: [RFC PATCH] builtin/worktree: enhance worktree removal

On Tue, Nov 21, 2017 at 10:55 PM, Junio C Hamano wrote: > OK, so the proposed log message was a bit confusing for those who > are *not* the person who wrote it (who knew why existing behaviour > was inadequate and did not describe how "worktree remove" would fail > under such a

Re: [PATCH 1/3] Documentation: allow overriding timestamps of generated asciidoc

On Tue, 21 Nov 2017, Jonathan Nieder wrote: > http://asciidoc.org/CHANGELOG.html is stale but asciidoc still seems > to be getting changes at https://github.com/asciidoc/asciidoc. I > wonder how difficult it would be to add any required SOURCE_DATE_EPOCH > support there. In fact I already did

Re: [PATCH v2] log: add option to choose which refs to decorate

Rafael Ascensão writes: > When `log --decorate` is used, git will decorate commits with all > available refs. While in most cases this the desired effect, under some Missing verb. s/this the/this may give the/; perhaps. > conditions it can lead to excessively verbose

Re: [RFC PATCH] builtin/worktree: enhance worktree removal

Eric Sunshine writes: > On Tue, Nov 21, 2017 at 10:14 PM, Eric Sunshine > wrote: >> The erroring out in this case looks like simple oversight. Most >> likely, this particular case did not occur to Duy. The code does >> intentionally check the

Re: [PATCH 2/2] Git/Packet.pm: use 'if' instead of 'unless'

Jonathan Nieder writes: > [...] >> --- a/perl/Git/Packet.pm >> +++ b/perl/Git/Packet.pm >> @@ -68,16 +68,16 @@ sub packet_bin_read { >> >> sub remove_final_lf_or_die { >> my $buf = shift; >> -unless ( $buf =~ s/\n$// ) { > > For readability, I find this whitespace

Re: [PATCH 1/2] Git/Packet.pm: rename packet_required_key_val_read()

Christian Couder writes: > The function calls itself "required", but it does not die when it > sees an unexpected EOF. > Let's rename it to "packet_key_val_read()". > > Signed-off-by: Christian Couder > --- > > These 2 patches are a late

Re: [PATCH 1/2] Git/Packet.pm: rename packet_required_key_val_read()

Jonathan Nieder writes: > nit: please wrap lines to a consistent width, to make the message > easier to read. In the above, it looks like the line break is > intentional --- is it meant to be two paragraphs (i.e. is it missing > another newline)? I'd think so; will add a

Re: [PATCH] prune: add "--progress" to man page and usage msg

"Robert P. J. Day" writes: > Add mention of git prune's "--progress" option to the SYNOPSIS and > DESCRIPTION sections of the man page, and to the usage message of "git > prune" itself. > > While we're here, move the explanation of "--" toward the end of the > DESCRIPTION

Re: [PATCH v2] doc: Add missing "-n" (dry-run) option to reflog man page

"Robert P. J. Day" writes: > While the "git reflog" man page supports both "--dry-run" and "-n" for > a dry run, the man page mentions only the former, not the latter. > > Signed-off-by: Robert P. J. Day > > --- I have a suspicion that this was

Re: [RFC PATCH] builtin/worktree: enhance worktree removal

On Tue, Nov 21, 2017 at 10:14 PM, Eric Sunshine wrote: > The erroring out in this case looks like simple oversight. Most > likely, this particular case did not occur to Duy. The code does > intentionally check the directory to see if it is dirty so that it can > warn the

Re: [PATCH 5/5] sha1_file: don't re-scan pack directory for null sha1

On Wed, Nov 22, 2017 at 10:49:25AM +0900, Junio C Hamano wrote: > WRT existing codepaths that pass 0{40} and refuses to notice a > potential repository corruption (from getting a NULL for a non null > object name), I think we would need a sweep of the codebase and fix > them in the longer term.

Re: [RFC PATCH] builtin/worktree: enhance worktree removal

On Tue, Nov 21, 2017 at 9:12 PM, Junio C Hamano wrote: > Eric Sunshine writes: >> Let me see if I understand. Sometimes you know that you've deleted the >> worktree directory, in which case 'git worktree prune' is the obvious >> choice. However, there

Re: [PATCH 1/3] Documentation: allow overriding timestamps of generated asciidoc

Jonathan Nieder writes: >> touch -d @SECONDS isn't POSIX compliant, and non-Linux systems don't >> provide it. POSIX only allows certain fixed format, and I assume that >> non-Linux parties (maybe OpenBSD) will want to have reproducible builds >> as well. > > Interesting.

Re: [PATCH v3 00/33] Add directory rename detection to git

Elijah Newren writes: > Interesting; tbdiff looks cool. Junio hasn't queued this series yet, > but it's easy enough to reconstruct the old one. It does weigh in > pretty heavy, and I'm slighly worried about gmail mangling all the > lines, but I'm going to give it a shot

Re: [RFC PATCH] xdiff/xpatience: support anchoring a line

Jonathan Tan writes: > Teach the patience diff to support prohibiting a user-specified line > from appearing as a deletion or addition in the end result. > > Signed-off-by: Jonathan Tan > --- > I'm sending this out to see if a change similar

Re: [PATCH] doc: remove explanation of "--" from man pages

Kevin Daudt writes: > Although I agree that common options don't need to be explained > everytime again, this change might make '--' even more obscure. To be > honest, I didn't even know about gitcli(7), let alone most new users. > > In the #git irc channel we often have to

Re: [PATCH] rebase: rebasing can also be done when HEAD is detached

Kaartic Sivaraam writes: > In a repository when attempting to rebase when the HEAD is detached > and it is already up to date with upstream (so there's nothing to do), > the following message is shown > > Current branch HEAD is up to date. > > which is clearly

Re: [RFC PATCH] builtin/worktree: enhance worktree removal

Eric Sunshine writes: > Let me see if I understand. Sometimes you know that you've deleted the > worktree directory, in which case 'git worktree prune' is the obvious > choice. However, there may be cases when you've forgotten that you > deleted the worktree directory

Re: [PATCH v2 4/4] builtin/branch: strip refs/heads/ using skip_prefix

Eric Sunshine writes: > On Tue, Nov 21, 2017 at 2:12 PM, Kaartic Sivaraam > wrote: >> On Wednesday 22 November 2017 12:08 AM, Eric Sunshine wrote: >>> The original code unconditionally uses "+ 11", which says that the >>> prefix is _always_

Re: core.safecrlf warning is confusing[improvement suggestion?]

Torsten Bögershausen writes: >> I want to have LF line endings in the repository and CRLF endings in >> the working copy. (Because I use windows-exclusive tools to develop.) > > Side note: If you ever want to push your repository somewhere, > it would be good practice to have a

Re: [PATCH v3 0/8] Coping with unrecognized ssh wrapper scripts in GIT_SSH

Jonathan Nieder writes: > Jonathan Nieder (8): > ssh test: make copy_ssh_wrapper_as clean up after itself > connect: move no_fork fallback to git_tcp_connect > connect: split git:// setup into a separate function > connect: split ssh command line options into separate

Re: [PATCH 5/5] sha1_file: don't re-scan pack directory for null sha1

Jeff King writes: > Here's a re-roll of patch 5 that behaves this way (the patch should be > unsurprising, but I've updated the commit message to match). > > I did notice one other thing: the function looks up replace objects, so > we have both the original and the replaced sha1

Re: [PATCH 5/5] sha1_file: don't re-scan pack directory for null sha1

Jeff King writes: > I'm not sure what the right behavior is, but I'm pretty sure that's not > it. Probably one of: > > - skip updating the ref when we see the breakage > > - ditto, but terminate the whole operation, since we might be deleting > other refs and in a broken

Re: t3512 & t3513 'unexpected passes'

Adam Dinwoodie writes: > I've seen the same unexpected passes, and had just completed the same > bisect run myself, although I fixed the build failure by cherry-picking > 82921316a ("SQUASH???", 2017-11-18) onto commits that wouldn't build, > given that commit seems to exist

Re: Draft of Git Rev News edition 33

Hi, Christian Couder wrote: > On Tue, Nov 21, 2017 at 2:10 AM, Jonathan Nieder wrote: >> That said, I believe that the gitattributes(5) manpage does an okay >> job of covering this and that that thread came to a clear conclusion: >> >> >>

Re: [PATCH v5 0/6] Partial clone part 1: object filtering

On Tue, 21 Nov 2017 20:58:46 + Jeff Hostetler wrote: > From: Jeff Hostetler > > Here is V5 of the list-object filtering, rev-list, and pack-objects. > > This version addresses comments on the V4 series. I removed the > questionable

Re: [PATCH] git-send-email: fix get_maintainer.pl regression

Thomas Adam writes: > Trying to come up with a reinvention of regexps for email addresses is asking > for trouble, not to mention a crappy rod for your own back. Don't do that. > This is why people use Mail::Address. > >

Re: Draft of Git Rev News edition 33

Christian Couder writes: > On Tue, Nov 21, 2017 at 2:12 PM, Junio C Hamano wrote: >> I just re-read the sub-thread Jonathan pointed at, and to me it does >> look like the original request was adequately addressed and talk has >> concluded at around

Re: [PATCH v3 3/3] worktree: make add dwim

Thomas Gummerer writes: > I didn't consider that, I think you are right, and the flag should > apply in that case as well. I think at that point we may as well pass > this flag through to the 'git branch' call, and let users set up > tracking if they want to, the same way

Re: [PATCH 1/3] Documentation: allow overriding timestamps of generated asciidoc

Hi, brian m. carlson wrote: > On Tue, Nov 21, 2017 at 03:34:32PM -0800, Jonathan Nieder wrote: >> --- a/Documentation/Makefile >> +++ b/Documentation/Makefile >> @@ -410,6 +410,7 @@ $(patsubst %.txt,%.texi,$(MAN_TXT)): %.texi : %.xml >> howto-index.txt: howto-index.sh $(wildcard howto/*.txt) >>

Re: Documentation of post-receive hook

Christoph Michelbach writes: > On November 20, 2017 2:17:58 AM GMT+01:00, >>How about this rewrite? Would it consider all the points raised and >>make it easier to understand? >> >>This hook is invoked by 'git-receive-pack' when it reacts to >>'git push' and

Re: [PATCH v3 00/33] Add directory rename detection to git

On Tue, Nov 21, 2017 at 4:42 PM, Stefan Beller wrote: > On Tue, Nov 21, 2017 at 12:00 AM, Elijah Newren wrote: >> This patchset introduces directory rename detection to merge-recursive; I'm >> resubmitting just a few hours after my PATCHv2 because I didn't

Re: [PATCH] recursive submodules: detach HEAD from new state

Jonathan Nieder writes: > The thread I am replying to appears to be where the patch comes from > but I have some memories of more recent discussion that I'm not > finding. > > More context: > https://public-inbox.org/git/xmqqshd8i3ze@gitster.mtv.corp.google.com/ > says >

Re: [PATCH 1/3] Documentation: allow overriding timestamps of generated asciidoc

On Tue, Nov 21, 2017 at 03:34:32PM -0800, Jonathan Nieder wrote: > From: Anders Kaseorg > Date: Wed, 30 Nov 2016 22:21:15 -0500 > > Allow overriding the timestamp in generated documentation by setting > SOURCE_DATE_EPOCH to the number of seconds since 1970-01-01 00:00:00 > UTC

Re: [PATCH v3 00/33] Add directory rename detection to git

On Tue, Nov 21, 2017 at 12:00 AM, Elijah Newren wrote: > This patchset introduces directory rename detection to merge-recursive; I'm > resubmitting just a few hours after my PATCHv2 because I didn't know about > the DEVELOPER=1 flag previously, and my code had a number of >

Re: [PATCH 1/5] p5550: factor our nonsense-pack creation

On Tue, Nov 21, 2017 at 7:58 AM, Jeff King wrote: > On Mon, Nov 20, 2017 at 06:55:51PM -0500, Eric Sunshine wrote: > >> On Mon, Nov 20, 2017 at 3:26 PM, Jeff King wrote: >> > p5550: factor our nonsense-pack creation >> >> s/our/out/, I guess. > > Heh, yes. I even

Re: [PATCH] list-objects-filter-options: fix up some sparse warnings

> [It would probably be easier if I used git to output this for me, rather > than typing it into my email client!] git config alias.gcs "show --date=short -s --pretty='format:%h ("%s", %ad)'" will make you the `git gcs` alias that I use to describe commits.

Re: [PATCH v3 0/8] Coping with unrecognized ssh wrapper scripts in GIT_SSH

On Mon, Nov 20, 2017 at 2:32 PM, Brandon Williams wrote: > On 11/20, Jonathan Nieder wrote: >> Previously: [1]. >> >> This version should be essentially identical to v2. Changes: >> - patch 1 is new and should fix the test failure on Windows >> - patch 2 is new, discussed at

Re: Documentation of post-receive hook

On November 20, 2017 2:17:58 AM GMT+01:00, >How about this rewrite? Would it consider all the points raised and >make it easier to understand? > >This hook is invoked by 'git-receive-pack' when it reacts to >'git push' and updates reference(s) in its repository. I think it's much more

[PATCH] defer expensive load_ref_decorations until needed

With many thousands of references, a simple `git rev-parse HEAD` may take more than a second to return because it first loads all the refs into memory even though it will never use them. Defer loading any references until we actually need them. Signed-off-by: Phil Hord ---

Re: [PATCH 1/8 v2] ssh test: make copy_ssh_wrapper_as clean up after itself

On Mon, Nov 20, 2017 at 5:49 PM, Jonathan Nieder wrote: > @@ -317,7 +317,7 @@ test_expect_success 'set up ssh wrapper' ' > > copy_ssh_wrapper_as () { > cp "$TRASH_DIRECTORY/ssh$X" "${1%$X}$X" && > - test_when_finished "rm -f ${1%$X}$X" && > +

[PATCH 3/3] generate-cmdlist: avoid non-deterministic output

Date: Fri, 1 Jul 2016 17:32:00 -0700 Non-determinism makes it harder for build tools to discover when a target needs to be rebuilt. generate-cmdlist.sh stores the full path in a comment: /* Automatically generated by /build/git-agojiD/git-2.15.0/generate-cmdlist.sh */ Use the file name alone

[PATCH 2/3] git-gui: sort entries in optimized tclIndex

From: Anders Kaseorg Date: Wed, 16 Nov 2016 16:37:17 -0500 auto_mkindex expands wildcards in directory order, which depends on the underlying filesystem. To improve build reproducibility, sort the list of *.tcl files in the Makefile. The unoptimized loading case was previously

Re: [PATCH 6/6] grep: show non-empty lines before functions with -W

On Mon, Nov 20, 2017 at 2:07 PM, René Scharfe wrote: > Am 20.11.2017 um 21:39 schrieb Stefan Beller: >> On Sat, Nov 18, 2017 at 10:08 AM, René Scharfe wrote: >>> Non-empty lines before a function definition are most likely comments >>> for that function and thus

[PATCH 1/3] Documentation: allow overriding timestamps of generated asciidoc

From: Anders Kaseorg Date: Wed, 30 Nov 2016 22:21:15 -0500 Allow overriding the timestamp in generated documentation by setting SOURCE_DATE_EPOCH to the number of seconds since 1970-01-01 00:00:00 UTC to use. This makes the generated documentation reproducible from the source

[PATCH 0/3] Improving build reproducibility

Hi, The reproducible builds project has been working on making it possible to verify that binary packages of open source projects were built from the source they were claimed to have been built from. To that end, Debian has been carrying patches 1-2 for a

Re: [RFC PATCH] xdiff/xpatience: support anchoring a line

On Tue, Nov 21, 2017 at 2:17 PM, Jonathan Tan wrote: > Teach the patience diff to support prohibiting a user-specified line > from appearing as a deletion or addition in the end result. > > Signed-off-by: Jonathan Tan > --- > I'm sending this

[PATCH] doc: prefer 'stash push' instead of 'stash save'

Although `git stash save` was deprecated recently, some parts of the documentation still refer to it. Signed-off-by: Phil Hord --- Documentation/git-stash.txt | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/Documentation/git-stash.txt

[PATCH] stash: Learn to parse -m/--message like commit does

`git stash push -m foo` uses "foo" as the message for the stash. But `git stash push -m"foo"` does not parse successfully. Similarly `git stash push --message="My stash message"` also fails. Nothing in the documentation suggests this syntax should work, but it does work for `git commit`, and my

Re: stash: learn to parse -m/--message like commit does

Hi, Phil Hord wrote: > `git stash push -m foo` uses "foo" as the message for the stash. But > `git stash push -m"foo"` does not parse successfully. Similarly > `git stash push --message="My stash message"` also fails. Nothing > in the documentation suggests this syntax should work, "git help

Re: doc: prefer 'stash push' over 'stash save'

Phil Hord wrote: > Although `git stash save` was deprecated recently, some parts of the > documentation still refer to it instead of `push`. > > Signed-off-by: Phil Hord > --- > Documentation/git-stash.txt | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-)

Re: [PATCH 5/5] sha1_file: don't re-scan pack directory for null sha1

On Tue, Nov 21, 2017 at 02:20:19PM +0900, Junio C Hamano wrote: > After queuing this series to an earlier part of 'pu' and resolving a > conflict with jh/fsck-promisors topic, I ended up with a code that > rejects 0{40} a lot earlier, before we try to see if a pack entry > for 0{40} exists, even

Re: stash: learn to parse -m/--message like commit does

Hm.. Sorry about the formatting here. It's been a while. I'll try again. On Tue, Nov 21, 2017 at 3:07 PM, Phil Hord wrote: > `git stash push -m foo` uses "foo" as the message for the stash. But > `git stash push -m"foo"` does not parse successfully. Similarly > `git

stash: learn to parse -m/--message like commit does

`git stash push -m foo` uses "foo" as the message for the stash. But `git stash push -m"foo"` does not parse successfully. Similarly `git stash push --message="My stash message"` also fails. Nothing in the documentation suggests this syntax should work, but it does work for `git commit`, and my

doc: prefer 'stash push' over 'stash save'

Although `git stash save` was deprecated recently, some parts of the documentation still refer to it instead of `push`. Signed-off-by: Phil Hord --- Documentation/git-stash.txt | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git

Re: [PATCH] recursive submodules: detach HEAD from new state

On Tue, Nov 21, 2017 at 2:47 PM, Jonathan Nieder wrote: > Hi, > > Stefan Beller wrote: >> On Tue, Nov 21, 2017 at 2:34 PM, Jonathan Nieder wrote: > >>> Stefan, do you know what thread I should look at to find the current >>> state of this patch? I've had

Re: [PATCH 5/5] sha1_file: don't re-scan pack directory for null sha1

On Tue, Nov 21, 2017 at 11:37:28AM +0900, Junio C Hamano wrote: > Jeff King writes: > > > In an ideal world, we'd simply fix all of the callers to > > notice the null sha1 and avoid passing it to us. But a > > simple experiment to catch this with a BUG() shows that > > there are

Re: [PATCH] recursive submodules: detach HEAD from new state

Hi, Stefan Beller wrote: > On Tue, Nov 21, 2017 at 2:34 PM, Jonathan Nieder wrote: >> Stefan, do you know what thread I should look at to find the current >> state of this patch? I've had it applied locally for a long time. > > It was "Undecided" for some time, then Junio

Re: [PATCH] recursive submodules: detach HEAD from new state

On Tue, Nov 21, 2017 at 2:34 PM, Jonathan Nieder wrote: > Stefan Beller wrote: >>> Junio C Hamano writes: > Also, while I do agree with you that the problem exists, it is unclear why this patch is a solution and not a hack that sweeps a

Re: [PATCH] recursive submodules: detach HEAD from new state

Stefan Beller wrote: >> Junio C Hamano writes: >>> Also, while I do agree with you that the problem exists, it is >>> unclear why this patch is a solution and not a hack that sweeps a >>> problem under the rug. >>> >>> It is unclear why this "silently detach HEAD without

[RFC PATCH] xdiff/xpatience: support anchoring a line

Teach the patience diff to support prohibiting a user-specified line from appearing as a deletion or addition in the end result. Signed-off-by: Jonathan Tan --- I'm sending this out to see if a change similar to this would be welcome. It is useful to me as a reviewer

[PATCH] Tests: clean up submodule recursive helpers

This continues the work in commit d3b5a49 ("Tests: clean up and document submodule helpers", 2017-11-08). Factor out the commonalities from test_submodule_switch_recursing_with_args() and test_submodule_forced_switch_recursing_with_args() in lib-submodule-update.sh, and document their usage. Some

Re: [PATCH v2] gitcli: tweak "man gitcli" for clarity

On Tue, 21 Nov 2017, Kevin Daudt wrote: > On Tue, Nov 21, 2017 at 04:47:42PM -0500, Robert P. J. Day wrote: > > On Tue, 21 Nov 2017, Kevin Daudt wrote: > > > > > On Tue, Nov 21, 2017 at 04:27:59PM -0500, Robert P. J. Day wrote: > > > > No major changes, just some rewording and showing some

Re: [PATCH v3 3/3] worktree: make add dwim

On 11/19, Eric Sunshine wrote: > On Sun, Nov 19, 2017 at 2:04 PM, Eric Sunshine > wrote: > > On Sat, Nov 18, 2017 at 5:47 PM, Thomas Gummerer > > wrote: > >> +To disable the behaviour of trying to match the basename of to > >> +a remote, and

Re: bash script to pull in branch B the changes from parent branch A

On Wed, 2017-11-22 at 00:19 +0800, Laetitia Pfaender wrote: > cd repo-in-branchB > git branch --set-upstream-to=origin/branchB > git pull > > git branch --set-upstream-to=origin/branchA > git pull > git branch --set- > upstream-to=origin/branchB > > It does exactly what I want but, as I have >

Re: [PATCH v2] gitcli: tweak "man gitcli" for clarity

On Tue, Nov 21, 2017 at 04:47:42PM -0500, Robert P. J. Day wrote: > On Tue, 21 Nov 2017, Kevin Daudt wrote: > > > On Tue, Nov 21, 2017 at 04:27:59PM -0500, Robert P. J. Day wrote: > > > No major changes, just some rewording and showing some variations of > > > general Git commands. > > > > > >

Boat Owners List

Hi, Greeting of the day! Would you be interested in acquiring an email list of "Boat Owners" from USA? Our Databases:-1.RV Owners List 2.Sail and Power boat Owners List 3.Travelers List 4.Fishing Enthusiasts List 5.Cruise Travelers List

Re: [PATCH v2] gitcli: tweak "man gitcli" for clarity

On Tue, 21 Nov 2017, Kevin Daudt wrote: > On Tue, Nov 21, 2017 at 04:27:59PM -0500, Robert P. J. Day wrote: > > No major changes, just some rewording and showing some variations of > > general Git commands. > > > > Signed-off-by: Robert P. J. Day > > > > --- > > > > diff

Re: [PATCH v2] gitcli: tweak "man gitcli" for clarity

On Tue, Nov 21, 2017 at 04:27:59PM -0500, Robert P. J. Day wrote: > No major changes, just some rewording and showing some variations of > general Git commands. > > Signed-off-by: Robert P. J. Day > > --- > > diff --git a/Documentation/gitcli.txt

Re: [RFC PATCH] builtin/worktree: enhance worktree removal

On Tue, Nov 21, 2017 at 10:09 AM, Kaartic Sivaraam wrote: > The new feature to 'remove' worktree was handy to remove specific > worktrees. It didn't cover one particular case of removal. Specifically, > if there is an "entry" (a directory in /.git/worktrees) > for a

[PATCH v2] log: add option to choose which refs to decorate

When `log --decorate` is used, git will decorate commits with all available refs. While in most cases this the desired effect, under some conditions it can lead to excessively verbose output. Introduce two command line options, `--decorate-refs=` and `--decorate-refs-exclude=` to allow the user

[PATCH v2] gitcli: tweak "man gitcli" for clarity

No major changes, just some rewording and showing some variations of general Git commands. Signed-off-by: Robert P. J. Day --- diff --git a/Documentation/gitcli.txt b/Documentation/gitcli.txt index 9f13266a6..d690d1ff0 100644 --- a/Documentation/gitcli.txt +++

Re: [PATCH] gitcli: tweak "man gitcli" for clarity

On Tue, 21 Nov 2017, Eric Sunshine wrote: > On Tue, Nov 21, 2017 at 3:53 PM, Robert P. J. Day > wrote: > > No major changes, just some rewording and showing some variations of > > general Git commands. > > > > Signed-off-by: Robert P. J. Day > >

Re: [PATCH] gitcli: tweak "man gitcli" for clarity

On Tue, Nov 21, 2017 at 3:53 PM, Robert P. J. Day wrote: > No major changes, just some rewording and showing some variations of > general Git commands. > > Signed-off-by: Robert P. J. Day > --- > diff --git a/Documentation/gitcli.txt

Re: [PATCH] doc: remove explanation of "--" from man pages

On Tue, Nov 21, 2017 at 04:12:02PM -0500, Robert P. J. Day wrote: > "man gitcli" already explains the purpose of the "--" syntax, so there > is no value to a small subset of Git commands explaining that in their > man pages. > > Signed-off-by: Robert P. J. Day > > --- >

Re: pedantry: is there a standard for what should be in the SYNOPSIS?

On Tue, 21 Nov 2017, Jonathan Nieder wrote: > Hi, > > Robert P. J. Day wrote: > > > following up on an earlier question of mine, is there a standard > > for what options should be listed in either the SYNOPSIS or the > > DESCRIPTION sections of a man page? i ask since i'm seeing some > > definite

[PATCH v5 03/14] fetch: refactor calculation of remote list

From: Jonathan Tan Separate out the calculation of remotes to be fetched from and the actual fetching. This will allow us to include an additional step before the actual fetching in a subsequent commit. Signed-off-by: Jonathan Tan ---

[PATCH v5 14/14] fetch-pack: restore save_commit_buffer after use

From: Jonathan Tan In fetch-pack, the global variable save_commit_buffer is set to 0, but not restored to its original value after use. In particular, if show_log() (in log-tree.c) is invoked after fetch_pack() in the same process, show_log() will return before

[PATCH v5 02/14] clone, fetch-pack, index-pack, transport: partial clone

From: Jeff Hostetler Signed-off-by: Jeff Hostetler --- builtin/clone.c | 9 + builtin/fetch-pack.c | 4 fetch-pack.c | 13 + fetch-pack.h | 2 ++ transport-helper.c | 5 + transport.c

[PATCH v5 13/14] unpack-trees: batch fetching of missing blobs

From: Jonathan Tan When running checkout, first prefetch all blobs that are to be updated but are missing. This means that only one pack is downloaded during such operations, instead of one per missing blob. This operates only on the blob level - if a repository has a

[PATCH v5 11/14] t5601: test for partial clone

From: Jonathan Tan Signed-off-by: Jonathan Tan Signed-off-by: Jeff Hostetler --- builtin/clone.c | 15 --- t/t5601-clone.sh | 49 + 2 files changed, 61

[PATCH v5 12/14] t5500: more tests for partial clone and fetch

From: Jonathan Tan Signed-off-by: Jonathan Tan Signed-off-by: Jeff Hostetler --- t/t5500-fetch-pack.sh | 60 +++ 1 file changed, 56 insertions(+), 4 deletions(-) diff

[PATCH v5 10/14] t5500: add fetch-pack tests for partial clone

From: Jonathan Tan Signed-off-by: Jonathan Tan Signed-off-by: Jeff Hostetler --- t/t5500-fetch-pack.sh | 36 1 file changed, 36 insertions(+) diff --git a/t/t5500-fetch-pack.sh

[PATCH v5 06/14] pack-objects: test support for blob filtering

From: Jonathan Tan As part of an effort to improve Git support for very large repositories in which clients typically have only a subset of all version-controlled blobs, test pack-objects support for --filter=blob:limit=, packing only blobs not exceeding that size

  1   2   3   >