Re: [PATCH v7 01/11] dir: free untracked cache when removing it

On Mon, Jan 25, 2016 at 8:16 PM, Stefan Beller wrote: > On Sun, Jan 24, 2016 at 7:28 AM, Christian Couder > wrote: >> Signed-off-by: Christian Couder >> --- >> builtin/update-index.c | 1 + >> 1 file changed, 1

Re: [PATCH v7 09/11] config: add core.untrackedCache

On Mon, Jan 25, 2016 at 9:47 PM, Junio C Hamano wrote: > Christian Couder writes: > >> diff --git a/read-cache.c b/read-cache.c >> index 5be7cd1..a04ec8c 100644 >> --- a/read-cache.c >> +++ b/read-cache.c >> @@ -1497,10 +1497,23 @@ static struct

Re: [PATCH 2/2] Fix up the arguments for git stash.

Fair enough. I'll re-roll the patches with improved comments, and get these out to the list today. Cheers, Paul Sent from my iPhone > On 26 Jan 2016, at 00:21, Junio C Hamano wrote: > > Paul Wagland writes: > >> Signed-off-by: Paul Wagland

Re: [PATCH 2/2] tag: do not show ambiguous tag names as "tags/foo"

On Tue, Jan 26, 2016 at 5:34 AM, Junio C Hamano wrote: > Jeff King writes: > >> Since b7cc53e9 (tag.c: use 'ref-filter' APIs, 2015-07-11), >> git-tag has started showing tags with ambiguous names (i.e., >> when both "heads/foo" and "tags/foo" exists) as

Re: [PATCH v3 12/15] ref-filter: align: introduce long-form syntax

On Tue, Jan 5, 2016 at 9:03 AM, Karthik Nayak wrote: > Introduce optional prefixes "width=" and "position=" for the align atom > so that the atom can be used as "%(align:width=,position=)". > > Add Documetation and tests for the same. s/Documetation/Documentation/ Thanks!

Re: [PATCH 17/19] mingw: fix git-svn tests that expect chmod to work

Hi Junio, On Sun, 24 Jan 2016, Junio C Hamano wrote: > Johannes Schindelin writes: > > > From: 마누엘 > > > > Some git-svn tests expect that the executable bit of files can be > > toggled. On Windows, this is not possible because

[BUG] typo DWIMery with alias broken (cd to random dir)

Hi there, with current next (989ee58 plus local additions) it seems that typo DWIMery with aliases is broken, see below. It appears that the typo DWIMery is broken only when there is a unique automatic DWIM substitution for a mistyped alias. I haven't bisected yet, but I suspect this to be

Re: [PATCH 13/19] mingw: outsmart MSYS2's path substitution in t1508

Hi Junio, On Mon, 25 Jan 2016, Junio C Hamano wrote: > Eric Sunshine writes: > > > On Sun, Jan 24, 2016 at 9:03 PM, Junio C Hamano wrote: > >> The new test hardcodes and promises such an incompatible behaviour, > >> i.e. a request to create "@//b"

Re: [PATCH 18/19] mingw: skip a couple of git-svn tests that cannot pass on Windows

Hi Junio, On Sun, 24 Jan 2016, Junio C Hamano wrote: > Johannes Schindelin writes: > > > Some of the tests expect that executable bits can be toggled, others > > expect that paths are POSIX paths (but when they come through git.exe, > > they are converted into

Re: [PATCH] travis-ci: run previously failed tests first, then slowest to fastest

On 01/24, Junio C Hamano wrote: > Junio C Hamano writes: > > > Sorry, but I am confused by all of the above. > > > > We write the thing out with write_entry(), possibly applying smudge > > filters and eol conversion to the "git" representation to create the > > "working tree"

Re: Minor bug, git ls-files -o aborts because of broken submodules

On Fri, 22 Jan 2016 17:26:50 +, Jeff King wrote: ... > Here it is. I think this is the right fix, based on the previous attempt > by Andreas and my comments. Sorry for stealing your topic, This seems to keep happening with things I try to patch. :-) > but I hope > the perf numbers in the

Re: [PATCH v2 1/1] merge-file: let conflict markers match end-of-line style of the context

