From: lists@haller-berlin.de (Stefan Haller)
To: avarab@gmail.com (Ævar Arnfjör? Bjarmason)
Cc: matt@mattmccutchen.net (Matt McCutchen), git@vger.kernel.org (git)
Subject: Re: Tools that do an automatic fetch defeat "git push --force-with-lease"
Date: Sat, 8 Apr 2017 19:28:35 +0200 [thread overview]
Message-ID: <1n46fel.1dbwuj6b61w2oM%lists@haller-berlin.de> (raw)
In-Reply-To: <CACBZZX4x0kJVWSkmQa+j6yn-w3m-u8ZiXDPZ60KG+ruvhejqNQ@mail.gmail.com>
Ævar Arnfjör? Bjarmason <avarab@gmail.com> wrote:
> On Sat, Apr 8, 2017 at 5:03 PM, Stefan Haller <lists@haller-berlin.de> wrote:
>
> > Here's a rough proposal for how I would imagine this to work.
> >
> > For every local branch that has a remote tracking branch, git maintains
> > a new config entry branch.*.integrated, which records the sha1 of the
> > last upstream commit that was integrated into the local branch.
>
> Can you elaborate on what "integrate" means in this context?
>
> In some ways the entire point of this feature is that you're trying to
> push over history that you don't want to integrate.
>
> I.e. you're trying to force push your unrelated X over remote history
> A, but not more recent arbitrary history B based on A which someone
> may have just pushed.
>
> I'm having a hard time imagining how anything merge/rebase/whatever
> would place in branch.*.integrated wouldn't just be a roundabout way
> of recording the info we now record via the tracking branch, or in
> cases where that's auto-updated for some reason having another
> tracking branch as my "[PATCH] push: document & test
> --force-with-lease with multiple remotes" suggests.
It doesn't matter whether the history you are overwriting is arbitrary,
or whether the new history you are pushing is related or unrelated to
what you are overwriting. What matters is whether you are aware of what
you are overwriting.
I want to record all cases where the local branch is brought up to date
with the tracking branch (or vice versa), i.e. mostly push and pull,
because I know that after pushing or pulling, my local branch is up to
date (in some way) with the tracking branch. If I then rewrite the local
branch, I know it is safe to push it *if* the branch on the remote is
still in the same state as what I recorded for last push or pull.
If the tracking branch is updated by fetch though, then my local branch
is not brought up to date with the remote branch, so I may be
overwriting stuff that appeared on the remote without me being aware of
it.
It may well be that there are better names then "integrate"; suggestions
welcome.
Your suggestion to use a second remote doesn't seem like a satisfactory
solution to me, firstly because it's extra work and complexity for the
user, and second because it doesn't solve the problem of working with
more than one local branch (pulling one branch amounts to a fetch for
the other).
--
Stefan Haller
Berlin, Germany
http://www.haller-berlin.de/
next prev parent reply other threads:[~2017-04-08 17:30 UTC|newest]
Thread overview: 49+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-04-08 2:15 Tools that do an automatic fetch defeat "git push --force-with-lease" Matt McCutchen
2017-04-08 7:24 ` Stefan Haller
2017-04-08 7:35 ` Ævar Arnfjörð Bjarmason
2017-04-08 9:29 ` Jeff King
2017-04-08 10:10 ` Jakub Narębski
2017-04-08 11:41 ` [PATCH] push: document & test --force-with-lease with multiple remotes Ævar Arnfjörð Bjarmason
2017-04-09 9:55 ` Simon Ruderich
2017-04-09 11:40 ` Ævar Arnfjörð Bjarmason
2017-04-17 3:56 ` Junio C Hamano
2017-04-19 9:22 ` [PATCH v2] " Ævar Arnfjörð Bjarmason
2017-04-08 21:54 ` Tools that do an automatic fetch defeat "git push --force-with-lease" Jacob Keller
2017-04-08 22:13 ` Jeff King
2017-04-08 22:21 ` Jacob Keller
2017-04-09 8:38 ` Stefan Haller
2017-04-09 8:49 ` Jacob Keller
2017-04-09 11:00 ` Stefan Haller
2017-04-10 8:08 ` Jacob Keller
2017-04-10 9:58 ` Ævar Arnfjörð Bjarmason
2017-04-10 23:33 ` Jacob Keller
2017-04-11 8:51 ` Junio C Hamano
2017-04-12 9:11 ` Stefan Haller
2017-07-06 18:56 ` [PATCH] push: disable lazy --force-with-lease by default Junio C Hamano
2017-07-06 19:38 ` Stefan Beller
2017-07-06 22:39 ` Junio C Hamano
2017-07-06 22:42 ` Stefan Beller
2017-07-10 22:32 ` Stefan Beller
2017-07-07 9:24 ` Stefan Haller
2017-07-07 9:42 ` Jeff King
2017-07-07 9:54 ` Ævar Arnfjörð Bjarmason
2017-07-07 15:15 ` Junio C Hamano
2017-07-15 10:45 ` Ævar Arnfjörð Bjarmason
2017-07-17 17:28 ` Junio C Hamano
2017-07-07 9:39 ` Ævar Arnfjörð Bjarmason
2017-04-11 12:37 ` Tools that do an automatic fetch defeat "git push --force-with-lease" Stefan Haller
2017-04-11 12:37 ` Stefan Haller
2017-04-10 18:31 ` Jeff King
2017-04-11 12:37 ` Stefan Haller
2017-04-11 12:50 ` Jeff King
2017-04-12 9:11 ` Stefan Haller
2017-04-09 8:38 ` Stefan Haller
2017-04-09 8:46 ` Jacob Keller
2017-04-08 8:25 ` Jacob Keller
2017-04-08 9:31 ` Jeff King
2017-04-08 15:03 ` Stefan Haller
2017-04-08 22:03 ` Jeff King
2017-04-08 15:03 ` Stefan Haller
2017-04-08 16:04 ` Ævar Arnfjörð Bjarmason
2017-04-08 17:28 ` Stefan Haller [this message]
2017-04-12 9:11 ` Stefan Haller
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=1n46fel.1dbwuj6b61w2oM%lists@haller-berlin.de \
--to=lists@haller-berlin.de \
--cc=avarab@gmail.com \
--cc=git@vger.kernel.org \
--cc=matt@mattmccutchen.net \
/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).