Re: Minor annoyance with git push

2 messages, 2 authors, 2016-06-15 · open the first message on its own page

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.

Re: Minor annoyance with git push

From: Steffen Prohaska <hidden>
Date: 2016-06-15 22:44:12

On Feb 8, 2008, at 8:48 AM, Junio C Hamano wrote:
"Martin Langhoff" [off-list ref] writes:
quoted
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 just print a warning that there are new commits on the
tracked branch and leave the decision how to proceed to
the user?

	Steffen
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help