• and? (unregistered)

    git add .frist

  • bvs23bkv33 (unregistered)

    .git disregard

  • DocMonster (unregistered)

    This is why while git is a great tool you learn to use it first before you just decide to use it otherwise you end up ignoring people who actually know what the fuck they're doing because everyone else is like well we've always done this way and we don't want someone else to tell us were doing wrong

  • Patrick_The_Pedant (unregistered)

    I'll confess, I've been working with git for years and I still don't feel like I grok it. The test isn't really whether you can get it to do what you want it to do. It's whether you can un-foul up what you, or someone else, just did, when you do something unusual.

    Recently, for example, I thought I'd got the hang of this scenario: You need to make a hotfix to master, so you branch off master, then merge back in. You then need to merge the same hotfix back into develop, but in a way that means the next time you need to merge release branch into master (having originally branched the release off develop), you don't have to rebase. So I think that at that point your merge into develop has to use 'git cherry-pick' so that you get the same hotfix commit that was in master into develop, not a different commit with the same changes. But last time I tried it I totally fouled up and ended up having to merge master back into develop, because I couldn't figure out how to undo what I did. And suddenly all my faith that I knew how git worked was shaken.

    To anyone who says condescending things about people who don't know git on this thread - are you sure you actually know all about it? Or do you just know enough to do things your way? (For starters, if you don't know prune, autosquash, the difference between a subtree and a submodule, and how to use annotate, then you don't know more than me, and I don't know much about git!)

  • ThatAnnoyingGit (unregistered)

    git config --local core.excludesFile .gitignore-local

    (and no, you don't have to add .gitignore(-local) to the repo to make it work - it's just more convenient to keep it in there to ensure that it stays in sync everywhere)

  • Tom (unregistered)

    A 100MB repo isn't uncommon... A fairly large project with a few months of history can reach it easily.

  • Jakub Narębski (google)

    WTF? How hard is to resolve merge conflicts in .gitignore file? If git cannot resolve it, then do it by hand. It is not a rocket science.

    Also, if a file (like .gitignore) is tracked by Git (is in repository), then it would not be ignored. Only unknown/untracked files can be ignored.

  • GopiKrishnan G (unregistered)

    Does it mean like "ignore the .gitignore forever" so that nothing can be ignored whilst checkin. Looks like a clever way to circumvent .gitignore using .gitignore. However, I was able to add and commit .gitignore with '.gitignore' in it. Am I missing anything ?

  • (nodebb) in reply to Patrick_The_Pedant

    Yeah you never rebase a branch that you have pushed. Otherwise you'll revert changes made by others between your checkout and the rebase point. This has happened at my work because he reckons a rebase is "cleaner" than a merge. I disagree.

    You should always be able to merge master into develop so you can merge hotfix branches into both. Our usual method is to just merge master into develop after merging in a hotfix.

    If someone creates a feature branch (off develop) which later needs to become a hotfix (off master) then we create a hotfix branch and cherry-pick the changes in.

    My biggest pet peeve at the moment is the way our repo handles LF vs CRLF conversions. The initial setup didn't bring it from SVN properly so we now get conflicts depending on who's editing what...

  • Haxton (unregistered) in reply to Patrick_The_Pedant

    My approach to spreading the hotfix would be to also merge it into develop, so that you don't have to worry when you merge next release into master.

    Judging from the other reply, though, it is not The Solution. I'm new to corporate git, so if my answer is wrong, could someone elaborate as to why? I'm curious.

  • Mixed Metaphor Man (unregistered)

    Or you can do the sane thing and have one person (or the entire team) do the merges to develop to ensure that everyone signs off on the merge and there isn't a conflict that has been overlooked.

  • jaja (unregistered) in reply to Patrick_The_Pedant

    git cherry-pick actually gives you 'a different commit with the same changes'. It cannot be the same commit since it will have a different parent.

    No saying I know more about git, just trying to clear up some confusion.

  • (nodebb) in reply to Tom

    Indeed, 100MB seems ... small.

    $ du -h .git --max-depth=1
