33 ms·

Where are my Git UI features from the future?

161 points by arxanas 4y ago

jandeboevrie 4y ago
I often use Sublime Merge to reword commits (edit commit message, even other branches, the entire log is visible), or to split up commits (it undoes the commit and you get everything in the working directory), so I’m not sure if his comparison table is entirely correct. (At least from a user point of view I can easily edit or reword). One other nice feature of Sublime Merge is the squashing of two commits, ignoring the latters message (as a fixup). Not sure how to do that in one click or command with cli git…
- arxanas 4y ago
  Can you reword/split commits without having them checked out, or without touching the working directory? That’s what these criteria are about, and from your description, it doesn’t sound like you can do those directly in Sublime Merge.
  - kemayo 4y ago
    You can only edit any commit that's reachable from the current HEAD without checking it out. I.e. a commit that's in a branch that's not merged back into wherever you currently are can't be edited. (I made a test repo to check this, because it had actually never come up before in my day-to-day usage.)
    - arxanas 4y ago
      Thanks for pointing this out. I confirmed that you can reword a commit without checking it out, with the caveats: - It has to be an ancestor of `HEAD`, like you said. - Doing so doesn't invoke Git's `post-rewrite` hook, which can cause interoperability issues with other tools :( - Doing so will abandon at least some descendant branches (possibly all descendant branches which aren't checked out, or possibly just those which branch aren't ancestors of `HEAD`). - Doing so doesn't seem to be undoable inside Sublime Merge via the undo command.
rcme 4y ago
> Rewording a commit is guaranteed to not cause a merge conflict, so requiring that the commit be checked out is unnecessary What if someone else rewords the same commit?
- afiori 4y ago
  That will be resolved during a merge/rebase and only if you are editing an already pushed commit. Overall git does use the filesystem in a lot of cases when it is not needed.
- arxanas 4y ago
  Ah, I should have been more precise. If you were to reword a commit in the equivalent manner as `git rebase -i`, which is to say, reapplying any descendant commits/patches, you would be guaranteed not to get conflicts while applying descendant commits. I suppose there is some possibility for merge conflicts in a workflow where you reword a public commit, which changes the merge-base in an unfortunate way and causes conflicts to appear which wouldn't have otherwise. Primarily I meant the workflow where you reword local commits only. More enlightened version control systems like Mercurial can handle this better, such as via its "commit evolution" feature. If you then rebase on top of a reworded commit, the patches will apply the same, and you can resolve the so-called "divergence" by running `hg evolve`. (It's still possible to have un-automatically-remediable divergences, such as if two people reword the same public commit in different ways, but it handles the common case.)
samuelstros 4y ago
We are working on "the next git" that brings version control to the rest of the world. > No one bothers to consider: what are the workflows that people actually want to do? What are the features that would make those workflows easier? What a coincidence, I just created a document [0] that collects engineering and UX issues that we are running into with inlang (localization infrastructure built on git) [1]. Part of bringing version control to people outside of software engineering is fixing UX related issues. For example, your proposed `sync` command is interesting. Our observations lean towards some real-time collaboration workflow that could make `pull, push, sync` workflows redundant. Applications that benefit from version control like a next-gen Figma, Adobe Premiere, Excel, etc. require real-time collaboration. A question that I've been asking myself whether real-time collaboration in software engineering makes sense too. To be elaborated! :) [0] https://github.com/inlang/inlang/blob/main/content/git-sdk-notes.md https://github.com/inlang/inlang/blob/main/content/git-sdk-n... [1] https://github.com/inlang/inlang https://github.com/inlang/inlang
yrgulation 4y ago
Git is pretty easy to use but people tend to overcomplicate it. Just push changes to your branch. Merge when ready. And keep your branch up to date with your main branch. Easy.
- nibbleshifter 4y ago
  Personally 99% of the time I just push to master/main lol.
  - yrgulation 4y ago
    [dead]
- ilyt 4y ago
  If you want to use DVCS as DVCS you gotta understand the details. People don't then get into trouble. But to be fair git will do exactly what you ask it to and not warn about some pitfalls and there is also no "tell me what this operation would do" so it's easy to get into nasty state if you just copy commands off internet.
- epolanski 4y ago
  this. Unless your company has a huge fixation with git history you really don't need to know much more than basics one can pick up with ease in what, few hours? I never rebase in my life, I just merge the target branch and call it a day, most companies only track merge commits anyway so history is the same.
  - yrgulation 4y ago
    [dead]
zoul 4y ago
The Git version control system has been causing us misery for 15+ years. I think this is uncharitable at best. It was a huge step forward compared to then popular VCSs such as Subversion, I have loved working with Git since it was created and I still enjoy working with it every day.
- arxanas 4y ago
  Mercurial has been around for approximately the same length of time, and from a UX perspective, I find it to be much superior to Git, which was largely built in terms of "what is the easiest way to solve this problem from an implementation perspective", rather from the user's standpoint. Of course, Git won for a reason, but I doubt that it wouldn't have still won had it incorporated some UX design ideas from Mercurial or elsewhere. > I have loved working with Git since it was created and I still enjoy working with it every day. I have been profoundly frustrated by working with Git every day, hence the article, and the linked set of tools which I wrote to improve my workflow. Not even because its mental model is hard to grasp or that the UI is poor, but because it doesn't even streamline the kinds of workflows that it should be good at (in the article, and discussed in its own `gitworkflows` man page).
  - Beltalowda 4y ago
    > Of course, Git won for a reason 1. Linus Torvalds wrote it 2. GitHub 3. Linus Torvalds wrote it To be fair, there are some real differences; e.g. there is no easy "hg rebase" by design, and whether that's a good or bad thing has been a topic of contention for about 15 years. But that Linus wrote it gave it a huge boost, and GitHub really was much better than many things that came before it (and arguably, still is).
    - murderfs 4y ago
      Having the kernel as an anchor customer definitely helped, but there's also the reason that Linus wrote git in the first place, and that's that every other competitor was horrendously slow by comparison.
alex_suzuki 4y ago
What I like about SourceTree is the ability to pick individual lines and „hunks“ to stage, as I often have changes and some debugging stuff sprinkled into some files (think printf). Since it‘s not explicitly mentioned, I assume this is a pretty standard feature? I wouldn’t mind switching away from SourceTree, it crashes often.
- xtian 4y ago
  Yes: `git add --patch`
- okl 4y ago
  Give `tig` a try.
- eyegor 4y ago
  The one built into vs2022 has this and works pretty well if you happen to use it already. I think vscode has many of these features but I haven't tried it there. Otherwise I'd say look at gitkraken (free for personal use I think) or sublime merge if you really want performance. Personally I use sublime merge or command line for everything. The sublime merge/text interactions are really nice, being able to right click in a diff and have it open the file at the line. You can try them for free forever but the price may be a deterrent since the dark theme for merge is locked behind a license key.
- iza 4y ago
  Indeed most git GUIs can do this. git-gui (built-in), VSCode, Sublime Merge, Git Extensions to name a few.
- misnome 4y ago
  You can do this on the terminal with `git add -p` but yes it’s always slightly more intuitive with a proper editor (I mainly use the many-times-forked GitX for this)
- Lex-2008 4y ago
  I used `git gui` for that (not sure how "native" to git is it, though), and recently switched to `gitg` for both looking at tree and committing individual lines. Can't compare them with SourceTree, though, since haven't used that. Also, when on command-line, I recently discovered `git add -i` for interactive mode (asks you about individual hunks and lets you "split" them), and `git add -e` (lets you edit the patch however you want).
mabbo 4y ago
Three things that I feel are true about git's model: 1- the model is not intuitive to beginners. There's a really tough learning curve. 2- the model is powerful but leads to a few specific workflow. If you don't have the same mental model and don't want to use those workflows, you will have the "misery" the author describes. Otherwise, you'll be perfectly fine. 3- no one has yet to do a great job of describing that model and workflow visually. The author's "features from the future" feel to me like they just haven't gotten a good feel for the model. That's why they are miserable. That's partially because git's model is hard to learn, and partially because after all this time they still haven't taken an hour to deeply learn it.
- timhh 4y ago
  I disagree. The model is intuitive. It's just that Git dresses it up in confusing language, a terrible CLI and a gazillion half baked GUIs. It doesn't help that lots of people recommend not using a GUI which is terrible advice for learning. Btw I would recommend GitExtensions for learning Git. It has the most intuitive interface I've found. For example it lets you browse the files at each commit which really shows how commits are snapshots, not diffs.
  - goku12 4y ago
    Git model is intuitive until you have to deal with merge conflicts, rebasing etc. Are you judging with that experience? > For example it lets you browse the files at each commit which really shows how commits are snapshots, not diffs. This is exactly the problem I mentioned. For one, each commit is a snapshot in the sense that it shows us a snapshot. Internally, it's a bunch of hashed and interlinked files. Git only collects them to show us a snapshot. But you probably knew this already. The real confusing part comes when you have to amend a commit, merge branches, interactive rebases, etc. The changes between the commits are propagated as patches. Even the merge algorithm uses a 3-way diff. Rebases is all about diffing and patching behind the scene. Thinking that these are snapshot operations will make the operation much more hard to imagine and predict. You should know when to use snapshot model and when to use diff-patch model in Git. This part is also rarely mentioned in Git tutorials or tools (stgit on the other hand, exposes this diff-patch idea very well)
seanalltogether 4y ago
I would like a ui that can show me what conflicts are about to happen before I do a merge or rebase. Trying to resolve a conflict after it's already happened is much harder then if I knew what files and lines are about to blow up on me. Even better start warning me about which files I've been editing are going to conflict with origin once I eventually have to sync up
- Izkata 4y ago
  Merge and rebase both have "--abort", which undoes the change if you're in the middle of a conflict.
  - seanalltogether 4y ago
    To be clear, I'd like to see the future conflict while my files remain in a clean state, so that I reconsider my own changes or work around the conflict before it happens
    - krupan 4y ago
      After you do --abort you are back in time before the conflict happened. This is literally what you are asking for
- okl 4y ago
  You can abort a merge or rebase with `git merge --abort` and `git rebase --abort` respectively.
- arxanas 4y ago
  Yep, most tools are deficient in this area, as per the table. My linked git-branchless tool will tell you before a merge conflict occurs, so that you don't have to abort it, although it could produce more information about the impending merge conflict.
- aequitas 4y ago
  This is one of those cases where the solution seems difficult, but the difficulty is in the problem itself, not the solution. The source of the conflicts is the fact that you work with multiple people, in a distributed way on the same codebase. Those conflicts are going to arise one way or another. Git could tell them to you beforehand, but that would be just the same as rebasing and then aborting. The conflicts stay the same, no matter how you slice them. In my experience best is to coordinate with other about code changes to avoid conflicts altogether or to fetch and rebase often to keep conflict scope to a minimum so they are more manageable. Also keeping commits focussed on single features/changes instead of spreading out the feature over multiple work in progress like commits so they can be applied as a standalone change helps. I really learned this when working in Gerrit Review for a while. Where there is no one pull request for a branch full of commits, but each commit is a change applied to master on its own and has to be reviewed/tested as such. Git is not a magical tool that solves all collaborative coding problems, but more a toolset that helps you manages code changes. You definitely need to put some effort into the mental model of how to manage changes before you can use the toolkit to its full potential.
