Things I wish everyone knew about Git (Part I) • Hacker News Board

Re: Things I wish everyone knew about Git (Part I)

#191

Post by woojoo666 » Fri, Jul 01, 2022, 6:28 AM UTC

shikoba wrote: post #176

woojoo666 wrote: post #168

Earlier quoted context omitted.

I don't think the UX is that intuitive. If you want to tweak a commit that's not the branch head, you have to rebase the parent of that commit. From a technical standpoint this sort of makes sense, but for a casual user this is not intuitive at all

> If you want to tweak a commit Here we are. You can't tweak a commit in git. You want to recreate a new one. That's why UX is awful, because there is a permanent confusion about what git does.

I know that rebasing creates a new commit (and all commits thereafter). As I said, from a technical standpoint I get it. But I don't see why there can't be a simple command or button that lets to modify a single commit, and performs the rebase behind the scenes. I commonly need it in my private repos and branches. But right now the rebase operation we're stuck with is very low-level and unintuitive.

Re: Things I wish everyone knew about Git (Part I)

#192

Post by fero14041 » Fri, Jul 01, 2022, 7:42 AM UTC

brianwawok wrote: post #98

HWR_14 wrote: post #67

Earlier quoted context omitted.

Am I the only one sad that Git beat out Mercurial as the industry standard? And am I also the only one who still knows how to do things in Mercurial but not how to take the corresponding action in Git? I mean, they're things I haven't had a reason to do in years, but it has some psychological cost to feel like I'm using a system I'm worse at.

I was on the team of a large org doing a POC between the two. Merc did some stuff better, git did more. I am glad git won out overall. I think the only feature Merc had that I cared about was tracking folders as objects.

Mike Bayer, creator of SQLAlchemy ORM in Python, wrote about migrating its repository from Mercurial to Git, in 2013: https://www.sqlalchemy.org/blog/2013/05/25/sqlalchemy-migrat... He had some IMHO strong points in favor of Git itself VS Hg, besides GitHub and its huge userbase, which personally convinced me to switch.

Re: Things I wish everyone knew about Git (Part I)

#193

Post by mathstuf » Fri, Jul 01, 2022, 10:24 AM UTC

woojoo666 wrote: post #190

mathstuf wrote: post #169

Earlier quoted context omitted.

You rebase onto the parent of that commit. The parent doesn't change. Or am I misunderstanding what you're describing here?

But the average casual user just wants to modify the commit. There could easily be a higher level command for this, which internally finds the parent and performs the rebase, but instead Git (and even most GUI tools on top) forces you to go the manual route of selecting the parent and initiating a rebase. It's counterintuitive

There is the ~ or ^ suffix to select a parentage. Also, vin-fugitive selects the parent automatically when you say "rebase starting here" on a commit under the cursor. Not sure what it does for merge commits; there's so great default there.

Re: Things I wish everyone knew about Git (Part I)

#194

Post by woojoo666 » Fri, Jul 01, 2022, 11:17 AM UTC

mathstuf wrote: post #193

woojoo666 wrote: post #190

Earlier quoted context omitted.

But the average casual user just wants to modify the commit. There could easily be a higher level command for this, which internally finds the parent and performs the rebase, but instead Git (and even most GUI tools on top) forces you to go the manual route of selecting the parent and initiating a rebase. It's counterintuitive

There is the ~ or ^ suffix to select a parentage. Also, vin-fugitive selects the parent automatically when you say "rebase starting here" on a commit under the cursor. Not sure what it does for merge commits; there's so great default there.

You still have to go through the "pick"/"reword" flow though. Most of the time people just want to modify a single commit. So why not just have a command for it, instead of needlessly exposing the low-level rebase process to the users

Re: Things I wish everyone knew about Git (Part I)

#195

Post by shikoba » Fri, Jul 01, 2022, 11:59 AM UTC

woojoo666 wrote: post #194

mathstuf wrote: post #193

Earlier quoted context omitted.

There is the ~ or ^ suffix to select a parentage. Also, vin-fugitive selects the parent automatically when you say "rebase starting here" on a commit under the cursor. Not sure what it does for merge commits; there's so great default there.

You still have to go through the "pick"/"reword" flow though. Most of the time people just want to modify a single commit. So why not just have a command for it, instead of needlessly exposing the low-level rebase process to the users

git commit --amend

Or git rebase

It's two simple command

Re: Things I wish everyone knew about Git (Part I)

#196

Post by woojoo666 » Fri, Jul 01, 2022, 10:39 PM UTC

shikoba wrote: post #195

woojoo666 wrote: post #194

Earlier quoted context omitted.

You still have to go through the "pick"/"reword" flow though. Most of the time people just want to modify a single commit. So why not just have a command for it, instead of needlessly exposing the low-level rebase process to the users

git commit --amend Or git rebase It's two simple command

