I'm new to git, and to GitHub. I'm using the GitHub for Windows program on Windows 7 64-bit. What I dislike is that when I create a new local repository, the initial change where the .gitattributes file is added is given a commit message containing an emoticon (seemingly chosen at random).
Here is a screencap of this problem in action: http://i.stack.imgur.com/sXVkv.gif
The emoticon in the above example was "confetti ball": http://i.stack.imgur.com/ePYdv.png
How do I prevent this emoticon? Or at least, how do I prevent the inital change from being automatically committed so that I have the opportunity to edit the commit message to remove the emoticon?
Even though I'd prefer to interact with the program's GUI, I have enough practice with the command line that if the fix for this issue requires using it, I'm comfortable with that.
Any help for this would be much appreciated.
git commit --amend
, then edit the commit message, then
git push origin master --force
(if the initial commit was also pushed behind your back)
Related
We recently moved to git from svn (both using Eclipse). I am in the (perhaps bad) habit of writing my Java code first, getting everything to work and then going back and adding comments. In SVN this was easy. I would just create a Fisheye review with my Jira task. The review would have a list of all the files I changed and methods I added or modified. I would note it and abandon the review. Then I would edit all the files listed and add the comments.
However, Fisheye does not (I believe) work with git. I could do a git status to see the files I changed but the local branch is already updated so it will not list any files. And all it does is tell me I am something like one commit ahead of the remote branch but does not list any files.
Is there some way to see a lit of the files I have changed with git so I can add comments? And when I say I wait for my comments I really mean mostly for added classes and methods. If I do something like add a line or two to a method I will generally add the comment too.
changing comments on git commits is not that easy. Each git commit has a sha-checksum which also includes the previous git commit. If you change a commit you change the current commits sha-checksum. therefore you create a new commit. All following commits of your branch must now be rebased on top of this new commit.
The command line provides the git rebase -i [commitid] where you can do lots of modifications including changing comments on commits. I never did this with a GUI but egit might support that too. Just refer documentation on egits rebase feature.
I found out how to do this.
The "Synchronize Workspace" in eclipse appears to show all the changed files not yet pushed remotely. I have not done any pushes, so this showed me what files changed.
I'm transitioning from using Subversion in Eclipse for code management to GitHub in RStudio. It's starting to make sense, but I can't seem to figure out how to pull effectively.
Specifically, if I use the Pull arrow in RStudio, every file change in the repository automatically updates my local files without warning. I can see how many files were updated, but not what changed!
Here are the questions I'm hoping to get help with:
1) Can I preview the repository file changes in RStudio before I pull them locally? With SVN in Eclipse, there was an indicator showing files with a difference, and the option to view side by side.
2) If multiple files have been changed on the repository, is it possible to pull just 1 locally?
3) How can I revert a local file to a previous version?
Right now I've been trying to do this all within RStudio for simplicity. I haven't used things like the GitHub desktop client.
I appreciate the help!
I would suggest you better get used to the git's own tools to stay informed about your repository.
For example you could do following.
Before you pull, check your current commit logs
git log
This should show you how your current commits stack up. Note the latest commit id (first 4-5 letters would usually do)
Now after pulling you can see the difference using following command
git diff --color your_previous_commit_id..HEAD
If you don't like the changes and want to go back,
you can just reset to your favorite commit with following command. BTW run "git stash save" to keep a copy of your uncommitted changes.
git reset --hard you_favorite_commit_id
Note: that this will delete all your uncommitted changes unless you stashed them and put your local branch behind the remote repo branch you are tracking again.
Wondering where to put these commands? Check https://git-scm.com/downloads.
What's good about using these git tools is that if you switch between IDEs you don't need to search for same functionalities you had in your earlier IDEs.
I have 2 branches: master & develop. I have been developing in "develop" and committed everything I need. What was left (application generated file: .out) I didn't care for! So when I went to switch branch, I got prompted following:
I clicked "Reset" however instead of switching to the branch I got prompted the same "Checkout Conflicts" windows with exactly the same choices. I clicked "Reset" again, however above process just repeated. I clicked a while -- no help the same happens again and again. More over I encountered the same scenario on different eclipses (Juno, Kepler) and different OS (Mac & Windows).
Am I doing something wrong? I don't want to commit or stash the file, I just want it to be reset. Is it a bug? Or there is a solution?
Thank you.
Add *.out to your .gitignore to get rid of those files once and forever.
In my version of egit, when i select reset, the reset window opens. Seems like a bug in your version. Try updating egit (not only eclipse).
If it still doesn't work, you can also use Team -> Reset... to perform a reset. After that you should be able to change the branches.
Actually, there are a few more ways to kill a file:
just delete the file
commit it and then reset the branch to the commit before that (effectively getting rid of that commit)
commit it and then perform an git rebase -interactive and delete the corresponding line
Feel free to edit this post and add more ways of violently killing a file from git!
I have a local development system where I have a Ubuntu-Server VM and I use eclipse in windows host. I develop in eclipse using Remote System Explorer & SSH. I want that whenever I save a file or do some changes in ubuntu-server's /var/www/site-folder it automatically commits and pushes the changes in my git repo. I did try the google but it wasn't much of a help. Any help is appreciated guys. Really wanna improve my workflow.
This sounds like something you'll have to script. If you save as much as I do (a lot), then you'll end up with a lot of commits. Unless you're careful about when you save, you'll probably end up with a messy history, unless you squash things later.
Are you sure that you want to commit and push automatically every time you save? It also matters whether or not you're pushing to your own private branch or repo.
Actually I think there are use cases where this /is/ a good idea. If you work on two different machines (even not simultaneously), for instance, you cannot share the Eclipse workspace. One simple way to overcome this is to put a bare git repository on a cloud server (dropbox, copy, one drive, etc) and push all work, completed or otherwise, to that everytime you close eclipse.
Will the repo be messy? Sure, but that's not the point.
I could find no easy hooks within Eclipse itself to automate this so I simply put an invocation of Eclipse in a script and finished off with:
git commit -a -m "WIP commit"
git push origin
You just have to watch out for newly-created files and remember to add those before you exit.
Is there a way in GitHub to change a commit message if I've committed with a message that has a typo or something dumb written in it?
I know you can do the ammend commit thing (which replaces the previous commit) from the CLI, but is there a way to just edit the commit message from the GitHub.com site interface?
If the problem commit is more than one commit ago, you have to fall back to interactive rebase. For example, if you notice a misspelling three commits ago, you would type something like this:
git rebase -i HEAD~4
Then rebase would open up your default editor with a view that looked something like this:
pick c5052cb Updated the workshop instructions
pick 6d6cd60 Upgraded to the plugin 0.6.1
pick c6d0921 Upgraded wrapper to Gradle 1.2
pick 7a111da Upgraded to 0.7 of the Liquibase Gradle Plugin.
# Rebase 097e6b2..7a111da onto 097e6b2
#
# Commands:
# p, pick = use commit
# r, reword = use commit, but edit the commit message
# e, edit = use commit, but stop for amending
# s, squash = use commit, but meld into previous commit
# f, fixup = like "squash", but discard this commit's log message
# x, exec = run command (the rest of the line) using shell
#
You'd want to edit the third line (the one referring to commit c6d0921) to start with the word "reword" instead of "pick." Once you save and exit from the editor, you'll find yourself right back in the editor with that commit's message in front of you. Correct your misspelling, save and exit, and all is well.
Note that doing this or doing a commit --ammend is dangerous business if you've already pushed these commits to an upstream repo. This is why there's no way to do this on GitHub.com directly. If you want to change commits you've already pushed, that's a separate matter entirely. :)
There isn't a way to do it directly on the site.
You could:
git commit --amend
git push --force origin master
One of the main reasons we don't want to allow people to do this on the site is because it'd change the entire structure of the commit (basically just think of this as changing the commit hash). This isn't a problem when it's only you, but for the sake of a community of people working with you, this is a problem because no one else will have that commit, and when they try to pull they run into issues.
This is the same as doing the ammend on the command line AFTER you've pushed, then force pushing to github.com. Usually a major no-no for workflows unless you take care with a lot of extra communication.