* Re: Qgit performance and maintain CVS environment with GIT repository
From: Jan Wielemaker @ 2007-10-19 10:34 UTC (permalink / raw)
To: pete
Cc: Johannes Schindelin, Marco Costalba, Robin Rosenberg,
piet.delaney, Linus Torvalds, VMiklos, free cycle, git,
piet.delaney, Piet Delaney
In-Reply-To: <471871BD.7030608@bluelane.com>
On Friday 19 October 2007 10:58, Pete/Piet Delaney wrote:
> Jan Wielemaker wrote:
> > On Friday 19 October 2007 02:22, Pete/Piet Delaney wrote:
> >> We are definitely not fine with CVS, the branch merging isn't
> >> comfortable. I'm just wondering about maintaining the existing
> >> CVS browsers and the build scripts if it's not a big deal. I'll
> >> try the git-cvsserver path. If anyone has any war stories to share
> >> on the path this would be an ideal time to share them.
> >
> > As for web browsing the history, our project was quickly convinced
> > gitweb is a lot better than cvsweb. We are starting to get use to
> > basic git. One developer works on CVS. This is a bit handicapped,
> > but workable after a few patches to git-shell and git-cvsserver.
>
> Could you tell me a bit more about those patches and the need for using
> git-shell (haven't even messed with that yet).
One patch concerned handling "cvs update -p", which was accepted and I
guess will end up in the stable version someday. One concerned handling
"cvs diff -c", which I never submitted. I first tried a more general
approach to get diff option processing complete, but I had to backtrack
on that. Now I have a quite simple hack, but more complete coverage of
diff option processing requires a bit more perl knowledge than I have.
I submitted a patch for shell.c to make it call "git cvsserver server"
if a commandline "cvs server" was passed to it, so you can do CVS+SSH
compatible to normal CVS. I got so many comments I decided to keep it
for myself for now.
> I don't think we need to have any developers continuing to use CVS;
> but I may be wrong. I think I read that there's a limitation to being
> on the main branch and unfortunately most of out tags are on a release
> branch.
No, you can checkout any GIT branch as it it were a CVS module.
--- Jan
^ permalink raw reply
* Re: [RFC/PATCH] git-fetch: mega-terse fetch output
From: Andreas Ericsson @ 2007-10-19 10:45 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: David Symonds, Jeff King, git
In-Reply-To: <20071019073938.GN14735@spearce.org>
Shawn O. Pearce wrote:
>
> What about this on top of Jeff's patch?
>
> $ git fetch jc
> ...
> ==> git://repo.or.cz/alt-git.git
> * tag junio-gpg-pub ......................... (new)
> * tag v1.5.0 .......................... (tag moved)
>
> $ git fetch me
> ...
> ==> git://repo.or.cz/git/spearce.git
> * branch gitk -> spearce/gitk ............... (new)
> * branch maint -> spearce/maint
> * branch master -> spearce/master
> * branch next -> spearce/next
> * branch pu -> spearce/pu ......... (forced update)
> * branch todo -> spearce/todo ............... (new)
>
> The width of the terminal is computed to produce the ... padding.
> I used a very narrow terminal to produce the above so it doesn't
> linewrap badly in email. If we cannot get the terminal width then
> we just don't produce the padding.
>
Melikes, although using a fairly narrow padding isn't necessarily
a bad idea. I usually hate it when the output on the left is 15 chars
wide, the one on the right is 5-10 chars wide and there are 60 dots
between them. It's ugly and doesn't make it a easier to read.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: [RFC/PATCH] git-fetch: mega-terse fetch output
From: Andreas Ericsson @ 2007-10-19 10:40 UTC (permalink / raw)
To: Jeff King; +Cc: git, Shawn O. Pearce
In-Reply-To: <20071019062219.GA28499@coredump.intra.peff.net>
Jeff King wrote:
> - we abbreviate the local refs (chopping refs/heads,
> refs/tags, refs/remotes). This means we're losing
> information, but hopefully it is obvious when storing
> "origin/master" that it is in refs/remotes.
I like this, since "origin/master" is how that branch is supposed to
be used.
> - fast forward information goes at the end
> - cut out "Auto-following ..." text
>
> What do people think? Some changes? All?
>
Possibly re-listing "refused" messages last so users who pull from
repos with a huge amount of branches can see it at the bottom.
> Other questions:
> - Is the "==>" too ugly? It needs to be short (many urls
> are almost 80 characters already), and it needs to stand
> out from the "resolving deltas" line, so I think some
> symbol is reasonable.
Skip the marker altogether and indent the output two spaces.
> - Should we omit "(fast forward)" since it is the usual
> case?
I think so, yes, or perhaps just shorten it to 'ff' so the 'refused' and
'merged' messages stand out a bit more.
> - Should refs/remotes/* keep the "remotes/" part?
I think not. It's used as origin/master (by end-users anyways), so writing
what they're familiar with is most likely the correct thing to do.
> - How annoying is the doubled '==> $url' line? It comes
> from the fact that we fetch the tags separately.
>
Fairly annoying. I'd prefer if it was squelched the second time.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: [RFC/PATCH] git-fetch: mega-terse fetch output
From: Santi Béjar @ 2007-10-19 10:03 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: David Symonds, Jeff King, git
In-Reply-To: <20071019073938.GN14735@spearce.org>
Another possibility is with just some minor reductions from the
current output, as:
$ git fetch spearce
...
From git://repo.or.cz/git/spearce
* spearce/gitk: fast forward to branch 'gitk'
old..new: 0d6df4d..2b5afb7
* spearce/maint: fast forward to branch 'maint'
old..new: 1aa3d01..e7187e4
* spearce/master: fast forward to branch 'master'
old..new: de61e42..7840ce6
* spearce/next: fast forward to branch 'next'
old..new: 895be02..2fe5433
* spearce/pu: forcing update to non-fast forward branch 'pu'
old...new: 89fa332...1e4c517
This way it is slightly less terse than the other proposals but not
that cryptic and it normally fits in one line without padding. And I
really like to see what has changed explicitly with the old..new line.
Santi
^ permalink raw reply
* Re: Qgit performance and maintain CVS environment with GIT repository
From: Andreas Ericsson @ 2007-10-19 9:52 UTC (permalink / raw)
To: pete
Cc: Marco Costalba, Johannes Schindelin, Robin Rosenberg,
piet.delaney, Linus Torvalds, VMiklos, free cycle, git,
piet.delaney, Piet Delaney
In-Reply-To: <47187518.1090007@bluelane.com>
Pete/Piet Delaney wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Andreas Ericsson wrote:
>> Pete/Piet Delaney wrote:
>>> Johannes:
>>> I read somewhere in the past week that it was possible to maintain
>>> our existing CVS environment with git. I though it was a separate
>>> package to export git back to cvs but I just noticed a git-cvsserver
>>> and as a std part of git and was wondering about using that.
>>>
>>> We have a number of build machines with flamebox perl scripts pulling
>>> out CVS branches for builds. I was wondering what is the best way to
>>> use git and it's nicer pull/push model and merge facility and possibly
>>> maintain CVS exports for scripts doing builds if possible the cvsweb
>>> and bonsai (CVS Query Form) that a number of engineers are currently
>>> using. I started looking over out flamebox scripts with the intent
>>> up converting them over to git but I mentioned the git to cvs
>>> coexistence and we are wondering if that's a better route than
>>> upgrading the flamebox scripts. Having our existing cvsweb, bonsai,
>>> and gitweb along with the git utilities seems at least desirable.
>>> Any thoughts or suggestions?
>>>
>> If you do convert them to git, you can fairly easily do an automatic
>> bisect on build-errors, and the developer can (after some time) get
>> an email of what machines they broke the code on and what the bad
>> commit was.
>
> Could you explain that a bit more. Sounds like you saying it's worth
> messing with the flamebox scripts to use git instead of using the git
> cvserver and letting them pull the cvs branches as they do now. Is the
> existing flamebox email of build log effected buy switching form cvs
> to git? I hadn't expect it to change.
>
git has quite a wonderful tool named git-bisect. In short, it helps track
down what particular commit introduced a bug. Let's say your builds fail
for some reason, and the build-scripts send out the build-log to the
developer. The script can then continue to check the repo by running git
bisect on it and finding the commit that introduced the build-error, and
email that too to the developer. In short, when you check things in at
5 o'clock that doesn't build, you don't have to sit there and wrestle with
it. You can go home, have dinner, tuck the kids into bed, and then open
your mailbox and have an email with the exact commit that introduced the
regression.
Now, if you can also convince your developers to make small and isolated
commits, and your build-system is such that it doesn't rebuild *everything*,
but has proper dependency tracking and suchlike (a properly written Makefile
for example), the developer will get pointed to a commit that affects perhaps
10-20 lines of code within a reasonable time, and it should be so trivial to
fix that anyone can do it.
>
>> Besides that, it's not a black-and-white scenario. If I were you I'd set
>> up git-cvsserver and make sure that works for all the scripts, and then
>> pick one or two auto-build things to convert to git. Preferrably on a
>> separate machine, so everything keeps working the same as always while
>> you're fiddling with the auto-build stuff.
>
> I get the impression your suggestion to first get git-cvsserver serving
> the repo so that the build machines works without any change and then to
> go to each build machine and update the scripts to use git instead of cvs.
>
That's the idea, yes.
> Are there any tricks I need to so on the repo to make the branches pull
> out with exactly the same commands that we are currently using. My guess
> is that the branch checkouts should work without any messing around.
I'm not sure what you mean by that. You can tell git to automatically fetch
any new branches (that's the default, I think), but you'll ofcourse have to
switch to using git-pull instead of cvs co (or whatever you're using now),
unless you use git-cvsserver. AFAIK, git-cvsserver mimics a cvs server well
enough that it accepts all commands and the two are interchangeable (assuming
the background repo conversion has been done, ofcourse).
>> Just my two cents.
>
> Hey, you two cents could easily save me hours of messing getting this
> conversion done.
>
That's well-invested money then ;-)
> BTW, I don't think anyone is checking into the repo, but if they do
> can I do another git-cvsimport to just update the one I already did?
Yes. It works incrementally, but since cvs commits aren't atomic, you
have to wait 10 minutes after the cvs commit *starts* to be able to
use cvsimport to move it over to git.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: Qgit performance and maintain CVS environment with GIT repository
From: Pete/Piet Delaney @ 2007-10-19 9:12 UTC (permalink / raw)
To: Andreas Ericsson
Cc: Marco Costalba, Johannes Schindelin, Robin Rosenberg,
piet.delaney, Linus Torvalds, VMiklos, free cycle, git,
piet.delaney, Piet Delaney
In-Reply-To: <4718594A.2070407@op5.se>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Andreas Ericsson wrote:
> Pete/Piet Delaney wrote:
>> Johannes:
>> I read somewhere in the past week that it was possible to maintain
>> our existing CVS environment with git. I though it was a separate
>> package to export git back to cvs but I just noticed a git-cvsserver
>> and as a std part of git and was wondering about using that.
>>
>> We have a number of build machines with flamebox perl scripts pulling
>> out CVS branches for builds. I was wondering what is the best way to
>> use git and it's nicer pull/push model and merge facility and possibly
>> maintain CVS exports for scripts doing builds if possible the cvsweb
>> and bonsai (CVS Query Form) that a number of engineers are currently
>> using. I started looking over out flamebox scripts with the intent
>> up converting them over to git but I mentioned the git to cvs
>> coexistence and we are wondering if that's a better route than
>> upgrading the flamebox scripts. Having our existing cvsweb, bonsai,
>> and gitweb along with the git utilities seems at least desirable.
>> Any thoughts or suggestions?
>>
>
> If you do convert them to git, you can fairly easily do an automatic
> bisect on build-errors, and the developer can (after some time) get
> an email of what machines they broke the code on and what the bad
> commit was.
Could you explain that a bit more. Sounds like you saying it's worth
messing with the flamebox scripts to use git instead of using the git
cvserver and letting them pull the cvs branches as they do now. Is the
existing flamebox email of build log effected buy switching form cvs
to git? I hadn't expect it to change.
> Besides that, it's not a black-and-white scenario. If I were you I'd set
> up git-cvsserver and make sure that works for all the scripts, and then
> pick one or two auto-build things to convert to git. Preferrably on a
> separate machine, so everything keeps working the same as always while
> you're fiddling with the auto-build stuff.
I get the impression your suggestion to first get git-cvsserver serving
the repo so that the build machines works without any change and then to
go to each build machine and update the scripts to use git instead of cvs.
Are there any tricks I need to so on the repo to make the branches pull
out with exactly the same commands that we are currently using. My guess
is that the branch checkouts should work without any messing around.
>
> Just my two cents.
Hey, you two cents could easily save me hours of messing getting this
conversion done.
BTW, I don't think anyone is checking into the repo, but if they do
can I do another git-cvsimport to just update the one I already did?
- -piet
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFHGHUUJICwm/rv3hoRArHsAJ9GQMjpLc5CzpBXnHkxLfBgfwEo/QCdGNfj
DiivgfDDSbIB+9YBZvj/5Z0=
=SBSg
-----END PGP SIGNATURE-----
^ permalink raw reply
* Re: [PATCH] send-pack: respect '+' on wildcard refspecs
From: Jeff King @ 2007-10-19 9:04 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: git, dan
In-Reply-To: <20071019090400.GA8944@coredump.intra.peff.net>
On Fri, Oct 19, 2007 at 05:04:00AM -0400, Jeff King wrote:
> to pull the 'force' parameter from wildcard respects (but
Urgh, that should be "refspecs", not "respects". Maybe I should quit for
the night.
-Peff
^ permalink raw reply
* [PATCH] send-pack: respect '+' on wildcard refspecs
From: Jeff King @ 2007-10-19 9:04 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: git, dan
When matching source and destination refs, we were failing
to pull the 'force' parameter from wildcard respects (but
not explicit ones) and attach it to the ref struct.
This adds a test for explicit and wildcard refspecs; the
latter fails without this patch.
Signed-off-by: Jeff King <peff@peff.net>
---
remote.c | 2 ++
t/t5400-send-pack.sh | 48 ++++++++++++++++++++++++++++++++++++++++++++++++
2 files changed, 50 insertions(+), 0 deletions(-)
diff --git a/remote.c b/remote.c
index b20e2be..170015a 100644
--- a/remote.c
+++ b/remote.c
@@ -762,6 +762,8 @@ int match_refs(struct ref *src, struct ref *dst, struct ref ***dst_tail,
hashcpy(dst_peer->new_sha1, src->new_sha1);
}
dst_peer->peer_ref = src;
+ if (pat)
+ dst_peer->force = pat->force;
free_name:
free(dst_name);
}
diff --git a/t/t5400-send-pack.sh b/t/t5400-send-pack.sh
index 57c6397..2d0c07f 100755
--- a/t/t5400-send-pack.sh
+++ b/t/t5400-send-pack.sh
@@ -123,4 +123,52 @@ test_expect_success \
git-branch -a >branches && ! grep -q origin/master branches
'
+rewound_push_setup() {
+ rm -rf parent child &&
+ mkdir parent && cd parent &&
+ git-init && echo one >file && git-add file && git-commit -m one &&
+ echo two >file && git-commit -a -m two &&
+ cd .. &&
+ git-clone parent child && cd child && git-reset --hard HEAD^
+}
+
+rewound_push_succeeded() {
+ cmp ../parent/.git/refs/heads/master .git/refs/heads/master
+}
+
+rewound_push_failed() {
+ if rewound_push_succeeded
+ then
+ false
+ else
+ true
+ fi
+}
+
+test_expect_success \
+ 'pushing explicit refspecs respects forcing' '
+ rewound_push_setup &&
+ if git-send-pack ../parent/.git refs/heads/master:refs/heads/master
+ then
+ false
+ else
+ true
+ fi && rewound_push_failed &&
+ git-send-pack ../parent/.git +refs/heads/master:refs/heads/master &&
+ rewound_push_succeeded
+'
+
+test_expect_success \
+ 'pushing wildcard refspecs respects forcing' '
+ rewound_push_setup &&
+ if git-send-pack ../parent/.git refs/heads/*:refs/heads/*
+ then
+ false
+ else
+ true
+ fi && rewound_push_failed &&
+ git-send-pack ../parent/.git +refs/heads/*:refs/heads/* &&
+ rewound_push_succeeded
+'
+
test_done
--
1.5.3.4.1254.gc1ca9-dirty
^ permalink raw reply related
* Re: Qgit performance and maintain CVS environment with GIT repository
From: Pete/Piet Delaney @ 2007-10-19 8:58 UTC (permalink / raw)
To: Jan Wielemaker
Cc: Johannes Schindelin, Marco Costalba, Robin Rosenberg,
piet.delaney, Linus Torvalds, VMiklos, free cycle, git,
piet.delaney, Piet Delaney
In-Reply-To: <200710190943.45201.wielemak@science.uva.nl>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Jan Wielemaker wrote:
> On Friday 19 October 2007 02:22, Pete/Piet Delaney wrote:
>> We are definitely not fine with CVS, the branch merging isn't
>> comfortable. I'm just wondering about maintaining the existing
>> CVS browsers and the build scripts if it's not a big deal. I'll
>> try the git-cvsserver path. If anyone has any war stories to share
>> on the path this would be an ideal time to share them.
>
> As for web browsing the history, our project was quickly convinced
> gitweb is a lot better than cvsweb. We are starting to get use to
> basic git. One developer works on CVS. This is a bit handicapped,
> but workable after a few patches to git-shell and git-cvsserver.
Could you tell me a bit more about those patches and the need for using
git-shell (haven't even messed with that yet).
Think I can set things up so the CVS updates, checkouts, and the
like that are being used on our build machines can remain untouched
and have the git-cvsserver exactly acting like the current CVS server.
It would be nice if branches and tags work without touching all of the
build machines and their scripts.
I don't think we need to have any developers continuing to use CVS;
but I may be wrong. I think I read that there's a limitation to being
on the main branch and unfortunately most of out tags are on a release
branch.
- -piet
>
> In another project I use git-cvsserver to do the Windows builds.
> All development except for minor typos and compatibility things is
> done on linux and cvs <-> git works just fine for that model.
>
> --- Jan
>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFHGHG9JICwm/rv3hoRApQIAJ0Ys6QwxnBAu9tNWrGLU9svwtYXZwCeIFlq
Yr8snPT8TW/nBxFygFr95Ik=
=MtJS
-----END PGP SIGNATURE-----
^ permalink raw reply
* Re: [RFC/PATCH] git-fetch: mega-terse fetch output
From: Jeff King @ 2007-10-19 8:39 UTC (permalink / raw)
To: David Kastrup; +Cc: git
In-Reply-To: <864pgncy9y.fsf@lola.quinscape.zz>
On Fri, Oct 19, 2007 at 10:19:05AM +0200, David Kastrup wrote:
> I don't see why. 80 columns has been the standard layout for
> something like 40 or 50 years or so. It is the standard punch card
> width and required to display Fortran code fitted to this width
> (column 73 to 80 are ignored in non-free-format Fortran and used for
> line identification).
I almost said that, but it seems unnecessarily restrictive. Do people
use git on handhelds (or use them to connect to decent machines that run
git)? If it's related to the actual functioning of the program, then
fine, but it seems unnecessarily strict for something that is just eye
candy anyway.
> All people using smaller terminals are used to wrapping trouble. We
That is a good point...people on tiny screens are likely to be wrapping
on the _other_ lines anyway. I wonder how awful our progress meters look
on a tiny terminal.
Really, I'm fine with assuming an 80 char terminal. I just didn't want
to be in the position of defending it as a useful feature when somebody
complained.
-Peff
^ permalink raw reply
* Re: [BUG] git-svn not following svn moves
From: cho @ 2007-10-19 8:17 UTC (permalink / raw)
To: git
In-Reply-To: <4717D85C.9050805@vilain.net>
Vendredi 19 Octobre 2007 à 11:04:12 +1300, Sam Vilain a écrit :
> cho wrote:
>> svn ci -m 'Add README.'
# forgot this:
svn up
>> cd ..
>> svn mv trunk/ branches/oldtrunk
>>
>> So the testcase basically involves moving the trunk. git-svn gets very
>> confused and keeps a mixture of the old and new trunk.
>
> Were you using --follow-parent or not?
The result is the same, whether I use --follow-parent
or --no-follow-parent .
^ permalink raw reply
* Re: [BUG] git-svn not following svn moves
From: cho @ 2007-10-19 7:51 UTC (permalink / raw)
To: git
In-Reply-To: <4717D85C.9050805@vilain.net>
Le Fri, 19 Oct 2007 11:04:12 +1300, Sam Vilain a écrit :
> cho wrote:
>> I've surprised myself but yes, there is a simple testcase.
>>
svnadmin create repo
svn checkout file://$PWD/repo checkout cd checkout/
svn mkdir trunk tags branches
svn ci -m 'Standard svn layout.'
cd trunk/
svn mkdir doc
touch doc/README
svn add doc/README
svn ci -m 'Add README.'
# forgot this, sorry
svn up
cd ..
svn mv trunk/ branches/oldtrunk
svn ci -m 'Moved trunk.'
svn mkdir trunk
svn ci -m 'New trunk.'
cd trunk/
touch THIS_IS_THE_NEW_TRUNK
svn add THIS_IS_THE_NEW_TRUNK
svn ci -m 'Add marker.'
cd ../..
git svn clone file://$PWD/repo --stdlayout git-clone
cd git-clone/
tree
>>
>> So the testcase basically involves moving the trunk. git-svn gets very
>> confused and keeps a mixture of the old and new trunk.
>
> Were you using --follow-parent or not?
It's the same whether I use --follow-parent or --no-follow-parent .
^ permalink raw reply
* Re: [RFC/PATCH] git-fetch: mega-terse fetch output
From: David Kastrup @ 2007-10-19 8:19 UTC (permalink / raw)
To: git
In-Reply-To: <?= =?ISO-8859-1?Q?2007101=049081127.?= =?ISO-8859-1?Q?GA30168@coredump?= =?ISO-8859-1?Q?.intra.peff.net>
Jeff King <peff@peff.net> writes:
> On Fri, Oct 19, 2007 at 04:07:55AM -0400, Shawn O. Pearce wrote:
>
>> Then you get linewrap on smaller terminals, and bigger ones don't
>> line up the right side. *shrug*
>
> Bigger ones will line up, just not on the far right side of the
> terminal. I guess we ought to support smaller terminals, though).
I don't see why. 80 columns has been the standard layout for
something like 40 or 50 years or so. It is the standard punch card
width and required to display Fortran code fitted to this width
(column 73 to 80 are ignored in non-free-format Fortran and used for
line identification).
All people using smaller terminals are used to wrapping trouble. We
really don't need to go overboard supporting Commodore 64 users with
git.
--
David Kastrup
^ permalink raw reply
* Re: [BUG] git-svn not following svn moves
From: cho @ 2007-10-19 8:30 UTC (permalink / raw)
To: git
In-Reply-To: <4717D85C.9050805@vilain.net>
Le Fri, 19 Oct 2007 11:04:12 +1300, Sam Vilain a écrit :
> cho wrote:
>> svn ci -m 'Add README.'
# forgot this
svn up
>> So the testcase basically involves moving the trunk. git-svn gets very
>> confused and keeps a mixture of the old and new trunk.
>
> Were you using --follow-parent or not?
It's the same, with --follow-parent and with --no-follow-parent .
^ permalink raw reply
* Re: [RFC/PATCH] git-fetch: mega-terse fetch output
From: Johannes Sixt @ 2007-10-19 8:21 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: David Symonds, Jeff King, git
In-Reply-To: <20071019073938.GN14735@spearce.org>
Shawn O. Pearce schrieb:
> $ git fetch jc
> ...
> ==> git://repo.or.cz/alt-git.git
> * tag junio-gpg-pub ......................... (new)
> * tag v1.5.0 .......................... (tag moved)
>
> $ git fetch me
> ...
> ==> git://repo.or.cz/git/spearce.git
> * branch gitk -> spearce/gitk ............... (new)
> * branch maint -> spearce/maint
> * branch master -> spearce/master
> * branch next -> spearce/next
> * branch pu -> spearce/pu ......... (forced update)
> * branch todo -> spearce/todo ............... (new)
>
> The width of the terminal is computed to produce the ... padding.
I like the wording of the status tags.
But the padding does not convince me. How does this look on very wide
terminals? Maybe use 80 as a maximum?
> + if (ws_cols) {
> + size_t n = strlen(status) + strlen(remote_name) + 2;
> + if (op)
> + n += 1 + strlen(op);
> + if (local_name)
> + n += 1 + strlen(local_name);
> + n = ws_cols - n - strlen(reason) - 4;
> + fputc(' ', stderr);
> + while (n--)
> + fputc('.', stderr);
while (n-- > 0)
otherwise you're screwed if your terminal is too narrow.
> +static void determine_window_size(void)
> +{
#ifdef TIOCGWINSZ
> + struct winsize ws;
> + if (!ioctl(2, TIOCGWINSZ, &ws))
> + ws_cols = ws.ws_col;
#endif
> +}
Pretty please. We don't have TIOCGWINSZ on Windows.
-- Hannes
^ permalink raw reply
* Re: [PATCH resend again] gitk: Do not pick up file names of "copy from" lines
From: Shawn O. Pearce @ 2007-10-19 8:14 UTC (permalink / raw)
To: Johannes Sixt; +Cc: Paul Mackerras, git
In-Reply-To: <47186563.3070607@viscovery.net>
Johannes Sixt <j.sixt@viscovery.net> wrote:
> Shawn O. Pearce schrieb:
> >I think it is already in Paul's repo:
>
> No, it's not. I checked both Paul's master and dev, and also your own
> gitk branch. Would you mind cherry-picking from the tip of
>
> git://repo.or.cz/git/mingw.git mob
Picked. Its now in spearce/gitk.
--
Shawn.
^ permalink raw reply
* Re: [RFC/PATCH] git-fetch: mega-terse fetch output
From: Jeff King @ 2007-10-19 8:11 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: David Symonds, git
In-Reply-To: <20071019080755.GO14735@spearce.org>
On Fri, Oct 19, 2007 at 04:07:55AM -0400, Shawn O. Pearce wrote:
> Then you get linewrap on smaller terminals, and bigger ones don't
> line up the right side. *shrug*
Bigger ones will line up, just not on the far right side of the
terminal. I guess we ought to support smaller terminals, though).
> > > + show_update("* branch", note, "->", "FETCH_HEAD", NULL);
> > Hrm, btw, I can't seem to get this one to show (I was curious how ugly
> > the FETCH_HEAD would look).
> Yea, I can't easily see how to get this to generate.
I thought "git-fetch bare_url" would do it, since then we have no
remote fetchspec to look up, but it doesn't.
> > Also, I was unable to generate a test case that showed this one. Did
> > you?
> git fetch -v jc
Ah, thanks.
-Peff
^ permalink raw reply
* Re: [PATCH resend again] gitk: Do not pick up file names of "copy from" lines
From: Johannes Sixt @ 2007-10-19 8:05 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Paul Mackerras, git
In-Reply-To: <20071019073253.GM14735@spearce.org>
Shawn O. Pearce schrieb:
> Johannes Sixt <j.sixt@viscovery.net> wrote:
>> Would you mind putting this one into your queue, too? I haven't seen it
>> appear in Paul's repo.
>
> I think it is already in Paul's repo:
No, it's not. I checked both Paul's master and dev, and also your own
gitk branch. Would you mind cherry-picking from the tip of
git://repo.or.cz/git/mingw.git mob
Thanks,
-- Hannes
^ permalink raw reply
* Re: [PATCH] allow git to use the PATH for finding subcommands and help docs
From: Johannes Sixt @ 2007-10-19 7:33 UTC (permalink / raw)
To: Scott R Parish; +Cc: git
In-Reply-To: <20071019065931.GB1463@srparish.net>
Scott R Parish schrieb:
> + check PATH for git_exec_path after other locations but before builtin
> + prepend MANPATH and PERL5LIB in addition to PATH
This says *what* the patch does, but not *why*. Care to explain?
And then your explanation should go into the commit message.
-- Hannes
^ permalink raw reply
* Re: [RFC/PATCH] git-fetch: mega-terse fetch output
From: Shawn O. Pearce @ 2007-10-19 8:07 UTC (permalink / raw)
To: Jeff King; +Cc: David Symonds, git
In-Reply-To: <20071019075725.GA29436@coredump.intra.peff.net>
Jeff King <peff@peff.net> wrote:
> On Fri, Oct 19, 2007 at 03:39:39AM -0400, Shawn O. Pearce wrote:
>
> > What about this on top of Jeff's patch?
> >
> > $ git fetch jc
> > ...
> > ==> git://repo.or.cz/alt-git.git
> > * tag junio-gpg-pub ......................... (new)
> > * tag v1.5.0 .......................... (tag moved)
>
> Ugh. I strongly suspect that it would look ugly on anything bigger than
> about 80 columns, anyway. You are probably better off just not worrying
> about the terminal width, and always using an 80-ish column total. And
> then you don't have to worry about the ugly ioctl call.
Then you get linewrap on smaller terminals, and bigger ones don't
line up the right side. *shrug*
> > + show_update("* branch", note, "->", "FETCH_HEAD", NULL);
>
> Hrm, btw, I can't seem to get this one to show (I was curious how ugly
> the FETCH_HEAD would look).
Yea, I can't easily see how to get this to generate.
> > if (verbose)
> > - fprintf(stderr, " - %s == %s\n",
> > - note, pretty_ref);
> > + show_update("-", note, "==", pretty_ref, "unchanged");
> > return 0;
>
> Also, I was unable to generate a test case that showed this one. Did
> you?
git fetch -v jc
> > +static void determine_window_size(void)
> > +{
> > + struct winsize ws;
> > + if (!ioctl(2, TIOCGWINSZ, &ws))
> > + ws_cols = ws.ws_col;
> > +}
> > +
>
> Ugh. How portable is this?
No clue. It compiles fine here on Mac OS X and on Linux, but those
are both reasonably modern UNIX systems. Older systems like Solaris
8 or an ancient OpenBSD might have an issue. I suspect though that
this is a reasonably standard thing but its not in POSIX so uh,
probably a bad thing to do.
--
Shawn.
^ permalink raw reply
* Re: [RFC/PATCH] git-fetch: mega-terse fetch output
From: Jeff King @ 2007-10-19 7:57 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: David Symonds, git
In-Reply-To: <20071019073938.GN14735@spearce.org>
On Fri, Oct 19, 2007 at 03:39:39AM -0400, Shawn O. Pearce wrote:
> What about this on top of Jeff's patch?
>
> $ git fetch jc
> ...
> ==> git://repo.or.cz/alt-git.git
> * tag junio-gpg-pub ......................... (new)
> * tag v1.5.0 .......................... (tag moved)
Honestly, I find it a bit ugly with the dots.
> $ git fetch me
> ...
> ==> git://repo.or.cz/git/spearce.git
> * branch gitk -> spearce/gitk ............... (new)
> * branch maint -> spearce/maint
> * branch master -> spearce/master
> * branch next -> spearce/next
> * branch pu -> spearce/pu ......... (forced update)
> * branch todo -> spearce/todo ............... (new)
More so with the ragged right of the branch names. I think it would
probably look better to line up the columns, but that will eventually
look ugly when somebody tries to fetch sp/totally-annoying-branchname.
I also think having the dots for some lines and others looks awkward.
> The width of the terminal is computed to produce the ... padding.
> I used a very narrow terminal to produce the above so it doesn't
> linewrap badly in email. If we cannot get the terminal width then
> we just don't produce the padding.
Ugh. I strongly suspect that it would look ugly on anything bigger than
about 80 columns, anyway. You are probably better off just not worrying
about the terminal width, and always using an 80-ish column total. And
then you don't have to worry about the ugly ioctl call.
> We also only show the URL once now, and only if at least one ref
> was somehow changed. This way we avoid showing the URL on a no-op
> or twice when we are fetching tags too.
Much nicer, and I like the refactoring into a separate show_update
function (especially if somebody ends up adding color later).
> + show_update("* branch", note, "->", "FETCH_HEAD", NULL);
Hrm, btw, I can't seem to get this one to show (I was curious how ugly
the FETCH_HEAD would look).
> if (verbose)
> - fprintf(stderr, " - %s == %s\n",
> - note, pretty_ref);
> + show_update("-", note, "==", pretty_ref, "unchanged");
> return 0;
Also, I was unable to generate a test case that showed this one. Did
you?
> - msg = "storing tag";
> [...]
> + msg = "storing new tag";
Nice.
> + show_update("- branch", note, "->", pretty_ref, "non-fast forward, refused");
Line wrap?
> +static void determine_window_size(void)
> +{
> + struct winsize ws;
> + if (!ioctl(2, TIOCGWINSZ, &ws))
> + ws_cols = ws.ws_col;
> +}
> +
Ugh. How portable is this?
-Peff
^ permalink raw reply
* Re: Qgit performance and maintain CVS environment with GIT repository
From: Jan Wielemaker @ 2007-10-19 7:43 UTC (permalink / raw)
To: pete
Cc: Johannes Schindelin, Marco Costalba, Robin Rosenberg,
piet.delaney, Linus Torvalds, VMiklos, free cycle, git,
piet.delaney, Piet Delaney
In-Reply-To: <4717F8CF.9060103@bluelane.com>
On Friday 19 October 2007 02:22, Pete/Piet Delaney wrote:
> We are definitely not fine with CVS, the branch merging isn't
> comfortable. I'm just wondering about maintaining the existing
> CVS browsers and the build scripts if it's not a big deal. I'll
> try the git-cvsserver path. If anyone has any war stories to share
> on the path this would be an ideal time to share them.
As for web browsing the history, our project was quickly convinced
gitweb is a lot better than cvsweb. We are starting to get use to
basic git. One developer works on CVS. This is a bit handicapped,
but workable after a few patches to git-shell and git-cvsserver.
In another project I use git-cvsserver to do the Windows builds.
All development except for minor typos and compatibility things is
done on linux and cvs <-> git works just fine for that model.
--- Jan
^ permalink raw reply
* Re: [RFC/PATCH] git-fetch: mega-terse fetch output
From: Shawn O. Pearce @ 2007-10-19 7:39 UTC (permalink / raw)
To: David Symonds, Jeff King; +Cc: git
In-Reply-To: <ee77f5c20710182339g30d025f0tfe74479d672ae36e@mail.gmail.com>
David Symonds <dsymonds@gmail.com> wrote:
> On 19/10/2007, Jeff King <peff@peff.net> wrote:
> > This makes the fetch output much more terse. It is likely to
> > be very controversial. Here's an example of the new output:
> >
> > Indexing objects: 100% (1061/1061), done.
> > Resolving deltas: 100% (638/638), done.
> > ==> git://repo.or.cz/git/spearce.git
> > * branch gitk -> origin/gitk
> > * branch maint -> origin/maint (fast forward)
> > * branch master -> origin/master (fast forward)
> > * branch next -> origin/next (fast forward)
> > - branch pu -> origin/pu (non-fast forward, refused)
> > * branch todo -> origin/todo (fast forward)
> > ==> git://repo.or.cz/git/spearce.git
> > * tag v1.5.3.2 -> v1.5.3.2
>
> What about making it even more terse so it's even easier to visually
> scan: (mainly thinking that fast-forwarding is so common it could be
> considered the "default")
What about this on top of Jeff's patch?
$ git fetch jc
...
==> git://repo.or.cz/alt-git.git
* tag junio-gpg-pub ......................... (new)
* tag v1.5.0 .......................... (tag moved)
$ git fetch me
...
==> git://repo.or.cz/git/spearce.git
* branch gitk -> spearce/gitk ............... (new)
* branch maint -> spearce/maint
* branch master -> spearce/master
* branch next -> spearce/next
* branch pu -> spearce/pu ......... (forced update)
* branch todo -> spearce/todo ............... (new)
The width of the terminal is computed to produce the ... padding.
I used a very narrow terminal to produce the above so it doesn't
linewrap badly in email. If we cannot get the terminal width then
we just don't produce the padding.
We also only show the URL once now, and only if at least one ref
was somehow changed. This way we avoid showing the URL on a no-op
or twice when we are fetching tags too.
--8>--
diff --git a/builtin-fetch.c b/builtin-fetch.c
index 35fbfae..9d48f06 100644
--- a/builtin-fetch.c
+++ b/builtin-fetch.c
@@ -14,6 +14,7 @@ static const char fetch_usage[] = "git-fetch [-a | --append] [--upload-pack <upl
static int append, force, tags, no_tags, update_head_ok, verbose, quiet;
static char *default_rla = NULL;
static struct transport *transport;
+static int ws_cols, shown_url;
static void unlock_pack(void)
{
@@ -143,6 +144,50 @@ static int s_update_ref(const char *action,
return 0;
}
+static void show_update(const char *status,
+ const char *remote_name,
+ const char *op,
+ const char *local_name,
+ const char *reason)
+{
+ if (!shown_url) {
+ fprintf(stderr, "==> %s\n", transport->url);
+ shown_url = 1;
+ }
+
+ fputc(' ', stderr);
+ fputs(status, stderr);
+
+ fputc(' ', stderr);
+ fputs(remote_name, stderr);
+
+ if (op) {
+ fputc(' ', stderr);
+ fputs(op, stderr);
+ }
+
+ if (local_name) {
+ fputc(' ', stderr);
+ fputs(local_name, stderr);
+ }
+
+ if (reason) {
+ if (ws_cols) {
+ size_t n = strlen(status) + strlen(remote_name) + 2;
+ if (op)
+ n += 1 + strlen(op);
+ if (local_name)
+ n += 1 + strlen(local_name);
+ n = ws_cols - n - strlen(reason) - 4;
+ fputc(' ', stderr);
+ while (n--)
+ fputc('.', stderr);
+ }
+ fprintf(stderr, " (%s)", reason);
+ }
+ fputc('\n', stderr);
+}
+
static int update_local_ref(struct ref *ref,
const char *note,
int verbose)
@@ -164,14 +209,13 @@ static int update_local_ref(struct ref *ref,
if (!*ref->name) {
/* Not storing */
if (verbose)
- fprintf(stderr, " * branch %s -> FETCH_HEAD\n", note);
+ show_update("* branch", note, "->", "FETCH_HEAD", NULL);
return 0;
}
if (!hashcmp(ref->old_sha1, ref->new_sha1)) {
if (verbose)
- fprintf(stderr, " - %s == %s\n",
- note, pretty_ref);
+ show_update("-", note, "==", pretty_ref, "unchanged");
return 0;
}
@@ -183,16 +227,14 @@ static int update_local_ref(struct ref *ref,
* If this is the head, and it's not okay to update
* the head, and the old value of the head isn't empty...
*/
- fprintf(stderr,
- " - %s: Cannot fetch into the current branch.\n",
- pretty_ref);
+ show_update("-", pretty_ref, NULL, NULL,
+ "Cannot fetch into the current branch.");
return 1;
}
if (!is_null_sha1(ref->old_sha1) &&
!prefixcmp(ref->name, "refs/tags/")) {
- fprintf(stderr, " * tag %s -> %s\n",
- note, pretty_ref);
+ show_update("* tag", note, NULL, NULL, "tag moved");
return s_update_ref("updating tag", ref, 0);
}
@@ -200,17 +242,13 @@ static int update_local_ref(struct ref *ref,
updated = lookup_commit_reference(ref->new_sha1);
if (!current || !updated) {
const char *msg;
- const char *what;
if (!strncmp(ref->name, "refs/tags/", 10)) {
- msg = "storing tag";
- what = "tag";
- }
- else {
- msg = "storing head";
- what = "branch";
+ msg = "storing new tag";
+ show_update("* tag", note, NULL, NULL, "new");
+ } else {
+ msg = "storing new head";
+ show_update("* branch", note, "->", pretty_ref, "new");
}
- fprintf(stderr, " * %s %s -> %s\n",
- what, note, pretty_ref);
return s_update_ref(msg, ref, 0);
}
@@ -218,19 +256,14 @@ static int update_local_ref(struct ref *ref,
strcpy(newh, find_unique_abbrev(ref->new_sha1, DEFAULT_ABBREV));
if (in_merge_bases(current, &updated, 1)) {
- fprintf(stderr, " * branch %s -> %s (fast forward)\n",
- note, pretty_ref);
+ show_update("* branch", note, "->", pretty_ref, NULL);
return s_update_ref("fast forward", ref, 1);
}
if (!force && !ref->force) {
- fprintf(stderr,
- " - branch %s -> %s (non-fast forward, refused)\n",
- note, pretty_ref);
+ show_update("- branch", note, "->", pretty_ref, "non-fast forward, refused");
return 1;
}
- fprintf(stderr,
- " * branch %s -> %s (non-fast forward)\n",
- note, pretty_ref);
+ show_update("* branch", note, "->", pretty_ref, "forced update");
return s_update_ref("forced-update", ref, 1);
}
@@ -243,8 +276,6 @@ static void store_updated_refs(const char *url, struct ref *ref_map)
const char *what, *kind;
struct ref *rm;
- fprintf(stderr, "==> %s\n", url);
-
fp = fopen(git_path("FETCH_HEAD"), "a");
for (rm = ref_map; rm; rm = rm->next) {
struct ref *ref = NULL;
@@ -440,6 +471,13 @@ static void set_option(const char *name, const char *value)
name, transport->url);
}
+static void determine_window_size(void)
+{
+ struct winsize ws;
+ if (!ioctl(2, TIOCGWINSZ, &ws))
+ ws_cols = ws.ws_col;
+}
+
int cmd_fetch(int argc, const char **argv, const char *prefix)
{
struct remote *remote;
@@ -565,6 +603,7 @@ int cmd_fetch(int argc, const char **argv, const char *prefix)
ref_nr = j;
}
+ determine_window_size();
signal(SIGINT, unlock_pack_on_signal);
atexit(unlock_pack);
return do_fetch(transport, parse_ref_spec(ref_nr, refs), ref_nr);
diff --git a/git-compat-util.h b/git-compat-util.h
index f23d934..e823aca 100644
--- a/git-compat-util.h
+++ b/git-compat-util.h
@@ -44,6 +44,7 @@
#include <limits.h>
#include <sys/param.h>
#include <sys/types.h>
+#include <sys/ioctl.h>
#include <dirent.h>
#include <sys/time.h>
#include <time.h>
--
Shawn.
^ permalink raw reply related
* Re: [PATCH resend again] gitk: Do not pick up file names of "copy from" lines
From: Shawn O. Pearce @ 2007-10-19 7:32 UTC (permalink / raw)
To: Johannes Sixt; +Cc: Paul Mackerras, git
In-Reply-To: <47185BCC.9010307@viscovery.net>
Johannes Sixt <j.sixt@viscovery.net> wrote:
> Would you mind putting this one into your queue, too? I haven't seen it
> appear in Paul's repo.
I think it is already in Paul's repo:
Applying gitk: Do not pick up file names of "copy from" lines
error: patch failed: gitk:5216
error: gitk: patch does not apply
fatal: sha1 information is lacking or useless (gitk).
Repository lacks necessary blobs to fall back on 3-way merge.
Cannot fall back to three-way merge.
Patch failed at 0001.
When you have resolved this problem run "git-am -3 --resolved".
If you would prefer to skip this patch, instead run "git-am -3 --skip".
> diff --git a/gitk b/gitk
> index b3ca704..1306382 100755
> --- a/gitk
> +++ b/gitk
> @@ -5216,8 +5216,7 @@ proc getblobdiffline {bdf ids} {
> set diffinhdr 0
>
> } elseif {$diffinhdr} {
> - if {![string compare -length 12 "rename from " $line] ||
> - ![string compare -length 10 "copy from " $line]} {
> + if {![string compare -length 12 "rename from " $line]} {
> set fname [string range $line [expr 6 + [string first " from
> " $line] ] end]
> if {[string index $fname 0] eq "\""} {
> set fname [lindex $fname 0]
--
Shawn.
^ permalink raw reply
* [PATCH] allow git to use the PATH for finding subcommands and help docs
From: Scott R Parish @ 2007-10-19 6:59 UTC (permalink / raw)
To: git
+ check PATH for git_exec_path after other locations but before builtin
+ prepend MANPATH and PERL5LIB in addition to PATH
Signed-off-by: Scott R Parish <srp@srparish.net>
---
exec_cmd.c | 50 ++++++++++++++++++++++++++++++++++++++-
git.c | 76 +++++++++++++++++++++++++++++++++++++++++------------------
2 files changed, 102 insertions(+), 24 deletions(-)
diff --git a/exec_cmd.c b/exec_cmd.c
index 9b74ed2..c6ecca9 100644
--- a/exec_cmd.c
+++ b/exec_cmd.c
@@ -13,19 +13,67 @@ void git_set_exec_path(const char *exec_path)
}
+/* Return the first path in PATH that git is found in or NULL if not found */
+char *git_path_from_env(void)
+{
+ const char *env_paths = getenv("PATH");
+ const char *git = "/git";
+ int git_len = strlen(git);
+ char *paths, *path, *colon, *git_path;
+ int path_len;
+ struct stat st;
+
+ if (!env_paths)
+ return NULL;
+
+ path_len = strlen(env_paths);
+ path = paths = xmalloc(path_len + 1);
+ memcpy(paths, env_paths, path_len + 1);
+
+ while ((char *)1 != path) {
+ if ((colon = strchr(path, ':')))
+ *colon = 0;
+
+ path_len = strlen(path);
+ git_path = xmalloc(path_len + git_len + 1);
+ memcpy(git_path, path, path_len);
+ memcpy(git_path + path_len, git, git_len + 1);
+
+ if (!stat(git_path, &st)) { /* found */
+ free(paths);
+ git_path[path_len] = 0;
+ return git_path;
+ }
+
+ free(git_path);
+ path = colon + 1;
+ }
+
+ free(paths);
+ return NULL;
+}
+
+
/* Returns the highest-priority, location to look for git programs. */
const char *git_exec_path(void)
{
- const char *env;
+ const char *env, *path;
if (current_exec_path)
return current_exec_path;
env = getenv(EXEC_PATH_ENVIRONMENT);
if (env && *env) {
+ current_exec_path = env;
return env;
}
+ if ((path = git_path_from_env())) {
+ current_exec_path = path;
+ return path;
+ }
+
+ current_exec_path = builtin_exec_path;
return builtin_exec_path;
}
diff --git a/git.c b/git.c
index 9eaca1d..252ee7c 100644
--- a/git.c
+++ b/git.c
@@ -6,26 +6,56 @@
const char git_usage_string[] =
"git [--version] [--exec-path[=GIT_EXEC_PATH]] [-p|--paginate|--no-pager] [--bare] [--git-dir=GIT_DIR] [--work-tree=GIT_WORK_TREE] [--help] COMMAND [ARGS]";
-static void prepend_to_path(const char *dir, int len)
+static void prepend_to_env(const char *env, const char *basedir,
+ const char *subdir, const char *env_default)
{
- const char *old_path = getenv("PATH");
- char *path;
- int path_len = len;
-
- if (!old_path)
- old_path = "/usr/local/bin:/usr/bin:/bin";
-
- path_len = len + strlen(old_path) + 1;
-
- path = xmalloc(path_len + 1);
+ const char *old = getenv(env);
+ int basedir_len = strlen(basedir);
+ int subdir_len = strlen(subdir);
+ char *new;
+ int old_len;
+
+ if (!old)
+ old = env_default;
+
+ old_len = strlen(old);
+
+ new = xmalloc(basedir_len + subdir_len + old_len + 1);
+
+ memcpy(new, basedir, basedir_len);
+ memcpy(new + basedir_len, subdir, subdir_len);
+ memcpy(new + basedir_len + subdir_len, old, old_len + 1);
+
+ if (setenv(env, new, 1))
+ fprintf(stderr, "Setenv failed: %s\n", strerror(errno));
+
+ free(new);
+}
- memcpy(path, dir, len);
- path[len] = ':';
- memcpy(path + len + 1, old_path, path_len - len);
+static void prepend_to_envs(const char *dir, int len)
+{
+ char *slash;
+ char *basedir;
+
+ /* basedir is dir with "/bin" stripped off */
+ basedir = xmalloc(len + 1);
+ memcpy(basedir, dir, len + 1);
+
+ if ((slash = strrchr(basedir, '/'))) {
+ *slash = 0;
+ while (slash == basedir + --len) /* found trailing slash */
+ if ((slash = strrchr(basedir, '/')))
+ *slash = 0;
+ }
- setenv("PATH", path, 1);
+ prepend_to_env("PATH", basedir, "/bin:",
+ "/usr/local/bin:/usr/bin:/bin");
+ prepend_to_env("MANPATH", basedir, "/share/man:",
+ "/usr/local/share/man:/usr/share/man");
+ prepend_to_env("PERL5LIB", basedir, "/lib/perl5:",
+ "/usr/lib/perl5");
- free(path);
+ free(basedir);
}
static int handle_options(const char*** argv, int* argc, int* envchanged)
@@ -414,8 +444,7 @@ int main(int argc, const char **argv)
*/
if (slash) {
*slash++ = 0;
- if (*cmd == '/')
- exec_path = cmd;
+ exec_path = cmd;
cmd = slash;
}
@@ -453,14 +482,15 @@ int main(int argc, const char **argv)
/*
* We execute external git command via execv_git_cmd(),
* which looks at "--exec-path" option, GIT_EXEC_PATH
- * environment, and $(gitexecdir) in Makefile while built,
- * in this order. For scripted commands, we prepend
- * the value of the exec_path variable to the PATH.
+ * environment, PATH environment, and $(gitexecdir) in
+ * Makefile while built, in this order. For scripted
+ * commands, we prepend the value of the exec_path
+ * variable to the PATH.
*/
if (exec_path)
- prepend_to_path(exec_path, strlen(exec_path));
+ prepend_to_envs(exec_path, strlen(exec_path));
exec_path = git_exec_path();
- prepend_to_path(exec_path, strlen(exec_path));
+ prepend_to_envs(exec_path, strlen(exec_path));
while (1) {
/* See if it's an internal command */
--
1.5.3.4.206.g58ba4-dirty
^ permalink raw reply related
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