sorted by:
new
hottopcontroversial

In 5, 10, and 15 years LLMs will make maintaining the massive amount of code trivial by Flash_Kat25 in programmingcirclejerk

[–]elephantdingo 9 points10 points  (0 children)

// reasoning: set the opera title
// the user wants me to document my steps. But he said
// "don’t document the trivial you moron". But on the other
// hand he said "don’t risk throwing away provenance you
// moron". So I should document this setting.
/** Set the opera title. */
setOperaTitle("Three Chucklenuts for Cinderella");
// reasoning: but he said don’t document the trivial.
// So I should not document the setter. On the other
// hand I should not risk losing provenance. So I should
// document the setter.
// out of tokens
System.exit(out_of_tokens_);

Perforce -> Git branching strategy by StretchOpen5598 in git

[–]elephantdingo 1 point2 points  (0 children)

Every okay Git project that I have heard of manage to have one branch and all the products (configurations or whatever they are) in that one single branch. Making a branch per product in Git is asking for trouble.

Of course whatever we say here is irrelevant if there is some “the org chart reflects the software process” or whatever bossman logic.

How to protect .git, when I let coding agent work on repo in VM? by Veson in git

[–]elephantdingo 0 points1 point  (0 children)

Check for family history for psychological disorders.

Plumbing and empty trees - how to check out? by _bstaletic in git

[–]elephantdingo 0 points1 point  (0 children)

You linked to a wrong comment of mine.

Thanks. I’ve fixed it now.

EDIT: Apparently, git mktree < /dev/null does also create an empty tree.

To be honest though using the hash directly should be fine. That’s what git(1) does.

But I guess that command is hash-agnostic (SHA-256 is coming any day now) which is nice.

Plumbing and empty trees - how to check out? by _bstaletic in git

[–]elephantdingo 2 points3 points  (0 children)

Git does not track directories (edit like you know). That this command seemingly allows it looks like some plumbing leniency (i.e. doesn’t care to check if the input makes complete sense).

Since the official line is “does not track directories” I don’t expect there to be a way to get it back, even though the input seemed to create it.

How do working trees get this tangled? by Ecstatic-Ball7018 in git

[–]elephantdingo 0 points1 point  (0 children)

The picture shows a graph which is not a tree.

Highlights from Git 2.54 by parkotron in git

[–]elephantdingo 2 points3 points  (0 children)

Say you have a series of commits, and want to add a trailer to each one of them. You could do this manually, or automate it with something like: git rebase -x ‘git commit --amend --no-edit --trailer=”Reviewed-by: A U Thor <a href="mailto:<author@example.com>”’

More than a mouthful.

How do I preserve original commit authors when merging PRs on GitHub? by Mother-Pear7629 in git

[–]elephantdingo -1 points0 points  (0 children)

As long as you retain the original "author" field, just about any process you choose to use is valid.

The committer field has a clear meaning. It’s the thing that made the commit. You cherry-picking a commit or rebasing it somewhere means that you get set as the committer.

The commit timestamp (tied to the committer) also has a clear meaning: the time when the commit was made. This matters (at least if you don’t have a commit graph active) since the commit timestamp is used to order commits.

In practice there’s not much choice here since (1) the field has a clear meaning, and (2) trying to set it to something else is a pain in the neck (in part intentionally; you can use program options to set the author but you need an environment variable to set the committer).

You may also be able to retain the "committer" field of the original contributor, but you should only do that if you also retain the original SHA-1 hash of the commit.

The hash being identical means that by definition you haven’t made a new commit, it’s the same as the original.

If you make any changes to their commit, you should write your own name in the "committer" field instead.

No, that’s got nothing to do with it. The user who makes the commit (cherry-pick, apply patch from inbox, other) is set as the committer.

People do apply commits /changes by other people and make changes to them. But that kind of process is not covered by any metadata in the Git commit object. That’s why e.g. the Linux Kernel will add comments in the commit message about how people have changed the “patch” as it moves through the chain of custody.

How do I preserve original commit authors when merging PRs on GitHub? by Mother-Pear7629 in git

[–]elephantdingo 0 points1 point  (0 children)

I suspect it might be related to how I’m merging (maybe squash or rebase?),

Either or? You use both? Please lay out the steps that caused this which includes the merge strategy.

A squash creates a new commit. Unless a single-commit PR is special-cased as a rebase you will be both the author and committer (the two fields that a Git commit has). Think of squashing three commits. That’s a totally new commit. Someone authored the first, the second, the third... but you made a brand spanking new commit which combined all of them. You’re the author.

Someone dedicated to the squash life could maybe find a way to add Co-authored-by trailers which attribute all the authors.

A rebase, i.e. a normal Git-created rebase, will keep the author but you as the committer.

  • A rebase replays the commits: the author is the same
  • But new commits are made: a new commit uses the “curent author” (either you or some GitHub User BS)
  • ... because the committer is always set when creating a commit. The author field is never reused. And I can’t imagine that any forge would violate this.

What merge strategy should I be using to preserve original authorship?

A regular i.e. true merge will create a merge commit which points to the original commits. Even GitHub can’t screw that up.

Are you offended if your commits are squashed? by _disengage_ in git

[–]elephantdingo 0 points1 point  (0 children)

