• xmunk@sh.itjust.works
      link
      fedilink
      arrow-up
      5
      ·
      1 year ago

      I would’ve… but mercurial isn’t better.

      As an aside, stop merging into in-progress private branches… it makes the absolute worst conflicts.

      • steph@lemmy.clueware.org
        link
        fedilink
        arrow-up
        0
        ·
        edit-2
        1 year ago

        I’ve had that kind of reaction - on rebases also - and most times it was in fact a code smell pointing to a case of spaghetti code.

        If you get to the point that you fear upstream merges/rebases into your WIP, stop for a second and ask yourself if maybe that might be an issue with too much interpendencies inside the code itself. Code should be as close to an directed acrylic graph as possible. (doesn’t count, I was not speaking of git! :b )

          • steph@lemmy.clueware.org
            link
            fedilink
            arrow-up
            1
            ·
            1 year ago

            A merge from upstream once a day, at the beginning of the day.

            I’m working on a DevOps setting, and even though we’re a small team, we have about two to three changes going through the pipeline a day.

            If you keep your fork too long without syncing, it just get more complicated to merge, and more importantly if you need help from the upstream change author they’ll have moved on to another subject and the change won’t be as fresh in their mind as if you had merged the day after they pushed it.

  • Ilflish@lemm.ee
    link
    fedilink
    arrow-up
    3
    ·
    edit-2
    1 year ago
    • Make Structured Commits by context
    • Make a MR
    • Forgot to Rebase
    • Close MR
    • Rebase
    • Make a MR
    • Forgot to push the Rebase so now all Rebase items are on my MR
    • Close MR
    • Reset Changes
    • Push Rebased Items
    • Make Structured Commits,
    • Forget a file
    • Reset Changes
    • Make a mega Commit
    • Make a MR
    • Pipeline fails
    • aspirate2959@sh.itjust.works
      link
      fedilink
      arrow-up
      2
      ·
      1 year ago

      Which makes a new commit. The old commit before the rebase is still there until it’s garbage collected. Editing a commit in any way changes its hash, turning it into a new commit.

    • nilloc@discuss.tchncs.de
      link
      fedilink
      English
      arrow-up
      1
      ·
      1 year ago

      I’ve said both subversion was better, and worse before for sure. PTSD is making it hard to remember what I’ve said when trying to remove a PSD of mpeg you accidentally committed in the first commit and just noticed as you cloned the repo home and it was 2gb for a 3 page website.

  • ExLisper@linux.community
    link
    fedilink
    English
    arrow-up
    1
    arrow-down
    1
    ·
    1 year ago

    I’ve been using git for 20 years and have no idea how it works. Probably will be the next things I will do a deep dive into.

  • PeriodicallyPedantic@lemmy.ca
    link
    fedilink
    arrow-up
    0
    arrow-down
    1
    ·
    1 year ago

    I stand by my opinion that git should be the what VCS software uses internally and is built on. It’s an API for VCS developers to use. And repon admins.

    Thev actual VCS should have it’s own API and CLI that is intuitive and shouldn’t require understanding the underlying data structure.