Re: [PATCH] diff-tree: read the index so attribute checks work in bare repositories

On Tue, Dec 05, 2017 at 14:13:37 -0800, Brandon Williams wrote: > This patch should fix the regression. Let me know if it doesn't solve the > issue and I'll investigate some more. Our test suite passes again. Thanks! Acked-by: Ben Boeckel <ben.boec...@kitware.com> --Ben

Re: gitattributes not read for diff-tree anymore in 2.15?

On Tue, Dec 05, 2017 at 10:16:45 -0800, Brandon Williams wrote: > Perfect, thanks! OK, attached is a shell script which recreates the issue. I haven't been able to get it to happen without the `GIT_WORK_TREE` and `GIT_INDEX_FILE` setup involved, so that seems to be important. I reran the bisect

Re: gitattributes not read for diff-tree anymore in 2.15?

On Mon, Dec 04, 2017 at 15:03:55 -0800, Brandon Williams wrote: > Reading the attributes files should be done regardless if the gitmodules > file is read. The gitmodules file should only come into play if you are > dealing with submodules. Yeah, it doesn't seem to make sense why this commit

gitattributes not read for diff-tree anymore in 2.15?

Hi, I've bisected a failure in our test suite to this commit: commit 557a5998df19faf8641acfc5b6b1c3c2ba64dca9 (HEAD, refs/bisect/bad) Author: Brandon Williams Date: Thu Aug 3 11:20:00 2017 -0700 submodule: remove gitmodules_config Now that the

[PATCH v3] Documentation: mention that `eol` can change the dirty status of paths

; Signed-off-by: Ben Boeckel <maths...@gmail.com> --- Documentation/gitattributes.txt | 5 - 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/Documentation/gitattributes.txt b/Documentation/gitattributes.txt index c4f2be2..4c68bc1 100644 --- a/Documentation/gitattributes.txt +

Re: [PATCH] Documentation: mention that `eol` can change the dirty status of paths

On Wed, Aug 30, 2017 at 14:31:30 -0700, Junio C Hamano wrote: > Is this "always makes them dirty" or "may make them dirty depending > on the situation"? > > If the latter, I'd prefer to see s/makes/may make/ here. Yes, a coworker reported that some files slipped through this. New patch

[PATCH v2] Documentation: mention that `eol` can change the dirty status of paths

When setting the `eol` attribute, paths can change their dirty status without any change in the working directory. This can cause confusion and should at least be mentioned with a remedy. Reviewed-by: Torsten Bögershausen <tbo...@web.de> Signed-off-by: Ben Boeckel <maths...@

Re: [PATCH] Documentation: mention that `eol` can change the dirty status of paths

On Thu, Aug 24, 2017 at 07:50:54 +0200, Torsten Bögershausen wrote: > This attribute sets a specific line-ending style to be used in the > working directory. It enables end-of-line conversion without any > -content checks, effectively setting the `text` attribute. > +content checks,

Re: [PATCH] Documentation: mention that `eol` can change the dirty status of paths

On Wed, Aug 23, 2017 at 17:17:41 -0400, Ben Boeckel wrote: > diff --git a/Documentation/gitattributes.txt b/Documentation/gitattributes.txt > index c4f2be2..3044b71 100644 > --- a/Documentation/gitattributes.txt > +++ b/Documentation/gitattributes.txt > @@ -151,7 +151,11

[PATCH] Documentation: mention that `eol` can change the dirty status of paths

When setting the `eol` attribute, paths can change their dirty status without any change in the working directory. This can cause confusion and should at least be mentioned with a remedy. Signed-off-by: Ben Boeckel <maths...@gmail.com> --- Documentation/gitattributes.txt | 6 +-

Re: Cannot checkout after setting the eol attribute

e is something in the documentation, that can be > improved, please let us know. I'll have a patch up shortly. > On Tue, Aug 22, 2017 at 03:44:41PM -0400, Ben Boeckel wrote: > > The fact that plumbing is necessary to dig yourself out of a hole of the > > `eol` attribute changes points

Re: Cannot checkout after setting the eol attribute

On Tue, Aug 22, 2017 at 21:13:18 +0200, Torsten Bögershausen wrote: > When you set the text attribute (in your case "eol=crlf" implies text) > then the file(s) -must- be nomalized and commited so that they have LF > in the repo (technically speaking the index) This seems like a special case that

Cannot checkout after setting the eol attribute

Hi, I specified the `eol` attribute on some files recently and the behavior of Git is very strange. Here is the set of commands to set up the repository used for the discussion: git init echo $'dos\r' > dos git add dos git commit -m "dos newlines" echo "dos -crlf" >

git bisect "commits left" miscount

