mbox series

[0/2] git-svn: use svn:global-ignores when creating .gitignores

Message ID pull.1747.git.git.1721246266.gitgitgadget@gmail.com (mailing list archive)
Headers show
Series git-svn: use svn:global-ignores when creating .gitignores | expand

Message

John Cai via GitGitGadget July 17, 2024, 7:57 p.m. UTC
Git-SVN does not currently use the svn:global-ignores property added in
Subversion 1.8 when showing or creating .gitignore files. This causes
Git-SVN to track files that are ignored by this directive in Subversion.

The following patches add svn:global-ignores to the list of public svn
properties, and update git svn show-ignore and git svn create-ignore to use
this attribute (as well as svn:ignore).

Alex Galvin (2):
  git-svn: add public property `svn:global-ignores`
  git-svn: use `svn:global-ignores` to create .gitignore

 git-svn.perl    | 45 +++++++++++++++++++++++++++++++--------------
 perl/Git/SVN.pm |  2 +-
 2 files changed, 32 insertions(+), 15 deletions(-)


base-commit: c2b3f2b3cdbf5ad9feb978dd367d77561a1271f7
Published-As: https://github.com/gitgitgadget/git/releases/tag/pr-git-1747%2Fav-gal%2Fgit-svn-global-ignores-v1
Fetch-It-Via: git fetch https://github.com/gitgitgadget/git pr-git-1747/av-gal/git-svn-global-ignores-v1
Pull-Request: https://github.com/git/git/pull/1747

Comments

Junio C Hamano July 17, 2024, 8:45 p.m. UTC | #1
"Alex Galvin via GitGitGadget" <gitgitgadget@gmail.com> writes:

> Git-SVN does not currently use the svn:global-ignores property added in
> Subversion 1.8 when showing or creating .gitignore files. This causes
> Git-SVN to track files that are ignored by this directive in Subversion.

That is a well written explanation of what issue the patches want to
address.

> The following patches add svn:global-ignores to the list of public svn
> properties, and update git svn show-ignore and git svn create-ignore to use
> this attribute (as well as svn:ignore).

Paying attention to the new property and get it reflected to
.gitignore on Git side may be a reasonable solution, especially if
we ignore older version of Subversion.  But I have a naïve question.
If a new version of git-svn starts to rely on the new property that
is only available in SVN 1.8, would it create problems with folks
whose SVN installation does not understand it?  Would it cause
problems to them?

Anyway, in this project, explanation of the problem the patches
address, with the outline of the solution, should be in the proposed
commit log message of the patches themselves, not just written in
the cover letter.  Can you redo the proposed log messages of these
two patches, where you have none in this iteration?

Thanks.

> Alex Galvin (2):
>   git-svn: add public property `svn:global-ignores`
>   git-svn: use `svn:global-ignores` to create .gitignore
>
>  git-svn.perl    | 45 +++++++++++++++++++++++++++++++--------------
>  perl/Git/SVN.pm |  2 +-
>  2 files changed, 32 insertions(+), 15 deletions(-)
>
>
> base-commit: c2b3f2b3cdbf5ad9feb978dd367d77561a1271f7
> Published-As: https://github.com/gitgitgadget/git/releases/tag/pr-git-1747%2Fav-gal%2Fgit-svn-global-ignores-v1
> Fetch-It-Via: git fetch https://github.com/gitgitgadget/git pr-git-1747/av-gal/git-svn-global-ignores-v1
> Pull-Request: https://github.com/git/git/pull/1747
Alex Galvin July 18, 2024, 7:59 p.m. UTC | #2
On 2024-07-17 4:45 p.m., Junio C Hamano wrote:
> Paying attention to the new property and get it reflected to
> .gitignore on Git side may be a reasonable solution, especially if
> we ignore older version of Subversion.  But I have a naïve question.
> If a new version of git-svn starts to rely on the new property that
> is only available in SVN 1.8, would it create problems with folks
> whose SVN installation does not understand it?  Would it cause
> problems to them?

I don't believe so. Git doesn't do anything to set these properties,
it just reads and translates them into the format used by .gitignore.
So users on old versions of SVN should not be affected, their
servers will not have this property set anywhere.

> Anyway, in this project, explanation of the problem the patches
> address, with the outline of the solution, should be in the proposed
> commit log message of the patches themselves, not just written in
> the cover letter.  Can you redo the proposed log messages of these
> two patches, where you have none in this iteration?
>
> Thanks.
Sure thing. An amended patchset is incoming.

Thanks,
Alex