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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.