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

The git history command

lalitm.com

Post reply on HN
Print view View original

311–320 of 330 posts

Re: The git history command

#311

Post by inigyou »

kazinator wrote: post #303
inigyou wrote: post #282

Earlier quoted context omitted.

Don't change old commits. Change commits you haven't pushed yet.

That's not for you to dictate to someone about some project you have no idea about. Git is not a religion or cult. Whether you're rewriting published or unpublished commits, this particular problem is the same. If the commit series contains self-references---later commits in the series have commit messages which refer to the hashes of earlier commits---those references make no sense at all when the series is pushed u…

If you think me telling you how to use a product is religious or cult indoctrination, I dont really see how you are getting anything done while dodging the high priests of "man" and "info"

Re: The git history command

#312

Post by WorldMaker »

skydhash wrote: post #309
WorldMaker wrote: post #307

Earlier quoted context omitted.

I've seen some really bad trainwreck merges in rebase heavy workflows, too. (Unwinding them is awful.) Rebases create just as many merge conflicts as merge commits do [0], but rebases don't save the evidence for them. Just because the evidence was lost of them doesn't mean the merge conflict markers were never there. Any time you integrate two branches, no matter how long running or short running, you have possible m…

I do agree that merge conflicts are a signal of a deeper collaboration issue. > Merge conflicts are a necessary part of source control and sweeping them under the rug is one way with dealing with them, but in my opinion not exactly the healthiest way. I don’t agree that retaining them is necessary. Merge workflows encourage long running branches. Sometimes divergence in understanding does not create conflicts and tha…

Use merge commits does not mean using "merge workflows with long running branches".

"Merge early and often" is just as useful of a concept as "rebase often". The workflow is often exactly the same. The only real difference is extra commits to mark the merge points, and the extra commits are mostly just a UI issue when code reviewing.