CSSer 4y ago
You’d think that Microsoft and Github would have a monopoly on this given their personal contributions to Git, ownership of Visual Studio Code, and ownership of the largest Git hosting PaaS. Don’t get me wrong, VS Code and Github are both okay. I use them both and drop into the integrated terminal for situations where my muscle memory is faster or the workflow is going to be more complex. I also find that setting VS Code to my default editor for Git makes this pretty seamless. Anyway, I find it interesting that there doesn’t seem to be a big focus on the sort of features the author mentioned in VS Code. Now that I think of it, this is also one of those few circumstances where I don’t need or want the tool to be modular. VCS are such a fixture today that I just expect this to be built into the IDE’s GUI. A separate app, even with perfect workflows, may be just as much of a bother as a terminal. After all, what’s stopping me from writing a handful of clever aliases?
- heywhatupboys 4y ago
  are you unironically wishing MS would EEE git? lol
- DangitBobby 4y ago
  The only passable git GUI IMO is the one built into Jetbrains IDEs. VSCode makes only the very most basic workflows simpler (doing a commit) so I use that as well on the rare occasion I'm using VSCode. For every other git GUI, I'd rather just stick to CLI.
vouaobrasil 4y ago
I've used Subversion, Git, Mercurial and a few others to test them out....honestly although Git is better than Subversion, I like Git the least and I've been using it for about 6 years. I don't like its interface, weird command names like remote add origin, fetch/pull/clone, clean -nx, arg. It's a very frustrating piece of software whose commands seem more reflective of it's design rather than what it was designed to do.
- deleted 4y ago
  [deleted]
- epolanski 4y ago
  Would be interested in reading a thorough analysis.
timhh 4y ago
> It should be possible to sync all of my branches (or some subset) via merge or rebase, in a single operation. Not sure if this is exactly what the author is looking for but I made Autorebase exactly for this. https://github.com/Timmmm/autorebase https://github.com/Timmmm/autorebase Great article btw. A lot of those things are way harder than they should be.
- epage 4y ago
  Also git-stack has a --pull flag to rebase all local branches and --push to force-push-with-lease them. EDIT: oh, article author is git-branchless author, they know of git-stack.
helloguillecl 4y ago
The CLI interface of git is very good at enforcing you to be aware of the underlying model (local state and the repo’s history). This allows for the user to draw an accurate user-model in his understanding of the system. Adding an “undo” command would be convenient, but it would hide the underlying potential away. This is something that should belong to a GUI client, and I still would want to know what is it actually doing. Instead of hiding the abstractions behind a “friendlier” CLI, Git shows you its real power and that of VCSs in general, by having a lower-level API. Not even the multiple GUIs built on top of Git, adventure themselves into hiding or dumbing down the abstractions that allow you to do quite complex things with the code and its history.
- arxanas 4y ago
  Git can have a powerful API and also support higher-level workflows; it just doesn't. > Adding an “undo” command would be convenient, but it would hide the underlying potential away. It would not hide any underlying potential away; see https://blog.waleedkhan.name/git-undo/ https://blog.waleedkhan.name/git-undo/ for a general-purpose CLI implementation.
- WastingMyTime89 4y ago
  > Instead of hiding the abstractions behind a “friendlier” CLI, Git shows you its real power and that of VCSs in general, by having a lower-level API. But that’s simply not true. Git is just inconsistent in how it does things. Sometimes it wants you to deal with its inner state (typically the undo where you just need to move HEAD to a previous commit which might be only visible in the reflog). Sometimes it introduces complex concepts which would be simpler if they were just exposed for what they are (stashes are just temporary commits). Honestly Git is a mess. It works but the UX has always been awful.
- klabb3 4y ago
  > The CLI interface of git is very good at enforcing you to be aware of the underlying model (local state and the repo’s history). Awareness of state is sometimes important, sometimes you just need awareness of operations. And awareness of git's data structure does not necessarily map 1:1 with understanding the state of the code base. Not saying you’re wrong, just saying that this may or may not be a good thing. I’m personally leaning towards this could be improved. Really good advanced tools should work well for common use cases, so you can master it incrementally. Git is extremely frictionous for certain simple tasks, which is evident if you look at stack overflow. If a user wants to do something very simple in human terms (like fix a typo), and you get a lecture about merkle trees and reflogs, then I think there is room for improvement. The truly important question though, is whether the UI can be improved enough without changing the data model (ie can replace the UI without replacing your repos).
fxtentacle 4y ago
> as if Git’s command-line interface were already the pinnacle of usability. It is, for me. I love git and checking in my progress in small chunks that make sense to me is very easy with the command line tools. They're also easy to integrate and automated. Maybe they truly are the pinnacle of usability? As another example, compare cashiers using one of those DOS GUIs with modern ones using touch screens. The simpler GUI works much faster, once mastered.
- stephen_g 4y ago
  Yeah, I’ve never had a problem with it. I mean, sure it’s not perfect but I really don’t get all the hate.
  - CivBase 4y ago
    I think the hate comes from it not being very "noob friendly". It's designed for power users who are familiar with how git works. In my experience, most git users don't really know how git works fundamentally. They just learn the commands for a particular workflow and stick to that. That's how I started. I've seen this to be especially true for developers coming from SVN or another centralized versioning system.
- howinteresting 4y ago
  A very basic issue with git is that if you're editing a stack of commits, you can't go back to an earlier commit without completing the rebase -i and restarting it.
  - cryptonector 4y ago
    Not quite true. You can add `exec git branch progressN HEAD` every so often in the `git rebase -i` script, or you can `edit` commits and before `git rebase --continue` do `git branch progressN HEAD`, then later if you need to abort and restart your rebase you can rebase --onto one of those saved HEADs.
samgranieri 4y ago
I highly recommend using Tower. Yes, it’s a paid app with a yearly subscription fee, but it’s worth it. I really enjoy using the rebase functionality to reword, split, and reorder commits. I also know how to do this on the command line, but sometimes I enjoy using a gui on macOS.
- arxanas 4y ago
  Can you specify which of the features in the table from the article it provides? If so, I can update the article. The last time I used Tower, I was not impressed, for the same reasons as the other Git UI tools in the table which try to offer simar features.
  - dhritzkiv 4y ago
    I would say that while Tower can't achieve the specific features to the specifications defined in the article (as I understand them), its main advantage is how stable, predictable, and at-home it feels on macOS, which cannot be said of /any/ of the other GUI clients (where applicable, on macOS). It's responsive, commands finish as expected, and I can also perform many operations with a drag and drop or via the context menu. This predictability lends a lot of confidence to me achieving my work, and I feel others feel the same. As for the features, it: - supports `undo` of arbitrary operations quite well. - has a dedicated `reword` (as "edit commit message") command/flow (but will ask if you want to stash your current working copy, with the option to automatically re-apply the stash) - `split` kind of works by entering a "edit a commit" flow, which lets you stage and commit multiple times. In short, editing a single commit can generate one or more commits. - `large-ops` and `large-load`: I've never noticed the GUI becoming unresponsive, but it's possible none of the repos I've checked out are large enough. Note: Tower on Windows feels out place on Windows/ doesn't work as well as on Mac, but is still a formidable git GUI.
    - brunobrito 4y ago
      Thank you for mentioning Tower! I would just like to add that Tower 9 also included many improvements around the merge/rebase experience, including an Instant Conflict Detection that should satisfy the "preview" workflow mentioned. Here's an example: https://imgur.com/a/VCkqrBI https://imgur.com/a/VCkqrBI More info here: https://www.git-tower.com/blog/tower-mac-9/#1-merge-improvements https://www.git-tower.com/blog/tower-mac-9/#1-merge-improvem...
vanjajaja1 4y ago
Would love a git/PR workflow that was aware that I work on the next feature (or two) while the previous PR is being deliberated. I need a pipeline system where I decouple “do code” and “negotiate merge upstream”. Managing this manually is a pain, especially over multiple connected repos.
- nektro 4y ago
  if this is something you're doing very often i believe https://git-scm.com/docs/git-worktree https://git-scm.com/docs/git-worktree is the intended solution
  - vanjajaja1 4y ago
    thanks, I'll have a play with this see if it helps
efortis 4y ago
IntelliJ's git UI has those features.
- arxanas 4y ago
  I have used IntelliJ's Git UI and never noticed it having those features as described in the article (such as reword without checking out or merge conflict previews). Can you show me where to find those features?
  - efortis 4y ago
    Reword: https://www.jetbrains.com/help/idea/edit-project-history.html https://www.jetbrains.com/help/idea/edit-project-history.htm... Resolve Merge Conflicts: https://www.jetbrains.com/help/idea/resolve-conflicts.html https://www.jetbrains.com/help/idea/resolve-conflicts.html
    - arxanas 4y ago
      If I'm reading this correctly, you cannot reword a commit without first checking it out, and you cannot preview merge conflicts without first starting a merge/rebase operation? Those are the criteria as described at https://blog.waleedkhan.name/git-ui-features/#rubric https://blog.waleedkhan.name/git-ui-features/#rubric
      - david_allison 4y ago
        Reword: you don't need to check out the commit. The 'log' tab shows a tree of the commits to the repo. This log can be filtered in multiple ways: for example by branch or via a search string. You may right click a commit to reword.
        arxanas 4y ago
        Thanks. I confirmed that you can reword a commit which is reachable from `HEAD`, but not those on other branches in this way, similar to Sublime Merge elsewhere in the comments.
jobstijl 4y ago
I'm still hoping https://pijul.org/ https://pijul.org/ usage will grow.
- goku12 4y ago
  Pijul is superb. I do use it. But my wish is that they release 1.0 ASAP. Long time in beta for a code management tool isn't too healthy for it.
  - pmeunier 4y ago
    From your usage, do you feel it's 1.0-quality?
    - goku12 4y ago
      In my opinion, you should certainly go for 1.0, unless you are planning some breaking changes at this point - which I guess you are not, after reaching beta. My general deduction is that tools with a few bugs at an early 1.0 has a better chance of succeeding than tools that stay too long in beta. It's important to ensure that interest from users, distro packagers and commercial adopters are kept alive while waiting on 1.0. I'm still waiting for pijul to be in the distro repos, though the crates version work satisfactorily. This may turn away many other potential users. Alphas and betas should be time-limited, not bugs-limited. Bugs are what patch versions in semantic versioning are for. Remember: 1.0 is a magic number - it increases the exposure of your tool and potential contributors by a large factor. By your standards, git would have stayed in pre-1.0 for a decade and would not have become this popular. On a personal level, I use pijul for managing my dotfiles. I haven't encountered any bugs yet. The only feature I miss from git is the availability of tools like syntax highlighters for diff and record and UIs like tig, gitui and magit. But again, those are just features you could add as minor versions. That aside, pijul feels like magic. A handful of pijul commands cover most of the use-cases of git. After using git for so long, I always wonder if I'm using pijul the wrong way, even though I get the expected result. I'm only familiar with svn, git, bzr and hg. Perhaps Darcs would have given a better idea about what pijul really is.
plusminusplus 4y ago
Thanks for doing the research, there's so many git GUIs it saved me a lot of time. Limitations of these GUIs leave you in a limbo switching between them and the CLI. The "git sucks" heading might turn off readers; there are so many "git sucks" articles with less nuance and research than this one. (Notice most of the comments already are just related to that, or git in general.)
- arxanas 4y ago
  > The "git sucks" heading might turn off readers that have otherwise have been interested Thanks for the feedback. Do you have a better idea for the heading name? > Notice most of the comments already are just related to that, or git in general. After having read the comments for many Git-related articles, and having posted a few of my own, I can tell you that this would have happened regardless of how well the article was written :)
  - pvg 4y ago
    I don't think it would have been as bad without the provocative title and subheds. They effectively hide the work you've done and provide handy hooks on which commenters will eagerly hang their generic tangents. This is a pretty lousy aspect of HN and I don't think it's any kind of indication the article is somehow not well written. But I think you underestimate how much these initial conditions affect the quality of discussion.
  - cryptonector 4y ago
    "Git sucks for me" Git definitely does not suck for me.
