git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: Hilco Wijbenga <hilco.wijbenga@gmail.com>
Cc: Thomas Rast <trast@student.ethz.ch>, Git Users <git@vger.kernel.org>
Subject: Re: Your branch and 'origin/master' have diverged
Date: Tue, 14 Aug 2012 11:49:55 -0700	[thread overview]
Message-ID: <7vlihh9ulo.fsf@alter.siamese.dyndns.org> (raw)
In-Reply-To: <CAE1pOi2DZNkYYwkH1MFh0m708T=DEdJawZCQgvk1HTGrqjkz2w@mail.gmail.com> (Hilco Wijbenga's message of "Tue, 14 Aug 2012 11:32:54 -0700")

Hilco Wijbenga <hilco.wijbenga@gmail.com> writes:

> I suppose I'm not entirely clear on how this two step process is
> "safer". Doing "git fetch" would seem to be harmless, right? So the
> problem is with "git merge" but master should always be "behind"
> origin/master so that "git merge" should just FF to origin/master
> which *should* be completely safe. Does that make sense? Especially
> given our use of master as an integration branch?
>
> [Given the trouble I have with getting people to use Git properly, I
> prefer things as simple as possible. :-) ]

Between the two procedures Thomas gave you, "fetch & rebase" is
safer than "fetch & reset --hard", exactly because it does not have
to rely on the validity of your "which should always be behind"
claim.

If it is behind, there won't be any difference, but if it is *not*,
the user will notice and won't lose his work on 'master' (which you
may argue that he shouldn't have done).  "rebase" will notice it.

The key for a procedure to be safe is not having to rely on the
claim of users such as "my history *should* always and already be
behind", and not silently lose information when these *should*s are
violated for whatever reason.  After all, if all these *should*s
were true, the user wouldn't have been having problems in the first
place and posting to the list asking for help in the first place ;-)

  reply	other threads:[~2012-08-14 18:50 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-08-13 19:58 Your branch and 'origin/master' have diverged Hilco Wijbenga
2012-08-14  8:27 ` Thomas Rast
2012-08-14 17:04   ` Hilco Wijbenga
2012-08-14 17:19     ` Junio C Hamano
2012-08-14 18:32       ` Hilco Wijbenga
2012-08-14 18:49         ` Junio C Hamano [this message]
2012-08-14 20:12         ` Thomas Rast
2012-08-14 20:49           ` Junio C Hamano
2012-08-15  6:59             ` Thomas Rast
2012-08-15 17:30               ` Junio C Hamano
2012-08-15 18:38                 ` Holger Hellmuth (IKS)
2012-08-15 19:07                   ` Junio C Hamano
2012-08-15 19:22                 ` Junio C Hamano
2012-08-16 16:24                   ` Jeff King
2012-08-16 17:57                     ` Junio C Hamano
2012-08-16 16:21               ` Jeff King
2012-08-14 22:15           ` Hilco Wijbenga
2012-08-14 22:35             ` Junio C Hamano
2012-08-14 16:02 ` PJ Weisberg
2012-08-14 17:07   ` Hilco Wijbenga

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=7vlihh9ulo.fsf@alter.siamese.dyndns.org \
    --to=gitster@pobox.com \
    --cc=git@vger.kernel.org \
    --cc=hilco.wijbenga@gmail.com \
    --cc=trast@student.ethz.ch \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).