Blakeyxkcd and the years and years of struggling with broken software that just so happens to use git
-
your complaints should be targeted at your company and not against the tool that doesn't fit your use case.
He knows that:
Companies invariably choose Git about a month before they hire me, so I never get any say in the process.
And this was even in this very same thread.
-
...for a company developing a proprietary product, a centralized VCS that allows you to keep all artifacts associated with the project in one place, simplifies administrative tasks such as revising commit messages, unpublishing sensitive data, notifying coworkers about which files are currently being worked on, etc would be more appropriate
If you're not storing huge binaries in your repo, it sounds like something like Gerrit (along with git commit --amend to rewrite commit messages) will do everything you want except the unpublishing bit and the file locking/notification bit.
(And for the unpublishing stuff, it would be trivial to write a Gerrit plugin that runs
git gc --aggressive --prune=allon demand, so you can force-push a new branch that doesn't have the sensitive data, prune the repo, and purge the data. Obviously, you'll then need to talk to your cow-orkers, but -honestly-, if they're nefarious, they will hear you coming and stash a copy of the sensitive data. ;))I'm not saying that you should use git. I'm saying that many people use git in as a CVCS that has really fast branch/compare/history perusal/rollback operations, and have written tools to help make this mode of operation easy.
-
git mergetoolopens files that have merge conflicts in your merge resolution tool of choice. (Rungit mergetool --tool-helpto see what merge resolution tools are supported on your system.)The fixup and squash stuff @JazzyJosh is talking about is a feature of
rebase --interactive(AKA interactive rebase).
-
Oh, I guess I've never needed to use rebase for anything other than squash and so I forgot fixup existed.
-
Making your database text is dangerous, because it will grow. Imagine a world where every table record field and thirty other columns of data describing every setting of a field in your database exists within a text file in source control, because the original was too hard to diff... One that has been added to for 30 years, and people are too terrified to delete anything from.
shudder
-
Making your database text is dangerous,
Yeah, but we're talking about some data that they put into a database for the specific purposes of specific tests. Not a full prod database or anything. At least, that was my understanding.
-
As long as you're careful with stuff like that. It isn't worth risking what we ended up with here.
-
As long as you're careful with stuff like that.
Oh, believe me! Whenever we hire someone, I make sure it ain't blakey before I give the thumbs up.
-
Whenever we hire someone, I make sure it ain't blakey before I give the thumbs up.
I just imagined you interviewing yourself and loled…
-
Status: Dumb git things: To selectively stash changes as well as newly added files, first stash the changes you want to keep, then stash the changes you actually want to stash, then stash pop the changes you wanted to keep
x-post!
-
Oh, believe me! Whenever we hire someone, I make sure it ain't blakey before I give the thumbs up.
How do you know I don't already work for a 140-year-old angry man who hates Cuba?
-
How do you know I don't already work for a 140-year-old angry man who hates Cuba?
If you did, it wouldn't be me. I love Cuba! Just not the murdering commies who currently run the place.
-
How do you know I don't already work for a 140-year-old angry man who hates Cuba?
Bit of a long commute.