franky47 4y ago
I only properly understood rebasing when I started using Ungit [1], visually seeing commits being replayed on the base branch makes it much more intuitive. Another was treating branches as "labels", that can be advanced to a more recent linear commit timeline. Very useful for a production branch following the main dev branch (essentially electing commits as production-ready). [1] https://github.com/FredrikNoren/ungit https://github.com/FredrikNoren/ungit
- FairDune 4y ago
  Thanks for the suggestion.
t00 4y ago
SmartGit have not received credit it deservers, sure there are hi quirks like showing unstaged file tree, but workflow with git made me switch to it from GitKraken, GitExtensiona and others. I would call the benchmark article rather subjective due to limited amount of comparable features and excluding most frequent workflow components with a respective ease of use score.
- arxanas 4y ago
  It is very much subjective!
wdfx 4y ago
I don't really understand how SmartGit failed you? In your table of results it covers at least as many features as the others. I call this out because I have been using SmartGit as my only git gui now for about 10 years and I think it does a grand job. It doesn't hide any information about the repo and makes just about any operation pretty straightforward. I also find it's built in diff and merge tools better than others. It also performs well enough and had been super stable. (I am not affiliated with SmartGit, just a happy customer).
- wdfx 4y ago
  Re-reading the article and I see that your table headers are misaligned. I see you did mark SmartGit negatively in every category. It does support many of those features, so what gives? EDIT: retract harsh words
  - arxanas 4y ago
    Apologies for the misalignment. I had difficulty formatting the table in a legible way. See my other comment re. the rubric.
- arxanas 4y ago
  SmartGit failed to provide for any of the workflows discusses in https://blog.waleedkhan.name/git-ui-features/#rubric https://blog.waleedkhan.name/git-ui-features/#rubric. Can you clarify which of these points was assessed wrongly, so that I can update them?
  - wdfx 4y ago
    Ok I will end up agreeing with you, for the specific clauses where you require the operation be possible on any commit, even if its not part of the tree of HEAD. I guess I reacted strongly to the negative review because despite your assessment it is still an eminently usable tool and in all the time I've used it haven't needed it to do anything more than it does. As per my original comment though, I'd you haven't tried it's conflict resolution/merge tool I would recommend you do and perhaps you might be tempted to give it at least half a bonus point :)
foobarbecue 4y ago
> The Git version control system has been causing us misery for 15+ years I think git is pretty good. It was good enough to be the first VCS to really reach critical mass (before, I used RCS, CVS, SVN, and hg). It might not be the BEST vcs, but it's got everything I need and it's easy enough that I can teach non-technical people to use it and clean up after them when they find the footguns. And the cli has been shortly but surely improving. It has facilitated my collaborations for 15 years with very little misery.
chx 4y ago
Speaking of undo, I have built a safety against git reset long ago https://gist.github.com/chx/3a694c2a077451e3d446f85546bb9278 https://gist.github.com/chx/3a694c2a077451e3d446f85546bb9278 there are a few more useful commands as well. This has saved my bacon a few times.
goku12 4y ago
>I will award honorary negative points for any client which dares to treat git rebase -i as if it were a fundamental primitive. If you think that a git rebase is overcomplicated, rather than a fundamental primitive, then you missed an important part of the tool. And phrasing it this way is an insult to anyone who really tried to understand the tool - kind of like the nerd badge in schools. Git rebase is fundamental to Git in many ways. It is also easy in many ways. At the minimum, it makes it easy to make mistakes while experimenting much less of a hassle, since the commit chain can be cleaned up later. However, the point here is that git rebase is more similar to what the kernel developers and git developers intended to do with the tool, compared to the commit-merge workflow. There are two aspects here: 1. The tool developers want every commit to be feature-complete and that it won't cause broken builds at least in the master branch. This is impossible to achieve in the regular commit-merge workflow.You need to add the interactive rebases to achieve the goal. 2. Git hides something behind the snapshot model it claims to be based on. The commits themselves are snapshots. But the way changes are propagated between commits (like stashing, commit amending, merging, cherry-picking, rebasing, squashing, splitting, etc) depend on plain old text diffs/patches. It takes a while for beginners to realize this. The kernel devs were using emailed patches and tools like quilt patch manager for nearly a decade before they created git. You can still see the influence of diff, diff3, merge and quilt in the design of git. Knowing this makes you much better at predicting the outcome of these operations. Blaming the tool without trying these techniques is very uncharitable indeed. I've been learning Pijul these days. All those complicated operations are condensed into a small set of commands in pijul. For one, it concentrates on patches only. I feel that part of Git's complexity is its mixing up of snapshot and patch model into a single program. Git didn't have the luxury of these diff alogrithms back then.
- arxanas 4y ago
  Rebasing is a fundamental primitive, but not Git's implementation of interactive rebasing. I very much subscribe to a "patch-stack" workflow, but have a great deal of difficulty doing advanced things in Git, because `git rebase`/`git rebase -i` do not support enough workflows. Here's some features I've implemented which improve on `git rebase` in general: https://github.com/arxanas/git-branchless/wiki/Command:-git-move#description https://github.com/arxanas/git-branchless/wiki/Command:-git-...
indymike 4y ago
> The Git version control system has been causing us misery for 15+ years. Not having git and using most other VCS (fossil and mercury are pretty good, too) creates way more misery. > No one bothers to consider: what are the workflows that people actually want to do? Well, here is where the problem is. Git has some fantastic workflow features that most people don't learn or use (https://git-scm.com/book/en/v2/Customizing-Git-Git-Hooks https://git-scm.com/book/en/v2/Customizing-Git-Git-Hooks). Workflow is also problematic because it is exactly where people will demand a wheel, except for more round, every time. So... how could it be better? Abstract it away to the os and filesystem so it is just part of the routine. Having full support for versioning everywhere would help because many of the rough edges with git are caused by having to support multiple OSes. A lot of confusion is that you have to use git's own tools or do an add/commit cycle for what should just be os file commands. These issues exist because git is not an OS level tool. Imagine commands like find or grep can return the file and version... imagine being able to just mv \dir;crusty-branch \new-dir and it just works. Back in the day, VMS did primitive versioning and it was quite nice (ie \dir\myfile.txt;22 where 22 was the version). Adding versioning like this also would encourage vendors to have sane file formats, so they could be versioned by the OS and pick up almost free change history features. Slapping a UI on git isn't all that helpful - many, many users just use git from the ide or command line, anyway. As far as workflow goes, the author has a point that git does not come with a lot of strong opinions or obvious ways to do things out of the box.
fedeb95 4y ago
The best git UI is git from command line. There are edge cases when additional tooling on top of git will screw you up because it makes assumptions on what you want to do. I want to avoid those edges.
- deleted 4y ago
  [deleted]
pjmlp 4y ago
I just keep using TortoiseGit alongside the Java and .NET IDEs support for git. Anything beyond the basic stuff gets a refresh clone and that's about it.
xixixao 4y ago
Not that it’s helpful, but Mercurial does have pretty much all the features OP is asking for…
- culebron21 4y ago
  Amen. When I finally had to switch to git, workflow with VCS became misery, exactly as the author suggests. It's mostly googling to Stackoverflow answers for simple operations, and being unable to memorize all those ten CLI options that you must type. Sadly, Mercurial has been dropped from Bitbucket in recent years.
- Shish2k 4y ago
  Sapling has basically combined Mercurial’s UI/UX, and added several more nice features on top, and added Git as a backend (ie, you can use sapling to seamlessly contribute to git projects) - https://sapling-scm.com/ https://sapling-scm.com/
dasil003 4y ago
I get where the author is coming from, but personally I feel like the juice isn't worth the squeeze. The thing about git is that it is incredibly powerful, and the model is very simple and well thought out. The only problem is the CLI is full of warts. That sucks for beginners, but once you get over the hump, git is like a chef's knife—you can do anything with it, quickly and efficiently. So any layers you build on it will, at best, make it easier to learn, but they won't make it more powerful. On the downside, making a legible UI will require some opinionated decisions about what to emphasize and what to de-emphasize (sort of like how Mercurial is designed in a way that discourages rebasing). As to the specific suggestions, some of them are very poorly thought out. For instance, the proposal for `git reword` suggests you shouldn't need to have the commit checked out since it won't create a merge conflict. Sure, but the SHA will change, and this will change all downstream commits, which means you could potentially be triggering a massive, silent rebase that will blow up spectacularly when you try to push. Another one is the `git preview`, saying you should be able to predict the conflicts on a rebase. But this is exactly what rebase does already! You start rebasing, then you get a conflict, at that point you can either fix it and proceed or abort the rebase being no worse for wear. Obviously you can't see the subsequent conflicts until you resolve the first, so there's no magic "see all downstream conflicts for the entire operation" possible (if that's what the OA meant, I'm not sure). Finally, the `git undo` is just a hand-wavy ask for the functionality provided by `git reset`. Combined with `git reflog` you can undo arbitrary operations including ones that you had abandoned and "overwritten". It's an incredibly simple and powerful model. I get that the `git reset` flags are not super intuitive, but they are few, terse, and domain complete.
- arxanas 4y ago
  On the contrary: I myself have implemented these better operations, and they work great. They also exist in some other VCSes, such as Mercurial and Jujutsu. You can see the `git-branchless` column in the table for comparison with the other clients. - git reword: https://github.com/arxanas/git-branchless/wiki/Command:-git-reword https://github.com/arxanas/git-branchless/wiki/Command:-git-... - git move will perform the magic "see all downstream conflicts", but unfortunately will only show you the number of conflicting files, at present: https://github.com/arxanas/git-branchless/wiki/Command:-git-move https://github.com/arxanas/git-branchless/wiki/Command:-git-... - You cannot undo arbitrary operations with the reflog (nor with `git reset`). See https://github.com/arxanas/git-branchless/wiki/Architecture#comparison-with-the-reflog https://github.com/arxanas/git-branchless/wiki/Architecture#.... Besides those points, my `git undo` can even undo some working copy changes: https://github.com/arxanas/git-branchless/wiki/Command:-git-undo https://github.com/arxanas/git-branchless/wiki/Command:-git-...
tylerjl 4y ago
Apologies if this is only tangentially related, but it's a thought I've often had: When I went through my university degree (which, admittedly, was over a decade ago), the skills and/or training for the day-to-day tools of software engineering - like git - were nearly never taught in a dedicated way in the same approach as concepts like data structures or algorithms. With degree in-hand the average graduate would probably be more comfortable reversing a linked list or estimating the O(n) of an algorithm than performing a git rebase. Yes, the latter is technology-specific rather than a generalized CS principle, but I would have to imagine that some capstone-type work would really spend time properly training a white-collar worker deeply on a standard few industry tools. I'm not saying that the author is wrong, because git is indeed deviously inscrutable at times. However, after my twelfth or thirteenth failed merge or rebase, I really _dedicated_ some time to figure out what the hell git was doing from the ground up - which wasn't easy or quick - but I haven't felt truly mystified and incandescently angry at git since. It probably isn't fair to expect every Joe Software Engineer to spend that kind of time on each tool they're expected to use (I'm a masochist and enjoy doing it) but it bums me out to run into the occasional software engineer who never had the opportunity to engage in deep learning and/or practice about their closest tools like a nurse with an ultrasound machine or a court reporter with a stenotype. In a more perfect world a well-rounded software engineering education program would give people space for that, but we're left with "squeezing it in-between sprints" or "on weekends" because it's hard to imagine a company granting people ample time for professional development that doesn't transparently inflate OKRs. Maybe my anecdote is out-of-date now and the situation is better, but I do still feel like most of us have had that "coworker had to blow away their local repo because git became too tangled" experience in recent memory. I also sort of assume that, in a paradoxical kind of way, code bootcamps may do this type of thing better, but I don't have that experience to draw from.
- deleted 4y ago
  [deleted]
