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

Is Git Irreplaceable? (2019)

fossil-scm.org

Post reply on HN
Print view View original

491–500 of 559 posts

Re: Is Git Irreplaceable? (2019)

#491

Post by theamk »

SQLite wrote: post #380
theamk wrote: post #317

Earlier quoted context omitted.

Does not Fossil’s “no rebases” philosophy bother you? IMHO, the ability to “commit early, commit often” and to squash/rebase original work later into clean and understandable commits is one of the best features of Git.

https://fossil-scm.org/fossil/doc/trunk/www/rebaseharm.md

Right - and I think that point 6 and 7 are exactly why I use rebase daily, and why I will never use Fossil.

The version control history is made for reading by other people, so it is a story. After all, we only write the commit once, but people will read it many more times. (This is especially true if there are code reviews involved)

I am an imperfect programmer. My work-in-progres is often broken, and even fails to compile. Sometimes I will refactor interface only, and will want to checkpoint my work before I go and refactor implementation as well. Sometimes I will choose a totally wrong approach and revert it later. Sometimes I will disable/break large part of system on purpose, to make testing easier. And I often do stupid data-destroying mistakes, so I want an ability to save/store all the past versions, even if they are completely broken.

My “raw” commits may look like: “start on feature X”, “refactor interface Y”, “more work on feature X”, “wip commit”, “fix tests”, “fix performance”, “fix more tests”. Does any future reader care it took me 3 commits to get the tests right? Do they care that I discovered the need to refactor only while I was halfway in feature X implementation? Do they want to see a repo that won’t even compile? Do they want to hav to cherry-pick dozens of commits to get the tests to pass? I don’t think so.

The final version will only have two commits, “refactor” and “feature X”. It would be obvious to everyone which lines of code are associated with which change. Each revision will be buildable, and will pass all tests - so bisect will actually work.

(If rebase support is missing, it is possible to “fake” it by having multiple checkouts and manually copying files around. But this is much more error prone and dangerous. I have spent plenty of time with SVN/CVS, manually copying files and applying patches - and I can tell that having this integrated with version control is much more pleasant)

Re: Is Git Irreplaceable? (2019)

#492

Post by Ntrails »

vvillena wrote: post #355
Ntrails wrote: post #332

Earlier quoted context omitted.

As a very basic git user, about once a month my local git repository will get into a state I cannot fix. I cannot revert, cannot reset, cannot make it just fucking be the same as origin/master. Usually I accidentally committed to local master and then did a couple other things and it's just easier to blat and re-clone than work out how to resolve. Git is hard for idiots imo, and there are a lot of us

> Usually I accidentally committed to local master and then did a couple other things Create a new branch and check it out while you are on the last commit (git checkout -b my-branch), delete the master branch (git branch -D master), and pull it again (git pull -u origin master). You'll end up with a local branch with a bunch of commits that you can merge, rebase or cherrypick, depending on what you want. If you want…

Deleting master is a thing that would _actually_ never have occurred to me! A neat trick

That being an example that I remember from late last year, there are just sharp edges to git I end up catching myself on :)

Re: Is Git Irreplaceable? (2019)

#493

Post by bhaak »

jerf wrote: post #477
bhaak wrote: post #475

Earlier quoted context omitted.

They still work. You can still develop with them. In that sense they aren't fatally flawed even today. 2018, 16% still used Subversion. https://insights.stackoverflow.com/survey/2018#development-p... But that's the hope, that we have something better by 2040, that makes today's Git look as outdated as CVS/Subversion looks to us now.

You're really doubling down on applying deliberately hostile definitions to what I said, aren't you? I get to tell you what I meant. You don't get to pick the definitions I was using, especially after I told you you explicitly you picked the wrong one.

You didn't really define what you meant with "fatal flaws". You just claimed that git didn't have them.

But if your Subversion example is one of those fatal flaws, then I just link to his example of Git usage that probably happens more often than we want to admit https://xkcd.com/1597/

Using your tool wrong is not a fatal flaw of the tool.

Re: Is Git Irreplaceable? (2019)

#494

Post by anoncake »

wyoung2 wrote: post #446
anoncake wrote: post #424

Earlier quoted context omitted.

> The problem is, is that git will happily destroy history. No, people will happily destroy history. Git is just a tool.

