Re: [PATCH v4 2/5] unpack-trees: add performance tracing

On Sun, 12 Aug 2018 at 09:19, Nguyễn Thái Ngọc Duy wrote: Hi, > + trace_performance_leave("cache_tree_update"); I would suggest trace_performance_leave() calls use __func__ instead. That way, there's no ambiguity if the function name ever changes. Kindly, Thomas

Adam Milton - advertising 2d animation video

Hey! My name is Adam Milton I am a team leader at " Inovit" animation studio. Our company creates professional 2d animation explainer videos that help to tell your business story in an engaging way, increase conversions, maximize your business exposure and boost sales. R

Re: Hash algorithm analysis

Somewhere upthread, Brian refers to me as a cryptographer. That's flattering (thank you), but probably not really true even on a good day. And certainly not true next to Joan Daemen. I do have experience with crypto at scale and in ecosystems, though. Joan's count of cryptanalysis papers is a

[PATCH v2] hooks/pre-auto-gc-battery: allow gc to run on non-laptops

ces as it already queried them, and is smarter than us (can handle multiple adapters). Reported by: Xin Li <delp...@google.com> Signed-off-by: Adam Borowski <kilob...@angband.pl> --- v2: improved commit message contrib/hooks/pre-auto-gc-battery | 2 +- 1 file changed, 1 insertion(+), 1 deletion(

Re: [PATCH] hooks/pre-auto-gc-battery: allow gc to run on non-laptops

On Wed, Feb 28, 2018 at 10:16:21AM -0800, Junio C Hamano wrote: > Adam Borowski <kilob...@angband.pl> writes: > > > Desktops and servers tend to have no power sensor, thus on_ac_power returns > > 255 ("unknown"). > > > > If that tool returns "u

[PATCH] hooks/pre-auto-gc-battery: allow gc to run on non-laptops

<delp...@google.com> Signed-off-by: Adam Borowski <kilob...@angband.pl> --- contrib/hooks/pre-auto-gc-battery | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/contrib/hooks/pre-auto-gc-battery b/contrib/hooks/pre-auto-gc-battery index 6a2cdebdb..7ba78c4df 100755 --- a/c

Re: [PATCH v3 22/23] cat-file: tests for new atoms added

("cat-file: tests for new atoms added", 2018-02-12), as the culprit. I'm afraid I'm not going to have the time to investigate the failure any further in the immediate future, but I wanted to report it promptly in case you / someone else can see what's going wrong. Adam

Re: [PATCH v4 8/7] wildmatch test: skip file creation tests on Windows proper

e have here, then I agree, but I don't think there's much value in doing that except as a proof of concept, as in this immediate discussion. The obvious-to-me way to do this would be following the precedent of the core code: gradually migrate things away from shell code to C code. Adam

Re: [PATCH v2 7/7] wildmatch test: create & test files on disk in addition to in-memory

On Wednesday 03 January 2018 at 08:14 pm +0100, Ævar Arnfjörð Bjarmason wrote: > > On Wed, Jan 03 2018, Adam Dinwoodie jotted: > > > On Wednesday 03 January 2018 at 02:31 pm +0100, Ævar Arnfjörð Bjarmason > > wrote: > >> Does the fixup above in <878tdm8

Re: [PATCH v2 7/7] wildmatch test: create & test files on disk in addition to in-memory

On Wednesday 03 January 2018 at 02:31 pm +0100, Ævar Arnfjörð Bjarmason wrote: > > On Wed, Jan 03 2018, Adam Dinwoodie jotted: > > > On Monday 25 December 2017 at 12:28 am +, Ævar Arnfjörð Bjarmason wrote: > >> There has never been any full roundtrip test

Re: [PATCH v2 7/7] wildmatch test: create & test files on disk in addition to in-memory

# wildtest_file_setup && # printf '%s' '\' >expect && # git --glob-pathspecs ls-files -z -- '00' >actual.raw 2>actual.err && # wildtest_stdout_stderr_cmp # I'm digging into the failures myself now, but wanted to report the problem in the name of getting more eyes on it. Adam [0]: https://gist.github.com/me-and/04443bcb00e12436f0eacce079b56d02

Re: Test failure for v2.16.0-rc0 on cygwin

On Saturday 30 December 2017 at 02:40 pm +, Adam Dinwoodie wrote: > On Saturday 30 December 2017 at 02:21 pm +, Ramsay Jones wrote: > > Hi Junio, Adam, > > > > Just a quick note about the failure of the test-suite on cygwin. > > In particular, test t5580-cl

Re: Test failure for v2.16.0-rc0 on cygwin

On Saturday 30 December 2017 at 02:21 pm +, Ramsay Jones wrote: > Hi Junio, Adam, > > Just a quick note about the failure of the test-suite on cygwin. > In particular, test t5580-clone-push-unc.sh #3, like so: > > > > Adam, are you running the tests on Windows

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

program does this, and they don't go down this route of having copies of various CPAN modules just in case. So why should we? We're not a special snowflake. -- Thomas Adam

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

re time hacking ;-) > > I guess the full solution is to make Mail::Address a hard dependency? This is what I was suggesting, and then as a follow-up, addressing the point that there's a bunch of require() hacks to also get around needing hard-dependencies. -- Thomas Adam