- epolanski 4y ago
  You have several debatable ideas. 1) thinking university degrees are meant to prepare you for jobs. This is not why higher education institutions like universities came to be centuries ago. Universities are about sharing knowledge and researching. I would even debate 99% of jobs requiring a degree don't really, software development being one of those. Hell, one of the most important and famous chief surgeons in Italy, with various high impact papers. Was found to never have even started a medical degree. 2) Of all the degrees, I would safely say, SE and even CS are among those closer to day-to-day tools at work. 3) Extracting your experience and assuming it to be similar to those in other colleges, years, countries.
jrmg 4y ago
One feature I would’ve given a lot for when recently working with a large team on a big project: Sometimes, it’s not obvious that a thing that’s made it to the main branch (whether committed or merged) is problematic until a while afterwards. In that case, later commits/merges may have been made that mean the problematic one cannot be cleanly reverted (conflicts, whether by accident or because it’s been deliberately built upon). What I want to be able to do is to revert a commit _and any later commit that depends on it_ - or at least be able to see a graph that shows the dependencies to make a risk/reward trade off between reverting it all and trying to fix the problem manually. This is definitely something it’s possible to do - I’ve done it by hand too many times!
- WastingMyTime89 4y ago
  You are describing "rebase -i". Just don’t pick the commit you want to revert and Git will replay the following ones one by one stopping when there is an issue.
  - jrmg 4y ago
    That’s a whole extra layer of tedium above what I’d like to see. I just want a single command that will do all the reverts cleanly, and the option to list the necessary reverts instead of doing them.
    - WastingMyTime89 4y ago
      > I just want a single command that will do all the reverts cleanly Well, "rebase -i" will do that if it can be done but that’s unlikely unless your commits have nothing in common. As changes will be necessary to adapt the code to the removal, it’s kind of hard to tell from the start what will be affected. Things might have knock on effects. It’s funny because I don’t really like Git but this is one of the case where what it does seem to be the best doable considering the actual complexity of the issue. If you just want to see what will be reverted you can do a three way diff between HEAD, the commit to revert and the commit you intend to revert to btw.
tkuraku 4y ago
Sublime merge is fantastic. Does everything I need. Fast and cross platform.
Shish2k 4y ago
Sapling seems to have most of these: reword: sl metaedit <commit> sync: sl pull && sl rebase -s 'draft()' -d main split: sl split preview: not that I’m aware of, though I’ve never looked for it undo: sl undo large-load / large-ops: yeah, it was designed for FAANG monorepo-scale Additionally, some other features that sapling has that I wish git had: smartlog: Show the state of all my branches off of the master branch, what commits there are, whether they are passing the CI test suite, and whether they’ve been code reviewed: https://sapling-scm.com/docs/overview/smartlog#super-smartlog https://sapling-scm.com/docs/overview/smartlog#super-smartlo... absorb: when you’ve got one commit eg adding a new method, and another commit making use of that method, and you then tweak both bits of code, “absorb” automatically merges your add-method tweaks into the add-method commit and the use-method tweaks into the use-method commit
- eclark 4y ago
  And it includes a ui to make stacked diff reviews better. If only github lands played better I would be done. I’m looking forward to the planned server and sparse options being brought inline with what the internal tools were.
bloopernova 4y ago
Git always seems to be explained terribly, and I wonder why that is. To me it feels straightforward now but I graduated the route of rcs->cvs->svn->git. I think people get tripped up by the multiple layers there are between remote and local repositories. Remote->fetch->pull brings data to you. Save->add->commit->push sends it back. Then there's branches to add another layer of safety. Git being difficult is a "hilarious" meme just like exiting Vim, or writing c++. Unfortunately people hear that and have given up trying to understand it before they've even tried.
- deleted 4y ago
  [deleted]
alkonaut 4y ago
Rewording “too easily” would inevitably lead to someone accidentally rewording a commit on a shared branch (such as main/master). What I want in a git gui is first and foremost the fundamentals of my workflow built into the tool. What patterns for branch names means they are private? Or short lived? Or forked but never merged back? This should control e.g how a graph is drawn (you don’t bend the main branch etc) or how branch pruning is done. If I push a feature branch, later it’s merged on a server using a as squash commit and deleted remotely, then there is no way to say it should be deleted locally because there is no merge commit. This means something is missing. Either the knowledge of deleted branches should be communicated. Or the record that the branch was pushed to the central repo but is since deleted there must be saved. And this requires also specifying clearly that a remote is the source of truth. Git just doesn’t care. The remote list is basically a map of names to urls. No name is more special than another, just like no branch names are really special. And while flexible, it’s also extremely limiting.
Zigurd 4y ago
Some of the commenters here get hung up on whether git needs undo when nearly all git operations are undo-able. That's just one aspect of the problem: - It is evidently difficult for git GUI front ends to implement truly general purpose undo/redo the way any users expect any other GUI to have. This makes discoverability hard, maybe impossible, with a GUI front end to git. - Not all git operations map to the "generic operations on a selection" model most GUI software implements. There is no general "do this to that." - You can create a visualization of a git repo, but that visualization doesn't do a lot for a GUI, because of the lack of a selection or focus. It all still has to be coordinated in the user's brain, which is why most people end up just having to develop a deep understanding of the git command line. GUIs do not take away much, if any, cognitive load. Imagine having to know how a text editor manipulates the structures representing a document. It's hard to think of another design domain that is so intractable for GUI interfaces.
ComputerGuru 4y ago
True undo is possible via my all-time favorite hack, `git reflog`.
- arxanas 4y ago
  It is not! See https://github.com/arxanas/git-branchless/wiki/Architecture#comparison-with-the-reflog https://github.com/arxanas/git-branchless/wiki/Architecture#...
  - ComputerGuru 4y ago
    Awesome work and great job writing and collecting resources. I spent a lot of time going through your docs and references.
bobleeswagger 4y ago
Whew this thread is rife with elitism. About git? To the folks sharing your difficulties with git, bravo. To everyone who says they "don't get" how people could be confused or lost while using git, you are the reason why those folks are lost, and you're perpetuating the culture of elitism by playing dumb. Git is hard as shit to understand unless you came from development before it existed, or you have had the luxury of trying other VCS professionally. Most people just know git, and it's confusing as hell if you have no reference. Don't even get me started with how this has poisoned the industry on the whole: Proper VCS implementations with CI/CD are incredibly rare, even at places with world class engineering talent.
- notdonspaulding 4y ago
  My hypothesis about git apologists is that they fall into one of 2 groups: 1. People who have an organizational development model and workflow which is equivalent in complexity to the Linux kernel development model and workflow (i.e. thousands of developers loosely coordinating the release of systems or mission-critical software on a regular cadence). For them git fits their needs better than almost anything else, and it makes sense because it was made for exactly that use case. 2. People who learned their first VCS after Github had reached critical mass and if you had to pick one VCS to start with, you picked git by default. For them their brain fits git, and they think "the git way" is synonymous with "the right way". Many folks in group 2 never stop to realize that they are on a development team of 5 (or 50, or 500)...and they always cut their release from `master`...and all of their branches are always pushed/pulled from the same Gitlab remote...and within 5 minutes they can chat with anyone who's made a commit in the last 2 years. I don't take issue with group 1 people who understand the git model and love it and adopt it in their workflow because they need its complexity and they're willing to pay the UX tax to get it. I take issue with the folks who don't understand the git model or realize they don't need any of the complexity and aren't aware of the existence of solutions like fossil and mercurial.
perryizgr8 4y ago
Someone should build a chatgpt type of tool that resolves merge commits. It should be able to read commit messages, and both parent trees, and just merge both cleanly. Train it on github. Just credit me on your website ;)
krupan 4y ago
PSA: magit does more than this post gives it credit for
SergeAx 4y ago
> Rewording a commit is guaranteed to not cause a merge conflict Except when the commit is already synced to another instance of this repo.
- arxanas 4y ago
  Sorry, my wording was imprecise, see my comment here https://news.ycombinator.com/item?id=34301971 https://news.ycombinator.com/item?id=34301971
hoseja 4y ago
Why is there so much whiny moaning about git.
diceduckmonk 4y ago
Does anyone have a set of shell aliases for more common Git workflows? It would at least smooth out some of the idiosyncrasies and memorization (need to Google search) associated with the CLI.
brunobrito 4y ago
Thanks for posting this interesting article. I work at Tower (Git client for Mac and Windows) so I feel compelled to chime in! :) Becoming more productive with Git is one of our main goals, and I'm happy to state that most of the operations you address are already included in Tower (apart from "sync", which we will think about internally). As for the others you mentioned: reword - you can edit any commit message from the currently checked out branch by right-clicking the intended commit and selecting "Edit Commit Message" Example: https://imgur.com/a/kexC8uW https://imgur.com/a/kexC8uW split - you can edit any commit from the currently checked out branch by right-clicking the intended commit and selecting "Edit Commit". You will then be able to reform that revision into one or more new commits. Example: https://imgur.com/a/NFkT4nS https://imgur.com/a/NFkT4nS preview - Tower offers an "Instant Conflict Detection" feature that will let you know in advance if conflicts will occur when merging another branch or revision (by merging, rebasing, or pulling). Our latest major update was focused heavily on creating a better merge experience and you can also see the number of unresolved conflicts that you still need to resolve (with a progress bar being shown in case of a rebase). If you mess things up, you can also undo the latest operation or abort the Merge/Rebase operation altogether. Example: https://imgur.com/a/VCkqrBI https://imgur.com/a/VCkqrBI You can learn more about Tower's Merge Improvements here https://www.git-tower.com/blog/tower-mac-9/#1-merge-improvements https://www.git-tower.com/blog/tower-mac-9/#1-merge-improvem... undo - you can undo pretty much any operation with CMD+Z (or CTRL+Z on Windows). This includes not only commits, branch creation/deletion but also more complex operations like merges, rebases, and even file discards (which is not something Git actually supports). You can learn more about Tower's Undo here https://www.git-tower.com/features/undo/ https://www.git-tower.com/features/undo/ large-load - Tower works well with large repos. We do build caches on first run, so the initial run might indeed take longer to display very large sets of data (e.g. 10k+ tags). large-ops - We designed Tower from the ground up to remain responsive when doing any kind of operation. All commands run asynchronously, so you can e.g. push a branch and immediately checkout another branch simultaneously. I hope you give Tower a try in the near future — feel free to get in touch with us if some other question pops up.
rusebor 4y ago
many say that git has an intuitive/concise data model. But it seems that even git team itself has not quite got it. Looking at one of the latest changes [1] in which a _new_ merge strategy (ort) was introduced and made default one can ask how is it possible that so fundamental change happened 15 years after git was created? Maybe the model is not so simple as it wants to seem. [1] https://github.blog/changelog/2022-09-12-merge-commits-now-created-using-the-merge-ort-strategy/ https://github.blog/changelog/2022-09-12-merge-commits-now-c...

