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
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 u
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 break
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 submodule-config sub
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
Reviewed-by: Junio C Hamano
Signed-off-by: Ben Boeckel
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
incoming
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
Signed-off-by: Ben Boeckel
---
Documentation/gitattributes.txt | 5
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, effectiv
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
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
---
Documentation/gitattributes.txt | 6 +-
1 file changed, 5 insertions
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 chan
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 G
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" > .gitattri
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 th
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
---
Documentation/git-remote.txt | 10
builtin/remote.c
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
---
Documentation/git-remote.txt | 10
builtin/remote.c
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
---
Documentation/git-remote.txt | 10
builtin/remote.c
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:
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
---
Documentation/git-remote.txt | 10
builtin/remote.c
On Mon, Aug 03, 2015 at 19:38:15 -0400, Eric Sunshine wrote:
> On Mon, Aug 3, 2015 at 5:00 PM, Ben Boeckel wrote:
> > + OPT_BOOL('\0', "push", &push_mode,
> > +N_("query push URLs")),
>
> A bit more e
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
---
Documentation/git-remote.txt | 10
builtin/remote.c
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
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
On Fri, Jul 31, 2015 at 12:02:14 -0700, Junio C Hamano wrote:
> Ben Boeckel 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
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-u
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
---
Documentation/git-ls-remote.txt | 7 ++-
builtin/ls-remote.c | 15 +--
2
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
27 matches
Mail list logo
