From: Michael J Gruber <git@drmicha.warpmail.net>
To: D Herring <dherring@tentpost.com>
Cc: git@vger.kernel.org
Subject: Re: idea: git "came from" tags
Date: Mon, 18 Jan 2010 10:49:38 +0100 [thread overview]
Message-ID: <4B542EB2.5030407@drmicha.warpmail.net> (raw)
In-Reply-To: <hj0nl9$uds$2@ger.gmane.org>
D Herring venit, vidit, dixit 18.01.2010 05:22:
> Actors:
> - public "upstream" repository
> - public "local" repository
> - end users tracking both
>
> Situation:
> - local starts by tracking upstream
> - local makes changes, commits, and sends upstream
> - users now tracking local ahead of upstream
Here I have to ask why. If users choose to track a volatile branch then
they have to live with rebasing or hard resets. If they want something
stable then they should track upstream.
> - upstream makes modified commits
> - local satisfied, wants to reset master to upstream/master
>
> Problem:
> - A merge will perpetually leave two parallel branches. Even though
> there are no longer any diffs, local/master cannot use the same
> objects as upstream/master.
If there are no diffs then, in fact, it can share most objects since
most trees will be the same, only a few commit objects will differ.
> - A hard reset lets local/master return to sharing objects with
> upstream/master; but this may break pulls or cause other problems for
> users.
>
> Proposed solution:
> - Local adds a "came from" tag to upstream/master, leaves a tag on the
> head of local/master, and does a hard reset from local/master to
> upstream/master. When a user tracking local/master does a pull, their
> client detects a non-fast-forward, finds the came-from tag, and treats
> it as a fast-forward.
>
> Basically, this is a protocol to glue a "strategy ours" merge onto an
> existing tree. This way local can cleanly track upstream, with no
> added complexity in the nominal (no local changes) case.
But doesn't that mean that users completely trust you about what they
should consider a fast forward, i.e. when they should do a hard reset?
So, this is completely equivalent to following one of your branches with
+f, i.e. having a public a branch which they pull from no matter what,
and having a private branch which pushes to the public one in case of
fast-forwards as well as in the case when you would use your special tag.
Michael
next prev parent reply other threads:[~2010-01-18 9:51 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-01-18 4:22 idea: git "came from" tags D Herring
2010-01-18 9:49 ` Michael J Gruber [this message]
2010-01-19 5:02 ` D Herring
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=4B542EB2.5030407@drmicha.warpmail.net \
--to=git@drmicha.warpmail.net \
--cc=dherring@tentpost.com \
--cc=git@vger.kernel.org \
/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).