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

Extremely Linear Git History

westling.dev

Post reply on HN
Print view View original

51–60 of 366 posts

Re: Extremely Linear Git History

#51

Post by koliber »

oneeyedpigeon wrote: post #43
zegl wrote: post #27

Earlier quoted context omitted.

Thanks for sharing, this is really cool! Using whitespace is a really clever trick, and running on the GPU makes it even more impressive. I've been using githashcrash [1], but it's only running on the CPU, which is why it's a bit slower. :-) [1]: https://github.com/Mattias-/githashcrash

Using whitespace is cool, but you know what would be really cool? Using a thesaurus to reword the commit message until it matches the hash :)

... or refactor the code using an automated thesaurus and a bit of AI in a way to generate a particular hash.

- Hey Bob, why did you rename the 'pick_person' function to 'choose_desirable_candidate'?

- git made me do it

Re: Extremely Linear Git History

#52

Post by chrismorgan »

It has been my habit for a while to make the root commit 0000000 because it’s fun, but for some reason it had not occurred to me to generalise this to subsequent commits. Tempting, very tempting. I have a couple of solo-developed-and-publicly-shared projects in mind that I will probably do this for.

Re: Extremely Linear Git History

#53

Post by whoooooo123 »

oneeyedpigeon wrote: post #43
zegl wrote: post #27

Earlier quoted context omitted.

Thanks for sharing, this is really cool! Using whitespace is a really clever trick, and running on the GPU makes it even more impressive. I've been using githashcrash [1], but it's only running on the CPU, which is why it's a bit slower. :-) [1]: https://github.com/Mattias-/githashcrash

Using whitespace is cool, but you know what would be really cool? Using a thesaurus to reword the commit message until it matches the hash :)

Only works if your commit message is written in hexadecimal characters

Re: Extremely Linear Git History

#54

Post by conaclos »

Another approach could be to use prefixes. A 0 could separate the prefix (fixed hash part) from the suffix (random part).

  0
  10
  20
  ...
Combined with auto-completion, you preserve the main advantage (ordering) and you are able to quickly compute the hash.

Re: Extremely Linear Git History

#55

Post by entropy_ »

oneeyedpigeon wrote: post #41

I bet I wasn't the first person who thought this would have to be done by modifying actual file content — e.g. a dummy comment or something. That would clearly have been horrible, but the fact that git bases the checksum off the commit message is... surprising and fortunate, in this case!

It's a hash of everything that goes into a commit, including the commit message. The idea is that nothing that makes up a commit can change without changing the hash.

Re: Extremely Linear Git History

#56

Post by chrismorgan »

eru wrote: post #46
Zoadian wrote: post #31

Earlier quoted context omitted.

which just means: lets waste many hours coordinating, for the benefit of having a 'nice looking' history.

You realise that this is a joke project?

I would not call this a joke project. It’s a fun and optional sort of a thing, but there’s no reason why you shouldn’t take it seriously, provided your approach to work makes it compatible.

Re: Extremely Linear Git History

#57

Post by DaiPlusPlus »

enriquto wrote: post #42
bigDinosaur wrote: post #14

Earlier quoted context omitted.

This doesn't handle the reasonably common case very well where someone is working on changes which are constantly breaking the branch for everyone else. They should have their own branch and be frequently rebasing/merging so as to not disrupt others. Also exploratory branches where any nonsense may go on (that may end up being merged, at least partially!). Also test/development vs. production branches! One may be bro…

> the reasonably common case very well where someone is working on changes which are constantly breaking the branch But isn't this bad practice? My grug brain refuses to commit anything that does not pass tests. Check tests, then commit. Check tests, then commit. You can hide your as yet incomplete feature inside an undocumented option, and work from there, without breaking anything.

How do you handle major refactoring, or entire directory structure reorganisation? Stuff like that you can’t hide behind a switch.

Re: Extremely Linear Git History

#58

Post by masklinn »

larschdk wrote: post #49

I want the 'merge' function completely deprecated. I simply don't trust it anymore. If there are no conflicts, you might as well rebase or cherry-pick. If there is any kind of conflict, you are making code changes in the merge commit itself to resolve it. Developer end up fixing additional issues in the merge commit instead of actual commits. If you use merge to sync two branches continously, you completely lose trac…

I think merge is great, having a “unit” for a feature branch being integrated is nice and not all things can be done in commits which are individually justifiable. The ability to bisect cleanly through the first ancestor is precious.

I do agree that resolving conflicts in merges is risky though. It can make sense when merging just one way between permanent branch (e.g. a 1.x branch into a 2.x), but as soon as cross merges become a possibility it’s probably a mistake.

Re: Extremely Linear Git History

#60

Post by belinder »

oneeyedpigeon wrote: post #41

I bet I wasn't the first person who thought this would have to be done by modifying actual file content — e.g. a dummy comment or something. That would clearly have been horrible, but the fact that git bases the checksum off the commit message is... surprising and fortunate, in this case!

I feel like it would be better to have some dummy file in your repo that the tool modifies than mucking up your commit messages
Post reply on HN