TE
TechEcho
Home24h TopNewestBestAskShowJobs
GitHubTwitter
Home

TechEcho

A tech news platform built with Next.js, providing global tech news and discussions.

GitHubTwitter

Home

HomeNewestBestAskShowJobs

Resources

HackerNews APIOriginal HackerNewsNext.js

© 2025 TechEcho. All rights reserved.

Why SQLite Does Not Use Git

508 pointsby trextrexabout 7 years ago

47 comments

jordighabout 7 years ago
&quot;Nobody really understands git&quot; is the truest part of that. While hyperbolic, it really has a lot of truth.<p>It&#x27;s always a bit frustrating when working with a team because everyone understands a different part of git and has slightly different ideas of how things should be done. I still routinely have to explain to others what a rebase is and others have to routinely explain to me what a blob really is.<p>In a team of the most moderate size, teaching and learning git from each other is a regular task.<p>People say git is simple underneath, and if you just learn its internal model, you can ignore its complex default UI. I disagree. Even just learning its internal model leads to surprises all the time, like the blobs that I keep forgetting why aren&#x27;t they just called files.
评论 #16807290 未加载
评论 #16807587 未加载
评论 #16807592 未加载
评论 #16807425 未加载
评论 #16807992 未加载
评论 #16807758 未加载
评论 #16812262 未加载
评论 #16816944 未加载
评论 #16812017 未加载
评论 #16808659 未加载
评论 #16808639 未加载
评论 #16808851 未加载
nealsabout 7 years ago
I&#x27;m a big fan of Fossil myself. But the SQlite people have something that I don&#x27;t really have within the teams I operate : the authority to dare and speak out against Git and not be laughed away like a hipster that is just trying to be different.
评论 #16806520 未加载
评论 #16806294 未加载
评论 #16806320 未加载
评论 #16807235 未加载
评论 #16807313 未加载
评论 #16811963 未加载
评论 #16807729 未加载
avarabout 7 years ago
I haven&#x27;t used Fossil, but just a comment on some of that page, in the order they&#x27;re presented:<p>1. It&#x27;s unclear to me what he means. Yes git doesn&#x27;t store anything like a doubly linked list of commits, and thus finding the &quot;next&quot; commit is more expensive, but you can do this with &#x27;git log --reverse &lt;commit&gt;..&#x27;, and it&#x27;s really snappy on sqlite.git.<p>It&#x27;s much slower on larger repositories, but git could relatively easily grow the ability to maintain such a reverse index on the side to speed this up.<p>2. Yeah a lot of the index etc. is complex, but I wonder how something like &quot;git add -p&quot; works in Fossil. I assume not at all. Is there a way to incrementally &quot;stage&quot; merge conflicts? Much of that complexity comes with significant advantages.<p>3. This is complaining about two unrelated things. One is that GitHub by default isn&#x27;t showing something like &#x27;git log --graph&#x27; output, the other is that he&#x27;s assuming that git treats the &quot;master&quot; branch magically.<p>Yeah GitHub and other viewers could grow some ability to special-case the main branch and say &quot;..and this was merged into &#x27;master&#x27;&quot; at the top of that page, but in any case all the same info exists in git as well, so it&#x27;s just a complaint about a specific web UI.
评论 #16806869 未加载
评论 #16807408 未加载
评论 #16806524 未加载
评论 #16808814 未加载
评论 #16811784 未加载
Animatsabout 7 years ago
Some time back, some GUI design firm asked on HN for a suggested open source program that needed a GUI developed. They had some developer time free and wanted something that would get them visibility. I suggested they do a GUI for Git. Several such things exists, but they&#x27;re just buttons hooked up to the command line; they have no useful visual outputs. A good GUI for Git, where you could look at branches and such graphically, would get attention.<p>Too hard, they said. They wanted something which just needed to be pretty, not something with tough human interface problems.
评论 #16806499 未加载
评论 #16806409 未加载
评论 #16806463 未加载
评论 #16806417 未加载
评论 #16806592 未加载
评论 #16806564 未加载
评论 #16806565 未加载
评论 #16807092 未加载
评论 #16806709 未加载
评论 #16806669 未加载
评论 #16806431 未加载
评论 #16806737 未加载
评论 #16806914 未加载
monocasaabout 7 years ago
It&#x27;s funny that they don&#x27;t list the real reason, which is that Fossil is built on top of SQLite and they want to dogfood it.
评论 #16807172 未加载
评论 #16806296 未加载
评论 #16806351 未加载
评论 #16806292 未加载
wiremineabout 7 years ago
Good list, but I feel like they bury the lede: integrated wiki, issues, and notes. That doesn&#x27;t scale to every project (linux kernel for example), but for a lot of projects it&#x27;s really cool.<p>Other selling points from the Fossil site:<p>* Integrated Bug Tracking, Wiki, and Technotes<p>* Built-in Web Interface _and_ Self-Contained (I combined these)<p>* Simple Networking (no git:&#x2F;&#x2F;, just HTTP and SSH)<p>* CGI&#x2F;SCGI Enabled<p>* Autosync - &quot;Fossil supports &quot;autosync&quot; mode which helps to keep projects moving forward by reducing the amount of needless forking and merging often associated with distributed projects.&quot;<p>* Robust &amp; Reliable - &quot;Fossil stores content using an enduring file format in an SQLite database so that transactions are atomic even if interrupted by a power loss or system crash. Automatic self-checks verify that all aspects of the repository are consistent prior to each commit.&quot;<p>It would be easy to get into comparing git and Fossil feature by feature. That&#x27;s interesting. But it&#x27;s more interesting to compare the philosophies between the two tools.<p>edit: for grammer.
评论 #16806697 未加载
评论 #16806359 未加载
评论 #16806310 未加载
评论 #16806328 未加载
plastroltechabout 7 years ago
Interesting and possibly relevant to note that SQLite is not your typical opensource project:<p>&quot;Open-Source, not Open-Contribution: SQLite is open-source, meaning that you can make as many copies of it as you want and do whatever you want with those copies, without limitation. But SQLite is not open-contribution. The project does not accept patches. Only 27 individuals have ever contributed any code to SQLite, and of those only 16 still have traces in the latest release. Only 3 developers have contributed non-comment changes within the previous five years and 96.4% of the latest release code was written by just two people. (The statistics in this paragraph were gathered on 2018-02-05.)&quot;<p><a href="https:&#x2F;&#x2F;www.sqlite.org&#x2F;copyright.html" rel="nofollow">https:&#x2F;&#x2F;www.sqlite.org&#x2F;copyright.html</a>
评论 #16807722 未加载
gregoriolabout 7 years ago
The argument that &quot;Git lacks native wiki and bug tracking&quot; is actually a very good thing: each of those 3 things (scm, wiki, bug tracking) are very different, and an scm must not bring a process&#x2F;management system with it. Obviously, often it&#x27;s nice to have all the things packaged, and GitLab does it amazingly well (maybe does too much these days though), but at a some level of process and IT management, wiki and issues have their tools already and should not depend on the scm.
评论 #16806762 未加载
vangarabout 7 years ago
&quot;The mental model for Git is needlessly complex and consequently distracts attention from software under development. A user of Git needs to keep all of the following in mind:<p><pre><code> The working directory The &quot;index&quot; or staging area The local head The local copy of the remote head The actual remote head </code></pre> Git contains commands (or options on commands) for moving and comparing content between all of these locations.<p>In contrast, Fossil users only need to think about their working directory and the check-in they are working on. That is 60% less distraction.&quot;<p>I don&#x27;t think about any of this when developing. I check out a branch, work on it, commit to it, and push it back up. If the fix is larger than a few commits i&#x27;ll make a feature branch. What&#x27;s so hard about that?<p>Also, everyone using git isn&#x27;t a bad thing. It means we finally have at least one standard in development.
评论 #16806349 未加载
评论 #16806350 未加载
评论 #16806291 未加载
评论 #16813472 未加载
评论 #16807778 未加载
truantbuickabout 7 years ago
First time I&#x27;ve heard of Fossil and started reading up on it: <a href="https:&#x2F;&#x2F;www.fossil-scm.org&#x2F;xfer&#x2F;doc&#x2F;trunk&#x2F;www&#x2F;fossil-v-git.wiki" rel="nofollow">https:&#x2F;&#x2F;www.fossil-scm.org&#x2F;xfer&#x2F;doc&#x2F;trunk&#x2F;www&#x2F;fossil-v-git.w...</a><p>In particular, I&#x27;m interested in the last section &quot;4.2 Features found in Git but missing from Fossil&quot;.<p>Maybe this is some deficiency of my workflow, but both those things make Fossil sound extremely unappealing to me. You&#x27;re telling me I have to push all local changes every time I want to push anything? What if I was just debugging or experimenting with one branch, and then I had to switch to a &quot;serious&quot; branch to push some critical changes?<p>And rebasing is fantastic when you have a feature branch workflow.
评论 #16806955 未加载
评论 #16859968 未加载
occams_chainsawabout 7 years ago
<p><pre><code> Git does not track branch history. This makes review of historical branches tedious. </code></pre> This isn&#x27;t true. It&#x27;s just the Fossil example has a better UI than their github example. Pop open gitk or anything with a nicer UI and you can easily follow branch history.
评论 #16806485 未加载
epageabout 7 years ago
Under (1)<p>&gt; The principle maintainer of SQLite cannot function effectively without being able to view the successors of a check-in.<p>I wish it went into more detail about why this is critical to his workflow.
评论 #16806584 未加载
评论 #16807717 未加载
nineteen999about 7 years ago
I really like git these days, and I was initially stubborn, having grown up in the age of first cvs then svn. I design&#x2F;implement core infrastructure and services for a large emergency services project. By nature the team that design and build it is especially conservative. It&#x27;s only this past year I&#x27;ve been able to convince management that we should move to git because it offers advantages over the traditional tool (svn).<p>What does make me chuckle however is seeing git used as a drop in replacement for svn without using any of the advanced branching&#x2F;merging features it offers. I find it funny to hear a devops youngster eschewing the benefits of git after hearing that &lt;n&gt; hip opensource projects use it, just to find that they use using it with a single tree (or bunch thereof), just continually committing everything to the master branch.<p>Just like people used to use cvs and svn.
deedubayaabout 7 years ago
I don&#x27;t know anything about Fossil, but saying that no one understands Git just makes me think they&#x27;re ignorant to learning Git. I doubt that&#x27;s the case, but still, why say that?
评论 #16806512 未加载
评论 #16806289 未加载
评论 #16806287 未加载
评论 #16806301 未加载
评论 #16807043 未加载
评论 #16806323 未加载
lifeisstillgoodabout 7 years ago
&gt;&gt;&gt; The principle maintainer of SQLite cannot function effectively without being able to view the successors of a check-in. This one issue is sufficient reason to not use Git, in the view of the designer of SQLite<p>Ok I&#x27;ll bite. Why?<p>I can see it&#x27;s a nice idea - but at some point you add function X, then ten check ins modify that function. what&#x27;s the difference between looking back at ten and looking forward at ten?<p>Perhaps I need an example.<p>If I remember rightly fossil was written by the Sqllite people? I tried it out for a while back in the day - I think it had this store the tickets in the branch alongside the code - it was an appealing idea, but got complicated quickly.
评论 #16806391 未加载
donutabout 7 years ago
&gt; Git encourages a style in which individual developers work in relative isolation, maintaining their own branches and occasionally rebasing and pushing selected changes up to the main repository.<p>&gt; Fossil, in contrast, strives to keep all changes from all contributors mirrored in the main repository (in separate branches) at all times.<p>From <a href="https:&#x2F;&#x2F;www.fossil-scm.org&#x2F;index.html&#x2F;doc&#x2F;trunk&#x2F;www&#x2F;fossil-v-git.wiki" rel="nofollow">https:&#x2F;&#x2F;www.fossil-scm.org&#x2F;index.html&#x2F;doc&#x2F;trunk&#x2F;www&#x2F;fossil-v...</a>
cyberferretabout 7 years ago
Sounds similar to my experiences with Bazaar many years ago. Ended up converting all project over to Git once we realised that nearly all external developers we worked with preferred Git and didn&#x27;t have a clue about Bzr.<p>Semi interesting full circle side note: One of those projects was actually a rudimentary version control system for a report writing app, which used SQLite as the VC data store.
评论 #16807018 未加载
评论 #16806627 未加载
alkonautabout 7 years ago
Git is absolutely terrible. Let’s just get that out of the way.<p>But it ticks the two boxes<p>- powerful enough (to e.g do proper merging, which cvs and svn never could)<p>- tooling support, meaning it’s supported out of the box in bug trackers, build systems etc.<p>All others (hg, perforce, svn, cvs, pijul, fossil, ...) fail one or both of the above.<p>Now, I <i>hope</i> that one day git will be replaced by something nicer. But for the time being it’s what we’re stuck with.<p>My pet peeve: sequential revision numbers. Why not have an arbitrary numbering of commits?? Saying “I have bug X in rev 1234 but it’s not in 1230” is fantastically powerful compared to “I have the bug in a1b34h but not in 3ae452”. These would be a sequence for a particular centralized branch - typically mainserver&#x2F;master.<p>Because this is the reality: it’s distributed version control but we almost all use centralized version control. This is also why it’s so odd that Git LFS took years to make it into git. Why would I want all past revisions of a binary (Yes, binaries must often be in version control, whether anyone thinks it’s a bad idea or not)?
评论 #16808515 未加载
Bromsklossabout 7 years ago
&gt; Git lacks native wiki and bug tracking. If you want these essential features, you have to install additional software such as GitLab, or else use a third-party service such as GitHub. And even then, the wiki and bug reports are centralized, not distributed.<p>Is a distributed bug reports etc even desirable? How would they work?
locusmabout 7 years ago
Anyone moved to BitKeeper now that its open source? <a href="http:&#x2F;&#x2F;www.bitkeeper.org" rel="nofollow">http:&#x2F;&#x2F;www.bitkeeper.org</a>
评论 #16808295 未加载
civilianabout 7 years ago
&gt; <i>In contrast, Fossil users only need to think about their working directory and the check-in they are working on. That is 60% less distraction. Every developer has a finite number of brain-cycles. Fossil requires fewer brain-cycles to operate, thus freeing up intellectual resources to focus on the software under development.</i><p>Not thinking about the actual remote head and&#x2F;or the local copy of the remote head seems bad? I&#x27;m worried that Fossil is just obscure information, rather than presenting it.<p>Is it possible to `fossil rebase origin&#x2F;master` without an internet connection?<p>&#x2F;&#x2F; edit:<p>Reading more of the docs, what I quoted at the top is definitely, ah, misleading.<p>&gt; <i>When autosync is turned off, the changes you commit are only on your local repository. To share those changes with other repositories, do: fossil push URL</i><p>&gt; <i>When you pull in changes from others, they go into your repository, not into your checked-out local tree. To get the changes into your local tree, use update:</i><p><a href="https:&#x2F;&#x2F;fossil-scm.org&#x2F;index.html&#x2F;doc&#x2F;trunk&#x2F;www&#x2F;quickstart.wiki" rel="nofollow">https:&#x2F;&#x2F;fossil-scm.org&#x2F;index.html&#x2F;doc&#x2F;trunk&#x2F;www&#x2F;quickstart.w...</a><p>We have confirmed that Fossil has<p><pre><code> The working directory The &quot;index&quot; or staging area The local head The local copy of the remote head The actual remote head </code></pre> So yeah, point #2 in the OP is lies.
maltalexabout 7 years ago
&gt; Fossil stores content using an enduring file format in an SQLite database so that transactions are atomic even if interrupted by a power loss or system crash.<p>Looks like the love is mutual
评论 #16806474 未加载
igammaraysabout 7 years ago
Git is needlessly complex. Absolutely. The solution we&#x27;ve stumbled upon is to use a good GUI (GitKraken). Every developer I&#x27;ve introduced it to was at first intensely skeptical &quot;I always use the command line and it&#x27;s fine&quot;, but their mind was blown once they actually started using the GUI. Our whole team got a significant boost in productivity once we enforced the use of GitKraken, and now I fire it up even for the simplest of commands.
评论 #16811652 未加载
评论 #16808618 未加载
jonahbabout 7 years ago
Fossil vs. Git (2011): <a href="https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=2524422" rel="nofollow">https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=2524422</a>
smarnachabout 7 years ago
The list of reasons not to use Git seems as smug as it is uninformed.<p>&gt; With Git, it is very difficult to find the successors (decendents) of a check-in.<p>&quot;git log --children&quot; and &quot;git log --reverse&quot; are very difficult indeed.<p>&gt; Fossil users only need to think about their working directory and the check-in they are working on. That is 60% less distraction.<p>Since Fossil is a distributed version control system, there is also remote state to keep in mind. I don&#x27;t know Fossil, so I don&#x27;t know the details, but simply pretending the remote state does not exist seems at least misleading.<p>&gt; Setting up a website for a project to use Git requires a lot more software, and a lot more work, than setting up a similar site with an integrated package like Fossil.<p>Setting up GitLab with Omnibus takes about five minutes. It&#x27;s not Git itself, but rather a third-party package, but why should I care? (And in general, I wouldn&#x27;t set up anything at all – I&#x27;d just use GitHub or GitLab or Bitbucket for my open-source software.)<p>It&#x27;s fine for different people to prefer different tools. Git can be annoying at times. However, it&#x27;s a blessing that the open-source community is moving towards a standard everyone can work with, and Git is Good Enough to be that standard. Using an obscure alternative and justifying it with a list of downright wrong claims doesn&#x27;t seem to create a welcoming atmosphere for new contributors.<p>(And don&#x27;t get me wrong – SQLite is a great piece of software, and I&#x27;m thankful people put in their time to create it.)
评论 #16810621 未加载
disordinaryabout 7 years ago
I&#x27;m sick of being the go to person in my team to fix their git rebase problems.
lclarkmichalekabout 7 years ago
2, 4, 5, and 6 seem pretty weak. Not a particularly interesting article. Mostly comes down to &#x27;we like X and Y about Fossil, and it works for us, so we use it instead&#x27;.
评论 #16806277 未加载
评论 #16806266 未加载
8ig8about 7 years ago
Similar discussion from almost 8 years ago...<p><a href="https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=1433387" rel="nofollow">https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=1433387</a>
FrozenVoidabout 7 years ago
The only version management that i find intuitive is wiki model(i.e. wiki articles). Imagine 3 tasks.<p>1.Revert 3 git commits. This is one-click revert in wiki.<p>2.Diff 2 arbitrary commits. One-click in wiki.<p>3.change 2 lines of code. Edit-&gt;Submit in wiki.<p>Why git has to be so arcane, especially reverting to specific point in time? The first code versioning control system that emulates the wikipedia UI model will win the market.
Myrmornisabout 7 years ago
&gt; The principle maintainer of SQLite cannot function effectively without being able to view the successors of a check-in. This one issue is sufficient reason to not use Git, in the view of the designer of SQLite.<p>He&#x27;s basically looking for<p>git branch --contains $commit_or_branch<p>isn&#x27;t he?<p>I do think it&#x27;s a thoughtful write-up, hopefully git maintainers and github read it.
deostrollabout 7 years ago
Found the following line from the article... &quot;entertaining&quot;<p># begin quote<p>Every developer has a finite number of &quot;brain-cycles&quot;. Fossil requires &quot;fewer brain-cycles to operate&quot;, thus &quot;freeing up intellectual resources&quot; to focus on the software under development.<p># end quote
ccostesabout 7 years ago
Interesting, I hadn&#x27;t heard of Fossil before.<p>It is useful to have a &#x27;lingua franca&#x27; of open-source version control, but I&#x27;m not sure git is necessarily the best choice for that (not that network-effects usually result in the &#x27;best&#x27; being chosen)
_pmf_about 7 years ago
Can someone explain how the problem of not being able to get successors causes issues in practice? I don&#x27;t doubt it does, but I&#x27;ve never personally had a situation where inspecting the graph did not give the information I required in this regard.
abqweabout 7 years ago
Also Fossil is licensed under 2-clause BSD license, Git - GNU GPL&#x2F;LGPL v2&#x2F;v2.1.
skandlabout 7 years ago
The refactored page brings up good points. Git has undeniably improved the world of software development, and is de facto the version control system to use in the majority of cases today.<p>That said, that doesn&#x27;t make the points SQLite makes invalid.
hi41about 7 years ago
Speaking truth to power! I like it! I so scared of saying that I never understood git and was getting by using only the most basic of the commands. Now Sqlite has called out!
profalseidolabout 7 years ago
I always find myself writhing a bash script to commit-and-push-all with commit comment as arg. Especially for small projects.
alkonautabout 7 years ago
These days I’m more interested in a comparison between pijul and git. Pijul actually brings real improvements over git.
nurettinabout 7 years ago
Unfortunately at work we use TFS which only offers Git and TFVS as version control systems.
nunezabout 7 years ago
I thought git reflog shows you basically everything...
ComputerGuruabout 7 years ago
Speaking of large projects that haven’t moved to git, I wonder when WordPress is finally going to make the move?
greggmanabout 7 years ago
I am not qualified to judge whether Fossil is better than git and I can completely acknowledge that git has a step learning curve (although I feel that a big chunk of that learning curve is unlearning previous VCS experience).<p>But, now that I do know git the biggest change from I noticed from previous VCSes is how much I work on multiple issues in the same repo. Something that was extremely hard with CVS, SVN, P4 (10yrs ago).<p>A friend was struggling with git recently and ranting about it. He didn&#x27;t get it and didn&#x27;t understand why anyone would use it compared to what he was used to (non DVCS). I wrote him this analogy<p>&gt; Imagine some one was working with a flat file system, no folders. They somehow have been able to get work done for years. You come along and say “You should switch to this new hierarchical file system. It has folders and allows you to organize better”. And they’re like “WTF would I need folders for? I’ve been working just fine for years with a flat file system. I just want to get shit done. I don’t want to have to learn these crazy commands like cd and mkdir and rmdir. I don’t want to have to remember what folder I’m in and make sure I run commands in the correct folder. As it is things are simple. I type “rm filename” it gets deleted. Now I type “rm foldername” and I get an error. I then have to go read a manual on how to delete folders. I find out I can type “rmdir foldername” but I still get an error the folder is not empty. It’s effing making me insane. Why I can’t just do it like I’ve always done!”. And so it is with git.<p>&gt; One analogy with git is that a flat filesystem is 1 dimensional. A hierarchical file system is 2 dimensional. A filesystem with git is 3 dimensional. You switch in the 3rd dimension by changing branches with git checkout nameofbranch. If the branch does not exist yet (you want to create a new branch) then git checkout -b nameofnewbranch.<p>&gt; Git’s branches are effectively that 3rd dimension. They set your folder (and all folders below) to the state of the stuff committed to that branch.<p>&gt; What this enables is working on 5, 10, 20 things at once. Something I rarely did with cvs, svn, p4, or hg. Sure once in awhile I’d find some convoluted workflow to allow me to work on 2 things at once. Maybe they happened to be in totally unrelated parts of the code in which case it might not be too hard of I remembered to move the changed files for the other work before check in. Maybe I’d checkout the entire project in another folder so I&#x27;d have 2 or more copies of the project in separate folders on my hard drive. Or I’d backup all the files to another folder, checkout the latest, work on feature 2, check it back in, then copy my backedup folder back to my main work folder, and sync in the new changes or some other convoluted solution.<p>&gt; In git all that goes away. Because I have git style lightweight branches it becomes trivial to work on lots of different things and switch between them instantly. It’s that feature that I’d argue is the big difference. Look at most people’s local git repos and you’ll find they have 5, 10, 20 branches. One branch to work on bug ABC, another to work on bug DEF, another to update to docs, another to implement feature XYZ, another working on a longer term feature GHI, another to refactor the renderer, another to test out an experimental idea, etc. All of these branches are local to them only and have no effect on remote repos like github (unless they want them to).<p>&gt; If you’re used to not using git style lightweight branches and working on lots of things at once let me suggest it’s because all other VCSes suck in this area. You’ve been doing it so long that way you can’t even imagine it could be different. The same way in the hypothetical example above the guy with the flat filesystem can’t imagine why he’d ever need folders and is frustrated at having to remember what the current folder is, how to delete&#x2F;rename a folder or how to move stuff between folders etc. All things he didn’t have to do with a flat system.<p>&gt; A big problem here is the word branch. Coming from cvs, svn, p4, and even hg the word &quot;branch&quot; means something heavy, something used to mark a release or a version. You probably rarely used them. I know I did. That&#x27;s not what branches are in git. Branches in git are a fundamental part of the git workflow. If you&#x27;re not using branches often you&#x27;re probably missing out on what makes git different.<p>&gt; In other words, I expect you won’t get the point of git style branches. You’ve been living happily without them not knowing what you’re missing, content that you pretty much only ever work on one thing at a time or find convoluted workarounds in those rare cases you really have to. git removes all of that by making branching the normal thing to do and just like the person that’s used to a hierarchical file system could never go back to a flat file system, the person that’s used to git style branches and working on multiple things with ease would never go back to a VCS that’s only designed to work on one thing at a time which is pretty much all other systems. But, until you really get how freeing it is to be able to make lots of branches and work on multiple things you’ll keep doing it the old way and not realize what you’re missing. Which is basically way all anyone can really say is “stick it out and when you get it you’ll get it”.<p>&gt; Note: I get that p4 has some features for working on multiple things. I also get that hg added some extensions to work more like git. For hg in particular though, while they added after the fact optional features to make it more like git go through pretty much any hg tutorial and it won&#x27;t teach you that workflow. It&#x27;s not the norm AFAICT where as in git it is the norm. That difference in base is what really set the two apart.<p>Sorry that was so long but my question for the Fossil guys would be &quot;which workflow does Fossil encourage?&quot; Lots of parallel development like git or like many other VCSes not so much parallel dev. Are branches light and easy like git or are they only meant for marking versions like the were in SVN, P4, CVS. Do branches even need to be related or can they be completely unrelated like gh-pages and the VCS won&#x27;t complain that you&#x27;re &quot;off master&quot; as hg does (did?)
AceJohnny2about 7 years ago
Paraphrasing:<p>&gt; <i>1. Git data model only lets you see ancestor commits, not descendants. Maintainer needs to find descendents.</i><p>It&#x27;s technically true about git&#x27;s data model, but it&#x27;s not too hard to reconstruct forward history based on all refs (branches for this purpose). (see &quot;git rev-list&quot;).<p>They don&#x27;t justify the use-case that demands this information be trivially available, and I&#x27;ve never personally needed it, so I find this a weak argument. I <i>have</i> needed to find what branches contained a given commit (either a regression or a bugfix), and that&#x27;s available with &quot;git branch --contains &lt;SHA&gt;&quot;<p>&gt; <i>2. The mental model of git is complex (working dir, index, local head, local copy of remote head, remote head)</i><p>Granted. It&#x27;s especially always complicated trying to explain to beginners the distinction between local head, local copy of remote head, and remote head. Though it makes sense to me when working out technical implications of git&#x27;s distributed data model, it&#x27;s obvious that many users are overwhelmed. (I think the mental model is actually great, but I won&#x27;t impose my opinion on others)<p>&gt; <i>3. Fossil&#x27;s branch history display is better than GitHub&#x27;s, and git doesn&#x27;t tell you if a branch has been merged</i><p>No mention of &quot;git log --graph&quot; (or any GUI alternative) which goes a long way of solving their complaint. I agree that GitHub&#x27;s graphless history is frustrating, but that&#x27;s a GitHub issue, not Git.<p>However, Git does &quot;swallow&quot; merged branches, as the merge commit may be a property of the receiver branch, not the original branch (depending on your development model). Git doesn&#x27;t enforce something there, so I agree with the issue.<p>&gt; <i>4. Git lacks essential wiki&#x2F;bug-tracking. If you use 3rd-party tool for these, they&#x27;re centralized</i><p>Granted, though I&#x27;m not quite convinced in how &quot;essential&quot; it is to have that tightly integrated in the version control system, and thus have it distributed, but that&#x27;s probably an artifact of me being used to existing git-based systems.<p>A counterpoint to this is that Git (now) has a healthy ecosystem of alternatives for you to choose from. If you&#x27;re not satisfied with Fossil&#x27;s offering, how easy is it to change?<p>&gt; <i>5. Git requires administrative support for the extra web tools that Fossil otherwise integrates</i><p>This follows from the previous point, so granted. I&#x27;d add to this that Git lacks a good access-control&#x2F;code-review system, hence the rise of so many alternative portals (GitHub&#x2F;Gitlab, Gerrit...)<p>&gt; <i>6. No-one really understands git [w&#x2F; XKCD link]</i><p>Now you&#x27;re just trolling.<p>Overall, I&#x27;m surprised at how many points I actually agree with the author(s), but the main difference is that git purposefully aims at a more limited feature-set that excludes project-management (ie wiki&#x2F;bugtracking), which I guess is the consequence of its Torvalds&#x2F;kernel-originated development history.
评论 #16806533 未加载
评论 #16806541 未加载
xdfilabout 7 years ago
Git is Great! But Humans should never interact with it directly. Treat Git only as an API meant for applications to interact.<p>If your team uses a common application to write their code which manages Git, it will align everyones method of use.<p>It&#x27;s funny watching an instructor training a group on Git. Everyone looks lost because there are too many scenarios being explained and how to handle them depending on what your intent might be. Before there is a solid grasp on the code management workflow the lecturing about commit comments begins, shifting clear over to the other side of the brain to guarantee none of it is collectively understood.<p>Presenting too many options to the collective is counter-productive.
kadenshepabout 7 years ago
&gt;Every day humans make me again realize that I love my dogs, and respect my dogs, more than humans. There are exceptions but they are few and far between.<p>You love them more than humans because they&#x27;re fundamentally incapable of calling you out on your fud?
评论 #16815460 未加载
评论 #16807763 未加载
crispyporkbitesabout 7 years ago
&gt; Fossil and Git are both block-chain version-control systems<p>Wow, we have gone full circle. Can’t wait for Linus to announce the git ICO!
评论 #16806275 未加载
评论 #16806265 未加载
deathanatosabout 7 years ago
&gt; <i>Given some historical check-in, it is quite challenging in Git to find out what came next. It can be done, but it is sufficiently difficult and slow that nobody ever does it.</i><p>On the command line:<p><pre><code> git for-each-ref --contains &lt;commit, branch, etc.&gt; </code></pre> Lists all refs (branches, tags) that contain the passed argument.<p>I&#x27;d be curious to know the author&#x27;s need for this. I&#x27;ve used something similar on GitHub to determine when a given commit, typically a bugfix, is released.<p>&gt; <i>There is no button in GitHub that shows the descendents of a check-in.</i><p>There is: go to the commit&#x27;s URL (<a href="https:&#x2F;&#x2F;github.com&#x2F;$ORG&#x2F;$PROJECT&#x2F;commit&#x2F;$COMMIT" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;$ORG&#x2F;$PROJECT&#x2F;commit&#x2F;$COMMIT</a>) and below the subject &amp; body of the commit, but above the author&#x2F;commit time, there&#x27;s a section that will have all branches, tags, and pull requests that the commit is a part of.<p>For example: <a href="https:&#x2F;&#x2F;github.com&#x2F;aio-libs&#x2F;aiohttp&#x2F;commit&#x2F;d7f0511ead6d05cf6b7537c1b81f825e8f181ad7" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;aio-libs&#x2F;aiohttp&#x2F;commit&#x2F;d7f0511ead6d05cf6...</a><p>That commit is part of the &quot;master&quot; branch, and the &quot;v3.1.2&quot; tag.¹<p>¹Note that more tags will likely appear in the future, if you&#x27;re reading this comment some time from when I&#x27;m writing it.