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

Things I just don't like about Git

cohost.org

Post reply on HN
Print view View original

101–110 of 118 posts

Re: Things I just don't like about Git

#101

Post by funklute »

Buttons840 wrote: post #100
funklute wrote: post #97

Earlier quoted context omitted.

> then git gives you the tools to ensure the repos you control are not rewritten I might betray my ignorance here, but what tools are those? If I host a git repo, then I can obviously ensure that any branches on the origin are never rewritten. But how can I ensure that people who submit pull requests have not rewritten their history?

> I can obviously ensure that any branches on the origin are never rewritten That is all I meant. As you say, people can still rewrite their own history on their own computer before submitting it. We could get philosophical about what "history" is. If I press backspace am I rewriting history? What granularity are we talking here? If I make change X by frequently committing and then squash, have I rewritten history? I…

Ah, fair enough!

On my team we use pre-commit[0] a lot. I guess I would define the history to be something like "has this commit ever been run through our pre-commit hooks?". If you rewrite history, you'll (usually) produce commits that have not been through pre-commit (and they've therefore dodged a lot of static checks that might catch code that wasn't working, at that point in time). That gives some manner of objectivity to the "history", although it does depend on each user having their pre-commit hooks activated in their local workspace.

[0]: https://pre-commit.com/

Re: Things I just don't like about Git

#102

Post by vidanay »

domador wrote: post #54
miohtama wrote: post #6

Earlier quoted context omitted.

Back in a day, late 00s, early 10s, Git had alternatives. - Bazaar - Mercurial (Hg) Both had superior user experience compared to git, including command line and GUIs. They were not as fast, but no slow either if you came from Subversion world. They were not as flexible, but still very very flexible. What caused Git to win was not rants of Linus Tolvards, but Github. Github gave Git a semi-understandable web user int…

I wish I lived in an alternate timeline where a delightfully unpronounceable service called HgHub had won the day instead. But on a more open-minded note, would Github been just as successful if they had used something other than Git for the backend? Or was Git already popular enough that Github had essentially no other choice but to use it instead of another DVCS if they wanted to become the dominant player in their…

It was called "Kiln" and integrated beautifully with FogBugz (both from Fog Creek). We used them for nearly 10 years.

Re: Things I just don't like about Git

#103

Post by gavinhoward »

UweSchmidt wrote: post #87
gavinhoward wrote: post #80

Earlier quoted context omitted.

Not in a file explorer, sadly. However, I was going to make a browser UI from the start. I could implement a branch and file explorer in that UI, which would allow you to do the same thing. Would that be good enough or not? I'd love to know because I want to build this tool for humans first.

Probably, yes. Anything that does not require thinking in current Git-logic. I don't mind Git that much in everyday work but if something nicer came along, that would be great. I do think that Git is very well established, and it would probably take a major player, maybe Azure or AWS with a cloud-based IDE to change paradigms.

Thank you.

I just realized something: maybe I can make it so regular file explorers work.

I had intended to use something like Fossil's checkouts. I could formalize it; each branch the user wants could be a separate directory in the repo directory.

While I hate that, people seem to like it. I think I will do it.

Thank you for pointing me in the right direction.

Re: Things I just don't like about Git

#104

Post by politelemon »

> git for windows does "merge rebase" commits that preserve history during rebases: it creates a merge commit with the latest version, replays the existing commits atop...

Could someone show what this command looks like or link to docs? Searching for it produces a lot of rebase Vs merge results.

Re: Things I just don't like about Git

#105

Post by UweSchmidt »

gavinhoward wrote: post #103
UweSchmidt wrote: post #87

Earlier quoted context omitted.

Probably, yes. Anything that does not require thinking in current Git-logic. I don't mind Git that much in everyday work but if something nicer came along, that would be great. I do think that Git is very well established, and it would probably take a major player, maybe Azure or AWS with a cloud-based IDE to change paradigms.

Thank you. I just realized something: maybe I can make it so regular file explorers work. I had intended to use something like Fossil's checkouts. I could formalize it; each branch the user wants could be a separate directory in the repo directory. While I hate that, people seem to like it. I think I will do it. Thank you for pointing me in the right direction.

Good luck!

Re: Things I just don't like about Git

#106

Post by jonmayer »

fouc wrote: post #94
jonmayer wrote: post #19

I wrote my company's git wrapper. It was meant to standardize our workflow and to be communal memory for every lesson learned and sharpened edge shaved. It's now 6000 lines of bash. (Ok, I'm a little proud of it. I'll open source it as soon as I rewrite it in Python.)

