* 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
* Re: GSoC podcast 18: Git
From: Sverre Rabbelier @ 2008-07-17 0:57 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git, spearce
In-Reply-To: <bd6139dc0807161732p70d01b32o39b85c8cbc75c8e9@mail.gmail.com>
On Thu, Jul 17, 2008 at 2:32 AM, Sverre Rabbelier <alturin@gmail.com> wrote:
> 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.
Also the origin of Shawn's forced-upon nickname on #git is explained,
which is rather hilarious :P. (I won't give it away, you should listen
to the podcast!)
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* Re: Considering teaching plumbing to users harmful
From: Stephan Beyer @ 2008-07-17 1:01 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <alpine.DEB.1.00.0807170120170.4318@eeepc-johanness>
Hi,
Johannes Schindelin wrote:
> 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"?
"show" is an intuitional name, "rev-parse" is not.[1]
But that wasn't my point. The point was, that it is not important to a
user whether the tool is called "plumbing" or "porcelain"; that these
terms have no value for the user, if she just wants to get a job done.
Of course, "usually" porcelain is more helpful and as I've said (or
at least tried to say), I don't think there is any plumbing that's
useful for a git beginner.
Regards,
Stephan
Footnote:
1. A further comment about the intuitionality or "remembering":
git-apply is plumbing and has an intuitional name (hence easy to
remember), git-am is porcelain and does not have one.
--
Stephan Beyer <s-beyer@gmx.net>, PGP 0x6EDDD207FCC5040F
^ permalink raw reply
* Re: [PATCH (GIT-GUI)] Fix pre-commit hooks under MinGW/MSYS
From: Shawn O. Pearce @ 2008-07-17 1:18 UTC (permalink / raw)
To: Alexander Gavrilov; +Cc: git
In-Reply-To: <200807170012.28769.angavrilov@gmail.com>
Alexander Gavrilov <angavrilov@gmail.com> wrote:
> Apply the work-around for checking the executable
> permission of hook files not only on Cygwin, but on
> Windows in general.
>
> Signed-off-by: Alexander Gavrilov <angavrilov@gmail.com>
> ---
> This is a fix for msysgit issue #118.
> (http://code.google.com/p/msysgit/issues/detail?id=118)
>
> I've already sent this patch, but resend it as I haven't received any reply,
> and it is not in git-gui.git yet.
Thanks. I'm not sure why I dropped this earlier, but it is
in my git-gui tree now.
> diff --git a/git-gui.sh b/git-gui.sh
> index e6e8890..2d14bf2 100755
> --- a/git-gui.sh
> +++ b/git-gui.sh
> @@ -473,10 +473,10 @@ proc githook_read {hook_name args} {
> set pchook [gitdir hooks $hook_name]
> lappend args 2>@1
>
> - # On Cygwin [file executable] might lie so we need to ask
> + # On Windows [file executable] might lie so we need to ask
> # the shell if the hook is executable. Yes that's annoying.
> #
> - if {[is_Cygwin]} {
> + if {[is_Windows]} {
> upvar #0 _sh interp
> if {![info exists interp]} {
> set interp [_which sh]
--
Shawn.
^ permalink raw reply
* Re: gitk: Author/Committer name with special characters
From: Paul Mackerras @ 2008-07-16 23:55 UTC (permalink / raw)
To: Torsten Paul; +Cc: git
In-Reply-To: <487E7525.7000708@gmx.de>
Torsten Paul writes:
> 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...
Something like that, I think, but to be sure I'd like to see the
actual author and committer lines that are causing the problem. Could
you send me the output of "git cat-file commit" on one of the
problematic commits?
Thanks,
Paul.
^ permalink raw reply
* Re: [PATCH (GIT-GUI) 0/3] Improve gui blame usability for large repositories
From: Shawn O. Pearce @ 2008-07-17 2:16 UTC (permalink / raw)
To: Alexander Gavrilov; +Cc: git
In-Reply-To: <200807170042.29462.angavrilov@gmail.com>
Alexander Gavrilov <angavrilov@gmail.com> wrote:
> Full copy detection can take quite some time on large repositories, which
> substantially decreases perceived usability of the 'git gui blame' command.
> This set of patches tries to overcome it by:
>
> 1) Allowing the user to disable '-C -C' and/or set the detection threshold.
>
> 2) Explicitly killing back-end processes, which don't produce any output
> during copy detection, and thus normally won't receive SIGPIPE until
> it is finished. Runaway processes are annoying.
>
> 3) To compensate for (1), adding a context menu item to manually invoke
> blame -C -C -C on a group of lines.
This series is nicely done. Works well on revision.c in git.git,
where the blame can be costly to compute with full copy detection.
And getting the incremental from the context menu also works well.
Thanks.
--
Shawn.
^ permalink raw reply
* Re: [PATCH 5/7] git mv: Support moving submodules
From: Junio C Hamano @ 2008-07-17 2:37 UTC (permalink / raw)
To: Petr Baudis; +Cc: git
In-Reply-To: <20080716191129.19772.41903.stgit@localhost>
Petr Baudis <pasky@suse.cz> writes:
> The usage of struct path_list here is a bit abusive,...
I do not think use of path_list->util is particularly bad. It is a data
structure to store a bag of random pointers that can be indexed with
string keys, which is exactly what you are doing here.
> ... The horrid
> index_path_src_sha1 hack is unfortunately much worse,
This one certainly is ugly beyond words.
By the way, why is it even necessary to rehash the contents when you run
"mv"?
IOW,
$ >foo
$ git add foo
$ echo 1 >foo
$ git mv foo bar
makes "foo" disappear from the index and adds "bar", but it makes the
local change added to the index at the same time.
Side note. It actually is a lot worse than that. When you move
something to another existing entry, the code does not even add
the object name of moved entry recorded in the index, nor rehashes
the moved file. This is totally inconsistent!
I personally think these buggy behaviours you are trying to inherit are
making this patch more complex than necessary. Perhaps this needs to be
fixed up even further (you did some fix with the first patch) before
adding new features? For example, I think it is a bug that the
"overwrite" codepath does not work with symlinks.
But let's assume that we do not want to "fix" any of these existing
(mis)behaviour, because doing so would change the semantics.
There are a few cases:
(1) gitlink exists and so is directory but no repository (i.e. the user is
not interested);
(2) gitlink exists and there is a repository. Its HEAD matches what
gitlink records;
(3) gitlink exists and there is a repository. Its HEAD does not match what
gitlink records;
The (mis)behaviour that automatically adds moved files to the index we saw
earlier suggests that in case (3) you would want to update the gitlink in
the index with whatever HEAD the submodule repository has to be
consistent.
So instead of adding a index_path_src_sha1 hack like that, how about
* When you see ce_is_gitlink(j), you keep the original gitlink object
name. That is very good in order to preserve it for not just (1) but
also for (3) once we decide to fix this "auto adding" misbehaviour in
the later round. But you do not have to do this for case (2) if you
are going to rehash anyway, don't you?
So when you see ce_is_gitlink(j), you check if it has repository and
HEAD, and record the path_list->util only when it is case (1).
* Then, only for case (1), you do not call add_file_to_cache() -- because
you know you do not have anything you can rehash; instead, factor out
the codepath "git-update-index --cacheinfo" uses and call that.
^ permalink raw reply
* Re: Considering teaching plumbing to users harmful
From: Theodore Tso @ 2008-07-17 2:47 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Avery Pennarun, Junio C Hamano, git
In-Reply-To: <alpine.DEB.1.00.0807170218280.4318@eeepc-johanness>
On Thu, Jul 17, 2008 at 02:25:05AM +0200, Johannes Schindelin wrote:
> Well, rev-parse is one of my pet peeves this day. rev-parse is _nothing_
> but plumbing.
Actually the the git man page doesn't list rev-parse as 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).
I know you don't like hearing about SVN, but normally the tutorials I
tend to point people to, in addition to the standard official git
tutorial and git's user manual, are these two web pages. First I tell
people to read first part of:
http://utsl.gen.nz/talks/git-svn/intro.html
which covers the git "philosophy" very nicely, up to the point where
it starts talking about the "git svn" command, and then I tell them to
go read:
http://git.or.cz/course/svn.html
There are no git plumbing commands in either of those two web pages,
because most SVN users would run screaming if they were given a
tutorial that talked about git-read-tree or git-commit-tree. :-)
- Ted
^ permalink raw reply
* Re: Considering teaching plumbing to users harmful
From: Stephen Sinclair @ 2008-07-17 3:21 UTC (permalink / raw)
To: Theodore Tso; +Cc: Junio C Hamano, Avery Pennarun, Johannes Schindelin, git
In-Reply-To: <20080716223205.GK2167@mit.edu>
On Wed, Jul 16, 2008 at 6:32 PM, Theodore Tso <tytso@mit.edu> wrote:
> 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
Wouldn't this be confusing if they have a few commits on the local
branch that aren't yet pushed to the remote branch?
They could suddenly have conflicts that have nothing to do with the
working tree, which could throw people off. Not to mention the
meaningless merges that clutter the gitk display.
I know I was personally pretty confused the first few times this
happened and I had little trapezoidal patterns in gitk showing 2
commits being automerged between the local and remote branches. This
was before I understood the concepts of local and remote branches.
Perhaps some warning when...
if git diff --quiet origin/master HEAD; then...
Personally I've since learned that git-pull is a command to think
about a little before doing, as opposed to svn up, since you might
have to resolve things you aren't prepared for, and we're trying to
avoid teaching git-reset here. I've had to untrain myself from using
git-pull, switching to git-fetch/merge more and more often, because I
keep doing stupid 3-commit merges by mistake when I didn't intend to.
Some tracking of what's been pushed and what hasn't is helpful to keep
things in the expected order imho.
Steve
^ permalink raw reply
* Re: [PATCH] gitk - work around stderr redirection on Cygwin
From: Eric Blake @ 2008-07-17 3:55 UTC (permalink / raw)
To: Mark Levedahl; +Cc: Junio C Hamano, paulus, git
In-Reply-To: <487A7949.9050800@gmail.com>
According to Mark Levedahl on 7/13/2008 3:53 PM:
>>>
>>>> Cygwin is *still* shipping with antiquated Tcl 8.4.1
>>>>
>>> Ping. This bug is in 1.5.6.x, and thus also in the current Cygwin git
>>> release: as a result, several gitk context menu items cause
>>> errors. (Let me know if I should resend the patch).
> I certainly have this patch in my tree so the folks I supply git to who
> use Cygwin have this patch. The question of whether to maintain this out
> of tree for the official Cygwin release is up to Eric.
Could you point me to the patch? I need to roll the Cygwin git release of
1.5.6.3 anyway (in part because cygwin has upgraded from perl 5.8 to
5.10). This sounds like something worth me including as a vendor patch,
if it does not get folded into the main repo.
--
Don't work too hard, make some time for fun as well!
Eric Blake ebb9@byu.net
^ 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