David Kastrup <dak@xxxxxxx> wrote: > Eric Wong <normalperson@xxxxxxxx> 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 - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
