Erick Mattos <erick.mattos@xxxxxxxxx> writes:
> As I see you have found a very good example under your common work
> flow. Nice. :-)
And realize that it does not help that you nuke the index while leaving
the working tree files.
I do not think you got my point at all, so let's try a different phrasing.
I've already spent too much time on this thread, so this will be the last
message from me on this topic for now. Hopefully you will understand this
time.
I saw two potential workflows that could be useful:
(1) "mostly common paths" workflow;
(2) "no common paths" workflow;
Suppose you are on master branch and creating an orphan branch. The first
command is this for either case:
$ git checkout -b orphan --orphan master
The next action the user needs to make before starting to work on
preparing for the first commit on that unborn branch is different
depending on how "checkout --orphan" behaves. Let's take two extreme:
- If it kept both the index and the working tree, the user does not need
to do anything for "mostly common paths", while the user only needs
"git rm -rf ." for "no common paths".
- If it nuked both the index and the working tree, the user does not need
to do anything else for "no common paths", while the user only needs
"git checkout master ." for "mostly common paths".
Notice that in either of these two implementations, one camp does not need
to do anything other than the checkout itself and can immediately start
working to prepare for the first commit. The other camp needs to do an
extra thing, but that is limited to one single, simple Porcelain command.
There is no "did you have untracked files? then do this" complications.
If you nuked the index but didn't touch the working tree, which is what
you did, everybody is forced to do extra things, and recovery is not as
simple as the above two extremes.
For people who wanted "mostly common paths", "git add ." would add paths
that were originally shown in the untracked list, so it cannot be used;
they need to either choose the necessary paths and run a series of random
"git add WHATEVER", or "git add ." and untrack unwanted paths with a
series of random "git rm --cached WHATEVER" after that.
For people who wanted "no common paths", "git rm" wouldn't work (as the
index is nuked), and "git clean" will lose originally untracked files;
again they need to give a series of random "git clean WHATEVER".
Either way, everbody suffers, and recovery won't be a single simple
command anymore.
The conclusion to draw is that, among four possible implementations ("keep
both", "remove both", "remove index but keep working tree", "keep index
but remove working tree"), the last two are clearly inferior compared to
the first two.
Between the first two, there are a few pros-and-cons.
- Obviously, if most people want "mostly common paths", then "keep both"
would be more helpful, and vice-versa.
- "keep both" would not need much safety, but "remove both" needs a
safety-valve implementation (you don't want to lose added changes in
the index, nor changes in the working tree yet to be added).
So I am inclined to say, unless "no common paths" is the majority of the
use case, "keep both" would be the design to pick.
I didn't see in your long mail any "third" workflow that would be helped
by your "remove index but keep working tree". All of them were either "no
common paths" or "mostly common paths". If you demonstrated that a
"third" workflow is the majority of the case, and that "remove index but
keep working tree" would be the most helpful for that "third" workflow,
then you might have made a case that "remove index but keep working tree"
is the right design to use. But I didn't see any workflow that wants a
working tree full of files that are nothing but untracked cruft.
--
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