4 ms·

It's obvious as soon as you consider that your push will overwrite a ref that's currently checked out in the target's repo workdir. The exact same thing happens

It's obvious as soon as you consider that your push will overwrite a ref that's currently checked out in the target's repo workdir. The exact same thing happens when pushing to local repos. You don't have to make a repo bare to avoid this issue, but it's certainly the easiest way to avoid it altogether when you don't need a workdir on the server side.

Dylan16807 1y ago
It's obvious that it needs to update the ref. It's not obvious that this would cause any problems. You could fix HEAD as part of writing the ref. Automatically managing HEAD is normal git behavior.
- seba_dos1 1y ago
  It's obvious that something non-obvious would have to happen with the workdir behind the user's back. Imagine that you are working with your workdir while someone else pushes something to your repo. Bailing out is the only sane option (unless something else has been explicitly requested by the user).
  - Dylan16807 1y ago
    Nothing has to happen to the workdir if you fix HEAD.
    - seba_dos1 1y ago
      ...except of all the things that rely on the HEAD pointing to another ref now changing their behavior. gbp will by default bail off if HEAD is not on a branch, "git commit" won't update the ref you thought it will cause you're now suddenly on "detached HEAD" etc.
      - Dylan16807 1y ago
        I've never heard of... debian package builder? I don't care if it gets annoyed; if that's one of the biggest issues then that's a good sign for the method. Yes the commit won't be on the branch you want, but you'd get about the same issue if the two repos had a bare upstream. The branch diverges and you need to merge. It's a bit less ergonomic here but could be improved. Git could use branch following improvements in general.
        seba_dos1 1y ago
        > Yes the commit won't be on the branch you want, but you'd get about the same issue if the two repos had a bare upstream. Not at all. The commit would have "landed" on the exact branch you thought it will. How it will be reconciled with a diverged remote branch is completely orthogonal and may not even be of concern in some use cases at all.
        Dylan16807 1y ago
        The situation is almost identical except you don't have a cute name for your new commit. Let's say you add a ref to your detached commit, perhaps local/foo. Then you're looking at a divergence between foo and local/foo. If you had a bare upstream it would be a divergence between origin/foo and foo. No real difference. And if you don't want to reconcile then you don't have to. If git was a tiny bit smarter it could remember you were working on "foo" even after the ref changes.
        seba_dos1 1y ago
        Of course it could, but that doesn't yet mean it should. A checked-out ref is considered to be in-use and not to be manipulated (unless done in tandem with HEAD), not just by "git push" but also other tools like "git branch". It's consistent and, IMO, less surprising than what you propose. It could be an optional behavior configured by receive.denyCurrentBranch, though I don't see a good use-case for it that isn't already handled by updateInstead.
        1y ago

Dylan16807 1y ago

It's obvious that it needs to update the ref. It's not obvious that this would cause any problems. You could fix HEAD as part of writing the ref. Automatically managing HEAD is normal git behavior.

seba_dos1 1y ago
It's obvious that something non-obvious would have to happen with the workdir behind the user's back. Imagine that you are working with your workdir while someone else pushes something to your repo. Bailing out is the only sane option (unless something else has been explicitly requested by the user).
- Dylan16807 1y ago
  Nothing has to happen to the workdir if you fix HEAD.
  - seba_dos1 1y ago
    ...except of all the things that rely on the HEAD pointing to another ref now changing their behavior. gbp will by default bail off if HEAD is not on a branch, "git commit" won't update the ref you thought it will cause you're now suddenly on "detached HEAD" etc.
    - Dylan16807 1y ago
      I've never heard of... debian package builder? I don't care if it gets annoyed; if that's one of the biggest issues then that's a good sign for the method. Yes the commit won't be on the branch you want, but you'd get about the same issue if the two repos had a bare upstream. The branch diverges and you need to merge. It's a bit less ergonomic here but could be improved. Git could use branch following improvements in general.
      - seba_dos1 1y ago
        > Yes the commit won't be on the branch you want, but you'd get about the same issue if the two repos had a bare upstream. Not at all. The commit would have "landed" on the exact branch you thought it will. How it will be reconciled with a diverged remote branch is completely orthogonal and may not even be of concern in some use cases at all.
        Dylan16807 1y ago
        The situation is almost identical except you don't have a cute name for your new commit. Let's say you add a ref to your detached commit, perhaps local/foo. Then you're looking at a divergence between foo and local/foo. If you had a bare upstream it would be a divergence between origin/foo and foo. No real difference. And if you don't want to reconcile then you don't have to. If git was a tiny bit smarter it could remember you were working on "foo" even after the ref changes.
        seba_dos1 1y ago
        Of course it could, but that doesn't yet mean it should. A checked-out ref is considered to be in-use and not to be manipulated (unless done in tandem with HEAD), not just by "git push" but also other tools like "git branch". It's consistent and, IMO, less surprising than what you propose. It could be an optional behavior configured by receive.denyCurrentBranch, though I don't see a good use-case for it that isn't already handled by updateInstead.
        1y ago