People being dicks in Coding Help suck



  • Continuing the discussion from Git/Atlassian Stash - how do combine commits before making a PR?:

    @Polygeekery said:

    Part of that is assumed that those asking for help will not be a dick to those attempting to help them.

    If Eldelshell had been attempting to help me, your post might make some sense. He was obviously not. His CLI command with no explanation was just posted to get my goat, and his StackOverflow link has no solution to the problem.


  • Grade A Premium Asshole

    Seriously blakey, when you ask for help on Git you act like a man who needs someone to hold their dick when they take a piss, else they piss all over the place.

    You asked for help. You did not ask for someone to write you a tutorial. Part of asking for help is that help will vary. Some of it will not be applicable, you can either ignore it or explain to the person why it is not applicable so that they might be able to refine their answer.

    But the bottom line is, if you shit all over those who try to help you, do not expect good help. You started out by shitting on everyone preemptively when you said:

    @blakeyrat said:

    I support there's approximately zero chance that any useful GUI for this feature would come from anybody who thinks using Git is a good idea?

    That seems condescending and it was in post #2, before anyone even had a chance to answer.



  • @Polygeekery said:

    You asked for help.

    Correct. None of Eldelshell's posts were even slightly helpful, AS HE ADMITTED HIMSELF WHEN HE ACTUALLY BOTHERED TO READ THE QUESTION.

    @Polygeekery said:

    You did not ask for someone to write you a tutorial.

    What I'd much rather have is a tool that does this intuitively so there's no need for a tool for anybody. I'm fucking sick of EVERYTHING about Git being so goddamned pointlessly complicated and difficult.

    @Polygeekery said:

    You started out by shitting on everyone preemptively when you said:

    How is that "shitting on everyone"? At best it's "shitting on people who write Git and clients for it", who frankly deserved to be shat on because their tools are all crap.

    @Polygeekery said:

    That seems condescending and it was in post #2, before anyone even had a chance to answer.

    Condescending to who?

    I just drew a picture of the thing I'm looking for.



  • @Polygeekery said:

    if you shit all over those who try to help you, do not expect good help

    Funny, that's what blakey said to @wood...



  • suck Help Coding in dicks being People


  • Grade A Premium Asshole

    @blakeyrat said:

    Correct. None of Eldelshell's posts were even slightly helpful, AS HE ADMITTED HIMSELF WHEN HE ACTUALLY BOTHERED TO READ THE QUESTION.

    So don't shit on him. You yourself respond to stuff without properly reading. It happens, move on.

    @blakeyrat said:

    What I'd much rather have is a tool that does this intuitively so there's no need for a tool for anybody.

    So...write one? The tools we have work well enough for everyone else. I use Git every day and I am OK with it. Not blown away, not driven to rage, I am just OK with it.

    @blakeyrat said:

    How is that "shitting on everyone"? At best it's "shitting on people who write Git and clients for it", who frankly deserved to be shat on because their tools are all crap.

    There is a disconnect somewhere. I read:

    @blakeyrat said:

    I support there's approximately zero chance that any useful GUI for this feature would come from anybody who thinks using Git is a good idea?

    ...and it seems directed at anyone who thinks that using Git is a good idea. I must have mistakenly gotten that impression from when you said:

    @blakeyrat said:

    anybody who thinks using Git is a good idea

    I guess, somehow, that is my error? Alrighty then.

    @blakeyrat said:

    Condescending to who?

    @blakeyrat said:

    anybody who thinks using Git is a good idea

    @blakeyrat said:

    I just drew a picture of the thing I'm looking for.

    ...and then shit on:

    @blakeyrat said:

    anybody who thinks using Git is a good idea

    Here is the problem as I see it:

    1. Your boss does not like your workflow (From what I gather, your check-ins before leaving are actually a good idea. He doesn't do that and thinks it is "noisy". C'est la vie.)

    2. You are trying to use a tool in a manner it was never initially intended to be used in. (Using a CLI tool with a shoehorned GUI)

    3. Your boss gets annoyed that he has to squash all of your commits to fit his mold of a proper workflow and level of "noisy".

    4. You need to be working someplace that does not use Git, or anything else that you rage against...good fucking luck with that. Your list of triggers could fill an encyclopedia.



  • Get over it, your title was wrong:

    And based on your title, the answer is straight forward.

    Yes, I might have missed the part about the remote branch, but rebase is actually done using the remote branch as reference:

    All changes made by commits in the current branch but that are not in <upstream> are saved to a temporary area.

  • :belt_onion:

    They're also using Git completely wrong, and that's probably why Blakey's hitting issues.

    note that this is not a personal attack against blakey, because he probably didn't set it up that way!

    You're having problems because you aren't using the tool correctly. Your stated company workflow is the reason behind this. Unfortunately, there's not much you can do other than just compromise and do the best you can.



  • @sloosecannon said:

    Git completely wrong

    Really? Only because they want to reduce the amount of noise? :crazy:


  • :belt_onion:

    @Eldelshell said:

    Really? Only because they want to reduce the amount of noise? :crazy:

    Yup.

    I agree the white noise commits aren't useful, but again, that stems from Git being used wrong (because no stash being used, etc). The other commits are, in fact, useful.



  • He can create his own workspace by branching from the branch.
    Then his commits to the test branch will be less noisy, and he'll have the security of his end of day commits.


  • Grade A Premium Asshole

    @xaade said:

    create his own workspace by branching from the branch.

    Good candidate for an Xzibit meme.



  • @Eldelshell said:

    Get over it, your title was wrong:

    No it's not. The pull request is created from the remote branch. AFAIK, the change HAS to be in a remote branch before you can create a PR for it. (Although I'm sure you're going to tell me it doesn't if you use the easy-to-remember command "git -dsad -rewasd "frogsuit" -dsadaue -*.* +236p")

    @sloosecannon said:

    They're also using Git completely wrong,

    How?

    @sloosecannon said:

    I agree the white noise commits aren't useful, but again, that stems from Git being used wrong (because no stash being used, etc). The other commits are, in fact, useful.

    There is NO WAY, using Git, to put my code changes on a server without also creating a commit message. This isn't our problem, this is Git's problem. Because this problem is FUCKING OBVIOUS and Git somehow, in 10 years, hasn't solved this FUCKING OBVIOUS problem.

    @xaade said:

    He can create his own workspace by branching from the branch.

    From which branch?

    @xaade said:

    Then his commits to the test branch will be less noisy, and he'll have the security of his end of day commits.

    What's "the test branch"? This concept came out of nowhere.


  • I survived the hour long Uno hand

    @sloosecannon said:

    using Git completely wrong

    What is the RIGHT way for a large corporation to use Git? Assume the following requirements:

    • Not losing work in progress when a developer gets hit by a bus
    • Not having to retrain all their devs who are not used to using git or maybe even unused to the command line
    • The ability for non-technical workers like graphic artists and BAs to submit things like logos and requirements documents that would benefit from version control

    I've never heard anyone ever say "This is how you meet those goals with git", always just "Well that way is wrong."


  • :belt_onion:

    @blakeyrat said:

    There is NO WAY, using Git, to put my code changes on a server without also creating a commit message. This isn't our problem, this is Git's problems. Because this problem is FUCKING OBVIOUS and Git somehow, in 10 years, hasn't solved this FUCKING OBVIOUS problem.

    That's not a problem! Why do you think that's a problem?!?!?!?!?!



  • @Yamikuronue said:

    I've never heard anyone ever say "This is how you meet those goals with git", always just "Well that way is wrong."

    Because it can't be done.

    @sloosecannon said:

    That's not a problem! Why do you think that's a problem?!?!?!?!?!

    The "development" branch, the log of our product's development from day one to present, the number one Source Of Truth for our entire codebase and this entire company's income source, has a change labelled "work in progress going home for the day".

    You don't see that as a problem?


  • Grade A Premium Asshole

    @Yamikuronue said:

    I've never heard anyone ever say "This is how you meet those goals with git", always just "Well that way is wrong."

    You could change "Git" for anything Linus Torvalds or Richard Stallman have ever produced and it would still make sense.


  • :belt_onion:

    @Yamikuronue said:

    * Not losing work in progress when a developer gets hit by a bus

    Push often, just like with other VCSes.
    @Yamikuronue said:
    * Not having to retrain all their devs who are not used to using git or maybe even unused to the command line

    • The ability for non-technical workers like graphic artists and BAs to submit things like logos and requirements documents that would benefit from version control

    I won't disagree with those points, having had to deal with both of them personally.

    When I said they're using Git wrong, I was saying attempting to force all your changes into one commit is using it wrong. You should have a lot of commits, that's not a bad thing!


  • :belt_onion:

    @blakeyrat said:

    The "development" branch, the log of our product's development from day one to present, the number one Source Of Truth for our entire codebase and this entire company's income source, has a change labelled "work in progress going home for the day".

    You don't see that as a problem?

    No... I don't understand why you do...


  • I survived the hour long Uno hand

    So let me just expand here.

    The solution is to:

    • Set up a remote repo on the central server
    • Push at least once per day so all your work gets into the central server

    Haven't you just re-invented CVCS using DVCS? So then, what is the "git way" of doing this that's radically different than the "svn way" of doing it?


  • :belt_onion:

    Yeah, and that's pretty much how it's used...

    Sheesh people, I'm not a DVCS/Git apologist here... I'm just pointing out that the way Blakey's boss is telling him to do things is not how the tool was intended to be used!



  • I've never heard anyone ever say "This is how you meet those goals with git", always just "Well that way is wrong."

    Unfortunately, this is because Git users tend to be idiots.

    The whole point of git is that it is an API for a version controlled file system. It's not supposed to define a workflow for you. You're supposed to script your own.

    In that spirit, people should be saying "This, broadly speaking, is how to do what you want. You can script it in your favorite language".

    But instead, they latch on to the default front end tools and say "durp". And this is why Git is such a mess. Because the default scripts make hugely broad assumptions (that are wrong for many work-flows) and also expose internals. It's the worst of both.

    What is the RIGHT way for a large corporation to use Git?

    They should probably script the API, in conjunction with continuous integration tools and the like.


  • I survived the hour long Uno hand

    SVN can't give me a detached head.

    Therefore, SVN wins. ¯\_(ツ)_/¯

    @sloosecannon said:

    I'm not a DVCS/Git apologist here

    I was asking the room at large, because I'm still waiting for a good answer in general. Didn't mean to attack you personally.


  • I survived the hour long Uno hand

    @Captain said:

    people should be saying "This, broadly speaking, is how to do what you want. You can script it in your favorite language".

    Got an example of a scripted workflow compatible with my stated goals I can crib off of? Giving me a whole blank canvas and saying "The joy is you can paint whatever you want!" is unhelpful if I'm still trying to figure out how to work a paintbrush.


  • :belt_onion:

    @Yamikuronue said:

    I was asking the room at large, because I'm still waiting for a good answer in general. Didn't mean to attack you personally.

    Very well then :)


  • Discourse touched me in a no-no place

    @blakeyrat said:

    You don't see that as a problem

    Theoretically speaking, if your primary concern were the company not losing your work if you got hit by a bus, then a daily backup before going home, that other people knew about, would get rid of the need for a superfluous commit.

    Also, I take your point about it being you unwieldy to have multiple repos on your machine. Would having some VMs, one per branch, help any? Then each branch could be in the same place. (I realize other issues, like "laptop not good enough for that", could get in the way.)



  • For your goals, I would consider:

    and also consider a multi-layer architecture of repos. You would want each developer to have his own gitfs repo (on a shared machine, to eliminate the hit-by-bus problem), for "scratch work" or whatever. And then actually commit to the shared, centralized repo, via scripting (i.e., a button that does ssh user@gitfs.company.com git push) .


  • :belt_onion:

    @Captain said:

    For your goals, I would consider:

    and also consider a multi-layer architecture of repos. You would want each developer to have his own gitfs repo (on a shared machine, to eliminate the hit-by-bus problem), for "scratch work" or whatever. And then actually commit to the shared, centralized repo, via scripting (i.e., a button that does ssh user@gitfs.company.com git push) .

    I have a feeling throwing more "shitty open source tools" at @blakeyrat probably will not do any good :)


  • I survived the hour long Uno hand

    @sloosecannon said:

    at @blakeyrat

    Today one of the team leads came to me and mentioned he'd gotten permission to report on why git makes sense for us.

    Two days ago one of the designers gave me access to his "off the books" gitlabs server where he's storing some design documents while they're in progress.

    This is all very relevant to my interests as well.


  • :belt_onion:

    Wow, I didn't even see the reply to, so I buttumed it was in response to Blakey. Carry on then.......

    Filed Under: Context fail



  • @FrostCat said:

    Also, I take your point about it being you unwieldy to have multiple repos on your machine. Would having some VMs, one per branch, help any?

    No.

    You're utterly ignoring the second reason the "multiple branches" solution doesn't work.


  • Discourse touched me in a no-no place

    @blakeyrat said:

    No.

    Ok then. I knew it would have it's own potential problems, but it sounded like it could have gotten rid of some of the existing ones.

    @blakeyrat said:

    You're utterly ignoring the second reason the "multiple branches" solution doesn't work.

    No, I couldn't find the post because I was on my phone. If you want to link back to it I might try to address it.


  • Grade A Premium Asshole

    @blakeyrat said:

    The "development" branch, the log of our product's development from day one to present, the number one Source Of Truth for our entire codebase and this entire company's income source, has a change labelled "work in progress going home for the day".

    You don't see that as a problem?

    Name it "In case I get hit by a bus". Problem solved.



  • @Captain said:

    Unfortunately, this is because Git users tend to be idiots.

    You could say that about computer users in general.

    @blakeyrat said:

    I'm fucking sick of EVERYTHING about Git being so goddamned pointlessly complicated and difficult.

    I work in a mixed IT/non-IT team and nobody there ever complained about Git being too hard. Sure, the non-technical team members like perforce (that is the only available alternative because corporate policy) better, since it actually has a usable GUI. It has shitty documentation, though. We also had a short encounter with SVN, which I hope to forget someday.

    'Git is too complicated and difficult' sounds weird from a SW engineer. You are supposed to know what you are doing when using a VCS. If you don't, ask for training before you break something. Squashing commits before pushing them out is standard practice in a Git environment.



  • @eskel said:

    'Git is too complicated and difficult' sounds weird from a SW engineer.

    Why?

    @eskel said:

    You are supposed to know what you are doing when using a VCS.

    I do.

    @eskel said:

    If you don't, ask for training before you break something.

    I do.

    @eskel said:

    Squashing commits before pushing them out is standard practice in a Git environment.

    Then how do you commit when you leave the office?


  • :belt_onion:

    @blakeyrat said:

    I do.

    Says the guy who refuses to learn Git on the command line...



  • @sloosecannon said:

    Says the guy who refuses to learn Git on the command line...

    Correct.

    I'd be losing code every week if I was attempting to use a CLI and Vi to control the shit, believe me.



  • @blakeyrat said:

    @eskel said:
    'Git is too complicated and difficult' sounds weird from a SW engineer.

    Why?

    Because VC is a complicated problem unless you work in a team of two people and commit once a month.

    @blakeyrat said:

    Then how do you commit when you leave the office?

    git commit ... Oh, you mean push, not commit. I don't. Why would I? Is the ongoing work you do on your machine backed up properly?



  • @eskel said:

    Is the ongoing work you do on your machine backed up properly?

    Sigh.

    The only folder on my work laptop backed-up is the network drive.

    I probably can't work off the network drive because I know from experience that both Visual Studio and SQL Server have issues when told to work off network drives.

    Even assuming I could, if I kept my source in the network drive, then I'd no longer be able to work remotely and there'd be no point to me having a laptop in the first place.

    You're willing to take the risk of losing your employer's work. I'm not. I'm a professional.


  • :belt_onion:

    @blakeyrat said:

    You're willing to take the risk of losing your employer's work. I'm not. I'm a professional.

    As is he, I'm sure. It's pretty ridiculous to be that paranoid about a hard drive crash...


  • Grade A Premium Asshole

    @sloosecannon said:

    It's pretty ridiculous to be that paranoid about a hard drive crash...

    ...or being hit by a bus...



  • @blakeyrat said:

    Visual Studio and SQL Server have issues when told to work off network drives.

    That sucks and is a WTF in itself.

    @blakeyrat said:

    You're willing to take the risk of losing your employer's work. I'm not. I'm a professional.

    Gods, no! Where do you get theese ideas? I just have proper backups of my daily work. If what you describe really is a problem, then someone else working there must have encountered it as well. How do the other people do this? You could store a private branch upstream. You could use intermediate software like Gerrit. Hell, you could even add a hook to propagate your local changes to the network drive.

    @Polygeekery said:

    being hit by a bus

    In this case, your boss being angry seems kind of irrelevant.


  • I survived the hour long Uno hand

    @eskel said:

    you could even add a hook to propagate your local changes to the network drive.

    Actually, there's an idea: put a working copy (or whatever the right word is in git-speak) on the network drive and just sync to it at the end of the day, rather than work from it.



  • @eskel said:

    If what you describe really is a problem, then someone else working there must have encountered it as well.

    That's why I'm so amazed there's no solution to the problem!



  • Doesn't change the fact that merging the commits together is a wide-awake nightmare involving the use of Vi.



  • Set your EDITOR variable to whatever you want.



  • Shhh... He knows what he's doing.


  • Grade A Premium Asshole

    @eskel said:

    Shhh... He knows what he's doing just wants to bitch.

    FTFY



  • @eskel said:

    You could store a private branch upstream.
    He's freaking doing that. But to push to that private branch you have to commit, and his boss is complaining that results in too many small, nonatomic commits.

    (The solution, of course, is to (1) get a Git client that doesn't suck and (2) rebase your branch. Or don't be so paranoid about losing a couple hours of work.)


  • Discourse touched me in a no-no place

    @blakeyrat said:

    I'd be losing code every week if I was attempting to use a CLI and Vi to control the shit, believe me.

    Or you could learn to use them properly.


Log in to reply