git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
* Branch next doesn't look like it was pushed
@ 2022-07-16 14:41 Stephen Smith
  2022-07-16 21:36 ` Junio C Hamano
  0 siblings, 1 reply; 3+ messages in thread
From: Stephen Smith @ 2022-07-16 14:41 UTC (permalink / raw)
  To: Junio C Hamano, git

Is there a reason that with the latest commits to the repository that next is 
no longer an ancestor of seen  and than main/master is no longer an ancestor 
of next?





^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: Branch next doesn't look like it was pushed
  2022-07-16 14:41 Branch next doesn't look like it was pushed Stephen Smith
@ 2022-07-16 21:36 ` Junio C Hamano
  2022-07-17 13:36   ` Stephen & Linda Smith
  0 siblings, 1 reply; 3+ messages in thread
From: Junio C Hamano @ 2022-07-16 21:36 UTC (permalink / raw)
  To: Stephen Smith; +Cc: git

Stephen Smith <ischis2@cox.net> writes:

> Is there a reason that with the latest commits to the repository that next is 
> no longer an ancestor of seen  and than main/master is no longer an ancestor 
> of next?

Let's get to the latter half of your question first.

Tips of various branches of Git project can be observed at
https://git.kernel.org/pub/scm/git/git.git/ and
https://github.com/git/git (among other mirrors) and they are at
these commits:

    maint         bbea4dcf42
    master        9dd64cb4d3
    next          4dd4a117ec
    seen          c82b393ce5

at the time of writing.  The 'next' branch is designed to be always
a descendant of 'master', unless I screw up, and I'd appreciate if
you let me know when it happens.  Right now, it is not the case,
though.

    $ git rev-list --count 4dd4a117ec..9dd64cb4d3
    0

Now, the 'seen' branch never was, and will never be, a descendant of
'next'.  It always is a decendant of 'master'.

Imagine how 'next' gets advanced.  It will never rewind during a
release cycle, so it starts at a feature release, and merges topics
and also merges 'master' back.  A topic might be merged once to
'next', then the topic may gain a commit or two to fix a bug in the
part of the topic that is already in 'next', and the updated topic
may be merged to 'next' again.  IOW, some topics may have merged to
'next' in multiple steps.  Topics cooking in 'next' may graduate by
getting merged to 'master', at which time, the draft release notes
is updated on the 'master' branch, and 'next' merges 'master' back.
This is to pick up the changes to the draft release notes.  In other
words, the history graph of 'next' will be a mess.

The 'seen' branch serves three purposes.

 * The first is to allow sanity checking the result of messy merges
   into 'next'.  For that, whenever 'master' advances, it is rebuilt
   from scratch from the tip of 'master' and merges each and every
   topic that are already in 'next' one by one, serially.  Even
   topics that were merged in multiple steps to 'next' may be merged
   in full with a single merge to 'seen'.  When all the topics in
   'next' (and nothing else) are merged, an empty single-parent
   commit with title '### match next' is added.  The idea is that
   the tree of this commit should exactly match the tree of 'next',
   or there may be some mismerges.  The 'next' branch, since it
   forked from the last release point, may have merged these topics
   in random order, in increments, and also merged back the changes
   made in 'master', but the end result should be the same as
   starting from the latest 'master' and merging the topics that are
   in 'next' but still not in 'master' one by one, each as a whole
   instead of doing so incrementally.

 * The second purpose of 'seen' is to gather other topics that I
   happened to have seen together into a single integration branch,
   so that

   (1) I can forewarn myself of possible conflicts and interactions
       among topics in flight, and

   (2) I can have a simple way to list all topics in flight.

   This is done by merging the other topic branches, on top of
   'seen^{/^### match next}' commit.  To list the topics that I am
   juggling "git log --oneline --first-parent master..seen" is an
   effective way.  For this to work, the rest of 'seen' cannot be
   built on top of 'next', whose history is allowed to be messy.
   This is why 'next' cannot be an ancestor of 'seen'.

 * The third purpose of 'seen' is to give me a version that I can be
   a guinea pig of.  I have a build of "git" that is cut from a
   point in 'seen' that is used in my daily use.

HTH.




^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: Branch next doesn't look like it was pushed
  2022-07-16 21:36 ` Junio C Hamano
@ 2022-07-17 13:36   ` Stephen & Linda Smith
  0 siblings, 0 replies; 3+ messages in thread
From: Stephen & Linda Smith @ 2022-07-17 13:36 UTC (permalink / raw)
  To: Junio C Hamano; +Cc: git

On Saturday, July 16, 2022 2:36:47 PM MST Junio C Hamano wrote:
> The 'next' branch is designed to be always
> a descendant of 'master', unless I screw up, and I'd appreciate if
> you let me know when it happens.  Right now, it is not the case,
> though.

I thought it had been, but you are right.    Sorry.



^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2022-07-17 13:37 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-07-16 14:41 Branch next doesn't look like it was pushed Stephen Smith
2022-07-16 21:36 ` Junio C Hamano
2022-07-17 13:36   ` Stephen & Linda Smith

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).