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 relat
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" results in "@/b" created, only to
> >> users o
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 cache_entry *create_from_disk(struct
>> ondisk_cac
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 insertion(+)
>>
>> diff --git a/builtin/update-index.c b/builtin/update-index.c
>> i
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 Windows paths and necessarily diff
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 Windows' Access
> > Control Lists are much more fine-grained than t
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
>> ---
>
> This needs a better explanation than
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!
--
To unsubscribe from
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 "tags/foo"
>> instead of just "foo". This i
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 first two components
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.
>
>
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
> the listing modes
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 tests, perhaps to t
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.
>
> Helped-by: Ramsay Jones
>
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 tag" includes onl
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 it a bit
> harder to unders
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.
> contrib/completion/git-completion.bash | 17 ++---
> 1 file changed,
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
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
> Signed-off-by: Karthik Nayak
>
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 reinventing the wheel
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 should treat it as a broken
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:
>
> https://github.com/dscho/git/commit/0b9eb3
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
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" option
>> interacts. It has been tha
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 index and the settings
>
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 the code.
>
> Helped-by: E
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 cache.h
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
possibly
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;
> }
>
> -static void chec
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 they see fit, but
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 mixed anyway, it is *still* o
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
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 force-updated.
>
> Modify the --force-with-lease ref statu
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 char is a colon which means any absolute paths on
>> > Windows confuse the tests that use
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 honest, I cannot imagine anybody usin
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 7431938..a6fff87 100644
> --- a/builtin/update-index.c
> +++
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
> unambiguous manner.
Is it reas
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 cautions of the
>> Github interface?
>
> Neither. It is from the author field as recorded in th
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
> discussion so I can catch
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 use of vsnprintf().
>
> Includ
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 the expectations of the Git userbase.
>
> What
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 catching!
>
> --
> Sebastian Schuberth
--
To un
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
>> state.
>
> Right, I wasn't c
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
> > > by the msys layer and therefore translated to a Windo
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'.
> >
> > This partially fixes t/t9100-git-svn-b
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 global_excludes.
> >
> > Suggested-by: Karsten Blees
> > Signed-off-by:
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 path.
> >
> > Here the trick is to double the slashes.
> >
> >
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)"
> > message when running "git init" (wh
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 suite.
>
> ;-)
>
> It is so
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 a
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" representation in thi
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 seco
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% agree, and I do con
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 available columns to d
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:
> >
> > git
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] ==
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 xdl_orig_copy(
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 xdl
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 "What's
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: Joha
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 respected
61 matches
Mail list logo
