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.

What comes after Git

227 pointsby rckrdalmost 3 years ago

48 comments

silisilialmost 3 years ago
Every time I use Git, I see how bad the UX is and marvel at how it ever became popular.<p>Even a simple merge&#x2F;rebase leaves one confused. Which should I use? What is incoming? Why does incoming change as you progress? I didn&#x27;t change anything (on purpose) but Git won&#x27;t let me change branches. What the hell does stashing do? How do I just unfuck what I did and go back to a branch? These are rather common use cases, and today people still just nuke a directory because they can&#x27;t figure out the arcane arts. I am one of those people, at times. Because it&#x27;s faster to do so than read heaps of manpages for a situation I may never hit again.<p>Git might have awesome tech underneath, I really don&#x27;t know or care. But someone needs to really spend time in a typical dev&#x27;s shoes to make it nicer to use.
评论 #31985646 未加载
评论 #31987740 未加载
评论 #31988158 未加载
评论 #31985549 未加载
评论 #31986928 未加载
评论 #31985439 未加载
评论 #31985326 未加载
评论 #31985702 未加载
评论 #31986043 未加载
评论 #31985551 未加载
评论 #31988276 未加载
评论 #31986307 未加载
评论 #31988060 未加载
评论 #31987060 未加载
评论 #31986035 未加载
评论 #31993863 未加载
评论 #31989575 未加载
评论 #31988090 未加载
mpermaralmost 3 years ago
&gt;Nearly a decade later, new problems arose when Kubernetes (the operating system of the cloud) brought open-source collaboration to a new level.<p>I&#x27;d love to get more context to that statement to understand it better because as it is, it sounds as such an arbitrary statement that undermines the credibility of all the content below.<p>Kubernetes didn&#x27;t brought open-source collaboration to a new level. No matter how relevant Kubernetes is today, it&#x27;s just a drop in the huge ocean of OSS. Maybe level in this context refers to &#x27;gitops&#x27; which many of us where doing years before the term was coined and without K8s involved. Or perhaps the author refers to the fact that most gitops K8s frameworks will work via polling which is a fundamental scalability flaw.
评论 #31988478 未加载
评论 #31987489 未加载
评论 #31986983 未加载
评论 #31986280 未加载
评论 #31987864 未加载
评论 #31988675 未加载
评论 #31987842 未加载
pdmccormickalmost 3 years ago
Am I the only one who thinks that Git&#x27;s UX is fine, and maybe even rather enjoyable? It has taken time to learn, and I am by no means a power user, but its model is now in my brain so, for better or worse, it&#x27;s how I think and work now too (interactive rebasing for the win, all the time, and lots of shell aliases to shorten things). I do wish I had an easier way to split up a commit that accidentally included several unrelated changes though.<p>What&#x27;s the lesson, that you can learn anything eventually, or that familiarity means you will lose the ability to accurately evaluate something?
评论 #31985700 未加载
评论 #31985787 未加载
评论 #31987169 未加载
评论 #31987634 未加载
评论 #31985604 未加载
评论 #31985964 未加载
评论 #31985613 未加载
评论 #31986150 未加载
评论 #31994091 未加载
评论 #31986826 未加载
评论 #31985796 未加载
评论 #31989302 未加载
评论 #31985738 未加载
评论 #31989269 未加载
评论 #31986589 未加载
评论 #31986065 未加载
评论 #31988333 未加载
评论 #31990542 未加载
评论 #31987218 未加载
评论 #31985929 未加载
评论 #31989337 未加载
评论 #32018723 未加载
评论 #31986754 未加载
评论 #31987534 未加载
评论 #31987323 未加载
评论 #31985817 未加载
madmax108almost 3 years ago
I personally believe that making diffs more human friendly is the next step of evolution we need. I work with a team on a NodeJS+React project and nearly every other PR shows up as &quot;Something changed in package.json, something changed in package-lock.json, some static assets added&#x2F;modified, some JSON changed&quot; etc and it makes reviewing code quite unwieldy (esp. since it forces folks to use Github UI interface to even see blob diffs. which is quite opinionated on when it collapses a file in the PR, and how it determines what changed in a file). I feel like git was perfect when &quot;code&quot; was nearly almost completely text and patches were sent over email, but there&#x27;s a lot more boilerplate+blob data that goes into git today and git needs to evolve to support this.<p>I feel that once tools like Difftastic [1] and similar get more mainstream, and ideally more firmly entrenched within git itself, it will make code reviewing much smoother process rather than having to depend on Github or any other proprietary service.<p>[1] <a href="https:&#x2F;&#x2F;github.com&#x2F;Wilfred&#x2F;difftastic" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;Wilfred&#x2F;difftastic</a>
评论 #31985424 未加载
评论 #31992976 未加载
srikualmost 3 years ago
I&#x27;ve been using fossil (<a href="https:&#x2F;&#x2F;fossil-scm.org" rel="nofollow">https:&#x2F;&#x2F;fossil-scm.org</a>) for personal projects for like a decade now and I much prefer it over git. The characteristics that get me to stick with it are -<p>1. Single file executable. No dependencies to &quot;install&quot;. Just the executable and you&#x27;re good. 2. The whole repo is a single sqlite DB file. Fabulous for backups, sharing, hosting etc. 3. You cannot rewrite history unlike git. Hence the name. Folks using git have no idea what kind of a peace of mind this gives me. 4. Integrated issue tracker stored in the same repo. Complete with cross references to commits. 5. Allows repeated use of same tag name. This is so convenient in personal projects I miss it in git. You can mark a commit as &quot;published&quot; and later look at the whole history of all previous commits tagged as &quot;published&quot;.<p>Other niceties -<p>1. Integrated wiki - I&#x27;ve occasionally used it, but usually prefer to write documentation in separate files. 2. Integrated webserver - `fossil ui` runs on the same thing so I do use it. The webserver comes complete with user account management and permissioning. 3. Can export and import to&#x2F;from git.
评论 #31986449 未加载
评论 #31986366 未加载
评论 #31987818 未加载
评论 #31986347 未加载
tedk-42almost 3 years ago
Oh god this author again going after clicks for hit pieces on technology without providing any alternatives.<p>If you think you can do it better then go ahead and try build the product and then pitch it.
评论 #31985208 未加载
评论 #31985157 未加载
评论 #31985248 未加载
评论 #31985083 未加载
alenmilkalmost 3 years ago
The thing is that git is not supposed to be smart when it comes to merging. <a href="https:&#x2F;&#x2F;wincent.com&#x2F;blog&#x2F;a-look-back-bram-cohen-vs-linus-torvalds" rel="nofollow">https:&#x2F;&#x2F;wincent.com&#x2F;blog&#x2F;a-look-back-bram-cohen-vs-linus-tor...</a><p>At the end of the article: This is a clearly ambiguous merge and it simply wouldn’t be right for your version control system to try &quot;resolving&quot; it for you.<p>So the strategy is that if there is any doubt you have to manually fix conflicts. This is by design.
评论 #31987094 未加载
lucideeralmost 3 years ago
A lot of people responding (in good faith) to the premise of the title but not really engaging with the absolute nonsense points made within it.<p>Aside from it all being very vague, it struck me these are high level concepts and keywords the author seemed to have gleaned from experience working with knowledgeable peers but never quite grokked themselves. So it surprised me to read their open-source maintainer experience about page (though the professional experience being in Google does fit my original assumption).<p>&gt; <i>Atomicity accross projects</i><p>Git repos are as atomic as you make them. Github is not a defacto monorepo. The only people likely to use it as such are monorepo aficionados (Googlers?) who are deliberately avoiding atomicity. Also, Github isn&#x27;t Git.<p>&gt; <i>Package management</i><p>Package managers already use checksums. This entire point is just wrong and ignorant. Reproducible builds would be nice here, sure, but outside of a few weird exceptions in dynamic builds we already have what the author wants here.<p>&gt; <i>Semantic diff</i><p>This would be great but... the author is an engineer right. How much have they thought about this? This would be a gargantuan undertaking. An awesome feature no doubt, but the maintenance effort...<p>&gt; <i>Merge queue data structure</i><p>The body of this bullet doesn&#x27;t relate to the heading. I guess they&#x27;re talking about how in-progress merges are stored on the FS but how would that impact testing (which the author rightfully points out is unrelated to VCS). What? This is just mashing unrelated jargon keywords together.<p>&gt; <i>Fan-out pull requests</i><p>Github is not Git.<p>&gt; <i>git should be fully decoupled from the pull request and merge workflow</i><p>Oh dear. Where is Drew Devault...<p>&gt; <i>lfs</i><p>The first good point they&#x27;ve made<p>&gt; <i>fossil</i><p>Yes fossil is cool. If the title of the post was &quot;we should all use fossil&quot; it would be more realistic.
评论 #31993734 未加载
leeoniyaalmost 3 years ago
&gt; Semantic diff – Can we figure out how to use version control to have more context-aware merges? Can you believe that we still rely on a text diffing algorithm from 1976 (and its shortcomings)? Git still has trouble with file renaming. GitHub Copilot, but for merge conflicts? Semantic diff has been tried before, but language-specific implementations will likely never work.<p>in case anyone missed it: <a href="https:&#x2F;&#x2F;github.com&#x2F;Wilfred&#x2F;difftastic" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;Wilfred&#x2F;difftastic</a>
评论 #31984752 未加载
评论 #31984720 未加载
knighthackalmost 3 years ago
The only major problem I see with Git is that it&#x27;s just a pain if you&#x27;re working in a gigantic monorepo.<p>Outside of this, I think it&#x27;s achieved it&#x27;s ultimate form and tradeoffs <i>for what it was originally intended to do</i> - and the majority of projects fall under that category, meaning that while Git can be improved, but it doesn&#x27;t need to &#x27;change&#x27; architecturally or philosophically to accommodate other things.<p>Separate version control software can be designed for solving a specific problem - but I don&#x27;t think Git should need to evolve beyond the problems it&#x27;s designed to take on.
评论 #31986157 未加载
gorgoileralmost 3 years ago
The project management features don’t <i>have</i> to live inside VCS, but it would be nice to sync them there or derive some of the primitive data structures there — comment trees, approvals, CI red&#x2F;green results at integration time.<p>A project should encapsulate the code, how we got there, what we changed, and why we changed it.<p>The code is your HEAD, available as a working copy. How we got there is the stack of diffs that, when applied to an empty repository, accumulate to being the current HEAD. What we changed is more nuanced that just the diffs: It’s the commit messages explaining the diffs and adding context. If the diff changes an algorithm from n^2 to n then what we changed is the runtime complexity of x, which is good for reasons y and z.<p>Why we changed it is the bit that’s missing. Was this work originally from a bug report? Did real-life-n stay small for our first six months and has all of a sudden become much bigger? Who was involved in deciding this was the right thing to do, what did they say, and what other approaches did we think about? Which cat meme was deemed appropriate for the final approval of the change?<p>Right now, that stuff is all linked to from git but it’s not really a part of the workflow unless you remain inside GitHub’s or GitLab’s ecosystems. Seeing that in the underlying tool would be really cool.
评论 #31987179 未加载
coxleyalmost 3 years ago
Mercurial solves a lot of the UX problems. Maybe if Meta open-sources the API-compliant rust rewrite, we&#x27;ll have the scaling sorted too.<p>Commits are automatically &quot;branches&quot; off trunk. You typically do 1:1, commit:PR. As you make new changes to the same PR, you `hg amend` instead of another commit. Those commits get merged into trunk.
ribitalmost 3 years ago
My main headache with git — which is absent from the list in the blog – is that it tracks snapshots instead of tracking changes. It&#x27;s probably less of an issue for software developers where a &quot;version&quot; is what this all is about — after all, that&#x27;s what you ship, but if you try to use version control in a context of academic writing or data analysis, it can become very difficult to track individual contributions. All git can do is to compare snapshots and allow you to impose a resemblance causal order onto them (which you can freely manipulate anyway with rebasing, squashing etc.). If your workflow consists of trying out many different ideas and then choosing which of them to keep and which to discard, git can be extremely painful — you either end up with a history that is a complete mess or waste a lot of time rebasing and reorganising the (fake anyway) order of snapshots.<p>That&#x27;s why I am exited for tools like Pijul that attempt to actually track changes.
评论 #31986594 未加载
i_have_an_ideaalmost 3 years ago
&gt; Kubernetes (the operating system of the cloud)<p>The post just loses credibility after this statement. Yes, Kubernetes is important, but &quot;operating system&quot; is a clearly defined technical term. Using it arbitrary on something that is clearly not an OS to achieve some sort of an off-topic emphasis effect undermines the credibility of the content.
评论 #31986302 未加载
stellaloalmost 3 years ago
&gt; I saw the pain points of git<p>What are these? Asking for real: it’s the second time I read a similar sentence on HN this week, without finding any specifics, so I’m curious
评论 #31984731 未加载
评论 #31984711 未加载
评论 #31984677 未加载
评论 #31984719 未加载
评论 #31985284 未加载
评论 #31984691 未加载
chriswarboalmost 3 years ago
I like the patch-based approach of Pijul and Darcs: rearranging patches seems less fragile than rebasing snapshots.<p>I&#x27;d like to see git&#x27;s content-based more integrated into projects like IPFS (and for IPFS to get their resource-usage down, so it can be run as a background task on my laptop!)<p>As for package management, Git and Nix work really well together: e.g. we can use `builtins.fetchGit` to fetch particular commits; and we can `import` Nix definitions from those git commits; and those definitions can fetch other repos, etc. so we get a Merkle tree of the exact code used by all of our dependencies. I also like to write commit IDs as default function arguments, which makes it easy to override any of these dependencies to use another commit.
评论 #31988176 未加载
pgtalmost 3 years ago
Implicit branching in Pijul is a killer feature (IMO): <a href="https:&#x2F;&#x2F;pijul.org&#x2F;" rel="nofollow">https:&#x2F;&#x2F;pijul.org&#x2F;</a>
评论 #31984892 未加载
Xenoamorphousalmost 3 years ago
&gt; Kubernetes (the operating system of the cloud)<p>Never seen it described like that.<p>&gt; Previously, I was a software engineer working on open-source Kubernetes at Google, building and maintaining Kubernetes developer tools such as minikube and skaffold<p>Ah!
torginusalmost 3 years ago
My main issue with Git, other than the terrible UX of the CLI, is just how common it is for one to want to rewrite the commit history - an operation for which there&#x27;s no version control.<p>You better get it right, or otherwise you get to nuke the whole repository.
评论 #31984784 未加载
评论 #31984891 未加载
评论 #31985663 未加载
评论 #31984811 未加载
评论 #31984796 未加载
评论 #31984821 未加载
评论 #31985436 未加载
评论 #31984771 未加载
评论 #31985269 未加载
评论 #31984782 未加载
zambalalmost 3 years ago
&gt; I saw the pain points of git (and GitHub) firsthand working on Kubernetes open-source.<p>The article could have been interesting if the author actually expanded on what these pain points are. I&#x27;m genuinely curious about those.
eternityforestalmost 3 years ago
I&#x27;m perfectly happy with Git. In the most basic uses, it&#x27;s extremely easy, get git cola and you&#x27;re done. The advanced uses are harder than they need to be, but not by that much. There&#x27;s always google.<p>I wish it had native zip and sqlite support, I&#x27;d love to see issues and PRs more integrated, but that&#x27;s about it.<p>It would be nice to have an unversioned sync directory in a repo, that could be updated without a commit and had no history, for implementing fast-changing stuff where history isn&#x27;t critical, like stashing log files right on an internal config repo. But that&#x27;s not exactly necessary.<p>I&#x27;m sure better things could be done. But would they be usable over ssh, no certs needed, as well as HTTP? Or would you need a domain name? Would they have decent GUIs? Would they still be decentralized? Would they have an equivalent to LFS? What features would they drop?<p>Would half the features be plugins so that every repo relied on a unique set of optional features?<p>I&#x27;m... not sure I&#x27;d like the kind of VCS that the current FOSS culture would like to make....<p>If people really tried to replace Git, could see multiple VCSes getting big at once. Git is pretty unique in how it is so popular, you probably don&#x27;t need to know any others.<p>We can do better than git, but it&#x27;s pretty unique. It&#x27;s already a base primitive for so many things like package managers and notetaking. It&#x27;s so deeply engrained in dev culture, it&#x27;s almost like UTF-8, and I would hope whatever replaces it has that same property.<p>I think the easy solution would just be if the git devs themselves made a new first party front-end and added a few features.<p>There are lots of git frontends, that everyone ignores because you might as well just learn git, it&#x27;s everywhere, but if some new git2 command was included and just as common, we could have a very smooth transition.
rswailalmost 3 years ago
I&#x27;d really like issues porcelain that is built over git so that when I clone I get all of the project&#x27;s history, as well as it being merged with pull requests etc.<p>I hate that the github&#x2F;lab hosting solutions end up with a central database to keep track of issues, CI, etc. It breaks the whole &quot;distributed&quot; model.
评论 #31985947 未加载
评论 #31993272 未加载
评论 #31985735 未加载
评论 #31985358 未加载
评论 #31985371 未加载
ChrisMarshallNYalmost 3 years ago
Personally, I’m mostly fine with Git.<p>But I started off with MPW Projector[0], so it&#x27;s all sunshine, after that...<p>The “UX” doesn’t bother me, as it’s a fairly classic CLI application. Any “UI” is provided by apps that are written over the CLI. That’s a common pattern in development.<p>I use SourceTree, for the most part, with occasional drops into CLI, for specialized tasks.<p>Not perfect, but adequate. I <i>do not</i> use the Git integration in Xcode. I find it to be inconsistent and buggy (like many Xcode features).<p>I have found that submodules are all but worthless, which sucks, because I feel that they really are the best way to tag aggregate codebases. From what I understand, this is because of the author’s workflow. If submodules worked like package managers, that would be wonderful.<p>In my experience, I find sparse checkouts to be a bit “kludgy.” I find it annoying to have to check out an entire repo, for a single file (my testing code usually dwarfs the implementation code, in my packages).<p>Perforce used to be good at specifying “only what is needed” workspaces.<p>One aspect of VSS (dating myself —no one else will) that was <i>very</i> cool, was the ability to specify “artificial” workspaces.<p>You could create a workspace that aliased files from multiple workspaces into a new aggregate. When you modified and checked in work, it could be doled out to several different repos.<p>That’s pretty hairy. It would be difficult to implement safely.<p>Git has changed the way I work. As time has gone on, I have moved away from using feature and release branches, to using tags on a single mainline.<p>I think forks and PRs are great things, but they aren’t actually native Git features.<p>[0] <a href="http:&#x2F;&#x2F;preserve.mactech.com&#x2F;articles&#x2F;mactech&#x2F;Vol.14&#x2F;14.06&#x2F;VersionControlAndTheDeveloper&#x2F;index.html" rel="nofollow">http:&#x2F;&#x2F;preserve.mactech.com&#x2F;articles&#x2F;mactech&#x2F;Vol.14&#x2F;14.06&#x2F;Ve...</a>
EdSchoutenalmost 3 years ago
- A client side virtual file system (FUSE), so that you can work with large repos that exceed the size of your own system.<p>Version control systems like Piper (Google internal) and Eden (Facebook), GitVFS (Microsoft) already do this, but adoption is marginal.
评论 #31984721 未加载
评论 #31993343 未加载
评论 #31984758 未加载
SulphurSmellalmost 3 years ago
I wish I could answer this. I have always had a penchant for any robust versioning system. Even the simple ones (CVS and the like) were amazeballs to me at the time. 20 odd years ago I spent a lot of time with ClearCase (initially Rational, now Rational IBM). I was <i>amazed</i> at what could be done. We had dozens of customers, maybe 3 major and 10-14 minor versions in the field, and probably dozens of &quot;bug fix&quot; or &quot;special customer branches&quot;. Oh, and likely 2 or 3 on-going major version dev branches. Somehow, it all worked. If you could describe (by whiteboard or hand-waving) what you wanted to see as your working branch, it could be done. &quot;Give me a view that is exactly what customer x has, but for this directory, give me latest, except for this file...I want that one from customer y&quot; . And blam! The CC guys would make it happen. The magical config spec. I have had to dabble in many other SCMs.. SVN, Git, etc...and they all seemed to be a compromise. Or, just ran out of gas when the going got tough. In my mind, I wish I could argue that ClearCase was where it was at, and the patterns it supported would be wonderful to have today...especially over Git. But I don&#x27;t know enough to defend the point. All I am saying is that even with enormously complex version scenarios, the damn thing didn&#x27;t break and we all got our work done.
评论 #31987879 未加载
evougaalmost 3 years ago
Auto merge using a “semantic diff” sounds line a complete nightmare to me.<p>How many people actually check that git has merged code correctly? When there are no conflicts and the merge passes CI? Exactly.<p>Now imagine the git automatically fixes conflicts by rewriting code Copilot-style. It will work perfectly 95% of the time—--so that new feature is too useful to ignore and everyone uses it. 5% of the time git resolves the conflict by riddling your code with subtle bugs and vulnerabilities…
bryanph_almost 3 years ago
I don&#x27;t really want Git to change so much. What I do want however is for other tools to take over features from Git. Pretty much every app that I use in my daily life would be enhanced if it had git-like features.<p>My notes on this: <a href="https:&#x2F;&#x2F;topictrails.com&#x2F;app&#x2F;d&#x2F;ed47e12a-7cf9-4ec6-8f22-1c9717494fae" rel="nofollow">https:&#x2F;&#x2F;topictrails.com&#x2F;app&#x2F;d&#x2F;ed47e12a-7cf9-4ec6-8f22-1c9717...</a>
geenatalmost 3 years ago
Native large file support.<p>Git annex functionality built in = gg every other source control system.
评论 #31993361 未加载
irrationalalmost 3 years ago
&gt; Will a new version control system (or something that solves similar problems) spring up?<p>Of course. There is no way Git is the be all and end all of version control. Anyone who has been around long enough has seen lots of version control systems and knows that we will see lots more as time goes on.
评论 #31985502 未加载
gigatexalalmost 3 years ago
I dunno. I’ve decided like with SystemD to just learn it and get on with life. Git is ubiquitous and so is SystemD. Learn them. Adapt. Move forward.<p>This is not to say they’re perfect but they’re open source so if I felt strongly I could offer code to change it.
polyrandalmost 3 years ago
Not related to the problems listed in the blog post, but most of my problems with git went away when I started using worktrees[0] (I do a `--bare` clone and add worktrees in there).<p>Working on a new feature: new worktree Doing a code review: new worktree Testing random changes: new worktree (usually in detached mode) Need to debug some code from the current production branch: new worktree<p>All the problems with `checkout`, `stash` and switching between branches disappeared.<p>[0]: <a href="https:&#x2F;&#x2F;git-scm.com&#x2F;docs&#x2F;git-worktree" rel="nofollow">https:&#x2F;&#x2F;git-scm.com&#x2F;docs&#x2F;git-worktree</a>
he0001almost 3 years ago
I developed a couple of tools on top of git for various reasons. The problem I found is that many many developers don’t understand how git actually works, so they can’t translate git and what it actually does. I have to explain how git works over and over again. I think git is extremely good compared to everything else and it’s extremely simple yet advanced. But people don’t seem to understand what it actually does. Trying to replace it with something else is going to be hard as I believe that anything more advanced will be hard.
samgranierialmost 3 years ago
I&#x27;ve used Git since 2007, and mastered some of the esoteric parts of it a few years ago. I think it&#x27;s gonna be here to stay for the long haul.<p>Granted, the learning curve can be a little steep, but once you learn it you&#x27;re good to go. There&#x27;s a rich ecosystem of documentation, helper tools and shell aliases you can find that can help you master the tool to get your job done.<p>Some of my favorite paid tools for working with git are Tower and Kaleidoscope (I&#x27;m a huge fan of native mac apps).
brendoncarrollalmost 3 years ago
I&#x27;ve been working on a project &quot;Got&quot;. Which deals with the LFS problem, mentioned in the post.<p><a href="https:&#x2F;&#x2F;github.com&#x2F;gotvc&#x2F;got" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;gotvc&#x2F;got</a><p>Got isn&#x27;t really trying to do software version control better than Git. It&#x27;s trying to make general purpose file versioning practical, with a workflow similar to Git&#x27;s.
ziml77almost 3 years ago
The semantic diffing bullet point has me wondering what attempts there are at making open source semantic diff tools. I love the closed source tool SemanticMerge, but the company behind it decided to be shitwads and pull the product so they could add a selling point to their proprietary version control system.
评论 #31993489 未加载
naileralmost 3 years ago
&gt; Semantic diff has been tried before, but language-specific implementations will likely never work.<p>Why not? Storing code as code (ie storing an AST not text) and treating all changes as a CRDT, allowing your refactor to use a variable I just renamed without merge conflicts, seems completely reasonable.
oftenwrongalmost 3 years ago
With regard to repo composition, I have been following this project: <a href="https:&#x2F;&#x2F;github.com&#x2F;josh-project&#x2F;josh" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;josh-project&#x2F;josh</a>
kache_almost 3 years ago
Nothing. Keep it simple. There&#x27;s a reason it has stuck around<p>&gt;inb4 it isn&#x27;t simple<p>it is
评论 #31985724 未加载
评论 #31985391 未加载
评论 #31985125 未加载
评论 #31984786 未加载
t43562almost 3 years ago
Version control as a way of distributing and versioning the built code and also of rebuilding it minimally.<p>Goodbye to installers and package managers....and traditional build systems.
HelloNursealmost 3 years ago
It seems just a promotion for the worst past and future GitHub features of the Microsoft period, starting from intentional confusion between git and GitHub.
jamesromalmost 3 years ago
&gt;GitHub Copilot, but for merge conflicts?<p>Great idea. The corpus of data to train with would be incredible. Every merge commit across all of GitHub.
fsiefkenalmost 3 years ago
Project management and issue tracking can be done with for example an org-mode or taskjuggler file in or outside git.
dvhalmost 3 years ago
&quot;Talk is cheap, show me the code&quot;
评论 #31985682 未加载
nathiasalmost 3 years ago
for all complaining about UX, you can make your custom aliases and install extensions (eg. git undo) ...
评论 #31985766 未加载
bvrmnalmost 3 years ago
Looks like author has a typo in the title and Git should be read as GitHub.
ghowardalmost 3 years ago
Funnily enough, I&#x27;m working on the next Git. (I&#x27;m not the author of Pijul; it is another one.)<p>So here&#x27;s what I think of these points, as well as how my VCS will address them.<p>1. Atomicity across projects: this is a good point, a necessary one. When I asked people why Git submodules are so bad [1], that was the biggest point. My VCS will have this, even though I haven&#x27;t <i>quite</i> figured out how to do it yet. I&#x27;m almost there.<p>2. Native package management: my VCS will have this, sort of. The thing is that I hate CMake, so I&#x27;m building a build system, and while doing the design of it, I realized people are doing build systems and package managers wrong. So I&#x27;m working on that too. Needless to say, my package manager&#x2F;build system will be well-integrated into my VCS. (My package manager will also have another shtick: you can set security policies for individual packages, which means that situations like where npm packages become malware should not cause damage.)<p>3. Semantic diff: I have figured this one out. It will exist. It will be language-specific, but all that it needs is a lexer for the language and a dumb understanding of the structure. This same system will also be used for diffing and merging binary files, such as Blender files, PNG&#x27;s, executables, PDF&#x27;s, files for Microsoft Office, files for LibreOffice, etc.<p>4. Merge queue data structure: my VCS will have something that will serve this purpose and could probably implement a high-level interface to it, like Git has porcelain over low-level operations. However, what I have actually designed is so powerful, it will also be capable of real-time collaboration and of implementing full undo&#x2F;redo.<p>5. Fan-out pull requests: this is currently not in my plans (I think better package management would handle most or all of this), but it would be trivial to implement if people want it.<p>6. Terrible UX of Git: I&#x27;m going to spend the time on this upfront. In fact, I want to do user testing with non-programmers until <i>they</i> find it easy. I will take inspiration from Mercurial for sure, but the user testing results will be the most important.<p>7. Large file storage: my VCS would be completely inductive at binary files if I didn&#x27;t have a plan for this. I do have a plan, and I will be testing on large files, including up to multiple terabytes, from the start.<p>8. Project management hooks, but not features: there will be built-in features for things that should always be there (issues is one, I believe), but there will also be a way to set up your own. They won&#x27;t be hooks, per se, but it will be possible to create the project management &quot;flavor of the month.&quot;<p>Comments on these are welcome.<p>[1]: <a href="https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=31792303" rel="nofollow">https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=31792303</a>
vaughanalmost 3 years ago
I’d love to move away from parent commit hash being included in a commit hash. It makes rewriting history so complex.
评论 #31990629 未加载
nathantsalmost 3 years ago
git is like cpp, you have to use a subset:<p>- push<p>- pull<p>- checkout<p>- checkout -b<p>- merge —ff-only<p>- stash<p>- stash pop<p>- reset —hard origin&#x2F;master<p>- reset —soft $hash<p>- commit -m
评论 #31985707 未加载
评论 #31985601 未加载