Blakeyxkcd and the years and years of struggling with broken software that just so happens to use git
-
-
Instead of in the product's installer?
Pulled in from e.g. Sharepoint (or something else that's good a managing binary blobs) when the installer is built?
-
-
TIL blob is an acronym.
-
something something do one thing and do it well
We probably have one of the smallest and most efficient codebases that handles all of the Affordable Care Act rules. Hell, probably over a gig of that is just the damned list of canonical procedure codes.
Most of the people doing this work are doing it in Java codebases running on OS/400.
-
Pulled in from e.g. Sharepoint (or something else that's good a managing binary blobs) when the installer is built?
Why not just put it in the source control so it's right there and your build server doesn't have to talk to like 54 other servers to do its job?
Look: Git is REALLY shitty at this use-case. The solution isn't to make the use-case unnecessarily complicated and annoying, the solution is to not pick Git in the first place. Because it's REALLY shitty at this use-case.
-
FYI the "something something" was meant to indicate that I don't agree with that Unix philosophy stuff. If you need tens of gigs in source control you'd think management would have considered that when picking a source control system
-
If you need tens of gigs in source control you'd think management would have considered that when picking a source control system
Companies invariably choose Git about a month before they hire me, so I never get any say in the process.
Wait, maybe I have the cause and effect wrong.
Maybe me being a month away from interviewing at a company CAUSES them to switch to Git!
-
Maybe me being a month away from interviewing at a company CAUSES them to switch to Git!
Maybe you're a masochist and secretly love the way Git punishes you for naughty things like trying to check in some code
-
Force push again
-
I'm just surprised it took over 200 posts before someone finally pointed out that storing binary files in your source control system is the real WTF.
-
What if it's version control instead?
-
It's not all source code. But generally: yeah. Why is that a bad thing?
Quantity has a quality all its own.
-
Have you ever noticed that source control, revision control, and version control are all treated as synonyms?
-
Actually, scratch that. Developers that feel mastery of the CLI is an advantage should be barred from developing interfaces at all. Because they end up adding to the list of broken interfaces that have to be learned as arcane secrets to stroke their egos, thinking their broken shit is good software.
That takes things way too far.
A good command line interface boobies an average GUI interface any day. With readline, an application developer can set up command autocompletion very easily. This makes it trivial to make "menus" of possible choices, gives the context of what you've already typed.
So, although you need to know that readline exists and that TAB is the default autocompletion key, once the user has gotten over that minor hump, the user has access to the same kind of contextual selection of choices as a GUI user. And it's scriptable, without learning yet another API. And it can be faster to use.
At my new job, the EHR software makes just about every window the kind where you have to close it to go back a screen. I'm writing and testing queries for the system, and I have to do a 15 click process to get from one context (where I can input the query) to the other (where I can run it).
I would literally be hitting up-up to run the two commands I want in alternation, if this was on the command line.
Flags and other shit are garbage, though.
-
A good command line interface breasts an average GUI interface any day.
Filed under: Softcore software porn
-
Filed under: Softcore software porn
You, my good lady, have my full and undivided attention.
-
A good command line interface breasts an average GUI interface any day.
There are certain things you just have to remember.
- A blind person will hate any program that depends on a GUI
- A deaf person will hate any program that depends on audio notifications
- A colorblind person will hate any program that depends on color-based highlighting.
- A dyslexic person will hate any interface that depends on lines of text being entered character-perfect.
- etc.
-
How embarrassing! Fixed.
-
Dunno what you're all moaning about.
-
-
I thought git was supposed to be hardcore?
-
-
Is outclassing Perforce and ClearCase supposed to be some kind of accomplishment?
Note even that congratulatory text doesn't attempt to claim Git outclasses TFS.
-
Note even that congratulatory text doesn't attempt to claim Git outclasses TFS.
Goes without saying. Even RCS outclasses TFS. So does shitting in a bucket and emptying it on your boss' desk
-
@accalia said:
You, my good lady, have my full and undivided attention.
Here we go again.
you say that like it's a bad thing!
:-D
-
you say that like it's a bad thing!
Not at all. I'm just making an observation.
So far, the cupcake fairy has disappointed. At least you got two underboob pics last time.
Here, let's fix that lack.
-
the cupcake fairy has disappointed.
the cupcake fairy is at work for another ten minutes or so and doesn't want to get flagged by a content filter ;)
-
How's this?
Or this
-
I'm just surprised it took over 200 posts before someone finally pointed out that storing binary files in your source control system is the real WTF.
I guess no one could believe it!
I bet they do not even need their binary files versioned, for them git is a convenient way to have binaries available in the build servers (git as cloud backend):Why not just put it in the source control so it's right there and your build server doesn't have to talk to like 54 other servers to do its job?
Ok I think I begin to see the TR
here. If you want to version binaries you can still use git lfsas suggested, a legitimate usecase is game developers who want to version their asset files.
But if you use git to upload binaries (perhaps your database blobs) you should know that when you commit a new blob the previous one sits right there in the history, because sane people sometimes use git to checkout older versions. git pull is not download and git push is not upload.
I wonder how tiny your baby-size project is that you only have 13.5GB of cumulative crap.
-
I bet they do not even need their binary files versioned,
Yes we do.
Ok I think I begin to see the TR
here. If you want to version binaries you can still use git lfs as suggested, a legitimate usecase is game developers who want to version their asset files.And our use-case is NOT legitimate. Of course. Why would it be.
But if you use git to upload binaries (perhaps your database blobs
) you should know that when you commit a new blob the previous one sits right there in the history, because sane people sometimes use git to checkout older versions. git pull is not download and git push is not upload.Duh?
I wonder how tiny your baby-size project is that you only have 13.5GB of cumulative crap.
The DB file binary isn't very big, like I said, it's just reference data the tests rely on.
-
Yes we do.
Ok then yes test data is a legitimate use case.The DB file binary isn't very big, like I said, it's just reference data the tests rely on.
Meaning it could be textual json files that could be imported to a test table during test. django even has ready to use fixture idiom for that. If that is out of question you should definitely start using
git lfs.
-
Meaning it could be textual json files that could be imported to a test table during test.
We could do a billion things, but why would we?
"Hey you're not doing things 'pure' (in my idiot open source opinion), therefore you should make your life really annoying and inconvenient!"
Thanks. Great. So helpful.
-
We could do a billion things, but why would we?
Off the top of my head: Having text should make it easier to tweak data in the future. Or do just about anything with it, presumably. It could alleviate at least some of your merging issues. Probably reduce the size of the repo.
-
How's this?
I was lucky that I didn't open this on the big screen I have at my workplace, TYVM.
-
I do agree that putting the merge conflict contents in the file is retarded as hell though. Is it really that hard to write it out as a .merge file? You're already copying the old file to .old!
I like seeing the conflicts in-line when editing my code. It means I can use the same editor I always use, and now I can use it to resolve merge conflicts the way I see fit without having ti learn some diffing tool or a merge tool. Clearly, we have differing personal preference.
I only fixup when I notice I made a minor error that has no reason for belonging in a separate commit.
I don't understand what 'fixup' means in this context. I also can't tell if this is sarcasm?
-
[W]hy is Git designed so shitty that the only way to change a commit's comment is to rewrite history?
Because -for data integrity/assurance reasons- a git commit's ID is something like a hash of the commit contents, the the commit message, and the hash of its parent?
It's actually nice to be able to walk the history of a given tree and know that someone hasn't surreptitiously tampered with it.
-
Right; but I'm talking about commits I haven't pushed yet.
-
A good interface would ask you "what commit do you want to alter, and what do you want it to say?", and it would handle the rewind, amend and ff steps behind the scenes.
That's exactly what
git rebase -idoes. You get a nice list of commits opened in your EDITOR. You can pick the one(s) that you want to edit, edit 'em, and the history rewriting is taken care of for you behind the scenes.
-
Right; but I'm talking about commits I haven't pushed yet.
As you know, git is a DVCS. Like most (all?) DVCSs, the only real distinction between your repo and the "central" repo that everyone uses as the central repo is that the group has decided that that copy of history is the central one.
In a DVCS, a repo is a repo is a repo, forever and always, regardless of on whose disk it lives.
-
Editing a commit comment should be easy (probably with a permanent indication that it's been edited) without going through a complicated process that risks corrupting your repo...
Git does make editing a commit comment fairly easy. It also isn't something that risks corrupting your repo. ;)
-
As you know, git is a DVCS.
I know it. I just don't care.
Git's problems are problems, regardless of how many D's are in the acronym describing it.
-
-
The problem is that the git CLI is generally only used for personal copies of git repos, not for server side copies. Servers should probably just use libgit and the CLI should probably just be for users.
-
There is a distinction between commits that exist only in that repository and commits which have been pushed/pulled to elsewhere though.
There is no reason to put restrictions on commits which exist only in one place.
-
DVCSs are problems
FTFTFY
Git's ok if you're working on an open source project or linux kernel, but 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
-
You are using it wrong so your complaints should be targeted at your company and not against the tool that doesn't fit your use case.
The fact that you're unable to understand it in the first place is irrelevant and a personal dysfunction.
Also how the duck (thanks auto correct) you quote a post on mobile?
-
Also how the duck (thanks auto correct) you quote a post on mobile?
Select the text in the usual way for your phone, if you can, then click the Reply button underneath the post, since you don't get the popup button that you do on Desktop.
-
squash
This command lets you combine two or more commits into a single commit. A commit is squashed into the commit above it. Git gives you the chance to write a new commit message describing both changes.
fixup
This is similar to squash, but the commit to be merged has its message discarded. The commit is simply merged into the commit above it, and the earlier commit's message is used to describe both changes.Clearly, we have differing personal preference.
Clearly this should be an option then :)
-
I thought it was an option? If not why do people keep mentioning "merge tool"?
