• Dilbertino (unregistered)

    O(n^2) version control. Neat!

  • (cs)

    zip -ur derpecated.zip comment.1.st

  • Complete Looney (unregistered)

    git filter-branch --index-filter 'git rm --cached --ignore-unmatch derpecated.zip' HEAD

  • (cs) in reply to Complete Looney
    Complete Looney:
    git filter-branch --index-filter 'git rm --cached --ignore-unmatch derpecated.zip' HEAD
    I *think* that's saying that git's capabilities are all there, in spades, but that it isn't remotely clear that it *can* do all these things so people don't explore what it can do. That exploration takes time, you know (and yes, I realise that you gain some benefit from doing it, but by all that's holy, I need to fix this one-off thing *now*, not spend an unknown time searching for how exactly to do what I need to do when I won't need to ever do it again...).
  • Frz (unregistered) in reply to Steve The Cynic
    Steve The Cynic:
    Complete Looney:
    git filter-branch --index-filter 'git rm --cached --ignore-unmatch derpecated.zip' HEAD
    I *think* that's saying that git's capabilities are all there, in spades, but that it isn't remotely clear that it *can* do all these things so people don't explore what it can do. That exploration takes time, you know (and yes, I realise that you gain some benefit from doing it, but by all that's holy, I need to fix this one-off thing *now*, not spend an unknown time searching for how exactly to do what I need to do when I won't need to ever do it again...).
    Yes and the answer is right there, right now. It's also quite accessible on StackOverflow and if it wasn't people would provide it within hours after asking.
  • (cs)

    'Course in Perforce, you'd just "p4 obliterate derpecated.zip" and have done with it... I think it's even smart enough to wipe out changelists that only reference the obliterated file. (And no, in a real system you don't let just anybody have obliterate rights, of course.)

    (Yes, I like Perforce. I store all manner of (Finnish words) in it at home, and my repository backs up in a big ol' tgz that currently tips the scales at around 8GB. And I've occasionally obliterated stuff that I didn't want in the repository anymore. It seems to just work.)

  • np (unregistered)

    Beware of people that repeatedly refuse help but are obviously stuck. They likely just don't want to be caught in the mess they put themselves in.

    Best to explain to them that they are causing the company money even if they work best alone. If they aren't getting work done, then they are just sucking money from the company.

  • I work best alone (unregistered) in reply to np

    = furiously masturbating at desk.

  • (cs)

    I hope that he wrote commit messages at least; let's say informational commit messages (Git would normally not allow empty commit message, but "v012" as a description of changes doesn't really help much).

    The solution is to create custom importer / exporter, based e.g on https://github.com/git/git/blob/master/contrib/fast-import/import-zips.py . And perhaps use reposurgeon to clean up history.

  • (cs)

    The Inner-Platform Effect applied to VCS.

  • foo AKA fooo (unregistered)

    So TRWTF wasn't that nobody bothered to check on the new guy's changes? The repo size exploding by some orders of magnitude didn't ring any bells before it was too late?

  • GWO (unregistered) in reply to np
    np:
    Beware of people that repeatedly refuse help but are obviously stuck. They likely just don't want to be caught in the mess they put themselves in.
    Beware also of "team leaders" who don't keep an careful eye on those people, and let them dig themselves into the sort of disaster that ends like the story above.
  • (cs) in reply to I work best alone
    I work best alone:
    = furiously masturbating at desk.
    Yeah, git can be like that.
  • (cs)

    Ah! One of my favourite flame wars: You'll add binaries to our repo over my dead body.

  • Tux "Tuxedo" Penguin (unregistered) in reply to ubersoldat
    ubersoldat:
    Ah! One of my favourite flame wars: You'll add binaries to our repo over my dead body.

    What if those binaries are actually required for the application to work? Like data files containing game's levels, etc. or images used as icons within the application?

  • (cs)

    Someone please clue me in WTF a giant crying ... ? Potato? Crisps Packet? Has to do with this story? I'm sure I'm just being dumb, or maybe it's an unfamiliar cultural reference. Hmm.

  • (cs) in reply to Zagyg
    Zagyg:
    Someone please clue me in WTF a giant crying ... ? Potato? Crisps Packet? Has to do with this story? I'm sure I'm just being dumb, or maybe it's an unfamiliar cultural reference. Hmm.

    Nevermind; google image search; know you meme. Forever alone. Got it.

  • Daniel (unregistered)

    DERPecated... hahahah funny. :P

  • MojoSlim (unregistered)

    TRWTF is that the manager had multiple clues that someone was amiss, including statements about committing binary files, and didn't at least check the repo himself. If his code was any good, they just lost a good dev (who just needed to learn how to use proper source control), to a bad manager.

  • Donny (unregistered) in reply to MojoSlim
    MojoSlim:
    TRWTF is that the manager had multiple clues that someone was amiss, including statements about committing binary files, and didn't at least check the repo himself. If his code was any good, they just lost a good dev (who just needed to learn how to use proper source control), to a bad manager.
    Sadly... THIS, right here. I know, we can all sit here and spout that a professional developer knows all about source control, etc etc. Unfortunately, that's not always true of the best skilled developers - especially ones that are happy to work alone.
  • Good Dev (unregistered) in reply to MojoSlim
    MojoSlim:
    TRWTF is that the manager had multiple clues that someone was amiss, including statements about committing binary files, and didn't at least check the repo himself. If his code was any good, they just lost a good dev (who just needed to learn how to use proper source control), to a bad manager.

    A dev who refuses to ask for help when he's having problems is not a good dev.

  • (cs) in reply to MojoSlim
    MojoSlim:
    TRWTF is that the manager had multiple clues that someone was amiss, including statements about committing binary files, and didn't at least check the repo himself. If his code was any good, they just lost a good dev (who just needed to learn how to use proper source control), to a bad manager.

    It does make me wonder if perhaps it was a local Repo and had never made it up to the shared repro....that is the power and pitfall of distributed source control.

  • lulzputz (unregistered) in reply to TheCPUWizard
    TheCPUWizard:
    MojoSlim:
    TRWTF is that the manager had multiple clues that someone was amiss, including statements about committing binary files, and didn't at least check the repo himself. If his code was any good, they just lost a good dev (who just needed to learn how to use proper source control), to a bad manager.

    It does make me wonder if perhaps it was a local Repo and had never made it up to the shared repro....that is the power and pitfall of distributed source control.

    Which would be a WTF in itself on the managers part.

  • (cs)

    Hmm, I thought .zip would by default compress each file individually, which would mean that most part of the .zip file would stay the same (unless, of course, the user zipped the old .zip (instead of its content) together with the changed files into a new .zip).

    On the other hand, git filter-branch can really take ages, and in case of a quite old repo created with an old version of git (I think that somehow did not include the author in the root commit - that particular repo was github.com/rapid7/metasploit-framework if anyone wants to try to remove all .mp3 and .dll from its history) can run a few hours and then abort on an internal error. Nothing that cannot be fixed (first run filter-branch with a filter that corrects the author) but you can indeed spend a long time fixing history in git...

  • GWO (unregistered) in reply to Good Dev
    Good Dev:
    MojoSlim:
    TRWTF is that the manager had multiple clues that someone was amiss, including statements about committing binary files, and didn't at least check the repo himself. If his code was any good, they just lost a good dev (who just needed to learn how to use proper source control), to a bad manager.
    A dev who refuses to ask for help when he's having problems is not a good dev.
    True, but as faults go, that one is a relatively easy fix. Tell them not to be afraid to ask for help, and if that doesn't get a response, start scheduling regular progress updates and/or code reviews.
  • Derp (unregistered)

    Derp

  • (cs)

    The first thing when backing up source code is not to make complaint about redundancy. That is one place where redundancy is good.

  • neminem (unregistered)

    Yeah, the real WTF is definitely a manager willing to agree that "works best alone" (which is fine) should extend to "not looking into a guy having a problem for days". I mean, if nothing else, complaining about git could mean he was doing it wrong, but it could also mean something that should really have been looked into by IT. That's what a manager is for.

    That said, the other real WTF is git. I freaking hate git.

  • (cs) in reply to Good Dev
    Good Dev:
    MojoSlim:
    TRWTF is that the manager had multiple clues that someone was amiss, including statements about committing binary files, and didn't at least check the repo himself. If his code was any good, they just lost a good dev (who just needed to learn how to use proper source control), to a bad manager.

    A dev who refuses to ask for help when he's having problems is not a good dev.

    Dev meaning god.

  • (cs)

    Oh my glob… It's like he challenged git with the following taunt: "Hey git! Bet you can't efficiently store that!", then proceeded to come up with the worst version control torture test the world has ever seen.

  • (cs) in reply to neminem
    neminem:
    That said, the other real WTF is git. I freaking hate git.

    people who cannot use software always hate them. like "forum favorite blackeyrat" hates lotus notes.

  • amomynous (unregistered)

    To the hell with the git abuse WTF, I want to know if William was really competent and churned through the issues like a proper professional (minus the git part) like the article seems to imply.

    Please?

  • Mikerad (unregistered) in reply to Nagesh
    Nagesh:
    neminem:
    That said, the other real WTF is git. I freaking hate git.

    people who cannot use software always hate them. like "forum favorite blackeyrat" hates lotus notes.

    To be fair, anyone who doesn't hate lotus notes obviously never used it.

  • (cs)

    Derpecated is such an appropriately Freudian slip.

  • (cs)

    derpecated.zip

    Please tell me that was the actual name of the file and not a typo or creative addition on TDWTF's side.

  • Josh (unregistered) in reply to vt_mruhlin

    TRW checking binary files into a repo is the easiest way to deal with our current workflow because Sharepoint is a PoC:

    http://www.gfycat.com/ArtisticIncomparableGerbil

    CAPTCHA: plaga Binary files are a plaga on repos

  • ¯\(°_o)/¯ I DUNNO LOL (unregistered) in reply to Nagesh
    Nagesh:
    neminem:
    That said, the other real WTF is git. I freaking hate git.
    people who cannot use software always hate them. like "forum favorite blackeyrat" hates lotus notes.
    Wait, you mean there's someone (other than the VP that's golf buddies with a Lotus rep) who actually likes Lotus Notes? And I've had to use it in two jobs, ten years apart, so I know of the horror that is Bloatus.
  • anon (unregistered) in reply to vt_mruhlin
    vt_mruhlin:
    derpecated.zip

    Please tell me that was the actual name of the file and not a typo or creative addition on TDWTF's side.

    From the source: One mysterious file, derpecated.zip<-- intentional mispelling -->, drew Dan’s attention.

  • Drive by Release Engineer (unregistered)

    The real WTF is the lack of any sign of code review in this organization. For new employees in particular, there should be plenty of warnings that something untoward is going on, no matter what VCS you choose to use. Yeah, if he never pushed, you'd never know, but how was this code being deployed without a proper build automation plan?

  • anonymous (unregistered) in reply to Good Dev
    Good Dev:
    MojoSlim:
    TRWTF is that the manager had multiple clues that someone was amiss... If his code was any good, they just lost a good dev ... to a bad manager.

    A dev who refuses to ask for help when he's having problems is not a good dev.

    TRWTF: I was once working on a huge InstallShield project for a company and stood by my assertion that it wouldn't be able to do a dependent install, then reboot the machine and automatically continue with the next stage. When it was already written to do that, in a four stage process.

    The project lead was gracious enough to suggest a couple of places in the IS documentation, and matching points in the existing code, and gave me the time to figure it out. My apology and a check-in showing I understood how to modify one of the stages AND the next stage trigger, was sufficient and we moved on.

    All in all, a very good learning experience in many ways.

  • Rumpelstilzchen (unregistered)

    Yeah, I'll turn all your code into gold for you, no problem.

  • Subversion weenie (unregistered)

    Can someone explain how adding a file to a zip causes a delta "nearly as large as the archive itself"? Adding more files doesn't change how pre-existing files are compressed, and any half-decent binary diff algorithm should be able to take advantage of that.

  • (cs)

    Dear Article Author:

    You're using the wrong brand of LED bulbs. Sincerely,
    The Modern Day.

  • EatenByAGrue (unregistered)

    Important lesson learned: Never believe a developer when he says something is done.

    Software is truly done when it's:

    1. Checked into the code repo.
    2. Reviewed by a peer or two.
    3. Through a round of QA in a test environment.
    4. Pushed live / shipped to customers.
    5. QA'd again in whatever qualifies as the live environment.
    6. Verified a week later to make sure that it's still working as it should.

    Even in a 1-person shop like I usually am in, I go through all those steps except step 2. But when I'm running a team, you can bet that I'm watching that code repo like a hawk and will notice when you tell me something is done when it's not even checked in.

    Also, never believe a developer who says something is 90% complete. A typical project status goes from 0% to 50% to 90% to 95% to 96% to 97% to 98% to 98% to 98% ... only asymptotically approaching 100%. That's because the dev believes they only have to fix the last bug, only to discover there's another last bug.

  • Klimax (unregistered)

    Funnily enough, Subversion with its efficient handling of binary data would hide this problem for along time.

    (I like SVN (By way of TSVN :D) and use it, also I consider as sane (D)VCS Mercurial; GIT and Bazaar are bizarre...)

  • Calli Arcale (unregistered)

    I think "derpecated" is my new favorite word of the day. :-D

  • AP² (unregistered) in reply to Tux "Tuxedo" Penguin
    Tux "Tuxedo" Penguin:
    ubersoldat:
    Ah! One of my favourite flame wars: You'll add binaries to our repo over my dead body.

    What if those binaries are actually required for the application to work? Like data files containing game's levels, etc. or images used as icons within the application?

    Use git-annex.

  • (cs)

    Sounds like this guy was on the autism spectrum.

  • Zan Lynx (unregistered) in reply to chubertdev

    It's a spectrum. Literally everyone is "on the autism spectrum" somewhere.

  • (cs) in reply to Zan Lynx

    Do you work for Microsoft? Your comment is accurate, but completely useless.

Leave a comment on “Forever Alone”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article