* Re: Considering teaching plumbing to users harmful
From: Stephan Beyer @ 2008-07-16 22:09 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <alpine.DEB.1.00.0807161804400.8950@racer>
Hi,
Johannes Schindelin wrote:
[...]
>
> I had the pleasure of introducing Git to a few users in the last months
> and in my opinion, restricting myself to teaching them these commands
> first helped tremendously:
>
> - clone, pull, status, add, commit, push, log
>
> All of these were presented without options, to keep things simple.
Basically I agree, but depending on the user's foreign SCM knowledge
it could be useful to talk about some basic "low-level" concepts of git
(without talking about the plumbing).
I mean:
- objects (commits, trees, blobs ... in very short)
- index
and perhaps
- refs (at least branches)
I was told that before I've seen a first git command and I still think
that was very useful.
Hmm, just recalling, my first git commands were:
1. init
2. add
3. status
4. commit
5. diff
6. log
7. branch
8. checkout
in this order, approximately. :)
(And I've used rebase before merge and I haven't used clone/pull/push for
a long time.)
It seems I haven't touched any plumbing before I've started with GSoC :)
I also think that for a user it is totally irrelevant if it is plumbing or
porcelain she is using, as long as it works. I mean, if I tought someone
using git, I'd never use the words "porcelain" or "plumbing".
Regards,
Stephan
--
Stephan Beyer <s-beyer@gmx.net>, PGP 0x6EDDD207FCC5040F
^ permalink raw reply
* git-svn: Trouble after project has moved in svn
From: Jukka Zitting @ 2008-07-16 22:12 UTC (permalink / raw)
To: git
Hi,
Somewhat related to the recent thread about Apache Synapse, I'm having
trouble making a git-svn clone of a project that has been moved around
in a Subversion repository.
See the script at the end of this message for a simple test case that
does the following svn commits:
PREPARE: creates projectA with the standard trunk,branches,tags structure
VERSION1: first version of README.txt in projectA/trunk
TAG1: tags projectA/trunk to projectA/tags/v1
MOVE: moves projectA to projectB
VERSION2: second version of README.txt in projectB/trunk
TAG2: tags projectB/trunk to projectB/tags/v2
The resulting repository structure is:
/projectB/
trunk/
README.txt # version 2
branches/
tags/
v1/
README.txt # version 1
v2/
README.txt # version 2
Here's the git commit graph created by the test case:
* TAG2 <- refs/remotes/tags/v2
| * VERSION2 <- refs/remotes/trunk
|/
* MOVE
* VERSION1 <- refs/remotes/trunk@3
| * MOVE <- refs/remotes/tags/v1
| * TAG1 <- refs/remotes/tags/v1@3
|/
* PREPARE <- refs/remotes/tags/v1@1
The most pressing issue is that the refs/remotes/tags/v1 branch starts
directly from the first PREPARE commit instead of VERSION1. Also, the
branch point of refs/remotes/tags/v2 seems to be incorrect, it should
be based on the VERSION2 commit instead of MOVE.
A more accurate commit graph would be:
* TAG2 <- refs/remotes/tags/v2
* VERSION2 <- refs/remotes/trunk
* MOVE
| * MOVE <- refs/remotes/tags/v1
| * TAG1
|/
* VERSION1
* PREPARE
Or even (but I guess git-svn needs to map each svn commit to at least
one git commit, so this probably wouldn't work):
* VERSION2 <- refs/remotes/trunk, refs/remotes/tags/v2
* VERSION1 <- refs/remotes/tags/v1
* PREPARE
I tried working my way through git-svn.perl to figure out how to
improve the way git-svn tracks svn moves, but so far I couldn't figure
out how to do that. Any ideas or hints?
BR,
Jukka Zitting
=====
#!/bin/sh
REPO=`pwd`/repo
svnadmin create $REPO
svn checkout file://$REPO checkout
cd checkout
svn mkdir projectA
svn mkdir projectA/trunk
svn mkdir projectA/branches
svn mkdir projectA/tags
svn commit -m PREPARE
echo VERSION1 > projectA/trunk/README.txt
svn add projectA/trunk/README.txt
svn commit -m VERSION1
svn copy projectA/trunk projectA/tags/v1
svn commit -m TAG1
svn update
svn move projectA projectB
svn commit -m MOVE
echo VERSION2 > projectB/trunk/README.txt
svn commit -m VERSION2
svn copy projectB/trunk projectB/tags/v2
svn commit -m TAG2
svn update
mkdir ../git
cd ../git
git svn init -s file://$REPO/projectB
git svn fetch
^ permalink raw reply
* gitk: Author/Committer name with special characters
From: Torsten Paul @ 2008-07-16 22:24 UTC (permalink / raw)
To: git; +Cc: Paul Mackerras
Hi!
I'm tracking a subversion repository which is running on
a windows machine with git-svn. The user names look like
DOMAIN\username and that's giving a strange display in
gitk as the backslash sequence is evaluated.
I'm not sure if I found the correct place to prevent this,
so I'd like to ask if the following change would be the
correct thing to prepare as patch...
ciao,
Torsten.
diff --git a/gitk-git/gitk b/gitk-git/gitk
index fddcb45..f114fa2 100644
--- a/gitk-git/gitk
+++ b/gitk-git/gitk
@@ -1510,10 +1510,10 @@ proc parsecommit {id contents listed} {
set tag [lindex $line 0]
if {$tag == "author"} {
set audate [lindex $line end-1]
- set auname [lrange $line 1 end-2]
+ set auname [join [lrange [split $line] 1 end-2]]
} elseif {$tag == "committer"} {
set comdate [lindex $line end-1]
- set comname [lrange $line 1 end-2]
+ set comname [join [lrange [split $line] 1 end-2]]
}
}
set headline {}
^ permalink raw reply related
* Re: Considering teaching plumbing to users harmful
From: Dmitry Potapov @ 2008-07-16 22:24 UTC (permalink / raw)
To: Avery Pennarun; +Cc: Junio C Hamano, Johannes Schindelin, git
In-Reply-To: <32541b130807161229ob4c21cbsc6c86ee3e42c4101@mail.gmail.com>
On Wed, Jul 16, 2008 at 03:29:39PM -0400, Avery Pennarun wrote:
>
> I find it interesting how git usability discussions tend to go. It
> usually starts out by someone saying, "Look, git really isn't that
> hard to learn, just do it like this..." and then someone says, "But
> actually, that's still really complicated. Everyone thinks xxx other
> VCS is easier to learn. Here's how they do it..."
Everyone thinks so? Somehow, I don't, and there are people who think
that Git is easily to learn if you teach it properly.
> And then someone
> says, "Yeah, but xxx VCS sucks!" and that somehow makes it okay that
> git is empirically harder to learn than xxx VCS, as anyone can see by
> browsing the web.
Browsing the web is not an empirical study. And if you say harder, you
should specify to whom. To those who already know xxx VCS, naturally
anything new or different than what you got used to will be difficult
at the beginning. Naturally, it is easier to learn something if there
are more books and articles about it, or just there are more people who
can answer on any your questions. But with everything else being equal,
do you really believe that SVN or CVS is easier to use than Git if we
speak about learning comparable functionality? What is your argument
for that? "svn update"? Well, it is a sure way to make mess in your
working directoy. So, your argument does not sound very convincing.
Dmitry
^ permalink raw reply
* Re: Considering teaching plumbing to users harmful
From: Johannes Schindelin @ 2008-07-16 22:28 UTC (permalink / raw)
To: Avery Pennarun; +Cc: Junio C Hamano, git
In-Reply-To: <32541b130807161229ob4c21cbsc6c86ee3e42c4101@mail.gmail.com>
Hi,
On Wed, 16 Jul 2008, Avery Pennarun wrote:
> I find it interesting how git usability discussions tend to go.
I find it not interesting at all, even slightly annoying, that I cannot
seem to start a perfectly valid discussion about advocating porcelain, and
trying to even avoid mentioning plumbing in user-visible documentation,
without somebody highjacking the thread to talk about svn.
I am disinterested in svn. So disinterested that I do not even want to
read about it. What we could learn from svn, we did, positive and
negative lessons, now there is nothing more to be seen here, please move
along.
So can those people who have something to say about _my_ subject of
discussion please speak up? I think this issue has not been discussed
properly.
Thanks.
Dscho
^ permalink raw reply
* Re: Considering teaching plumbing to users harmful
From: Theodore Tso @ 2008-07-16 22:32 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Avery Pennarun, Johannes Schindelin, git
In-Reply-To: <7vr69tpoze.fsf@gitster.siamese.dyndns.org>
On Wed, Jul 16, 2008 at 01:12:53PM -0700, Junio C Hamano wrote:
> If you are advocating that mode of operation to be easy in git, you should
> think again. That pull (be it with or without --rebase) can conflict and
> you would need to resolve it, and then your "stash pop" can conflict
> again. You can have your own "git avery-up" alias which is your "svn up"
> equivalent, but if you train users with that first, the users have to
> learn how to cope with conflicts in individual steps anyway.
>
> Making these three into a single alias is not an improvement either. If
> you are not ready to incorporate other's changes to your history, why are
> you pulling? Being distributed gives the power of working independently
> and at your own pace. You should train your brain to think about the
> workflow first. "You should stash before pull" is _not_ a good advice.
> "Do not pull when you are not ready" is.
What I've found is that some people will take that advice, and other
people won't. Saying that you are thinking about things the wrong way
doesn't really help for people who have been so ingrained into an old
way of doing things. Indeed, it can end up sounding very elistist.
So from a pedagogical perspective, what I would probably do is show
them how to replicate svn-up, and explain to them how this script
works:
#!/bin/sh
# git-up
if git diff --quiet && git diff --quiet --cached ; then
git pull $*
else
git stash ; git pull $*; git stash pop
fi
And then tell them that if this put this into their path, then "git
up" will work the same way as "svn up" --- but that git has a better
way of doing things, and why it is so. And then what I would tell
them is that no really, merges are really easy with git, and that even
if they were to rely on the "git up" alias as a crutch, that over time
they would find that there are much more natural, easy, and powerful
ways of doing things.
In general, I find that people are more willing to listen to "we have
a more powerful way of doing things", if you can first give them the
equivalent of the "dumb and stupid" way that they are used to doing
things so they can switch to the new tool right away without too much
of a steep learning curve; they will then switch to the more
advanced/powerful workflows at their own pace. Other people may have
other pedgogical techniques, but I find mine to work fairly well.
Regards,
- Ted
^ permalink raw reply
* Re: [PATCH 6/7] git rm: Support for removing submodules
From: Johannes Schindelin @ 2008-07-16 22:41 UTC (permalink / raw)
To: Petr Baudis; +Cc: git
In-Reply-To: <20080716191134.19772.85003.stgit@localhost>
Hi,
On Wed, 16 Jul 2008, Petr Baudis wrote:
> This patch adds support for removing submodules to 'git rm', including
> removing the appropriate sections from the .gitmodules file to reflect
> this
I have no time to look at the whole series, or even at the patch, but I
have concerns. Do you really remove the whole directory? Because if you
do, you remove more than what can be possibly reconstructed from the
object store.
That is much more dangerous than what "git rm" does.
For example, you can have local branches, remote settings, untracked
files, etc. in the subdirectory. And that cannot be recovered once
deleted.
I wonder if it really makes sense to integrate that into git-rm, and not
git-submodule, if only to introduce another level of consideration for the
user before committing what is potentially a big mistake.
Ciao,
Dscho
^ permalink raw reply
* Re: Considering teaching plumbing to users harmful
From: Junio C Hamano @ 2008-07-16 22:41 UTC (permalink / raw)
To: Theodore Tso; +Cc: Avery Pennarun, Johannes Schindelin, git
In-Reply-To: <20080716223205.GK2167@mit.edu>
Theodore Tso <tytso@mit.edu> writes:
> So from a pedagogical perspective, what I would probably do is show
> them how to replicate svn-up, and explain to them how this script
> works:
>
> #!/bin/sh
> # git-up
>
> if git diff --quiet && git diff --quiet --cached ; then
> git pull $*
> else
> git stash ; git pull $*; git stash pop
> fi
Looks good, except:
if git diff ....; then
git pull "$@"
else
git stash && git pull "$@" && git stash pop
fi
to make sure the conflict notices won't be scrolled off by error messages
from the later commands.
^ permalink raw reply
* Re: Considering teaching plumbing to users harmful
From: Theodore Tso @ 2008-07-16 22:49 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Avery Pennarun, Junio C Hamano, git
In-Reply-To: <alpine.DEB.1.00.0807170024310.4318@eeepc-johanness>
On Thu, Jul 17, 2008 at 12:28:27AM +0200, Johannes Schindelin wrote:
> Hi,
>
> On Wed, 16 Jul 2008, Avery Pennarun wrote:
>
> > I find it interesting how git usability discussions tend to go.
>
> I find it not interesting at all, even slightly annoying, that I cannot
> seem to start a perfectly valid discussion about advocating porcelain, and
> trying to even avoid mentioning plumbing in user-visible documentation,
> without somebody highjacking the thread to talk about svn.
I've already said I agree with you, but maybe it would be helpful if
you focused the discussion a little more with a concrete suggestion
about how we could improve the user-visible documentation. For
example, it is already the case that "git help" only shows porcelain
commands, that has been a big step forward.
So a concrete suggestion might be to move the list of plumbing
commands from the top-level git man page to a "git-plumbing" man page.
I'll note that the git user manual is pretty good about avoiding the
use of git plumbing commands. It's not until Chapter 9, "Low Level
Git Commands" that it start going into the plumbing. (There are a
couple of mentions of git rev-parse before chapter 9, but that's about
it that I could find).
Was there other git documentation where you think there is too many
references to git plumbing?
- Ted
^ permalink raw reply
* Re: Considering teaching plumbing to users harmful
From: Sean Kelley @ 2008-07-16 22:53 UTC (permalink / raw)
To: git
In-Reply-To: <20080716223205.GK2167@mit.edu>
Hi
On Wed, Jul 16, 2008 at 5:32 PM, Theodore Tso <tytso@mit.edu> wrote:
>
> In general, I find that people are more willing to listen to "we have
> a more powerful way of doing things", if you can first give them the
> equivalent of the "dumb and stupid" way that they are used to doing
> things so they can switch to the new tool right away without too much
> of a steep learning curve; they will then switch to the more
> advanced/powerful workflows at their own pace. Other people may have
> other pedgogical techniques, but I find mine to work fairly well.
>
> Regards,
>
> - Ted
When one has 100 users in a company using a DVCS, you really need some
sort of simplified workflow documented and taught. Not everyone who
writes code is particularly keen on the vagaries of a VCS' commands.
I know that must be shocking to this audience the GIT list, but it is
very very true. They don't give a crap what sort of weird command
combination one can pull out of the 100 or so commands when you type
git-<tab> at a bash prompt. They just want the damn thing to behave
in a somewhat friendly fashion. They want to check in their code and
get on with software development and not over analyzing how many ways
they can do the same command. In my experience, what Ted is
suggesting is the only way to handle it. Most developers just want it
to work and focus on debugging their project. Never expect your users
to have the same interest as you in VCS.
Sean
^ permalink raw reply
* Re: Considering teaching plumbing to users harmful
From: Johannes Schindelin @ 2008-07-16 23:05 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vmykhpn6z.fsf@gitster.siamese.dyndns.org>
Hi,
On Wed, 16 Jul 2008, Junio C Hamano wrote:
> 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
^ permalink raw reply
* Re: Considering teaching plumbing to users harmful
From: Nigel Magnay @ 2008-07-16 23:17 UTC (permalink / raw)
To: Theodore Tso; +Cc: Junio C Hamano, Avery Pennarun, Johannes Schindelin, git
In-Reply-To: <20080716223205.GK2167@mit.edu>
>
> In general, I find that people are more willing to listen to "we have
> a more powerful way of doing things", if you can first give them the
> equivalent of the "dumb and stupid" way that they are used to doing
> things so they can switch to the new tool right away without too much
> of a steep learning curve; they will then switch to the more
> advanced/powerful workflows at their own pace. Other people may have
> other pedgogical techniques, but I find mine to work fairly well.
>
That totally mirrors my experience.
Unless you're teaching people totally new to SCM, they're likely to
have experience of something else, and are likely to ask 'but how do I
do xyz'. And sometimes the reply is rather embarrassing, as the new
and powerful way involves 5x as many commands. That's where it gets
the reputation of complexity (when actually it might be more correct
to be a reputation of verbosity).
I tend to actually avoid the commands (porcelain or plumbing) to begin
with, and actually concentrate on the data structures (commits, blobs,
index etc) - then how various people's repos look when you do
particular commands. That way people tend to relax about the many
commands as they can grok that there's probably lots of things you
need to do bit by bit, but that aren't relevant to understand right
now - this seems to help in abstracting away the complexity without
sweeping it under the carpet.
So I pretty much agree. Your set looks good, but I always do fetch and
merge before pull, and also add rebase at the end.
^ permalink raw reply
* Re: Considering teaching plumbing to users harmful
From: Johannes Schindelin @ 2008-07-16 23:19 UTC (permalink / raw)
To: Dmitry Potapov; +Cc: git
In-Reply-To: <20080716214849.GF2925@dpotapov.dyndns.org>
Hi,
On Thu, 17 Jul 2008, Dmitry Potapov wrote:
> On Wed, Jul 16, 2008 at 06:21:02PM +0100, Johannes Schindelin wrote:
> >
> > I had the pleasure of introducing Git to a few users in the last
> > months and in my opinion, restricting myself to teaching them these
> > commands first helped tremendously:
> >
> > - clone, pull, status, add, commit, push, log
>
> Yes, it is a good list, and I think it is very important at the
> beginning to limit the number commands to 7-8, otherwise many users may
> be confused. And, of course, it is better to stay away from all
> command-line options at first...
Thanks.
> > All of these were presented without options, to keep things simple.
> >
> > In particular, I refrained from giving them the "-a" option to commit.
> > That seemed to help incredibly with their embracing the index as a
> > natural concept (which it is).
>
> Most things that we call as "natural" is those that we got used.
In this case, I have to add that it is natural because it is the way you
_have_ to do it. Even if the other SCMs hide it.
You almost never commit a full revision. You usually update just a couple
of files. Now, even CVS has an extra command to add a file, so it accepts
the fact that staging and committing are two different operations, even if
"cvs add" does not stage the changes of a tracked file.
Of course, it is easier for us: we can use all the lessons learnt from
CVS.
> > Now, it makes me really, really sad that Git has a reputation of being
> > complicated, but I regularly hear from _my_ users that they do not
> > understand how that came about.
>
> I think this reputation is largely due to people who open Git user
> manual, read about >100 commands, were horrified and stopped learning.
Heh. I catually would be delighted if one outcome of this discussion
would be that the user manual starts with a nice big chapter describing
just my first set of commands, without options.
Another nice outcome could be if all the plumbing man pages were moved
into a different section, and all the porcelain's man pages would be
changed to avoid referring to plumbing.
It could be a good idea, too, to explain advanced topics not by command,
but by scenario.
> > Am I the only one who deems teaching plumbing to users ("I like it
> > raw! So I teach it the same way!") harmful?
>
> There is only one thing that seems to be true about teaching Git (or
> anything else) -- there is no single method that works equally well
> for anyone.
I disagree. I think that the first steps are the same for everyone.
Ciao,
Dscho
^ permalink raw reply
* Re: Considering teaching plumbing to users harmful
From: Johannes Schindelin @ 2008-07-16 23:22 UTC (permalink / raw)
To: Stephan Beyer; +Cc: git
In-Reply-To: <20080716220946.GC18558@leksak.fem-net>
Hi,
On Thu, 17 Jul 2008, Stephan Beyer wrote:
> I also think that for a user it is totally irrelevant if it is plumbing
> or porcelain she is using, as long as it works. I mean, if I tought
> someone using git, I'd never use the words "porcelain" or "plumbing".
So you would say that remembering the name "rev-parse" is just as easy as
remembering "show"?
You want to say that --keep-dash-dash and --stat are on the same level,
since both work? Somehow I don't think so.
Ciao,
Dscho
^ permalink raw reply
* [PATCH] guilt(1): fix path to git-sh-setup
From: Alex Chiang @ 2008-07-16 23:23 UTC (permalink / raw)
To: jeffpc; +Cc: git
git is in the process of moving subcommands to /usr/libexec/git-core
This move breaks an assumption in guilt about the location of
git-sh-setup.
We can ask git for where it thinks its executables live.
Signed-off-by: Alex Chiang <achiang@hp.com>
---
diff --git a/guilt b/guilt
index 50414a4..ba4593a 100755
--- a/guilt
+++ b/guilt
@@ -23,7 +23,7 @@ esac
# we change directories ourselves
SUBDIRECTORY_OK=1
-. git-sh-setup
+. `git --exec-path`/git-sh-setup
#
# Git version check
^ permalink raw reply related
* GSoC podcast 18: Git
From: Johannes Schindelin @ 2008-07-16 23:35 UTC (permalink / raw)
To: git; +Cc: spearce
Hi list,
you might be interested in listening to Leslie Hawthorn interviewing Git's
GSoC administrator (Shawn) and his lazy bum^Wbackup administrator (yours
truly).
I haven't seen it being mentioned on the official blog, but after waiting
for over an hour, I figured I could just send the direct link:
http://google-developer-podcast.googlecode.com/files/gsocpodcast018.ogg
Enjoy,
Dscho
^ permalink raw reply
* Re: Considering teaching plumbing to users harmful
From: Junio C Hamano @ 2008-07-16 23:40 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <alpine.DEB.1.00.0807170100320.4318@eeepc-johanness>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> Hi,
>
> On Wed, 16 Jul 2008, Junio C Hamano wrote:
>
>> 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.
Perhaps you did not read my first paragraph?
^ permalink raw reply
* Re: Considering teaching plumbing to users harmful
From: Johannes Schindelin @ 2008-07-17 0:02 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vk5flo0si.fsf@gitster.siamese.dyndns.org>
Hi,
On Wed, 16 Jul 2008, Junio C Hamano wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>
> > On Wed, 16 Jul 2008, Junio C Hamano wrote:
> >
> >> 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.
>
> 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.
^ permalink raw reply
* Re: GSoC podcast 18: Git
From: Sverre Rabbelier @ 2008-07-17 0:02 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git, spearce
In-Reply-To: <alpine.DEB.1.00.0807170133150.4318@eeepc-johanness>
On Thu, Jul 17, 2008 at 1:35 AM, Johannes Schindelin
<Johannes.Schindelin@gmx.de> wrote:
> Hi list,
>
> you might be interested in listening to Leslie Hawthorn interviewing Git's
> GSoC administrator (Shawn) and his lazy bum^Wbackup administrator (yours
> truly).
Interesting! What is the subject of the interview though?
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* Re: git-cvsexportcommit keyword mismatch issue
From: Lars Noschinski @ 2008-07-16 23:16 UTC (permalink / raw)
To: git
In-Reply-To: <E1KJ30U-0004EL-BV@corti>
* Barak A. Pearlmutter <barak@cs.nuim.ie> [08-07-16 11:09]:
>Simply avoiding expanded keywords should solve the problem. I thought
>git-cvsimport -k would keep them out of my git repo, but no such luck.
>Even when I use "cvs checkout -kk" for the CVS sandbox and then
>"git-cvsimport -k", keywords were *still* expanded in my git repo.
>(This is with both git 1.4.4.4 and git 1.5.6.) Either the -k switch
>to git-cvsimport is busted, or I'm doing something wrong.
git-cvsimport -k works for me as of version 1.5.5.2 and 1.5.6.2.
In my opinion, git-cvsexportcommit misses an option -k to do cvs update
with -kk (as -kk is sticky for already checked out files, but not for
the whole repository, so new files will not get -kk set). If I cannot
get rid of this cvs repository soon, I'll probably cook up a patch for
it.
^ permalink raw reply
* Re: Considering teaching plumbing to users harmful
From: Johannes Schindelin @ 2008-07-17 0:25 UTC (permalink / raw)
To: Theodore Tso; +Cc: Avery Pennarun, Junio C Hamano, git
In-Reply-To: <20080716224954.GL2167@mit.edu>
Hi,
On Wed, 16 Jul 2008, Theodore Tso wrote:
> I've already said I agree with you, but maybe it would be helpful if you
> focused the discussion a little more with a concrete suggestion about
> how we could improve the user-visible documentation.
Well, I was not sure if I was full of shot or not.
> So a concrete suggestion might be to move the list of plumbing commands
> from the top-level git man page to a "git-plumbing" man page.
I think that would not help much.
As I replied to Dimitry, I could imagine that moving the plumbing into its
own manual section would be a way.
> I'll note that the git user manual is pretty good about avoiding the use
> of git plumbing commands. It's not until Chapter 9, "Low Level Git
> Commands" that it start going into the plumbing. (There are a couple of
> mentions of git rev-parse before chapter 9, but that's about it that I
> could find).
Well, rev-parse is one of my pet peeves this day. rev-parse is _nothing_
but plumbing.
> Was there other git documentation where you think there is too many
> references to git plumbing?
Actually, the problem arose with a few "tutorials" on the web, and their
creators violently arguing for their ways (and me being more and more
uncertain if they are wrong or me).
And then I saw people on IRC doing the same thing. Realizing that the
recipients of the "help" were more confused than before, and just typed
what was written (they would probably even have typed "rm -rf $HOME")
because they had given up trying to understand.
Ciao,
Dscho
^ permalink raw reply
* Re: GSoC podcast 18: Git
From: Johannes Schindelin @ 2008-07-17 0:27 UTC (permalink / raw)
To: sverre; +Cc: git, spearce
In-Reply-To: <bd6139dc0807161702m48f3caefre2202fc7cdbdee5a@mail.gmail.com>
Hi,
On Thu, 17 Jul 2008, Sverre Rabbelier wrote:
> On Thu, Jul 17, 2008 at 1:35 AM, Johannes Schindelin
> <Johannes.Schindelin@gmx.de> wrote:
>
> > you might be interested in listening to Leslie Hawthorn interviewing
> > Git's GSoC administrator (Shawn) and his lazy bum^Wbackup
> > administrator (yours truly).
>
> Interesting! What is the subject of the interview though?
Git?
:-D,
Dscho
^ permalink raw reply
* Re: GSoC podcast 18: Git
From: Sverre Rabbelier @ 2008-07-17 0:32 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git, spearce
In-Reply-To: <alpine.DEB.1.00.0807170227100.4318@eeepc-johanness>
On Thu, Jul 17, 2008 at 2:27 AM, Johannes Schindelin
<Johannes.Schindelin@gmx.de> wrote:
> Hi,
>
> On Thu, 17 Jul 2008, Sverre Rabbelier wrote:
>
>> On Thu, Jul 17, 2008 at 1:35 AM, Johannes Schindelin
>> <Johannes.Schindelin@gmx.de> wrote:
>>
>> > you might be interested in listening to Leslie Hawthorn interviewing
>> > Git's GSoC administrator (Shawn) and his lazy bum^Wbackup
>> > administrator (yours truly).
>>
>> Interesting! What is the subject of the interview though?
>
> Git?
>
> :-D,
Dun dun dun, captain obvious to the rescue! Am listening to it now and
it seems to be a general talk on Git's participation in GSoC, and how
Shawn and Dscho experienced GSoC as a mentor as well.
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* Re: [PATCH] Use SHELL_PATH
From: SungHyun Nam @ 2008-07-17 0:32 UTC (permalink / raw)
To: git; +Cc: sverre, namsh, git
In-Reply-To: <7vr69tu91e.fsf@gitster.siamese.dyndns.org>
Junio C Hamano wrote:
> "Sverre Rabbelier" <alturin@gmail.com> writes:
>
>> On Wed, Jul 16, 2008 at 3:31 AM, SungHyun Nam <goweol@gmail.com> wrote:
>>> Signed-off-by: SungHyun Nam <goweol@gmail.com>
>>> ---
>>> t/Makefile | 2 +-
>>> 1 files changed, 1 insertions(+), 1 deletions(-)
>>>
>>> diff --git a/t/Makefile b/t/Makefile
>>> index a778865..0d65ced 100644
>>> --- a/t/Makefile
>>> +++ b/t/Makefile
>>> @@ -26,7 +26,7 @@ clean:
>>> $(RM) -r 'trash directory' test-results
>>>
>>> aggregate-results:
>>> - ./aggregate-results.sh test-results/t*-*
>>> + '$(SHELL_PATH_SQ)' ./aggregate-results.sh test-results/t*-*
>>>
>>> # we can test NO_OPTIMIZE_COMMITS independently of LC_ALL
>>> full-svn-test:
>>> --
>>> 1.5.6.3.350.g6c11a
>> It is not clear to me what this patch does, there is no justification
>> in the commit msg either. Instead you say what is being done, which we
>> can see from the commit diff. Please clarify?
>
> It wants to make sure that the shell specified from the toplevel Makefile
> (or from make command line) is used to run the aggregation script. It is
> often necessary when platform /bin/sh is not quite POSIX (e.g. the script
> in question uses arithmetic expansion "$(( $var1 + $var2 ))").
>
> Just saying "Use specified shell to run shell scripts" on the title line
> would be sufficient, but I wonder if this is the only remaining place...
For the 'make test', yes, it's the only remaining place to me.
Well, I skip the cvs/svn/.. tests which I never use.
And I need this patch for the Solaris.
And I also need to run a script function below between 'make all'
and 'make test/install'. I hope GIT does this. Of course, GIT's
Makefile would use SHELL_PATH and PERL_PATH.
git_fix_interpreter()
{
p="/usr/local/bin/perl"
if test -x "$p"
then
for f in $(find . -name '*.perl')
do
e=$(dirname $f)/$(basename $f .perl)
[ -f "$e" -a -x "$e" ] \
&& "$p" -pi -e
's@^#!/usr/(bin/perl.*)$@#!/usr/local/\1@g' "$e"
done
fi
if test -x /bin/bash
then
for f in $(find . -name '*.sh')
do
e=$(dirname $f)/$(basename $f .sh)
[ -f "$e" -a -x "$e" ] \
&& "$p" -pi -e 's@^#!/bin/sh(.*)$@#!/bin/bash\1@g' "$e"
done
fi
}
^ permalink raw reply
* Re: [PATCH] Use SHELL_PATH
From: SungHyun Nam @ 2008-07-17 0:38 UTC (permalink / raw)
To: git; +Cc: namsh, git, sverre, namsh
In-Reply-To: <487E932A.5080502@gmail.com>
SungHyun Nam wrote:
> And I also need to run a script function below between 'make all'
> and 'make test/install'. I hope GIT does this. Of course, GIT's
> Makefile would use SHELL_PATH and PERL_PATH.
Oops! I'm sorry! Ignore this part. GIT alreay does it, just i didn't
realize that.
Regards,
namsh
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox