On Mon, Dec 01, 2008 at 09:22:43PM -0500, Leo Razoumov wrote:

quoted text
> 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.

quoted text
> (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.

quoted text
> 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@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html