641–650 of 821 posts
Since I read the git book, I never once had to rm -rf + git clone, and I've never been stuck in any situation.
It's the same thing as people blaming regexes or CSS for being hard without reading full courses.
Earlier quoted context omitted.
Ya, I'm the opposite, I never use rebase. Horses for courses...
You should, or do you just merge updated remote branches into your stale local branches? A lot of new developers seem to do that here until we explain to them how it messes up the history.
When we release to production, develop gets merged to master.
We consider a 'feature' a large piece of work that will take several weeks, during which time several releases to production may be done for other work/tickets.
Why is "name only" split but "oneline" is not?
Earlier quoted context omitted.
> You might as well ask how to unsend an email. That is also a reasonable request. I'm unable to fathom the notion that if a computer doesn't work the way people want, the answer is for people to adapt to the computer. The whole point of computers is to do things for people. With physical messages, unsending has at least partial support. Before the mailman picks up from my porch, I can grab a sent message any time. I…
You can’t unsend an email because you can’t force someone else to delete something. Emails end up as files on someone else’s server. Claiming this is a UX issue is intentionally missing the point. If this is legitimately a foreign concept to you, an afternoon setting up postfix and playing around with it might be worth your time. Email is a protocol, not a program. A “delete” request would be just that, a request. Yo…
Earlier quoted context omitted.
I really don't see the issue. I've never struggled with git and it's already a muscle memory for me.
There have been many many blog posts about Git's terrible CLI. It's an established fact.
* It is too powerful
* It is not prescriptive
* It has horrifyingly bad UX/semantics
Git exposes all of its complexity at installation, which means that you are able to do any amount of damage from minute one. There are no cascading layers of abstraction that map onto the user's comfort level with git.
Git also doesn't prescribe workflows. Overtime, people have come up with standard workflows, but there are too many of them and they all have different mental models. The issue is that most of these workflows are only marginally better/worse than each other and don't necessarily provide additional functionality in any sense. It would be much better if there was only one way of doing things in git. It would make things marginally inconvenient for many, but the marginal loss of productivity would be more than made up by a consistent mental model and the increased reliability of the 'canon' workflow.
Last, and certainly my biggest complaint is the terrible UX and the semantics they convey. It is almost as though the creators went out of their way to have naming schemes at odds with natural language.
I hope someone builds a keras-like tool for git. Interoperable with the tensorflow (v1) that is the git underneath, but exposes a much easier and in most cases feature complete set of abstractions that work for 99% of its users.
Earlier quoted context omitted.
You forgot log, cherry, stash, blame, which are also daily use commands. You also have to learn a lot of concepts to even understand the help and error messages for these commands - the worktree, the index, the stash, HEAD, ours vs theirs, conflicts, remotes, tracking branches, when it is safe to push -F, etc. Depending on the project you joined, you may also have to immediately learn about git LFS, submodules, squas…
I think of log, cherry-pick, stash & blame "quarterly use" commands rather than "daily use" commands. log maybe monthly, the rest quarterly unless you're doing something wrong.
At work we do care that our git history makes sense, is free of random nonsense, but contains only self-contained commits with reasonable documentation. So I call git log many times every day, I would not know how to do it without.
Cherry-pick probably depends how may maintenance branches you maintain. We don't have many, so I don't need it very often. I guess that could be very different for someone required to support long product life cycles. Sometimes when I need to split or unite development branches that need major reorganization I use it.
Blame I need soon when I try to understand others code. Sometimes even on my own. Also when you get bug reports form the field, to understand how long certain bugs existed. Not always to be able to blame the author, but just understanding how long a line has been unchanged.
Personally I don't use stash a lot because I'm not afraid of committing anything to my working branch. I can always fix the code or the history later. Or I make a temporary branch with a descriptive name than just stash. Some use stash more frequently I have noticed.
Earlier quoted context omitted.
> You might as well ask how to unsend an email. That is also a reasonable request. I'm unable to fathom the notion that if a computer doesn't work the way people want, the answer is for people to adapt to the computer. The whole point of computers is to do things for people. With physical messages, unsending has at least partial support. Before the mailman picks up from my porch, I can grab a sent message any time. I…
>I'm unable to fathom the notion that if a computer doesn't work the way people want, the answer is for people to adapt to the computer. You don't understand because you think you're fighting computers but you're actually at odds with other human's desires. If I pull your code, even if it was a mistake I don't want you to later rip the rug out from me and force me to figure out what happened from the history you dele…
I also don't think what you said is necessarily true. If person A has pushed and nobody else has pulled, then for most situations there's no reason to prevent A from un-pushing. Even if person B has pulled, a propagating un-push might well be what they want. I generally would. There are certainly some cases where B might not want that, but given that undoability is a has become a strong user expectation, I don't have particular reason to believe that balancing users needs would come out in favor of the current behavior.
Earlier quoted context omitted.
Autostash
Ok, so you don't need to know git stash (good) but you need to know that autostash exists and how to configure it, so you still don't get away without an extra concept. I suppose the nice part about autostash is that it's easier for someone to just give you a .gitconfig with it, and not have to teach you how to use git stash.
Git's problem is 3 fold: * It is too powerful * It is not prescriptive * It has horrifyingly bad UX/semantics Git exposes all of its complexity at installation, which means that you are able to do any amount of damage from minute one. There are no cascading layers of abstraction that map onto the user's comfort level with git. Git also doesn't prescribe workflows. Overtime, people have come up with standard workflows…