search

fork-dev / TrackerWin

Bug and issue tracker for Fork for Windows
450 stars 10 forks source link

Fork not stripping comment chars while plain git does #2181

Open PlasmaHH opened 3 months ago

PlasmaHH commented 3 months ago

We use a commit template that consists mostly of comments (introduced with #) that describe how to write a comment, what to include etc.

When doing a normal git commit on the command line, these chars are stripped away. However when fork loads the message it saves it in a file and passes that file to git.

I tried setting core.commentchar="#" but that doesn't help. It seems that when using git commit --file then the commit message is considered to be totally complete and will not be processed by git?

It might be enough to pass --cleanup=strip which is the default when the message is edited (otherwise the default seems to be whitespace.

DanPristupov commented 3 months ago

duplicate https://github.com/fork-dev/TrackerWin/issues/203

PlasmaHH commented 3 months ago

Oh, well, I saw that one and quickly skipped it because I thought it was about some special case when merging...

Anyways allow me to state my probably overly lengthy opinion about that matter, especially the one mentioned in https://github.com/fork-dev/Tracker/issues/180#issuecomment-800431233 ...

It seems to be that there are bascially two ways to look at fork, both having a validity on their own: one uses fork with all its cool and helpful additions, seeing it as if fork uses git as a tool to get the work done. Otoh there are people that use git and see fork as a tool to use git.

We are in the later camp, also because of the variety of git clients we want to allow in the teams, as well as the command line. This leads to the case for us that for all git guis/integrations, the default behaviour of git on the command line is the best.

My suggestion therefore is to give people the least of suprises, until a real good solution that works for everyone is found ( that ticket over there seems to be open since 2017 and in 2023 someone commented that this remains the only frustration with fork ) that there is an option somewhere to use --cleanup=strip ( one could argue whats the default value here, for me it wouldn't matter much personally as I can easily change it ).

This would make force for the majority of operations behave just like you would expect from git on the command line. It also would allow people to continue using their commit message templates. I would personally be somehwat, uhm, not be happy if using a tool would cause to not be able to use the templates I use elsewhere.

As for solving the problem "once and for all"™ here is my idea, maybe it is helpful in getting to the right direction:

Write up all the possible solutions and problems in one post so people can understand it. Write up all the features people might want to use together that are either mutually exclusive or don't really need to work together. From that on people could comment and maybe there emerges a single setting that helps >90% of the people to do what they want?

For my part for example I don't quite get the problem with using # as a comment char with rebases, it works fine for me in plain command line git. Also you mention people wanting to use # at the start for ticket number references etc. but those would not be using it as a comment char then with plain git and strip anyways.

You mention that the argument that cleanup=strip won't work is that fork uses ^ as comment char. If that is the only thing, then possibly checking if strip is active and having fork remove them on its own might work? I really dislike fork overriding commentchar and can imagine that it might lead to issues here and there as git does some guesswork when it is not set to anything...

While writing this and thinking about it, more and more I think that having a second layer of comments within fork and not letting git see anything of that might be the best way. Fork can then do add whatever comments it likes and remove them and git won't ever see any of this ( There will surely never be a case where the message is created in one tool and then commited just using the other )

PlasmaHH commented 3 months ago

Just in case someone didn't have the idea: I will try working around this issue by using the commit-msg hook, not ideal and surely nothing that should be required to use fork.