* Re: [PATCH] Invoke git-repo-config directly.
From: Junio C Hamano @ 2006-03-17 2:10 UTC (permalink / raw)
To: git
In-Reply-To: <44196DE7.8010205@op5.se>
Andreas Ericsson <ae@op5.se> writes:
>> . ${GIT_EXEC_PATH-'@@@GIT_EXEC_PATH@@@'}/git-sh-setup
>> isn't too grim, and shows how the git_exec shell function can be made
>> somewhat terser.
>
> But it breaks the convenience when testing.
I think that's OK. When I test things in the build directory
without installing I would usually do:
$ GIT_EXEC_PATH=`pwd` PATH=`pwd`:/usr/bin:/bin ./git-cmd-to-test
and the above would not break things.
^ permalink raw reply
* Re: git-reset and clones
From: Junio C Hamano @ 2006-03-17 2:10 UTC (permalink / raw)
To: paul; +Cc: git list
In-Reply-To: <Pine.LNX.4.64.0603161424310.5276@sheen.jakma.org>
Paul Jakma <paul@clubi.ie> writes:
> If a git repository has a reset HEAD~X done, then any later pulls in
> clone repositories get /really/ upset, with:
>
> $ git pull
> * refs/heads/origin: does not fast forward to branch 'master' of
> /home/paul/foo-git/;
>
> Type of thing. This seems to be a similar issue to:
>
> http://www.gelato.unsw.edu.au/archives/git/0510/10767.html
>
> The question is has this improved at all since last year? Is there
> anything the origin repository maintainer (the one who did reset) can
> do to recover from this?
You used to have something like this:
o---o---o---A
/ ^ your HEAD used to point at here
---o---o---o
and you forgot other people already have the commit chain up to
commit A. But you rewound and did cleanups:
o---o---o---A
/
---o---o---o---o---o---B
^ your HEAD now points at here
People who track your HEAD have A and your updated head B does
not fast forward. Oops.
The recovery consists of two steps. The first step is more
important. To find what commits you lost that others already
may have. You may be lucky and remember A's commit object name,
but when I did that I had to ask around on the list X-<.
The second step is a single command:
$ git merge -s ours 'Graft the lost side branch back in' \
HEAD A
where A is the object name of that commit. On your current
branch, this creates a merge commit between A and B (your
current HEAD), taking the tree object from B.
o---o---o---A
/ \
---o---o---o---o---o---B---M
You want to keep the contents of the cleaned-up HEAD, so that is
why you are taking the tree from B. With this commit M, you are
telling the outside world that it is OK if they start from a
commit on the now-recovered side branch.
If the tree of A and B exactly match, further merges with people
starting from A branch would not have conflicts. If the
difference between A and B are mostly clean-ups, automerge would
lose dirtiness you cleaned-up when they update to your new HEAD
(because the transition from A to M reverts the dirtiness, which
is what your clean-up was about), which is what you want.
^ permalink raw reply
* Re: First dumb question to the list :)
From: Alex Riesen @ 2006-03-16 22:11 UTC (permalink / raw)
To: Paolo Ciarrocchi; +Cc: git
In-Reply-To: <4d8e3fd30603160949l655c4f9blb1e202eaf22fbfe@mail.gmail.com>
Paolo Ciarrocchi, Thu, Mar 16, 2006 18:49:16 +0100:
> What I want to do is to simply keep my repository aligned with Linus
> so I simply have to do:
> cd linus2.6
> cg-fetch
Or "git pull"
> How can I confg git in order to, by default, use git instead of rsync ?
By editing .git/remotes/origin and replacing "rsync://rsync." with
"git://git." (I think the rest is identical, but you better check).
> Now my dumb question is... since I want to build that kernel do I have
> to locally clone/copy it in order to don't modify any file on my local
> tree?
No. As long you don't modify anything under .git you can always get to
any state of your kernel tree you ever had (assuming you _use_ git, of
course).
Or you can just revert your changes after you've played enough with
them: "git reset --hard".
^ permalink raw reply
* Re: [PATCH] Invoke git-repo-config directly.
From: Qingning Huo @ 2006-03-16 20:33 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v64mebxsu.fsf@assigned-by-dhcp.cox.net>
On Thu, Mar 16, 2006 at 12:26:09AM -0800, Junio C Hamano wrote:
>
> We could probably define a shell function that looks like:
>
> git_exec () {
> cmd="$1"
> shift
> case "${GIT_EXEC_PATH+set}" in
> set) ;;
> *) GIT_EXEC_PATH='@@GIT_EXEC_PATH@@' ;;
> esac
> "$GIT_EXEC_PATH/git-$cmd" "$@"
> }
>
> in git-sh-setup [*1*], and then rewrite the above to something
> like this instead:
>
> diff --git a/git-commit.sh b/git-commit.sh
> index 330a434..8a73420 100755
> --- a/git-commit.sh
> +++ b/git-commit.sh
> ...
> @@ -115,7 +115,7 @@ run_status () {
> echo '#
> # Initial commit
> #'
> - git-ls-files |
> + git_exec ls-files |
> sed -e '
> s/\\/\\\\/g
> s/ /\\ /g
> @@ -126,7 +126,7 @@ run_status () {
> committable="$?"
> fi
>
> - git-diff-files --name-status |
> + git_exec diff-files --name-status |
> sed -e '
> s/\\/\\\\/g
> s/ /\\ /g
> ...
>
> But that does not cover Perl nor Python scripts, and does not
> address the ugliness either.
This is similiar to what I had in mind when I recommended the full path
approach. Perl or Python should be able to do the similiar. I have no
comment on the ugliness. The functionality and effeciency of the
program is more important to me. But I do recognize the difficulties of
changing all scripts overnight.
Anyway, there are at least other two ways to solve my problem. (a)
setup PATH in git-sh-setup, or (b) consistently use git-command form in
scripts. Even before their implementation, I can still use "git push".
Qingning
^ permalink raw reply
* Re: [PATCH] Invoke git-repo-config directly.
From: Jon Loeliger @ 2006-03-16 19:32 UTC (permalink / raw)
To: Git List
In-Reply-To: <1142537257.17536.137.camel@cashmere.sps.mot.com>
On Thu, 2006-03-16 at 13:27, Jon Loeliger wrote:
> While we want to proved an abstraction layer to the
> user through the "git" wrapper, we still want to be
> precise internally within the scripts themselves.
Hey! Nice English there, Jon!
s/proved/provide
jdl
^ permalink raw reply
* Re: [PATCH] Invoke git-repo-config directly.
From: Jon Loeliger @ 2006-03-16 19:27 UTC (permalink / raw)
To: Git List
In-Reply-To: <7vmzfq8zmr.fsf@assigned-by-dhcp.cox.net>
On Thu, 2006-03-16 at 04:14, Junio C Hamano wrote:
> And the second issue is the last point in the "implications"
> list above. You are right, and I stand corrected. Our scripts
> should consistently use dash form.
>
> One thing that bothers me is that we need to keep encouraging
> users to use dashless form from the command line, while we
> update our scripts to use dash form. What a contradicting and
> confusing situation X-<.
I think it has a philosophical rationale, though.
While we want to proved an abstraction layer to the
user through the "git" wrapper, we still want to be
precise internally within the scripts themselves.
Or so.
jdl
^ permalink raw reply
* First dumb question to the list :)
From: Paolo Ciarrocchi @ 2006-03-16 17:49 UTC (permalink / raw)
To: git
Hi all,
I just installed git and cogito from Ubuntu Drapper,
performed a simple cg-clone git://URItoLinus2.6 linux2.6
and aftwer more or less one hour I had a clone of Linus 2.6 tree.
So far so good.
What I want to do is to simply keep my repository aligned with Linus
so I simply have to do:
cd linus2.6
cg-fetch
How can I confg git in order to, by default, use git instead of rsync ?
Now my dumb question is... since I want to build that kernel do I have
to locally clone/copy it in order to don't modify any file on my local
tree?
If I don't do so, I guess git/cogito will not be happy when I run
cg-fetch, right?
Thanks!
--
Paolo
^ permalink raw reply
* Re: git-reset and clones
From: Paul Jakma @ 2006-03-16 15:48 UTC (permalink / raw)
To: sean; +Cc: git
In-Reply-To: <BAYC1-PASMTP09E59C4F23C4CDF45B1C42AEE70@CEZ.ICE>
On Thu, 16 Mar 2006, sean wrote:
> $ git reset ORIG_HEAD
Ah, of course :).
Thanks.
regards,
--
Paul Jakma paul@clubi.ie paul@jakma.org Key ID: 64A2FF6A
Fortune:
There's no such thing as pure pleasure; some anxiety always goes with it.
^ permalink raw reply
* Re: git-reset and clones
From: sean @ 2006-03-16 15:21 UTC (permalink / raw)
To: Andreas Ericsson; +Cc: paul, git
In-Reply-To: <44197C04.5080400@op5.se>
On Thu, 16 Mar 2006 15:53:56 +0100
Andreas Ericsson <ae@op5.se> wrote:
> In mothership-repo:
> git checkout master
> git branch next-master ORIGIN
> git rebase next-master; # fix conflicts and commit
> git branch -d master
> git checkout -b master next-master
> git -d next-master
> git revert (the bad commits)
Downstream repos may still be broken afterward though; not much
you can do about that unfortunately.
Sean
^ permalink raw reply
* Re: git-reset and clones
From: Andreas Ericsson @ 2006-03-16 14:59 UTC (permalink / raw)
To: Andreas Ericsson; +Cc: Paul Jakma, git list
In-Reply-To: <44197C04.5080400@op5.se>
Andreas Ericsson wrote:
>
> git branch next-master ORIGIN
s/ORIGIN/ORIG_HEAD/
otherwise the advice still applies.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: git-reset and clones
From: sean @ 2006-03-16 14:52 UTC (permalink / raw)
To: Paul Jakma; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0603161424310.5276@sheen.jakma.org>
On Thu, 16 Mar 2006 14:34:42 +0000 (GMT)
Paul Jakma <paul@clubi.ie> wrote:
> If a git repository has a reset HEAD~X done, then any later pulls in
> clone repositories get /really/ upset, with:
>
> $ git pull
> * refs/heads/origin: does not fast forward to branch 'master' of
> /home/paul/foo-git/;
>
> Type of thing. This seems to be a similar issue to:
>
> http://www.gelato.unsw.edu.au/archives/git/0510/10767.html
>
> The question is has this improved at all since last year? Is there
> anything the origin repository maintainer (the one who did reset) can
> do to recover from this?
It's still not a recommended operation on a repository that is pulled
by others. If you realize you made a mistake by resetting the head,
you can undo the operation afterward with:
$ git reset ORIG_HEAD
Sean
^ permalink raw reply
* Re: git-reset and clones
From: Andreas Ericsson @ 2006-03-16 14:53 UTC (permalink / raw)
To: Paul Jakma; +Cc: git list
In-Reply-To: <Pine.LNX.4.64.0603161424310.5276@sheen.jakma.org>
Paul Jakma wrote:
> Hi,
>
> Next dumb question:
>
> If a git repository has a reset HEAD~X done, then any later pulls in
> clone repositories get /really/ upset, with:
>
> $ git pull
> * refs/heads/origin: does not fast forward to branch 'master' of
> /home/paul/foo-git/;
>
> Type of thing. This seems to be a similar issue to:
>
> http://www.gelato.unsw.edu.au/archives/git/0510/10767.html
>
> The question is has this improved at all since last year? Is there
> anything the origin repository maintainer (the one who did reset) can do
> to recover from this?
>
> I'm guessing the answer is:
>
> Yes:
>
> 1. where git-reset has already been done, manually update the
> refs back to the previous HEAD
> 2. then use git-revert, and continue to use git-revert only.
>
> My question then would be, presuming some innocent repository maintainer
> has already done 1, what's the easiest way to accomplish 1?
>
> (they shouldn't have done it obviously, but assume they're git newbies,
> made an honest mistake and now need to recover, preferably without
> having to involve those who pull).
>
I *think* this should work. Get a backup before trying. Note that I'm
assuming "git reset" hasn't been run several times, or you'll have to
replace ORIGIN with whatever HEAD pointed to before the first reset.
In mothership-repo:
git checkout master
git branch next-master ORIGIN
git rebase next-master; # fix conflicts and commit
git branch -d master
git checkout -b master next-master
git -d next-master
git revert (the bad commits)
Some shortcuts can be taken if we're not to use git commands the entire
way, but this is easier to explain to those newbie-ish people you mentioned.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: [PATCH] Invoke git-repo-config directly.
From: Andreas Ericsson @ 2006-03-16 14:39 UTC (permalink / raw)
To: Timo Hirvonen; +Cc: git
In-Reply-To: <20060316162709.6f383f95.tihirvon@gmail.com>
Timo Hirvonen wrote:
> On Thu, 16 Mar 2006 12:53:20 +0000 (UTC)
> Mark Wooding <mdw@distorted.org.uk> wrote:
>
>
>>By the way, am I the only person who /likes/ having all the git-*
>>programs on his path? It makes shell completion work fairly well
>>without having to install strange completion scripts which get out of
>>date for one thing.
>
>
> I like git-* for the same reason. But if git potty had aliases for long
> commands then git-* commands would become irrelevant. Especially
> "git co" would be nice. It even would be faster to type than
> git-ch<tab>c<tab>o<tab> ;)
>
It would indeed, and it should also be fairly trivial. However, adding
short-hands that are identical with cvs and svn but does a totally
different thing (well, not really different, but cvs users will be
surprised) is not necessarily a good thing.
It would be better, imo, to add ambiguity detection for commands that
lacks an exact match. That way "git br" and "git branch" would be
identical and the logic only needs doing once. I'm not terribly excited
about it though, so...
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* git-reset and clones
From: Paul Jakma @ 2006-03-16 14:34 UTC (permalink / raw)
To: git list
Hi,
Next dumb question:
If a git repository has a reset HEAD~X done, then any later pulls in
clone repositories get /really/ upset, with:
$ git pull
* refs/heads/origin: does not fast forward to branch 'master' of
/home/paul/foo-git/;
Type of thing. This seems to be a similar issue to:
http://www.gelato.unsw.edu.au/archives/git/0510/10767.html
The question is has this improved at all since last year? Is there
anything the origin repository maintainer (the one who did reset) can
do to recover from this?
I'm guessing the answer is:
Yes:
1. where git-reset has already been done, manually update the
refs back to the previous HEAD
2. then use git-revert, and continue to use git-revert only.
My question then would be, presuming some innocent repository
maintainer has already done 1, what's the easiest way to accomplish
1?
(they shouldn't have done it obviously, but assume they're git
newbies, made an honest mistake and now need to recover, preferably
without having to involve those who pull).
regards,
--
Paul Jakma paul@clubi.ie paul@jakma.org Key ID: 64A2FF6A
Fortune:
Be cautious in your daily affairs.
^ permalink raw reply
* Re: [PATCH] Invoke git-repo-config directly.
From: Timo Hirvonen @ 2006-03-16 14:27 UTC (permalink / raw)
To: git
In-Reply-To: <slrne1inu0.fr9.mdw@metalzone.distorted.org.uk>
On Thu, 16 Mar 2006 12:53:20 +0000 (UTC)
Mark Wooding <mdw@distorted.org.uk> wrote:
> By the way, am I the only person who /likes/ having all the git-*
> programs on his path? It makes shell completion work fairly well
> without having to install strange completion scripts which get out of
> date for one thing.
I like git-* for the same reason. But if git potty had aliases for long
commands then git-* commands would become irrelevant. Especially
"git co" would be nice. It even would be faster to type than
git-ch<tab>c<tab>o<tab> ;)
--
http://onion.dynserv.net/~timo/
^ permalink raw reply
* Re: [PATCH] Invoke git-repo-config directly.
From: Andreas Ericsson @ 2006-03-16 13:53 UTC (permalink / raw)
To: Mark Wooding; +Cc: git
In-Reply-To: <slrne1inu0.fr9.mdw@metalzone.distorted.org.uk>
Mark Wooding wrote:
> Junio C Hamano <junkio@cox.net> wrote:
>
>
>>*1* BTW, I just noticed that git-sh-setup needs to be on user's
>>PATH, so we probably have to inline and duplicate the git_exec()
>>shell function definition at the beginning of each script after
>>all, when we make the initial ". git-sh-setup" inclusion to
>>honor GIT_EXEC_PATH without munging the user's PATH.
>
>
> . ${GIT_EXEC_PATH-'@@@GIT_EXEC_PATH@@@'}/git-sh-setup
>
> isn't too grim, and shows how the git_exec shell function can be made
> somewhat terser.
>
But it breaks the convenience when testing.
> By the way, am I the only person who /likes/ having all the git-*
> programs on his path? It makes shell completion work fairly well
> without having to install strange completion scripts which get out of
> date for one thing.
>
I like it too, but I don't use it unless I can't remember what the
command was named (finger-training). It shouldn't be too difficult to
make git.c write its own auto-generated bash-completion rules. If
someone would care to teach me the syntax I'd gladly hack up a patch for
it. This is a Good Thing, since it means it would also work for the
internal commands, which bash's path-completion doesn't.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: [PATCH] Invoke git-repo-config directly.
From: Mark Wooding @ 2006-03-16 12:53 UTC (permalink / raw)
To: git
In-Reply-To: <7v64mebxsu.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> wrote:
> *1* BTW, I just noticed that git-sh-setup needs to be on user's
> PATH, so we probably have to inline and duplicate the git_exec()
> shell function definition at the beginning of each script after
> all, when we make the initial ". git-sh-setup" inclusion to
> honor GIT_EXEC_PATH without munging the user's PATH.
. ${GIT_EXEC_PATH-'@@@GIT_EXEC_PATH@@@'}/git-sh-setup
isn't too grim, and shows how the git_exec shell function can be made
somewhat terser.
By the way, am I the only person who /likes/ having all the git-*
programs on his path? It makes shell completion work fairly well
without having to install strange completion scripts which get out of
date for one thing.
-- [mdw]
^ permalink raw reply
* Re: [PATCH] Invoke git-repo-config directly.
From: Andreas Ericsson @ 2006-03-16 11:55 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Qingning Huo, git
In-Reply-To: <7vmzfq8zmr.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
>
> And the second issue is the last point in the "implications"
> list above. You are right, and I stand corrected. Our scripts
> should consistently use dash form.
>
> One thing that bothers me is that we need to keep encouraging
> users to use dashless form from the command line, while we
> update our scripts to use dash form. What a contradicting and
> confusing situation X-<.
>
One of the two reasons for rewriting the git wrapper in C was the
performance penalty that came from having it as a shell-script while it
was desirable from a porcelainish standpoint to use the dash-less form
since we thought even then that "git" would always be in PATH while
"git-foo" was to be moved to the still-imaginary GIT_EXEC_PATH.
The prepending of the GIT_EXEC_PATH to PATH was a laziness workaround
for scripts that use the dashed form until we'd had time to change
those, although I see from the commit-message that it's a far cry from
abundantly clear (reading it now I even think it's clear I meant the
other way around, although I remember I didn't). Anyways, the relative
parts are these, from commit 8e49d50388211a0f3e7286f6ee600bf7736f4814
---8<---8<---8<---
The location of the GIT_EXEC_PATH (name discussion's closed,
thank gods) can be obtained by running
git --exec-path
which will hopefully give porcelainistas ample time to adapt their
heavy-duty loops to call the core programs directly and thus save
the extra fork() / execve() overhead, although that's not really
necessary any more.
The --exec-path value is prepended to $PATH, so the git-* programs
should Just Work without ever requiring any changes to how they call
other programs in the suite.
Some timing values for 10000 invocations of git-var >&/dev/null:
git.sh: 24.194s
git.c: 9.044s
git-var: 7.377s
---8<---8<---8<---
From the timing values there I think the performance issues of using
the dash-less form can just be ignored. Very rarely will a porcelainish
wrapper do 10000 invocations of git commands where less than 2 seconds
will be a large percentage of the overall runtime.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: [PATCH] Invoke git-repo-config directly.
From: Junio C Hamano @ 2006-03-16 10:14 UTC (permalink / raw)
To: Qingning Huo; +Cc: git
In-Reply-To: <20060316075324.GA19650@pfit.vm.bytemark.co.uk>
Qingning Huo <qhuo@mayhq.org> writes:
> On Wed, Mar 15, 2006 at 03:35:36PM -0800, Junio C Hamano wrote:
>> I think some historical background is in order.
>> ...
> Thanks for the historical background.
Sorry, it just occurred to me that I was totally confused, and I
apologize for giving only half of the historical background,
without giving the "end of the story -- conclusion", which I did
not remember until now.
What we ended up deciding after that "My /usr/bin/git is sane
but /usr/bin/diff is wrong so I have /home/$u/bin/diff and
/home/$u/bin is listed earlier in my $PATH" discussion, as I
remember, was this:
* We expect users to invoke things on the command line via the
"git" wrapper. Either having the directory that has our
"git" in earlier on the PATH, or giving the full path to it
as the command (your use of alias qualifies as the latter).
* One of the important things the "git" wrapper does is to
prefix GIT_EXEC_PATH to the $PATH environment before invoking
the "git-foo" commands [*1*].
* "git-foo" command, if it is written in a scripting language,
can safely assume "git-bar" is found on the PATH while it is
executing. If it is C-level and uses exec[vl]_git_cmd() to
run the subcommand, it would also work fine (it will use the
right GIT_EXEC_PATH).
This has a few implications:
* By doing the above setup, we are effectively punting on the
original issue. First of all, it is very inconceivable that
/usr/bin/git is sane, and /usr/bin/diff is not (git wants a
working diff after all). If the user is overriding
/usr/bin/diff by having a better diff under /home/$u/bin/, he
could have his own copy of git under /home/$u/bin/ as well
(more likely, the person with correct privilege to installed
/usr/bin/git would have replaced faulty /usr/bin/diff). More
importantly, when bindir and gitexecdir are split, gitexecdir
will not be /usr/bin (bindir will be). It will more likely
to be /usr/lib/git/exec, and it would contain only git-*
things; prefixing that directory to PATH would not mask the
/home/$u/bin/diff or anything else non-git the user wanted to
mask stuff from /usr/bin with, so the original issue becomes
moot at that point.
* Typing "git-foo" on the command line would work most of the
time, if git is built with gitexecdir set to standard bin
directory (the way our Makefile is shipped). git-foo will be
found on your PATH, and it will find "git-bar" on your PATH.
However, when we split bindir and gitexecdir, typing
"git-foo" on the command line without having GIT_EXEC_PATH on
your PATH would stop working, so users have been encouraged
to train their fingers to use dashless form ever since
GIT_EXEC_PATH was introduced [*2*].
* If "git-foo" invoked from the command line (without necessary
GIT_EXEC_PATH prefixing done by the "git" wrapper) tries to
run "git", the right git needs to be found on your PATH,
otherwise things may not necessarily work (your setup
violates this). But people have been encouraged to say "git
foo" to begin with, so this is probably not a big
deal. Retraining people to say "git foo" instead of "git-foo"
is a bigger issue compared to this.
* If "git foo" is typed on the command line, underlying
"git-foo" is run with GIT_EXEC_PATH prefixed, so it will find
"git-bar". If the script uses "git bar", "git" needs to be
found either in GIT_EXEC_PATH or on your PATH, since our
Makefile does not install "git" in gitexecdir. Right now, we
have bindir == gitexecdir, so "git bar" in "git-foo" script
will work fine and this is a non-issue, but when we split
them, it will break your setup, so we need to address this
before that happens.
So in short, there are two real issues with your original
"git-push misbehaves". One is that it broke because it was
spelled with dash. I think "git push" shouldn't misbehave even
with your setup, because the "git" wrapper, before it calls
"git-push", should set up the PATH so that its exec-path is in
front of anything you have in your original PATH (either
/usr/bin or ~/opt/bin), and should find the right "git".
And the second issue is the last point in the "implications"
list above. You are right, and I stand corrected. Our scripts
should consistently use dash form.
One thing that bothers me is that we need to keep encouraging
users to use dashless form from the command line, while we
update our scripts to use dash form. What a contradicting and
confusing situation X-<.
[Footnote]
*1* The "remove prefixing from git.c" patch I sent out earlier
tonight is wrong. That's the crucial piece to make this whole
setup work.
*2* I think I've been careful enough to use dashless form in the
examples I give in my list postings, but I am not sure how
successful I have been.
^ permalink raw reply
* Re: [PATCH] Invoke git-repo-config directly.
From: Junio C Hamano @ 2006-03-16 8:26 UTC (permalink / raw)
To: Qingning Huo; +Cc: git
In-Reply-To: <20060316075324.GA19650@pfit.vm.bytemark.co.uk>
Qingning Huo <qhuo@mayhq.org> writes:
> So we recognize the full path approach is desired,
I said "if you can work problems your environment has _without_
doing the full path thing, then it would be ideal".
I never said full path is desired -- I despise full path, in
fact. It makes certain things very inconvenient.
> ...but because of
> technique reasons (building and testing), it is not applied.
There were not even a patch. I suspect people involved in the
discussion realized that approach was unworkably cumbersome.
In our Makefile, we have sed script mechanism to replace tokens
so we _could_ change our sources to do something like this:
diff --git a/git-commit.sh b/git-commit.sh
index 330a434..10835c6 100755
--- a/git-commit.sh
+++ b/git-commit.sh
...
@@ -115,7 +115,7 @@ run_status () {
echo '#
# Initial commit
#'
- git-ls-files |
+ @@GIT_PATH@@git-ls-files |
sed -e '
s/\\/\\\\/g
s/ /\\ /g
@@ -126,7 +126,7 @@ run_status () {
committable="$?"
fi
- git-diff-files --name-status |
+ @@GIT_PATH@@git-diff-files --name-status |
sed -e '
s/\\/\\\\/g
s/ /\\ /g
...
and sed it out with 's/@@GIT_PATH@@/$(gitexecdir_SQ)/g'.
However, you have to realize that I often want to try things out
*without* running "make", let alone installing. The current way
things are set up lets me say:
$ GIT_EXEC_PATH=$my_git_source \
sh -x $my_git_source/git-commit.sh
to see where things break. Changing things the way I quoted
above would make things _extremely_ inconvenient for me.
And it is ugly. "Making things ugly and inconvenient for what
purpose?" is the question I have to ask myself at this point.
And if the answer is "to support unusual configuration which,
quite frankly, I think is broken", then...
We could probably define a shell function that looks like:
git_exec () {
cmd="$1"
shift
case "${GIT_EXEC_PATH+set}" in
set) ;;
*) GIT_EXEC_PATH='@@GIT_EXEC_PATH@@' ;;
esac
"$GIT_EXEC_PATH/git-$cmd" "$@"
}
in git-sh-setup [*1*], and then rewrite the above to something
like this instead:
diff --git a/git-commit.sh b/git-commit.sh
index 330a434..8a73420 100755
--- a/git-commit.sh
+++ b/git-commit.sh
...
@@ -115,7 +115,7 @@ run_status () {
echo '#
# Initial commit
#'
- git-ls-files |
+ git_exec ls-files |
sed -e '
s/\\/\\\\/g
s/ /\\ /g
@@ -126,7 +126,7 @@ run_status () {
committable="$?"
fi
- git-diff-files --name-status |
+ git_exec diff-files --name-status |
sed -e '
s/\\/\\\\/g
s/ /\\ /g
...
But that does not cover Perl nor Python scripts, and does not
address the ugliness either.
[Footnote]
*1* BTW, I just noticed that git-sh-setup needs to be on user's
PATH, so we probably have to inline and duplicate the git_exec()
shell function definition at the beginning of each script after
all, when we make the initial ". git-sh-setup" inclusion to
honor GIT_EXEC_PATH without munging the user's PATH.
Which is not a big deal by itself, since we preprocess
*.{sh,perl,py} files anyway, but still it leaves a _big_
ugliness factor.
^ permalink raw reply
* Re: [PATCH] Invoke git-repo-config directly.
From: Junio C Hamano @ 2006-03-16 7:57 UTC (permalink / raw)
To: Qingning Huo; +Cc: git
In-Reply-To: <20060316075324.GA19650@pfit.vm.bytemark.co.uk>
Qingning Huo <qhuo@mayhq.org> writes:
> I cannot uninstall /usr/bin/git. It is not under my control. I am
> wondering whether I should move my home dir to the front of the PATH.
That's what I found your configuration quite unusual.
When people have standard system executable directories such as
/usr/bin and /bin and private directories like /home/$u/bin and
/usr/local/bin on their PATH, private directories always come
before the system directories, so that things in the system
directories (often you do not have write permission to) can be
overriden by private directories (which is under your control).
I've never seen anybody sane to have system path before private
ones.
^ permalink raw reply
* Re: [PATCH] Invoke git-repo-config directly.
From: Qingning Huo @ 2006-03-16 7:53 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Qingning Huo, Linus Torvalds, git
In-Reply-To: <7vlkvbffhz.fsf@assigned-by-dhcp.cox.net>
On Wed, Mar 15, 2006 at 03:35:36PM -0800, Junio C Hamano wrote:
> Linus Torvalds <torvalds@osdl.org> writes:
>
> > On Wed, 15 Mar 2006, Junio C Hamano wrote:
> >>
> >> If we do the dash-form for consistency's sake, we should do
> >> PATH="`git --exec-path`:$PATH" in git-setup-sh when/before we do
> >> so.
> >
> > Yes. That would make sense too. Then git-setup-sh would look more like
> > what the builtin git.c does.
>
> I think some historical background is in order.
>
> We started without bindir vs execdir distinction but we wanted a
> way to someday migrate out of putting everything in bindir. As
> one part of the solution, "git" wrapper was invented, and as the
> result of that effort, some parts of the scripts, and lot of
> documentation pages and sample scripts, lost dashes.
>
> Historically, git tools have always wanted everything git-* to
> be found on user's PATH, and we were alarmed to see 100+ git-*
> commands in /usr/bin. That's why "git" wrapper and
> GIT_EXEC_PATH environment were invented. People can have
> /usr/bin/git and no other git-* on their PATH, because that
> "git" knows where to find the rest of git-* commands. For that
> to work, the scripts should know where to find the rest -- and
> cleanest way is to run others via "git foo" form.
>
> Consistency via s/git-foo/git foo/g _is_ the goal, but that kind
> of change interferes with the other patches that do the real
> work, and it is kind of boring, so nobody has done wholesale
> clean-up of all the scripts.
Thanks for the historical background.
> Invoking with the full path is not an option -- it makes
> building and testing-before-installing process too cumbersome.
> You are welcome to try and send in a patch to do that if (and
> only if) you volunteer to go the whole nine yards, but I have to
> warn you that that approach is something we have already
> considered and discarded, one reason why is because it makes the
> testsuite unworkable (testing needs to be done before
> installing).
So we recognize the full path approach is desired, but because of
technique reasons (building and testing), it is not applied. I would
like to have a look of the said patch. Can you give me some pointers?
> If you want to use the other "git" (GNU interactive tools, which
> I once heard is changing its name to gitfm or something like
> that -- how nice of them -- but has it ever happened?), and if
> you want to have /usr/bin (which has that "git") and then
> /other/bin (which has on-topic "git") on your PATH, in that
> order, that would be a problem. Saying just "git" would invoke
> other "git" that does not know what to do.
This is exactly the problem I want to solve. In this case, I alias git
to use our git program.
> If you can solve that without hardcoding the full path in our
> scripts, that would be ideal. But otherwise, especially with
> changing things back to "git-foo" form without making sure going
> backward in that way would not hinder the migration out of
> /usr/bin, then that creates more problems than it solves.
We do not hard code the full path in the script. We can use a function
gitexec() (in git-sh-setup) similiar to execv_git_cmd(). gitexec
searches git-command in GIT_EXEC_PATH, and then libexedir. libexedir is
hardcoded in git-sh-setup. But can be override by the environment
GIT_EXEC_PATH. The make test target should set GIT_EXEC_PATH to the
build directory.
The remaining job is search and replace. If we call gitexec() git(), we
can even keep the "git command" form unchanged. But I prefer explicit
gitexec().
> I _think_ the simplest fix is to change the order of directories
> you list on your PATH so that "git" is found before GNU
> interactive tool, which is my impression that most people seem
> to do (many in fact do not have GNU interactive tool on their
> PATH anywhere).
I cannot uninstall /usr/bin/git. It is not under my control. I am
wondering whether I should move my home dir to the front of the PATH.
But a good tool should not force users to change their settings.
Qingning
^ permalink raw reply
* Re: [PATCH] Invoke git-repo-config directly.
From: Junio C Hamano @ 2006-03-16 6:37 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Qingning Huo, git
In-Reply-To: <Pine.LNX.4.64.0603151450070.3618@g5.osdl.org>
Linus Torvalds <torvalds@osdl.org> writes:
> On Wed, 15 Mar 2006, Junio C Hamano wrote:
>>
>> If we do the dash-form for consistency's sake, we should do
>> PATH="`git --exec-path`:$PATH" in git-setup-sh when/before we do
>> so.
>
> Yes. That would make sense too. Then git-setup-sh would look more like
> what the builtin git.c does.
I actually think what git.c does is _wrong_.
Believe it or not, there are people with bizarre configurations
just like Qingning's is bizarre in different sense [*1*]. They
have diff they do not like (either broken or inadequete)
installed under /usr/bin, and they install GNU diff under
/home/$u/bin, and have their PATH set so that /home/$u/bin/diff
is found before /usr/bin/diff (up to here, there is nothing
bizarre). However, somehow they have the latest "git" installed
under /usr/bin (this _is_ the bizarre part).
Earlier, we prepended GIT_EXEC_PATH to user-supplied PATH when
C-level routines needed to exec git programs. This breaks that
"bizarre" setup -- for such a setup, GIT_EXEC_PATH is currently
set to /usr/bin and when we try to exec "diff", we ended up
running /usr/bin/diff. So in order to work this around, we
introduced exec[vl]_git_cmd() wrappers which use --exec-path
(if the command supports per invocation override), GIT_EXEC_PATH
environment, and then gitexecdir in Makefile when it was built,
in this order. "git" wrapper should know about this, but the
older code was never removed when we introduced exec_cmd.c.
I think we need to do something like the attached patch.
[Footnote]
*1* I first wrote "configuration even more bizarre than
Qingning's", but before sending the message out I came to
senses. We have to admit that that configuration is quite
unusual, and I would say it is the one more bizarre than the one
in question here. When people have standard system executable
directories such as /usr/bin and /bin and private directories
like /home/$u/bin and /usr/local/bin on their PATH, private
directories always come before the system directories, so that
things in the system directories (often you do not have write
permission to) can be overriden by private directories (which is
under your control).
-- >8 --
diff --git a/git.c b/git.c
index 0b40e30..25e6a4e 100644
--- a/git.c
+++ b/git.c
@@ -219,25 +219,6 @@ static void cmd_usage(int show_all, cons
exit(1);
}
-static void prepend_to_path(const char *dir, int len)
-{
- char *path, *old_path = getenv("PATH");
- int path_len = len;
-
- if (!old_path)
- old_path = "/usr/local/bin:/usr/bin:/bin";
-
- path_len = len + strlen(old_path) + 1;
-
- path = malloc(path_len + 1);
-
- memcpy(path, dir, len);
- path[len] = ':';
- memcpy(path + len + 1, old_path, path_len - len);
-
- setenv("PATH", path, 1);
-}
-
static void show_man_page(const char *git_cmd)
{
const char *page;
@@ -447,18 +428,6 @@ int main(int argc, const char **argv, ch
}
argv[0] = cmd;
- /*
- * We search for git commands in the following order:
- * - git_exec_path()
- * - the path of the "git" command if we could find it
- * in $0
- * - the regular PATH.
- */
- if (exec_path)
- prepend_to_path(exec_path, strlen(exec_path));
- exec_path = git_exec_path();
- prepend_to_path(exec_path, strlen(exec_path));
-
/* See if it's an internal command */
handle_internal_command(argc, argv, envp);
^ permalink raw reply related
* Re: [PATCH 3/3] blame: Rename detection (take 2)
From: Junio C Hamano @ 2006-03-16 0:31 UTC (permalink / raw)
To: Fredrik Kuivinen; +Cc: git
In-Reply-To: <20060310092141.24015.42482.stgit@c165>
Very nice. It even works with that "insanely fast rename
detector" by Linus ;-)
An example, from an early part of "git blame git-format-patch.sh":
0acfc972 git-format-patch-script (Junio C Hamano 2005-07-05 13:19:05 -0700
0acfc972 git-format-patch-script (Junio C Hamano 2005-07-05 13:19:05 -0700
0acfc972 git-format-patch-script (Junio C Hamano 2005-07-05 13:19:05 -0700
19bb7327 git-format-patch.sh (Mike McCormack 2006-03-06 22:12:12 +0900 6)
66f04f38 git-format-patch.sh (Andreas Ericsso 2006-02-07 09:37:54 +0000 7)
66f04f38 git-format-patch.sh (Andreas Ericsso 2006-02-07 09:37:54 +0000 8)
66f04f38 git-format-patch.sh (Andreas Ericsso 2006-02-07 09:37:54 +0000 9)
66f04f38 git-format-patch.sh (Andreas Ericsso 2006-02-07 09:37:54 +0000 10)
However, I think this underlines that chopping people's names to
the first 15 bytes (or any length for that matter) does not buy
you much.
^ permalink raw reply
* Re: [patch] fix imap-send for OSX
From: Junio C Hamano @ 2006-03-15 23:50 UTC (permalink / raw)
To: Randal L. Schwartz; +Cc: git
In-Reply-To: <86slpj5ljp.fsf@blue.stonehenge.com>
Thanks.
How much would we care about non GNU libc I wonder. We could
just lose that private definition, and say
#define _GNU_SOURCE
#include <stdio.h>
instead, in git-compat-util.h.
But let's leave that to later rounds.
^ 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