Re: [PATCH v3 09/12] get_short_oid / peel_onion: ^{tree} should be tree, not treeish

Ævar Arnfjörð Bjarmason writes: > But ^{tree} shows just the trees, but would previously be equivalent > to the above: > > $ git rev-parse e8f2^{tree} > error: short SHA1 e8f2 is ambiguous > hint: The candidates are: > hint: e8f2093055 tree > hint:

Re: [PATCH v2] wt-status: use rename settings from init_diff_ui_defaults

On Tue, May 01, 2018 at 05:08:27PM -0700, Elijah Newren wrote: > Eckhard, can you add some comments to your commit message mentioning > the email pointed to by Junio about break detection and rename > detection being unsafe to use together, as well as the inconsistencies > in break detection

Re: [PATCH v3 06/12] get_short_oid: sort ambiguous objects by type, then SHA-1

Ævar Arnfjörð Bjarmason writes: > + /* > + * Between object types show tags, then commits, and finally > + * trees and blobs. > + * > + * The object_type enum is commit, tree, blob, tag, but we > + * want tag, commit, tree blob. Cleverly (perhaps

Re: [PATCH v3 04/12] cache.h: add comment explaining the order in object_type

Ævar Arnfjörð Bjarmason writes: > The order in the enum might seem arbitrary, and isn't explained by > 72518e9c26 ("more lightweight revalidation while reusing deflated > stream in packing", 2006-09-03) which added it. > > Derrick Stolee suggested that it's ordered

Re: Blame / annotate with mixed mac line endings?

"Jason Pyeron" writes: > $ cat /usr/local/bin/helper.sh > cat "$1" | mac2unix > > The important issue was to not use mac2unix directly, because it > modifies the file itself. I wonder if [diff "test"] textconv = sh -c 'mac2unix <"$1"' -IAmArgv0- works without an

RE: Blame / annotate with mixed mac line endings?

> -Original Message- > From: Junio C Hamano > Sent: Wednesday, May 2, 2018 21:22 > Subject: Re: Blame / annotate with mixed mac line endings? > > "Jason Pyeron" writes: > > > Any way to hit git with a stick to treat lone CR as a line > break for blame/annotate? > I

Re: [GSoC] Info: new blog series of my work on Git GSoC '18

On Thu, May 3, 2018 at 6:31 AM, Andrew Ardill wrote: > On 2 May 2018 at 17:12, Johannes Schindelin > wrote: >> Hi Pratik, >> >> On Wed, 2 May 2018, Pratik Karki wrote: >> >>> As promised in my proposal, I've started >>> to write a blog series

Re: Blame / annotate with mixed mac line endings?

"Jason Pyeron" writes: > Any way to hit git with a stick to treat lone CR as a line break for > blame/annotate? I highly suspect that you would get more help from those whose love is Git if your inquiry were about a way to ask Git politely to do what you want to achieve,

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

On Wed, May 2, 2018 at 5:53 PM, Stefan Beller wrote: > +struct cb_foreach { > + char *toplevel; ... > + OPT_STRING(0, "toplevel", , N_("path"), > + N_("path from the top level of the invocation")), This is a leftover from my

[PATCH 5/5] 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/5] submodule foreach: document '$sm_path' instead of '$path'

From: Prathamesh Chavan As using a variable '$path' may be harmful to users due to capitalization issues, see 64394e3ae9 (git-submodule.sh: Don't use $path variable in eval_gettext string, 2012-04-17). Adjust the documentation to advocate for using $sm_path, which contains

[PATCH 3/5] submodule foreach: clarify the '$toplevel' variable documentation

From: Prathamesh Chavan It does not contain the topmost superproject as the author assumed, but the direct superproject, such that $toplevel/$sm_path is the actual absolute path of the submodule. Discussed-with: Ramsay Jones Signed-off-by: Stefan

[PATCH 1/5] submodule foreach: correct '$path' in nested submodules from a subdirectory

From: Prathamesh Chavan When running 'git submodule foreach --recursive' from a subdirectory of your repository, nested submodules get a bogus value for $path: For a submodule 'sub' that contains a nested submodule 'nested', running 'git -C dir submodule foreach echo $path'

[PATCH 0/5] Rebooting pc/submodule-helper-foreach

The "What's cooking" email carried this series for some time now: > * pc/submodule-helper-foreach (2018-02-02) 5 commits > - submodule: port submodule subcommand 'foreach' from shell to C > - submodule foreach: document variable '$displaypath' > - submodule foreach: clarify the '$toplevel'

[PATCH 4/5] submodule foreach: document variable '$displaypath'

From: Prathamesh Chavan It was observed that the variable '$displaypath' was accessible but undocumented. Hence, document it. Discussed-with: Ramsay Jones Signed-off-by: Stefan Beller Signed-off-by: Prathamesh Chavan

Re: [GSoC] Info: new blog series of my work on Git GSoC '18

On 2 May 2018 at 17:12, Johannes Schindelin wrote: > Hi Pratik, > > On Wed, 2 May 2018, Pratik Karki wrote: > >> As promised in my proposal, I've started >> to write a blog series of GSoC '18 with Git. The initial blog is up. >> You can find it here[1]. The initial one

Blame / annotate with mixed mac line endings?

I think this file may have been from a mac at one point. Note the lone CR (0x0d) line endings, with CRLFs later. $ cat src/htdocs/hr/ats/rpts/incl/slt_org.cfm | sed 's/[a-zA-Z]/x/g;s/[0-9]/8/g' | hexdump -C 3c 21 2d 2d 2d 0d 78 78 78 78 78 78 78 78 3a 20 |.

Re: [PATCH v2 00/42] object_id part 13

On Wed, May 02, 2018 at 05:32:24PM +0200, Duy Nguyen wrote: > Interdiff for people who don't have time to read 42 patches yet Thanks for this. I had intended to include tbdiff output in my series but had forgotten when I reformatted the patches. -- brian m. carlson: Houston, Texas, US OpenPGP:

Re: What's cooking in git.git (Apr 2018, #04; Mon, 30)

On 04/30, Junio C Hamano wrote: > * bw/protocol-v2 (2018-03-15) 35 commits > (merged to 'next' on 2018-04-11 at 23ee234a2c) > + remote-curl: don't request v2 when pushing > + remote-curl: implement stateless-connect command > + http: eliminate "# service" line when using protocol v2 > +

Re: [PATCH 08/41] packfile: abstract away hash constant values

On Wed, May 02, 2018 at 05:26:25PM +0200, Duy Nguyen wrote: > On Wed, May 2, 2018 at 2:11 AM, brian m. carlson > wrote: > > On Tue, May 01, 2018 at 12:22:43PM +0200, Duy Nguyen wrote: > >> While we're abstracting away 20. There's the only 20 left in > >> sha1_file.c

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

On Tue, 1 May 2018 14:34:03 -0700 Stefan Beller wrote: > +void *allocate_alloc_state(void) > +{ > + return xcalloc(1, sizeof(struct alloc_state)); > +} > + > +void clear_alloc_state(struct alloc_state *s) > +{ > + while (s->slab_nr > 0) { > +

Re: [PATCH 12/13] object: allow create_object to handle arbitrary repositories

On Tue, 1 May 2018 14:34:02 -0700 Stefan Beller wrote: > Signed-off-by: Jonathan Nieder > Signed-off-by: Stefan Beller Reviewed-by: Jonathan Tan Downloading this patch set and viewing the whole function

Re: [PATCH 04/13] alloc: add repository argument to alloc_blob_node

On Tue, 1 May 2018 14:33:54 -0700 Stefan Beller wrote: > Signed-off-by: Stefan Beller Add the same boilerplate explanation to this and subsequent commits. If editing it for every new function name is cumbersome, maybe use this shortened version: This

Re: [PATCH 01/13] repository: introduce object parser field

On Tue, 1 May 2018 14:33:51 -0700 Stefan Beller wrote: > Git's object access code can be thought of as containing two layers: > the raw object store provides access to raw object content, while the > higher level obj_hash code parses raw objects and keeps track of >

Re: [PATCH] git-p4 - Add option --sha1 to submit in p4

On 2 May 2018 at 16:51, Merland Romain wrote: > Thanks Luke, > > Following your comments, I will: > - change the option name to --commit if it suits you Seems like a good name. > - add an option --force-rebase which defaults to false. Setting it to true > will rebase even

RE: [PATCH 00/13] object store: alloc

> -Original Message- > From: Duy Nguyen > Sent: Wednesday, May 2, 2018 2:23 PM > To: Jameson Miller > Cc: Stefan Beller ; Git Mailing List > Subject: Re: [PATCH 00/13] object store: alloc > > On Wed,

Re: [PATCH] checkout & worktree: introduce a core.DWIMRemote setting

On Wed, May 02 2018, Eric Sunshine wrote: > On Wed, May 2, 2018 at 11:21 AM, Duy Nguyen wrote: >> On Wed, May 2, 2018 at 12:54 PM, Ævar Arnfjörð Bjarmason >> wrote: >>> Introduce a core.DWIMRemote setting which can be used to designate a >>> remote to

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

On Wed, May 2, 2018 at 8:07 PM, Jameson Miller wrote: > > >> -Original Message- >> From: Duy Nguyen >> Sent: Wednesday, May 2, 2018 1:02 PM >> To: Stefan Beller >> Cc: Git Mailing List ; Jameson Miller >>

Re: [PATCH] checkout & worktree: introduce a core.DWIMRemote setting

On Wed, May 2, 2018 at 8:00 PM, Eric Sunshine wrote: > 2. Building on #1: How well is the term "DWIM" understood by non-power > users? A term, such as "default" is more well known. I'm going off topic but I kinda dislike this term. First time I encountered it in the code

RE: [PATCH 00/13] object store: alloc

> -Original Message- > From: Duy Nguyen > Sent: Wednesday, May 2, 2018 1:02 PM > To: Stefan Beller > Cc: Git Mailing List ; Jameson Miller > > Subject: Re: [PATCH 00/13] object store: alloc > > On Tue,

Re: [PATCH] checkout & worktree: introduce a core.DWIMRemote setting

On Wed, May 2, 2018 at 11:21 AM, Duy Nguyen wrote: > On Wed, May 2, 2018 at 12:54 PM, Ævar Arnfjörð Bjarmason > wrote: >> Introduce a core.DWIMRemote setting which can be used to designate a >> remote to prefer (via core.DWIMRemote=origin) when running e.g.

Re: [PATCH 01/13] repository: introduce object parser field

On Wed, May 2, 2018 at 7:26 PM, Stefan Beller wrote: >> Another suggestion is object_pool, if we keep 'struct object' instead >> of 'struct parsed_object' and also want to keep current allocation >> behavior: no individual deallocation. If you free, you free the whole >> pool

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

On Tue, May 1, 2018 at 11:34 PM, Stefan Beller wrote: > #include "cache.h" > #include "object.h" > @@ -30,8 +31,25 @@ struct alloc_state { > int count; /* total number of nodes allocated */ > int nr;/* number of nodes left in current allocation */ >

