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

361–370 of 559 posts

Re: Is Git Irreplaceable? (2019)

#361

Post by jat850 »

barrkel wrote: post #316
tomesch1982 wrote: post #237

Earlier quoted context omitted.

Git is neither easy not is it really elegant. It is useful for projects like Linux™ but for the vast majority of projects way better tools like mercurial or fossil would be a much better fit.

After svn, git was a breath of fresh air; far easier to use and reason about, not to mention much faster. I don't think much of your all-in-one solution like fossil - that's a competitor for GitHub (without the bits that make GH good), not git. I tried to use hg at one point in the early days, and found it much slower than git. Git's low latency for commands made a substantial difference, perceptually. In principle I…

Can you explain what you mean by fossil being a competitor for github, rather than git? Fossil is a scm with additional features for usage, but (the last I used it, and to my memory) it was just the command line fossil very much like git, and that's how I used it.

What makes it the case that fossil cannot be a competitor to git (or hg), in that they are both a vcs?

edit I haven't had a lot of sleep. What I'm trying to ask, I suppose, is why can't you use fossil just like git and ignore any all-in-one features it provides? (This is not to comment on how good, scalable, fast, correct, or robust it is.)

Re: Is Git Irreplaceable? (2019)

#362

Post by oswamano »

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.

Honestly if we can reduce the tooling churn for development that sounds great

Re: Is Git Irreplaceable? (2019)

#363

Post by coldpie »

baud147258 wrote: post #348
coldpie wrote: post #326

Earlier quoted context omitted.

> At least in my experience, the interface makes a lot more sense if you understand the underlying data structure, which does have a certain elegant simplicity. Yeah. Take an afternoon to read through gittutorial(7), gittutorial-2(7), and gitcore-tutorial(7). Git is a tool, and just like any other tool (car, tablesaw), you will be much better off if you take the time to learn to use it properly. Once you see "The Mat…

The fact that you put Git in the same category as tools having a potential of inflicting grievous bodily harm if misused is telling. And why does Git require this whereas other VCS don't? Mercurial was incredibly easy to use nearly right out of the gate, not after an afternoon of work.

> The fact that you put Git in the same category as tools having a potential of inflicting grievous bodily harm if misused is telling.

They're just examples of tools.

> Mercurial was incredibly easy to use nearly right out of the gate, not after an afternoon of work.

I talk about this elsewhere in this thread, but I disagree with this assertion. I find Mercurial baffling and Git very elegant, though it could be an artifact of the order in which I learned the tools.

Re: Is Git Irreplaceable? (2019)

#364

Post by eyegor »

adrianmsmith wrote: post #312
saurik wrote: post #279

Earlier quoted context omitted.

Another simple tracking thing that git doesn't do that would easily make git much much better is if it tracked when you did a cherrypick of another commit in the commit graph (not just as some kind of metadata comment in the commit message, but as a kind of soft parent); then if you did a rebase, you could actually "reverse engineer" the rebase (if and only if you absolutely needed to, such as to track what happened…

Another thing that Git does not track - I saw a web designer check in a huge hierarchy of empty directories which would be the structure of the new project that their team should work on. They were quite surprised when it didn't show up on any of the other designer's computers after a "pull". They had to go to the "Git guru" for help. Windows and Mac both have directories as a major fundamental concept. Everyone know…

It kind of does, iff you have a file there. In which case it tracks the path to the file, and then creates the relevant directory structure to get to it.

Of course git is also incredibly painful and brittle if you want "exclude/except" behavior on the gitignore involving subdirectories.

Re: Is Git Irreplaceable? (2019)

#365

Post by jerf »

alkonaut wrote: post #255
dragonwriter wrote: post #236

Earlier quoted context omitted.

> I think it's simple and elegant as a data structure, when what people need and want is something that is (at least also) simple and elegant in its UX and most importantly VERY simple and elegant for the 80/20 use cases. That's what UIs (whether CLIs or otherwise) for standardized workflows like git-flow are, IMO.

It doesn't nearly go all the way there though. Why do people need to use a command line and a gui tool (usually) for git? Because it's fundamentally not written to be used with a GUI. That I think is one of its biggest flaws. Using a GUI with git always feels like you are missing vital information and just trying to poke a cli underneath to do what you want. Some design decisions also shine through like "no branch is…

"Why do people need to use a command line and a gui tool (usually) for git?"

