"Martin Langhoff" <martin.langhoff@xxxxxxxxx> writes: > On Feb 8, 2008 5:44 PM, Martin Langhoff <martin.langhoff@xxxxxxxxx> wrote: >> 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. - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
