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

Oh shit, git (2016)

ohshitgit.com

Post reply on HN
Print view View original

41–50 of 280 posts

Re: Oh shit, git (2016)

#41

Post by dwaltrip »

Git is pretty nice, but I'm sure there is something much better waiting to he invented. The CLI in particular could use a ton of improvements.

And I feel it in my bones that there is a revolutionary GUI waiting to be invented. Why can't I drag a commit or set of commits from one branch to another? With safe, easy undo (reflog doesn't count) and super smooth conflict resolution? Etc etc.

And of course there is the interesting rabbit hole of semanitc / language aware diff. Line diffs suck in many ways.

It's one of the hundreds of of problems that I'd love to work on one day, but probably won't get a chance to. Sigh... :)

Re: Oh shit, git (2016)

#42

Post by fulafel »

mehrdadn wrote: post #37
fulafel wrote: post #22

Earlier quoted context omitted.

This then discourages ad hoc teamwork because you can't touch feature branches other than the ones you own. And because the results of getting it wrong are hairy, people will tend to stay away just in case. It's a chilling effect. Or, someone might have created another branch off your feature branch, because they depend on your work. Now you've creaed a time bomb for them when they try to merge their work after you'v…

> This then discourages ad hoc teamwork because you can't touch feature branches other than the ones you own. And because the results of getting it wrong are hairy, people will tend to stay away just in case. It's a chilling effect. Do you frequently go messing with a branch assigned to single developers on your team without any sort of prior heads-up? And then surprise them with new commits next time they push/pull?…

Not as often as we'd like to[1], but it happens regularly in reviews, or when casually working together on the same thing in, or when basing branches on other people's unfinalized work, etc. If a team member is used to a force push / rebase type of workflow, it invariably means that stuff will blow up becuause they forgot they had rebased, or they do a force push out of habit, etc. If you include rebase / force push in your daily workflow, you will invariably foul up with it and forget to make an exception for the teamwork.

Your proposed "heads up" way can work in theory, but it introduces too much friction and risk of error, and still leaves the situation in shambles when they have a rebased branch on their laptop that they haven't pushed yet. So you need to have a multi phase protocol that requires many interactions and even then the other guy may well forget about it and do a rebase & force push out of habit in the end.

[1] Well, "branch assigned to a single developer" isn't a thing, but most feature branches are finished by 1-2 people.

Re: Oh shit, git (2016)

#43

Post by darkpuma »

jchw wrote: post #35
_7fvc wrote: post #20

Reading this article, I realize that I'm old now. I still remember wrestling with cvs, svn. Merge, branch were slow and even more challenging. It was much easier to mess up and so difficult to rewind. When I first learned git, I thought it's pretty neat. It solves merge, branch, rewind problems. Git is one of the things in life that doesn't work like the way we think. But it turns out to be a better way.

I’m torn. Practically Mercurial feels like it should be the winner. The commands are more uniform and predictable. That’s not all it has going for it either. Mercurial has a concept of commit stages to make history rewriting safer. It has a commit model that enables you to work on and manipulate branches of commits seamlessly, without needing named branches. It has not just a tree of commits but also each commit trac…

Hg and git have near feature parity, so I don't really lament Hg's loss so much. Sure Hg's CLI is a little bit better, but beyond that it never really offered any really compelling features over git. Mercurial and git is like Honda and Toyota; maybe one is a bit nicer than the other, but they're both offering you more or less the same thing.

Fossil is another matter. Fossil defies pithy car analogies. Integrating the bug tracker into the version control alone is a game changer, and that's not even all that Fossil does.

Re: Oh shit, git (2016)

#44

Post by darkpuma »

scarejunba wrote: post #32
thatoneuser wrote: post #24

Earlier quoted context omitted.

OK hot shot. Tell everyone here how you've never fucked up commands and had to blow out a repo and start over and how were all idiots for having done that. It's a tool. Any tool can be confusing if the person isn't taught how to use it. Git requires teaching so there's a lot of room for misunderstanding.

I'm not the hot shot. The hot shots are all the kids from Berkeley and Stanford who figure this shit out as interns while supposedly fully-trained engineers with all the knowledge of data structures that should come with that think this shit is too hard. I think I'd be completely unsurprised to see an intern successfully use `rerere` on a longer project of theirs.

I know of teenagers who happily use git because nobody ever told them they were supposed to consider it hard.

Re: Oh shit, git (2016)

#45

Post by jchw »

darkpuma wrote: post #43
jchw wrote: post #35

Earlier quoted context omitted.

I’m torn. Practically Mercurial feels like it should be the winner. The commands are more uniform and predictable. That’s not all it has going for it either. Mercurial has a concept of commit stages to make history rewriting safer. It has a commit model that enables you to work on and manipulate branches of commits seamlessly, without needing named branches. It has not just a tree of commits but also each commit trac…

Hg and git have near feature parity, so I don't really lament Hg's loss so much. Sure Hg's CLI is a little bit better, but beyond that it never really offered any really compelling features over git. Mercurial and git is like Honda and Toyota; maybe one is a bit nicer than the other, but they're both offering you more or less the same thing. Fossil is another matter. Fossil defies pithy car analogies. Integrating the…

