Re: What's in git.git (stable)

Andy Parkins [off-list ref] writes:

On Thursday 2006, December 14 21:22, Junio C Hamano wrote:

quoted

This is interesting.  You said "commit -b", were pointed out
that you were talking about "checkout -b", and just after saying
"yup, that is right, I was", you again say "commit -b".

There truly is something wrong with me.

I did not mean it that way.  I only took it as a sign that maybe
"first create and switch to a branch and then work and commit
there, in separate steps", which is how git encourages things to
be done, does not match people's mental model so well.

I'm not sure about your "commit -b"; is it wise to have /another/ way of 
making a branch?  I mean - I'm clearly confused enough, have a heart :-)

I said "commit -b <newbranch>" and deliberately avoided saying
"commit -b <anybranch>", because I did not want to open another
can of worms while we are discussing so many good things
already, and my head can hold only a handful topics at once.

But people on the list (and #git channel) sometimes wished an
easy way to help the following workflow.

 * I am in the middle of working on a new feature.  As a good
   git user, I am on a topic branch dedicated for that purpose.

 * While working on it, I find an obvious bug that I would not
   want to fix on the branch (the topic branch I am currently on
   is not about fixing that bug).

 * But I fix it in the working tree anyway, because otherwise I
   would forget.  It happens to be in an isolated file that my
   current topic does not need to modify (say, I was looking at
   a function in that file that my new feature needs to call and
   I wanted to study its calling convention. And I found a typo in
   the comment near the function).

 * The fix does not belong to the current topic, but can go to
   the 'master' branch straight.  It's a fix in the comment that
   cannot possibly break things, and I can/will test it later
   anyway.

 * So with the existing set of tools, I would go there, commit
   and then come back:

	$ git checkout [-m] master
        $ git commit -m 'fix typo in that-file' that-file
        $ git checkout [-m] topic

   But it might be faster to say:

   	$ git commit -b master -m 'fix typo in that-file' that-file

   to make a commit on the other branch and come back
   immediately afterwards.

 * In the same situation, when the 'master' is closed for some
   administrative reason (e.g. "deep freeze before a release and
   strict bugfixes and nothing else are allowed"), I would create
   a new 'typofix' branch and do the same.  I can rebase it
   later on 'master' when it reopens.

	$ git commit -b typofix -m 'fix typo in that-file' that-file

	... much later when master reopens ...
        $ git rebase --onto master topic typofix

It's just a possible typesaver, but I am likely not using it
myself (my fingers are already trained to do the three command
sequence dance).

I do agree that it adds one more way to do the same thing and
would make the documentation noisier, potentially adding more to
the confusion.  So let's not go there.

The 'can of worms' is that switching to an existing branch could
fail with conflicts.

One fix for this would be the idea I've proposed to have a new flag
for "git checkout" to 'stash' the dirty state in the current branch
before switching.

Then, there wouldn't be a problem to implement "commit -b <anybranch>"
on top of the stashing checkout.

I think the only real problem with the idea of having dirty changes
stashed in a branch is that git already allows dirty changes to be
carried while switching to a branch, (with or without -m). And doing
both of those at once would lead to an ugly new conflict situation,
(where _neither_ of the conflicted states exist as exposed tree
objects). Even if there were no conflict, it would mingle two
different sets of local modifications, and that could be unkind as it
might be hard for the user to separate them if they didn't want them
mingled.

If someone were to pursue this idea, I think it would be reasonable to
just make that case an error, "Cannot carry local modifications when
checking out a branch with stashed modifications." That message could
even suggest the user use the stash option to leave the local
modifications behind when doing the checkout.

-Carl

On Thursday 2006 December 14 23:46, Junio C Hamano wrote:

quoted

There truly is something wrong with me.

I did not mean it that way.  I only took it as a sign that maybe

Don't worry; I've got thicker skin than that.  I was simply amazed at my lack 
of comprehension ability. :-)

quoted

I'm not sure about your "commit -b"; is it wise to have /another/ way of
making a branch?  I mean - I'm clearly confused enough, have a heart :-)

I said "commit -b <newbranch>" and deliberately avoided saying
"commit -b <anybranch>", because I did not want to open another
can of worms while we are discussing so many good things
already, and my head can hold only a handful topics at once.

Absolutely.  I'd agree that only <newbranch> is worth even considering.

 * While working on it, I find an obvious bug that I would not
   want to fix on the branch (the topic branch I am currently on
   is not about fixing that bug).

I find myself swayed by this.  This is indeed something that happens to me a 
lot.  In certain circumstances I've been defeated by git because I couldn't 
switch to the other branch to make that quick commit because my local changes 
conflicted with that other branch.  The solution I use is to commit the bug 
fix in the wrong branch, finish my current on-topic commit then 
rebase/reset/etc to put everything where it should be.

I do agree that it adds one more way to do the same thing and
would make the documentation noisier, potentially adding more to
the confusion.  So let's not go there.

Yep.  Although you've persuaded me with the above example, I think this is the 
correct path.  It's not wise to add every bell and whistle just because we 
can.  As long as there is /a/ way to achieve every task, that's good enough, 
we don't need every way to achieve every task.  We might even argue that 
git's flexibility is what makes it harder to learn.  It's similar to UNIX in 
that respect - hard to learn, easy to use.


Andy

-- 
Dr Andy Parkins, M Eng (hons), MIEE

Andy Parkins [off-list ref] writes:

On Thursday 2006 December 14 23:46, Junio C Hamano wrote:
...

quoted

I said "commit -b <newbranch>" and deliberately avoided saying
"commit -b <anybranch>", because I did not want to open another
can of worms while we are discussing so many good things
already, and my head can hold only a handful topics at once.

Absolutely.  I'd agree that only <newbranch> is worth even considering.

Just for the record, I do not necessarily agree.  Committing a
small and obvious change out of context to an existing branch
makes just as much sense.

After all, with the example workflow in my message you responded
to, after running the "commit -b typofix" (which creates a new
branch) to record the first typo fix, I am sure that I would
want to record the second typofix I would find while on my topic
to go to the same typofix branch I previously created.

The 'can of worms' is that switching to an existing branch could
fail with conflicts.  Although "git checkout -m" can help
sometimes, that is not something we would want to do in the
middle of doing something else on a topic.  That's why I do not
think "commit -b <anybranch>" is a good idea.

Allowing the form for only a new branch makes an inconsistency
that is hard to explain to new people, and that is why I am not
in favor of having "commit -b <newbranch>" either.

Yep.  Although you've persuaded me with the above example, I 
think this is the 
correct path.  It's not wise to add every bell and whistle 
just because we 
can.  As long as there is /a/ way to achieve every task, 
that's good enough, 
we don't need every way to achieve every task.  We might even 
argue that 
git's flexibility is what makes it harder to learn.  It's 
similar to UNIX in 
that respect - hard to learn, easy to use.

So we prefer to tell users "You can do what you want with these 3 commands,
since we don't want to confuse use with another option to do it with just
1"?

Andy

-- 
best regards

  Ray