Johannes Schindelin [off-list ref] writes:
Hi,
On Wed, 16 Jul 2008, Junio C Hamano wrote:
quoted
Johannes Schindelin [off-list ref] writes:
quoted
Am I the only one who deems teaching plumbing to users ("I like it raw!
So I teach it the same way!") harmful?
I think that justification is harmful.
More productive way to think about it is to identify cases where we
_need_ to go down to combination of the plumbing commands in our daily
workflow, with today's command set. That would give us a good
indication that some Porcelain may need to be enhanced.
An example. I find myself running "git read-tree -m -u $another_state"
while redoing a series inside a "rebase -i" session to move commit
boundaries. There may need an insn that says "use that tree" instead of
"edit" and running "read-tree -m -u" by hand. This does not bother me
too much, but there probably are other examples.
Another example. I often run "git ls-files -u" while looking at which
paths are conflicting. ls-files is classified as plumbing, but it does
not bother me as much as having to see the staged long object names in
this output. Other people, however, might find it yucky, and we might
want "git merge --unmerged" or something that lists the paths (and only
paths, no stage information) that still have conflicts.
I agree that if you know Git internals -- and you and me do -- it comes in
_right_ handy to know the 100+ commands with many options by heart.
However, my point was about telling users, especially new ones.
Perhaps you did not read my first paragraph?
Hi,
On Wed, 16 Jul 2008, Junio C Hamano wrote:
Johannes Schindelin [off-list ref] writes:
quoted
On Wed, 16 Jul 2008, Junio C Hamano wrote:
quoted
Johannes Schindelin [off-list ref] writes:
quoted
Am I the only one who deems teaching plumbing to users ("I like it
raw! So I teach it the same way!") harmful?
I think that justification is harmful.
More productive way to think about it is to identify cases where we
_need_ to go down to combination of the plumbing commands in our
daily workflow, with today's command set. That would give us a good
indication that some Porcelain may need to be enhanced.
An example. I find myself running "git read-tree -m -u $another_state"
while redoing a series inside a "rebase -i" session to move commit
boundaries. There may need an insn that says "use that tree" instead of
"edit" and running "read-tree -m -u" by hand. This does not bother me
too much, but there probably are other examples.
Another example. I often run "git ls-files -u" while looking at which
paths are conflicting. ls-files is classified as plumbing, but it does
not bother me as much as having to see the staged long object names in
this output. Other people, however, might find it yucky, and we might
want "git merge --unmerged" or something that lists the paths (and only
paths, no stage information) that still have conflicts.
I agree that if you know Git internals -- and you and me do -- it comes in
_right_ handy to know the 100+ commands with many options by heart.
However, my point was about telling users, especially new ones.
Perhaps you did not read my first paragraph?
Well, I did.
But as was visible from the thread including this message:
http://thread.gmane.org/gmane.comp.version-control.git/59935/focus=62021
I take it that we do not really have to go down to the plumbing that
often.
Sure, advanced usage is nice, and often involves plumbing, especially for
scripting. And there is a time to explain plumbing. But I think that the
first lesson is not it. Not even the second or the third.
And as I said in my first mail, I consider it harmful to _start out_ with
plumbing.
And other answers in this thread (the ones that do not try to highjack the
thread to talk about a crappy but popular SCM) make me even more certain
of that.
Ciao,
Dscho
P.S.: Of course, there may be users who like to spend a lot of time
grasping the internals of Git first, before issuing their first Git
command. Just like there are people who like electrodes on their thighs.