Allow to edit the commit message

[Christian Weiss]

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
> Password-Store at lists.zx2c4.com
> https://lists.zx2c4.com/mailman/listinfo/password-store
>