3 ms·

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 call

by avar 5y ago

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?

btschaegg 5y ago
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)…
- avar 5y ago
  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.
  - btschaegg 5y ago
    The reference to the `push.default` config key clarified a lot of things for me. Thank you very much! :)

by avar 5y ago

btschaegg 5y ago

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)…

avar 5y ago
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.
- btschaegg 5y ago
  The reference to the `push.default` config key clarified a lot of things for me. Thank you very much! :)