Change git-cp to use cleaner branch approach#1169
Conversation
|
@spacewander I'd appreciate any suggestion you have for moving this forward. I tried to follow the contribution instructions but I may have gotten something wrong. Also, I am confused by the lint check error:
Thanks in advance! |
|
@MattiasEh Maybe we can change our CI code according to the jitterbit/get-changed-files#19 (comment). (It will go as another pull request) |
| git merge $MERGE_OPT "${DESTINATION_SAVED}" "${INTERMEDIATE_SAVED}" -m "Duplicate ${CURRENT_FILENAME} history." | ||
| # Switch to the original branch and merge this back in. | ||
| git checkout - | ||
| git merge --no-ff "$BRANCH_NAME" -m "Copying $CURRENT_FILENAME into $DESTINATION_FILENAME" |
There was a problem hiding this comment.
This produces a commit with the repeated message (there is already a message Copying .... before it).
Could we optimize it?
There was a problem hiding this comment.
I'd be happy to change the commit messages to be more descriptive. The reason I made them like this is because this merge message is the key one directly on the branch, so I figured it should be a summary message for the whole operation.
Here's an example of what results when I used this version of git-cp, run thrice, to turn one file into four copies--setting up for a commit that prunes down all four into just the parts each should keep:

With this context, what do you think are the best messages?
There was a problem hiding this comment.
These messages look good to me.
There was a problem hiding this comment.
Great! I have pushed the better commit messages and taken this PR out of Draft. Thanks, @spacewander .
|
@MattiasEh |
Happy to help! And thank you, @spacewander ! |

Change git-cp to use cleaner branch approach, per https://stackoverflow.com/a/46484848/32841 and https://devblogs.microsoft.com/oldnewthing/20190919-00/?p=102904
This approach avoids the need for messy temporary files and therefore eliminates the class of problems related to those--which means that this resolves #1090. It also makes for a cleaner history (at least IMHO) and should affect the original branch atomically.
My changes seem to work well for me, but I don't have a great way to test regressions for this fairly significant approach-change.