Hi,
Erick Mattos wrote:
> I am just trying to make you satisfied so gitsters, I mean git users,
> will have this feature as soon as possible.
Well, hopefully everyone wants it to make sense, too. :)
> I do prefer my first design mainly because it mimics the state of an
> initial commit. I think that is subjectively better.
>
> You have been asking me to make one of the two possible work flow uses
> you pictured as favored so things will be already set to them. No
> further commands to them.
>
> I did it! As a matter of fact the "mostly common paths" people were
> favored as you have noticed your inclination to it before.
I guess I am confused because I am not sure what you are trying to do:
A. on one hand, you might want a command to use as a building block.
In practice, people would use scripts or refer to known recipes to
make use of this building block in one of a few known combinations
with other commands.
B. on the other hand, you might be trying to make it easier to get
some particular task done.
Junio was discussing the case B. Whoever has the itch is in a good
position to say what interface would be convenient. Usually one command
invocation can be enough to accomplish most of what is needed on its
own. There were two examples of such commands he gave:
1. * [public]
\
* --- * --- * [private] ===> * --- * --- * --- * [private]
for the “we cannot publish the whole history” use,
and
2. * [doc]
* --- * --- * [master] ===> * --- * --- * --- * [master]
for the “starting unrelated development but restrictive disk quotas
mean I have to use the same working directory” use.
In these examples (which are just examples for illustration of what a
well supported use case looks like), the content in the index and work
tree after the command is run is tailored to what is expected to be
needed.
I suspect you are aiming for case A instead. For scripts and special
case recipes, it might be a good idea to have a command to use as an
ingredient in tasks like (1) and (2) above. The recipe people
currently use is usually something like the following:
git symbolic-ref HEAD refs/heads/newbranch
rm .git/index
but that indeed is not perfect: it does not check for a dirty index
in case 1, it does not keep track of what files were not registered
in the index so as not to delete them in case 2, and so on.
Also one might object to the knowledge of repository layout required;
gitrepository-layout(5) is probably not the first place a person would
look in trying to figure out how to carry out this task. That misses
the point, though, in my opinion, since
git symbolic-ref HEAD refs/heads/newbranch
git rm --cached '*'
accomplishes the same thing. Anyway, if your goal is to create
plumbing, I would suggest modifying a plumbing command instead of
‘git checkout’.
Thank you for your efforts. As hinted above, I would not mind seeing
improvement in this area at all. Anyway, I hope this has provided some
food for thought (if not, don’t mind me; please carry on).
Kind regards,
Jonathan
--
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