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

Why SQLite does not use Git (2018)

sqlite.org

Post reply on HN
Print view View original

301–310 of 454 posts

Re: Why SQLite does not use Git (2018)

#301

Post by eru »

lloeki wrote: post #296
eru wrote: post #265

Earlier quoted context omitted.

> I also wonder, how much better git could be if it was based on DAGs not trees [...] Git generally supports DAGs. > [...] corollarily I‘d like to rebase subtrees (sub-DAGs) instead of single branches. Rebasing is something you do to the commit graph, which is a DAG. Branches only come in incidentally. Branches in git are really just mutable pointer to immutable commits. What you are describing is probably some usefu…

I seem to understand GP wants to move a whole DAG potentially having multiple leaves, not just a DAG ending at a single leaf. IOW git rebase --onto shaX shaY shaZ ends at shaZ, git walks backwards from it until the commit whose parent is shaY to produce the list of commits to cherry-pick onto shaX So presumably this would be useful: git rebase --onto shaX shaY [shaZ1 shaZ2 shaZ3 ...] with shaZn being optional and con…

OK, that makes sense.

I think if you wanted to do this, it would probably be easiest to produce an artificial leaf that points to all the leaves you want to rebase.

Re: Why SQLite does not use Git (2018)

#302

Post by tempay »

seba_dos1 wrote: post #282
Zacharias030 wrote: post #253

Earlier quoted context omitted.

Generally git‘s support for a stacked PR workflow is poor [0], but imho that is the future of team collab (git is great for very asynchronously built projects, like the linux kernel). I also wonder, how much better git could be if it was based on DAGs not trees (I may want to use a changeset that is still developing in more than one branch without maintaining copies of it) and corollarily I‘d like to rebase subtrees…

> (I may want to use a changeset that is still developing in more than one branch without maintaining copies of it) Not sure if you realize, but a commit is a state of all files in the repository, not a patch. Patches are calculated for you at display time (and can be calculated against any other commit, not just a parent). Sounds like you may be confused because of trying to apply a wrong mental model of how the rep…

> I'd say that git actually supports stacked workflows quite well. It's GitHub's PR model that makes it hard.

I agree that the model does but I’m not aware of any good way of using such a workflow with the CLI either. Is there a reasonable way to effectively keep rebasing on top of multiple upstream branches?

Re: Why SQLite does not use Git (2018)

#303

Post by GabrielTFS »

bonzini wrote: post #252
anon35 wrote: post #210

Made a list of all the revision control tools I've used over the decades, the year they were created, and the year I last used them: sccs 1973 2000 rcs 1982 2000 cvs 1990 2004 clearcase 1992 2004 perforce 1995 2011 subversion 2000 2015 mercurial 2005 2015 git 2005 present So, at least for me, they last around 15 years or so. But often time when I tell juinors that when they're my age, git will be distant a strange me…

Subversion is basically CVS done right. The problem is that CVS was a dead end that didn't scale to a distributed development model. Git goes back to the local RCS model and adds atomic commits to that model. That's how it climbed out of the local optimum that was Subversion. There were a couple controversial choices that Git made, for example not tracking renames and not having linear revision numbers, but they turn…

> I know no one who is using git switch and git restore instead of the overloaded and confusing git checkout.

Welp, I guess there's me, but it does indeed seem like adoption of the new commands hasn't been very forthcoming - I guess that's what happens when "the old way still works just fine" - but personally I'd expect that more and more people will change to the new commands over time.

Re: Why SQLite does not use Git (2018)

#304

Post by Git-Master »

cryptonector wrote: post #163
NBJack wrote: post #7

I think there are some legitimate criticisms of Git here. But some of them are...odd. Despite using Git in a variety of circumstances, from a local personal repo project to very large company repos, I admit I haven't run into about half of these issues. > The closest I have found is the network, which is slow to render (unless it is already cached), does not offer nearly as much details, and scarcely works at all on…

> > The closest I have found is the network, which is slow to render (unless it is already cached), does not offer nearly as much details, and scarcely works at all on mobile. (The preceding text in TFA makes it clear that this refers to rendering a view of history. This is in a section titled "Git does not provide good situational awareness".) Here's the thing: if you use a rebase workflow then all history will be l…

> At Sun we had a strict linear history mandate

Out of curiosity: Was this also with TeamWare/SCCS?

> If you care about history, what you really want is to see what's changed over time, and that is always linear. At time t_n you have some commit, and at t_n+1 you have some other commit, and so on.

Depends on what the history should represent or what you care about specifically, or optimize for.

What landed in the integration branch or was deployed to a singular test environment is certainly linearily ordered on the time scale. What happened during parallel development is rather a DAG. (And even there you could have different working models: clean up (e.g. with git rebase), then integrate; or keep every commit ever made (even if hidden in presentation), fossil-style.)

This has all pros and cons and most of us have their preferences, or even reasons. It should be consistent per project and supported by the tooling.

> Besides, if you have N commits in a branch and you merge it into another, when you resolve conflicts you won't know which conflicts and resolutions go with which of those N commits, and you won't care, but if you want to understand your work -and also others to understand your work- it seems much better to rebase and resolve conflicts commit by commit.

However, with rebasing on top (or squash-merges) you lose the commits in their original context. You may have no merge-commits, but all your commits are merged commits. (They only have one parent in version history, but the file content is the result of a merge, be it automatic or manual.) This may no big deal for things you can and do test for. If finding out a bug later however, it is often easier to comprehend, if one can see or test, if that happened only while integrating the changes. Then you have at least still the working version from the tip of the branch available for comparison.

One could also have a merge for each of the commits (in order), but that does not help with a keeping the history lean.

