Why would a 64bit architecture version of git run differently than a 32bit one? The mind boggles. So at this point, I've figured out what caused my problem but I just don't know why yet. It wouldn't instantly through the error instead, it would try for 10 seconds and then through the error. This would happen when I right clicked on the git message before the git commit message that I actually wanted to rebase and then went to Rebase Interactive From. I was getting when I opened my project in SmartGit, which is just a GUI for git. I wasn't getting this error popping up in the git console though. Leaves incomplete git operation and also adds a file on disk, sh.exe.stackdump with STATUS_STACK_OVERFLOW + register dump. Now, I honestly don't know why this is but I did find a post on GitHub that was talking about certain commands failing on the 64bit architecture, specifically git rebase and certain git merge operations according to that post. The answer was that I was using the 64bit architecture instead of the 32bit architecture. The final answer to my question of why git rebase -i isn't bringing up a preferred editor to even choose whether to reword a commit message or any other option like.
Thanks so much for your help I greatly appreciate it. Is there something I'm missing? Like I said before I could have sworn that this at one time worked perfectly fine with pushed and unpushed commits. When I run the exact same command but with a git commit that hasn't been pushed up to GitHub yet, everything works perfectly fine. # Note that empty commits are commented out # However, if you remove everything, the rebase will be aborted. # If you remove a line here THAT COMMIT WILL BE LOST. # These lines can be re-ordered they are executed from top to bottom. For that we use: git commit -m 'This is our commit message' Now all our staged changes are bind to this commit. git add foldername/filename.js Commit files No we can finally add a commit message to our files. # x, exec = run command (the rest of the line) using shell If we want to do a specific file, we need to use this command. # f, fixup = like "squash", but discard this commit's log message # s, squash = use commit, but meld into previous commit # e, edit = use commit, but stop for amending
# r, reword = use commit, but edit the commit message The problem that I'm having right now is when I run git rebase -interactive I get something that looks like this. I could have sworn that in the past I have used this same command to edit already pushed git commits and have no issues what so ever.
Smartgit commit amend how to#
See "The Perils of Rebasing" section of the Git Pro book for further explanation.I am having the hardest time trying to figure out how to edit a git commit message that has already been pushed to GitHub. It is the same problem as with rebasing (a commit -amend is sort of like a mini-rebase). But that will cause problems for other developers who have based their work on the original commit. You could do your amend and then do a force push git push -f.
The original commit A is still there, but no branch is pointing to it B - AĪnd then amend, you won't be allowed to make a normal push, since that push would not be a fast forward merge local remoteĮxcacerbating the problem: others may have already used your commit local remote The current branch will point to this new commit. Then you change your mind and amend A, that will actually create a new commit A'. Lets say you made a commit A (after a commit B): B - A <- master You cannot replace that commit with another commit. You have already shared the commit with others that may have pulled it and based work on that commit. But when you have pushed the commit it is essentially too late. It is still there, but nothing references it anymore and it will eventually be garbage collected unless something starts referencing it. You haven't really altered the original commit. What git commit -amend does is to "replace" the previous commit with a similar, but altered, commit.
0 kommentar(er)
