Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

What comes after Git

matt-rickard.com

Post reply on HN
Print view View original

141–150 of 430 posts

Re: What comes after Git

#141

Post by troppl »

krageon wrote: post #105
pdmccormick wrote: post #100

Am I the only one who thinks that Git's UX is fine, and maybe even rather enjoyable? It has taken time to learn, and I am by no means a power user, but its model is now in my brain so, for better or worse, it's how I think and work now too (interactive rebasing for the win, all the time, and lots of shell aliases to shorten things). I do wish I had an easier way to split up a commit that accidentally included several…

> Am I the only one who thinks that Git's UX is fine [...] No, I think most people that use it are fine with it. But those are usually not the ones you hear :)

Are you really sure that is the case here? I think everyone that starts working with git is a bit hung up by its complexity at least for a year, if not more.

It seems to me that, as it should be, every professional SW dev has managed to work with git at some point in their life, then. Because git is simply what you will most likely use nowadays.

But still, everyone remembers how hard it was to start out. Which is why, I think, these blog posts about git are so popular all the time.

Re: What comes after Git

#142

Post by [deleted] »

pdmccormick wrote: post #100

Am I the only one who thinks that Git's UX is fine, and maybe even rather enjoyable? It has taken time to learn, and I am by no means a power user, but its model is now in my brain so, for better or worse, it's how I think and work now too (interactive rebasing for the win, all the time, and lots of shell aliases to shorten things). I do wish I had an easier way to split up a commit that accidentally included several…

[deleted]

Re: What comes after Git

#143

Post by LtWorf »

bmitc wrote: post #102
alexchamberlain wrote: post #88

Earlier quoted context omitted.

Simply separating concerns so that each PR/commit focuses on 1 thing.

But what is the one thing if you're just adding a dependency, where you're only adding it so that you can subsequently add a feature using it in a separate PR? The atomic action is adding the feature which requires the new dependency. Unless I misunderstood what you wrote. I still agree with the original comment in that diffing technology feels decades behind, and that a lot of what we do as software engineers are wo…

You can review pr commit by commit… if the commits are poorly made just reject the changes and ask to make them properly.

Re: What comes after Git

#144

Post by throw-ru-938 »

troppl wrote: post #141
krageon wrote: post #105

Earlier quoted context omitted.

> Am I the only one who thinks that Git's UX is fine [...] No, I think most people that use it are fine with it. But those are usually not the ones you hear :)

Are you really sure that is the case here? I think everyone that starts working with git is a bit hung up by its complexity at least for a year, if not more. It seems to me that, as it should be, every professional SW dev has managed to work with git at some point in their life, then. Because git is simply what you will most likely use nowadays. But still, everyone remembers how hard it was to start out. Which is why…

Come on, getting comfortable with a couple of incantations takes people a whole _year_? Because you don't need much more when you're starting out.

Re: What comes after Git

#145

Post by happyweasel »

tsimionescu wrote: post #126
kache_ wrote: post #7

Nothing. Keep it simple. There's a reason it has stuck around >inb4 it isn't simple it is

Subversion is much simpler than Git (centralized is always simpler than decentralized). Being simple is not what made Git popular. Git is popular because it is free, fast, works well enough, and was popular in some major projects. Its major advantage for most orgs (those who actually use it in a centralized manner, with a corporate repo that everyone syncs with every day, unlike the Linux kernel team) as compared to…

> it makes branches cheap and easy.

IMHO branching itself isn't expensive in Subversion, the problems arise when you merge (feature)branches back. If you branch off (for release branches) and then just selectively merge certain commits to that branch only if needed (the info being stored in svn:mergeinfo), I think its not that bad. I prefer branch-by-abstraction and trunk-based dev anyway, so here you go ;)

Re: What comes after Git

#146

Post by sriku »

I've been using fossil (https://fossil-scm.org) for personal projects for like a decade now and I much prefer it over git. The characteristics that get me to stick with it are -

1. Single file executable. No dependencies to "install". Just the executable and you're good. 2. The whole repo is a single sqlite DB file. Fabulous for backups, sharing, hosting etc. 3. You cannot rewrite history unlike git. Hence the name. Folks using git have no idea what kind of a peace of mind this gives me. 4. Integrated issue tracker stored in the same repo. Complete with cross references to commits. 5. Allows repeated use of same tag name. This is so convenient in personal projects I miss it in git. You can mark a commit as "published" and later look at the whole history of all previous commits tagged as "published".

Other niceties -

1. Integrated wiki - I've occasionally used it, but usually prefer to write documentation in separate files. 2. Integrated webserver - `fossil ui` runs on the same thing so I do use it. The webserver comes complete with user account management and permissioning. 3. Can export and import to/from git.

Re: What comes after Git

#148

Post by throw-ru-938 »

sedatk wrote: post #26
torginus wrote: post #13

My main issue with Git, other than the terrible UX of the CLI, is just how common it is for one to want to rewrite the commit history - an operation for which there's no version control. You better get it right, or otherwise you get to nuke the whole repository.

which is why I love Mercurial as it's immutable by default. You have to try really hard to mess up your repository.

Which is why I don't love Mercurial, because once you mess up your repo, it's messed up forever.

IMO "easy to break but easy to fix" is better than "hard to break but impossible to fix", and there ain't no such thing as "hard to break" after enough time passes.

Re: What comes after Git

#149

Post by flurdy »

alexchamberlain wrote: post #81
torginus wrote: post #51

Earlier quoted context omitted.

You learn something every day!

Another super simple technique is to create a branch where you start to go back to if you need to; ie if you are rebasing `foo`, start by running `git branch foo-back` and you can always reset back there if needed.

Since I often play with razors by rebasing, resetting, cherry picking, etc locally - I created a `git tmp` alias so I can play without fear of needing to go reflog diving again.

The `tmp` command creates a commit of all changes, branches it, then rolls back the commit.

[1] https://github.com/flurdy/dotfiles/blob/master/.config/fish/...

Re: What comes after Git

#150

Post by mejutoco »

pdmccormick wrote: post #100

Am I the only one who thinks that Git's UX is fine, and maybe even rather enjoyable? It has taken time to learn, and I am by no means a power user, but its model is now in my brain so, for better or worse, it's how I think and work now too (interactive rebasing for the win, all the time, and lots of shell aliases to shorten things). I do wish I had an easier way to split up a commit that accidentally included several…

I agree with you. Adding new well-thought commands while keeping the old more arcane syntax would be enough for me (like git switch, git restore, git create-branch instead of git checkout -b, etc.).

This way new users will find it better to learn and people familiar with it don't need to change it.

Post reply on HN