Follow

code review metadata & comments should have been baked into distributed version control systems from the start and now we get to pay for this mistake forever.

(let's throw issue tracking in there while we're at it.)

Show thread

the point here being not that one single piece of software needs to do all this stuff, but rather that the data is so integral to what a piece of code _is_ (just like the history!) that capturing it has effectively foreclosed most of the possibilities of the dvcs as an escape valve from monopoly control over the software development platforms.

Show thread

you should, ideally, be able to treat code hosting and the VCS format itself as a simple pipe between whatever tooling suits your purposes. instead... well, here we are.

Show thread

@brennen agreed. I think you could say this is an important part of a larger problem, that git et al have specific use cases baked in

@brennen the Linux kernel folks on the whole don't seem to believe in tool support for keeping track of bugs, or even in keeping honest history about how development actually happened (cf the concept of the "perfect patch"). I honestly believe the Linux kernel developer mindset is to throw away any information that suggests things were ever not perfect

@jamey @brennen I used to think that if course you want an honest history, because of the value for others to see how a person works.

But lately while working on only slightly larger projects, I've come to see the value of a commit that shows the *intent* of the change rather than the messy process that led there. The messy history is fun for archival purposes, but the tidy history is far more useful when tracking down why things are the way they are without getting distracted by accidental changes. The messy history can be impossible to review, whereas the neat history can tell a story you can follow.

Ideally you'd have both. I would love for a PR to be merged as a neat squashed commit or tidy merge, with the messy history as a second parent, the tooling allowing me to choose which one is relevant for my current task.
@brennen @jamey It's can be super annoying to hear someone tell a story of what they did last seek, where they interrupt themselves, backtrack, suddenly laugh inexplicably and go "er, I guess you had to be there", and then suddenly stop and you're supposed to understand that the story has been told and there was a point in there somewhere.

Listening to a seven-year-old trying to explain something is a lot like that, and I prefer to have a structured adult tell the story. When I write my code I'm a seven-year-old, and when I tidy it up for PR I'm an adult.

github being positively awful at presenting commit history doesn't help either, that's why we squash almost every PR at work. Sadly that leaves a lot of relevant information in the PR, and on occasion I've had to bring back the PR branch to help automatically resolve some merge conflicts.

@clacke @brennen I agree that both views are useful. I was going to say more but then I realized I've already said everything I would have, here: jamey.thesharps.us/2016/05/19/

To your points, I think I particularly want to emphasize where I wrote that "we shouldn’t design our processes around the UX failures of our tools if we can just fix the tools instead."

(The first blog link from that post is broken; it should now go to sage.thesharps.us/2013/05/08/p )

@clacke @jamey

> Ideally you'd have both. I would love for a PR to be merged as a neat squashed commit or tidy merge, with the messy history as a second parent

i've been using gerrit at work for some time now, which has been a window into just how nice carefully authored units of history can be, and in fact offers something like this: changes are a single commit, but you can if needed go back and find all the patchsets that they were assembled from.

@clacke @jamey (gerrit has many other problems, but the underlying model that it grafts on top of git is pretty interesting. it also stores some amount of review metadata in the repo using git-notes, which is the thing that prompted my original post.)

@brennen @jamey Yeah, working with gerrit a few years ago probably helped steer my mind in this direction. The insistence on a single commit is frustrating, but the rebase flow focuses on the neat merge model.

Gerrit together with OpenStack Zuul and an hours-long merge queue taught me a lot about git surgery, to help a pending merge queue merge cleanly. 😁

Gerrit shows merge commits in a very smart way, and I miss that when I'm on github/lab/tea.

@brennen I'd like to think it's not necessarily too late. And there exists at least one example of tooling like this already (fossil), but yeah, we're all well and truly captured by chains of our own making. And it's not just tools. It's our institutions and the values we decide they should stand for. It was interesting to watch Python just slide over to GitHub because it revealed a little about the values of the institution.

@brennen

so,

I know you're actually talking about the systemic issue of nobody having had something like this available (or a number of other things) and how that's affected running projects up to now

but, there are apparently already ways to keep issues in a repository,
and I've been considering a project to try to integrate one with #gitea

dist-bugs.branchable.com/softw

there seem to be a number of people who want this, so even if I don't get far i'd assume others will be trying similar things

@Valenoern @brennen wow, thanks for sharing this. Looked at a few and they seem very interesting.

@brennen "but brennen," a voice from no where says, "don't you agree, that worse is better?"

@brennen "having something, even if it only implements part of the solution surely beats having nothing"

sweeps darcs and fossil under the carpet

Sign in to participate in the conversation
Mastodon

Server run by the main developers of the project 🐘 It is not focused on any particular niche interest - everyone is welcome as long as you follow our code of conduct!