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

291–300 of 454 posts

Re: Why SQLite does not use Git (2018)

#291

Post by [deleted] »

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

[deleted]

Re: Why SQLite does not use Git (2018)

#292

Post by Sterm »

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…

[flagged]

Re: Why SQLite does not use Git (2018)

#293

Post by booleandilemma »

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

Would their git provide file system access?

Re: Why SQLite does not use Git (2018)

#294

Post by masklinn »

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

Eh. Apple’s cli utilities are hot garbage, and with some of the poorest documentation you can find when they’re at all documented.

As bad as git is, and god knows it’s bad, launchctl is in an other galaxy of unusability.

Re: Why SQLite does not use Git (2018)

#295

Post by medstrom »

mattbillenstein wrote: post #288
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…

Point could be made people don't really use git anymore - they use github as the primary interface. Branching, merging, review, etc.

How many people know GitHub can do that? Your comment was the first I'd heard about it.

Re: Why SQLite does not use Git (2018)

#296

Post by lloeki »

eru wrote: post #265
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 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 consisting of all leaves down from shaY

This is achievable with git but it's not just doing n rebases like so:

    git rebase --onto shaX shaY shaZ1
    git rebase --onto shaX shaY shaZ2
    git rebase --onto shaX shaY shaZ3
    ...
because each rebase would produce different commits for parts that are common to shaZ n1 and shaZn2 ancestry, so one would have to first find all the branching points and do partial rebases onto the rebased parent commits in order.

It definitely can be done (manually or automatically) but is not as trivial as one might think.

Re: Why SQLite does not use Git (2018)

#297

Post by eru »

seba_dos1 wrote: post #279
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…

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.

In general, it's almost always better to use long options. So that would be `git rebase --rebase-merges` in this case.

Almost always means: it's better eg when communicating with other humans, whether that's on a forum like HN or in code or scripts. Long options are easier for humans to understand and to 'google'. They also provide some redundancy against typos.

The sole exception, where short options can be useful, is when you are actually using a command line interactively. Use short options to your heart's content there.

Re: Why SQLite does not use Git (2018)

#298

Post by eru »

bombcar wrote: post #287
eru wrote: post #257

Earlier quoted context omitted.

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'.

Many of those variations of ethernet remain compatible, 10g switches can often negotiate down to 10/100.

Yes. And the replacement to git might also stay compatible.

(In an extreme case, git can talk svn via git-svn. In a weird alternative history, you could imagine git being treated as a new version of svn; but apart from the names, nothing much else would change compared to our universe.)

Re: Why SQLite does not use Git (2018)

#299

Post by Mizoguchi »

Spent many years on Subversion and Mercurial before moving to Git.

I agree that it may be complex if you don't take the time to understand the fundamentals.

I made the mistake to jump right at it on a very large project thinking my experience with other non distributed systems would be enough.

So I had to take a step back and dedicate some time to read documentation including visual examples of the most common situations I encounter.

Merging and resolving conflicts are those of two situations where I struggled the most particularly when working with sub branches in large projects (5+ developers) with a very fast pace of development.

Once you understand the fundamentals (you can confidently draw on paper the current and future state of the tree after your changes) Git is not difficult IMO and 99% of the time you can work with a dozen of commands if you have discipline to use standards and do frequent housekeeping.

If you let changes and branches go for two long without committing, merging and deleting them, never tag and release, write poor commit messages and don't reference issue numbers, lack naming conventions, submit dirty PRs and let PRs sit for days and weeks before approval, etc, then the problem isn't Git.

Re: Why SQLite does not use Git (2018)

#300

Post by astrobe_ »

lolive wrote: post #220
_Algernon_ wrote: post #214

Earlier quoted context omitted.

Git BASH (from that page) is what they referred to when they said "you literally have to bring half of a whole unix with you to run git".

GitBash, AutoHotkey, Notepad++, 7zip and PowerToys are the basic installs I do on any Windows I am given. Any dev opening a CMD is suspect, to me.

CLI and GUI are different languages that are optimal for different use-cases. A dev who doesn't understand that and refuses to use CLI where appropriate is like a dev who would refuse to learn English. They are crawling when others can run.
Post reply on HN