If you had very long lived feature branches, you might want to generate merge commits, but even then, I would probably figure out some way around it. Generally, I try to make sure that any feature branches get pulled into the main development branch fairly regularly. I want to present a picture of a perfect series of sequential commits in my main branch. Press enter on a line to view the commit where the line changed, or g to see other available maps. Force this behavior for any command with :Git -paginate or :Git -p.:Git blame uses a temporary buffer with maps for additional triage. I personally prohibit merge commits entirely in any workflow I have anything to do with, if only to make rebase happiness. :Git diff, :Git log, and other verbose, paginated commands have their output loaded into a temporary buffer. Now I need to identify the commit hash (hashes) which added those lines (deleted 38,39 and 40 lines) to the file, but the blame view for the file shown in here does not show the history for the deleted lines. Commits reachable from any of the commits given on the command line form a set, and then commits reachable from any of. With any luck, it will go all the way through and you'll have a new clean branch where that folder was never deleted in the first place. You can think of this as a set operation. Now, check the file again to make sure there's nothing bad in it, and then execute it in your shell: source cherries.sh This will mean that the script stops if there is any problem and doesn't keep going, applying all sorts of useless commits after an error. The Repositoriestool window will open containing the snapshot of your project at the selected revision. File Blame will color code the commit author of each line or hunk. File History shows that file’s commit history on the left. You may also click on a commit in the graph and then right click a file to access File History or File Blame. Select a commit and choose Show Repository at Revisionfrom the context menu. To access either option, click to view the file diff and the options will appear in the upper right. Also remove any commit reverting that one. Open the Gittool window Alt+9and switch to the Logtab. Remove it or you won't actually fix the problem. The first line will cherry pick the deletion of "client" dir. This leaves you with a file cherries.sh that will cherry pick all the non-merge commits. I'm assuming that exactly your merge commits contain the string "Merge pull request", which is true of this one codebase I'm experimenting on - you should check the history to find a grep that exactly only matches merges! Now, do this one-liner: git log -reverse -oneline -grep="Merge pull request" -invert-grep fixed.feature \ Go back to the commit ID before deleting /client and then git cherry-pick all non merge commits after that.Ĭreate a new branch fixed that ends with the last commit before "temp removed client dir" Here's a hacky solution if you're on *nux or Cygwin, but one that will work, and likely without user intervention, and you'll end up losing the merge commits. Git rebase -preserve-merges or -rebase-merges is supposed to do that, but I never really got my head around these. Git rebase -i is the logical solution, but you have a ton of merge commits in there, and this is preventing rebasing, am I right?
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |