Bryan Donlan <bdonlan@xxxxxxxxx> writes:
> If the local "dev" is meant to just track the remote, you really ought
> to avoid doing anything very involved in it (unless you're planning on
> merging something into it and pushing the result, that is!). If
> there's no local changes, then you can just pull with impunity, and
> let it fast-forward - or use git merge or git rebase if you've already
> fetched and don't want to spend the few seconds it takes to ask the
> server if there's anything new :)
With git that is not ancient (i.e. v1.5.0 or newer), there is no reason to
have local "dev" that purely track the remote anymore. If you only want
to go-look-and-see, you can check out the remote tracking branch directly
on a detached HEAD with "git checkout origin/dev".
Which means that the only cases we need to make it convenient for users
are to handle these local branches that "track" remote ones when you do
have local changes, or when you plan to have some.
If you do have local changes on "dev" that is marked to track the remove
"dev", and if you are on a branch different from "dev", then we should not
do anything after "git feftch" updates the remote tracking "dev". It
won't fast forward anyway, and we do not need to talk about this case in
this thread.
That leaves only one case. Your "dev" forked from the remote "dev"
sometime in the past, is marked to "track" the latter, but you haven't
done anything on the branch. Should we have a convenient way to
fast-forward it after a "git fetch" that updates the remote "dev"?
I'd actually say we should give users a convenient way to remove the local
branches that are marked to track remote tracking branches but do not have
anything interesting on their own (iow when they can fast-forward to their
corresponding remote tracking branches), if the true motive behind this
thread is "'git push' will notice 'dev' that is left behind and gives
clutter".
Yes, you may earlier thought about building on top of the remote branch,
but you haven't done anything other than creating a branch, you left it
without doing anything interesting and kept it behind.
If you later decide to revisit whatever you wanted to work on by forking
from that branch, you can "git checkout -t -b dev origin/dev" at that time
to recreate the branch just as easily as you would do "git checkout dev",
and between the time you notice that you have a stale "dev" that does not
have anything interesting and the time you decide to really work on the
topic again, you may be better off not cluttering "git branch" output with
such useless local branches.
So how about "git branch --prune --remote=<upstream>" that iterates over
local branches, and if
(1) it is not the current branch; and
(2) it is marked to track some branch taken from the <upstream>; and
(3) it does not have any commits on its own;
then remove that branch? "git remote --prune-local-forks <upstream>" is
also fine; I do not care about which command implements the feature that
much.
The only case I think would be useful to keep a local branch that does not
yet have a commit on its own happens in this workflow:
(1) You notice a bug sometime in the past (or at the tip) of the "dev"
branch you see in the remote;
(2) You bisect, find a faulty commit, and fork your "dev" from that
commit, so that you can work on fixing that single bug, later to be
merged back (because you anticipate the fix would be an involved
series);
(3) But you haven't had a chance to work on the fix yet.
Your fork point in this workflow has a meaning: this is the broken commit
I fix with my commits immediately after it. It should not be rebased nor
fast-forwarded.
But in that case, you shouldn't mark "dev" as tracking the remote's "dev"
to begin with, so the hypothetical "branch --prune --remote=<upstream>"
would not touch such a "fork to address old issues", and we'd be safe.
--
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