161 points by arxanas 4y ago

I often use Sublime Merge to reword commits (edit commit message, even other branches, the entire log is visible), or to split up commits (it undoes the commit and you get everything in the working directory), so I’m not sure if his comparison table is entirely correct. (At least from a user point of view I can easily edit or reword). One other nice feature of Sublime Merge is the squashing of two commits, ignoring the latters message (as a fixup). Not sure how to do that in one click or command with cli git…

arxanas 4y ago
Can you reword/split commits without having them checked out, or without touching the working directory? That’s what these criteria are about, and from your description, it doesn’t sound like you can do those directly in Sublime Merge.
- kemayo 4y ago
  You can only edit any commit that's reachable from the current HEAD without checking it out. I.e. a commit that's in a branch that's not merged back into wherever you currently are can't be edited. (I made a test repo to check this, because it had actually never come up before in my day-to-day usage.)
  - arxanas 4y ago
    Thanks for pointing this out. I confirmed that you can reword a commit without checking it out, with the caveats: - It has to be an ancestor of `HEAD`, like you said. - Doing so doesn't invoke Git's `post-rewrite` hook, which can cause interoperability issues with other tools :( - Doing so will abandon at least some descendant branches (possibly all descendant branches which aren't checked out, or possibly just those which branch aren't ancestors of `HEAD`). - Doing so doesn't seem to be undoable inside Sublime Merge via the undo command.

rcme 4y ago

> Rewording a commit is guaranteed to not cause a merge conflict, so requiring that the commit be checked out is unnecessary What if someone else rewords the same commit?

afiori 4y ago
That will be resolved during a merge/rebase and only if you are editing an already pushed commit. Overall git does use the filesystem in a lot of cases when it is not needed.
arxanas 4y ago
Ah, I should have been more precise. If you were to reword a commit in the equivalent manner as `git rebase -i`, which is to say, reapplying any descendant commits/patches, you would be guaranteed not to get conflicts while applying descendant commits. I suppose there is some possibility for merge conflicts in a workflow where you reword a public commit, which changes the merge-base in an unfortunate way and causes conflicts to appear which wouldn't have otherwise. Primarily I meant the workflow where you reword local commits only. More enlightened version control systems like Mercurial can handle this better, such as via its "commit evolution" feature. If you then rebase on top of a reworded commit, the patches will apply the same, and you can resolve the so-called "divergence" by running `hg evolve`. (It's still possible to have un-automatically-remediable divergences, such as if two people reword the same public commit in different ways, but it handles the common case.)

samuelstros 4y ago

We are working on "the next git" that brings version control to the rest of the world. > No one bothers to consider: what are the workflows that people actually want to do? What are the features that would make those workflows easier? What a coincidence, I just created a document [0] that collects engineering and UX issues that we are running into with inlang (localization infrastructure built on git) [1]. Part of bringing version control to people outside of software engineering is fixing UX related issues. For example, your proposed `sync` command is interesting. Our observations lean towards some real-time collaboration workflow that could make `pull, push, sync` workflows redundant. Applications that benefit from version control like a next-gen Figma, Adobe Premiere, Excel, etc. require real-time collaboration. A question that I've been asking myself whether real-time collaboration in software engineering makes sense too. To be elaborated! :) [0] https://github.com/inlang/inlang/blob/main/content/git-sdk-notes.md https://github.com/inlang/inlang/blob/main/content/git-sdk-n... [1] https://github.com/inlang/inlang https://github.com/inlang/inlang

yrgulation 4y ago

Git is pretty easy to use but people tend to overcomplicate it. Just push changes to your branch. Merge when ready. And keep your branch up to date with your main branch. Easy.

nibbleshifter 4y ago
Personally 99% of the time I just push to master/main lol.
- yrgulation 4y ago
  [dead]
ilyt 4y ago
If you want to use DVCS as DVCS you gotta understand the details. People don't then get into trouble. But to be fair git will do exactly what you ask it to and not warn about some pitfalls and there is also no "tell me what this operation would do" so it's easy to get into nasty state if you just copy commands off internet.
epolanski 4y ago
this. Unless your company has a huge fixation with git history you really don't need to know much more than basics one can pick up with ease in what, few hours? I never rebase in my life, I just merge the target branch and call it a day, most companies only track merge commits anyway so history is the same.
- yrgulation 4y ago
  [dead]

zoul 4y ago

The Git version control system has been causing us misery for 15+ years. I think this is uncharitable at best. It was a huge step forward compared to then popular VCSs such as Subversion, I have loved working with Git since it was created and I still enjoy working with it every day.

arxanas 4y ago
Mercurial has been around for approximately the same length of time, and from a UX perspective, I find it to be much superior to Git, which was largely built in terms of "what is the easiest way to solve this problem from an implementation perspective", rather from the user's standpoint. Of course, Git won for a reason, but I doubt that it wouldn't have still won had it incorporated some UX design ideas from Mercurial or elsewhere. > I have loved working with Git since it was created and I still enjoy working with it every day. I have been profoundly frustrated by working with Git every day, hence the article, and the linked set of tools which I wrote to improve my workflow. Not even because its mental model is hard to grasp or that the UI is poor, but because it doesn't even streamline the kinds of workflows that it should be good at (in the article, and discussed in its own `gitworkflows` man page).
- Beltalowda 4y ago
  > Of course, Git won for a reason 1. Linus Torvalds wrote it 2. GitHub 3. Linus Torvalds wrote it To be fair, there are some real differences; e.g. there is no easy "hg rebase" by design, and whether that's a good or bad thing has been a topic of contention for about 15 years. But that Linus wrote it gave it a huge boost, and GitHub really was much better than many things that came before it (and arguably, still is).
  - murderfs 4y ago
    Having the kernel as an anchor customer definitely helped, but there's also the reason that Linus wrote git in the first place, and that's that every other competitor was horrendously slow by comparison.

alex_suzuki 4y ago

What I like about SourceTree is the ability to pick individual lines and „hunks“ to stage, as I often have changes and some debugging stuff sprinkled into some files (think printf). Since it‘s not explicitly mentioned, I assume this is a pretty standard feature? I wouldn’t mind switching away from SourceTree, it crashes often.

xtian 4y ago
Yes: `git add --patch`
okl 4y ago
Give `tig` a try.
eyegor 4y ago
The one built into vs2022 has this and works pretty well if you happen to use it already. I think vscode has many of these features but I haven't tried it there. Otherwise I'd say look at gitkraken (free for personal use I think) or sublime merge if you really want performance. Personally I use sublime merge or command line for everything. The sublime merge/text interactions are really nice, being able to right click in a diff and have it open the file at the line. You can try them for free forever but the price may be a deterrent since the dark theme for merge is locked behind a license key.
iza 4y ago
Indeed most git GUIs can do this. git-gui (built-in), VSCode, Sublime Merge, Git Extensions to name a few.
misnome 4y ago
You can do this on the terminal with `git add -p` but yes it’s always slightly more intuitive with a proper editor (I mainly use the many-times-forked GitX for this)
Lex-2008 4y ago
I used `git gui` for that (not sure how "native" to git is it, though), and recently switched to `gitg` for both looking at tree and committing individual lines. Can't compare them with SourceTree, though, since haven't used that. Also, when on command-line, I recently discovered `git add -i` for interactive mode (asks you about individual hunks and lets you "split" them), and `git add -e` (lets you edit the patch however you want).

mabbo 4y ago

Three things that I feel are true about git's model: 1- the model is not intuitive to beginners. There's a really tough learning curve. 2- the model is powerful but leads to a few specific workflow. If you don't have the same mental model and don't want to use those workflows, you will have the "misery" the author describes. Otherwise, you'll be perfectly fine. 3- no one has yet to do a great job of describing that model and workflow visually. The author's "features from the future" feel to me like they just haven't gotten a good feel for the model. That's why they are miserable. That's partially because git's model is hard to learn, and partially because after all this time they still haven't taken an hour to deeply learn it.

timhh 4y ago
I disagree. The model is intuitive. It's just that Git dresses it up in confusing language, a terrible CLI and a gazillion half baked GUIs. It doesn't help that lots of people recommend not using a GUI which is terrible advice for learning. Btw I would recommend GitExtensions for learning Git. It has the most intuitive interface I've found. For example it lets you browse the files at each commit which really shows how commits are snapshots, not diffs.
- goku12 4y ago
  Git model is intuitive until you have to deal with merge conflicts, rebasing etc. Are you judging with that experience? > For example it lets you browse the files at each commit which really shows how commits are snapshots, not diffs. This is exactly the problem I mentioned. For one, each commit is a snapshot in the sense that it shows us a snapshot. Internally, it's a bunch of hashed and interlinked files. Git only collects them to show us a snapshot. But you probably knew this already. The real confusing part comes when you have to amend a commit, merge branches, interactive rebases, etc. The changes between the commits are propagated as patches. Even the merge algorithm uses a 3-way diff. Rebases is all about diffing and patching behind the scene. Thinking that these are snapshot operations will make the operation much more hard to imagine and predict. You should know when to use snapshot model and when to use diff-patch model in Git. This part is also rarely mentioned in Git tutorials or tools (stgit on the other hand, exposes this diff-patch idea very well)

seanalltogether 4y ago

I would like a ui that can show me what conflicts are about to happen before I do a merge or rebase. Trying to resolve a conflict after it's already happened is much harder then if I knew what files and lines are about to blow up on me. Even better start warning me about which files I've been editing are going to conflict with origin once I eventually have to sync up

Izkata 4y ago
Merge and rebase both have "--abort", which undoes the change if you're in the middle of a conflict.
- seanalltogether 4y ago
  To be clear, I'd like to see the future conflict while my files remain in a clean state, so that I reconsider my own changes or work around the conflict before it happens
  - krupan 4y ago
    After you do --abort you are back in time before the conflict happened. This is literally what you are asking for
okl 4y ago
You can abort a merge or rebase with `git merge --abort` and `git rebase --abort` respectively.
arxanas 4y ago
Yep, most tools are deficient in this area, as per the table. My linked git-branchless tool will tell you before a merge conflict occurs, so that you don't have to abort it, although it could produce more information about the impending merge conflict.
aequitas 4y ago
This is one of those cases where the solution seems difficult, but the difficulty is in the problem itself, not the solution. The source of the conflicts is the fact that you work with multiple people, in a distributed way on the same codebase. Those conflicts are going to arise one way or another. Git could tell them to you beforehand, but that would be just the same as rebasing and then aborting. The conflicts stay the same, no matter how you slice them. In my experience best is to coordinate with other about code changes to avoid conflicts altogether or to fetch and rebase often to keep conflict scope to a minimum so they are more manageable. Also keeping commits focussed on single features/changes instead of spreading out the feature over multiple work in progress like commits so they can be applied as a standalone change helps. I really learned this when working in Gerrit Review for a while. Where there is no one pull request for a branch full of commits, but each commit is a change applied to master on its own and has to be reviewed/tested as such. Git is not a magical tool that solves all collaborative coding problems, but more a toolset that helps you manages code changes. You definitely need to put some effort into the mental model of how to manage changes before you can use the toolkit to its full potential.

CSSer 4y ago

