From: Eric Wong <normalperson@yhbt.net>
To: David Kastrup <dak@gnu.org>
Cc: Russ Brown <pickscrape@gmail.com>, git@vger.kernel.org
Subject: Re: git-svn: Branching clarifications
Date: Sat, 8 Sep 2007 00:49:44 -0700 [thread overview]
Message-ID: <20070908074944.GC24166@muzzle> (raw)
In-Reply-To: <85r6l9zlt4.fsf@lola.goethe.zz>
David Kastrup <dak@gnu.org> wrote:
> Eric Wong <normalperson@yhbt.net> writes:
>
> > git-svn sets "master" to the most recently committed-to branch
> > in SVN the first time it fetches. "git-log master" will tell
> > you (look at the git-svn-id: lines).
>
> Sigh. Another "surprise the user by an arbitrary looking choice that
> might possibly correspond to what he wants done because it something
> obscure in the commit history suggests so" design decision.
>
> I don't want my master set according to something that a coworker (or
> even myself) happened to commit last to.
>
> Please. git-svn is told how to find the trunk on its command line.
> Nothing makes sense (short of an _explicit_ wish otherwise for which
> it might make sense to create a command line option) than to map
> master to the trunk.
Keep in mind that command-line arguments for trunk, branches and tags
are _all_ optional to git-svn.
If only trunk or nothing is specified, the current behavior will always
be correct.
There's also a case if only branches and/or tags are specified, with no
trunk given. That would need to be handled, somehow...
I've also tracked several (both OSS and closed) projects that have a
policy of doing all work on branches with a trunk that's almost never
up-to-date.
Tracking the last-committed branch was the easiest to code, and we even
tell the user which branch they're on. I guess I could add a message
telling them all the other refs they can "git reset --hard" to if they
don't like their current one.
> As a design rule: don't second-guess the user, _ever_, and
> particularly not on decisions with large consequences. A tool should
> not have a mind of its own but do what it is told. And if it can't
> figure out what it is told, by simple, user-understandable criteria,
> barf. And of course have a way to _direct_ it when it can't figure it
> out on its own, or if the simple and obvious default would not do the
> right thing.
git-svn used to never check anything out and leave HEAD dangling. I was
happy with that, but I got a lot of user complaints from that, too.
--
Eric Wong
next prev parent reply other threads:[~2007-09-08 7:49 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-09-07 16:47 git-svn: Branching clarifications Russ Brown
2007-09-08 5:21 ` Eric Wong
2007-09-08 6:57 ` David Kastrup
2007-09-08 7:49 ` Eric Wong [this message]
2007-09-08 7:58 ` David Kastrup
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=20070908074944.GC24166@muzzle \
--to=normalperson@yhbt.net \
--cc=dak@gnu.org \
--cc=git@vger.kernel.org \
--cc=pickscrape@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.