Re: [PATCH 01/13] repository: introduce object parser field

On Wed, May 2, 2018 at 10:17 AM, Duy Nguyen wrote: > On Tue, May 1, 2018 at 11:33 PM, Stefan Beller wrote: >> /* >> -* Holds any information related to accessing the raw object content. >> +* Holds any information needed to retrieve

Re: [PATCH v4 0/3] add additional config settings for merge

Hi Ben, Thanks for your persistence. On Wed, May 2, 2018 at 9:01 AM, Ben Peart wrote: > This version incorporates Elijah's fixup patch and is now based on > en/rename-directory-detection in next. en/rename-directory-detection was in master but reverted.

Re: [PATCH 01/13] repository: introduce object parser field

On Tue, May 1, 2018 at 11:33 PM, Stefan Beller wrote: > /* > -* Holds any information related to accessing the raw object content. > +* Holds any information needed to retrieve the raw content > +* of objects. The object_parser uses this to get

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

On Tue, May 1, 2018 at 11:33 PM, Stefan Beller wrote: > I also debated if it is worth converting alloc.c via this patch series > or if it might make more sense to use the new mem-pool by Jameson[1]. > > I vaguely wonder about the performance impact, as the object allocation >

Gute Nachrichten

Ich bin Sgt.Monica Lin Brown, ursprünglich aus Lake Jackson Texas USA. Ich habe persönlich eine spezielle Recherche im Internet durchgeführt und bin auf Ihre Informationen gestoßen. Ich sende Ihnen diese E-Mail von der US-Militärbasis Kabul Afghanistan. Ich habe einen gesicherten

Re: [PATCH v4 03/10] commit-graph: compute generation numbers

Derrick Stolee writes: > On 4/29/2018 5:08 AM, Jakub Narebski wrote: >> Derrick Stolee writes: [...] >> It is a bit strange to me that the code uses get_be32 for reading, but >> htonl for writing. Is Git tested on non little-endian machines, like >>

[PATCH v4 3/3] merge: pass aggressive when rename detection is turned off

Set aggressive flag in git_merge_trees() when rename detection is turned off. This allows read_tree() to auto resolve more cases that would have otherwise been handled by the rename detection. Reviewed-by: Johannes Schindelin Signed-off-by: Ben Peart

[PATCH v4 2/3] merge: Add merge.renames config setting

Add the ability to control rename detection for merge via a config setting. This setting behaves the same and defaults to the value of diff.renames but only applies to merge. Reviewed-by: Johannes Schindelin Helped-by: Elijah Newren Signed-off-by:

[PATCH v4 1/3] merge: update documentation for {merge,diff}.renameLimit

Update the documentation to better indicate that the renameLimit setting is ignored if rename detection is turned off via command line options or config settings. Signed-off-by: Ben Peart --- Documentation/diff-config.txt | 3 ++- Documentation/merge-config.txt | 3 ++-

[PATCH v4 0/3] add additional config settings for merge

This version incorporates Elijah's fixup patch and is now based on en/rename-directory-detection in next. Base Ref: en/rename-directory-detection Web-Diff: https://github.com/benpeart/git/commit/16b175c25f Checkout: git fetch https://github.com/benpeart/git merge-renames-v4 && git checkout

Re: [PATCH v2 1/2] commit: fix --short and --porcelain options

On Tue, May 1, 2018 at 10:50 PM Junio C Hamano wrote: > Samuel Lijin writes: > > Mark the commitable flag in the wt_status object in the call to > > `wt_status_collect()`, instead of in `wt_longstatus_print_updated()`, > > and simplify the logic in the

Re: [PATCH v2 00/42] object_id part 13

On Wed, May 02, 2018 at 12:25:28AM +, brian m. carlson wrote: > Changes from v1: > * Add missing sign-off. > * Removed unneeded braces from init_pack_info. > * Express 51 in terms of the_hash_algo->hexsz. > * Fix comments referring to SHA-1. > * Update commit messages as suggested. > * Add and

Re: [PATCH 08/41] packfile: abstract away hash constant values

On Wed, May 2, 2018 at 2:11 AM, brian m. carlson wrote: > On Tue, May 01, 2018 at 12:22:43PM +0200, Duy Nguyen wrote: >> On Mon, Apr 23, 2018 at 11:39:18PM +, brian m. carlson wrote: >> > There are several instances of the constant 20 and 20-based values in >> >

Re: [PATCH] checkout & worktree: introduce a core.DWIMRemote setting

On Wed, May 2, 2018 at 12:54 PM, Ævar Arnfjörð Bjarmason wrote: > Introduce a core.DWIMRemote setting which can be used to designate a > remote to prefer (via core.DWIMRemote=origin) when running e.g. "git > checkout master" to mean origin/master, even though there's other >

Re: [PATCH v2 1/4] test-tool: help verifying BUG() code paths

On Wed, May 2, 2018 at 11:38 AM, Johannes Schindelin wrote: > When we call BUG(), we signal via SIGABRT that something bad happened, > dumping cores if so configured. In some setups these coredumps are > redirected to some central place such as

Re: [PATCH] git-p4 - Add option --sha1 to submit in p4

On 2 May 2018 at 15:32, Merland Romain wrote: > From 4867808cad2b759ebf31c275356e602b72c5659f Mon Sep 17 00:00:00 2001 > From: Romain Merland > To: git@vger.kernel.org > Cc: Junio C Hamano , Jeff King , Luke > Diamand

Re:

On 4/30/2018 12:12 PM, Elijah Newren wrote: On Mon, Apr 30, 2018 at 6:11 AM, Ben Peart wrote: On 4/27/2018 2:19 PM, Elijah Newren wrote: From: Elijah Newren On Thu, Apr 26, 2018 at 5:54 PM, Ben Peart wrote: Can you write the

[PATCH] git-send-email: allow re-editing of message

When shown the email summary, an opportunity is presented for the user to edit the email as if they had specified --annotate. This also permits them to edit it multiple times. Signed-off-by: Drew DeVault Reviewed-by: Simon Ser --- Sent to the ML without

Re: [PATCH v2] wt-status: use rename settings from init_diff_ui_defaults

On 5/1/2018 8:08 PM, Elijah Newren wrote: On Tue, May 1, 2018 at 4:11 PM, Junio C Hamano wrote: Elijah Newren writes: I also just realized that in addition to status being inconsistent with diff/log/show, it was also inconsistent with itself -- it

Re: [PATCH v3 00/12] get_short_oid UI improvements

On 5/2/2018 8:42 AM, Derrick Stolee wrote: On 5/1/2018 2:40 PM, Ævar Arnfjörð Bjarmason wrote: The biggest change in v3 is the no change at all to the code, but a lengthy explanation of why I didn't go for Derrick's simpler implementation. Maybe I'm wrong about that, but I felt uneasy

Re: [PATCH v4 08/10] commit: add short-circuit to paint_down_to_common()

On 5/2/2018 9:05 AM, Jakub Narebski wrote: Derrick Stolee writes:     For a copy of the Linux repository, we measured the following     performance improvements:     git merge-base v3.3 v4.5     Before: 234 ms After: 208 ms Rel %: -11%     git merge-base

Re: [PATCH v4 08/10] commit: add short-circuit to paint_down_to_common()

Derrick Stolee writes: > On 4/30/2018 6:19 PM, Jakub Narebski wrote: >> Derrick Stolee writes: [...] >>> @@ -831,6 +834,13 @@ static struct commit_list *paint_down_to_common(struct >>> commit *one, int n, struc >>> struct commit_list

Re: [PATCH v3 00/12] get_short_oid UI improvements

On 5/1/2018 2:40 PM, Ævar Arnfjörð Bjarmason wrote: The biggest change in v3 is the no change at all to the code, but a lengthy explanation of why I didn't go for Derrick's simpler implementation. Maybe I'm wrong about that, but I felt uneasy offloading undocumented (or if I documented it, it

Re: [PATCH] gitweb: Measure offsets against UTF-8 flagged string

> ideally we should be able to say "function X takes non-UTF8 and > works on it", "function Y takes UTF8 and works on it", and "function > Z takes non-UTF8 and gives UTF8 data back" for each functions > clearly, not "function W can take either UTF8 or any other garbage > and tries to return UTF8".

Re: [PATCH v4 09/10] merge: check config before loading commits

Derrick Stolee writes: > On 4/30/2018 6:54 PM, Jakub Narebski wrote: >> Derrick Stolee writes: >> >>> Now that we use generation numbers from the commit-graph, we must >>> ensure that all commits that exist in the commit-graph are loaded >>> from that

[PATCH] checkout & worktree: introduce a core.DWIMRemote setting

Introduce a core.DWIMRemote setting which can be used to designate a remote to prefer (via core.DWIMRemote=origin) when running e.g. "git checkout master" to mean origin/master, even though there's other remotes that have the "master" branch. I want this because it's very handy to use this

Re: What's cooking in git.git (Apr 2018, #04; Mon, 30)

Johannes Schindelin writes: >> As I wrote elsewhere, for a low-impact and ralatively old issue like >> this, it is OK for a fix to use supporting code that only exists in >> more recent codebase and become unmergeable to anything older than >> the concurrent 'maint'

Re: [PATCH 2/6] t1406: prepare for the refs code to fail with BUG()

Johannes Schindelin writes: >> As discussed in this thread, tests that use t/helper/ executables >> that try to trickle BUG() codepath to ensure that these "should >> never happen" conditions are caught do need to deal with it. If >> dumping core is undesirable,

[PATCH v2 0/4] Finish the conversion from die("BUG: ...") to BUG()

The BUG() macro was introduced in this patch series: https://public-inbox.org/git/20170513032414.mfrwabt4hovuj...@sigill.intra.peff.net The second patch in that series converted one caller from die("BUG: ") to use the BUG() macro. It seems that there was no concrete plan to address the same

[PATCH v2 2/4] run-command: use BUG() to report bugs, not die()

The slightly misleading name die_bug() of the function intended to report a bug is actually called always, and only reports a bug if the passed-in parameter `err` is non-zero. It uses die_errno() to report the bug, to helpfully include the error message corresponding to `err`. However, as these

[PATCH v2 3/4] Replace all die("BUG: ...") calls by BUG() ones

In d8193743e08 (usage.c: add BUG() function, 2017-05-12), a new macro was introduced to use for reporting bugs instead of die(). It was then subsequently used to convert one single caller in 588a538ae55 (setup_git_env: convert die("BUG") to BUG(), 2017-05-12). The cover letter of the patch series

[PATCH v2 4/4] Convert remaining die*(BUG) messages

These were not caught by the previous commit, as they did not match the regular expression. While at it, remove the localization from one instance: we never want BUG() messages to be translated, as they target Git developers, not the end user (hence it would be quite unhelpful to not only burden

[PATCH v2 1/4] test-tool: help verifying BUG() code paths

When we call BUG(), we signal via SIGABRT that something bad happened, dumping cores if so configured. In some setups these coredumps are redirected to some central place such as /proc/sys/kernel/core_pattern, which is a good thing. However, when we try to verify in our test suite that bugs are

Re: [PATCH 0/3] Add --progress and --dissociate to git submodule

Thanks I was not aware of that option. On Wed, May 2, 2018 at 12:37 AM, Junio C Hamano wrote: > Casey Fitzpatrick writes: > >> These patches add --progress and --dissociate options to git submodule. >> >> The --progress option existed beforehand, but only

Re: [PATCH] gitweb: Measure offsets against UTF-8 flagged string

Shin Kojima writes: > Offset positions should not be counted by byte length, but by actual > character length. > ... > # escape tabs (convert tabs to spaces) > sub untabify { > - my $line = shift; > + my $line = to_utf8(shift); > > while ((my $pos =

Re: [PATCH v4 10/10] commit-graph.txt: update design document

Derrick Stolee writes: > On 4/30/2018 7:32 PM, Jakub Narebski wrote: >> Derrick Stolee writes: [...] >>> - After computing and storing generation numbers, we must make graph >>> walks aware of generation numbers to gain the performance benefits

Re: [PATCH 2/6] t1406: prepare for the refs code to fail with BUG()

Hi, On Wed, 2 May 2018, Junio C Hamano wrote: > Duy Nguyen writes: > > > On Mon, Apr 30, 2018 at 12:17 AM, Johannes Schindelin > > wrote: > >> t1406 specifically verifies that certain code paths fail with a BUG: ... > >> message. > >> > >> In the

Re: git merge banch w/ different submodule revision

Am Montag, den 30.04.2018, 19:02 +0200 schrieb Heiko Voigt: > On Thu, Apr 26, 2018 at 03:19:36PM -0700, Stefan Beller wrote: > > Stefan wrote: > > > See > > > https://github.com/git/git/commit/68d03e4a6e448aa557f52adef92595ac4d6cd4bd > > > (68d03e4a6e (Implement automatic fast-forward merge for

Re: [GSoC] Info: new blog series of my work on Git GSoC '18

Hi Pratik, On Wed, 2 May 2018, Pratik Karki wrote: > As promised in my proposal, I've started > to write a blog series of GSoC '18 with Git. The initial blog is up. > You can find it here[1]. The initial one is just to get started and > from next iterations, I'll start detailing of my work

Re: [PATCH v2] test-drop-caches: simplify delay loading of NtSetSystemInformation

Hi Ben, On Tue, 1 May 2018, Ben Peart wrote: > Take advantage of the recent addition of support for lazy loading functions[1] > on Windows to simplify the loading of NtSetSystemInformation. > > [1] db2f7c48cb (Win32: simplify loading of DLL functions, 2017-09-25) > > Signed-off-by: Ben Peart

Re: What's cooking in git.git (Apr 2018, #04; Mon, 30)

Hi Junio, On Wed, 2 May 2018, Junio C Hamano wrote: > Johannes Schindelin writes: > > > So the problem you found is not a problem with *my* branch, of course, as > > I did not fork off of ... > > Correct; there is no blame on you with the choice of the base. It >

Re: [PATCH] revisions.txt: expand tabs to spaces in diagram

On 2 May 2018 at 06:50, Junio C Hamano wrote: > Martin Ågren writes: > >> The diagram renders fine in AsciiDoc before and after this patch. >> Asciidoctor, on the other hand, ignores the tabs entirely, which results >> in different indentation for

Re: [PATCH 1/3] submodule: clean up subsititions in script

Casey Fitzpatrick writes: > 'recommend_shallow' and 'jobs' variables do not need quotes (they never > contain > spaces) and do not require any additional prefix, therefore remove the > unnecessary subsitition. The resulting patch is good, but "they never contain spaces" is