Hi, When bisecting given a set of paths, git counts the number of remaining commits improperly. Here's example output (based in the git.git repository): % git bisect start -- sha1_file.c % git bisect good v2.10.0 % git bisect bad v2.10.3 Bisecting: 1 revision left to test after

[PATCH v6] remote: add get-url subcommand

Expanding `insteadOf` is a part of ls-remote --url and there is no way to expand `pushInsteadOf` as well. Add a get-url subcommand to be able to query both as well as a way to get all configured urls. Signed-off-by: Ben Boeckel <maths...@gmail.com> --- Documentation/git-remote.tx

[PATCH v5] remote: add get-url subcommand

Expanding `insteadOf` is a part of ls-remote --url and there is no way to expand `pushInsteadOf` as well. Add a get-url subcommand to be able to query both as well as a way to get all configured urls. Signed-off-by: Ben Boeckel <maths...@gmail.com> --- Documentation/git-remote.tx

[PATCH v4] remote: add get-url subcommand

Expanding `insteadOf` is a part of ls-remote --url and there is no way to expand `pushInsteadOf` as well. Add a get-url subcommand to be able to query both as well as a way to get all configured urls. Signed-off-by: Ben Boeckel <maths...@gmail.com> --- Documentation/git-remote.tx

Re: [PATCH v3] remote: add get-url subcommand

On Wed, Aug 05, 2015 at 13:34:18 -0700, Junio C Hamano wrote: Changes to these two files look reasonable. Don't you want to protect this feature from future breakage by others by adding a couple of tests, though, to t/t5505? Thanks, I've done so locally. It actually brings up this case:

[PATCH v3] remote: add get-url subcommand

Expanding `insteadOf` is a part of ls-remote --url and there is no way to expand `pushInsteadOf` as well. Add a get-url subcommand to be able to query both as well as a way to get all configured urls. Signed-off-by: Ben Boeckel maths...@gmail.com --- Documentation/git-remote.txt | 10

Re: [PATCH v2] remote: add get-url subcommand

On Mon, Aug 03, 2015 at 19:38:15 -0400, Eric Sunshine wrote: On Mon, Aug 3, 2015 at 5:00 PM, Ben Boeckel maths...@gmail.com wrote: + OPT_BOOL('\0', push, push_mode, +N_(query push URLs)), A bit more explanatory: query push URLs rather than fetch

[PATCH v2] add git-url subcommand

Implements a get-url subcommand to git-remote which allows for querying the URLs for a remote while expanding insteadOf and pushInsteadOf. --Ben Ben Boeckel (1): remote: add get-url subcommand Documentation/git-remote.txt | 10 builtin/remote.c | 55

[PATCH v2] remote: add get-url subcommand

Expanding `insteadOf` is a part of ls-remote --url and there is no way to expand `pushInsteadOf` as well. Add a get-url subcommand to be able to query both as well as a way to get all configured urls. Signed-off-by: Ben Boeckel maths...@gmail.com --- Documentation/git-remote.txt | 10

[PATCH] ls-remote: add --get-push-url option

With pushInsteadOf and triangle workflows, a flag to have git fully expand the push URL is also useful since it can be very different from the --get-url output. Signed-off-by: Ben Boeckel maths...@gmail.com --- Documentation/git-ls-remote.txt | 7 ++- builtin/ls-remote.c | 15

[PATCH] add ls-remote --get-push-url option

Not sure if it would be better to make a new variable or to reuse the existing one. I'm reusing it currently because it makes it easier to ensure they are mutually exclusive. Please keep me CC'd to the list; I'm not subscribed. Thanks, --Ben Ben Boeckel (1): ls-remote: add --get-push-url

Re: [PATCH] add ls-remote --get-push-url option

On Fri, Jul 31, 2015 at 12:02:14 -0700, Junio C Hamano wrote: Ben Boeckel maths...@gmail.com writes: With some sed, yes, but then so would `git remote show` just as useful too (and in that case, why does --get-url exist either? comes to mind). Either carelessness let it slip

Re: [PATCH] add ls-remote --get-push-url option

On Fri, Jul 31, 2015 at 12:16:46 -0700, Junio C Hamano wrote: Or even git remote get url [$there], git remote get push-url [$there]. Looking at `git remote`'s existing subcommands, consistency there would be something like: git remote get-url $there git remote get-url --push $there The

Re: [PATCH] add ls-remote --get-push-url option

On Fri, Jul 31, 2015 at 11:40:12 -0700, Junio C Hamano wrote: Probably get-url makes (some) sense because ls-remote is a fetch that does not actually fetch anything. But get-push-url to ls-remote makes _no_ sense whatsoever. ls-remote and fetch do not have to know or care about push-url;