I have had the alias pfusch=push --force-with-lease for a long time now. Not only is it an approximation of the full command, but in German, 'pfusch' means to make things worse both by good intentions (and implied ignorance) or simply by not giving a shit
committing to multiple branches is brilliant! its always a PITA to notice/fix a core bug when working on a feature branch.. stash->checkout->pop->commit->checkout->merge is so much overhead for what started as a 5-second one liner fix.
I clearly don't understand git at all. "It's for sharing your code!" Ah, do it's like paste bin but very confusing and I can't figure out how to share my code with it.
The recording feature would be great. We've all been there, when we did a lot of work and then accidentally deleted the code, and it wasn't added/committed yet. And you pull your hair out wonder why th you didn't commit it... and you have to rewrite everything. It would be great if git allowed you to undelete something.
Been a developer for almost 15 years and making $250K a year and knew some of the commands but not even used it! Why would someone wants to pollute their brain with these commands while IDE's have integrated tools that does these nicely. My suggestion, search it when you need it!!!!
I've been using worktrees forever and never met anyone else who uses it. I have no idea how people work without it! They must not be working... I've needed GitButler for so long, you have no idea.
Thank you very much in general. What's disappointing, out of the 3 things I found the most useful for me, *none* works properly, and 2 (git maintenance start, git fsmonitor-daemon) don't work at all on Linux :( The 3rd thing, --word-diff, works, but mangles the diff (swallowing an important space between words) so that you think "oh! how could I make such a typo?!" only to realise there's no typo, it's git devs, not you, who made a typo...
Remember when version control used to be simple? When it didn't need to be wrapped in huge frameworks so that people could work with it? When it didn't need conferences like this? When it wasn't the main topic of conversation on a project, and we just did the project?
Yes I do. And source control back then wasn't a tool the way git is. Like, also,git is awful in many ways, but I still love it deeply for the things it lets me do, manipulate and interrogate my repo history in many useful ways. It lets me approach certain problem classes in a meta way that old source control just could not. Branching is a first class citizen in git and that was not the case inb4. Learning git is a brick wall, as an early adopter I had the difficulty of explaining git many times to many companies, simple things are often stupid, and git basically requires you to learn it's mental model pretty well before you can do basic things with confidence. Then again, idk, sql doesn't make much sense unless you know what a relational database is. So git is hard in dumb ways, and if anything ever replaces it the way git ate svn, then I can't wait to drop git over whatever that future better system is, but it doesn't seem to exist, so I'm on the whole far far happier with git, warts and all, then any prior system. CVS wasn't even atomic, and vss would corrupt itself, svn really couldn't do branches and merge conflicts ruined your working copy in unrecoverable ways, and git is so so fast, and also best case was you could do exactly one local commit effectively where git you can do infinity local commits and also peer to peer stuff. Evolution of source control systems has been a net positive
@@rebeccakeller4666 Hi Rebecca. I could write a similar passage about how bad it is, but I won't bother. I will just say one thing; it is too difficult, and any good software should be easy. Yes, it can be learned, and when you have learned it, it is ok. But it shouldn't take so long to learn. I have been using Git for the last 10 years, so I feel like know it fairly in depth, but it took me about two years to get to this level. Why? You can of course take the easy way out at this point and just say I must be stupid, but I will assume you won't do that. It took me just a few weeks to get to a similar level with CVS, SVN, Clearcase etc. Now I know Git, but I have to work on projects with more junior people who are currently going through the same hell I went through. While they are learning, they make a lot of mistakes and people have to spend their time trying to fix them. The old systems, which would have improved a lot by now, were much better because they were simple and just worked. Anyway, I am glad you like it. Each to their own.
I know a bit of git. I found some races in git. Upstream refuses to fix them, even if patches are provided. I gave up on git consistency, workarounds are required. Git has no consistency model, the only way do be consistent it to never delete anything, ever. git submodules are garbage, and cannot be fixed because they have been defined in a way that makes them garbage. The only way forward is to throw away git, and start from scratch.
Who uses terminal?!?! There are amazing UIs made that give you so much perspective on the code and so easy to control. There is a reason we use graphic user interfaces. Otherwise everything would be just terminal and text and js and CSS would never be created. And the mouse would never be used.
The problem is that we have more tools that work better in a terminal than we have GUIs to support those tools. Most Linux users will swear that the terminal is the only way to be productive, but that's only because most of their tools have no GUI, or the existing GUI is very limiting. If you want, I implore you to attempt building a GUI vs. building a command line interface for an application. You will quickly find out why GUIs are not as common. For one, it's more complicated and not all tools have an API, that exposes every aspect of that tool, in a way a GUI can easily present the same options to a user.
When working in JetBrains IDEs, I use Change lists: for example, I can create one for dev changes (that I definitely don't want to commit), other ones per branch. When commit, I select only needed change list(s) and other changes are not affected. Overall, JetBrains commit tab is quite comfortable for me.
Scott: "Who uses the command line?" *lots of hands raised* "Fucking nerds" Also Scott: "My voice is my passport, verify me" As if he could sneak in an Uplink reference without being called out
So, it looks like automation, where you have a local brach with a mess of commits, but when you push to a remote branch it do auto squash. Is it correct, or am I missing something?
TL;DW: Git is DIY version control. The less you know about git, the less likely you are to accidentally corrupt your repository. The safest way to use git is to each time, check out a fresh copy of your project, make your edits, and check it back in. Minimize the likelihood of repository corruption by making sure no one else checks out your project at the same time you're making changes. Keep archived copies of your project tree around locally and make multiple backups to be sure.
This is great but what this does is abstract away all the git commands behind a UI. The person using this tool will never learn about git at the fundamental level. However, I do agree that it's great for users who are already experienced on working with git directly.
