Highlights from Git 2.34

Re:Highlights from Git 2.34 by avar on Tuesday November 16, 2021 @07:14AM (#29239648)

I understand.

Is there any reason you don't (or perhaps you're not aware that you can) use the branch upstream info for this?

Whenever I work on a branch called "topic" I do the equivalent of "git branch --set-upstream-to origin/master" on it. That means that all of:

    git log @{u}..
    git diff @{u}
    git diff @{u}...

Will use that upstream point (@{u} or @{upstream}). What does this have to do with rebase? If you do:

    git rebase -i

It's the same as doing:

    git rebase -i @{u}

That's probably not exactly what you're asking for, i.e. if you've got a history since master of:

    A foo
    B bar
    C !fixup bar
    D !fixup bar

You'd open an editor with A..D with that, whereas you perhaps only want B..D?

[ Parent | on HN ]

Re:Highlights from Git 2.34 by btschaegg on Tuesday November 16, 2021 @11:41AM (#29242663)

You're right, I didn't know about @{u}, thanks for the hint!

> You'd open an editor with A..D with that, whereas you perhaps only want B..D?

That wouldn't be much of an issue for me, but I still tried to implement an option that doesn't rely on my repository having a defined remote.

I quite often start a new local git repository whenever I'm about to start a new experiment (or just scripting some one-off task), and most of these will never get pushed onto a git server. However, even in those cases, my scatterbrain often triggers the "gah, that should have been in a previous commit!" reflex.

By the way: Thank you very much for taking your time and reading all this! :)

Edit: I just re-read the upstream-point thing. Wouldn't that cause a `git push` on `thing` to push directly to `origin/master`?

That also wouldn't be compatible with the workflow we have at work (we use GitLab merge requests)…

[ Parent | on HN ]

Re:Highlights from Git 2.34 by avar on Tuesday November 16, 2021 @06:28PM (#29247581)

You can set "upstream" to another local branch, no remote is required, it's just how it's typically used. Under the hood it's just a way of naming another reference as a divergence point.

I use this extensively with Git(Hub|Lab) (PR|MR)'s. I set the upstream to "master" but push to "topic". The "push.default" docs cover how to have your cake and eat it too there.

[ Parent | on HN ]

Re:Highlights from Git 2.34 by btschaegg on Wednesday November 17, 2021 @04:02PM (#29258793)

The reference to the `push.default` config key clarified a lot of things for me. Thank you very much! :)

[ Parent | on HN ]