Re: [PATCH v4 0/2] launch_editor(): indicate that Git waits for user input

On Thu, Nov 30, 2017 at 03:12:17PM -0500, Jeff King wrote: > On Wed, Nov 29, 2017 at 06:35:16PM +, Thomas Adam wrote: > > > On Wed, Nov 29, 2017 at 03:37:50PM +0100, lars.schnei...@autodesk.com wrote: > > > + if (print_waiting_for_editor) { > > > +

Re: [PATCH v4 0/2] launch_editor(): indicate that Git waits for user input

On Thu, Nov 30, 2017 at 02:55:35PM +0100, Lars Schneider wrote: > > > On 29 Nov 2017, at 19:35, Thomas Adam <tho...@xteddy.org> wrote: > > > > On Wed, Nov 29, 2017 at 03:37:50PM +0100, lars.schnei...@autodesk.com wrote: > >> +

Re: [PATCH v4 0/2] launch_editor(): indicate that Git waits for user input

s typically unbuffered on most systems I've used, and although the call to fflush() is harmless, I suspect it's not having any effect. That said, there's plenty of other places in Git which seems to think fflush()ing stderr actually does something. -- Thomas Adam

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

On Tuesday 21 November 2017 at 12:00 am -0800, Elijah Newren wrote: > > > merge-recursive.c | 1243 +++- > merge-recursive.h | 17 + > t/t3501-revert-cherry-pick.sh |5 +- > t/t6043-merge-rename-directories.sh | 3821 >

Re: Bisect marking new commits incorrectly

On Wednesday 22 November 2017 at 05:21 pm +0100, Christian Couder wrote: > On Wed, Nov 22, 2017 at 3:39 PM, Adam Dinwoodie <a...@dinwoodie.org> wrote: > > In trying to do a bisect on the Git repository, I seem to have come > > across surprising behavior where the order

Bisect marking new commits incorrectly

In trying to do a bisect on the Git repository, I seem to have come across surprising behavior where the order in which `git bisect` appears to forget that previous commits were marked as new. You can see this behaviour in the following commands, run on the Git repository, where the order of the

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

y depending on which modules are installed. Given the pretty good state of packaging across those platforms which Git runs on, I would argue we're now in a much better position to explicitly check for non-core modules at BEGIN{} time, and moan loudly if they're not installed. -- Thomas Adam

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

ions to the > appropriate bits. Maybe Matthieu or Remi (CC'ed) might want to chime in > on other options? 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. https://metacpan.org/pod/distribution/MailTools/lib/Mail/Address.pod -- Thomas Adam

Re: t3512 & t3513 'unexpected passes'

On Monday 20 November 2017 at 08:16 pm +, Ramsay Jones wrote: > For several days, I have been staring at some 'unexpected passes' in > the t3512-cherry-pick-submodule.sh and t3513-revert-submodule.sh test > files (tests #11-13 in both cases). > > I finally found time tonight to 'git bisect'

[RFC PATCH v2 2/2] bisect: add "edit" command

his commit merely reduces those separate steps to a single step. Signed-off-by: Adam Dinwoodie <a...@dinwoodie.org> --- builtin/bisect--helper.c | 3 ++- git-bisect.sh| 18 ++ 2 files changed, 20 insertions(+), 1 deletion(-) diff --git a/builtin/bisect--helper.c

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

find a consensus on what best practice is for handling errors between the existing shell code in this script and git-rebase--interactive.sh. - There aren't yet any tests or documentation changes; I wanted to get commentary on the initial code changes before I spent time on those parts.

[RFC PATCH v2 1/2] bisect: split out replay file parsing

In order to allow a git bisect log file to be replayed without using all the surrounding code to do things like clean the repository state, split out the file-parsing part of bisect_replay into a separate function. Signed-off-by: Adam Dinwoodie <a...@dinwoodie.org> --- git-bisect.

[PATCH v4] doc/SubmittingPatches: correct subject guidance

as what appears to be the more common pratice on the mailing list, is to use "[RFC PATCH]", not "[PATCH/RFC]". Update the SubmittingPatches article to match and to reference the `format-patch` helper arguments, and also make some minor text clarifications in the area. Signed-

Re: [PATCH] notes: add `rm` and `delete` commands

On Friday 10 November 2017 at 12:14 pm +0900, Junio C Hamano wrote: > Eric Sunshine writes: > > > or against the change: > > > > - synonym bloat; balloons documentation > > - steals command verbs from potential future features > > - ... > > I tend to agree

[PATCH] notes: add `rm` and `delete` commands

Add `git notes rm` and `git notes delete` as alternative ways of saying `git notes remove`. Signed-off-by: Adam Dinwoodie <a...@dinwoodie.org> --- Documentation/git-notes.txt | 4 +++- builtin/notes.c | 8 +--- t/t3301-notes.sh| 6 +++--- 3 files chang

[PATCH v3] doc/SubmittingPatches: correct subject guidance

as what appears to be the more common pratice on the mailing list, is to use "[RFC PATCH]", not "[PATCH/RFC]". Update the SubmittingPatches article to match, and to reference the `format-patch` helper arguments. Signed-off-by: Adam Dinwoodie <a...@dinwoodie.o

Re: [PATCH v2] doc/SubmittingPatches: correct subject guidance

On Wednesday 08 November 2017 at 09:10 am -0500, Eric Sunshine wrote: > On Wed, Nov 8, 2017 at 8:47 AM, Adam Dinwoodie <a...@dinwoodie.org> wrote: > > +e-mail discussions. Use of markers in addition to PATCH within > > +the brackets to describe the nature of the patch is

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

> This causes some repo corruption tests to fail. Confirmed: I see this patch, or at least f7e0dbc38 ("clone, fetch-pack, index-pack, transport: partial clone", 2017-11-02), causing t5300.26 to fail on 64-bit Cygwin. For the sake of anyone trying to reproduce this, I needed to cherry pick 66d4c7a58 ("fixup! upload-pack: add object filtering for partial clone", 2017-11-08) onto that commit before I was able to get it to compile. Adam

Re: [RFC PATCH] rebisect: add script for easier bisect log editing

On Wednesday 08 November 2017 at 05:15 pm +0100, Christian Couder wrote: > >> +git bisect replay "$GIT_BISECT_LOG_TMP" > >> +rm -f "$GIT_BISECT_LOG_TMP" > > While at it, is there a reason for the -f option above? I was following the lead of git-bisect.sh, which has used `rm -f` for such things

Re: [RFC PATCH] rebisect: add script for easier bisect log editing

On Wednesday 08 November 2017 at 05:12 pm +0100, Christian Couder wrote: > On Wed, Nov 8, 2017 at 2:59 PM, Adam Dinwoodie <a...@dinwoodie.org> wrote: > > +git bisect reset HEAD > > I guess that using "reset HEAD" could be cheaper than just "reset&qu

[RFC PATCH] rebisect: add script for easier bisect log editing

Add a short script, vaguely inspired by `git rebase --interactive`, to ease the process described in the `git bisect` documentation of saving off a bisect log, editing it, then replaying it. Signed-off-by: Adam Dinwoodie <a...@dinwoodie.org> --- When I'm bisecting, I find I need t

[PATCH v2] doc/SubmittingPatches: correct subject guidance

as what appears to be the more common pratice on the mailing list, is to use "[RFC PATCH]", not "[PATCH/RFC]". Update the SubmittingPatches article to match. Signed-off-by: Adam Dinwoodie <a...@dinwoodie.org> --- I'm re-rolling this patch with some more substantive changes

[PATCH] rebase -i: fix comment typo

Signed-off-by: Adam Dinwoodie <a...@dinwoodie.org> --- git-rebase--interactive.sh | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/git-rebase--interactive.sh b/git-rebase--interactive.sh index 2563dc52d..437815669 100644 --- a/git-rebase--interactive.sh +++ b/git-

[PATCH] doc/SubmittingPatches: correct subject guidance

r the closing bracket. Signed-off-by: Adam Dinwoodie <a...@dinwoodie.org> --- Documentation/SubmittingPatches | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Documentation/SubmittingPatches b/Documentation/SubmittingPatches index 558d465b6..e91ce8269 100644 --- a/D

Re: [PATCH v4 3/7] remote-mediawiki: show known namespace choices on failure

spaces = map { s/ /_/g; $_; } sort keys %namespaces_id; Oops. This was my typo from my original suggestion. The hash is '%namespace_id', not '%namespaces_id'. However, how did this slip through testing? I'm assuming you blindly copied this from my example, which although quick to do, is only being caught because of my sharp eyes... -- Thomas Adam

Re: [PATCH v4 2/7] remote-mediawiki: allow fetching namespaces with spaces

t this to the following: my @tracked_namespaces = map { chomp; s/_/ /g; $_; } split(/[ \n]/, run_git("config --get-all remote.${remotename}.namespaces")); This would, once again, avoid creating @tracked_namespaces, and iterating over it. Note that this isn't about trying to 'golf' this; it's a performance consideration. Kindly, Thomas Adam

Re: [PATCH 3/4] remote-mediawiki: show known namespace choices on failure

keys %namespace_id; > + for (@namespaces) { s/ /_/g; } I am sure we can improve upon the need to process @namespaces twice: my @namespaces = map { s/ /_/g; $_; } sort keys %namespaces_id; -- Thomas Adam

Re: [PATCH v3 7/7] remote-mediawiki: show progress while fetching namespaces

wiser to transition this to using Carp in the long run -- it would decrease the round-trip time to debugging should there be a situation where that was needed, and hence I would recommend using "warn" for less-severe errors/debugging. -- Thomas Adam

Re: [PATCH v3 7/7] remote-mediawiki: show progress while fetching namespaces

On Thu, Nov 02, 2017 at 06:26:43PM -0400, Antoine Beaupré wrote: > On 2017-11-02 22:18:07, Thomas Adam wrote: > > Hi, > > > > On Thu, Nov 02, 2017 at 05:25:18PM -0400, Antoine Beaupré wrote: > >> +print {*STDERR} "$#{$mw_pages} found in namespace >

Re: [PATCH v3 7/7] remote-mediawiki: show progress while fetching namespaces

Hi, On Thu, Nov 02, 2017 at 05:25:18PM -0400, Antoine Beaupré wrote: > +print {*STDERR} "$#{$mw_pages} found in namespace $local_namespace > ($namespace_id)\n"; How is this any different to using warn()? I appreciate you're using a globbed filehandle, but it seems superfluous to me.

Re: [PATCH] t5580: add Cygwin support

On Wed, Nov 01, 2017 at 10:44:22AM +0900, Junio C Hamano wrote: > Adam Dinwoodie <a...@dinwoodie.org> writes: > > > t5580 tests that specifying Windows UNC paths works with Git. Cygwin > > supports UNC paths, albeit only using forward slashes, not backslashes, > &g

[PATCH] t5580: add Cygwin support

for calculating the UNC path to the current directory. Instead use Cygwin's `cygpath` utility to get the Windows-style path. Signed-off-by: Adam Dinwoodie <a...@dinwoodie.org> --- t/t5580-clone-push-unc.sh | 12 1 file changed, 8 insertions(+), 4 deletions(-) diff --git a/t

Ascertaining amount of "original" code across files/repo

then did some maths on the total lines from each of those files and to work out a percentage by file, and over all. What I'm curious to know is whether this approach of using "git blame" is a good approach or not. Thanks for your time. -- Thomas Adam

Re: v2.15.0-rc1 test failure

On Thu, Oct 12, 2017 at 01:27:57AM +0100, Ramsay Jones wrote: > On 11/10/17 23:34, Adam Dinwoodie wrote: > [snip] > > Hi Ramsay, > > > > I assume, given you're emailing me, that this is a Cygwin failure? > > Yes, sorry, I should have made that clear. > >

Re: v2.15.0-rc1 test failure

On Wed, Oct 11, 2017 at 11:15:57PM +0100, Ramsay Jones wrote: > Hi Adam, > > I had a test failure on the v2.15.0-rc1 build tonight. > The test in question being t0021-conversion.sh #15 > ('required process filter should filter data'). I didn't > have any test failures on v2.15.

[PATCH] doc: correct command formatting

Leaving spaces around the `-delimeters for commands means asciidoc fails to parse them as the start of a literal string. Remove an extraneous space that is causing a literal to not be formatted as such. Signed-off-by: Adam Dinwoodie <a...@dinwoodie.org> --- Documentation/git.txt | 2 +-

Re: [PATCH 1/1] fast-import: checkpoint: dump branches/tags/marks even if object_count==0

On Wed, Sep 27, 2017 at 10:07:41PM -0700, Eric Rannaud wrote: > The checkpoint command cycles packfiles if object_count != 0, a sensible > test or there would be no pack files to write. Since 820b931012, the > command also dumps branches, tags and marks, but still conditionally. > However, it is

Re: Unexpected pass for t6120-describe.sh on cygwin

On Sat, Sep 09, 2017 at 02:13:32PM +0100, Ramsay Jones wrote: > I ran the test-suite on the 'pu' branch last night (simply because > that was what I had built at the time!), which resulted in a PASS, > but t6120 was showing a 'TODO passed' for #52. Confirmed, I also see this unexpected pass. >

Re: cat-file timing window on Cygwin

On Sun, Aug 27, 2017 at 03:06:31AM +0100, Ramsay Jones wrote: > On 26/08/17 22:11, Adam Dinwoodie wrote: > > On Sat, Aug 26, 2017 at 11:53:37AM -0700, Jeff King wrote: > >> Interesting. I find it a little hard to believe there's so obvious a bug > >> as "fflus

Re: cat-file timing window on Cygwin

On Sat, Aug 26, 2017 at 11:53:37AM -0700, Jeff King wrote: > On Sat, Aug 26, 2017 at 01:57:18AM +0100, Ramsay Jones wrote: > > > > diff --git a/run-command.c b/run-command.c > > > index 98621faca8..064ebd1995 100644 > > > --- a/run-command.c > > > +++ b/run-command.c > > > @@ -641,7 +641,6 @@ int

Re: cat-file timing window on Cygwin

On Sat, Aug 26, 2017 at 01:57:18AM +0100, Ramsay Jones wrote: > On 25/08/17 16:08, Jeff King wrote: > > On Fri, Aug 25, 2017 at 12:25:29PM +0100, Adam Dinwoodie wrote: > > > >> As of v2.10.0-rc1-4-g321459439 ("cat-file: support --textconv/--filters > >> in b

cat-file timing window on Cygwin

As of v2.10.0-rc1-4-g321459439 ("cat-file: support --textconv/--filters in batch mode"), t8010-cat-file-filters.sh has been failing on Cygwin. Digging into this, the test looks to expose a timing window: it appears that if `git cat-file --textconv --batch` receives input on stdin too quickly, it

Re: splitting off shell test framework

On 23 August 2017 at 16:47, Jeff King <p...@peff.net> wrote: > On Wed, Aug 23, 2017 at 02:46:30PM +0100, Adam Spiers wrote: >> >> Done at least once already: >> >> >> >> http://comments.gmane.org/gmane.comp.version-control.git/201591 >> [...] &g

Re: splitting off shell test framework

I got a helpful response to the following question almost 5 years ago: On 12 November 2012 at 23:09, Adam Spiers <g...@adamspiers.org> wrote: > On Mon, Nov 12, 2012 at 6:18 PM, Drew Northup <n1xim.em...@gmail.com> wrote: >> On Mon, Nov 12, 2012 at 11:37 AM, Adam Spiers <g.

Re: Bug?: git archive exclude pathspec and gitattributes export-ignore

On Mon, 14 Aug 2017, René Scharfe wrote: > Am 13.08.2017 um 06:53 schrieb David Adam: > > I think I have a bug in git (tested 2.11.0 on Debian 8, 2.14.1 on OS X and > > 2.14.1.145.gb3622a4 on OS X). > > > > Given a repository with an export-ignore d

Bug?: git archive exclude pathspec and gitattributes export-ignore

s is a reduced testcase; my goal is to end up with two archives, one containing directory b only, and one containing everything except for directory b - so I can't just add 'b export-ignore' to gitattributes. Thanks David Adam zanc...@ucc.gu.uwa.edu.au

Re: t3700 broken on pu on Cygwin

On Tue, Aug 08, 2017 at 06:25:24PM +0100, Adam Dinwoodie wrote: > I'm running a bisect overnight to try to isolate the commit on the left > merge parent that seems to be interacting badly with the commit on the > right, and will send in the results from that when I have them. For

Re: t3700 broken on pu on Cygwin

On Tue, Aug 08, 2017 at 05:32:21PM +0200, René Scharfe wrote: > Am 08.08.2017 um 17:18 schrieb Adam Dinwoodie: > > The t3700-add.sh test is currently failing on the pu branch on Cygwin. > > To my surprise, the problem appears to have been introduced by a merge, > > 867

t3700 broken on pu on Cygwin

The t3700-add.sh test is currently failing on the pu branch on Cygwin. To my surprise, the problem appears to have been introduced by a merge, 867fa1d6a. Both parents of that merge have the test succeeding, but it's failing on that merge commit. Failing test output below: $ ./t3700-add.sh

Re: [PATCH 0/1] add git-splice subcommand for non-interactive branch splicing

On 31 July 2017 at 23:18, Junio C Hamano <gits...@pobox.com> wrote: > Adam Spiers <g...@adamspiers.org> writes: > > > Therefore there is a risk that each new UI for higher-level workflows > > will end up re-implementing these mid-level operations. This > > un

[PATCH 0/1] add git-splice subcommand for non-interactive branch splicing

course very welcome! Thanks, Adam Adam Spiers (1): add git-splice command for non-interactive branch splicing .gitignore | 1 +- Documentation/git-splice.txt | 125 ++- Makefile | 1 +- git-splice.sh| 737 ++

[PATCH 1/1] add git-splice command for non-interactive branch splicing

is persisted to disk, and thereby supports standard --abort and --continue semantics just like git's other extended workflow commands. It also handles more complex cases, as described in the manual page. Signed-off-by: Adam Spiers <g...@adamspiers.org> --- .gitignore

Re: Continous Integration (was: RE: Git v2.13.1 SHA1 very broken)

ly limited spare time, though, and not something I've done before, so it's taking a little while to get going. Adam

Re: Which hash function to use, was Re: RFC: Another proposed hash function transition plan

On Fri, Jun 16, 2017 at 6:24 AM, Johannes Schindelin <johannes.schinde...@gmx.de> wrote: > > And while I am really thankful that Adam chimed in, I think he would agree > that BLAKE2 is a purposefully weakened version of BLAKE, for the benefit > of speed That is correct. Alth

Re: Which hash function to use, was Re: RFC: Another proposed hash function transition plan

(I was asked to comment a few points in public by Jonathan.) I think this group can safely assume that SHA-256, SHA-512, BLAKE2, K12, etc are all secure to the extent that I don't believe that making comparisons between them on that axis is meaningful. Thus I think the question is primarily

Re: [PATCH] docs: suggest "Helped-by" rather than "Thanks-to"

(Resending to everyone after only sending to Junio by mistake.) On Wed, Jun 07, 2017 at 08:44:08AM +0900, Junio C Hamano wrote: > Adam Dinwoodie <a...@dinwoodie.org> writes: > > > On Mon, Jun 05, 2017 at 11:42:31AM -0700, Stefan Beller wrote: > >> So I was wond

Re: [PATCH] docs: suggest "Helped-by" rather than "Thanks-to"

On Mon, Jun 05, 2017 at 11:42:31AM -0700, Stefan Beller wrote: > So I was wondering if there is a command that shows all trailers? > Similar to a "shortlog -sne" I would want to have a list of all trailers. > This is because there might be an even more popular trailer than > "Helped-by", but we

Re: Git v2.13.1 SHA1 very broken

On Tue, Jun 06, 2017 at 08:55:04PM +0900, Junio C Hamano wrote: > Adam Dinwoodie <a...@dinwoodie.org> writes: > > > Digging briefly into the endianness detection, it appears Cygwin has > > both _LITTLE_ENDIAN and _BIG_ENDIAN defined. Git's detection works by > > as

Re: Git v2.13.1 SHA1 very broken

On Tue, Jun 06, 2017 at 10:20:45AM +0900, Junio C Hamano wrote: > Ævar Arnfjörð Bjarmason writes: > > > That looks scary, can you please comment out this: > > > > #define SHA1DC_ALLOW_UNALIGNED_ACCESS > > > > In sha1dc/sha1.c and see if that helps, alternatively comment out

Git v2.13.1 SHA1 very broken

ing this, but I'm happy to take pointers / try things out on my box. Cheers, Adam

[PATCH] docs: suggest "Helped-by" rather than "Thanks-to"

;Thanks-to" is not common usage, and should instead be "Helped-by". Signed-off-by: Adam Dinwoodie <a...@dinwoodie.org> --- Documentation/SubmittingPatches | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Documentation/SubmittingPatches b/Documentation/Submi

[PATCH v2] docs: fix formatting and grammar

aren't necessary and not having them keeps the markup simpler. Also include a minor grammar fix suggested by Jeff while we're changing these lines. Signed-off-by: Adam Dinwoodie <a...@dinwoodie.org> Helped-by: Jeff King <p...@peff.net> --- Documentation/git-pull.txt | 4 ++-- 1 fil

Re: [PATCH] docs: fix literal quoted spaces

On Thu, Jun 01, 2017 at 11:06:18AM +0900, Junio C Hamano wrote: > Jeff King <p...@peff.net> writes: > > > On Wed, May 31, 2017 at 04:06:24PM +0100, Adam Dinwoodie wrote: > > > >> Instead, use + to avoid asciidoc's literal passthrough, and encode the > >>

[PATCH] docs: fix literal quoted spaces

text. Instead, use + to avoid asciidoc's literal passthrough, and encode the space as {sp}. In particular, this means asciidoc will correctly detect the end of the monospace formatting, rather than having it continue past the backtick. Signed-off-by: Adam Dinwoodie <a...@dinwoodie.

Re: git v2.13.0-rc0 test failures on cygwin

tial-cache" && # test -S "$HOME/.cache/git/credential/socket" # This specific output came from v2.13.0-rc1 on an up-to-date 64-bit Cygwin installation. I'm happy to experiment with other build options / patches / environments / if that would be useful

Re: CYGWIN git cannot install python packages with pip

gt; executables... Confirmed: the Cygwin project as a general rule doesn't support this sort of mixing of Windows and Cygwin tools. Either use Python and Git packages both provided by Cygwin, or both provided by Windows. Mixing and matching does work sometimes -- as was apparently the case with Cygwin Git v2.8.3-1 -- but it requires care and you're generally on your own with it. Adam

Re: git v2.13.0-rc0 test failures on cygwin

On 23 April 2017 at 15:44, Ramsay Jones wrote: > [Adam, if you are no longer the git package maintainer for cygwin, then > please ignore this email and sorry for the noise!] I am still the Cygwin Git package maintainer; I've been quiet of late because of personal health issues, but I

RFC: new git-transplant subcommand for non-interactively moving commits between branches

On Fri, May 27, 2016 at 03:08:11PM +0100, Adam Spiers wrote: > Hi all, > > I finally got around to implementing a new git subcommand which I've > wanted for quite a while. I've called it git-splice. [snipped] > Next steps, and the future > -- > >

Re: RFC: new git-splice subcommand for non-interactive branch splicing

On Sat, May 28, 2016 at 09:06:59AM +0200, Johannes Schindelin wrote: > Hi Adam, > > please reply-to-all on this list. Sorry, I forgot that was the policy here. Every list and individual has different preferences on whether to Cc: on list mail, so I find it almost impossible to keep tra

Re: RFC: new git-splice subcommand for non-interactive branch splicing

Hi Johannes, Thanks for the quick reply! Responses inline below: On Fri, May 27, 2016 at 05:27:14PM +0200, Johannes Schindelin wrote: > On Fri, 27 May 2016, Adam Spiers wrote: > > > Description > > --- > > > > git-splice(1) non-interactively splices

RFC: new git-splice subcommand for non-interactive branch splicing

# Manually complete tidy-up of those branches git push ... git send-email ... Feedback on any of this is very welcome! Thanks, Adam [0] https://github.com/aspiers/git-deps/#user-content-use-case-2-splitting-a-patch-series This type of dependency could be described as textual or

[PATCH] crlf: Add test showing double warning on commit

Add failing test case showing CRLF -> LF rewrite warnings being printed multiple times when running "git commit". Signed-off-by: Adam Dinwoodie <a...@dinwoodie.org> --- t/t0020-crlf.sh | 16 +++- 1 file changed, 15 insertions(+), 1 deletion(-) diff --git a/t/t002

Re: Bug report: Duplicate CRLF rewrite warnings on commit

On Sat, May 14, 2016 at 07:40:11AM +0200, Torsten Bögershausen wrote: > On 13.05.16 18:43, Junio C Hamano wrote: > > Adam Dinwoodie <a...@dinwoodie.org> writes: > > > >> If you use .gitattributes to enable CRLF->LF rewriting, then commit a > >> file

Bug report: Duplicate CRLF rewrite warnings on commit

ad5, but I couldn't get that to build on my current box), and I'm seeing them on my Cygwin box's build of the current next branch (d10caa2) and on my CentOS box's v2.8.1 release. Example: $ git init Initialized empty Git repository in /home/Adam/test/.git/ $ echo '* text' >.git

[PATCH] git-gui: Remove ancient Cygwin compatibility code

>From 50c9cbb6ce31529316ba004194f63a24ae59b4b0 Mon Sep 17 00:00:00 2001 From: Adam Dinwoodie <a...@dinwoodie.org> Date: Fri, 13 May 2016 11:52:32 +0100 Subject: [PATCH] git-gui: Remove unused Cygwin compatibility code Cygwin-distributed builds of git-gui have patched out the Cygwin

Silent failure to add Windows-style paths in Cygwin Git

shows I get the same behaviour for 'c:\tmp\file', 'c:/tmp/file' and 'subdir\file'. I'm seeing this on v2.8.0; the downstream report says the same behaviour occurs on v2.7.4[0], and I've also seen what appears to be the same behaviour on a v2.0.5 build I produced to check. Adam [0]: https://cygwin.c

Silent failure to add Windows-style paths in Cygwin Git

report says the same behaviour occurs on v2.7.4[0], and I've also seen what appears to be the same behaviour on a v2.0.5 build I produced to check. Adam [0]: https://cygwin.com/ml/cygwin/2016-04/msg00474.html -- To unsubscribe from this list: send the line "unsubscribe git" in t

[PATCH resubmission] config.mak.uname: Cygwin: Use renames for creation

When generating build options for Cygwin, enable OBJECT_CREATION_USES_RENAMES. This is necessary to use Git on Windows shared directories, and is already enabled for the MinGW and plain Windows builds. Reported-by: Peter Rosin <p...@lysator.liu.se> Signed-off-by: Adam Din

Re: Binary grep t7008 known breakage vanished on Cygwin

On Mon, Apr 18, 2016 at 06:08:15PM +0100, Ramsay Jones wrote: > On 18/04/16 16:21, Adam Dinwoodie wrote: > > t7008.12 is marked as an expected failure, but building Git on Cygwin > > including a `make configure && ./configure` step has the test > > unexpected

Binary grep t7008 known breakage vanished on Cygwin

not ideal, but I don't know if there's anything that "ought" to be done to either ensure consistent behaviour across platforms, or to stop marking the test as an expected failure on platforms where it passes. Adam -- To unsubscribe from this list: send the line "unsubscribe git"

Re: [PATCH] commit: --amend -m '' silently fails to wipe message

On Thu, Apr 07, 2016 at 12:42:19AM -0400, Jeff King wrote: > On Wed, Apr 06, 2016 at 06:15:03PM +0100, Adam Dinwoodie wrote: > > `git commit --amend -m ''` seems to be an unambiguous request to blank a > > commit message, but it actually leaves the commit message as-is. That

[PATCH] commit: --amend -m '' silently fails to wipe message

this behaviour. Signed-off-by: Adam Dinwoodie <a...@dinwoodie.org> --- I've had to guess at the correct file to add these tests to; t7500 covers the mainline --allow-empty-message cases, while t7501 doesn't (currently) cover --allow-empty-message but does cover --amend. I've made an educated

Re: When does git check for branch-X being uptodate with origin/branch-X?

bad idea, then good, we don't have to > bother discussing that option. :) Ah, oops! I was meaning more, whether to print the message in the case where the branch was uptodate, but now I appreciate it's cached. Apologies for the confusion. -- Thomas Adam -- To unsubscribe from this list: send t

Re: When does git check for branch-X being uptodate with origin/branch-X?

e was last updated? That is: "branch-X is uptodate with origin/branch-X (as of DD-MM-YY HH:MM:SS)" No one's suggesting that this message is removed, I'm not sure where you got that from? -- Thomas Adam -- To unsubscribe from this list: send the line "unsubscribe git&qu

Re: When does git check for branch-X being uptodate with origin/branch-X?

ifferent problem. -- Thomas Adam -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html

  1   2   3   4   >