Hg actually does go beyond Git in many areas; I did outline a few but my favorites are the improved commit model (stages, natural branching, rewrite tracking,) the commands Git doesn’t have (absorb, evolve,) and the extensibility (see Facebook extensions.)

Sure, the model is similar and Fossil is different. But that is kind of an important note. If Fossil can’t be compared on the same level, maybe that’s a sign it solves fundamentally different problems.

In most setups, the bug tracker and source control are separate, but that doesn’t mean you can’t get bugtracking alongside code either, GitLab provides everything from bugtracking to CI to deploying stuff to Kubernetes.

Not to say Fossil isn’t cool or doesn’t have its place, but if I disagree with the philosophy (and I do, fundamentally,) then I don’t feel like I lose much using alternative software suites.

Re: Oh shit, git (2016)

#46

Post by rk06 »

dwaltrip wrote: post #41

Git is pretty nice, but I'm sure there is something much better waiting to he invented. The CLI in particular could use a ton of improvements. And I feel it in my bones that there is a revolutionary GUI waiting to be invented. Why can't I drag a commit or set of commits from one branch to another? With safe, easy undo (reflog doesn't count) and super smooth conflict resolution? Etc etc. And of course there is the int…

https://gitless.com/

Re: Oh shit, git (2016)

#47

Post by clarry »

lixtra wrote: post #39
broodbucket wrote: post #19

Earlier quoted context omitted.

That's not public git history though, those are just patches on mailing lists. Even before it goes into maintainer's lists, in my experience it's extremely rare that a maintainer will force push to their own public -next branch.

EDIT: parent is right. I see about 600 pull requests on github[1]. My understanding was that Linus moved away from mailing lists some time ago. But then I'm not involved in kernel hacking. [1] https://github.com/torvalds/linux/pulls

Did you ever look at any one of these PRs?

Re: Oh shit, git (2016)

#48

Post by saagarjha »

lixtra wrote: post #39
broodbucket wrote: post #19

Earlier quoted context omitted.

That's not public git history though, those are just patches on mailing lists. Even before it goes into maintainer's lists, in my experience it's extremely rare that a maintainer will force push to their own public -next branch.

EDIT: parent is right. I see about 600 pull requests on github[1]. My understanding was that Linus moved away from mailing lists some time ago. But then I'm not involved in kernel hacking. [1] https://github.com/torvalds/linux/pulls

The Linux kernel has a bot that reminds people that kernel development happens on the mailing list: https://github.com/KernelPRBot. Since GitHub does not allow for disabling the pull requests tab, the pull requests invariably get closed.

Re: Oh shit, git (2016)

#49

Post by jayd16 »

dwaltrip wrote: post #41

Git is pretty nice, but I'm sure there is something much better waiting to he invented. The CLI in particular could use a ton of improvements. And I feel it in my bones that there is a revolutionary GUI waiting to be invented. Why can't I drag a commit or set of commits from one branch to another? With safe, easy undo (reflog doesn't count) and super smooth conflict resolution? Etc etc. And of course there is the int…

>and super smooth conflict resolution?

Because the hardest part of conflicts is already the conflicting changes themselves and not the source control.

Re: Oh shit, git (2016)

#50

Post by mehrdadn »

fulafel wrote: post #42
mehrdadn wrote: post #37

Earlier quoted context omitted.

> This then discourages ad hoc teamwork because you can't touch feature branches other than the ones you own. And because the results of getting it wrong are hairy, people will tend to stay away just in case. It's a chilling effect. Do you frequently go messing with a branch assigned to single developers on your team without any sort of prior heads-up? And then surprise them with new commits next time they push/pull?…

Not as often as we'd like to[1], but it happens regularly in reviews, or when casually working together on the same thing in, or when basing branches on other people's unfinalized work, etc. If a team member is used to a force push / rebase type of workflow, it invariably means that stuff will blow up becuause they forgot they had rebased, or they do a force push out of habit, etc. If you include rebase / force push…

> but it happens regularly in reviews

But then you already know someone is reviewing that branch! So both of you avoid force-pushing.

> or when casually working together on the same thing in

Again, you both know multiple people are involved here... "casually working together" is the heads-up! You don't need another one.

> or when basing branches on other people's unfinalized work

Without any sort of hint to the guy working on that branch? How do you know it's even in a stable state to build on if you have no communication?

> or they do a force push out of habit

Yes it breaks if you screw up, but I mean then you just deal with it right? It's a dumb mistake just like any other silly mistake that can happen during committing, it's infrequent, it's on an ephemeral branch, and it's completely reversible. I don't see why someone occasionally mistakenly pushing the wrong thing (forced or otherwise) on a branch that isn't even going to exist for much longer is such a catastrophic event that you have to formulate your whole team's entire development process around avoiding that event 100% at all costs?

> Your proposed "heads up" way can work in theory, but it introduces too much friction and risk of error, and still leaves the situation in shambles when they have a rebased branch on their laptop that they haven't pushed yet. So you need to have a multi phase protocol that requires many interactions and even then the other guy may well forget about it and do a rebase & force push out of habit in the end.

Again, you don't need an explicit heads-up when you already know multiple people involved, and you can just deal with the occasional errors, as I mentioned. See above.

Post reply on HN