* Re: Closing the merge window for 1.6.0
2008-07-15 16:26 7% ` Nicolas Pitre
2008-07-15 16:46 0% ` Sverre Rabbelier
@ 2008-07-15 17:28 0% ` Petr Baudis
1 sibling, 0 replies; 76+ results
From: Petr Baudis @ 2008-07-15 17:28 UTC (permalink / raw)
To: Nicolas Pitre
Cc: Johannes Schindelin, Dmitry Potapov, Junio C Hamano, Gerrit Pape,
git
On Tue, Jul 15, 2008 at 12:26:48PM -0400, Nicolas Pitre wrote:
> Anyway this is all hand waving until someone can come with some evidence
> that git 1.4.4 is actually used by a significant amount of people, and
> that those people depend on dumb transfer protocols.
That will be hard to produce. :-) _My_ personal story is that I have
Git-1.4.4.4 installed system-wide on repo.or.cz and follow git#next
locally, and quite panicked when I was inspecting some repositories
as root (using the system-wide Git) and these error messages popped up.
This may become a similar experience for others on multi-user systems
where people want to share work but don't realize that one of them has
Git installed locally and the other one doesn't. We can save them the
head-slapping and a bit of wasted life.
Out of interest, I did a simple statistics of HTTP user agents on
repo.or.cz; the dumb access does not seem very widely used overally,
it turns out. The stats begin at 19/May/2008:10:54:32 +0200. Here is the
breakdown, counting unique clients only:
# zgrep '"GET /r/.*/info/packs' /var/log/apache2/repo-access.log* | egrep -v bot\|slurp\|Gecko\|Opera |
cut -d " " -f 1,12- | sed 's/\.g[a-f0-9]*\(\.dirty\)*"/"/' | sort -u |
cut -d ' ' -f 2 | sort | uniq -c | sort -rn | head -n 50
1501 "git/1.5.4.3" <- Ubuntu Hardy (heh.. is just that it?)
278 "git/1.5.5.1" <- RHEL5 (ditto)
151 "git/1.5.2.5" <- Ubuntu Gutsy
133 "git/1.5.5.3" <- ? (maybe Gentoo ~x86 for some time)
125 "git/1.5.4.5" <- OpenSUSE 11.0, FC9, Gentoo x86, Dapper backports
104 "git/1.5.6" <- Debian Lenny
94 "git/1.5.5"
66 "git/1.5.3.7"
63 "git/1.5.5.4"
63 "git/1.5.5.1015"
55 "git/1.5.2.4" <- OpenSUSE 10.3
51 "Mozilla/4.0 (compatible;)" <- huh?
42 "git/1.5.3.8"
37 "git/1.5.5.GIT"
37 "git/1.5.3.5.2229"
34 "git/1.5.6.1"
33 "git/1.5.3.6" <- Feisty backports
31 "git/1.5.4.1"
30 "git/1.5.6.2"
20 "git/1.5.6.GIT"
18 "git/1.5.3"
17 "git/1.5.2.2"
17 "git/1.4.4.4"
15 "git/1.5.6.1.1071"
14 "git/1.5.3.3"
13 "git/1.5.4.4"
13 "git/1.5.4"
11 "git/1.5.6.1062"
11 "git/1.5.5.2"
10 "git/1.5.5.1.316"
(I also got two 1.4.4.2 (feisty?) fetches from one client. No older
Git versions.)
So wrt. keeping backwards compatibility, this is not _very_ convincing,
I admit. ;-)
--
Petr "Pasky" Baudis
GNU, n. An animal of South Africa, which in its domesticated state
resembles a horse, a buffalo and a stag. In its wild condition it is
something like a thunderbolt, an earthquake and a cyclone. -- A. Pierce
^ permalink raw reply [relevance 0%]
* Re: Closing the merge window for 1.6.0
2008-07-15 16:26 7% ` Nicolas Pitre
@ 2008-07-15 16:46 0% ` Sverre Rabbelier
2008-07-15 17:28 0% ` Petr Baudis
1 sibling, 0 replies; 76+ results
From: Sverre Rabbelier @ 2008-07-15 16:46 UTC (permalink / raw)
To: Nicolas Pitre
Cc: Johannes Schindelin, Dmitry Potapov, Petr Baudis, Junio C Hamano,
Gerrit Pape, git
On Tue, Jul 15, 2008 at 6:26 PM, Nicolas Pitre <nico@cam.org> wrote:
> Anyway this is all hand waving until someone can come with some evidence
> that git 1.4.4 is actually used by a significant amount of people, and
> that those people depend on dumb transfer protocols.
Can't we add a msg to 1.4.4.x when it finds pack version 2 to upgrade
to 1.5.x? Gets rid of the problem all together while still giving the
user a reasonable message when it finds a repo version 2.
Hey, here's an idea, can't we have 1.4.4.x just give that msg for everything?
$cat git
#!/bin/sh
echo "Please upgrade to 1.5.x, version 1.4.x is no longer supported
nor should you even want to use it </cluebat>"
--
Cheers,
Sverre Rabbelier
^ permalink raw reply [relevance 0%]
* Re: Closing the merge window for 1.6.0
@ 2008-07-15 16:26 7% ` Nicolas Pitre
2008-07-15 16:46 0% ` Sverre Rabbelier
2008-07-15 17:28 0% ` Petr Baudis
0 siblings, 2 replies; 76+ results
From: Nicolas Pitre @ 2008-07-15 16:26 UTC (permalink / raw)
To: Johannes Schindelin
Cc: Dmitry Potapov, Petr Baudis, Junio C Hamano, Gerrit Pape, git
On Tue, 15 Jul 2008, Johannes Schindelin wrote:
> And I absolutely agree with Pasky that this does _nothing_ in the vague
> direction of wielding a reputation of being easy to use.
Staying with git versions prior 1.5 isn't either. In fact, git had a
much harder time with its usability reputation in those days. In other
words, if some user of Debian is rebutted by the upgrade path for a later
git version, then the awkwardness of git 1.4.4 UI will be even worse.
Anyway this is all hand waving until someone can come with some evidence
that git 1.4.4 is actually used by a significant amount of people, and
that those people depend on dumb transfer protocols.
Nicolas
^ permalink raw reply [relevance 7%]
* Re: Closing the merge window for 1.6.0
@ 2008-07-15 15:06 7% ` Dmitry Potapov
0 siblings, 1 reply; 76+ results
From: Dmitry Potapov @ 2008-07-15 15:06 UTC (permalink / raw)
To: Petr Baudis
Cc: Junio C Hamano, Nicolas Pitre, Gerrit Pape, Johannes Schindelin,
git
On Tue, Jul 15, 2008 at 11:20:23AM +0200, Petr Baudis wrote:
>
> (iii) Most importantly, this is not about waiting another few
> years for Debian to catch up, since the next stable release
> should really be upcoming rather soon:
>
> http://debian-community.org/LennyReleaseSchedule/
Even if Lenny will be released right on the scheduler (which I seriously
doubt), Etch will be around for another year. In fact, the last release
of oldstable (sarge) happened on April 12 this year. Thus delaying of
indexversion=2 does not help much here. Anyone who is more or less
seriously about using Git grabs it from backports. The downside of
delaying is that any incompatible changes are much less welcome by users
during minor releases than major ones. People tend to read release notes
during major releases more carefully and think whether they prefer new
features or backward compatibility. This choice will not be the same for
anyone, but changing default settings on the major release is much more
appropriate than during minor ones.
>
> (iv) These problems do not concern people who are currently
> _actively_ _working_ with Git; these people hopefully do not
> use 1.4 willingly and already use Git from backports.org.
> This is about user experience for casual users who are quite
> possibly interested only in read-only tracking of upstream
> using Git - these people will likely use default Debian Git
> version and that is okay, because frankly, for them, the
> 1.5 improvements do not really matter much. This is also
> large class of prospective future real Git users and we might
> not want to ruin Git's reputation in their eyes.
I disagree. It is not Git does not support the old format, but it
switches on the new one as default on the next major release, which
is a sensible thing to do. Those repos that think that access for
Git 1.4 users is important for them can set indexformat=1. As to
prospective future real Git users, anyone who is trying to use Git
1.4 is going to hit by many usability issues that were resolved in
1.5; and there is no community support for Git 1.4 either -- you can
ask about any problem with Git 1.4 on this list, and the only answer
you'll get is that you should upgrade your Git. So, there is no way
for newcommers to start using Git 1.4 and be satisfied with it.
Finally, 18 months since 1.4.4 may not appear as a long time ago for
other projects that are being developed for many years, but for Git,
which was only 21 months when Git 1.4.4 was released, 18 months is
really very *long* time ago.
Dmitry
^ permalink raw reply [relevance 7%]
* Re: Closing the merge window for 1.6.0
@ 2008-07-15 3:30 7% ` Nicolas Pitre
0 siblings, 0 replies; 76+ results
From: Nicolas Pitre @ 2008-07-15 3:30 UTC (permalink / raw)
To: Shawn O. Pearce
Cc: Gerrit Pape, Johannes Schindelin, Petr Baudis, Junio C Hamano,
git
On Tue, 15 Jul 2008, Shawn O. Pearce wrote:
> Nicolas Pitre <nico@cam.org> wrote:
> > On Mon, 14 Jul 2008, Gerrit Pape wrote:
> >
> > > On Mon, Jul 14, 2008 at 12:57:56PM +0100, Johannes Schindelin wrote:
> > > > On Mon, 14 Jul 2008, Petr Baudis wrote:
> > > > > I'm saying this because I believe the best conservative upper bound for
> > > > > backwards compatibility is Git version in Debian stable. It gets
> > > > > probably the most stale from all the widely used software distributions
> > > > > using Git, and it *is* quite widely used. Etch carries v1.4.4.4, which
> > > > > fails miserably on the new packs.
> >
> > Maybe we can release 1.4.5 with the ability to read index v2? That
> > wouldn't be hard to backport the reading part of it.
>
> If we consider that supporting 1.4.4.4 clients is still a priority,
> due to the widespread distribution of that version in a popular
> version of Debian, we shouldn't be rushing the index v2 or OFS_DELTA
> functionality on by default in 1.6.0.
OFS_DELTA is supported by 1.4.4.4 so that's a non issue.
> Instead we would wait until Debian stable (and most other widely
> popular distributions) are on a modern enough version of Git to
> understand this format.
I don't think we should have git development be dictated by some
discutable policy from one distribution.
IMHO git prior 1.5.0 is so horrible as general usability goes, and so
different from what everybody is discussing on the net, that no one sane
should still be using it. Even ourselves (i.e. the git community) are
not supporting git 1.4.4 anymore so this hardly can be a priority.
As far as I know, there is no other widely popular distribution other
than Debian using git prior 1.5.0 in their latest release. If Debian
people want to support git 1.4.4 although we called thatversion obsolete
_long_ ago then that's their problem. We should not be bound by that
external policy to which we never agreed with.
Now I proposed a compromise which consists of making 1.4.4.4+1 able to
cope with index v2. That should fall into Debian's "major usability
fix" category. I think that is a far better compromize than delaying
index v2 even further.
> Really. As much as I'd love to see the switch to v2 made by default
> I don't think we can/should do it unless the majority of the user
> base will be able to grok it. And Debian etch sounds like it won't.
I truly hope the majority of the user is _not_ using 1.4.4.4. Otherwise
I may only have pity for them.
Nicolas
^ permalink raw reply [relevance 7%]
* Re: new GIT-VERSION-GEN with old GIT
2008-02-23 17:34 5% new GIT-VERSION-GEN with old GIT Martin Koegler
@ 2008-02-23 18:46 0% ` Junio C Hamano
0 siblings, 0 replies; 76+ results
From: Junio C Hamano @ 2008-02-23 18:46 UTC (permalink / raw)
To: Martin Koegler; +Cc: git
mkoegler@auto.tuwien.ac.at (Martin Koegler) writes:
> On Debian, git 1.4.4 is still shipped in the stable distribution.
>
> Since e5fc9a0aea2c3c49829b5cdf499339e5c759706b, simply running make in
> a git checkout yields to an error message.
>
> The error is in GIT-VERSION-GEN:
> | + git diff-index --quiet HEAD
> ...
Sorry about that. I already have forgotten that --quiet was a
relatively recent invention.
Before e5fc9a, we used --name-only, which was around forever.
The original diff-cache had it since mid July 2005, and the
command kept the option when it was renamed to diff-index in
early September 2005. That is what we should use.
GIT-VERSION-GEN | 3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/GIT-VERSION-GEN b/GIT-VERSION-GEN
index 03fb9d7..d4714ee 100755
--- a/GIT-VERSION-GEN
+++ b/GIT-VERSION-GEN
@@ -16,7 +16,8 @@ elif test -d .git &&
case "$VN" in
*$LF*) (exit 1) ;;
v[0-9]*)
- git diff-index --quiet HEAD || VN="$VN-dirty" ;;
+ test -z "$(git diff-index --name-only HEAD)" ||
+ VN="$VN-dirty" ;;
esac
then
VN=$(echo "$VN" | sed -e 's/-/./g');
^ permalink raw reply related [relevance 0%]
* new GIT-VERSION-GEN with old GIT
@ 2008-02-23 17:34 5% Martin Koegler
2008-02-23 18:46 0% ` Junio C Hamano
0 siblings, 1 reply; 76+ results
From: Martin Koegler @ 2008-02-23 17:34 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
On Debian, git 1.4.4 is still shipped in the stable distribution.
Since e5fc9a0aea2c3c49829b5cdf499339e5c759706b, simply running make in
a git checkout yields to an error message.
The error is in GIT-VERSION-GEN:
| + git diff-index --quiet HEAD
| usage: git-diff-index [-m] [--cached] [<common diff options>] <tree-ish> [<path>...]
| common diff options:
| -z output diff-raw with lines terminated with NUL.
| -p output patch format.
| -u synonym for -p.
| --patch-with-raw
| output both a patch and the diff-raw format.
| --stat show diffstat instead of patch.
| --numstat show numeric diffstat instead of patch.
| --patch-with-stat
| output a patch and prepend its diffstat.
| --name-only show only names of changed files.
| --name-status show names and status of changed files.
| --full-index show full object name on index lines.
| --abbrev=<n> abbreviate object names in diff-tree header and diff-raw.
| -R swap input file pairs.
| -B detect complete rewrites.
| -M detect renames.
| -C detect copies.
| --find-copies-harder
| try unchanged files as candidate for copy detection.
| -l<n> limit rename attempts up to <n> paths.
| -O<file> reorder diffs according to the <file>.
| -S<string> find filepair whose only one side contains the string.
| --pickaxe-all
| show all files diff when -S is used and hit is found.
| -a --text treat all files as text.
The problem is not critical, as the build process continues with wrong
version information.
mfg Martin Kögler
^ permalink raw reply [relevance 5%]
* Git pull fails on a repository > 1.5G.
@ 2007-09-17 8:59 6% pradeep singh
0 siblings, 0 replies; 76+ results
From: pradeep singh @ 2007-09-17 8:59 UTC (permalink / raw)
To: git
Hi All,
I am using git at work for a rather big repository. Size is around
1.5-1.8Gigs now.
My git version is 1.5.2.4.
The remote repo has some changes to a file with some simple printk's
some some code changes.
I have my git repo in /mnt/reiser/project .
I changed to the my repo.
i did a git-pull ssh://user1@10.100.205.34/opt/test/project test .[to
pull from another test machine].
I got some conflicts in a file but in some important files it did not update it.
Any hints whats wrong with my technique or is there something wrong with git?
BTW the two machines have different versions of git. The remote
machine have git-1.4.4 from ubuntu repo.
Thanks
---
Pradeep
^ permalink raw reply [relevance 6%]
* Re: git-update-server-info may be required,cannot clone and pull from a remote repository
2007-07-13 0:17 0% ` Jakub Narebski
@ 2007-07-13 8:27 0% ` pradeep singh
0 siblings, 0 replies; 76+ results
From: pradeep singh @ 2007-07-13 8:27 UTC (permalink / raw)
To: Jakub Narebski; +Cc: Eric Wong, git
Thank you all for your valuable suggestions and timely help.
I am now able to view the git repo in a web browser.
Thank you once again for help and for a great tool like git.
--pradeep
On 7/13/07, Jakub Narebski <jnareb@gmail.com> wrote:
> Pradeep Singh wrote:
> > On 7/12/07, Jakub Narebski <jnareb@gmail.com> wrote:
> >> [Cc: git@vger.kernel.org, Pradeep Singh <pradeep.rautela@gmail.com>,
> >> Eric Wong <normalperson@yhbt.net> (instaweb creator)]
> >>
> >> pradeep singh wrote:
> >>
> >>> Anyway i could not get gitweb running after running git-instaweb.
> >>>
> >>> Any thoughts on how to setup a gitweb interface ?
> >>
> >> What information does gitweb/INSTALL lack?
> >
> > May be I am running some old version on my Ubuntu Edgy machine
> > perhaps? I cannot find such a file anywhere?
>
> You can always look up this file at git.git gitweb (either kernel.org
> one, or repo.or.cz one), e.g.
>
> http://repo.or.cz/w/alt-git.git/:gitweb/INSTALL
>
> > Looks like it is available in newer versions.
> > Does it works for git-1.4.4?
>
> The installation instructions may have changed a bit since then. It is
> much easier to use 1.5.x series, nevertheless.
>
> --
> Jakub Narebski
> Poland
>
--
Pradeep
^ permalink raw reply [relevance 0%]
* Re: git-update-server-info may be required,cannot clone and pull from a remote repository
[not found] ` <a901b49a0707120550i9361e30wc5811bd5d3305f59@mail.gmail.com>
2007-07-12 12:52 0% ` pradeep singh
@ 2007-07-13 0:17 0% ` Jakub Narebski
2007-07-13 8:27 0% ` pradeep singh
1 sibling, 1 reply; 76+ results
From: Jakub Narebski @ 2007-07-13 0:17 UTC (permalink / raw)
To: pradeep singh; +Cc: Eric Wong, git
Pradeep Singh wrote:
> On 7/12/07, Jakub Narebski <jnareb@gmail.com> wrote:
>> [Cc: git@vger.kernel.org, Pradeep Singh <pradeep.rautela@gmail.com>,
>> Eric Wong <normalperson@yhbt.net> (instaweb creator)]
>>
>> pradeep singh wrote:
>>
>>> Anyway i could not get gitweb running after running git-instaweb.
>>>
>>> Any thoughts on how to setup a gitweb interface ?
>>
>> What information does gitweb/INSTALL lack?
>
> May be I am running some old version on my Ubuntu Edgy machine
> perhaps? I cannot find such a file anywhere?
You can always look up this file at git.git gitweb (either kernel.org
one, or repo.or.cz one), e.g.
http://repo.or.cz/w/alt-git.git/:gitweb/INSTALL
> Looks like it is available in newer versions.
> Does it works for git-1.4.4?
The installation instructions may have changed a bit since then. It is
much easier to use 1.5.x series, nevertheless.
--
Jakub Narebski
Poland
^ permalink raw reply [relevance 0%]
* Re: git-update-server-info may be required,cannot clone and pull from a remote repository
2007-07-12 13:13 0% ` Johannes Schindelin
@ 2007-07-12 13:32 0% ` pradeep singh
0 siblings, 0 replies; 76+ results
From: pradeep singh @ 2007-07-12 13:32 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Jakub Narebski, Eric Wong, git
On 7/12/07, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> Hi,
>
> On Thu, 12 Jul 2007, pradeep singh wrote:
>
> > On 7/12/07, pradeep singh <pradeep.rautela@gmail.com> wrote:
> > > On 7/12/07, Jakub Narebski <jnareb@gmail.com> wrote:
> > > > What information does gitweb/INSTALL lack?
> > >
> > > May be i am running some old version on my Ubuntu Edgy machine
> > > perhaps? I cannot find such a file anywhere?
> > >
> > > Looks like it is available in newer versions. Does it works for
> > > git-1.4.4?
>
> IMHO it is not good to start with anything prior to 1.5.0, if you did not
> have any exposure to older Git. In terms of user friendliness,
> 1.4.4.4->1.5.0 is a leap by an astronomic unit.
thanks for the update.
My question now changes to -
If i upgrade to git 1.5.x will i loose my earlier git info and all the stuff?
I hope having differnt git versions on different machines does not hurts?
Thanks once again for the valuable advice.
regards
>
> Ciao,
> Dscho
>
>
--
Pradeep
^ permalink raw reply [relevance 0%]
* Re: git-update-server-info may be required,cannot clone and pull from a remote repository
2007-07-12 12:52 0% ` pradeep singh
@ 2007-07-12 13:13 0% ` Johannes Schindelin
2007-07-12 13:32 0% ` pradeep singh
0 siblings, 1 reply; 76+ results
From: Johannes Schindelin @ 2007-07-12 13:13 UTC (permalink / raw)
To: pradeep singh; +Cc: Jakub Narebski, Eric Wong, git
Hi,
On Thu, 12 Jul 2007, pradeep singh wrote:
> On 7/12/07, pradeep singh <pradeep.rautela@gmail.com> wrote:
> > On 7/12/07, Jakub Narebski <jnareb@gmail.com> wrote:
> > > What information does gitweb/INSTALL lack?
> >
> > May be i am running some old version on my Ubuntu Edgy machine
> > perhaps? I cannot find such a file anywhere?
> >
> > Looks like it is available in newer versions. Does it works for
> > git-1.4.4?
IMHO it is not good to start with anything prior to 1.5.0, if you did not
have any exposure to older Git. In terms of user friendliness,
1.4.4.4->1.5.0 is a leap by an astronomic unit.
Ciao,
Dscho
^ permalink raw reply [relevance 0%]
* Re: git-update-server-info may be required,cannot clone and pull from a remote repository
[not found] ` <a901b49a0707120550i9361e30wc5811bd5d3305f59@mail.gmail.com>
@ 2007-07-12 12:52 0% ` pradeep singh
2007-07-12 13:13 0% ` Johannes Schindelin
2007-07-13 0:17 0% ` Jakub Narebski
1 sibling, 1 reply; 76+ results
From: pradeep singh @ 2007-07-12 12:52 UTC (permalink / raw)
To: Jakub Narebski; +Cc: Eric Wong, git
sorry forgot to CC gitlist in my last mail.
On 7/12/07, pradeep singh <pradeep.rautela@gmail.com> wrote:
> On 7/12/07, Jakub Narebski <jnareb@gmail.com> wrote:
> > [Cc: git@vger.kernel.org, Pradeep Singh <pradeep.rautela@gmail.com>,
> > Eric Wong <normalperson@yhbt.net> (instaweb creator)]
> >
> > pradeep singh wrote:
> >
> > > Anyway i could not get gitweb running after running git-instaweb.
> > >
> > > Any thoughts on how to setup a gitweb interface ?
> >
> > What information does gitweb/INSTALL lack?
>
> May be i am running some old version on my Ubuntu Edgy machine perhaps?
> I cannot find such a file anywhere?
>
> Looks like it is available in newer versions.
> Does it works for git-1.4.4?
>
> thanks for help.
> >
> > --
> > Jakub Narebski
> > Warsaw, Poland
> > ShadeHawk on #git
> >
> >
> >
>
>
> --
> Pradeep
>
--
Pradeep
^ permalink raw reply [relevance 0%]
* Re: basics... when reading docs doesn't help
@ 2007-03-30 20:23 5% ` Theodore Tso
0 siblings, 0 replies; 76+ results
From: Theodore Tso @ 2007-03-30 20:23 UTC (permalink / raw)
To: Guennadi Liakhovetski
Cc: Linus Torvalds, J. Bruce Fields, Junio C Hamano, git
On Fri, Mar 30, 2007 at 09:49:20PM +0200, Guennadi Liakhovetski wrote:
> Aha, so, that's how it is then! Why hasn't anybody explained this to me
> strait away?!:-))))
A lot of this is in the git 1.5's User Manual:
http://www.kernel.org/pub/software/scm/git/docs/user-manual.html
See also the man page for git-remote, or here:
http://www.kernel.org/pub/software/scm/git/docs/git-remote.html
> Yeah, hopefully, I'll learn to at least use this thing efficiently enough.
> Someone has to write a book on it though...
The user-manual and the git tutorials are pretty good --- just make
sure you look at the ones that come with git 1.5.0, or the ones at
http://www.kernel.org/pub/software/svm/git/docs (which reflects the
Documentation as of the latest development version of git).
The problem is that there are some tutorials on the web which assume
git 1.4.x, or cogito, and that has been listed as a defect by people
who have been confused because those tutorials are out of date with
respect to modern git.[1]
[1] http://changelog.complete.org/posts/594-More-on-Git,-Mercurial,-and-Bzr.html
> And, so, it's a pity I cloned Paul's tree yesterday with the "old" git.
> And from your answer above it seems like some features of the "new" git
> will not be available with this tree, like equally named local and remote
> branches, etc. There isn't a way to convert such a "old style" tree to the
> "new style", is there? Not a big deal, will re-clone at some point, maybe
> when we get local git mirrors...
Yeah, we need to really make sure the word gets out that new git users
should really make sure they are using git 1.5, and not git 1.4.x; it
is such an improvement in terms of usability over git 1.4.x that there
really is no comparison. (Of course, guess what Debian is going to
ship in their soon-to-be-release "stable" distribution? git 1.4.4. Sigh...)
It is possible to get the new style naming, by using the git remote
command. Just do
git remote add origin <url>
...and that will adjust your git configuration file appropriate.
Check out the git 1.5.0 release notes, and the git-config man page,
and there are some other adjustments you can make as well that will
make git more efficiently, at the cost of breaking some level of
compatibility with git 1.4.x tools which replicate via the "dumb" http
protocol. But for local development repositories that generally isn't
a concern.
- Ted
^ permalink raw reply [relevance 5%]
* Re: how to speed up "git log"?
2007-02-12 4:20 0% ` Linus Torvalds
@ 2007-02-12 11:27 6% ` Bruno Haible
0 siblings, 0 replies; 76+ results
From: Bruno Haible @ 2007-02-12 11:27 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Johannes Schindelin, git
Linus,
> > git-1.4.4: 25 seconds real time, 24 seconds of CPU time (12 user, 12 system)
> > git-1.5.0: 50 seconds real time, 39 seconds of CPU time (20 user, 19 system)
>
> That's an interesting fact in itself.
Sorry, these measurements happened to be done in different conditions:
repo fully cached in RAM vs. repo not yet in buffer cache / page cache.
When measured under the same conditions, no speed difference is visible
between git-1.4.4 and git-1.5.0-rc4.
Bruno
^ permalink raw reply [relevance 6%]
* Re: how to speed up "git log"?
2007-02-11 23:41 7% ` Bruno Haible
` (2 preceding siblings ...)
2007-02-11 23:59 0% ` Robin Rosenberg
@ 2007-02-12 4:20 0% ` Linus Torvalds
2007-02-12 11:27 6% ` Bruno Haible
3 siblings, 1 reply; 76+ results
From: Linus Torvalds @ 2007-02-12 4:20 UTC (permalink / raw)
To: Bruno Haible; +Cc: Johannes Schindelin, git
On Mon, 12 Feb 2007, Bruno Haible wrote:
> Hello Johannes,
>
> Thanks for the helpful answer.
>
> > Yes, because there were only 147 commits which changed the file. But git
> > looked at all commits to find that.
>
> Ouch.
This should become a FAQ.
Git simply DOES NOT HAVE per-file history. And having it is actually a
BUG in other systems.
Not having per-file history is what allows git to do
git log directory-or-file-set
ratehr than being able to track just one file. You can't do it sanely
with per-file history (because to tie the per-file histories back
together in a logical sequence, you need the global history to sort it
again!)
So:
- git is "slow" on single-file things, because such things DON'T EVEN
EXIST in git!
When you do "git log <path-limiter>", itreally always ends up being a
full git log.
- but this is fundamentally what allows you to track multiple directories
well. It's what makes things like "gitk drivers/scsi/" actually work,
where you really can see the history for a random *collection* of
files. Nobody else can do it, afaik, and git just considers a single
filename to be a case of the "random collection of files".
The example I gave to corecode was to do
gitk builtin-rev-list.c
gitk builtin-rev-parse.c
gitk builtin-rev-parse.c builtin-rev-list.c
adn realize that doing the history for two files together is NOT AT ALL
EQUIVALENT to doing the history for those files individually and stitching
it together.
(The reason the above is a great example is that both of the files alone
have a very simple linear history, but when you look at the *combined*
history you actually see concurrent development, and merges: you see
merge commits that simply don't "exist" when only looking at the history
of one of them separately).
> Is there some other concept or command that git offers? I'm in the situation
> where I know that 'tr' in coreutils version 5.2.1 had a certain bug and
> version 6.4 does not have the bug, and I want to review all commits that
> are relevant to this. I know that the only changes in tr.c are relevant
> for this, and I'm interested in a display of the minimum amount of relevant
> commit messages. If "git log" is not the right command for this question,
> which command is it?
Do
git log v5.2.1..v6.4 -- tr.c
(or whatever your tag-names for releases are) where you can limit the log
generation cost by giving the beginning commit. But yeah, it *will* look
at the whole history in between, so if there is a long long history
between v5.2.1 and v6.4, you'll still end up using reasonable amounts of
CPU.
> > Probably the mmap() problem. Does it go away when you use git 1.5.0-rc4?
>
> No, it became even worse: git-1.5.0-rc4 is twice as slow as git-1.4.4 for
> this command:
> git-1.4.4: 25 seconds real time, 24 seconds of CPU time (12 user, 12 system)
> git-1.5.0: 50 seconds real time, 39 seconds of CPU time (20 user, 19 system)
That's an interesting fact in itself. Do you have the repo available
somewhere?
Yes, some of the operations can be improved upon by not wasting quite so
much time uncompressing stuff, so we could at least help this a bit. But
that's a long-term thing. The slowdown is bad, and that probably has some
simple explanation.
Linus
^ permalink raw reply [relevance 0%]
* Re: how to speed up "git log"?
2007-02-11 23:59 0% ` Robin Rosenberg
2007-02-12 2:02 5% ` Bruno Haible
@ 2007-02-12 4:08 0% ` Junio C Hamano
1 sibling, 0 replies; 76+ results
From: Junio C Hamano @ 2007-02-12 4:08 UTC (permalink / raw)
To: Robin Rosenberg; +Cc: Bruno Haible, Johannes Schindelin, git
Robin Rosenberg <robin.rosenberg.lists@dewire.com> writes:
>> No, it became even worse: git-1.5.0-rc4 is twice as slow as git-1.4.4 for
>> this command:
>> git-1.4.4: 25 seconds real time, 24 seconds of CPU time (12 user, 12 system)
>> git-1.5.0: 50 seconds real time, 39 seconds of CPU time (20 user, 19 system)
>
> Could the UTF-8 stuff have anything to do with this?
I doubt it -- sliding mmap() in the current git, while is a good
change overall for handling really huge repos, would most likely
perform poorer than the fixed mmap() in 1.4.4 series on
platforms with slow mmap(), most notably on MacOS X.
It _might_ be possible that turning some sliding mmap() calls
into pread() makes it perform better on MacOS X.
I wonder what happens it git is compiled with NO_MMAP there...
^ permalink raw reply [relevance 0%]
* Re: how to speed up "git log"?
2007-02-11 23:59 0% ` Robin Rosenberg
@ 2007-02-12 2:02 5% ` Bruno Haible
2007-02-12 4:08 0% ` Junio C Hamano
1 sibling, 0 replies; 76+ results
From: Bruno Haible @ 2007-02-12 2:02 UTC (permalink / raw)
To: Robin Rosenberg; +Cc: Johannes Schindelin, git
Thanks for the responses.
Robin Rosenberg wrote:
> Since you know that you are not interested in the whole history, you can limit your scan.
>
> git log COREUTILS-5_2_1..COREUTILS-6_4 src/tr.c
Thanks, that indeed does the trick: it reduces the time from 33 sec to 11 sec.
To reduce the time even more, and to allow more flexibility among the
search criteria (e.g. "I need the commits from date X to date Y, on this
file set, from anyone except me"), I would need to connect git to a database.
git cannot store all kinds of indices and reverse mappings to allow all
kinds of queries; that's really a classical database application area.
> > No, it became even worse: git-1.5.0-rc4 is twice as slow as git-1.4.4 for
> > this command:
> > git-1.4.4: 25 seconds real time, 24 seconds of CPU time (12 user, 12 system)
> > git-1.5.0: 50 seconds real time, 39 seconds of CPU time (20 user, 19 system)
>
> Could the UTF-8 stuff have anything to do with this?
Actually, no. Brown paper bag on me for doing benches in different
conditions. The timing difference is an effect of the buffer cache / page
cache:
- After the second repetition of the command (i.e. when all files are cached
in RAM), the timings are
25 seconds real time, 24 seconds of CPU time (13 user, 11 system)
both in git-1.4.4 and -1.5.0-rc4.
- After unmounting and remounting the disk containing the repository (i.e.
when none of the files are cached in RAM), the timings are
49 seconds real time, 38 seconds of CPU time (20 user, 18 system)
Sorry for the false alarm.
Bruno
^ permalink raw reply [relevance 5%]
* Re: how to speed up "git log"?
2007-02-11 23:41 7% ` Bruno Haible
2007-02-11 23:46 0% ` Shawn O. Pearce
2007-02-11 23:56 0% ` Johannes Schindelin
@ 2007-02-11 23:59 0% ` Robin Rosenberg
2007-02-12 2:02 5% ` Bruno Haible
2007-02-12 4:08 0% ` Junio C Hamano
2007-02-12 4:20 0% ` Linus Torvalds
3 siblings, 2 replies; 76+ results
From: Robin Rosenberg @ 2007-02-11 23:59 UTC (permalink / raw)
To: Bruno Haible; +Cc: Johannes Schindelin, git
måndag 12 februari 2007 00:41 skrev Bruno Haible:
> Hello Johannes,
>
> Thanks for the helpful answer.
>
> > Yes, because there were only 147 commits which changed the file. But git
> > looked at all commits to find that.
>
> Ouch.
>
> > Basically, we don't do file versions. File versions do not make sense,
> > since they strip away the context.
>
> Is there some other concept or command that git offers? I'm in the situation
> where I know that 'tr' in coreutils version 5.2.1 had a certain bug and
> version 6.4 does not have the bug, and I want to review all commits that
> are relevant to this. I know that the only changes in tr.c are relevant
> for this, and I'm interested in a display of the minimum amount of relevant
> commit messages. If "git log" is not the right command for this question,
> which command is it?
Since you know that you are not interested in the whole history, you can limit your scan.
git log COREUTILS-5_2_1..COREUTILS-6_4 src/tr.c
> > > 2) Why so much system CPU time, but only on MacOS X?
> >
> > Probably the mmap() problem. Does it go away when you use git 1.5.0-rc4?
>
> No, it became even worse: git-1.5.0-rc4 is twice as slow as git-1.4.4 for
> this command:
> git-1.4.4: 25 seconds real time, 24 seconds of CPU time (12 user, 12 system)
> git-1.5.0: 50 seconds real time, 39 seconds of CPU time (20 user, 19 system)
Could the UTF-8 stuff have anything to do with this?
-- robin
^ permalink raw reply [relevance 0%]
* Re: how to speed up "git log"?
2007-02-11 23:41 7% ` Bruno Haible
2007-02-11 23:46 0% ` Shawn O. Pearce
@ 2007-02-11 23:56 0% ` Johannes Schindelin
2007-02-11 23:59 0% ` Robin Rosenberg
2007-02-12 4:20 0% ` Linus Torvalds
3 siblings, 0 replies; 76+ results
From: Johannes Schindelin @ 2007-02-11 23:56 UTC (permalink / raw)
To: Bruno Haible; +Cc: git
Hi,
On Mon, 12 Feb 2007, Bruno Haible wrote:
> > Yes, because there were only 147 commits which changed the file. But git
> > looked at all commits to find that.
>
> Ouch.
Not so ouch:
> > Basically, we don't do file versions. File versions do not make sense,
> > since they strip away the context.
You could have it faster, but you'd break a very useful concept by doing
so.
> Is there some other concept or command that git offers? I'm in the
> situation where I know that 'tr' in coreutils version 5.2.1 had a
> certain bug and version 6.4 does not have the bug, and I want to review
> all commits that are relevant to this.
So, only look at those:
git log v5.2.1..v6.4 tr.c
(provided you have the tags for the releases). You can start reviewing
right away, since the output will start very fast (much faster than it
takes to complete the log!).
If you want to get the patches to tr.c with the logs, just add "-p":
git log -p v5.2.1..v6.4 tr.c
> > > 2) Why so much system CPU time, but only on MacOS X?
> >
> > Probably the mmap() problem. Does it go away when you use git
> > 1.5.0-rc4?
>
> No, it became even worse: git-1.5.0-rc4 is twice as slow as git-1.4.4 for
> this command:
> git-1.4.4: 25 seconds real time, 24 seconds of CPU time (12 user, 12 system)
> git-1.5.0: 50 seconds real time, 39 seconds of CPU time (20 user, 19 system)
Hmmm. I don't have MacOSX any more, so I cannot investigate. You might
find this the perfect opening into working on git ;-)
Hth,
Dscho
^ permalink raw reply [relevance 0%]
* Re: how to speed up "git log"?
2007-02-11 23:41 7% ` Bruno Haible
@ 2007-02-11 23:46 0% ` Shawn O. Pearce
2007-02-11 23:56 0% ` Johannes Schindelin
` (2 subsequent siblings)
3 siblings, 0 replies; 76+ results
From: Shawn O. Pearce @ 2007-02-11 23:46 UTC (permalink / raw)
To: Bruno Haible; +Cc: Johannes Schindelin, git
Bruno Haible <bruno@clisp.org> wrote:
> Is there some other concept or command that git offers? I'm in the situation
> where I know that 'tr' in coreutils version 5.2.1 had a certain bug and
> version 6.4 does not have the bug, and I want to review all commits that
> are relevant to this. I know that the only changes in tr.c are relevant
> for this, and I'm interested in a display of the minimum amount of relevant
> commit messages. If "git log" is not the right command for this question,
> which command is it?
Two options come to mind:
`git log v5.2.1..v6.4 -- tr.c`
`git bisect`
The former has a few different flavors, e.g. you can run the
same arguments to `gitk` to view the changes in a graphical form.
The latter will help you do a binary search through the commits
which affected tr.c between the known good and known bad revisions,
allowing you to test the possible candidates for the defect.
> > > 2) Why so much system CPU time, but only on MacOS X?
> >
> > Probably the mmap() problem. Does it go away when you use git 1.5.0-rc4?
>
> No, it became even worse: git-1.5.0-rc4 is twice as slow as git-1.4.4 for
> this command:
> git-1.4.4: 25 seconds real time, 24 seconds of CPU time (12 user, 12 system)
> git-1.5.0: 50 seconds real time, 39 seconds of CPU time (20 user, 19 system)
That's not so good... This is `git log -- tr.c >/dev/null` ?
--
Shawn.
^ permalink raw reply [relevance 0%]
* Re: how to speed up "git log"?
@ 2007-02-11 23:41 7% ` Bruno Haible
2007-02-11 23:46 0% ` Shawn O. Pearce
` (3 more replies)
0 siblings, 4 replies; 76+ results
From: Bruno Haible @ 2007-02-11 23:41 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
Hello Johannes,
Thanks for the helpful answer.
> Yes, because there were only 147 commits which changed the file. But git
> looked at all commits to find that.
Ouch.
> Basically, we don't do file versions. File versions do not make sense,
> since they strip away the context.
Is there some other concept or command that git offers? I'm in the situation
where I know that 'tr' in coreutils version 5.2.1 had a certain bug and
version 6.4 does not have the bug, and I want to review all commits that
are relevant to this. I know that the only changes in tr.c are relevant
for this, and I'm interested in a display of the minimum amount of relevant
commit messages. If "git log" is not the right command for this question,
which command is it?
> > 2) Why so much system CPU time, but only on MacOS X?
>
> Probably the mmap() problem. Does it go away when you use git 1.5.0-rc4?
No, it became even worse: git-1.5.0-rc4 is twice as slow as git-1.4.4 for
this command:
git-1.4.4: 25 seconds real time, 24 seconds of CPU time (12 user, 12 system)
git-1.5.0: 50 seconds real time, 39 seconds of CPU time (20 user, 19 system)
Bruno
^ permalink raw reply [relevance 7%]
* Re: Git rescue mission
@ 2007-02-08 15:56 5% ` Jakub Narebski
0 siblings, 0 replies; 76+ results
From: Jakub Narebski @ 2007-02-08 15:56 UTC (permalink / raw)
To: git
Bill Lear wrote:
> On Wednesday, February 7, 2007 at 16:48:42 (-0800) Junio C Hamano writes:
>> Bill Lear <rael@zopyra.com> writes:
>>
>>> 2) Why does git pull do the right thing when on master, but seemingly
>>> changes behavior when on topic?
>>
>> Because you told it to.
>>
>> % cat .git/remotes/origin
>> URL: /repos/git/project
>> Pull: refs/heads/master:refs/heads/origin
>> Pull: refs/heads/topic:refs/heads/topic
>>
>> It tells "git pull" to drive "git fetch" to copy their master to
>> your origin and overwrite your topic with their topic, and then
>> merge their master to whatever branch you are currently on.
>>
>> The sane/safe thing to do in the traditional layout (I'll talk
>> about non-traditional one in a second) is:
>>
>> - do your 'pull' only and always while on your 'master' and not
>> anywhere else.
>
> This I understand, and can follow. Sorry, but there my comprehension
> stops. Lots of confusion and befuddlement follow. Thank you in
> advance for being patient.
>
>> - never build on a branch that appears on the RHS of ':'.
>
> This I don't quite understand. So, if it is on the LHS, it is ok?
> But, if it is ALSO on the RHS it is not?
RHS = right hand side (of refspec). You should not "build" on branches
which appear on the right hand side of ':' in the "Pull:" lines, in
this example they are 'origin' and 'topic'.
> So, this:
>
> Pull: refs/heads/topic:refs/heads/topic
>
> really means don't don't work on a branch named topic in this
> repository?
Yes, with this line you should not work on a branch named 'topic';
otherwise badness might follow.
> I assume by "build on" you mean "work, compile, check stuff in,
> etc."?. Did you have something else in mind when you said "build on"?
By "build on" we mean build in SCM (in version control) sense, i.e.
adding commits on top of given branch (committing when on given branch).
Well, also do not rewind the branch (reset, rebase,...).
>> This layout is convenient when you always do fetches and pulls
>> while on 'master', but has burned enough people. So what people
>> on the list seem to recommend is to use a separate remote layout
>> in the repository.
>>
>> The principle is:
>>
>> * The branches you work on in the repository are kept in refs/heads/
>>
>> * Copies of branches from other repositories (it does not
>> matter who is in control of them -- some of them may be your
>> repository) are kept in refs/remotes/<symbolic name>.
>
> I don't currently have any 'refs/remotes' of any sort, so I guess you
> mean that the new principle, using git clone --use-separate-remote
> will effect this.
In git 1.4.4 series, "git clone --use-separate-remote"; in git 1.5.0
this layout is default when making non-bare clone (the only layout,
I think; were --use-separate-remote and --no-separate-remote removed,
or only removed from Documentation, by the way? this affects backwards
compatibility a bit).
>> So the current "git clone" (if you are using 1.4.4 series, you
>> can say "git clone --use-separate-remote") creates something
>> like this instead:
>>
>> URL: /repos/git/project
>> Pull: refs/heads/master:refs/remotes/origin/master
>> Pull: refs/heads/topic:refs/remotes/origin/topic
>>
>> (git-clone from 1.5.0 does not actually make remotes/origin file
>> in .git/ that has the above -- it creates the moral equivalent
>> in .git/config).
>
> So, using 1.4.4 series, or 1.5, the "sane" way to work in git
> is to use clone --use-separate-remotes.
>
>> So whatever you do the first step of "git pull", which is "git
>> fetch", will _not_ overwrite the current branch.
>
> I assume by this you mean that if I do the separate remote trick, I
> will not shoot myself by doing a 'git pull' while on my topic branch,
> as the setup will cause git to refuse to do it.
You would _never_ shoot yourself in foot doing "git fetch".
"git pull" would refuse merge wwhen not on correct branch only if you
use new 1.5.0 globbing (as described below).
But it is fairly easy to recover from errorneous pull.
"git reset --hard" should be enough (if fetch screwed something
"git reset --hard ORIG_HEAD" should be enough).
>> In order to prevent merging their 'master' into your 'topic'
>> when you are on 'topic', git-fetch/git-pull from 1.5.0 uses
>> further safety which is left by 'git clone'. The real
>> configuration created by 'git clone' looks like this:
>>
>> [remote "origin"]
>> url = /repos/git/project
>> fetch = refs/heads/*:refs/remotes/origin/*
>> [branch "master"]
>> remote = origin
>> merge = refs/heads/master
>>
>> The 'fetch' lines correspond to 'Pull' in .git/remotes/origin file;
>> it uses globbing pattern so if there are new branches on the
>> remote side you can automatically track them, which is a plus.
>>
>> But more importantly, when 'fetch' lines only do the globbing
>> pattern, 'git pull' without explicitly saying which remote
>> branch you want to merge to the current branch (perhaps by
>> mistake) refuses to do a merge, if there is no branch.*.merge
>> configuration ("refs/heads/master" in the above example). So
>> with the above configuration, 'git pull' from 1.5.0 will fetch
>> two remote branches and keep them in remotes/origin/master and
>> remotes/origin/topic, and if you are on 'master' their
>> refs/heads/master is merged into your current branch, but if you
>> are on 'topic', it will not do the merge step (this only applies
>> to "git pull" without any refspec parameters).
We assume for later discussion that we use git 1.5.0 (well, 1.5.0-rc4)
in the situation below.
> Ok, so if I am on master, I do this:
>
> [master] % git pull
>
> and this will fetch the remote master and merge it to my master, and
> fetch the remote topic and merge it to my local topic.
This would fetch remote master (refs/heads/master) into your local
tracking branch origin/master (refs/remotes/origin/master), and fetch
remote topic into origin/topic. Then it would merge remote master
(which is equivalent to merging local origin/master) into your local
master branch.
> While, if I am on my topic branch, if I do this:
>
> [topic] % git pull
>
> it sill fetches from the remote master and the remote topic, but will
> not merge at all.
True, it would fetch but refuse to merge.
> If I am, this still seems bizarre. I really just want a way to sync
> two repos that works consistently, and is invoked consistently, no
> matter what branch I am currently on. And, again, by "sync", I just
> mean no cross-branch merging --- no "crossing of the streams". Even
> if it were limited to syncing the current branch only, that would be
> ok, but this variable behavior seems rather odd and confusing. In
> other words, I just want to type the equivalent of 'git sync' and have
> it work, and not have to give a branch name, or be in the "right
> place" for it to work as I expect.
"Crossing of the streams" is _required_ if you do parallel work. If you
work only on one repository or the other, never doing parallel work, it
would be easier to just use 1:1 mapping (like in bare repository), and
use only "git fetch" and "git push".
If you do parallel work (well, unless you send changes via patches), then
you have to do merges. BTW git would detect if only one side made any
changes: this would result in so called fast-forward case, and no true
merge at all.
BTW. what had happened to git merge strategy "subordinate" (later renamed to
more proper "rebase" strategy)?
> Thus, I don't want to have to think "oh, I'm on my topic branch, and
> if I really want to sync from my remote repo, I need to get on my
> master branch". It seems that the only difference in the "insane" way
> I was doing things and the "sane" way you propose is that in my way, I
> had to make this mental leap or get burned by a cross-branch merge,
> but in the new way, I still have to make this mental leap if I want it
> to work, but if I don't, at least I don't get burned.
Parallel distributed development is intrinsically difficult, but also much
more elastic than rigid centralized CVS-like development.
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply [relevance 5%]
* Re: 'git config' vs 'git repo-config'
@ 2007-02-04 10:52 6% ` Junio C Hamano
0 siblings, 0 replies; 76+ results
From: Junio C Hamano @ 2007-02-04 10:52 UTC (permalink / raw)
To: Marco Costalba; +Cc: git
"Marco Costalba" <mcostalba@gmail.com> writes:
>> "Marco Costalba" <mcostalba@gmail.com> writes:
>
> I plan to release a point release after git-1.5 is out, so I'm
> wondering if renaming git-repo-config --> git-config also in qgit.
>
> BTW 'git-repo-config' seems to be currently used also by StGit
It's really up to you and Catalin, but if you expect people
might run with git 1.4.4, it would make more sense to stick with
the tried-and-proven names and wait until you are reasonably
sure that everybody you care about are running at least 1.5.0.
The only reason the in-tree scripts git.git ships with use the
new names is because they know they are part of a revision that
has them.
^ permalink raw reply [relevance 6%]
* Re: [RFC] Replace rebase with filtering
2007-01-16 21:49 6% ` Jakub Narebski
@ 2007-01-16 22:31 0% ` Brian Gernhardt
0 siblings, 0 replies; 76+ results
From: Brian Gernhardt @ 2007-01-16 22:31 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
On Jan 16, 2007, at 4:49 PM, Jakub Narebski wrote:
> Johannes Schindelin wrote:
>
>> Usually, however, this results in a conflict which you have to
>> resolve.
>> And _you_ do not have a hard time verifying that the patch already
>> went
>> in, and you just say "git rebase --skip" and the rebasing will
>> continue
>> _without_ having committed the now obsolete patch.
>
> Unfortunately, at least with git 1.4.4.x, not quite. You have to have
> index clean to do "git rebase --skip", while usually there would be
> conflict when applying patch that is already present some deeper.
>
> I think that is a bug in git-rebase.
Agreed. I tend to "git checkout HEAD -- files" before a "git rebase
--skip" to fix that, although I guess "git reset --hard" would work
just the same. But by saying "--skip" means "these changes are
irrelevant", so it should clean up after itself. It's a definite
usability snafu.
I'd put a simple patch to add the reset to git-merge.sh, but I'm not
sure I understand what --skip is doing in there with a 30 second
peek. Maybe if I get more tuits, I'll do it, but someone more
familiar with it can probably do it much faster (and be more certain
it's the right thing to do).
~~ Brian
^ permalink raw reply [relevance 0%]
* Re: [RFC] Replace rebase with filtering
@ 2007-01-16 21:49 6% ` Jakub Narebski
2007-01-16 22:31 0% ` Brian Gernhardt
0 siblings, 1 reply; 76+ results
From: Jakub Narebski @ 2007-01-16 21:49 UTC (permalink / raw)
To: git
Johannes Schindelin wrote:
> Usually, however, this results in a conflict which you have to resolve.
> And _you_ do not have a hard time verifying that the patch already went
> in, and you just say "git rebase --skip" and the rebasing will continue
> _without_ having committed the now obsolete patch.
Unfortunately, at least with git 1.4.4.x, not quite. You have to have
index clean to do "git rebase --skip", while usually there would be
conflict when applying patch that is already present some deeper.
I think that is a bug in git-rebase.
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply [relevance 6%]
* Re: What's in git.git and announcing GIT v1.5.0-rc1
2007-01-15 20:54 6% ` lamikr
@ 2007-01-15 21:56 0% ` Junio C Hamano
0 siblings, 0 replies; 76+ results
From: Junio C Hamano @ 2007-01-15 21:56 UTC (permalink / raw)
To: lamikr; +Cc: git, Horst H. von Brand
lamikr <lamikr@cc.jyu.fi> writes:
>> Be careful, this gives you a old-fashioned repository, the repositories
>> created by 1.5.0-rc are different, and 1.4.4.4 doesn't grok them:
>>
>> * refusing to create funny ref 'remotes/origin/*' locally
>>
> So that would also not work if one uses git-1.4.4 client for fetching
> from the git-1.5.x repository?
That is untrue. You do not care (nor you would not generally be
even to tell) which version the repository at the remote end was
prepared with when cloning or fetching from a remote git
repository.
A new repository created by 'git-clone' in 1.5.0 will create the
repository with default configuration that uses a new feature to
allow all (present or future) remote branches tracked.
The feature is
"refspec wildcard" and looks like this:
[remote "origin"]
fetch = +refs/heads/*:refs/remotes/origin/*
1.4.4 and older do not understand this new feature used in the
configuration, so if you create a new repository by running
1.5.0 clone, you would need to futz with the configuration file
if we want to use that repository with 1.4.4; you would need to
specify the branches you would want individually:
[remote "origin"]
fetch = +refs/heads/master:refs/remotes/origin/master
fetch = +refs/heads/next:refs/remotes/origin/next
Even if you are updating to 1.5.0, if you will never be
interested in some of the remote branches, the above to exclude
unwanted ones is a good trick to know.
^ permalink raw reply [relevance 0%]
* Re: What's in git.git and announcing GIT v1.5.0-rc1
@ 2007-01-15 20:54 6% ` lamikr
2007-01-15 21:56 0% ` Junio C Hamano
0 siblings, 1 reply; 76+ results
From: lamikr @ 2007-01-15 20:54 UTC (permalink / raw)
To: Horst H. von Brand; +Cc: Junio C Hamano, git
>> Would it make sense to add something like this to the announcements as
>> it is not very easy to find references to the git-repository itself from
>> the net.
>>
>> You can get the git repository-itself by using a following commands
>>
>> git-clone git://git.kernel.org/pub/scm/git/git.git git_repo
>>
>> After that you can switch to tagged version <v1.5.0-rc1> or sources
>> from the repository by using command
>>
>> git-checkout -f v1.5.0-rc1 master
>>
>> Alternatively you can download the tar packed version of sources from
>>
>> http://www.kernel.org/pub/software/scm/git/
>>
>
> Be careful, this gives you a old-fashioned repository, the repositories
> created by 1.5.0-rc are different, and 1.4.4.4 doesn't grok them:
>
> * refusing to create funny ref 'remotes/origin/*' locally
>
So that would also not work if one uses git-1.4.4 client for fetching
from the git-1.5.x repository?
How one is then supposed to jump from head/master to tagged version?
Mika
^ permalink raw reply [relevance 6%]
* [PATCH] git-svnimport: clean svn path when accessing SVN repo
2006-12-14 21:43 8% ` Sasha Khapyorsky
@ 2007-01-07 0:22 5% ` Sasha Khapyorsky
0 siblings, 0 replies; 76+ results
From: Sasha Khapyorsky @ 2007-01-07 0:22 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
Clean svn path from leading '/' when accessing SVN repo.
Signed-off-by: Sasha Khapyorsky <sashak@voltaire.com>
---
This fixes git-svnimport problems reported in this thread ("git-svnimport
breakage as of git-1.4.4"). Finally I forgot to submit this then, sorry
about that.
git-svnimport.perl | 4 ++++
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/git-svnimport.perl b/git-svnimport.perl
index cbaa8ab..071777b 100755
--- a/git-svnimport.perl
+++ b/git-svnimport.perl
@@ -146,6 +146,7 @@ sub file {
print "... $rev $path ...\n" if $opt_v;
my (undef, $properties);
my $pool = SVN::Pool->new();
+ $path =~ s#^/*##;
eval { (undef, $properties)
= $self->{'svn'}->get_file($path,$rev,$fh,$pool); };
$pool->clear;
@@ -181,6 +182,7 @@ sub ignore {
my($self,$path,$rev) = @_;
print "... $rev $path ...\n" if $opt_v;
+ $path =~ s#^/*##;
my (undef,undef,$properties)
= $self->{'svn'}->get_dir($path,$rev,undef);
if (exists $properties->{'svn:ignore'}) {
@@ -197,6 +199,7 @@ sub ignore {
sub dir_list {
my($self,$path,$rev) = @_;
+ $path =~ s#^/*##;
my ($dirents,undef,$properties)
= $self->{'svn'}->get_dir($path,$rev,undef);
return $dirents;
@@ -354,6 +357,7 @@ open BRANCHES,">>", "$git_dir/svn2git";
sub node_kind($$) {
my ($svnpath, $revision) = @_;
my $pool=SVN::Pool->new;
+ $svnpath =~ s#^/*##;
my $kind = $svn->{'svn'}->check_path($svnpath,$revision,$pool);
$pool->clear;
return $kind;
--
1.5.0.rc0.g2484-dirty
^ permalink raw reply related [relevance 5%]
* newbie question - git-pull and local branch merge
@ 2006-12-22 10:27 5% Pelle Svensson
0 siblings, 0 replies; 76+ results
From: Pelle Svensson @ 2006-12-22 10:27 UTC (permalink / raw)
To: git
Hi,
I'm quiet new to git and I have done this so far:
1. Installed git-1.4.4
2. pulled linus kernel tree.
3. Created a local branch 'git-checkout my stuff'
4. Edit a number of files.
5. git-commit -a
6. git-pull
7. Edit a couple more files.
8. git-pull <- Problem!
Accidentally I had 2 files not committed and one of these also
had changes in the git-pull master branch which git could
not merge automatically.
Changes has been done but I'm not fully convinced what has happen.
I see that files has been changed and the failing merge file need's
to be edit.
The really question I need answer is how can I see what changes
has been done in the master branch (the one pulled in) of the
file I suppose to merge manually. Is there no way to get out
the 2 last versions from the master branch and supply them to
KDiff3 or similarly diff program.
Also by reading the documentation I wounder what the difference is of:
- commit and check-in, seem to be same thing.
- update index-file and update the repository.
/Thanks
^ permalink raw reply [relevance 5%]
* Re: git-svnimport breakage as of git-1.4.4
2006-12-14 21:32 8% ` Junio C Hamano
@ 2006-12-14 21:43 8% ` Sasha Khapyorsky
2007-01-07 0:22 5% ` [PATCH] git-svnimport: clean svn path when accessing SVN repo Sasha Khapyorsky
0 siblings, 1 reply; 76+ results
From: Sasha Khapyorsky @ 2006-12-14 21:43 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
On 13:32 Thu 14 Dec , Junio C Hamano wrote:
> >
> > Thanks for reporting. I still run git-svnimport against
> > http://tortoisesvn.tigris.org/svn/tortoisesvn, works fine up to now.
>
> An applicable version of the patch with proposed commit log
> message would be much appreciated.
Sure.
Wanted at least to finish the test (it is running yet), then will
submit the patch in conventional way.
^ permalink raw reply [relevance 8%]
* Re: git-svnimport breakage as of git-1.4.4
2006-12-14 21:20 8% ` Sasha Khapyorsky
@ 2006-12-14 21:32 8% ` Junio C Hamano
2006-12-14 21:43 8% ` Sasha Khapyorsky
0 siblings, 1 reply; 76+ results
From: Junio C Hamano @ 2006-12-14 21:32 UTC (permalink / raw)
To: Sasha Khapyorsky; +Cc: git
Sasha Khapyorsky <sashak@voltaire.com> writes:
> On 16:05 Thu 14 Dec , Daniel Drake wrote:
>> On Thu, 2006-12-14 at 04:21 +0200, Sasha Khapyorsky wrote:
>> > Try this please:
>> >
>> >
>> > diff --git a/git-svnimport.perl b/git-svnimport.perl
>> > index cbaa8ab..071777b 100755
>> > --- a/git-svnimport.perl
>> > +++ b/git-svnimport.perl
>>
>> Thanks, it now works for both forms of command line arguments.
>
> Thanks for reporting. I still run git-svnimport against
> http://tortoisesvn.tigris.org/svn/tortoisesvn, works fine up to now.
An applicable version of the patch with proposed commit log
message would be much appreciated.
^ permalink raw reply [relevance 8%]
* Re: git-svnimport breakage as of git-1.4.4
2006-12-14 21:05 8% ` Daniel Drake
@ 2006-12-14 21:20 8% ` Sasha Khapyorsky
2006-12-14 21:32 8% ` Junio C Hamano
0 siblings, 1 reply; 76+ results
From: Sasha Khapyorsky @ 2006-12-14 21:20 UTC (permalink / raw)
To: Daniel Drake; +Cc: git, Dongsheng Song
On 16:05 Thu 14 Dec , Daniel Drake wrote:
> On Thu, 2006-12-14 at 04:21 +0200, Sasha Khapyorsky wrote:
> > Try this please:
> >
> >
> > diff --git a/git-svnimport.perl b/git-svnimport.perl
> > index cbaa8ab..071777b 100755
> > --- a/git-svnimport.perl
> > +++ b/git-svnimport.perl
>
> Thanks, it now works for both forms of command line arguments.
Thanks for reporting. I still run git-svnimport against
http://tortoisesvn.tigris.org/svn/tortoisesvn, works fine up to now.
^ permalink raw reply [relevance 8%]
* Re: git-svnimport breakage as of git-1.4.4
2006-12-14 2:21 8% ` Sasha Khapyorsky
@ 2006-12-14 21:05 8% ` Daniel Drake
2006-12-14 21:20 8% ` Sasha Khapyorsky
0 siblings, 1 reply; 76+ results
From: Daniel Drake @ 2006-12-14 21:05 UTC (permalink / raw)
To: Sasha Khapyorsky; +Cc: git
On Thu, 2006-12-14 at 04:21 +0200, Sasha Khapyorsky wrote:
> Try this please:
>
>
> diff --git a/git-svnimport.perl b/git-svnimport.perl
> index cbaa8ab..071777b 100755
> --- a/git-svnimport.perl
> +++ b/git-svnimport.perl
Thanks, it now works for both forms of command line arguments.
--
Daniel Drake
Brontes Technologies, A 3M Company
^ permalink raw reply [relevance 8%]
* Re: git-svnimport breakage as of git-1.4.4
2006-12-11 21:01 8% ` Dongsheng Song
@ 2006-12-14 2:25 7% ` Sasha Khapyorsky
0 siblings, 0 replies; 76+ results
From: Sasha Khapyorsky @ 2006-12-14 2:25 UTC (permalink / raw)
To: Dongsheng Song; +Cc: Daniel Drake, git
On 05:01 Tue 12 Dec , Dongsheng Song wrote:
>
> git-svnimport -v -i -r -o master -l $mr -C $WC_ROOT/$REPO_NAME
> http://tortoisesvn.tigris.org/svn/tortoisesvn
Thanks.
I'm running now git-svnimport against
http://tortoisesvn.tigris.org/svn/tortoisesvn with follow patch:
diff --git a/git-svnimport.perl b/git-svnimport.perl
index cbaa8ab..071777b 100755
--- a/git-svnimport.perl
+++ b/git-svnimport.perl
@@ -146,6 +146,7 @@ sub file {
print "... $rev $path ...\n" if $opt_v;
my (undef, $properties);
my $pool = SVN::Pool->new();
+ $path =~ s#^/*##;
eval { (undef, $properties)
= $self->{'svn'}->get_file($path,$rev,$fh,$pool); };
$pool->clear;
@@ -181,6 +182,7 @@ sub ignore {
my($self,$path,$rev) = @_;
print "... $rev $path ...\n" if $opt_v;
+ $path =~ s#^/*##;
my (undef,undef,$properties)
= $self->{'svn'}->get_dir($path,$rev,undef);
if (exists $properties->{'svn:ignore'}) {
@@ -197,6 +199,7 @@ sub ignore {
sub dir_list {
my($self,$path,$rev) = @_;
+ $path =~ s#^/*##;
my ($dirents,undef,$properties)
= $self->{'svn'}->get_dir($path,$rev,undef);
return $dirents;
@@ -354,6 +357,7 @@ open BRANCHES,">>", "$git_dir/svn2git";
sub node_kind($$) {
my ($svnpath, $revision) = @_;
my $pool=SVN::Pool->new;
+ $svnpath =~ s#^/*##;
my $kind = $svn->{'svn'}->check_path($svnpath,$revision,$pool);
$pool->clear;
return $kind;
And it works up to now.
This is the same patch as recently posted to Daniel. Could you try?
^ permalink raw reply related [relevance 7%]
* Re: git-svnimport breakage as of git-1.4.4
2006-12-13 16:28 8% ` Daniel Drake
@ 2006-12-14 2:21 8% ` Sasha Khapyorsky
2006-12-14 21:05 8% ` Daniel Drake
0 siblings, 1 reply; 76+ results
From: Sasha Khapyorsky @ 2006-12-14 2:21 UTC (permalink / raw)
To: Daniel Drake; +Cc: git
On 11:28 Wed 13 Dec , Daniel Drake wrote:
>
> Sorry, apparently I was using the wrong git-svnimport in my last mail.
> The above command, with or without your svn_dir patch, doesn't solve the
> problem.
>
> With your patch:
Original patch is wrong, so only w/out this patch.
>
> # git-svnimport -v -i -C repo -r https://server/repo
>
> RA layer request failed: PROPFIND request failed on '/trunk/.cvsignore':
> PROPFIND of '/trunk/.cvsignore': 405 Method Not Allowed (https://svn) at
> git-svnimport line 364
>
> Without the patch, the error is the same as the 1st case in both
> situations.
Try this please:
diff --git a/git-svnimport.perl b/git-svnimport.perl
index cbaa8ab..071777b 100755
--- a/git-svnimport.perl
+++ b/git-svnimport.perl
@@ -146,6 +146,7 @@ sub file {
print "... $rev $path ...\n" if $opt_v;
my (undef, $properties);
my $pool = SVN::Pool->new();
+ $path =~ s#^/*##;
eval { (undef, $properties)
= $self->{'svn'}->get_file($path,$rev,$fh,$pool); };
$pool->clear;
@@ -181,6 +182,7 @@ sub ignore {
my($self,$path,$rev) = @_;
print "... $rev $path ...\n" if $opt_v;
+ $path =~ s#^/*##;
my (undef,undef,$properties)
= $self->{'svn'}->get_dir($path,$rev,undef);
if (exists $properties->{'svn:ignore'}) {
@@ -197,6 +199,7 @@ sub ignore {
sub dir_list {
my($self,$path,$rev) = @_;
+ $path =~ s#^/*##;
my ($dirents,undef,$properties)
= $self->{'svn'}->get_dir($path,$rev,undef);
return $dirents;
@@ -354,6 +357,7 @@ open BRANCHES,">>", "$git_dir/svn2git";
sub node_kind($$) {
my ($svnpath, $revision) = @_;
my $pool=SVN::Pool->new;
+ $svnpath =~ s#^/*##;
my $kind = $svn->{'svn'}->check_path($svnpath,$revision,$pool);
$pool->clear;
return $kind;
Thanks,
^ permalink raw reply related [relevance 8%]
* Re: git-svnimport breakage as of git-1.4.4
2006-12-11 20:49 8% ` Sasha Khapyorsky
2006-12-11 21:03 8% ` Daniel Drake
@ 2006-12-13 16:28 8% ` Daniel Drake
2006-12-14 2:21 8% ` Sasha Khapyorsky
1 sibling, 1 reply; 76+ results
From: Daniel Drake @ 2006-12-13 16:28 UTC (permalink / raw)
To: Sasha Khapyorsky; +Cc: git
On Mon, 2006-12-11 at 22:49 +0200, Sasha Khapyorsky wrote:
> Maybe I'm starting to understand. Your svn url (url which points to svn
> repository) is https://server/repo and not just https://server, right?
>
> If so, please remove the patch (you don't need it) and rerun:
>
> git-svnimport -v -i -C repo -r https://server/repo
Sorry, apparently I was using the wrong git-svnimport in my last mail.
The above command, with or without your svn_dir patch, doesn't solve the
problem.
With your patch:
# git-svnimport -v -i -C repo -r https://server/repo
RA layer request failed: PROPFIND request failed on '/trunk/.cvsignore':
PROPFIND of '/trunk/.cvsignore': 405 Method Not Allowed (https://svn) at
git-svnimport line 364
# git-svnimport -v -i -C repo -r https://server repo
perl: subversion/libsvn_subr/path.c:377: svn_path_basename: Assertion
`is_canonical (path, len)' failed.
Aborted
Without the patch, the error is the same as the 1st case in both
situations.
--
Daniel Drake
Brontes Technologies, A 3M Company
^ permalink raw reply [relevance 8%]
* Re: git-svnimport breakage as of git-1.4.4
2006-12-11 21:03 8% ` Daniel Drake
@ 2006-12-11 22:03 8% ` Sasha Khapyorsky
0 siblings, 0 replies; 76+ results
From: Sasha Khapyorsky @ 2006-12-11 22:03 UTC (permalink / raw)
To: Daniel Drake; +Cc: git
On 16:03 Mon 11 Dec , Daniel Drake wrote:
> On Mon, 2006-12-11 at 22:49 +0200, Sasha Khapyorsky wrote:
> > Maybe I'm starting to understand. Your svn url (url which points to svn
> > repository) is https://server/repo and not just https://server, right?
>
> Yes, and then under that we have https://server/repo/trunk
>
> > If so, please remove the patch (you don't need it) and rerun:
> >
> > git-svnimport -v -i -C repo -r https://server/repo
>
> Ah, that fixes it. However, in versions before 1.4.4, either invokation
> style works.
Frankly I think that it was bug. And I will see how to restore this. :)
^ permalink raw reply [relevance 8%]
* Re: git-svnimport breakage as of git-1.4.4
2006-12-11 20:49 8% ` Sasha Khapyorsky
@ 2006-12-11 21:03 8% ` Daniel Drake
2006-12-11 22:03 8% ` Sasha Khapyorsky
2006-12-13 16:28 8% ` Daniel Drake
1 sibling, 1 reply; 76+ results
From: Daniel Drake @ 2006-12-11 21:03 UTC (permalink / raw)
To: Sasha Khapyorsky; +Cc: git
On Mon, 2006-12-11 at 22:49 +0200, Sasha Khapyorsky wrote:
> Maybe I'm starting to understand. Your svn url (url which points to svn
> repository) is https://server/repo and not just https://server, right?
Yes, and then under that we have https://server/repo/trunk
> If so, please remove the patch (you don't need it) and rerun:
>
> git-svnimport -v -i -C repo -r https://server/repo
Ah, that fixes it. However, in versions before 1.4.4, either invokation
style works.
Thanks,
--
Daniel Drake
Brontes Technologies, A 3M Company
^ permalink raw reply [relevance 8%]
* Re: git-svnimport breakage as of git-1.4.4
2006-12-11 20:50 8% ` Sasha Khapyorsky
@ 2006-12-11 21:01 8% ` Dongsheng Song
2006-12-14 2:25 7% ` Sasha Khapyorsky
0 siblings, 1 reply; 76+ results
From: Dongsheng Song @ 2006-12-11 21:01 UTC (permalink / raw)
To: Sasha Khapyorsky; +Cc: Daniel Drake, git
$ cat svn2git-tortoisesvn.sh
#!/bin/sh
export LC_ALL=C
export WC_ROOT=/home/cauchy/wc/git
export REPO_NAME=tortoisesvn
echo "[`date`] Start import & pack ..."
mr=0
while [ $mr -le 9000 ]; do
if test -f $WC_ROOT/$REPO_NAME/.git/SVN2GIT_HEAD; then
echo "[`date`] clean up ..."
cd $WC_ROOT/$REPO_NAME
git-read-tree -m -u SVN2GIT_HEAD HEAD && rm -f .git/SVN2GIT_HEAD
echo "[`date`] clean up finished"
fi
mr=$(($mr + 1000))
echo "[`date`] Start import up to revison $mr ..."
git-svnimport -v -i -r -o master -l $mr -C $WC_ROOT/$REPO_NAME
http://tortoisesvn.tigris.org/svn/tortoisesvn
echo "[`date`] Finish import up to revison $mr"
cd $WC_ROOT/$REPO_NAME && git-repack -a -d --window=64 --depth=64
echo "[`date`] Finish repack revison $mr"
cd $WC_ROOT/$REPO_NAME && find .git -name pack | xargs ls -l
done
echo "[`date`] Finished import & pack"
2006/12/12, Sasha Khapyorsky <sashak@voltaire.com>:
> On 04:00 Tue 12 Dec , Dongsheng Song wrote:
> > Sorry, I assume you have see http://tortoisesvn.tigris.org/:
> >
> > username : guest
> > password : ""
>
> Thanks, I can grab svn log now. Which command line you are using?
>
> Sasha
^ permalink raw reply [relevance 8%]
* Re: git-svnimport breakage as of git-1.4.4
2006-12-11 20:00 8% ` Dongsheng Song
@ 2006-12-11 20:50 8% ` Sasha Khapyorsky
2006-12-11 21:01 8% ` Dongsheng Song
0 siblings, 1 reply; 76+ results
From: Sasha Khapyorsky @ 2006-12-11 20:50 UTC (permalink / raw)
To: Dongsheng Song; +Cc: Daniel Drake, git
On 04:00 Tue 12 Dec , Dongsheng Song wrote:
> Sorry, I assume you have see http://tortoisesvn.tigris.org/:
>
> username : guest
> password : ""
Thanks, I can grab svn log now. Which command line you are using?
^ permalink raw reply [relevance 8%]
* Re: git-svnimport breakage as of git-1.4.4
2006-12-11 14:27 8% ` Daniel Drake
@ 2006-12-11 20:49 8% ` Sasha Khapyorsky
2006-12-11 21:03 8% ` Daniel Drake
2006-12-13 16:28 8% ` Daniel Drake
0 siblings, 2 replies; 76+ results
From: Sasha Khapyorsky @ 2006-12-11 20:49 UTC (permalink / raw)
To: Daniel Drake; +Cc: git
On 09:27 Mon 11 Dec , Daniel Drake wrote:
> On Fri, 2006-12-08 at 22:32 +0200, Sasha Khapyorsky wrote:
> > > # git-svnimport -v -i -C repo -r https://server repo
> >
> > Is this 'server' public? Can I rerun this git-svnimport?
>
> Sorry, it is not.
>
> > @@ -906,7 +912,7 @@ sub commit_all {
> > my ($changed_paths, $revision, $author, $date, $message, $pool) = @_;
> > my %p;
> > while(my($path,$action) = each %$changed_paths) {
> > - $p{$path} = [ $action->action,$action->copyfrom_path, $action->copyfrom_rev, $path ];
> > + $p{$path} = [ $action->action,$svn_dir$action->copyfrom_path, $action->copyfrom_rev, $svn_dir$path ];
>
> This is not valid perl - I think you wanted $svn_dir . $path
Yes, sorry.
>
> After making that modification it's not fixed though:
>
> Fetching from 1 to 10742 ...
> Tree ID 4b825dc642cb6eb9a060e54bf8d69288fbee4904
> Committed change 1:/ 2004-12-22 22:53:27)
> Committing initial tree 4b825dc642cb6eb9a060e54bf8d69288fbee4904
> Commit ID 2614c05ac4c5f24eb89cea056a7d46c909084d8c
> Writing to refs/heads/origin
> DONE: 1 origin 2614c05ac4c5f24eb89cea056a7d46c909084d8c
> perl: subversion/libsvn_subr/path.c:377: svn_path_basename: Assertion
> `is_canonical (path, len)' failed.
> Aborted
Maybe I'm starting to understand. Your svn url (url which points to svn
repository) is https://server/repo and not just https://server, right?
If so, please remove the patch (you don't need it) and rerun:
git-svnimport -v -i -C repo -r https://server/repo
^ permalink raw reply [relevance 8%]
* Re: git-svnimport breakage as of git-1.4.4
2006-12-10 11:47 8% ` Sasha Khapyorsky
@ 2006-12-11 20:00 8% ` Dongsheng Song
2006-12-11 20:50 8% ` Sasha Khapyorsky
0 siblings, 1 reply; 76+ results
From: Dongsheng Song @ 2006-12-11 20:00 UTC (permalink / raw)
To: Sasha Khapyorsky; +Cc: Daniel Drake, git
Sorry, I assume you have see http://tortoisesvn.tigris.org/:
username : guest
password : ""
2006/12/10, Sasha Khapyorsky <sashak@voltaire.com>:
> On 11:49 Sun 10 Dec , Dongsheng Song wrote:
> > I met the broken too, when I downgrade to 1.4.3.4, it's fine.
> >
> > I have not test your patch, but you can try your self,
> >
> > http://tortoisesvn.tigris.org/svn/tortoisesvn
> >
> > and the master branch(today) fail between r6000~r7000 too
>
> Thanks for the link. but I cannot access - this requires
> username/password authentication.
>
> Sasha
^ permalink raw reply [relevance 8%]
* Re: git-svnimport breakage as of git-1.4.4
2006-12-08 20:32 8% ` Sasha Khapyorsky
2006-12-10 3:49 8% ` Dongsheng Song
@ 2006-12-11 14:27 8% ` Daniel Drake
2006-12-11 20:49 8% ` Sasha Khapyorsky
1 sibling, 1 reply; 76+ results
From: Daniel Drake @ 2006-12-11 14:27 UTC (permalink / raw)
To: Sasha Khapyorsky; +Cc: git
On Fri, 2006-12-08 at 22:32 +0200, Sasha Khapyorsky wrote:
> > # git-svnimport -v -i -C repo -r https://server repo
>
> Is this 'server' public? Can I rerun this git-svnimport?
Sorry, it is not.
> @@ -906,7 +912,7 @@ sub commit_all {
> my ($changed_paths, $revision, $author, $date, $message, $pool) = @_;
> my %p;
> while(my($path,$action) = each %$changed_paths) {
> - $p{$path} = [ $action->action,$action->copyfrom_path, $action->copyfrom_rev, $path ];
> + $p{$path} = [ $action->action,$svn_dir$action->copyfrom_path, $action->copyfrom_rev, $svn_dir$path ];
This is not valid perl - I think you wanted $svn_dir . $path
After making that modification it's not fixed though:
Fetching from 1 to 10742 ...
Tree ID 4b825dc642cb6eb9a060e54bf8d69288fbee4904
Committed change 1:/ 2004-12-22 22:53:27)
Committing initial tree 4b825dc642cb6eb9a060e54bf8d69288fbee4904
Commit ID 2614c05ac4c5f24eb89cea056a7d46c909084d8c
Writing to refs/heads/origin
DONE: 1 origin 2614c05ac4c5f24eb89cea056a7d46c909084d8c
perl: subversion/libsvn_subr/path.c:377: svn_path_basename: Assertion
`is_canonical (path, len)' failed.
Aborted
--
Daniel Drake
Brontes Technologies, A 3M Company
^ permalink raw reply [relevance 8%]
* Re: git-svnimport breakage as of git-1.4.4
2006-12-10 3:49 8% ` Dongsheng Song
@ 2006-12-10 11:47 8% ` Sasha Khapyorsky
2006-12-11 20:00 8% ` Dongsheng Song
0 siblings, 1 reply; 76+ results
From: Sasha Khapyorsky @ 2006-12-10 11:47 UTC (permalink / raw)
To: Dongsheng Song; +Cc: Daniel Drake, git
On 11:49 Sun 10 Dec , Dongsheng Song wrote:
> I met the broken too, when I downgrade to 1.4.3.4, it's fine.
>
> I have not test your patch, but you can try your self,
>
> http://tortoisesvn.tigris.org/svn/tortoisesvn
>
> and the master branch(today) fail between r6000~r7000 too
Thanks for the link. but I cannot access - this requires
username/password authentication.
^ permalink raw reply [relevance 8%]
* Re: git-svnimport breakage as of git-1.4.4
2006-12-08 20:32 8% ` Sasha Khapyorsky
@ 2006-12-10 3:49 8% ` Dongsheng Song
2006-12-10 11:47 8% ` Sasha Khapyorsky
2006-12-11 14:27 8% ` Daniel Drake
1 sibling, 1 reply; 76+ results
From: Dongsheng Song @ 2006-12-10 3:49 UTC (permalink / raw)
To: Sasha Khapyorsky; +Cc: Daniel Drake, git
I met the broken too, when I downgrade to 1.4.3.4, it's fine.
I have not test your patch, but you can try your self,
http://tortoisesvn.tigris.org/svn/tortoisesvn
and the master branch(today) fail between r6000~r7000 too
2006/12/9, Sasha Khapyorsky <sashak@voltaire.com>:
> Hi,
>
> On 10:26 Thu 07 Dec , Daniel Drake wrote:
> >
> > git-svnimport broken between git-1.4.3.5 and git-1.4.4
> >
>
> Is this 'server' public? Can I rerun this git-svnimport?
>
> If not, please try the patch:
^ permalink raw reply [relevance 8%]
* Re: git-svnimport breakage as of git-1.4.4
2006-12-07 15:26 14% git-svnimport breakage as of git-1.4.4 Daniel Drake
@ 2006-12-08 20:32 8% ` Sasha Khapyorsky
2006-12-10 3:49 8% ` Dongsheng Song
2006-12-11 14:27 8% ` Daniel Drake
0 siblings, 2 replies; 76+ results
From: Sasha Khapyorsky @ 2006-12-08 20:32 UTC (permalink / raw)
To: Daniel Drake; +Cc: git
Hi,
On 10:26 Thu 07 Dec , Daniel Drake wrote:
>
> git-svnimport broken between git-1.4.3.5 and git-1.4.4
>
> I have found that commit 83936a29e275bc0c04f60d3333e4951a9e16b1fc is the
> cause of this.
>
> I am using git-svnimport to work with a repo with this layout:
>
> https://server/repo/trunk
> https://server/repo/tags/x.y.z
> https://server/repo/branches/somebranch
>
> Starting a fresh import:
>
> # git-svnimport -v -i -C repo -r https://server repo
Is this 'server' public? Can I rerun this git-svnimport?
If not, please try the patch:
diff --git a/git-svnimport.perl b/git-svnimport.perl
index cbaa8ab..b9de446 100755
--- a/git-svnimport.perl
+++ b/git-svnimport.perl
@@ -210,6 +210,12 @@ $svn .= "/$svn_dir" if defined $svn_dir;
my $svn2 = SVNconn->new($svn);
$svn = SVNconn->new($svn);
+if($svn_dir) {
+ $svn_dir =~ s#/*$#/#;
+} else {
+ $svn_dir = "";
+}
+
my $lwp_ua;
if($opt_d or $opt_D) {
$svn_url = URI->new($svn_url)->canonical;
@@ -906,7 +912,7 @@ sub commit_all {
my ($changed_paths, $revision, $author, $date, $message, $pool) = @_;
my %p;
while(my($path,$action) = each %$changed_paths) {
- $p{$path} = [ $action->action,$action->copyfrom_path, $action->copyfrom_rev, $path ];
+ $p{$path} = [ $action->action,$svn_dir$action->copyfrom_path, $action->copyfrom_rev, $svn_dir$path ];
}
$changed_paths = \%p;
Thanks,
^ permalink raw reply related [relevance 8%]
* git-svnimport breakage as of git-1.4.4
@ 2006-12-07 15:26 14% Daniel Drake
2006-12-08 20:32 8% ` Sasha Khapyorsky
0 siblings, 1 reply; 76+ results
From: Daniel Drake @ 2006-12-07 15:26 UTC (permalink / raw)
To: git; +Cc: sashak
Hi,
git-svnimport broken between git-1.4.3.5 and git-1.4.4
I have found that commit 83936a29e275bc0c04f60d3333e4951a9e16b1fc is the
cause of this.
I am using git-svnimport to work with a repo with this layout:
https://server/repo/trunk
https://server/repo/tags/x.y.z
https://server/repo/branches/somebranch
Starting a fresh import:
# git-svnimport -v -i -C repo -r https://server repo
Fetching from 1 to 10707 ...
Tree ID 4b825dc642cb6eb9a060e54bf8d69288fbee4904
Committed change 1:/ 2004-12-22 22:53:27)
Committing initial tree 4b825dc642cb6eb9a060e54bf8d69288fbee4904
Commit ID 2614c05ac4c5f24eb89cea056a7d46c909084d8c
Writing to refs/heads/origin
DONE: 1 origin 2614c05ac4c5f24eb89cea056a7d46c909084d8c
RA layer request failed: PROPFIND request failed on '/trunk/.cvsignore':
PROPFIND of '/trunk/.cvsignore': 405 Method Not Allowed (https://server)
at /usr/bin/git-svnimport line 358
According to the server logs, git is requesting /trunk/.cvsignore rather
than /repo/trunk/.cvsignore
I'm happy to test patches and whatnot but don't have time to investigate
further right now.
Thanks!
--
Daniel Drake
Brontes Technologies, A 3M Company
^ permalink raw reply [relevance 14%]
* Re: jgit performance update
2006-12-03 23:39 6% ` Robin Rosenberg
2006-12-03 23:58 0% ` Jakub Narebski
@ 2006-12-04 20:35 0% ` Juergen Stuber
1 sibling, 0 replies; 76+ results
From: Juergen Stuber @ 2006-12-04 20:35 UTC (permalink / raw)
To: git
Hej Robin,
Robin Rosenberg <robin.rosenberg.lists@dewire.com> writes:
> söndag 03 december 2006 23:42 skrev Juergen Stuber:
>> Jakub Narebski <jnareb@gmail.com> writes:
>> > GitWiki tells us about egit/jgit repository at
>> > http://www.spearce.org/projects/scm/egit.git
>>
>> I tried to access that with git 1.4.4.1 from Debian but
>>
>> % git clone http://www.spearce.org/projects/scm/egit.git
>>
>> hangs, the first time after "walk
>> e339766abc2b919e7bb396cae22ddef065821381", the second time after "walk
>> 9eec90ec5da239e063eaff6305d77294dc03396e" which is the "walk" line just
>> before it.
> Works fine here. (git 1.4.4.gf05d).
now it works fine for me, too.
Tack
Jürgen
--
Jürgen Stuber <juergen@jstuber.net>
http://www.jstuber.net/
gnupg key fingerprint = 2767 CA3C 5680 58BA 9A91 23D9 BED6 9A7A AF9E 68B4
^ permalink raw reply [relevance 0%]
* Re: jgit performance update
2006-12-03 23:39 6% ` Robin Rosenberg
@ 2006-12-03 23:58 0% ` Jakub Narebski
2006-12-04 20:35 0% ` Juergen Stuber
1 sibling, 0 replies; 76+ results
From: Jakub Narebski @ 2006-12-03 23:58 UTC (permalink / raw)
To: git
Robin Rosenberg wrote:
> söndag 03 december 2006 23:42 skrev Juergen Stuber:
>>
>> Jakub Narebski <jnareb@gmail.com> writes:
>>>
>>> GitWiki tells us about egit/jgit repository at
>>> http://www.spearce.org/projects/scm/egit.git
>>
>> I tried to access that with git 1.4.4.1 from Debian but
>>
>> % git clone http://www.spearce.org/projects/scm/egit.git
>>
>> hangs, the first time after "walk
>> e339766abc2b919e7bb396cae22ddef065821381", the second time after "walk
>> 9eec90ec5da239e063eaff6305d77294dc03396e" which is the "walk" line just
>> before it.
>
> Works fine here. (git 1.4.4.gf05d).
Works fine here. (git 1.4.4.1)
>> There's also the following error shortly after the start:
>>
>> error: File bc01ab9e5fcd26918d7a334207183fa57ff1ce50
>> (http://www.spearce.org/projects/scm/egit.git/objects/75/1c8f2e504c40d1c41e
>>bbd87d8f8968529e9c30) corrupt
>
> Unfortunately, messages about corrupt objects are "normal" with clone over
> http. I'm not sure it has to be that way though. Run git-fsck-objects to make
> sure there are no errors. The hangs aren't normal.
I got:
$ git clone http://www.spearce.org/projects/scm/egit.git
[...]
got 73ed47b2bb1fa5978f7368775979e5c85d354c5a
error: File 2332eacf114debb7a27d138811197f06eb262551
(http://www.spearce.org/projects/scm/egit.git/objects/75/1c8f2e504c40d1c41ebbd87d8f8968529e9c30) corrupt
Getting pack list for http://www.spearce.org/projects/scm/egit.git/
got afefbe09bacc08adb75fb46200a973001c6b02de
[...]
walk c1f287cb19b9910af19756cf29c08b1fda75da8c
Some loose object were found to be corrupt, but they might be just
a false '404 Not Found' error message sent with incorrect HTTP
status code. Suggest running git fsck-objects.
got eab86de8ac23e2e77878835007724146fdd83796
$ git fsck-objects --unreachable --full --strict ;# returns no errors
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply [relevance 0%]
* Re: jgit performance update
@ 2006-12-03 23:39 6% ` Robin Rosenberg
2006-12-03 23:58 0% ` Jakub Narebski
2006-12-04 20:35 0% ` Juergen Stuber
0 siblings, 2 replies; 76+ results
From: Robin Rosenberg @ 2006-12-03 23:39 UTC (permalink / raw)
To: Juergen Stuber; +Cc: git, jnareb
söndag 03 december 2006 23:42 skrev Juergen Stuber:
> Hi Jakub,
>
> Jakub Narebski <jnareb@gmail.com> writes:
> > GitWiki tells us about egit/jgit repository at
> > http://www.spearce.org/projects/scm/egit.git
>
> I tried to access that with git 1.4.4.1 from Debian but
>
> % git clone http://www.spearce.org/projects/scm/egit.git
>
> hangs, the first time after "walk
> e339766abc2b919e7bb396cae22ddef065821381", the second time after "walk
> 9eec90ec5da239e063eaff6305d77294dc03396e" which is the "walk" line just
> before it.
Works fine here. (git 1.4.4.gf05d).
>
> There's also the following error shortly after the start:
>
> error: File bc01ab9e5fcd26918d7a334207183fa57ff1ce50
> (http://www.spearce.org/projects/scm/egit.git/objects/75/1c8f2e504c40d1c41e
>bbd87d8f8968529e9c30) corrupt
Unfortunately, messages about corrupt objects are "normal" with clone over
http. I'm not sure it has to be that way though. Run git-fsck-objects to make
sure there are no errors. The hangs aren't normal.
-- robin
^ permalink raw reply [relevance 6%]
* Re: git: how to produce context diffs?
2006-11-27 15:19 0% ` Sean
@ 2006-11-27 16:05 0% ` Jakub Narebski
0 siblings, 0 replies; 76+ results
From: Jakub Narebski @ 2006-11-27 16:05 UTC (permalink / raw)
To: Sean; +Cc: git
Sean wrote:
> On Mon, 27 Nov 2006 15:27:20 +0100
> Jakub Narebski <jnareb@gmail.com> wrote:
>
>> Bruno Haible wrote:
>>
>>> Is this a bug in git-diff? The git-diff-files.html says:
>>>
>>> " When the environment variable GIT_EXTERNAL_DIFF is not set ...
>>> For example, if you prefer context diff:
>>> GIT_DIFF_OPTS=-c git-diff-index -p HEAD "
>>>
>>> This doesn't work for me with git-1.4.4:
>>
>> Yes, the bug in documentation, I think. There is an option '-c' to git-diff,
>> but it means "combined diff" (for merges), not "context diff".
>
> Indeed. That documentation predates built-in diff completely.
>
> It appears the only valid options now are "-u XX" and "--unified=XX".
Which both mean the same.
> These options are never passed to diff, but rather used to control
> the internal diff. Strangely, it appears that gitk is even passing
> incorrect parameters via GIT_DIFF_OPTS.
Which, in convoluted way is said in documentation (the fact that
GIT_DIFF_OPTS affect internal diff).
> Unless i've really missed something, the above documentation should be
> reworked to remove mention of running diff altogether, and should mention
> that the GIT_DIFF_OPTS only has two valid settings.
For now.
--
Jakub Narebski
^ permalink raw reply [relevance 0%]
* Re: git: how to produce context diffs?
2006-11-27 14:27 0% ` Jakub Narebski
2006-11-27 15:19 0% ` Sean
@ 2006-11-27 15:38 0% ` Sean
1 sibling, 0 replies; 76+ results
From: Sean @ 2006-11-27 15:38 UTC (permalink / raw)
To: git; +Cc: Jakub Narebski
On Mon, 27 Nov 2006 15:27:20 +0100
Jakub Narebski <jnareb@gmail.com> wrote:
> Bruno Haible wrote:
>
> > Is this a bug in git-diff? The git-diff-files.html says:
> >
> > " When the environment variable GIT_EXTERNAL_DIFF is not set ...
> > For example, if you prefer context diff:
> > GIT_DIFF_OPTS=-c git-diff-index -p HEAD "
> >
> > This doesn't work for me with git-1.4.4:
>
> Yes, the bug in documentation, I think. There is an option '-c' to git-diff,
> but it means "combined diff" (for merges), not "context diff".
Indeed. That documentation predates built-in diff completely.
It appears the only valid options now are "-u XX" and "--unified=XX".
These options are never passed to diff, but rather used to control
the internal diff. Strangely, it appears that gitk is even passing
incorrect parameters via GIT_DIFF_OPTS.
Unless i've really missed something, the above documentation should be
reworked to remove mention of running diff altogether, and should mention
that the GIT_DIFF_OPTS only has two valid settings.
^ permalink raw reply [relevance 0%]
* Re: git: how to produce context diffs?
2006-11-27 14:27 0% ` Jakub Narebski
@ 2006-11-27 15:19 0% ` Sean
2006-11-27 16:05 0% ` Jakub Narebski
2006-11-27 15:38 0% ` Sean
1 sibling, 1 reply; 76+ results
From: Sean @ 2006-11-27 15:19 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
On Mon, 27 Nov 2006 15:27:20 +0100
Jakub Narebski <jnareb@gmail.com> wrote:
> Bruno Haible wrote:
>
> > Is this a bug in git-diff? The git-diff-files.html says:
> >
> > " When the environment variable GIT_EXTERNAL_DIFF is not set ...
> > For example, if you prefer context diff:
> > GIT_DIFF_OPTS=-c git-diff-index -p HEAD "
> >
> > This doesn't work for me with git-1.4.4:
>
> Yes, the bug in documentation, I think. There is an option '-c' to git-diff,
> but it means "combined diff" (for merges), not "context diff".
Indeed. That documentation predates built-in diff completely.
It appears the only valid options now are "-u XX" and "--unified=XX".
These options are never passed to diff, but rather used to control
the internal diff. Strangely, it appears that gitk is even passing
incorrect parameters via GIT_DIFF_OPTS.
Unless i've really missed something, the above documentation should be
reworked to remove mention of running diff altogether, and should mention
that the GIT_DIFF_OPTS only has two valid settings.
^ permalink raw reply [relevance 0%]
* Re: git: how to produce context diffs?
2006-11-27 14:16 5% git: how to produce context diffs? Bruno Haible
@ 2006-11-27 14:27 0% ` Jakub Narebski
2006-11-27 15:19 0% ` Sean
2006-11-27 15:38 0% ` Sean
0 siblings, 2 replies; 76+ results
From: Jakub Narebski @ 2006-11-27 14:27 UTC (permalink / raw)
To: git
Bruno Haible wrote:
> Is this a bug in git-diff? The git-diff-files.html says:
>
> " When the environment variable GIT_EXTERNAL_DIFF is not set ...
> For example, if you prefer context diff:
> GIT_DIFF_OPTS=-c git-diff-index -p HEAD "
>
> This doesn't work for me with git-1.4.4:
Yes, the bug in documentation, I think. There is an option '-c' to git-diff,
but it means "combined diff" (for merges), not "context diff".
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply [relevance 0%]
* git: how to produce context diffs?
@ 2006-11-27 14:16 5% Bruno Haible
2006-11-27 14:27 0% ` Jakub Narebski
0 siblings, 1 reply; 76+ results
From: Bruno Haible @ 2006-11-27 14:16 UTC (permalink / raw)
To: Junio C Hamano, git
Hi,
Is this a bug in git-diff? The git-diff-files.html says:
" When the environment variable GIT_EXTERNAL_DIFF is not set ...
For example, if you prefer context diff:
GIT_DIFF_OPTS=-c git-diff-index -p HEAD "
This doesn't work for me with git-1.4.4:
$ unset GIT_EXTERNAL_DIFF
$ export GIT_DIFF_OPTS=-c
$ git-diff-index -p HEAD
diff --git a/configure.ac b/configure.ac
index 74901dc..d222ded 100644
--- a/configure.ac
+++ b/configure.ac
@@ -1,5 +1,5 @@
dnl Process this file with autoconf to produce a configure script.
-AC_INIT(hello, 2.1.1, bug-gnu-hello@gnu.org)
+AC_INIT(hello, 2.1.2, bug-gnu-hello@gnu.org)
AC_CONFIG_SRCDIR([src/hello.c])
AC_PREREQ(2.52)
Expected output:
$ git-diff-index -p HEAD
index 74901dc..d222ded 100644
diff --git a/configure.ac b/configure.ac
*** a/configure.ac
--- b/configure.ac
***************
*** 1,5 ****
dnl Process this file with autoconf to produce a configure script.
! AC_INIT(hello, 2.1.1, bug-gnu-hello@gnu.org)
AC_CONFIG_SRCDIR([src/hello.c])
AC_PREREQ(2.52)
--- 1,5 ----
dnl Process this file with autoconf to produce a configure script.
! AC_INIT(hello, 2.1.2, bug-gnu-hello@gnu.org)
AC_CONFIG_SRCDIR([src/hello.c])
AC_PREREQ(2.52)
(Really, while I find -u diffs fine for tiny changes, I find them unreadable
for rewrites of larger blocks, and cannot live without -c for these.)
When I look at diff.c around
const char *diffopts = getenv("GIT_DIFF_OPTS");
it appears that only unified diffs are supported??
^ permalink raw reply related [relevance 5%]
* Re: git crash when cg-fetch:ing dash
2006-11-23 15:54 6% ` Horst H. von Brand
@ 2006-11-23 16:18 0% ` Sean
0 siblings, 0 replies; 76+ results
From: Sean @ 2006-11-23 16:18 UTC (permalink / raw)
To: Horst H. von Brand; +Cc: René Scharfe, git
On Thu, 23 Nov 2006 12:54:57 -0300
"Horst H. von Brand" <vonbrand@inf.utfsm.cl> wrote:
> René Scharfe <rene.scharfe@lsrfire.ath.cx> wrote:
> > Horst H. von Brand schrieb:
> > > I did:
> > > git clone http://gondor.apana.org.au/~herbert/dash/dash.git
> > > and got:
> > > error: Unable to start request
> > > error: Could not interpret heads/master as something to pull
> >
> > It works for me with both the version of git that came with Ubuntu 6.10
> > (1.4.1) and a self-compiled git 1.4.4.g5942. :-?
>
> Here it's git-1.4.4 (self-built from Junio's SRPM, on Fedora rawhide i686).
Works fine here with 1.4.3.3.g869c.
Horst, this is the second recent example of something not working in your
environment that works for others. Is it possible you have an old stray
version of git installed in your ~/bin or something? By the way, did you
ever resolve that other issue?
^ permalink raw reply [relevance 0%]
* Re: git crash when cg-fetch:ing dash
2006-11-23 9:34 6% ` René Scharfe
@ 2006-11-23 15:54 6% ` Horst H. von Brand
2006-11-23 16:18 0% ` Sean
0 siblings, 1 reply; 76+ results
From: Horst H. von Brand @ 2006-11-23 15:54 UTC (permalink / raw)
To: René Scharfe; +Cc: Horst H. von Brand, git
René Scharfe <rene.scharfe@lsrfire.ath.cx> wrote:
> Horst H. von Brand schrieb:
> > I did:
> > git clone http://gondor.apana.org.au/~herbert/dash/dash.git
> > and got:
> > error: Unable to start request
> > error: Could not interpret heads/master as something to pull
>
> It works for me with both the version of git that came with Ubuntu 6.10
> (1.4.1) and a self-compiled git 1.4.4.g5942. :-?
Here it's git-1.4.4 (self-built from Junio's SRPM, on Fedora rawhide i686).
--
Dr. Horst H. von Brand User #22616 counter.li.org
Departamento de Informatica Fono: +56 32 2654431
Universidad Tecnica Federico Santa Maria +56 32 2654239
^ permalink raw reply [relevance 6%]
* Re: git crash when cg-fetch:ing dash
@ 2006-11-23 9:34 6% ` René Scharfe
2006-11-23 15:54 6% ` Horst H. von Brand
0 siblings, 1 reply; 76+ results
From: René Scharfe @ 2006-11-23 9:34 UTC (permalink / raw)
To: Horst H. von Brand; +Cc: git
Horst H. von Brand schrieb:
> I did:
>
> git clone http://gondor.apana.org.au/~herbert/dash/dash.git
>
> and got:
>
> error: Unable to start request
> error: Could not interpret heads/master as something to pull
It works for me with both the version of git that came with Ubuntu 6.10
(1.4.1) and a self-compiled git 1.4.4.g5942. :-?
^ permalink raw reply [relevance 6%]
* Re: [PATCH] gitweb: make HTML links out of http/https URLs in changelogs
2006-11-22 9:00 0% ` Kir Kolyshkin
@ 2006-11-22 20:56 0% ` Petr Baudis
0 siblings, 0 replies; 76+ results
From: Petr Baudis @ 2006-11-22 20:56 UTC (permalink / raw)
To: Kir Kolyshkin; +Cc: git
On Wed, Nov 22, 2006 at 10:00:05AM CET, Kir Kolyshkin wrote:
> Petr Baudis wrote:
> >On Tue, Nov 21, 2006 at 11:02:36PM CET, Kir Kolyshkin wrote:
> >
> >>Slightly tested on http://git.openvz.org/. Applicable to git-1.4.4.
> >>
> >
> >...but in git's gitweb view it will make this <a
> >href="http://git.openvz.org/.">http://git.openvz.org/.</a>. :-)
> Not a problem actually since "." means "current directory", so it will
> work fine (and I have checked that) :)
> Sure there is a room for improvement for this regex -- and I am
> collecting those.
But "http://git.openvz.org/index.html." might not work so fine, nor
"http://git.openvz.org/,"...
Bad URLs matchers which don't snip unlikely (!= invalid!) characters
from the end of the URL are my pet peeve. ;-)
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
The meaning of Stonehenge in Traflamadorian, when viewed from above, is:
"Replacement part being rushed with all possible speed."
^ permalink raw reply [relevance 0%]
* Re: [PATCH] gitweb: make HTML links out of http/https URLs in changelogs
2006-11-22 0:06 0% ` Petr Baudis
@ 2006-11-22 9:00 0% ` Kir Kolyshkin
2006-11-22 20:56 0% ` Petr Baudis
0 siblings, 1 reply; 76+ results
From: Kir Kolyshkin @ 2006-11-22 9:00 UTC (permalink / raw)
To: Petr Baudis; +Cc: git
Petr Baudis wrote:
> On Tue, Nov 21, 2006 at 11:02:36PM CET, Kir Kolyshkin wrote:
>
>> Slightly tested on http://git.openvz.org/. Applicable to git-1.4.4.
>>
>
> ...but in git's gitweb view it will make this <a
> href="http://git.openvz.org/.">http://git.openvz.org/.</a>. :-)
Not a problem actually since "." means "current directory", so it will
work fine (and I have checked that) :)
Sure there is a room for improvement for this regex -- and I am
collecting those.
^ permalink raw reply [relevance 0%]
* Re: [PATCH] gitweb: make HTML links out of http/https URLs in changelogs
2006-11-21 22:02 6% [PATCH] gitweb: make HTML links out of http/https URLs in changelogs Kir Kolyshkin
2006-11-21 22:28 0% ` Jakub Narebski
@ 2006-11-22 0:06 0% ` Petr Baudis
2006-11-22 9:00 0% ` Kir Kolyshkin
1 sibling, 1 reply; 76+ results
From: Petr Baudis @ 2006-11-22 0:06 UTC (permalink / raw)
To: Kir Kolyshkin; +Cc: git
On Tue, Nov 21, 2006 at 11:02:36PM CET, Kir Kolyshkin wrote:
> Slightly tested on http://git.openvz.org/. Applicable to git-1.4.4.
...but in git's gitweb view it will make this <a
href="http://git.openvz.org/.">http://git.openvz.org/.</a>. :-)
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
The meaning of Stonehenge in Traflamadorian, when viewed from above, is:
"Replacement part being rushed with all possible speed."
^ permalink raw reply [relevance 0%]
* Re: [PATCH] gitweb: make HTML links out of http/https URLs in changelogs
2006-11-21 22:02 6% [PATCH] gitweb: make HTML links out of http/https URLs in changelogs Kir Kolyshkin
@ 2006-11-21 22:28 0% ` Jakub Narebski
2006-11-22 0:06 0% ` Petr Baudis
1 sibling, 0 replies; 76+ results
From: Jakub Narebski @ 2006-11-21 22:28 UTC (permalink / raw)
To: git
Kir Kolyshkin wrote:
> It is a common practice to put links to bugzillas, mailing lists, etc.
> in git log entries. The fact that gitweb doesn't make HTML links out of
> that URLs makes following those URLs inconvenient. This patch fixes that
> problem, trying to address cases when URL is enclosed in round or square
> brackets.
Preliminary committags support was sent as an RFC patch on git mailing list
once. Hyperlinking plain text http, https, ftp, ftps links etc. is a special
case of committag. That wha is implemented now, namely hyperlinking
commitsha to commit view is also special case of comittag.
And I plan to implement it, only later. But you are welcome to do it
instead.
gitweb-xmms2 http://git.xmms.se/?p=gitweb-xmms2.git has xmms2 related
committags support (links to xmms2 Mantis bugtracker from BUG(n) and
FEATURE(n))
> Slightly tested on http://git.openvz.org/. Applicable to git-1.4.4.
>
> Signed-off-by: Kir Kolyshkin <kir@openvz.org>
> ---
> gitweb/gitweb.perl | 2 ++
> 1 file changed, 2 insertions(+)
>
> --- git-1.4.4/gitweb/gitweb.perl 2006-11-15 08:22:27.000000000 +0100
> +++ git-1.4.4-my/gitweb/gitweb.perl 2006-11-21 22:49:14.000000000 +0100
> @@ -828,6 +828,8 @@
Could you please send patches created by git tools, namely git-format-patch,
or if you really need to send GNU diff patches, use -p option? It really
helps in patch review.
> $line =~ s/$hash_text/$link/;
> }
> }
> + # make HTML links out of http(s) URLs
> + $line =~ s/(http[s]?:\/\/[^[:space:]\]\)]+)/<a href="\1">\1<\/a>/g;
> return $line;
> }
Wont work correctly if commit message has sha1 of commit in it; it would be
changed to
<a href="$my_uri?p=$project;a=commit;h=$hash_text" class="text">$hash_text</a>
then the code you added will add hyperlink in place of href value (!).
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply [relevance 0%]
* [PATCH] gitweb: make HTML links out of http/https URLs in changelogs
@ 2006-11-21 22:02 6% Kir Kolyshkin
2006-11-21 22:28 0% ` Jakub Narebski
2006-11-22 0:06 0% ` Petr Baudis
0 siblings, 2 replies; 76+ results
From: Kir Kolyshkin @ 2006-11-21 22:02 UTC (permalink / raw)
To: git
It is a common practice to put links to bugzillas, mailing lists, etc.
in git log entries. The fact that gitweb doesn't make HTML links out of
that URLs makes following those URLs inconvenient. This patch fixes that
problem, trying to address cases when URL is enclosed in round or square
brackets.
Slightly tested on http://git.openvz.org/. Applicable to git-1.4.4.
Signed-off-by: Kir Kolyshkin <kir@openvz.org>
---
gitweb/gitweb.perl | 2 ++
1 file changed, 2 insertions(+)
--- git-1.4.4/gitweb/gitweb.perl 2006-11-15 08:22:27.000000000 +0100
+++ git-1.4.4-my/gitweb/gitweb.perl 2006-11-21 22:49:14.000000000 +0100
@@ -828,6 +828,8 @@
$line =~ s/$hash_text/$link/;
}
}
+ # make HTML links out of http(s) URLs
+ $line =~ s/(http[s]?:\/\/[^[:space:]\]\)]+)/<a href="\1">\1<\/a>/g;
return $line;
}
^ permalink raw reply [relevance 6%]
* static linking lib order problem
@ 2006-11-20 17:32 7% Bennett Todd
0 siblings, 0 replies; 76+ results
From: Bennett Todd @ 2006-11-20 17:32 UTC (permalink / raw)
To: git
[-- Attachment #1: Type: text/plain, Size: 1761 bytes --]
I build git for Bent Linux, with
make prefix=/usr NEEDS_LIBICONV=YesPlease
It develops compile and link lines that look like:
gcc -g -O2 -Wall -DSHA1_HEADER='<openssl/sha.h>' -DNO_STRLCPY -o git-http-fetch fetch.o http.o http-fetch.o \
libgit.a xdiff/lib.a -lz -liconv -lcrypto -lcurl -lexpat
which produce vast numbers of errors, which look like
/usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.1/../../../libcurl.a(ssluse.o)(.text.rand_enough+0x4): In function `rand_enough':
: undefined reference to `RAND_status'
/usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.1/../../../libcurl.a(ssluse.o)(.text.ossl_seed+0x2b): In function `ossl_seed':
: undefined reference to `RAND_load_file'
[...]
/usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.1/../../../libcurl.a(http_ntlm.o)(.text.Curl_output_ntlm+0x370): In function `Curl_output_ntlm':
: undefined reference to `MD5_Update'
/usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.1/../../../libcurl.a(http_ntlm.o)(.text.Curl_output_ntlm+0x37d): In function `Curl_output_ntlm':
: undefined reference to `MD5_Final'
collect2: ld returned 1 exit status
make: *** [git-http-fetch] Error 1
I've been kludging around it with this patch:
diff -ru git-1.4.4.orig/Makefile git-1.4.4/Makefile
--- git-1.4.4.orig/Makefile 2006-11-15 07:22:27.000000000 +0000
+++ git-1.4.4/Makefile 2006-11-15 20:49:26.000000000 +0000
@@ -439,7 +439,7 @@
BASIC_CFLAGS += -I$(CURLDIR)/include
CURL_LIBCURL = -L$(CURLDIR)/lib -R$(CURLDIR)/lib -lcurl
else
- CURL_LIBCURL = -lcurl
+ CURL_LIBCURL = -lcurl -lssl -lcrypto
endif
PROGRAMS += git-http-fetch$X
curl_check := $(shell (echo 070908; curl-config --vernum) | sort -r | sed -ne 2p)
just because I didn't take the time to understand the git build
process's library conf system.
-Bennett
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply [relevance 7%]
* Re: git-svn bug?
2006-11-15 22:55 0% ` Troy Telford
@ 2006-11-17 8:55 0% ` Eric Wong
0 siblings, 0 replies; 76+ results
From: Eric Wong @ 2006-11-17 8:55 UTC (permalink / raw)
To: Troy Telford; +Cc: Junio C Hamano, git
Sorry for the late replies, I've been caught up with other things.
Troy Telford <ttelford.groups@gmail.com> wrote:
> On Wed, 15 Nov 2006 14:43:30 -0700, Junio C Hamano <junkio@cox.net> wrote:
>
> >"Troy Telford" <ttelford.groups@gmail.com> writes:
> >
> >>(using git 1.4.4, svn 1.3.1 on a SLES 10 box)
> >>fatal: Not a valid object name
> >>92e2e0c50bbbacb0a3426b2c0f8b3e043eb4830a~1
> >>32768 at /usr/lib/perl5/5.8.8/Memoize.pm line 269
> >>...
> >>I couldn't find an object named
> >>"92e2e0c50bbbacb0a3426b2c0f8b3e043eb4830a~1" in .git/
> >
> >Troy, do you have object 92e2e0c5? Is it a root commit (i.e. a
> >commit that does not have a parent)?
dcommit expects to be run on a git-svn fetch-ed HEAD that is linear
superset of remotes/git-svn. That is: remotes/git-svn..HEAD should
(ideally) contain no merges, and no root commits. git-svn currently
does no checking for root commits, but it should.
> I'll have to admit I'm stabbing in the dark on how to get the correct
> answer this, but here goes:
>
> * `git cat-file -t 92e2e0...` returns 'commit'
> * 'git cat-file -p 92e2e0...` returns: (minus the header/footer asterisks)
> *********************************************
> tree 4b825dc642cb6eb9a060e54bf8d69288fbee4904
> author unknown <unknown> 961088898 +0000
> committer unknown <unknown> 961088898 +0000
>
> New repository initialized by cvs2svn.
> *********************************************
This commit is missing the git-svn-id: line at the bottom. If you
simply left it out (private svn repository info), can you check that the
URL in this line is actually for the SVN repository you want to commit
to?
It seems like your usage of dcommit would actually cause the issue
you're experiencing to be triggered on the dummy repository, and not the
real one. My other guess would be that you somehow merged commits from
your dummy svn repo into your master branch.
--
^ permalink raw reply [relevance 0%]
* Re: how to authenticate with git-svn on a subversion repository
@ 2006-11-15 23:39 6% ` Sam Vilain
0 siblings, 0 replies; 76+ results
From: Sam Vilain @ 2006-11-15 23:39 UTC (permalink / raw)
To: Comète; +Cc: Git Mailing List
Comète wrote:
> hello !
>
> i would like to use git-svn to commit some modifications to a Subversion
> repository but i don't know where i can enter my username and password
> to commit to the repository ? Is there any special file to put them.
> For now i get an error:
>
> # git-svn commit remotes/git-svn
> Autorisation refusée: MKACTIVITY de
> '/svn/!svn/act/8115f5df-c0da-4a6d-91ef-135dcb76141c': Échec à
> l'autorisation (http://projet.archlinuxfr.org) at /usr/bin/git-svn line 553
> 512 at /usr/bin/git-svn line 574
> main::commit_lib('f45ba41060287fedfcedfb5fc4c29ecfe30a7466') called at
> /usr/bin/git-svn line 480
> main::commit('remotes/git-svn') called at /usr/bin/git-svn line 172
>
Two questions;
- have you tried this with Git 1.4.4? There have been some git-svn updates
- which version of the SVN Perl bindings are you using?
^ permalink raw reply [relevance 6%]
* Re: git-svn bug?
2006-11-15 21:43 0% ` Junio C Hamano
@ 2006-11-15 22:55 0% ` Troy Telford
2006-11-17 8:55 0% ` Eric Wong
0 siblings, 1 reply; 76+ results
From: Troy Telford @ 2006-11-15 22:55 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Eric Wong
On Wed, 15 Nov 2006 14:43:30 -0700, Junio C Hamano <junkio@cox.net> wrote:
> "Troy Telford" <ttelford.groups@gmail.com> writes:
>
>> (using git 1.4.4, svn 1.3.1 on a SLES 10 box)
>> fatal: Not a valid object name
>> 92e2e0c50bbbacb0a3426b2c0f8b3e043eb4830a~1
>> 32768 at /usr/lib/perl5/5.8.8/Memoize.pm line 269
>> ...
>> I couldn't find an object named
>> "92e2e0c50bbbacb0a3426b2c0f8b3e043eb4830a~1" in .git/
>
> Troy, do you have object 92e2e0c5? Is it a root commit (i.e. a
> commit that does not have a parent)?
I'll have to admit I'm stabbing in the dark on how to get the correct
answer this, but here goes:
* `git cat-file -t 92e2e0...` returns 'commit'
* 'git cat-file -p 92e2e0...` returns: (minus the header/footer asterisks)
*********************************************
tree 4b825dc642cb6eb9a060e54bf8d69288fbee4904
author unknown <unknown> 961088898 +0000
committer unknown <unknown> 961088898 +0000
New repository initialized by cvs2svn.
*********************************************
--
^ permalink raw reply [relevance 0%]
* Re: git-svn bug?
2006-11-15 21:05 7% git-svn bug? Troy Telford
@ 2006-11-15 21:43 0% ` Junio C Hamano
2006-11-15 22:55 0% ` Troy Telford
0 siblings, 1 reply; 76+ results
From: Junio C Hamano @ 2006-11-15 21:43 UTC (permalink / raw)
To: Troy Telford; +Cc: git, Eric Wong
"Troy Telford" <ttelford.groups@gmail.com> writes:
> (using git 1.4.4, svn 1.3.1 on a SLES 10 box)
> fatal: Not a valid object name 92e2e0c50bbbacb0a3426b2c0f8b3e043eb4830a~1
> 32768 at /usr/lib/perl5/5.8.8/Memoize.pm line 269
>...
> I couldn't find an object named
> "92e2e0c50bbbacb0a3426b2c0f8b3e043eb4830a~1" in .git/
Troy, do you have object 92e2e0c5? Is it a root commit (i.e. a
commit that does not have a parent)?
The only place that mentions ~1 in git-svn seems to be inside
dcommit but it seems that it unconditionally appends ~1 to the
rev. I do not know how the code guarantees it does not go down
to the root commit.
Eric, any clues?
^ permalink raw reply [relevance 0%]
* git-svn bug?
@ 2006-11-15 21:05 7% Troy Telford
2006-11-15 21:43 0% ` Junio C Hamano
0 siblings, 1 reply; 76+ results
From: Troy Telford @ 2006-11-15 21:05 UTC (permalink / raw)
To: git@vger.kernel.org
I've got a repository I've converted over to git from svn. (using
git-svn. since there's only been one branch, I figured I could skip
git-svnimport).
For quite a while, all I did was fetch/rebase from the svn repository to
my git repository; all of my own work was committed to the git repository;
none of the changes were commited to the svn repository.
Then came the time to commit changes from my git repository to the svn
repository.
Being somewhat cautious, I created an empty 'dummy' svn repository and
familiarize myself with using git-svn to commit from git -> svn.
I ran:
git-svn fetch
git-svn rebase remotes/git-svn (already updated)
git-svn dcommit (to push my changes to the svn repository)
Everything seemed to work fine with the dummy repository.
Encouraged, I did the same with the 'real' repository, and received the
following error:
(Using git 1.4.3.5, svn 1.4.0 on a Gentoo box)
fatal: Not a valid object name 92e2e0c50bbbacb0a3426b2c0f8b3e043eb4830a~1
32768 at /usr/lib64/perl5/5.8.8/Memoize.pm line 269
(using git 1.4.4, svn 1.3.0 on a SLES 9 SP3 box)
fatal: Not a valid object name 92e2e0c50bbbacb0a3426b2c0f8b3e043eb4830a~1
32768 at /usr/lib/perl5/5.8.3/Memoize.pm line 269
(using git 1.4.4, svn 1.3.1 on a SLES 10 box)
fatal: Not a valid object name 92e2e0c50bbbacb0a3426b2c0f8b3e043eb4830a~1
32768 at /usr/lib/perl5/5.8.8/Memoize.pm line 269
I had NFS mounted the git repository, so the SLES 9 was local the other
two were NFS. In any event, the error seems to be essentially identical
on every platform I've tried.
Additionally, I had created three branches for the purpose of pushing my
changes to svn:
master (used for my own development)
svn (created using git checkout -b svn remotes/git-svn -- basically only
what is in svn)
merge (git checkout -b merge svn; git rebase master)
`git diff-tree merge master | wc -l` returns 0 (which I assume means no
changes)
`git diff-tree svn merge | wc -l` returns 44 (again, I assume this means
44 changes)
I couldn't find an object named
"92e2e0c50bbbacb0a3426b2c0f8b3e043eb4830a~1" in .git/
Aside from my cluelessness, is there anything else wrong?
--
^ permalink raw reply [relevance 7%]
* RE: [GIT PATCH] Makefile missing git-runstatus in PROGRAMS list
@ 2006-11-15 18:08 8% Bhavesh Davda
0 siblings, 0 replies; 76+ results
From: Bhavesh Davda @ 2006-11-15 18:08 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
[-- Attachment #1: Type: text/plain, Size: 1519 bytes --]
> Interesting. You do not seem to have not just git-runstatus but
> anything built-in. The last action in "make install" should
> look like this log entry (I just did "make prefix=/var/tmp/ggg
> clean all install"):
>
> rm -f '/var/tmp/ggg/bin/git-format-patch' && ln
> '/var/tmp/ggg/bin/git' '/var/tmp/ggg/bin/git-format-patch' ;
> rm -f '/var/tmp/ggg/bin/git-show' && ln
> '/var/tmp/ggg/bin/git' '/var/tmp/ggg/bin/git-show' ; ... rm
> -f '/var/tmp/ggg/bin/git-verify-pack' && ln
> '/var/tmp/ggg/bin/git' '/var/tmp/ggg/bin/git-verify-pack' ;
> rm -f '/var/tmp/ggg/bin/git-write-tree' && ln
> '/var/tmp/ggg/bin/git' '/var/tmp/ggg/bin/git-write-tree' ;
>
> that installs 47 hardlinks to $(prefix)/bin/git.
Attached is my attempt at the same command "make prefix=/var/tmp/ggg clean
all install"
make install failes for the templates directory, leading to the entire make
install failing:
make -C templates DESTDIR='' install
make[1]: Entering directory `/VMware/kernel/git/git/templates'
: no custom templates yet
install -d -m755 '/var/tmp/ggg/share/git-core/templates/'
(cd blt && tar cf - .) | \
(cd '/var/tmp/ggg/share/git-core/templates/' && tar xf -)
tar: This does not look like a tar archive
tar: Skipping to next header
tar: Archive contains obsolescent base-64 headers
tar: Error exit delayed from previous errors
make[1]: *** [install] Error 2
make[1]: Leaving directory `/VMware/kernel/git/git/templates'
make: *** [install] Error 2
Thanks
- Bhavesh
[-- Attachment #2: ggg-bpd.log --]
[-- Type: application/octet-stream, Size: 44849 bytes --]
GIT_VERSION = 1.4.4-rc2.GIT
rm -f *.o mozilla-sha1/*.o arm/*.o ppc/*.o compat/*.o xdiff/*.o \
libgit.a xdiff/lib.a
rm -f git-convert-objects git-fetch-pack git-fsck-objects git-hash-object git-index-pack git-local-fetch git-merge-base git-daemon git-merge-index git-mktag git-mktree git-patch-id git-peek-remote git-receive-pack git-send-pack git-shell git-show-index git-ssh-fetch git-ssh-upload git-unpack-file git-update-server-info git-upload-pack git-verify-pack git-pack-redundant git-var git-describe git-merge-tree git-imap-send git-merge-recursive git-ssh-pull git-ssh-push git-http-fetch git-http-push git-bisect git-checkout git-clean git-clone git-commit git-fetch git-ls-remote git-merge-one-file git-parse-remote git-pull git-rebase git-repack git-request-pull git-reset git-resolve git-revert git-sh-setup git-tag git-verify-tag git-applymbox git-applypatch git-am git-merge git-merge-stupid git-merge-octopus git-merge-resolve git-merge-ours git-lost-found git-quiltimport git-archimport git-cvsimport git-relink git-shortlog git-rerere git-cvsserver git-svnimport git-cvsexportcommit git-send-email git-svn git-merge-recursive-old git-cherry-pick git-status git-instaweb git-merge-recur git-format-patch git-show git-whatchanged git-cherry git-get-tar-commit-id git-add git-annotate git-apply git-archive git-blame git-branch git-cat-file git-checkout-index git-check-ref-format git-commit-tree git-count-objects git-diff git-diff-files git-diff-index git-diff-stages git-diff-tree git-fmt-merge-msg git-for-each-ref git-grep git-init-db git-log git-ls-files git-ls-tree git-mailinfo git-mailsplit git-mv git-name-rev git-pack-objects git-prune git-prune-packed git-push git-read-tree git-repo-config git-rev-list git-rev-parse git-rm git-runstatus git-show-branch git-stripspace git-symbolic-ref git-tar-tree git-unpack-objects git-update-index git-update-ref git-upload-archive git-verify-pack git-write-tree git-show-ref git-pack-refs git
rm -f *.spec *.pyc *.pyo */*.pyc */*.pyo common-cmds.h TAGS tags
rm -rf autom4te.cache
rm -f configure config.log config.mak.autogen config.mak.append config.status config.cache
rm -rf git-1.4.4-rc2.GIT .doc-tmp-dir
rm -f git-1.4.4-rc2.GIT.tar.gz git-core_1.4.4-rc2.GIT-*.tar.gz
rm -f git-htmldocs-1.4.4-rc2.GIT.tar.gz git-manpages-1.4.4-rc2.GIT.tar.gz
rm -f gitweb/gitweb.cgi
make -C Documentation/ clean
make[1]: Entering directory `/VMware/kernel/git/git/Documentation'
rm -f doc.dep+ doc.dep
perl ./build-docdep.perl >doc.dep+
mv doc.dep+ doc.dep
make[1]: Leaving directory `/VMware/kernel/git/git/Documentation'
make[1]: Entering directory `/VMware/kernel/git/git/Documentation'
rm -f *.xml *.html *.1 *.7 howto-index.txt howto/*.html doc.dep README
make[1]: Leaving directory `/VMware/kernel/git/git/Documentation'
[ ! -f perl/Makefile ] || make -C perl/ clean || make -C perl/ clean
rm -f perl/ppport.h perl/Makefile.old
make -C templates/ clean
make[1]: Entering directory `/VMware/kernel/git/git/templates'
rm -rf blt boilerplates.made
make[1]: Leaving directory `/VMware/kernel/git/git/templates'
make -C t/ clean
make[1]: Entering directory `/VMware/kernel/git/git/t'
rm -fr trash
make[1]: Leaving directory `/VMware/kernel/git/git/t'
rm -f GIT-VERSION-FILE GIT-CFLAGS
* new build flags or prefix
(cd perl && /usr/bin/perl Makefile.PL \
PREFIX='/var/tmp/ggg')
/VMware/kernel/git/git/perl
Writing Makefile for Git
gcc -o convert-objects.o -c -g -O2 -Wall -DSHA1_HEADER='<openssl/sha.h>' -DNO_STRLCPY convert-objects.c
gcc -o blob.o -c -g -O2 -Wall -DSHA1_HEADER='<openssl/sha.h>' -DNO_STRLCPY blob.c
gcc -o commit.o -c -g -O2 -Wall -DSHA1_HEADER='<openssl/sha.h>' -DNO_STRLCPY commit.c
gcc -o connect.o -c -g -O2 -Wall -DSHA1_HEADER='<openssl/sha.h>' -DNO_STRLCPY connect.c
gcc -o csum-file.o -c -g -O2 -Wall -DSHA1_HEADER='<openssl/sha.h>' -DNO_STRLCPY csum-file.c
gcc -o cache-tree.o -c -g -O2 -Wall -DSHA1_HEADER='<openssl/sha.h>' -DNO_STRLCPY cache-tree.c
gcc -o base85.o -c -g -O2 -Wall -DSHA1_HEADER='<openssl/sha.h>' -DNO_STRLCPY base85.c
gcc -o date.o -c -g -O2 -Wall -DSHA1_HEADER='<openssl/sha.h>' -DNO_STRLCPY date.c
gcc -o diff-delta.o -c -g -O2 -Wall -DSHA1_HEADER='<openssl/sha.h>' -DNO_STRLCPY diff-delta.c
gcc -o entry.o -c -g -O2 -Wall -DSHA1_HEADER='<openssl/sha.h>' -DNO_STRLCPY entry.c
gcc -o exec_cmd.o -c -g -O2 -Wall -DSHA1_HEADER='<openssl/sha.h>' -DNO_STRLCPY '-DGIT_EXEC_PATH="/var/tmp/ggg/bin"' exec_cmd.c
gcc -o ident.o -c -g -O2 -Wall -DSHA1_HEADER='<openssl/sha.h>' -DNO_STRLCPY ident.c
gcc -o interpolate.o -c -g -O2 -Wall -DSHA1_HEADER='<openssl/sha.h>' -DNO_STRLCPY interpolate.c
gcc -o lockfile.o -c -g -O2 -Wall -DSHA1_HEADER='<openssl/sha.h>' -DNO_STRLCPY lockfile.c
gcc -o object.o -c -g -O2 -Wall -DSHA1_HEADER='<openssl/sha.h>' -DNO_STRLCPY object.c
gcc -o pack-check.o -c -g -O2 -Wall -DSHA1_HEADER='<openssl/sha.h>' -DNO_STRLCPY pack-check.c
gcc -o patch-delta.o -c -g -O2 -Wall -DSHA1_HEADER='<openssl/sha.h>' -DNO_STRLCPY patch-delta.c
gcc -o path.o -c -g -O2 -Wall -DSHA1_HEADER='<openssl/sha.h>' -DNO_STRLCPY path.c
gcc -o pkt-line.o -c -g -O2 -Wall -DSHA1_HEADER='<openssl/sha.h>' -DNO_STRLCPY pkt-line.c
gcc -o sideband.o -c -g -O2 -Wall -DSHA1_HEADER='<openssl/sha.h>' -DNO_STRLCPY sideband.c
gcc -o quote.o -c -g -O2 -Wall -DSHA1_HEADER='<openssl/sha.h>' -DNO_STRLCPY quote.c
gcc -o read-cache.o -c -g -O2 -Wall -DSHA1_HEADER='<openssl/sha.h>' -DNO_STRLCPY read-cache.c
gcc -o refs.o -c -g -O2 -Wall -DSHA1_HEADER='<openssl/sha.h>' -DNO_STRLCPY refs.c
gcc -o run-command.o -c -g -O2 -Wall -DSHA1_HEADER='<openssl/sha.h>' -DNO_STRLCPY run-command.c
gcc -o dir.o -c -g -O2 -Wall -DSHA1_HEADER='<openssl/sha.h>' -DNO_STRLCPY dir.c
gcc -o object-refs.o -c -g -O2 -Wall -DSHA1_HEADER='<openssl/sha.h>' -DNO_STRLCPY object-refs.c
gcc -o server-info.o -c -g -O2 -Wall -DSHA1_HEADER='<openssl/sha.h>' -DNO_STRLCPY server-info.c
gcc -o setup.o -c -g -O2 -Wall -DSHA1_HEADER='<openssl/sha.h>' -DNO_STRLCPY setup.c
gcc -o sha1_file.o -c -g -O2 -Wall -DSHA1_HEADER='<openssl/sha.h>' -DNO_STRLCPY sha1_file.c
gcc -o sha1_name.o -c -g -O2 -Wall -DSHA1_HEADER='<openssl/sha.h>' -DNO_STRLCPY sha1_name.c
gcc -o strbuf.o -c -g -O2 -Wall -DSHA1_HEADER='<openssl/sha.h>' -DNO_STRLCPY strbuf.c
gcc -o tag.o -c -g -O2 -Wall -DSHA1_HEADER='<openssl/sha.h>' -DNO_STRLCPY tag.c
gcc -o tree.o -c -g -O2 -Wall -DSHA1_HEADER='<openssl/sha.h>' -DNO_STRLCPY tree.c
gcc -o usage.o -c -g -O2 -Wall -DSHA1_HEADER='<openssl/sha.h>' -DNO_STRLCPY usage.c
gcc -o config.o -c -g -O2 -Wall -DSHA1_HEADER='<openssl/sha.h>' -DNO_STRLCPY config.c
gcc -o environment.o -c -g -O2 -Wall -DSHA1_HEADER='<openssl/sha.h>' -DNO_STRLCPY environment.c
gcc -o ctype.o -c -g -O2 -Wall -DSHA1_HEADER='<openssl/sha.h>' -DNO_STRLCPY ctype.c
gcc -o copy.o -c -g -O2 -Wall -DSHA1_HEADER='<openssl/sha.h>' -DNO_STRLCPY copy.c
gcc -o revision.o -c -g -O2 -Wall -DSHA1_HEADER='<openssl/sha.h>' -DNO_STRLCPY revision.c
gcc -o pager.o -c -g -O2 -Wall -DSHA1_HEADER='<openssl/sha.h>' -DNO_STRLCPY pager.c
gcc -o tree-walk.o -c -g -O2 -Wall -DSHA1_HEADER='<openssl/sha.h>' -DNO_STRLCPY tree-walk.c
gcc -o xdiff-interface.o -c -g -O2 -Wall -DSHA1_HEADER='<openssl/sha.h>' -DNO_STRLCPY xdiff-interface.c
gcc -o write_or_die.o -c -g -O2 -Wall -DSHA1_HEADER='<openssl/sha.h>' -DNO_STRLCPY write_or_die.c
gcc -o trace.o -c -g -O2 -Wall -DSHA1_HEADER='<openssl/sha.h>' -DNO_STRLCPY trace.c
gcc -o list-objects.o -c -g -O2 -Wall -DSHA1_HEADER='<openssl/sha.h>' -DNO_STRLCPY list-objects.c
gcc -o grep.o -c -g -O2 -Wall -DSHA1_HEADER='<openssl/sha.h>' -DNO_STRLCPY grep.c
gcc -o alloc.o -c -g -O2 -Wall -DSHA1_HEADER='<openssl/sha.h>' -DNO_STRLCPY alloc.c
gcc -o merge-file.o -c -g -O2 -Wall -DSHA1_HEADER='<openssl/sha.h>' -DNO_STRLCPY merge-file.c
gcc -o path-list.o -c -g -O2 -Wall -DSHA1_HEADER='<openssl/sha.h>' -DNO_STRLCPY path-list.c
./generate-cmdlist.sh > common-cmds.h+
mv common-cmds.h+ common-cmds.h
gcc -o help.o -c -g -O2 -Wall -DSHA1_HEADER='<openssl/sha.h>' -DNO_STRLCPY help.c
gcc -o unpack-trees.o -c -g -O2 -Wall -DSHA1_HEADER='<openssl/sha.h>' -DNO_STRLCPY unpack-trees.c
gcc -o diff.o -c -g -O2 -Wall -DSHA1_HEADER='<openssl/sha.h>' -DNO_STRLCPY diff.c
gcc -o diff-lib.o -c -g -O2 -Wall -DSHA1_HEADER='<openssl/sha.h>' -DNO_STRLCPY diff-lib.c
gcc -o diffcore-break.o -c -g -O2 -Wall -DSHA1_HEADER='<openssl/sha.h>' -DNO_STRLCPY diffcore-break.c
gcc -o diffcore-order.o -c -g -O2 -Wall -DSHA1_HEADER='<openssl/sha.h>' -DNO_STRLCPY diffcore-order.c
gcc -o diffcore-pickaxe.o -c -g -O2 -Wall -DSHA1_HEADER='<openssl/sha.h>' -DNO_STRLCPY diffcore-pickaxe.c
gcc -o diffcore-rename.o -c -g -O2 -Wall -DSHA1_HEADER='<openssl/sha.h>' -DNO_STRLCPY diffcore-rename.c
gcc -o tree-diff.o -c -g -O2 -Wall -DSHA1_HEADER='<openssl/sha.h>' -DNO_STRLCPY tree-diff.c
gcc -o combine-diff.o -c -g -O2 -Wall -DSHA1_HEADER='<openssl/sha.h>' -DNO_STRLCPY combine-diff.c
gcc -o diffcore-delta.o -c -g -O2 -Wall -DSHA1_HEADER='<openssl/sha.h>' -DNO_STRLCPY diffcore-delta.c
gcc -o log-tree.o -c -g -O2 -Wall -DSHA1_HEADER='<openssl/sha.h>' -DNO_STRLCPY log-tree.c
gcc -o color.o -c -g -O2 -Wall -DSHA1_HEADER='<openssl/sha.h>' -DNO_STRLCPY color.c
gcc -o wt-status.o -c -g -O2 -Wall -DSHA1_HEADER='<openssl/sha.h>' -DNO_STRLCPY wt-status.c
gcc -o archive-zip.o -c -g -O2 -Wall -DSHA1_HEADER='<openssl/sha.h>' -DNO_STRLCPY archive-zip.c
gcc -o archive-tar.o -c -g -O2 -Wall -DSHA1_HEADER='<openssl/sha.h>' -DNO_STRLCPY archive-tar.c
gcc -o compat/strlcpy.o -c -g -O2 -Wall -DSHA1_HEADER='<openssl/sha.h>' -DNO_STRLCPY compat/strlcpy.c
rm -f libgit.a && ar rcs libgit.a blob.o commit.o connect.o csum-file.o cache-tree.o base85.o date.o diff-delta.o entry.o exec_cmd.o ident.o interpolate.o lockfile.o object.o pack-check.o patch-delta.o path.o pkt-line.o sideband.o quote.o read-cache.o refs.o run-command.o dir.o object-refs.o server-info.o setup.o sha1_file.o sha1_name.o strbuf.o tag.o tree.o usage.o config.o environment.o ctype.o copy.o revision.o pager.o tree-walk.o xdiff-interface.o write_or_die.o trace.o list-objects.o grep.o alloc.o merge-file.o path-list.o help.o unpack-trees.o diff.o diff-lib.o diffcore-break.o diffcore-order.o diffcore-pickaxe.o diffcore-rename.o tree-diff.o combine-diff.o diffcore-delta.o log-tree.o color.o wt-status.o archive-zip.o archive-tar.o compat/strlcpy.o
gcc -o xdiff/xdiffi.o -c -g -O2 -Wall -DSHA1_HEADER='<openssl/sha.h>' -DNO_STRLCPY xdiff/xdiffi.c
gcc -o xdiff/xprepare.o -c -g -O2 -Wall -DSHA1_HEADER='<openssl/sha.h>' -DNO_STRLCPY xdiff/xprepare.c
gcc -o xdiff/xutils.o -c -g -O2 -Wall -DSHA1_HEADER='<openssl/sha.h>' -DNO_STRLCPY xdiff/xutils.c
gcc -o xdiff/xemit.o -c -g -O2 -Wall -DSHA1_HEADER='<openssl/sha.h>' -DNO_STRLCPY xdiff/xemit.c
rm -f xdiff/lib.a && ar rcs xdiff/lib.a xdiff/xdiffi.o xdiff/xprepare.o xdiff/xutils.o xdiff/xemit.o
gcc -g -O2 -Wall -DSHA1_HEADER='<openssl/sha.h>' -DNO_STRLCPY -o git-convert-objects convert-objects.o libgit.a xdiff/lib.a -lz -lcrypto
gcc -o fetch-pack.o -c -g -O2 -Wall -DSHA1_HEADER='<openssl/sha.h>' -DNO_STRLCPY fetch-pack.c
gcc -g -O2 -Wall -DSHA1_HEADER='<openssl/sha.h>' -DNO_STRLCPY -o git-fetch-pack fetch-pack.o libgit.a xdiff/lib.a -lz -lcrypto
gcc -o fsck-objects.o -c -g -O2 -Wall -DSHA1_HEADER='<openssl/sha.h>' -DNO_STRLCPY fsck-objects.c
gcc -g -O2 -Wall -DSHA1_HEADER='<openssl/sha.h>' -DNO_STRLCPY -o git-fsck-objects fsck-objects.o libgit.a xdiff/lib.a -lz -lcrypto
gcc -o hash-object.o -c -g -O2 -Wall -DSHA1_HEADER='<openssl/sha.h>' -DNO_STRLCPY hash-object.c
gcc -g -O2 -Wall -DSHA1_HEADER='<openssl/sha.h>' -DNO_STRLCPY -o git-hash-object hash-object.o libgit.a xdiff/lib.a -lz -lcrypto
gcc -o index-pack.o -c -g -O2 -Wall -DSHA1_HEADER='<openssl/sha.h>' -DNO_STRLCPY index-pack.c
gcc -g -O2 -Wall -DSHA1_HEADER='<openssl/sha.h>' -DNO_STRLCPY -o git-index-pack index-pack.o libgit.a xdiff/lib.a -lz -lcrypto
gcc -o local-fetch.o -c -g -O2 -Wall -DSHA1_HEADER='<openssl/sha.h>' -DNO_STRLCPY local-fetch.c
gcc -o fetch.o -c -g -O2 -Wall -DSHA1_HEADER='<openssl/sha.h>' -DNO_STRLCPY fetch.c
gcc -g -O2 -Wall -DSHA1_HEADER='<openssl/sha.h>' -DNO_STRLCPY -o git-local-fetch local-fetch.o fetch.o libgit.a xdiff/lib.a -lz -lcrypto
gcc -o merge-base.o -c -g -O2 -Wall -DSHA1_HEADER='<openssl/sha.h>' -DNO_STRLCPY merge-base.c
gcc -g -O2 -Wall -DSHA1_HEADER='<openssl/sha.h>' -DNO_STRLCPY -o git-merge-base merge-base.o libgit.a xdiff/lib.a -lz -lcrypto
gcc -o daemon.o -c -g -O2 -Wall -DSHA1_HEADER='<openssl/sha.h>' -DNO_STRLCPY daemon.c
gcc -g -O2 -Wall -DSHA1_HEADER='<openssl/sha.h>' -DNO_STRLCPY -o git-daemon daemon.o libgit.a xdiff/lib.a -lz -lcrypto
gcc -o merge-index.o -c -g -O2 -Wall -DSHA1_HEADER='<openssl/sha.h>' -DNO_STRLCPY merge-index.c
gcc -g -O2 -Wall -DSHA1_HEADER='<openssl/sha.h>' -DNO_STRLCPY -o git-merge-index merge-index.o libgit.a xdiff/lib.a -lz -lcrypto
gcc -o mktag.o -c -g -O2 -Wall -DSHA1_HEADER='<openssl/sha.h>' -DNO_STRLCPY mktag.c
gcc -g -O2 -Wall -DSHA1_HEADER='<openssl/sha.h>' -DNO_STRLCPY -o git-mktag mktag.o libgit.a xdiff/lib.a -lz -lcrypto
gcc -o mktree.o -c -g -O2 -Wall -DSHA1_HEADER='<openssl/sha.h>' -DNO_STRLCPY mktree.c
gcc -g -O2 -Wall -DSHA1_HEADER='<openssl/sha.h>' -DNO_STRLCPY -o git-mktree mktree.o libgit.a xdiff/lib.a -lz -lcrypto
gcc -o patch-id.o -c -g -O2 -Wall -DSHA1_HEADER='<openssl/sha.h>' -DNO_STRLCPY patch-id.c
gcc -g -O2 -Wall -DSHA1_HEADER='<openssl/sha.h>' -DNO_STRLCPY -o git-patch-id patch-id.o libgit.a xdiff/lib.a -lz -lcrypto
gcc -o peek-remote.o -c -g -O2 -Wall -DSHA1_HEADER='<openssl/sha.h>' -DNO_STRLCPY peek-remote.c
gcc -g -O2 -Wall -DSHA1_HEADER='<openssl/sha.h>' -DNO_STRLCPY -o git-peek-remote peek-remote.o libgit.a xdiff/lib.a -lz -lcrypto
gcc -o receive-pack.o -c -g -O2 -Wall -DSHA1_HEADER='<openssl/sha.h>' -DNO_STRLCPY receive-pack.c
gcc -g -O2 -Wall -DSHA1_HEADER='<openssl/sha.h>' -DNO_STRLCPY -o git-receive-pack receive-pack.o libgit.a xdiff/lib.a -lz -lcrypto
gcc -o send-pack.o -c -g -O2 -Wall -DSHA1_HEADER='<openssl/sha.h>' -DNO_STRLCPY send-pack.c
gcc -g -O2 -Wall -DSHA1_HEADER='<openssl/sha.h>' -DNO_STRLCPY -o git-send-pack send-pack.o libgit.a xdiff/lib.a -lz -lcrypto
gcc -o shell.o -c -g -O2 -Wall -DSHA1_HEADER='<openssl/sha.h>' -DNO_STRLCPY shell.c
gcc -g -O2 -Wall -DSHA1_HEADER='<openssl/sha.h>' -DNO_STRLCPY -o git-shell shell.o libgit.a xdiff/lib.a -lz -lcrypto
gcc -o show-index.o -c -g -O2 -Wall -DSHA1_HEADER='<openssl/sha.h>' -DNO_STRLCPY show-index.c
gcc -g -O2 -Wall -DSHA1_HEADER='<openssl/sha.h>' -DNO_STRLCPY -o git-show-index show-index.o libgit.a xdiff/lib.a -lz -lcrypto
gcc -o ssh-fetch.o -c -g -O2 -Wall -DSHA1_HEADER='<openssl/sha.h>' -DNO_STRLCPY ssh-fetch.c
gcc -o rsh.o -c -g -O2 -Wall -DSHA1_HEADER='<openssl/sha.h>' -DNO_STRLCPY rsh.c
gcc -g -O2 -Wall -DSHA1_HEADER='<openssl/sha.h>' -DNO_STRLCPY -o git-ssh-fetch ssh-fetch.o rsh.o fetch.o libgit.a xdiff/lib.a -lz -lcrypto
gcc -o ssh-upload.o -c -g -O2 -Wall -DSHA1_HEADER='<openssl/sha.h>' -DNO_STRLCPY ssh-upload.c
gcc -g -O2 -Wall -DSHA1_HEADER='<openssl/sha.h>' -DNO_STRLCPY -o git-ssh-upload ssh-upload.o rsh.o libgit.a xdiff/lib.a -lz -lcrypto
gcc -o unpack-file.o -c -g -O2 -Wall -DSHA1_HEADER='<openssl/sha.h>' -DNO_STRLCPY unpack-file.c
gcc -g -O2 -Wall -DSHA1_HEADER='<openssl/sha.h>' -DNO_STRLCPY -o git-unpack-file unpack-file.o libgit.a xdiff/lib.a -lz -lcrypto
gcc -o update-server-info.o -c -g -O2 -Wall -DSHA1_HEADER='<openssl/sha.h>' -DNO_STRLCPY update-server-info.c
gcc -g -O2 -Wall -DSHA1_HEADER='<openssl/sha.h>' -DNO_STRLCPY -o git-update-server-info update-server-info.o libgit.a xdiff/lib.a -lz -lcrypto
gcc -o upload-pack.o -c -g -O2 -Wall -DSHA1_HEADER='<openssl/sha.h>' -DNO_STRLCPY upload-pack.c
gcc -g -O2 -Wall -DSHA1_HEADER='<openssl/sha.h>' -DNO_STRLCPY -o git-upload-pack upload-pack.o libgit.a xdiff/lib.a -lz -lcrypto
gcc -o builtin-add.o -c -g -O2 -Wall -DSHA1_HEADER='<openssl/sha.h>' -DNO_STRLCPY builtin-add.c
gcc -o builtin-annotate.o -c -g -O2 -Wall -DSHA1_HEADER='<openssl/sha.h>' -DNO_STRLCPY builtin-annotate.c
gcc -o builtin-apply.o -c -g -O2 -Wall -DSHA1_HEADER='<openssl/sha.h>' -DNO_STRLCPY builtin-apply.c
gcc -o builtin-archive.o -c -g -O2 -Wall -DSHA1_HEADER='<openssl/sha.h>' -DNO_STRLCPY builtin-archive.c
gcc -o builtin-blame.o -c -g -O2 -Wall -DSHA1_HEADER='<openssl/sha.h>' -DNO_STRLCPY builtin-blame.c
gcc -o builtin-branch.o -c -g -O2 -Wall -DSHA1_HEADER='<openssl/sha.h>' -DNO_STRLCPY builtin-branch.c
gcc -o builtin-cat-file.o -c -g -O2 -Wall -DSHA1_HEADER='<openssl/sha.h>' -DNO_STRLCPY builtin-cat-file.c
gcc -o builtin-checkout-index.o -c -g -O2 -Wall -DSHA1_HEADER='<openssl/sha.h>' -DNO_STRLCPY builtin-checkout-index.c
gcc -o builtin-check-ref-format.o -c -g -O2 -Wall -DSHA1_HEADER='<openssl/sha.h>' -DNO_STRLCPY builtin-check-ref-format.c
gcc -o builtin-commit-tree.o -c -g -O2 -Wall -DSHA1_HEADER='<openssl/sha.h>' -DNO_STRLCPY builtin-commit-tree.c
gcc -o builtin-count-objects.o -c -g -O2 -Wall -DSHA1_HEADER='<openssl/sha.h>' -DNO_STRLCPY builtin-count-objects.c
gcc -o builtin-diff.o -c -g -O2 -Wall -DSHA1_HEADER='<openssl/sha.h>' -DNO_STRLCPY builtin-diff.c
gcc -o builtin-diff-files.o -c -g -O2 -Wall -DSHA1_HEADER='<openssl/sha.h>' -DNO_STRLCPY builtin-diff-files.c
gcc -o builtin-diff-index.o -c -g -O2 -Wall -DSHA1_HEADER='<openssl/sha.h>' -DNO_STRLCPY builtin-diff-index.c
gcc -o builtin-diff-stages.o -c -g -O2 -Wall -DSHA1_HEADER='<openssl/sha.h>' -DNO_STRLCPY builtin-diff-stages.c
gcc -o builtin-diff-tree.o -c -g -O2 -Wall -DSHA1_HEADER='<openssl/sha.h>' -DNO_STRLCPY builtin-diff-tree.c
gcc -o builtin-fmt-merge-msg.o -c -g -O2 -Wall -DSHA1_HEADER='<openssl/sha.h>' -DNO_STRLCPY builtin-fmt-merge-msg.c
gcc -o builtin-for-each-ref.o -c -g -O2 -Wall -DSHA1_HEADER='<openssl/sha.h>' -DNO_STRLCPY builtin-for-each-ref.c
gcc -o builtin-grep.o -c -g -O2 -Wall -DSHA1_HEADER='<openssl/sha.h>' -DNO_STRLCPY builtin-grep.c
gcc -o builtin-init-db.o -c -g -O2 -Wall -DSHA1_HEADER='<openssl/sha.h>' -DNO_STRLCPY -DDEFAULT_GIT_TEMPLATE_DIR='"/var/tmp/ggg/share/git-core/templates/"' builtin-init-db.c
gcc -o builtin-log.o -c -g -O2 -Wall -DSHA1_HEADER='<openssl/sha.h>' -DNO_STRLCPY builtin-log.c
gcc -o builtin-ls-files.o -c -g -O2 -Wall -DSHA1_HEADER='<openssl/sha.h>' -DNO_STRLCPY builtin-ls-files.c
gcc -o builtin-ls-tree.o -c -g -O2 -Wall -DSHA1_HEADER='<openssl/sha.h>' -DNO_STRLCPY builtin-ls-tree.c
gcc -o builtin-mailinfo.o -c -g -O2 -Wall -DSHA1_HEADER='<openssl/sha.h>' -DNO_STRLCPY builtin-mailinfo.c
gcc -o builtin-mailsplit.o -c -g -O2 -Wall -DSHA1_HEADER='<openssl/sha.h>' -DNO_STRLCPY builtin-mailsplit.c
gcc -o builtin-mv.o -c -g -O2 -Wall -DSHA1_HEADER='<openssl/sha.h>' -DNO_STRLCPY builtin-mv.c
gcc -o builtin-name-rev.o -c -g -O2 -Wall -DSHA1_HEADER='<openssl/sha.h>' -DNO_STRLCPY builtin-name-rev.c
gcc -o builtin-pack-objects.o -c -g -O2 -Wall -DSHA1_HEADER='<openssl/sha.h>' -DNO_STRLCPY builtin-pack-objects.c
gcc -o builtin-prune.o -c -g -O2 -Wall -DSHA1_HEADER='<openssl/sha.h>' -DNO_STRLCPY builtin-prune.c
gcc -o builtin-prune-packed.o -c -g -O2 -Wall -DSHA1_HEADER='<openssl/sha.h>' -DNO_STRLCPY builtin-prune-packed.c
gcc -o builtin-push.o -c -g -O2 -Wall -DSHA1_HEADER='<openssl/sha.h>' -DNO_STRLCPY builtin-push.c
gcc -o builtin-read-tree.o -c -g -O2 -Wall -DSHA1_HEADER='<openssl/sha.h>' -DNO_STRLCPY builtin-read-tree.c
gcc -o builtin-repo-config.o -c -g -O2 -Wall -DSHA1_HEADER='<openssl/sha.h>' -DNO_STRLCPY builtin-repo-config.c
gcc -o builtin-rev-list.o -c -g -O2 -Wall -DSHA1_HEADER='<openssl/sha.h>' -DNO_STRLCPY builtin-rev-list.c
gcc -o builtin-rev-parse.o -c -g -O2 -Wall -DSHA1_HEADER='<openssl/sha.h>' -DNO_STRLCPY builtin-rev-parse.c
gcc -o builtin-rm.o -c -g -O2 -Wall -DSHA1_HEADER='<openssl/sha.h>' -DNO_STRLCPY builtin-rm.c
gcc -o builtin-runstatus.o -c -g -O2 -Wall -DSHA1_HEADER='<openssl/sha.h>' -DNO_STRLCPY builtin-runstatus.c
gcc -o builtin-show-branch.o -c -g -O2 -Wall -DSHA1_HEADER='<openssl/sha.h>' -DNO_STRLCPY builtin-show-branch.c
gcc -o builtin-stripspace.o -c -g -O2 -Wall -DSHA1_HEADER='<openssl/sha.h>' -DNO_STRLCPY builtin-stripspace.c
gcc -o builtin-symbolic-ref.o -c -g -O2 -Wall -DSHA1_HEADER='<openssl/sha.h>' -DNO_STRLCPY builtin-symbolic-ref.c
gcc -o builtin-tar-tree.o -c -g -O2 -Wall -DSHA1_HEADER='<openssl/sha.h>' -DNO_STRLCPY builtin-tar-tree.c
gcc -o builtin-unpack-objects.o -c -g -O2 -Wall -DSHA1_HEADER='<openssl/sha.h>' -DNO_STRLCPY builtin-unpack-objects.c
gcc -o builtin-update-index.o -c -g -O2 -Wall -DSHA1_HEADER='<openssl/sha.h>' -DNO_STRLCPY builtin-update-index.c
gcc -o builtin-update-ref.o -c -g -O2 -Wall -DSHA1_HEADER='<openssl/sha.h>' -DNO_STRLCPY builtin-update-ref.c
gcc -o builtin-upload-archive.o -c -g -O2 -Wall -DSHA1_HEADER='<openssl/sha.h>' -DNO_STRLCPY builtin-upload-archive.c
gcc -o builtin-verify-pack.o -c -g -O2 -Wall -DSHA1_HEADER='<openssl/sha.h>' -DNO_STRLCPY builtin-verify-pack.c
gcc -o builtin-write-tree.o -c -g -O2 -Wall -DSHA1_HEADER='<openssl/sha.h>' -DNO_STRLCPY builtin-write-tree.c
gcc -o builtin-show-ref.o -c -g -O2 -Wall -DSHA1_HEADER='<openssl/sha.h>' -DNO_STRLCPY builtin-show-ref.c
gcc -o builtin-pack-refs.o -c -g -O2 -Wall -DSHA1_HEADER='<openssl/sha.h>' -DNO_STRLCPY builtin-pack-refs.c
gcc -DGIT_VERSION='"1.4.4-rc2.GIT"' \
-g -O2 -Wall -DSHA1_HEADER='<openssl/sha.h>' -DNO_STRLCPY -o git git.c \
builtin-add.o builtin-annotate.o builtin-apply.o builtin-archive.o builtin-blame.o builtin-branch.o builtin-cat-file.o builtin-checkout-index.o builtin-check-ref-format.o builtin-commit-tree.o builtin-count-objects.o builtin-diff.o builtin-diff-files.o builtin-diff-index.o builtin-diff-stages.o builtin-diff-tree.o builtin-fmt-merge-msg.o builtin-for-each-ref.o builtin-grep.o builtin-init-db.o builtin-log.o builtin-ls-files.o builtin-ls-tree.o builtin-mailinfo.o builtin-mailsplit.o builtin-mv.o builtin-name-rev.o builtin-pack-objects.o builtin-prune.o builtin-prune-packed.o builtin-push.o builtin-read-tree.o builtin-repo-config.o builtin-rev-list.o builtin-rev-parse.o builtin-rm.o builtin-runstatus.o builtin-show-branch.o builtin-stripspace.o builtin-symbolic-ref.o builtin-tar-tree.o builtin-unpack-objects.o builtin-update-index.o builtin-update-ref.o builtin-upload-archive.o builtin-verify-pack.o builtin-write-tree.o builtin-show-ref.o builtin-pack-refs.o libgit.a xdiff/lib.a -lz -lcrypto
rm -f git-verify-pack && ln git git-verify-pack
gcc -o pack-redundant.o -c -g -O2 -Wall -DSHA1_HEADER='<openssl/sha.h>' -DNO_STRLCPY pack-redundant.c
gcc -g -O2 -Wall -DSHA1_HEADER='<openssl/sha.h>' -DNO_STRLCPY -o git-pack-redundant pack-redundant.o libgit.a xdiff/lib.a -lz -lcrypto
gcc -o var.o -c -g -O2 -Wall -DSHA1_HEADER='<openssl/sha.h>' -DNO_STRLCPY var.c
gcc -g -O2 -Wall -DSHA1_HEADER='<openssl/sha.h>' -DNO_STRLCPY -o git-var var.o libgit.a xdiff/lib.a -lz -lcrypto
gcc -o describe.o -c -g -O2 -Wall -DSHA1_HEADER='<openssl/sha.h>' -DNO_STRLCPY describe.c
gcc -g -O2 -Wall -DSHA1_HEADER='<openssl/sha.h>' -DNO_STRLCPY -o git-describe describe.o libgit.a xdiff/lib.a -lz -lcrypto
gcc -o merge-tree.o -c -g -O2 -Wall -DSHA1_HEADER='<openssl/sha.h>' -DNO_STRLCPY merge-tree.c
gcc -g -O2 -Wall -DSHA1_HEADER='<openssl/sha.h>' -DNO_STRLCPY -o git-merge-tree merge-tree.o libgit.a xdiff/lib.a -lz -lcrypto
gcc -o imap-send.o -c -g -O2 -Wall -DSHA1_HEADER='<openssl/sha.h>' -DNO_STRLCPY imap-send.c
gcc -g -O2 -Wall -DSHA1_HEADER='<openssl/sha.h>' -DNO_STRLCPY -o git-imap-send imap-send.o libgit.a xdiff/lib.a -lz -lcrypto
gcc -o merge-recursive.o -c -g -O2 -Wall -DSHA1_HEADER='<openssl/sha.h>' -DNO_STRLCPY merge-recursive.c
gcc -g -O2 -Wall -DSHA1_HEADER='<openssl/sha.h>' -DNO_STRLCPY -o git-merge-recursive merge-recursive.o libgit.a xdiff/lib.a -lz -lcrypto
gcc -o ssh-pull.o -c -g -O2 -Wall -DSHA1_HEADER='<openssl/sha.h>' -DNO_STRLCPY ssh-pull.c
gcc -g -O2 -Wall -DSHA1_HEADER='<openssl/sha.h>' -DNO_STRLCPY -o git-ssh-pull ssh-pull.o rsh.o fetch.o libgit.a xdiff/lib.a -lz -lcrypto
gcc -o ssh-push.o -c -g -O2 -Wall -DSHA1_HEADER='<openssl/sha.h>' -DNO_STRLCPY ssh-push.c
gcc -g -O2 -Wall -DSHA1_HEADER='<openssl/sha.h>' -DNO_STRLCPY -o git-ssh-push ssh-push.o rsh.o libgit.a xdiff/lib.a -lz -lcrypto
gcc -o http.o -c -g -O2 -Wall -DSHA1_HEADER='<openssl/sha.h>' -DNO_STRLCPY -DGIT_USER_AGENT='"git/1.4.4-rc2.GIT"' http.c
gcc -o http-fetch.o -c -g -O2 -Wall -DSHA1_HEADER='<openssl/sha.h>' -DNO_STRLCPY http-fetch.c
gcc -g -O2 -Wall -DSHA1_HEADER='<openssl/sha.h>' -DNO_STRLCPY -o git-http-fetch fetch.o http.o http-fetch.o \
libgit.a xdiff/lib.a -lz -lcrypto -lcurl -lexpat
gcc -o http-push.o -c -g -O2 -Wall -DSHA1_HEADER='<openssl/sha.h>' -DNO_STRLCPY http-push.c
gcc -g -O2 -Wall -DSHA1_HEADER='<openssl/sha.h>' -DNO_STRLCPY -o git-http-push revision.o http.o http-push.o \
libgit.a xdiff/lib.a -lz -lcrypto -lcurl -lexpat
rm -f git-bisect git-bisect+
sed -e '1s|#!.*/sh|#!/bin/sh|' \
-e 's|@@PERL@@|/usr/bin/perl|g' \
-e 's/@@GIT_VERSION@@/1.4.4-rc2.GIT/g' \
-e 's/@@NO_CURL@@//g' \
-e 's/@@NO_PYTHON@@//g' \
git-bisect.sh >git-bisect+
chmod +x git-bisect+
mv git-bisect+ git-bisect
rm -f git-checkout git-checkout+
sed -e '1s|#!.*/sh|#!/bin/sh|' \
-e 's|@@PERL@@|/usr/bin/perl|g' \
-e 's/@@GIT_VERSION@@/1.4.4-rc2.GIT/g' \
-e 's/@@NO_CURL@@//g' \
-e 's/@@NO_PYTHON@@//g' \
git-checkout.sh >git-checkout+
chmod +x git-checkout+
mv git-checkout+ git-checkout
rm -f git-clean git-clean+
sed -e '1s|#!.*/sh|#!/bin/sh|' \
-e 's|@@PERL@@|/usr/bin/perl|g' \
-e 's/@@GIT_VERSION@@/1.4.4-rc2.GIT/g' \
-e 's/@@NO_CURL@@//g' \
-e 's/@@NO_PYTHON@@//g' \
git-clean.sh >git-clean+
chmod +x git-clean+
mv git-clean+ git-clean
rm -f git-clone git-clone+
sed -e '1s|#!.*/sh|#!/bin/sh|' \
-e 's|@@PERL@@|/usr/bin/perl|g' \
-e 's/@@GIT_VERSION@@/1.4.4-rc2.GIT/g' \
-e 's/@@NO_CURL@@//g' \
-e 's/@@NO_PYTHON@@//g' \
git-clone.sh >git-clone+
chmod +x git-clone+
mv git-clone+ git-clone
rm -f git-commit git-commit+
sed -e '1s|#!.*/sh|#!/bin/sh|' \
-e 's|@@PERL@@|/usr/bin/perl|g' \
-e 's/@@GIT_VERSION@@/1.4.4-rc2.GIT/g' \
-e 's/@@NO_CURL@@//g' \
-e 's/@@NO_PYTHON@@//g' \
git-commit.sh >git-commit+
chmod +x git-commit+
mv git-commit+ git-commit
rm -f git-fetch git-fetch+
sed -e '1s|#!.*/sh|#!/bin/sh|' \
-e 's|@@PERL@@|/usr/bin/perl|g' \
-e 's/@@GIT_VERSION@@/1.4.4-rc2.GIT/g' \
-e 's/@@NO_CURL@@//g' \
-e 's/@@NO_PYTHON@@//g' \
git-fetch.sh >git-fetch+
chmod +x git-fetch+
mv git-fetch+ git-fetch
rm -f git-ls-remote git-ls-remote+
sed -e '1s|#!.*/sh|#!/bin/sh|' \
-e 's|@@PERL@@|/usr/bin/perl|g' \
-e 's/@@GIT_VERSION@@/1.4.4-rc2.GIT/g' \
-e 's/@@NO_CURL@@//g' \
-e 's/@@NO_PYTHON@@//g' \
git-ls-remote.sh >git-ls-remote+
chmod +x git-ls-remote+
mv git-ls-remote+ git-ls-remote
rm -f git-merge-one-file git-merge-one-file+
sed -e '1s|#!.*/sh|#!/bin/sh|' \
-e 's|@@PERL@@|/usr/bin/perl|g' \
-e 's/@@GIT_VERSION@@/1.4.4-rc2.GIT/g' \
-e 's/@@NO_CURL@@//g' \
-e 's/@@NO_PYTHON@@//g' \
git-merge-one-file.sh >git-merge-one-file+
chmod +x git-merge-one-file+
mv git-merge-one-file+ git-merge-one-file
rm -f git-parse-remote git-parse-remote+
sed -e '1s|#!.*/sh|#!/bin/sh|' \
-e 's|@@PERL@@|/usr/bin/perl|g' \
-e 's/@@GIT_VERSION@@/1.4.4-rc2.GIT/g' \
-e 's/@@NO_CURL@@//g' \
-e 's/@@NO_PYTHON@@//g' \
git-parse-remote.sh >git-parse-remote+
chmod +x git-parse-remote+
mv git-parse-remote+ git-parse-remote
rm -f git-pull git-pull+
sed -e '1s|#!.*/sh|#!/bin/sh|' \
-e 's|@@PERL@@|/usr/bin/perl|g' \
-e 's/@@GIT_VERSION@@/1.4.4-rc2.GIT/g' \
-e 's/@@NO_CURL@@//g' \
-e 's/@@NO_PYTHON@@//g' \
git-pull.sh >git-pull+
chmod +x git-pull+
mv git-pull+ git-pull
rm -f git-rebase git-rebase+
sed -e '1s|#!.*/sh|#!/bin/sh|' \
-e 's|@@PERL@@|/usr/bin/perl|g' \
-e 's/@@GIT_VERSION@@/1.4.4-rc2.GIT/g' \
-e 's/@@NO_CURL@@//g' \
-e 's/@@NO_PYTHON@@//g' \
git-rebase.sh >git-rebase+
chmod +x git-rebase+
mv git-rebase+ git-rebase
rm -f git-repack git-repack+
sed -e '1s|#!.*/sh|#!/bin/sh|' \
-e 's|@@PERL@@|/usr/bin/perl|g' \
-e 's/@@GIT_VERSION@@/1.4.4-rc2.GIT/g' \
-e 's/@@NO_CURL@@//g' \
-e 's/@@NO_PYTHON@@//g' \
git-repack.sh >git-repack+
chmod +x git-repack+
mv git-repack+ git-repack
rm -f git-request-pull git-request-pull+
sed -e '1s|#!.*/sh|#!/bin/sh|' \
-e 's|@@PERL@@|/usr/bin/perl|g' \
-e 's/@@GIT_VERSION@@/1.4.4-rc2.GIT/g' \
-e 's/@@NO_CURL@@//g' \
-e 's/@@NO_PYTHON@@//g' \
git-request-pull.sh >git-request-pull+
chmod +x git-request-pull+
mv git-request-pull+ git-request-pull
rm -f git-reset git-reset+
sed -e '1s|#!.*/sh|#!/bin/sh|' \
-e 's|@@PERL@@|/usr/bin/perl|g' \
-e 's/@@GIT_VERSION@@/1.4.4-rc2.GIT/g' \
-e 's/@@NO_CURL@@//g' \
-e 's/@@NO_PYTHON@@//g' \
git-reset.sh >git-reset+
chmod +x git-reset+
mv git-reset+ git-reset
rm -f git-resolve git-resolve+
sed -e '1s|#!.*/sh|#!/bin/sh|' \
-e 's|@@PERL@@|/usr/bin/perl|g' \
-e 's/@@GIT_VERSION@@/1.4.4-rc2.GIT/g' \
-e 's/@@NO_CURL@@//g' \
-e 's/@@NO_PYTHON@@//g' \
git-resolve.sh >git-resolve+
chmod +x git-resolve+
mv git-resolve+ git-resolve
rm -f git-revert git-revert+
sed -e '1s|#!.*/sh|#!/bin/sh|' \
-e 's|@@PERL@@|/usr/bin/perl|g' \
-e 's/@@GIT_VERSION@@/1.4.4-rc2.GIT/g' \
-e 's/@@NO_CURL@@//g' \
-e 's/@@NO_PYTHON@@//g' \
git-revert.sh >git-revert+
chmod +x git-revert+
mv git-revert+ git-revert
rm -f git-sh-setup git-sh-setup+
sed -e '1s|#!.*/sh|#!/bin/sh|' \
-e 's|@@PERL@@|/usr/bin/perl|g' \
-e 's/@@GIT_VERSION@@/1.4.4-rc2.GIT/g' \
-e 's/@@NO_CURL@@//g' \
-e 's/@@NO_PYTHON@@//g' \
git-sh-setup.sh >git-sh-setup+
chmod +x git-sh-setup+
mv git-sh-setup+ git-sh-setup
rm -f git-tag git-tag+
sed -e '1s|#!.*/sh|#!/bin/sh|' \
-e 's|@@PERL@@|/usr/bin/perl|g' \
-e 's/@@GIT_VERSION@@/1.4.4-rc2.GIT/g' \
-e 's/@@NO_CURL@@//g' \
-e 's/@@NO_PYTHON@@//g' \
git-tag.sh >git-tag+
chmod +x git-tag+
mv git-tag+ git-tag
rm -f git-verify-tag git-verify-tag+
sed -e '1s|#!.*/sh|#!/bin/sh|' \
-e 's|@@PERL@@|/usr/bin/perl|g' \
-e 's/@@GIT_VERSION@@/1.4.4-rc2.GIT/g' \
-e 's/@@NO_CURL@@//g' \
-e 's/@@NO_PYTHON@@//g' \
git-verify-tag.sh >git-verify-tag+
chmod +x git-verify-tag+
mv git-verify-tag+ git-verify-tag
rm -f git-applymbox git-applymbox+
sed -e '1s|#!.*/sh|#!/bin/sh|' \
-e 's|@@PERL@@|/usr/bin/perl|g' \
-e 's/@@GIT_VERSION@@/1.4.4-rc2.GIT/g' \
-e 's/@@NO_CURL@@//g' \
-e 's/@@NO_PYTHON@@//g' \
git-applymbox.sh >git-applymbox+
chmod +x git-applymbox+
mv git-applymbox+ git-applymbox
rm -f git-applypatch git-applypatch+
sed -e '1s|#!.*/sh|#!/bin/sh|' \
-e 's|@@PERL@@|/usr/bin/perl|g' \
-e 's/@@GIT_VERSION@@/1.4.4-rc2.GIT/g' \
-e 's/@@NO_CURL@@//g' \
-e 's/@@NO_PYTHON@@//g' \
git-applypatch.sh >git-applypatch+
chmod +x git-applypatch+
mv git-applypatch+ git-applypatch
rm -f git-am git-am+
sed -e '1s|#!.*/sh|#!/bin/sh|' \
-e 's|@@PERL@@|/usr/bin/perl|g' \
-e 's/@@GIT_VERSION@@/1.4.4-rc2.GIT/g' \
-e 's/@@NO_CURL@@//g' \
-e 's/@@NO_PYTHON@@//g' \
git-am.sh >git-am+
chmod +x git-am+
mv git-am+ git-am
rm -f git-merge git-merge+
sed -e '1s|#!.*/sh|#!/bin/sh|' \
-e 's|@@PERL@@|/usr/bin/perl|g' \
-e 's/@@GIT_VERSION@@/1.4.4-rc2.GIT/g' \
-e 's/@@NO_CURL@@//g' \
-e 's/@@NO_PYTHON@@//g' \
git-merge.sh >git-merge+
chmod +x git-merge+
mv git-merge+ git-merge
rm -f git-merge-stupid git-merge-stupid+
sed -e '1s|#!.*/sh|#!/bin/sh|' \
-e 's|@@PERL@@|/usr/bin/perl|g' \
-e 's/@@GIT_VERSION@@/1.4.4-rc2.GIT/g' \
-e 's/@@NO_CURL@@//g' \
-e 's/@@NO_PYTHON@@//g' \
git-merge-stupid.sh >git-merge-stupid+
chmod +x git-merge-stupid+
mv git-merge-stupid+ git-merge-stupid
rm -f git-merge-octopus git-merge-octopus+
sed -e '1s|#!.*/sh|#!/bin/sh|' \
-e 's|@@PERL@@|/usr/bin/perl|g' \
-e 's/@@GIT_VERSION@@/1.4.4-rc2.GIT/g' \
-e 's/@@NO_CURL@@//g' \
-e 's/@@NO_PYTHON@@//g' \
git-merge-octopus.sh >git-merge-octopus+
chmod +x git-merge-octopus+
mv git-merge-octopus+ git-merge-octopus
rm -f git-merge-resolve git-merge-resolve+
sed -e '1s|#!.*/sh|#!/bin/sh|' \
-e 's|@@PERL@@|/usr/bin/perl|g' \
-e 's/@@GIT_VERSION@@/1.4.4-rc2.GIT/g' \
-e 's/@@NO_CURL@@//g' \
-e 's/@@NO_PYTHON@@//g' \
git-merge-resolve.sh >git-merge-resolve+
chmod +x git-merge-resolve+
mv git-merge-resolve+ git-merge-resolve
rm -f git-merge-ours git-merge-ours+
sed -e '1s|#!.*/sh|#!/bin/sh|' \
-e 's|@@PERL@@|/usr/bin/perl|g' \
-e 's/@@GIT_VERSION@@/1.4.4-rc2.GIT/g' \
-e 's/@@NO_CURL@@//g' \
-e 's/@@NO_PYTHON@@//g' \
git-merge-ours.sh >git-merge-ours+
chmod +x git-merge-ours+
mv git-merge-ours+ git-merge-ours
rm -f git-lost-found git-lost-found+
sed -e '1s|#!.*/sh|#!/bin/sh|' \
-e 's|@@PERL@@|/usr/bin/perl|g' \
-e 's/@@GIT_VERSION@@/1.4.4-rc2.GIT/g' \
-e 's/@@NO_CURL@@//g' \
-e 's/@@NO_PYTHON@@//g' \
git-lost-found.sh >git-lost-found+
chmod +x git-lost-found+
mv git-lost-found+ git-lost-found
rm -f git-quiltimport git-quiltimport+
sed -e '1s|#!.*/sh|#!/bin/sh|' \
-e 's|@@PERL@@|/usr/bin/perl|g' \
-e 's/@@GIT_VERSION@@/1.4.4-rc2.GIT/g' \
-e 's/@@NO_CURL@@//g' \
-e 's/@@NO_PYTHON@@//g' \
git-quiltimport.sh >git-quiltimport+
chmod +x git-quiltimport+
mv git-quiltimport+ git-quiltimport
rm -f git-archimport git-archimport+
INSTLIBDIR=`make -C perl -s --no-print-directory instlibdir` && \
sed -e '1{' \
-e ' s|#!.*perl|#!/usr/bin/perl|' \
-e ' h' \
-e ' s=.*=use lib (split(/:/, $ENV{GITPERLLIB} || "@@INSTLIBDIR@@"));=' \
-e ' H' \
-e ' x' \
-e '}' \
-e 's|@@INSTLIBDIR@@|'"$INSTLIBDIR"'|g' \
-e 's/@@GIT_VERSION@@/1.4.4-rc2.GIT/g' \
git-archimport.perl >git-archimport+
chmod +x git-archimport+
mv git-archimport+ git-archimport
rm -f git-cvsimport git-cvsimport+
INSTLIBDIR=`make -C perl -s --no-print-directory instlibdir` && \
sed -e '1{' \
-e ' s|#!.*perl|#!/usr/bin/perl|' \
-e ' h' \
-e ' s=.*=use lib (split(/:/, $ENV{GITPERLLIB} || "@@INSTLIBDIR@@"));=' \
-e ' H' \
-e ' x' \
-e '}' \
-e 's|@@INSTLIBDIR@@|'"$INSTLIBDIR"'|g' \
-e 's/@@GIT_VERSION@@/1.4.4-rc2.GIT/g' \
git-cvsimport.perl >git-cvsimport+
chmod +x git-cvsimport+
mv git-cvsimport+ git-cvsimport
rm -f git-relink git-relink+
INSTLIBDIR=`make -C perl -s --no-print-directory instlibdir` && \
sed -e '1{' \
-e ' s|#!.*perl|#!/usr/bin/perl|' \
-e ' h' \
-e ' s=.*=use lib (split(/:/, $ENV{GITPERLLIB} || "@@INSTLIBDIR@@"));=' \
-e ' H' \
-e ' x' \
-e '}' \
-e 's|@@INSTLIBDIR@@|'"$INSTLIBDIR"'|g' \
-e 's/@@GIT_VERSION@@/1.4.4-rc2.GIT/g' \
git-relink.perl >git-relink+
chmod +x git-relink+
mv git-relink+ git-relink
rm -f git-shortlog git-shortlog+
INSTLIBDIR=`make -C perl -s --no-print-directory instlibdir` && \
sed -e '1{' \
-e ' s|#!.*perl|#!/usr/bin/perl|' \
-e ' h' \
-e ' s=.*=use lib (split(/:/, $ENV{GITPERLLIB} || "@@INSTLIBDIR@@"));=' \
-e ' H' \
-e ' x' \
-e '}' \
-e 's|@@INSTLIBDIR@@|'"$INSTLIBDIR"'|g' \
-e 's/@@GIT_VERSION@@/1.4.4-rc2.GIT/g' \
git-shortlog.perl >git-shortlog+
chmod +x git-shortlog+
mv git-shortlog+ git-shortlog
rm -f git-rerere git-rerere+
INSTLIBDIR=`make -C perl -s --no-print-directory instlibdir` && \
sed -e '1{' \
-e ' s|#!.*perl|#!/usr/bin/perl|' \
-e ' h' \
-e ' s=.*=use lib (split(/:/, $ENV{GITPERLLIB} || "@@INSTLIBDIR@@"));=' \
-e ' H' \
-e ' x' \
-e '}' \
-e 's|@@INSTLIBDIR@@|'"$INSTLIBDIR"'|g' \
-e 's/@@GIT_VERSION@@/1.4.4-rc2.GIT/g' \
git-rerere.perl >git-rerere+
chmod +x git-rerere+
mv git-rerere+ git-rerere
rm -f git-cvsserver git-cvsserver+
INSTLIBDIR=`make -C perl -s --no-print-directory instlibdir` && \
sed -e '1{' \
-e ' s|#!.*perl|#!/usr/bin/perl|' \
-e ' h' \
-e ' s=.*=use lib (split(/:/, $ENV{GITPERLLIB} || "@@INSTLIBDIR@@"));=' \
-e ' H' \
-e ' x' \
-e '}' \
-e 's|@@INSTLIBDIR@@|'"$INSTLIBDIR"'|g' \
-e 's/@@GIT_VERSION@@/1.4.4-rc2.GIT/g' \
git-cvsserver.perl >git-cvsserver+
chmod +x git-cvsserver+
mv git-cvsserver+ git-cvsserver
rm -f git-svnimport git-svnimport+
INSTLIBDIR=`make -C perl -s --no-print-directory instlibdir` && \
sed -e '1{' \
-e ' s|#!.*perl|#!/usr/bin/perl|' \
-e ' h' \
-e ' s=.*=use lib (split(/:/, $ENV{GITPERLLIB} || "@@INSTLIBDIR@@"));=' \
-e ' H' \
-e ' x' \
-e '}' \
-e 's|@@INSTLIBDIR@@|'"$INSTLIBDIR"'|g' \
-e 's/@@GIT_VERSION@@/1.4.4-rc2.GIT/g' \
git-svnimport.perl >git-svnimport+
chmod +x git-svnimport+
mv git-svnimport+ git-svnimport
rm -f git-cvsexportcommit git-cvsexportcommit+
INSTLIBDIR=`make -C perl -s --no-print-directory instlibdir` && \
sed -e '1{' \
-e ' s|#!.*perl|#!/usr/bin/perl|' \
-e ' h' \
-e ' s=.*=use lib (split(/:/, $ENV{GITPERLLIB} || "@@INSTLIBDIR@@"));=' \
-e ' H' \
-e ' x' \
-e '}' \
-e 's|@@INSTLIBDIR@@|'"$INSTLIBDIR"'|g' \
-e 's/@@GIT_VERSION@@/1.4.4-rc2.GIT/g' \
git-cvsexportcommit.perl >git-cvsexportcommit+
chmod +x git-cvsexportcommit+
mv git-cvsexportcommit+ git-cvsexportcommit
rm -f git-send-email git-send-email+
INSTLIBDIR=`make -C perl -s --no-print-directory instlibdir` && \
sed -e '1{' \
-e ' s|#!.*perl|#!/usr/bin/perl|' \
-e ' h' \
-e ' s=.*=use lib (split(/:/, $ENV{GITPERLLIB} || "@@INSTLIBDIR@@"));=' \
-e ' H' \
-e ' x' \
-e '}' \
-e 's|@@INSTLIBDIR@@|'"$INSTLIBDIR"'|g' \
-e 's/@@GIT_VERSION@@/1.4.4-rc2.GIT/g' \
git-send-email.perl >git-send-email+
chmod +x git-send-email+
mv git-send-email+ git-send-email
rm -f git-svn git-svn+
INSTLIBDIR=`make -C perl -s --no-print-directory instlibdir` && \
sed -e '1{' \
-e ' s|#!.*perl|#!/usr/bin/perl|' \
-e ' h' \
-e ' s=.*=use lib (split(/:/, $ENV{GITPERLLIB} || "@@INSTLIBDIR@@"));=' \
-e ' H' \
-e ' x' \
-e '}' \
-e 's|@@INSTLIBDIR@@|'"$INSTLIBDIR"'|g' \
-e 's/@@GIT_VERSION@@/1.4.4-rc2.GIT/g' \
git-svn.perl >git-svn+
chmod +x git-svn+
mv git-svn+ git-svn
rm -f git-merge-recursive-old git-merge-recursive-old+
sed -e '1s|#!.*python|#!/usr/bin/python|' \
-e 's|@@GIT_PYTHON_PATH@@|/var/tmp/ggg/share/git-core/python|g' \
-e 's/@@GIT_VERSION@@/1.4.4-rc2.GIT/g' \
git-merge-recursive-old.py >git-merge-recursive-old+
chmod +x git-merge-recursive-old+
mv git-merge-recursive-old+ git-merge-recursive-old
cp git-revert git-cherry-pick+
mv git-cherry-pick+ git-cherry-pick
cp git-commit git-status+
mv git-status+ git-status
rm -f gitweb/gitweb.cgi gitweb/gitweb.cgi+
sed -e '1s|#!.*perl|#!/usr/bin/perl|' \
-e 's|++GIT_VERSION++|1.4.4-rc2.GIT|g' \
-e 's|++GIT_BINDIR++|/var/tmp/ggg/bin|g' \
-e 's|++GITWEB_CONFIG++|gitweb_config.perl|g' \
-e 's|++GITWEB_HOME_LINK_STR++|projects|g' \
-e 's|++GITWEB_SITENAME++||g' \
-e 's|++GITWEB_PROJECTROOT++|/pub/git|g' \
-e 's|++GITWEB_EXPORT_OK++||g' \
-e 's|++GITWEB_STRICT_EXPORT++||g' \
-e 's|++GITWEB_BASE_URL++||g' \
-e 's|++GITWEB_LIST++||g' \
-e 's|++GITWEB_HOMETEXT++|indextext.html|g' \
-e 's|++GITWEB_CSS++|gitweb.css|g' \
-e 's|++GITWEB_LOGO++|git-logo.png|g' \
-e 's|++GITWEB_FAVICON++|git-favicon.png|g' \
-e 's|++GITWEB_SITE_HEADER++||g' \
-e 's|++GITWEB_SITE_FOOTER++||g' \
gitweb/gitweb.perl >gitweb/gitweb.cgi+
chmod +x gitweb/gitweb.cgi+
mv gitweb/gitweb.cgi+ gitweb/gitweb.cgi
rm -f git-instaweb git-instaweb+
sed -e '1s|#!.*/sh|#!/bin/sh|' \
-e 's/@@GIT_VERSION@@/1.4.4-rc2.GIT/g' \
-e 's/@@NO_CURL@@//g' \
-e 's/@@NO_PYTHON@@//g' \
-e '/@@GITWEB_CGI@@/r gitweb/gitweb.cgi' \
-e '/@@GITWEB_CGI@@/d' \
-e '/@@GITWEB_CSS@@/r gitweb/gitweb.css' \
-e '/@@GITWEB_CSS@@/d' \
git-instaweb.sh > git-instaweb+
chmod +x git-instaweb+
mv git-instaweb+ git-instaweb
rm -f git-merge-recur && ln git-merge-recursive git-merge-recur
rm -f git-format-patch && ln git git-format-patch
rm -f git-show && ln git git-show
rm -f git-whatchanged && ln git git-whatchanged
rm -f git-cherry && ln git git-cherry
rm -f git-get-tar-commit-id && ln git git-get-tar-commit-id
rm -f git-add && ln git git-add
rm -f git-annotate && ln git git-annotate
rm -f git-apply && ln git git-apply
rm -f git-archive && ln git git-archive
rm -f git-blame && ln git git-blame
rm -f git-branch && ln git git-branch
rm -f git-cat-file && ln git git-cat-file
rm -f git-checkout-index && ln git git-checkout-index
rm -f git-check-ref-format && ln git git-check-ref-format
rm -f git-commit-tree && ln git git-commit-tree
rm -f git-count-objects && ln git git-count-objects
rm -f git-diff && ln git git-diff
rm -f git-diff-files && ln git git-diff-files
rm -f git-diff-index && ln git git-diff-index
rm -f git-diff-stages && ln git git-diff-stages
rm -f git-diff-tree && ln git git-diff-tree
rm -f git-fmt-merge-msg && ln git git-fmt-merge-msg
rm -f git-for-each-ref && ln git git-for-each-ref
rm -f git-grep && ln git git-grep
rm -f git-init-db && ln git git-init-db
rm -f git-log && ln git git-log
rm -f git-ls-files && ln git git-ls-files
rm -f git-ls-tree && ln git git-ls-tree
rm -f git-mailinfo && ln git git-mailinfo
rm -f git-mailsplit && ln git git-mailsplit
rm -f git-mv && ln git git-mv
rm -f git-name-rev && ln git git-name-rev
rm -f git-pack-objects && ln git git-pack-objects
rm -f git-prune && ln git git-prune
rm -f git-prune-packed && ln git git-prune-packed
rm -f git-push && ln git git-push
rm -f git-read-tree && ln git git-read-tree
rm -f git-repo-config && ln git git-repo-config
rm -f git-rev-list && ln git git-rev-list
rm -f git-rev-parse && ln git git-rev-parse
rm -f git-rm && ln git git-rm
rm -f git-runstatus && ln git git-runstatus
rm -f git-show-branch && ln git git-show-branch
rm -f git-stripspace && ln git git-stripspace
rm -f git-symbolic-ref && ln git git-symbolic-ref
rm -f git-tar-tree && ln git git-tar-tree
rm -f git-unpack-objects && ln git git-unpack-objects
rm -f git-update-index && ln git git-update-index
rm -f git-update-ref && ln git git-update-ref
rm -f git-upload-archive && ln git git-upload-archive
rm -f git-write-tree && ln git git-write-tree
rm -f git-show-ref && ln git git-show-ref
rm -f git-pack-refs && ln git git-pack-refs
make -C perl
make[1]: Entering directory `/VMware/kernel/git/git/perl'
cp private-Error.pm blib/lib/Error.pm
cp Git.pm blib/lib/Git.pm
Manifying blib/man3/private-Error.3pm
Manifying blib/man3/Git.3pm
make[1]: Leaving directory `/VMware/kernel/git/git/perl'
make -C templates
make[1]: Entering directory `/VMware/kernel/git/git/templates'
ls *--* 2>/dev/null | \
while read boilerplate; \
do \
case "$boilerplate" in *~) continue ;; esac && \
dst=`echo "$boilerplate" | sed -e 's|^this|.|;s|--|/|g'` && \
dir=`expr "$dst" : '\(.*\)/'` && \
mkdir -p blt/$dir && \
case "$boilerplate" in \
*--) ;; \
*) cp $boilerplate blt/$dst ;; \
esac || exit; \
done || exit
date >boilerplates.made
: no custom templates yet
make[1]: Leaving directory `/VMware/kernel/git/git/templates'
install -d -m755 '/var/tmp/ggg/bin'
install -d -m755 '/var/tmp/ggg/bin'
install git-convert-objects git-fetch-pack git-fsck-objects git-hash-object git-index-pack git-local-fetch git-merge-base git-daemon git-merge-index git-mktag git-mktree git-patch-id git-peek-remote git-receive-pack git-send-pack git-shell git-show-index git-ssh-fetch git-ssh-upload git-unpack-file git-update-server-info git-upload-pack git-verify-pack git-pack-redundant git-var git-describe git-merge-tree git-imap-send git-merge-recursive git-ssh-pull git-ssh-push git-http-fetch git-http-push git-bisect git-checkout git-clean git-clone git-commit git-fetch git-ls-remote git-merge-one-file git-parse-remote git-pull git-rebase git-repack git-request-pull git-reset git-resolve git-revert git-sh-setup git-tag git-verify-tag git-applymbox git-applypatch git-am git-merge git-merge-stupid git-merge-octopus git-merge-resolve git-merge-ours git-lost-found git-quiltimport git-archimport git-cvsimport git-relink git-shortlog git-rerere git-cvsserver git-svnimport git-cvsexportcommit git-send-email git-svn git-merge-recursive-old git-cherry-pick git-status git-instaweb git-merge-recur '/var/tmp/ggg/bin'
install git gitk '/var/tmp/ggg/bin'
make -C templates DESTDIR='' install
make[1]: Entering directory `/VMware/kernel/git/git/templates'
: no custom templates yet
install -d -m755 '/var/tmp/ggg/share/git-core/templates/'
(cd blt && tar cf - .) | \
(cd '/var/tmp/ggg/share/git-core/templates/' && tar xf -)
tar: This does not look like a tar archive
tar: Skipping to next header
tar: Archive contains obsolescent base-64 headers
tar: Error exit delayed from previous errors
make[1]: *** [install] Error 2
make[1]: Leaving directory `/VMware/kernel/git/git/templates'
make: *** [install] Error 2
^ permalink raw reply [relevance 8%]
* [ANNOUNCE] GIT 1.4.4
@ 2006-11-15 7:43 8% Junio C Hamano
0 siblings, 0 replies; 76+ results
From: Junio C Hamano @ 2006-11-15 7:43 UTC (permalink / raw)
To: git; +Cc: linux-kernel
The latest feature release GIT 1.4.4 is available at the usual
places:
http://www.kernel.org/pub/software/scm/git/
git-1.4.4.tar.{gz,bz2} (tarball)
git-htmldocs-1.4.4.tar.{gz,bz2} (preformatted docs)
git-manpages-1.4.4.tar.{gz,bz2} (preformatted docs)
RPMS/$arch/git-*-1.4.4-1.$arch.rpm (RPM)
Quite a lot of changes during the last month.
- pack-refs, along with a lot of internal clean-up of the code
that deal with refs, is in. A repository with many tags
would benefit from packing and pruning them. Currently dumb
transports are not capable of fetching from a repository that
has packed and pruned its refs, so please keep that in mind.
Hopefully we will get an update for dumb transports shortly.
- git native transport can now keep transferred packs without
exploding it into loose objects. Also "git repack" can be
told to keep "historical" packs from getting repacked by
marking them with .keep file. Docmentation update is
probably needed.
- git-blame can now detect line movements across files. No, it
is not called git-pickaxe.
- a lot of gitweb and git-svn updates.
----------------------------------------------------------------
Changes since v1.4.3 are as follows:
Alan Chandler:
Gitweb - provide site headers and footers
Alex Riesen:
merge-recursive implicitely depends on trust_executable_bit
Alexandre Julliard:
git.el: Added a function to open the current file in another window.
git.el: Added functions for moving to the next/prev unmerged file.
git.el: Include MERGE_MSG in the log-edit buffer even when not committing a merge.
git.el: Move point after the log message header when entering log-edit mode.
pack-refs: Store the full name of the ref even when packing only tags.
prune-packed: Fix uninitialized variable.
Andy Parkins:
git-clone documentation didn't mention --origin as equivalent of -o
Make filenames line up in git-status output
Minor grammar fixes for git-diff-index.txt
Remove uneccessarily similar printf() from print_ref_list() in builtin-branch
Andy Whitcroft:
cvsimport: move over to using git-for-each-ref to read refs.
git-for-each-ref: improve the documentation on scripting modes
Aneesh Kumar K.V:
gitweb: Remove extra "/" in path names for git_get_project_list
Christian Couder:
Add pack-refs and show-ref test cases.
Add [-s|--hash] option to Linus' show-ref.
Check that a tag exists using show-ref instead of looking for the ref file.
Clean up "git-branch.sh" and add remove recursive dir test cases.
Documentation: add git in /etc/services.
Documentation: add upload-archive service to git-daemon.
Document git-show-ref [-s|--hash] option.
Do not create tag leading directories since git update-ref does it.
Fix a remove_empty_dir_recursive problem.
Fix show-ref usage for --dereference.
Remove --syslog in git-daemon inetd documentation examples.
Uncomment test case: git branch c/d should barf if branch c exists.
Use git-update-ref to delete a tag instead of rm()ing the ref file.
Use Linus' show ref in "git-branch.sh".
When creating branch c/d check that branch c does not already exists.
Dennis Stosberg:
lock_ref_sha1_basic does not remove empty directories on BSD
Remove bashism from t3210-pack-refs.sh
Bash completion support for aliases
Dmitry V. Levin:
git-clone: define die() and use it.
Edgar Toernig:
Use memmove instead of memcpy for overlapping areas
Eric Wong:
git-send-email: do not pass custom Date: header
git-svn: avoid printing filenames of files we're not tracking
git-svn: don't die on rebuild when --upgrade is specified
git-svn: fix dcommit losing changes when out-of-date from svn
git-svn: fix symlink-to-file changes when using command-line svn 1.4.0
Gerrit Pape:
Set $HOME for selftests
J. Bruce Fields:
Make prune also run prune-packed
Documentation: updates to "Everyday GIT"
Jakub Narebski:
diff-format.txt: Combined diff format documentation supplement
diff-format.txt: Correct information about pathnames quoting in patch format
Documentation: Transplanting branch with git-rebase --onto
Documentation: Update information about <format> in git-for-each-ref
gitweb: Add "next" link to commitdiff view
gitweb: Add '..' (up directory) to tree view if applicable
gitweb: Better git-unquoting and gitweb-quoting of pathnames
gitweb: Better support for non-CSS aware web browsers
gitweb: Check git base URLs before generating URL from it
gitweb: Do not esc_html $basedir argument to git_print_tree_entry
gitweb: Filter out commit ID from @difftree in git_commit and git_commitdiff
gitweb: Get rid of git_print_simplified_log
gitweb: Improve git_print_page_path
gitweb: Move git_get_last_activity subroutine earlier
gitweb: New improved patchset view
gitweb: Output also empty patches in "commitdiff" view
gitweb: Print commit message without title in commitdiff only if there is any
gitweb: Secure against commit-ish/tree-ish with the same name as path
gitweb: Use character or octal escape codes (and add span.cntrl) in esc_path
gitweb: Use git-for-each-ref to generate list of heads and/or tags
gitweb: Use --no-commit-id in git_commit and git_commitdiff
gitweb: Use 's' regexp modifier to secure against filenames with LF
gitweb: Whitespace cleanup - tabs are for indent, spaces are for align (2)
Jan Harkes:
Continue traversal when rev-list --unpacked finds a packed commit.
Jeff King:
wt-status: use simplified resolve_ref to find current branch
gitignore: git-pack-refs is a generated file.
gitignore: git-show-ref is a generated file.
git-pickaxe: work properly in a subdirectory.
Fix git-runstatus for repositories containing a file named HEAD
Jim Meyering:
Don't use $author_name undefined when $from contains no /\s</.
git-clone: honor --quiet
xdiff/xemit.c (xdl_find_func): Elide trailing white space in a context header.
Johannes Schindelin:
Fix git-update-index --again
show-branch: mark active branch with a '*' again
Turn on recursive with --summary
link_temp_to_file: call adjust_shared_perm() only when we created the directory
Johannes Sixt:
test-lib.sh: A command dying due to a signal is an unexpected failure.
Catch errors when writing an index that contains invalid objects.
Jonas Fonseca:
Add man page for git-show-ref
git-update-index(1): fix use of quoting in section title
Junio C Hamano:
Add callback data to for_each_ref() family.
Add git-for-each-ref: helper for language bindings
adjust_shared_perm: chmod() only when needed.
apply: handle "traditional" creation/deletion diff correctly.
blame.c: move code to output metainfo into a separate function.
blame.c: whitespace and formatting clean-up.
blame: Document and add help text for -f, -n, and -p
branch: work in subdirectories.
cherry is built-in, do not ship git-cherry.sh
Clean-up lock-ref implementation
combine-diff: a few more finishing touches.
combine-diff: fix hunk_comment_line logic.
combine-diff: honour --no-commit-id
core.logallrefupdates create new log file only for branch heads.
core.logallrefupdates thinko-fix
daemon: do not die on older clients.
delete_ref(): delete packed ref
diff --numstat
Documentation: clarify refname disambiguation rules.
Documentation: fix git-format-patch mark-up and link it from git.txt
Documentation: move blame examples
Documentation: note about contrib/.
Documentation/SubmittingPatches: 3+1 != 6
Document git-pack-refs and link it to git(7).
Fix refs.c;:repack_without_ref() clean-up path
Fix t1400-update-ref test minimally
for-each-ref: "creator" and "creatordate" fields
fsck-objects: adjust to resolve_ref() clean-up.
GIT 1.4.3-rc1
GIT 1.4.4
GIT 1.4.4-rc2
git-annotate: fix -S on graft file with comments.
git-annotate: no need to exec blame; it is built-in now.
git-blame: add internal statistics to count read blobs.
git-blame --porcelain
git-blame: --show-name (and -f)
git-blame: --show-number (and -n)
git-branch: remove D/F check done by hand.
git-cvsserver: read from git with -z to get non-ASCII pathnames.
git-diff/git-apply: make diff output a bit friendlier to GNU patch (part 1)
git-fetch: adjust to packed-refs.
git-fetch: do not look into $GIT_DIR/refs to see if a tag exists.
git-pack-refs --all
git-pack-refs --prune
git-pickaxe: allow -Ln,m as well as -L n,m
git-pickaxe: allow "-L <something>,+N"
git-pickaxe: blame rewritten.
git-pickaxe: cache one already found path per commit.
git-pickaxe -C: blame cut-and-pasted lines.
git-pickaxe: do not confuse two origins that are the same.
git-pickaxe: do not keep commit buffer.
git-pickaxe: fix nth_line()
git-pickaxe: fix origin refcounting
git-pickaxe: get rid of wasteful find_origin().
git-pickaxe: improve "best match" heuristics
git-pickaxe: introduce heuristics to avoid "trivial" chunks
git-pickaxe: -L /regexp/,/regexp/
git-pickaxe -M: blame line movements within a file.
git-pickaxe: optimize by avoiding repeated read_sha1_file().
git-pickaxe: pagenate output by default.
git-pickaxe: refcount origin correctly in find_copy_in_parent()
git-pickaxe: rename detection optimization
git-pickaxe: re-scan the blob after making progress with -C
git-pickaxe: re-scan the blob after making progress with -M
git-pickaxe: retire pickaxe
git-pickaxe: simplify Octopus merges further
git-pickaxe: split find_origin() into find_rename() and find_origin().
git-pickaxe: swap comparison loop used for -C
git-pickaxe: tighten sanity checks.
git-pickaxe: WIP to refcount origin structure.
git-repack: repo.usedeltabaseoffset
git-send-email: do not drop custom headers the user prepared
git-send-email: real name with period need to be dq-quoted on From: line
git-status: quote LF in its output
gitweb: do not give blame link unconditionally in diff-tree view
gitweb: fix disabling of "forks"
gitweb: fix unmatched div in commitdiff
gitweb: make leftmost column of blame less cluttered.
gitweb: minimally fix "fork" support.
gitweb: prepare for repositories with packed refs.
gitweb: protect blob and diff output lines from controls.
gitweb: protect commit messages from controls.
gitweb: spell "blame --porcelain" with -p
gitweb: use blame --porcelain
gitweb: use for-each-ref to show the latest activity across branches
grep --all-match
Introduce a new revision set operator <rev>^!
link_temp_to_file: don't leave the path truncated on adjust_shared_perm failure
lock_ref_sha1_basic: remove unused parameter "plen".
lock_ref_sha1(): check D/F conflict with packed ref when creating.
lock_ref_sha1(): do not sometimes error() and sometimes die().
Make git-send-email detect mbox-style patches more readily
merge: loosen overcautious "working file will be lost" check.
merge-recursive: adjust to loosened "working file clobbered" check
merge-recursive: make a few functions static.
merge-recursive: use abbreviated commit object name.
pack-objects: document --delta-base-offset option
pack-refs: call fflush before fsync.
pack-refs: do not pack symbolic refs.
pack-refs: fix git_path() usage.
pack-refs: use lockfile as everybody else does.
pager: default to LESS=FRS
pager: default to LESS=FRSX not LESS=FRS
path-list: fix path-list-insert return value
quote.c: ensure the same quoting across platforms.
receive-pack: call setup_ident before git_config
Refer to git-rev-parse:Specifying Revisions from git.txt
ref locking: allow 'foo' when 'foo/bar' used to exist but not anymore.
ref-log: allow ref@{count} syntax.
ref-log: fix D/F conflict coming from deleted refs.
refs: minor restructuring of cached refs data.
Revert 954a6183756a073723a7c9fd8d2feb13132876b0
Revert "send-pack --keep: do not explode into loose objects on the receiving end."
revision traversal: --unpacked does not limit commit list anymore.
RPM package re-classification.
send-pack --keep: do not explode into loose objects on the receiving end.
sha1_name.c: avoid compilation warnings.
show-ref --hash=len, --abbrev=len, and --abbrev
Surround "#define DEBUG 0" with "#ifndef DEBUG..#endif"
symbolit-ref: fix resolve_ref conversion.
t3200: git-branch testsuite update
t6022: ignoring untracked files by merge-recursive when they do not matter
Teach receive-pack about ref-log
teach revision walker about --all-match.
Tell between packed, unpacked and symbolic refs.
tests: merge-recursive is usable without Python
update a few Porcelain-ish for ref lock safety.
Update cherry documentation.
update-ref: -d flag and ref creation safety.
Karl Hasselström:
git-vc: better installation instructions
ignore-errors requires cl
Lars Hjemli:
Fix typo in show-index.c
Fix usagestring for git-branch
Make git-branch a builtin
Fix show-ref usagestring
Linus Torvalds:
Add "git show-ref" builtin command
Teach "git checkout" to use git-show-ref
Start handling references internally as a sorted in-memory list
Add support for negative refs
Make ref resolution saner
Enable the packed refs file format
git-apply: prepare for upcoming GNU diff -u format change.
Allow '-' in config variable names
git push: add verbose flag and allow overriding of default target repository
Luben Tuikov:
gitweb: blame: print commit-8 on the leading row of a commit-block
gitweb: blame: Mouse-over commit-8 shows author and date
gitweb: blame porcelain: lineno and orig lineno swapped
git-revert with conflicts to behave as git-merge with conflicts
gitweb: esc_html() author in blame
Martin Waitz:
gitweb: start to generate PATH_INFO URLs.
gitweb: warn if feature cannot be overridden.
Matthew Wilcox:
Add --dry-run option to git-send-email
Nguyễn Thái Ngọc Duy:
Reject hexstring longer than 40-bytes in get_short_sha1()
Add revspec documentation for ':path', ':[0-3]:path' and git-describe
Nicolas Pitre:
introduce delta objects with offset to base
teach git-unpack-objects about deltas with offset to base
teach git-index-pack about deltas with offset to base
make git-pack-objects able to create deltas with offset to base
make pack data reuse compatible with both delta types
let the GIT native protocol use offsets to delta base when possible
zap a debug remnant
allow delta data reuse even if base object is a preferred base
index-pack: compare only the first 20-bytes of the key.
reduce delta head inflated size
add the capability for index-pack to read from a stream
enable index-pack streaming capability
make index-pack able to complete thin packs.
add progress status to index-pack
mimic unpack-objects when --stdin is used with index-pack
enhance clone and fetch -k experience
index-pack: minor fixes to comment and function name
missing small substitution
pack-objects doesn't create random pack names
make git-push a bit more verbose
Allow pack header preprocessing before unpack-objects/index-pack.
git-fetch can use both --thin and --keep with fetch-pack now
improve fetch-pack's handling of kept packs
have index-pack create .keep file more carefully
remove .keep pack lock files when done with refs update
git-pack-objects progress flag documentation and cleanup
OGAWA Hirofumi:
gitk: Fix nextfile() and add prevfile()
Petr Baudis:
Fix broken sha1 locking
Fix buggy ref recording
gitweb: Document features better
gitweb: Fix search form when PATH_INFO is enabled
bisect reset: Leave the tree in usable state if git-checkout failed
gitweb: Fix setting $/ in parse_commit()
gitweb: Restore object-named links in item lists
gitweb: Make search type a popup menu
gitweb: Do not automatically append " git" to custom site name
gitweb: Show project's README.html if available
xdiff: Match GNU diff behaviour when deciding hunk comment worthiness of lines
gitweb: Support for 'forks'
gitweb: Fix up bogus $stylesheet declarations
Nicer error messages in case saving an object to db goes wrong
Rene Scharfe:
git-archive --format=zip: use default version ID
git-archive --format=zip: add symlink support
git-merge: show usage if run without arguments
Built-in cherry
Make git-cherry handle root trees
git-cherry: document limit and add diagram
Robert Shearman:
git-rebase: Use --ignore-if-in-upstream option when executing git-format-patch.
git-rebase: Add a -v option to show a diffstat of the changes upstream at the start of a rebase.
git-rebase: Use --ignore-if-in-upstream option when executing git-format-patch.
Robin Rosenberg:
Mention that pull can work locally in the synopsis
Swap the porcelain and plumbing commands in the git man page
Rework cvsexportcommit to handle binary files for all cases.
Ryan Anderson:
Remove git-annotate.perl and create a builtin-alias for git-blame
Santi Béjar:
fetch: Misc output cleanup
merge and resolve: Output short hashes and .. in "Updating ..."
Documentation for the [remote] config
Sasha Khapyorsky:
git-svnimport.perl: copying directory from original SVN place
git-svnimport: support for partial imports
Sean Estabrooks:
Add --global option to git-repo-config.
Sergey Vlasov:
git-send-email: Document support for local sendmail instead of SMTP server
git-send-email: Read the default SMTP server from the GIT config file
Shawn Pearce:
Added completion support for git-branch.exe.
Added bash completion support for git-reset.
Use ULONG_MAX rather than implicit cast of -1.
Remove SIMPLE_PROGRAMS and make git-daemon a normal program.
Remove unsupported C99 style struct initializers in git-archive.
Added missing completions for show-branch and merge-base.
Only load .exe suffix'd completions on Cygwin.
Bash completion support for remotes in .git/config.
Take --git-dir into consideration during bash completion.
Support bash completion on symmetric difference operator.
Remove more sed invocations from within bash completion.
Use column indexes in git-cvsserver where necessary.
Allow short pack names to git-pack-objects --unpacked=.
Only repack active packs by skipping over kept packs.
Teach git-index-pack how to keep a pack file.
Remove unused variable in receive-pack.
Move deny_non_fast_forwards handling completely into receive-pack.
Teach receive-pack how to keep pack files based on object count.
Tero Roponen:
remove an unneeded test
Tuncer Ayaz:
git-fetch.sh printed protocol fix
^ permalink raw reply [relevance 8%]
* gitweb some known issues
@ 2006-11-12 6:28 5% Junio C Hamano
0 siblings, 0 replies; 76+ results
From: Junio C Hamano @ 2006-11-12 6:28 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git, Petr Baudis, Luben Tuikov
Visit git.git gitweb page (http://repo.or.cz/w/git.git would
work fine if git.kernel.org is too busy), and click on "GIT 1.4.4-rc1"
to view the tag (not the commit).
The navigation bar has commit/commitdiff/tree with explicit h
and hb object names that point at 'master', which feels wrong.
When the tag that is displayed points at a commit, perhaps we
would want to use that commit for commit and commitdiff? When
the tag does not point at a commit (which is admittably very
rare), probably not showing these links is the right thing to do
(if tag points at tree it might make sense to give tree,
though).
Also shortlog/log links do not say where to begin the log with,
which means start digging from HEAD. When we display a commit
or commitdiff, we seem to give a link to start log at that
commit, so doing the same as above for shortlog/log may make
them more consistent.
^ permalink raw reply [relevance 5%]
* What's in git.git
@ 2006-11-12 6:07 6% Junio C Hamano
0 siblings, 0 replies; 76+ results
From: Junio C Hamano @ 2006-11-12 6:07 UTC (permalink / raw)
To: git
Execuive summary.
I've tagged the tip of 'master' as v1.4.4-rc2 tonight. In the
meantime, GIT 1.4.3.5 was cut from the 'maint' branch.
We hopefully can declare the real 1.4.4 soon enough, before the
turkey time.
----------------------------------------------------------------
* The 'maint' branch has these fixes since the last announcement.
Eric Wong (3):
git-svn: avoid printing filenames of files we're not tracking
git-svn: don't die on rebuild when --upgrade is specified
git-svn: fix dcommit losing changes when out-of-date from svn
Junio C Hamano (2):
path-list: fix path-list-insert return value
git-cvsserver: read from git with -z to get non-ASCII pathnames.
Petr Baudis (1):
Nicer error messages in case saving an object to db goes wrong
Robert Shearman (1):
git-rebase: Use --ignore-if-in-upstream option when executing git-format-patch.
* The 'master' branch has these since the last announcement.
Eric Wong (3):
git-svn: avoid printing filenames of files we're not tracking
git-svn: don't die on rebuild when --upgrade is specified
git-svn: fix dcommit losing changes when out-of-date from svn
Jakub Narebski (3):
gitweb: Better git-unquoting and gitweb-quoting of pathnames
gitweb: Use character or octal escape codes (and add span.cntrl) in esc_path
gitweb: New improved patchset view
Junio C Hamano (14):
gitweb: fix disabling of "forks"
gitweb: minimally fix "fork" support.
gitweb: do not give blame link unconditionally in diff-tree view
git-status: quote LF in its output
git-pickaxe: retire pickaxe
gitweb: protect blob and diff output lines from controls.
gitweb: protect commit messages from controls.
gitweb: fix unmatched div in commitdiff
Documentation: move blame examples
git-annotate: no need to exec blame; it is built-in now.
git-annotate: fix -S on graft file with comments.
path-list: fix path-list-insert return value
git-cvsserver: read from git with -z to get non-ASCII pathnames.
GIT 1.4.4-rc2
OGAWA Hirofumi (1):
gitk: Fix nextfile() and add prevfile()
Petr Baudis (1):
Nicer error messages in case saving an object to db goes wrong
Robert Shearman (1):
git-rebase: Use --ignore-if-in-upstream option when executing git-format-patch.
* The 'next' branch, in addition, has these.
Junio C Hamano (4):
upload-pack: stop the other side when they have more roots than we do.
pack-objects: use of version 3 delta is now optional.
Revert "pack-objects: use of version 3 delta is now optional."
adjust_shared_perm: chmod() only when needed.
* The 'pu' branch, in addition, has these.
Alexandre Julliard (1):
Shallow clone: do not ignore shallowness when following tags
Jakub Narebski (1):
gitweb: New improved formatting of chunk header in diff
Johannes Schindelin (6):
upload-pack: no longer call rev-list
support fetching into a shallow repository
allow cloning a repository "shallowly"
Build in shortlog
allow deepening of a shallow repository
add tests for shallow stuff
Junio C Hamano (6):
git-branch -a: show both local and remote tracking branches.
git-commit: show --summary after successful commit.
git-diff/git-apply: make diff output a bit friendlier to GNU patch (part 2)
rev-list --left-right
blame: --show-stats for easier optimization work.
gitweb: steal loadavg throttle from kernel.org
^ permalink raw reply [relevance 6%]
* Re: What's in git.git
2006-11-08 7:58 6% ` Jakub Narebski
@ 2006-11-08 8:26 0% ` Junio C Hamano
0 siblings, 0 replies; 76+ results
From: Junio C Hamano @ 2006-11-08 8:26 UTC (permalink / raw)
To: git; +Cc: jnareb
Jakub Narebski <jnareb@gmail.com> writes:
> Junio C Hamano wrote:
>
>> [master]
>>
>> Three topics that have been cooking in 'next' have been
>> merged, I've tagged the tip as v1.4.4-rc1.
>
> By the way, tag v1.4.4-rc1 has "GIT 1.4.4-rc1" as title, while the commit it
> points to, v1.4.4-rc1^{} has "GIT 1.4.3-rc1" as a title.
Yeah, sometimes I make typoes. Not a news X-<.
^ permalink raw reply [relevance 0%]
* Re: What's in git.git
@ 2006-11-08 7:58 6% ` Jakub Narebski
2006-11-08 8:26 0% ` Junio C Hamano
0 siblings, 1 reply; 76+ results
From: Jakub Narebski @ 2006-11-08 7:58 UTC (permalink / raw)
To: git
Junio C Hamano wrote:
> [master]
>
> Three topics that have been cooking in 'next' have been
> merged, I've tagged the tip as v1.4.4-rc1.
By the way, tag v1.4.4-rc1 has "GIT 1.4.4-rc1" as title, while the commit it
points to, v1.4.4-rc1^{} has "GIT 1.4.3-rc1" as a title.
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply [relevance 6%]
Results 1-76 of 76 | reverse | options above
-- pct% links below jump to the message on this page, permalinks otherwise --
2006-11-08 3:21 What's in git.git Junio C Hamano
2006-11-08 7:58 6% ` Jakub Narebski
2006-11-08 8:26 0% ` Junio C Hamano
2006-11-12 6:07 6% Junio C Hamano
2006-11-12 6:28 5% gitweb some known issues Junio C Hamano
2006-11-14 14:32 how to authenticate with git-svn on a subversion repository Comète
2006-11-15 23:39 6% ` Sam Vilain
2006-11-15 7:43 8% [ANNOUNCE] GIT 1.4.4 Junio C Hamano
2006-11-15 18:08 8% [GIT PATCH] Makefile missing git-runstatus in PROGRAMS list Bhavesh Davda
2006-11-15 21:05 7% git-svn bug? Troy Telford
2006-11-15 21:43 0% ` Junio C Hamano
2006-11-15 22:55 0% ` Troy Telford
2006-11-17 8:55 0% ` Eric Wong
2006-11-20 17:32 7% static linking lib order problem Bennett Todd
2006-11-21 22:02 6% [PATCH] gitweb: make HTML links out of http/https URLs in changelogs Kir Kolyshkin
2006-11-21 22:28 0% ` Jakub Narebski
2006-11-22 0:06 0% ` Petr Baudis
2006-11-22 9:00 0% ` Kir Kolyshkin
2006-11-22 20:56 0% ` Petr Baudis
2006-11-23 2:47 git crash when cg-fetch:ing dash Horst H. von Brand
2006-11-23 9:34 6% ` René Scharfe
2006-11-23 15:54 6% ` Horst H. von Brand
2006-11-23 16:18 0% ` Sean
2006-11-27 14:16 5% git: how to produce context diffs? Bruno Haible
2006-11-27 14:27 0% ` Jakub Narebski
2006-11-27 15:19 0% ` Sean
2006-11-27 16:05 0% ` Jakub Narebski
2006-11-27 15:38 0% ` Sean
2006-12-03 4:59 jgit performance update Shawn Pearce
2006-12-03 17:56 ` Jakub Narebski
2006-12-03 22:42 ` Juergen Stuber
2006-12-03 23:39 6% ` Robin Rosenberg
2006-12-03 23:58 0% ` Jakub Narebski
2006-12-04 20:35 0% ` Juergen Stuber
2006-12-07 15:26 14% git-svnimport breakage as of git-1.4.4 Daniel Drake
2006-12-08 20:32 8% ` Sasha Khapyorsky
2006-12-10 3:49 8% ` Dongsheng Song
2006-12-10 11:47 8% ` Sasha Khapyorsky
2006-12-11 20:00 8% ` Dongsheng Song
2006-12-11 20:50 8% ` Sasha Khapyorsky
2006-12-11 21:01 8% ` Dongsheng Song
2006-12-14 2:25 7% ` Sasha Khapyorsky
2006-12-11 14:27 8% ` Daniel Drake
2006-12-11 20:49 8% ` Sasha Khapyorsky
2006-12-11 21:03 8% ` Daniel Drake
2006-12-11 22:03 8% ` Sasha Khapyorsky
2006-12-13 16:28 8% ` Daniel Drake
2006-12-14 2:21 8% ` Sasha Khapyorsky
2006-12-14 21:05 8% ` Daniel Drake
2006-12-14 21:20 8% ` Sasha Khapyorsky
2006-12-14 21:32 8% ` Junio C Hamano
2006-12-14 21:43 8% ` Sasha Khapyorsky
2007-01-07 0:22 5% ` [PATCH] git-svnimport: clean svn path when accessing SVN repo Sasha Khapyorsky
2006-12-22 10:27 5% newbie question - git-pull and local branch merge Pelle Svensson
2007-01-15 2:21 What's in git.git and announcing GIT v1.5.0-rc1 Horst H. von Brand
2007-01-15 20:54 6% ` lamikr
2007-01-15 21:56 0% ` Junio C Hamano
2007-01-16 2:41 [RFC] Replace rebase with filtering Steven Grimm
2007-01-16 11:18 ` Johannes Schindelin
2007-01-16 19:20 ` Steven Grimm
2007-01-16 19:43 ` Steven Grimm
2007-01-16 20:35 ` Johannes Schindelin
2007-01-16 20:40 ` Steven Grimm
2007-01-16 21:20 ` Johannes Schindelin
2007-01-16 21:49 6% ` Jakub Narebski
2007-01-16 22:31 0% ` Brian Gernhardt
2007-02-04 9:38 'git config' vs 'git repo-config' Marco Costalba
2007-02-04 9:47 ` Junio C Hamano
2007-02-04 10:00 ` Marco Costalba
2007-02-04 10:09 ` Junio C Hamano
2007-02-04 10:23 ` Marco Costalba
2007-02-04 10:52 6% ` Junio C Hamano
2007-02-08 0:18 Git rescue mission Bill Lear
2007-02-08 0:48 ` Junio C Hamano
2007-02-08 15:27 ` Bill Lear
2007-02-08 15:56 5% ` Jakub Narebski
2007-02-11 11:52 how to speed up "git log"? Bruno Haible
2007-02-11 16:49 ` Johannes Schindelin
2007-02-11 23:41 7% ` Bruno Haible
2007-02-11 23:46 0% ` Shawn O. Pearce
2007-02-11 23:56 0% ` Johannes Schindelin
2007-02-11 23:59 0% ` Robin Rosenberg
2007-02-12 2:02 5% ` Bruno Haible
2007-02-12 4:08 0% ` Junio C Hamano
2007-02-12 4:20 0% ` Linus Torvalds
2007-02-12 11:27 6% ` Bruno Haible
2007-03-29 20:50 basics... when reading docs doesn't help Guennadi Liakhovetski
2007-03-29 21:16 ` J. Bruce Fields
2007-03-29 21:26 ` Junio C Hamano
2007-03-29 21:46 ` J. Bruce Fields
2007-03-29 22:13 ` Guennadi Liakhovetski
2007-03-29 22:35 ` Linus Torvalds
2007-03-30 18:16 ` Guennadi Liakhovetski
2007-03-30 18:48 ` Linus Torvalds
2007-03-30 19:49 ` Guennadi Liakhovetski
2007-03-30 20:23 5% ` Theodore Tso
2007-07-11 14:08 git-update-server-info may be required,cannot clone and pull from a remote repository pradeep singh
2007-07-11 14:31 ` Alex Riesen
2007-07-12 5:27 ` pradeep singh
2007-07-12 9:58 ` Jakub Narebski
[not found] ` <a901b49a0707120550i9361e30wc5811bd5d3305f59@mail.gmail.com>
2007-07-12 12:52 0% ` pradeep singh
2007-07-12 13:13 0% ` Johannes Schindelin
2007-07-12 13:32 0% ` pradeep singh
2007-07-13 0:17 0% ` Jakub Narebski
2007-07-13 8:27 0% ` pradeep singh
2007-09-17 8:59 6% Git pull fails on a repository > 1.5G pradeep singh
2008-02-23 17:34 5% new GIT-VERSION-GEN with old GIT Martin Koegler
2008-02-23 18:46 0% ` Junio C Hamano
2008-07-02 4:41 What's cooking in git.git (topics) Junio C Hamano
2008-07-06 10:04 ` Junio C Hamano
2008-07-08 2:46 ` Junio C Hamano
2008-07-10 2:32 ` Junio C Hamano
2008-07-14 5:11 ` Junio C Hamano
2008-07-14 7:50 ` Closing the merge window for 1.6.0 Junio C Hamano
2008-07-14 8:55 ` Petr Baudis
2008-07-14 11:57 ` Johannes Schindelin
2008-07-14 12:41 ` Gerrit Pape
2008-07-14 17:54 ` Nicolas Pitre
2008-07-14 19:00 ` Junio C Hamano
2008-07-15 9:20 ` Petr Baudis
2008-07-15 15:06 7% ` Dmitry Potapov
2008-07-15 15:27 ` Johannes Schindelin
2008-07-15 16:26 7% ` Nicolas Pitre
2008-07-15 16:46 0% ` Sverre Rabbelier
2008-07-15 17:28 0% ` Petr Baudis
2008-07-15 2:51 ` Shawn O. Pearce
2008-07-15 3:30 7% ` Nicolas Pitre
Code repositories for project(s) associated with this public inbox
https://80x24.org/mirrors/git.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).