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

321–330 of 559 posts

Re: Is Git Irreplaceable? (2019)

#321

Post by breck »

deanCommie wrote: post #92
aylons wrote: post #83

Earlier quoted context omitted.

I don't think this should be part of version control, simply because is too tied to the environment and development practices that may not be shared by the whole set of current and future developers of any given project. The version control should keep the code history, not the paperwork history. What I think you're looking for could, however, use git as a platform for that. That's what GitHub, GitLab and the likes d…

I think the distinction you're drawing between code history and paperwork history is more arbitrary than you give it credit. If all we cared about was code history, a super pure "version control" system would have one trunk, no branches, and a sequentially increasing version number with no commit messages or author information. But if you can annotate an entire commit with a descriptive message, why not annotate a sp…

I would like a workflow with all of the features of GitHub (code reviews, issue tracking, etc), but everything stored in Git.

Perhaps every project might have a branch called "issues" or "reviews", etc. Not sure the best setup but generally the more I can do in my code editors the faster I can work.

Has anyone found good work patterns like that?

Re: Is Git Irreplaceable? (2019)

#322

Post by mschaef »

baud147258 wrote: post #294
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.

If its interface is not simple and elegant, I don't see how you can call git simple and elegant, since it's how all users will interact through the interface. And personally I prefer a VCS with less ways to shoot myself in the foot than git.

> If its interface is not simple and elegant, I don't see how you can call git simple and elegant, since it's how all users will interact through the interface.

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. (Even if it doesn't work quite the same as traditional source code control systems. Failing to work with directories is a problem of the git approach. Having a nice offline story is a distinct advantage.)

> And personally I prefer a VCS with less ways to shoot myself in the foot than git.

Oddly, the thing I love about git is how easy it makes it to recover from mistakes. Even if there are more ways to shoot yourself in the foot, there are also more ways to put your foot back exactly the way it was before you shot it. (If only real life worked that way!) This is what the immutable content storage under the hood of a git repository gets you.

If you know the commit hash (and there are a bunch of ways to easily keep track of these), you can get back to the state that's represented by that hash. Commands like merge/rebase/cherry-pick make this particularly easy by providing an '--abort' option that means "I've screwed this operation up beyond repair and need to bail out." And the abort works. As long as you had your target state committed, you can get back to it. (And if that's just a transient state that you don't want to persist, it's easy enough to squash it into something coherent.)

Re: Is Git Irreplaceable? (2019)

#323

Post by mschaef »

yodsanklai wrote: post #234
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.

I hope it's the last DVCS, if it can save me the hassle of learning a new one. There is some learning curve, but it works just fine once you know how to use it.

> I hope it's the last DVCS,

The only reason I'd disagree is if the next source code control system were somehow as much an improvement over git as git was over its predecessors.

> if it can save me the hassle of learning a new one.

Not to mention the hassle of converting all those legacy repositories, converting CI/CD, etc.

Re: Is Git Irreplaceable? (2019)

#324

Post by crazypython »

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…

Isn't its API the file system layout? I use GitUp, which interacts directly with the .git/ folder.

Re: Is Git Irreplaceable? (2019)

#325

Post by rkangel »

peteretep wrote: post #249
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.

> way better tools I work with a group of people who all know enough git that we're productive, and a few of us know enough git to solve complicated problem. I've not seriously considered fossil or mercurial -- what are the top three tangible benefits I'd get from them getting our team to switch?

I have never used Fossil, but I used to be a strong proponent of Mercurial. My advice is don't - Mercurial lost, git has won, and fighting against the current is just going to make your life harder.

The main advantage Mercurial has over git is a command line syntax that makes consistent sense. The operations you want to do are easy and as you try and do more complicated things, the new commands will be unsurprising and predictable. If you already know how to use git then this advantage is (mostly) irrelevant.

There are some other features that are interesting - Mercurial has a couple of different types of branches. Bookmarks are like git branches, whereas named branches are a completely different concept which can be useful. 'Phases' tracks whether commits have been shared, and prevents you rewriting (rebasing) them when appropriate.

If you do experiment, note that many 'power user' features are turned off by default. There is a robust extension system, and the default mercurial installation includes a load of standard ones. My config file includes the following to turn on some useful stuff ('record' is the most useful for a staging area like facility):

[extensions] pager = color = convert = fetch = graphlog = progress = record = rebase = purge =

Re: Is Git Irreplaceable? (2019)

#326

Post by coldpie »

mschaef wrote: post #322
baud147258 wrote: post #294

Earlier quoted context omitted.

If its interface is not simple and elegant, I don't see how you can call git simple and elegant, since it's how all users will interact through the interface. And personally I prefer a VCS with less ways to shoot myself in the foot than git.

> If its interface is not simple and elegant, I don't see how you can call git simple and elegant, since it's how all users will interact through the interface. 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. (Even if it doesn't work quite the same as traditional source code control systems. Failing to work…

> 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 Matrix" behind Git, it becomes an incredibly easy to use and flexible tool for managing source code and other plaintext files.

Re: Is Git Irreplaceable? (2019)

#327

Post by orf »

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…

There is, it's the .git directory. Both the protocol and the directory are well specified. See libgit2 for an example non-reference implementation.

I think someone even built an implementation in bash, but I can't seem to find it now.

Re: Is Git Irreplaceable? (2019)

#328

Post by chrisweekly »

MaulingMonkey wrote: post #271
taftster wrote: post #188

Earlier quoted context omitted.

Do you have tools that you can utilize diffs from your binary file changes? Or does a change simply just replace all the bytes. I'd argue if it's the later, that git was never the right choice to begin with. You don't really want to record a full 10MB of data every time you change one pixel in your texture or one blip in your sound, right? So I don't know if this is a "major limitation" of git per se. Not saying ther…

While I can't speak for the person you're replying to, the technology at least exists. Binary diffs are sometimes used to distribute game updates, where you're saving on bandwidth for thousands if not millions of players - which costs enough $$$ to actually be worth optimizing for. On the other hand, between simpler designs and content encryption being sometimes at odds with content compression ... so is just sending…

"Having an exact binary copy of a build a bug was reported against can be incredibly useful."

Sure, immutable build artifacts can be invaluable -- but aren't they also an orthogonal concern?

Re: Is Git Irreplaceable? (2019)

#329

Post by orf »

squiggleblaz wrote: post #215
comex wrote: post #48

Git's biggest flaw is that it doesn't scale. If a new system can fix that without sacrificing any of Git's benefits, I think it can topple Git. It's ironic that Git was popularized in the same era as monorepos, yet Git is a poor fit for monorepos. There have been some attempts to work around this. Google's `repo` command is a wrapper around Git that treats a set of smaller repos like one big one, but it's a (very) le…

The only way I've ever successfully `git clone`d my work repo is from another locally connected device. Even with shallow and then gradually unshallowing it, it will not generally complete before the internet falls over. Nowadays, a new computer means a git clone (or just plain copy-paste) of a USB stick from the old one. This seems like it's a single feature of git that could be written, but if you told me "there's…

I'm guessing your work repo is has lots of large binary files in it's history?

Re: Is Git Irreplaceable? (2019)

#330

Post by vnorilo »

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.

After using darcs, I can never see Git as elegant, no matter how clearly it is a more pragmatic choice these days.
Post reply on HN