Re: Minor annoyance with git push
From: Junio C Hamano <hidden>
Date: 2016-06-15 22:44:11
"Martin Langhoff" [off-list ref] writes:
On Feb 8, 2008 5:44 PM, Martin Langhoff [off-list ref] wrote:quoted
None of these "rejected" branches have anything _new_, they are just stale. Nothing new to say.And I guess the natural follow up question is: would it make sense to tell git pull to do a "merge" for not-checked-out branches where we can safely tell that the resulting "merge" will actually be a fast-forward? Would that be unsafe in any way?
Not "unsafe" in the sense that you would not be losing commit objects, but I'd feel uneasy about that. The fact that the branch tip was pointing at an older commit gets lost, and in your workflow that information is useless, but that does not necessarily mean it is useless for everybody.
Because when I "git checkout bla-stale-branch" to help a fellow developer again, I have to remember to "git merge origin/bla-stale-branch" to get a much needed fast-forward before starting to work.
Perhaps it might make sense to have a checkout hook that notices the branch that is being checked out is meant to build on top of a corresponding remote tracking branch, and performs the necessary fast-forward when that is the case.
[ Or we could be more proactive at deleting unused local heads. But that's a bit of silly maintenance just to keep things tidy, that git could keep tidy ;-) ... ]
Well, git couldn't, unless you tell it "I've pushed out my work, and I am done with helping with this client branch for now", and the way for you to do so is "git branch -d". Perhaps "git branch -d" should be taught to check if the tip of the deleted branch is part of the corresponding remote tracking branch, when "one local branch to track one remote branch" model is used. Its safety to forbid deleting the branch unless it is an ancestor of the "current" branch would not make sense in such a workflow.