Jakub Narebski [off-list ref] writes:
Junio C Hamano wrote:
quoted
I think the latter is more important point. If you train a
naive user to use --only-tracked to ignore "Untracked" list, you
are doing him or her a great disservice. Mistake to forget "git
add" a new file before commiting will bound to happen.
If it won't acquire short version, nor tab completion, mosts users when
confronted with such a mothful of option-name wouldn't use it unless
necessary, I think...
Yeah, but if we accept that --only-tracked patch, I know from
the past experience that people would send a "shorter synonym"
patch, arguing that the capability is already there.
I really think we should resist temptation to add misfeatures
that would encourage bad workflows and new user mistakes.
On Aug 25, 2007, at 02:06, Junio C Hamano wrote:
Jakub Narebski [off-list ref] writes:
quoted
Junio C Hamano wrote:
quoted
I think the latter is more important point. If you train a
naive user to use --only-tracked to ignore "Untracked" list, you
are doing him or her a great disservice. Mistake to forget "git
add" a new file before commiting will bound to happen.
If it won't acquire short version, nor tab completion, mosts users
when
confronted with such a mothful of option-name wouldn't use it unless
necessary, I think...
Yeah, but if we accept that --only-tracked patch, I know from
the past experience that people would send a "shorter synonym"
patch, arguing that the capability is already there.
I really think we should resist temptation to add misfeatures
that would encourage bad workflows and new user mistakes.
I really do think that there is a use case for this patch. But this
assumes that the testing is done in the source tree, but maybe that
in itself can be considered a bad workflow.
An example would be in game development, where I have a directory
full of images, and I wish to try out different images in the place
of one. I usually create different versions of the images with
different names, filling up the image directory under VCS. This
usually results in tens of images that will not be tracked (unless
they replace the original images), but because of my bad habit of
creating the files inside the source tree, which results in a little
bit faster workflow for me. With all these untracked files, git-
status will obscure the actual contents of the status I wish to see.
I cannot put those files inside .gitignore, as there would have to be
some kind of exclusion pattern for them that won't match the tracked
files. Sure I could prefix all of my test images with 'test_' or
something similiar. Or I could just add '*' to .gitignore, and force
adds. The latter seems like a bad habit for me, the other seems to
include a lot of manual labor, especially when someone else sends
test files for me.
So the end result for me is, that it's easier to use --only-tracked
Fringe case? Maybe. Workflow could be better, sure. But --only-
tracked even works for the less technical folk, which might be scared
of forcing the changes, or annoyed by having to name the files with a
magic prefix.
--
Väinö
Hi,
On Sat, 25 Aug 2007, V?in? J?rvel wrote:
An example would be in game development, where I have a directory full
of images, and I wish to try out different images in the place of one. I
usually create different versions of the images with different names,
filling up the image directory under VCS.
I have a similar use case, funnily enough also with images. I created a
tmp/ directory and put the images there, cp'ing or ln -s'ing the current
one into the cwd. Then, "/tmp/" is put into .gitignore and all is well.
Especially the fact that I no longer forget to check in the images that I
_do_ want to track.
Ciao,
Dscho