* Problem with git push on (somewhat) large binaries
@ 2010-04-03 11:02 3% Tobi Stadelmaier
0 siblings, 0 replies; 128+ results
From: Tobi Stadelmaier @ 2010-04-03 11:02 UTC (permalink / raw)
To: git
Hi,
I recently encountered a problem while pushing to a remote repository using
ssh
- this usually works fine (and did for the last ~500 or so commits with no
problem), and I was able to pin it down to one commit where somebody added a
bunch of somewhat large (but not *huge*) binaries - about 30 MBs of JPGs,
MOVs
and others overall in that commit.
What I see when I want to push out this branch is the expected:
Pushing to <xxx>
Counting objects: 172, done.
Delta compression using up to 2 threads.
Compressing objects: 100% (72/72), done
..then gits starts to write objects, and gets to object 51 of 172. Then, all
of
a sudden, it gets progressively slower (Kib/s indicator drops from 600K/s to
200, then to 50, and further down) and then after a while it does nothing at
all
any more. Eventually, I get
Write failed: Connection reset by peer
error: pack-objects died of signal 13MiB | 47 KiB/s
error: pack-objects died with strange error
error: failed to push some refs to '<xxx>'
Everything works when I rebase that branch so that I drop that one commit
that
adds the binaries, and then push out the result.
Upgrading the server from git 1.6.1 to 1.7.0.4 didn't help. I first expected
a
cygwin problem (yeah, some of us are on Windows unfortunately), but I tried
it
with a fresh clone on Kubuntu Edgy with git 1.6.3 - same problem. I also
tried
-delta on the binary files in question with .gitattributes as suggested
somwhere, no luck.
SCPing my local repository to the server and then pushing "over the file
system"
there works, though.
Any ideas?
Thanks
Tobi
^ permalink raw reply [relevance 3%]
* Re: git diff looping?
2009-06-16 11:47 0% ` Jeff King
@ 2009-06-16 15:48 0% ` John Bito
0 siblings, 0 replies; 128+ results
From: John Bito @ 2009-06-16 15:48 UTC (permalink / raw)
To: Jeff King; +Cc: git
Thank you, Jeff!
Configuring the dummy regex allows the diff process to complete on
Solaris 10, as well.
~John
On Tue, Jun 16, 2009 at 4:47 AM, Jeff King<peff@peff.net> wrote:
> On Mon, Jun 15, 2009 at 06:37:21PM -0700, John Bito wrote:
>
>> Running Git 1.6.1 on Solaris 10, git diff seems to go into a loop -
>> consuming CPU and producing no output after a little bit. While the
>> repository isn't small, it's not huge (it's
>> http://repo.or.cz/w/egit.git). I've tried the following:
>
> I can reproduce the problem on Solaris 8 using git v1.6.3. It seems to
> be caused by a horribly slow system regex implementation; it really
> chokes on the regex we use to find the "funcname" line for java files. I
> tried running "git diff v0.4.0" and it still hadn't finished after 90
> seconds. Then I did:
>
> git config diff.java.xfuncname foo ;# some garbage regex
> git diff v0.4.0
>
> and it completed in about 2.5 seconds.
>
> Can you try that and see if it works around the problem for you?
>
> If anybody wants to look further into the problem, I think it is
> specifically triggered by this file (and the built-in xfuncname for java
> files):
>
> $ git clone git://repo.or.cz/egit.git
> $ git diff v0.4.0 -- \
> org.spearce.egit.core.test/src/org/spearce/egit/core/op/T0001_ConnectProviderOperationTest.java
>
> which isn't even all that big a file, but it is either causing some
> horrible algorithmic behavior in the regex library, or is outright
> sending it into an infinite loop.
>
> I tried building against the code in compat/regex; it completes in a
> reasonable amount of time, though it is still noticeably slow. With
> system regex, the diff given above doesn't complete in less than 90
> seconds (at which I get bored and kill it). With compat/regex, it
> completes in about 2.2 seconds. Disabling the xfuncname, it completes in
> 0.14 seconds.
>
> So I think it is a viable solution to recommend building against
> compat/regex on Solaris, but I think there is still room for improvement
> in what we ship in compat/.
>
> -Peff
>
^ permalink raw reply [relevance 0%]
* Re: git diff looping?
2009-06-16 1:37 4% git diff looping? John Bito
@ 2009-06-16 11:47 0% ` Jeff King
2009-06-16 15:48 0% ` John Bito
0 siblings, 1 reply; 128+ results
From: Jeff King @ 2009-06-16 11:47 UTC (permalink / raw)
To: John Bito; +Cc: git
On Mon, Jun 15, 2009 at 06:37:21PM -0700, John Bito wrote:
> Running Git 1.6.1 on Solaris 10, git diff seems to go into a loop -
> consuming CPU and producing no output after a little bit. While the
> repository isn't small, it's not huge (it's
> http://repo.or.cz/w/egit.git). I've tried the following:
I can reproduce the problem on Solaris 8 using git v1.6.3. It seems to
be caused by a horribly slow system regex implementation; it really
chokes on the regex we use to find the "funcname" line for java files. I
tried running "git diff v0.4.0" and it still hadn't finished after 90
seconds. Then I did:
git config diff.java.xfuncname foo ;# some garbage regex
git diff v0.4.0
and it completed in about 2.5 seconds.
Can you try that and see if it works around the problem for you?
If anybody wants to look further into the problem, I think it is
specifically triggered by this file (and the built-in xfuncname for java
files):
$ git clone git://repo.or.cz/egit.git
$ git diff v0.4.0 -- \
org.spearce.egit.core.test/src/org/spearce/egit/core/op/T0001_ConnectProviderOperationTest.java
which isn't even all that big a file, but it is either causing some
horrible algorithmic behavior in the regex library, or is outright
sending it into an infinite loop.
I tried building against the code in compat/regex; it completes in a
reasonable amount of time, though it is still noticeably slow. With
system regex, the diff given above doesn't complete in less than 90
seconds (at which I get bored and kill it). With compat/regex, it
completes in about 2.2 seconds. Disabling the xfuncname, it completes in
0.14 seconds.
So I think it is a viable solution to recommend building against
compat/regex on Solaris, but I think there is still room for improvement
in what we ship in compat/.
-Peff
^ permalink raw reply [relevance 0%]
* git diff looping?
@ 2009-06-16 1:37 4% John Bito
2009-06-16 11:47 0% ` Jeff King
0 siblings, 1 reply; 128+ results
From: John Bito @ 2009-06-16 1:37 UTC (permalink / raw)
To: git
Running Git 1.6.1 on Solaris 10, git diff seems to go into a loop -
consuming CPU and producing no output after a little bit. While the
repository isn't small, it's not huge (it's
http://repo.or.cz/w/egit.git). I've tried the following:
$ git diff v0.4.0 > ~/t.diff
$ git diff v0.4.0 HEAD > ~/t.diff
Both sit indefinitely eating most of 1 CPU
$ git fsck
Exits quickly with no output.
I don't mind going to a newer version of Git, but I'd like to have
some idea of the source of the problem before I start trying things.
Thanks!
John
^ permalink raw reply [relevance 4%]
* Re: git clone failing over slow links?
2009-06-09 15:52 5% git clone failing over slow links? skillzero
2009-06-09 17:12 0% ` Robin H. Johnson
@ 2009-06-09 18:55 0% ` Nicolas Pitre
1 sibling, 0 replies; 128+ results
From: Nicolas Pitre @ 2009-06-09 18:55 UTC (permalink / raw)
To: skillzero; +Cc: git
On Tue, 9 Jun 2009, skillzero@gmail.com wrote:
> People with slower connections are having problems cloning my
> repository. The server seems to just drop the connection. This
> repository is about 300 MB. The server is using git 1.6.1. This is
> using an ssh URL. They've tried many times and it usually dies at
> different places in the clone (5%, 80%, etc., with one successful
> clone so far for them).
Do you clearly have a set of people for whom the clone works and another
set with issues?
> remote: Counting objects: 121290, done.
> remote: Compressing objects: 100% (82778/82778), done.
> fatal: The remote end hung up unexpectedly62.14 MiB | 147 KiB/s
147 KiB/s is not particularly slow either. What is fast enough for the
clone to usually succeed?
Also, since this is through an ssh connection, do you have anything in
your syslog from sshd (usually in /var/log/secure) about anything
unusual for the connection to go down?
> Are there any known issues with git 1.6.1 that might cause this? I can
> try to get the server updated to 1.6.2.3, but I was curious if anyone
> knew of any specific issues like this. The server is running Mac OS X,
> if that matters.
Maybe it does. Major sites using git often use Linux and we would have
heard from them if anything like your problem was seen there.
Nicolas
^ permalink raw reply [relevance 0%]
* Re: git clone failing over slow links?
2009-06-09 17:12 0% ` Robin H. Johnson
@ 2009-06-09 18:42 0% ` Nicolas Pitre
0 siblings, 0 replies; 128+ results
From: Nicolas Pitre @ 2009-06-09 18:42 UTC (permalink / raw)
To: Robin H. Johnson; +Cc: Git Mailing List
On Tue, 9 Jun 2009, Robin H. Johnson wrote:
> On Tue, Jun 09, 2009 at 08:52:10AM -0700, skillzero@gmail.com wrote:
> > People with slower connections are having problems cloning my
> > repository. The server seems to just drop the connection. This
> > repository is about 300 MB. The server is using git 1.6.1. This is
> > using an ssh URL. They've tried many times and it usually dies at
> > different places in the clone (5%, 80%, etc., with one successful
> > clone so far for them).
> For Gentoo, we saw what I think was same problem early on with our
> conversion experiments. In our case however, it's going to be a
> non-problem as we intend on disabling initial clone and requiring use of
> a bundle.
In the Gentoo case, I think your problem was rather about the memory
usage impact of an initial clone and nothing to do with the speed of the
connection.
Nicolas
^ permalink raw reply [relevance 0%]
* Re: git clone failing over slow links?
2009-06-09 15:52 5% git clone failing over slow links? skillzero
@ 2009-06-09 17:12 0% ` Robin H. Johnson
2009-06-09 18:42 0% ` Nicolas Pitre
2009-06-09 18:55 0% ` Nicolas Pitre
1 sibling, 1 reply; 128+ results
From: Robin H. Johnson @ 2009-06-09 17:12 UTC (permalink / raw)
To: Git Mailing List
On Tue, Jun 09, 2009 at 08:52:10AM -0700, skillzero@gmail.com wrote:
> People with slower connections are having problems cloning my
> repository. The server seems to just drop the connection. This
> repository is about 300 MB. The server is using git 1.6.1. This is
> using an ssh URL. They've tried many times and it usually dies at
> different places in the clone (5%, 80%, etc., with one successful
> clone so far for them).
For Gentoo, we saw what I think was same problem early on with our
conversion experiments. In our case however, it's going to be a
non-problem as we intend on disabling initial clone and requiring use of
a bundle.
--
Robin Hugh Johnson
Gentoo Linux Developer & Infra Guy
E-Mail : robbat2@gentoo.org
GnuPG FP : 11AC BA4F 4778 E3F6 E4ED F38E B27B 944E 3488 4E85
^ permalink raw reply [relevance 0%]
* git clone failing over slow links?
@ 2009-06-09 15:52 5% skillzero
2009-06-09 17:12 0% ` Robin H. Johnson
2009-06-09 18:55 0% ` Nicolas Pitre
0 siblings, 2 replies; 128+ results
From: skillzero @ 2009-06-09 15:52 UTC (permalink / raw)
To: git
People with slower connections are having problems cloning my
repository. The server seems to just drop the connection. This
repository is about 300 MB. The server is using git 1.6.1. This is
using an ssh URL. They've tried many times and it usually dies at
different places in the clone (5%, 80%, etc., with one successful
clone so far for them).
remote: Counting objects: 121290, done.
remote: Compressing objects: 100% (82778/82778), done.
fatal: The remote end hung up unexpectedly62.14 MiB | 147 KiB/s
fatal: early EOF
fatal: index-pack failed
Are there any known issues with git 1.6.1 that might cause this? I can
try to get the server updated to 1.6.2.3, but I was curious if anyone
knew of any specific issues like this. The server is running Mac OS X,
if that matters.
^ permalink raw reply [relevance 5%]
* Re: git checkout -b -t
@ 2009-06-02 15:25 4% ` Michael J Gruber
0 siblings, 0 replies; 128+ results
From: Michael J Gruber @ 2009-06-02 15:25 UTC (permalink / raw)
To: John Tapsell; +Cc: Git List
John Tapsell venit, vidit, dixit 02.06.2009 16:49:
> Hey all,
>
> I've become the "guy to ask about git" in my company and people are
> always getting into a mess with git. So in turn I try to get git to
> be a more friendly. Today someone had a problem. Basically they had
> done:
>
> $ git checkout -t origin/mybranch
> fatal: git checkout: --track and --no-track require -b
>
> So they do exactly what it tells them:
> $ git checkout -b -t origin/mybranch
> Switched to a new branch "-t"
>
> doh
>
> How can we make this less easy for people to shoot themselves in the
> foot? The behavior of -t has changed recently iirc, so I think that
> problem has gone away?
git 1.6.1 and above contains DWIMery which, in the case above, would
automatically behave like
git checkout -t origin/mybranch -b mybranch
which complains in case 'mybranch' exists already, without pointing at
'-b', though. Do you think this creates a new type of head aches for
your patients?
>
> Also:
> $ git branch -D -t
>
> Doesn't work. I can see why, but it does make my life difficult :-D
>
> John
^ permalink raw reply [relevance 4%]
* Re: Managing submodules on large multi-user projects
2009-05-29 20:09 4% ` R. Tyler Ballance
@ 2009-05-29 20:18 4% ` Avery Pennarun
0 siblings, 0 replies; 128+ results
From: Avery Pennarun @ 2009-05-29 20:18 UTC (permalink / raw)
To: R. Tyler Ballance; +Cc: git
On Fri, May 29, 2009 at 4:09 PM, R. Tyler Ballance <tyler@slide.com> wrote:
> On Fri, May 29, 2009 at 03:53:26PM -0400, Avery Pennarun wrote:
>> Just so I understand, is the reason you're splitting into submodules
>> *just* to avoid memory usage / repository size issues? I can sort of
>> understand the memory usage issues - sort of - but how does it reduce
>> repository size if you need to need to check out all the submodule
>> repositories along with the main project anyway?
>
> I've got an eye on submodules as a way of avoiding the need to require a
> whole tree clone to just work on parts of it, but that's not really
> relevant to my query, just explaining our environment and setting the stage ;)
>
> We're using submodules right now similar to how we used svn externals in
> the past (except better, clearly), to incorporate outside components
> (like open source projects) that our stack depends on.
That makes sense.
>> Just looking to clarify for myself. (I'm continuing my work on
>> git-subtree, which is getting more and more positive feedback. It
>> solves all the *other* problems that you listed vs. submodules, but it
>> certainly doesn't resolve any repository size issues.)
>
> Good to know, we're still on Git 1.6.1, are there any benefits or
> additional features in more recent releases of Git that help alleviate
> the submodules issues I outlined at the top of the thread?
git-subtree is my own little project that hasn't been accepted into
git proper yet. It does work with git 1.6.1 (and also git 1.5.4, at
least) just by dropping the script into your PATH. Google "git
subtree" for more.
AFAIK, the particular issues you outlined with submodules continue to
exist in latest git. They are certainly fixable (they aren't
*fundamental* problems), but nobody has fixed them yet. I looked at
the issues for a long time and failed miserably to find a good general
solution, but that's just me.
Have fun,
Avery
^ permalink raw reply [relevance 4%]
* Re: Managing submodules on large multi-user projects
@ 2009-05-29 20:09 4% ` R. Tyler Ballance
2009-05-29 20:18 4% ` Avery Pennarun
0 siblings, 1 reply; 128+ results
From: R. Tyler Ballance @ 2009-05-29 20:09 UTC (permalink / raw)
To: Avery Pennarun; +Cc: git
[-- Attachment #1: Type: text/plain, Size: 1904 bytes --]
On Fri, May 29, 2009 at 03:53:26PM -0400, Avery Pennarun wrote:
> On Fri, May 29, 2009 at 2:41 PM, R. Tyler Ballance <tyler@slide.com> wrote:
> > As some of you may recall from my last swath of emails to the list
> > regarding memory usage and repository size, we have quite a large
> > repository. About a month ago, I added a submodule to the primary repo
> > in an effort to start to segment where possible, particularly around
> > third party modules.
> >
> > I've noticed that keeping submodules updated is an absolute pain,
> > particularly with a large multiuser setup with *lots* of branches.
>
> Just so I understand, is the reason you're splitting into submodules
> *just* to avoid memory usage / repository size issues? I can sort of
> understand the memory usage issues - sort of - but how does it reduce
> repository size if you need to need to check out all the submodule
> repositories along with the main project anyway?
I've got an eye on submodules as a way of avoiding the need to require a
whole tree clone to just work on parts of it, but that's not really
relevant to my query, just explaining our environment and setting the stage ;)
We're using submodules right now similar to how we used svn externals in
the past (except better, clearly), to incorporate outside components
(like open source projects) that our stack depends on.
> Just looking to clarify for myself. (I'm continuing my work on
> git-subtree, which is getting more and more positive feedback. It
> solves all the *other* problems that you listed vs. submodules, but it
> certainly doesn't resolve any repository size issues.)
Good to know, we're still on Git 1.6.1, are there any benefits or
additional features in more recent releases of Git that help alleviate
the submodules issues I outlined at the top of the thread?
Cheers
--
-R. Tyler Ballance
Slide, Inc.
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply [relevance 4%]
* Re: [msysGit] The 9th production of the msysGit Herald
2009-05-13 0:29 2% The 9th production of the msysGit Herald Johannes Schindelin
@ 2009-05-13 5:31 0% ` Frank Li
0 siblings, 0 replies; 128+ results
From: Frank Li @ 2009-05-13 5:31 UTC (permalink / raw)
To: Johannes.Schindelin; +Cc: msysgit, git
Johannes Schindelin
Msysgit actually is git windows porting. TortoiseGit
really benefits msysgit. But tortoisegit have not break rule.
Tortoisegit open all source code as GPLv2 and have not included
msysgit install package. And tell user need install msysgit
seperately.
I don't know why tortoisegit make you feel sad.
I think msysgit is not cross-platform. Linux\Mac system
use git directly. Linux developers have been used to use command line.
I also feel happy to use command line at linux related developing.
But windows users have been spoiled by GUI.
At least TortoiseGit help git spread at windows.
We can change view to think cross platform. Linux can use
Wine to run win32 program.
best regards
Frank Li
2009/5/13 Johannes Schindelin <Johannes.Schindelin@gmx.de>:
>
> Good morning git land!
>
> A clear Tuesday night, just after midnight, is as good an occasion as
> any to offer to you the 9th production of the msysGit Herald, the
> quite irregular news letter to keep you informed about msysGit, the
> effort to bring one of the most powerful Source Code Management
> systems to the Operating System known as Windows.
>
> These are the covered topics:
>
> What happened since the last Herald (1 year, 2 months and 11 days ago)?
>
> Interview with Pat Thoyts
>
> TortoiseGit vs GitCheetah
>
> Being not nice about netiquette
>
> New contributors
>
> The issue with the issue tracker
>
> Supporting send-email: mstmp
>
> The MSys project
>
> A GitTogether in Berlin "Alles wird Git!"
>
>
>
> I'm back.
>
>
> What happened since the last Herald (1 year, 2 months and 11 days ago)?
> =======================================================================
>
> Git 1.5.5.
>
> Git 1.5.6.
>
> Git 1.5.6.1.
>
> Git 1.6.0.2 (the new libexec/ layout really gave us some problems).
>
> Git 1.6.0.3.
>
> Git 1.6.1.
>
> Git 1.6.2.
>
> Git 1.6.2.2.
>
> Git 1.6.3.
>
> (The last three were done by me, serving as interim maintainer when
> Steffen Prohaska was on some well-deserved vacation.)
>
> We started recently to ship Portable Git packages, i.e. archives that
> only need to be unpacked (as opposed to be installed).
>
> In the meantime, we fixed quite some bugs. Just to give you an idea,
> the newest bug report is msysGit issue 256 (already fixed), while the
> number of open issues -- some of them enhancement requests -- is 17.
> Slightly more than a sixteenth. Not bad, I would say.
>
> During the same time, we upgraded GCC to version 4.3.3, and then to
> 4.4.0.
>
> Tcl/Tk was updated to version 8.5.5.
>
> We also upgraded vi to version 7.2 (thanks Christian Michon).
>
> GNU make was upgraded to version 3.81.
>
> Git filter-branch was included back into the installer, as it seems to
> work now.
>
> Marius Storm-Olsen contributed patches to speed up malloc() and
> readdir(). This might sound uninteresting, but the test suite (run
> with -j5, i.e. 5 parallel threads) runs in 18 minutes now, opposed to
> 45 minutes. A reduction by 60%. Good stuff.
>
> Lots of patches sent upstream. I mean _lots_. Really _lots_. Thanks go
> to Hannes Sixt and Steffen!
>
> In particular, Hannes worked very hard on getting the test suite
> up-to-par. We currently have almost no deviations there from upstream
> git.git.
>
> The patches accepted into git.git succeeded in reducing the deviations
> from git.git to only a handful of patches, which were compiled by
> Steffen into the 'work/not-v1.6.3' branch of 4msysgit, subject to
> being thrown upstream in the near future.
>
> The program 'git-svn' was removed in time for release 1.6.0.2 due to
> lack of maintainership. We were talked into including it again into
> 1.6.2 after Alexander Gavrilov contributed some patches to fix the
> most obvious issues. To this date, there is no maintainer of git-svn
> on Windows, and as a consequence we still have to stick with (slow)
> MSys Perl, and some things just do not work on Windows.
>
> There has been work to choose something different than the much-hated
> autoCRLF=true option during install: there are options for
> autoCRLF=false and autoCRLF=input together with explanations, with the
> latest installers.
>
> The "netinstall" and "fullinstall" packages should work again
> (fullinstall is stuck at 1.6.1 for the moment, basically because I am
> too lazy, and do not want to waste much of our Google Code quota for a
> new fullinstall package).
>
> We now have a "kill" tool, thanks to Alexander Gavrilov.
>
> We make full use of pthreads on Windows now (thanks to Dhruva
> Krishnamurthy and Peter Harris).
>
> There is subtantially better support for running Git from cmd.exe.
>
> We patched msys-1.0.dll in several ways to accomodate Git better. An
> important step was to have a script that allows us to rebuild
> msys-1.0.dll relatively easily from within msysGit. The most important
> work was done by Steffen.
>
> It was pretty awkward to switch msysGit branches on Windows, as files
> in-use (such as msys-1.0.dll) cannot be overwritten. We have added a
> hook to msysGit which installs a script on the desktop when a file in
> use needs replacing due to a branch switch. The user can then quit all
> msysGit windows, start that script and thereby fix up the files that
> need replacing, and then restart msysGit again. This is far from
> perfect, but way better than the situation before (where you were
> stuck with the dirty files forever).
>
>
> Interview with Pat Thoyts
> =========================
>
> I noticed Pat for the first time on the msysGit tracker. He answered a
> Tcl/Tk related question, and the answer actually struck me as pretty
> competent, something I did not quite expect from a name I never heard
> before.
>
> It turned out that Pat is a maintainer of Tcl/Tk, very proficient in
> Windows matters, and he was more than just helpful at a number of
> occasions.
>
> Naturally, I like to honor people who add to msysGit's value in a
> substantial way, and asked him the 10 questions you all know by now.
> So, without further delay, here is what he says:
>
> 2009/5/12 Johannes Schindelin <Johannes.Schindelin@gmx.de>:
>
>> 1) How did you get involved with Git?
>
> I do a fair amount of work as a maintainer for Tcl and Tk,
> particularly for Windows issues for these projects. Some time ago I
> started to look at DVCS to see how they might help or change the way I
> work. Tcl and Tk use CVS at the moment and I typically have a number
> of patches sitting around on my working tree. When I change track I
> update the patch, apply it in reverse and apply some different patch.
> Clearly this can loose development history and can result in a
> proliferation of versioned patches.
>
> Initially I looked into Mercurial as it had a reasonable following and
> apparently good Windows support. Mercurial encourages you to clone the
> repository for each branch you want to work on which leads to a lot of
> directories and eats quite a bit of space after a bit. I found I
> started to use the quilt equivalenet - mercurial queues - but that has
> trouble with line endings on windows.
>
> I then had a look at git. Git makes a much smaller repository than
> Mercurial (for tcl .git is around 32MB while .hg is 98MB) but also
> branches are contained in the repository so there is only one place to
> look for everything. I have also had no problem with line-endings so
> far. Now all my patches have become branches in my local git
> repository leaving the system much tidier.
>
>> 2) What were the reasons that you started working on Git?
>
> As a software developer, if I encounter a problem in a tool I am using
> I generally will attempt to fix it. Most open source projects have far
> more bugs than developers so there is not usually much point just
> raising a complaint. It needs to be examined in more depth before
> anyone else can hope to fix it. In my case there were a few issues in
> gitk that I can quite easily deal with given my experience with Tk.
> The hardest thing was to work out what to do with the patches until I
> discovered they should all be posted to the git mailing list.
>
>> 3) What do you like most in Git?
>
> The speed. And gitk. And git bisect.
>
>> 4) What do you hate most in Git?
>
> The learning curve is steep. Even for someone who has a lot of
> experience with unix and the mindset behind such tools.
>
>> 5) What was the most surprising moment when working with Git?
>
> The speed at which you can check out the earliest versions of the
> code. For the Tk repository I can examine any commit right down to
> 1998 almost instantly, checkout the code for that version in next to
> no time. I've done a bisect to isolate a fault in less time than it
> has taken to checkout a given revision from sourceforge cvs.
>
>> 6) What was the most frustrating moment when working with Git?
>
> Discovering that cvsimport doesnt handle vendor branches properly. At
> the moment this is a major problem as I'm mirroring ongoing cvs
> development.
>
>> 7) In what environment do you work?
>
> Sat in an Ikea chair in the living room with a laptop ignoring the TV.
>
> Oh - maybe you meant something else - Windows x64 mostly. And
> sometimes Linux. Occasionally solaris on a sparc server I have in a
> cupboard.
>
>> 8) What other hobbies do you have?
>
> Thats a joke right? I used to have hobbies - then I had children.
>
>> 9) What is your favourite movie?
>
> Usually the last one I saw. WallE for now then.
>
>> 10) What are your visions for Git? (I.e. where do you want it to
> go?)
>
> I don't really have any plans for git. It's looking good at the
> moment. Getting a good explorer plugin will make it more acceptable to
> a lot of windows developers so that is something to look into. I might
> be able to persuade my co-workers to make the switch if we had a
> robust plugin. gitk and gitweb already help with code review tasks. I
> might try and investigate ipv6 for msysgit at some point as I operate
> a ipv6 network locally using the SiXXS tunnel broker. Its not that
> urgent though. As ssh will run over ipv6 and my local git remotes will
> use ssh that means they are already using ipv6.
>
> I am very happy to be able to use a native Windows git. I would not
> have looked at git at all if it had only had a cygwin port.
>
> Pat Thoyts
>
>
> TortoiseGit vs GitCheetah
> =========================
>
> A long time ago, I started GitCheetah in the hope that it would prove
> two things: a "Tortoise"-style Explorer extension does not need to be
> large, and does not need to be limited to Windows. Oh, and it does not
> have to rely on a closed-source compiler.
>
> I was quite enthusiastic about the project, especially when some GSoC
> student offered to work on it last year. Unfortunately, he was grabbed
> by a different organization, but that's the way it goes.
>
> To my further chagrin, Brian Hetro, who offered to take GitCheetah to
> new glory, stalled working on it pretty quickly.
>
> At some state, Kirill (whose surname I do not know, but who lives
> pretty close to me now, it seems) started working on Git Cheetah, even
> if he seemed not to be willing to take the project into his own hands.
>
> In the meantime, much to my now-enhanced sadness, somebody took
> TortoiseSVN and adapted it to Git. It makes me sad for several
> reasons:
>
> - TortoiseSVN is big, too big for my liking, and so is TortoiseGit; I
> sincerely believe that it should be much smaller for the things it
> does,
>
> - TortoiseGit seems to be compileable only with closed-source tools,
> and the author even seems happy about it,
>
> - TortoiseGit is as unportable as TortoiseSVN (i.e. I cannot use it
> myself, Linux being my main platform),
>
> - TortoiseGit takes resources -- including people -- that would be
> better spent on GitCheetah, and
>
> - in spite of making me very sad, TortoiseGit benefits greatly from my
> (and others') work on msysGit.
>
> In the meantime, I even had to notice that TortoiseHg implemented my
> dream of a cross-platform Tortoise. Why can't we have some people who
> are dedicated to this project rather than being happy to just wait for
> (and complain about the lack of) a capable and cross-platform
> FileBrowser extension?
>
> Happily, Bosko Ivanisevic worked a bit on GitCheetah, adding cascaded
> menus and more, and maybe this project can build up enough momentum to
> be interesting even for Linux/MacOSX developers, which would add an
> additional benefit to the project.
>
> So maybe there is some hope left.
>
>
> Being not nice about netiquette
> ===============================
>
> One of the biggest reasons which made me lose fun with msysGit back
> when I gave up on it was that many Windows users are just rude.
>
> They probably do not mean to, and do not even realize that they are,
> but the whole idea of abusing the people who do all the work is not
> only incredibly wrong, it is also incredibly stupid: It should go
> without saying that if you want other people to work for you, you
> should provide them with a reason to do so. A good reason.
>
> In Open Source, by tradiditon there are almost no financial benefits
> which could try to convince people to work for other people, as there
> is a usually active user community offering to help for free. No
> surprise that when asked "would you pay for Git support", the previous
> Git surveys came up pretty blank.
>
> So there is no financial benefit.
>
> The big problem is that Windows is often much harder to work on than
> other platforms, as not only documentation is worse, and not only are
> you not able to look at the source where the documentation is lacking:
> many things are just not the same in different installations, much
> more so than when comparing, say, different Linux installations.
>
> Just one example: on Linux, you can rely on hard links being
> serialized properly. That is, if you call "link(source, target)" and
> right after that "unlink(source)" (to delete the file <source>), it
> works if <target> does not exist yet. This is the common paradigm on
> Unix to guarantee that <target> is not overwritten if it exists. Not
> so on Windows. Sometimes it works, but at other occasions, the
> procedure will succeed but <target> ends up corrupted (typically all
> zero, but correct size).
>
> Needless to say that issues like this one are hard to debug, and cost
> a lot of time (I call this the "Microsoft time tax", the time you have
> to spend on coping with Windows that would be better spent on other
> issues).
>
> So there is a tremendous amount of time to be spent, with no real
> benefit for most people who know how to fix things (as they seem to be
> mostly spread over other Operating Systems than Windows).
>
> To repeat: the effect I saw was that many people got abusive, and many
> a user actually expected msysGit to work out-of-the-box, and got
> really angry when their issues were not taken care of -- for free!
>
> As I _had_ to work on msysGit again, and was unwilling to let my
> efforts go to waste (after all, the initial "port" to MSys was done by
> me, and when I ran out of steam, Hannes took over), I tried a
> different tack, which works out pretty fine so far.
>
> The trick seems to be to actually use the powers I have as
> administrator of the Google Code page and the Google Group (having
> started it all, I am naturally given quite some permissions): I will
> not allow anybody to annoy me anymore.
>
> I will delete comments on the Wiki that do not contribute value, I
> will delete comments on the Wiki if they are just not comments but
> insults (and I will even delete commants that are useful after
> addressing their concerns), I will remove comments on the issue
> tracker that I do not like because they are abusive or just rantings,
> and I _will_ delete all mails in the Google Group that I find
> offensive.
>
> This might sound selfish, but look at it this way: some people will
> vent, oblivious of the effects they have on the project and on the
> people doing all the hard work. They would cast a damning light on the
> project, just by their bad choice of words. And they would make people
> lose fun in the project, just like they succeed with me, over one year
> ago.
>
> As some people (including me) put in a lot of effort, I feel _obliged_
> to delete offending comments and emails. I even feel good about
> removing them. If you do not like that policy, first earn my respect,
> and then complain privately about it.
>
> Oh, and a little hint: you do not earn my respect by complaining.
>
> If you need a hint how to earn my respect, do read on:
>
>
> New contributors
> ================
>
> For a very long time, msysGit was pushed forward by the gang formed of
> Hannes, Steffen, Sebastian Schuberth and myself. At some stage I got
> so frustrated that I stopped working on msysGit altogether. The reason
> is simple: it was no more fun. Way too many people asked for fixes or
> enhancements, and _none_ of them offered contributions of their own.
> As I am not a Windows person (being a happy Linux user since 1994),
> the work on msysGit was not rewarding enough for me to continue. So I
> stopped.
>
> But in the meantime, things have changed.
>
> We got contributions by Eric Raible, Petr Kodl, Pat Thoyts, Jeff King,
> Janos Laube, Marius Storm-Olsen, Peter Harris, Markus Heidelberg,
> Edward Z. Yang, Steve Haslam, Dhruva Krishnamurthy, Clifford Caoile,
> Heiko Voigt, Erik Faye-Lund, Kurt Pfeifle, Kirill (?) and Alexander
> Gavrilov.
>
> (And I should mention the continued contributions of Hannes Sixt,
> Steffen Prohaska and Sebastian Schuberth.)
>
> A few of them became pretty regular contributors -- we can always do
> with more, but the situation has improved noticably.
>
> I also want to thank all those who did not abuse the issue tracker to
> vent, or to report something and then go away, never to be seen again,
> or as a kind of a diary.
>
> There were some _very_ responsive people, one of them even offering
> VNC access so that I could debug issues on the machine where they
> happened.
>
> My heartfelt thanks go to all people who were helping msysGit!
>
>
> The issue with the issue tracker
> ================================
>
> Some time ago, I tried to disable the issue tracker, because issues
> started to accumulate, but nobody took care of them.
>
> I was talked into reenabling it, putting the msysGit mailing list as
> "default assignee".
>
> Unfortunately, my worst fears happened to become true. Still nobody
> took care of the issues. Still it seemed that I was the only person
> feeling enough of an itch to take care of the issues.
>
> Even worse, some people abuse the issue tracker, either by adding
> issues that were already addressed (which can be a simple mistake, and
> therefore excusable), or by abusing it as a sort of a diary (which is
> not so excusable), or as a place to put rantings (which is not
> excusable, as it wastes the time of people trying to help), or even to
> put insulting comments (which totally inexcusable, there is nothing at
> all that could justify this behavior).
>
> I have to admit that I am totally unamazed by the "sheer" number of
> people adding helpful comments to the issue tracker. I mean, I could
> understand if the _ratio_ of people helping vs people being helped was
> unfavorable on Windows, since with a pretty large user base it is much
> easier to indulge in the convenient laziness of not helping fellow
> human beings with their problems.
>
> But seeing that the absolute number of people helping each other on
> the Git mailing list is so much unbelivably larger than the number of
> people helping on the msysGit tracker is just sad. Really sad.
>
>
> Supporting send-email: mstmp
> ============================
>
> There is an issue (number 27: git-send-mail not working properly)
> which makes me particularly sad. Torgil promised almost two years ago
> to take care of it, but nothing happened.
>
> I am very, very disappointed at that.
>
> Now at least, it seems that Kirill took things in hand, but there are
> problems with the autoconf tools, and I just lack the time to help
> out, always hoping that other people would find their calling in
> helping with the troubles.
>
> After my addition of /share/msysGit/install-mingw-tar.sh things should
> become easier, but it seems that we need more enthusiastic people
> still.
>
>
> The MSys project
> ================
>
> There is an msysGit issue saying that we should contribute our changes
> back to the MSys project. If it weren't for the fact that the reporter
> actually did some work on msysGit, I would say that this falls into
> the "abusive" category mentioned previously.
>
> However, the issue reporter lost interest after starting work on it,
> so things are stalled right now.
>
> On the other hand, we have evidence that the MSys project is
> interested in the msysGit effort, at least in the person of Cesar
> Strauss, an important MSys contributor, who added helpful comments to
> a few issues on our issue tracker.
>
> With our recent work on msys-1.0.dll, it seems that we can really
> contribute back some useful changes, too (even if I would have
> preferred to have a lieutenant to take care of the MSys-msysGit
> liaison).
>
>
> A GitTogether in Berlin "Alles wird Git!"
> =========================================
>
> This is not strictly an msysGit issue, but somehow it actually is: a
> guy called "A Large Angry SCM" on the Git mailing list offered some
> free beer in Berlin on October 3rd 2009 (actually, he offered the
> first $100 in beer, we'll see how strong the dollar is then ;-).
>
> The part that makes this at least partially an msysGit thing is that
> Steffen, the msysGit maintainer, graciously offered hosting space.
> Thank you very much, Steffen, and of course Zuse-Institute Berlin!
>
> In case you wondered, the title "Alles wird Git!" means something like
> "Everything will be _fine_!", where the "fine" is misspelt to read
> "Git".
>
> This GitTogether -- as all GitTogethers before -- is what you make of
> it. If you have contact to a company wanting to sponsor lunch, drinks
> or accomodations, please contact me. If you want to hack on Git, bring
> your laptop. If you want to give a presentation, bring everything you
> need for it. If you want to have fun, just go there.
>
> In any case, if you want to participate, be sure to add your name to
> the Git Wiki: http://git.or.cz/gitwiki/GitTogether
>
> October 3rd is a special date: it is the German national holiday for
> celebrating the reunification of the formerly-two Germanies! Actually,
> a better day would have been June 17th, but some politicians are just
> full of themselves and want to change dates, so there you are.
>
> The positive side is that it happens to be the date a certain big and
> not-so-peaceful SCM is offering free beer. Oh, and I could imagine
> that the party will be _big_ in the evening, as it is the 20th
> anniversary of the reunification. In the party-town of Germany, things
> will probably be anything except boring.
>
^ permalink raw reply [relevance 0%]
* The 9th production of the msysGit Herald
@ 2009-05-13 0:29 2% Johannes Schindelin
2009-05-13 5:31 0% ` [msysGit] " Frank Li
0 siblings, 1 reply; 128+ results
From: Johannes Schindelin @ 2009-05-13 0:29 UTC (permalink / raw)
To: msysgit, git
Good morning git land!
A clear Tuesday night, just after midnight, is as good an occasion as
any to offer to you the 9th production of the msysGit Herald, the
quite irregular news letter to keep you informed about msysGit, the
effort to bring one of the most powerful Source Code Management
systems to the Operating System known as Windows.
These are the covered topics:
What happened since the last Herald (1 year, 2 months and 11 days ago)?
Interview with Pat Thoyts
TortoiseGit vs GitCheetah
Being not nice about netiquette
New contributors
The issue with the issue tracker
Supporting send-email: mstmp
The MSys project
A GitTogether in Berlin "Alles wird Git!"
I'm back.
What happened since the last Herald (1 year, 2 months and 11 days ago)?
=======================================================================
Git 1.5.5.
Git 1.5.6.
Git 1.5.6.1.
Git 1.6.0.2 (the new libexec/ layout really gave us some problems).
Git 1.6.0.3.
Git 1.6.1.
Git 1.6.2.
Git 1.6.2.2.
Git 1.6.3.
(The last three were done by me, serving as interim maintainer when
Steffen Prohaska was on some well-deserved vacation.)
We started recently to ship Portable Git packages, i.e. archives that
only need to be unpacked (as opposed to be installed).
In the meantime, we fixed quite some bugs. Just to give you an idea,
the newest bug report is msysGit issue 256 (already fixed), while the
number of open issues -- some of them enhancement requests -- is 17.
Slightly more than a sixteenth. Not bad, I would say.
During the same time, we upgraded GCC to version 4.3.3, and then to
4.4.0.
Tcl/Tk was updated to version 8.5.5.
We also upgraded vi to version 7.2 (thanks Christian Michon).
GNU make was upgraded to version 3.81.
Git filter-branch was included back into the installer, as it seems to
work now.
Marius Storm-Olsen contributed patches to speed up malloc() and
readdir(). This might sound uninteresting, but the test suite (run
with -j5, i.e. 5 parallel threads) runs in 18 minutes now, opposed to
45 minutes. A reduction by 60%. Good stuff.
Lots of patches sent upstream. I mean _lots_. Really _lots_. Thanks go
to Hannes Sixt and Steffen!
In particular, Hannes worked very hard on getting the test suite
up-to-par. We currently have almost no deviations there from upstream
git.git.
The patches accepted into git.git succeeded in reducing the deviations
from git.git to only a handful of patches, which were compiled by
Steffen into the 'work/not-v1.6.3' branch of 4msysgit, subject to
being thrown upstream in the near future.
The program 'git-svn' was removed in time for release 1.6.0.2 due to
lack of maintainership. We were talked into including it again into
1.6.2 after Alexander Gavrilov contributed some patches to fix the
most obvious issues. To this date, there is no maintainer of git-svn
on Windows, and as a consequence we still have to stick with (slow)
MSys Perl, and some things just do not work on Windows.
There has been work to choose something different than the much-hated
autoCRLF=true option during install: there are options for
autoCRLF=false and autoCRLF=input together with explanations, with the
latest installers.
The "netinstall" and "fullinstall" packages should work again
(fullinstall is stuck at 1.6.1 for the moment, basically because I am
too lazy, and do not want to waste much of our Google Code quota for a
new fullinstall package).
We now have a "kill" tool, thanks to Alexander Gavrilov.
We make full use of pthreads on Windows now (thanks to Dhruva
Krishnamurthy and Peter Harris).
There is subtantially better support for running Git from cmd.exe.
We patched msys-1.0.dll in several ways to accomodate Git better. An
important step was to have a script that allows us to rebuild
msys-1.0.dll relatively easily from within msysGit. The most important
work was done by Steffen.
It was pretty awkward to switch msysGit branches on Windows, as files
in-use (such as msys-1.0.dll) cannot be overwritten. We have added a
hook to msysGit which installs a script on the desktop when a file in
use needs replacing due to a branch switch. The user can then quit all
msysGit windows, start that script and thereby fix up the files that
need replacing, and then restart msysGit again. This is far from
perfect, but way better than the situation before (where you were
stuck with the dirty files forever).
Interview with Pat Thoyts
=========================
I noticed Pat for the first time on the msysGit tracker. He answered a
Tcl/Tk related question, and the answer actually struck me as pretty
competent, something I did not quite expect from a name I never heard
before.
It turned out that Pat is a maintainer of Tcl/Tk, very proficient in
Windows matters, and he was more than just helpful at a number of
occasions.
Naturally, I like to honor people who add to msysGit's value in a
substantial way, and asked him the 10 questions you all know by now.
So, without further delay, here is what he says:
2009/5/12 Johannes Schindelin <Johannes.Schindelin@gmx.de>:
> 1) How did you get involved with Git?
I do a fair amount of work as a maintainer for Tcl and Tk,
particularly for Windows issues for these projects. Some time ago I
started to look at DVCS to see how they might help or change the way I
work. Tcl and Tk use CVS at the moment and I typically have a number
of patches sitting around on my working tree. When I change track I
update the patch, apply it in reverse and apply some different patch.
Clearly this can loose development history and can result in a
proliferation of versioned patches.
Initially I looked into Mercurial as it had a reasonable following and
apparently good Windows support. Mercurial encourages you to clone the
repository for each branch you want to work on which leads to a lot of
directories and eats quite a bit of space after a bit. I found I
started to use the quilt equivalenet - mercurial queues - but that has
trouble with line endings on windows.
I then had a look at git. Git makes a much smaller repository than
Mercurial (for tcl .git is around 32MB while .hg is 98MB) but also
branches are contained in the repository so there is only one place to
look for everything. I have also had no problem with line-endings so
far. Now all my patches have become branches in my local git
repository leaving the system much tidier.
> 2) What were the reasons that you started working on Git?
As a software developer, if I encounter a problem in a tool I am using
I generally will attempt to fix it. Most open source projects have far
more bugs than developers so there is not usually much point just
raising a complaint. It needs to be examined in more depth before
anyone else can hope to fix it. In my case there were a few issues in
gitk that I can quite easily deal with given my experience with Tk.
The hardest thing was to work out what to do with the patches until I
discovered they should all be posted to the git mailing list.
> 3) What do you like most in Git?
The speed. And gitk. And git bisect.
> 4) What do you hate most in Git?
The learning curve is steep. Even for someone who has a lot of
experience with unix and the mindset behind such tools.
> 5) What was the most surprising moment when working with Git?
The speed at which you can check out the earliest versions of the
code. For the Tk repository I can examine any commit right down to
1998 almost instantly, checkout the code for that version in next to
no time. I've done a bisect to isolate a fault in less time than it
has taken to checkout a given revision from sourceforge cvs.
> 6) What was the most frustrating moment when working with Git?
Discovering that cvsimport doesnt handle vendor branches properly. At
the moment this is a major problem as I'm mirroring ongoing cvs
development.
> 7) In what environment do you work?
Sat in an Ikea chair in the living room with a laptop ignoring the TV.
Oh - maybe you meant something else - Windows x64 mostly. And
sometimes Linux. Occasionally solaris on a sparc server I have in a
cupboard.
> 8) What other hobbies do you have?
Thats a joke right? I used to have hobbies - then I had children.
> 9) What is your favourite movie?
Usually the last one I saw. WallE for now then.
> 10) What are your visions for Git? (I.e. where do you want it to
go?)
I don't really have any plans for git. It's looking good at the
moment. Getting a good explorer plugin will make it more acceptable to
a lot of windows developers so that is something to look into. I might
be able to persuade my co-workers to make the switch if we had a
robust plugin. gitk and gitweb already help with code review tasks. I
might try and investigate ipv6 for msysgit at some point as I operate
a ipv6 network locally using the SiXXS tunnel broker. Its not that
urgent though. As ssh will run over ipv6 and my local git remotes will
use ssh that means they are already using ipv6.
I am very happy to be able to use a native Windows git. I would not
have looked at git at all if it had only had a cygwin port.
Pat Thoyts
TortoiseGit vs GitCheetah
=========================
A long time ago, I started GitCheetah in the hope that it would prove
two things: a "Tortoise"-style Explorer extension does not need to be
large, and does not need to be limited to Windows. Oh, and it does not
have to rely on a closed-source compiler.
I was quite enthusiastic about the project, especially when some GSoC
student offered to work on it last year. Unfortunately, he was grabbed
by a different organization, but that's the way it goes.
To my further chagrin, Brian Hetro, who offered to take GitCheetah to
new glory, stalled working on it pretty quickly.
At some state, Kirill (whose surname I do not know, but who lives
pretty close to me now, it seems) started working on Git Cheetah, even
if he seemed not to be willing to take the project into his own hands.
In the meantime, much to my now-enhanced sadness, somebody took
TortoiseSVN and adapted it to Git. It makes me sad for several
reasons:
- TortoiseSVN is big, too big for my liking, and so is TortoiseGit; I
sincerely believe that it should be much smaller for the things it
does,
- TortoiseGit seems to be compileable only with closed-source tools,
and the author even seems happy about it,
- TortoiseGit is as unportable as TortoiseSVN (i.e. I cannot use it
myself, Linux being my main platform),
- TortoiseGit takes resources -- including people -- that would be
better spent on GitCheetah, and
- in spite of making me very sad, TortoiseGit benefits greatly from my
(and others') work on msysGit.
In the meantime, I even had to notice that TortoiseHg implemented my
dream of a cross-platform Tortoise. Why can't we have some people who
are dedicated to this project rather than being happy to just wait for
(and complain about the lack of) a capable and cross-platform
FileBrowser extension?
Happily, Bosko Ivanisevic worked a bit on GitCheetah, adding cascaded
menus and more, and maybe this project can build up enough momentum to
be interesting even for Linux/MacOSX developers, which would add an
additional benefit to the project.
So maybe there is some hope left.
Being not nice about netiquette
===============================
One of the biggest reasons which made me lose fun with msysGit back
when I gave up on it was that many Windows users are just rude.
They probably do not mean to, and do not even realize that they are,
but the whole idea of abusing the people who do all the work is not
only incredibly wrong, it is also incredibly stupid: It should go
without saying that if you want other people to work for you, you
should provide them with a reason to do so. A good reason.
In Open Source, by tradiditon there are almost no financial benefits
which could try to convince people to work for other people, as there
is a usually active user community offering to help for free. No
surprise that when asked "would you pay for Git support", the previous
Git surveys came up pretty blank.
So there is no financial benefit.
The big problem is that Windows is often much harder to work on than
other platforms, as not only documentation is worse, and not only are
you not able to look at the source where the documentation is lacking:
many things are just not the same in different installations, much
more so than when comparing, say, different Linux installations.
Just one example: on Linux, you can rely on hard links being
serialized properly. That is, if you call "link(source, target)" and
right after that "unlink(source)" (to delete the file <source>), it
works if <target> does not exist yet. This is the common paradigm on
Unix to guarantee that <target> is not overwritten if it exists. Not
so on Windows. Sometimes it works, but at other occasions, the
procedure will succeed but <target> ends up corrupted (typically all
zero, but correct size).
Needless to say that issues like this one are hard to debug, and cost
a lot of time (I call this the "Microsoft time tax", the time you have
to spend on coping with Windows that would be better spent on other
issues).
So there is a tremendous amount of time to be spent, with no real
benefit for most people who know how to fix things (as they seem to be
mostly spread over other Operating Systems than Windows).
To repeat: the effect I saw was that many people got abusive, and many
a user actually expected msysGit to work out-of-the-box, and got
really angry when their issues were not taken care of -- for free!
As I _had_ to work on msysGit again, and was unwilling to let my
efforts go to waste (after all, the initial "port" to MSys was done by
me, and when I ran out of steam, Hannes took over), I tried a
different tack, which works out pretty fine so far.
The trick seems to be to actually use the powers I have as
administrator of the Google Code page and the Google Group (having
started it all, I am naturally given quite some permissions): I will
not allow anybody to annoy me anymore.
I will delete comments on the Wiki that do not contribute value, I
will delete comments on the Wiki if they are just not comments but
insults (and I will even delete commants that are useful after
addressing their concerns), I will remove comments on the issue
tracker that I do not like because they are abusive or just rantings,
and I _will_ delete all mails in the Google Group that I find
offensive.
This might sound selfish, but look at it this way: some people will
vent, oblivious of the effects they have on the project and on the
people doing all the hard work. They would cast a damning light on the
project, just by their bad choice of words. And they would make people
lose fun in the project, just like they succeed with me, over one year
ago.
As some people (including me) put in a lot of effort, I feel _obliged_
to delete offending comments and emails. I even feel good about
removing them. If you do not like that policy, first earn my respect,
and then complain privately about it.
Oh, and a little hint: you do not earn my respect by complaining.
If you need a hint how to earn my respect, do read on:
New contributors
================
For a very long time, msysGit was pushed forward by the gang formed of
Hannes, Steffen, Sebastian Schuberth and myself. At some stage I got
so frustrated that I stopped working on msysGit altogether. The reason
is simple: it was no more fun. Way too many people asked for fixes or
enhancements, and _none_ of them offered contributions of their own.
As I am not a Windows person (being a happy Linux user since 1994),
the work on msysGit was not rewarding enough for me to continue. So I
stopped.
But in the meantime, things have changed.
We got contributions by Eric Raible, Petr Kodl, Pat Thoyts, Jeff King,
Janos Laube, Marius Storm-Olsen, Peter Harris, Markus Heidelberg,
Edward Z. Yang, Steve Haslam, Dhruva Krishnamurthy, Clifford Caoile,
Heiko Voigt, Erik Faye-Lund, Kurt Pfeifle, Kirill (?) and Alexander
Gavrilov.
(And I should mention the continued contributions of Hannes Sixt,
Steffen Prohaska and Sebastian Schuberth.)
A few of them became pretty regular contributors -- we can always do
with more, but the situation has improved noticably.
I also want to thank all those who did not abuse the issue tracker to
vent, or to report something and then go away, never to be seen again,
or as a kind of a diary.
There were some _very_ responsive people, one of them even offering
VNC access so that I could debug issues on the machine where they
happened.
My heartfelt thanks go to all people who were helping msysGit!
The issue with the issue tracker
================================
Some time ago, I tried to disable the issue tracker, because issues
started to accumulate, but nobody took care of them.
I was talked into reenabling it, putting the msysGit mailing list as
"default assignee".
Unfortunately, my worst fears happened to become true. Still nobody
took care of the issues. Still it seemed that I was the only person
feeling enough of an itch to take care of the issues.
Even worse, some people abuse the issue tracker, either by adding
issues that were already addressed (which can be a simple mistake, and
therefore excusable), or by abusing it as a sort of a diary (which is
not so excusable), or as a place to put rantings (which is not
excusable, as it wastes the time of people trying to help), or even to
put insulting comments (which totally inexcusable, there is nothing at
all that could justify this behavior).
I have to admit that I am totally unamazed by the "sheer" number of
people adding helpful comments to the issue tracker. I mean, I could
understand if the _ratio_ of people helping vs people being helped was
unfavorable on Windows, since with a pretty large user base it is much
easier to indulge in the convenient laziness of not helping fellow
human beings with their problems.
But seeing that the absolute number of people helping each other on
the Git mailing list is so much unbelivably larger than the number of
people helping on the msysGit tracker is just sad. Really sad.
Supporting send-email: mstmp
============================
There is an issue (number 27: git-send-mail not working properly)
which makes me particularly sad. Torgil promised almost two years ago
to take care of it, but nothing happened.
I am very, very disappointed at that.
Now at least, it seems that Kirill took things in hand, but there are
problems with the autoconf tools, and I just lack the time to help
out, always hoping that other people would find their calling in
helping with the troubles.
After my addition of /share/msysGit/install-mingw-tar.sh things should
become easier, but it seems that we need more enthusiastic people
still.
The MSys project
================
There is an msysGit issue saying that we should contribute our changes
back to the MSys project. If it weren't for the fact that the reporter
actually did some work on msysGit, I would say that this falls into
the "abusive" category mentioned previously.
However, the issue reporter lost interest after starting work on it,
so things are stalled right now.
On the other hand, we have evidence that the MSys project is
interested in the msysGit effort, at least in the person of Cesar
Strauss, an important MSys contributor, who added helpful comments to
a few issues on our issue tracker.
With our recent work on msys-1.0.dll, it seems that we can really
contribute back some useful changes, too (even if I would have
preferred to have a lieutenant to take care of the MSys-msysGit
liaison).
A GitTogether in Berlin "Alles wird Git!"
=========================================
This is not strictly an msysGit issue, but somehow it actually is: a
guy called "A Large Angry SCM" on the Git mailing list offered some
free beer in Berlin on October 3rd 2009 (actually, he offered the
first $100 in beer, we'll see how strong the dollar is then ;-).
The part that makes this at least partially an msysGit thing is that
Steffen, the msysGit maintainer, graciously offered hosting space.
Thank you very much, Steffen, and of course Zuse-Institute Berlin!
In case you wondered, the title "Alles wird Git!" means something like
"Everything will be _fine_!", where the "fine" is misspelt to read
"Git".
This GitTogether -- as all GitTogethers before -- is what you make of
it. If you have contact to a company wanting to sponsor lunch, drinks
or accomodations, please contact me. If you want to hack on Git, bring
your laptop. If you want to give a presentation, bring everything you
need for it. If you want to have fun, just go there.
In any case, if you want to participate, be sure to add your name to
the Git Wiki: http://git.or.cz/gitwiki/GitTogether
October 3rd is a special date: it is the German national holiday for
celebrating the reunification of the formerly-two Germanies! Actually,
a better day would have been June 17th, but some politicians are just
full of themselves and want to change dates, so there you are.
The positive side is that it happens to be the date a certain big and
not-so-peaceful SCM is offering free beer. Oh, and I could imagine
that the party will be _big_ in the evening, as it is the 20th
anniversary of the reunification. In the party-town of Germany, things
will probably be anything except boring.
^ permalink raw reply [relevance 2%]
* newb: Given a commit id, find which branches have it as an ancestor
@ 2009-03-12 15:21 3% Kelly F. Hickel
0 siblings, 0 replies; 128+ results
From: Kelly F. Hickel @ 2009-03-12 15:21 UTC (permalink / raw)
To: git; +Cc: Kelly F. Hickel
Hi all, I've been working on testing importing our cvs repo via cvs2git,
then using cvsps to pull incremental updates. Something seems to have
gone awry with one of the commits, and I'm having trouble tracking it
down.
This is a question about how to track something down after the fact, not
a question about what went wrong with the cvsps import....
This is git 1.6.1 running on Centos 5.2 linux.
So, the scenario is that one of the last few commits pulled into my git
repo by cvsps/cvsimport should have landed on origin/master, but when I
look at the file, the change is missing. I'm trying to figure out
"where it went", since it didn't go where I expected it.
Things I've tried that didn't tell me what I wanted to know:
$ git name-rev 15fa81b
15fa81b undefined
$ git log --children 15fa81b
This shows me a bunch of commits that, going by the commit date, appear
to be ancestors of the commit I'm interested in, not children.
$ git checkout 15fa81b5ae
Note: moving to "15fa81b5ae" which isn't a local branch If you want to
create a new branch from this checkout, you may do so (now or later) by
using -b with the checkout command again. Example:
git checkout -b <new_branch_name>
HEAD is now at 15fa81b... Changed version to 4.1.0.157 $ gitk (as
expected, shows me that the commit I care about is the latest in the
workspace)
$ git checkout master
Previous HEAD position was 15fa81b... Changed version to 4.1.0.157
Switched to branch "master"
$ gitk
Doesn't list my target commit, in fact, doesn't list any commits after
the cvs2git date, so it appears that none of my cvsps pulled commits
landed on master (ok, so maybe this post is about what went wrong, just
a little ;-} ).
I suspect that I'm missing some factoid in trying to map my workflow to
Git, but this seems like the kind of thing I'd want to know, i.e. given
a commit, what branches have that commit as an ancestor. It would seem
to be useful in two cases:
1) I've found a commit that introduced a bug and want to know what
releases that bug ended up in.
2) I've identified a fix for a previous bug and want to know what
releases already contain the fix.
(ok, those are pretty much the same workflow, but different reasons).
What am I missing????
--
Kelly F. Hickel
Senior Product Architect
MQSoftware, Inc.
952-345-8677 Office
952-345-8721 Fax
kfh@mqsoftware.com
www.mqsoftware.com
Certified IBM SOA Specialty
Your Full Service Provider for IBM WebSphere
Learn more at www.mqsoftware.com
^ permalink raw reply [relevance 3%]
* Re: Git for Windows 1.6.2-preview20090308
2009-03-09 10:34 0% ` Rutger Nijlunsing
@ 2009-03-09 10:37 0% ` Johannes Schindelin
0 siblings, 0 replies; 128+ results
From: Johannes Schindelin @ 2009-03-09 10:37 UTC (permalink / raw)
To: git; +Cc: git, msysgit
Hi,
On Mon, 9 Mar 2009, Rutger Nijlunsing wrote:
> On Sun, Mar 08, 2009 at 02:10:21AM +0100, Johannes Schindelin wrote:
> >
> > Hi,
> >
> > I just released a new version of Git for Windows (TAFKA WinGit). It is
> > basically Git 1.6.2 plus a few patches. Please find the installer here:
> >
> > http://msysgit.googlecode.com/
> >
> [snip]
> > Changes since Git-1.6.1-preview20081225
> >
> > Bugfixes
> > - Comes with updated msys-1.0.dll (should fix some Vista issues).
>
> Thanks! This also fixes the 'git hangs 5s without any reason on some
> Windows XP machines'!
Good to know!
Thanks,
Dscho
^ permalink raw reply [relevance 0%]
* Re: Git for Windows 1.6.2-preview20090308
2009-03-08 1:10 3% Git for Windows 1.6.2-preview20090308 Johannes Schindelin
2009-03-08 12:59 0% ` Lee Henson
@ 2009-03-09 10:34 0% ` Rutger Nijlunsing
2009-03-09 10:37 0% ` Johannes Schindelin
1 sibling, 1 reply; 128+ results
From: Rutger Nijlunsing @ 2009-03-09 10:34 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git, msysgit
On Sun, Mar 08, 2009 at 02:10:21AM +0100, Johannes Schindelin wrote:
>
> Hi,
>
> I just released a new version of Git for Windows (TAFKA WinGit). It is
> basically Git 1.6.2 plus a few patches. Please find the installer here:
>
> http://msysgit.googlecode.com/
>
[snip]
> Changes since Git-1.6.1-preview20081225
>
> Bugfixes
> - Comes with updated msys-1.0.dll (should fix some Vista issues).
Thanks! This also fixes the 'git hangs 5s without any reason on some
Windows XP machines'!
--
Rutger Nijlunsing ---------------------------------- eludias ed dse.nl
never attribute to a conspiracy which can be explained by incompetence
----------------------------------------------------------------------
^ permalink raw reply [relevance 0%]
* Re: Git for Windows 1.6.2-preview20090308
2009-03-08 1:10 3% Git for Windows 1.6.2-preview20090308 Johannes Schindelin
@ 2009-03-08 12:59 0% ` Lee Henson
2009-03-09 10:34 0% ` Rutger Nijlunsing
1 sibling, 0 replies; 128+ results
From: Lee Henson @ 2009-03-08 12:59 UTC (permalink / raw)
To: Johannes.Schindelin; +Cc: git, msysgit
[-- Attachment #1: Type: text/plain, Size: 2857 bytes --]
Thanks to everyone involved in the production of this installer!
2009/3/8 Johannes Schindelin <Johannes.Schindelin@gmx.de>
>
> Hi,
>
> I just released a new version of Git for Windows (TAFKA WinGit). It is
> basically Git 1.6.2 plus a few patches. Please find the installer here:
>
> http://msysgit.googlecode.com/
>
> Disclaimer: Git for Windows is still in a state where I do _not_ recommend
> using it unless you have the means to fix issues. Unlike git.git
> developer community, the msysGit team is heavily undermanned.
>
> Known issues
>
> - Some commands are not yet supported on Windows and excluded from the
> installation; namely: git archimport, git cvsexportcommit, git
> cvsimport, git cvsserver, git filter-branch, git instaweb, git
> send-email, git shell.
>
> - The Logitec QuickCam software can cause spurious crashes. See "Why does
> make often crash creating a sh.exe.stackdump file when I try to compile
> my source code?" in the MinGW FAQs
> (http://www.mingw.org/MinGWiki/index.php/FAQ).
>
> - The Quick Launch icon will only be installed for the user running setup
> (typically the Administrator). This is a technical restriction and will
> not change.
>
> - Git Bash launched through the Explorer shell extension does not have the
> git icon in its taskbar. This is a technical restriction and will not
> change.
>
> - git send-mail does not work properly (Issue 27).
>
> - curl uses $HOME/_netrc instead of $HOME/.netrc.
>
> - If you want to specify a different location for --upload-pack, you have
> to start the absolute path with two slashes. Otherwise MSys will mangle
> the path.
>
> - git clone fails when the repository contains UTF-8 filepaths (Issue 80).
>
> Changes since Git-1.6.1-preview20081225
>
> New Features
> - Comes with official git 1.6.2.
> - Comes with upgraded vim 7.2.
> - Compiled with GCC 4.3.3.
> - The user can choose the preferred CR/LF behavior in the installer now.
> - Peter Kodl contributed support for hardlinks on Windows.
> - The bash prompt now shows information about the current repository.
>
> Bugfixes
> - If supported by the file system, pack files can grow larger than 2gb.
> - Comes with updated msys-1.0.dll (should fix some Vista issues).
> - Assorted fixes to support the new libexec/git-core/ layout better.
> - Read-only files can be properly replaced now.
> - git-svn is included again (original caveats still apply).
> - Obsolete programs from previous installations are cleaned up.
>
>
> So what are the next steps?
>
> Hannes is busy sorting out the differences between the test suites in
> git.git and mingw.git.
>
> Thanks to the awesome efforts of both Hannes and Steffen, the rest of the
> differences are really small (the biggest being Peter's hard link patch).
> I'll try to put together a patch series in the next few weeks.
>
> Ciao,
> Dscho
>
>
[-- Attachment #2: Type: text/html, Size: 3528 bytes --]
^ permalink raw reply [relevance 0%]
* Git for Windows 1.6.2-preview20090308
@ 2009-03-08 1:10 3% Johannes Schindelin
2009-03-08 12:59 0% ` Lee Henson
2009-03-09 10:34 0% ` Rutger Nijlunsing
0 siblings, 2 replies; 128+ results
From: Johannes Schindelin @ 2009-03-08 1:10 UTC (permalink / raw)
To: git, msysgit
Hi,
I just released a new version of Git for Windows (TAFKA WinGit). It is
basically Git 1.6.2 plus a few patches. Please find the installer here:
http://msysgit.googlecode.com/
Disclaimer: Git for Windows is still in a state where I do _not_ recommend
using it unless you have the means to fix issues. Unlike git.git
developer community, the msysGit team is heavily undermanned.
Known issues
- Some commands are not yet supported on Windows and excluded from the
installation; namely: git archimport, git cvsexportcommit, git
cvsimport, git cvsserver, git filter-branch, git instaweb, git
send-email, git shell.
- The Logitec QuickCam software can cause spurious crashes. See "Why does
make often crash creating a sh.exe.stackdump file when I try to compile
my source code?" in the MinGW FAQs
(http://www.mingw.org/MinGWiki/index.php/FAQ).
- The Quick Launch icon will only be installed for the user running setup
(typically the Administrator). This is a technical restriction and will
not change.
- Git Bash launched through the Explorer shell extension does not have the
git icon in its taskbar. This is a technical restriction and will not
change.
- git send-mail does not work properly (Issue 27).
- curl uses $HOME/_netrc instead of $HOME/.netrc.
- If you want to specify a different location for --upload-pack, you have
to start the absolute path with two slashes. Otherwise MSys will mangle
the path.
- git clone fails when the repository contains UTF-8 filepaths (Issue 80).
Changes since Git-1.6.1-preview20081225
New Features
- Comes with official git 1.6.2.
- Comes with upgraded vim 7.2.
- Compiled with GCC 4.3.3.
- The user can choose the preferred CR/LF behavior in the installer now.
- Peter Kodl contributed support for hardlinks on Windows.
- The bash prompt now shows information about the current repository.
Bugfixes
- If supported by the file system, pack files can grow larger than 2gb.
- Comes with updated msys-1.0.dll (should fix some Vista issues).
- Assorted fixes to support the new libexec/git-core/ layout better.
- Read-only files can be properly replaced now.
- git-svn is included again (original caveats still apply).
- Obsolete programs from previous installations are cleaned up.
So what are the next steps?
Hannes is busy sorting out the differences between the test suites in
git.git and mingw.git.
Thanks to the awesome efforts of both Hannes and Steffen, the rest of the
differences are really small (the biggest being Peter's hard link patch).
I'll try to put together a patch series in the next few weeks.
Ciao,
Dscho
^ permalink raw reply [relevance 3%]
* Re: Using Git with windows
@ 2009-03-06 15:30 4% ` Dmitry Potapov
0 siblings, 0 replies; 128+ results
From: Dmitry Potapov @ 2009-03-06 15:30 UTC (permalink / raw)
To: Tim Visher; +Cc: Tariq Hassanen, git
On Fri, Mar 6, 2009 at 5:38 PM, Tim Visher <tim.visher@gmail.com> wrote:
>
> IMHO, Git under cygwin's pretty nice. I tried using MSysGit as well
> and didn't feel like it was quite as good as just building Git under
> cygwin. I also run Git on an Mac at home and while it's clearly
> faster, Git under Cygwin still beats the pants off of SVN under
> Cygwin.
If I am not mistaken Git 1.6.1 should work about twice faster under
Cygwin than previous versions with such common operations as
"git diff", "git status", because it avoids emulation of stat() in most
common cases...
>
>> But is there a way around this if i run a linux VM with Git running
>> and mount a windows ntfs partition ?
>
> Would this really be faster? I don't have a whole lot of experience
> with virtualization, but isn't Cygwin 'basically' doing this already?
No, Cygwin works very differently... In some cases, Cygwin will work
faster, but there are operations that are very costly under Cygwin
such as fork(). So, what is faster depends on what you do, and
there are many other factors here such available memory or
present some antivirus programs, which can kill performance...
But, in general, if you work on Windows, it makes much more
sense to Cygwin or MSysGit than running Git under VmWare...
Dmitry
^ permalink raw reply [relevance 4%]
* Re: [RFC PATCH] git-svn does not support intermediate directories?
2009-03-04 4:30 0% ` Tim Stoakes
@ 2009-03-06 0:12 0% ` Michael Lai
0 siblings, 0 replies; 128+ results
From: Michael Lai @ 2009-03-06 0:12 UTC (permalink / raw)
To: Tim Stoakes, git
I did some additional hacking and may have found a slightly cleaner
way of at least fixing the problems with "git svn fetch". The problem
with the wrong paths being initialized for branches and tags is fairly
minor (since you can just edit the config by hand), so I'll probably
address that later, if I have time. Here's the patch (I hope I'm
doing this right):
diff --git a/git-svn.perl b/git-svn.perl
index 959eb52..174f266 100755
--- a/git-svn.perl
+++ b/git-svn.perl
@@ -2351,7 +2351,11 @@ sub match_paths {
if (my $path = $paths->{"/$self->{path}"}) {
return ($path->{action} eq 'D') ? 0 : 1;
}
- $self->{path_regex} ||= qr/^\/\Q$self->{path}\E\//;
+ my $repos_root = $self->ra->{repos_root};
+ my $intermediate_path = $self->{url};
+ $intermediate_path =~ s#^\Q$repos_root\E(/|$)#\/#;
+ $intermediate_path .= '/' if $intermediate_path;
+ $self->{path_regex} ||= qr/^\/\Q$intermediate_path$self->{path}\E\//;
if (grep /$self->{path_regex}/, keys %$paths) {
return 1;
}
--
On Tue, Mar 3, 2009 at 8:30 PM, Tim Stoakes <tim@stoakes.net> wrote:
> Michael Lai(myllai@gmail.com)@030309-17:43:
>> After spending some hours struggling with git svn, it would appear
>> that it does not support svn projects stored in paths similar to
>> "http://foo.com/svn/repos/bar/myproject", where "myproject" uses the
>> standard SVN tags/trunk/branches layout. I'm currently using git
>> 1.6.1, though I tried this with 1.6.2-rc2 as well. The resulting
>> .git/config looks something like this:
>>
>> [svn-remote "svn"]
>> url = http://foo.com/svn/repos/bar
>> fetch = myproject/trunk:refs/remotes/trunk
>> branches = bar/myproject/branches/*:refs/remotes/*
>> tags = bar/myproject/tags/*:refs/remotes/tags/*
>>
>> Yes, that's a redundant "bar" directory under "branches =" and "tags
>> =". The issue seems to lie in git-svn doing something intelligent to
>> extract the appropriate trunk directory. For the branches and tags,
>> however, it just takes the full URL and removes the repository root
>> (http://foo.com/svn/repos/bar) to produce "bar/myproject/{branches,
>> tags}/*". The second effect is that "git svn fetch" will run but exit
>> quietly without actually pulling anything from the repository. I
>> tracked down an existing thread on the mailing list from a while ago
>> (Feb 4th, title of "git-svn doesn't fetch anything"), but there was no
>> resolution.
>
> I've just run into this exact same issue.
>
>> There is a quick workaround, which was to make this change to match_paths:
>> < $self->{path_regex} ||= qr/^\/\Q$self->{path}\E\//;
>> ---
>> > $self->{path_regex} ||= qr/\/\Q$self->{path}\E\//;
>>
>> The additional "bar" directory gets pulled in when git-svn tries to
>> determine what paths to pull down, and tries to match
>> "/myproject/trunk" to "/bar/myproject/trunk". I've merely put a
>> band-aid on the situation. My perl is rudimentary at best, or I'd
>> have spent additional time to try to put in a "proper" patch, but was
>> wondering if anyone else had run into this problem and would be
>> willing to put in a fix (or point me in the right direction, that
>> works too).
>
> I messed about with disabling $Git::SVN::_minimize_url, but that seemed
> to break other things.
>
> Made worse for me was the fact that my 'bar' in the present was renamed
> from 'baz' in the past, so git-svn couldn't find it at r1. Very
> confusing!
>
> I'd like a nicer solution too.
>
> Tim
>
> --
> Tim Stoakes
>
^ permalink raw reply related [relevance 0%]
* Re: git-svn does not support intermediate directories?
2009-03-04 1:43 3% git-svn does not support intermediate directories? Michael Lai
@ 2009-03-04 4:30 0% ` Tim Stoakes
2009-03-06 0:12 0% ` [RFC PATCH] " Michael Lai
0 siblings, 1 reply; 128+ results
From: Tim Stoakes @ 2009-03-04 4:30 UTC (permalink / raw)
To: Michael Lai; +Cc: git
Michael Lai(myllai@gmail.com)@030309-17:43:
> After spending some hours struggling with git svn, it would appear
> that it does not support svn projects stored in paths similar to
> "http://foo.com/svn/repos/bar/myproject", where "myproject" uses the
> standard SVN tags/trunk/branches layout. I'm currently using git
> 1.6.1, though I tried this with 1.6.2-rc2 as well. The resulting
> .git/config looks something like this:
>
> [svn-remote "svn"]
> url = http://foo.com/svn/repos/bar
> fetch = myproject/trunk:refs/remotes/trunk
> branches = bar/myproject/branches/*:refs/remotes/*
> tags = bar/myproject/tags/*:refs/remotes/tags/*
>
> Yes, that's a redundant "bar" directory under "branches =" and "tags
> =". The issue seems to lie in git-svn doing something intelligent to
> extract the appropriate trunk directory. For the branches and tags,
> however, it just takes the full URL and removes the repository root
> (http://foo.com/svn/repos/bar) to produce "bar/myproject/{branches,
> tags}/*". The second effect is that "git svn fetch" will run but exit
> quietly without actually pulling anything from the repository. I
> tracked down an existing thread on the mailing list from a while ago
> (Feb 4th, title of "git-svn doesn't fetch anything"), but there was no
> resolution.
I've just run into this exact same issue.
> There is a quick workaround, which was to make this change to match_paths:
> < $self->{path_regex} ||= qr/^\/\Q$self->{path}\E\//;
> ---
> > $self->{path_regex} ||= qr/\/\Q$self->{path}\E\//;
>
> The additional "bar" directory gets pulled in when git-svn tries to
> determine what paths to pull down, and tries to match
> "/myproject/trunk" to "/bar/myproject/trunk". I've merely put a
> band-aid on the situation. My perl is rudimentary at best, or I'd
> have spent additional time to try to put in a "proper" patch, but was
> wondering if anyone else had run into this problem and would be
> willing to put in a fix (or point me in the right direction, that
> works too).
I messed about with disabling $Git::SVN::_minimize_url, but that seemed
to break other things.
Made worse for me was the fact that my 'bar' in the present was renamed
from 'baz' in the past, so git-svn couldn't find it at r1. Very
confusing!
I'd like a nicer solution too.
Tim
--
Tim Stoakes
^ permalink raw reply [relevance 0%]
* git-svn does not support intermediate directories?
@ 2009-03-04 1:43 3% Michael Lai
2009-03-04 4:30 0% ` Tim Stoakes
0 siblings, 1 reply; 128+ results
From: Michael Lai @ 2009-03-04 1:43 UTC (permalink / raw)
To: git
Hey all,
After spending some hours struggling with git svn, it would appear
that it does not support svn projects stored in paths similar to
"http://foo.com/svn/repos/bar/myproject", where "myproject" uses the
standard SVN tags/trunk/branches layout. I'm currently using git
1.6.1, though I tried this with 1.6.2-rc2 as well. The resulting
.git/config looks something like this:
[svn-remote "svn"]
url = http://foo.com/svn/repos/bar
fetch = myproject/trunk:refs/remotes/trunk
branches = bar/myproject/branches/*:refs/remotes/*
tags = bar/myproject/tags/*:refs/remotes/tags/*
Yes, that's a redundant "bar" directory under "branches =" and "tags
=". The issue seems to lie in git-svn doing something intelligent to
extract the appropriate trunk directory. For the branches and tags,
however, it just takes the full URL and removes the repository root
(http://foo.com/svn/repos/bar) to produce "bar/myproject/{branches,
tags}/*". The second effect is that "git svn fetch" will run but exit
quietly without actually pulling anything from the repository. I
tracked down an existing thread on the mailing list from a while ago
(Feb 4th, title of "git-svn doesn't fetch anything"), but there was no
resolution.
There is a quick workaround, which was to make this change to match_paths:
< $self->{path_regex} ||= qr/^\/\Q$self->{path}\E\//;
---
> $self->{path_regex} ||= qr/\/\Q$self->{path}\E\//;
The additional "bar" directory gets pulled in when git-svn tries to
determine what paths to pull down, and tries to match
"/myproject/trunk" to "/bar/myproject/trunk". I've merely put a
band-aid on the situation. My perl is rudimentary at best, or I'd
have spent additional time to try to put in a "proper" patch, but was
wondering if anyone else had run into this problem and would be
willing to put in a fix (or point me in the right direction, that
works too).
Thanks,
Mike
^ permalink raw reply [relevance 3%]
* Re: post-receive email
2009-02-18 12:44 4% post-receive email Arya, Manish Kumar
@ 2009-02-18 13:36 0% ` Patrick Notz
0 siblings, 0 replies; 128+ results
From: Patrick Notz @ 2009-02-18 13:36 UTC (permalink / raw)
To: Arya, Manish Kumar; +Cc: git
On Wed, Feb 18, 2009 at 5:44 AM, Arya, Manish Kumar <m.arya@yahoo.com> wrote:
>
> Hi,
>
> I am using git 1.6.1
>
> I have configured post-receive hook for sending emails on remote push activity.
Are you using the example contrib/hooks/post-receive-email that comes with Git?
>
> But I am getting this error while push. any one using this script for email. can you suggest some other working script for this ?
>
> ----------------------------------
> Counting objects: 5, done.
> Compressing objects: 100% (3/3) Compressing objects: 100% (3/3), done.
> Writing objects: 100% (3/3) Writing objects: 100% (3/3), 344 bytes, done.
> Total 3 (delta 1), reused 0 (delta 0)
> hooks/post-receive: syntax error at line 73: `oldrev=$' unexpected
> error: hooks/post-receive exited with error code 2
> Pushing to ssh://xxx.xxx.xxx.net/opt/repos/mka.git
> To ssh://xxx.xxx.xxx.net/opt/repos/mka.git
> db4b382..186b0af master -> master
> -----------------------------------
>
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [relevance 0%]
* post-receive email
@ 2009-02-18 12:44 4% Arya, Manish Kumar
2009-02-18 13:36 0% ` Patrick Notz
0 siblings, 1 reply; 128+ results
From: Arya, Manish Kumar @ 2009-02-18 12:44 UTC (permalink / raw)
To: git
Hi,
I am using git 1.6.1
I have configured post-receive hook for sending emails on remote push activity.
But I am getting this error while push. any one using this script for email. can you suggest some other working script for this ?
----------------------------------
Counting objects: 5, done.
Compressing objects: 100% (3/3) Compressing objects: 100% (3/3), done.
Writing objects: 100% (3/3) Writing objects: 100% (3/3), 344 bytes, done.
Total 3 (delta 1), reused 0 (delta 0)
hooks/post-receive: syntax error at line 73: `oldrev=$' unexpected
error: hooks/post-receive exited with error code 2
Pushing to ssh://xxx.xxx.xxx.net/opt/repos/mka.git
To ssh://xxx.xxx.xxx.net/opt/repos/mka.git
db4b382..186b0af master -> master
-----------------------------------
^ permalink raw reply [relevance 4%]
* Re: segfault during clone via http
2009-02-04 16:10 4% segfault during clone via http Adam Thorsen
@ 2009-02-04 18:00 0% ` Jay Soffian
0 siblings, 0 replies; 128+ results
From: Jay Soffian @ 2009-02-04 18:00 UTC (permalink / raw)
To: Adam Thorsen; +Cc: git
On Wed, Feb 4, 2009 at 11:10 AM, Adam Thorsen <adam.thorsen@gmail.com> wrote:
> Git is segfaulting when downloading from a repo via http. Here's what the
> output looks like: http://gist.github.com/58167. Anybody seen this before or
> know how I can debug it? I've made sure my git (1.6.1) is compiled with libcurl.
Please run git under gdb so that there is a stacktrace to work from. Here is an
example of running git under gdb and providing a trace:
http://article.gmane.org/gmane.comp.version-control.git/107860
j.
^ permalink raw reply [relevance 0%]
* segfault during clone via http
@ 2009-02-04 16:10 4% Adam Thorsen
2009-02-04 18:00 0% ` Jay Soffian
0 siblings, 1 reply; 128+ results
From: Adam Thorsen @ 2009-02-04 16:10 UTC (permalink / raw)
To: git
Git is segfaulting when downloading from a repo via http. Here's what the
output looks like: http://gist.github.com/58167. Anybody seen this before or
know how I can debug it? I've made sure my git (1.6.1) is compiled with libcurl.
^ permalink raw reply [relevance 4%]
* [ANNOUNCE] CGIT 0.8.2
@ 2009-02-01 18:57 3% Lars Hjemli
0 siblings, 0 replies; 128+ results
From: Lars Hjemli @ 2009-02-01 18:57 UTC (permalink / raw)
To: Git Mailing List
Feature-release 0.8.2 (+ bugfix release 0.8.1.1) of cgit, a fast
webinterface for git, is now available:
Clone: git://hjemli.net/pub/git/cgit
Browse: http://hjemli.net/git/cgit
The highlights:
* The repository list can now be sorted on any column
* The shortlog can be expanded to show full commit messages
* New stats-view shows simple time/author-related statistics
* Log- and commit-view are now decorated with refnames
* Binary files are properly handled in diff- and plain-views (aka `hexdump -C`)
* Working text-selection in plain-view
* Plenty of bugfixes
Big thanks to everyone who provided patches, ideas and feedback!
Bugfixes included in 0.8.1.1
============================
Karl Chen (1):
Use mode 0644 for non-executable files
Lars Hjemli (13):
Use GIT-1.6.0.3
ui-repolist: handle empty agefiles
ui-log: try to disambiguate ref names
Makefile: allow cgit.conf to override platform-specific tweaks
ui-repolist: avoid build warning for strcasestr(3)
parsing.c: enable builds with NO_ICONV defined
tests/t0010-validate-html.sh: skip tests if 'tidy' is not available
tests/setup.sh: allow testsuite to fail properly with POSIX standard shell
ui-tree.c: do not add blank line when displaying blobs
Makefile: avoid libcurl when building git
ui-tag: escape tagnames properly
Avoid SEGFAULT on invalid requests
CGIT 0.8.1.1
Ramsay Jones (3):
Fix some warnings to allow -Werror
Fix tests to work on Ubuntu (dash)
Extra cygwin-specific changes
Todd Zullinger (3):
Fix tar.bz2 snapshot example
Makefile: add INSTALL var to set install command
Makefile: install cgit.{css,png} in CGIT_DATA_PATH
Tomas Carnecky (1):
ui-patch: whitespace changes in the patch generation code
Additional changes in 0.8.2
===========================
Benjamin Close (1):
Add support for sorting by Age in the repolist
Justin Waters (2):
Change toggle to more meaningful term
Add decorations to commit pages
Lars Hjemli (33):
ui-repolist: extract get_repo_modtime() from print_modtime()
ui-repolist: add support for sorting any column
ui-repolist: sort null values last
ui-repolist: implement lazy caching of repo->mtime
ui-log: add support for showing the full commit message
ui-log: (ab)use extra columns for commit message when showmsg=1
ui-log: use css to make full-log prettier
ui-snapshot: improve extraction of revision from snapshot name
ui-shared: exploit snapshot dwimmery in cgit_print_snapshot_links
ui-refs.c: show download links for all tags referring to commit objects
ui-shared: shorten the sha1 printed by cgit_object_link
Add a 'stats' page to each repo
ui-stats: enable path-filtered stats
ui-stats: replace 'enable-stats' setting with 'max-stats'
ui-shared: add and use cgit_stats_link()
ui-tree: add link to stats page per path
ui-shared: externalize add_hidden_formfields()
ui-stats.c: reuse cgit_add_hidden_formfields()
Untie logic for SCRIPT_NAME and PATH_INFO
shared.c: future-proof usage of git diff-structures
Use GIT-1.6.1
ui-snapshot.c: change mime-type for tar.gz and tar.bz2
tests/t0107-snapshot.sh: make testscript match updated snapshot behavior
ui-log: show name-decorations in log output
cgit.css: minor adjustment of commit decorations
tests/t0105-commit.sh: expect commit decorations
Add support for a custom header
html.c: use correct escaping in html attributes
Handle binary files in diffs
ui-tree: show hexdump of binary blobs
shared.c: avoid SEGFAULT when checking for binary buffers
Use GIT-1.6.1.1
CGIT 0.8.2
Natanael Copa (2):
Set prefix in snapshots when using dwimmery
return 404 if snapshot is not found
Onne Gorter (1):
changed objects are outputted, allowing for selections of code only
Robin Redeker (2):
ui-refs: avoid SEGFAULT on lightweight tags
Make all tags viewable
^ permalink raw reply [relevance 3%]
* Re: 'git clone' doesn't use alternates automatically?
2009-01-30 22:12 4% 'git clone' doesn't use alternates automatically? James Pickens
@ 2009-01-31 7:12 0% ` Jeff King
0 siblings, 0 replies; 128+ results
From: Jeff King @ 2009-01-31 7:12 UTC (permalink / raw)
To: James Pickens; +Cc: Git ML
On Fri, Jan 30, 2009 at 03:12:42PM -0700, James Pickens wrote:
> I have a central, shared Git repository on an NFS drive at path
> $central. I have added "$central/objects" to
> $central/objects/info/alternates. I see that when I clone this
> repository with Git 1.6.1, the alternates file is automatically copied
> to the clone, but so are all the pack files and loose objects. If I
> then cd to the clone and run 'git gc', it removes the redundant local
> objects.
Yes, we don't set up alternates to an origin by default. If it's a local
clone, we do hardlink by default:
$ ls -i git/.git/objects/pack
7639155 pack-0651ae7e35ffde1921db158a3292e1c81153be1a.idx
7638782 pack-0651ae7e35ffde1921db158a3292e1c81153be1a.pack
$ git clone git foo
...
$ ls -i foo/.git/objects/pack
7639155 pack-0651ae7e35ffde1921db158a3292e1c81153be1a.idx
7638782 pack-0651ae7e35ffde1921db158a3292e1c81153be1a.pack
but presumably in your example the second clone is _not_ on the NFS
mount, and therefore can't hardlink.
So you can try "git clone -s" to specify that you definitely want
alternates.
> I thought I tested this setup a few months back, and 'git clone'
> automatically used the alternates file to avoid copying the redundant
> objects into the clone. Has this behavior changed, or is my memory
> bad?
I don't recall clone ever being that clever, but I could be wrong (it is
not an area of the code that I am too familiar with).
Can you try a test with a few different versions to see if it ever
behaved as you expected (and if it does, bisect to find the breakage)?
-Peff
^ permalink raw reply [relevance 0%]
* 'git clone' doesn't use alternates automatically?
@ 2009-01-30 22:12 4% James Pickens
2009-01-31 7:12 0% ` Jeff King
0 siblings, 1 reply; 128+ results
From: James Pickens @ 2009-01-30 22:12 UTC (permalink / raw)
To: Git ML
Hi,
I have a central, shared Git repository on an NFS drive at path
$central. I have added "$central/objects" to
$central/objects/info/alternates. I see that when I clone this
repository with Git 1.6.1, the alternates file is automatically copied
to the clone, but so are all the pack files and loose objects. If I
then cd to the clone and run 'git gc', it removes the redundant local
objects.
I thought I tested this setup a few months back, and 'git clone'
automatically used the alternates file to avoid copying the redundant
objects into the clone. Has this behavior changed, or is my memory
bad?
James
^ permalink raw reply [relevance 4%]
* Re: Emacs git-mode feature request: support fill-paragraph correctly
2009-01-28 21:32 0% ` Junio C Hamano
@ 2009-01-29 10:42 0% ` Alexandre Julliard
0 siblings, 0 replies; 128+ results
From: Alexandre Julliard @ 2009-01-29 10:42 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Peter Simons
Junio C Hamano <gitster@pobox.com> writes:
> Peter Simons <simons@cryp.to> writes:
>
>> that patch has the desired effect (tested with GNU Emacs 22.3.1 and
>> GIT 1.6.1). Thank you very much.
>>
>> Now, I'd be hugely in favor of applying that change to the repository
>> so that future versions of GIT have it.
>
> Alexandre?
Sure, I'll include it in my next pull request.
--
Alexandre Julliard
julliard@winehq.org
^ permalink raw reply [relevance 0%]
* [ANNOUNCE] GIT 1.6.1.2
@ 2009-01-29 10:16 4% Junio C Hamano
0 siblings, 0 replies; 128+ results
From: Junio C Hamano @ 2009-01-29 10:16 UTC (permalink / raw)
To: git; +Cc: linux-kernel
The latest maintenance release GIT 1.6.1.2 is available at the
usual places:
http://www.kernel.org/pub/software/scm/git/
git-1.6.1.2.tar.{gz,bz2} (source tarball)
git-htmldocs-1.6.1.2.tar.{gz,bz2} (preformatted docs)
git-manpages-1.6.1.2.tar.{gz,bz2} (preformatted docs)
The RPM binary packages for a few architectures are also provided
as courtesy.
RPMS/$arch/git-*-1.6.1.2-1.fc9.$arch.rpm (RPM)
People with 1.6.1 or 1.6.1.1, who push into a repository that borrows
objects from other repositories via "alternates" mechanism (most of the
linux kernel subsystems hosted on k.org, and "forks" on various public
hosting site such as repo.or.cz and github fall into this category), may
want to upgrade to this version, as these two versions have a buggy "git
push" that does not like such a repository served by git 1.6.1 or newer.
GIT v1.6.1.2 Release Notes
==========================
Fixes since v1.6.1.1
--------------------
* The logic for rename detectin in internal diff used by commands like
"git diff" and "git blame" have been optimized to avoid loading the same
blob repeatedly.
* We did not allow writing out a blob that is larger than 2GB for no good
reason.
* "git format-patch -o $dir", when $dir is a relative directory, used it
as relative to the root of the work tree, not relative to the current
directory.
* v1.6.1 introduced an optimization for "git push" into a repository (A)
that borrows its objects from another repository (B) to avoid sending
objects that are available in repository B, when they are not yet used
by repository A. However the code on the "git push" sender side was
buggy and did not work when repository B had new objects that are not
known by the sender. This caused pushing into a "forked" repository
served by v1.6.1 software using "git push" from v1.6.1 sometimes did not
work. The bug was purely on the "git push" sender side, and has been
corrected.
* "git status -v" did not paint its diff output in colour even when
color.ui configuration was set.
* "git ls-tree" learned --full-tree option to help Porcelain scripts that
want to always see the full path regardless of the current working
directory.
* "git grep" incorrectly searched in work tree paths even when they are
marked as assume-unchanged. It now searches in the index entries.
* "git gc" with no grace period needlessly ejected packed but unreachable
objects in their loose form, only to delete them right away.
----------------------------------------------------------------
Changes since v1.6.1.1 are as follows:
Björn Steinbrink (1):
Rename detection: Avoid repeated filespec population
Jeff King (1):
avoid 31-bit truncation in write_loose_object
Johannes Schindelin (2):
get_sha1_basic(): fix invalid memory access, found by valgrind
test-path-utils: Fix off by one, found by valgrind
Junio C Hamano (4):
ls-tree: add --full-tree option
Teach format-patch to handle output directory relative to cwd
send-pack: do not send unknown object name from ".have" to pack-objects
GIT 1.6.1.2
Marcel M. Cary (1):
git-sh-setup: Fix scripts whose PWD is a symlink to a work-dir on OS X
Markus Heidelberg (2):
git-commit: color status output when color.ui is set
git-status -v: color diff output when color.ui is set
Nanako Shiraishi (1):
Document git-ls-tree --full-tree
Nguyễn Thái Ngọc Duy (2):
grep: support --no-ext-grep to test builtin grep
grep: grep cache entries if they are "assume unchanged"
Nicolas Pitre (1):
objects to be pruned immediately don't have to be loosened
^ permalink raw reply [relevance 4%]
* Re: Git SVN fetch failing on large commit
2009-01-29 1:24 5% Git SVN fetch failing on large commit Andrew Selder
@ 2009-01-29 3:43 0% ` Andrew Selder
0 siblings, 0 replies; 128+ results
From: Andrew Selder @ 2009-01-29 3:43 UTC (permalink / raw)
To: git
Andrew Selder <aselder <at> mac.com> writes:
>
> Hi,
>
> I'm trying to import an SVN repository and I'm running into trouble on a huge
> SVN revision.
>
> One of the revisions in SVN has a 1.25 GB file. When the git svn fetch process
> gets to this revision, it crashed with the following message:
>
> fatal: Out of memory, malloc failed
> hash-object -w --stdin-paths: command returned error: 128
> This is running on a machine with 3 GB of memory (2.5 GB free before starting
> git svn), Git 1.6.1, Git-svn 1.6.1(svn 1.5.1)
Upgraded to Git 1.6.1.1, but still the same results. I saw the --ignore-paths
option online, but it doesn't seem to be in the lastest version. This would
probably work for me. Does anybody know when that feature is scheduled for
release?
^ permalink raw reply [relevance 0%]
* Git SVN fetch failing on large commit
@ 2009-01-29 1:24 5% Andrew Selder
2009-01-29 3:43 0% ` Andrew Selder
0 siblings, 1 reply; 128+ results
From: Andrew Selder @ 2009-01-29 1:24 UTC (permalink / raw)
To: git
Hi,
I'm trying to import an SVN repository and I'm running into trouble on a huge
SVN revision.
One of the revisions in SVN has a 1.25 GB file. When the git svn fetch process
gets to this revision, it crashed with the following message:
fatal: Out of memory, malloc failed
hash-object -w --stdin-paths: command returned error: 128
error closing pipe: Bad file descriptor at /usr/local/libexec/git-core//git-svn
line 0
error closing pipe: Bad file descriptor at /usr/local/libexec/git-core//git-svn
line 0
This is running on a machine with 3 GB of memory (2.5 GB free before starting
git svn), Git 1.6.1, Git-svn 1.6.1(svn 1.5.1)
Help would be greatly appreciated.
^ permalink raw reply [relevance 5%]
* Re: Emacs git-mode feature request: support fill-paragraph correctly
2009-01-27 14:07 4% ` Peter Simons
@ 2009-01-28 21:32 0% ` Junio C Hamano
2009-01-29 10:42 0% ` Alexandre Julliard
0 siblings, 1 reply; 128+ results
From: Junio C Hamano @ 2009-01-28 21:32 UTC (permalink / raw)
To: Alexandre Julliard; +Cc: git, Peter Simons
Peter Simons <simons@cryp.to> writes:
> Hi Alexandre,
>
> > diff --git a/contrib/emacs/git.el b/contrib/emacs/git.el
> > index 3c37d0d..e314c44 100644
> > --- a/contrib/emacs/git.el
> > +++ b/contrib/emacs/git.el
> > @@ -1331,6 +1331,7 @@ Return the list of files that haven't been handled."
> > (log-edit-diff-function . git-log-edit-diff)) buffer)
> > (log-edit 'git-do-commit nil 'git-log-edit-files buffer))
> > (setq font-lock-keywords (font-lock-compile-keywords git-log-edit-font-lock-keywords))
> > + (setq paragraph-separate (concat (regexp-quote git-log-msg-separator) "$\\|Author: \\|Date: \\|Merge: \\|Signed-off-by: \\|\f\\|[ ]*$"))
> > (setq buffer-file-coding-system coding-system)
> > (re-search-forward (regexp-quote (concat git-log-msg-separator "\n")) nil t))))
>
> that patch has the desired effect (tested with GNU Emacs 22.3.1 and
> GIT 1.6.1). Thank you very much.
>
> Now, I'd be hugely in favor of applying that change to the repository
> so that future versions of GIT have it.
Alexandre?
^ permalink raw reply [relevance 0%]
* Re: git 1.6.1 on AIX 5.3
2009-01-28 7:42 5% ` Jeff King
@ 2009-01-28 15:03 5% ` Perry Smith
0 siblings, 0 replies; 128+ results
From: Perry Smith @ 2009-01-28 15:03 UTC (permalink / raw)
To: Jeff King; +Cc: Junio C Hamano, Mike Ralphson, git
On Jan 28, 2009, at 1:42 AM, Jeff King wrote:
> On Tue, Jan 27, 2009 at 11:37:21PM -0800, Junio C Hamano wrote:
>
>>>> Just to be sure we are on the same page. My directory structure
>>>> has a
>>>> top/src/git-1.6.1 and top/build/git.1.6.1. The src/git-1.6.1 is
>>>> the
>>>> tar ball. The build/git-1.6.1 starts out empty. I cd into it and
>>>> then do: ../../src/git-1.6.1/configure <options> After this
>>>> completes, you can do "make".
>>>
>>> I don't see how this would work without automake support, which
>>> git does
>>> not have.
>>
>> ... nor want to have ;-).
>
> Heh. Yes, in case there was any confusion: I don't want my statement
> in
> any way to be construed as a suggestion to support automake.
>
> I would not be opposed to it if it somehow enhanced some users'
> experience without bothering people who didn't want to touch it (like
> the way that autoconf support is implemented). But I don't see how
> that
> would be possible.
Thats fine. I didn't know if this was a "known" situation or not so I
just mentioned it.
As I mentioned, most open source code supports this style of build. I
have no idea
what it would take to get it to work.
^ permalink raw reply [relevance 5%]
* Re: git 1.6.1 on AIX 5.3
2009-01-28 1:35 11% ` Perry Smith
2009-01-28 7:01 5% ` Jeff King
@ 2009-01-28 9:48 5% ` Mike Ralphson
1 sibling, 0 replies; 128+ results
From: Mike Ralphson @ 2009-01-28 9:48 UTC (permalink / raw)
To: Perry Smith; +Cc: git, Jeff King
2009/1/28 Perry Smith <pedzsan@gmail.com>:
> Sorry... I thought "out of tree" was a universal term.
No, my mistake, I didn't think about what you meant.
> About 90% of the open source configure / autoconf code out there can do this
> with. The other 10% you can not. I like it because when things die, its easier to
> grep around the source tree and I blow away the build directory and start back over and
> I know that I'm starting fresh.
Even if you're only building git, unless disc space is tight, I'd
probably recommend cloning the git.git repository, then you can either
use make clean or git clean, plus it makes updating to
latest/arbitrary versions easier. Anyway, I don't think your setup is
wrong.
> Yea, part of my larger quest is to start a web site to provide AIX builds
> of open source images as installp images. I have not added iconv to the
> mix yet because I fear bad interactions with GNU's and AIX's. In theory,
> AIX's commands should use AIX's library but it would not surprise me if there are
> a few AIX applications that are not built properly.
A pity package distribution for AIX is so fragmented, but when IBM had
the ball, they dropped it. Mail me if you want links to other existing
sites who might appreciate contributed builds.
> I assume the GIT_SKIP_TESTS is done:
It's documented in test/README
> I just tried setting SHELL_PATH (and exporting it) and the make test gets
> into the second batch and then fails two tests. ... now test 10 of t0001.sh
> fails because test_cmp can not be found.
>
> Is that a GNU tool? (I didn't see it in git or coreutils.)
As Peff said, there's a wrapper around either diff -u or a user
supplied comparison tool (e.g. cmp) set in GIT_TEST_CMP. Setting it to
cmp works fine on AIX if you don't have a diff which takes -u on your
PATH.
As (at the moment) you need bash, gcc, gmake and ginstall to build,
test and (maybe) run all parts of git on AIX, I haven't set up a clean
environment to try and flush out any other quirks to get git to
build/test/run on a stock AIX with no GNU tools installed. For obvious
reasons such AIX machines being used for dev purposes are (I believe)
rare.
Mike
^ permalink raw reply [relevance 5%]
* Re: git 1.6.1 on AIX 5.3
2009-01-28 7:37 5% ` Junio C Hamano
@ 2009-01-28 7:42 5% ` Jeff King
2009-01-28 15:03 5% ` Perry Smith
0 siblings, 1 reply; 128+ results
From: Jeff King @ 2009-01-28 7:42 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Perry Smith, Mike Ralphson, git
On Tue, Jan 27, 2009 at 11:37:21PM -0800, Junio C Hamano wrote:
> >> Just to be sure we are on the same page. My directory structure has a
> >> top/src/git-1.6.1 and top/build/git.1.6.1. The src/git-1.6.1 is the
> >> tar ball. The build/git-1.6.1 starts out empty. I cd into it and
> >> then do: ../../src/git-1.6.1/configure <options> After this
> >> completes, you can do "make".
> >
> > I don't see how this would work without automake support, which git does
> > not have.
>
> ... nor want to have ;-).
Heh. Yes, in case there was any confusion: I don't want my statement in
any way to be construed as a suggestion to support automake.
I would not be opposed to it if it somehow enhanced some users'
experience without bothering people who didn't want to touch it (like
the way that autoconf support is implemented). But I don't see how that
would be possible.
-Peff
^ permalink raw reply [relevance 5%]
* Re: git 1.6.1 on AIX 5.3
2009-01-28 7:01 5% ` Jeff King
@ 2009-01-28 7:37 5% ` Junio C Hamano
2009-01-28 7:42 5% ` Jeff King
0 siblings, 1 reply; 128+ results
From: Junio C Hamano @ 2009-01-28 7:37 UTC (permalink / raw)
To: Jeff King; +Cc: Perry Smith, Mike Ralphson, git
Jeff King <peff@peff.net> writes:
> On Tue, Jan 27, 2009 at 07:35:00PM -0600, Perry Smith wrote:
>
>> Just to be sure we are on the same page. My directory structure has a
>> top/src/git-1.6.1 and top/build/git.1.6.1. The src/git-1.6.1 is the
>> tar ball. The build/git-1.6.1 starts out empty. I cd into it and
>> then do: ../../src/git-1.6.1/configure <options> After this
>> completes, you can do "make".
>
> I don't see how this would work without automake support, which git does
> not have.
... nor want to have ;-).
^ permalink raw reply [relevance 5%]
* Re: git 1.6.1 on AIX 5.3
2009-01-28 1:35 11% ` Perry Smith
@ 2009-01-28 7:01 5% ` Jeff King
2009-01-28 7:37 5% ` Junio C Hamano
2009-01-28 9:48 5% ` Mike Ralphson
1 sibling, 1 reply; 128+ results
From: Jeff King @ 2009-01-28 7:01 UTC (permalink / raw)
To: Perry Smith; +Cc: Mike Ralphson, git
On Tue, Jan 27, 2009 at 07:35:00PM -0600, Perry Smith wrote:
> Just to be sure we are on the same page. My directory structure has a
> top/src/git-1.6.1 and top/build/git.1.6.1. The src/git-1.6.1 is the
> tar ball. The build/git-1.6.1 starts out empty. I cd into it and
> then do: ../../src/git-1.6.1/configure <options> After this
> completes, you can do "make".
I don't see how this would work without automake support, which git does
not have. The configure script just generates a config.mak.autogen file,
which is included by the Makefile. So you have no Makefile in your build
directory.
> About 90% of the open source configure / autoconf code out there can
> do this with. The other 10% you can not. I like it because when
> things die, its easier to grep around the source tree and I blow away
> the build directory and start back over and I know that I'm starting
> fresh.
Another way of solving the same problem:
cd untarred-sources
git init
git add .
git commit -m 'pristine sources'
Now you can use "git clean" to clean up cruft, not to mention the usual
git stuff like tracking any changes you've made and submitting any
patches upstream.
> I get further. But now test 10 of t0001.sh fails because test_cmp can
> not be found.
>
> Is that a GNU tool? (I didn't see it in git or coreutils.)
It's a shell function defined in test-lib.sh (which is sourced by all of
the test scripts).
-Peff
^ permalink raw reply [relevance 5%]
* Re: git 1.6.1 on AIX 5.3
2009-01-27 10:10 5% ` Mike Ralphson
@ 2009-01-28 1:35 11% ` Perry Smith
2009-01-28 7:01 5% ` Jeff King
2009-01-28 9:48 5% ` Mike Ralphson
0 siblings, 2 replies; 128+ results
From: Perry Smith @ 2009-01-28 1:35 UTC (permalink / raw)
To: Mike Ralphson; +Cc: git, Jeff King
On Jan 27, 2009, at 4:10 AM, Mike Ralphson wrote:
> 2009/1/26 Perry Smith <pedzsan@gmail.com>:
>> Thanks guys. I picked up coreutils version 7. I didn't
>> install them but just moved ginstall over to /usr/local/bin.
>>
>> A few other comments: I had to add in the --without-tcltk flag. I
>> don't
>> have tcl installed but the config did not autodetect that it was
>> not present.
>
> Yup, I usually build with NO_TCLTK=YesPlease in my config.mak, which
> you can see from the link Peff posted.
>
> When you said 'out of tree builds' I thought you meant using the AIX
> defaults in the Makefile without running ./configure, but it seems
> not, you meant is a clone of the tree buildable by itself or are only
> release snapshots buildable. Sorry.
Sorry... I thought "out of tree" was a universal term.
Just to be sure we are on the same page. My directory structure has a
top/src/git-1.6.1
and top/build/git.1.6.1. The src/git-1.6.1 is the tar ball. The
build/git-1.6.1 starts out
empty. I cd into it and then do: ../../src/git-1.6.1/configure
<options> After this completes,
you can do "make".
About 90% of the open source configure / autoconf code out there can
do this with.
The other 10% you can not. I like it because when things die, its
easier to grep around
the source tree and I blow away the build directory and start back
over and I know that
I'm starting fresh.
>
>
> ./configure is (deliberately) a second-class citizen in the world of
> git, and may still get you a slightly suboptimal build compared with
> the defaults on platforms such as AIX... e.g. it doesn't test for
> performance-related switches such as INTERNAL_QSORT. If you have run
> configure, there's some file you need to blow away to get back to a
> non-autoconf world... is it config.mak.autogen?
>
> Despite that, your problem with --without-tcltk falling back to wish,
> but not falling back if that isn't installed does look like something
> we should fix, as per Peff's mail.
>
>> I can't tell if make test is happy or not. The output looks like
>> its happy
>> but the exit code is 2.
>>
>> Below is my "configure" script if anyone is interested.
>>
>> #!/usr/bin/env bash
>>
>> export CONFIG_SHELL=/usr/local/bin/bash
>> export LDFLAGS='-L/usr/local/lib -L/usr/local/ssl/lib'
>> export CFLAGS='-I/usr/local/include -I/usr/local/ssl/include'
>> export CC=gcc
>> echo CONFIG_SHELL set to ${CONFIG_SHELL}
>>
>> ${CONFIG_SHELL} ../../src/git-1.6.1/configure --without-tcltk
>>
>> #
>> # Note that to install you need to do:
>> # make INSTALL=ginstall install
>> # to use GNU's install program
>
> I build with SHELL_PATH={path}/bash as well. If I don't, the test
> suite exits after t0000-basic.sh with an unexpected error despite
> passing all the tests.
>
> gmake -C t/ all
> gmake[1]: Entering directory `/usr/local/src/gitbuild/t'
> rm -f -r test-results
> gmake aggregate-results-and-cleanup
> gmake[2]: Entering directory `/usr/local/src/gitbuild/t'
> *** t0000-basic.sh ***
> * passed all remaining 40 test(s)
> FATAL: Unexpected exit with code 0
> gmake[2]: *** [t0000-basic.sh] Error 1
> gmake[2]: Leaving directory `/usr/local/src/gitbuild/t'
> gmake[1]: *** [all] Error 2
> gmake[1]: Leaving directory `/usr/local/src/gitbuild/t'
> gmake: *** [test] Error 2
>
> Is that what you're seeing? There's many more test scripts than that
> 8-)
>
> With GIT_SKIP_TESTS='t3900 t3901 t5100.[12] t8005' (to omit some cases
> not handled by the version of iconv I have access to on all the AIX
> boxes I deploy to) the test suit runs to completion on AIX 5.3 for me.
Yea, part of my larger quest is to start a web site to provide AIX
builds
of open source images as installp images. I have not added iconv to the
mix yet because I fear bad interactions with GNU's and AIX's. In
theory, AIX's
commands should use AIX's library but it would not surprise me if
there are
a few AIX applications that are not built properly.
>
>
> BTW Are you running AIX's make or GNU make?
yes -- GNU's make and gcc 4.3.1
I just tried setting SHELL_PATH (and exporting it) and the make test
gets into
the second batch and then fails two tests. I assume the
GIT_SKIP_TESTS is
done:
make GIT_SKIP_TESTS=....test
I get further. But now test 10 of t0001.sh fails because test_cmp can
not be found.
Is that a GNU tool? (I didn't see it in git or coreutils.)
(I'll go searching for it...)
Thank you,
Perry
^ permalink raw reply [relevance 11%]
* Bad objects error since upgrading GitHub servers to 1.6.1
@ 2009-01-27 23:04 5% PJ Hyett
0 siblings, 0 replies; 128+ results
From: PJ Hyett @ 2009-01-27 23:04 UTC (permalink / raw)
To: git
Hi folks,
We upgraded our servers to Git 1.6.1 yesterday and almost immediately
starting hearing reports of "Fatal: Bad Object Error." I have
experienced this myself, so I'm 99% certain this isn't user error. I'm
also using 1.6.1 locally.
I ran into this error after trying to push code to GitHub after a
series of simple commits, I was doing absolutely nothing out of the
ordinary.
Please see our support thread for more examples:
http://support.github.com/discussions/feature-requests/157-fatal-bad-object-error-when-doing-simple-push
All of the error messages are the same. Can anyone please shed some
light on this, I don't see any other recourse but to downgrade Git
until this is resolved.
Thanks,
PJ
^ permalink raw reply [relevance 5%]
* rebase failure if commit message looks like a patch
@ 2009-01-27 17:50 3% Anton
0 siblings, 0 replies; 128+ results
From: Anton @ 2009-01-27 17:50 UTC (permalink / raw)
To: git
I have found a strange behaviour of "git rebase", present in following versions:
git 1.6.1, linux,
git 1.6.0.4, cygwin
if the commit message of one of revisions on local branch
containing something, what looks like patch:
------------------ bad-commit-message { ---------------
changeset a1 - feature added
--- a0 2009-01-25 10:09:05.953125000 +0100
+++ ./r/a 2009-01-25 10:15:20.093750000 +0100
@@ -1,5 +1,5 @@
-1
+1 - upstream
2
3
4
-5
+5 - feature
------------------ bad-commit-message } ---------------
Following shell script reproduces the bug for me:
------------------ show-bug.sh { ---------------
#!/bin/bash
rm -rf r # clean-up
mkdir r # repo dir
cd r
git init
cd ..
cp a0 r/a
cd r
git add a
git ci -m "initial addition of a0"
git br feature
git co feature
cd ..
cp a1 r/a
cd r
git add a
## no bug
#git ci -m "changeset a1 - feature added"
# bug
git ci -F ../bad-commit-message
git co master
cd ..
cp a2 r/a
cd r
git add a
git ci -m "changeset a2 - upstream revision"
git co feature
git rebase master
------------------ show-bug.sh } ---------------
produces the error on final rebase attempt:
First, rewinding head to replay your work on top of it...
Applying: changeset a1 - feature added
error: r/a: does not exist in index
fatal: sha1 information is lacking or useless (r/a).
Repository lacks necessary blobs to fall back on 3-way merge.
Cannot fall back to three-way merge.
Patch failed at 0001.
When you have resolved this problem run "git rebase --continue".
If you would prefer to skip this patch, instead run "git rebase --skip".
To restore the original branch and stop rebasing run "git rebase --abort".
In case one uses
# no bug
git ci -m "changeset a1 - feature added"
instead of
# bug
git ci -F ../bad-commit-message
The final rebase succeded !
Content of other files:
---------------- a0 { -------------------
1
2
3
4
5
---------------- a0 } -------------------
---------------- a1 { -------------------
1
2
3
4
5 - feature
---------------- a1 } -------------------
---------------- a2 { -------------------
1 - upstream
2
3
4
5
---------------- a2 } -------------------
--
Anton
^ permalink raw reply [relevance 3%]
* Re: Emacs git-mode feature request: support fill-paragraph correctly
@ 2009-01-27 14:07 4% ` Peter Simons
2009-01-28 21:32 0% ` Junio C Hamano
0 siblings, 1 reply; 128+ results
From: Peter Simons @ 2009-01-27 14:07 UTC (permalink / raw)
To: git
Hi Alexandre,
> diff --git a/contrib/emacs/git.el b/contrib/emacs/git.el
> index 3c37d0d..e314c44 100644
> --- a/contrib/emacs/git.el
> +++ b/contrib/emacs/git.el
> @@ -1331,6 +1331,7 @@ Return the list of files that haven't been handled."
> (log-edit-diff-function . git-log-edit-diff)) buffer)
> (log-edit 'git-do-commit nil 'git-log-edit-files buffer))
> (setq font-lock-keywords (font-lock-compile-keywords git-log-edit-font-lock-keywords))
> + (setq paragraph-separate (concat (regexp-quote git-log-msg-separator) "$\\|Author: \\|Date: \\|Merge: \\|Signed-off-by: \\|\f\\|[ ]*$"))
> (setq buffer-file-coding-system coding-system)
> (re-search-forward (regexp-quote (concat git-log-msg-separator "\n")) nil t))))
that patch has the desired effect (tested with GNU Emacs 22.3.1 and
GIT 1.6.1). Thank you very much.
Now, I'd be hugely in favor of applying that change to the repository
so that future versions of GIT have it.
Take care,
Peter
^ permalink raw reply [relevance 4%]
* Re: git 1.6.1 on AIX 5.3
2009-01-26 22:57 10% ` Perry Smith
2009-01-27 3:52 5% ` Jeff King
@ 2009-01-27 10:10 5% ` Mike Ralphson
2009-01-28 1:35 11% ` Perry Smith
1 sibling, 1 reply; 128+ results
From: Mike Ralphson @ 2009-01-27 10:10 UTC (permalink / raw)
To: Perry Smith; +Cc: git, Jeff King
2009/1/26 Perry Smith <pedzsan@gmail.com>:
> Thanks guys. I picked up coreutils version 7. I didn't
> install them but just moved ginstall over to /usr/local/bin.
>
> A few other comments: I had to add in the --without-tcltk flag. I don't
> have tcl installed but the config did not autodetect that it was not present.
Yup, I usually build with NO_TCLTK=YesPlease in my config.mak, which
you can see from the link Peff posted.
When you said 'out of tree builds' I thought you meant using the AIX
defaults in the Makefile without running ./configure, but it seems
not, you meant is a clone of the tree buildable by itself or are only
release snapshots buildable. Sorry.
./configure is (deliberately) a second-class citizen in the world of
git, and may still get you a slightly suboptimal build compared with
the defaults on platforms such as AIX... e.g. it doesn't test for
performance-related switches such as INTERNAL_QSORT. If you have run
configure, there's some file you need to blow away to get back to a
non-autoconf world... is it config.mak.autogen?
Despite that, your problem with --without-tcltk falling back to wish,
but not falling back if that isn't installed does look like something
we should fix, as per Peff's mail.
> I can't tell if make test is happy or not. The output looks like its happy
> but the exit code is 2.
>
> Below is my "configure" script if anyone is interested.
>
> #!/usr/bin/env bash
>
> export CONFIG_SHELL=/usr/local/bin/bash
> export LDFLAGS='-L/usr/local/lib -L/usr/local/ssl/lib'
> export CFLAGS='-I/usr/local/include -I/usr/local/ssl/include'
> export CC=gcc
> echo CONFIG_SHELL set to ${CONFIG_SHELL}
>
> ${CONFIG_SHELL} ../../src/git-1.6.1/configure --without-tcltk
>
> #
> # Note that to install you need to do:
> # make INSTALL=ginstall install
> # to use GNU's install program
I build with SHELL_PATH={path}/bash as well. If I don't, the test
suite exits after t0000-basic.sh with an unexpected error despite
passing all the tests.
gmake -C t/ all
gmake[1]: Entering directory `/usr/local/src/gitbuild/t'
rm -f -r test-results
gmake aggregate-results-and-cleanup
gmake[2]: Entering directory `/usr/local/src/gitbuild/t'
*** t0000-basic.sh ***
* passed all remaining 40 test(s)
FATAL: Unexpected exit with code 0
gmake[2]: *** [t0000-basic.sh] Error 1
gmake[2]: Leaving directory `/usr/local/src/gitbuild/t'
gmake[1]: *** [all] Error 2
gmake[1]: Leaving directory `/usr/local/src/gitbuild/t'
gmake: *** [test] Error 2
Is that what you're seeing? There's many more test scripts than that 8-)
With GIT_SKIP_TESTS='t3900 t3901 t5100.[12] t8005' (to omit some cases
not handled by the version of iconv I have access to on all the AIX
boxes I deploy to) the test suit runs to completion on AIX 5.3 for me.
BTW Are you running AIX's make or GNU make?
Mike
^ permalink raw reply [relevance 5%]
* Re: git 1.6.1 on AIX 5.3
2009-01-26 22:57 10% ` Perry Smith
@ 2009-01-27 3:52 5% ` Jeff King
2009-01-27 10:10 5% ` Mike Ralphson
1 sibling, 0 replies; 128+ results
From: Jeff King @ 2009-01-27 3:52 UTC (permalink / raw)
To: Perry Smith; +Cc: Mike Ralphson, git
On Mon, Jan 26, 2009 at 04:57:16PM -0600, Perry Smith wrote:
> A few other comments: I had to add in the --without-tcltk flag. I
> don't have tcl installed but the config did not autodetect that it was
> not present.
Hmm. It looks like we respect --with[out]-tcltk, and without it we
always say "just use wish from the PATH" without detecting whether it
actually exists:
# No Tcl/Tk switches given. Do not check for Tcl/Tk, use bare
# 'wish'.
TCLTK_PATH=wish
AC_SUBST(TCLTK_PATH)
I'm sure the fix would be something along the lines of
if which wish; then
TCLTK_PATH=wish
else
NO_TCLTK=yes
fi
but I know for fact that is not portable and that there must be some
special autoconf way of doing the same thing.
> I can't tell if make test is happy or not. The output looks like its
> happy but the exit code is 2.
That doesn't sound very happy. You should see either a "command failed"
error from make, or some results like:
'/bin/sh' ./aggregate-results.sh test-results/t*-*
fixed 1
success 4026
failed 0
broken 3
total 4030
where "broken" is OK (it is a test that is marked as "we know this is
broken currently, but ideally it would be fixed in the future") but
"failed" is a problem.
But I believe unless you are using "make -k", that it won't even
aggregate the results if something fails, and you should just see make
complaining about the failed test script.
-Peff
^ permalink raw reply [relevance 5%]
* Re: git 1.6.1 on AIX 5.3
2009-01-26 22:32 5% ` Mike Ralphson
@ 2009-01-26 22:57 10% ` Perry Smith
2009-01-27 3:52 5% ` Jeff King
2009-01-27 10:10 5% ` Mike Ralphson
0 siblings, 2 replies; 128+ results
From: Perry Smith @ 2009-01-26 22:57 UTC (permalink / raw)
To: Mike Ralphson; +Cc: git, Jeff King
On Jan 26, 2009, at 4:32 PM, Mike Ralphson wrote:
> 2009/1/26 Jeff King <peff@peff.net>:
>> [cc-ing Mike Ralphson, our local AIX expert]
>
> Bless you!
>
>> On Mon, Jan 26, 2009 at 02:02:15PM -0600, Perry Smith wrote:
>>
>>> I tried building git 1.6.1 on AIX 5.3 as an "out of tree" build
>>> and it
>>> does not seem to be set up to do out of tree builds. If that is not
>>> true, please let me know.
>>>
>>> The install process wants to call install with a -d option. AIX
>>> has two
>>> install programs but they are pretty old -- neither takes a -d
>>> option.
>>>
>>> Is there a GNU install program I can get? I've not been able to
>>> locate
>>> one.
>>
>> It's in GNU coreutils:
>>
>> http://www.gnu.org/software/coreutils/
>>
>> I don't know what Mike uses to install on AIX; you can see his config
>> setup here:
>>
>> http://repo.or.cz/w/git/gitbuild.git?a=tree;f=mr/aix;hb=platform
>>
>> but I don't see any override of install.
>
> I've got the AIX Toolbox for Linux applications[1] installed and ahead
> of /bin and /usr/bin on my PATH. Beware that some of these don't
> function as well as the stock AIX utilities and should normally be
> removed. I've posted about this on what is ostensibly a blog but which
> is really just a post-it note I'm less likely to lose[2].
>
> Failing that, many programs which are primarily configured using
> autoconf will ship with an install shell script which you can co-opt,
> some apache stuff does too[3].
>
> Any other questions, don't hesitate to ask.
>
> Mike
>
> [1] http://www-03.ibm.com/systems/power/software/aix/linux/index.html
>
> [2] http://mermade.blogspot.com/2008/04/aix-toolbox.html
>
> [3] http://svn.apache.org/repos/asf/tcl/websh/trunk/src/unix/install-
> sh
Thanks guys. I picked up coreutils version 7. I didn't
install them but just moved ginstall over to /usr/local/bin.
A few other comments: I had to add in the --without-tcltk flag. I
don't have
tcl installed but the config did not autodetect that it was not present.
I can't tell if make test is happy or not. The output looks like its
happy
but the exit code is 2.
Below is my "configure" script if anyone is interested.
#!/usr/bin/env bash
export CONFIG_SHELL=/usr/local/bin/bash
export LDFLAGS='-L/usr/local/lib -L/usr/local/ssl/lib'
export CFLAGS='-I/usr/local/include -I/usr/local/ssl/include'
export CC=gcc
echo CONFIG_SHELL set to ${CONFIG_SHELL}
${CONFIG_SHELL} ../../src/git-1.6.1/configure --without-tcltk
#
# Note that to install you need to do:
# make INSTALL=ginstall install
# to use GNU's install program
^ permalink raw reply [relevance 10%]
* Re: git 1.6.1 on AIX 5.3
2009-01-26 21:00 5% ` Jeff King
@ 2009-01-26 22:32 5% ` Mike Ralphson
2009-01-26 22:57 10% ` Perry Smith
0 siblings, 1 reply; 128+ results
From: Mike Ralphson @ 2009-01-26 22:32 UTC (permalink / raw)
To: Perry Smith; +Cc: git, Jeff King
2009/1/26 Jeff King <peff@peff.net>:
> [cc-ing Mike Ralphson, our local AIX expert]
Bless you!
> On Mon, Jan 26, 2009 at 02:02:15PM -0600, Perry Smith wrote:
>
>> I tried building git 1.6.1 on AIX 5.3 as an "out of tree" build and it
>> does not seem to be set up to do out of tree builds. If that is not
>> true, please let me know.
>>
>> The install process wants to call install with a -d option. AIX has two
>> install programs but they are pretty old -- neither takes a -d option.
>>
>> Is there a GNU install program I can get? I've not been able to locate
>> one.
>
> It's in GNU coreutils:
>
> http://www.gnu.org/software/coreutils/
>
> I don't know what Mike uses to install on AIX; you can see his config
> setup here:
>
> http://repo.or.cz/w/git/gitbuild.git?a=tree;f=mr/aix;hb=platform
>
> but I don't see any override of install.
I've got the AIX Toolbox for Linux applications[1] installed and ahead
of /bin and /usr/bin on my PATH. Beware that some of these don't
function as well as the stock AIX utilities and should normally be
removed. I've posted about this on what is ostensibly a blog but which
is really just a post-it note I'm less likely to lose[2].
Failing that, many programs which are primarily configured using
autoconf will ship with an install shell script which you can co-opt,
some apache stuff does too[3].
Any other questions, don't hesitate to ask.
Mike
[1] http://www-03.ibm.com/systems/power/software/aix/linux/index.html
[2] http://mermade.blogspot.com/2008/04/aix-toolbox.html
[3] http://svn.apache.org/repos/asf/tcl/websh/trunk/src/unix/install-sh
^ permalink raw reply [relevance 5%]
* Re: git 1.6.1 on AIX 5.3
2009-01-26 20:02 10% git 1.6.1 on AIX 5.3 Perry Smith
@ 2009-01-26 21:00 5% ` Jeff King
2009-01-26 22:32 5% ` Mike Ralphson
0 siblings, 1 reply; 128+ results
From: Jeff King @ 2009-01-26 21:00 UTC (permalink / raw)
To: Perry Smith; +Cc: Mike Ralphson, git
[cc-ing Mike Ralphson, our local AIX expert]
On Mon, Jan 26, 2009 at 02:02:15PM -0600, Perry Smith wrote:
> I tried building git 1.6.1 on AIX 5.3 as an "out of tree" build and it
> does not seem to be set up to do out of tree builds. If that is not
> true, please let me know.
>
> The install process wants to call install with a -d option. AIX has two
> install programs but they are pretty old -- neither takes a -d option.
>
> Is there a GNU install program I can get? I've not been able to locate
> one.
It's in GNU coreutils:
http://www.gnu.org/software/coreutils/
I don't know what Mike uses to install on AIX; you can see his config
setup here:
http://repo.or.cz/w/git/gitbuild.git?a=tree;f=mr/aix;hb=platform
but I don't see any override of install.
> Last -- just so I know for future reference, is this list a 'text only
> email' list?
If you mean "no html", then yes, it is absolutely text only.
-Peff
^ permalink raw reply [relevance 5%]
* git 1.6.1 on AIX 5.3
@ 2009-01-26 20:02 10% Perry Smith
2009-01-26 21:00 5% ` Jeff King
0 siblings, 1 reply; 128+ results
From: Perry Smith @ 2009-01-26 20:02 UTC (permalink / raw)
To: git
I tried building git 1.6.1 on AIX 5.3 as an "out of tree" build and it
does not seem to be set up to do out of tree builds. If that is not
true, please let me know.
The install process wants to call install with a -d option. AIX has
two install programs but they are pretty old -- neither takes a -d
option.
Is there a GNU install program I can get? I've not been able to
locate one.
The curious thing is I installed git 1.5.6.4 on a similar AIX system a
few months ago and succeeded.
Last -- just so I know for future reference, is this list a 'text only
email' list?
Thank you for your help,
Perry
Ease Software, Inc. ( http://www.easesoftware.com )
Low cost SATA Disk Systems for IBMs p5, pSeries, and RS/6000 AIX systems
^ permalink raw reply [relevance 10%]
* Re: bug: transform a binary file into a symlink in one commit => invalid binary patch
2009-01-26 0:35 0% ` Jeff King
@ 2009-01-26 7:37 0% ` Junio C Hamano
0 siblings, 0 replies; 128+ results
From: Junio C Hamano @ 2009-01-26 7:37 UTC (permalink / raw)
To: Jeff King; +Cc: Pixel, git
Jeff King <peff@peff.net> writes:
> On Fri, Jan 23, 2009 at 01:25:30PM +0100, Pixel wrote:
>
>> i hit a bug (git 1.6.1): when you transform a binary file into a
>> symlink in one commit, the binary patch can't be used in "git apply".
>> Is it a known issue?
>
> Not that I know of.
>
> Below is a patch against the test suite that fairly neatly displays the
> problem. I didn't get a chance to look into actually fixing it, though
> (I'm not even sure the problem is in apply, and not in the generated
> patch).
The generated diff is wrong.
A filepair that changes type must be split into deletion followed by
creation, which means the "index" line should say 0{40} on the right hand
side for the first half and then 0{40} on the left hand side for the
second half. The patch generated by this step:
> +test_expect_success 'create patch' '
> + git diff-tree --binary HEAD^ HEAD >patch
> +'
However says the blob contents change from "\0" to "file" on both.
This is because diff.c::run_diff() computes "index" only once and reuses
it for both halves.
^ permalink raw reply [relevance 0%]
* Re: bug: transform a binary file into a symlink in one commit => invalid binary patch
2009-01-23 12:25 4% bug: transform a binary file into a symlink in one commit => invalid binary patch Pixel
2009-01-23 13:13 0% ` Michael J Gruber
@ 2009-01-26 0:35 0% ` Jeff King
2009-01-26 7:37 0% ` Junio C Hamano
1 sibling, 1 reply; 128+ results
From: Jeff King @ 2009-01-26 0:35 UTC (permalink / raw)
To: Pixel; +Cc: git
On Fri, Jan 23, 2009 at 01:25:30PM +0100, Pixel wrote:
> i hit a bug (git 1.6.1): when you transform a binary file into a
> symlink in one commit, the binary patch can't be used in "git apply".
> Is it a known issue?
Not that I know of.
Below is a patch against the test suite that fairly neatly displays the
problem. I didn't get a chance to look into actually fixing it, though
(I'm not even sure the problem is in apply, and not in the generated
patch).
---
diff --git a/t/t4130-apply-symlink-binary.sh b/t/t4130-apply-symlink-binary.sh
new file mode 100755
index 0000000..0ee2ba1
--- /dev/null
+++ b/t/t4130-apply-symlink-binary.sh
@@ -0,0 +1,30 @@
+#!/bin/sh
+
+test_description='apply handles binary to symlink conversion'
+. ./test-lib.sh
+
+test_expect_success 'create commit with binary' '
+ echo content >file && git add file &&
+ printf "\0" > binary && git add binary &&
+ git commit -m one
+'
+
+test_expect_success 'convert binary to symlink' '
+ rm binary &&
+ ln -s file binary &&
+ git add binary &&
+ git commit -m two
+'
+
+test_expect_success 'create patch' '
+ git diff-tree --binary HEAD^ HEAD >patch
+'
+
+test_expect_success 'apply patch' '
+ git reset --hard HEAD^ &&
+ git apply patch &&
+ test -h binary &&
+ test_cmp binary file
+'
+
+test_done
^ permalink raw reply related [relevance 0%]
* [RFC PATCH (GIT-GUI/CORE BUG)] git-gui: Avoid an infinite rescan loop in handle_empty_diff.
@ 2009-01-23 21:52 3% Alexander Gavrilov
0 siblings, 0 replies; 128+ results
From: Alexander Gavrilov @ 2009-01-23 21:52 UTC (permalink / raw)
To: git; +Cc: Shawn O. Pearce, Junio C Hamano, Andy Davey, kbro
If the index update machinery and git diff happen to disagree
on whether a particular file is modified, it may cause git-gui
to enter an infinite index rescan loop, where an empty diff
starts a rescan, which finds the same set of files modified,
and tries to display the diff for the first one, which happens
to be the empty one. A current example of a possible disagreement
point is the autocrlf filter.
This patch breaks the loop by using a global variable to track
the auto-rescans. The variable is reset whenever a non-empty
diff is displayed. As a way to work around the malfunctioning
index rescan command, it resurrects the pre-0.6.0 code that
directly updates only the affected file.
Signed-off-by: Alexander Gavrilov <angavrilov@gmail.com>
---
Note that if the file is actually modified, and the bug is
either in git-diff or the way git-gui calls it, this patch
will stage the file without displaying it in the UI. Thus, it
may be better to simply do nothing if the loop prevention
logic triggers.
On Jan 22, 11:31 pm, kbro <kevin.broa...@googlemail.com> wrote:
> However, for me it was worse as the "No differences" message popped up
> as soon as I opened git-gui, and the dialog said it would run a rescan
> to find all files in a similar state. The rescan caused the same
> error to be detected again, so I could never get the dialog box to go
> away.
On Friday 23 January 2009 02:56:23 Andy Davey wrote:
> I had the exact same problem you described running git-1.6.1-
> preview20081227 on Windows XP as well. (the endless loop of dialog box
> is very frustrating).
P.S. Steps to reproduce the autocrlf handling mismatch on Linux:
$ git init
$ echo > foo
$ git add foo && git commit -m init
$ unix2dos -o foo
$ git config core.autocrlf true
$ git status
# On branch master
# Changed but not updated:
# (use "git add <file>..." to update what will be committed)
# (use "git checkout -- <file>..." to discard changes in working directory)
#
# modified: foo
#
no changes added to commit (use "git add" and/or "git commit -a")
$ git diff foo
diff --git a/foo b/foo
It happens because git-status assumes that a change in
file size always means that the file contents have changed.
Content filters like autocrlf may invalidate this assumption.
lib/diff.tcl | 16 +++++++++++++++-
1 files changed, 15 insertions(+), 1 deletions(-)
diff --git a/lib/diff.tcl b/lib/diff.tcl
index bbbf15c..e5abb49 100644
--- a/lib/diff.tcl
+++ b/lib/diff.tcl
@@ -51,6 +51,7 @@ proc force_diff_encoding {enc} {
proc handle_empty_diff {} {
global current_diff_path file_states file_lists
+ global last_empty_diff
set path $current_diff_path
set s $file_states($path)
@@ -66,7 +67,17 @@ A rescan will be automatically started to find other files which may have the sa
clear_diff
display_file $path __
- rescan ui_ready 0
+
+ if {![info exists last_empty_diff]} {
+ set last_empty_diff $path
+ rescan ui_ready 0
+ } else {
+ # We already tried rescanning recently, and it failed,
+ # so resort to updating this particular file.
+ if {[catch {git update-index -- $path} err]} {
+ error_popup [mc "Failed to refresh index:\n\n%s" $err]
+ }
+ }
}
proc show_diff {path w {lno {}} {scroll_pos {}} {callback {}}} {
@@ -310,6 +321,7 @@ proc read_diff {fd cont_info} {
global ui_diff diff_active
global is_3way_diff is_conflict_diff current_diff_header
global current_diff_queue
+ global last_empty_diff
$ui_diff conf -state normal
while {[gets $fd line] >= 0} {
@@ -415,6 +427,8 @@ proc read_diff {fd cont_info} {
if {[$ui_diff index end] eq {2.0}} {
handle_empty_diff
+ } else {
+ catch { unset last_empty_diff }
}
set callback [lindex $cont_info 1]
if {$callback ne {}} {
--
1.6.1.63.g950db
^ permalink raw reply related [relevance 3%]
* Re: git blame: two "-C"s versus just a single -C
2009-01-23 11:28 4% git blame: two "-C"s versus just a single -C Sitaram Chamarty
@ 2009-01-23 19:12 0% ` Sitaram Chamarty
0 siblings, 0 replies; 128+ results
From: Sitaram Chamarty @ 2009-01-23 19:12 UTC (permalink / raw)
To: git
On 2009-01-23, Sitaram Chamarty <sitaramc@gmail.com> wrote:
> I seem to recall (and the docs indicate) that when you
> *copy* (not move, just copy) a function from file1.c to
> file2.c, commit, and then do a "git blame -C -C file2.c", it
> should tell you that those lines came from file1.c
>
> Is this not true? Git 1.6.1, I tried this on a dummy branch
> where I just copied a good sized function (about 45 lines)
> from one C program and dumped it at the bottom of a second
> one, and neither the gui blame nor the CLI blame show me
> that the lines came from elsewhere.
>
> What am I doing wrong?
(replying to myself...)
It works when I give it three "-C" arguments. I thought it
was supposed to be 2 though.
^ permalink raw reply [relevance 0%]
* Re: bug: transform a binary file into a symlink in one commit => invalid binary patch
2009-01-23 12:25 4% bug: transform a binary file into a symlink in one commit => invalid binary patch Pixel
@ 2009-01-23 13:13 0% ` Michael J Gruber
2009-01-26 0:35 0% ` Jeff King
1 sibling, 0 replies; 128+ results
From: Michael J Gruber @ 2009-01-23 13:13 UTC (permalink / raw)
To: Pixel; +Cc: git
Pixel venit, vidit, dixit 23.01.2009 13:25:
> hi,
>
> i hit a bug (git 1.6.1): when you transform a binary file into a
> symlink in one commit, the binary patch can't be used in "git apply".
> Is it a known issue?
>
>
> reproducer:
>
> ----------
> #!/bin/sh -e
>
> # the bug: if you transform a binary file into a symlink in one commit,
> # the binary patch can't be used in "git apply"
> #
> # nb: if you uncomment the "##" lines, the problem disappears
> # since the first patch will empty the binary file then the non-binary file
> # will be transformed into a symlink
>
> rm -rf t t2
> mkdir t
> dd if=/dev/urandom of=t/a count=10
> cp -r t t2
>
> cd t
> git init
> git add .
> git commit -m initial
>
> ##echo -n > a
> ##git commit -a -m foo
> ln -sf zzz a
> git commit -a -m foo2
> git format-patch :/initial
>
> cd ../t2
> git apply ../t/*.patch
>
> cd ..
> rm -rf t t2
> ----------
You're not even initialising a repo in t2. I assume you want to "cp -a t
t2" after the "initial" commit, don't you? Doing that I get
error: binary patch to 'a' creates incorrect result (expecting
e132db255c0e0e3e9309c3c58a0a9c9eb97dd942, got
e69de29bb2d1d6434b8b29ae775ad8c2e48c5391)
error: a: patch does not apply
error: a: already exists in working directory
which is not that magnificient either. If that's the error you're after
your test script needs to be modified.
Michael
^ permalink raw reply [relevance 0%]
* bug: transform a binary file into a symlink in one commit => invalid binary patch
@ 2009-01-23 12:25 4% Pixel
2009-01-23 13:13 0% ` Michael J Gruber
2009-01-26 0:35 0% ` Jeff King
0 siblings, 2 replies; 128+ results
From: Pixel @ 2009-01-23 12:25 UTC (permalink / raw)
To: git
hi,
i hit a bug (git 1.6.1): when you transform a binary file into a
symlink in one commit, the binary patch can't be used in "git apply".
Is it a known issue?
reproducer:
----------
#!/bin/sh -e
# the bug: if you transform a binary file into a symlink in one commit,
# the binary patch can't be used in "git apply"
#
# nb: if you uncomment the "##" lines, the problem disappears
# since the first patch will empty the binary file then the non-binary file
# will be transformed into a symlink
rm -rf t t2
mkdir t
dd if=/dev/urandom of=t/a count=10
cp -r t t2
cd t
git init
git add .
git commit -m initial
##echo -n > a
##git commit -a -m foo
ln -sf zzz a
git commit -a -m foo2
git format-patch :/initial
cd ../t2
git apply ../t/*.patch
cd ..
rm -rf t t2
----------
^ permalink raw reply [relevance 4%]
* git blame: two "-C"s versus just a single -C
@ 2009-01-23 11:28 4% Sitaram Chamarty
2009-01-23 19:12 0% ` Sitaram Chamarty
0 siblings, 1 reply; 128+ results
From: Sitaram Chamarty @ 2009-01-23 11:28 UTC (permalink / raw)
To: git
I seem to recall (and the docs indicate) that when you
*copy* (not move, just copy) a function from file1.c to
file2.c, commit, and then do a "git blame -C -C file2.c", it
should tell you that those lines came from file1.c
Is this not true? Git 1.6.1, I tried this on a dummy branch
where I just copied a good sized function (about 45 lines)
from one C program and dumped it at the bottom of a second
one, and neither the gui blame nor the CLI blame show me
that the lines came from elsewhere.
What am I doing wrong?
^ permalink raw reply [relevance 4%]
* Re: git fast-import problem converting from CVS with git 1.6.1 and cvs2svn 2.2.0
2009-01-22 14:30 6% ` Kelly F. Hickel
2009-01-22 16:31 6% ` Johannes Schindelin
@ 2009-01-23 4:14 5% ` Michael Haggerty
1 sibling, 0 replies; 128+ results
From: Michael Haggerty @ 2009-01-23 4:14 UTC (permalink / raw)
To: Kelly F. Hickel; +Cc: git, cvs2svn users
Kelly F. Hickel wrote:
> I found the section in question, it is:
> -- snip --
> commit refs/heads/TAG.FIXUP
> mark :1000007128
> committer cvs2svn <cvs2svn> 1002043747 +0000
> data 88
> This commit was manufactured by cvs2svn to create tag
> 'T_BU_Problem_9xxx_Merge_3-21-2000'.
> merge :1000007126
> M 100755 :180810 mfcdev/Domedit/DlgAddAlias.h
> -- snap --
>
> By my count, 88 is the ending single quote character, leaving the '.' to
> be interpreted as a command.
>
> Looks like I should go post this on the cvs2svn list.....
Yes, that would be helpful. Please include enough information and data
to enable me to reproduce your problem, because it is very mysterious.
The lines in question are (in Python)
self.f.write('data %d\n' % (len(log_msg),))
self.f.write('%s\n' % (log_msg,))
where self.f is a file that was opened in binary mode, and log_msg is an
8-bit or unicode string. Since the log message is being output to a
binary file, f.write() should squeal if the string includes any
non-ascii characters (I just verified this with Python 2.2, 2.4, and
2.5). Nevertheless, I suspect that your problem is caused by some kind
of character encoding problem, perhaps dependent on platform or Python
version.
You might also try the trunk version of cvs2svn; there have been a lot
of changes to cvs2git since release 2.1.1--even a new command that is
actually called cvs2git! (though for now you still need to use an
options file to start conversions).
Michael
------------------------------------------------------
http://cvs2svn.tigris.org/ds/viewMessage.do?dsForumId=1670&dsMessageId=1044191
To unsubscribe from this discussion, e-mail: [users-unsubscribe@cvs2svn.tigris.org].
^ permalink raw reply [relevance 5%]
* RE: git fast-import problem converting from CVS with git 1.6.1 and cvs2svn 2.2.0
2009-01-22 14:30 6% ` Kelly F. Hickel
@ 2009-01-22 16:31 6% ` Johannes Schindelin
2009-01-23 4:14 5% ` Michael Haggerty
1 sibling, 0 replies; 128+ results
From: Johannes Schindelin @ 2009-01-22 16:31 UTC (permalink / raw)
To: Kelly F. Hickel; +Cc: git
Hi,
On Thu, 22 Jan 2009, Kelly F. Hickel wrote:
> I found the section in question, it is:
> -- snip --
> commit refs/heads/TAG.FIXUP
> mark :1000007128
> committer cvs2svn <cvs2svn> 1002043747 +0000
> data 88
> This commit was manufactured by cvs2svn to create tag
> 'T_BU_Problem_9xxx_Merge_3-21-2000'.
> merge :1000007126
> M 100755 :180810 mfcdev/Domedit/DlgAddAlias.h
> -- snap --
>
> By my count, 88 is the ending single quote character, leaving the '.' to
> be interpreted as a command.
Great!
> Looks like I should go post this on the cvs2svn list.....
Indeed. I think that Michael will find the culprit very soon, with this
detailed report.
BTW for future reference, please Cc: the people you are responding to.
The Git mailing list is a high volume list, and people will miss you
answers otherwise.
Thanks,
Dscho
^ permalink raw reply [relevance 6%]
* RE: git fast-import problem converting from CVS with git 1.6.1 and cvs2svn 2.2.0
2009-01-20 16:04 6% ` Kelly F. Hickel
@ 2009-01-22 14:30 6% ` Kelly F. Hickel
2009-01-22 16:31 6% ` Johannes Schindelin
2009-01-23 4:14 5% ` Michael Haggerty
0 siblings, 2 replies; 128+ results
From: Kelly F. Hickel @ 2009-01-22 14:30 UTC (permalink / raw)
To: Kelly F. Hickel, git
(Sorry for the mangled quotes)
> That is strange. The command "data 88" should read the next 88 bytes
and
> not stop at the line starting with '.
>
> Just to test, I successfully imported this:
>
> -- snip --
> commit refs/heads/testing/test
> mark :1
> committer cvs2svn <cvs2svn> 1002043747 +0000
> data 3
> '.
>
> -- snap --
>
> So I guess the problem lies much earlier: I could imagine that there
is
> _another_ "data" command that has a bogus length and just happens to
end
> after the line "data 88".
>
> Maybe that helps?
>
> I could also imagine that the '. actually is the end of an example
> inside a blob, that literally looks like a fast-import script, but
> actually is not meant for _this_ fast-import run.
>
> Ciao,
> Dscho
>
> --
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@...
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
> From: Daniel Barkalow
> Can you find that part of the input? I wouldn't be too surprised if
> something were giving the wrong length in a data command, causing it
to
> either eat another data command and end up in the data or to use
> not-quite-all of the data and end up near the end of the data.
>
> -Daniel
> *This .sig left intentionally blank*
>
>
I found the section in question, it is:
-- snip --
commit refs/heads/TAG.FIXUP
mark :1000007128
committer cvs2svn <cvs2svn> 1002043747 +0000
data 88
This commit was manufactured by cvs2svn to create tag
'T_BU_Problem_9xxx_Merge_3-21-2000'.
merge :1000007126
M 100755 :180810 mfcdev/Domedit/DlgAddAlias.h
-- snap --
By my count, 88 is the ending single quote character, leaving the '.' to
be interpreted as a command.
Looks like I should go post this on the cvs2svn list.....
Thanks!
--
Kelly F. Hickel
Senior Product Architect
MQSoftware, Inc.
952-345-8677 Office
952-345-8721 Fax
kfh@mqsoftware.com
www.mqsoftware.com
Certified IBM SOA Specialty
Your Full Service Provider for IBM WebSphere
Learn more at www.mqsoftware.com
^ permalink raw reply [relevance 6%]
* Re: git fast-import problem converting from CVS with git 1.6.1 and cvs2svn 2.2.0
2009-01-20 15:46 5% git fast-import problem converting from CVS with git 1.6.1 and cvs2svn 2.2.0 Kelly F. Hickel
2009-01-20 16:04 6% ` Kelly F. Hickel
2009-01-20 16:41 6% ` Johannes Schindelin
@ 2009-01-20 20:29 6% ` Daniel Barkalow
2 siblings, 0 replies; 128+ results
From: Daniel Barkalow @ 2009-01-20 20:29 UTC (permalink / raw)
To: Kelly F. Hickel; +Cc: git
On Tue, 20 Jan 2009, Kelly F. Hickel wrote:
> Hello all,
>
> Back in June I had done a test convert of our CVS repo using git 1.5.5.1
> and cvs2svn 2.2.0 that went reasonably well (although it takes nearly a
> week to finish!). Recently I wanted to try again with the latest
> versions of git and cvs2svn.
>
> When I get to the final stage (running git fast-import to build the
> converted repo), I get the following output:
> cat ../cvs2svn-tmp/git-blob.dat ../cvs2svn-tmp/git-dump.dat | git
> fast-import
> fatal: Unsupported command: '.
> fast-import: dumping crash report to .git/fast_import_crash_19097
>
> The crash is 18MB and I'd rather not post it, but the only bits that
> seem somewhat interesting are:
> fast-import crash report:
> fast-import process: 19097
> parent process : 19095
> at Mon Jan 19 11:44:42 2009
>
> fatal: Unsupported command: '.
>
> Most Recent Commands Before Crash
> ---------------------------------
> (...)
> reset refs/tags/T_9772
> from :1000007127
> reset refs/heads/TAG.FIXUP
>
> commit refs/heads/TAG.FIXUP
> mark :1000007128
> committer cvs2svn <cvs2svn> 1002043747 +0000
> data 88
> * '.
>
>
> Has anyone got any ideas how to resolve this?
Can you find that part of the input? I wouldn't be too surprised if
something were giving the wrong length in a data command, causing it to
either eat another data command and end up in the data or to use
not-quite-all of the data and end up near the end of the data.
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply [relevance 6%]
* Re: git fast-import problem converting from CVS with git 1.6.1 and cvs2svn 2.2.0
2009-01-20 15:46 5% git fast-import problem converting from CVS with git 1.6.1 and cvs2svn 2.2.0 Kelly F. Hickel
2009-01-20 16:04 6% ` Kelly F. Hickel
@ 2009-01-20 16:41 6% ` Johannes Schindelin
2009-01-20 20:29 6% ` Daniel Barkalow
2 siblings, 0 replies; 128+ results
From: Johannes Schindelin @ 2009-01-20 16:41 UTC (permalink / raw)
To: Kelly F. Hickel; +Cc: git
Hi,
On Tue, 20 Jan 2009, Kelly F. Hickel wrote:
> cat ../cvs2svn-tmp/git-blob.dat ../cvs2svn-tmp/git-dump.dat | git
> fast-import
> fatal: Unsupported command: '.
> fast-import: dumping crash report to .git/fast_import_crash_19097
>
> The crash is 18MB and I'd rather not post it, but the only bits that
> seem somewhat interesting are:
> fast-import crash report:
> fast-import process: 19097
> parent process : 19095
> at Mon Jan 19 11:44:42 2009
>
> fatal: Unsupported command: '.
>
> Most Recent Commands Before Crash
> ---------------------------------
> (...)
> reset refs/tags/T_9772
> from :1000007127
> reset refs/heads/TAG.FIXUP
>
> commit refs/heads/TAG.FIXUP
> mark :1000007128
> committer cvs2svn <cvs2svn> 1002043747 +0000
> data 88
> * '.
>
>
That is strange. The command "data 88" should read the next 88 bytes and
not stop at the line starting with '.
Just to test, I successfully imported this:
-- snip --
commit refs/heads/testing/test
mark :1
committer cvs2svn <cvs2svn> 1002043747 +0000
data 3
'.
-- snap --
So I guess the problem lies much earlier: I could imagine that there is
_another_ "data" command that has a bogus length and just happens to end
after the line "data 88".
Maybe that helps?
I could also imagine that the '. actually is the end of an example
inside a blob, that literally looks like a fast-import script, but
actually is not meant for _this_ fast-import run.
Ciao,
Dscho
^ permalink raw reply [relevance 6%]
* RE: git fast-import problem converting from CVS with git 1.6.1 and cvs2svn 2.2.0
2009-01-20 15:46 5% git fast-import problem converting from CVS with git 1.6.1 and cvs2svn 2.2.0 Kelly F. Hickel
@ 2009-01-20 16:04 6% ` Kelly F. Hickel
2009-01-22 14:30 6% ` Kelly F. Hickel
2009-01-20 16:41 6% ` Johannes Schindelin
2009-01-20 20:29 6% ` Daniel Barkalow
2 siblings, 1 reply; 128+ results
From: Kelly F. Hickel @ 2009-01-20 16:04 UTC (permalink / raw)
To: Kelly F. Hickel, git
> Back in June I had done a test convert of our CVS repo using git
> 1.5.5.1
> and cvs2svn 2.2.0 that went reasonably well
That's a typo. The June conversion used git 1.5.5.1 and cvs2svn 2.1.1
(not 2.2.0 as previously stated).
Sorry for the confusion.
-Kelly
^ permalink raw reply [relevance 6%]
* git fast-import problem converting from CVS with git 1.6.1 and cvs2svn 2.2.0
@ 2009-01-20 15:46 5% Kelly F. Hickel
2009-01-20 16:04 6% ` Kelly F. Hickel
` (2 more replies)
0 siblings, 3 replies; 128+ results
From: Kelly F. Hickel @ 2009-01-20 15:46 UTC (permalink / raw)
To: git
Hello all,
Back in June I had done a test convert of our CVS repo using git 1.5.5.1
and cvs2svn 2.2.0 that went reasonably well (although it takes nearly a
week to finish!). Recently I wanted to try again with the latest
versions of git and cvs2svn.
When I get to the final stage (running git fast-import to build the
converted repo), I get the following output:
cat ../cvs2svn-tmp/git-blob.dat ../cvs2svn-tmp/git-dump.dat | git
fast-import
fatal: Unsupported command: '.
fast-import: dumping crash report to .git/fast_import_crash_19097
The crash is 18MB and I'd rather not post it, but the only bits that
seem somewhat interesting are:
fast-import crash report:
fast-import process: 19097
parent process : 19095
at Mon Jan 19 11:44:42 2009
fatal: Unsupported command: '.
Most Recent Commands Before Crash
---------------------------------
(...)
reset refs/tags/T_9772
from :1000007127
reset refs/heads/TAG.FIXUP
commit refs/heads/TAG.FIXUP
mark :1000007128
committer cvs2svn <cvs2svn> 1002043747 +0000
data 88
* '.
Has anyone got any ideas how to resolve this?
Thanks,
--
Kelly F. Hickel
Senior Product Architect
MQSoftware, Inc.
952-345-8677 Office
952-345-8721 Fax
kfh@mqsoftware.com
www.mqsoftware.com
Certified IBM SOA Specialty
Your Full Service Provider for IBM WebSphere Learn more at
www.mqsoftware.com
^ permalink raw reply [relevance 5%]
* Re: [PATCH 2/3] http-push: when sending objects, don't PUT before MOVE
2009-01-17 6:13 0% ` Johannes Schindelin
@ 2009-01-17 12:08 0% ` Ray Chuan
0 siblings, 0 replies; 128+ results
From: Ray Chuan @ 2009-01-17 12:08 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
Hi,
On Sat, Jan 17, 2009 at 2:13 PM, Johannes Schindelin
<Johannes.Schindelin@gmx.de> wrote:
> Hi,
>
> On Sat, 17 Jan 2009, Ray Chuan wrote:
>
>> since 753bc911f489748a837ecb5ea4b5216220b24845, the opaquelocktocken
>
> It would be nice to use the form <abbrev-sha1>(<oneline>) instead of a
> non-abbreviated SHA-1 that everybody who is interested has to look up,
> wasting time.
sorry, i was referring to 753bc91 (Remove the requirement
opaquelocktoken uri scheme).
>> URI isn't used, so it doesn't make sense to PUT then MOVE.
>>
>> currently, git PUTs to
>>
>> /repo.git/objects/1a/1a2b..._opaquelocktoken:1234-....
>
> First you say that the opaquelocktoken URI is not used, but here it looks
> like one?
>
>> on some platforms, ':' isn't allowed in filenames so this fails
>> (assuming the server doesn't recognize it as opaquelocktoken scheme).
>> in fact, i don't think this is the correct implementation of the
>> scheme; 'opaquelocktoken: ' should come in front of the path.
>
> It would be nice to make that a fact-backed commit message. IOW there has
> to be some documentation about the subject which you can quote, and which
> would give you a definitive answer to the question if it should be a
> prefix or not.
According to the opaquelocktoken URI scheme in RFC2518
OpaqueLockToken-URI = "opaquelocktoken:" UUID [Extension]
if i'm not wrong, then the URI should read
opaquelocktoken:1234-....:/repo.git/objects/1a/1a2b...
rather than (currently):
/repo.git/objects/1a/1a2b..._opaquelocktoken:1234-....
this means either the opaquelocktoken URI scheme wasn't meant to be
implemented, or it is an incorrect implementation.
my belief is of the former, since the URI scheme is meant to represent
the lock token currently held when communicating to the server; in
addition, the lock held doesn't apply to the PUT path; it is
'refs/heads/abranch' rather than 'objects/' that is locked, so it
doesn't make sense to pass the lock token to the server while
accessing 'objects/'.
- Show quoted text -
>> diff --git a/src/git-1.6.1/http-push.c b/src/git-1.6.1/http-push.c
>> index a646a49..838ff6f 100644
>> --- a/src/git-1.6.1/http-push.c
>> +++ b/src/git-1.6.1/http-push.c
>> @@ -31,7 +31,6 @@ enum XML_Status {
>> /* DAV methods */
>> #define DAV_LOCK "LOCK"
>> #define DAV_MKCOL "MKCOL"
>> -#define DAV_MOVE "MOVE"
>> #define DAV_PROPFIND "PROPFIND"
>> #define DAV_PUT "PUT"
>> #define DAV_UNLOCK "UNLOCK"
>> @@ -104,7 +103,6 @@ enum transfer_state {
>> NEED_PUSH,
>> RUN_MKCOL,
>> RUN_PUT,
>> - RUN_MOVE,
>> ABORTED,
>> COMPLETE,
>> };
>> @@ -528,11 +526,6 @@ static void start_put(struct transfer_request *request)
>> posn += 2;
>> *(posn++) = '/';
>> strcpy(posn, hex + 2);
>> - request->dest = xmalloc(strlen(request->url) + 14);
>> - sprintf(request->dest, "Destination: %s", request->url);
>> - posn += 38;
>> - *(posn++) = '_';
>> - strcpy(posn, request->lock->token);
>>
>> slot = get_active_slot();
>> slot->callback_func = process_response;
>
> Color me puzzled again. Why is this code no longer needed? Is this the
> lock you were talking about?
the first two hunks remove MOVE-specific flags and status codes, while
the last hunk removes code that generates the "Destination: <url>"
header needed for a MOVE, which isn't needed by any other DAV
requests.
it isn't related to locks, although the "source" url would contain the
word lock in the current implementation.
for example, currently, a PUT path appended with a opaquelocktoken is
followed by a MOVE request:
PUT /git/test_repo.git/objects/50/b820aea6d3503362343cdc0e699b760c700b2b_opaquelocktoken:6960ad7a-84b0-9b4e-85cc-b9f15652c658
MOVE /git/test_repo.git/objects/50/b820aea6d3503362343cdc0e699b760c700b2b
(actually, it is the request header 'Destination: ' that contains the
destination path, not the request url; i replaced it for demonstrative
purposes.)
>> @@ -705,23 +672,13 @@ static void finish_request(struct
>> transfer_request *request)
>> }
>> } else if (request->state == RUN_PUT) {
>> if (request->curl_result == CURLE_OK) {
>> - start_move(request);
>> - } else {
>> - fprintf(stderr, "PUT %s failed, aborting (%d/%ld)\n",
>> - sha1_to_hex(request->obj->sha1),
>> - request->curl_result, request->http_code);
>> - request->state = ABORTED;
>> - aborted = 1;
>> - }
>
> ... and here comes my first doubt that it would be a good idea to avoid
> "put && move"; what if "put" fails? Then you end up with a corrupt
> repository.
if we take the "put && move" procedure as a guard against failure (as
opposed to "put"), then how does one explain the fact that this
procedure isn't applied when updating a branch file (eg.
refs/heads/mybranch)?
in any case, "put && move" isn't an effective guard after failure
during put. the PUT sends an object/revision to the repository,
however, the repository doesn't yet know that such an object/revision
exists, cos the ref file for the branch to be updated in the remote
repository (eg. refs/heads/mybranch) has yet to be updated; it is
updated only if the PUT was successful.
thus the repository won't be corrupt if a PUT request fails.
> Ciao,
> Dscho
>
>
--
Cheers,
Ray Chuan
^ permalink raw reply [relevance 0%]
* Re: Minimum required version of subversion for git-svn?
2009-01-12 8:03 0% ` Tom G. Christensen
@ 2009-01-17 10:58 0% ` Eric Wong
0 siblings, 0 replies; 128+ results
From: Eric Wong @ 2009-01-17 10:58 UTC (permalink / raw)
To: Tom G. Christensen; +Cc: git@vger.kernel.org
"Tom G. Christensen" <tgc@statsbiblioteket.dk> wrote:
> Eric Wong wrote:
>> "Tom G. Christensen" <tgc@statsbiblioteket.dk> wrote:
>>> Hello,
>>>
>>> With git 1.6.0.5 I was able to run git-svn with subversion 1.1.4 on
>>> RHEL4/i386 but with 1.6.0.6 and 1.6.1 the testsuite now fails in the new
>>> test t9104.10:
>>
>> ...
>>
>>> With 1.6.1 I also see t9129.10-12 failing with subversion 1.1.4:
>>> * FAIL 10: ISO-8859-1 should match UTF-8 in svn
>>
>> ...
>>
>>> * failed 3 among 12 test(s)
>>> make[2]: Leaving directory `/builddir/build/BUILD/git-1.6.1/t'
>>> make[2]: *** [t9129-git-svn-i18n-commitencoding.sh] Error 1
>>>
>>> I see in git-svn.perl that only SVN::Core 1.1.0 is required. Is it still
>>> the intention that git-svn should work with subversion 1.1.x?
>>>
>>> If you're going to bump the minimum requirement I would ask that you
>>> atleast keep 1.3.x as supported. This is the last release of subversion
>>> where RHEL3 can satisfy the dependencies out of the box and I've
>>> verified that the testsuite will pass with 1.3.2.
>>
>> It's still my intention that SVN 1.1.x is supported; but I haven't had
>> the chance to test those versions in a while.
>>
>> Can you rerun the tests that failed with "sh -x t91..." ?
>>
> I've run the tests from 1.6.1 with -v, sh -x and sh -x + -v and dumped
> the results at http://jupiterrise.com/tmp
>
> You'll find results from one more test (t9106) which I didn't mention
> and which is also giving me problems but only with rhel4/x86_64 and svn
> 1.1.4. It should be noted that this test has never worked for me with
> this config.
Thanks, I'll try to setup an environment that lets me test older
SVN builds over the weekend.
--
Eric Wong
^ permalink raw reply [relevance 0%]
* Re: git-svn fails to fetch repository
2009-01-17 10:06 3% ` Vladimir Pouzanov
@ 2009-01-17 10:45 0% ` Eric Wong
0 siblings, 0 replies; 128+ results
From: Eric Wong @ 2009-01-17 10:45 UTC (permalink / raw)
To: Vladimir Pouzanov; +Cc: git, Jay Soffian
Vladimir Pouzanov <farcaller@gmail.com> wrote:
> On 17 янв. 2009, at 11:51, Eric Wong wrote:
>> Does the following patch (a shot in the dark) work for you?
>> (it generates a lot of warnings for me)
>
> $ git svn clone http://qsb-mac.googlecode.com/svn/trunk qsbmac
> Initialized empty Git repository in /Users/farcaller/temp/qsbmac/.git/
> r1 = 810fe584c48b884460b5403a28bc61d872452b93 (git-svn)
> Attempt to release temp file 'GLOB(0x82b290)' that has not been locked
> at /opt/local/libexec/git-core/git-svn line 3413
> A externals/BSJSONAdditions/NSArray+BSJSONAdditions.m
> Attempt to release temp file 'GLOB(0xa0de34)' that has not been locked
> at /opt/local/libexec/git-core/git-svn line 3413
> A externals/BSJSONAdditions/BSJSON.h
> Attempt to release temp file 'GLOB(0x80ed84)' that has not been locked
> at /opt/local/libexec/git-core/git-svn line 3413
> A externals/BSJSONAdditions/NSDictionary+BSJSONAdditions.m
> Attempt to release temp file 'GLOB(0x9d3018)' that has not been locked
> at /opt/local/libexec/git-core/git-svn line 3413
> A externals/BSJSONAdditions/Example/Unit Tests/
> BSJSONScanner_UnitTests.h
> Attempt to release temp file 'GLOB(0xa0df48)' that has not been locked
> at /opt/local/libexec/git-core/git-svn line 3413
> A externals/BSJSONAdditions/Example/version.plist
> Attempt to release temp file 'GLOB(0x9d8114)' that has not been locked
> at /opt/local/libexec/git-core/git-svn line 3413
> A externals/BSJSONAdditions/NSDictionary+BSJSONAdditions.h
> Temp file with moniker 'svn_delta' already in use at /opt/local/lib/
> perl5/site_perl/5.8.8/Git.pm line 1011.
OK, and there are no symlinks in the repository which could trigger a
rare code path, either. Very strange, does abort_edit() ever get called
in there?
> I've built git 1.6.1 based on OSX original perl an subversion, and it
> handles the give repo without any problems, so the problem is kind of
> solved. Strange thing is that macports git (the one that fails) handles
> other svn repositories without any problems, I had cloned whole
> transmissionbt repo (>7000 revs) with all the tags and branches and
> several other simpler repositories.
At least you got a working combination working. Does anybody know if
macports git have any patches/changes to it that could cause this?
--
Eric Wong
^ permalink raw reply [relevance 0%]
* Re: git-svn fails to fetch repository
@ 2009-01-17 10:06 3% ` Vladimir Pouzanov
2009-01-17 10:45 0% ` Eric Wong
0 siblings, 1 reply; 128+ results
From: Vladimir Pouzanov @ 2009-01-17 10:06 UTC (permalink / raw)
To: Eric Wong; +Cc: git, Jay Soffian
On 17 янв. 2009, at 11:51, Eric Wong wrote:
> Does the following patch (a shot in the dark) work for you?
> (it generates a lot of warnings for me)
$ git svn clone http://qsb-mac.googlecode.com/svn/trunk qsbmac
Initialized empty Git repository in /Users/farcaller/temp/qsbmac/.git/
r1 = 810fe584c48b884460b5403a28bc61d872452b93 (git-svn)
Attempt to release temp file 'GLOB(0x82b290)' that has not been locked
at /opt/local/libexec/git-core/git-svn line 3413
A externals/BSJSONAdditions/NSArray+BSJSONAdditions.m
Attempt to release temp file 'GLOB(0xa0de34)' that has not been locked
at /opt/local/libexec/git-core/git-svn line 3413
A externals/BSJSONAdditions/BSJSON.h
Attempt to release temp file 'GLOB(0x80ed84)' that has not been locked
at /opt/local/libexec/git-core/git-svn line 3413
A externals/BSJSONAdditions/NSDictionary+BSJSONAdditions.m
Attempt to release temp file 'GLOB(0x9d3018)' that has not been locked
at /opt/local/libexec/git-core/git-svn line 3413
A externals/BSJSONAdditions/Example/Unit Tests/
BSJSONScanner_UnitTests.h
Attempt to release temp file 'GLOB(0xa0df48)' that has not been locked
at /opt/local/libexec/git-core/git-svn line 3413
A externals/BSJSONAdditions/Example/version.plist
Attempt to release temp file 'GLOB(0x9d8114)' that has not been locked
at /opt/local/libexec/git-core/git-svn line 3413
A externals/BSJSONAdditions/NSDictionary+BSJSONAdditions.h
Temp file with moniker 'svn_delta' already in use at /opt/local/lib/
perl5/site_perl/5.8.8/Git.pm line 1011.
I've built git 1.6.1 based on OSX original perl an subversion, and it
handles the give repo without any problems, so the problem is kind of
solved. Strange thing is that macports git (the one that fails)
handles other svn repositories without any problems, I had cloned
whole transmissionbt repo (>7000 revs) with all the tags and branches
and several other simpler repositories.
--
Sincerely,
Vladimir "Farcaller" Pouzanov
^ permalink raw reply [relevance 3%]
* Re: [PATCH 2/3] http-push: when sending objects, don't PUT before MOVE
2009-01-17 2:59 12% [PATCH 2/3] http-push: when sending objects, don't PUT before MOVE Ray Chuan
@ 2009-01-17 6:13 0% ` Johannes Schindelin
2009-01-17 12:08 0% ` Ray Chuan
0 siblings, 1 reply; 128+ results
From: Johannes Schindelin @ 2009-01-17 6:13 UTC (permalink / raw)
To: Ray Chuan; +Cc: git
Hi,
On Sat, 17 Jan 2009, Ray Chuan wrote:
> since 753bc911f489748a837ecb5ea4b5216220b24845, the opaquelocktocken
It would be nice to use the form <abbrev-sha1>(<oneline>) instead of a
non-abbreviated SHA-1 that everybody who is interested has to look up,
wasting time.
> URI isn't used, so it doesn't make sense to PUT then MOVE.
>
> currently, git PUTs to
>
> /repo.git/objects/1a/1a2b..._opaquelocktoken:1234-....
First you say that the opaquelocktoken URI is not used, but here it looks
like one?
> on some platforms, ':' isn't allowed in filenames so this fails
> (assuming the server doesn't recognize it as opaquelocktoken scheme).
> in fact, i don't think this is the correct implementation of the
> scheme; 'opaquelocktoken: ' should come in front of the path.
It would be nice to make that a fact-backed commit message. IOW there has
to be some documentation about the subject which you can quote, and which
would give you a definitive answer to the question if it should be a
prefix or not.
> diff --git a/src/git-1.6.1/http-push.c b/src/git-1.6.1/http-push.c
> index a646a49..838ff6f 100644
> --- a/src/git-1.6.1/http-push.c
> +++ b/src/git-1.6.1/http-push.c
> @@ -31,7 +31,6 @@ enum XML_Status {
> /* DAV methods */
> #define DAV_LOCK "LOCK"
> #define DAV_MKCOL "MKCOL"
> -#define DAV_MOVE "MOVE"
> #define DAV_PROPFIND "PROPFIND"
> #define DAV_PUT "PUT"
> #define DAV_UNLOCK "UNLOCK"
> @@ -104,7 +103,6 @@ enum transfer_state {
> NEED_PUSH,
> RUN_MKCOL,
> RUN_PUT,
> - RUN_MOVE,
> ABORTED,
> COMPLETE,
> };
> @@ -528,11 +526,6 @@ static void start_put(struct transfer_request *request)
> posn += 2;
> *(posn++) = '/';
> strcpy(posn, hex + 2);
> - request->dest = xmalloc(strlen(request->url) + 14);
> - sprintf(request->dest, "Destination: %s", request->url);
> - posn += 38;
> - *(posn++) = '_';
> - strcpy(posn, request->lock->token);
>
> slot = get_active_slot();
> slot->callback_func = process_response;
Color me puzzled again. Why is this code no longer needed? Is this the
lock you were talking about?
> @@ -705,23 +672,13 @@ static void finish_request(struct
> transfer_request *request)
> }
> } else if (request->state == RUN_PUT) {
> if (request->curl_result == CURLE_OK) {
> - start_move(request);
> - } else {
> - fprintf(stderr, "PUT %s failed, aborting (%d/%ld)\n",
> - sha1_to_hex(request->obj->sha1),
> - request->curl_result, request->http_code);
> - request->state = ABORTED;
> - aborted = 1;
> - }
... and here comes my first doubt that it would be a good idea to avoid
"put && move"; what if "put" fails? Then you end up with a corrupt
repository.
Ciao,
Dscho
^ permalink raw reply [relevance 0%]
* Re: [PATCH 1/3] http-push: append slash if possible for directories
2009-01-17 2:53 13% [PATCH 1/3] http-push: append slash if possible for directories Ray Chuan
2009-01-17 5:19 0% ` Johannes Schindelin
@ 2009-01-17 6:02 0% ` Johannes Schindelin
1 sibling, 0 replies; 128+ results
From: Johannes Schindelin @ 2009-01-17 6:02 UTC (permalink / raw)
To: Ray Chuan; +Cc: git
Hi,
more comments:
On Sat, 17 Jan 2009, Ray Chuan wrote:
> diff --git a/src/git-1.6.1/http-push.c b/src/git-1.6.1/http-push.c
> index 7c64609..25b655d 100644
> --- a/src/git-1.6.1/http-push.c
> +++ b/src/git-1.6.1/http-push.c
> @@ -1189,6 +1189,7 @@ static struct remote_lock *lock_remote(const
> char *path, long timeout)
> struct strbuf in_buffer = STRBUF_INIT;
> char *url;
> char *ep;
> + char ep_old;
> char timeout_header[25];
> struct remote_lock *lock = NULL;
> struct curl_slist *dav_headers = NULL;
> @@ -1198,9 +1199,18 @@ static struct remote_lock *lock_remote(const
> char *path, long timeout)
> sprintf(url, "%s%s", remote->url, path);
>
> /* Make sure leading directories exist for the remote ref */
> - ep = strchr(url + strlen(remote->url) + 1, '/');
> - while (ep) {
> - *ep = 0;
> + ep = url + strlen(remote->url) + 1;
> + int has_fs = 0;
decl-after-statement.
And name-not-meaningful. What does "has_fs" stand for?
> + while (1) {
> + ep = strchr(ep + 1, '/');
> + if(ep) {
> + ep++;
> + ep_old=*ep;
Okay, you succeeded in fooling me. It took fully five minutes until I
realized that ep_old is not the old value of ep, but of *ep.
And now I know what has_fs does, but the name is an even bigger puzzle.
Almost as big as the puzzle why you did not do a much less intrusive
change:
- after the "while (ep) {" you could say "char saved_character = ep[1];
- then you replace the "*ep = 0" by "ep[1] = '\0';"
- at the end of the loop, you replace the "*ep = '/'" with "ep[1] =
saved_character;"
That way, not only would the patch be much smaller, it would also not have
been as difficult to review as it was.
Ciao,
Dscho
^ permalink raw reply [relevance 0%]
* Re: [PATCH 1/3] http-push: append slash if possible for directories
2009-01-17 2:53 13% [PATCH 1/3] http-push: append slash if possible for directories Ray Chuan
@ 2009-01-17 5:19 0% ` Johannes Schindelin
2009-01-17 6:02 0% ` Johannes Schindelin
1 sibling, 0 replies; 128+ results
From: Johannes Schindelin @ 2009-01-17 5:19 UTC (permalink / raw)
To: Ray Chuan; +Cc: git
Hi,
On Sat, 17 Jan 2009, Ray Chuan wrote:
> src/git-1.6.1/http-push.c | 21 ++++++++++++++++-----
That is a, uhm, creative way of using Git...
Ciao,
Dscho
^ permalink raw reply [relevance 0%]
* [PATCH 3/3] http-push: update tests
@ 2009-01-17 2:59 14% Ray Chuan
0 siblings, 0 replies; 128+ results
From: Ray Chuan @ 2009-01-17 2:59 UTC (permalink / raw)
To: git
note: the test needs to chmod the test_repo.git folder so that
apache/mod_dav can create .DAV folders in it for locking.
Signed-off-by: Tay Ray Chuan <rctay89@gmail.com>
---
src/git-1.6.1/t/t5540-http-push.sh | 7 +++----
1 files changed, 3 insertions(+), 4 deletions(-)
diff --git a/src/git-1.6.1/t/t5540-http-push.sh
b/src/git-1.6.1/t/t5540-http-push.sh
index da95886..730b9cb 100755
--- a/src/git-1.6.1/t/t5540-http-push.sh
+++ b/src/git-1.6.1/t/t5540-http-push.sh
@@ -51,17 +51,16 @@ test_expect_success 'clone remote repository' '
git clone $HTTPD_URL/test_repo.git test_repo_clone
'
-test_expect_failure 'push to remote repository' '
+test_expect_success 'push to remote repository' '
cd "$ROOT_PATH"/test_repo_clone &&
: >path2 &&
git add path2 &&
test_tick &&
git commit -m path2 &&
- git push &&
- [ -f "$HTTPD_DOCUMENT_ROOT_PATH/test_repo.git/refs/heads/master" ]
+ git push origin master
'
-test_expect_failure 'create and delete remote branch' '
+test_expect_success 'create and delete remote branch' '
cd "$ROOT_PATH"/test_repo_clone &&
git checkout -b dev &&
: >path3 &&
--
1.6.0.4
^ permalink raw reply related [relevance 14%]
* [PATCH 2/3] http-push: when sending objects, don't PUT before MOVE
@ 2009-01-17 2:59 12% Ray Chuan
2009-01-17 6:13 0% ` Johannes Schindelin
0 siblings, 1 reply; 128+ results
From: Ray Chuan @ 2009-01-17 2:59 UTC (permalink / raw)
To: git
since 753bc911f489748a837ecb5ea4b5216220b24845, the opaquelocktocken
URI isn't used, so it doesn't make sense to PUT then MOVE.
currently, git PUTs to
/repo.git/objects/1a/1a2b..._opaquelocktoken:1234-....
on some platforms, ':' isn't allowed in filenames so this fails
(assuming the server doesn't recognize it as opaquelocktoken scheme).
in fact, i don't think this is the correct implementation of the
scheme; 'opaquelocktoken: ' should come in front of the path.
Signed-off-by: Tay Ray Chuan <rctay89@gmail.com>
---
src/git-1.6.1/http-push.c | 45 +--------------------------------------------
1 files changed, 1 insertions(+), 44 deletions(-)
diff --git a/src/git-1.6.1/http-push.c b/src/git-1.6.1/http-push.c
index a646a49..838ff6f 100644
--- a/src/git-1.6.1/http-push.c
+++ b/src/git-1.6.1/http-push.c
@@ -31,7 +31,6 @@ enum XML_Status {
/* DAV methods */
#define DAV_LOCK "LOCK"
#define DAV_MKCOL "MKCOL"
-#define DAV_MOVE "MOVE"
#define DAV_PROPFIND "PROPFIND"
#define DAV_PUT "PUT"
#define DAV_UNLOCK "UNLOCK"
@@ -104,7 +103,6 @@ enum transfer_state {
NEED_PUSH,
RUN_MKCOL,
RUN_PUT,
- RUN_MOVE,
ABORTED,
COMPLETE,
};
@@ -528,11 +526,6 @@ static void start_put(struct transfer_request *request)
posn += 2;
*(posn++) = '/';
strcpy(posn, hex + 2);
- request->dest = xmalloc(strlen(request->url) + 14);
- sprintf(request->dest, "Destination: %s", request->url);
- posn += 38;
- *(posn++) = '_';
- strcpy(posn, request->lock->token);
slot = get_active_slot();
slot->callback_func = process_response;
@@ -557,32 +550,6 @@ static void start_put(struct transfer_request *request)
}
}
-static void start_move(struct transfer_request *request)
-{
- struct active_request_slot *slot;
- struct curl_slist *dav_headers = NULL;
-
- slot = get_active_slot();
- slot->callback_func = process_response;
- slot->callback_data = request;
- curl_easy_setopt(slot->curl, CURLOPT_HTTPGET, 1); /* undo PUT setup */
- curl_easy_setopt(slot->curl, CURLOPT_CUSTOMREQUEST, DAV_MOVE);
- dav_headers = curl_slist_append(dav_headers, request->dest);
- dav_headers = curl_slist_append(dav_headers, "Overwrite: T");
- curl_easy_setopt(slot->curl, CURLOPT_HTTPHEADER, dav_headers);
- curl_easy_setopt(slot->curl, CURLOPT_WRITEFUNCTION, fwrite_null);
- curl_easy_setopt(slot->curl, CURLOPT_URL, request->url);
-
- if (start_active_slot(slot)) {
- request->slot = slot;
- request->state = RUN_MOVE;
- } else {
- request->state = ABORTED;
- free(request->url);
- request->url = NULL;
- }
-}
-
static int refresh_lock(struct remote_lock *lock)
{
struct active_request_slot *slot;
@@ -705,23 +672,13 @@ static void finish_request(struct
transfer_request *request)
}
} else if (request->state == RUN_PUT) {
if (request->curl_result == CURLE_OK) {
- start_move(request);
- } else {
- fprintf(stderr, "PUT %s failed, aborting (%d/%ld)\n",
- sha1_to_hex(request->obj->sha1),
- request->curl_result, request->http_code);
- request->state = ABORTED;
- aborted = 1;
- }
- } else if (request->state == RUN_MOVE) {
- if (request->curl_result == CURLE_OK) {
if (push_verbosely)
fprintf(stderr, " sent %s\n",
sha1_to_hex(request->obj->sha1));
request->obj->flags |= REMOTE;
release_request(request);
} else {
- fprintf(stderr, "MOVE %s failed, aborting (%d/%ld)\n",
+ fprintf(stderr, "PUT %s failed, aborting (%d/%ld)\n",
sha1_to_hex(request->obj->sha1),
request->curl_result, request->http_code);
request->state = ABORTED;
--
1.6.0.4
^ permalink raw reply related [relevance 12%]
* [PATCH 1/3] http-push: append slash if possible for directories
@ 2009-01-17 2:53 13% Ray Chuan
2009-01-17 5:19 0% ` Johannes Schindelin
2009-01-17 6:02 0% ` Johannes Schindelin
0 siblings, 2 replies; 128+ results
From: Ray Chuan @ 2009-01-17 2:53 UTC (permalink / raw)
To: git
the lock_remote currently sends MKCOL requests to leading directories
to make sure they exist; however, it doesn't put a forward slash '/'
behind the path, so if the path is a directory, the server sends a 301
redirect.
by appending a '/' we can save the server this additional step.
in addition, it seems that curl doesn't re-send the authentication
credentials when it follows a 301 redirect, so skipping (unnecessary)
redirects can also be seen as a workaround for this issue. (i'm using
7.16.3)
Signed-off-by: Tay Ray Chuan <rctay89@gmail.com>
---
src/git-1.6.1/http-push.c | 21 ++++++++++++++++-----
1 files changed, 16 insertions(+), 5 deletions(-)
diff --git a/src/git-1.6.1/http-push.c b/src/git-1.6.1/http-push.c
index 7c64609..25b655d 100644
--- a/src/git-1.6.1/http-push.c
+++ b/src/git-1.6.1/http-push.c
@@ -1189,6 +1189,7 @@ static struct remote_lock *lock_remote(const
char *path, long timeout)
struct strbuf in_buffer = STRBUF_INIT;
char *url;
char *ep;
+ char ep_old;
char timeout_header[25];
struct remote_lock *lock = NULL;
struct curl_slist *dav_headers = NULL;
@@ -1198,9 +1199,18 @@ static struct remote_lock *lock_remote(const
char *path, long timeout)
sprintf(url, "%s%s", remote->url, path);
/* Make sure leading directories exist for the remote ref */
- ep = strchr(url + strlen(remote->url) + 1, '/');
- while (ep) {
- *ep = 0;
+ ep = url + strlen(remote->url) + 1;
+ int has_fs = 0;
+ while (1) {
+ ep = strchr(ep + 1, '/');
+ if(ep) {
+ ep++;
+ ep_old=*ep;
+ *ep = 0;
+ has_fs = 1;
+ } else {
+ break;
+ }
slot = get_active_slot();
slot->results = &results;
curl_easy_setopt(slot->curl, CURLOPT_HTTPGET, 1);
@@ -1222,8 +1232,9 @@ static struct remote_lock *lock_remote(const
char *path, long timeout)
free(url);
return NULL;
}
- *ep = '/';
- ep = strchr(ep + 1, '/');
+ if(has_fs) {
+ *ep = ep_old;
+ }
}
strbuf_addf(&out_buffer.buf, LOCK_REQUEST, git_default_email);
--
1.6.0.4
^ permalink raw reply related [relevance 13%]
* git add --patch bug with split+edit?
@ 2009-01-17 1:37 3% Hannu Koivisto
0 siblings, 0 replies; 128+ results
From: Hannu Koivisto @ 2009-01-17 1:37 UTC (permalink / raw)
To: git
Greetings,
If I have a hunk that adds three lines, I can edit the hunk and
remove the last line but I can't split it in two, stage the first
part, edit the second part and remove the last line. An example:
mkdir gittest
cd gittest
git init
echo "baz\nbaz" > baz
git add baz
git commit -m baz baz
rm baz
echo "sur\nbaz\nbaz\njee\njee" > baz
git add --patch
Now say 's RET y RET e RET' and remove the second "+jee" line using
your editor. The output for me looks like this:
--8<-----------------------------------------------------------------
diff --git a/baz b/baz
index 1f55335..48a5f83 100644
--- a/baz
+++ b/baz
@@ -1,2 +1,5 @@
+sur
baz
baz
+jee
+jee
Stage this hunk [y/n/a/d/s/e/?]? s
Split into 2 hunks.
@@ -1,2 +1,3 @@
+sur
baz
baz
Stage this hunk [y/n/a/d/j/J/e/?]? y
@@ -1,2 +2,4 @@
baz
baz
+jee
+jee
Stage this hunk [y/n/a/d/K/e/?]? e
Waiting for Emacs...
error: patch failed: baz:1
error: baz: patch does not apply
Your edited hunk does not apply. Edit again (saying "no" discards!) [y/n]?
--8<-----------------------------------------------------------------
What I also didn't expect is that if I answer 'n' to that last
question, I get...
@@ -1,2 +1,3 @@
+sur
baz
baz
Stage this hunk [y/n/a/d/j/J/e/?]?
...which is the first part of the splitted hunk that I already
staged. If I answer 'd', git status and git diff indicate that
"+sur" is nevertheless staged.
Now, if instead of splitting the hunk and editing it, I edit the
entire...
@@ -1,2 +1,5 @@
+sur
baz
baz
+jee
+jee
...hunk and remove the last "+jee" line, I get no error.
I'm using git 1.6.1 on Linux.
--
Hannu
^ permalink raw reply related [relevance 3%]
* Re: rebase -p confusion in 1.6.1
@ 2009-01-15 13:39 4% ` Michael J Gruber
0 siblings, 0 replies; 128+ results
From: Michael J Gruber @ 2009-01-15 13:39 UTC (permalink / raw)
To: Sitaram Chamarty; +Cc: git, Stephen Haberman
Sitaram Chamarty venit, vidit, dixit 15.01.2009 11:39:
> Hello all,
>
> While trying to understand "rebase -p", I came across some
> very unexpected behaviour that made me throw in the towel
> and ask for help!
>
> The outputs I got really confused me. Before the "rebase
> -p", the tree looked like
>
> * 78ffda9... (refs/heads/work) b4
> * be1e3a4... b3
> * cd8d893... Merge branch 'master' into work
> |\
> | * 0153c27... (refs/heads/master) a4
> | * 74f4387... a3
> * | f1b0c1c... b2
> * | 2e202d0... b1
> |/
> * b37ae36... a2
> * ed1e1bc... a1
>
> But afterward, this is what it looks like -- all the "b"
> commits are gone!
>
> * 0153c27... (refs/heads/work, refs/heads/master) a4
> * 74f4387... a3
> * b37ae36... a2
> * ed1e1bc... a1
>
> What did I do wrong/misunderstand?
>
> Here's how to recreate. Note that "testci" is a shell
> function and "lg" is a git alias. They are, respectively,
> (1) testci() { for i; do echo $i > $i; git add $i; git commit -m $i; done; }
> (2) git config alias.lg log --graph --pretty=oneline --abbrev-commit --decorate
>
> git init
> testci a1 a2
> git checkout -b work
> testci b1 b2
> git checkout master
> testci a3 a4
> git checkout work
> git merge master
> testci b3 b4
> git --no-pager lg # graph before rebase -p
> git rebase -p master
> git --no-pager lg # graph after rebase -p
>
First of all: git 1.6.0.6 gives you the unchanged graph after using
rebase -i -p (git 1.6.1 adds -i behind you back and sets up a dummy
editor). In any case, git rebase should not simply eat those commits -
either leave them alone or rewrite them. git bisect says
d80d6bc146232d81f1bb4bc58e5d89263fd228d4 is first bad commit
commit d80d6bc146232d81f1bb4bc58e5d89263fd228d4
Author: Stephen Haberman <stephen@exigencecorp.com>
Date: Wed Oct 15 02:44:39 2008 -0500
rebase-i-p: do not include non-first-parent commits touching UPSTREAM
so I'll cc the bad guy ;)
Second, what result do you expect? If the merge is to be preserved then
b1, b2 can't be simply ripped out - or else you get the linear structure
which rebase without '-p' delivers. The merge base (as returned by git
merge-base) between work and master is a4, i.e. master, so that the
expected result with '-p' is the one from 1.6.0.6 (unchanged graph).
Cheers,
Michael
^ permalink raw reply [relevance 4%]
* Re: [2/3] git-daemon: use getnameinfo to resolve hostname
@ 2009-01-14 19:25 4% ` Jan Engelhardt
0 siblings, 0 replies; 128+ results
From: Jan Engelhardt @ 2009-01-14 19:25 UTC (permalink / raw)
To: Jeff King; +Cc: git
On Wednesday 2009-01-14 13:25, Jeff King wrote:
>On Wed, Jan 14, 2009 at 11:48:38AM +0100, Jan Engelhardt wrote:
>
>> This is much shorter than inet_ntop'ing, and also translated
>> unresolvable addresses into a string.
>
>Er, doesn't this totally change the meaning of REMOTE_ADDR from an IP
>address to a hostname? That seems bad because:
>[...]
> - people already have hooks that compare REMOTE_ADDR against an
> address, so we are breaking their hooks
>[...]
>So at the very least, you should be adding REMOTE_HOST in _addition_ to
>REMOTE_ADDR, not instead of.
Good catch. It's always good to have someone else look through it.
Changed, and below is the proposition as a non-mergable diff.
In case getnameinfo fails, the IP address from inet_ntop
should be left in addrbuf, is not it?
And yeah, it does not have a flag to disable DNS resolution, but
it's a draft for now.
---8<---
git-daemon: resolve source host's DNS
Try to resolve DNS addresses so that run_service() can print the
name of the host from which the request originated.
[addrbuf is passed to run_service as a result of patch 1/3]
---
daemon.c | 4 ++++
1 file changed, 4 insertions(+)
Index: git-1.6.1/daemon.c
===================================================================
--- git-1.6.1.orig/daemon.c
+++ git-1.6.1/daemon.c
@@ -530,6 +530,10 @@ static int execute(struct sockaddr *addr
#endif
}
setenv("REMOTE_ADDR", addrbuf, 1);
+ getnameinfo(addr, (addr->sa_family == AF_INET6) ?
+ sizeof(struct sockaddr_in6) :
+ sizeof(struct sockaddr_in),
+ addrbuf, sizeof(addrbuf), NULL, 0, 0);
}
else {
unsetenv("REMOTE_ADDR");
^ permalink raw reply [relevance 4%]
* [PATCH 3/3] git-daemon: vhost support
2009-01-14 10:48 4% ` [PATCH 2/3] git-daemon: use getnameinfo to resolve hostname Jan Engelhardt
@ 2009-01-14 10:49 4% ` Jan Engelhardt
1 sibling, 0 replies; 128+ results
From: Jan Engelhardt @ 2009-01-14 10:49 UTC (permalink / raw)
To: git
parent v1.6.1
git-daemon: support vhosts
Since git clients usually send the target hostname in the request
similar to the "Host:" HTTP header, one can do virtual hosting.
Signed-off-by: Jan Engelhardt <jengelh@medozas.de>
---
daemon.c | 22 +++++++++++++++++++---
1 file changed, 19 insertions(+), 3 deletions(-)
Index: git-1.6.1/daemon.c
===================================================================
--- git-1.6.1.orig/daemon.c
+++ git-1.6.1/daemon.c
@@ -2,6 +2,7 @@
#include "pkt-line.h"
#include "exec_cmd.h"
+#include <stdbool.h>
#include <syslog.h>
#ifndef HOST_NAME_MAX
@@ -21,7 +22,7 @@ static const char daemon_usage[] =
" [--timeout=n] [--init-timeout=n] [--max-connections=n]\n"
" [--strict-paths] [--base-path=path] [--base-path-relaxed]\n"
" [--user-path | --user-path=path]\n"
-" [--interpolated-path=path]\n"
+" [--interpolated-path=path] [--vhost]\n"
" [--reuseaddr] [--detach] [--pid-file=file]\n"
" [--[enable|disable|allow-override|forbid-override]=service]\n"
" [--inetd | [--listen=host_or_ipaddr] [--port=n]\n"
@@ -36,6 +37,7 @@ static int strict_paths;
static int export_all_trees;
/* Take all paths relative to this one if non-NULL */
+static bool enable_vhosting;
static char *base_path;
static char *interpolated_path;
static int base_path_relaxed;
@@ -309,8 +311,18 @@ static int run_service(char *dir, struct
return -1;
}
- if (!(path = path_ok(dir)))
- return -1;
+ if (enable_vhosting) {
+ char vdir[256];
+
+ if (avoid_alias(dir) != 0)
+ return -1;
+ snprintf(vdir, sizeof(vdir), "/%s%s", hostname, dir);
+ if ((path = path_ok(vdir)) == NULL)
+ return -1;
+ } else {
+ if ((path = path_ok(dir)) == NULL)
+ return -1;
+ }
/*
* Security on the cheap.
@@ -1046,6 +1058,10 @@ int main(int argc, char **argv)
make_service_overridable(arg + 18, 0);
continue;
}
+ if (strcmp(arg, "--vhost") == 0) {
+ enable_vhosting = true;
+ continue;
+ }
if (!strcmp(arg, "--")) {
ok_paths = &argv[i+1];
break;
^ permalink raw reply [relevance 4%]
* [PATCH 2/3] git-daemon: use getnameinfo to resolve hostname
2009-01-14 10:48 3% [PATCH 1/3] git-daemon: single-line logs Jan Engelhardt
@ 2009-01-14 10:48 4% ` Jan Engelhardt
2009-01-14 10:49 4% ` [PATCH 3/3] git-daemon: vhost support Jan Engelhardt
0 siblings, 2 replies; 128+ results
From: Jan Engelhardt @ 2009-01-14 10:48 UTC (permalink / raw)
To: git
parent v1.6.1
git-daemon: use getnameinfo to resolve hostname
This is much shorter than inet_ntop'ing, and also translated
unresolvable addresses into a string.
Signed-off-by: Jan Engelhardt <jengelh@medozas.de>
---
daemon.c | 26 +++++++-------------------
1 file changed, 7 insertions(+), 19 deletions(-)
Index: git-1.6.1/daemon.c
===================================================================
--- git-1.6.1.orig/daemon.c
+++ git-1.6.1/daemon.c
@@ -512,25 +512,13 @@ static int execute(struct sockaddr *addr
int pktlen, len, i;
if (addr) {
- int port = -1;
-
- if (addr->sa_family == AF_INET) {
- struct sockaddr_in *sin_addr = (void *) addr;
- inet_ntop(addr->sa_family, &sin_addr->sin_addr, addrbuf, sizeof(addrbuf));
- port = ntohs(sin_addr->sin_port);
-#ifndef NO_IPV6
- } else if (addr && addr->sa_family == AF_INET6) {
- struct sockaddr_in6 *sin6_addr = (void *) addr;
-
- char *buf = addrbuf;
- *buf++ = '['; *buf = '\0'; /* stpcpy() is cool */
- inet_ntop(AF_INET6, &sin6_addr->sin6_addr, buf, sizeof(addrbuf) - 1);
- strcat(buf, "]");
-
- port = ntohs(sin6_addr->sin6_port);
-#endif
- }
- setenv("REMOTE_ADDR", addrbuf, 1);
+ i = getnameinfo(addr, (addr->sa_family == AF_INET6) ?
+ sizeof(struct sockaddr_in6) : sizeof(struct sockaddr_in),
+ addrbuf, sizeof(addrbuf), NULL, 0, 0);
+ if (i == 0)
+ setenv("REMOTE_ADDR", addrbuf, 1);
+ else
+ unsetenv("REMOTE_ADDR");
}
else {
unsetenv("REMOTE_ADDR");
^ permalink raw reply [relevance 4%]
* [PATCH 1/3] git-daemon: single-line logs
@ 2009-01-14 10:48 3% Jan Engelhardt
2009-01-14 10:48 4% ` [PATCH 2/3] git-daemon: use getnameinfo to resolve hostname Jan Engelhardt
0 siblings, 1 reply; 128+ results
From: Jan Engelhardt @ 2009-01-14 10:48 UTC (permalink / raw)
To: git
parent v1.6.1
git-daemon: single-line logs
Having just a single line per connection attempt, much like Apache
httpd2 access logs, makes log parsing much easier, especially when
just glancing over it non-automated.
Signed-off-by: Jan Engelhardt <jengelh@medozas.de>
---
daemon.c | 15 ++++++---------
1 file changed, 6 insertions(+), 9 deletions(-)
Index: git-1.6.1/daemon.c
===================================================================
--- git-1.6.1.orig/daemon.c
+++ git-1.6.1/daemon.c
@@ -295,12 +295,13 @@ static int git_daemon_config(const char
return 0;
}
-static int run_service(char *dir, struct daemon_service *service)
+static int run_service(char *dir, struct daemon_service *service,
+ const char *origin, const char *vhost)
{
const char *path;
int enabled = service->enabled;
- loginfo("Request %s for '%s'", service->name, dir);
+ loginfo("%s->%s %s \"%s\"\n", origin, vhost, service->name, dir);
if (!enabled && !service->overridable) {
logerror("'%s': service not enabled.", service->name);
@@ -507,10 +508,10 @@ static void parse_extra_args(char *extra
static int execute(struct sockaddr *addr)
{
static char line[1000];
+ char addrbuf[256] = "";
int pktlen, len, i;
if (addr) {
- char addrbuf[256] = "";
int port = -1;
if (addr->sa_family == AF_INET) {
@@ -529,7 +530,6 @@ static int execute(struct sockaddr *addr
port = ntohs(sin6_addr->sin6_port);
#endif
}
- loginfo("Connection from %s:%d", addrbuf, port);
setenv("REMOTE_ADDR", addrbuf, 1);
}
else {
@@ -541,10 +541,6 @@ static int execute(struct sockaddr *addr
alarm(0);
len = strlen(line);
- if (pktlen != len)
- loginfo("Extended attributes (%d bytes) exist <%.*s>",
- (int) pktlen - len,
- (int) pktlen - len, line + len + 1);
if (len && line[len-1] == '\n') {
line[--len] = 0;
pktlen--;
@@ -569,7 +565,8 @@ static int execute(struct sockaddr *addr
* Note: The directory here is probably context sensitive,
* and might depend on the actual service being performed.
*/
- return run_service(line + namelen + 5, s);
+ return run_service(line + namelen + 5, s,
+ addrbuf, hostname);
}
}
^ permalink raw reply [relevance 3%]
* [RFC/PATCH] gitweb: Fix nested links problem with ref markers
2009-01-13 0:59 0% ` Giuseppe Bilotta
@ 2009-01-14 0:17 0% ` Jakub Narebski
0 siblings, 0 replies; 128+ results
From: Jakub Narebski @ 2009-01-14 0:17 UTC (permalink / raw)
To: Giuseppe Bilotta; +Cc: git
On Tue, 13 Jan 2009, Giuseppe Bilotta wrote:
> On Mon, Jan 12, 2009 at 7:13 PM, Jakub Narebski <jnareb@gmail.com> wrote:
>> On Mon, 12 Jan 2009, Giuseppe Bilotta wrote:
>>> On Sun, Jan 11, 2009 at 8:15 PM, Jakub Narebski <jnareb@gmail.com> wrote:
[...]
> Notice that nested links are actually valid *XML*. Indeed, I asked on
> www-style and they suggested leaving the problem as-is, serving as
> html+xml which is what we do.
But nested links are neither valid HTML nor valid XHTML. This
restriction (no nested links) is IMVHO quite sensible, but IIRC
it simply cannot be expressed as pure XML restriction (DTD, XML Schema,
Relax-NG... perhaps Sablotron can express this restriction).
>>>> * Revert 4afbaef (we lose feature, but how often used is it?)
>>>> * Always use quirks mode, or check browser and use quirks mode if it
>>>> would break layout
>>>> * Use extra divs and links and CSS positioning to make layout which
>>>> looks like current one, and behaves as current one, but is more
>>>> complicated.
>>>
>>> I'm asking on #html, hopefully I'll get some interesting idea to try for this.
>>
>> I have found _a_ solution. Perhaps not the best one, but it works.
>> And IMHO gives / can give even better visual.
>>
>> Current version (line wrapped for better visibility):
[...]
>> Proposed code (line wrapped for better visibility, with CSS embedded,
>> which would change in final version of course). Only parts of style
>> related to positioning are shown.
>> <div class="header">
>> <a href="..." style="float: left; margin: 6px 1px 6px 8px;">GIT 1.6.1</a>
>> <div style="float: left; margin: 6px 1px;">
>> <span class="refs">
>> <span class="tag indirect" title="tags/v1.6.1">
>> <a href="...">v1.6.1</a>
>> </span>
>> </span>
>> </div>
>> <a href="..." style="display: block; padding: 6px 8px;"> </a>
>> </div>
[...]
>> What do you think?
>
> The float thing was the second suggestion I was given on www-style.
What was the first suggestion? And what is www-style?
> Can you provide a patch I can apply to my tree for testing to see how
> it comes up?
Here it is. Note that CSS could be I think reduced. The size of
gitweb.perl changes is affected by changing calling convention for
git_print_header_html subroutine.
There is also strange artifact at least in Mozilla 1.17.2: if I hover
over ref marker, the subject (title) gets darker background. Curious...
-- >8 --
From: Jakub Narebski <jnareb@gmail.com>
Date: Wed, 14 Jan 2009 01:07:30 +0100
Subject: [RFC/PATCH] gitweb: Fix nested links problem with ref markers
Now that ref markers are links, they create nested links which are not
allowed in HTML, and in strict mode in some browsers it causes layout
errors.
It fixes format_subject_html subroutine (used for example in
'shortlog' view) to put $extra (which currently is formatted ref
marker) outside "subject" link, as $extra can contain links and in
HTML links cannot be nested.
It changes calling convention of git_print_header_div (and accordingly
its calling sites) to provide $ref as separate argument, instead of
concatenating it and putting it in $title, and provides workaround so
links are not nested.
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
---
gitweb/gitweb.css | 25 +++++++++++++++++++++-
gitweb/gitweb.perl | 56 ++++++++++++++++++++++++++++++++-------------------
2 files changed, 58 insertions(+), 23 deletions(-)
diff --git a/gitweb/gitweb.css b/gitweb/gitweb.css
index a01eac8..244eea2 100644
--- a/gitweb/gitweb.css
+++ b/gitweb/gitweb.css
@@ -76,23 +76,44 @@ div.page_body {
font-family: monospace;
}
-div.title, a.title {
+div.title, a.block {
display: block;
padding: 6px 8px;
+ text-decoration: none;
+ background-color: #edece6;
+}
+
+div.title, a.title {
font-weight: bold;
background-color: #edece6;
text-decoration: none;
color: #000000;
}
+div.header div.extra,
+div.header a.float {
+ float: left;
+ margin: 6px 1px;
+}
+
+div.header a.float {
+ margin: 6px 1px 6px 8px;
+}
+
div.readme {
padding: 8px;
}
-a.title:hover {
+a.block:hover,
+div.header:hover a.title {
background-color: #d9d8d1;
}
+div.header a.title:hover {
+ background-color: #edece6; /* ??? */
+ text-decoration: underline;
+}
+
div.title_text {
padding: 6px 0px;
border: solid #d9d8d1;
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index 0ac84d1..9c192ba 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -1408,6 +1408,7 @@ sub format_ref_marker {
}
# format, perhaps shortened and with markers, title line
+# $extra can contain links, and nested links are illegal in HTML
sub format_subject_html {
my ($long, $short, $href, $extra) = @_;
$extra = '' unless defined($extra);
@@ -1415,10 +1416,10 @@ sub format_subject_html {
if (length($short) < length($long)) {
return $cgi->a({-href => $href, -class => "list subject",
-title => to_utf8($long)},
- esc_html($short) . $extra);
+ esc_html($short)) . $extra;
} else {
return $cgi->a({-href => $href, -class => "list subject"},
- esc_html($long) . $extra);
+ esc_html($long)) . $extra;
}
}
@@ -3146,17 +3147,30 @@ sub format_paging_nav {
## functions printing or outputting HTML: div
sub git_print_header_div {
- my ($action, $title, $hash, $hash_base) = @_;
+ my ($action, $title, $ref, $hash, $hash_base) = @_;
my %args = ();
$args{'action'} = $action;
$args{'hash'} = $hash if $hash;
$args{'hash_base'} = $hash_base if $hash_base;
- print "<div class=\"header\">\n" .
- $cgi->a({-href => href(%args), -class => "title"},
- $title ? $title : $action) .
- "\n</div>\n";
+ my $href = href(%args);
+ if ($ref) {
+ # $ref can contain links, and nested links are illegal in HTML
+ # that is why we do this trick (see also gitweb.css for style)
+ # of title text, ref markers and 'background' link
+ print "<div class=\"header\">\n" .
+ $cgi->a({-href => $href, -class => "title float"},
+ $title ? $title : $action) . "\n" .
+ "<div class=\"extra\">\n$ref\n</div>\n" .
+ $cgi->a({-href => $href, -class => "block"}, ' ') .
+ "\n</div>\n"; # class="header"
+ } else {
+ print "<div class=\"header\">\n" .
+ $cgi->a({-href => $href, -class => "title block"},
+ $title ? $title : $action) .
+ "\n</div>\n"; # class="header"
+ }
}
#sub git_print_authorship (\%) {
@@ -3781,7 +3795,7 @@ sub git_patchset_body {
while ($patch_line) {
# parse "git diff" header line
- if ($patch_line =~ m/^diff --git (\"(?:[^\\\"]*(?:\\.[^\\\"]*)*)\"|[^ "]*) (.*)$/) {
+ if ($patch_line =~ m/^diff --git (\"(?:[^\\\"]*(?:\\.[^\\\"]*)*)\"|[^ \"]*) (.*)$/) {
# $1 is from_name, which we do not use
$to_name = unquote($2);
$to_name =~ s!^b/!!;
@@ -4523,7 +4537,7 @@ sub git_tag {
die_error(404, "Unknown tag object");
}
- git_print_header_div('commit', esc_html($tag{'name'}), $hash);
+ git_print_header_div('commit', esc_html($tag{'name'}), undef, $hash);
print "<div class=\"title_text\">\n" .
"<table class=\"object_header\">\n" .
"<tr>\n" .
@@ -4591,7 +4605,7 @@ sub git_blame {
$cgi->a({-href => href(action=>"blame", file_name=>$file_name)},
"HEAD");
git_print_page_nav('','', $hash_base,$co{'tree'},$hash_base, $formats_nav);
- git_print_header_div('commit', esc_html($co{'title'}), $hash_base);
+ git_print_header_div('commit', esc_html($co{'title'}), undef, $hash_base);
git_print_page_path($file_name, $ftype, $hash_base);
# page body
@@ -4797,7 +4811,7 @@ sub git_blob {
"raw");
}
git_print_page_nav('','', $hash_base,$co{'tree'},$hash_base, $formats_nav);
- git_print_header_div('commit', esc_html($co{'title'}), $hash_base);
+ git_print_header_div('commit', esc_html($co{'title'}), undef, $hash_base);
} else {
print "<div class=\"page_nav\">\n" .
"<br/><br/></div>\n" .
@@ -4870,7 +4884,7 @@ sub git_tree {
push @views_nav, $snapshot_links;
}
git_print_page_nav('tree','', $hash_base, undef, undef, join(' | ', @views_nav));
- git_print_header_div('commit', esc_html($co{'title'}) . $ref, $hash_base);
+ git_print_header_div('commit', esc_html($co{'title'}), $ref, $hash_base);
} else {
undef $hash_base;
print "<div class=\"page_nav\">\n";
@@ -5009,7 +5023,7 @@ sub git_log {
my %ad = parse_date($co{'author_epoch'});
git_print_header_div('commit',
"<span class=\"age\">$co{'age_string'}</span>" .
- esc_html($co{'title'}) . $ref,
+ esc_html($co{'title'}), $ref,
$commit);
print "<div class=\"title_text\">\n" .
"<div class=\"log_link\">\n" .
@@ -5097,9 +5111,9 @@ sub git_commit {
$formats_nav);
if (defined $co{'parent'}) {
- git_print_header_div('commitdiff', esc_html($co{'title'}) . $ref, $hash);
+ git_print_header_div('commitdiff', esc_html($co{'title'}), $ref, $hash);
} else {
- git_print_header_div('tree', esc_html($co{'title'}) . $ref, $co{'tree'}, $hash);
+ git_print_header_div('tree', esc_html($co{'title'}), $ref, $co{'tree'}, $hash);
}
print "<div class=\"title_text\">\n" .
"<table class=\"object_header\">\n";
@@ -5292,7 +5306,7 @@ sub git_blobdiff {
git_header_html(undef, $expires);
if (defined $hash_base && (my %co = parse_commit($hash_base))) {
git_print_page_nav('','', $hash_base,$co{'tree'},$hash_base, $formats_nav);
- git_print_header_div('commit', esc_html($co{'title'}), $hash_base);
+ git_print_header_div('commit', esc_html($co{'title'}), undef, $hash_base);
} else {
print "<div class=\"page_nav\"><br/>$formats_nav<br/></div>\n";
print "<div class=\"title\">$hash vs $hash_parent</div>\n";
@@ -5462,7 +5476,7 @@ sub git_commitdiff {
git_header_html(undef, $expires);
git_print_page_nav('commitdiff','', $hash,$co{'tree'},$hash, $formats_nav);
- git_print_header_div('commit', esc_html($co{'title'}) . $ref, $hash);
+ git_print_header_div('commit', esc_html($co{'title'}), $ref, $hash);
git_print_authorship(\%co);
print "<div class=\"page_body\">\n";
if (@{$co{'comment'}} > 1) {
@@ -5579,7 +5593,7 @@ sub git_history {
git_header_html();
git_print_page_nav('history','', $hash_base,$co{'tree'},$hash_base, $paging_nav);
- git_print_header_div('commit', esc_html($co{'title'}), $hash_base);
+ git_print_header_div('commit', esc_html($co{'title'}), undef, $hash_base);
git_print_page_path($file_name, $ftype, $hash_base);
git_history_body(\@commitlist, 0, 99,
@@ -5660,13 +5674,13 @@ sub git_search {
}
git_print_page_nav('','', $hash,$co{'tree'},$hash, $paging_nav);
- git_print_header_div('commit', esc_html($co{'title'}), $hash);
+ git_print_header_div('commit', esc_html($co{'title'}), undef, $hash);
git_search_grep_body(\@commitlist, 0, 99, $next_link);
}
if ($searchtype eq 'pickaxe') {
git_print_page_nav('','', $hash,$co{'tree'},$hash);
- git_print_header_div('commit', esc_html($co{'title'}), $hash);
+ git_print_header_div('commit', esc_html($co{'title'}), undef, $hash);
print "<table class=\"pickaxe search\">\n";
my $alternate = 1;
@@ -5735,7 +5749,7 @@ sub git_search {
if ($searchtype eq 'grep') {
git_print_page_nav('','', $hash,$co{'tree'},$hash);
- git_print_header_div('commit', esc_html($co{'title'}), $hash);
+ git_print_header_div('commit', esc_html($co{'title'}), undef, $hash);
print "<table class=\"grep_search\">\n";
my $alternate = 1;
--
1.6.0.4
^ permalink raw reply related [relevance 0%]
* git-svn fails to fetch repository
@ 2009-01-13 14:53 4% Vladimir Pouzanov
0 siblings, 0 replies; 128+ results
From: Vladimir Pouzanov @ 2009-01-13 14:53 UTC (permalink / raw)
To: git
Hi all,
I'm trying to fetch svn repository:
git svn clone http://qsb-mac.googlecode.com/svn/trunk qsb-mac
This one fails at random time at:
Temp file with moniker ' at /opt/local/lib/perl5/site_perl/5.8.8/Git.pm
line 1011.
I know nothing about perl, so can't make anything out of that. Any hints?
Running Git 1.6.1, perl 5.8.8, OSX 10.5.6
PS: Please CC me on answer.
^ permalink raw reply [relevance 4%]
* Re: [BUG/RFH] gitweb: Trouble with ref markers being hyperlinks because of illegally nested links
2009-01-13 0:13 5% ` Jakub Narebski
@ 2009-01-13 0:59 0% ` Giuseppe Bilotta
2009-01-14 0:17 0% ` [RFC/PATCH] gitweb: Fix nested links problem with ref markers Jakub Narebski
0 siblings, 1 reply; 128+ results
From: Giuseppe Bilotta @ 2009-01-13 0:59 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
On Mon, Jan 12, 2009 at 7:13 PM, Jakub Narebski <jnareb@gmail.com> wrote:
> On Mon, 12 Jan 2009, Giuseppe Bilotta wrote:
>> On Sun, Jan 11, 2009 at 8:15 PM, Jakub Narebski <jnareb@gmail.com> wrote:
>
>> > I see possible the following alternate solutions:
>> > * Ignore this issue (e.g. if it does not affect modern browsers)
>>
>> That would be my current choice until we find a better solution.
>
> By the way, how common this error is? Could you check if _your_ web
> browser (Firefox, Internet Explorer, Opera, Konqueror, Safari, Chrome)
> does show this bug or not, please?
Opera works fine (no display or functionality anomaly). That makes
sense, since I was the one who submitted the patch 8-D. Konqueror
3.5.9 does the ugly thing instead.
Notice that nested links are actually valid *XML*. Indeed, I asked on
www-style and they suggested leaving the problem as-is, serving as
html+xml which is what we do.
>> > * Revert 4afbaef (we lose feature, but how often used is it?)
>> > * Always use quirks mode, or check browser and use quirks mode if it
>> > would break layout
>> > * Use extra divs and links and CSS positioning to make layout which
>> > looks like current one, and behaves as current one, but is more
>> > complicated.
>>
>> I'm asking on #html, hopefully I'll get some interesting idea to try for this.
>
> I have found _a_ solution. Perhaps not the best one, but it works.
> And IMHO gives / can give even better visual.
>
> Current version (line wrapped for better visibility):
> <div class="header">
> <a class="title" href="...">GIT 1.6.1
> <span class="refs">
> <span class="tag indirect" title="tags/v1.6.1">
> <a href="...">v1.6.1</a>
> </span>
> </span>
> </a>
> </div>
>
> Current CSS (relevant part):
> a.title {
> display: block;
> padding: 6px 8px;
> }
>
> Current rendering:
> -----------------------------------------------------------
> |_GIT 1.6.1_ [] |
> -----------------------------------------------------------
> __v1.6.1__
>
>
> Proposed code (line wrapped for better visibility, with CSS embedded,
> which would change in final version of course). Only parts of style
> related to positioning are shown.
> <div class="header">
> <a href="..." style="float: left; margin: 6px 1px 6px 8px;">GIT 1.6.1</a>
> <div style="float: left; margin: 6px 1px;">
> <span class="refs">
> <span class="tag indirect" title="tags/v1.6.1">
> <a href="...">v1.6.1</a>
> </span>
> </span>
> </div>
> <a href="..." style="display: block; padding: 6px 8px;"> </a>
> </div>
>
> Rendering with proposed code:
> -----------------------------------------------------------
> _|_GIT 1.6.1_ [_v1.6.1_] |_
> -----------------------------------------------------------
>
> I guess that instead of additional DIV element, we could use DIV for
> .refs, or use "float: right" style with SPAN element. I have not
> checked if other variations works: this one does.
>
> What do you think?
The float thing was the second suggestion I was given on www-style.
Can you provide a patch I can apply to my tree for testing to see how
it comes up?
--
Giuseppe "Oblomov" Bilotta
^ permalink raw reply [relevance 0%]
* Re: [BUG/RFH] gitweb: Trouble with ref markers being hyperlinks because of illegally nested links
@ 2009-01-13 0:13 5% ` Jakub Narebski
2009-01-13 0:59 0% ` Giuseppe Bilotta
0 siblings, 1 reply; 128+ results
From: Jakub Narebski @ 2009-01-13 0:13 UTC (permalink / raw)
To: Giuseppe Bilotta; +Cc: git
On Mon, 12 Jan 2009, Giuseppe Bilotta wrote:
> On Sun, Jan 11, 2009 at 8:15 PM, Jakub Narebski <jnareb@gmail.com> wrote:
> > Commit 4afbaef by Giuseppe Bilotta (gitweb: ref markers link to named
> > shortlogs) turned ref markers for tags and heads into links to
> > appropriate views for the ref name.
> >
> > Unfortunately the code didn't take into account the fact that nesting
> > links (A elements) is illegal in (X)HTML:
> >
> > 12.2.2 Nested links are illegal
> >
> > Links and anchors defined by the A element must not be nested;
> > an A element must not contain any other A elements.
[...]
> > What is more complicated is the issue of ref marker from
> > git_print_header_div e.g. in 'commit'/'commitdiff' view, and in 'log'
> > view. There link is made into block element using "display: block;"
> > CSS rule (div.title, a.title), so that you can click _anywhere_ on the
> > header block. This breaks layout even worse, making hyperlinked ref
> > marker text appear *below* header div:
> >
> > -----------------------------------------------------------
> > |_Merge branch into maint_ [] |
> > -----------------------------------------------------------
> > _maint_
> >
> > To preserve current layout and behavior it would be needed to do some
> > deep HTML + CSS positioning hackery, perhaps with additional link block
> > without any text... But I don't know exactly how to do this; all [few]
> > experiments I did failed.
> >
> > I see possible the following alternate solutions:
> > * Ignore this issue (e.g. if it does not affect modern browsers)
>
> That would be my current choice until we find a better solution.
By the way, how common this error is? Could you check if _your_ web
browser (Firefox, Internet Explorer, Opera, Konqueror, Safari, Chrome)
does show this bug or not, please?
> > * Revert 4afbaef (we lose feature, but how often used is it?)
> > * Always use quirks mode, or check browser and use quirks mode if it
> > would break layout
> > * Use extra divs and links and CSS positioning to make layout which
> > looks like current one, and behaves as current one, but is more
> > complicated.
>
> I'm asking on #html, hopefully I'll get some interesting idea to try for this.
I have found _a_ solution. Perhaps not the best one, but it works.
And IMHO gives / can give even better visual.
Current version (line wrapped for better visibility):
<div class="header">
<a class="title" href="...">GIT 1.6.1
<span class="refs">
<span class="tag indirect" title="tags/v1.6.1">
<a href="...">v1.6.1</a>
</span>
</span>
</a>
</div>
Current CSS (relevant part):
a.title {
display: block;
padding: 6px 8px;
}
Current rendering:
-----------------------------------------------------------
|_GIT 1.6.1_ [] |
-----------------------------------------------------------
__v1.6.1__
Proposed code (line wrapped for better visibility, with CSS embedded,
which would change in final version of course). Only parts of style
related to positioning are shown.
<div class="header">
<a href="..." style="float: left; margin: 6px 1px 6px 8px;">GIT 1.6.1</a>
<div style="float: left; margin: 6px 1px;">
<span class="refs">
<span class="tag indirect" title="tags/v1.6.1">
<a href="...">v1.6.1</a>
</span>
</span>
</div>
<a href="..." style="display: block; padding: 6px 8px;"> </a>
</div>
Rendering with proposed code:
-----------------------------------------------------------
_|_GIT 1.6.1_ [_v1.6.1_] |_
-----------------------------------------------------------
I guess that instead of additional DIV element, we could use DIV for
.refs, or use "float: right" style with SPAN element. I have not
checked if other variations works: this one does.
What do you think?
--
Jakub Narebski
Poland
^ permalink raw reply [relevance 5%]
* Re: Minimum required version of subversion for git-svn?
2009-01-12 1:03 0% ` Eric Wong
@ 2009-01-12 8:03 0% ` Tom G. Christensen
2009-01-17 10:58 0% ` Eric Wong
0 siblings, 1 reply; 128+ results
From: Tom G. Christensen @ 2009-01-12 8:03 UTC (permalink / raw)
To: Eric Wong; +Cc: git@vger.kernel.org
Eric Wong wrote:
> "Tom G. Christensen" <tgc@statsbiblioteket.dk> wrote:
>> Hello,
>>
>> With git 1.6.0.5 I was able to run git-svn with subversion 1.1.4 on
>> RHEL4/i386 but with 1.6.0.6 and 1.6.1 the testsuite now fails in the new
>> test t9104.10:
>
> ...
>
>> With 1.6.1 I also see t9129.10-12 failing with subversion 1.1.4:
>> * FAIL 10: ISO-8859-1 should match UTF-8 in svn
>
> ...
>
>> * failed 3 among 12 test(s)
>> make[2]: Leaving directory `/builddir/build/BUILD/git-1.6.1/t'
>> make[2]: *** [t9129-git-svn-i18n-commitencoding.sh] Error 1
>>
>> I see in git-svn.perl that only SVN::Core 1.1.0 is required. Is it still
>> the intention that git-svn should work with subversion 1.1.x?
>>
>> If you're going to bump the minimum requirement I would ask that you
>> atleast keep 1.3.x as supported. This is the last release of subversion
>> where RHEL3 can satisfy the dependencies out of the box and I've
>> verified that the testsuite will pass with 1.3.2.
>
> It's still my intention that SVN 1.1.x is supported; but I haven't had
> the chance to test those versions in a while.
>
> Can you rerun the tests that failed with "sh -x t91..." ?
>
I've run the tests from 1.6.1 with -v, sh -x and sh -x + -v and dumped
the results at http://jupiterrise.com/tmp
You'll find results from one more test (t9106) which I didn't mention
and which is also giving me problems but only with rhel4/x86_64 and svn
1.1.4. It should be noted that this test has never worked for me with
this config.
-tgc
^ permalink raw reply [relevance 0%]
* Re: Minimum required version of subversion for git-svn?
2009-01-09 10:11 5% Minimum required version of subversion for git-svn? Tom G. Christensen
@ 2009-01-12 1:03 0% ` Eric Wong
2009-01-12 8:03 0% ` Tom G. Christensen
0 siblings, 1 reply; 128+ results
From: Eric Wong @ 2009-01-12 1:03 UTC (permalink / raw)
To: Tom G. Christensen; +Cc: git
"Tom G. Christensen" <tgc@statsbiblioteket.dk> wrote:
> Hello,
>
> With git 1.6.0.5 I was able to run git-svn with subversion 1.1.4 on
> RHEL4/i386 but with 1.6.0.6 and 1.6.1 the testsuite now fails in the new
> test t9104.10:
...
> With 1.6.1 I also see t9129.10-12 failing with subversion 1.1.4:
> * FAIL 10: ISO-8859-1 should match UTF-8 in svn
...
> * failed 3 among 12 test(s)
> make[2]: Leaving directory `/builddir/build/BUILD/git-1.6.1/t'
> make[2]: *** [t9129-git-svn-i18n-commitencoding.sh] Error 1
>
> I see in git-svn.perl that only SVN::Core 1.1.0 is required. Is it still
> the intention that git-svn should work with subversion 1.1.x?
>
> If you're going to bump the minimum requirement I would ask that you
> atleast keep 1.3.x as supported. This is the last release of subversion
> where RHEL3 can satisfy the dependencies out of the box and I've
> verified that the testsuite will pass with 1.3.2.
It's still my intention that SVN 1.1.x is supported; but I haven't had
the chance to test those versions in a while.
Can you rerun the tests that failed with "sh -x t91..." ?
Thanks.
--
Eric Wong
^ permalink raw reply [relevance 0%]
* Minimum required version of subversion for git-svn?
@ 2009-01-09 10:11 5% Tom G. Christensen
2009-01-12 1:03 0% ` Eric Wong
0 siblings, 1 reply; 128+ results
From: Tom G. Christensen @ 2009-01-09 10:11 UTC (permalink / raw)
To: git
Hello,
With git 1.6.0.5 I was able to run git-svn with subversion 1.1.4 on
RHEL4/i386 but with 1.6.0.6 and 1.6.1 the testsuite now fails in the new
test t9104.10:
* FAIL 10: follow-parent is atomic
(
cd wc &&
svn up &&
svn mkdir stunk &&
echo "trunk stunk" > stunk/readme &&
svn add stunk/readme &&
svn ci -m "trunk stunk" &&
echo "stunk like junk" >> stunk/readme &&
svn ci -m "really stunk" &&
echo "stink stank stunk" >> stunk/readme &&
svn ci -m "even the grinch agrees"
) &&
svn copy -m "stunk flunked" "$svnrepo"/stunk
"$svnrepo"/flunk &&
{ svn cp -m "early stunk flunked too" \
"$svnrepo"/stunk@17 "$svnrepo"/flunked ||
svn cp -m "early stunk flunked too" \
-r17 "$svnrepo"/stunk "$svnrepo"/flunked; } &&
git svn init --minimize-url -i stunk "$svnrepo"/stunk &&
git svn fetch -i stunk &&
git update-ref refs/remotes/flunk@18
refs/remotes/stunk~2 &&
git update-ref -d refs/remotes/stunk &&
git config --unset svn-remote.svn.fetch stunk &&
mkdir -p "$GIT_DIR"/svn/flunk@18 &&
rev_map=$(cd "$GIT_DIR"/svn/stunk && ls .rev_map*) &&
dd if="$GIT_DIR"/svn/stunk/$rev_map \
of="$GIT_DIR"/svn/flunk@18/$rev_map bs=24 count=1 &&
rm -rf "$GIT_DIR"/svn/stunk &&
git svn init --minimize-url -i flunk "$svnrepo"/flunk &&
git svn fetch -i flunk &&
git svn init --minimize-url -i stunk "$svnrepo"/stunk &&
git svn fetch -i stunk &&
git svn init --minimize-url -i flunked
"$svnrepo"/flunked &&
git svn fetch -i flunked
test "`git rev-parse --verify refs/remotes/flunk@18`" \
= "`git rev-parse --verify refs/remotes/stunk`" &&
test "`git rev-parse --verify refs/remotes/flunk~1`" \
= "`git rev-parse --verify refs/remotes/stunk`" &&
test "`git rev-parse --verify refs/remotes/flunked~1`" \
= "`git rev-parse --verify refs/remotes/stunk~1`"
With 1.6.1 I also see t9129.10-12 failing with subversion 1.1.4:
* FAIL 10: ISO-8859-1 should match UTF-8 in svn
(
cd ISO-8859-1 &&
compare_svn_head_with
"$TEST_DIRECTORY"/t3900/1-UTF-8.txt
)
* FAIL 11: $H should match UTF-8 in svn
(
cd $H &&
compare_svn_head_with
"$TEST_DIRECTORY"/t3900/2-UTF-8.txt
)
* FAIL 12: $H should match UTF-8 in svn
(
cd $H &&
compare_svn_head_with
"$TEST_DIRECTORY"/t3900/2-UTF-8.txt
)
* failed 3 among 12 test(s)
make[2]: Leaving directory `/builddir/build/BUILD/git-1.6.1/t'
make[2]: *** [t9129-git-svn-i18n-commitencoding.sh] Error 1
I see in git-svn.perl that only SVN::Core 1.1.0 is required. Is it still
the intention that git-svn should work with subversion 1.1.x?
If you're going to bump the minimum requirement I would ask that you
atleast keep 1.3.x as supported. This is the last release of subversion
where RHEL3 can satisfy the dependencies out of the box and I've
verified that the testsuite will pass with 1.3.2.
-tgc
^ permalink raw reply [relevance 5%]
* http push to WebDAV server fails (apache 2.2 under Win) - possible bug!?
@ 2009-01-05 6:26 7% Harald Weppner
0 siblings, 0 replies; 128+ results
From: Harald Weppner @ 2009-01-05 6:26 UTC (permalink / raw)
To: git
[-- Attachment #1: Type: text/plain, Size: 5232 bytes --]
Hi there,
just trying to get started to host a remote repository on a WebDAV
share (served by apache2.2 on Windows). When I attempt to push from my
local repository it indicates a 405 failure on a PUT of a
*opaquelocktoken:* resource (cf. apache access log below). I don't
know WebDAV in detail to know what's going wrong here but the colon in
the resource name looks suspicious as it's not a permitted character
under Windows. Could this indeed be a problem of not escaping the
resource name properly?
Thanks & cheerio, Harry.
> git push -v origin master
Pushing to http://user@example.com/webdav/repos/example.git/
Fetching remote heads...
refs/
refs/heads/
refs/tags/
updating 'refs/heads/master'
from 0000000000000000000000000000000000000000
to d310d475c459f7440a9a4ab8ae518f3a91011eb2
sending 12 objects
PUT 9d68391c5426d3b3c69a6b4c43c1110d13a710d5 failed, aborting (22/405)
PUT 57964966cd88e6a3a61c46ed4b186f26d5133dab failed, aborting (22/405)
PUT 7e03ccd9dcbb5a2770cc5e52aa168a97897ce01b failed, aborting (22/405)
PUT 67d59f8095ad0b5d90b50b05634038c831871f05 failed, aborting (22/405)
PUT 726f7925fa8539c202558d1cf7567c173fed6b42 failed, aborting (22/405)
error: failed to push some refs to 'http://user@example.com/webdav/repos/example.git/'
Here's how the apache error log looks like
[Sun Jan 04 21:51:27 2009] [error] [client xxx.xxx.xx.xxx] File does
not exist: C:/xampp/webdav/repos/example.git/info/refs
[Sun Jan 04 21:51:27 2009] [error] [client xxx.xxx.xx.xxx] File does
not exist: C:/xampp/webdav/repos/example.git/objects/info/packs
and this is apache's access log (showing the 405 errors)
[04/Jan/2009:21:51:26 -0800] "PROPFIND /webdav/repos/example.git/ HTTP/
1.1" 207 588 "-" "git/1.6.1"
[04/Jan/2009:21:51:27 -0800] "HEAD /webdav/repos/example.git/info/refs
HTTP/1.1" 404 - "-" "git/1.6.1"
[04/Jan/2009:21:51:27 -0800] "HEAD /webdav/repos/example.git/objects/
info/packs HTTP/1.1" 404 - "-" "git/1.6.1"
[04/Jan/2009:21:51:27 -0800] "PROPFIND /webdav/repos/example.git/refs/
HTTP/1.1" 207 2637 "-" "git/1.6.1"
[04/Jan/2009:21:51:27 -0800] "PROPFIND /webdav/repos/example.git/refs/
heads/ HTTP/1.1" 207 950 "-" "git/1.6.1"
[04/Jan/2009:21:51:27 -0800] "PROPFIND /webdav/repos/example.git/refs/
tags/ HTTP/1.1" 207 950 "-" "git/1.6.1"
[04/Jan/2009:21:51:27 -0800] "MKCOL /webdav/repos/example.git/refs
HTTP/1.1" 301 433 "-" "git/1.6.1"
[04/Jan/2009:21:51:28 -0800] "MKCOL /webdav/repos/example.git/refs/
HTTP/1.1" 405 1060 "-" "git/1.6.1"
[04/Jan/2009:21:51:28 -0800] "MKCOL /webdav/repos/example.git/refs/
heads HTTP/1.1" 301 439 "-" "git/1.6.1"
[04/Jan/2009:21:51:28 -0800] "MKCOL /webdav/repos/example.git/refs/
heads/ HTTP/1.1" 405 1060 "-" "git/1.6.1"
[04/Jan/2009:21:51:28 -0800] "LOCK /webdav/repos/example.git/refs/
heads/master HTTP/1.1" 200 471 "-" "git/1.6.1"
[04/Jan/2009:21:51:28 -0800] "PROPFIND /webdav/repos/example.git/
objects/d3/ HTTP/1.1" 404 1138 "-" "git/1.6.1"
[04/Jan/2009:21:51:28 -0800] "PROPFIND /webdav/repos/example.git/
objects/24/ HTTP/1.1" 404 1138 "-" "git/1.6.1"
[04/Jan/2009:21:51:28 -0800] "PROPFIND /webdav/repos/example.git/
objects/62/ HTTP/1.1" 404 1138 "-" "git/1.6.1"
[04/Jan/2009:21:51:28 -0800] "PROPFIND /webdav/repos/example.git/
objects/ca/ HTTP/1.1" 207 950 "-" "git/1.6.1"
[04/Jan/2009:21:51:28 -0800] "PROPFIND /webdav/repos/example.git/
objects/9c/ HTTP/1.1" 404 1138 "-" "git/1.6.1"
[04/Jan/2009:21:51:29 -0800] "PROPFIND /webdav/repos/example.git/
objects/7e/ HTTP/1.1" 207 950 "-" "git/1.6.1"
[04/Jan/2009:21:51:29 -0800] "PROPFIND /webdav/repos/example.git/
objects/6f/ HTTP/1.1" 404 1138 "-" "git/1.6.1"
[04/Jan/2009:21:51:29 -0800] "PROPFIND /webdav/repos/example.git/
objects/72/ HTTP/1.1" 207 950 "-" "git/1.6.1"
[04/Jan/2009:21:51:29 -0800] "PROPFIND /webdav/repos/example.git/
objects/67/ HTTP/1.1" 207 950 "-" "git/1.6.1"
[04/Jan/2009:21:51:29 -0800] "PROPFIND /webdav/repos/example.git/
objects/57/ HTTP/1.1" 207 951 "-" "git/1.6.1"
[04/Jan/2009:21:51:29 -0800] "PROPFIND /webdav/repos/example.git/
objects/9d/ HTTP/1.1" 207 950 "-" "git/1.6.1"
[04/Jan/2009:21:51:29 -0800] "PUT /webdav/repos/example.git/objects/9d/
68391c5426d3b3c69a6b4c43c1110d13a710d5_opaquelocktoken:
35019a69-7377-2545-a7fa-0f7888f6e3bc HTTP/1.1" 405 1058 "-" "git/1.6.1"
[04/Jan/2009:21:51:29 -0800] "PUT /webdav/repos/example.git/objects/
57/964966cd88e6a3a61c46ed4b186f26d5133dab_opaquelocktoken:
35019a69-7377-2545-a7fa-0f7888f6e3bc HTTP/1.1" 405 1058 "-" "git/1.6.1"
[04/Jan/2009:21:51:29 -0800] "PUT /webdav/repos/example.git/objects/7e/
03ccd9dcbb5a2770cc5e52aa168a97897ce01b_opaquelocktoken:
35019a69-7377-2545-a7fa-0f7888f6e3bc HTTP/1.1" 405 1058 "-" "git/1.6.1"
[04/Jan/2009:21:51:29 -0800] "PUT /webdav/repos/example.git/objects/67/
d59f8095ad0b5d90b50b05634038c831871f05_opaquelocktoken:
35019a69-7377-2545-a7fa-0f7888f6e3bc HTTP/1.1" 405 1058 "-" "git/1.6.1"
[04/Jan/2009:21:51:29 -0800] "PUT /webdav/repos/example.git/objects/
72/6f7925fa8539c202558d1cf7567c173fed6b42_opaquelocktoken:
35019a69-7377-2545-a7fa-0f7888f6e3bc HTTP/1.1" 405 1058 "-" "git/1.6.1"
[04/Jan/2009:21:51:30 -0800] "UNLOCK /webdav/repos/example.git/refs/
heads/master HTTP/1.1" 204 - "-" "git/1.6.1"
[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 2425 bytes --]
^ permalink raw reply [relevance 7%]
* Re: git push question.. error: Unable to lock remote branch refs/heads/master
2008-12-31 8:17 4% git push question.. error: Unable to lock remote branch refs/heads/master aaron smith
@ 2008-12-31 8:22 0% ` aaron smith
0 siblings, 0 replies; 128+ results
From: aaron smith @ 2008-12-31 8:22 UTC (permalink / raw)
To: git
Oh Shit, I just figured it out. I had a friggin .htaccess file in
root, that was screwing things up. Sorry for any annoyance!
On Wed, Dec 31, 2008 at 12:17 AM, aaron smith
<beingthexemplarylists@gmail.com> wrote:
> Hey All,
>
> First, i've looked all over for a solution to this, and can't seem to
> get it figured out. Here's my setup:
>
> centeos
> apache 2
> webdav
> git 1.6.1
>
> I went through most of the git config over http text file instructions
> (http://www.kernel.org/pub/software/scm/git/docs/howto/setup-git-server-over-http.txt),
> just for the quick and dirty. Here's what I have in my http conf:
>
> <VirtualHost *:80>
> ServerName www.codeendeavor.com
> DocumentRoot /var/www/vhosts/codeendeavor/
> DavLockDB /var/logs/httpd/webdav/davlock
> <Location "/guttershark.git/">
> DAV on
> </Location>
> </VirtualHost>
>
> So, I have a bare git repo here:
> /var/www/vhosts/codeendeavor/guttershark.git/ (I used: mkdir
> guttershark.git; cd guttershark.git; git --bare init). And I've turned
> on webdav for that location.
>
> I created the DavLockDB directory: mkdir /var/logs/httpd/webdav/davlock
>
> And I've updated permissions on the git repo, and the webdav lock to
> apache:apache. And when it still didn't work, I updated the
> permissions on the git repo to 777, and on the davlock.
>
> I'm not sure what would be going on. I searched through the servers'
> empty git, and my local git repo for a lock file. But don't see
> anything.
>
> I don't have authentication on it yet so if you want to try and push
> to it, feel free.
>
> After all that. here is how I interact with it:
>
> $git push origin master
> Unable to lock remote branch refs/heads/master
> error: failed to push some refs to 'http://codeendeavor.com/guttershark.git/'
>
> Anyone have any idea?
>
> Thanks a bunch!
>
^ permalink raw reply [relevance 0%]
* git push question.. error: Unable to lock remote branch refs/heads/master
@ 2008-12-31 8:17 4% aaron smith
2008-12-31 8:22 0% ` aaron smith
0 siblings, 1 reply; 128+ results
From: aaron smith @ 2008-12-31 8:17 UTC (permalink / raw)
To: git
Hey All,
First, i've looked all over for a solution to this, and can't seem to
get it figured out. Here's my setup:
centeos
apache 2
webdav
git 1.6.1
I went through most of the git config over http text file instructions
(http://www.kernel.org/pub/software/scm/git/docs/howto/setup-git-server-over-http.txt),
just for the quick and dirty. Here's what I have in my http conf:
<VirtualHost *:80>
ServerName www.codeendeavor.com
DocumentRoot /var/www/vhosts/codeendeavor/
DavLockDB /var/logs/httpd/webdav/davlock
<Location "/guttershark.git/">
DAV on
</Location>
</VirtualHost>
So, I have a bare git repo here:
/var/www/vhosts/codeendeavor/guttershark.git/ (I used: mkdir
guttershark.git; cd guttershark.git; git --bare init). And I've turned
on webdav for that location.
I created the DavLockDB directory: mkdir /var/logs/httpd/webdav/davlock
And I've updated permissions on the git repo, and the webdav lock to
apache:apache. And when it still didn't work, I updated the
permissions on the git repo to 777, and on the davlock.
I'm not sure what would be going on. I searched through the servers'
empty git, and my local git repo for a lock file. But don't see
anything.
I don't have authentication on it yet so if you want to try and push
to it, feel free.
After all that. here is how I interact with it:
$git push origin master
Unable to lock remote branch refs/heads/master
error: failed to push some refs to 'http://codeendeavor.com/guttershark.git/'
Anyone have any idea?
Thanks a bunch!
^ permalink raw reply [relevance 4%]
* [ANNOUNCE] MSYSGIT 1.6.1
2008-12-25 6:36 7% [ANNOUNCE] GIT 1.6.1 Junio C Hamano
` (2 preceding siblings ...)
2008-12-25 11:44 5% ` Heikki Orsila
@ 2008-12-27 10:31 0% ` Steffen Prohaska
3 siblings, 0 replies; 128+ results
From: Steffen Prohaska @ 2008-12-27 10:31 UTC (permalink / raw)
To: Git Mailing List, msysGit; +Cc: Junio C Hamano
On Dec 25, 2008, at 7:36 AM, Junio C Hamano wrote:
> The latest feature release GIT 1.6.1 is available at the usual
> places:
The msysgit installer is available at
http://code.google.com/p/msysgit/downloads
Steffen
^ permalink raw reply [relevance 0%]
* Re: [ANNOUNCE] GIT 1.6.1
2008-12-25 11:44 5% ` Heikki Orsila
2008-12-26 1:38 5% ` Sitaram Chamarty
@ 2008-12-27 1:56 5% ` Nicolas Pitre
1 sibling, 0 replies; 128+ results
From: Nicolas Pitre @ 2008-12-27 1:56 UTC (permalink / raw)
To: Heikki Orsila; +Cc: Junio C Hamano, git, lkml
On Thu, 25 Dec 2008, Heikki Orsila wrote:
> On Wed, Dec 24, 2008 at 10:36:27PM -0800, Junio C Hamano wrote:
> > * The packfile machinery hopefully is more robust when dealing with
> > corrupt packs if redundant objects involved in the corruption are
> > available elsewhere.
>
> Has anyone written a summary of how Git's redundancy operates?
>
> * What would be the probability for a single bit flip to corrupt the
> repository?
This is not something that git itself could answer. The probability
depends on the quality of your hardware. Once that probability has
occurred though, it is clear that your repository is then corrupted as
there is hardly any redundant bits in a git repository.
> * And what is the situation where a single bit flip can not corrupt the
> database?
The database can be resilient against most kind of corruptions if you
have a redundant copy of the affected object. It will still be
corrupted, but git is now able to detect corruptions gracefully and
function correctly with some fallback objects. Those objects must exist
in some other related repository though, and copied over to the affected
repository manually. It's then possible and recommended to "fix" the
corruption simply by repacking the repository at that point.
So there is no magic involved: you need to have some kind of backups,
either using traditional backup solutions, or by simply having your
repository cloned somewhere else. The idea of having a repository fixed
with redundant objects is for those cases where you need to salvage new
work that has no corresponding backup, but although corresponding
objects are not corrupted, they could be delta objects which base is
against old objects which happen to be corrupted.
> * When (which commands/functions) is error detection done?
Error detection is performed all the time. When it's not the more
expensive SHA1 checksum, at least the zlib CRC32 is verified. What the
latest git version does amongst other corruption related things is to
close some small holes where some specific kind of corruptions could
have been undetected and propagated from one pack to another when
repacking.
Nicolas
^ permalink raw reply [relevance 5%]
* Re: [ANNOUNCE] GIT 1.6.1
2008-12-25 18:50 5% ` Junio C Hamano
@ 2008-12-26 14:42 5% ` bill lam
0 siblings, 0 replies; 128+ results
From: bill lam @ 2008-12-26 14:42 UTC (permalink / raw)
To: git
On Thu, 25 Dec 2008, Junio C Hamano wrote:
> build process); it is plausible that it has broken checks for detecting
> the need of NO_UINTMAX_T.
>
> Relevant part of configure.ac reads like this:
>
> # Define NO_UINTMAX_T if your platform does not have uintmax_t
> AC_CHECK_TYPE(uintmax_t,
> [NO_UINTMAX_T=],
> [NO_UINTMAX_T=YesPlease],[
> #include <inttypes.h>
> ])
> AC_SUBST(NO_UINTMAX_T)
>
> and I do not see anything suspicious there...
Thanks, I guess the configure is not part of the repository and I use
a legacy configure from earlier version. After I run the make
configure again, it is now ok.
--
regards,
====================================================
GPG key 1024D/4434BAB3 2008-08-24
gpg --keyserver subkeys.pgp.net --recv-keys 4434BAB3
唐詩093 駱賓王 在獄詠蟬
西路蟬聲唱 南冠客思侵 那堪玄鬢影 來對白頭吟
露重飛難進 風多響易沉 無人信高潔 誰為表予心
^ permalink raw reply [relevance 5%]
* Re: [ANNOUNCE] GIT 1.6.1
2008-12-25 18:53 5% ` Pau Garcia i Quiles
@ 2008-12-26 14:33 5% ` bill lam
0 siblings, 0 replies; 128+ results
From: bill lam @ 2008-12-26 14:33 UTC (permalink / raw)
To: git
On Thu, 25 Dec 2008, Pau Garcia i Quiles wrote:
> Works for me both in Hardy and Intrepid. If you have trouble building
> from source, there are binary package for Hardy and Intrepid in my
> PPA:
> http://launchpad.net/~pgquiles/+archive
Thanks you head up. No problem now, but I'll bookmark your page.
--
regards,
====================================================
GPG key 1024D/4434BAB3 2008-08-24
gpg --keyserver subkeys.pgp.net --recv-keys 4434BAB3
唐詩281 劉禹錫 春詞
新妝宜面下朱樓 深鎖春光一院愁 行到中庭數花朵 蜻蜓飛上玉搔頭
^ permalink raw reply [relevance 5%]
* Re: [ANNOUNCE] GIT 1.6.1
2008-12-25 11:44 5% ` Heikki Orsila
@ 2008-12-26 1:38 5% ` Sitaram Chamarty
2008-12-27 1:56 5% ` Nicolas Pitre
1 sibling, 0 replies; 128+ results
From: Sitaram Chamarty @ 2008-12-26 1:38 UTC (permalink / raw)
To: git; +Cc: linux-kernel
["Followup-To:" header set to gmane.comp.version-control.git.]
On 2008-12-25, Heikki Orsila <shdl@zakalwe.fi> wrote:
> * What would be the probability for a single bit flip to corrupt the
> repository?
> * And what is the situation where a single bit flip can not corrupt the
> database?
These two questions are not specific to git; whatever
answers apply to sha1 also apply here. Sha1 will always be
strong enough to detect any combination of random errors.
As for deliberate attacks, it is considered strong enough to
resist all but the most computationally intensive attacks
(the kind that require a worldwide effort or maybe NSA type
facilities).
> * When (which commands/functions) is error detection done?
"git fsck --full" will do it of course, but I'm not sure
what other operations also start off or end up doing a
check.
^ permalink raw reply [relevance 5%]
* Re: [ANNOUNCE] GIT 1.6.1
2008-12-25 10:00 5% ` bill lam
2008-12-25 10:13 5% ` Junio C Hamano
@ 2008-12-25 18:53 5% ` Pau Garcia i Quiles
2008-12-26 14:33 5% ` bill lam
1 sibling, 1 reply; 128+ results
From: Pau Garcia i Quiles @ 2008-12-25 18:53 UTC (permalink / raw)
To: git
On Thu, Dec 25, 2008 at 11:00 AM, bill lam <cbill.lam@gmail.com> wrote:
> On ubuntu64 8.10, the NO_UINTMAX_T seems cause some trouble, I have to
> comment out the block (in the Makefile),
>
> fdef NO_UINTMAX_T
> BASIC_CFLAGS += -Duintmax_t=uint32_t
> ndif
>
> to make a successful compilation. Does it happen to me only?
Works for me both in Hardy and Intrepid. If you have trouble building
from source, there are binary package for Hardy and Intrepid in my
PPA:
http://launchpad.net/~pgquiles/+archive
--
Pau Garcia i Quiles
http://www.elpauer.org
(Due to my workload, I may need 10 days to answer)
^ permalink raw reply [relevance 5%]
* Re: [ANNOUNCE] GIT 1.6.1
2008-12-25 10:25 5% ` bill lam
2008-12-25 11:42 5% ` René Scharfe
@ 2008-12-25 18:50 5% ` Junio C Hamano
2008-12-26 14:42 5% ` bill lam
1 sibling, 1 reply; 128+ results
From: Junio C Hamano @ 2008-12-25 18:50 UTC (permalink / raw)
To: bill lam; +Cc: git
bill lam <cbill.lam@gmail.com> writes:
>> Why are you building with NO_UINTMAX_T to begin with? Isn't ubuntu 8.10 a
>> recent enough platform that ships with modern enough header files that
>> define ANSI uintmax_t type?
>
> No, I did not do anything on that,
>
> make clean
> ./configure --prefix=/usr
> make
I do not use configure myself (use of configure is entirely optional, and
it is not tested often and core developers do not touch that part very
much --- in a sense, use of autoconf is a second-class citizen in our
build process); it is plausible that it has broken checks for detecting
the need of NO_UINTMAX_T.
Relevant part of configure.ac reads like this:
# Define NO_UINTMAX_T if your platform does not have uintmax_t
AC_CHECK_TYPE(uintmax_t,
[NO_UINTMAX_T=],
[NO_UINTMAX_T=YesPlease],[
#include <inttypes.h>
])
AC_SUBST(NO_UINTMAX_T)
and I do not see anything suspicious there...
Running "./configure --verbose" might leave some clues in config.log; for
me on my primary development box (Debian on x86_64), the relevant part
passes the test (iow, inclusion of inttypes.h does give a working
uintmax_t type) like this:
configure:5709: checking for uintmax_t
configure:5742: cc -c -g -O2 conftest.c >&5
configure:5748: $? = 0
configure:5763: result: yes
^ permalink raw reply [relevance 5%]
* Re: [ANNOUNCE] GIT 1.6.1
2008-12-25 11:42 5% ` René Scharfe
@ 2008-12-25 14:09 5% ` bill lam
0 siblings, 0 replies; 128+ results
From: bill lam @ 2008-12-25 14:09 UTC (permalink / raw)
To: git
On Thu, 25 Dec 2008, René Scharfe wrote:
> configure seems to be confused. What happens if you take it out of the
> equation, i.e. run the following commands?
>
> $ make distclean
> $ make prefix=/usr
Thanks René! I followed your installation, deleted the old configure,
and it compiled successfully,
Happy holidays to everyone on mailing list!
--
regards,
====================================================
GPG key 1024D/4434BAB3 2008-08-24
gpg --keyserver subkeys.pgp.net --recv-keys 4434BAB3
唐詩104 李白 夜泊牛渚懷古
牛渚西江夜 青天無片雲 登舟望秋月 空憶謝將軍
余亦能高詠 斯人不可聞 明朝挂帆席 楓葉落紛紛
^ permalink raw reply [relevance 5%]
* Re: [ANNOUNCE] GIT 1.6.1
2008-12-25 6:36 7% [ANNOUNCE] GIT 1.6.1 Junio C Hamano
2008-12-25 8:32 5% ` Christian MICHON
2008-12-25 10:00 5% ` bill lam
@ 2008-12-25 11:44 5% ` Heikki Orsila
2008-12-26 1:38 5% ` Sitaram Chamarty
2008-12-27 1:56 5% ` Nicolas Pitre
2008-12-27 10:31 0% ` [ANNOUNCE] MSYSGIT 1.6.1 Steffen Prohaska
3 siblings, 2 replies; 128+ results
From: Heikki Orsila @ 2008-12-25 11:44 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, linux-kernel
On Wed, Dec 24, 2008 at 10:36:27PM -0800, Junio C Hamano wrote:
> * The packfile machinery hopefully is more robust when dealing with
> corrupt packs if redundant objects involved in the corruption are
> available elsewhere.
Has anyone written a summary of how Git's redundancy operates?
* What would be the probability for a single bit flip to corrupt the
repository?
* And what is the situation where a single bit flip can not corrupt the
database?
* When (which commands/functions) is error detection done?
Heikki
^ permalink raw reply [relevance 5%]
* Re: [ANNOUNCE] GIT 1.6.1
2008-12-25 10:25 5% ` bill lam
@ 2008-12-25 11:42 5% ` René Scharfe
2008-12-25 14:09 5% ` bill lam
2008-12-25 18:50 5% ` Junio C Hamano
1 sibling, 1 reply; 128+ results
From: René Scharfe @ 2008-12-25 11:42 UTC (permalink / raw)
To: bill lam; +Cc: git, Junio C Hamano
bill lam schrieb:
>> Why are you building with NO_UINTMAX_T to begin with? Isn't ubuntu 8.10 a
>> recent enough platform that ships with modern enough header files that
>> define ANSI uintmax_t type?
>
> No, I did not do anything on that,
>
> make clean
> ./configure --prefix=/usr
> make
>
> and this is the error logged.
>
> GIT_VERSION = 1.6.1
> * new build flags or prefix
> In file included from /usr/include/netinet/in.h:24,
> from git-compat-util.h:78,
> from builtin.h:4,
> from fast-import.c:142:
> /usr/include/stdint.h:136: error: conflicting types for ‘uint32_t’
> /usr/include/stdint.h:52: error: previous declaration of ‘uint32_t’ was here
> fast-import.c: In function ‘parse_progress’:
> fast-import.c:2339: warning: ignoring return value of ‘fwrite’, declared with attribute warn_unused_result
> make: *** [fast-import.o] Error 1
>
> version of gcc:
> gcc (Ubuntu 4.3.2-1ubuntu11) 4.3.2
I don't get any error on Ubuntu 8.10 on x86_64 (but several of those
warnings about ignored return values), neither with the tar file nor a
cloned repository (in the former case I had to add a "make configure"
step, though).
Line 52 of /usr/include/stdint.h:
typedef unsigned int uint32_t;
Lines 134-136 of /usr/include/stdint.h:
#if __WORDSIZE == 64
typedef long int intmax_t;
typedef unsigned long int uintmax_t;
If you get to line 136, you probably are on a 64 bit installation, too,
correct?
configure seems to be confused. What happens if you take it out of the
equation, i.e. run the following commands?
$ make distclean
$ make prefix=/usr
René
^ permalink raw reply [relevance 5%]
* Re: [ANNOUNCE] GIT 1.6.1
2008-12-25 10:13 5% ` Junio C Hamano
@ 2008-12-25 10:25 5% ` bill lam
2008-12-25 11:42 5% ` René Scharfe
2008-12-25 18:50 5% ` Junio C Hamano
0 siblings, 2 replies; 128+ results
From: bill lam @ 2008-12-25 10:25 UTC (permalink / raw)
To: git
> Why are you building with NO_UINTMAX_T to begin with? Isn't ubuntu 8.10 a
> recent enough platform that ships with modern enough header files that
> define ANSI uintmax_t type?
No, I did not do anything on that,
make clean
./configure --prefix=/usr
make
and this is the error logged.
GIT_VERSION = 1.6.1
* new build flags or prefix
In file included from /usr/include/netinet/in.h:24,
from git-compat-util.h:78,
from builtin.h:4,
from fast-import.c:142:
/usr/include/stdint.h:136: error: conflicting types for ‘uint32_t’
/usr/include/stdint.h:52: error: previous declaration of ‘uint32_t’ was here
fast-import.c: In function ‘parse_progress’:
fast-import.c:2339: warning: ignoring return value of ‘fwrite’, declared with attribute warn_unused_result
make: *** [fast-import.o] Error 1
version of gcc:
gcc (Ubuntu 4.3.2-1ubuntu11) 4.3.2
--
regards,
====================================================
GPG key 1024D/4434BAB3 2008-08-24
gpg --keyserver subkeys.pgp.net --recv-keys 4434BAB3
唐詩105 杜甫 月夜
今夜鄜州月 閨中只獨看 遙憐小兒女 未解憶長安
香霧雲鬟濕 清輝玉臂寒 何時倚虛幌 雙照淚痕乾
^ permalink raw reply [relevance 5%]
* Re: [ANNOUNCE] GIT 1.6.1
2008-12-25 10:00 5% ` bill lam
@ 2008-12-25 10:13 5% ` Junio C Hamano
2008-12-25 10:25 5% ` bill lam
2008-12-25 18:53 5% ` Pau Garcia i Quiles
1 sibling, 1 reply; 128+ results
From: Junio C Hamano @ 2008-12-25 10:13 UTC (permalink / raw)
To: bill lam; +Cc: git
bill lam <cbill.lam@gmail.com> writes:
> On ubuntu64 8.10, the NO_UINTMAX_T seems cause some trouble, I have to
> comment out the block (in the Makefile),
>
> fdef NO_UINTMAX_T
> BASIC_CFLAGS += -Duintmax_t=uint32_t
> ndif
>
> to make a successful compilation. Does it happen to me only?
Nobody reported it since that was added about a month and half ago.
Why are you building with NO_UINTMAX_T to begin with? Isn't ubuntu 8.10 a
recent enough platform that ships with modern enough header files that
define ANSI uintmax_t type?
^ permalink raw reply [relevance 5%]
* Re: [ANNOUNCE] GIT 1.6.1
2008-12-25 6:36 7% [ANNOUNCE] GIT 1.6.1 Junio C Hamano
2008-12-25 8:32 5% ` Christian MICHON
@ 2008-12-25 10:00 5% ` bill lam
2008-12-25 10:13 5% ` Junio C Hamano
2008-12-25 18:53 5% ` Pau Garcia i Quiles
2008-12-25 11:44 5% ` Heikki Orsila
2008-12-27 10:31 0% ` [ANNOUNCE] MSYSGIT 1.6.1 Steffen Prohaska
3 siblings, 2 replies; 128+ results
From: bill lam @ 2008-12-25 10:00 UTC (permalink / raw)
To: git
On ubuntu64 8.10, the NO_UINTMAX_T seems cause some trouble, I have to
comment out the block (in the Makefile),
fdef NO_UINTMAX_T
BASIC_CFLAGS += -Duintmax_t=uint32_t
ndif
to make a successful compilation. Does it happen to me only?
--
regards,
====================================================
GPG key 1024D/4434BAB3 2008-08-24
gpg --keyserver subkeys.pgp.net --recv-keys 4434BAB3
唐詩282 白居易 後宮詞
淚濕羅巾夢不成 夜深前殿按歌聲 紅顏未老恩先斷 斜倚薰籠坐到明
^ permalink raw reply [relevance 5%]
* Re: [ANNOUNCE] GIT 1.6.1
2008-12-25 6:36 7% [ANNOUNCE] GIT 1.6.1 Junio C Hamano
@ 2008-12-25 8:32 5% ` Christian MICHON
2008-12-25 10:00 5% ` bill lam
` (2 subsequent siblings)
3 siblings, 0 replies; 128+ results
From: Christian MICHON @ 2008-12-25 8:32 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
On Thu, Dec 25, 2008 at 7:36 AM, Junio C Hamano <gitster@pobox.com> wrote:
> The latest feature release GIT 1.6.1 is available at the usual
> places:
>
a nice christmas gift indeed! thanks for making this release possible.
my best wishes to the list for xmas and incoming 2009!
--
Christian
--
http://detaolb.sourceforge.net/, a linux distribution for Qemu with Git inside !
^ permalink raw reply [relevance 5%]
* [ANNOUNCE] GIT 1.6.1
@ 2008-12-25 6:36 7% Junio C Hamano
2008-12-25 8:32 5% ` Christian MICHON
` (3 more replies)
0 siblings, 4 replies; 128+ results
From: Junio C Hamano @ 2008-12-25 6:36 UTC (permalink / raw)
To: git; +Cc: linux-kernel
The latest feature release GIT 1.6.1 is available at the usual
places:
http://www.kernel.org/pub/software/scm/git/
git-1.6.1.tar.{gz,bz2} (source tarball)
git-htmldocs-1.6.1.tar.{gz,bz2} (preformatted docs)
git-manpages-1.6.1.tar.{gz,bz2} (preformatted docs)
The RPM binary packages for a few architectures are also found in the
vicinity.
RPMS/$arch/git-*-1.6.1-1.fc9.$arch.rpm (RPM)
----------------------------------------------------------------
GIT v1.6.1 Release Notes
========================
Updates since v1.6.0
--------------------
When some commands (e.g. "git log", "git diff") spawn pager internally, we
used to make the pager the parent process of the git command that produces
output. This meant that the exit status of the whole thing comes from the
pager, not the underlying git command. We swapped the order of the
processes around and you will see the exit code from the command from now
on.
(subsystems)
* gitk can call out to git-gui to view "git blame" output; git-gui in turn
can run gitk from its blame view.
* Various git-gui updates including updated translations.
* Various gitweb updates from repo.or.cz installation.
* Updates to emacs bindings.
(portability)
* A few test scripts used nonportable "grep" that did not work well on
some platforms, e.g. Solaris.
* Sample pre-auto-gc script has OS X support.
* Makefile has support for (ancient) FreeBSD 4.9.
(performance)
* Many operations that are lstat(3) heavy can be told to pre-execute
necessary lstat(3) in parallel before their main operations, which
potentially gives much improved performance for cold-cache cases or in
environments with weak metadata caching (e.g. NFS).
* The underlying diff machinery to produce textual output has been
optimized, which would result in faster "git blame" processing.
* Most of the test scripts (but not the ones that try to run servers)
can be run in parallel.
* Bash completion of refnames in a repository with massive number of
refs has been optimized.
* Cygwin port uses native stat/lstat implementations when applicable,
which leads to improved performance.
* "git push" pays attention to alternate repositories to avoid sending
unnecessary objects.
* "git svn" can rebuild an out-of-date rev_map file.
(usability, bells and whistles)
* When you mistype a command name, git helpfully suggests what it guesses
you might have meant to say. help.autocorrect configuration can be set
to a non-zero value to accept the suggestion when git can uniquely
guess.
* The packfile machinery hopefully is more robust when dealing with
corrupt packs if redundant objects involved in the corruption are
available elsewhere.
* "git add -N path..." adds the named paths as an empty blob, so that
subsequent "git diff" will show a diff as if they are creation events.
* "git add" gained a built-in synonym for people who want to say "stage
changes" instead of "add contents to the staging area" which amounts
to the same thing.
* "git apply" learned --include=paths option, similar to the existing
--exclude=paths option.
* "git bisect" is careful about a user mistake and suggests testing of
merge base first when good is not a strict ancestor of bad.
* "git bisect skip" can take a range of commits.
* "git blame" re-encodes the commit metainfo to UTF-8 from i18n.commitEncoding
by default.
* "git check-attr --stdin" can check attributes for multiple paths.
* "git checkout --track origin/hack" used to be a syntax error. It now
DWIMs to create a corresponding local branch "hack", i.e. acts as if you
said "git checkout --track -b hack origin/hack".
* "git checkout --ours/--theirs" can be used to check out one side of a
conflicting merge during conflict resolution.
* "git checkout -m" can be used to recreate the initial conflicted state
during conflict resolution.
* "git cherry-pick" can also utilize rerere for conflict resolution.
* "git clone" learned to be verbose with -v
* "git commit --author=$name" can look up author name from existing
commits.
* output from "git commit" has been reworded in a more concise and yet
more informative way.
* "git count-objects" reports the on-disk footprint for packfiles and
their corresponding idx files.
* "git daemon" learned --max-connections=<count> option.
* "git daemon" exports REMOTE_ADDR to record client address, so that
spawned programs can act differently on it.
* "git describe --tags" favours closer lightweight tags than farther
annotated tags now.
* "git diff" learned to mimic --suppress-blank-empty from GNU diff via a
configuration option.
* "git diff" learned to put more sensible hunk headers for Python,
HTML and ObjC contents.
* "git diff" learned to vary the a/ vs b/ prefix depending on what are
being compared, controlled by diff.mnemonicprefix configuration.
* "git diff" learned --dirstat-by-file to count changed files, not number
of lines, when summarizing the global picture.
* "git diff" learned "textconv" filters --- a binary or hard-to-read
contents can be munged into human readable form and the difference
between the results of the conversion can be viewed (obviously this
cannot produce a patch that can be applied, so this is disabled in
format-patch among other things).
* "--cached" option to "git diff has an easier to remember synonym "--staged",
to ask "what is the difference between the given commit and the
contents staged in the index?"
* "git for-each-ref" learned "refname:short" token that gives an
unambiguously abbreviated refname.
* Auto-numbering of the subject lines is the default for "git
format-patch" now.
* "git grep" learned to accept -z similar to GNU grep.
* "git help" learned to use GIT_MAN_VIEWER environment variable before
using "man" program.
* "git imap-send" can optionally talk SSL.
* "git index-pack" is more careful against disk corruption while
completing a thin pack.
* "git log --check" and "git log --exit-code" passes their underlying diff
status with their exit status code.
* "git log" learned --simplify-merges, a milder variant of --full-history;
"gitk --simplify-merges" is easier to view than with --full-history.
* "git log" learned "--source" to show what ref each commit was reached
from.
* "git log" also learned "--simplify-by-decoration" to show the
birds-eye-view of the topology of the history.
* "git log --pretty=format:" learned "%d" format element that inserts
names of tags that point at the commit.
* "git merge --squash" and "git merge --no-ff" into an unborn branch are
noticed as user errors.
* "git merge -s $strategy" can use a custom built strategy if you have a
command "git-merge-$strategy" on your $PATH.
* "git pull" (and "git fetch") can be told to operate "-v"erbosely or
"-q"uietly.
* "git push" can be told to reject deletion of refs with receive.denyDeletes
configuration.
* "git rebase" honours pre-rebase hook; use --no-verify to bypass it.
* "git rebase -p" uses interactive rebase machinery now to preserve the merges.
* "git reflog expire branch" can be used in place of "git reflog expire
refs/heads/branch".
* "git remote show $remote" lists remote branches one-per-line now.
* "git send-email" can be given revision range instead of files and
maildirs on the command line, and automatically runs format-patch to
generate patches for the given revision range.
* "git submodule foreach" subcommand allows you to iterate over checked
out submodules.
* "git submodule sync" subcommands allows you to update the origin URL
recorded in submodule directories from the toplevel .gitmodules file.
* "git svn branch" can create new branches on the other end.
* "gitweb" can use more saner PATH_INFO based URL.
(internal)
* "git hash-object" learned to lie about the path being hashed, so that
correct gitattributes processing can be done while hashing contents
stored in a temporary file.
* various callers of git-merge-recursive avoid forking it as an external
process.
* Git class defined in "Git.pm" can be subclasses a bit more easily.
* We used to link GNU regex library as a compatibility layer for some
platforms, but it turns out it is not necessary on most of them.
* Some path handling routines used fixed number of buffers used alternately
but depending on the call depth, this arrangement led to hard to track
bugs. This issue is being addressed.
Fixes since v1.6.0
------------------
All of the fixes in v1.6.0.X maintenance series are included in this
release, unless otherwise noted.
* Porcelains implemented as shell scripts were utterly confused when you
entered to a subdirectory of a work tree from sideways, following a
symbolic link (this may need to be backported to older releases later).
* Tracking symbolic links would work better on filesystems whose lstat()
returns incorrect st_size value for them.
* "git add" and "git update-index" incorrectly allowed adding S/F when S
is a tracked symlink that points at a directory D that has a path F in
it (we still need to fix a similar nonsense when S is a submodule and F
is a path in it).
* "git am" after stopping at a broken patch lost --whitespace, -C, -p and
--3way options given from the command line initially.
* "git diff --stdin" used to take two trees on a line and compared them,
but we dropped support for such a use case long time ago. This has
been resurrected.
* "git filter-branch" failed to rewrite a tag name with slashes in it.
* "git http-push" did not understand URI scheme other than opaquelocktoken
when acquiring a lock from the server (this may need to be backported to
older releases later).
* After "git rebase -p" stopped with conflicts while replaying a merge,
"git rebase --continue" did not work (may need to be backported to older
releases).
* "git revert" records relative to which parent a revert was made when
reverting a merge. Together with new documentation that explains issues
around reverting a merge and merging from the updated branch later, this
hopefully will reduce user confusion (this may need to be backported to
older releases later).
* "git rm --cached" used to allow an empty blob that was added earlier to
be removed without --force, even when the file in the work tree has
since been modified.
* "git push --tags --all $there" failed with generic usage message without
telling saying these two options are incompatible.
* "git log --author/--committer" match used to potentially match the
timestamp part, exposing internal implementation detail. Also these did
not work with --fixed-strings match at all.
* "gitweb" did not mark non-ASCII characters imported from external HTML fragments
correctly.
^ permalink raw reply [relevance 7%]
* Re: git 1.6.1-rc4 testing dependency
2008-12-22 15:06 10% git 1.6.1-rc4 testing dependency Peter van der Does
@ 2008-12-22 20:50 5% ` Junio C Hamano
0 siblings, 0 replies; 128+ results
From: Junio C Hamano @ 2008-12-22 20:50 UTC (permalink / raw)
To: Peter van der Does; +Cc: git
Peter van der Does <peter@ourvirtualhome.com> writes:
> On my building machine I don't have any locales installed, making the
> LC_ALL=C.
> Not everybody will have this locale installed nor would they want it
> installed on their machines.
I think some tests play nicer than this one and skip tests that want UTF-8
locales; you may want to teach this script the same trick.
In the meantime, perhaps "GIT_SKIP_TETS='t9129' make test" would help.
^ permalink raw reply [relevance 5%]
* git 1.6.1-rc4 testing dependency
@ 2008-12-22 15:06 10% Peter van der Does
2008-12-22 20:50 5% ` Junio C Hamano
0 siblings, 1 reply; 128+ results
From: Peter van der Does @ 2008-12-22 15:06 UTC (permalink / raw)
To: git
[-- Attachment #1: Type: text/plain, Size: 799 bytes --]
With git 1.6.1 it it seems you need to install the locale en_US.UTF-8
otherwise it won't pass the testing during building the package.
The locale comes in play with test:
t9129-git-svn-i18n-commitencoding.sh
compare_svn_head_with () {
LC_ALL=en_US.UTF-8 svn log --limit 1 `git svn info --url` | \
sed -e 1,3d -e "/^-\{1,\}\$/d" >current &&
test_cmp current "$1"
}
On my building machine I don't have any locales installed, making the
LC_ALL=C.
Not everybody will have this locale installed nor would they want it
installed on their machines.
Is the locale is a dependency for git svn?
Or can this test be changed? Either by not having the locale dependency
or by skipping the test completely?
--
Peter van der Does
GPG key: E77E8E98
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply [relevance 10%]
* git 1.6.1-rc4 testing dependency
@ 2008-12-22 16:05 10% Peter van der Does
0 siblings, 0 replies; 128+ results
From: Peter van der Does @ 2008-12-22 16:05 UTC (permalink / raw)
To: git
With git 1.6.1 it it seems you need to install the locale en_US.UTF-8
otherwise it won't pass the testing during building the package.
The locale comes in play with test:
t9129-git-svn-i18n-commitencoding.sh
compare_svn_head_with () {
LC_ALL=en_US.UTF-8 svn log --limit 1 `git svn info --url` | \
sed -e 1,3d -e "/^-\{1,\}\$/d" >current &&
test_cmp current "$1"
}
On my building machine I don't have any locales installed, making the
LC_ALL=C.
Not everybody will have this locale installed nor would they want it
installed on their machines.
Is the locale is a dependency for git svn?
Or can this test be changed? Either by not having the locale dependency
or by skipping the test completely?
I apologize if this message shows up twice.
--
Peter van der Does
GPG key: E77E8E98
^ permalink raw reply [relevance 10%]
* [ANNOUNCE] GIT 1.6.1-rc4
@ 2008-12-22 9:54 8% Junio C Hamano
0 siblings, 0 replies; 128+ results
From: Junio C Hamano @ 2008-12-22 9:54 UTC (permalink / raw)
To: git
This hopefully will be the last -rc before 1.6.1 becomes your Christmas
present.
Changes since v1.6.1-rc3 are minor and boring details.
Alexander Gavrilov (2):
git-gui: Fix handling of relative paths in blame.
git-gui: Fix commit encoding handling.
Arjen Laarhoven (1):
Enable threaded delta search on Mac OS X/Darwin
Boyd Stephen Smith Jr (1):
git-revert documentation: refer to new HOWTO on reverting faulty merges
Christian Stimming (3):
git-gui: Update German (completed) translation.
gitk: Mark forgotten strings (header sentence parts in color chooser) for translation
gitk: Update German translation
David Aguilar (1):
git-mergetool: properly handle "git mergetool -- filename"
Fredrik Skolmli (1):
git-gui: Starting translation for Norwegian
Giuseppe Bilotta (1):
gitk: Map / to focus the search box
Johannes Schindelin (3):
fast-import: close pack before unlinking it
git-gui: Get rid of the last remnants of GIT_CONFIG_LOCAL
fast-export: deal with tag objects that do not have a tagger
Johannes Sixt (3):
gitk: Use check-buttons' -text property instead of separate labels
gitk: Ensure that "Reset branch" menu entry is enabled
gitk: Force the focus to the main window on Windows
Junio C Hamano (12):
git-show: do not segfault when showing a bad tag
pager: do not dup2 stderr if it is already redirected
gitweb: do not run "git diff" that is Porcelain
GIT 1.5.4.7
gitweb: do not run "git diff" that is Porcelain
make_absolute_path(): check bounds when seeing an overlong symlink
builtin-blame.c: use strbuf_readlink()
combine-diff.c: use strbuf_readlink()
fast-import: make tagger information optional
Make sure lockfiles are unlocked when dying on SIGPIPE
send-email: futureproof split_addrs() sub
GIT 1.6.1-rc4
Kevin Ballard (1):
gitk: Allow unbalanced quotes/braces in commit headers
Kirill A. Korinskiy (1):
Remove the requirement opaquelocktoken uri scheme
Lee Marlow (2):
bash completion: Sort config completion variables
bash completion: Sync config variables with their man pages
Linus Torvalds (5):
Add generic 'strbuf_readlink()' helper function
Make 'ce_compare_link()' use the new 'strbuf_readlink()'
Make 'index_path()' use 'strbuf_readlink()'
Make 'diff_populate_filespec()' use the new 'strbuf_readlink()'
Make 'prepare_temp_file()' ignore st_size for symlinks
Marcel M. Cary (1):
git-sh-setup: Fix scripts whose PWD is a symlink into a git work-dir
Markus Heidelberg (7):
Documentation: fix description for enabling hooks
doc/git-reset: add reference to git-stash
Documentation: sync example output with git output
Documentation: fix typos, grammar, asciidoc syntax
Documentation: fix typos, grammar, asciidoc syntax
Documentation/git-show-branch: work around "single quote" typesetting glitch
doc/git-fsck: change the way for getting heads' SHA1s
Michael J Gruber (1):
test overlapping ignore patterns
Michele Ballabio (1):
git gui: update Italian translation
Miklos Vajna (4):
git-gui: Update Hungarian translation for 0.12
git-daemon documentation: use {tilde}
githooks documentation: add a note about the +x mode
SubmittingPatches: mention the usage of real name in Signed-off-by: lines
Nanako Shiraishi (3):
git-gui: Update Japanese translation for 0.12
Clarify documentation of "git checkout <tree-ish> paths" syntax
Add a documentat on how to revert a faulty merge
Paul Mackerras (1):
gitk: Fix bugs in blaming code
Peter Krefting (2):
git-gui: Updated Swedish translation (515t0f0u).
git-gui: Fixed typos in Swedish translation.
René Scharfe (3):
Fix type-mismatch compiler warning from diff_populate_filespec()
connect.c: stricter port validation, silence compiler warning
fast-import.c: stricter strtoul check, silence compiler warning
Richard Hartmann (2):
Make help entries alphabetical
Always show which directory is not a git repository
Robin Rosenberg (1):
git-revert: record the parent against which a revert was made
Shawn O. Pearce (2):
git-gui: Update po template to include 'Mirroring %s' message
git-gui 0.12
Wu Fengguang (1):
git-send-email: handle email address with quoted comma
^ permalink raw reply [relevance 8%]
* Re: remote tracking branch deletion problem
2008-12-19 11:57 4% remote tracking branch deletion problem Thomas Jarosch
@ 2008-12-19 14:56 0% ` Michael J Gruber
0 siblings, 0 replies; 128+ results
From: Michael J Gruber @ 2008-12-19 14:56 UTC (permalink / raw)
To: Thomas Jarosch; +Cc: git, Junio C Hamano
Thomas Jarosch venit, vidit, dixit 19.12.2008 12:57:
> Hello together,
>
> while playing around with git, I stumbled upon a strange remote tracking
> branch deletion problem. It seems I'm unable to delete the remote tracking
> branch "origin/HEAD" using git 1.6.0.5. Here's what I did:
>
> [tomj@storm repo]$ git init
> Initialized empty Git repository in /tmp/repo/.git/
>
> [tomj@storm repo]$ echo "test" >test
> [tomj@storm repo]$ git add test
> [tomj@storm repo]$ git commit -m "Test"
>
> [tomj@storm tmp]$ git clone repo alice
> Initialized empty Git repository in /tmp/alice/.git/
>
> [tomj@storm alice]$ git branch -r
> origin/HEAD
> origin/master
>
> [tomj@storm alice]$ git branch -r -d origin/HEAD
> Deleted remote branch origin/HEAD.
> [tomj@storm alice]$ git branch -r -d origin/master
> Deleted remote branch origin/master.
>
> [tomj@storm alice]$ ls -al .git/refs/remotes/origin/HEAD
> -rw-rw---- 1 tomj intra2net 32 19. Dec 12:43 .git/refs/remotes/origin/HEAD
> [tomj@storm alice]$ git branch -r
> error: refs/remotes/origin/HEAD points nowhere!
>
> Is this supposed to be? git 1.6.1.rc3.35.gc0ceb shows a similar behavior.
I think the point here is that HEAD is really a symref. "git remote rm
origin" makes sure that symrefs are removed, and is the right command to
use here.
"git branch -r -d", as well as "git update-ref -d" fail to remove HEAD
because it's really not a branch but a symref.
You can use "git update-ref -d --no-deref" to remove HEAD.
Making builtin-branch use delete_ref(,,REF_ISSYMREF) leads to success
for your above commands. I don't know about side effects, though all
tests pass. Is this sensible?
I guess I should come up with a test for this along with the patch.
Michael
^ permalink raw reply [relevance 0%]
* remote tracking branch deletion problem
@ 2008-12-19 11:57 4% Thomas Jarosch
2008-12-19 14:56 0% ` Michael J Gruber
0 siblings, 1 reply; 128+ results
From: Thomas Jarosch @ 2008-12-19 11:57 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano
Hello together,
while playing around with git, I stumbled upon a strange remote tracking
branch deletion problem. It seems I'm unable to delete the remote tracking
branch "origin/HEAD" using git 1.6.0.5. Here's what I did:
[tomj@storm repo]$ git init
Initialized empty Git repository in /tmp/repo/.git/
[tomj@storm repo]$ echo "test" >test
[tomj@storm repo]$ git add test
[tomj@storm repo]$ git commit -m "Test"
[tomj@storm tmp]$ git clone repo alice
Initialized empty Git repository in /tmp/alice/.git/
[tomj@storm alice]$ git branch -r
origin/HEAD
origin/master
[tomj@storm alice]$ git branch -r -d origin/HEAD
Deleted remote branch origin/HEAD.
[tomj@storm alice]$ git branch -r -d origin/master
Deleted remote branch origin/master.
[tomj@storm alice]$ ls -al .git/refs/remotes/origin/HEAD
-rw-rw---- 1 tomj intra2net 32 19. Dec 12:43 .git/refs/remotes/origin/HEAD
[tomj@storm alice]$ git branch -r
error: refs/remotes/origin/HEAD points nowhere!
Is this supposed to be? git 1.6.1.rc3.35.gc0ceb shows a similar behavior.
Cheers,
Thomas
^ permalink raw reply [relevance 4%]
* Re: [ANNOUNCE] GIT 1.6.1-rc3
2008-12-15 10:04 5% ` Anders Melchiorsen
@ 2008-12-15 10:17 5% ` Junio C Hamano
0 siblings, 0 replies; 128+ results
From: Junio C Hamano @ 2008-12-15 10:17 UTC (permalink / raw)
To: Anders Melchiorsen; +Cc: Junio C Hamano, raa.lkml, git
"Anders Melchiorsen" <mail@cup.kalibalik.dk> writes:
> The patch in that post improved things somewhat, by making a correct
> commit. Of course, the working tree then silently loses a file, which
> could be seen as being worse than a fatal failure.
Thanks for a reminder. When resending for discussion, please make it
accompanied with a test case. In any case, let's leave anything iffy
after the final.
^ permalink raw reply [relevance 5%]
* Re: [ANNOUNCE] GIT 1.6.1-rc3
2008-12-15 8:32 11% ` [ANNOUNCE] GIT 1.6.1-rc3 Junio C Hamano
@ 2008-12-15 10:04 5% ` Anders Melchiorsen
2008-12-15 10:17 5% ` Junio C Hamano
0 siblings, 1 reply; 128+ results
From: Anders Melchiorsen @ 2008-12-15 10:04 UTC (permalink / raw)
To: Junio C Hamano, raa.lkml; +Cc: git
Junio C Hamano wrote:
> I have fixed a few more smallish (old) bugs after I tagged this, which
> will be in 'master' shortly, but it seems that this cycle is stabilizing
> fairly nicely. Let's have a successful 1.6.1 tagged on 20th. Please hunt
> and fix bugs until then.
Even though it is not a 1.6.1 regression, I wonder about the merge
conflict issue in
http://thread.gmane.org/gmane.comp.version-control.git/100859/focus=101182
The patch in that post improved things somewhat, by making a correct
commit. Of course, the working tree then silently loses a file, which
could be seen as being worse than a fatal failure.
Anders.
^ permalink raw reply [relevance 5%]
* [ANNOUNCE] GIT 1.6.1-rc3
2008-12-08 2:53 10% [ANNOUNCE] GIT 1.6.1-rc2 Junio C Hamano
@ 2008-12-15 8:32 11% ` Junio C Hamano
2008-12-15 10:04 5% ` Anders Melchiorsen
0 siblings, 1 reply; 128+ results
From: Junio C Hamano @ 2008-12-15 8:32 UTC (permalink / raw)
To: git; +Cc: linux-kernel
I have fixed a few more smallish (old) bugs after I tagged this, which
will be in 'master' shortly, but it seems that this cycle is stabilizing
fairly nicely. Let's have a successful 1.6.1 tagged on 20th. Please hunt
and fix bugs until then.
http://www.kernel.org/pub/software/scm/git/
git-1.6.1-rc3.tar.{gz,bz2} (source tarball)
git-htmldocs-1.6.1-rc3.tar.{gz,bz2} (preformatted docs)
git-manpages-1.6.1-rc3.tar.{gz,bz2} (preformatted docs)
The RPM binary packages for a few architectures are also there.
testing/git-*-1.6.1-rc3-1.fc9.$arch.rpm (RPM)
----------------------------------------------------------------
Changes since v1.6.1-rc2 are as follows:
Alexander Gavrilov (1):
Documentation: Describe git-gui Tools menu configuration options.
Alexander Potashev (2):
Fix typos in documentation
Fix typo in comment in builtin-add.c
Alexey Borzenkov (1):
Define linkgit macro in [macros] section
Brandon Casey (1):
git-branch: display sha1 on branch deletion
Deskin Miller (1):
git-svn: Make following parents atomic
Jakub Narebski (1):
gitweb: Fix bug in insert_file() subroutine
Jeff King (5):
reorder ALLOW_TEXTCONV option setting
diff: allow turning on textconv explicitly for plumbing
diff: fix handling of binary rewrite diffs
diff: respect textconv in rewrite diffs
rebase: improve error messages about dirty state
Jim Meyering (1):
git-config.txt: fix a typo
Johannes Schindelin (1):
Get rid of the last remnants of GIT_CONFIG_LOCAL
Junio C Hamano (4):
builtin-checkout.c: check error return from read_cache()
read-cache.c: typofix in comment
work around Python warnings from AsciiDoc
Fix t4031
Linus Torvalds (1):
fsck: reduce stack footprint
Markus Heidelberg (1):
builtin-commit: remove unused message variable
Nicolas Pitre (1):
make sure packs to be replaced are closed beforehand
Ralf Wildenhues (1):
Improve language in git-merge.txt and related docs
Tor Arvid Lund (1):
git-p4: Fix regression in p4Where method.
YONETANI Tomokazu (1):
git-fast-import possible memory corruption problem
^ permalink raw reply [relevance 11%]
* [ANNOUNCE] GIT 1.6.1-rc2
@ 2008-12-08 2:53 10% Junio C Hamano
2008-12-15 8:32 11% ` [ANNOUNCE] GIT 1.6.1-rc3 Junio C Hamano
0 siblings, 1 reply; 128+ results
From: Junio C Hamano @ 2008-12-08 2:53 UTC (permalink / raw)
To: git; +Cc: linux-kernel
Another week, another rc. There are no outstanding features that should
graduate from 'next' anymore until final.
http://www.kernel.org/pub/software/scm/git/
git-1.6.1-rc2.tar.{gz,bz2} (source tarball)
git-htmldocs-1.6.1-rc2.tar.{gz,bz2} (preformatted docs)
git-manpages-1.6.1-rc2.tar.{gz,bz2} (preformatted docs)
The RPM binary packages for a few architectures are also there.
testing/git-*-1.6.1-rc2-1.fc9.$arch.rpm (RPM)
----------------------------------------------------------------
Changes since v1.6.1-rc1 are as follows:
Alex Riesen (3):
Make some of fwrite/fclose/write/close failures visible
Make chdir failures visible
Report symlink failures in merge-recursive
Alexander Gavrilov (2):
gitk: Make line origin search update the busy status
gitk: Add a menu option to start git gui
Christian Couder (2):
bisect: fix "git bisect skip <commit>" and add tests cases
Documentation: describe how to "bisect skip" a range of commits
Christian Stimming (1):
gitk: Update German translation
Davide Libenzi (1):
xdiff: give up scanning similar lines early
Deskin Miller (1):
git-svn: Make branch use correct svn-remote
Giuseppe Bilotta (2):
gitweb: make gitweb_check_feature a boolean wrapper
Update comment on gitweb_check/get_feature
Jakub Narebski (2):
gitweb: Fix handling of non-ASCII characters in inserted HTML files
gitweb: Make project specific override for 'grep' feature work
Jeff King (2):
add stage to gitignore
tag: delete TAG_EDITMSG only on successful tag
Johannes Sixt (1):
t4030-diff-textconv: Make octal escape sequence more portable
Junio C Hamano (17):
builtin-rm.c: explain and clarify the "local change" logic
git add --intent-to-add: fix removal of cached emptiness
git add --intent-to-add: do not let an empty blob be committed by accident
gitweb: fix 'ctags' feature check and others
gitweb: rename gitweb_check_feature to gitweb_get_feature
Makefile: introduce NO_PTHREADS
Install git-stage in exec-path
git-am --whitespace: do not lose the command line option
git-am: propagate -C<n>, -p<n> options as well
git-am: propagate --3way options as well
Test that git-am does not lose -C/-p/--whitespace options
git-am: rename apply_opt_extra file to apply-opt
Update draft release notes to 1.6.1
GIT 1.6.0.5
Update draft release notes for 1.6.1
Revert "git-stash: use git rev-parse -q"
Point "stale" 1.6.0.5 documentation from the main git documentation page
Linus Torvalds (1):
Add backslash to list of 'crud' characters in real name
Mark Burton (1):
git-gui: Teach start_push_anywhere_action{} to notice when remote is a mirror.
Matt McCutchen (1):
"git diff <tree>{3,}": do not reverse order of arguments
Miklos Vajna (8):
User's Manual: remove duplicated url at the end of Appendix B
git-stash: use git rev-parse -q
filter-branch: use git rev-parse -q
lost-found: use git rev-parse -q
pull: use git rev-parse -q
rebase: use git rev-parse -q
submodule: use git rev-parse -q
http.c: use 'git_config_string' to get 'curl_http_proxy'
Nguyễn Thái Ngọc Duy (1):
Extend index to save more flags
Paul Mackerras (3):
gitk: Fix context menu items for generating diffs when in tree mode
gitk: Highlight only when search type is "containing:".
gitk: Fix bug in accessing undefined "notflag" variable
Scott Chacon (1):
Add a built-in alias for 'stage' to the 'add' command
Thomas Rast (1):
fetch-pack: Avoid memcpy() with src==dst
Tor Arvid Lund (1):
git-p4: Fix bug in p4Where method.
^ permalink raw reply [relevance 10%]
* Re: two questions about the format of loose object
2008-12-02 3:05 4% ` Liu Yubao
@ 2008-12-04 0:54 0% ` Nicolas Pitre
0 siblings, 0 replies; 128+ results
From: Nicolas Pitre @ 2008-12-04 0:54 UTC (permalink / raw)
To: Liu Yubao; +Cc: Shawn O. Pearce, git list
On Tue, 2 Dec 2008, Liu Yubao wrote:
> In fact the format I proposed in my patches is uncompressed loose
> object, not uncompressed loose object header, that's to say I
> proposed format 2 in my question 2, I am just curious why the
> loose object header is compressed in question 1.
>
> I did a test to add all files of git-1.6.1-rc1 with git-add, the
> time spent decreased by half. Other commands like git diff,
> git diff --cached, git diff HEAD~ HEAD should be faster now
> although the change may be not noticable for small and medium project.
Please try this with an unmodified git version:
git config --global core.loosecompression 0
and redo your tests please.
One thing that a purely uncompressed loose object format is missing is
quick data integrity protection. With the above, you'll have all your
loose objects uncompressed but they'll still have a CRC32 done over
them.
Nicolas
^ permalink raw reply [relevance 0%]
* Re: [PATCH] gitweb: Fix handling of non-ASCII characters in inserted HTML files
2008-12-03 3:55 0% ` Junio C Hamano
@ 2008-12-03 10:21 0% ` Jakub Narebski
0 siblings, 0 replies; 128+ results
From: Jakub Narebski @ 2008-12-03 10:21 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Tatsuki Sugiura, Gerrit Pape, Recai Oktas
Junio C Hamano wrote:
> Jakub Narebski <jnareb@gmail.com> writes:
>
> > Use new insert_file() subroutine to insert HTML chunks from external
> > files: $site_header, $home_text (by default indextext.html),
> > $site_footer, and $projectroot/$project/REAME.html.
> >
> > All non-ASCII chars of those files will be broken by Perl IO layer
> > without decoding to utf8, so insert_file() does to_utf8() on each
> > printed line; alternate solution would be to open those files with
> > "binmode $fh, ':utf8'", or even all files with "use open qw(:std :utf8)".
> > This is more complete solution that the one provided by Tatsuki Sugiura
> > in original patch
> >
> > [PATCH] gitweb: fix encode handling for site_{header,footer}
> > Msg-Id: <87vdumbxgc.wl@vaj-k-334-sugi.local.valinux.co.jp>
> > http://thread.gmane.org/gmane.comp.version-control.git/101199
>
> It may be more complete but it is obviously untested. Please help me
> trust you better with your future patches. Because I personally do not
> run gitweb myself, I really need a trustworthy lieutenant(s) in the area.
>
> [Wed Dec 3 01:52:07 2008] gitweb.perl: Global symbol "$fd" requires explicit package name at /git.git/t/../gitweb/gitweb.perl line 4500.
> [Wed Dec 3 01:52:07 2008] gitweb.perl: Execution of /git.git/t/../gitweb/gitweb.perl aborted due to compilation errors.
>
> > but it is in principle the same solution.
> >
> > I think this one as it is a bugfix should go in git 1.6.1
>
> Trading a gitweb with a small bug with a gitweb that does not even pass
> its test script does not feel like a good change to me.
>
> I think the breakage is the "close $fd" at the end of this hunk:
[...]
> I'll queue it to 'pu', with the "close $fd" removed, for now.
I'm very sorry about that. It was a bit of time since my last patch
sent, and I forgot that nevermind how obvious and simple the change,
one should run relevant parts of test suite, or at least try to run
gitweb / changed command.
With "close $fd" removed the patch is correct (and patches t9500*).
--
Jakub Narebski
Poland
^ permalink raw reply [relevance 0%]
* What's in git.git (Dec 2008, #01; Tue, 02)
@ 2008-12-03 6:23 5% Junio C Hamano
0 siblings, 0 replies; 128+ results
From: Junio C Hamano @ 2008-12-03 6:23 UTC (permalink / raw)
To: git
We'll probably have 1.6.0.5 by the end of this week.
The tip of the 'master' branch is at 1.6.1-rc1 with a few more fixes.
Hopefully we will have the final 1.6.1 by the end of the year.
* The 'maint' branch has these fixes since the last announcement.
Joey Hess (1):
sha1_file: avoid bogus "file exists" error message
Johannes Schindelin (1):
fast-export: use an unsorted string list for extra_refs
Junio C Hamano (1):
Update draft release notes to 1.6.0.5
Martin Koegler (1):
git push: Interpret $GIT_DIR/branches in a Cogito compatible way
Matt McCutchen (1):
git checkout: don't warn about unborn branch if -f is already passed
Miklos Vajna (2):
Add new testcase to show fast-export does not always exports all tags
User's Manual: remove duplicated url at the end of Appendix B
Nguyễn Thái Ngọc Duy (1):
generate-cmdlist.sh: avoid selecting synopsis at wrong place
Pete Wyckoff (1):
git-p4: fix keyword-expansion regex
Ralf Wildenhues (1):
Fix typos in the documentation.
SZEDER Gábor (2):
bash: remove dashed command leftovers
bash: offer refs instead of filenames for 'git revert'
Sam Vilain (1):
sha1_file.c: resolve confusion EACCES vs EPERM
Samuel Tardieu (2):
tag: Check that options are only allowed in the appropriate mode
tag: Add more tests about mixing incompatible modes and options
* The 'master' branch has these since the last announcement
in addition to the above.
Alexander Gavrilov (3):
gitk: Avoid handling the Return key twice in Add Branch
gitk: Make line origin search update the busy status
gitk: Add a menu option to start git gui
Cheng Renquan (1):
git-remote: add verbose mode to git remote update
Christian Couder (4):
git-gui: french translation update
bisect: teach "skip" to accept special arguments like "A..B"
bisect: fix "git bisect skip <commit>" and add tests cases
Documentation: describe how to "bisect skip" a range of commits
Christian Stimming (1):
gitk: Update German translation
Giuseppe Bilotta (2):
gitweb: make gitweb_check_feature a boolean wrapper
Update comment on gitweb_check/get_feature
Johannes Schindelin (1):
Document levenshtein.c
Johannes Sixt (2):
compat/mingw.c: Teach mingw_rename() to replace read-only files
t4030-diff-textconv: Make octal escape sequence more portable
Junio C Hamano (6):
gitweb: fix 'ctags' feature check and others
gitweb: rename gitweb_check_feature to gitweb_get_feature
send-email: do not reverse the command line arguments
Include git-gui--askpass in git-gui RPM package
GIT 1.6.1-rc1
Makefile: introduce NO_PTHREADS
Linus Torvalds (3):
Add cache preload facility
Fix index preloading for racy dirty case
Add backslash to list of 'crud' characters in real name
Mark Burton (1):
git-gui: Teach start_push_anywhere_action{} to notice when remote is a
mirror.
Michele Ballabio (1):
git gui: update Italian translation
Miklos Vajna (5):
Update Hungarian translation. 100% completed.
builtin-clone: use strbuf in guess_dir_name()
builtin-clone: use strbuf in clone_local() and copy_or_link_directory()
builtin_clone: use strbuf in cmd_clone()
git-stash: use git rev-parse -q
Nanako Shiraishi (1):
git-gui: update Japanese translation
Paul Mackerras (6):
gitk: Index line[hnd]tag arrays by id rather than row number
gitk: Fix switch statement in parseviewargs
gitk: Show local changes properly when we have a path limit
gitk: Fix context menu items for generating diffs when in tree mode
gitk: Highlight only when search type is "containing:".
gitk: Fix bug in accessing undefined "notflag" variable
Peter Krefting (1):
Updated Swedish translation (514t0f0u).
Pierre Habouzit (4):
git send-email: make the message file name more specific.
git send-email: interpret unknown files as revision lists
git send-email: add --annotate option
git send-email: ask less questions when --compose is used.
Ralf Wildenhues (1):
Fix typos in the documentation.
René Scharfe (6):
add strbuf_expand_dict_cb(), a helper for simple cases
merge-recursive: use strbuf_expand() instead of interpolate()
daemon: use strbuf_expand() instead of interpolate()
daemon: inline fill_in_extra_table_entries()
daemon: deglobalize variable 'directory'
remove the unused files interpolate.c and interpolate.h
SZEDER Gábor (1):
bash: complete full refs
Samuel Tardieu (1):
Fix deletion of last character in levenshtein distance
Scott Chacon (1):
Add a built-in alias for 'stage' to the 'add' command
Tuncer Ayaz (2):
Teach/Fix pull/fetch -q/-v options
Retain multiple -q/-v occurrences in git pull
^ permalink raw reply [relevance 5%]
* Re: [PATCH] gitweb: Fix handling of non-ASCII characters in inserted HTML files
2008-12-01 18:01 3% ` [PATCH] gitweb: Fix handling of non-ASCII characters in inserted HTML files Jakub Narebski
@ 2008-12-03 3:55 0% ` Junio C Hamano
2008-12-03 10:21 0% ` Jakub Narebski
0 siblings, 1 reply; 128+ results
From: Junio C Hamano @ 2008-12-03 3:55 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git, Tatsuki Sugiura, Gerrit Pape, Recai Oktas
Jakub Narebski <jnareb@gmail.com> writes:
> Use new insert_file() subroutine to insert HTML chunks from external
> files: $site_header, $home_text (by default indextext.html),
> $site_footer, and $projectroot/$project/REAME.html.
>
> All non-ASCII chars of those files will be broken by Perl IO layer
> without decoding to utf8, so insert_file() does to_utf8() on each
> printed line; alternate solution would be to open those files with
> "binmode $fh, ':utf8'", or even all files with "use open qw(:std :utf8)".
>
> Note that inserting README.html lost one of checks for simplicity.
>
> Noticed-by: Tatsuki Sugiura <sugi@nemui.org>
> Signed-off-by: Jakub Narebski <jnareb@gmail.com>
> ---
> This is more complete solution that the one provided by Tatsuki Sugiura
> in original patch
>
> [PATCH] gitweb: fix encode handling for site_{header,footer}
> Msg-Id: <87vdumbxgc.wl@vaj-k-334-sugi.local.valinux.co.jp>
> http://thread.gmane.org/gmane.comp.version-control.git/101199
It may be more complete but it is obviously untested. Please help me
trust you better with your future patches. Because I personally do not
run gitweb myself, I really need a trustworthy lieutenant(s) in the area.
[Wed Dec 3 01:52:07 2008] gitweb.perl: Global symbol "$fd" requires explicit package name at /git.git/t/../gitweb/gitweb.perl line 4500.
[Wed Dec 3 01:52:07 2008] gitweb.perl: Execution of /git.git/t/../gitweb/gitweb.perl aborted due to compilation errors.
> but it is in principle the same solution.
>
> I think this one as it is a bugfix should go in git 1.6.1
Trading a gitweb with a small bug with a gitweb that does not even pass
its test script does not feel like a good change to me.
I think the breakage is the "close $fd" at the end of this hunk:
> @@ -4472,13 +4475,11 @@ sub git_summary {
> print "</table>\n";
>
> if (-s "$projectroot/$project/README.html") {
> - if (open my $fd, "$projectroot/$project/README.html") {
> - print "<div class=\"title\">readme</div>\n" .
> - "<div class=\"readme\">\n";
> - print $_ while (<$fd>);
> - print "\n</div>\n"; # class="readme"
> - close $fd;
> - }
> + print "<div class=\"title\">readme</div>\n" .
> + "<div class=\"readme\">\n";
> + insert_file("$projectroot/$project/README.html");
> + print "\n</div>\n"; # class="readme"
> + close $fd;
> }
>
> # we need to request one more than 16 (0..15) to check if
I'll queue it to 'pu', with the "close $fd" removed, for now.
^ permalink raw reply [relevance 0%]
* Re: two questions about the format of loose object
@ 2008-12-02 3:05 4% ` Liu Yubao
2008-12-04 0:54 0% ` Nicolas Pitre
0 siblings, 1 reply; 128+ results
From: Liu Yubao @ 2008-12-02 3:05 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: git list
Shawn O. Pearce wrote:
> Liu Yubao <yubao.liu@gmail.com> wrote:
>> In current implementation the loose objects are compressed:
>>
>> loose object = deflate(typename + <space> + size + '\0' + data)
> ...
>> * Question 1:
>>
>> Why not use the format below for loose object?
>> loose object = typename + <space> + size + '\0' + deflate(data)
>
> Historical accident. We really should have used a format more
> like what you are asking here, because it makes inflation easier.
> The pack file format uses a header structure sort of like this,
> for exactly that reason. IOW we did learn our mistakes and fix them.
>
> If you look up the new style loose object code you'll see that it
> has a format like this (sort of), the header is actually the same
> format that is used in the pack files, making it smaller than what
> you propose but also easier to unpack as the code can be reused
> with the pack reading code.
>
> Unfortunately the new style loose object was phased out; it never
> really took off and it made the code much more complex. So it was
> pulled in commit 726f852b0ed7e03e88c419a9996c3815911c9db1:
>
In fact the format I proposed in my patches is uncompressed loose
object, not uncompressed loose object header, that's to say I
proposed format 2 in my question 2, I am just curious why the
loose object header is compressed in question 1.
I did a test to add all files of git-1.6.1-rc1 with git-add, the
time spent decreased by half. Other commands like git diff,
git diff --cached, git diff HEAD~ HEAD should be faster now
although the change may be not noticable for small and medium project.
> Author: Nicolas Pitre <nico@cam.org>:
> > deprecate the new loose object header format
> >
> > Now that we encourage and actively preserve objects in a packed form
> > more agressively than we did at the time the new loose object format and
> > core.legacyheaders were introduced, that extra loose object format
> > doesn't appear to be worth it anymore.
> >
> > Because the packing of loose objects has to go through the delta match
> > loop anyway, and since most of them should end up being deltified in
> > most cases, there is really little advantage to have this parallel loose
> > object format as the CPU savings it might provide is rather lost in the
> > noise in the end.
> >
> > This patch gets rid of core.legacyheaders, preserve the legacy format as
> > the only writable loose object format and deprecate the other one to
> > keep things simpler.
>
Thank you for dig it out for me!
Best regards,
Liu Yubao
^ permalink raw reply [relevance 4%]
* [PATCH 0/5] support reading and writing uncompressed loose object
@ 2008-12-02 1:48 3% ` Liu Yubao
0 siblings, 0 replies; 128+ results
From: Liu Yubao @ 2008-12-02 1:48 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git list
Hi,
In original implementation, git stores loose object like this:
loose object = deflate(typename + <space> + size + data)
The patches below add support to read and write uncompressed loose
object:
loose object = typename + <space> + size + data
The cons and pros to use uncompressed loose object:
cons
* old git can't read these uncompressed loose objects
(I think it's not a big problem because old git can read
pack files generated by new git)
* uncompressed loose objects occupy more disk space
(I also think it's not a big problem because loose objects
aren't too many in general)
pros
* avoid compressing and uncompressing loose objects that are likely
frequently used when coding/merging with git add/diff/diff --cached/
merge/rebase/log.
* the code to read and write uncompressed loose objects is
simpler, although there are now more code paths for compatibility.
* better to share loose objects among multiple git processes because
sha1 files can be used directly after mmapped. The original git
uncompresses loose objects into heap memory area so that they
can't be shared by other processes.
(NOTICE: The patches below doesn't use mmapped sha1 files directly
because I find parse_object() requires a buffer terminated with
zero.)
* easy to grep objects in .git/objects (...stupid use case :-)
If these patches are worth being included into upstream branch,
I will add a new config variable core.uncompressedLooseObject.
Explanation to the patches:
1) avoid parse_sha1_header() accessing memory out of bound
Just for more safety, no inflateInit() to detect errors for
uncompressed loose objects.
2) don't die immediately when convert an invalid type name
So we can fall back to compressed loose objects.
3) optimize parse_sha1_header() a little by detecting object type
To quickly detect whether it seems an uncompressed loose object.
4) support reading uncompressed loose object
The new feature.
5) support writing uncompressed loose object
The new feature, need a git-config variable yet.
The patches are generated against git-1.6.1-rc, I have run the test cases
and it seems ok.
object.c | 14 +++++++++++++-
object.h | 1 +
sha1_file.c | 58 +++++++++++++++++++++++++++++++++++++++++++++-------------
3 files changed, 59 insertions(+), 14 deletions(-)
^ permalink raw reply [relevance 3%]
* [PATCH] gitweb: Fix handling of non-ASCII characters in inserted HTML files
@ 2008-12-01 18:01 3% ` Jakub Narebski
2008-12-03 3:55 0% ` Junio C Hamano
0 siblings, 1 reply; 128+ results
From: Jakub Narebski @ 2008-12-01 18:01 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano, Tatsuki Sugiura, Gerrit Pape, Recai Oktas
Use new insert_file() subroutine to insert HTML chunks from external
files: $site_header, $home_text (by default indextext.html),
$site_footer, and $projectroot/$project/REAME.html.
All non-ASCII chars of those files will be broken by Perl IO layer
without decoding to utf8, so insert_file() does to_utf8() on each
printed line; alternate solution would be to open those files with
"binmode $fh, ':utf8'", or even all files with "use open qw(:std :utf8)".
Note that inserting README.html lost one of checks for simplicity.
Noticed-by: Tatsuki Sugiura <sugi@nemui.org>
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
---
This is more complete solution that the one provided by Tatsuki Sugiura
in original patch
[PATCH] gitweb: fix encode handling for site_{header,footer}
Msg-Id: <87vdumbxgc.wl@vaj-k-334-sugi.local.valinux.co.jp>
http://thread.gmane.org/gmane.comp.version-control.git/101199
but it is in principle the same solution.
I think this one as it is a bugfix should go in git 1.6.1
gitweb/gitweb.perl | 33 +++++++++++++++++----------------
1 files changed, 17 insertions(+), 16 deletions(-)
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index 933e137..82262a3 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -2740,6 +2740,15 @@ sub get_file_owner {
return to_utf8($owner);
}
+# assume that file exists
+sub insert_file {
+ my $filename = shift;
+
+ open my $fd, '<', $filename;
+ print map(to_utf8, <$fd>);
+ close $fd;
+}
+
## ......................................................................
## mimetype related functions
@@ -2928,9 +2937,7 @@ EOF
"<body>\n";
if (-f $site_header) {
- open (my $fd, $site_header);
- print <$fd>;
- close $fd;
+ insert_file($site_header);
}
print "<div class=\"page_header\">\n" .
@@ -3017,9 +3024,7 @@ sub git_footer_html {
print "</div>\n"; # class="page_footer"
if (-f $site_footer) {
- open (my $fd, $site_footer);
- print <$fd>;
- close $fd;
+ insert_file($site_footer);
}
print "</body>\n" .
@@ -4358,9 +4363,7 @@ sub git_project_list {
git_header_html();
if (-f $home_text) {
print "<div class=\"index_include\">\n";
- open (my $fd, $home_text);
- print <$fd>;
- close $fd;
+ insert_file($home_text);
print "</div>\n";
}
print $cgi->startform(-method => "get") .
@@ -4472,13 +4475,11 @@ sub git_summary {
print "</table>\n";
if (-s "$projectroot/$project/README.html") {
- if (open my $fd, "$projectroot/$project/README.html") {
- print "<div class=\"title\">readme</div>\n" .
- "<div class=\"readme\">\n";
- print $_ while (<$fd>);
- print "\n</div>\n"; # class="readme"
- close $fd;
- }
+ print "<div class=\"title\">readme</div>\n" .
+ "<div class=\"readme\">\n";
+ insert_file("$projectroot/$project/README.html");
+ print "\n</div>\n"; # class="readme"
+ close $fd;
}
# we need to request one more than 16 (0..15) to check if
^ permalink raw reply related [relevance 3%]
* [ANNOUNCE] GIT 1.6.1-rc1
@ 2008-12-01 9:54 5% Junio C Hamano
0 siblings, 0 replies; 128+ results
From: Junio C Hamano @ 2008-12-01 9:54 UTC (permalink / raw)
To: git
As promised, 1.6.1-rc1 is found at the usual places, and from here on we
will be in bugfixes-only mode until 1.6.1 final. I also think there
probably are a few more patches on 'next' (e.g. the first patch on the
gp/gitweb-feature topic, which is a pure bugfix) that haven't merged to
'master' but should.
^ permalink raw reply [relevance 5%]
* git gui: update Italian translation
2008-11-16 21:58 4% git-gui translators - 0.12 coming soon Shawn O. Pearce
@ 2008-11-19 9:49 0% ` Michele Ballabio
0 siblings, 0 replies; 128+ results
From: Michele Ballabio @ 2008-11-19 9:49 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: git
[-- Attachment #1: Type: text/plain, Size: 356 bytes --]
On Sunday 16 November 2008, Shawn O. Pearce wrote:
> git-gui 0.12 will be coming soon. Some new strings have entered
> the project, so I'd like to ask everyone to update their .po with
> new translations. I'm freezing new features, so we can focus on
> translation activity and bug fixing during the git 1.6.1 rc period.
>
> Thanks!
>
Patch attached.
[-- Attachment #2: 0001-git-gui-update-Italian-translation.patch.gz --]
[-- Type: application/x-gzip, Size: 13308 bytes --]
^ permalink raw reply [relevance 0%]
* git-gui translators - 0.12 coming soon
@ 2008-11-16 21:58 4% Shawn O. Pearce
2008-11-19 9:49 0% ` git gui: update Italian translation Michele Ballabio
0 siblings, 1 reply; 128+ results
From: Shawn O. Pearce @ 2008-11-16 21:58 UTC (permalink / raw)
To: git
git-gui 0.12 will be coming soon. Some new strings have entered
the project, so I'd like to ask everyone to update their .po with
new translations. I'm freezing new features, so we can focus on
translation activity and bug fixing during the git 1.6.1 rc period.
Thanks!
--
Shawn.
^ permalink raw reply [relevance 4%]
* Re: [PATCH] t9001: use older Getopt::Long boolean prefix '--no' rather than '--no-'
2008-10-11 0:24 4% ` Shawn O. Pearce
@ 2008-10-11 0:44 0% ` Brandon Casey
0 siblings, 0 replies; 128+ results
From: Brandon Casey @ 2008-10-11 0:44 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Git Mailing List
Shawn O. Pearce wrote:
> Brandon Casey <casey@nrlssc.navy.mil> wrote:
>> Since dbf5e1e9, the '--no-validate' option is a Getopt::Long boolean
>> option. The '--no-' prefix (as in --no-validate) for boolean options
>> is not supported in Getopt::Long version 2.32 which was released with
>> Perl 5.8.0. This version only supports '--no' as in '--novalidate'.
>> More recent versions of Getopt::Long, such as version 2.34, support
>> either prefix. So use the older form in the tests.
>
> Ouch.
>
> Should we update our docs?
>
> Actually, if 2.32 doesn't support the --no-validate syntax than
> this is a regression in Git. Even if it is what many would call a
> bug in Getopt::Long in Perl, I think Git 1.6.1 should still honor
> --no-validate like it did in Git 1.6.0.
If it makes any difference, none of the other boolean options would
work in the documented '--no-' form either, such as --no-thread,
--no-signed-off-by-cc, etc. '--no-validate' is probably the only one
that used to work.
Update the docs?
---[no-]validate::
+--[no-|no]validate::
hmm. not sure.
-brandon
^ permalink raw reply [relevance 0%]
* Re: [PATCH] t9001: use older Getopt::Long boolean prefix '--no' rather than '--no-'
@ 2008-10-11 0:24 4% ` Shawn O. Pearce
2008-10-11 0:44 0% ` Brandon Casey
0 siblings, 1 reply; 128+ results
From: Shawn O. Pearce @ 2008-10-11 0:24 UTC (permalink / raw)
To: Brandon Casey; +Cc: Git Mailing List
Brandon Casey <casey@nrlssc.navy.mil> wrote:
> Since dbf5e1e9, the '--no-validate' option is a Getopt::Long boolean
> option. The '--no-' prefix (as in --no-validate) for boolean options
> is not supported in Getopt::Long version 2.32 which was released with
> Perl 5.8.0. This version only supports '--no' as in '--novalidate'.
> More recent versions of Getopt::Long, such as version 2.34, support
> either prefix. So use the older form in the tests.
Ouch.
Should we update our docs?
Actually, if 2.32 doesn't support the --no-validate syntax than
this is a regression in Git. Even if it is what many would call a
bug in Getopt::Long in Perl, I think Git 1.6.1 should still honor
--no-validate like it did in Git 1.6.0.
> diff --git a/t/t9001-send-email.sh b/t/t9001-send-email.sh
> index d098a01..561ae7d 100755
> --- a/t/t9001-send-email.sh
> +++ b/t/t9001-send-email.sh
> @@ -109,7 +109,7 @@ test_expect_success 'allow long lines with --no-validate' '
> --from="Example <nobody@example.com>" \
> --to=nobody@example.com \
> --smtp-server="$(pwd)/fake.sendmail" \
> - --no-validate \
> + --novalidate \
> $patches longline.patch \
> 2>errors
> '
--
Shawn.
^ permalink raw reply [relevance 4%]
* Re: [PATCH (GITK,GIT-GUI,DOCS) 3/7] git-gui: Support starting gitk from Gui Blame
@ 2008-08-25 5:06 4% ` Shawn O. Pearce
0 siblings, 0 replies; 128+ results
From: Shawn O. Pearce @ 2008-08-25 5:06 UTC (permalink / raw)
To: Alexander Gavrilov; +Cc: git, Paul Mackerras, Junio C Hamano
Alexander Gavrilov <angavrilov@gmail.com> wrote:
> Add a context menu command to load commits
> that are within a certain time range from the
> selected commit into gitk.
>
> It can be useful for understanding of the code,
> especially if the repository is imported from
> a VCS that does not support atomic commits.
The git-gui part of this series is now staged in my pu branch.
If Paul is going to also apply this to gitk we can ship it in
the next feature release of Git (1.6.1).
--
Shawn.
^ permalink raw reply [relevance 4%]
* Re: Closing the merge window for 1.6.0
@ 2008-07-15 17:04 4% ` Dmitry Potapov
0 siblings, 0 replies; 128+ results
From: Dmitry Potapov @ 2008-07-15 17:04 UTC (permalink / raw)
To: Johannes Schindelin
Cc: Petr Baudis, Junio C Hamano, Nicolas Pitre, Gerrit Pape, git
On Tue, Jul 15, 2008 at 04:27:02PM +0100, Johannes Schindelin wrote:
>
> >From the time balance sheet, it does not look good at all: a few minutes
> for Junio to change and commit, up to a few hours (because they missed it
> in the release notes) for probably more than hundred repository
> maintainers that are not subscribed to the Git mailing list.
If you just grab sources and never read release notes, there is nothing
that can help you. If Git 1.6.0 is not the right moment to do these
changes then Git 1.6.1 is neither, regardless whether Debian will
release Lenny by that time or not. People do not upgrade their distro in
the day of release. Some upgraded to Etch not so long ago. So, should we
wait for another year till 1.7.0?
>
> And I absolutely agree with Pasky that this does _nothing_ in the vague
> direction of wielding a reputation of being easy to use.
I don't think Git 1.4 is easy to use. If you want Git that is easy to
use install Git 1.5.x. And, it is *much* easier to install Git from
backports then to deal with usability issues of Git 1.4 and the lack
of community support. So, I don't see how this change may hurt.
>
> Sure, we can make it easy on ourselves. And it is just as easy to make it
> hard on others. If you're okay with that, I am not.
It has *nothing* to do with making easy on ourselves and hard on others.
The question here is what is the appropriate time to change these default
settings, and I believe that *major* releases are the appropriate time
while minor ones are not.
Dmitry
^ permalink raw reply [relevance 4%]
Results 1-128 of 128 | reverse | options above
-- pct% links below jump to the message on this page, permalinks otherwise --
2008-07-14 5:11 What's cooking in git.git (topics) 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 ` Dmitry Potapov
2008-07-15 15:27 ` Johannes Schindelin
2008-07-15 17:04 4% ` Dmitry Potapov
2008-08-23 8:25 [PATCH (GITK,GIT-GUI,DOCS) 0/7] Improve gui blame and gitk integration Alexander Gavrilov
2008-08-23 8:30 ` [PATCH (GITK,GIT-GUI,DOCS) 3/7] git-gui: Support starting gitk from Gui Blame Alexander Gavrilov
2008-08-25 5:06 4% ` Shawn O. Pearce
2008-10-11 0:21 [PATCH] t9001: use older Getopt::Long boolean prefix '--no' rather than '--no-' Brandon Casey
2008-10-11 0:24 4% ` Shawn O. Pearce
2008-10-11 0:44 0% ` Brandon Casey
2008-11-16 21:58 4% git-gui translators - 0.12 coming soon Shawn O. Pearce
2008-11-19 9:49 0% ` git gui: update Italian translation Michele Ballabio
2008-11-17 10:40 [PATCH] gitweb: fix encode handling for site_{header,footer} Jakub Narebski
2008-12-01 18:01 3% ` [PATCH] gitweb: Fix handling of non-ASCII characters in inserted HTML files Jakub Narebski
2008-12-03 3:55 0% ` Junio C Hamano
2008-12-03 10:21 0% ` Jakub Narebski
2008-12-01 8:00 two questions about the format of loose object Liu Yubao
2008-12-01 8:25 ` Junio C Hamano
2008-12-02 1:48 3% ` [PATCH 0/5] support reading and writing uncompressed " Liu Yubao
2008-12-01 15:32 ` two questions about the format of " Shawn O. Pearce
2008-12-02 3:05 4% ` Liu Yubao
2008-12-04 0:54 0% ` Nicolas Pitre
2008-12-01 9:54 5% [ANNOUNCE] GIT 1.6.1-rc1 Junio C Hamano
2008-12-03 6:23 5% What's in git.git (Dec 2008, #01; Tue, 02) Junio C Hamano
2008-12-08 2:53 10% [ANNOUNCE] GIT 1.6.1-rc2 Junio C Hamano
2008-12-15 8:32 11% ` [ANNOUNCE] GIT 1.6.1-rc3 Junio C Hamano
2008-12-15 10:04 5% ` Anders Melchiorsen
2008-12-15 10:17 5% ` Junio C Hamano
2008-12-19 11:57 4% remote tracking branch deletion problem Thomas Jarosch
2008-12-19 14:56 0% ` Michael J Gruber
2008-12-22 9:54 8% [ANNOUNCE] GIT 1.6.1-rc4 Junio C Hamano
2008-12-22 15:06 10% git 1.6.1-rc4 testing dependency Peter van der Does
2008-12-22 20:50 5% ` Junio C Hamano
2008-12-22 16:05 10% Peter van der Does
2008-12-25 6:36 7% [ANNOUNCE] GIT 1.6.1 Junio C Hamano
2008-12-25 8:32 5% ` Christian MICHON
2008-12-25 10:00 5% ` bill lam
2008-12-25 10:13 5% ` Junio C Hamano
2008-12-25 10:25 5% ` bill lam
2008-12-25 11:42 5% ` René Scharfe
2008-12-25 14:09 5% ` bill lam
2008-12-25 18:50 5% ` Junio C Hamano
2008-12-26 14:42 5% ` bill lam
2008-12-25 18:53 5% ` Pau Garcia i Quiles
2008-12-26 14:33 5% ` bill lam
2008-12-25 11:44 5% ` Heikki Orsila
2008-12-26 1:38 5% ` Sitaram Chamarty
2008-12-27 1:56 5% ` Nicolas Pitre
2008-12-27 10:31 0% ` [ANNOUNCE] MSYSGIT 1.6.1 Steffen Prohaska
2008-12-31 8:17 4% git push question.. error: Unable to lock remote branch refs/heads/master aaron smith
2008-12-31 8:22 0% ` aaron smith
2009-01-05 6:26 7% http push to WebDAV server fails (apache 2.2 under Win) - possible bug!? Harald Weppner
2009-01-09 10:11 5% Minimum required version of subversion for git-svn? Tom G. Christensen
2009-01-12 1:03 0% ` Eric Wong
2009-01-12 8:03 0% ` Tom G. Christensen
2009-01-17 10:58 0% ` Eric Wong
2009-01-12 1:15 [BUG/RFH] gitweb: Trouble with ref markers being hyperlinks because of illegally nested links Jakub Narebski
2009-01-12 2:59 ` Giuseppe Bilotta
2009-01-13 0:13 5% ` Jakub Narebski
2009-01-13 0:59 0% ` Giuseppe Bilotta
2009-01-14 0:17 0% ` [RFC/PATCH] gitweb: Fix nested links problem with ref markers Jakub Narebski
2009-01-13 14:53 4% git-svn fails to fetch repository Vladimir Pouzanov
2009-01-13 19:01 Vladimir Pouzanov
2009-01-13 20:39 ` Björn Steinbrink
2009-01-13 20:46 ` Vladimir Pouzanov
2009-01-13 21:12 ` Jay Soffian
2009-01-13 21:16 ` Vladimir Pouzanov
2009-01-13 21:28 ` Jay Soffian
2009-01-13 21:34 ` Vladimir Pouzanov
2009-01-14 0:58 ` Jay Soffian
2009-01-14 8:32 ` Vladimir Pouzanov
2009-01-14 18:06 ` Jay Soffian
2009-01-17 9:51 ` Eric Wong
2009-01-17 10:06 3% ` Vladimir Pouzanov
2009-01-17 10:45 0% ` Eric Wong
2009-01-14 10:48 3% [PATCH 1/3] git-daemon: single-line logs Jan Engelhardt
2009-01-14 10:48 4% ` [PATCH 2/3] git-daemon: use getnameinfo to resolve hostname Jan Engelhardt
2009-01-14 10:49 4% ` [PATCH 3/3] git-daemon: vhost support Jan Engelhardt
2009-01-14 12:25 ` [PATCH 2/3] git-daemon: use getnameinfo to resolve hostname Jeff King
2009-01-14 19:25 4% ` [2/3] " Jan Engelhardt
2009-01-15 10:39 rebase -p confusion in 1.6.1 Sitaram Chamarty
2009-01-15 13:39 4% ` Michael J Gruber
2009-01-17 1:37 3% git add --patch bug with split+edit? Hannu Koivisto
2009-01-17 2:53 13% [PATCH 1/3] http-push: append slash if possible for directories Ray Chuan
2009-01-17 5:19 0% ` Johannes Schindelin
2009-01-17 6:02 0% ` Johannes Schindelin
2009-01-17 2:59 12% [PATCH 2/3] http-push: when sending objects, don't PUT before MOVE Ray Chuan
2009-01-17 6:13 0% ` Johannes Schindelin
2009-01-17 12:08 0% ` Ray Chuan
2009-01-17 2:59 14% [PATCH 3/3] http-push: update tests Ray Chuan
2009-01-20 15:46 5% git fast-import problem converting from CVS with git 1.6.1 and cvs2svn 2.2.0 Kelly F. Hickel
2009-01-20 16:04 6% ` Kelly F. Hickel
2009-01-22 14:30 6% ` Kelly F. Hickel
2009-01-22 16:31 6% ` Johannes Schindelin
2009-01-23 4:14 5% ` Michael Haggerty
2009-01-20 16:41 6% ` Johannes Schindelin
2009-01-20 20:29 6% ` Daniel Barkalow
2009-01-23 11:28 4% git blame: two "-C"s versus just a single -C Sitaram Chamarty
2009-01-23 19:12 0% ` Sitaram Chamarty
2009-01-23 12:25 4% bug: transform a binary file into a symlink in one commit => invalid binary patch Pixel
2009-01-23 13:13 0% ` Michael J Gruber
2009-01-26 0:35 0% ` Jeff King
2009-01-26 7:37 0% ` Junio C Hamano
2009-01-23 21:52 3% [RFC PATCH (GIT-GUI/CORE BUG)] git-gui: Avoid an infinite rescan loop in handle_empty_diff Alexander Gavrilov
2009-01-26 11:57 Emacs git-mode feature request: support fill-paragraph correctly Peter Simons
2009-01-27 11:03 ` Alexandre Julliard
2009-01-27 14:07 4% ` Peter Simons
2009-01-28 21:32 0% ` Junio C Hamano
2009-01-29 10:42 0% ` Alexandre Julliard
2009-01-26 20:02 10% git 1.6.1 on AIX 5.3 Perry Smith
2009-01-26 21:00 5% ` Jeff King
2009-01-26 22:32 5% ` Mike Ralphson
2009-01-26 22:57 10% ` Perry Smith
2009-01-27 3:52 5% ` Jeff King
2009-01-27 10:10 5% ` Mike Ralphson
2009-01-28 1:35 11% ` Perry Smith
2009-01-28 7:01 5% ` Jeff King
2009-01-28 7:37 5% ` Junio C Hamano
2009-01-28 7:42 5% ` Jeff King
2009-01-28 15:03 5% ` Perry Smith
2009-01-28 9:48 5% ` Mike Ralphson
2009-01-27 17:50 3% rebase failure if commit message looks like a patch Anton
2009-01-27 23:04 5% Bad objects error since upgrading GitHub servers to 1.6.1 PJ Hyett
2009-01-29 1:24 5% Git SVN fetch failing on large commit Andrew Selder
2009-01-29 3:43 0% ` Andrew Selder
2009-01-29 10:16 4% [ANNOUNCE] GIT 1.6.1.2 Junio C Hamano
2009-01-30 22:12 4% 'git clone' doesn't use alternates automatically? James Pickens
2009-01-31 7:12 0% ` Jeff King
2009-02-01 18:57 3% [ANNOUNCE] CGIT 0.8.2 Lars Hjemli
2009-02-04 16:10 4% segfault during clone via http Adam Thorsen
2009-02-04 18:00 0% ` Jay Soffian
2009-02-18 12:44 4% post-receive email Arya, Manish Kumar
2009-02-18 13:36 0% ` Patrick Notz
2009-03-04 1:43 3% git-svn does not support intermediate directories? Michael Lai
2009-03-04 4:30 0% ` Tim Stoakes
2009-03-06 0:12 0% ` [RFC PATCH] " Michael Lai
[not found] <e878dbad0903052321l6c0d310bk2ba568138b409d36@mail.gmail.com>
2009-03-06 7:23 ` Using Git with windows Tariq Hassanen
2009-03-06 14:38 ` Tim Visher
2009-03-06 15:30 4% ` Dmitry Potapov
2009-03-08 1:10 3% Git for Windows 1.6.2-preview20090308 Johannes Schindelin
2009-03-08 12:59 0% ` Lee Henson
2009-03-09 10:34 0% ` Rutger Nijlunsing
2009-03-09 10:37 0% ` Johannes Schindelin
2009-03-12 15:21 3% newb: Given a commit id, find which branches have it as an ancestor Kelly F. Hickel
2009-05-13 0:29 2% The 9th production of the msysGit Herald Johannes Schindelin
2009-05-13 5:31 0% ` [msysGit] " Frank Li
2009-05-29 18:41 Managing submodules on large multi-user projects R. Tyler Ballance
2009-05-29 19:53 ` Avery Pennarun
2009-05-29 20:09 4% ` R. Tyler Ballance
2009-05-29 20:18 4% ` Avery Pennarun
2009-06-02 14:49 git checkout -b -t John Tapsell
2009-06-02 15:25 4% ` Michael J Gruber
2009-06-09 15:52 5% git clone failing over slow links? skillzero
2009-06-09 17:12 0% ` Robin H. Johnson
2009-06-09 18:42 0% ` Nicolas Pitre
2009-06-09 18:55 0% ` Nicolas Pitre
2009-06-16 1:37 4% git diff looping? John Bito
2009-06-16 11:47 0% ` Jeff King
2009-06-16 15:48 0% ` John Bito
2010-04-03 11:02 3% Problem with git push on (somewhat) large binaries Tobi Stadelmaier
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).