On 25/01/16 06:53, Johannes Schindelin wrote: > Hi Torsten, > > On Sun, 24 Jan 2016, Torsten Bögershausen wrote: > >> On 24.01.16 11:48, Johannes Schindelin wrote: >> (I had the same reasoning about the CRLF in the working tree: >> We don't need to look at core.autocrlf/attributes, so Ack from

Re: [PATCH v3 1/2] merge-file: let conflict markers match end-of-line style of the context

Johannes Schindelin writes: > We actually do not have to look at the *entire* context at all: if the > files are all LF-only, or if they all have CR/LF line endings, it is > sufficient to look at just a *single* line to match that style. And if > the line endings are

Re: [PATCH] tag: do not show ambiguous tag names as "tags/foo"

On Mon, Jan 25, 2016 at 3:31 PM, Jeff King wrote: > On Sun, Jan 24, 2016 at 06:26:50PM -0800, Junio C Hamano wrote: > >> Jeff King writes: >> >> > Yeah, "strip=2" would also get the job done, and extends more naturally >> > to the branch case. >> > >> > To be

Re: GPL v2 authoritative answer on stored code as a derived work

Jonathan Smith writes: > It's pretty clear that code stored in a Git repository isn't > considered a derived work of Git, regardless of whether it is used > in a commercial context or otherwise. > > However, I'm unable to find this stated in any authoritative and >

Re: [PATCH 16/19] mingw: avoid absolute path in t0008

On Mon, Jan 25, 2016 at 4:48 PM, Johannes Schindelin wrote: > Hi Junio, > > On Sun, 24 Jan 2016, Junio C Hamano wrote: > >> Johannes Schindelin writes: >> >> > From: Pat Thoyts >> > >> > The test separator

Re: [PATCH 12/19] mingw: do not use symlinks with SVN in t9100

Hi Junio, On Sun, 24 Jan 2016, Junio C Hamano wrote: > Johannes Schindelin writes: > > > From: Karsten Blees > > > > The SVN library does not seem to support symlinks, even if symlinks are > > enabled in MSYS2 and Git. Use 'cp' instead of 'ln -s'. >

Re: [RFC/PATCH 0/5] [WAS: Submodule Groups] Labels and submodule.autoInitialize

On Sun, Jan 24, 2016 at 11:38 AM, Jens Lehmann wrote: > Disclaimer: Due to my currently very limited Git time budget I only > glanced over the recent discussion and patches. If you think I missed > something already discussed, I'd be happy being pointed to the relevant >

Re: [PATCH v7 01/11] dir: free untracked cache when removing it

On Sun, Jan 24, 2016 at 7:28 AM, Christian Couder wrote: > Signed-off-by: Christian Couder > --- > builtin/update-index.c | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/builtin/update-index.c b/builtin/update-index.c > index

Re: [PATCH 09/19] mingw: accomodate t0060-path-utils for MSYS2

Hi Hannes, On Sun, 24 Jan 2016, Johannes Sixt wrote: > Am 24.01.2016 um 16:44 schrieb Johannes Schindelin: > > On Windows, there are no POSIX paths, only Windows ones (an absolute > > Windows path looks like "C:\Program Files\Git\ReleaseNotes.html", under > > most circumstances, forward slashes

Re: [PATCH 16/19] mingw: avoid absolute path in t0008

Hi Junio, On Sun, 24 Jan 2016, Junio C Hamano wrote: > Johannes Schindelin writes: > > > From: Pat Thoyts > > > > The test separator char is a colon which means any absolute paths on > > Windows confuse the tests that use

Re: [PATCH 01/19] mingw: let's use gettext with MSYS2

Hi Junio, On Sun, 24 Jan 2016, Junio C Hamano wrote: > Johannes Schindelin writes: > > > This solves two problems: > > > > - we now have proper localisation even on Windows > > > > - we sidestep the infamous "BUG: your vsnprintf is broken (returned -1)" > >

Re: [PATCH 13/19] mingw: outsmart MSYS2's path substitution in t1508

Hi Junio, On Mon, 25 Jan 2016, Johannes Schindelin wrote: > On Sun, 24 Jan 2016, Junio C Hamano wrote: > > > Johannes Schindelin writes: > > > > > From: Thomas Braun > > > > > > A string of the form "@/abcd" is considered a file path

Re: [PATCH 00/19] Let Git's tests pass on Windows

Hi Junio, On Sun, 24 Jan 2016, Junio C Hamano wrote: > Johannes Schindelin writes: > > > This is a big milestone. With these modifications, Git's source code > > does not only build without warnings in Git for Windows' SDK, but > > passes the entire regression test

Re: [PATCH] travis-ci: run previously failed tests first, then slowest to fastest

Thomas Gummerer writes: > On 01/24, Junio C Hamano wrote: >> To put it differently, if a blob stored at path has CRLF line >> endings and .gitattributes is changed after the fact to say that it >> must have LF line endings, we should treat it as a broken transitory >>

Re: [PATCH 13/19] mingw: outsmart MSYS2's path substitution in t1508

Hi Junio, On Sun, 24 Jan 2016, Junio C Hamano wrote: > Johannes Schindelin writes: > > > From: Thomas Braun > > > > A string of the form "@/abcd" is considered a file path > > by the msys layer and therefore translated to a Windows

Re: [PATCH 13/19] mingw: outsmart MSYS2's path substitution in t1508

Eric Sunshine writes: > On Sun, Jan 24, 2016 at 9:03 PM, Junio C Hamano wrote: >> The new test hardcodes and promises such an incompatible behaviour, >> i.e. a request to create "@//b" results in "@/b" created, only to >> users on MINGW, fracturing

Re: [PATCH 01/19] mingw: let's use gettext with MSYS2

Johannes Schindelin writes: >> > - we sidestep the infamous "BUG: your vsnprintf is broken (returned -1)" >> > message when running "git init" (which otherwise prevents the entire >> > test suite from running) >> >> It is unclear to me how gettext is related to

Re: [PATCH 3/5] submodule-config: keep labels around

On Sun, Jan 24, 2016 at 10:06 AM, Sebastian Schuberth wrote: > On Sat, Jan 23, 2016 at 1:31 AM, Stefan Beller wrote: > >> We need the submodule groups in a later patch. > > The commit message should now say "labels", too, I guess. Sure, thanks for

Re: [PATCH v3 10/15] ref-filter: introduce parse_align_position()

On Tue, Jan 5, 2016 at 3:03 AM, Karthik Nayak wrote: > From align_atom_parser() form parse_align_position() which given a > string would give us the alignment position. This is a preparatory > patch as to introduce prefixes for the %(align) atom and avoid > redundancy in

Re: [PATCH v7 09/11] config: add core.untrackedCache

Christian Couder writes: > diff --git a/read-cache.c b/read-cache.c > index 5be7cd1..a04ec8c 100644 > --- a/read-cache.c > +++ b/read-cache.c > @@ -1497,10 +1497,23 @@ static struct cache_entry *create_from_disk(struct > ondisk_cache_entry *ondisk, > return ce;

[PATCH] mingw: avoid linking to the C library's isalpha()

The implementation of mingw_skip_dos_drive_prefix() calls isalpha() via has_dos_drive_prefix(). Since the definition occurs long before isalpha() is defined in git-compat-util.h, my build environment reports: CC alloc.o In file included from git-compat-util.h:186, from

Re: [PATCH] travis-ci: run previously failed tests first, then slowest to fastest

Junio C Hamano writes: > I am not saying that we shouldn't have support for users to fix > their repository and get out of this transititory broken state. A > recent work by Torsten Bögershausen to have ls-files report the end > of line convention used in the blob in the

[RFC] tag-ref and tag object binding

Hello everyone. I've done some further research on the security properties of git metadata and I think I've identified something that might be worth discussing. In this case, The issue is related to the refs that point to git tag objects. Specifically, the "loose" nature of tag refs might

Re: [PATCH] mingw: avoid linking to the C library's isalpha()

Thanks. -- 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

Re: [PATCH 16/19] mingw: avoid absolute path in t0008

Johannes Schindelin writes: >> Is the fact that $global_excludes is specified using an absolute >> path significant to the correctness of this test script? > > Apparently not. So I followed your suggestion and made this independent > of the OS: > >

Re: [PATCH v3 12/15] ref-filter: align: introduce long-form syntax

On Tue, Jan 5, 2016 at 3:03 AM, Karthik Nayak wrote: > Introduce optional prefixes "width=" and "position=" for the align atom > so that the atom can be used as "%(align:width=,position=)". > > Add Documetation and tests for the same. > > Helped-by: Eric Sunshine

Re: [PATCH] travis-ci: run previously failed tests first, then slowest to fastest

On 01/25, Junio C Hamano wrote: > Thomas Gummerer writes: > > > On 01/24, Junio C Hamano wrote: > >> To put it differently, if a blob stored at path has CRLF line > >> endings and .gitattributes is changed after the fact to say that it > >> must have LF line endings, we

Re: [PATCH 2/2] Fix up the arguments for git stash.

Paul Wagland writes: > Signed-off-by: Paul Wagland > --- This needs a better explanation than just "Fix up" in the title. What is broken in the current behaviour and what is the more desired behaviour? Thanks. >

Re: What's cooking in git.git (Jan 2016, #02; Mon, 11)

Duy Nguyen writes: > On Tue, Jan 12, 2016 at 6:45 AM, Junio C Hamano wrote: >> * jk/graph-format-padding (2015-09-14) 1 commit >> - pretty: pass graph width to pretty formatting for use in '%>|(N)' >> >> Redefine the way '%>|(N)' padding and the "--graph"

Re: [PATCHv3 0/2] Port `git submodule init` from shell to C

Stefan Beller writes: > This applies on top of sb/submodule-parallel-update, replacing > sb/submodule-init. > > Fixes: > > * a more faithful conversion by staying on stdout (We switch to stderr later >in another series) > * use the existing find_last_dir_sep instead of

Re: PATCH 1/2] Update the flags for git show-branch

Thanks. I'll retitle this to completion: complete show-branch "--date-order" while queuing. -- 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

Re: [PATCH v3 12/15] ref-filter: align: introduce long-form syntax

Eric Sunshine writes: >> + git for-each-ref --format="|%(align:$option)refname is >> %(refname)%(end)|%(refname)" >actual && > > This is not wrong, per se, but referencing $option inside the > non-interpolating single-quote context of the test body makes

Re: [PATCH 06/19] mingw: try to delete target directory before renaming

Johannes Schindelin writes: > Hi Philip, > > On Sun, 24 Jan 2016, Philip Oakley wrote: > >> From: "Johannes Schindelin" >> >From: 마누엘 >> >> Is this Nalla's preferred email, or just a carry over from

Re: [PATCH] push --force-with-lease: Fix ref status reporting

Andrew Wheeler writes: > From: Andrew Wheeler > > The --force--with-lease push option leads to less > detailed status information than --force. In particular, > the output indicates that a reference was fast-forwarded, > even when it was

Re: [PATCH] tag: do not show ambiguous tag names as "tags/foo"

Jeff King writes: > I'm not sure "remove-standard-prefix" doesn't open its own questions. > Like "what are the standard prefixes?". It is easy to define, no? This is invented for the internal use of the listing modes of "tag" and "branch", so the users are welcome to use it if

Re: [PATCH 2/2] tag: do not show ambiguous tag names as "tags/foo"

Jeff King writes: > Since b7cc53e9 (tag.c: use 'ref-filter' APIs, 2015-07-11), > git-tag has started showing tags with ambiguous names (i.e., > when both "heads/foo" and "tags/foo" exists) as "tags/foo" > instead of just "foo". This is both: > > - pointless; the output of "git

Re: [PATCH v3 13/15] ref-filter: introduce remote_ref_atom_parser()

On Tue, Jan 5, 2016 at 3:03 AM, Karthik Nayak wrote: > Introduce remote_ref_atom_parser() which will parse the '%(upstream)' > and '%(push)' atoms and store information into the 'used_atom' > structure based on the modifiers used along with the corresponding > atom. > >

[PATCH v3 0/2] Let merge-file write out conflict markers with correct EOLs

The original patch was sent by Beat Bolli in http://thread.gmane.org/gmane.comp.version-control.git/281600 My suggestion to extend it to respect gitattributes led to changes that broke the original patch. And they were misguided to begin with (see below). Since there have been a couple of

[PATCH v3 2/2] merge-file: ensure that conflict sections match eol style

In the previous patch, we made sure that the conflict markers themselves match the end-of-line style of the input files. However, this still left out the conflicting text itself: if it lacks a trailing newline, we add one, and should add a carriage return when appropriate, too. Signed-off-by:

[PATCH v3 1/2] merge-file: let conflict markers match end-of-line style of the context

When merging files with CR/LF line endings, the conflict markers should match those, lest the output file has mixed line endings. This is particularly of interest on Windows, where some editors get *really* confused by mixed line endings. The original version of this patch by Beat Bolli

Re: [PATCH v3 1/2] merge-file: let conflict markers match end-of-line style of the context

On 25.01.16 09:07, Johannes Schindelin wrote: [] > diff --git a/xdiff/xmerge.c b/xdiff/xmerge.c > index 625198e..c852acc 100644 > --- a/xdiff/xmerge.c > +++ b/xdiff/xmerge.c > @@ -143,6 +143,35 @@ static int xdl_orig_copy(xdfenv_t *xe, int i, int count, > int add_nl, char *dest) > return

Re: [PATCH v3 2/2] merge-file: ensure that conflict sections match eol style

Hi, On Mon, 25 Jan 2016, Johannes Schindelin wrote: > diff --git a/xdiff/xmerge.c b/xdiff/xmerge.c > index c852acc..d98f430 100644 > --- a/xdiff/xmerge.c > +++ b/xdiff/xmerge.c > @@ -172,15 +178,8 @@ static int is_eol_crlf(xdfile_t *file, int i) > file->recs[i - 1]->ptr[size - 2]

Re: [PATCH] tag: do not show ambiguous tag names as "tags/foo"

On Sun, Jan 24, 2016 at 06:39:05PM -0500, Eric Sunshine wrote: > > Yeah, "strip=2" would also get the job done, and extends more naturally > > to the branch case. > > > > To be honest, I cannot imagine anybody using anything _but_ strip=2, but > > maybe there are special cases, like: > > > >

Re: [PATCH] tag: do not show ambiguous tag names as "tags/foo"

On Sun, Jan 24, 2016 at 06:26:50PM -0800, Junio C Hamano wrote: > Jeff King writes: > > > Yeah, "strip=2" would also get the job done, and extends more naturally > > to the branch case. > > > > To be honest, I cannot imagine anybody using anything _but_ strip=2... > > I 100%

Re: [PATCH v3 1/2] merge-file: let conflict markers match end-of-line style of the context

Hi Torsten, On Mon, 25 Jan 2016, Torsten Bögershausen wrote: > On 25.01.16 09:07, Johannes Schindelin wrote: > [] > > diff --git a/xdiff/xmerge.c b/xdiff/xmerge.c > > index 625198e..c852acc 100644 > > --- a/xdiff/xmerge.c > > +++ b/xdiff/xmerge.c > > @@ -143,6 +143,35 @@ static int

Re: What's cooking in git.git (Jan 2016, #02; Mon, 11)

On Tue, Jan 12, 2016 at 6:45 AM, Junio C Hamano wrote: > * jk/graph-format-padding (2015-09-14) 1 commit > - pretty: pass graph width to pretty formatting for use in '%>|(N)' > > Redefine the way '%>|(N)' padding and the "--graph" option > interacts. It has been that the

Re: [PATCH] push --force-with-lease: Fix ref status reporting

On Mon, Jan 25, 2016 at 1:37 PM, Junio C Hamano wrote: > >* passing the --force argument > > + * > > This new blank line is probably unwanted. > Do we want to make sure that other people will not break this fix in > the future by adding a few

Re: [PATCH] tag: do not show ambiguous tag names as "tags/foo"

On Mon, Jan 25, 2016 at 12:21:21PM -0800, Junio C Hamano wrote: > Jeff King writes: > > > I'm not sure "remove-standard-prefix" doesn't open its own questions. > > Like "what are the standard prefixes?". > > It is easy to define, no? This is invented for the internal use of >

Re: [PATCH] tag: do not show ambiguous tag names as "tags/foo"

On Mon, Jan 25, 2016 at 09:37:53PM -0500, Jeff King wrote: > So what about this: > > 1. Implement ":strip=" and use it from git-tag. > > 2. Have it error out on a ref with fewer than components. This > should be impossible to trigger via "git-tag" with the default > format. > >

Re: [PATCH] tag: do not show ambiguous tag names as "tags/foo"

Jeff King writes: > What does this do: > > git for-each-ref --format='%(refname:remove-standard-prefix)' > > ? > > Is there no standard prefix, because we are not in branch/tag? Does it > remove well-known prefixes like "refs/heads/", "refs/tags/", etc? Does > it remove the