I commited several files to my repo without having a .gitconfig file with username and e-mail details, so git took the wrong e-mail I specified in my linux /etc/hostname file.
This is the repo I'm talking about, the grayed-out commits with name "Leslie King" don't link to anything:
https://github.com/zoliky/dotfiles/commits/master
Is there anything wrong in leaving as is? I don't really want to mess with modifying the git log. I will continue commiting with the good e-mail from now on. I'm just wondering if there's anything wrong in leaving the old commits as is.
No, under normal circumstances this will not be a problem.
The only place it may be an issue would be if you were making submissions to a larger Open Source project that requires all submitters to sign a contributors agreement, the automated systems that manage these would see this code as being contributed by 2 separate people (1 per email address).
If you really want to "fix" it then you could look at this set of instructions https://help.github.com/articles/changing-author-info/
Related
I have recently contributed some files to my github account. You can find it under here. The contributions are correctly displayed in the contribution activity under the graph. However, the graph does not update (the squares don't become green). I have read all the helps from Github, checked out dozens of webpages, but I simply can't find a solution. Can you guys do?
Thank you so much for your help!
Can you try another web browser, or clean your browser cache?
I see the green square on graph for 3 contributions from "Sep 18, 2016".
It will probably be something with caching in your web browser.
There isn't quite enough to go off here so I'm going to go out on a limb.
My guess is that you had the repo and everything was fine. Then you got a new computer, downloaded the files, are able to change and push but (as you mentioned) no credit the work you did. If that's the case, what is likely is that you have a config problem. Github is crediting someone or something else, just not you.
How to fix it:
git config --global user.name "<your github user name>"
git config --global user.email "<the email account you have for github>"
How to tell:
I put this last because the fix is simply easier to do.
On your computer and in the repo that isn't getting credit type
git blame <file you've made recent changes>. Look for two different names. Unfortunately, it doesn't show email but use this as a first go. If you don't see any differences and there is a chance (hence the reason to simply do the fix first) no email is configured or the two emails differ.
git blame --line-porcelain <file you've made recent changes>
From there carefully look at the first two lines (author and author-mail) and look for discrepancies.
We are using CVS for version control and committing and fetching changes in a project.
Often we face the following problem:- CVS is integrated in Eclipse.
Since team is large, people often commit and don't write comment as to who actually committed it. This creates a big problem when someone
changes the code and the identity of that person is unknown.
Is there any way of capturing details of user who commit anything in CVS whether he wishes to tell or not. This way even if someone changes anything in repository without informing anyone the identity and change done by that person can be found out.
CVS records the user ID associated with each commit. Setting up users/passwords is the task of the CVS administrator. Multiple authentication schemes are possible (such as authenticating against the underlying OS, or authenticating against a file), but at the end of the day, a user has to "log in" to a CVS repository in order to be able to use it.
So, as long as your CVS administrator has set up proper authentication, each user will have their own user ID and password to log into CVS.
Try executing cvs log against a file, and you'll see a list of revision numbers, along with details of all committers.
If your CVS repository is not set up with proper authentication, then in a way, you're shooting yourself in the foot here. By allowing people to commit code without properly identifying themselves, you give up the possibility of... identifying committers.
If you'd like to check how your CVS server is configured security-wise, try to look at how you, yourself, are accessing your CVS server. Start by looking at the CVSROOT environment variable (if you're working from the command line), or - if you're working through an IDE - look at the settings of your CVS connection. I find it hard to believe that you can connect to a CVS server in your organization, without really knowing how to do it.
A colleague of mine was working on a VS project this morning, which he claims was in a folder clone of our central repository. He built a release version of the application which is still there with the correct date/time stamp on it.
He then said he committed several times during this time, but at some point, he tried pulling down changes from the central repository and merge them in with his changes. He can't really remember what steps he took, but the end result is that all the changes he did to the source were lost. now, i'm trying to help him to see if we can recover any of those changes.
He told me after he committed his changes (several commits), He went into the tortoisehg workbench, pulled, and saw that there were many changes in the central repository. He decided to either "Merge with local" or "Update" to the tip pulled down - he can't remember which. I showed him the two dialogs, and asked him if he discarded changes, shelved or anything else. He couldn't remember, really, but he did remember he had to back out because tortoisehg didn't like what he was doing. Eventually, he did seem to be able to update to the repository tip.
I'm thinking that unless he physically deleted the folder in which he was working, and then got the latest, those commits he claimed to have done would have been recorded somewhere? What are common errors people do when pulling the remote repo? Are there any log files or history i can check to see if i can salvage or at least tell where he was working on this stuff?
any hints to troubleshoot this would be greatly appreciated.
First of all backup the tree somewhere including .hg and everything under it. Then...
hg heads
...to see if he's just lost track of his commits. If it's there, it's just a case of updating back to it and doing a proper merge.
hg log -u 'His Username'
...to see if the commits are anywhere in the repo. If they're are there you can then work forward from them.
hg shelve --list
...to see if he's managed to shelve things somewhere
Take a look in .hg/strip-backups, to see if he's managed to strip his changes somehow. Anything else destructive should have left backups in .hg too.
That should be a good start. If none of those give any clues then others may be able to suggest some things.
I don’t know about TortoiseHG, but usually the first thing would be to check hg out.
Help me do some damage! I'm tired of just a half-dozen Google hits that tell me never to do this. Let's muck things up real good! I'm pretty sure that I can get ahold of the actual files in db/transactions, so how can I screw these up in interesting ways? I've looked at SVN::Delta, but I can't even figure out what it's supposed to be doing (letting someone make pretty graphs of changes to a repository? sending coded messages to the CIA?).
I really don't care to hear more reasons why not to do this. I work in an environment with 40 or 50 other people who use subversion. And while we're coding, we need some passwords in web.config files, in DataSource.groovy files, you name it. And just refusing the commit because we left them in is as annoying as hell. We have to save the files with the passwords manually deleted (and we have to open up those files, it's not like they're necessarily open), then once we're done committing we have to put them back just to continue to work? This is a good idea I suppose if you just want to bitchslap people every time they commit until they develop a Pavlovian reflex to never commit anything. And why? Because computers aren't supposed to automate tasks? Because the software client won't know that the pre-commit hook didn't actually save the version still on the developer's machine?
I'm fairly language agnostic here. Show me an example of how to do what you're never supposed to do... which file do I edit from pre-commit? How do I interpret the gobbledygook after the DELTA # # # line? Are there any libraries that will help with that? Let's have some fun!
PS Seriously, no one's created a "bad-ideas" tag? WTF.
It is your build process that is flawed, not Subversion. If you must not commit passwords, do something like the following:
1 - Web.config files should not be committed. Instead, commit files like Web.config.dev or Web.config.qa.
2 - Have your build script rename the appropriate .config file to Web.config, and then do token replacement so that the proper passwords are inserted. This info can come from another file that is also not commited that says what environment you are in (so it knows which .config file to use), and what the passwords are.
I just started using github.com and my friend and I are working on a project. How can I pull parts of the project but check out certain files I'm working on so he doesn't work on them. He can still download the files but he won't be able to open or edit them until I upload them back and give permission?
I suppose you mean lock a file when you edit it. Git won't let you do this and it's not something you need to worry about. Instead, you can both work on the same file and then merge your changes later.
If you really want to work that way (i.e: lock files, or at least control when your friend will modify your repo), you can ask your friend to fork your repo.
That way, he/she:
will have his/her own copy of said repo
will work on any file
will rebase first with branches fetched from your repo (added as a remote on his/her fork, as described in GitHub: working with remotes)
will make pull request, allowing to decide what to include and when.
Historically version control systems provide a checkin/checkout feature. When you do a checkout, you reserve the artifact. If another person also has the same file checked out, then you get an error when trying to checkin the artifact. Not sure creating another fork is really the equivale