Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Git tips and tricks

blog.gitbutler.com

Post reply on HN
Print view View original

121–130 of 143 posts

Re: Git tips and tricks

#121

Post by Shacklz »

saiya-jin wrote: post #108
Shacklz wrote: post #34

Earlier quoted context omitted.

I had the same experience for a long time and then I took a bit of time to have a deeper look behind the curtain and I have to say, once you grasp the data-model of git itself (a branch is a pointer to a commit, a commit is a pointer with metadata to a tree, a tree is...), many of the commands start to make sense all of a sudden, or at the very least "stop looking dangerous". As it's one of those rare tools that's pr…

This generic statements can be said about basically any technology (MS MFC anybody? (L)DAP? IBM Websphere studio J2EE abominations?) if you are smart enough / have enough time to dig around. It doesn't help discussion at all (and plenty of folks complain about git all the time), since one can't avoid being branded as lazy/stupid if its not grokking this uber important yet trivial tool like me (TM). But then there is…

> But its design is far, very far from the most important software design principle (KISS)

My suggestion was more to look at the underlying data-model, which really isn't that much harder to grasp than what your average undergrad datastructure course teaches. Git really does solve a rather complex problem in a quite elegant way - it just so happens that the packaging around it (the cli) is indeed a bit more controversial.

I can only speak for myself but once I started to look at git less like "a tool" and rather from a perspective of datastructure/algorithms etc. (which are inherently agnostic to how they're implemented), it started to make sense to me rather quick (a matter of hours actually, which is nothing compared to the countless of hours I've already wasted trying to find the right cheat-sheet-incantation before).

Re: Git tips and tricks

#122

Post by js2 »

svieira wrote: post #117
js2 wrote: post #107

Earlier quoted context omitted.

meta-tip: you can also put your aliases that start with '!' into stand-alone shell scripts named `git-fza` (e.g.) and then call it as `git fza` which will search your PATH for `git-fza` and invoke it as if it's built-in. I do this for some of my more complicated aliases because I generally think it's poor form to embed shell scripts into configuration languages. (Looking at you, yaml.)

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:

https://github.com/git/git/blob/2996f11c1d11ab68823f0939b646...

It basically prefixes your `PATH` (or a suitable default if `PATH` isn't set) with `GIT_EXEC_PATH` (defaulting to a compiled in value if not set) and then uses the normal Unix execvp machinery to run the command.

You can try:

  $ GIT_TRACE=1 git foo
But I'm not sure that will tell you anything helpful.

Re: Git tips and tricks

#123

Post by bloopernova »

svieira wrote: post #117
js2 wrote: post #107

Earlier quoted context omitted.

meta-tip: you can also put your aliases that start with '!' into stand-alone shell scripts named `git-fza` (e.g.) and then call it as `git fza` which will search your PATH for `git-fza` and invoke it as if it's built-in. I do this for some of my more complicated aliases because I generally think it's poor form to embed shell scripts into configuration languages. (Looking at you, yaml.)

I have several scripts like that in my PATH, but Git on Mac can never find them. What am I doing wrong?

What version of git do you have? If it came with macOS and wasn't installed via homebrew, it's possible that it's old enough to cause problems.

Re: Git tips and tricks

#124

Post by elevatedastalt »

goku12 wrote: post #96
smallpipe wrote: post #63

Earlier quoted context omitted.

> Eventually, I figured out that it was operating on diffs, not snapshots The snapshot include all the history that led to the current snapshot. So even if you did a squash instead of dropping, you're changing everything that depends on that

> The snapshot include all the history that led to the current snapshot Git snapshots don't contain any history, other than the commit chain (reference to the parent commit/s) in the commit object. While the storage format is a bit complex, they behave fundamentally like a copy of the working tree at the point of commit. > So even if you did a squash instead of dropping, you're changing everything that depends on tha…

Yes, but since they change the commit id, and since each commit has a pointer to its parent commit, you have to rewrite all the commit objects, even if the tree doesn't change.

Re: Git tips and tricks

#125

Post by grimgrin »

softwaredoug wrote: post #64

I have vastly simplified my git workflow with some aliases that work in a variety of settings git synced # git pub # git pr # git hub # https://softwaredoug.com/blog/2022/11/09/idiot-proof-git-ali...

let's get meta, doug

tell me about your choice of separator, the weird hairy arrow

Re: Git tips and tricks

#126

Post by iraqmtpizza »

yjftsjthsd-h wrote: post #92
iraqmtpizza wrote: post #17

Earlier quoted context omitted.

>originally meant to just the plumbing this describes all of unix. as soon as scripts were allowed to use commands, those commands could never be changed. lest we have a nerd riot on our hands

> as soon as scripts were allowed to use commands, those commands could never be changed That's not a script thing, that's an API surface thing, and even then only applies to backwards-incompatible changes. You can change the arguments to git or chmod just as easily as printf() or fork()

As I said here already, the difference is that scripts are interpreted, rarely if ever check what version they're running on before they attempt to do something, and the authors of the scripts have been explicitly encouraged to memorize a heapload of letter permutations and throw a thermonuclear systemd-sized fit if something changes.

None of this is inherent to APIs.

Re: Git tips and tricks

#127

Post by goku12 »

elevatedastalt wrote: post #124
goku12 wrote: post #96

Earlier quoted context omitted.

> The snapshot include all the history that led to the current snapshot Git snapshots don't contain any history, other than the commit chain (reference to the parent commit/s) in the commit object. While the storage format is a bit complex, they behave fundamentally like a copy of the working tree at the point of commit. > So even if you did a squash instead of dropping, you're changing everything that depends on tha…

Yes, but since they change the commit id, and since each commit has a pointer to its parent commit, you have to rewrite all the commit objects, even if the tree doesn't change.

The context of my first comment is about how a rebase affects the contents of the tree. It's about predicting what happens to subsequent snapshots. Bringing commit ID and parent commit into that context complicates and obscures the point I'm trying to convey.

Re: Git tips and tricks

#128

Post by barreira »

renegade-otter wrote: post #61

I 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

Re: Git tips and tricks

#129

Post by js2 »

bloopernova wrote: post #123
svieira wrote: post #117

Earlier 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?

What version of git do you have? If it came with macOS and wasn't installed via homebrew, it's possible that it's old enough to cause problems.

git has had this behavior for at least a decade. As well, macOS does not ship with git - it's installed as part of either the Command Line Tools package and/or Xcode and is reasonably up to date.

For many years now, macOS has included what are effectively wrappers in /usr/bin for the various development tools and that use the xcode-select mechanism to run the actual command. If neither Xcode nor the CLT package are installed, you'll get a prompt to install the CLT package.

Re: Git tips and tricks

#130

Post by infogulch »

phillco wrote: post #114
goku12 wrote: post #39

Earlier quoted context omitted.

One thing about git I learned the hard way is the use of diffs and patches (more accurately, 3-way merges) for operations like merging, cherry picking and rebasing. Pro-git (correctly) emphasizes the snapshot storage model of git - it helps a lot in understanding many of its operations and quirks. But the snapshot model can cause confusion in the case of the aforementioned operations - especially rebasing. For exampl…

Julia Evans wrote a nice blog post about this recently, in that sometimes it's helpful to think commits as snapshots and sometimes as diffs. https://jvns.ca/blog/2024/01/05/do-we-think-of-git-commits-a... I guess while it's true the storage layer is snapshot based, as you say, that only gets you so far conceptually, and it's probably best to focus on the _operation_ you're doing, as rebase, cherry-pick, apply-patch,…

Commits have a dual snapshot-like and diff-like nature, depending on how you observe them.
Post reply on HN