I GOT MY PROGRAMMED BLANK ATM CARD TO WITHDRAW A MAXIMUM OF $5000 DAILY.
I AM SO EXCITED BECAUSE I ORDERED AND PAID FOR DELIVERY, DIDN'T GET SCAMMED, AND I NOW OWN MY HOME,
MY BUSINESS HAS GROWN BIGGER.
GEORG BEDNORZ (georgbednorzhackers@gmail.com) IS THE NAME OF THIS USA HACKER THAT GAVE ME THE CARD
AND ALSO HE IS OFFERING ALL KINDS OF LOAN WITH ONLY 2% INTEREST RATE.
High-Level Problems with Git and How to Fix Them
61–70 of 294 posts
Re: High-Level Problems with Git and How to Fix Them
#62Earlier quoted context omitted.
Commit messages could just as easily be a policy requirement instead of a tool requirement. Maybe all the repos you interact with require a message for every commit, and that's fine. But maybe the default policy should be permissive. People might decide not to use any tool at all if this is the straw that broke the camel's back for them, and that's a worse outcome in my opinion. And, honestly, 90% of all commits I've…
"Change 357" could be a sufficient message if there is some other tool to track changes where I can look up what #357 is all about. I'd argue that for any piece of software where a failure requires a root cause investigation the VCS history is a critical artifact and a great deal of care should be taken to make it easy to understand for what reasons changes happened and how they interact.
There are a lot of very sophisticated things you can do with and to a body of code to fix extremely complicated problems, but the information needed to do so is at times quite delicate.
The overlap of people who believe in Bad Luck and don’t care about transparency is pretty high. Things just are, there’s no one to blame and certainly no lessons to be learned.
They don’t get how a breaking the commit history with a mangled move operation or shitty merge will fuck is over eighteen months from now. Hell half of these people think they’ll be retired or working someplace else 18 months from now anyway.
Re: High-Level Problems with Git and How to Fix Them
#63I'm surprisedly the staging-area hate. Does it really violate peoples' assumptions? I like the ability to make a big, complex change and checkpoint stable portions (subsets) of the work as I go.
How do you test the thing you're actually committing without everything else in your working tree contaminating your test?
There are ways to do this using stash but if you stash before you commit, you get merge conflicts when you pop the stash. The workaround I've seen is to commit before you stash, but that means you're also committing before you've actually tested that change, which seems pretty broken, IMHO.
Re: High-Level Problems with Git and How to Fix Them
#64One personal anecdote: In a decade of using Mercurial, I've managed to get a repository in such a confused state that I had to blow it up and start from scratch just once. In the same time, I've had to do the same for git repositories at least 5 or 6 times--and I never really used git all that much. Even nowadays, where I'm more or less forcing myself to use git [1], I'm incredibly hesitant to try any sort of complex…
wow.
> I'm incredibly hesitant to try any sort of complex git operation because of the risk that I might lose my in-progress commits.
correct way of learning git is every time you want to use a "complex"/dangerous commands in git, you `cd /tmp` and create a git repository there. then create some commits, branches and experiment. you will NOT lose anything, but you will learn a lot.
I did and do this every time I have doubts. and with time you will understand how non-dangerous git commands are.
"dangerous" part comes from the user, not the software, and it is okay. when you accidentally kick a corner of a furniture, that does not make that furniture "dangerous".
Re: High-Level Problems with Git and How to Fix Them
#65I'm surprisedly the staging-area hate. Does it really violate peoples' assumptions? I like the ability to make a big, complex change and checkpoint stable portions (subsets) of the work as I go.
To me staging is the best part of git. I don't want to commit all the time so I slowly stage changes that I think are OK. Once the feature is done I can do a full commit. Perfect!
The author purports that this can be achieved without staging. For example, you could slowly commit small changes that you think are ok on a work-in-progress feature branch with `git commit -p --allow-empty-message`. When you are done you could squash rebase + message rewrite.
While currently this workflow is clunky, it could be made to work with the same nice semantics of your workflow, and not have a staging area at all.
Re: High-Level Problems with Git and How to Fix Them
#66Earlier quoted context omitted.
Partial commits through piecemeal staging is great as a poweruser's tool, like rebase. But it's beyond weird that anyone thought it was a good idea to make people deal with staging for every commit. It doesn't even have to go away. (And on that note, I'm bummed that the conclusion in the article is to do that, especially because everytime this comes up, there's an uproar.) But, jeez. Just tuck it away so futzing with…
Git doesn't actually make people deal with staging for every commit, though. It's quite common to tell newcomers to always `git commit -a`, and `git add` for adding new files. That's pretty much exactly where SVN is/was, and nobody complained about that being complicated or onerous either.
[deleted]
Re: High-Level Problems with Git and How to Fix Them
#67I'm surprisedly the staging-area hate. Does it really violate peoples' assumptions? I like the ability to make a big, complex change and checkpoint stable portions (subsets) of the work as I go.
Partial commits through piecemeal staging is great as a poweruser's tool, like rebase. But it's beyond weird that anyone thought it was a good idea to make people deal with staging for every commit. It doesn't even have to go away. (And on that note, I'm bummed that the conclusion in the article is to do that, especially because everytime this comes up, there's an uproar.) But, jeez. Just tuck it away so futzing with…
If you consider the use case "linux kernel development", you realize that you really don't want to automatically commit all your changes.
Re: High-Level Problems with Git and How to Fix Them
#68One personal anecdote: In a decade of using Mercurial, I've managed to get a repository in such a confused state that I had to blow it up and start from scratch just once. In the same time, I've had to do the same for git repositories at least 5 or 6 times--and I never really used git all that much. Even nowadays, where I'm more or less forcing myself to use git [1], I'm incredibly hesitant to try any sort of complex…
> I'm never really sure what could cause me to lose unpushed commits... Effectively nothing. By default, old, unreferenced data is only garbage collected after a month. If you screw up a rebase, the old commits are still there with the same hash they always had. You just need to point the branch at them again. > ...or uncommitted working files That's fair. If I'm unsure, I just stash or commit first. Anything that's…
Sometimes I find myself doing "git stash; git stash apply" just so I have a checkpoint of what I'm working on. That plus "git stash list -p" lets me go back through tons of non-checked in junk to find (say) that one line of debugging code that turned out to be pretty useful…
Re: High-Level Problems with Git and How to Fix Them
#69The Git staging area doesn't have to be this complicated. A re-branding away from index to staging area would go a long way. Adding an alias from git diff --staged to git diff --cached and removing references to the cache from common user commands would make a lot of sense and reduce end-user confusion.
--staged is already an alias for --cached in the latest Git version.
Re: High-Level Problems with Git and How to Fix Them
#70Earlier quoted context omitted.
Stashes should cover your first scenario; put those changes (both staged and unstaged, optionally also untracked files) in a bag and re-apply them when you are back from your short expedition: https://git-scm.com/docs/git-stash To clean up outgoing changes, you can run an interactive rebase of the current branch onto its remote tracking counterpart. This will list all affected commits in a text editor, and allows you…
Problem with stashing is that you then need to redo the work of staging afterward.
You only need to git stash pop and the staging area is back as it where, there is no need to redo the work of staging.