40K     .git/info
607K    .git/logs
303M    .git/objects
150K    .git/refs
308M    .git

    And we don't have libraries in the repo: those are all loaded via package tools from build scripts. Indeed, the vendor folder is in .gitignore and is currently 283M in my working copy.

  • Kabi (unregistered)

    A 100MB Repo? That's ... cute.

    We have a core repository whose latest revision has a size of ca. 700MB. This repository is linked in all our projects via svn:external, creating its separate copy on our disks for every project we work on. Checking out another project or creating a new one takes up to 15 minutes...

    Worst part: This is considered normal

  • jaja (unregistered) in reply to Patrick_The_Pedant

    Also, you never 'have to rebase'. Rebasing is always purely optional (except when using git-svn, but then that's an entirely different situation where you're using git as an svn client). In a way rebasing is cheating/lying. You change history by saying 'this is what happened' while it's not actually what happened.

    Rebasing has it's advantages sometimes. I sometimes rebase my feature branch onto develop to re-organise all changes in a more logical fashion and patch op typos in commit messages. This makes it easier for my coworkers to see what I meant to do. But it can lead to screw ups as well when you make a mistake during rebasing and you end up commiting stuff in the wrong order, leading to problems when you later want to do a git-bisect and you have unbuildable commits in your repository.

  • (nodebb)

    My Perforce repository at home squishes down to a 9GB .tgz when I back it up. (Stop p4d, run tar over the repository, restart p4d.)

    The main reason it is so large is my habit of checking in substantial binary files (spreadsheets, a large .docx with every paper letter I write, various sorts of image file, etc.), combined with my wife's habit of doing that and not setting "revert if unchanged" in the GUI commit dialog box.

    Well, all that and it having 16 years of commits.

  • Adam H (unregistered)

    I think our main repo is ~400-500MB, primarily binary files that we didn't understand early on. I've wanted to do a bug fix up of history for a while, but just haven't had a chance.

    I'd say TRWTF is that solving merges in .gitignore isn't any different than in code files, so it should be handled fine. I bet they didn't configure a default one, so everyone was touching it early on and having conflicts. So rather than understanding and learning, they .gitignored the correct solution. (My company did something similar with submodules, but that's a story for another day)

  • Ron Fox (google)

    git is TRWTF

  • Steve (unregistered)

    this one is definitely made up

  • ApoY2k (unregistered) in reply to jaja

    Just as a follow-up; what if you forgot to add issue IDs to two or more commit messages. Rebase is the only chance to change the messages and push it to remote. For me this is the most common usecase for rebasing, right?

  • Zslatkei (unregistered) in reply to Zemm

    D:\Work\Cust\prj.git>du -sh . 969M .

    includes 2 Sparks, 2 hadoops, 200 Mb of test data files... deleted.

  • Jedi Mind Trick (unregistered)

    Whatever you do, DO NOT think about blue elephants.

  • Sarcasto (unregistered)

    Also remember, when you make commits with git it is crucial to use a meaningful and helpful git commit message, if you're ever stuck you can use this automatic git commit message generator

    http://whatthecommit.com/ (joke)

  • wjr (unregistered)

    One-upping all the one-ups on repository size: 86 terabytes in a single repository. http://cacm.acm.org/magazines/2016/7/204032-why-google-stores-billions-of-lines-of-code-in-a-single-repository/fulltext

  • Ace (unregistered)

    I misread the first 2 sentences has JavaChip keeping there QA works in cardboard boxes. Must have been some large cardboard boxes in which a desk could fit. Not to say that a cubicle is much different.

  • Kjella (unregistered) in reply to Steve_The_Cynic

    "Well, all that and it having 16 years of commits."

    Impressive, since git is only 11 years old...

  • Smoke 003723 (google)

    Using .gitignore to ignore .gitignore? Is this what they mean about being trapped in a cycle of ignorance?

  • Not Steve (unregistered) in reply to Kjella

    I thought the same thing, but the literal second word of that comment was Perforce which is ~20ish I believe

  • Karl Bielefeldt (github) in reply to Not Steve

    You can have commit history older than a version control system, because of importing.

    Is anyone else waiting for the other shoe to drop? There's nothing different about resolving merge conflicts in .gitignore compared to any other file, so I'm wondering if they have some convoluted process for the merges they can't avoid. Is a sequel to this article in the works?

    Also, so many WTFs happen on someone's first commit. Maybe the first commit should become the last round of the interviewing process.

  • (nodebb)

    Maybe Brent thought 100MB was large compared to what he expected based on what he'd been testing in QA.

  • Peter Gordon (github) in reply to Karl Bielefeldt

    I have access to the AmigaOS4 subversion repo (yes, yes, thats already several real WTFs, I know), and that has commits going back to the 80s :-)

  • (nodebb) in reply to Kjella

    Good thing I was talking about a Perforce repository, I guess.

    Addendum 2016-10-07 06:26: And I started on version 2000.1.

  • TheCPUWizard (unregistered) in reply to wjr

    re: Google's massive repository - it is not Git!!!!!!

  • ricecake (unregistered)

    Obligatory XKCD: https://xkcd.com/1597/

  • jonny_q (unregistered)

    None of this makes sense to me :(

    I agree with the other comments that 100MB is not large at all. git checkouts contain all history, and that can get to 100MB easily.

    git 'commits' are local. How did they get pushed to anywhere Karla could see them? Unless he decided to blindly push changes upstream... on his first day with no review.

    Yeah, having log files in the repo is obviously not good, but they're obviously in a transition period and Karla just hasn't worked that part out yet.

  • Pietro Gagliardi (andlabs) (unregistered) in reply to ThatAnnoyingGit

    While this would work, git has a mechanism for user-local repo-specific ignore files that doesn't require any additional configuration:

    "Patterns which are specific to a particular repository but which do not need to be shared with other related repositories (e.g., auxiliary files that live inside the repository but are specific to one user’s workflow) should go into the $GIT_DIR/info/exclude file."

    where if $GIT_DIR is not set git uses the project's top-level .git folder.

    Brent, if you're reading this, consider it.

  • anonymous (unregistered)

    TRWTF is pushing a project-config level change on your first day on team

    (I won't add 'just having transitioned from doing QA. since the story didn't say if he was just doing testing or was a qa-engineer... but sounds like the former)

    I don't care if you know git 1000% better than the project lead - you don't make any changes, much less project-effecting changes on your first day on the job - without asking!

    If he by mistake pushed when he though he only checked in locally - fine, that's his bad. But didn't sound that way from his response to the lead.

    Sounds like the QA role was a better fit

  • Norman Diamond (unregistered)

    Brent, if you're reading this, consider it.

    The repository for git's git history will be this thread? TDWTF is going to be famous!

  • Chris McCall (unregistered) in reply to jaja

    It's not "cheating" or lying. History is meant to express intent, which is the only thing important in life. Once you work in a real dev shop you're going to feel sorry for your former self.

  • GorGutz 'Ead 'Unta (unregistered) in reply to anonymous

    Indeed. I keep seeing these "oh! Something that looks wrong to me! I think I'll change it! major system problems ensue Oh shit, maybe I shoulda asked why this was before messing with it." stories. Failure to talk to other people causes shit like this to happen. Also why couldn't his leader just call from home instead of coming down to the office to tell him to revert a change that they knew he made? Couldn't she have just called him to ask or called a minion to revert the change and tell him about it?

Leave a comment on “.gitignorant”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article