On Mon, 11 Jul 2005, Junio C Hamano wrote:
> > 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 

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.

To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to