Fossil's opinion on this is that history is an immutable record of project history. It may be messy and unfortunate at times, but it is what happened, and it shouldn't be altered in place any more than you'd do that with an accounts ledger. In extremis, Fossil offers the "shun" command to remove improperly-committed artifacts, but even then it's subject to a lot of restrictions. ( https://fossil-scm.org/fossil/doc/tr…

> Fossil's opinion

Tools don't have opinions, people do. Fossil is just inflexible.

You don't want to alter history? Don't do it then. Git supports not altering history just fine.

Re: Is Git Irreplaceable? (2019)

#495

Post by anoncake »

phkahler wrote: post #334
tasuki wrote: post #199

> I worry that Git might be the last mass-market DVCS within my lifetime. The possibility of git being the last mass-market DVCS within my lifetime leaves me with warm fuzzy feelings. Git is simple and elegant, though its interface might not be.

>> The possibility of git being the last mass-market DVCS within my lifetime leaves me with warm fuzzy feelings. Agreed. Technology should converge on a best solution so we can stop chasing things and get work done. Stable open source standard solutions are what we need more of. Some anti-pattern examples are C++ and Vulcan.

You want technology to converge without changing? That's impossible.

Re: Is Git Irreplaceable? (2019)

#496

Post by anoncake »

Frondo wrote: post #447
munmaek wrote: post #442

Earlier quoted context omitted.

Git already has layers on top of it like git porcelain or the various GUI tools that attempt to handle things smoothly. > significant time and energy All someone needs is to read through https://rogerdudler.github.io/git-guide/ , and learn a few commands. Are we seriously going to refer to “reading the manual” as “significant time and energy”? In this case you don’t even have to read the manual, just a primer on how…

Because a lot of us have used tools besides git that enable the workflow we need without that complexity, and without the fragility that often necessitates going to stackoverflow or asking on a slack channel. I have a way of picking the losing side so I've been using mercurial for everything until now, and until now Bitbucket offered hg. They're decommissioning it so I'm moving over to git and I feel like my workflow…

> Because a lot of us have used tools besides git that enable the workflow we need

Thankfully the standard DVCS is flexible enough to enable the workflows others need too.

Re: Is Git Irreplaceable? (2019)

#497

Post by phkahler »

stcg wrote: post #468
phkahler wrote: post #334

Earlier quoted context omitted.

>> The possibility of git being the last mass-market DVCS within my lifetime leaves me with warm fuzzy feelings. Agreed. Technology should converge on a best solution so we can stop chasing things and get work done. Stable open source standard solutions are what we need more of. Some anti-pattern examples are C++ and Vulcan.

> Some anti-pattern examples are C++ and Vulcan. Are you referring to the Vulkan API? If so, why do you see it as an anti-pattern example? I like the API and I think it is a great and necessary improvement over OpenGL. I actually hope to see Vulkan become the ‘stable open source standard solution’ for graphics.

Maybe I should have said OpenGL since it keeps getting new versions. Does Vulcan? It just seems like kronos keeps moving the target.

Re: Is Git Irreplaceable? (2019)

#498

Post by alkonaut »

wyoung2 wrote: post #486
alkonaut wrote: post #483

Earlier quoted context omitted.

I’d guess not one user in 100.000 uses git decentralized (as in, doesn’t have a blessed “central” repo). It’s the disabling of locking that should be the special case! The big problem with git is that you can’t mark a repo as a master repo/blessed repo (which would be the one where lockfiles are stored). A lot of functionality would be helped if the commands could know which end is the important/central one.

> I’d guess not one user in 100.000 uses git decentralized I understand your sentiment, but the denominator in that fraction is probably much lower than your guess. Consider even simple cases like the disconnected laptop case. You may work at a small office with only local employees, and so you have one central "blessed" repo, but if one person locks a file and then goes off to lunch, working on the file while at the…

Not sure I understand the problem. If I lock fileX and go to lunch, then I own the lock on that file while I’m out to lunch. It’s basically analogous me pushing the file fileX.lock to the repo next to fileX, with my user id as content. I can only do it if it isn’t there.

Everyone else will only see that lock if they fetch and if they don’t, they might edit their local copy of fileX too, but would be prevented from pushing their version to the blessed repository by the lock. They can push a copy under another name, or wait until I have removed the lock (but probably can’t resolve the conflict anyway because it’s likely a binary document). So they user will remember to never start editing without taking the lock in the future.

It’s not perfect by any stretch of the imagination but it’s all anyone asks for in terms of file locking. It’s what Subversion always did.

Re: Is Git Irreplaceable? (2019)

#499

Post by jnurmine »

wyoung2 wrote: post #479
jnurmine wrote: post #471

Earlier quoted context omitted.

By the way, the "one checkout per repository" is not strictly true. You can use "git worktree"; this is a lightweight way to reuse an existing git repository and have each worktree use a different branch. It's a nice feature, and I use it daily. Also, a comment about the argumentation in "test before commit". It feels a bit artificial wrt. what can be done locally, what git commit and git push do and what their relat…

> By the way, the "one checkout per repository" is not strictly true. You must be referring to just the table at the top, not to the detailed argument below, which mentions git-worktree and then points you to a web search that gives a bunch of blog articles, Q&A posts, project issue reports and such talking about the problems that come from using that feature of Git. I suspect this is because git-worktree is a relati…

> You must be referring to just the table at the top, not to the detailed argument below

Well, not entirely, because in my opinion the detailed argument kind of hand-waves away the entire git worktree. Continuously switching branches inside a single large Git repo is certainly a suboptimal way to work with Git, but most of the time one should be able to avoid that with the worktree (though the worktree stuff is, of course, not a miracle cure for everything).

Re: Is Git Irreplaceable? (2019)

#500

Post by frutiger »

hinkley wrote: post #184
frutiger wrote: post #151

Earlier quoted context omitted.

> Imagine instead of that were available as a sort of materialized view. I don’t understand what you mean by this, can you provide some more detail?

Why do we have byte code? Why not run everything in interpreters? Because parsing pure text takes a lot of work. So we store it in an intermediate mode to economize. Saying just parse it every time is denying that there are very real costs associated with hat decision.

You can store the result of the parse in git if you want to.
Post reply on HN