Re: Considering teaching plumbing to users harmful

From: Johannes Schindelin <johannes.schindelin@gmx.de>
Date: Jul 16, 2008, 23:05 UTC
Message-ID: <alpine.DEB.1.00.0807170100320.4318@eeepc-johanness>
In-Reply-To: <7vmykhpn6z.fsf@gitster.siamese.dyndns.org>

Hi,

On Wed, 16 Jul 2008, Junio C Hamano wrote:

Show 24 quoted lines

> Johannes Schindelin <Johannes.Schindelin@gmx.de> 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