The FOSDEM talk that goes along with this page was top tier - I really enjoyed it and learnt a lot, plus it was super engaging in person.
Git tips and tricks
131–140 of 143 posts
Re: Git tips and tricks
#132I never really understood why the majority of developers insist on using the git CLI, when modern UI clients like GitKraken [0] are perfectly usable and very helpful. :shrug: [0] https://www.gitkraken.com/
Knowledge of the CLI transfers to writing scripts. Knowledge learned from using Git in scripts transfers to day-to-day use.
Also, if I SSH into my Raspberry Pi that I'm using as server, I don't want to feel useless just because I'm forced to use a CLI.
I'm not entirely against using a GUI, it's just that at this point I'm more efficient using the CLI, and I don't want to spend effort searching for a GUI that is:
* Good-looking.
* Is native, not an outdated vendored copy of a web browser.
* Doesn't have telemetry, or at least it's disabled by default.
* Is fully open source; not open-core or proprietary.
* I can reasonably expect that it won't disappear 5 years in the future.
* That it doesn't make things more confusing. Like for example Visual Studio[1] having a button that very ominously says "Accept merge", when it really means "Mark conflict as resolved". If an IDE wants to use its own cute way of labelling things, good; I can accept more friendly terms that make it more approachable for a wider audience. But at least don't make things confusing for people that already expect certain words to mean certain things.
* That I can trust that it won't "helpfully" do fancy stuff, like having a button saying "Commit changes" that "helpfully" also pushes to remote. I don't know if any GUI does this, but my trust is low.
[1]: I had to use it at a previous company because it was the only realistic way to work with their codebase.
Re: Git tips and tricks
#133Earlier quoted context omitted.
Creating an alternative UI is rather uncontroversial. The plumbing doesn't need replacement. Jujutsu for example, seems to be popular.
Ha, replacement? You can't even get them to fix bugs. If you fix a bug in a unix command you'll break every script in existence and bring the world down. It's idiotic. The user's a file! The internet's a file! Keyboard is a file! What are checkboxes? This is a volunteer project! You can't expect us to include UI in the OS! We'll just bikeshed forever so sorry, write your own, lol.
I found and fixed a bug in Debian’s vixie-cron where if the system time clock changed without restarting crond, it wouldn’t modify its runs until the next DST event.
This was well-received without complaint or concern for breaking people’s [insane] workflows that may be relying on that behavior.
Re: Git tips and tricks
#134I do not want to learn git tricks. I just wanna use it as simple as possible. Just let me push my code and be done with git and keep on working. Kudos to all who love git, for me, it's just a tool I have to use.
Honestly, get outside of commit and pull and my brain feels dread like regular expressions. Hopefully the incantation is on the Cheat Sheet and I don't make it worse.
As long as you remember that the reflog exists (and it hasn’t run gc, but usually you immediately know when you’ve messed up), you’ll be fine. It’s exceedingly hard to break your repo beyond repair without trying to do so.
Re: Git tips and tricks
#135Heya, author here. I have to admit that I learned a lot of these things fairly recently. The large repository stuff has been added into core piece by piece by Microsoft and GitHub over the last few years, it's hard to actually find one place that describes everything they've done. Hope it's helpful. I've also had some fun conversations with the Mercurial guys about this. They've recently started writing some Hg inter…
The YouTube video of your presentation is great and I recommend to anyone that wants to learn more about Git or uses Git on a regular basis.
Thanks for the info.
Re: Git tips and tricks
#136Earlier quoted context omitted.
I have several scripts like that in my PATH, but Git on Mac can never find them. What am I doing wrong?
The scripts have to be in your `PATH` and be executable from wherever you're running `git`. Say you have a script named `git-foo`. At the shell prompt, all of these should work: $ which git-foo $ git-foo $ git foo If the first or second commands fail, then `git-foo` is not in your PATH or is not executable. If those both work but the third command fails, I have no explanation. Here's the code which runs commands: htt…
Well, this is fun:
$ which git-foo
$ type git-foo
git-foo is /Users/my.user/.local/bin/git-foo
$ git-foo --help
Help output from git-foo
$ GIT_TRACE=1 git foo
14:26:18.849078 git.c:749 trace: exec: git-foo
14:26:18.849815 run-command.c:657 trace: run_command: git-foo
git: 'foo' is not a git command. See 'git --help'.
And today-I-learned that while bash expands `~` in PATH entries other programs do not. The fix was changing my PATH from:
PATH=~/.local/bin:other:paths
PATH=$HOME/.local/bin:other:paths
Re: Git tips and tricks
#137I'm pretty comfortable with Git for all my every day use. There's one place where I lose my bearings: its' the 'History Simplification' section of 'git log' man page. I'd love it if someone could "simplify" that section. I coudld have done it, but I ought to understand that first.
Re: Git tips and tricks
#138I stopped pretending as if I know what I am doing and instead use visual Git tools, such as SmartGit or the one that comes with IntelliJ. Being a Git "command-line hero" is for show offs. Porcelain can be just infuriatingly confusing. For example, "Yours and Theirs" can mean the opposite in different contexts. The whole user interface has no common style or theme - it needs a new "visual" layer in order to not drive…
These are not mutually exclusive. I share your sentiment in that I only use visual tools for diffs and conflicts and stuff, but I’ve gained a lot from learning about commit objects, reflogs, what a rebase does in the background, interactive rebases, hard/soft resets, etc
Oh, I do that as well. "reset --hard origin/trunk" for the win, if you know what I mean.
But, will I venture out to stage only a few chunks of local changes into a single commit using the command line interface? Hells to the no.
Re: Git tips and tricks
#139Earlier quoted context omitted.
The scripts have to be in your `PATH` and be executable from wherever you're running `git`. Say you have a script named `git-foo`. At the shell prompt, all of these should work: $ which git-foo $ git-foo $ git foo If the first or second commands fail, then `git-foo` is not in your PATH or is not executable. If those both work but the third command fails, I have no explanation. Here's the code which runs commands: htt…
Well, this is fun: $ which git-foo $ type git-foo git-foo is /Users/my.user/.local/bin/git-foo $ git-foo --help Help output from git-foo $ GIT_TRACE=1 git foo 14:26:18.849078 git.c:749 trace: exec: git-foo 14:26:18.849815 run-command.c:657 trace: run_command: git-foo git: 'foo' is not a git command. See 'git --help'. I can't say I've ever seen `which` and `type` disagree before ... And today-I-learned that while bash…
[deleted]
Re: Git tips and tricks
#140Heya, author here. I have to admit that I learned a lot of these things fairly recently. The large repository stuff has been added into core piece by piece by Microsoft and GitHub over the last few years, it's hard to actually find one place that describes everything they've done. Hope it's helpful. I've also had some fun conversations with the Mercurial guys about this. They've recently started writing some Hg inter…
Hey, thanks for a great little series. The part about `--force-with-leash` could include `--force-if-includes` as well. `--force-with-leash` doesn’t do much if you fetch often. https://stackoverflow.com/questions/65837109/when-should-i-u...
"--force-with-leash" sounds like git for the BDSM community...