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

411–420 of 430 posts

Re: What comes after Git

#411

Post by throw-ru-938 »

sedatk wrote: post #395
throw-ru-938 wrote: post #148

Earlier quoted context omitted.

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.

How do you mess up an immutable repository?

Accidentally commit a huge video to a code repo (stupid as it sounds, this actually happened at a past employer). Make commits with unreadable messages, huge-ass commits with tens of logically different changes, split a single logical feature over several commits, etc.

Re: What comes after Git

#412

Post by bilekas »

parasti wrote: post #373
bilekas wrote: post #133

Earlier quoted context omitted.

> You can't learn Git by using its commands. From experience, this is just straight up wrong. I came from an SVN enviornment which was all GUI tools. Git's learning curve was steep but extremely short. Once you know what is happening, even those crazy states you can find yourself in really are not that hard.

> Once you know what is happening, even those crazy states you can find yourself in really are not that hard. I think we're saying the same thing. Once you know how Git works, it's easy. But can you figure out "how Git works" by using a handful of commands like git add, git commit and git push?

> But can you figure out "how Git works" by using a handful of commands like git add, git commit and git push

Once you can picture what's happening, absolutely. I can think of some other cases that require a lookup later like one I had to lookup after: 'rebase v merge' for example, after a 5 min documentation read, and with a picture in your head of how your state is it makes sense.

You're right if you're looking for 'how git works under the hood' that's a bit different. I might have misunderstood your sentiment.

Re: What comes after Git

#413

Post by Aozora7 »

c7DJTLrn wrote: post #314
Aozora7 wrote: post #274

Earlier quoted context omitted.

I find git reasonably understandable as long as you are using a GUI. When you have a GUI, every action you take provides you visual feedback, so it's way easier to understand the purposes of merges, rebeases, stashes, and resets. My understanding of git workflow greatly improved thanks to it.

On the contrary, I've met plenty of people who struggle along with a GUI because they don't want to learn the CLI. They mash fetch and pull rhymthically hoping it will do what they want with no clue what it's really doing underneath. Eventually, they give up, nuke the repo and reclone it. Most CLI users I've met are at least competent at using git.

I have the opposite experience, the CLI users I see pretty much never use anything besides commit, push and pull, while GUI users tend to use more advanced commands since they can actually see what they do.

Re: What comes after Git

#414

Post by dotancohen »

5e92cb50239222b wrote: post #45
dotancohen wrote: post #40

Earlier quoted context omitted.

> And do you seriously not see the need of rebasing? Git user for a decade. I never rebase, not professionally and not in my personal projects. I merge the work of other devs, no matter how ugly their history. I don't see any real problem that rebase solves, but I do see that it mangles history and makes troubleshooting e.g. git bisect much more difficult.

You must not ever work with junior developers. Rarely do I see a properly created commit history, what you usually get is something like: add upd fix upd fix Rebasing that stuff before merging it into master feels mandatory, or you're left with history with a very low signal-to-noise ratio.

If that's the case, I would have the dev go rebase that into a nice single commit. Not the guy doing the integration work. I expect that the dev's last operation was to merge from the dev branch, fix conflicts, then push a PR.

At the least, if you're dev refuses to give you a nice commit, you could merge-squash his branch.

Re: What comes after Git

#415

Post by jerf »

silisili wrote: post #410
jerf wrote: post #289

Earlier quoted context omitted.

There's a lesson here, too. To unseat git, you need to not just be slightly better than it; you need to have a big use case for many people and be radically better than it in that particular use case. You even can be worse than git in some others as long as you have that radical improvement to build on. Being merely better isn't enough; see mercurial. The use case actually has to be important to people in real life,…

Well said, but I humbly disagree that it has to be better in some way, just easier AND as technically sound. Unless that is by your definition better. Ease of use is probably one of the most important factors in real life in determining preferences for software. I strongly feel if someone could match the merging ability of Git with the ease of simple, well worded commands, it could win. And it doesn't even have to be…

"I strongly feel if someone could match the merging ability of Git with the ease of simple, well worded commands, it could win."

But we have that, and not only didn't it win, it shows no sign of winning. Mercurial isn't even growing in apparent mindshare.

