* Re: [PATCH v1 1/1] convert: git cherry-pick -Xrenormalize did not work
From: Torsten Bögershausen @ 2016-11-29 20:16 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, eevee.reply
In-Reply-To: <xmqq7f7mgmb9.fsf@gitster.mtv.corp.google.com>
On Tue, Nov 29, 2016 at 10:42:18AM -0800, Junio C Hamano wrote:
> tboegi@web.de writes:
>
> > From: Torsten Bögershausen <tboegi@web.de>
> >
> > Working with a repo that used to be all CRLF. At some point it
> > was changed to all LF, with `text=auto` in .gitattributes.
> > Trying to cherry-pick a commit from before the switchover fails:
> >
> > $ git cherry-pick -Xrenormalize <commit>
> > fatal: CRLF would be replaced by LF in [path]
>
> OK. That's a very clear description of the symptom that can be
> observed from the surface.
>
> > Whenever crlf_action is CRLF_TEXT_XXX and not CRLF_AUTO_XXX,
> > SAFE_CRLF_RENORMALIZE must be turned into CRLF_SAFE_FALSE.
>
> Aside from needing s/CRLF_SAFE/SAFE_CRLF/, this however lacks
> "Otherwise, because of X and Y, Z ends up doing W" to explain
> the "must be" part. Care to explain it a bit more?
Thanks for the review - how about this:
convert: git cherry-pick -Xrenormalize did not work
Working with a repo that used to be all CRLF. At some point it
was changed to all LF, with `text=auto` in .gitattributes.
Trying to cherry-pick a commit from before the switchover fails:
$ git cherry-pick -Xrenormalize <commit>
fatal: CRLF would be replaced by LF in [path]
Commit 65237284 "unify the "auto" handling of CRLF" introduced
a regression:
Whenever crlf_action is CRLF_TEXT_XXX and not CRLF_AUTO_XXX,
SAFE_CRLF_RENORMALIZE was feed into check_safe_crlf().
This is wrong because here everything else than SAFE_CRLF_WARN is
treated as SAFE_CRLF_FAIL.
Solution: Turn SAFE_CRLF_RENORMALIZE into SAFE_CRLF_FALSE before
calling check_safe_crlf().
Reported-by: Eevee (Lexy Munroe) <eevee@veekun.com>
Signed-off-by: Torsten Bögershausen <tboegi@web.de>
^ permalink raw reply
* Re: gitconfig includes
From: Eli Barzilay @ 2016-11-29 19:53 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <xmqq7f7mf4rs.fsf@gitster.mtv.corp.google.com>
On Tue, Nov 29, 2016 at 2:46 PM, Junio C Hamano <gitster@pobox.com> wrote:
> Eli Barzilay <eli@barzilay.org> writes:
>
>> So this is at least a documentation issue,...
>
> This already is documented, and I think it is clear enough.
>
> --[no-]includes
> Respect include.* directives in config files when
> looking up values. Defaults to off when a specific
> file is given (e.g., using --file, --global, etc)
> and on when searching all config files.
Yeah, that's clear, sorry for not checking the latest.
[I'd expect/wish it to be on by default though... Any reason for the
default being off in these cases?]
--
((x=>x(x))(x=>x(x))) Eli Barzilay:
http://barzilay.org/ Maze is Life!
^ permalink raw reply
* Re: gitconfig includes
From: Junio C Hamano @ 2016-11-29 19:46 UTC (permalink / raw)
To: Eli Barzilay; +Cc: git
In-Reply-To: <CALO-gutW80d6RLdXAtYA2m2GWOchAjNNPy3YCsr31_fCss512g@mail.gmail.com>
Eli Barzilay <eli@barzilay.org> writes:
> So this is at least a documentation issue,...
This already is documented, and I think it is clear enough.
--[no-]includes
Respect include.* directives in config files when
looking up values. Defaults to off when a
specific file is given (e.g., using --file,
--global, etc) and on when searching all config
files.
^ permalink raw reply
* gitconfig includes
From: Eli Barzilay @ 2016-11-29 19:40 UTC (permalink / raw)
To: git
I just noticed something weird: if I have this in my ~/.gitconfig:
[x]
x = global
[include]
path = .gitconfig.more
and .gitconfig.more has
[x]
x = more
then I get:
1. git config x.x => more
2. git config --global x.x => global
3. git config --global --includes x.x => more
The first works as I expected. The second surprised me, since I took
"--global" to mean "the global file and stuff it includes" (that's my
understanding of the description of `include`). The third is fine, but
it made me even more surprised at the second, especially since the man
blurb on --includes says "Defaults to on."...
So this is at least a documentation issue, though I hope that #2 is a
bug and that it *should* return "more"...?
--
((x=>x(x))(x=>x(x))) Eli Barzilay:
http://barzilay.org/ Maze is Life!
^ permalink raw reply
* Re: [GIT PULL] l10n updates for 2.11.0 round 3 with ru and ca translations
From: Junio C Hamano @ 2016-11-29 19:36 UTC (permalink / raw)
To: Jiang Xin; +Cc: Dimitriy Ryazantcev, Alex Henrie, Git List
In-Reply-To: <CANYiYbHYaOUwJo_8Vc4vAYatC+Xu09fWLw5q+T7W_7_xwuD7Nw@mail.gmail.com>
Jiang Xin <worldhello.net@gmail.com> writes:
> Final l10n updates for this release cycle, please pull.
Thanks!
^ permalink raw reply
* Re: What's cooking in git.git (Nov 2016, #06; Mon, 28)
From: Stefan Beller @ 2016-11-29 19:29 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git@vger.kernel.org
In-Reply-To: <xmqqk2bmf5pv.fsf@gitster.mtv.corp.google.com>
On Tue, Nov 29, 2016 at 11:26 AM, Junio C Hamano <gitster@pobox.com> wrote:
>>> Need to read it over again, deal with SQUASH, and may ask for a
>>> reroll.
>>
>> Ok, I looked over it again and I may see some issues:
>
> OK then I'll procrastinate on this.
This is not what I had in mind when typing out the issues.
I'd rather wanted to hear "these issues are all non-issues,
your design is actually correct as a first solution". ;)
^ permalink raw reply
* Re: [PATCH v2 00/11] git worktree (re)move
From: Junio C Hamano @ 2016-11-29 19:28 UTC (permalink / raw)
To: Duy Nguyen; +Cc: Johannes Schindelin, Git Mailing List, Johannes Sixt
In-Reply-To: <20161129135646.GA19797@ash>
Duy Nguyen <pclouds@gmail.com> writes:
> Another way, as pointed out by j6t, is go with "move within filesystem
> only", at least at the first step. Which is probably a good idea
> anyway so we can concentrate on git-specific stuff before going to
> minor and complicated copy/move details.
Yup, that is a very sensible approach.
^ permalink raw reply
* Re: What's cooking in git.git (Nov 2016, #06; Mon, 28)
From: Junio C Hamano @ 2016-11-29 19:26 UTC (permalink / raw)
To: Stefan Beller; +Cc: git@vger.kernel.org
In-Reply-To: <CAGZ79kZbBufaKoJyTQa_DseE5GofMAwb=ujtEYn35r9VEwdJ2g@mail.gmail.com>
Stefan Beller <sbeller@google.com> writes:
> On Mon, Nov 28, 2016 at 4:15 PM, Junio C Hamano <gitster@pobox.com> wrote:
>>
>> * sb/push-make-submodule-check-the-default (2016-10-10) 2 commits
>> - push: change submodule default to check when submodules exist
>> - submodule add: extend force flag to add existing repos
>>
>> Turn the default of "push.recurseSubmodules" to "check" when
>> submodules seem to be in use.
>>
>> Need to rebase on hv/submodule-not-yet-pushed-fix and then consider
>> merging to 'next'.
>
> The rebase is without merge conflicts, so I assume there is no
> work needed by me here.
Correct.
>> * sb/submodule-intern-gitdir (2016-11-22) 5 commits
>> - SQUASH
>> - submodule: add embed-git-dir function
>> - test-lib-functions.sh: teach test_commit -C <dir>
>> - submodule helper: support super prefix
>> - submodule: use absolute path for computing relative path connecting
>>
>> A new submodule helper "git submodule embedgitdirs" to make it
>> easier to move embedded .git/ directory for submodules in a
>> superproject to .git/modules/ (and point the latter with the former
>> that is turned into a "gitdir:" file) has been added.
>>
>> Need to read it over again, deal with SQUASH, and may ask for a
>> reroll.
>
> Ok, I looked over it again and I may see some issues:
OK then I'll procrastinate on this.
> That slipped by me. Will review.
>
>> * sb/attr (2016-11-11) 35 commits
>> - completion: clone can initialize specific submodules
>> - clone: add --init-submodule=<pathspec> switch
>> - submodule update: add `--init-default-path` switch
>
> I may end up rerolling these top three patches as its own series
> again without the underlying pathspec support.
>
> I will investigate if we need the mutex at all for the attribute
> code or if we can initialize all attrs (in the pathspecs) before the
> threaded preload_index takes place. That sounds cleaner to me,
> but I do not prioritize it as high.
OK.
Thanks.
^ permalink raw reply
* Re: What's cooking in git.git (Nov 2016, #06; Mon, 28)
From: Stefan Beller @ 2016-11-29 19:21 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git@vger.kernel.org
In-Reply-To: <xmqqk2bngn03.fsf@gitster.mtv.corp.google.com>
On Mon, Nov 28, 2016 at 4:15 PM, Junio C Hamano <gitster@pobox.com> wrote:
>
> * sb/push-make-submodule-check-the-default (2016-10-10) 2 commits
> - push: change submodule default to check when submodules exist
> - submodule add: extend force flag to add existing repos
>
> Turn the default of "push.recurseSubmodules" to "check" when
> submodules seem to be in use.
>
> Need to rebase on hv/submodule-not-yet-pushed-fix and then consider
> merging to 'next'.
The rebase is without merge conflicts, so I assume there is no
work needed by me here.
> * sb/submodule-intern-gitdir (2016-11-22) 5 commits
> - SQUASH
> - submodule: add embed-git-dir function
> - test-lib-functions.sh: teach test_commit -C <dir>
> - submodule helper: support super prefix
> - submodule: use absolute path for computing relative path connecting
>
> A new submodule helper "git submodule embedgitdirs" to make it
> easier to move embedded .git/ directory for submodules in a
> superproject to .git/modules/ (and point the latter with the former
> that is turned into a "gitdir:" file) has been added.
>
> Need to read it over again, deal with SQUASH, and may ask for a
> reroll.
Ok, I looked over it again and I may see some issues:
* it is applicable to all submodules recursive by default, i.e. really
"all submodules reachable from this superproject". I anticipate
this to be the most relevant use case (i.e. as a preparatory step
for having e.g. git-checkout work), but there are no other commands
yet that are recursing into submodules recursively by default. So
a discussion/disagreement on the default may come up.
(We also may want to see a --[no-]recursive flag)
* The output is okay-ish, but could be better as it is a mix of
relative and absolute path:
Migrating git directory of plugins/cookbook from
'/absolute/path/here/gerrit/plugins/cookbook/.git' to
'/absolute/path/here/gerrit/.git/modules/plugins/cookbook/'
On the other hand this seems like what the user may need,
as it is the maximum for trouble shooting
* As this is a subcommand we do not need to add it to command-list.txt
However we may want to discuss if some submodule commands are
porcelain (all except for the new embedgitdirs?) and if this new command
is plumbing. We could also argue the submodule--helper (which needs
listing in command-list.txt as a plumbing command?) is the plumbing
equivalent and the "submodule embedgitdirs" is the porcelain.
* any other part where we need to add documentation for a new command?
FYI: I have a series cooking internally that adds a new page in
Documentation/submodules that introduces the concept of submodules,
which then allows Documentation/git-submodule.txt to be focused on the
actual command and its options.
>
> * dt/empty-submodule-in-merge (2016-11-17) 1 commit
> - submodules: allow empty working-tree dirs in merge/cherry-pick
>
> Waiting for review
That slipped by me. Will review.
> * sb/attr (2016-11-11) 35 commits
> - completion: clone can initialize specific submodules
> - clone: add --init-submodule=<pathspec> switch
> - submodule update: add `--init-default-path` switch
I may end up rerolling these top three patches as its own series
again without the underlying pathspec support.
I will investigate if we need the mutex at all for the attribute
code or if we can initialize all attrs (in the pathspecs) before the
threaded preload_index takes place. That sounds cleaner to me,
but I do not prioritize it as high.
> Waiting for review.
There was some review by Duy and Brandon, I may reroll with just their
issues addressed.
Thanks,
Stefan
^ permalink raw reply
* Re: [PATCH/RFC v1 1/1] New way to normalize the line endings
From: Junio C Hamano @ 2016-11-29 19:15 UTC (permalink / raw)
To: tboegi; +Cc: git
In-Reply-To: <20161127162245.11757-1-tboegi@web.de>
tboegi@web.de writes:
> From: Torsten Bögershausen <tboegi@web.de>
>
> Sincec commit 6523728499e7 'convert: unify the "auto" handling of CRLF'
> the normalization instruction in Documentation/gitattributes.txt
> doesn't work any more.
Aside from s/Sincec/Since/, the above made it sound as if the named
commit was a regression that wants to be reverted, at least to my
first reading. I think you want to be a bit more clear that we
updated the world order and made it a better place with that commit,
and examples in the doc need to be updated. To convince readers
that, I think you would need to explain things like why the old way
illustrated in the example was bad, and why the new way is better.
> Update the documentation and add a test case.
>
> Reported by Kristian Adrup
> https://github.com/git-for-windows/git/issues/954
>
> Signed-off-by: Torsten Bögershausen <tboegi@web.de>
> ---
> Documentation/gitattributes.txt | 7 +++----
> t/t0025-crlf-auto.sh | 29 +++++++++++++++++++++++++++++
> 2 files changed, 32 insertions(+), 4 deletions(-)
>
> diff --git a/Documentation/gitattributes.txt b/Documentation/gitattributes.txt
> index 976243a..1f7529a 100644
> --- a/Documentation/gitattributes.txt
> +++ b/Documentation/gitattributes.txt
> @@ -227,11 +227,10 @@ From a clean working directory:
>
> -------------------------------------------------
> $ echo "* text=auto" >.gitattributes
> -$ rm .git/index # Remove the index to force Git to
> -$ git reset # re-scan the working directory
> +$ git ls-files --eol | egrep "i/(crlf|mixed)" # find not normalized files
Does this step help anything? I do not see anything in the later
steps that the user uses the finding from the output of this step to
affect the end result.
> +$ rm .git/index # Remove the index to re-scan the working directory
> +$ git add .
"A clean working directory" usually means all paths in the index
match what's in the working tree but this requires a bit more than
that, as this step ends up adding untracked and unignored paths.
> $ git status # Show files that will be normalized
> -$ git add -u
> -$ git add .gitattributes
> $ git commit -m "Introduce end-of-line normalization"
> -------------------------------------------------
>
> diff --git a/t/t0025-crlf-auto.sh b/t/t0025-crlf-auto.sh
> index d0bee08..4ad4d02 100755
> --- a/t/t0025-crlf-auto.sh
> +++ b/t/t0025-crlf-auto.sh
> @@ -152,4 +152,33 @@ test_expect_success 'eol=crlf _does_ normalize binary files' '
> test -z "$LFwithNULdiff"
> '
>
> +test_expect_success 'prepare unnormalized' '
> +
> + > .gitattributes &&
Lose SP before ".gitattributes".
> + git config core.autocrlf false &&
> + printf "LINEONE\nLINETWO\r\n" >mixed &&
> + git add mixed .gitattributes &&
> + git commit -m "Add mixed" &&
> + git ls-files --eol | egrep "i/crlf" &&
> + git ls-files --eol | egrep "i/mixed"
> +
> +'
Any particular reason why we must use egrep not grep here?
> +
> +test_expect_success 'normalize unnormalized' '
> + echo "* text=auto" >.gitattributes &&
> + rm .git/index &&
> + git add . &&
> + git commit -m "Introduce end-of-line normalization" &&
> + git ls-files --eol | tr "\\t" " " | sort >act &&
> +cat >exp <<EOF &&
> +i/-text w/-text attr/text=auto LFwithNUL
> +i/lf w/crlf attr/text=auto CRLFonly
> +i/lf w/crlf attr/text=auto LFonly
> +i/lf w/lf attr/text=auto .gitattributes
> +i/lf w/mixed attr/text=auto mixed
> +EOF
Use <<-EOF to indent the above 7 lines?
> + test_cmp exp act
> +
> +'
> +
> test_done
^ permalink raw reply
* Re: [PATCH] allow git-p4 to create shelved changelists
From: Junio C Hamano @ 2016-11-29 18:59 UTC (permalink / raw)
To: Luke Diamand; +Cc: Vinicius Kursancew, Lars Schneider, Git Users
In-Reply-To: <CAE5ih78+br88ST3Hkiw744V62AZ9iYWZ4nD5EYjewfmQRWvsiw@mail.gmail.com>
Luke Diamand <luke@diamand.org> writes:
> On 28 November 2016 at 19:06, Junio C Hamano <gitster@pobox.com> wrote:
>> Vinicius Kursancew <viniciusalexandre@gmail.com> writes:
>>
>>> This patch adds a "--shelve" option to the submit subcommand, it will
>>> save the changes to a perforce shelve instead of commiting them.
>
> Looks good to me, thanks!
>
> Works a treat.
Thanks.
^ permalink raw reply
* Re: [PATCH 1/2] mergetool: honor mergetool.$tool.trustExitCode for built-in tools
From: Junio C Hamano @ 2016-11-29 18:57 UTC (permalink / raw)
To: David Aguilar; +Cc: Git ML, Dun Peal
In-Reply-To: <20161129093807.24637-1-davvid@gmail.com>
David Aguilar <davvid@gmail.com> writes:
> Built-in merge tools contain a hard-coded assumption about
> whether or not a tool's exit code can be trusted to determine
> the success or failure of a merge. Tools whose exit codes are
> not trusted contain calls to check_unchanged() in their
> merge_cmd() functions.
>
> A problem with this is that the trustExitCode configuration is
> not honored for built-in tools.
>
> Teach built-in tools to honor the trustExitCode configuration.
> Extend run_merge_cmd() so that it is responsible for calling
> check_unchanged() when a tool's exit code cannot be trusted.
> Remove check_unchanged() calls from scriptlets since they are no
> longer responsible for calling it.
>
> When no configuration is present, exit_code_trustable() is
> checked to see whether the exit code should be trusted.
> The default implementation returns false.
>
> Tools whose exit codes can be trusted override
> exit_code_trustable() to true.
>
> Reported-by: Dun Peal <dunpealer@gmail.com>
> Signed-off-by: David Aguilar <davvid@gmail.com>
> ---
> git-mergetool--lib.sh | 56 ++++++++++++++++++++++++++++++++++++++----------
> mergetools/araxis | 2 --
> mergetools/bc | 2 --
> mergetools/codecompare | 2 --
> mergetools/deltawalker | 6 +++++-
> mergetools/diffmerge | 4 ++++
> mergetools/diffuse | 2 --
> mergetools/ecmerge | 2 --
> mergetools/emerge | 4 ++++
> mergetools/examdiff | 2 --
> mergetools/kdiff3 | 4 ++++
> mergetools/kompare | 4 ++++
> mergetools/meld | 3 +--
> mergetools/opendiff | 2 --
> mergetools/p4merge | 2 --
> mergetools/tkdiff | 4 ++++
> mergetools/tortoisemerge | 2 --
> mergetools/vimdiff | 2 --
> mergetools/winmerge | 2 --
> mergetools/xxdiff | 2 --
> 20 files changed, 71 insertions(+), 38 deletions(-)
OK, so the idea is that the backends that used to touch $BACKUP and
used to call check_unchanged stop doing these two things, while
other backends override exit_code_trustable(). That makes the
change to the backends very straightforward to understand.
> # Run a either a configured or built-in merge tool
> run_merge_cmd () {
> - merge_cmd "$1"
> + mergetool_trust_exit_code=$(trust_exit_code "$1")
> + if test "$mergetool_trust_exit_code" = "true"
> + then
> + merge_cmd "$1"
> + else
> + touch "$BACKUP"
> + merge_cmd "$1"
> + check_unchanged
> + fi
> }
Looks sensible. Thanks. Will queue.
^ permalink raw reply
* Re: [PATCH] RelNotes: typo fix in 2.11.0 notes
From: Tobias Klauser @ 2016-11-29 18:50 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <xmqqbmwygmmd.fsf@gitster.mtv.corp.google.com>
On 2016-11-29 at 19:35:38 +0100, Junio C Hamano <gitster@pobox.com> wrote:
> Tobias Klauser <tklauser@distanz.ch> writes:
>
> > s/paht/path/ in the "Backwards compatibility notes" section of the
> > 2.11.0 release notes.
> >
> > Signed-off-by: Tobias Klauser <tklauser@distanz.ch>
> > ---
>
> This looks somewhat familiar. Perhaps
>
> https://public-inbox.org/git/1477668782.1869.4.camel@seestieto.com/
Oops, certainly didn't read carefiul enough. Sorry for the noise and
thanks for the reference.
> > Documentation/RelNotes/2.11.0.txt | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/Documentation/RelNotes/2.11.0.txt b/Documentation/RelNotes/2.11.0.txt
> > index b7b7dd361ef0..4c8a9be60f52 100644
> > --- a/Documentation/RelNotes/2.11.0.txt
> > +++ b/Documentation/RelNotes/2.11.0.txt
> > @@ -5,7 +5,7 @@ Backward compatibility notes.
> >
> > * An empty string used as a pathspec element has always meant
> > 'everything matches', but it is too easy to write a script that
> > - finds a path to remove in $path and run 'git rm "$paht"' by
> > + finds a path to remove in $path and run 'git rm "$path"' by
> > mistake (when the user meant to give "$path"), which ends up
> > removing everything. This release starts warning about the
> > use of an empty string that is used for 'everything matches' and
>
^ permalink raw reply
* Re: [PATCH 0/2] add format specifiers to display trailers
From: Keller, Jacob E @ 2016-11-29 18:43 UTC (permalink / raw)
To: gitster@pobox.com, jacob.keller@gmail.com
Cc: git@vger.kernel.org, jonathantanmy@google.com
In-Reply-To: <xmqqwpfwkar2.fsf@gitster.mtv.corp.google.com>
On Mon, 2016-11-21 at 09:23 -0800, Junio C Hamano wrote:
> Jacob Keller <jacob.keller@gmail.com> writes:
>
> > > We have %s and %b so that we can reconstruct the whole thing by
> > > using both. It is unclear how %bT fits in this picture. I
> > > wonder
> > > if we also need another placeholder that expands to the body of
> > > the
> > > message without the trailer---otherwise the whole set would
> > > become
> > > incoherent, no?
> >
> > I'm not entirely sure what to do here. I just wanted a way to
> > easily
> > format "just the trailers" of a message. We could add something
> > that
> > formats just the non-trailers, that's not too difficult. Not really
> > sure what I'd call it though.
>
> I was wondering if %(log:<name of a part>) was a better way to go.
>
> %(log:title) and %(log:body) would be equivalents of traditional %s
> and %b, and %(log:body) in turn would be a shorter way to write
> %(log:description)%+(log:trailer), i.e. show the message body, and
> if there is a trailer block, add it after adding a blank line.
>
> Or something like that?
That would work for me.
Thanks,
Jake
^ permalink raw reply
* Re: [PATCH v1 1/1] convert: git cherry-pick -Xrenormalize did not work
From: Junio C Hamano @ 2016-11-29 18:42 UTC (permalink / raw)
To: tboegi; +Cc: git, eevee.reply
In-Reply-To: <20161129163023.23403-1-tboegi@web.de>
tboegi@web.de writes:
> From: Torsten Bögershausen <tboegi@web.de>
>
> Working with a repo that used to be all CRLF. At some point it
> was changed to all LF, with `text=auto` in .gitattributes.
> Trying to cherry-pick a commit from before the switchover fails:
>
> $ git cherry-pick -Xrenormalize <commit>
> fatal: CRLF would be replaced by LF in [path]
OK. That's a very clear description of the symptom that can be
observed from the surface.
> Whenever crlf_action is CRLF_TEXT_XXX and not CRLF_AUTO_XXX,
> SAFE_CRLF_RENORMALIZE must be turned into CRLF_SAFE_FALSE.
Aside from needing s/CRLF_SAFE/SAFE_CRLF/, this however lacks
"Otherwise, because of X and Y, Z ends up doing W" to explain
the "must be" part. Care to explain it a bit more?
Thanks.
> Reported-by: Eevee (Lexy Munroe) <eevee@veekun.com>
> Signed-off-by: Torsten Bögershausen <tboegi@web.de>
> ---
>
> Thanks for reporting.
> Here is a less invasive patch.
> Please let me know, if the patch is OK for you
> (email address, does it work..)
>
> convert.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/convert.c b/convert.c
> index be91358..526ec1d 100644
> --- a/convert.c
> +++ b/convert.c
> @@ -286,7 +286,9 @@ static int crlf_to_git(const char *path, const char *src, size_t len,
> checksafe = SAFE_CRLF_FALSE;
> else if (has_cr_in_index(path))
> convert_crlf_into_lf = 0;
> - }
> + } else if (checksafe == SAFE_CRLF_RENORMALIZE)
> + checksafe = SAFE_CRLF_FALSE;
> +
> if (checksafe && len) {
> struct text_stat new_stats;
> memcpy(&new_stats, &stats, sizeof(new_stats));
^ permalink raw reply
* Re: What's cooking in git.git (Nov 2016, #06; Mon, 28)
From: Jeff King @ 2016-11-29 18:37 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <xmqqfumagmso.fsf@gitster.mtv.corp.google.com>
On Tue, Nov 29, 2016 at 10:31:51AM -0800, Junio C Hamano wrote:
> Jeff King <peff@peff.net> writes:
>
> > I'm actually considering scrapping the approach you've queued above, and
> > just teaching verify_path() to reject any index entry starting with
> > ".git" that is a symlink.
>
> Hmph, that's a thought.
I was resistant to it at first because we'll have to deal with all of
the headaches of matching case-folding, but if we just match ".git*" and
not ".gitmodules", ".gitattributes", etc, it actually gets easier. I
think we can basically build off of the existing is_hfs_dotgit() and
is_ntfs_dotgit() functions.
I haven't written the code yet, though, so there may be complications.
-Peff
^ permalink raw reply
* Re: [PATCH] RelNotes: typo fix in 2.11.0 notes
From: Junio C Hamano @ 2016-11-29 18:35 UTC (permalink / raw)
To: Tobias Klauser; +Cc: git
In-Reply-To: <20161129095725.13280-1-tklauser@distanz.ch>
Tobias Klauser <tklauser@distanz.ch> writes:
> s/paht/path/ in the "Backwards compatibility notes" section of the
> 2.11.0 release notes.
>
> Signed-off-by: Tobias Klauser <tklauser@distanz.ch>
> ---
This looks somewhat familiar. Perhaps
https://public-inbox.org/git/1477668782.1869.4.camel@seestieto.com/
> Documentation/RelNotes/2.11.0.txt | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/Documentation/RelNotes/2.11.0.txt b/Documentation/RelNotes/2.11.0.txt
> index b7b7dd361ef0..4c8a9be60f52 100644
> --- a/Documentation/RelNotes/2.11.0.txt
> +++ b/Documentation/RelNotes/2.11.0.txt
> @@ -5,7 +5,7 @@ Backward compatibility notes.
>
> * An empty string used as a pathspec element has always meant
> 'everything matches', but it is too easy to write a script that
> - finds a path to remove in $path and run 'git rm "$paht"' by
> + finds a path to remove in $path and run 'git rm "$path"' by
> mistake (when the user meant to give "$path"), which ends up
> removing everything. This release starts warning about the
> use of an empty string that is used for 'everything matches' and
^ permalink raw reply
* Re: What's cooking in git.git (Nov 2016, #06; Mon, 28)
From: Junio C Hamano @ 2016-11-29 18:31 UTC (permalink / raw)
To: Jeff King; +Cc: git
In-Reply-To: <20161129065912.xa7itc3os425mr3r@sigill.intra.peff.net>
Jeff King <peff@peff.net> writes:
> I'm actually considering scrapping the approach you've queued above, and
> just teaching verify_path() to reject any index entry starting with
> ".git" that is a symlink.
Hmph, that's a thought.
^ permalink raw reply
* Re: gitk crashes on RHEL
From: Stefan Beller @ 2016-11-29 17:41 UTC (permalink / raw)
To: Alessandro Renieri, Paul Mackerras, eric.frederich, Stefan Naewe,
rappazzo
Cc: git@vger.kernel.org
In-Reply-To: <CAKXGFGMGqnGJSEBx8=FXfG3pGEcpFGjLNUH23VTo4LEo75kTKg@mail.gmail.com>
On Tue, Nov 29, 2016 at 1:51 AM, Alessandro Renieri <a.renieri@gmail.com> wrote:
> On Redhat Enterprise gitk returns the following error when launched:
>
> Error in startup script: unknown color name "lime"
> (processing "-fill" option)
> invoked from within
> "$progresscanv create rect -1 0 0 $h -fill lime"
> (procedure "makewindow" line 201)
> invoked from within
> "makewindow"
> (file "/..../bin/git-exe/bin/gitk" line 12434)
>
> The fix is to change lime with {lime green}
>
> Regards
+cc Paul Mackeras, and people involved in the last bug report
See discussion at
https://public-inbox.org/git/CAAoZyYNnWk-yE9TG_Fpxxs-oRN-yEsm_YFs+Ej7muQ+5YCW43w@mail.gmail.com/#t
^ permalink raw reply
* Re: [PATCH 31/35] pathspec: allow querying for attributes
From: Stefan Beller @ 2016-11-29 17:37 UTC (permalink / raw)
To: Brandon Williams; +Cc: Junio C Hamano, Duy Nguyen, git@vger.kernel.org
In-Reply-To: <20161128221123.GC150448@google.com>
On Mon, Nov 28, 2016 at 2:11 PM, Brandon Williams <bmwill@google.com> wrote:
> On 11/10, Stefan Beller wrote:
>> @@ -500,6 +586,18 @@ void copy_pathspec(struct pathspec *dst, const struct pathspec *src)
>>
>> void clear_pathspec(struct pathspec *pathspec)
>> {
>> + int i, j;
>> + for (i = 0; i < pathspec->nr; i++) {
>> + if (!pathspec->items[i].attr_match_nr)
>> + continue;
>> + for (j = 0; j < pathspec->items[j].attr_match_nr; j++)
>> + free(pathspec->items[i].attr_match[j].value);
>> + free(pathspec->items[i].attr_match);
>> + if (pathspec->items[i].attr_check)
>> + git_attr_check_clear(pathspec->items[i].attr_check);
>> + free(pathspec->items[i].attr_check);
>> + }
>> +
>> free(pathspec->items);
>> pathspec->items = NULL;
>
> You may also want to add logic like this to the 'copy_pathspec' function
> so that when a pathspec struct is copied, the destination also has
> ownership of its own attribute items.
>
Thanks for the review comments, I'll plan on resending this series after the
submodule checkout series (which is nowhere near done, but the foundation
is set with sb/submodule-intern-gitdir as a preparation.)
After discussion with Jonathan Nieder, I think it may be possible to make
this new pathspec magic work without the need for thread safety. This is
archived by constructing all relevant attr_check stacks before the preload_index
functionality (which is threaded) and then use the preconstructed attr_checks
to get attr_results just like in this series.
That approach would come with the benefit of not needing mutexes
at all inside the attr code.
^ permalink raw reply
* [PATCH] difftool.c: mark a file-local symbol with static
From: Ramsay Jones @ 2016-11-29 17:36 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Junio C Hamano, GIT Mailing-list
Signed-off-by: Ramsay Jones <ramsay@ramsayjones.plus.com>
---
Hi Johannes,
If you need to re-roll your 'js/difftool-builtin' branch, could
you please squash this into the relevant patch.
Thanks!
Also, due to a problem in my config.mak file on Linux (a commented
out line that had a line continuation '\', grrrrr!), gcc issued a
warning, thus:
builtin/difftool.c: In function ‘run_dir_diff’:
builtin/difftool.c:568:13: warning: zero-length gnu_printf format string [-Wformat-zero-length]
warning("");
^
I am not sure why -Wno-format-zero-length is set in DEVELOPER_CFLAGS,
but do you really need to space the output with an an 'empty'
"warning:" line? (Just curious).
ATB,
Ramsay Jones
builtin/difftool.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/builtin/difftool.c b/builtin/difftool.c
index 3480920..830369c 100644
--- a/builtin/difftool.c
+++ b/builtin/difftool.c
@@ -170,7 +170,7 @@ struct path_entry {
char path[FLEX_ARRAY];
};
-int path_entry_cmp(struct path_entry *a, struct path_entry *b, void *key)
+static int path_entry_cmp(struct path_entry *a, struct path_entry *b, void *key)
{
return strcmp(a->path, key ? key : b->path);
}
--
2.9.0
^ permalink raw reply related
* [PATCH v1 1/1] convert: git cherry-pick -Xrenormalize did not work
From: tboegi @ 2016-11-29 16:30 UTC (permalink / raw)
To: git, eevee.reply; +Cc: Torsten Bögershausen
In-Reply-To: <6a7e155-f399-c9f8-c69e-8164e0735dfb@veekun.com>
From: Torsten Bögershausen <tboegi@web.de>
Working with a repo that used to be all CRLF. At some point it
was changed to all LF, with `text=auto` in .gitattributes.
Trying to cherry-pick a commit from before the switchover fails:
$ git cherry-pick -Xrenormalize <commit>
fatal: CRLF would be replaced by LF in [path]
Whenever crlf_action is CRLF_TEXT_XXX and not CRLF_AUTO_XXX,
SAFE_CRLF_RENORMALIZE must be turned into CRLF_SAFE_FALSE.
Reported-by: Eevee (Lexy Munroe) <eevee@veekun.com>
Signed-off-by: Torsten Bögershausen <tboegi@web.de>
---
Thanks for reporting.
Here is a less invasive patch.
Please let me know, if the patch is OK for you
(email address, does it work..)
convert.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/convert.c b/convert.c
index be91358..526ec1d 100644
--- a/convert.c
+++ b/convert.c
@@ -286,7 +286,9 @@ static int crlf_to_git(const char *path, const char *src, size_t len,
checksafe = SAFE_CRLF_FALSE;
else if (has_cr_in_index(path))
convert_crlf_into_lf = 0;
- }
+ } else if (checksafe == SAFE_CRLF_RENORMALIZE)
+ checksafe = SAFE_CRLF_FALSE;
+
if (checksafe && len) {
struct text_stat new_stats;
memcpy(&new_stats, &stats, sizeof(new_stats));
--
2.10.0
^ permalink raw reply related
* Re: [PATCH v2 00/11] git worktree (re)move
From: Duy Nguyen @ 2016-11-29 13:56 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Johannes Schindelin, Git Mailing List, Johannes Sixt
In-Reply-To: <CACsJy8DQDPzZGJXLpTVHVFUeupPpp5e=b9z4m7xceJWrxPfF3Q@mail.gmail.com>
On Tue, Nov 29, 2016 at 07:08:16PM +0700, Duy Nguyen wrote:
> On Tue, Nov 29, 2016 at 3:20 AM, Junio C Hamano <gitster@pobox.com> wrote:
> > Junio C Hamano <gitster@pobox.com> writes:
> >
> >> Does this round address the issue raised in
> >>
> >> http://public-inbox.org/git/alpine.DEB.2.20.1611161041040.3746@virtualbox
> >>
> >> by Dscho?
>
> It does not (and is sort of expected), quoting from the commit message
>
> copy.c: convert copy_file() to copy_dir_recursively()
>
> This finally enables busybox's copy_file() code under a new name
> (because "copy_file" is already taken in Git code base). Because this
> comes from busybox, POSIXy (or even Linuxy) behavior is expected. More
> changes may be needed for Windows support.
>
> I could "#ifdef WINDOWS return -ENOSYS" for now, which would make it
> build. "git worktree move" won't work on Windows of course...
Another way, as pointed out by j6t, is go with "move within filesystem
only", at least at the first step. Which is probably a good idea
anyway so we can concentrate on git-specific stuff before going to
minor and complicated copy/move details.
If you drop all the "copy.c: " patches and squash this to "worktree
move: new command", and if Windows rename() can move directories, then
git should build and new tests pass.
-- 8< --
diff --git a/builtin/worktree.c b/builtin/worktree.c
index f114965..d8d0127 100644
--- a/builtin/worktree.c
+++ b/builtin/worktree.c
@@ -569,9 +569,9 @@ static int move_worktree(int ac, const char **av, const char *prefix)
wt->path, dst.buf);
/* second try.. */
- if (copy_dir_recursively(wt->path, dst.buf))
- die(_("failed to copy '%s' to '%s'"),
- wt->path, dst.buf);
+ if (copy_dir_recursively(dst.buf, wt->path))
+ die_errno(_("failed to copy '%s' to '%s'"),
+ wt->path, dst.buf);
else {
struct strbuf sb = STRBUF_INIT;
diff --git a/cache.h b/cache.h
index a50a61a..2d4edf6 100644
--- a/cache.h
+++ b/cache.h
@@ -1857,6 +1857,7 @@ extern void fprintf_or_die(FILE *, const char *fmt, ...);
extern int copy_fd(int ifd, int ofd);
extern int copy_file(const char *dst, const char *src, int mode);
extern int copy_file_with_time(const char *dst, const char *src, int mode);
+extern int copy_dir_recursively(const char *dst, const char *src);
extern void write_or_die(int fd, const void *buf, size_t count);
extern void fsync_or_die(int fd, const char *);
diff --git a/copy.c b/copy.c
index 4de6a11..b232aec 100644
--- a/copy.c
+++ b/copy.c
@@ -65,3 +65,9 @@ int copy_file_with_time(const char *dst, const char *src, int mode)
return copy_times(dst, src);
return status;
}
+
+int copy_dir_recursively(const char *dst, const char *src)
+{
+ errno = ENOSYS;
+ return -1;
+}
-- 8< --
^ permalink raw reply related
* [GIT PULL] l10n updates for 2.11.0 round 3 with ru and ca translations
From: Jiang Xin @ 2016-11-29 13:30 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Dimitriy Ryazantcev, Alex Henrie, Git List
Hi Junio,
Final l10n updates for this release cycle, please pull.
The following changes since commit 6366c34b895613482fa32f1abe1c3ca043905ad2:
l10n: de.po: translate 210 new messages (2016-11-28 18:49:25 +0100)
are available in the git repository at:
git://github.com/git-l10n/git-po tags/l10n-2.11.0-rnd3.1
for you to fetch changes up to 082ed8f8706bdb0645ceb13f8ba3cb8ccfb58d5d:
Merge branch 'russian-l10n' of https://github.com/DJm00n/git-po-ru
(2016-11-29 21:19:43 +0800)
----------------------------------------------------------------
l10n-2.11.0-rnd3.1: update ru and ca translations
----------------------------------------------------------------
Alex Henrie (1):
l10n: ca.po: update translation
Dimitriy Ryazantcev (1):
l10n: ru.po: update Russian translation
Jiang Xin (1):
Merge branch 'russian-l10n' of https://github.com/DJm00n/git-po-ru
po/ca.po | 8907 ++++++++++++++++++++++++++++++++++----------------------------
po/ru.po | 8340 ++++++++++++++++++++++++++++++++--------------------------
2 files changed, 9473 insertions(+), 7774 deletions(-)
--
Jiang Xin
^ permalink raw reply
* Re: [PATCH] allow git-p4 to create shelved changelists
From: Luke Diamand @ 2016-11-29 12:47 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Vinicius Kursancew, Lars Schneider, Git Users
In-Reply-To: <xmqqeg1vjug2.fsf@gitster.mtv.corp.google.com>
On 28 November 2016 at 19:06, Junio C Hamano <gitster@pobox.com> wrote:
> Vinicius Kursancew <viniciusalexandre@gmail.com> writes:
>
>> This patch adds a "--shelve" option to the submit subcommand, it will
>> save the changes to a perforce shelve instead of commiting them.
Looks good to me, thanks!
Works a treat.
Ack.
>>
>> Vinicius Kursancew (1):
>> git-p4: allow submit to create shelved changelists.
>>
>> Documentation/git-p4.txt | 5 +++++
>> git-p4.py | 36 ++++++++++++++++++++++--------------
>> t/t9807-git-p4-submit.sh | 31 +++++++++++++++++++++++++++++++
>> 3 files changed, 58 insertions(+), 14 deletions(-)
>
> Thanks, but I am a wrong person to review this change, so I'll
> summon two people who appear in "git shortlog --since=18.months"
> output to help review it.
>
>
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox