51–60 of 490 posts
I've gotten kind of familiar with the Git CLI. But it took a lot of wasted hours and headaches to do so, and even now it takes headaches and extra time / effort to do certain things like rewrite history and "good" commits. I still prefer CLI to GUI but I wish it was more intuitive.
How hard is `git reflog` `git reset --hard ` Or if you just want to move back 1 commit `git reset HEAD@{1}`
Earlier quoted context omitted.
Are you using Git via GUI(s)? Between my colleagues, there is a strong correlation between using a GUI, and messing up the repository. I agree that Git's UX is pretty bad (checkout overloading; overlapping between checkout and reset; push overloading... yikes!), however, I believe that in contexts where using Git is a constraint, stop using GUIs is the best strategy one can apply to improve the understanding.
I use the Pycharm/Jetbrains Git GUI. At this point I can't imagine effectively handling merge conflicts any other way. EDIT: Also, I really like being able to look at a diff of every file before I commit, and easily choosing which files to include in a commit. Too often I see people on the CLI accidentally committing changes they didn't mean to, because there is no easy way to check everything at the last minute.
This seems like putting a training wheel on a training wheel. git is already the easiest to understand of any VCS that I've used, and it's somewhat hard to do something in git that can't be reversed. As the articles states, it's unlikely you'll ever lose your changes. Further, this doesn't seem to be that different of a concept from git reset, so why not learn reset instead of yet another command?
Breaks down in uproarious laughter.
One of the worst offenses git is its use of multiple different jargon terms for the same concept; indeed, it's the only VCS I've used where reading help leaves me less sure than when I started if it does what I want it to do.
If I accidentally leave my system in a weird state (say, I'm in the middle of a git rebase and I forgot to git rebase --continue), and I start doing some regular git commits, the resulting mistakes are, while possible to recover from, difficult to do so unless you know git's internals. I have to use the "what's that git command to list the commits I just dropped on the floor by accident?" with surprising frequency.
Damn, this is such a GREAT idea. I've messed up repos a few times, and it's never good. It's always -- "what's the magic want I have to wave now"? The truth is, while we use git every day, most people really don't understand how it works. There I said it. And I'm not ashamed. I don't really know how Git works. And I think I'm not the only one. What does "git reflog" or "git reset --hard ...." do? What are the implica…
I understand how git works, and I still can't use it. There are three problems: 1. Despite the claim that git never loses data, there are actually some dangerous operations that will irretrievably nuke your work with no warning. Git checkout is the canonical example. This makes me very gun-shy about doing anything that I'm not intimately familiar with. 2. Git's merge is not smart enough to realize that identical chan…
This seems like putting a training wheel on a training wheel. git is already the easiest to understand of any VCS that I've used, and it's somewhat hard to do something in git that can't be reversed. As the articles states, it's unlikely you'll ever lose your changes. Further, this doesn't seem to be that different of a concept from git reset, so why not learn reset instead of yet another command?
Hard disagree, git's docs and UI have improved over the years but every time I have to teach it to a beginner I realize how arcane and scary it is, especially when compared to old school centralized VCSs like subversion. Not that I'd trade git for subversion mind you, in the hands of a trained individual git is a godsend, but the training part can be arduous. Even among DVCSs I'd argue that mercurial for instance is…
If it's a matter of understanding the flow of the tool, then I will have to concede that mercurial probably is easier to understand for the beginner.
My company has an equivalent to 'git undo' that basically undoes anything you just did to your local repo.
It's just so freeing. Sometimes you need that Ctrl+Z so you can undo and redo things correctly. It gets your mind back to whatever you were doing before without needing to debug wtf just happened.
Damn, this is such a GREAT idea. I've messed up repos a few times, and it's never good. It's always -- "what's the magic want I have to wave now"? The truth is, while we use git every day, most people really don't understand how it works. There I said it. And I'm not ashamed. I don't really know how Git works. And I think I'm not the only one. What does "git reflog" or "git reset --hard ...." do? What are the implica…
For some reason people love to defend the obscure and strange and oftentimes objectively terrible Git CLI. I’ve found Mercurial much more straightforward for my (mundane and boring but prevalent) use cases, and I lament that it isn’t more widely used.
Earlier quoted context omitted.
I agree and limit Git Gui usage to read-only use, any mods to git I use command line.
Git Gui is a decent tool to compose commits, but for everything else I can't see myself using anything but the command line.
Damn, this is such a GREAT idea. I've messed up repos a few times, and it's never good. It's always -- "what's the magic want I have to wave now"? The truth is, while we use git every day, most people really don't understand how it works. There I said it. And I'm not ashamed. I don't really know how Git works. And I think I'm not the only one. What does "git reflog" or "git reset --hard ...." do? What are the implica…
I know (or, at least, have known ) how git works, in the way most people mean that (the data structures & on-disk layout, what a commit is, what a tag is, what a branch is, what HEAD is, staging, et c.). What I can't keep straight is WTF the commands are actually doing, in that low-level sense, which is a different thing, and there's approximately a 0% chance I'm ever going to use more than a tiny fraction of the com…
git init --submodule --recursive
Or is it
git submodule --init --recursive?
God I hate this UX so much I usually have a ./fetch-subrepos.sh that runs a bunch of "git clone" commands.
And if I push without first pulling, must it always punish me with a merge commit? Can't I say "oh shit I don't want to do this, go back and git pull"?