"Easier" and "technically sound" is by observation, not by a long line of strained theorizing, not enough. Theories must take this fact into account or be useless in explaining the real world.

Re: What comes after Git

#416

Post by bvrmn »

AvImd wrote: post #380
bvrmn wrote: post #362

Earlier quoted context omitted.

I successfully use [stgit][1] (for 10 years) for private commits and pretty much for the rest of near-git workflows. [1]: https://stacked-git.github.io/

Does stgit help with the following scenario: 1. I want some changes in my repo to be persistent whenever I switch to a new branch, pull, or merge a remote. 2. They should not be shown in git status. 3. They should not be pushed. From skimming the front page I haven't found whether something like this is supported. I see that with stgit I can `stg pop` my "persistent changes" before pushing to the remote and then appl…

For this case `git stash` is enough.

Re: What comes after Git

#417

Post by bvrmn »

koonsolo wrote: post #366
bvrmn wrote: post #282

Earlier quoted context omitted.

Do/did you use other VCSes? I did. ClearCase, CVS, SVN, Mercurial. It's a real horror (excluding later) to deal with. Sometimes basic operations like merge need separate role (human) to perform. Mercurial is nice if you are a max middle-level and do not use anything besides checkout/commit/push. Any non-trivial stuff requires manual reading (the same as for git) I know you have no time to know your tool. But I don't…

> Do/did you use other VCSes? I did. ClearCase, CVS, SVN, Mercurial. It's a real horror (excluding later) to deal with. I did, plus MS SourceSafe, Team Foundation Source Control and Bazaar. I don't see the problem with SVN and Mercurial. If you have merge conflicts, no tool is going to solve that. If you love git so much, try to do a squash merge to the main, then do some other changes in your branch, and try to merg…

> If you love git so much, try to do a squash merge to the main, then do some other changes in your branch, and try to merge again. Have fun solving all the merge conflicts that actually shouldn't be there.

Why I should want to do it? It feels unnatural. What problem you are trying to solve by this workflow?

I'm very curious how your favorite VCS handle this case.

Re: What comes after Git

#418

Post by morleyk »

koonsolo wrote: post #366
bvrmn wrote: post #282

Earlier quoted context omitted.

Do/did you use other VCSes? I did. ClearCase, CVS, SVN, Mercurial. It's a real horror (excluding later) to deal with. Sometimes basic operations like merge need separate role (human) to perform. Mercurial is nice if you are a max middle-level and do not use anything besides checkout/commit/push. Any non-trivial stuff requires manual reading (the same as for git) I know you have no time to know your tool. But I don't…

> Do/did you use other VCSes? I did. ClearCase, CVS, SVN, Mercurial. It's a real horror (excluding later) to deal with. I did, plus MS SourceSafe, Team Foundation Source Control and Bazaar. I don't see the problem with SVN and Mercurial. If you have merge conflicts, no tool is going to solve that. If you love git so much, try to do a squash merge to the main, then do some other changes in your branch, and try to merg…

I would just delete the branch after merge to the main and then create a new branch from main.

Re: What comes after Git

#419

Post by enasterosophes »

vaughan wrote: post #84
enasterosophes wrote: post #58

Earlier quoted context omitted.

Well, you can look at the author's past HN submissions to see what was meant. It's basically click-bait for hackers. "How to do X technology better" with a few paragraphs of ideas, and taking no responsibility for actually doing something about it, aside from hoping that their vision might inspire someone else to put in the hard work.

Why do they have to take responsibility? I can point to so many oss projects where someone else’s vision was implemented.

Confuse "is" vs "ought" much?

I didn't say they have to do anything. I did observe a pattern.

There is a difference between saying everyone should take responsibility for fixing all their criticisms and noticing that a particular person never takes responsibility for any of their criticisms.

Re: What comes after Git

#420

Post by kjeetgill »

nathants wrote: post #370
kjeetgill wrote: post #224

Earlier quoted context omitted.

That's reasonable, but I think a commit + a rebase -i of just that single commit gets you to the same place. And now your backup branch can preserve the code you would have stashed.

rebase is a multi stage command that often requires force push. as good as it can be, discouraging it’s use, especially in contexts where git is considered challenging, is probably the play.

That's a really good point.
Post reply on HN