191–200 of 233 posts
Earlier quoted context omitted.
> The data model is more important than the user space. For those interested in the different perspectives on how to weigh those priorities, I recommend starting here: https://en.wikipedia.org/wiki/Worse_is_better
I think the programmer tendency to think of usability as an implementation detail is probably why open-source app UX was considered a joke for so many years. Only now is that perception starting to change, because enough people have taken an interest in the space who make usability a priority.
Earlier quoted context omitted.
I am by all accounts the SME on git at my company. I often am the VCS expert at my company. I don't like using tools I don't understand, and my brain is pretty good at handling problems that look like graph theory. After using git for 6 years git still terrifies me. After 9 months of svn I performed open heart surgery to remove a 1GB zip file that some dummy merged before anyone thought to stop him. It was at least 1…
It's not that hard man. Really isn't. Your anecdote sounds like someone who thinks they're awesome at git setting a noob up for failure and then mansplaining when they fuck up. It's not hard to be better at git than 85% of people, most devs I've met don't understand the basics beyond pull commit push.
But it’s certainly not the easiest thing to mess up a Git repository to the point of losing data; the reflog keeps it all intact for at least a month unless you very deliberately tell it not to (see the “CHECKLIST FOR SHRINKING A REPOSITORY” section of git-filter-branch(1) for sample invocations after such an edit), and I’d be much more comfortable about open heart surgery on Git’s model than on SVN’s.
That's very cool to have support for rsync/dropbox collaboration of the repo files. I'm always sad that there isn't a maintained p2p git implementation anymore. I'd love to just dump a bare repo to a syncthing share and collaborate with a small group of people accessing it.
What, it isn't actually a decentralised distributed system any more?!?
> I'd love to just dump a bare repo to a syncthing share and collaborate with a small group of people accessing it.
Are you saying one can't do that with the latest versions of git?
WTF, when did this happen and how can I have missed what must have been huge news when it happened?
Maybe I'm too brainwashed by git, but it seems to me one of its benefits is the way the index works. You're encouraged to be fairly explicit about what you're adding to a commit, which encourages making a nice version history. Why would I want everything I do to automatically be added to a commit by default? Doesn't this encourage me to either put all kinds of unintended, not-ready crap in my commits, or constantly m…
And maybe I'm too brainwashed by Mercurial, but to me the index is nothing but a single weird commit with only downsides (why do we need a UI to work with the index that's different from the one to interact with commits, although the capabilities should be the same? Why being limited to a single index and not several? Why the different versioning/shareability characteristics, etc).
I largely prefer Mercurial's "public vs draft" strategy and the "commit what you have and we give you the tools to tidy up the series whenever you feel like it". In practice it means that you have as many "indexes" as your series is long, and with hg's mutable-history and amazing history-rewriting extensions like absorb, it's much more convenient, fast and safe to work with than the git inconsistent equivalents.
" It also means that you can always check out a different commit without first explicitly committing the working copy changes (you can even check out a different commit while resolving merge conflicts)." That's really interesting. Having to manage stashes is annoying.
Try using git worktrees: https://geekmonkey.org/rethink-your-git-workflow-with-git-wo...
jujutsu looks interesting, but one thing that i find missing from git is historical branch tracking. once two branches are merged, git does not tell me which series of commits used to belong to which branch. i can't check out main from two weeks ago if a merge happened in the meantime because that information is lost. i fear to add such a feature additional information would need to be stored in the git repo itself w…
Git has the concept and knowledge of which side a merge came from. A commit having multiple parents (a merge commit) maintains the order of those parents within the commit. The branch names are famously lost, but by convention you can say that the first parent should always be the main branch. As with all other git things, the ux for this feature isn’t the best and it’s use varies wildly across tools and organization…
Removing the "convince my team to move away from git" part of a better DVCS could make jujutsu very popular.
Or other git compatible spinoffs could be made that follow this approach and explore other design spaces.
I like that this is not "a dvcs written in rust" but rather "a dvcs with these awesome improvements over git." which incidentally happens to be written in rust because of course it's the right language for this.