Git commit amend only works if you want to modify thr latest commit. Rebase is unnecessarily complicated if you just want to modify a single commit. It should be something more like `git edit [commit sha]`

Re: Things I wish everyone knew about Git (Part I)

#197

Post by mathstuf » Sat, Jul 02, 2022, 11:41 AM UTC

woojoo666 wrote: post #196

shikoba wrote: post #195

Earlier quoted context omitted.

git commit --amend Or git rebase It's two simple command

Git commit amend only works if you want to modify thr latest commit. Rebase is unnecessarily complicated if you just want to modify a single commit. It should be something more like `git edit [commit sha]`

That gets complicated. What if there's a merge commit between here and there? How about a conflict? You cannot hide the underlying mechanism of reapplying a set of changes.

On that note, I have written something like this, but it is not something I think belongs in the standard toolbox. It is a tool that applies "formatting" fixes to a topic, preserving history topology. However, it requires some automated tool to be able to perform the edit so that any conflicts can be resolved by running the tool to perform the edit (typically clang-format or autopep8, but sed or something like that is also a candidate). I don't know that requiring your edit to be expressed in terms of sed is suitable for such a "simple" tool to replace rebase.

Re: Things I wish everyone knew about Git (Part I)

#198

Post by zasdffaa » Sat, Jul 02, 2022, 2:56 PM UTC

kjeetgill wrote: post #118

masklinn wrote: post #53

Earlier quoted context omitted.

> My question is why hasn't anyone come along and fixed it? Git has the plumbing vs. porcelain separation. Dozens have, but by the time their replacement porcelain gets anywhere near useful they’ve attained a grasp of the plumbing more than good enough they don’t need it anymore. > My second question is, if the underlying model is so f*cking elegant, how did it lead to such a confusing interface? Mastery of structura…

> Every database. The relational model is a beautiful thing, sql is a horrendous shit-show. Amen. We probably disagree on if we need less abstraction or better abstraction though. For all the griping that git gets I really think it could be much worse. It's a somewhat inelegant shrink-wrap over its data structures but at least I can get at all the pieces I need. I get that SQL works well for ad-hoc analysis and busin…

> but for service to service calls I'd love a language that let's me refer to the tables, the b-trees, row-ids

Quite Insane :)

Ok, more helpfully, what possible value would you get if the DB gave you access to those?

Re: Things I wish everyone knew about Git (Part I)

#199

Post by woojoo666 » Sun, Jul 03, 2022, 10:26 PM UTC

mathstuf wrote: post #197

woojoo666 wrote: post #196

Earlier quoted context omitted.

Git commit amend only works if you want to modify thr latest commit. Rebase is unnecessarily complicated if you just want to modify a single commit. It should be something more like `git edit [commit sha]`

That gets complicated. What if there's a merge commit between here and there? How about a conflict? You cannot hide the underlying mechanism of reapplying a set of changes. On that note, I have written something like this, but it is not something I think belongs in the standard toolbox. It is a tool that applies "formatting" fixes to a topic, preserving history topology. However, it requires some automated tool to be…

It would still use rebase in the background. If there's a conflict that happens when reapplying changes, then an error pops up, and the user can look into it and will start to understand the process. But in my experience of just doing quick patches on my private repos (where I do multiple small commits a day so patching an earlier commit is relatively common), a conflict rarely ever happens. I think I've run into it once in my many years of dev.

So for the majority of users, they wouldn't have to even know about rebase until they have quite a bit of experience with git (and programming in general). It's a better learning curve, especially considering Git is now being taught to beginner programmers.

A `git edit` command is not as powerful as `git rebase`, but this is just how UX works. You expose a smaller simpler set of features at the front, and then (if you aren't Apple) allow the users to do more advanced low-level operations if they need to.

Re: Things I wish everyone knew about Git (Part I)

#200

Post by mathstuf » Mon, Jul 04, 2022, 11:43 AM UTC

woojoo666 wrote: post #199

mathstuf wrote: post #197

Earlier quoted context omitted.

That gets complicated. What if there's a merge commit between here and there? How about a conflict? You cannot hide the underlying mechanism of reapplying a set of changes. On that note, I have written something like this, but it is not something I think belongs in the standard toolbox. It is a tool that applies "formatting" fixes to a topic, preserving history topology. However, it requires some automated tool to be…

It would still use rebase in the background. If there's a conflict that happens when reapplying changes, then an error pops up, and the user can look into it and will start to understand the process. But in my experience of just doing quick patches on my private repos (where I do multiple small commits a day so patching an earlier commit is relatively common), a conflict rarely ever happens. I think I've run into it…

I, on the other hand, do something similar, but run into conflicts all the time. Usually when reordering commits or fixing up missed hunks that belong in some older patch. I do conflict resolution dozens of times a week.

I guess we just disagree on how shallow or deep any problems `git edit` tries to hide are in practice and therefore how much convenience it actually saves.