git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Johannes Schindelin <Johannes.Schindelin@gmx.de>
To: Junio C Hamano <gitster@pobox.com>
Cc: panzercheg <panzercheg@gmail.com>,
	panzercheg via GitGitGadget <gitgitgadget@gmail.com>,
	git@vger.kernel.org
Subject: Re: [PATCH v2 1/1] "git lfs" allows users to specify the custom storage location by configuration variable lfs.storage, but when "git p4" interacts with GitLFS pointers, it always used the hardcoded default that is the .git/lfs/ directory, without paying attention to the configuration.
Date: Thu, 12 Dec 2019 20:47:28 +0100 (CET)	[thread overview]
Message-ID: <nycvar.QRO.7.76.6.1912122046400.46@tvgsbejvaqbjf.bet> (raw)
In-Reply-To: <xmqq8snipxec.fsf@gitster-ct.c.googlers.com>

Hi Junio,

On Wed, 11 Dec 2019, Junio C Hamano wrote:

> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>
> > On Mon, 9 Dec 2019, Junio C Hamano wrote:
> >
> >> "panzercheg via GitGitGadget" <gitgitgadget@gmail.com> writes:
> >>
> >> >Subject: Re: [PATCH v2 1/1] "git lfs" allows users to specify the custom storage location by configuration variable lfs.storage, but when "git p4" interacts with GitLFS pointers, it always used the hardcoded default that is the .git/lfs/ directory, without paying attention to the configuration.
> >>
> >> Oops, what happened here?
> >>
> >> I wonder/I wish if GGG can be a bit more helpful when seeing a
> >> commit that looks "strange".
> >
> > There is already a ticket about that:
> > https://github.com/gitgitgadget/gitgitgadget/issues/120
> >
> > All it requires is a contributor with a little time :-)
> >
> >> > From: panzercheg <panzercheg@gmail.com>
> >> >
> >> > Use the value configured in lfs.storage, if exists, as all the
> >> > "git" operations do, for consistency.
> >> >
> >> > Signed-off-by: r.burenkov <panzercheg@gmail.com>
> >>
> >> Please make sure that the name/email as the author matches whom you
> >> sign-off the patch as.
> >
> > This, too, should be addressed as part of above-mentioned ticket.
>
> Tooling improvement is fine, but let's not sink too much time on
> tangents and steal time from *this* patch.

I fully agree.

> Would the following version (which I munged by hand) be close enough
> to what the author would have sent out in the ideal world?  If so,
> let's queue it.

I obviously cannot speak for r.burenkov, but from my point of view, the
below patch is very much the intended outcome.

Thanks,
Dscho

>
> -- >8 --
> Subject: git-p4: honor lfs.storage configuration variable
> From: r.burenkov <panzercheg@gmail.com>
>
> "git lfs" allows users to specify the custom storage location by the
> configuration variable `lfs.storage`, but when "git p4" interacts with
> GitLFS pointers, it always uses the hardcoded default that is the
> `.git/lfs/` directory, without paying attention to the configuration.
>
> Use the value configured in `lfs.storage`, if exists, as all the
> "git" operations do, for consistency.
>
> Signed-off-by: r.burenkov <panzercheg@gmail.com>
> ---
>  git-p4.py | 10 ++++++++--
>  1 file changed, 8 insertions(+), 2 deletions(-)
>
> diff --git a/git-p4.py b/git-p4.py
> index 60c73b6a37..0b3a07cb31 100755
> --- a/git-p4.py
> +++ b/git-p4.py
> @@ -1257,9 +1257,15 @@ def generatePointer(self, contentFile):
>              pointerFile = re.sub(r'Git LFS pointer for.*\n\n', '', pointerFile)
>
>          oid = re.search(r'^oid \w+:(\w+)', pointerFile, re.MULTILINE).group(1)
> +        # if someone use external lfs.storage ( not in local repo git )
> +        lfs_path = gitConfig('lfs.storage')
> +        if not lfs_path:
> +            lfs_path = 'lfs'
> +        if not os.path.isabs(lfs_path):
> +            lfs_path = os.path.join(os.getcwd(), '.git', lfs_path)
>          localLargeFile = os.path.join(
> -            os.getcwd(),
> -            '.git', 'lfs', 'objects', oid[:2], oid[2:4],
> +            lfs_path,
> +            'objects', oid[:2], oid[2:4],
>              oid,
>          )
>          # LFS Spec states that pointer files should not have the executable bit set.
> --
> gitgitgadget
>

      reply	other threads:[~2019-12-12 19:47 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-12-04 13:30 [PATCH 0/1] git-p4: use lfs.storage instead of local .git/lfs r.burenkov via GitGitGadget
2019-12-04 13:30 ` [PATCH 1/1] git-p4: use lfs.storage instead of local .git/lfs Use lfs.storage if it defined in git.config. If lfs.storage not define - used local .git/lfs. Original code uses local .git/lfs in sync/clone operations, but if you have external lfs storage better to use it panzercheg via GitGitGadget
2019-12-04 16:51   ` Junio C Hamano
2019-12-09 14:28 ` [PATCH v2 0/1] git-p4: use lfs.storage instead of local .git/lfs r.burenkov via GitGitGadget
2019-12-09 14:28   ` [PATCH v2 1/1] "git lfs" allows users to specify the custom storage location by configuration variable lfs.storage, but when "git p4" interacts with GitLFS pointers, it always used the hardcoded default that is the .git/lfs/ directory, without paying attention to the configuration panzercheg via GitGitGadget
2019-12-09 22:27     ` Junio C Hamano
2019-12-09 22:50       ` Eric Sunshine
2019-12-10 12:19       ` Johannes Schindelin
2019-12-11 17:47         ` Junio C Hamano
2019-12-12 19:47           ` Johannes Schindelin [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=nycvar.QRO.7.76.6.1912122046400.46@tvgsbejvaqbjf.bet \
    --to=johannes.schindelin@gmx.de \
    --cc=git@vger.kernel.org \
    --cc=gitgitgadget@gmail.com \
    --cc=gitster@pobox.com \
    --cc=panzercheg@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).