Hi,
On Wed, 16 Jul 2008, Junio C Hamano wrote:
> Johannes Schindelin <Johannes.Schindelin@xxxxxx> writes:
>
> > 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.
For example, I would _never_ suggest the following workflow to a n00b
because it would be confusing:
$ tar xvf <xyz>
<try to compile>
<fix a compile error>
<fix other things>
<oh, I could contribute the fixes!>
$ git init
$ git remote add -f origin <url>
$ git read-tree <that-tag>
$ git status
$ git add -p
$ git commit -s
<repeat until there are no changes left>
$ git rebase -i origin/master
$ git format-patch -n origin/master
Even if this is something I did at least a handfull times myself.
Ciao,
Dscho
--
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
