Re: Minor annoyance with git push

[Junio C Hamano <gitster@pobox.com>]

"Martin Langhoff" <martin.langhoff@gmail.com> writes:

> On Feb 8, 2008 5:44 PM, Martin Langhoff <martin.langhoff@gmail.com> 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.