Re: Bootstrapping into git, commit gripes at me
- From
Linus Torvalds <torvalds@osdl.org>
- Date
- Jul 12, 2005, 03:18 UTC
- Message-ID
- <Pine.LNX.4.58.0507112010120.17536@g5.osdl.org>
- In-Reply-To
- <7voe98g3ws.fsf@assigned-by-dhcp.cox.net>
On Mon, 11 Jul 2005, Junio C Hamano wrote:
Show 5 quoted lines
> > > Opinions? > > How about treating "master" a temporary thing --- "whatever I > happen to be working on right now"?
I'd not mind with this in theory, but it has the fundamental problem that we can end up losing sight of commits we have, and then have no way to reach them.
Which is ok per se - sometimes you simply don't care about them, and I occasionally drop some commits on purpose when I've done something I decide to undo and then do a "git prune" to get rid of the objects.
But I don't want this to happen _easily_.
Your examples aren't actually very interesting:
Show 10 quoted lines
> - git branch <branch-name> ;# copies master to branch-name; > if branch-name exists in refs/heads, > warn and refuse. Override > with --force flag. > > - git checkout <branch-name> ;# copies branch-name to master; but > if master does not match any > of the other refs/heads/, warn > and refuse. Override with > --force flag.
because those two examples end up avoiding the _real_ issue, which is the
git checkout v2.6.12
case, which is exactly the case that would need a "--force" flag, since master is what you're working on before. And --force would drop that information.
So I want something that naturally works with this (very reasonable) way of working, and does _not_ force people to drop information.
In your world, you'd have to first save the old master with
git branch work-branch
and then you could do
git checkout v2.6.12
to start on "master" anew. That's fair, but it's conceptually very wrong: it rquires you to name the _old_ thing, which to me just sounds very confusing indeed. You don't care about the old thing, it's the _new_ thing you care about.
So at least to me it makes much more sense to say "ok, I'll start something new, and call it xyzzy", than "ok, I'll start something new, and I'll save the old under 'old'".
The "old" thing might not even be anything you worked on (it might be something you just cloned from somebody else), so you giving it a name isn't very logical. In contrast, you're clearly doing something active with the new thing, so naming _that_ makes sense.
Linus