A good PR UI (and GitHub isn't always, but it tries) doesn't show commits brought in from the base branch. (I think GitHub would have a simpler thing if it defaulted to a simpler `--first-parent` approach (rather than trying to math from the base branch) with an option to drill down, but I'm not a a GitHub UX designer.

Don't confuse the workflow with the DAG shape, that is more aesthetic than not.

Re: The git history command

#313

Post by NateEag »

klibertp wrote: post #257
NateEag wrote: post #131

Earlier quoted context omitted.

Don't forget mergiraf, for tree-sitter-based conflict resolution: https://mergiraf.org/

I absolutely love the images on the landing page. "Inappropriate use of blame, push and pull to resolve a conflict" is pure genius. Even the name had a lot of thought put into it (didn't know about "Giraffe language" before). Beautiful! :)

The documentation is truly a thing of beauty.

As someone who learned a lot from Non-Violent Communication, discovering mergiraf went something like

  > ...oh, cool - I've wanted this for years, great that someone buckled down and wrote it.
  >
  > Why 'mergiraf,' though? 
  >
  > [Sees NVC link on the site] 
  >
  > ...OH. Conflict resolution through understanding. That's absolutely brilliant, at so many levels.

Re: The git history command

#314

Post by rmunn »

bjackman wrote: post #163
rmunn wrote: post #25

Earlier quoted context omitted.

I have so many branches named `temp` or `before-rebase` for exactly that reason; I'm using them effectively as tags, but branches can be moved around with less ceremony than tags (since tags are designed to be for things like v1.2.3, placed once and then almost never moved again), so I usually just do `git branch before-rebase/some-feature` before running a big `rebase -i`. I've almost never needed to run `get reset…

After a rebase, mybranch@{1} refers to the previous location of mybranch, so you don't need to manually track these before-rebase branches etc. (In practice I find this syntax super annoying and usually end up typing `git reflog mybranch` and then copy-pasting the commit hash from the output).

TIL!

Re: The git history command

#315

Post by rmunn »

hack1312 wrote: post #118
rmunn wrote: post #25

Earlier quoted context omitted.

I have so many branches named `temp` or `before-rebase` for exactly that reason; I'm using them effectively as tags, but branches can be moved around with less ceremony than tags (since tags are designed to be for things like v1.2.3, placed once and then almost never moved again), so I usually just do `git branch before-rebase/some-feature` before running a big `rebase -i`. I've almost never needed to run `get reset…

This is the exact same thing I do, though with the prefix "pre-rebase/"

The fact that I misread that as "prebase" (I've done the same misreading with "prerelease" in the past, too) is why I prefer `before-rebase`, even though `pre-rebase` is slightly faster to type.

Re: The git history command

#316

Post by rmunn »

hnfong wrote: post #143
bad_username wrote: post #129

I was uncomfortable with git until I read (the first 3 chapters of) the pro git book ( free here : https://git-scm.com/book/en/v2 ). It provides a great mental model of how git works under the hood. The UI of git - for better or worse - directly reflects its internals. And when I understood them, everything clicked into place.

Same here. The git commands were confusing to me until I actually saw a Linus video on youtube explaining how the git data structures worked under the hood. It was dead simple, and one could easily mentally map the tools' functions onto how they operated on the data structures. Once I understood that, as you said, everything clicked into place. Somehow the "higher level abstractions" that git tries to do makes the th…

I've recommended https://learngitbranching.js.org/ to so many people. Something about seeing it visually, with the arrows pointing from child to parent, just clicks in the mind where a written explanation doesn't. (Not for everyone, of course: some people understand it quite well from the written explanation. But if your coworkers who don't grok Git are visual learners, https://learngitbranching.js.org/ might be the thing that helps them unlock a deeper understanding of what's going on with branches and HEAD and so on).

Re: The git history command

#317

Post by rmunn »

chrismorgan wrote: post #87
rmunn wrote: post #25

Earlier quoted context omitted.

I have so many branches named `temp` or `before-rebase` for exactly that reason; I'm using them effectively as tags, but branches can be moved around with less ceremony than tags (since tags are designed to be for things like v1.2.3, placed once and then almost never moved again), so I usually just do `git branch before-rebase/some-feature` before running a big `rebase -i`. I've almost never needed to run `get reset…

Diffing diffs is so valuable for that reason, seriously underrated. Once I even found a use case for diffing diff diffs. I also often wish to edit commits or resolve rebase conflicts or whatever by editing the patch rather than the files.

Seconded, I diff diffs all the time after a rebase or after merging the `develop` branch into my feature branch (which I sometimes do when the rebase would have produced so many merge conflicts over so many commits that it's just not worth the hassle, even using rerere — and since our team routinely uses the GitHub "Squash and merge" button, the develop->feature branch merge gets squashed away and doesn't end up showing up in the develop branch log once the PR is merged). It's the best way I've found to double-check that I didn't made a mistake in merge conflict resolution: does the diff from branchpoint to before-rebase still match the diff from new branchpoint to after-rebase? Yes? Then I probably didn't screw up the merge conflict resolution.

Re: The git history command

#318

Post by kazinator »

inigyou wrote: post #311
kazinator wrote: post #303

Earlier quoted context omitted.

That's not for you to dictate to someone about some project you have no idea about. Git is not a religion or cult. Whether you're rewriting published or unpublished commits, this particular problem is the same. If the commit series contains self-references---later commits in the series have commit messages which refer to the hashes of earlier commits---those references make no sense at all when the series is pushed u…

If you think me telling you how to use a product is religious or cult indoctrination, I dont really see how you are getting anything done while dodging the high priests of "man" and "info"

"Never rewrite public history", while it is a directive that talks about how to use a product or not used it, is just your personal preference, and nothing correct or incorrect.

Just like "never type a profane word into Vim" is ostensibly a statement about how to use Vim, but of no technical value related to Vim use.

It is nothing similar to advice such as using a screwdriver to drive screws and a hammer for nails.

Some people regard the git repository as the object they are working on and want to create the perfect history in it, yet also to ship regularly. That requires shipped history be revised.

It's entirely possible to work productively with an upstream that revises history, producing non-fast-forward changes.

There are things you have to do and know that are not required in FF-only workflows, but nothing too terrible.

Re: The git history command

#319

Post by psychoslave »

hackrmn wrote: post #179
Hendrikto wrote: post #171

Earlier quoted context omitted.

Git is not nearly as confusing as people make it out to be. They just never take the few hours it takes to understand it. Which is a sad state of affairs for such an essential tool in the belt of any software engineer. git commit -am “Changes” just does not cut it, if you call yourself a professional.

My observation has been that those who have never learned Git properly -- disregarding for a moment the issue with what "properly" means here -- just don't think they need to, sticking to very simple workflows that produce linear graphs featuring squash-rebased work throughout. Because they don't know Git's fundamental model (including what you'd think was the obligatory piece of information that commits are essentia…

SVN was damn slow and working with branches was a hell.

Git sucks on so many points that there ain't be enough walls in the world to write our lamentations about it. But it's damn fast. If I have a doubt, I just create a backup branch before messing with the work at stake, and the bottleneck will be the time I take to type the command.

And I don't know if SVN had some advanced mode to do any branch in local, but in my frightening memories full of scarces, one had to synchronize everything to the central repo to do anything.

Re: The git history command

#320

Post by psychoslave »

hnfong wrote: post #143
bad_username wrote: post #129

I was uncomfortable with git until I read (the first 3 chapters of) the pro git book ( free here : https://git-scm.com/book/en/v2 ). It provides a great mental model of how git works under the hood. The UI of git - for better or worse - directly reflects its internals. And when I understood them, everything clicked into place.

Same here. The git commands were confusing to me until I actually saw a Linus video on youtube explaining how the git data structures worked under the hood. It was dead simple, and one could easily mentally map the tools' functions onto how they operated on the data structures. Once I understood that, as you said, everything clicked into place. Somehow the "higher level abstractions" that git tries to do makes the th…

Can you point to this video please?
Post reply on HN