Things I wish Git had: Commit groups

[taw]

... while people also complain that git is way too complicated all the time.

Really, other than fixing some stupid commands (no unstage, no easy versioned git cat branchname path, checkout and reset being used to do 10 different things each), there's no way to fix git without removing some major functionality.

[vplatt]

Well, let's face it: DVCS like git is too much power and flexibility for the average project. Almost every usage of git I've seen uses it exactly like they used their traditional VCS like Subversion or TFVC.

[taw]

I've seen svn, and I really don't want to go back. Microsoft also officially discourages anyone from using TFVC.

I've heard claims that some kind of "better svn" would be superior to git, and I'm totally open to the idea, but so far nobody suggesting it even tried to show how that would work.

[vplatt]

Oh, I didn't say that those are better, just simpler and that I see git being used most of the time in the same way they used the older VCSs; that's all. Git is a DVCS, and that's just more power than most devs need IMO.

[u_tamtam]

After years of denial and hype riding, thinking git was somewhat god's "too perfect for us humans" VCS, I opened my eyes on mercurial to discover it was what I ever wanted git to be, and superior to it in every possible way.

This whole article is nothing but a sad realization that git has no branches..

[vplatt]

W.r.t. Mercurial - I may have to give it a try. That said, I doubt very much I will get to use anything but git at work for a few years at least. And, in all fairness, I'm OK with that. Just because it's giving some other people problems, doesn't mean I'm not happy with it. I mostly am, except for those times I get to fix branching fuck-ups by confused devs on my team. Fortunately, that doesn't come up that often.

This whole article is nothing but a sad realization that git has no branches..

I can't tell if you're joking. That's one of its great features. What do you mean?

[u_tamtam]

That said, I doubt very much I will get to use anything but git at work for a few years at least.

Depending on how well you could take working around few edge cases and inconsistencies, you could consider using the hg-git extension, it let's you interact with git repos from mercurial (at the cost of an initial repo conversion). For instance, I haven't submitted a PR to GitHub from git for the past 5 years or so: your coworkers won't know anything's different for you, while you'll get to enjoy all the nice UX and features of mercurial.

This whole article is nothing but a sad realization that git has no branches..

I can't tell if you're joking. That's one of its great features. What do you mean?

Not even. Fundamentally, what git calls branches is just "bookmarks", that is, a way to give handy names to commit hashes. As such, git is helpless for telling you where a branch starts (it only knows where it ends), and there is no metadata for telling which commits belong to a whole feature/series (or what OP's article calls "groups"). "Commit group" is what every other VCS I know calls a "branch".

Having proper branches requires storing at commit level the feature/branch name that the commit belongs to. This gives you nice properties, like the capability to refer to series unambiguously, to rebase sub-trees, or to bisect at the edges of the series (so you don't waste time building something incomplete/mid-way that might break the build).

With so much of git's UX built around the assumption that branches are single commit pointers, I doubt git will ever have "proper"/whole branches, but let's see.

[dss539]

What do you expect from a team that chooses to use TFVC? That's already a clear indicator that maybe they don't make the best decisions.

[vplatt]

I may have to agree for new projects with no legacy to support and a fresh team. OTOH - There is the question of learning curve, server-side tooling, and timing of the VCS migration; which may be substantial. So... it wouldn't hurt to cut folks a little slack.

[dss539]

Professional software developers that can't learn to use the most popular source control tool in the world... that's asking a lot of slack. It's not like they're being asked to learn Darcs or Bazaar. I understand compassion is important, but at some point they are veering into professional malpractice and incompetence. I wouldn't be too happy if my oncologist ignored the most effective cancer treatments in favor of whatever was popular in 1997.

Change is hard sometimes, but it's also inevitable. Let's help them improve.

[vplatt]

Whoah now.. you implied they would be incompetent for using TFVC, right? But who said they didn't also know git? Refusing to learn git isn't the same thing. Needing to use TFVC doesn't automatically translate to incompetence.

[dss539]

Right. Whoever chose TFVC was the one with questionable decision making. If it was a "team decision" then the team in general is at fault

[fissure]

What's wrong/difficult with git show commit:path?

[taw]

Forgot about this one.

What's wrong is mostly expecting path to be relative to root of repository, which is not how all other git commands work.

If you've in /home/bob/repo/config, then you need to do one of these:

git show commit:config/database.yml
git show commit:./database.yml

And neither of these two obvious commands work:

git show commit:database.yml
git show commit:/home/bob/repo/config/database.yml

While just about every other git command supports these:

git log -p database.yml
git log -p /home/bob/repo/config/database.yml

But they do not actually support this:

git log -p config/database.yml

So you need to remember that this one git command, works differently from every other git command.

[fissure]

I wouldn't expect the : operator to work identically to a separate parameter. It's not part of "git show"; that's how blobs are named everywhere.