> I'll open source it as soon as I rewrite it in Python. Realistically speaking, will that happen? Why not throw up the bash code as a separate repository from the python one anyways? As an example. Could throw it into archived mode right after or something perhaps.

It will happen, but if you want to see the bash, warts and all, here you go.

https://github.com/enfabrica/enkit/blob/master/scripts/gee

One of the big issues you'll find is that some off the defaults are very specific to my company. I'll fix that in the rewrite.

Re: Things I just don't like about Git

#107

Post by halostatue »

domador wrote: post #54
miohtama wrote: post #6

Earlier quoted context omitted.

Back in a day, late 00s, early 10s, Git had alternatives. - Bazaar - Mercurial (Hg) Both had superior user experience compared to git, including command line and GUIs. They were not as fast, but no slow either if you came from Subversion world. They were not as flexible, but still very very flexible. What caused Git to win was not rants of Linus Tolvards, but Github. Github gave Git a semi-understandable web user int…

I wish I lived in an alternate timeline where a delightfully unpronounceable service called HgHub had won the day instead. But on a more open-minded note, would Github been just as successful if they had used something other than Git for the backend? Or was Git already popular enough that Github had essentially no other choice but to use it instead of another DVCS if they wanted to become the dominant player in their…

Bitbucket was the original Mercurial hosting site. They only added git years later after it was clear that Mercurial had (at best) stalled, and removed Mercurial when it was clear that no one cared about it anymore.

Re: Things I just don't like about Git

#108

Post by miohtama »

Macha wrote: post #77
CableNinja wrote: post #51

Earlier quoted context omitted.

git gained popularity way before github/gitlab. Its popularity stemmed from the features that CVS and SVN were severely lacking. Github just made it easier to share and discover projects, and it happened to use git. It also helps that github was not a target for foss, instead it was started as a business. Before then, git, cvs, svn, were all foss projects and hosted (usually mostly) by the project owners.

Define popularity? SVN was still the majority platform because Sourceforge and Google Code were the most popular publicly accessible project hosting platforms. A lot of the self-hosted projects were still on CVS repos, often without anonymous access, so you'd just get tarballs of the source code with releases as a non-contributor. My memory is definitely that github adoption drove git adoption by basically its code f…

Also open source developers had to find a new home

- SourceForge had become questionable with its inclusion of its own malware in installers https://arstechnica.com/information-technology/2016/06/under...

- Google Code was untrusted, because they have a tendency to rug pull their products now and then

Github served a market need.

For others

- Bazaar was too Ubuntu specific (was in-house Ubuntu project originally)

- Bitbucket kind of survived as Atlassian

Re: Things I just don't like about Git

#109

Post by plorkyeran »

SQLite wrote: post #71
danShumway wrote: post #49

Earlier quoted context omitted.

> e.g. rewriting history, as is necessary for kernel-scale projects, is an unwavering absolute no-no in fossil We could go further, but yeah, this is basically the biggest problem. I know this is a fundamental attribute of Fossil and that's fine, but to me it makes Fossil unusable as a VC system for most serious projects. I don't think of VC as an immutable record, I think of it as a tool for organization and collabo…

Yeah - I'm very much about maintaining an immutable record. That is why, back in 2006, I started designing Fossil to control SQLite, instead of just switching to Git. I think that proper version control should be immutable. If history is changeable, what's the point in having history at all? It ceases to be "history" and becomes just a fable or hagiography. Mistakes happen, and it is important to be able to correct t…

History is only immutable once it's committed to Fossil, and anything not committed is lost forever. This may sound banally obvious, but I think it's fundamentally the problem with Fossil's approach. With git I essentially commit my entire undo/redo stack. I end up discarding most of that later, while with Fossil I would never have committed those intermediate versions in the first place.

Without history rewriting, the rewriting simply takes place before committing instead of after.

Re: Things I just don't like about Git

#110

Post by joshka »

gavinhoward wrote: post #103
UweSchmidt wrote: post #87

Earlier quoted context omitted.

Probably, yes. Anything that does not require thinking in current Git-logic. I don't mind Git that much in everyday work but if something nicer came along, that would be great. I do think that Git is very well established, and it would probably take a major player, maybe Azure or AWS with a cloud-based IDE to change paradigms.

Thank you. I just realized something: maybe I can make it so regular file explorers work. I had intended to use something like Fossil's checkouts. I could formalize it; each branch the user wants could be a separate directory in the repo directory. While I hate that, people seem to like it. I think I will do it. Thank you for pointing me in the right direction.

It's not impossible - https://github.com/g2p/git-fs did this a long while back and https://github.com/presslabs/gitfs did something similar too.
Post reply on HN