Re-introduce commit message template #1756
Conversation
Co-Authored-By: Tilde Ann Thurium <annthurium@github.com>
Repro steps: open repo with merge conflict click undo see error (cannot do a soft reset in the middle of a merge) expected: no change to commit message box actual: commit message from last commit appears in box
See #1464 (for performance)
It's best to assume that template users craft their template exactly as they want it. For example, I have two empty lines at the beginning of mine so that I can quickly type my message.
We don't want it to be at the end
According to @smashwilson > it may be worth triggering some of that behavior manually if a user aborts (or, eventually, initiates) a merge through our UI. in terms of reliability - on all three platforms there is some risk of dropped events that increases with the number of events that arrive in quick succession (like if a ton of files are created at once). merges in huge repositories _might_ trigger this but it shouldn't be common. Co-Authored-By: Ash Wilson <smashwilson@gmail.com>
Co-Authored-By: Matt <mattmattmatt@users.noreply.github.com>
We don't want to be setting up a commit template for every single test that runs. We do it locally for the tests that need it
kuychaco
added this to In Progress 🔧
in Feature Sprint : 1 October - 19 November 2018 : v0.21.0
via automation
Co-Authored-By: Katrina Uychaco <katrina@github.com>
| const regex = new RegExp('^~([^/]*)/'); | ||
| templatePath = templatePath.trim().replace(regex, (_, user) => { | ||
| // if no user is specified, fall back to using the home directory. | ||
| return `${user ? path.join(path.dirname(homeDir), user) : homeDir}/`; |
annthurium
Oct 25, 2018
Contributor
@smashwilson: can you test this on non-Mac operating systems? We want to make sure if a username is specified, it does the right thing for our Linux and or Windows users.
@smashwilson: can you test this on non-Mac operating systems? We want to make sure if a username is specified, it does the right thing for our Linux and or Windows users.
smashwilson
Oct 29, 2018
Member
Can do, and will report back 🙇
One thing that I can see right away is that this won't handle ~root/ correctly; on most *nix systems, that should expand to /root, not /users/root. In general the right thing to do on Unix-y systems is to use getpwnam(3) to read the definitive information, taking into account any weird local network drive setups and so on. Windows I'm less familiar with.
There are a few tilde-expansion libraries on npm, but unfortunately looking at their source it doesn't look like many of them handle all of this correctly either! I found one that uses etc-passwd to read its info, but I don't believe it has any accommodations for Windows. This may be a sign that this isn't important enough to hold up the 🚢 for 😉
Can do, and will report back
One thing that I can see right away is that this won't handle ~root/ correctly; on most *nix systems, that should expand to /root, not /users/root. In general the right thing to do on Unix-y systems is to use getpwnam(3) to read the definitive information, taking into account any weird local network drive setups and so on. Windows I'm less familiar with.
There are a few tilde-expansion libraries on npm, but unfortunately looking at their source it doesn't look like many of them handle all of this correctly either! I found one that uses etc-passwd to read its info, but I don't believe it has any accommodations for Windows. This may be a sign that this isn't important enough to hold up the
Co-Authored-By: Katrina Uychaco <katrina@github.com>
This only works for commit message templates where every line starts with a #. We explored using isCommitMessageClean to try and handle commit message templates that have uncommented lines. We're not calling didUpdate every time the commit message is updated, so it's out of sync, and we decided it was getting too edge casey out there. Co-Authored-By: Katrina Uychaco <katrina@github.com>
|
I have a bunch of assorted feedback, but no bugs or blockers I'll test the |
| // Regex translation: | ||
| // ^~ line starts with tilde | ||
| // ([^/]*)/ captures non-forwardslash characters before first slash | ||
| const regex = new RegExp('^~([^/]*)/'); |
smashwilson
Oct 29, 2018
Member
Is there a reason this is constructed with new RegExp() rather than as a regexp literal? Is it just for readability so you don't have to escape all of the / and get into leaning-toothpick-syndrome?
A more descriptive name than regex may be nice too 😄 How about something like tildeExpansionPattern?
Is there a reason this is constructed with new RegExp() rather than as a regexp literal? Is it just for readability so you don't have to escape all of the / and get into leaning-toothpick-syndrome?
A more descriptive name than regex may be nice too tildeExpansionPattern?
annthurium
Oct 29, 2018
Contributor
We didn't really have a strong reason for preferring the regexp constructor over literals here. We went with what the original author had.
Out of curiosity, we looked to see if there was a performance difference. Answer: not really.
https://www.measurethat.net/Benchmarks/Show/1734/1/regexp-constructor-vs-literal
We did give it a more descriptive name, and moved it out of this function so as to avoid creating a new regex every time.
We didn't really have a strong reason for preferring the regexp constructor over literals here. We went with what the original author had.
Out of curiosity, we looked to see if there was a performance difference. Answer: not really.
https://www.measurethat.net/Benchmarks/Show/1734/1/regexp-constructor-vs-literal
We did give it a more descriptive name, and moved it out of this function so as to avoid creating a new regex every time.
| const regex = new RegExp('^~([^/]*)/'); | ||
| templatePath = templatePath.trim().replace(regex, (_, user) => { | ||
| // if no user is specified, fall back to using the home directory. | ||
| return `${user ? path.join(path.dirname(homeDir), user) : homeDir}/`; |
smashwilson
Oct 29, 2018
Member
Can do, and will report back 🙇
One thing that I can see right away is that this won't handle ~root/ correctly; on most *nix systems, that should expand to /root, not /users/root. In general the right thing to do on Unix-y systems is to use getpwnam(3) to read the definitive information, taking into account any weird local network drive setups and so on. Windows I'm less familiar with.
There are a few tilde-expansion libraries on npm, but unfortunately looking at their source it doesn't look like many of them handle all of this correctly either! I found one that uses etc-passwd to read its info, but I don't believe it has any accommodations for Windows. This may be a sign that this isn't important enough to hold up the 🚢 for 😉
Can do, and will report back
One thing that I can see right away is that this won't handle ~root/ correctly; on most *nix systems, that should expand to /root, not /users/root. In general the right thing to do on Unix-y systems is to use getpwnam(3) to read the definitive information, taking into account any weird local network drive setups and so on. Windows I'm less familiar with.
There are a few tilde-expansion libraries on npm, but unfortunately looking at their source it doesn't look like many of them handle all of this correctly either! I found one that uses etc-passwd to read its info, but I don't believe it has any accommodations for Windows. This may be a sign that this isn't important enough to hold up the
| async updateCommitMessageAfterFileSystemChange(events) { | ||
| for (let i = 0; i < events.length; i++) { | ||
| const event = events[i]; | ||
| const endsWith = (...segments) => event.path.endsWith(path.join(...segments)); |
smashwilson
Oct 29, 2018
Member
Might be worth extracting this to helpers.js?
It is a one-liner, but eh.
Might be worth extracting this to helpers.js?
It is a one-liner, but eh.
annthurium
Oct 29, 2018
Contributor
sure! Good suggestion. Extracted.
sure! Good suggestion. Extracted.
| return {repository, observer}; | ||
| } | ||
|
|
||
| function expectEvents(repository, ...suffixes) { |
smashwilson
Oct 29, 2018
Member
Yeah, these would be great to extract to a helper and clean up a bit... We have a few places that test Real Filesystem Events ™️ where these would be nice.
Yeah, these would be great to extract to a helper and clean up a bit... We have a few places that test Real Filesystem Events
Co-Authored-By: Katrina Uychaco <katrina@github.com>
Co-Authored-By: Katrina Uychaco <katrina@github.com>
Co-Authored-By: Tilde Ann Thurium <annthurium@github.com>
Tests were failing because my global config was being used to look up the commit template
Co-Authored-By: Ash Wilson <smashwilson@gmail.com>
|
I just found a bug on Windows. If I run From the message, I'm guessing that the fetched commit template is Oddly it's fine if I ctrl-F5 with no |
|
Path logic is |
|
|
|
We should probably fix that stack trace I found when running |
Description of the Change
This PR re-introduces the commit message template feature, originally introduced in #1713. It re-works some of the implementation, cleans up tests, and additionally fixes the merge message regression.
With these change, the repository model now manages and updates the commit message based on file system events indicating that the config has changed or a merge has been initiated/completed.
/cc @annthurium
Alternate Designs
N/A
Benefits
Folks will be able to make commits with the aid of commit message templates
Possible Drawbacks
The usual drawbacks associated with code changes. This feature in particular touches a part of the system that is complex and fairly edge-casey...
Applicable Issues
Original PR - #1713
Reverted PR - #1754
Metrics
N/A
Tests
Added unit tests for:
Manually tested:
tabbing to commit box, cursor is at beginning of template (rather than at the very end)@smashwilson to test manually on Linux and Windows
Documentation
User Experience Research (Optional)
N/A
TODO: