Hi Gianluca,
i do not want to get bugged with another question (to input a
change-comment) at all, at least not mandatory.
Personally i prefer auto-generated commit messages, as we should ensure
that no one discloses valuable information accidentally.
You already have author, timestamp, changed files/paths in git.
So please make some suggestions of what text would help you when planing
to revert to an earlyer commit.
I guess "Field X,Y,Z updated. Field M dropped, Field T added", is
something that would help you, but for others this is maybe already to
mutch details disclosed.
So maybe a .pass file with optional flags for the commit message
generator is one way to implement it at password-store level.
I guess a full revert of the whole repo e.g. 50 commits back to the past
is not what you are looking for. I guess you are looking for restoring
an old version of a specific password (file/path) - a re-commit of an
older version of a password/file instead of a full rollback of the repo
to a certain point in time (would result in loosing all other changes
made to other passwords in between).
I would like to see a "password-file history" in pass (only commits that
belongs to that file, not all commits) within pass with the option to
select one for restore (while leaving the file-history 100% complete).
Or are you asking for just good commit messages and doing it directly in
git?
Team-Mode:
Do we need special-pass treatment e.g. restoring of old password/file
versions by users that are no longer listed in .gpg-id? Auto
re-encrypting based on current .gpg-id, but first checking if you are
able to decrypt this password/file and cancle re-store if decryption
failed. Sure someone could do it with native git commands - but that way
we would provide a more guided way (bullet prove). Do not get me wrong,
this is not to establish a certain level of security it is just for
convenience (more guided). If a user was dropped (no longer encrypted
for that user) and if "restored-password" is equal to "previous
password" we may want to get a warning to recommend to generate a new
password for security reasons (to the the dropped user lose access to
that system; not just to the latest password/file version).
Someone may come-up with other situations where we should implement a
pass-specific process instead of using git directly.
Best regards
Christian Weiss
On 29.02.20 13:28, Gianluca Recchia wrote:
Hi,
I like how pass works overall and the way it integrates with Git is
great!
However, there's one thing that I find slightly annoying: the default
commit message is often not very descriptive of the change I made to
an entry and I often find myself having to amend the commit in order
to change the message.
I believe it would be an improvement in user experience if the user
were given the ability to edit the commit message before committing,
perhaps using the prepare-commit-msg hook to prefill the message
buffer with what the default message would be, so that the user would
only need to exit the editor if they're okay with the default message.
Alternatively this could be optional in the local .gitconfig and
overridable only for one command through a flag.
Best regards,
Gianluca
_______________________________________________
Password-Store mailing list
[email protected]
https://lists.zx2c4.com/mailman/listinfo/password-store
_______________________________________________
Password-Store mailing list
[email protected]
https://lists.zx2c4.com/mailman/listinfo/password-store