You’d think that Microsoft and Github would have a monopoly on this given their personal contributions to Git, ownership of Visual Studio Code, and ownership of the largest Git hosting PaaS. Don’t get me wrong, VS Code and Github are both okay. I use them both and drop into the integrated terminal for situations where my muscle memory is faster or the workflow is going to be more complex. I also find that setting VS Code to my default editor for Git makes this pretty seamless. Anyway, I find it interesting that there doesn’t seem to be a big focus on the sort of features the author mentioned in VS Code. Now that I think of it, this is also one of those few circumstances where I don’t need or want the tool to be modular. VCS are such a fixture today that I just expect this to be built into the IDE’s GUI. A separate app, even with perfect workflows, may be just as much of a bother as a terminal. After all, what’s stopping me from writing a handful of clever aliases?

heywhatupboys 4y ago
are you unironically wishing MS would EEE git? lol
DangitBobby 4y ago
The only passable git GUI IMO is the one built into Jetbrains IDEs. VSCode makes only the very most basic workflows simpler (doing a commit) so I use that as well on the rare occasion I'm using VSCode. For every other git GUI, I'd rather just stick to CLI.

vouaobrasil 4y ago

I've used Subversion, Git, Mercurial and a few others to test them out....honestly although Git is better than Subversion, I like Git the least and I've been using it for about 6 years. I don't like its interface, weird command names like remote add origin, fetch/pull/clone, clean -nx, arg. It's a very frustrating piece of software whose commands seem more reflective of it's design rather than what it was designed to do.

deleted 4y ago
[deleted]
epolanski 4y ago
Would be interested in reading a thorough analysis.

timhh 4y ago

> It should be possible to sync all of my branches (or some subset) via merge or rebase, in a single operation. Not sure if this is exactly what the author is looking for but I made Autorebase exactly for this. https://github.com/Timmmm/autorebase https://github.com/Timmmm/autorebase Great article btw. A lot of those things are way harder than they should be.

epage 4y ago
Also git-stack has a --pull flag to rebase all local branches and --push to force-push-with-lease them. EDIT: oh, article author is git-branchless author, they know of git-stack.

helloguillecl 4y ago

The CLI interface of git is very good at enforcing you to be aware of the underlying model (local state and the repo’s history). This allows for the user to draw an accurate user-model in his understanding of the system. Adding an “undo” command would be convenient, but it would hide the underlying potential away. This is something that should belong to a GUI client, and I still would want to know what is it actually doing. Instead of hiding the abstractions behind a “friendlier” CLI, Git shows you its real power and that of VCSs in general, by having a lower-level API. Not even the multiple GUIs built on top of Git, adventure themselves into hiding or dumbing down the abstractions that allow you to do quite complex things with the code and its history.

arxanas 4y ago
Git can have a powerful API and also support higher-level workflows; it just doesn't. > Adding an “undo” command would be convenient, but it would hide the underlying potential away. It would not hide any underlying potential away; see https://blog.waleedkhan.name/git-undo/ https://blog.waleedkhan.name/git-undo/ for a general-purpose CLI implementation.
WastingMyTime89 4y ago
> Instead of hiding the abstractions behind a “friendlier” CLI, Git shows you its real power and that of VCSs in general, by having a lower-level API. But that’s simply not true. Git is just inconsistent in how it does things. Sometimes it wants you to deal with its inner state (typically the undo where you just need to move HEAD to a previous commit which might be only visible in the reflog). Sometimes it introduces complex concepts which would be simpler if they were just exposed for what they are (stashes are just temporary commits). Honestly Git is a mess. It works but the UX has always been awful.
klabb3 4y ago
> The CLI interface of git is very good at enforcing you to be aware of the underlying model (local state and the repo’s history). Awareness of state is sometimes important, sometimes you just need awareness of operations. And awareness of git's data structure does not necessarily map 1:1 with understanding the state of the code base. Not saying you’re wrong, just saying that this may or may not be a good thing. I’m personally leaning towards this could be improved. Really good advanced tools should work well for common use cases, so you can master it incrementally. Git is extremely frictionous for certain simple tasks, which is evident if you look at stack overflow. If a user wants to do something very simple in human terms (like fix a typo), and you get a lecture about merkle trees and reflogs, then I think there is room for improvement. The truly important question though, is whether the UI can be improved enough without changing the data model (ie can replace the UI without replacing your repos).

fxtentacle 4y ago

> as if Git’s command-line interface were already the pinnacle of usability. It is, for me. I love git and checking in my progress in small chunks that make sense to me is very easy with the command line tools. They're also easy to integrate and automated. Maybe they truly are the pinnacle of usability? As another example, compare cashiers using one of those DOS GUIs with modern ones using touch screens. The simpler GUI works much faster, once mastered.

stephen_g 4y ago
Yeah, I’ve never had a problem with it. I mean, sure it’s not perfect but I really don’t get all the hate.
- CivBase 4y ago
  I think the hate comes from it not being very "noob friendly". It's designed for power users who are familiar with how git works. In my experience, most git users don't really know how git works fundamentally. They just learn the commands for a particular workflow and stick to that. That's how I started. I've seen this to be especially true for developers coming from SVN or another centralized versioning system.
howinteresting 4y ago
A very basic issue with git is that if you're editing a stack of commits, you can't go back to an earlier commit without completing the rebase -i and restarting it.
- cryptonector 4y ago
  Not quite true. You can add `exec git branch progressN HEAD` every so often in the `git rebase -i` script, or you can `edit` commits and before `git rebase --continue` do `git branch progressN HEAD`, then later if you need to abort and restart your rebase you can rebase --onto one of those saved HEADs.

samgranieri 4y ago

I highly recommend using Tower. Yes, it’s a paid app with a yearly subscription fee, but it’s worth it. I really enjoy using the rebase functionality to reword, split, and reorder commits. I also know how to do this on the command line, but sometimes I enjoy using a gui on macOS.

arxanas 4y ago
Can you specify which of the features in the table from the article it provides? If so, I can update the article. The last time I used Tower, I was not impressed, for the same reasons as the other Git UI tools in the table which try to offer simar features.
- dhritzkiv 4y ago
  I would say that while Tower can't achieve the specific features to the specifications defined in the article (as I understand them), its main advantage is how stable, predictable, and at-home it feels on macOS, which cannot be said of /any/ of the other GUI clients (where applicable, on macOS). It's responsive, commands finish as expected, and I can also perform many operations with a drag and drop or via the context menu. This predictability lends a lot of confidence to me achieving my work, and I feel others feel the same. As for the features, it: - supports `undo` of arbitrary operations quite well. - has a dedicated `reword` (as "edit commit message") command/flow (but will ask if you want to stash your current working copy, with the option to automatically re-apply the stash) - `split` kind of works by entering a "edit a commit" flow, which lets you stage and commit multiple times. In short, editing a single commit can generate one or more commits. - `large-ops` and `large-load`: I've never noticed the GUI becoming unresponsive, but it's possible none of the repos I've checked out are large enough. Note: Tower on Windows feels out place on Windows/ doesn't work as well as on Mac, but is still a formidable git GUI.
  - brunobrito 4y ago
    Thank you for mentioning Tower! I would just like to add that Tower 9 also included many improvements around the merge/rebase experience, including an Instant Conflict Detection that should satisfy the "preview" workflow mentioned. Here's an example: https://imgur.com/a/VCkqrBI https://imgur.com/a/VCkqrBI More info here: https://www.git-tower.com/blog/tower-mac-9/#1-merge-improvements https://www.git-tower.com/blog/tower-mac-9/#1-merge-improvem...

vanjajaja1 4y ago

Would love a git/PR workflow that was aware that I work on the next feature (or two) while the previous PR is being deliberated. I need a pipeline system where I decouple “do code” and “negotiate merge upstream”. Managing this manually is a pain, especially over multiple connected repos.

nektro 4y ago
if this is something you're doing very often i believe https://git-scm.com/docs/git-worktree https://git-scm.com/docs/git-worktree is the intended solution
- vanjajaja1 4y ago
  thanks, I'll have a play with this see if it helps

efortis 4y ago

IntelliJ's git UI has those features.

arxanas 4y ago
I have used IntelliJ's Git UI and never noticed it having those features as described in the article (such as reword without checking out or merge conflict previews). Can you show me where to find those features?
- efortis 4y ago
  Reword: https://www.jetbrains.com/help/idea/edit-project-history.html https://www.jetbrains.com/help/idea/edit-project-history.htm... Resolve Merge Conflicts: https://www.jetbrains.com/help/idea/resolve-conflicts.html https://www.jetbrains.com/help/idea/resolve-conflicts.html
  - arxanas 4y ago
    If I'm reading this correctly, you cannot reword a commit without first checking it out, and you cannot preview merge conflicts without first starting a merge/rebase operation? Those are the criteria as described at https://blog.waleedkhan.name/git-ui-features/#rubric https://blog.waleedkhan.name/git-ui-features/#rubric
    - david_allison 4y ago
      Reword: you don't need to check out the commit. The 'log' tab shows a tree of the commits to the repo. This log can be filtered in multiple ways: for example by branch or via a search string. You may right click a commit to reword.
      - arxanas 4y ago
        Thanks. I confirmed that you can reword a commit which is reachable from `HEAD`, but not those on other branches in this way, similar to Sublime Merge elsewhere in the comments.

jobstijl 4y ago

I'm still hoping https://pijul.org/ https://pijul.org/ usage will grow.

goku12 4y ago
Pijul is superb. I do use it. But my wish is that they release 1.0 ASAP. Long time in beta for a code management tool isn't too healthy for it.
- pmeunier 4y ago
  From your usage, do you feel it's 1.0-quality?
  - goku12 4y ago
    In my opinion, you should certainly go for 1.0, unless you are planning some breaking changes at this point - which I guess you are not, after reaching beta. My general deduction is that tools with a few bugs at an early 1.0 has a better chance of succeeding than tools that stay too long in beta. It's important to ensure that interest from users, distro packagers and commercial adopters are kept alive while waiting on 1.0. I'm still waiting for pijul to be in the distro repos, though the crates version work satisfactorily. This may turn away many other potential users. Alphas and betas should be time-limited, not bugs-limited. Bugs are what patch versions in semantic versioning are for. Remember: 1.0 is a magic number - it increases the exposure of your tool and potential contributors by a large factor. By your standards, git would have stayed in pre-1.0 for a decade and would not have become this popular. On a personal level, I use pijul for managing my dotfiles. I haven't encountered any bugs yet. The only feature I miss from git is the availability of tools like syntax highlighters for diff and record and UIs like tig, gitui and magit. But again, those are just features you could add as minor versions. That aside, pijul feels like magic. A handful of pijul commands cover most of the use-cases of git. After using git for so long, I always wonder if I'm using pijul the wrong way, even though I get the expected result. I'm only familiar with svn, git, bzr and hg. Perhaps Darcs would have given a better idea about what pijul really is.

plusminusplus 4y ago

Thanks for doing the research, there's so many git GUIs it saved me a lot of time. Limitations of these GUIs leave you in a limbo switching between them and the CLI. The "git sucks" heading might turn off readers; there are so many "git sucks" articles with less nuance and research than this one. (Notice most of the comments already are just related to that, or git in general.)

arxanas 4y ago
> The "git sucks" heading might turn off readers that have otherwise have been interested Thanks for the feedback. Do you have a better idea for the heading name? > Notice most of the comments already are just related to that, or git in general. After having read the comments for many Git-related articles, and having posted a few of my own, I can tell you that this would have happened regardless of how well the article was written :)
- pvg 4y ago
  I don't think it would have been as bad without the provocative title and subheds. They effectively hide the work you've done and provide handy hooks on which commenters will eagerly hang their generic tangents. This is a pretty lousy aspect of HN and I don't think it's any kind of indication the article is somehow not well written. But I think you underestimate how much these initial conditions affect the quality of discussion.