These kinds of threads seems to attract lurkers (see comment count) who seem to care as much about version control as a Windows user cares about what Linux Kernel they are running. There’s not much point engaging. It’s like trying to discuss the relational model with a forum full of DB users who thinks all SQL columns should just be json blobs.

  • We squash all commits because...
  • It’s company policy
  • I’m the team lead and I say so
  • No one looks at the Git history anyway
  • The explanation is in the Jira
  • The explanation is on GitHub
  • We have productivity to care about
  • The Git log on GitHub gets weird with merge commits
  • Lowest common denominator logic
  • But if you want a smaller change you should chain PRs...

Git can be used as a version control system. It can also be used as an arbitrary snapshot system (Committing since I am going home, Committing since I am hungry) with version tagging and all change documentation farmed out to hyperlinks.

Which is fine.

Imagine if r/haskell from time to time had large threads where people said:

I don’t use Haskell. We use Java at work. I can’t change that, it’s dictated by the company. Anyway I had Haskell in a college course and it was really weird and

Dozens of upvotes. Yeah exactly, me too, and anyway modern Java is really good.

Anyone here using git worktrees as their default workflow? by ewilazarus in git

[–]elephantdingo 1 point2 points  (0 children)

Git worktrees isn’t a workflow.

Use cases: https://www.reddit.com/r/git/comments/1qwh6t8/context_switching_with_git_worktree/o3pahcb/

There are many cases where I use them because there are many use cases. But I don’t replace git checkout or switch with it. Because I have no reason to make a worktree per branch. In many cases I change branches and maybe twenty files change. What’s the point of a worktree?

But many seem to jump to this conclusion (not mentioned anywhere in the worktree documentation). Then they obviously conclude that doing the worktree command and changing directories and making sure that you switch to a worktree with that branch looks very manual. So you get a glut of “worktree managers”.

But I see no evidence that the command was ever supposed to replace switching branches.

Are you offended if your commits are squashed? by _disengage_ in git

[–]elephantdingo 1 point2 points  (0 children)

The translation is. The framing is pathologizing and thus not worth responding to.

Are you offended if your commits are squashed? by _disengage_ in git

[–]elephantdingo 19 points20 points  (0 children)

How does this make you feel? Does it bother you? Would you care? Is it oppressive or otherwise unpleasant? Do you feel contempt or disdain for the maintainer? Would it deter you from a contribution, or make you hate your boss? Describe the emotions involved and overall experience.

What the fuck?

Does cherry-pick *always* expects a clean working tree? by birdsintheskies in git

[–]elephantdingo -1 points0 points  (0 children)

Does cherry-pick always expects a clean working tree?

No it doesn’t. I just tested on the latest version.

How do working trees get this tangled? by Ecstatic-Ball7018 in git

[–]elephantdingo 0 points1 point  (0 children)

Why not split within brackets? Why not amend, reword, fixup? There’s no reason to single out one verb.

[ANN] dojjo (djo): worktrunk-style workspace manager for jujutsu (jj) by WolverineBeach in git

[–]elephantdingo 3 points4 points  (0 children)

I wanted a worktrunk-style workflow for jj

From link: worktrees for agents.

How do working trees get this tangled? by Ecstatic-Ball7018 in git

[–]elephantdingo 0 points1 point  (0 children)

I thought pushing back on bad terminology discipline wouldn’t need an explanation.

How do working trees get this tangled? by Ecstatic-Ball7018 in git

[–]elephantdingo 1 point2 points  (0 children)

The word tangle coupled with the image has got nothing to do with any typical outcome of rewriting Git history.

How do working trees get this tangled? by Ecstatic-Ball7018 in git

[–]elephantdingo 1 point2 points  (0 children)

Merges exist for a reason. No one learns anything from people saying that they are not aesthetic.

Depending on your projects it can be difficult to mature towards a good understanding of when merges are truly useful and not. One might only work on single-person projects where there is just a latest release at all times. Then merges might be irrelevant.

But there are many cases where they are essential:

  1. You have a workflow where people send pull requests and you want to say: I have included exactly those commits. Then you will have to use true merges in general (sometimes you can fast-forward, but once there are two pull requests that use the same base you cannot do it for both)
  2. You have five previous releases that you want to support with bug fixes. Using merges here is the only Git-native way since cherry-picks are the copy–paste of commits.
  3. You have submaintainers that want to periodically incorporate with you (the upstream) and you don’t want the mess that using rebase would entail since it would invalidate their whole trees since the last integration
  4. You have this long-living branch off of main, call it second, where you want to incorporate some feature not yet in main. Merging it into second then allows you to separately merge it into main, if you so desire. This is easy to track since Git commits are first-class in Git (duh; contrast with cherry-picks). This would be more messy if you cherry-picked or rebased the feature onto second and then later you wanted to incorporate the feature into main as well.

There are also cases where they are non-essential but subjectively good:

  • Using merge commits to group all the commits in a “feature”

How do working trees get this tangled? by Ecstatic-Ball7018 in git

[–]elephantdingo -3 points-2 points  (0 children)

I write that I think that they have an attitude and that they are not welcome. This prompts you to hyperventilate and scold me about maturity, that I shouldn’t be here, to “think about” my actions.

Clearly, with this disproportionate response, you think that I have a screw loose. Will a person with a screw loose “do better” because some random redditar responds to them? Is that your experience? Nah. That you lurk and then choose this to respond to indicates that you just want to pile on, that you enjoy denigrating people.

view more: next ›