flipflop

Yeah but one is using Tk and the other doesn't look any better than git log --graph. I think the point of this is that it looks okish and is in the terminal.

I mean ... tig does a lot more, but it also has the revision graph

-edit: typo-

@chrash0 @onlinepersona That's a thing I got told back in university: Technology cannot solve social problems (which is quite frustrating, at least in this case...)

If your colleagues cannot follow guidelines, do not have the common sense to add a description, and completely ignore a form, I think you have a much bigger problem on your hands.

It is a handful, but git log --graph --decorate --all --full-index --color=always | less -R is what I use and I think it's great. Especially after I found the vim mode in my terminal emulator alacritty, and copying the commit hashes got really easy

Nice.
I tend to use the graph made by git, but always feel like it would make my comprehension faster, if I had a properly rendered tree. But then I have been too lazy to use something like gitk.

Looking at the repo, the code being Rust, I feel like I will give it a try the next time I need to view a graph and hopefully the interface matches my requirements.

Doesn't look like it.

the CONTRIBUTING.md document has always existed and contains our guidelines. they know what we’ve agreed upon belongs in a PR, and they simply don’t do it. i’d rather have an empty description than a big stupid ignored form template, because the problem isn’t they don’t know but that they don’t care. that’s a problem that forms, in my experience, don’t fix.

So, a bit like tig? (Screenshots)

When PRs begin with a headline and checklist the GitHub hover-preview becomes useless. When the PR description begins with the summation of the change, it is very useful.

Most of the time I see headlines and check lists in tickets I create or contributions I create PRs for, I feel stifled and like I have to produce something very inefficient or convoluted.

The worst I have seen is when, at work, I had to create bug tickets for a new system in a service desk to a third party, and they had a very excessive, guided, formalized submission form [for dumb users]. More than once, I wrote the exact same thing three times into three separate text boxes that required input. (Something like "describe what is wrong", "describe what happens", "describe how to reproduce".) Something that I could have described well, concise, fully and correctly in one or two sentences or paragraphs became an excessively spread, formalized mess. I'm certainly not your average end user, but man that annoyed me. And the response of "we found this necessary" was certainly not for my kind of users, maybe not even experience with IT personnel.

At work, I'm glad I have a small and close enough team where I can guide colleagues and new team members into good or at least decent practice.

Checklists can be a good thing, if processes can be formalized, can serve as guidance for the developer, and proof of consideration for the reviewer. At the same time, they can feel inappropriate and like noise in other cases.

I've been using horizontal line separators to separate description from test description and aside/scoping/wider context and considerations - maybe I will start adding headlines on those to be more explicit.

Apparently there's an automatic detection of what's supported and a nice degradation. But yes, I don't see a clear advantage wrt tig's UTF-8 graph display.

You aren't treating them like children. That's just projection because you know what you want from a PR and feel like someone telling you what they want is belittling you. Not everybody wants the same nor has the same expectations from a PR.

Guidelines and rules exist for this very reason: people are different. Adding a CONTRIBUTING.md isn't treating somebody like a child and PR templates neither.

I know what you mean. Quite often when I've worked in a project where there is a pull request template, a lot of the time people don't bother to fill it out. However, in an ideal world, people would be proud of the work that they've delivered, and take the time to describe the changes when raising a pull request.

honestly, i hate having a form for my coworkers to fill out. i’ve done it before. i’ve seen it done. i prefer my collaborators, especially in a work environment to do the professional thing and give me enough context to understand the change. i don’t want to have to treat my coworkers like half interested children, but that temptation is always there. a bunch of “did you do your homework?” check boxes feels condescending by proxy. we don’t need a check box for “are the tests passing?” cuz we have automated tests and CI.

i prefer something that just nudges people in the right direction if i can get away with it.

just this week i added a template that read like:

PR guidelines are in CONTRIBUTING.md

This text is meant to be replaced by a short description of your change to inform as to _why_ this change was made to help us triage errors when things go wrong, to provide relevant context to reviewers, and as a matter of due diligence. 

Falls into a weird niche for me - if I'm in a situation where text-only history is not good enough, I'll just use something graphical, rather than some crazy image-in-terminal solution.

Mostly in git I use an alias I wrote/stole ages ago which displays linear history compactly.

This is really cool but I’m unsure why exactly the kitty/iterm image protocols are a requirement.

Is it to display the actual ‘graph’ on the left of the screen? If the terminal does not support image display does it degrade gracefully (e.g. unicode symbols) or does it just not work?

If it only works in terminal emulators with specific image support that seems a tad unfortunate for what otherwise seems a very nice fire-and-forget solution for trawling through commit logs.

branch-1
branch-2
branch-3

Nice to see QEMU was leading on LLM policies. I suspect more open source projects are going to have to come up with some sort of policy on these contributions going forward.

Can't you already SHA-256 a git repo?

like it a lot but the docker setup for knots has bugs

It has some merit but I'll wait until they support ap.

Git is already decentralized. We just need an issue tracker and PR requester that works on activitypub and we should be golden.

After a bit of experimentation, I've managed to find a cleaner solution to enforcing the ticket number in the subject:

module.exports = {
  extends: ['@commitlint/config-conventional'],
  rules: {
    // Enforce scope to match JIRA ticket format like PER-123
    'jira-ticket-rule': [2, 'always'],
    'subject-case': [0],
  },
  plugins: [
    {
      rules: {
        'jira-ticket-rule': ({ subject }) => {
          return [
             subject && subject.match(/[A-Z]+-\d+/),
            'Your subject should contain a JIRA ticket eg PER-123',
          ];
        },
      },
    },
  ],
};

twiice

gitupl

file-dupl

change-dupl

"I know what you were"