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!!!

    :wtf: Is basic user tracking beyond github's ability?


  • FoxDev

    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 :wtf:


  • FoxDev

    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


  • FoxDev

    @mott555 said:

    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)



  • @accalia said:

    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...



  • @mott555 said:

    Welp...I just officially spent more time working around Git than I did on developing and deploying the mod itself...

    Welcome to Git.


  • Discourse touched me in a no-no place

    @dcon said:

    Welcome to Git.

    Check in with @blakeyrat to get your "I Hate Git club" decoder ring.



  • So, to summarize:

    SVN workflow:

    1. Add files
    2. SVN commit
    3. Enter username
    4. Enter password.
    5. Done.

    Git workflow:

    1. Add files
    2. git push
    3. Enter username
    4. Enter password
    5. 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.
    6. Wonder :wtf: 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:



  • @mott555 said:

    git push
    Enter username

    Well 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?


  • FoxDev

    he cloned via https not ssh apparently.

    that would be the github username



  • @ben_lubar said:

    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.



  • @accalia said:

    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.



  • @mott555 said:

    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




  • Grade A Premium Asshole

    @mott555 said:

    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. :)


  • Grade A Premium Asshole

    @mott555 said:

    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.


  • Grade A Premium Asshole

    @mott555 said:

    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.



  • @bugmenot said:

    (This is why git urges you to configure your identity before you start making commits.)

    Except it never urged me to configure anything.

    @bugmenot said:

    I wager that if you configure your SpigotMC build tool

    I wish I knew what this means.



  • @mott555 said:

    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 to unconfigured@null.spigotmc.org.


  • Grade A Premium Asshole

    @mott555 said:

    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?



  • @riking said:

    I said festering

    Liar.



  • Eh, festering, fostering, close enough for @accalia



  • A little too close for @accalia...


  • Winner of the 2016 Presidential Election

    @riking said:

    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.



  • @bugmenot said:

    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.

    @bugmenot said:

    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.


  • Grade A Premium Asshole

    @Bulb said:

    I would simply do

    git config user.name
    and
    git config user.email

    as 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.


  • Discourse touched me in a no-no place

    @mott555 said:

    Git workflow:

    1. Add files
    2. git push
    3. Enter username
    4. Enter password
    5. 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.
    6. Wonder :wtf: 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...


  • Grade A Premium Asshole

    @PJH said:

    Should have just used git-authenticate-commit

    You're mean.


  • I survived the hour long Uno hand

    @bugmenot said:

    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.


  • Fake News

    @mott555 said:

    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.



  • @PJH said:

    Should have just used git-authenticate-commit...

    That page reads like Star Trek technobabble to me...it's just words strung together...


  • kills Dumbledore

    @mott555 said:

    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.

    @Jaloopa said:

    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.


  • Discourse touched me in a no-no place

    @mott555 said:

    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?



  • @mott555 said:

    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?

    @mott555 said:

    That page reads like Star Trek technobabble to me...it's just words strung together...

    ...you did notice it was nonsense.



  • @powerlord said:

    ...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.


  • Discourse touched me in a no-no place

    @mott555 said:

    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....



  • @mott555 said:

    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

    @mott555 said:

    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!

  • Discourse touched me in a no-no place

    @mott555 said:

    I whooshed.

    That reminds me...


Log in to reply