danny0838/git-store-meta

Feature request: add shasum field

priyadarshan opened this issue · 7 comments

priyadarshan commented

Although it is not important in the git ecosphere, it would be nice to be able to specify an optional shasum field, to be used with the -f switch, especially if #3 is accepted and implemented.

It could perhaps leverage local unix shasum, as that is very fast.

Adding a shasum field would make git-store-meta a very powerful tool for many.

Thank you for considering this.

priyadarshan commented

We have two use-cases where the shasum field would be useful:

  1. We have several very long-lived repositories (from early 2000, inported from CVS).

Over the course of time, it has happened that we need to remove a subdirectory, only to later add a new subdirectory with same name and sometime files with same names as previous ones (especially documentation).

In that case, .git/hooks/git-store-meta.pl --apply could potentially apply the wrong metadata, since the files in question would have same path, but not be same files.

If git-store-meta could double check shasum (perhaps even just as an option), it could identify new files with same names, perhaps offering switch to overwrite previous values, or perhaps be warned.

  1. Sometimes we need to move a given directory. Having shasum would allow to trace the moved files, and possibly updating the path in .git_store_meta

Thank you for keeping this ticket open.

danny0838 commented

I'm not quite convinced to the usage case you mentioned.

By design --apply should only be run when the working tree is clean. If some files have been changed, it is a case that either:
(1) the change is good: commit the changes and --update; or
(2) the change is bad: revert the changes and re--apply.

It seems likely a wrong usage to change files and then run --apply, as far as I could tell.

priyadarshan commented

Sorry, I was not aware that git-store-meta was removing all metadata if not in the filesystem.

I realise that our use-case may be a bit special, and therefore outside git-store-meta scope. Let me try to rephrase it.

We would need to care for metadata of any file, as long as it is in the repository's history, even if at a given time, that file has been removed and it does not show up in the filesystem.

  1. If I track file a.txt, git-store-meta will help track its metadata
  2. a.txt is removed. metadata is also removed
  3. At some time in the future, we realise it was a mistake. So, a.txt is restored back to Working Copy, at the proper past revision, say b861b2e3.
  4. git-store-meta adds new metadata, like file was completely new

We would need instead:
4. git-store-meta restore old metadata, as it was at b861b2e3

Basically, as long as a file is somehwre in the repository, we would like to preserve its metadata as well.

I understand this may be a bit out of scope though. Please feel free to close this request any time. We may have to write a custom tool for this special use-case.

Thank you.

danny0838 commented

In the case I think you can edit the .git_store_meta file to make the line of a.txt use the value in the revision b861b2e3, and then run --apply.

  • 👍1
priyadarshan commented

Yes, one could do it manually. It will definitely work for one or few files. I guess one could use a custom tool, in case he will need to do it for hundreds or thousands (like in our case).
Thank you.

danny0838 commented

I don't think we can help further with such case. Even if we implement a shasum field as you proposed, it will also get removed at the time a.txt is removed in your case.

priyadarshan commented

Yes, it is really a corner case, I am not sure how many would be interested.
We can always make an ad hoc tool. In that case, I will keep you updated.
Please feel free to close this ticket if you so wish.