- cryptonector 4y ago
  "Git sucks for me" Git definitely does not suck for me.

franky47 4y ago

I only properly understood rebasing when I started using Ungit [1], visually seeing commits being replayed on the base branch makes it much more intuitive. Another was treating branches as "labels", that can be advanced to a more recent linear commit timeline. Very useful for a production branch following the main dev branch (essentially electing commits as production-ready). [1] https://github.com/FredrikNoren/ungit https://github.com/FredrikNoren/ungit

FairDune 4y ago
Thanks for the suggestion.

t00 4y ago

SmartGit have not received credit it deservers, sure there are hi quirks like showing unstaged file tree, but workflow with git made me switch to it from GitKraken, GitExtensiona and others. I would call the benchmark article rather subjective due to limited amount of comparable features and excluding most frequent workflow components with a respective ease of use score.

arxanas 4y ago
It is very much subjective!

wdfx 4y ago

I don't really understand how SmartGit failed you? In your table of results it covers at least as many features as the others. I call this out because I have been using SmartGit as my only git gui now for about 10 years and I think it does a grand job. It doesn't hide any information about the repo and makes just about any operation pretty straightforward. I also find it's built in diff and merge tools better than others. It also performs well enough and had been super stable. (I am not affiliated with SmartGit, just a happy customer).

wdfx 4y ago
Re-reading the article and I see that your table headers are misaligned. I see you did mark SmartGit negatively in every category. It does support many of those features, so what gives? EDIT: retract harsh words
- arxanas 4y ago
  Apologies for the misalignment. I had difficulty formatting the table in a legible way. See my other comment re. the rubric.
arxanas 4y ago
SmartGit failed to provide for any of the workflows discusses in https://blog.waleedkhan.name/git-ui-features/#rubric https://blog.waleedkhan.name/git-ui-features/#rubric. Can you clarify which of these points was assessed wrongly, so that I can update them?
- wdfx 4y ago
  Ok I will end up agreeing with you, for the specific clauses where you require the operation be possible on any commit, even if its not part of the tree of HEAD. I guess I reacted strongly to the negative review because despite your assessment it is still an eminently usable tool and in all the time I've used it haven't needed it to do anything more than it does. As per my original comment though, I'd you haven't tried it's conflict resolution/merge tool I would recommend you do and perhaps you might be tempted to give it at least half a bonus point :)

foobarbecue 4y ago

> The Git version control system has been causing us misery for 15+ years I think git is pretty good. It was good enough to be the first VCS to really reach critical mass (before, I used RCS, CVS, SVN, and hg). It might not be the BEST vcs, but it's got everything I need and it's easy enough that I can teach non-technical people to use it and clean up after them when they find the footguns. And the cli has been shortly but surely improving. It has facilitated my collaborations for 15 years with very little misery.

chx 4y ago

Speaking of undo, I have built a safety against git reset long ago https://gist.github.com/chx/3a694c2a077451e3d446f85546bb9278 https://gist.github.com/chx/3a694c2a077451e3d446f85546bb9278 there are a few more useful commands as well. This has saved my bacon a few times.

goku12 4y ago

>I will award honorary negative points for any client which dares to treat git rebase -i as if it were a fundamental primitive. If you think that a git rebase is overcomplicated, rather than a fundamental primitive, then you missed an important part of the tool. And phrasing it this way is an insult to anyone who really tried to understand the tool - kind of like the nerd badge in schools. Git rebase is fundamental to Git in many ways. It is also easy in many ways. At the minimum, it makes it easy to make mistakes while experimenting much less of a hassle, since the commit chain can be cleaned up later. However, the point here is that git rebase is more similar to what the kernel developers and git developers intended to do with the tool, compared to the commit-merge workflow. There are two aspects here: 1. The tool developers want every commit to be feature-complete and that it won't cause broken builds at least in the master branch. This is impossible to achieve in the regular commit-merge workflow.You need to add the interactive rebases to achieve the goal. 2. Git hides something behind the snapshot model it claims to be based on. The commits themselves are snapshots. But the way changes are propagated between commits (like stashing, commit amending, merging, cherry-picking, rebasing, squashing, splitting, etc) depend on plain old text diffs/patches. It takes a while for beginners to realize this. The kernel devs were using emailed patches and tools like quilt patch manager for nearly a decade before they created git. You can still see the influence of diff, diff3, merge and quilt in the design of git. Knowing this makes you much better at predicting the outcome of these operations. Blaming the tool without trying these techniques is very uncharitable indeed. I've been learning Pijul these days. All those complicated operations are condensed into a small set of commands in pijul. For one, it concentrates on patches only. I feel that part of Git's complexity is its mixing up of snapshot and patch model into a single program. Git didn't have the luxury of these diff alogrithms back then.

arxanas 4y ago
Rebasing is a fundamental primitive, but not Git's implementation of interactive rebasing. I very much subscribe to a "patch-stack" workflow, but have a great deal of difficulty doing advanced things in Git, because `git rebase`/`git rebase -i` do not support enough workflows. Here's some features I've implemented which improve on `git rebase` in general: https://github.com/arxanas/git-branchless/wiki/Command:-git-move#description https://github.com/arxanas/git-branchless/wiki/Command:-git-...

indymike 4y ago

> The Git version control system has been causing us misery for 15+ years. Not having git and using most other VCS (fossil and mercury are pretty good, too) creates way more misery. > No one bothers to consider: what are the workflows that people actually want to do? Well, here is where the problem is. Git has some fantastic workflow features that most people don't learn or use (https://git-scm.com/book/en/v2/Customizing-Git-Git-Hooks https://git-scm.com/book/en/v2/Customizing-Git-Git-Hooks). Workflow is also problematic because it is exactly where people will demand a wheel, except for more round, every time. So... how could it be better? Abstract it away to the os and filesystem so it is just part of the routine. Having full support for versioning everywhere would help because many of the rough edges with git are caused by having to support multiple OSes. A lot of confusion is that you have to use git's own tools or do an add/commit cycle for what should just be os file commands. These issues exist because git is not an OS level tool. Imagine commands like find or grep can return the file and version... imagine being able to just mv \dir;crusty-branch \new-dir and it just works. Back in the day, VMS did primitive versioning and it was quite nice (ie \dir\myfile.txt;22 where 22 was the version). Adding versioning like this also would encourage vendors to have sane file formats, so they could be versioned by the OS and pick up almost free change history features. Slapping a UI on git isn't all that helpful - many, many users just use git from the ide or command line, anyway. As far as workflow goes, the author has a point that git does not come with a lot of strong opinions or obvious ways to do things out of the box.

fedeb95 4y ago

The best git UI is git from command line. There are edge cases when additional tooling on top of git will screw you up because it makes assumptions on what you want to do. I want to avoid those edges.

deleted 4y ago
[deleted]

pjmlp 4y ago

I just keep using TortoiseGit alongside the Java and .NET IDEs support for git. Anything beyond the basic stuff gets a refresh clone and that's about it.

xixixao 4y ago

Not that it’s helpful, but Mercurial does have pretty much all the features OP is asking for…

culebron21 4y ago
Amen. When I finally had to switch to git, workflow with VCS became misery, exactly as the author suggests. It's mostly googling to Stackoverflow answers for simple operations, and being unable to memorize all those ten CLI options that you must type. Sadly, Mercurial has been dropped from Bitbucket in recent years.
Shish2k 4y ago
Sapling has basically combined Mercurial’s UI/UX, and added several more nice features on top, and added Git as a backend (ie, you can use sapling to seamlessly contribute to git projects) - https://sapling-scm.com/ https://sapling-scm.com/

dasil003 4y ago

I get where the author is coming from, but personally I feel like the juice isn't worth the squeeze. The thing about git is that it is incredibly powerful, and the model is very simple and well thought out. The only problem is the CLI is full of warts. That sucks for beginners, but once you get over the hump, git is like a chef's knife—you can do anything with it, quickly and efficiently. So any layers you build on it will, at best, make it easier to learn, but they won't make it more powerful. On the downside, making a legible UI will require some opinionated decisions about what to emphasize and what to de-emphasize (sort of like how Mercurial is designed in a way that discourages rebasing). As to the specific suggestions, some of them are very poorly thought out. For instance, the proposal for `git reword` suggests you shouldn't need to have the commit checked out since it won't create a merge conflict. Sure, but the SHA will change, and this will change all downstream commits, which means you could potentially be triggering a massive, silent rebase that will blow up spectacularly when you try to push. Another one is the `git preview`, saying you should be able to predict the conflicts on a rebase. But this is exactly what rebase does already! You start rebasing, then you get a conflict, at that point you can either fix it and proceed or abort the rebase being no worse for wear. Obviously you can't see the subsequent conflicts until you resolve the first, so there's no magic "see all downstream conflicts for the entire operation" possible (if that's what the OA meant, I'm not sure). Finally, the `git undo` is just a hand-wavy ask for the functionality provided by `git reset`. Combined with `git reflog` you can undo arbitrary operations including ones that you had abandoned and "overwritten". It's an incredibly simple and powerful model. I get that the `git reset` flags are not super intuitive, but they are few, terse, and domain complete.

arxanas 4y ago
On the contrary: I myself have implemented these better operations, and they work great. They also exist in some other VCSes, such as Mercurial and Jujutsu. You can see the `git-branchless` column in the table for comparison with the other clients. - git reword: https://github.com/arxanas/git-branchless/wiki/Command:-git-reword https://github.com/arxanas/git-branchless/wiki/Command:-git-... - git move will perform the magic "see all downstream conflicts", but unfortunately will only show you the number of conflicting files, at present: https://github.com/arxanas/git-branchless/wiki/Command:-git-move https://github.com/arxanas/git-branchless/wiki/Command:-git-... - You cannot undo arbitrary operations with the reflog (nor with `git reset`). See https://github.com/arxanas/git-branchless/wiki/Architecture#comparison-with-the-reflog https://github.com/arxanas/git-branchless/wiki/Architecture#.... Besides those points, my `git undo` can even undo some working copy changes: https://github.com/arxanas/git-branchless/wiki/Command:-git-undo https://github.com/arxanas/git-branchless/wiki/Command:-git-...

tylerjl 4y ago

Apologies if this is only tangentially related, but it's a thought I've often had: When I went through my university degree (which, admittedly, was over a decade ago), the skills and/or training for the day-to-day tools of software engineering - like git - were nearly never taught in a dedicated way in the same approach as concepts like data structures or algorithms. With degree in-hand the average graduate would probably be more comfortable reversing a linked list or estimating the O(n) of an algorithm than performing a git rebase. Yes, the latter is technology-specific rather than a generalized CS principle, but I would have to imagine that some capstone-type work would really spend time properly training a white-collar worker deeply on a standard few industry tools. I'm not saying that the author is wrong, because git is indeed deviously inscrutable at times. However, after my twelfth or thirteenth failed merge or rebase, I really _dedicated_ some time to figure out what the hell git was doing from the ground up - which wasn't easy or quick - but I haven't felt truly mystified and incandescently angry at git since. It probably isn't fair to expect every Joe Software Engineer to spend that kind of time on each tool they're expected to use (I'm a masochist and enjoy doing it) but it bums me out to run into the occasional software engineer who never had the opportunity to engage in deep learning and/or practice about their closest tools like a nurse with an ultrasound machine or a court reporter with a stenotype. In a more perfect world a well-rounded software engineering education program would give people space for that, but we're left with "squeezing it in-between sprints" or "on weekends" because it's hard to imagine a company granting people ample time for professional development that doesn't transparently inflate OKRs. Maybe my anecdote is out-of-date now and the situation is better, but I do still feel like most of us have had that "coworker had to blow away their local repo because git became too tangled" experience in recent memory. I also sort of assume that, in a paradoxical kind of way, code bootcamps may do this type of thing better, but I don't have that experience to draw from.