You don't. The reason is that you're using a tool that didn't budget the time to directly work on git data files and it uses the command line under the hood, because that's a hard business case to make for most small tools. This is not fundamental to git; the very top-end git-based tools like Github or Bitbucket all do their own internal, direct implementation of git functionality for this reason. It's not a characteristic of git, it's a characteristic of the GUI tools you're using.

A perfectly sensible one based on perfectly sensible engineering tradeoffs, let me add; no criticism of such tools intended. Git's internals from what I've seen are not particularly difficult to manipulate directly as such things go, but you are simply by the nature of such a thing taking on a lot more responsibility than if you use the command line-based UI.

Re: Is Git Irreplaceable? (2019)

#366

Post by mschaef »

ldiracdelta wrote: post #344
baud147258 wrote: post #343

Earlier quoted context omitted.

>the interface makes a lot more sense if you understand the underlying data structure Except that I don't have to understand the underlying data structure to use a more basic VCS like Mercurial. What makes git so special that I would have to do that before being able to use it? And for recovery from mistakes, I meant stashing the changes somewhere, deleting the repository and downloading a clean copy to start again,…

You also don't have to understand the underlying structure for a similarly powerful DVCS like bitkeeper. Yes, it isn't open source, but git was a major step back in usability for my group from bk to git.

> git was a major step back in usability for my group from bk to git.

What does that mean in concrete terms? What are the failures you're seeing with git that you weren't with bk? How long has your team used git? bk?

Re: Is Git Irreplaceable? (2019)

#367

Post by mschaef »

baud147258 wrote: post #348
coldpie wrote: post #326

Earlier quoted context omitted.

> At least in my experience, the interface makes a lot more sense if you understand the underlying data structure, which does have a certain elegant simplicity. Yeah. Take an afternoon to read through gittutorial(7), gittutorial-2(7), and gitcore-tutorial(7). Git is a tool, and just like any other tool (car, tablesaw), you will be much better off if you take the time to learn to use it properly. Once you see "The Mat…

The fact that you put Git in the same category as tools having a potential of inflicting grievous bodily harm if misused is telling. And why does Git require this whereas other VCS don't? Mercurial was incredibly easy to use nearly right out of the gate, not after an afternoon of work.

> And why does Git require this whereas other VCS don't?

It doesn't. It just works better when you take the time to learn how it works. (Which is an experience I commonly have with the tools I use, for whatever that's worth.)

Re: Is Git Irreplaceable? (2019)

#368

Post by dev_north_east »

_ZeD_ wrote: post #133
jerf wrote: post #60

Earlier quoted context omitted.

Speaking personally, definitely no. Even before I heard of git, I did not like SVN. In particular, it made an error I don't hear many other people mention where directories were checked out to revisions, rather than entire repositories. Consequently it was very easy to accidentally update just a subset of your repository, and have your whole repository in a state that didn't exist in the version control system at all…

>>> [SVN] made an error I don't hear many other people mention where directories were checked out to revisions, rather than entire repositories. that is a feature! You don't know how I miss that! (that, and the handling of blobs)

> that is a feature! You don't know how I miss that!

Yep, handiest way to perform a first pass on narrowing down an introduced bug between a few commits.

Re: Is Git Irreplaceable? (2019)

#369

Post by icholy »

mikece wrote: post #320

The problem with Git is that the software and API aren't separated. Like all modern software, there should be an API or interface to which all distributed source control engines comply, allowing the specific DVCS engine to an implementation detail. Want the old-school one written in C by Linus? Fine. Want a revamped version of Mercurial that uses the same commands and creates the same repository format? Cool! Want to…

Go has a pretty solid git implementation https://github.com/src-d/go-git

Re: Is Git Irreplaceable? (2019)

#370

Post by ldiracdelta »

mschaef wrote: post #366
ldiracdelta wrote: post #344

Earlier quoted context omitted.

You also don't have to understand the underlying structure for a similarly powerful DVCS like bitkeeper. Yes, it isn't open source, but git was a major step back in usability for my group from bk to git.

> git was a major step back in usability for my group from bk to git. What does that mean in concrete terms? What are the failures you're seeing with git that you weren't with bk? How long has your team used git? bk?

We used bk when I was with the group for 3 years and then switched to git. Been using git for 8 years. I know git, but the ergonomics and basic English semantic meaning of commands is much worse. I have to look up git commands and subflags _all_ the time still for checking out old versions of files to a new file. Looking at tags. Commiting to a new branch, et c. Bk's version of gitk was superior and the usage was nicer. I've used mercurial, svn, cvs, git, and bk. Git is hard, but it is the standard now, so of course I'll continue to embrace it. Just not as ergonomic.
Post reply on HN