Raman Gupta [off-list ref] writes:
Junio C Hamano wrote:
...
If you wish to remove discussion of 'next' from this document, that is
probably better done in a separate followup change. Though personally
I think its a useful concept for readers to learn about as they are
setting up their own workflows.
I do not have a particularly strong feeling about 'next' either way.
As the document states at the top, it lists ingredients from git.git
management and it is left up to the readers to adopt parts that suit their
needs, while not using others. In that spirit, the description of 'next'
as "ahead of master that is supposed to be rock solid" may be a good thing
to keep. It is orthogonal if the project wants to rewind and rebuild
'next' after every feature release---they do not need to (and we didn't do
so for quite some time). One valid choice by readers is to adopt the
concept of 'next' in their project but never rewind and rebuild it, and
you made that clear that it is optional. So I think this part of your
patch is good as-is.
quoted
Other parts (except for the "branch -f" bit I've already told you
about in the other message) looked good.
I'll add some discussion about the branch -f bit -- I hope you agree
that in this document that is distributed with git, some
beginner-level explanation of the difference between the branch -f and
the merge approach is warranted?
Surely and thanks.
Junio C Hamano wrote:
Raman Gupta [off-list ref] writes:
quoted
Junio C Hamano wrote:
...
If you wish to remove discussion of 'next' from this document, that is
probably better done in a separate followup change. Though personally
I think its a useful concept for readers to learn about as they are
setting up their own workflows.
I do not have a particularly strong feeling about 'next' either way.
As the document states at the top, it lists ingredients from git.git
management and it is left up to the readers to adopt parts that suit their
needs, while not using others. In that spirit, the description of 'next'
as "ahead of master that is supposed to be rock solid" may be a good thing
to keep. It is orthogonal if the project wants to rewind and rebuild
'next' after every feature release---they do not need to (and we didn't do
so for quite some time). One valid choice by readers is to adopt the
concept of 'next' in their project but never rewind and rebuild it, and
you made that clear that it is optional. So I think this part of your
patch is good as-is.
It might be useful to add some explanation of why one would want to
rewind and rebuild vs simply continue as is.
I guess the advantage is that the history for next starts out nice and
clean for the next release, without any cruft from repeated merging of
topic branches.
The disadvantage is that one must publish the operation and all forks
must deal with the rebase.
Any other thoughts?
Cheers,
Raman
Raman Gupta [off-list ref] writes:
It might be useful to add some explanation of why one would want to
rewind and rebuild vs simply continue as is.
I guess the advantage is that the history for next starts out nice and
clean for the next release, without any cruft from repeated merging of
topic branches.
Repeated merges are usually not a major issue. Summarization tools such
as log and shortlog can be told not to list merges.
What matters more is a revert of a topic, that looked promising when it
started, but later found undesirable or premature. In such a case, the
topic is reverted out of 'next' and but the fact remains in the history
that it was once merged, and it was reverted. We would want to get rid of
these records at some point to give a chance for another incarnation of
the topic done right a clean slate to retry, and a feature release is a
good point in history to do so.
The disadvantage is that one must publish the operation and all forks
must deal with the rebase.
Yes.