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

521–530 of 559 posts

Re: Is Git Irreplaceable? (2019)

#521

Post by bhaak »

chucky wrote: post #371
bhaak wrote: post #313

Earlier quoted context omitted.

Look at the URL: "rewriting-history" Ammending changes the hash of the commit. That doesn't matter if you haven't pushed it yet but if you have, you can't push the change upstream without force-pushing. And if I want to change a commit message further back in history (regardless of my own or of somebody else), it would branch off at that point from the upstream git history. What I want is that you could put multiple…

You can accomplish something like this by using git-notes ( https://git-scm.com/docs/git-notes ). You'd have to have your own tooling to read/write these in a convenient way of course.

Yes but they are just a patch over the missing functionality.

The key point is "your own tooling". Git has a great tool universe but unfortunately you immediately lose many tools if you go beyond what the core offers.

Re: Is Git Irreplaceable? (2019)

#522

Post by mikl »

int_19h wrote: post #256
mikl wrote: post #229

Earlier quoted context omitted.

Git scales well enough for almost everyone (especially if you have a little discipline with what you put in the repo). It’s only huge megacorps that need larger scale things like GVFS. As for large files, that is not what Git is for. Git is for source code . Much like how you don’t put large files in your RDBMS, you should not be putting them in your SCM either.

What if you need to version them? Git imposes a very specific versioning model: version is a property of the entire repository. Thus, not including some file in the repo implies that it's not versioned in the same manner. It's not just a function of binary vs source.

Versioning big binary blobs is not what Git was designed for. It’ll do fine with smaller assets like icons and the like, but its data model is based on everyone using the repo having a local copy of the full repository history. You can’t easily purge old data. That scales poorly if you want to use it for audio/video files or other large data sets.

You can still do it if you want, but you might be better served using https://git-lfs.github.com/ or using another system designed for that purpose.

Re: Is Git Irreplaceable? (2019)

#523

Post by GuB-42 »

reissbaker wrote: post #186
kccqzy wrote: post #152

Earlier quoted context omitted.

Mercurial is probably that competitor. Only slightly slower than Git. Works on very large monorepos (as large as Facebook's or Google's monorepo). Very similar workflow as compared to Git, with some minor differences in terminology.

As an FB employee, I use hg regularly (because it is required). I would not use it as a git replacement for non-FB-sized repos. It has some weird design choices (e.g. branching is bad), and it very often requires manual intervention for merges that git performs correctly and automatically. You can get around branching-is-bad by changing your workflows a bit, but you can't get around the bad merges: over time it's lik…

What is so bad about mercurial branching? The underlying structure is the same as git: a directed acyclic graph, the only real difference is how branches are named.

Mercurial has 3 ways of doing branching:

- bookmarks: these are like git branches, a pointer to a revision

- branches: when you are in a branch, all commits are permanently affixed with that branch name. Less flexible than bookmarks (and therefore git branches) but good for traceability

- heads: unlike with git, a branch name can refer to several actual branches, it usually happens when you are pulling from a central repository, but you can create them yourself if you need some kind of anonymous branching. These can be pushed but it is not recommended.

Git only has the first option.

The way central repository are managed is also a bit different even if the fundamentals are the same. Git has the "origin" namespace to distinguish remote branches from local branches. Mercurial uses a "phase" which can be "public" (in remote), "private" (local only, will become "public" after a push) and "secret" (like "private", but will not be pushed and therefore will not become "public"). So if you are not synchronized with the remote, in git you will have two branches: origin/my_branch and my_branch, in mercurial, you will have two branches named my_branch, one public, one private. That's essentially the same thing, presented differently.

In the end, they are fundamentally the same. The feel is different though. Git is flexible, and gives you plenty of tools to keep things nice and clean when working with large, distributed project. As expected for something designed for the Linux kernel. Mercurial focuses on preserving history, including the history of your mistakes, and I feel it is better suited for managed teams than a loosely connected community.

Re: Is Git Irreplaceable? (2019)

#524

Post by wyoung2 »

balfirevic wrote: post #511
wyoung2 wrote: post #479

Earlier quoted context omitted.

> 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…

> Fossil is made to work that way from the start, so you can't run into these problems with Fossil. You'd have to go out of your way to use Fossil in the default Git style, such as by cloning into ~/ckout/.fossil and opening that repo in place. That's unfortunate. Reading the comments here, switch-branch-in-place is seen as some kind of flaw, but I don't think I would voluntarily use a VCS that doesn't let me easily…

> switch-branch-in-place is seen as some kind of flaw

You're conflating two separate concepts:

1. Git's default of commingled repo and and working/checkout directory

2. Switch-in-place workflow encouraged by #1

Fossil doesn't do #1, but that doesn't prevent switch-in-place or even discourage it. The hard separation of repo and checkout in Fossil merely encourages multiple separate long-lived checkouts.

A common example is having one checkout directory for the active development branch (e.g. "trunk" or "master") and one for the latest stable release version of the software. A customer calls while you're working on new features, and their problem doesn't replicate with the development version, so you switch to the release checkout to reproduce the problem they're having against the latest stable code. When the call ends, you "cd -" to get back to work on the development branch, having confirmed that the fix is already done and will appear in the next release.

Another example is having one checkout for a feature development branch you're working on solo and one for the team's main development branch. You start work from the team's working branch, realize you need a feature branch to avoid disturbing the rest of the team, so you check your initial work in on that branch, open a checkout of that new branch in a separate directory and continue work there so you can switch back to the team's working branch with a quick cd if something comes up. Another team member might send you a message about a change needed on the main working branch that you're best suited to handle: you don't want to disturb your personal feature branch with the work by switching that checkout in place to the other branch, so you cd over to the team branch checkout, do the work there, cd back, and probably merge the fix up into your feature branch so you can work with the fix in place there, too.

These are just two common reasons why it can be useful to have multiple long-lived checkouts which you switch among with "cd" rather than invalidate build artifacts multiple times in a workday when switching versions.

Git can give you multiple long-lived working checkouts via git-worktree, but according to the Internets it has several well-known problems. Not being a daily Git user, I'm not able to tell you whether this is still true, just that it apparently has been true up to some point in the past.

Since no one is telling me those issues with git-worktree are all now fixed, it remains a valid point of comparison in the fossil-v-git article.

Re: Is Git Irreplaceable? (2019)

#525

Post by balfirevic »

wyoung2 wrote: post #524
balfirevic wrote: post #511

Earlier quoted context omitted.

> Fossil is made to work that way from the start, so you can't run into these problems with Fossil. You'd have to go out of your way to use Fossil in the default Git style, such as by cloning into ~/ckout/.fossil and opening that repo in place. That's unfortunate. Reading the comments here, switch-branch-in-place is seen as some kind of flaw, but I don't think I would voluntarily use a VCS that doesn't let me easily…

> switch-branch-in-place is seen as some kind of flaw You're conflating two separate concepts: 1. Git's default of commingled repo and and working/checkout directory 2. Switch-in-place workflow encouraged by #1 Fossil doesn't do #1, but that doesn't prevent switch-in-place or even discourage it. The hard separation of repo and checkout in Fossil merely encourages multiple separate long-lived checkouts. A common examp…

If what you're trying to tell me is that I can use switch-in-place workflow in Fossil as easily as in Git then that's cool. Thumbs up!

Edit: It could be worth it to emphasize this in the Fossil vs. Git comparison that you linked, as it wasn't very clear to me after reading it.

Re: Is Git Irreplaceable? (2019)

#526

Post by wyoung2 »

balfirevic wrote: post #525
wyoung2 wrote: post #524

Earlier quoted context omitted.

> switch-branch-in-place is seen as some kind of flaw You're conflating two separate concepts: 1. Git's default of commingled repo and and working/checkout directory 2. Switch-in-place workflow encouraged by #1 Fossil doesn't do #1, but that doesn't prevent switch-in-place or even discourage it. The hard separation of repo and checkout in Fossil merely encourages multiple separate long-lived checkouts. A common examp…

If what you're trying to tell me is that I can use switch-in-place workflow in Fossil as easily as in Git then that's cool. Thumbs up! Edit: It could be worth it to emphasize this in the Fossil vs. Git comparison that you linked, as it wasn't very clear to me after reading it.

It's updated now, here: https://www.fossil-scm.org/fossil/doc/trunk/www/fossil-v-git...

Thanks for the feedback!

Re: Is Git Irreplaceable? (2019)

#527

Post by wyoung2 »

u801e wrote: post #484
munmaek wrote: post #387

Earlier quoted context omitted.

With the amount of information available, there is no excuse: * https://rogerdudler.github.io/git-guide/ * https://git-scm.com/book/en/v2 Also see stackoverflow. Git is a complex tool because it’s tackling a complex problem. I don’t see a way of making it “easier” without massively reducing what it can do. It’s like saying we should reduce a formula one car so people can use it without reading up on it, etc. If somet…

> It’s like saying we should reduce a formula one car so people can use it without reading up on it, etc A far better analogy is: It's like saying we should reduce a programming language so people can use it without reading up on it, etc.

Sorry, but this is a terrible analogy.

The core problem with it is that very few people can get paid more by being better at using their [D]VCS, whereas those more skilled with their programming language(s) of choice often do get paid more to wield that knowledge.

Consequently, most people do not fully master their version control system to the same level that they do with their programming language, their text editor, etc.

To be specific, there are many more C++ wizards and Vim wizards than there are Git wizards.

In situations like this, I prefer a tool that lets me pick it up quickly, use it easily, and then put it back down again without having to think too much about it.

You see this pattern over and over in software. It is why all OSes now have some sort of Control Panel / Settings app, even if all it does is call down to some low-level tool that modifies a registry setting, XML file, or whatever, which you could edit by hand if you wanted to. These tools exist even for geeky OSes like Linux because driving the OS is usually not the end user's goal, it is to do something productive atop that OS.

[D]VCSes are at this same level of infrastructure: something to use and then get past ASAP, so you can go be productive.

Re: Is Git Irreplaceable? (2019)

#528

Post by wyoung2 »

bhaak wrote: post #313
philbarr wrote: post #305

Earlier quoted context omitted.

But you can go back and change a commit message with ammend? Or are you wanting to change other people's? https://www.atlassian.com/git/tutorials/rewriting-history#gi...

Look at the URL: "rewriting-history" Ammending changes the hash of the commit. That doesn't matter if you haven't pushed it yet but if you have, you can't push the change upstream without force-pushing. And if I want to change a commit message further back in history (regardless of my own or of somebody else), it would branch off at that point from the upstream git history. What I want is that you could put multiple…

> Ammending changes the hash of the commit

Not necessarily. Fossil's `amend` command works by adding additional information to the repo that the web UI and commands like `fossil info` look at when building up information intended for direct consumption by the user.

In this way, you can edit commit messages, rename branches/tags, add/remove tags, etc. to historical check-ins without breaking the blockchain / Merkle tree of commits.

This allows Fossil to keep all of the historical information about what happened to a given file, commit, ticket, etc. while still allowing a coherent presentation of the current state of affairs to the user.

Re: Is Git Irreplaceable? (2019)

#529

Post by wyoung2 »

jerf wrote: post #455
dev_north_east wrote: post #440

Earlier quoted context omitted.

Just reading up on it now. Seems interesting, might give it a shot next time.

In the case you mentioned of "just a few commits" it's of marginal utility, because you can do that manually almost as quickly, but it's a killer when it comes to "I don't really know when we introduced this" and you have to sift over thousands of commits. Unfortunately, it requires that you have the discipline to keep every commit on the relevant branches buildable (enough so to find the bugs), which is something yo…

Agreed. Bisecting a deep and complex version history can be a lifesaver, especially under a time crunch.

Fossil has bisecting with much the same CLI as Git, for what that's worth.

Re: Is Git Irreplaceable? (2019)

#530

Post by wtetzner »

xorcist wrote: post #308
rumanator wrote: post #196

Earlier quoted context omitted.

Git does far more than making it easy to fork: it makes it trivial and inexpensive. Meanwhile SVN supports forking in the sense that it supports copying directories.

The "fork" concept is not native to neither Subversion nor git. You are probably thinking of branches and tags, and those are used similarly in both systems. They are a bit more convenient in git since they are created in constant as opposed to linear time. Copies in Subversion are only metadata. Since partial clones are native to the system, it is simple to present both branches and tags as file paths. It was likely…

> They are a bit more convenient in git since they are created in constant as opposed to linear time.

I would argue that branches are nicer in git because it makes merging so much easier.

Post reply on HN