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

Git Notes: Git's coolest, most unloved­ feature (2022)

tylercipriani.com

Post reply on HN
Print view View original

131–140 of 147 posts

Re: Git Notes: Git's coolest, most unloved­ feature (2022)

#131

Post by chrishill89 »

raju wrote: post #94
steve_adams_86 wrote: post #72

Earlier quoted context omitted.

Ha, I expected to know the features you were going to list, but got surprise attacked by pickaxe. What the hell? I guess I shouldn’t be so confident

pickaxe isn't a Git command, rather, it's a set of flags that `git log` offers (specifically `-S` and `-G`). Shameless plug: I recently did a webinar on how the pickaxe options are better than `git-blame`) that you can find here: https://nofluffjuststuff.com/webinar/142/level_up_your_git_g... (Note: It requires you to provide an email address).

"Pickaxe" most often means those options. But it's also a (apparently legacy) command alias for git-blame.

Re: Git Notes: Git's coolest, most unloved­ feature (2022)

#132

Post by chrishill89 »

rlpb wrote: post #90
xg15 wrote: post #88

Sounds really cool, but how do notes play together with the "history rewriting" features (amend, rebase, etc) where you effectively replace a commit with a modified copy? It sounds as if the notes are attached to a specific commit (or tree or blob) ID. Are git rebase etc smart enough to also copy over the notes to the new commit, or will they just vanish? What happens on interactive rebases, e.g. if I squash multiple…

> Are git rebase etc smart enough to also copy over the notes to the new commit... This is configurable. By default, amend and rebase operations will copy them forward. See git-config(1) under `notes.rewrite`.

By default no copying will be done. While `notes.rewrite.amend` and `notes.rewrite.rebase` are true you also need `notes.rewriteRef` which tells it what notes refs should be rewritten. And it has no value by default. (you can set it to a glob copy over all notes refs)

Re: Git Notes: Git's coolest, most unloved­ feature (2022)

#133

Post by chrishill89 »

knallfrosch wrote: post #49
lucasoshiro wrote: post #46

There are many "Git's coolest, most unloved feature", e.g.: bisect, pickaxe, reflog, range-diff, archive, annotated tags, etc. Sadly they are often forgotten as many people thing of Git only as a glorified Google Drive...

Git notes is redundant since you need a higher-level project management tool to track features anyway. Roadmaps, feature hierarchy and non-technical details. Think of any big tracker or Jira. I think that's fine. Unix philosophy is to focus on one thing and do that well.

There are many uses for Git notes even though you might use a project management tool. Particularly all those things which are relevant for developers only, or that the developers can use as the data source for "higher-level" goals.

Re: Git Notes: Git's coolest, most unloved­ feature (2022)

#134

Post by chrishill89 »

ozim wrote: post #102

It is not coolest most unloved feature. It is a gimmick feature that could have been cool in some really specific cases like team of only developers running the whole company. Whatever is needed goes into commit message and referencing tickets in separate system is a feature not a bug - because JIRA or any other system is used to communicate with non developers. Like business analysts don't get access to code or repo…

There’s plenty of data which is extra-commit (doesn’t belong in the commit messages but is relevant). Like if the tests passed[1], manual testing notes, iteration on code review, notes for code spelunking when you find a problematic 6+ month old commit.

[^1] https://news.ycombinator.com/item?id=44348438

Re: Git Notes: Git's coolest, most unloved­ feature (2022)

#135

Post by hinkley »

Zambyte wrote: post #107
hinkley wrote: post #73

Earlier quoted context omitted.

You’re treating a commit as an atom, which is not true in patch based git situations like Linux. Most of the rest of us do not work this way, but they still do. The rest of us also only have to deal with three way merges most of the time, instead of octopus merges. Though I jokingly call, “fixing an incorrect three way merge” a “five way merge” because you end up doing a star shaped pattern of diffs to re-resolve the…

I'm not really sure what you mean by this. Git treats commits as atomic (unchangeable), and thus they are atoms (indivisible). This is not really related to patches, unless you're referring to partially applying patch series. Can you elaborate on what you mean?

This guy explains it better than I could

https://news.ycombinator.com/item?id=44355218

Re: Git Notes: Git's coolest, most unloved­ feature (2022)

#136

Post by WorldMaker »

legends2k wrote: post #27

I discovered notes from the man pages around 2020 but didn't use them as it was primarily a local repo feature. By default they don't get pushed or fetched. If course, one can configure it such that it's pushed and fetched, but that's a team decision and mine didn't vote for it.

I feel like notes needs a more similar default to tags' updated defaults today: fetched/pulled by default but not pushed by default. It is useful to keep personal tags and personal notes and some people have workflows involving those, but once tags/notes are in the upstream repository, it should maybe be assumed that everyone should know about them.

Re: Git Notes: Git's coolest, most unloved­ feature (2022)

#137

Post by hinkley »