While I do use git rebase to clean up, I do merge branches afterwards and keep the commits. I usually do my rebases with --keep-base (unless they have been started at a totally wrong branch point) and therefore no integration work with other branches will be done here. That will happen in the merge, to be able to distinguish between what was developed and what was the result if the integration.

Re: Why SQLite does not use Git (2018)

#305

Post by eitland »

tester756 wrote: post #278
Guvante wrote: post #185

I think git gets a bad rep because no one can agree how to use it. GitHub PRs vs pushing a branch, rebase vs merge are just two examples of tools that do identical things in fundamentally different ways. And the problem is none of them are wrong. Rebasing minor commits simplifies unnecessary complexity in your history. Merging preserves what actually happened which can provide insight into why changes occurred. Of co…

git gets bad rep because its cli is a terrible mess if apple designed git's cli it'd be bilion times better from ux perspective while only 10% less powerful I guess

> if apple designed git's cli it'd be bilion times better from ux perspective while only 10% less powerful I guess

Why then does every dev I am aware of who use Apple start by installing Homebrew?

Also, you are talking about the same Apple that has a menu system that closes the menu if you click at a submenu?

I mean, it breaks at least two reasonable assumptions:

- clicking on a branch node would work on the branch like clicking on a leaf node affects the leaf

- clicking the menu works like everywhere else

Or the same Apple UX where, if I opened a dialog in my browser I cannot use the same browser to look up in the wiki where on the file server I am supposed to find a certain file I am supposed to upload?

Or the same Apple UX where there is a different shortcut depending on whether I want to switch between windows of the same app or windows from different apps?

The same Apple UX where I had to learn from application to application which features were in the menu and which were hidden under one or another gear icon?

That said, I am considering another for my next laptop.

But their UX is well and truly overrated IMNSHO.

Re: Why SQLite does not use Git (2018)

#306

Post by sbochins »

anon35 wrote: post #210

Made a list of all the revision control tools I've used over the decades, the year they were created, and the year I last used them: sccs 1973 2000 rcs 1982 2000 cvs 1990 2004 clearcase 1992 2004 perforce 1995 2011 subversion 2000 2015 mercurial 2005 2015 git 2005 present So, at least for me, they last around 15 years or so. But often time when I tell juinors that when they're my age, git will be distant a strange me…

I don’t know what we’ll be using 15 years from now. But the thing that is really sad in your list is that you stopped using mercurial in 2015, but still use git to this day.

Re: Why SQLite does not use Git (2018)

#307

Post by erik_seaberg »

bonzini wrote: post #252
anon35 wrote: post #210

Made a list of all the revision control tools I've used over the decades, the year they were created, and the year I last used them: sccs 1973 2000 rcs 1982 2000 cvs 1990 2004 clearcase 1992 2004 perforce 1995 2011 subversion 2000 2015 mercurial 2005 2015 git 2005 present So, at least for me, they last around 15 years or so. But often time when I tell juinors that when they're my age, git will be distant a strange me…

Subversion is basically CVS done right. The problem is that CVS was a dead end that didn't scale to a distributed development model. Git goes back to the local RCS model and adds atomic commits to that model. That's how it climbed out of the local optimum that was Subversion. There were a couple controversial choices that Git made, for example not tracking renames and not having linear revision numbers, but they turn…

I for one am trying to train myself to start using switch and restore, so that I can recommend them in company channels for people having problems with our monorepo(s).

Re: Why SQLite does not use Git (2018)

#308

Post by seba_dos1 »

marcandre wrote: post #290
seba_dos1 wrote: post #279

Earlier quoted context omitted.

Not only it's useful, it's as easy to do in git as typing `git rebase -r`. Recently it even gained support for rewriting branch pointers in the process.

Do you mean it can rewrite branch pointers that pointed to intermediate commits? How?

--update-refs

Re: Why SQLite does not use Git (2018)

#309

Post by jpgvm »

Culonavirus wrote: post #249
avikalp wrote: post #128

Earlier quoted context omitted.

I tried that (primarily because I didn't know about it and was excited), but it didn't work. It needs me to install "lighttpd" to work. And the steps to install that are not straightforward. I like that a lot of functionality is not bundled up in the git that I have already installed in my computer, but at the same time, I agree with the fact that adding these separate binaries is not easy as a user.

> lighttpd Wow now that's a blast from the past. That's a nice relic from the times of people getting annoyed with Apache's one process per request model and Nginx not being popular just yet. Does anyone use that anymore for, well, anything?

Still very common in low resource environments.

Re: Why SQLite does not use Git (2018)

#310

Post by sanderjd »

eru wrote: post #257
quietbritishjim wrote: post #228

Earlier quoted context omitted.

In fairness, the rate of change of any type of tool slows down over time as the problem domain becomes well understood. It's like the Joel on Software article (which annoyingly I can't find at the moment) about how software is always pretty much done by about version 4. His example was office software, especially Excel, and sure enough if you loaded Excel 4 today you'd see it does fundamentally all the main things. I…

I think mostly it will depend on what we will call the replacement to git. We might end up calling it 'git', too. Less weirdly: ethernet has been replaced a few times already, but they always just end up branding the replacement as a new version of 'ethernet'.

I think this is a great point! What even is "git"? If it's the binary program named "git", then there are already lots of replacements for that binary that people use, and it would not be surprising at all if one of those different frontends becomes more dominant than "git" itself.

But if "git" is the protocol, the specification of how a particular construction of a database of versions, then I suspect that will be pretty sticky. I'm sure it isn't the optimal solution but it works well and it's very useful to have a lingua franca for this.

Post reply on HN