git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: "Shawn O. Pearce" <spearce@spearce.org>
To: Theodore Tso <tytso@mit.edu>
Cc: Junio C Hamano <gitster@pobox.com>,
	Johannes Schindelin <Johannes.Schindelin@gmx.de>,
	git@vger.kernel.org
Subject: Re: What's cooking in git/spearce.git (topics)
Date: Tue, 23 Oct 2007 00:46:57 -0400	[thread overview]
Message-ID: <20071023044657.GC14735@spearce.org> (raw)
In-Reply-To: <20071023043321.GC27132@thunk.org>

Theodore Tso <tytso@mit.edu> wrote:
> On Tue, Oct 23, 2007 at 12:05:22AM -0400, Shawn O. Pearce wrote:
> >
> > Yes.  Because 'next' always has commits in it that never appear in
> > 'master'.  So any topic forked from master must merge into next.
> > It can't be a fast-forward.  No forced merging required.
> 
> Why is it the case that 'next' always commits that never appear in
> 'master'.  So far in how I've been doing things that hasn't been the
> case.  When I do a "git checkout master; git merge next", it's always
> been a fast-forward merge. 
> 
> Oh, I see.  That's because if you put some trivial changes in
> 'master', and then pull those changes into next, there will be merge
> commits in 'next' that will never be in 'master.  Is that it?  

Exactly.  This of course means that next has been growing in distance
from master for quite some time.  It has well over 1000 commits now
in git.git that aren't in master.  Most of those will never merge
there either.
 
> I had been trying to avoid that case by always putting new commits,
> even trivial ones, into 'next', and then having them drop into
> 'master' at the next cycle; so 'master' was always trailing 'next',
> but they were always the same commit string (i.e., 'master' was always
> a subset of 'next').  
> 
> Aside from the WC script not working right, are there other
> disadvantages to my doing things that way as opposed to the way the
> Junio has been running the git repository?

The reason Junio does what he does is flexibility.

By merging only individual topics forked from master into next you
can merge those individual topics into master at different points
in time.  For example db/fetch-pack has been in next for many weeks
and hasn't yet merged into master, yet jc/am-quiet was forked after
db/fetch-pack started and has already merged into master.

Your way would make jc/am-quiet wait until db/fetch-pack was ready.
That's a big risk in the sense that your tree is "blocked" and even
simple changes are held up by ones that suddenly became a lot more
complex then you originally thought they were going to be.

-- 
Shawn.

  reply	other threads:[~2007-10-23  4:47 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-10-16  6:04 What's cooking in git/spearce.git (topics) Shawn O. Pearce
2007-10-16 11:16 ` Johannes Schindelin
2007-10-16 19:57   ` Theodore Tso
2007-10-17  3:20     ` Shawn O. Pearce
2007-10-23  1:15     ` Junio C Hamano
2007-10-23  1:21       ` Theodore Tso
2007-10-23  1:29         ` Junio C Hamano
2007-10-23  2:00           ` Theodore Tso
2007-10-23  4:05             ` Shawn O. Pearce
2007-10-23  4:33               ` Theodore Tso
2007-10-23  4:46                 ` Shawn O. Pearce [this message]
2007-10-23  4:56                   ` Theodore Tso
2007-10-23  5:07                     ` Shawn O. Pearce
2007-10-23  5:30                       ` Theodore Tso
2007-10-23  5:42                         ` Shawn O. Pearce
2007-10-23 12:03                           ` Theodore Tso
2007-10-23 17:44                             ` Daniel Barkalow
2007-10-23 19:00                             ` Junio C Hamano
2007-10-24  0:12                               ` Theodore Tso
2007-10-23  4:27         ` Shawn O. Pearce
2007-10-16 23:40   ` Shawn O. Pearce
  -- strict thread matches above, loose matches on Subject: below --
2007-10-22  6:32 Shawn O. Pearce
2007-10-22  6:59 ` Jeff King
2007-10-22  7:16 ` Jeff King
2007-10-23  2:32   ` Linus Torvalds
2007-10-23  3:48     ` Jeff King
2007-10-22  7:24 ` Pierre Habouzit
2007-10-22 15:27 ` Steffen Prohaska
2007-10-23  1:26 ` Junio C Hamano
2007-10-23  3:34   ` Shawn O. Pearce

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

  List information: http://vger.kernel.org/majordomo-info.html

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

  git send-email \
    --in-reply-to=20071023044657.GC14735@spearce.org \
    --to=spearce@spearce.org \
    --cc=Johannes.Schindelin@gmx.de \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=tytso@mit.edu \
    /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.
Code repositories for project(s) associated with this public inbox

	https://80x24.org/mirrors/git.git

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 read-only IMAP folder(s) and NNTP newsgroup(s).