arxanas

11 ms·

61.
by 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:/&
62.
by arxanas 4y ago
If I recall correctly, the last time I tried it, it was unusably unresponsive on large repositories (500k+ commits), so I'm unable to use it for work :(
63.
by 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 `gi
64.
by arxanas 4y ago
Apologies for the misalignment. I had difficulty formatting the table in a legible way. See my other comment re. the rubric.
65.
by arxanas 4y ago
It is very much subjective!
66.
by arxanas 4y ago
SmartGit failed to provide for any of the workflows discusses in https://blog.waleedkhan.name/git-ui-features/#rubric . Can you clarify which of these points was assessed wrongly, so that I can update them?
67.
by 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 de
68.
by 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 tha
69.
by 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?
70.
by 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 offe
71.
by arxanas 4y ago
> and partially because after all this time they still haven't taken an hour to deeply learn it. I've spent a fair amount of time working directly with the object database, working with the latest Git features, filing bugs to u
72.
by 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 impendin
73.
by 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
74.
by 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 implementa
75.
by 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
76.
by 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.
77.
Where are my Git UI features from the future?(blog.waleedkhan.name)
161 points by arxanas 4y ago|236 comments
78.
by arxanas 4y ago
I'm not familiar with ClearCase. From what little I've heard, I had understood those specifications to specify how to check out files into the working copy, more similar to Git's sparse checkout profile than to revsets.
79.
Bringing Revsets to Git(blog.waleedkhan.name)
40 points by arxanas 4y ago|3 comments
80.
by arxanas 4y ago
> Oh, I was referring to Sapling. I know even less about Jujutsu than I do about Sapling! I was just remarking about Jujutsu, in the case that it was important to you for some reason whether or not your VCS called out to Git. > Intere
81.
by arxanas 4y ago
What I mean is that you can't co-locate your Sapling repository with your Git repository (at least, for now). You have to have them in separate directories and push/pull between them. git-branchless is only an extension to Git, so
82.
by arxanas 4y ago
To accomplish your workflow, there doesn't seem to be any need for a staging area at all. You can use an interactive commit selector to stage a subset of changes (or select a set of changes some other way), and then if you want to keep
83.
by arxanas 4y ago
It's not a big deal either way, but the staging area interacts worse with some operations. For example, if you have staged changes and then get a conflict with `git checkout --merge`, AFAIK there's no way to undo to before the con
84.
by arxanas 4y ago
A lot of the important work is on back-end scaling for a centralized repository. Example: the segmented changelog allows answering merge-base queries in ~O(log n) time and very quickly in practice; these queries need to happen all the time
85.
by arxanas 4y ago
Generally speaking, they simply don't use multiple branches on the central server. See https://trunkbaseddevelopment.com/
86.
by arxanas 4y ago
You can push and pull directly from Git repositories, without resorting to some kind of tedious intermediate conversion step. Note that they don't support co-locating in the same repository at present, i.e. running both `sl` and `git`
87.
by arxanas 4y ago
Yep — after trying out Sapling, it aborts many operations due to working copy changes, which I now find to be jarring interruptions to my workflow. Jujutsu (and even git-branchless) have much better support for juggling working copy changes
88.
by arxanas 4y ago
Generally, you "stack" your commits/PRs and review them in small units (which I think is what you mean by working on something else without making any Git checkouts). But you can certainly create new "branches" of d
89.
by arxanas 4y ago
We know empirically that the staging area is a major pain point for users in practice, as discussed in https://investigating-archiving-git.gitlab.io/ The findings validate the earlier conceptual design analysis in practical
90.
by arxanas 4y ago
In my opinion, Git added too many moving parts in a poorly-designed way. Commits, the staging area, and stashes all implement the same sort of idea, but interact poorly and considerably complicate workflows. Having them is better than not

More ›