On Wed, Nov 28, 2012 at 11:02:45AM -0800, Junio C Hamano wrote:
> "W. Trevor King" <wk...@tremily.us> writes:
> > From: "W. Trevor King" <wk...@tremily.us>
> > Signed-off-by: W. Trevor King <wk...@tremily.us>
> > ---
> > Documentation/git-submodule.txt | 3 ++-
> > git-submodule.sh | 2 +-
> > 2 files changed, 3 insertions(+), 2 deletions(-)
> Hmm, I wonder why I have this funny feeling that this was proposed
> and rejected already...
> As the command takes other options whose names begin with 'r', I
> thought the longer term plan was to stop letting "--rebase" squat on
> short and sweet "-r" and leaving it undocumented (even though the
> short one was added by mistake) was meant to be the first step in
> that process.
> But maybe I am confusing an undocumented single-letter option from
> some other subcommand. Anybody remembers?
Perhaps you are remembering:
On Sun, Nov 11, 2012 at 02:33:45AM -0800, Junio C Hamano wrote:
> Ah, this reminds me of another thing I noticed when I saw that
> patch. The change seems to think "branch" is the _only_ thing the
> user might want to record per submodule upon "git submodule add".
> As an interface to muck with an uninterpreted random configuration,
> it squats on a good option name for setting one single and arbitrary
> variable---quite a selfish change that is not acceptable.
> Calling the option "--record-branch-for-submodule" or something more
> specific might alleviate the problem, but then it would become even
> less useful as a short-hand for "config submodule.$name.branch", I
> would suspect.
With this recent patch, I'm just documenting someone else's squatting
;). But yes, the reason I noticed was because I was tempted to make
the same mistake again :p. In my defense, I think `update --remote`
is a good deal more general than my earlier `add --record`.
This email may be signed or encrypted with GnuPG (http://www.gnupg.org).
For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html