You signed in with another tab or window.
Reload
to refresh your session.
You signed out in another tab or window.
Reload
to refresh your session.
You switched accounts on another tab or window.
Reload
to refresh your session.
By clicking “Sign up for GitHub”, you agree to our
terms of service
and
privacy statement
. We’ll occasionally send you account related emails.
Already on GitHub?
Sign in
to your account
Within our bug tracking application (think Jira, Rally etc) we like to generate links to diffs as enclosures, work entries or comments for future references. If a developer needs to look at a diff associated with a given bug they can open the enclosure and click the link to be taken to the related diff. When I run git-lfs migrate those links break because the SHAs change during the rewrite of the history. I looked for ways to draw a correlation between the old and new SHAs but I ran into problems trying to get a distinct set of variables to determine which old SHA is associated with which new SHA. The variables I came up with were:
Commiter
Comment
Branch Name
Numerical order within the branch
I was able to think up scenarios where these variables were not distinct.
E.G. An automated build commits changes as a generic user using a default commit message and does so multiple times on a branch where git-lfs-migrate rewrote history and dropped some SHAs that had net zero changes.
In this situation the commit order in the branch has changed while the committer and comment are identical. I have no way of easily determining which new SHA is associated with which old SHA for these specific commits.
My ask is for git-lfs-migrate to generate a log that maps old SHAs to new SHAs on a per branch basis during the migration process. Such a log would allow us to fix our broken links on an as needed basis. Ideally that log could be stored in a newly created branch that lives on with the repo but a standard log file would work as well.
Hi
@jerick1976
, in the latest version of Git LFS (v2.4.2) there is a patch included (introduced via
#2929
) that writes a CSV file containing a correspondence from old SHA to new (migrated) SHA.
With regards to the part of your comment:
on a per branch basis during the migration process
I am not quite sure what you mean. Commit SHAs are not related to individual branches other than via questions like "which SHAs does this branch contain?" or "which SHAs are unique to this branch only". Those types of questions can be answered by
git rev-list
.
It will but it seems that 2.4.2 does not have access to the option
git lfs --version
git-lfs/2.4.2 (GitHub; linux amd64; go 1.10.2; git
6f4b2e9
)
git lfs migrate --object-map="/var/tmp/map.txt" --everything --include="*.gz"
---SNIP---
Error: unknown flag: --object-map
fatal: 'lfs' appears to be a git command, but we were not
able to execute it. Maybe git-lfs is broken?
Or perhaps I'm missing something obvious?
You must specify a migration mode, which in this case is
import
. You can read more about this by running
git lfs migrate --help
or
git lfs help migrate
. In this case, you'd want to run that as:
git lfs migrate import --object-map="/var/tmp/map.txt" --everything --include="*.gz"
Git LFS appears not to be executable by your operating system's installation of Git. This can be because the git-lfs
binary itself does not have executable permission, or that it is the wrong architecture. Please make sure that you have the right version of Git LFS installed.
Sorry, copied a bad command. Here is what I'm seeing from 2.4.2. If I don't specify the --object-map option the import proceeds as expected. However, when I use this option it returns an unknown option error:
git lfs --version
git-lfs/2.4.2 (GitHub; linux amd64; go 1.10.2; git 6f4b2e9)
git lfs migrate import --everything --include="*.gz"
migrate: Sorting commits: ..., done
^Cgrate: Rewriting commits: 5% (3387/60482)
Exiting because of "interrupt" signal.
git lfs migrate import --object-map= "/var/tmp/map.txt" --everything --include="*.gz"
Sorry, no usage text found for "import"
Error: unknown flag: --object-map
fatal: 'lfs' appears to be a git command, but we were not
able to execute it. Maybe git-lfs is broken?