Pxtl wrote: post #126
hinkley wrote: post #74

Earlier quoted context omitted.

Can you say more? I use rebase to avoid history destruction/obscuration. Do you mean squash? If so then I agree.

Basically, the fact that any kind of tweaking to the history in terms of comments or grouping together related commits into a single commit changes the hashes. This means that git's normally useful ability to check "hey is commit X in the history of both branches A and B" is broken. That's a huge usability problem with git. Even as simple as a "rebase on merge" or "squash on merge" automation makes it impractical to…

Ah. I know about this. I’m used to people meaning different things when they say history destruction.

There’s also a fun loophole where you can edit other people’s commits when doing a merge and attribute bugs to someone else. I caught someone doing this once (they were terrible at git) on account of I was the one who reviewed the code that got changed, and I specifically looked for that class of bug before approving it. Git blame and the commit history no longer agreed and I was able to show what happened.

Re: Git Notes: Git's coolest, most unloved­ feature (2022)

#138

Post by Pxtl »

saghm wrote: post #129
GuB-42 wrote: post #113

Earlier quoted context omitted.

You do whatever you want on your own repository, but as soon as you make anything public, for me, it is here to stay, I consider every push to be pulled by someone else, and if you rebase or do anything to change your history, you have just created a new branch, even if you pretend it doesn't exist anymore using a push --force. Git is a decentralized version control system. It is effectively a blockchain like Bitcoin…

I guess we just fundamentally disagree with how using git should work. I don't agree at all that using git for a public repo somehow implies that you're committing to preserving every single branch in perpetuity just because the tool can support it. If it's confusing, I'd argue it's from mistakenly inferring that others are conveying intent by publishing public feature branches.

That's my core complaint about git's history-destroying behavior. Git wants you to make a clean history, but it also has awful behavior when you modify history that you've started collaborating with people upon.

It is a fundamental flaw. Either git needs to work better at using the history in all of its warty and real glory (for example offering a separate mutable presentation-layer commit-log in front of the immutable data-layer commit-log), or needs to provide better automation and mapping concepts that allow you handle incoming code that has a different history from the current branch.

Re: Git Notes: Git's coolest, most unloved­ feature (2022)

#139

Post by GuB-42 »

Pxtl wrote: post #138
saghm wrote: post #129

Earlier quoted context omitted.

I guess we just fundamentally disagree with how using git should work. I don't agree at all that using git for a public repo somehow implies that you're committing to preserving every single branch in perpetuity just because the tool can support it. If it's confusing, I'd argue it's from mistakenly inferring that others are conveying intent by publishing public feature branches.

That's my core complaint about git's history-destroying behavior. Git wants you to make a clean history, but it also has awful behavior when you modify history that you've started collaborating with people upon. It is a fundamental flaw. Either git needs to work better at using the history in all of its warty and real glory (for example offering a separate mutable presentation-layer commit-log in front of the immutab…

Git doesn't what you to have a clean history. Git just stores all the commits in a DAG structure, and then gives you a lot of freedom in what you make of it.

The git UI however is notoriously terrible, so your complain about presentation is probably justified, but it git itself offers facilities to keep a clean history without clobbering branches without changing the fundamentals.

For example, you can decide to make your clean branches only out of merge commits, so if you look only at the clean branches you will have the nice history you expect, but each commit will have a reference to a parallel ugly branch so you can see everything if you want to, without rewriting. To avoir conflicts polluting your clean branch, first merge the clean branch into the ugly branch, resolve the conflicts and do everything you need to do to stay up to date, then merge back into the clean branch, with a nice merge commit message. The clean branches merge commits are your "presentation layer".

It won't be mutable, but mutable anything is a problem in a distributed system like git that gives you availability but as per the CAP theorem, not consistency.

Re: Git Notes: Git's coolest, most unloved­ feature (2022)

#140

Post by ozim »

stopthe wrote: post #103
ozim wrote: post #102

It is not coolest most unloved feature. It is a gimmick feature that could have been cool in some really specific cases like team of only developers running the whole company. Whatever is needed goes into commit message and referencing tickets in separate system is a feature not a bug - because JIRA or any other system is used to communicate with non developers. Like business analysts don't get access to code or repo…

> business analysts don't get access to code or repositories at all for example or support people don't get access to the repositories and code. Yes, but isn't it insane? What is the benefit from treating your own product as a black box? Yet that's mainstream. Sometimes I have the analyst (not on my team, but from a team we share a monorepo with) asking me questions that can be answered literally with a line of code.…

I think you underestimate inefficiency of requiring all business analysts and employees to learn GIT. If not all employees than more employees. I can pick put up job ad for BA saying knows JIRA and I have dozens of applicants.

We had a technical guy once where I worked that wanted to force sales guys to use LaTex to write documentation and requirements in and store it in GIT. I feel bad for the guy as he was laughed out by sales guys and he did not understood why because those are such a great tools…

Post reply on HN