3 ms·

"Pushing locally"...what? How is this different from fetch? The author tried to explain this distinction and I read it several times but I still don't get it.

mst 4y ago
From my reading, the crucial difference from a QoL POV is not needing to have the branch you're targeting checked out like pull/merge requires.
detaro 4y ago
> git fetch foo updates your local origin/foo, not foo. Pushing locally pushes to foo.
myme 4y ago
Yes. This one was hard for me to explain. I've discussed it with others too and might try to rephrase it again in the post. As far as I know, there's no other git command that let's you (as easily) change which commit a local branch is pointing to without first checking it out. And "without checking it out" is the crucial part. If, as the example tried to explain, you have a huge piece of software (think C++ monorepo) that takes ages to build, unnecessary switching of files back and forth easily messes up build tools relying on modified timestamps to determine what needs to be rebuilt. (Sure, blame the build system, but that might not be a trivial fix.) So, in that example, the use-case is to make sure the branch is up to date before switching to it. (And you could of course argue that why don't you just create a new branch, which is also a completely valid approach).
dreamcompiler 4y ago
I think I have it now: Both git fetch and ordinary git push update refs/remotes from refs/heads but they don't change anything under refs/heads at all. Ordinary git pull will update refs/heads/<currentbranch> because by default it merges/rebases the current branch after fetching, but that's not always desirable when branch switching is expensive. Pushing locally updates refs/heads/<somebranch> from refs/remotes/<somebranch> without switching to that branch. Now I also understand @myme's sentence "In fact, in order to properly “push to the local repository” it’s necessary to invoke a git fetch first to ensure that the remote tracking branches are updated." Thanks to @myme and other responders in this thread!
- myme 4y ago
  Yes! Right on the money! Thanks for coming back to state that it makes sense to you now.

mst 4y ago

From my reading, the crucial difference from a QoL POV is not needing to have the branch you're targeting checked out like pull/merge requires.

detaro 4y ago

> git fetch foo updates your local origin/foo, not foo. Pushing locally pushes to foo.

myme 4y ago

Yes. This one was hard for me to explain. I've discussed it with others too and might try to rephrase it again in the post. As far as I know, there's no other git command that let's you (as easily) change which commit a local branch is pointing to without first checking it out. And "without checking it out" is the crucial part. If, as the example tried to explain, you have a huge piece of software (think C++ monorepo) that takes ages to build, unnecessary switching of files back and forth easily messes up build tools relying on modified timestamps to determine what needs to be rebuilt. (Sure, blame the build system, but that might not be a trivial fix.) So, in that example, the use-case is to make sure the branch is up to date before switching to it. (And you could of course argue that why don't you just create a new branch, which is also a completely valid approach).

dreamcompiler 4y ago

I think I have it now: Both git fetch and ordinary git push update refs/remotes from refs/heads but they don't change anything under refs/heads at all. Ordinary git pull will update refs/heads/<currentbranch> because by default it merges/rebases the current branch after fetching, but that's not always desirable when branch switching is expensive. Pushing locally updates refs/heads/<somebranch> from refs/remotes/<somebranch> without switching to that branch. Now I also understand @myme's sentence "In fact, in order to properly “push to the local repository” it’s necessary to invoke a git fetch first to ensure that the remote tracking branches are updated." Thanks to @myme and other responders in this thread!

myme 4y ago
Yes! Right on the money! Thanks for coming back to state that it makes sense to you now.