TE
科技回声
首页24小时热榜最新最佳问答展示工作
GitHubTwitter
首页

科技回声

基于 Next.js 构建的科技新闻平台,提供全球科技新闻和讨论内容。

GitHubTwitter

首页

首页最新最佳问答展示工作

资源链接

HackerNews API原版 HackerNewsNext.js

© 2025 科技回声. 版权所有。

Why Don't I Like Git More?

57 点作者 josephscott大约 1 年前

17 条评论

VincentEvans大约 1 年前
I don’t expect my comment to somehow open the eyes of the writer of this piece, I have almost a resigned feeling posting this, as I have had this same interaction so many times…<p>I am not a smart man. I’ve been using git for about a decade and I won’t know how to do a checkout using CLI without asking chatgp. But at the same time I have none of the struggles the writer complains about. Because I use a GUI.<p>And before using git for the first time in 2016 - I used SVN for about a decade, also with a GUI.<p>The downside is it makes me a lot less cool than Neo-like hackers writing incantations in the dim glow of the monitor. Also if I wanted to write a blog post I would need to think of some other topic.<p>I use Gitkraken if you are curious, but I know you probably aren’t.
评论 #39950021 未加载
评论 #39949781 未加载
评论 #39949622 未加载
评论 #39949565 未加载
评论 #39964130 未加载
ptero大约 1 年前
I was reading the first part with instant buy in: simpler interface, &quot;light&quot; mode, yes, Yes, YES! We do not need 90% of the functionality, it can go into the expert mode.<p>And then I got to the main item of the proposal, removing decentralization, and my reaction was &quot;oh, no! Decentralization is what makes git worth it for me&quot;! So I guess while everyone does not need 90% of git functionality different users need different 10% of it. Which is a strong argument against a universal &quot;light&quot; mode. My 2c.
评论 #39978582 未加载
评论 #39956427 未加载
raggi大约 1 年前
A merge only workflow with replacement log tools to only show merge commits, and a better solution for CI and web presentation would basically fix git.<p>People have a ton of opinions on merge commits but they stem from very few real issues: The log UI is bad, bisect handles merges badly. That&#x27;s basically the crux of it. If you &quot;hid&quot; the railroad tracks as any higher level solution does then most of the problem goes away. Unsurprisingly the issue is that investment on this path disappeared when the rebase people won, and now we&#x27;re stuck with the least capable merge tool that git has as the way that everyone does everything. We kneecapped git, and it was us that did it to ourselves.<p>Edit: and rerere still is no where near as capable as merge.
评论 #39949358 未加载
seeknotfind大约 1 年前
IDK man. I&#x27;m kind of sad we don&#x27;t used decentralized more. That was a vision of the infinite future lost to the past. Client&#x2F;server symmetry is beautiful and maybe if GitHub goes down one day, we&#x27;ll remember the glory and power of a million scattered copies to save the day. Plus all this hoopdy-doo about what we can and can&#x27;t put on other people&#x27;s servers? Self-host, self-speak, self-actualize. ;P
评论 #39949588 未加载
erhaetherth大约 1 年前
There&#x27;s also Jujutsu; <a href="https:&#x2F;&#x2F;github.com&#x2F;martinvonz&#x2F;jj">https:&#x2F;&#x2F;github.com&#x2F;martinvonz&#x2F;jj</a>
评论 #39953866 未加载
rootusrootus大约 1 年前
Recent discussion with more comments: <a href="https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=39940448">https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=39940448</a>
dools大约 1 年前
For things I do frequently there&#x27;s alias or scripts. For things I do rarely there&#x27;s ChatGPT&#x2F;StackOverflow. I can&#x27;t imagine liking or not liking git. It&#x27;s just there. I guess it does everything I need it to do and so I like it. I like it better than CVS which is what I used before git.
juliusdavies大约 1 年前
He might like doing this:<p><pre><code> git push origin HEAD:refs&#x2F;heads&#x2F;MY_NEW_BRANCH&quot;. </code></pre> If you add a &quot;+&quot; character, it becomes a force-push:<p><pre><code> git push origin +HEAD:refs&#x2F;heads&#x2F;MY_NEW_BRANCH </code></pre> Let&#x27;s me work from master locally, but push my work to a new remote branch just for the PR. Saves a couple steps in his normal workflow as he describes it. I also tend to use the &quot;Squash&quot;, &quot;Rebase&quot; and &quot;Amend&quot; buttons on the PR&#x27;s web UI that makes a few of my common &quot;post-push&quot; operations even more convenient (thanks to a Bitbucket plugin).<p>Oh, and &quot;git pull --rebase --autosquash&quot; is also a big part of my workflow. Quite a miraculous &quot;does exactly what you want without you even knowing you want it&quot; command.
评论 #39949736 未加载
评论 #39949701 未加载
评论 #39949265 未加载
000ooo000大约 1 年前
Disagree with a bit in the article but particularly unpalatable to me is the idea that Git should be more than it is (e.g. PR support, web UI). Seemingly obscured in this idea is lock-in; if I don&#x27;t like Git with email patch workflow, I can use Git with GitHub. If I don&#x27;t like that, I can use Git with Forgejo. Good luck moving to more suitable tooling (because what is suitable often shifts over time) when you are stuck with the inertia of your entire VCS stack being one thing. Semi related: I was at an org recently who wouldn&#x27;t migrate to Git because they didn&#x27;t like the Git code review equivalent in Visual Studio, compared to how TFS code review looked in VS. That was seemingly the only possible way to review code - in VS.
capitainenemo大约 1 年前
This reminds me a little of this rant. <a href="https:&#x2F;&#x2F;www.bitquabit.com&#x2F;post&#x2F;unorthodocs-abandon-your-dvcs-and-return-to-sanity&#x2F;" rel="nofollow">https:&#x2F;&#x2F;www.bitquabit.com&#x2F;post&#x2F;unorthodocs-abandon-your-dvcs...</a><p>I do love mercurial&#x27;s tooling though. revsets, hg grep --all, hg absorb, hg fa --deleted, phases.. But, I&#x27;ve found svn is way easier to get a total novice up and running on, and for shared work servers, it&#x27;s fine...
hyperman1大约 1 年前
I&#x27;ve started to en ntegrate lazygit into my workflow.<p>It&#x27;s quite easy to work with and I use git in a more powerfull way. My main problem is finding the way in all hotkeys.<p><a href="https:&#x2F;&#x2F;github.com&#x2F;jesseduffield&#x2F;lazygit?tab=readme-ov-file#table-of-contents">https:&#x2F;&#x2F;github.com&#x2F;jesseduffield&#x2F;lazygit?tab=readme-ov-file#...</a>
viburnum大约 1 年前
It helped me a lot when I realized everything in git could’ve been named better.
q0uaur大约 1 年前
Totally agree with the OP&#x27;s feelings about git except one small nitpick, for me push and pull are opposites seen as how i use them, so it feels intuitive enough. Except for the wording of pull request, which IMO concerns the point OP made about decentralisation.<p>i fully agree that we could take more advantage of the effectively centralized nature git is mostly used.<p>personally, i don&#x27;t love using git, but i do love the advantages it brings, even for the smallest problems. it&#x27;s pretty much an all in one backup and sync solution too in my workflow, so i&#x27;m using it for my whole system configuration and user dir too, even tried using it for my addressbook and calendar with xandikos (baikal ended up working better for me though).<p>it&#x27;s just very unfriendly to use at times, and there&#x27;s reasons the &quot;meme&quot; about copying out your changes, deleting the whole repo, and pulling again is actually a common thing to do.<p>like, it&#x27;s easy to add everything with &quot;git add .&quot;. But you realize one file doesn&#x27;t belong in the commit, what do you do? git remove doesn&#x27;t exist. git rm isn&#x27;t it either. git unstage? nope. it&#x27;s git restore --staged, but ... i don&#x27;t want to restore anything? sure, the git version i&#x27;m currently using dislpays this every time i run git status, but... the whole fact that this needs to be displayed like this should tell you a lot already.<p>agreed that there is an unmet need for a version control that does the 99% of usecases in user-friendly ways.<p>edit: while we&#x27;re at it, let&#x27;s also ensure the next system we use makes it even harder to lose data. accidentally deleting a file that hasn&#x27;t been added in git can happen, and i&#x27;d like my version control system to help with that too.
评论 #39949478 未加载
ludston大约 1 年前
I guess I can&#x27;t take this seriously as soon as he said he didn&#x27;t want decentralised version control.
评论 #39949404 未加载
评论 #39978903 未加载
kazinator大约 1 年前
&gt; <i>Do I want submodules or subtree?&quot;</i><p>There is a sane third alternative: you add the dependency as an upstream directly to your repo and fetch its objects. You track it on a branch in which only that dependency exists (there is nothing else in the tree). You perform a rename which moves that dependency into the directory where you want it. Then you merge or cherry pick the renamed version of the dependency into your trunk.<p>The one advantage of a submodule is that you can maintain a separation if you locally hack the dependency. Your commits to the submodule are entirely separate from your project&#x27;s stream, and could be published independently and possibly upstreamed by that submodule&#x27;s project.<p>These activities are not impossible if you integrate like I recommend above, but they become more work.
CRConrad大约 1 年前
There&#x27;s so much wrong with this that it&#x27;s hard to see if there&#x27;s anything at all right with it.<p>&gt; More specifically, it doesn&#x27;t work offline.<p>??? Of fucking <i>course</i> it does! You mean Git <i>Hub</i> doesn&#x27;t work offline, don&#x27;t you?<p>&gt; It relies on merge controls that aren&#x27;t even a part of git with Pull Requests.<p>No, <i>git</i> doesn&#x27;t &quot;rely on merge controls that aren&#x27;t even a part of git&quot;. Other things do. Things people nowadays confuse with git. People like, apparently, the author of TFA. (And no, the &quot;F&quot; doesn&#x27;t stand for &quot;fine&quot; in this case.)<p>&gt; Dump the decentralized model.<p>You can do that yourself: Just don&#x27;t use it.<p>&gt; Move a lot of the work server-side and on-demand.<p>Sure, just ssh into the server and run your search there. What&#x27;s your problem?<p>&gt; Pull Request as a first-class citizen.<p>A: Huh? But that&#x27;s part of a decentralized workflow, and didn&#x27;t you just say to &quot;Dump the decentralized model&quot;? Make up your mind.<p>B: &quot;git request-pull&quot;: <a href="https:&#x2F;&#x2F;git-scm.com&#x2F;docs&#x2F;git-request-pull" rel="nofollow">https:&#x2F;&#x2F;git-scm.com&#x2F;docs&#x2F;git-request-pull</a><p>&gt; Why did SVN get dumped then? One word: branches.<p>Yeah, that <i>is</i> a bit ironic... Seeing as how git&#x27;s killer feature was branches, and for the last ten years (or how long has it been; at least five?) everyone has been pooh-poohing them and going on about their &quot;linear commit history&quot;, as if that were somehow so fucking important.<p>&gt; I also think programmers love decentralized designs because it encourages the (somewhat) false hope of portability. Yes I am entirely reliant on GitHub actions, Pull Requests, GitHub access control<p>Who told you to make yourself dependant on all that shit? I sure didn&#x27;t, and I&#x27;m pretty sure git didn&#x27;t either. Sounds -- again -- like your problem is with GitHub, not with git.<p>&gt; I could move the actual repo itself to a different provider.<p>Your problem is probably that you think you need a &quot;provider&quot; in the first place. Just put a fucking ordinary <i>git repo</i> somewhere, and use that.<p>Sheesh.
narven大约 1 年前
have u tried <a href="https:&#x2F;&#x2F;github.com&#x2F;martinvonz&#x2F;jj">https:&#x2F;&#x2F;github.com&#x2F;martinvonz&#x2F;jj</a><p>??