git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: "panzercheg via GitGitGadget" <gitgitgadget@gmail.com>
Cc: git@vger.kernel.org, panzercheg <panzercheg@gmail.com>
Subject: Re: [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.
Date: Wed, 04 Dec 2019 08:51:23 -0800	[thread overview]
Message-ID: <xmqqh82g5910.fsf@gitster-ct.c.googlers.com> (raw)
In-Reply-To: <73d0dfc9dd7e6e800297b5084de84b727e28b900.1575466209.git.gitgitgadget@gmail.com> (panzercheg via GitGitGadget's message of "Wed, 04 Dec 2019 13:30:09 +0000")

"panzercheg via GitGitGadget" <gitgitgadget@gmail.com> writes:

> From: panzercheg <panzercheg@gmail.com>

> Subject: Re: [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.

The reason why you ended up with this unreadably long subject line
is because your commit did not follow the recommended

    <area>: summary of the change in 50 or so characters

    description of the issue being tackled,
    where it came from,
    why the current behaviour is considered not ideal, etc.

    what the proposed change does, and why it is the good idea.

format, each clearly separated into their own paragraphs.

Especially the title MUST be in its own, single-line paragraph.

Let's dissect what we see on the single long subject line.


    git-p4: use lfs.storage instead of local .git/lfs

    Use lfs.storage if it defined in git.config.

What is "git.config"?  Is it our own usual configuration file(s), or
is it the Git-LFS customized .lfsconfig file at the root of the
repository, or something else?

Grammo: "Use lfs.storage if it is defined ..."

But do not start your proposed log message with the conclusion.
Before "Use X", we want to see readers convinced why using X is a
good idea; in other words, you need to tell the reason why the
current system that does not use X is not ideal, and explain that
the change makes the world a better place by teaching Git to use X.

    If lfs.storage not define - used local .git/lfs.
    Original code uses local .git/lfs in sync/clone operations,

These are saying pretty much the same thing, that can easily
inferred from the "Use lfs.storage if it is defined.", iow, without
having much original information content.

    but if you have external lfs storage better to use it.

This is probably the sole line that attempts to justify the change.
It should be made stronger, I would think.

Possible rewrite (don't use it literally---I am not an GitLFS user so
I may be writing nonsense here):

    git-p4: prefer lfs.storage over local .git/lfs directory

    "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.

    Use the value configured in lfs.storage, if exists, as all the
    "git" operations do, for consistency.

    Signed-off-by: ...


>
> Signed-off-by: r.burenkov <panzercheg@gmail.com>
> ---
>  git-p4.py | 8 ++++++--
>  1 file changed, 6 insertions(+), 2 deletions(-)
>
> diff --git a/git-p4.py b/git-p4.py
> index 60c73b6a37..2bd0497c31 100755
> --- a/git-p4.py
> +++ b/git-p4.py
> @@ -1257,9 +1257,13 @@ 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 )

s/use/uses/; also lose SP after '(' and before ')'.

> +        lfs_path = os.path.join(os.getcwd(), '.git', 'lfs')
> +        if gitConfig('lfs.storage'):
> +            lfs_path = gitConfig('lfs.storage')

Shouldn't the above three lines be more like this?

	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)

The reason why I suspect so is because [*1*] says that the value of
the lfs.storage that is not an absolute path is relative to ".git".

Thanks.



[Reference]

*1* https://github.com/git-lfs/git-lfs/blob/master/docs/man/git-lfs-config.5.ronn



>          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.

  reply	other threads:[~2019-12-04 16:51 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 [this message]
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

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

  List information: http://vger.kernel.org/majordomo-info.html

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

  git send-email \
    --in-reply-to=xmqqh82g5910.fsf@gitster-ct.c.googlers.com \
    --to=gitster@pobox.com \
    --cc=git@vger.kernel.org \
    --cc=gitgitgadget@gmail.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.
Code repositories for project(s) associated with this public inbox

	https://80x24.org/mirrors/git.git

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 read-only IMAP folder(s) and NNTP newsgroup(s).