Re: Bootstrapping into git, commit gripes at me

On Mon, 11 Jul 2005, Junio C Hamano wrote:

quoted

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:

 - 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