From: Erick Mattos <erick.mattos@gmail.com>
To: Jakub Narebski <jnareb@gmail.com>
Cc: git@vger.kernel.org
Subject: Re: [PATCH] git checkout -b: unparent the new branch with -o
Date: Wed, 24 Feb 2010 19:14:24 -0300 [thread overview]
Message-ID: <55bacdd31002241414p4428165asea22b71726afff68@mail.gmail.com> (raw)
In-Reply-To: <55bacdd31002241410h747ae221xd72dfcf269bdb84e@mail.gmail.com>
Hi,
> > Subject: [PATCH] git checkout -b: unparent the new branch with -o
>
> I would say it is rather: "git checkout -b: allow creating unrelated branch",
> or something like that.
I don't see a point to change something specific to a general not yet
defined option.
>
> By the way, for the solution to be complete it should work not only for
> "git checkout -b" shortcut, but also for "git branch".
That is not the idea. The idea is to start coding a new orphan
branch. Not to create an empty orphan branch for later.
Also it is not meant to clone a commit to a new orphan branch. Even
though this could be done, using "git checkout TARGET; git checkout
-ob NEW_BRANCH; git add .; git commit -C/-c TARGET --reset-author".
It is meant to start a parallel development which will be connected to
existing ones. Of course there will be other possible uses (I always
trust in people inventiveness).
>
> >
> > Sometimes it is necessary to start up a new development branch of code
> > intended to be merged in the near future to existing branches but which
> > actually does not relate to them.
>
> I'm not sure if 'unrelated but _intended to merge_' is most common
> workflow utilizing unrelated branches... and whether git should
> promote such workflow, even if only describing it in the commit
> message.
This is dependent of point-of-view. So thank you very much for sharing yours.
Anyway all those unrelated branches uses you mentioned would be
satisfied by this new option.
>
> >
> > The new -o/--orphan is intended to solve this situation allowing the
> > creation of a new branch unparented to any other.
>
> I think that for example '--root', or '--rootless', or '--unrelated'
> would be a better name than '--orphan'. Besides I don't think that
> such rarely used option should squat on rare resource of single-letter
> option.
Parent is the term employed even by the commits itself to describe the
commit of origin so I don't think those suggestions are nice. I do
agree about the importance of single-letters because we only have 26
but in this case it would be only the fifth used.
> >
> > Signed-off-by: Erick Mattos <erick.mattos@gmail.com>
> > ---
>
> [...]
>
> > --- a/Documentation/git-checkout.txt
> > +++ b/Documentation/git-checkout.txt
> > @@ -9,7 +9,7 @@ SYNOPSIS
> > --------
> > [verse]
> > 'git checkout' [-q] [-f] [-m] [<branch>]
> > -'git checkout' [-q] [-f] [-m] [-b <new_branch>] [<start_point>]
> > +'git checkout' [-q] [-f] [-m] [-b <new_branch> [-o]] [<start_point>]
>
> This is not stricly correct, as you can use either '-o' OR '<start_point>',
> but not both (but you can use '-o' only together with '-b <new_branch>').
You are right on that because start_point would be useless.
>
>
>
> > +-o::
> > +--orphan::
> > + When creating a new branch, set it up as unparented thus
> > + unrelated to the previous branch.
> > +
>
> Unparented? Perhaps "set it up so first commit on this branch would
> be root (parenless) commit". Hmmm... it is not easy to describe it
> well...
Everything we try do define with human language is incomplete. So we
normally employ added layers of information to better describe things
as much as requested.
In our case we start with a single word represented by a letter or not
that try to give an idea. If not enough, by --help or when people use
it incorrectly they will get a small message describing the intended
use better. Then by a 'man' a paragraph. Further text is added to
the 'man' if necessary. And then the help files, tutorials and other
people.
I think all off those steps were taken correctly in this case and that
what is written now is good enough.
Thank you very much for your comments. I did appreciate it.
Best regards.
prev parent reply other threads:[~2010-02-24 22:20 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-02-23 21:20 [PATCH] git checkout -b: unparent the new branch with -o Erick Mattos
2010-02-23 21:56 ` Junio C Hamano
2010-02-24 22:23 ` Erick Mattos
2010-02-24 22:40 ` Erick Mattos
2010-02-24 22:27 ` Erick Mattos
2010-02-23 23:26 ` Jakub Narebski
[not found] ` <55bacdd31002241410h747ae221xd72dfcf269bdb84e@mail.gmail.com>
2010-02-24 22:14 ` Erick Mattos [this message]
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=55bacdd31002241414p4428165asea22b71726afff68@mail.gmail.com \
--to=erick.mattos@gmail.com \
--cc=git@vger.kernel.org \
--cc=jnareb@gmail.com \
/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).