In which Mott555 gets confused by Github
-
So I just authored a couple really simple Minecraft mods, specifically for Spigot. I decided to release them even though I just wanted them for my own personal server. This means I had to launch a github account.
I never really understood git but stumbled through it well enough to commit my mod source. Since this topic is public, I'll refrain from posting my gamer handle in text, but some of you may know it...and it's in the unsearchable image below...the new github account is under that.
However, even though my git repository on github is showing my code that I just pushed using my login and my password, it is attributed to some user named KodekPL whom I don't know!!!
Is basic user tracking beyond github's ability?
-
specifically github attributes authorship to the recorded email for commits. there are collisions if you fail to set that correctly.
There are design reasons baked into git that are traceable back to torvalds as to why this is but basically github does not assume the pushing user is the author user.
-
That is ridiculous...I know you can pay for github, I wonder if they randomly charge other people's cards when you don't set some field correctly?
-
And from that link:
But I did use my email address associated with my GitHub account
-
nope authorship of commits isn't something you pay for.
just repo space and/or private repos.
your repo is still yours, but git matched emails for your commit to a different user.
yes it's more than a little stupid but there are design reasons for that, and there are certain usage patterns that make use of that functionality so it can't be changed easily
-
But I did use my email address associated with my GitHub account
accalia_de_elementia@sockdrawer:~/workspace/ArkSaddleRecipe (master) $ git log commit 3ef8d1bdc502a679bf6e1d6005c1aafc5b47f193 Author: BuildTools <unconfigured@null.spigotmc.org> Date: Mon Jul 13 18:42:47 2015 -0500 Initial check-in. commit 753f1c761e6cd5ee70657ac95ba6938f6ac53e32 Author: aRottenKomquat <a***t@o***.com> Date: Mon Jul 13 15:58:19 2015 -0500 Initial commit accalia_de_elementia@sockdrawer:~/workspace/ArkSaddleRecipe (master) $
Huh. so you did.... (email address censored to avoid spambot spam)
-
Author: BuildTools <unconfigured@null.spigotmc.org>
Hmm...perhaps the process for downloading Spigot somehow globally screws up git...because this certainly has nothing to do with my mod and everything to do with the Spigot file I downloaded.
-
Welp...I just officially spent more time working around Git than I did on developing and deploying the mod itself...
-
Welp...I just officially spent more time working around Git than I did on developing and deploying the mod itself...
Welcome to Git.
-
-
So, to summarize:
SVN workflow:
- Add files
- SVN commit
- Enter username
- Enter password.
- Done.
Git workflow:
- Add files
- git push
- Enter username
- Enter password
- Rewrite git history to use correct username because git totally ignored the username I just gave it and decided to use some other random user's instead.
- Wonder rewriting history is even a thing....oh because it was probably easier to write that feature than fix the stupid push command using a random username.
I don't think I could write software that messed up if I tried.
-
I love how the two commits on the repo have exactly the same message that tells me nothing about what's in them.
Example of one of my commit messages:
-
git push
Enter usernameWell there's your problem. If you enter your username AFTER you've already made the commit, how is it supposed to put it in the commit?
-
he cloned via https not ssh apparently.
that would be the github username
-
I love how the two commits on the repo have exactly the same message that tells me nothing about what's in them.
I love how Ben Lubar's being a snide asshole.
-
I learned from a master.
-
he cloned via https not ssh apparently.
Clone via ssh didn't work and I don't remember why. https just worked.
I wish someone would make a github-like thing for subversion. Just a big, free, public SVN server.
-
You can use your GitHub repository with a svn client.
-
That sounds worthy of further investigation.
-
I wish someone would make a github-like thing for subversion. Just a big, free, public SVN server.
Wikipedia has a list of such things: https://en.wikipedia.org/wiki/Comparison_of_source_code_hosting_facilities#Available_version_control_systems
-
-
Git workflow:
- Add files
- git push
- Enter username
- Enter password
So, git is a little different than SVN.
- Git carries commit authorship around with each commit in the repo. (This is why git urges you to configure your identity before you start making commits.)
- Everyone who has cloned a copy of a git repo has a complete copy of that repo. Folks decide which copy is the canonical copy and push to and pull from that.
- When you "git commit", git uses your local identity information to attribute the changes you're committing to your local repo.
- When you "git push", git pushes the new commits from your local repo -along with their attribution information- to the canonical (aka: "remote") repo.
- "git push" does not rewrite commit attribution information. "Git push" is the second half of the SVN commit operation (get the commits to a remote repository); "git commit" is the first (create a(n) commit(s), with log message(s)), though -as mentioned- git does commit attribution before it pushes, rather than after.
Anything that makes commits to your local git repo -including yourself- can set the attribution of a commit to whatever it wants. It looks like the SpigotMC build tools needed to know what identity you wanted them to use when they made a build or whatever. (Notice that the log that accalia pulled up attributes the strange commit to "Author: BuildTools unconfigured@null.spigotmc.org".)
I wager that if you configure your SpigotMC build tool, this problem will go away. :)
-
Clone via ssh didn't work and I don't remember why.
Did you upload your SSH public key?
If you have an SSH keypair, skip to step four: "Add your SSH key to your account.": https://help.github.com/articles/generating-ssh-keys/
If you don't have an SSH keypair, and don't know how to create one, feel free to ask anyone but Blakeyrat. If you're on a *nix system, and you follow the instructions in that Github help article, IMO Step 3 is completely optional. I don't use an SSH agent on my machines.
-
Wonder rewriting history is even a thing....oh because it was probably easier to write that feature than fix the stupid push command using a random username.
Rewriting history (via "git rebase --interactive") is super useful if you're like me and you make a billion little "checkpoint" commits throughout the day (so you can roll back to a known-good state when you fuck up your code while working on it). At the end of the day (or whenever you want to publish your code), you can combine those billion little commits into a series of larger commits that make logical sense, rather than having to worry about that while you're in the middle of coding. You can even reorder (or remove) commits, if that makes the history make more sense.
Another thing to remember is that git branches are (like in SVN) labels to a given commit and its history. But -unlike SVN- every significant change you make to your local repo is kept around -by default- for 90 days.
So, if you (somehow) seriously screw up a history rewrite, and didn't label the branch that you started from (or make note of its commit hash), you can dig around in git's history to find the commit hash and make it a branch.
This is all substantially less complicated than it might seem. (It seemed pretty complicated to me when I was starting out, but I played with it for a few days, grew to understand it, and now can't live without the power that this way of working gives me.) Additionally, I'm pretty sure that 90% of Blakeyrat's problems with git have to do with whatever shitty GUI-over-top-of-git he has been forced to use that day. I exclusively use the git CLI and never run into the issues that he does.
-
(This is why git urges you to configure your identity before you start making commits.)
Except it never urged me to configure anything.
I wager that if you configure your SpigotMC build tool
I wish I knew what this means.
-
Except it never urged me to configure anything.
That would be because someone else got there first and set your name to
BuildTools
and your email address tounconfigured@null.spigotmc.org
.
-
Except it never urged me to configure anything.
Did you follow these instructions or something similar to them? https://www.spigotmc.org/wiki/spigot-s-bukkitapi-mac-osx-1-8-tutorial/
If you did, notice that step 2 tells git that your name is "BuildTools" and your email address is "unconfigured@null.spigotmc.org", and overwrites any previous values for those properties(!). This is... less than optimal. In fact, it's incredibly stupid. It's pretty clear that whoever wrote this tutorial has no regard for the safety of novices' data, or is -themselves- an FNG. :/
Edit:
If you're on a *nix and you do
git config --global -l | grep -e user.name -e user.email
you can tell what git thinks your name and email address are.
-
Ah, so the source of the stupidity is the people who forked a project and antagonized the upstream, while fostering a culture of adding 20 flags to your java command line.
(Note for Spigot apologists: I said festering, not promoting.)
I don't suppose that this is a good time to be telling @mott555 that he should really be using Sponge/Forge/Gradle?
-
-
Eh, festering, fostering, close enough for @accalia
-
A little too close for @accalia...
-
while fostering a culture of adding 20 flags to your java command line
The worst thing about Java is still the vast amount of incompetent developers who think they can use that language.
-
If you're on a *nix and you do
It does not have to be unix. The git-bash in windows behaves enough like unix to support the same.
git config --global -l | grep -e user.name -e user.email
I would simply do
git config user.name
and
git config user.email
as separate commands. Without the
--global
this prints the effective values used in the current repository.
-
I would simply do
git config user.name
and
git config user.emailas separate commands.
Ordinarily, I would do that too. However, given that Mott555 appears to be a git neophyte (and might be confused by the data he got if he checked the config in an entirely unrelated repo) and that the most likely HOWTO munged his global git config, I felt that peeking at the global git config was most appropriate. :)
Your comment about git-bash is spot on. I couldn't find a sufficiently terse way to introduce it, so I left it out.
-
Git workflow:
- Add files
- git push
- Enter username
- Enter password
- Rewrite git history to use correct username because git totally ignored the username I just gave it and decided to use some other random user's instead.
- Wonder rewriting history is even a thing....oh because it was probably easier to write that feature than fix the stupid push command using a random username.
Should have just used
git-authenticate-commit
...
-
-
At the end of the day (or whenever you want to publish your code),
But it had better be before you leave for the day, or else you're an idiot who misunderstands the fundamental concepts of git.
-
I never really understood git but stumbled through it well enough to commit my mod source.
Bad, bad idea.If you know CVS and/or Subversion, Git will be alien to you. Linus hates CVS and its ilk with a passion, and allegedly would have renamed concepts to spite CVS "fans". Here's an excerpt from a tech talk at Google:
@Linus Torvalds said:I credit CVS in a very very negative way. Because I, in many ways, when I designed git, it's "what would Jesus do" except that it's "what would CVS never ever do"-kind of approach to source control management. I've never actually used CVS for the kernel. For the first 10 years of kernel maintenance, we literally used tarballs and patches, which is a much superior source control management system than CVS is, but I did end up using CVS for 7 years at a commercial company, and I hate it with a passion.
When I say I hate CVS with a passion, I have to also say that if there any SVN users (Subversion users) in the audience, you might want to leave. Because my hatred of CVS has meant that I see Subversion as being the most pointless project ever started, because the whole slogan for the Subversion for a while was 'CVS done right' or something like that. And if you start with that kind of slogan, there is nowhere you can go. It's like, there is no way to do CVS right.
Or further along:
@Linus Torvalds said:Being distributed very much means that you do not have one central location that keeps track of your data. No single place is more important than any other single place. So for example this is why I would never touch Subversion with a ten-foot pole. There is a massive subversion repository and it's where everybody has to write. And the centralized model just does not work when,... let's look at a few of the cases.
This is why Git doesn't use your Github credentials when pushing: Github is no more important than your local copy. You need to configure your own credentials (user, email) somewhere on your system if you wish that the
commit
command picks up on it or you need to pass the--author
parameter every time you run the command.Really, git is more about writing history, so it has tools at your disposal to do it. When you have a consistent history locally, a
push
is then nothing more than convincing the server that your history is canon rather than telling the server "add change x to the global history".You do need to verify that you created the correct history though, otherwise you have to start cleaning it after the fact like you had to do now.
-
Should have just used git-authenticate-commit...
That page reads like Star Trek technobabble to me...it's just words strung together...
-
That page reads like Star Trek technobabble to me...it's just words strung together...
Which is different to an actual Git manpage how?
-
That mindset is so alien to me...SVN is easy to set up, easy to use, easy to configure, and most of the time Just Works. So Torvalds set out to do the exact opposite of that? And apparently succeeded.
Which is different to an actual Git manpage how?
I never looked at them, I just used Github's tutorials, which are apparently inadequate and/or not quite correct.
-
That page reads like Star Trek technobabble to me...it's just words strung together...
Damn... he noticed!
-
Oops, I missed the
This is NOT real git documentation! Read carefully, and click the button to generate a new man page.
at the top. Still, what does that say about Git that fake documentation was indistinguishable from real documentation to a newbie?
-
Oops, I missed the
This is NOT real git documentation! Read carefully, and click the button to generate a new man page.
at the top. Still, what does that say about Git that fake documentation was indistinguishable from real documentation to a newbie?
That page reads like Star Trek technobabble to me...it's just words strung together...
...you did notice it was nonsense.
-
...you did notice it was nonsense.
Actually I didn't. I figured I didn't understand it because I don't know Git, and was trying to make a jab at Git in response. I whooshed.
-
SVN is easy to set up, easy to use, easy to configure, and most of the time Just Works.
You've not seen how badly fucked a SVN repository can get.
-
I've never seen an SVN repository get messed up. And we have some repos with a very WTF structure...tags within trunk within branches within other projects in the same repo within tags done by people who don't quite think like software devs....
-
Still, what does that say about Git that fake documentation was indistinguishable from real documentation to a newbie?
And how do you know if you
I never looked at them
?
To be honest, I find most git tutorials starting from the wrong end. Git is not hard once you understand the core concept, but because of how the commands grew haphazardly and organically on the core if you start with recipes for this and that operation, you have slim chance of gleaning that concept from it and it will just look like confusing mess to you.
So what I believe the tutorials should do is start by explaining versions and patches, history as a directed acyclic graph of them, still generally, and then introduce the git object types and git refs as their git representation.
Git calls many of it's concepts with new words and I think it is right, as it's trying to make you learn their meaning without preconceptions from other systems. Unfortunately many tutorials try to translate them into Subversion terms and it simply does not work, because they are
fundamentally different.
They are more fundamental. You can explain Subversion in Git terms, but not the other way around. Because the directed acyclic graph is always there, but Subversion complicates things by having commits on branches and consequently asymmetric merges and generally distinguishing cases that are not distinguished in Git.
-
This post is deleted!
-