On Mon, Dec 01, 2008 at 09:22:43PM -0500, Leo Razoumov wrote:
> I do not think that having a work-flow different from yours deserves a
> "somewhat insane" label. But let us consider the consequences of
a) you are responding to a nearly month-old message. Please read the
rest of the thread where we decide that it is not so insane, and
that the behavior should be configurable with a default of "warn"
at least for now.
b) My comment was not that it is insane simply because it is different
from mine. It is because it creates a dangerous situation (where
dangerous implies changes might be silently lost) which requires
manual intervention to fix, and which the user was given no warning
whatsoever about. It is a direct response to frequent complaints on
the list about users getting bit by this.
> (1) Switch target's current branch to something else (prevent a
> conflict) before pushing and then restore it back after the push
>
> (2) Use git-fetch from the target.
(3) Use git-reset --hard, but set a config variable that says "I know
what I'm doing." You don't even have to do it per-repo, you can do it
per-user.
(4) Push into a non-current branch and merge from the target.
> Method (2) is even worse, because git-fetch provides no control of
> what branches/tags to fetch, it sucks everything in from all branches.
> "git-push", OTOH, can be instructed to be very selective.
Er, what? git-fetch takes a refspec very similar to the ones used by
git-push. The real reason that (2) is not an acceptable solution is that
you can't necessarily connect to the source repo (e.g., it is on your
workstation with no ssh or git server running).
-Peff
--
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