deleted 4y ago
[deleted]
epolanski 4y ago
You have several debatable ideas. 1) thinking university degrees are meant to prepare you for jobs. This is not why higher education institutions like universities came to be centuries ago. Universities are about sharing knowledge and researching. I would even debate 99% of jobs requiring a degree don't really, software development being one of those. Hell, one of the most important and famous chief surgeons in Italy, with various high impact papers. Was found to never have even started a medical degree. 2) Of all the degrees, I would safely say, SE and even CS are among those closer to day-to-day tools at work. 3) Extracting your experience and assuming it to be similar to those in other colleges, years, countries.

jrmg 4y ago

One feature I would’ve given a lot for when recently working with a large team on a big project: Sometimes, it’s not obvious that a thing that’s made it to the main branch (whether committed or merged) is problematic until a while afterwards. In that case, later commits/merges may have been made that mean the problematic one cannot be cleanly reverted (conflicts, whether by accident or because it’s been deliberately built upon). What I want to be able to do is to revert a commit _and any later commit that depends on it_ - or at least be able to see a graph that shows the dependencies to make a risk/reward trade off between reverting it all and trying to fix the problem manually. This is definitely something it’s possible to do - I’ve done it by hand too many times!

WastingMyTime89 4y ago
You are describing "rebase -i". Just don’t pick the commit you want to revert and Git will replay the following ones one by one stopping when there is an issue.
- jrmg 4y ago
  That’s a whole extra layer of tedium above what I’d like to see. I just want a single command that will do all the reverts cleanly, and the option to list the necessary reverts instead of doing them.
  - WastingMyTime89 4y ago
    > I just want a single command that will do all the reverts cleanly Well, "rebase -i" will do that if it can be done but that’s unlikely unless your commits have nothing in common. As changes will be necessary to adapt the code to the removal, it’s kind of hard to tell from the start what will be affected. Things might have knock on effects. It’s funny because I don’t really like Git but this is one of the case where what it does seem to be the best doable considering the actual complexity of the issue. If you just want to see what will be reverted you can do a three way diff between HEAD, the commit to revert and the commit you intend to revert to btw.

tkuraku 4y ago

Sublime merge is fantastic. Does everything I need. Fast and cross platform.

Shish2k 4y ago

Sapling seems to have most of these: reword: sl metaedit <commit> sync: sl pull && sl rebase -s 'draft()' -d main split: sl split preview: not that I’m aware of, though I’ve never looked for it undo: sl undo large-load / large-ops: yeah, it was designed for FAANG monorepo-scale Additionally, some other features that sapling has that I wish git had: smartlog: Show the state of all my branches off of the master branch, what commits there are, whether they are passing the CI test suite, and whether they’ve been code reviewed: https://sapling-scm.com/docs/overview/smartlog#super-smartlog https://sapling-scm.com/docs/overview/smartlog#super-smartlo... absorb: when you’ve got one commit eg adding a new method, and another commit making use of that method, and you then tweak both bits of code, “absorb” automatically merges your add-method tweaks into the add-method commit and the use-method tweaks into the use-method commit

eclark 4y ago
And it includes a ui to make stacked diff reviews better. If only github lands played better I would be done. I’m looking forward to the planned server and sparse options being brought inline with what the internal tools were.

bloopernova 4y ago

Git always seems to be explained terribly, and I wonder why that is. To me it feels straightforward now but I graduated the route of rcs->cvs->svn->git. I think people get tripped up by the multiple layers there are between remote and local repositories. Remote->fetch->pull brings data to you. Save->add->commit->push sends it back. Then there's branches to add another layer of safety. Git being difficult is a "hilarious" meme just like exiting Vim, or writing c++. Unfortunately people hear that and have given up trying to understand it before they've even tried.

deleted 4y ago
[deleted]

alkonaut 4y ago

Rewording “too easily” would inevitably lead to someone accidentally rewording a commit on a shared branch (such as main/master). What I want in a git gui is first and foremost the fundamentals of my workflow built into the tool. What patterns for branch names means they are private? Or short lived? Or forked but never merged back? This should control e.g how a graph is drawn (you don’t bend the main branch etc) or how branch pruning is done. If I push a feature branch, later it’s merged on a server using a as squash commit and deleted remotely, then there is no way to say it should be deleted locally because there is no merge commit. This means something is missing. Either the knowledge of deleted branches should be communicated. Or the record that the branch was pushed to the central repo but is since deleted there must be saved. And this requires also specifying clearly that a remote is the source of truth. Git just doesn’t care. The remote list is basically a map of names to urls. No name is more special than another, just like no branch names are really special. And while flexible, it’s also extremely limiting.

Zigurd 4y ago

Some of the commenters here get hung up on whether git needs undo when nearly all git operations are undo-able. That's just one aspect of the problem: - It is evidently difficult for git GUI front ends to implement truly general purpose undo/redo the way any users expect any other GUI to have. This makes discoverability hard, maybe impossible, with a GUI front end to git. - Not all git operations map to the "generic operations on a selection" model most GUI software implements. There is no general "do this to that." - You can create a visualization of a git repo, but that visualization doesn't do a lot for a GUI, because of the lack of a selection or focus. It all still has to be coordinated in the user's brain, which is why most people end up just having to develop a deep understanding of the git command line. GUIs do not take away much, if any, cognitive load. Imagine having to know how a text editor manipulates the structures representing a document. It's hard to think of another design domain that is so intractable for GUI interfaces.

ComputerGuru 4y ago

True undo is possible via my all-time favorite hack, `git reflog`.

arxanas 4y ago
It is not! See https://github.com/arxanas/git-branchless/wiki/Architecture#comparison-with-the-reflog https://github.com/arxanas/git-branchless/wiki/Architecture#...
- ComputerGuru 4y ago
  Awesome work and great job writing and collecting resources. I spent a lot of time going through your docs and references.

bobleeswagger 4y ago

Whew this thread is rife with elitism. About git? To the folks sharing your difficulties with git, bravo. To everyone who says they "don't get" how people could be confused or lost while using git, you are the reason why those folks are lost, and you're perpetuating the culture of elitism by playing dumb. Git is hard as shit to understand unless you came from development before it existed, or you have had the luxury of trying other VCS professionally. Most people just know git, and it's confusing as hell if you have no reference. Don't even get me started with how this has poisoned the industry on the whole: Proper VCS implementations with CI/CD are incredibly rare, even at places with world class engineering talent.

notdonspaulding 4y ago
My hypothesis about git apologists is that they fall into one of 2 groups: 1. People who have an organizational development model and workflow which is equivalent in complexity to the Linux kernel development model and workflow (i.e. thousands of developers loosely coordinating the release of systems or mission-critical software on a regular cadence). For them git fits their needs better than almost anything else, and it makes sense because it was made for exactly that use case. 2. People who learned their first VCS after Github had reached critical mass and if you had to pick one VCS to start with, you picked git by default. For them their brain fits git, and they think "the git way" is synonymous with "the right way". Many folks in group 2 never stop to realize that they are on a development team of 5 (or 50, or 500)...and they always cut their release from `master`...and all of their branches are always pushed/pulled from the same Gitlab remote...and within 5 minutes they can chat with anyone who's made a commit in the last 2 years. I don't take issue with group 1 people who understand the git model and love it and adopt it in their workflow because they need its complexity and they're willing to pay the UX tax to get it. I take issue with the folks who don't understand the git model or realize they don't need any of the complexity and aren't aware of the existence of solutions like fossil and mercurial.

perryizgr8 4y ago

Someone should build a chatgpt type of tool that resolves merge commits. It should be able to read commit messages, and both parent trees, and just merge both cleanly. Train it on github. Just credit me on your website ;)

krupan 4y ago

PSA: magit does more than this post gives it credit for

SergeAx 4y ago

> Rewording a commit is guaranteed to not cause a merge conflict Except when the commit is already synced to another instance of this repo.

arxanas 4y ago
Sorry, my wording was imprecise, see my comment here https://news.ycombinator.com/item?id=34301971 https://news.ycombinator.com/item?id=34301971

hoseja 4y ago

Why is there so much whiny moaning about git.

diceduckmonk 4y ago

Does anyone have a set of shell aliases for more common Git workflows? It would at least smooth out some of the idiosyncrasies and memorization (need to Google search) associated with the CLI.

brunobrito 4y ago

Thanks for posting this interesting article. I work at Tower (Git client for Mac and Windows) so I feel compelled to chime in! :) Becoming more productive with Git is one of our main goals, and I'm happy to state that most of the operations you address are already included in Tower (apart from "sync", which we will think about internally). As for the others you mentioned: reword - you can edit any commit message from the currently checked out branch by right-clicking the intended commit and selecting "Edit Commit Message" Example: https://imgur.com/a/kexC8uW https://imgur.com/a/kexC8uW split - you can edit any commit from the currently checked out branch by right-clicking the intended commit and selecting "Edit Commit". You will then be able to reform that revision into one or more new commits. Example: https://imgur.com/a/NFkT4nS https://imgur.com/a/NFkT4nS preview - Tower offers an "Instant Conflict Detection" feature that will let you know in advance if conflicts will occur when merging another branch or revision (by merging, rebasing, or pulling). Our latest major update was focused heavily on creating a better merge experience and you can also see the number of unresolved conflicts that you still need to resolve (with a progress bar being shown in case of a rebase). If you mess things up, you can also undo the latest operation or abort the Merge/Rebase operation altogether. Example: https://imgur.com/a/VCkqrBI https://imgur.com/a/VCkqrBI You can learn more about Tower's Merge Improvements here https://www.git-tower.com/blog/tower-mac-9/#1-merge-improvements https://www.git-tower.com/blog/tower-mac-9/#1-merge-improvem... undo - you can undo pretty much any operation with CMD+Z (or CTRL+Z on Windows). This includes not only commits, branch creation/deletion but also more complex operations like merges, rebases, and even file discards (which is not something Git actually supports). You can learn more about Tower's Undo here https://www.git-tower.com/features/undo/ https://www.git-tower.com/features/undo/ large-load - Tower works well with large repos. We do build caches on first run, so the initial run might indeed take longer to display very large sets of data (e.g. 10k+ tags). large-ops - We designed Tower from the ground up to remain responsive when doing any kind of operation. All commands run asynchronously, so you can e.g. push a branch and immediately checkout another branch simultaneously. I hope you give Tower a try in the near future — feel free to get in touch with us if some other question pops up.

rusebor 4y ago

many say that git has an intuitive/concise data model. But it seems that even git team itself has not quite got it. Looking at one of the latest changes [1] in which a _new_ merge strategy (ort) was introduced and made default one can ask how is it possible that so fundamental change happened 15 years after git was created? Maybe the model is not so simple as it wants to seem. [1] https://github.blog/changelog/2022-09-12-merge-commits-now-created-using-the-merge-ort-strategy/ https://github.blog/changelog/2022-09-12-merge-commits-now-c...