* Re: Git on MSys
From: Johannes Schindelin @ 2007-08-03 15:43 UTC (permalink / raw)
To: Mike Pape; +Cc: git, Marius Storm-Olsen
In-Reply-To: <fd2562310708030837l7cc3bf1dx10297ad7a5109d2@mail.gmail.com>
Hi,
[Marius Cc'ed, because he reported the same issue]
On Fri, 3 Aug 2007, Mike Pape wrote:
> I'm not subscribed to the list, so I'm sorry I'm not continuing the
> existing thread. I've been hacking on git using a regular MSys
> install but tried the new "all in one" installer. It compiles fine
> but hangs indefinitely on make install.
Yeah, sorry. I just realised that. Please hang on.
Ciao,
Dscho
^ permalink raw reply
* RE: Re: cvs2svn conversion directly to git ready for experimentation
From: Patwardhan, Rajesh @ 2007-08-03 16:42 UTC (permalink / raw)
To: Jon Smirl
Cc: Michael Haggerty, Martin Langhoff, Guilhem Bonnefille, git, users
In-Reply-To: <9e4733910708030841r31175efg4ea4ea41e852ab2@mail.gmail.com>
Thank you very much for the email.
Yes if the time for conversion can be brought down to 1/2 hour then it
would be really great.
We could do a automated cvs2svn everyday for testing and that way
maximum lag between cvs and test svn repo would be 1 day.
Please do let me know when available.
Regards,
Rajesh
-----Original Message-----
From: Jon Smirl [mailto:jonsmirl@gmail.com]
Sent: Friday, August 03, 2007 8:41 AM
To: Patwardhan, Rajesh
Cc: Michael Haggerty; Martin Langhoff; Guilhem Bonnefille;
git@vger.kernel.org; users@cvs2svn.tigris.org
Subject: Re: Re: cvs2svn conversion directly to git ready for
experimentation
On 8/3/07, Patwardhan, Rajesh <rajesh.patwardhan@etrade.com> wrote:
>
> Hello Michael,
> I will explain a scenario (we are passing thru this right now)
> 1) you have 10 years worth of cvs data.
> 2) We want to move to svn.
> 3) The repository move should be in such a way that the development
> does not get hampered for any 1 work day.
> 4) We have atleast 4 major modules in cvs which takes about 30 - 40
> hours each for conversion currently.
There are known ways (that haven't been implemented) to get the 40 hr
number down to 1/2 hour. Would that be a better approach than doing
incremental imports?
> 5) With increamental conversions we can do a few things ...
> A) Keep the downtime for hard cutoff minimal
> B) try out the svn move for other auxillary tools that are
> needed by the SCM process.
> C) Do some meaningful testing and validation with simulated
> live moves of changes from cvs to svn before the actual move on a day
> to day basis.
>
> Hopefuly this would substantiate the request \ need for increamental
> moves. Or if someone out there has a better suggestion for such
> scenario's please point me in the right direction.
>
> Regards,
> Rajesh
>
> -----Original Message-----
> From: Michael Haggerty [mailto:mhagger@alum.mit.edu]
> Sent: Friday, August 03, 2007 1:36 AM
> To: Martin Langhoff
> Cc: Guilhem Bonnefille; git@vger.kernel.org; users@cvs2svn.tigris.org
> Subject: Re: cvs2svn conversion directly to git ready for
> experimentation
>
> Martin Langhoff wrote:
> > Is there any way we can run tweak cvs2svn to run incrementals, even
> > if
>
> > not as fast as cvsps/git-cvsimport? The "do it remotely" part can be
> > worked around in most cases.
>
> I don't see any fundamental reason why not, but I think it would be a
> significant amount of work. There are two main issues:
>
> 1. With CVS, it is possible to change things retroactively, such as
> changing which version of a file is included in a tag, or adding a new
> file to a tag, or changing whether a file is text vs. binary. And
> many people copy and/or rename files within the CVS repository itself
> (to get around CVS's inability to rename a file). This makes it look
> like the file has *always* existed under the new name and *never*
> existed under the old name. An incremental conversion tool would have
> to look carefully for such changes and either handle them properly or
> complain loudly and abort.
>
> 2. cvs2svn uses a lot of repository-wide information to make decisions
> about how to group CVSItems into changesets, and a lot of these
> decisions are based on heuristics. Incremental conversion would
> require that the decisions made in one cvs2svn run are recorded and
> treated as unalterable in subsequent runs.
>
> This hasn't been a priority in the Subversion world, because, frankly,
> what reason would a person have to stick with CVS instead of switching
> to Subversion, given that (1) they are intentionally so similar in
> workflow, an (2) there is no significant competition from other
> centralized SCMs? But of course until the distributed SCM playing
> field has been thinned out a bit, people will probably be reluctant to
> commit to one or the other.
>
> I don't expect to have time to implement incremental conversions in
> cvs2svn in the near future. (I'd much rather work on output back ends
> to other distributed SCMs.) But if any volunteers step forward (hint,
> hint) I would be happy to help them get started and answer their
> questions. I think that cvs2svn is quite hackable now, so the
> learning curve is hopefully much less frightening than when I started
> on the project :-)
>
> Michael
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@cvs2svn.tigris.org
> For additional commands, e-mail: users-help@cvs2svn.tigris.org
>
> -
> 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
>
--
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply
* Re: Git on MSys (or how to make it easy for Windows users to compile git)
From: Johannes Schindelin @ 2007-08-03 16:46 UTC (permalink / raw)
To: Marius Storm-Olsen; +Cc: Dmitry Kakurin, git, Mike Pape
In-Reply-To: <46B34B0D.6030106@trolltech.com>
Hi,
On Fri, 3 Aug 2007, Marius Storm-Olsen wrote:
> 1) msys.bat still kills the previous window
> msys.bat needs to change from
> :startsh
> start sh --login -i
> exit
>
> to just
> :startsh
> sh --login -i
>
> (start <cmd> opens a new CMD window, and exit kills the current one)
Done.
> 2) If $HOME is set to the normal home directory of the user (which I
> have, but I doubt it's common)
> C:\Documents and Settings\<username>
> then you'll have problems with spaces in path, so the
> make install
> actually fails. So, next time you start msys.bat, it will try to do
> the installation step again. I don't think we have to care about that
> right now. The current setup work fine for now. I'll play around a bit
> with it, and we'll see.
I agree, it is much saner to install it to /bin. That should make
creating an installer for Git (the compiled one) easier, too.
> 3) When "Setting up git" the second time, it feels like the whole thing
> is hanging; have let it run for ~5min now without anything happening.
> Not sure what's going on here. It looks like git.exe was ran with any
> options, but that should not consume 100% CPU.. Hmm
Yep. I did not test the initial phase, and there is a serious bug in
setup_git_directory_gently() in origin/devel. I fixed that.
> 4) When using the install, I get
> marius@STORM /git
> $ git init
> warning: templates not found C:/msysGit/share/git-core/templates/
> Initialized empty Git repository in .git/
>
> Probably due to the "Setting up git" step not completing.
That is expected. Hooks are activated by chmod'ing them to executable.
AFAIK this concept is thoroughly broken by Windows. So I do not even
attempt to install the templates; otherwise all hooks would be blindly
activated (and you do not want that, trust me).
New installer is available and tagged 0.2.
Ciao,
Dscho
P.S.: I also uploaded the script I created to make the installer. It
assumes that you installed 7zip to C:\Program Files\7-Zip but is trivial
to adapt to your setup.
^ permalink raw reply
* Some ideas for StGIT
From: Pavel Roskin @ 2007-08-03 17:50 UTC (permalink / raw)
To: Catalin Marinas; +Cc: git
Hello!
I was recently disappointed to learn that one of the Linux drivers
(bcm43xx_mac80211, to be precise) switched from git to quilt. I asked
whether StGIT was considered, a discussion followed, and I think the key
points need to be shared with StGIT developers. I'll add some of my
ideas to the mix.
The main point in favor of quilt is that it allows to edit the patches
with the text editor. One can pop all patches, edit them and push the
all back.
I don't suggest that StGIT gives up on the git-based storage, but this
mode of operation could be implemented in two ways.
One is to have a command opposite to "export". It would read the files
that "export" produces, replacing the existing patches.
Another approach would be to reexamine the patch after "stg refresh -es"
and to apply it instead of the original patch. If the patch doesn't
apply, the options would be to discard the edits or to re-launch the
editor.
Next issue is that it should be possible to create a patch in one
operation. StGIT follows quilt too closely here in requiring "new" and
"refresh", instead of utilizing the advantage of the workflow that
allows immediate editing of the sources without any commands.
Basically, I want one command that:
1) shows user what was changed
2) allows user to name the patch
3) allows user to describe the patch
4) allows user to exclude files from the patch
5) doesn't require another command to put the changes to the patch
I think the most natural approach would be to enhance "stg new". I see
"stg new -s" is supposed to show the changes, but it's currently broken.
This is run in a clean StGIT repository with no patches:
$ stg new -s foo
Traceback (most recent call last):
File "/home/proski/bin/stg", line 43, in <module>
main()
File "home/proski/lib/python2.5/site-packages/stgit/main.py", line 284, in main
File "/usr/lib64/python2.5/new.py", line 82, in func
File "home/proski/lib/python2.5/site-packages/stgit/stack.py", line 842, in new_patch
File "home/proski/lib/python2.5/site-packages/stgit/stack.py", line 89, in edit_file
File "home/proski/lib/python2.5/site-packages/stgit/stack.py", line 461, in get_patch
File "home/proski/lib/python2.5/site-packages/stgit/stack.py", line 148, in __init__
File "/usr/lib64/python2.5/posixpath.py", line 60, in join
if b.startswith('/'):
AttributeError: 'NoneType' object has no attribute 'startswith'
Another backtrace in "stg new", also run in a clean StGIT repository with no patches:
$ EDITOR=true stg new todo
Invoking the editor: "true .stgitmsg.txt" ... done
$ stg export -np
Checking for changes in the working directory ... done
Traceback (most recent call last):
File "/home/proski/bin/stg", line 43, in <module>
main()
File "home/proski/lib/python2.5/site-packages/stgit/main.py", line 284, in main
File "home/proski/lib/python2.5/site-packages/stgit/commands/export.py", line 137, in func
AttributeError: 'NoneType' object has no attribute 'strip'
Finally, it would be great to have TLS support in the mail command.
Mercurial has it, and looking at their mail.py, it doesn't seem to be
much work.
--
Regards,
Pavel Roskin
^ permalink raw reply
* Re: Git on MSys (or how to make it easy for Windows users to compile git)
From: Marius Storm-Olsen @ 2007-08-03 17:53 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Dmitry Kakurin, git, Mike Pape
In-Reply-To: <Pine.LNX.4.64.0708031649480.14781@racer.site>
[-- Attachment #1: Type: text/plain, Size: 2216 bytes --]
Johannes Schindelin wrote:
> On Fri, 3 Aug 2007, Marius Storm-Olsen wrote:
>> 1) msys.bat still kills the previous window
>> (start <cmd> opens a new CMD window, and exit kills the current one)
> Done.
Works nicely now.
>> 2) If $HOME is set to the normal home directory of the user (which I
>> have, but I doubt it's common)
>> then you'll have problems with spaces in path, so the
>> make install
>
> I agree, it is much saner to install it to /bin. That should make
> creating an installer for Git (the compiled one) easier, too.
Perfect! All neatly packaged in c:\MSysGit\bin now :-)
>> 3) When "Setting up git" the second time, it feels like the whole thing
>> is hanging; have let it run for ~5min now without anything happening.
>> Not sure what's going on here. It looks like git.exe was ran with any
>> options, but that should not consume 100% CPU.. Hmm
>
> Yep. I did not test the initial phase, and there is a serious bug in
> setup_git_directory_gently() in origin/devel. I fixed that.
Yup, work now.
>> 4) When using the install, I get
>> marius@STORM /git
>> $ git init
>> warning: templates not found C:/msysGit/share/git-core/templates/
>> Initialized empty Git repository in .git/
>>
>> Probably due to the "Setting up git" step not completing.
>
> That is expected. Hooks are activated by chmod'ing them to executable.
> AFAIK this concept is thoroughly broken by Windows. So I do not even
> attempt to install the templates; otherwise all hooks would be blindly
> activated (and you do not want that, trust me).
Actually, the MinGW build uses NOEXECTEMPL to set a '.noexec' postfix to
the template files, so they are not executed, even with Windows
brokeness. ;-) So, you can safely copy them into
msysgit\shared\git-core\templates.
> P.S.: I also uploaded the script I created to make the installer. It
> assumes that you installed 7zip to C:\Program Files\7-Zip but is
> trivial to adapt to your setup.
Thnx! I guess I should become a member of the project then, so I can
upload packages when needed :-) (I already have a code.google.com
account 'mstormo', so you can add that user)
Later!
--
.marius
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 187 bytes --]
^ permalink raw reply
* Re: [PATCH] Add a --user option to git-config
From: Ramsay Jones @ 2007-08-02 19:44 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Johannes Schindelin, GIT Mailing-list
In-Reply-To: <7vzm1b3y3w.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>
>>> Yep, which is why I made it a synonym; git-gui uses the
>>> --global option, for example, and I'm confident that other
>>> (user) scripts use it too. The "future" I had in mind was
>>> something like 1 year down the road, but it could be longer
>>> (or forever) if necessary.
>> Please read my reply as "I vote against ever removing the --global
>> option".
>
> I would say with --system present, I do not see much point
> having the new alias --user either. Get used to it. It is
> global across the repositories you have control over.
>
OK
ATB,
Ramsay Jones
^ permalink raw reply
* Re: Some ideas for StGIT
From: Andy Parkins @ 2007-08-03 18:14 UTC (permalink / raw)
To: git; +Cc: Pavel Roskin, Catalin Marinas
In-Reply-To: <1186163410.26110.55.camel@dv>
On Friday 2007, August 03, Pavel Roskin wrote:
> I don't suggest that StGIT gives up on the git-based storage, but this
> mode of operation could be implemented in two ways.
git's shiny new git rebase -i has removed, for me, those times when I needed
stgit. Perhaps those who've move from git to quilt would try again when
1.5.3 is out with the magic that is "rebase -i".
Andy
--
Dr Andy Parkins, M Eng (hons), MIET
andyparkins@gmail.com
^ permalink raw reply
* Re: Git on MSys (or how to make it easy for Windows users to compile git)
From: Mike Pape @ 2007-08-03 18:33 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Marius Storm-Olsen, Dmitry Kakurin, git
In-Reply-To: <46B36B7F.8010008@trolltech.com>
> >> 3) When "Setting up git" the second time, it feels like the whole thing
> >> is hanging; have let it run for ~5min now without anything happening.
> >> Not sure what's going on here. It looks like git.exe was ran with any
> >> options, but that should not consume 100% CPU.. Hmm
> >
> > Yep. I did not test the initial phase, and there is a serious bug in
> > setup_git_directory_gently() in origin/devel. I fixed that.
>
> Yup, work now.
Works for me as well now. One catch is that at work, I'm behind a
firewall so git:// doesn't work for me. I have a packaged version
that adds curl and expat, enables them in the build, and then falls
back to http:// if git:// fails in /etc/profile. Is that something
you'd want up on code.google.com?
^ permalink raw reply
* Re: Git on MSys (or how to make it easy for Windows users to compile git)
From: Marius Storm-Olsen @ 2007-08-03 18:39 UTC (permalink / raw)
To: Mike Pape; +Cc: Johannes Schindelin, Dmitry Kakurin, git
In-Reply-To: <fd2562310708031133m72b43265n35277c360ef2ca7a@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1082 bytes --]
Mike Pape wrote:
>>>> 3) When "Setting up git" the second time, it feels like the whole thing
>>>> is hanging; have let it run for ~5min now without anything happening.
>>>> Not sure what's going on here. It looks like git.exe was ran with any
>>>> options, but that should not consume 100% CPU.. Hmm
>>> Yep. I did not test the initial phase, and there is a serious bug in
>>> setup_git_directory_gently() in origin/devel. I fixed that.
>> Yup, work now.
>
> Works for me as well now. One catch is that at work, I'm behind a
> firewall so git:// doesn't work for me. I have a packaged version
> that adds curl and expat, enables them in the build, and then falls
> back to http:// if git:// fails in /etc/profile. Is that something
> you'd want up on code.google.com?
Ooo, I'd like your built curl and expat libs in a zip, pretty please! :-)
Then we can add it to the package. The more complete MinGW port, the
better. Do you have anywhere you can put out such a zip, so I can get
ahold of it? You can mail me privately, if you'd like.
--
.marius
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 187 bytes --]
^ permalink raw reply
* Re: Git on MSys (or how to make it easy for Windows users to compile git)
From: Johannes Schindelin @ 2007-08-03 18:55 UTC (permalink / raw)
To: Marius Storm-Olsen; +Cc: Mike Pape, Dmitry Kakurin, git
In-Reply-To: <46B3764E.6090106@trolltech.com>
Hi,
On Fri, 3 Aug 2007, Marius Storm-Olsen wrote:
> Mike Pape wrote:
> >>>> 3) When "Setting up git" the second time, it feels like the whole thing
> >>>> is hanging; have let it run for ~5min now without anything happening.
> >>>> Not sure what's going on here. It looks like git.exe was ran with any
> >>>> options, but that should not consume 100% CPU.. Hmm
> >>> Yep. I did not test the initial phase, and there is a serious bug in
> >>> setup_git_directory_gently() in origin/devel. I fixed that.
> >> Yup, work now.
> >
> > Works for me as well now. One catch is that at work, I'm behind a
> > firewall so git:// doesn't work for me. I have a packaged version
> > that adds curl and expat, enables them in the build, and then falls
> > back to http:// if git:// fails in /etc/profile. Is that something
> > you'd want up on code.google.com?
>
> Ooo, I'd like your built curl and expat libs in a zip, pretty please! :-)
>
> Then we can add it to the package. The more complete MinGW port, the
> better. Do you have anywhere you can put out such a zip, so I can get
> ahold of it? You can mail me privately, if you'd like.
I already installed curl, didn't I?
Ciao,
Dscho
^ permalink raw reply
* Re: Git on MSys (or how to make it easy for Windows users to compile git)
From: Johannes Schindelin @ 2007-08-03 18:57 UTC (permalink / raw)
To: Mike Pape; +Cc: Marius Storm-Olsen, Dmitry Kakurin, git
In-Reply-To: <fd2562310708031133m72b43265n35277c360ef2ca7a@mail.gmail.com>
Hi,
On Fri, 3 Aug 2007, Mike Pape wrote:
> > >> 3) When "Setting up git" the second time, it feels like the whole thing
> > >> is hanging; have let it run for ~5min now without anything happening.
> > >> Not sure what's going on here. It looks like git.exe was ran with any
> > >> options, but that should not consume 100% CPU.. Hmm
> > >
> > > Yep. I did not test the initial phase, and there is a serious bug in
> > > setup_git_directory_gently() in origin/devel. I fixed that.
> >
> > Yup, work now.
>
> Works for me as well now. One catch is that at work, I'm behind a
> firewall so git:// doesn't work for me. I have a packaged version
> that adds curl and expat, enables them in the build, and then falls
> back to http:// if git:// fails in /etc/profile. Is that something
> you'd want up on code.google.com?
Hang on. Dmitry proposed opening a project on repo.or.cz, but I did not
think that it made sense. I am converted now.
I am in the middle of registering it.
Ciao,
Dscho
^ permalink raw reply
* Re: cvs2svn conversion directly to git ready for experimentation
From: Michael Haggerty @ 2007-08-03 18:58 UTC (permalink / raw)
To: Jon Smirl
Cc: Patwardhan, Rajesh, Martin Langhoff, Guilhem Bonnefille, git,
users
In-Reply-To: <9e4733910708030841r31175efg4ea4ea41e852ab2@mail.gmail.com>
[I set followup-to users@cvs2svn.tigris.org, since this has nothing to
do with git.]
Jon Smirl wrote:
> On 8/3/07, Patwardhan, Rajesh <rajesh.patwardhan@etrade.com> wrote:
>> Hello Michael,
>> I will explain a scenario (we are passing thru this right now)
>> 1) you have 10 years worth of cvs data.
>> 2) We want to move to svn.
>> 3) The repository move should be in such a way that the development does
>> not get hampered for any 1 work day.
>> 4) We have atleast 4 major modules in cvs which takes about 30 - 40
>> hours each for conversion currently.
>
> There are known ways (that haven't been implemented) to get the 40 hr
> number down to 1/2 hour. Would that be a better approach than doing
> incremental imports?
Jon, I would like very much to hear how you propose to get an 60-fold
speed increase in cvs2svn. I've never heard of any plausible way to
accomplish anything even close to this.
Please note that the user wants to convert to Subversion, not git. But
even converting to git, I don't think that such speeds are possible
without massive changes that would include processing everything in RAM
and switching large parts of cvs2svn from Python to a compiled language.
Michael
^ permalink raw reply
* Re: Git on MSys (or how to make it easy for Windows users to compile git)
From: Marius Storm-Olsen @ 2007-08-03 18:59 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Mike Pape, Dmitry Kakurin, git
In-Reply-To: <Pine.LNX.4.64.0708031954480.14781@racer.site>
[-- Attachment #1: Type: text/plain, Size: 885 bytes --]
Johannes Schindelin wrote:
> On Fri, 3 Aug 2007, Marius Storm-Olsen wrote:
>> Mike Pape wrote:
>>> Works for me as well now. One catch is that at work, I'm behind
>>> a firewall so git:// doesn't work for me. I have a packaged
>>> version that adds curl and expat, enables them in the build, and
>>> then falls back to http:// if git:// fails in /etc/profile. Is
>>> that something you'd want up on code.google.com?
>> Ooo, I'd like your built curl and expat libs in a zip, pretty
>> please! :-)
>>
>> Then we can add it to the package. The more complete MinGW port,
>> the better. Do you have anywhere you can put out such a zip, so I
>> can get ahold of it? You can mail me privately, if you'd like.
>
> I already installed curl, didn't I?
Ah, yes, you did.
However, we don't use it, due to Makefile's
NO_CURL=YesPlease
for MINGW builds.
--
.marius
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 187 bytes --]
^ permalink raw reply
* Re: Git on MSys (or how to make it easy for Windows users to compile git)
From: Mike Pape @ 2007-08-03 19:13 UTC (permalink / raw)
To: Marius Storm-Olsen; +Cc: Johannes Schindelin, Dmitry Kakurin, git
In-Reply-To: <46B37B09.1030808@trolltech.com>
On 8/3/07, Marius Storm-Olsen <marius@trolltech.com> wrote:
> Johannes Schindelin wrote:
> > On Fri, 3 Aug 2007, Marius Storm-Olsen wrote:
> >> Mike Pape wrote:
> >>> Works for me as well now. One catch is that at work, I'm behind
> >>> a firewall so git:// doesn't work for me. I have a packaged
> >>> version that adds curl and expat, enables them in the build, and
> >>> then falls back to http:// if git:// fails in /etc/profile. Is
> >>> that something you'd want up on code.google.com?
> >> Ooo, I'd like your built curl and expat libs in a zip, pretty
> >> please! :-)
> >>
> >> Then we can add it to the package. The more complete MinGW port,
> >> the better. Do you have anywhere you can put out such a zip, so I
> >> can get ahold of it? You can mail me privately, if you'd like.
> >
> > I already installed curl, didn't I?
>
> Ah, yes, you did.
> However, we don't use it, due to Makefile's
> NO_CURL=YesPlease
> for MINGW builds.
>
Was it in the latest version (0.2)? I didn't see it there. Either
way, I had to make a couple changes to the Makefile to get it to work
and also add expat (unless I somehow missed that too). Marius, do you
still want a zipped copy or do you have it already?
^ permalink raw reply
* Re: Git on MSys (or how to make it easy for Windows users to compile git)
From: Marius Storm-Olsen @ 2007-08-03 19:18 UTC (permalink / raw)
To: Mike Pape; +Cc: Johannes Schindelin, Dmitry Kakurin, git
In-Reply-To: <fd2562310708031213sabc4599m79166f52e78edde3@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 732 bytes --]
>>>> Then we can add it to the package. The more complete MinGW
>>>> port, the better. Do you have anywhere you can put out such a
>>>> zip, so I can get ahold of it? You can mail me privately, if
>>>> you'd like.
>>> I already installed curl, didn't I?
>> Ah, yes, you did. However, we don't use it, due to Makefile's
>> NO_CURL=YesPlease for MINGW builds.
>>
> Was it in the latest version (0.2)? I didn't see it there. Either
> way, I had to make a couple changes to the Makefile to get it to work
> and also add expat (unless I somehow missed that too). Marius, do
> you still want a zipped copy or do you have it already?
Yeah, curl is in there, but not expat, so we'd like that one, yes.
--
.marius
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 187 bytes --]
^ permalink raw reply
* Re: Shell script cleanups/style changes?
From: Uwe Kleine-König @ 2007-08-03 19:29 UTC (permalink / raw)
To: David Kastrup; +Cc: git
In-Reply-To: <86sl72j9vn.fsf@lola.quinscape.zz>
David Kastrup wrote:
> Robert Schiele <rschiele@gmail.com> writes:
>
> > On Thu, Aug 02, 2007 at 12:44:22PM +0200, David Kastrup wrote:
> >> ! logfile="${1#-?}"
> >
> > You can't do something like that on /bin/sh on many systems (for
> > instance Solaris).
>
> Sigh. It's in Posix.
Well Solaris is (kind of) Posix compliant---you need some extra effort
to get it into Posix "mode":
login@~ > uname -a
SunOS login 5.10 Generic_125100-10 sun4u sparc
login@~ > sh
$ set tralala
$ echo "${1#tra}"
lala
$ ^D
the "problem" here is, that my PATH includes /usr/xpg4/bin before
/usr/bin and that's non-standard (for Solaris). That is
/usr/xpg4/bin/sh is Posix compliant and /usr/bin/sh is compatible to
former versions of Solaris/SunOS and this one doesn't support these
substitutions:
login@~ > /usr/bin/sh
$ set tralala
$ echo "${1#tra}"
bad substitution
Having
login@~ > ls -l /bin
lrwxrwxrwx 1 root root 9 2006-07-03 09:29 /bin -> ./usr/bin
sadly the Solaris sh is used for shell scripts that use a shebang line
calling /bin/sh.
Best regards
Uwe
--
Uwe Kleine-König
http://www.google.com/search?q=5+choose+3
^ permalink raw reply
* Re: Git on MSys (or how to make it easy for Windows users to compile git)
From: Johannes Schindelin @ 2007-08-03 19:33 UTC (permalink / raw)
To: Mike Pape; +Cc: Marius Storm-Olsen, Dmitry Kakurin, git
In-Reply-To: <fd2562310708031213sabc4599m79166f52e78edde3@mail.gmail.com>
Hi,
On Fri, 3 Aug 2007, Mike Pape wrote:
> On 8/3/07, Marius Storm-Olsen <marius@trolltech.com> wrote:
> > Johannes Schindelin wrote:
> > > On Fri, 3 Aug 2007, Marius Storm-Olsen wrote:
> > >> Mike Pape wrote:
> > >>> Works for me as well now. One catch is that at work, I'm behind
> > >>> a firewall so git:// doesn't work for me. I have a packaged
> > >>> version that adds curl and expat, enables them in the build, and
> > >>> then falls back to http:// if git:// fails in /etc/profile. Is
> > >>> that something you'd want up on code.google.com?
> > >> Ooo, I'd like your built curl and expat libs in a zip, pretty
> > >> please! :-)
> > >>
> > >> Then we can add it to the package. The more complete MinGW port,
> > >> the better. Do you have anywhere you can put out such a zip, so I
> > >> can get ahold of it? You can mail me privately, if you'd like.
> > >
> > > I already installed curl, didn't I?
> >
> > Ah, yes, you did.
> > However, we don't use it, due to Makefile's
> > NO_CURL=YesPlease
> > for MINGW builds.
> >
>
> Was it in the latest version (0.2)? I didn't see it there. Either
> way, I had to make a couple changes to the Makefile to get it to work
> and also add expat (unless I somehow missed that too). Marius, do you
> still want a zipped copy or do you have it already?
Okay, I am really close to initialising the repository on
http://repo.or.cz/w/git/mingw/msysgit.git
now.
Everybody interested in contributing, please register as a user on
repo.or.cz and mail me your user name.
Ciao,
Dscho
^ permalink raw reply
* Re: Forcing rewrite of files in working tree
From: Linus Torvalds @ 2007-08-03 19:55 UTC (permalink / raw)
To: Andy Parkins; +Cc: git
In-Reply-To: <200708031345.47127.andyparkins@gmail.com>
On Fri, 3 Aug 2007, Andy Parkins wrote:
>
> I want to write a little recipe in a Makefile that ensures the $Id$ field in a
> series of text files is correct. In case it's relevant, I'm including a load
> of asciidoc files as subsections into one master file; each file has a $Id$
> field in the header, which very nicely prints out at the start of each
> section. However, the $Id$ field is only written on checkout (not on checkin
> for fairly obvious reasons). That means that for any files I've changed, the
> $Id$ is wrong. Before I generate output using ASCIIdoc I'd like to ensure
> the $Id$ is correct.
>
> How do I do it?
Something like
git read-tree HEAD
git checkout -f
should do it.
The read-tree basically invalidated the index, by forcing it to the HEAD
tree (and *without* doing a merge with the old index, so it doesn't get
any of the size/date/inode fields right). And at that point, git thinks
that all files are stale, so "git checkout -f" will force the checkout for
all of them.
I'm sure you can do it other ways too, but that's the "obvious" one.
Linus
^ permalink raw reply
* git shell scripts flaw wrt dirty env
From: Pierre Habouzit @ 2007-08-03 20:14 UTC (permalink / raw)
To: git
[-- Attachment #1: Type: text/plain, Size: 1285 bytes --]
I recently had an issue with git-rebase, and actually git-am, kind of
hard to track down. After some hassle to understand what was going on,
it happened that for an idiotic reason (me trying a fancy new login
manager for X that didn't cleansed environment before staring X) made
all my env dirty. In particular it had $resume (in small letters) set to
/dev/sda5, and git-am happens to use the very same variable, without
cleansing the environment.
I'm maybe completely out of luck, and that's the sole unsafe use of
variables in git shell scripts, but I don't think so, and maybe some
kind of failsafe could be used. A crude way is to call:
unset `env | cut -d= -f1 | grep -v [A-Z]`
at the beginning of every script, so that every lowercase-only
variables are unset, hence can be safely used. But it's completely
tasteless. Though, as it can really lead to _very_ odd bugs, well, I
just wanted to share the issue. For the curious, you can read on [0]
what the issue looked like for me...
[0] http://bugs.debian.org/cgi-bin/bugreport.cgi?msg=38;bug=435807#38
Cheers,
--
·O· Pierre Habouzit
··O madcoder@debian.org
OOO http://www.madism.org
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: cvs2svn conversion directly to git ready for experimentation
From: Jon Smirl @ 2007-08-03 20:16 UTC (permalink / raw)
To: Michael Haggerty
Cc: Patwardhan, Rajesh, Martin Langhoff, Guilhem Bonnefille, git,
users
In-Reply-To: <46B37ADB.8020103@alum.mit.edu>
On 8/3/07, Michael Haggerty <mhagger@alum.mit.edu> wrote:
> [I set followup-to users@cvs2svn.tigris.org, since this has nothing to
> do with git.]
>
> Jon Smirl wrote:
> > On 8/3/07, Patwardhan, Rajesh <rajesh.patwardhan@etrade.com> wrote:
> >> Hello Michael,
> >> I will explain a scenario (we are passing thru this right now)
> >> 1) you have 10 years worth of cvs data.
> >> 2) We want to move to svn.
> >> 3) The repository move should be in such a way that the development does
> >> not get hampered for any 1 work day.
> >> 4) We have atleast 4 major modules in cvs which takes about 30 - 40
> >> hours each for conversion currently.
> >
> > There are known ways (that haven't been implemented) to get the 40 hr
> > number down to 1/2 hour. Would that be a better approach than doing
> > incremental imports?
>
> Jon, I would like very much to hear how you propose to get an 60-fold
> speed increase in cvs2svn. I've never heard of any plausible way to
> accomplish anything even close to this.
>
> Please note that the user wants to convert to Subversion, not git. But
> even converting to git, I don't think that such speeds are possible
> without massive changes that would include processing everything in RAM
> and switching large parts of cvs2svn from Python to a compiled language.
Make a bulk importer for SVN like git-fastimport. I measured some SVN
imports and the bulk of the time was spent forking off SVN. Before
git-fast import it would have taken git two weeks to import Mozilla
CVS.
>
> Michael
>
>
--
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply
* Re: cvs2svn conversion directly to git ready for experimentation
From: Jon Smirl @ 2007-08-03 20:27 UTC (permalink / raw)
To: Michael Haggerty
Cc: Patwardhan, Rajesh, Martin Langhoff, Guilhem Bonnefille, git,
users
In-Reply-To: <9e4733910708031316x1b7d2a40n5d0298cedd6cf97c@mail.gmail.com>
On 8/3/07, Jon Smirl <jonsmirl@gmail.com> wrote:
> Make a bulk importer for SVN like git-fastimport. I measured some SVN
> imports and the bulk of the time was spent forking off SVN. Before
> git-fast import it would have taken git two weeks to import Mozilla
> CVS.
And add a CVS parser to cvs2svn. Use the one I posted or write it again.
Fork is not a very fast operation, millions of forks take a week to run.
In the cvs2git code I did there was one process running cvs2svn and it
parsed the CVS files internally. A second process ran git-fastimport.
Nothing else was forked.
When I first started we were forking both git and cvs. When I ran
oprofile on it 95% of the CPU time was being spent in the kernel.
Linus helped me figure out what was going on. It was the overhead of
page table copies associated with millions of forks that was taking so
long. The solution is to eliminate the forks.
My first try with forks for both cvs and git took about a week to
import Mozilla CVS. After all the forks were eliminated I could import
Mozilla CVS in four hours.
>
> >
> > Michael
> >
> >
>
>
> --
> Jon Smirl
> jonsmirl@gmail.com
>
--
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply
* RPMs for latest release
From: rdavid274 @ 2007-08-03 19:25 UTC (permalink / raw)
To: git
Hello,
Downloaded the 10 rpms necessary for a complete install however, there
is NO single rpm that is independent of the other rpms.
Every rpm that I have downloaded depends on at 1 other rpm to have been
already installed.
So, how does a newbie deal with this issue?
rdp
^ permalink raw reply
* Re: [PATCH] Add --show-touched option to show "diff --git" line when contents are unchanged
From: Junio C Hamano @ 2007-08-03 20:33 UTC (permalink / raw)
To: Johannes Schindelin
Cc: Steven Grimm, Jean-Fran?ois Veillette, Matthieu Moy, git
In-Reply-To: <Pine.LNX.4.64.0708031121000.14781@racer.site>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> But I'd really think that what should be done (if anything has to be done
> at all) is to introduce a config variable which triggers the same logic in
> git-diff as was introduced in 2b5f9a8c0cff511f2bb0833b1ee02645b79323f4.
Sorry, I don't follow at all. The diff toolchain works all
inside core without having to write a temporary index out, which
was the issue the commit you are quoting was about.
In any case, enough discussion. Here is an updated patch, which
I _could_ be pursuaded to consider for inclusion after v1.5.3
happens, if there are enough agreements and Acks.
-- >8 --
git-diff: --stat-unmatch
Traditionally, git-diff with the working tree files showed files
whose lstat(2) information did not match with what were recorded
in the index, even if the actual contents did not have any
differences. This squelches such output from git-diff by
default.
A new option, --stat-unmatch, is introduced to restore the
traditional behaviour. This is useful to see if you want to
know you have too many files you only touch(1)ed without
modifying. Having many such paths hurts performance, and you
can run "git-update-index --refresh" to update the lstat(2)
information recorded in the index in such a case.
The low level git-diff-files command is not affected.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
Documentation/git-diff.txt | 13 ++++++++++
builtin-diff.c | 13 ++++++++++
diff.c | 54 ++++++++++++++++++++++++++++++++++++++++++++
diff.h | 1 +
4 files changed, 81 insertions(+), 0 deletions(-)
diff --git a/Documentation/git-diff.txt b/Documentation/git-diff.txt
index b36e705..efdc65b 100644
--- a/Documentation/git-diff.txt
+++ b/Documentation/git-diff.txt
@@ -59,6 +59,19 @@ OPTIONS
-------
include::diff-options.txt[]
+--stat-unmatch::
+ Traditionally, `git-diff` with the working tree files
+ showed files whose `lstat(2)` information did not match
+ with what were recorded in the index, even if the actual
+ contents did not have any differences, but recent git
+ squelches such output. This option can be used to
+ restore the traditional behaviour. This is useful to
+ see if you want to know you have too many files you only
+ `touch(1)`ed without modifying. Having many such paths
+ hurts performance, and you can run `git-update-index
+ --refresh` to update the `lstat(2)` information recorded
+ in the index in such a case.
+
<path>...::
The <paths> parameters, when given, are used to limit
the diff to the named paths (you can give directory
diff --git a/builtin-diff.c b/builtin-diff.c
index b48121e..c8e137d 100644
--- a/builtin-diff.c
+++ b/builtin-diff.c
@@ -222,6 +222,7 @@ int cmd_diff(int argc, const char **argv, const char *prefix)
prefix = setup_git_directory_gently(&nongit);
git_config(git_diff_ui_config);
init_revisions(&rev, prefix);
+ rev.diffopt.skip_stat_unmatch = 1;
if (!setup_diff_no_index(&rev, argc, argv, nongit, prefix))
argc = 0;
@@ -338,5 +339,17 @@ int cmd_diff(int argc, const char **argv, const char *prefix)
ent, ents);
if (rev.diffopt.exit_with_status)
result = rev.diffopt.has_changes;
+
+ /*
+ * We do not actually do this here because 99% of the time
+ * the pager is in effect and this will not be shown, but
+ * you could if you wanted to.
+ *
+ * if (1 < rev.diffopt.skip_stat_unmatch)
+ * fprintf(stderr,
+ * "Squelched %d stat-only differences.\n",
+ * rev.diffopt.skip_stat_unmatch - 1);
+ *
+ */
return result;
}
diff --git a/diff.c b/diff.c
index a5fc56b..8c26e4d 100644
--- a/diff.c
+++ b/diff.c
@@ -2261,6 +2261,8 @@ int diff_opt_parse(struct diff_options *options, const char **av, int ac)
else if (!strcmp(arg, "--shortstat")) {
options->output_format |= DIFF_FORMAT_SHORTSTAT;
}
+ else if (!strcmp(arg, "--stat-unmatch"))
+ options->skip_stat_unmatch = 0;
else if (!prefixcmp(arg, "--stat")) {
char *end;
int width = options->stat_width;
@@ -3143,11 +3145,63 @@ static void diffcore_apply_filter(const char *filter)
*q = outq;
}
+static void diffcore_skip_stat_unmatch(struct diff_options *diffopt)
+{
+ int i;
+ struct diff_queue_struct *q = &diff_queued_diff;
+ struct diff_queue_struct outq;
+ outq.queue = NULL;
+ outq.nr = outq.alloc = 0;
+
+ for (i = 0; i < q->nr; i++) {
+ struct diff_filepair *p = q->queue[i];
+
+ /*
+ * 1. Entries that come from stat info dirtyness
+ * always have both sides (iow, not create/delete),
+ * one side of the object name is unknown, with
+ * the same mode and size. Keep the ones that
+ * do not match these criteria. They have real
+ * differences.
+ *
+ * 2. At this point, the file is known to be modified,
+ * with the same mode and size, and the object
+ * name of one side is unknown. Need to inspect
+ * the identical contents.
+ */
+ if (!DIFF_FILE_VALID(p->one) || /* (1) */
+ !DIFF_FILE_VALID(p->two) ||
+ (p->one->sha1_valid && p->two->sha1_valid) ||
+ (p->one->mode != p->two->mode) ||
+ diff_populate_filespec(p->one, 1) ||
+ diff_populate_filespec(p->two, 1) ||
+ (p->one->size != p->two->size) ||
+
+ diff_populate_filespec(p->one, 0) || /* (2) */
+ diff_populate_filespec(p->two, 0) ||
+ memcmp(p->one->data, p->two->data, p->one->size))
+ diff_q(&outq, p);
+ else {
+ /*
+ * The caller can subtract 1 from skip_stat_unmatch
+ * to determine how many paths were dirty only
+ * due to stat info mismatch.
+ */
+ diffopt->skip_stat_unmatch++;
+ diff_free_filepair(p);
+ }
+ }
+ free(q->queue);
+ *q = outq;
+}
+
void diffcore_std(struct diff_options *options)
{
if (options->quiet)
return;
+ if (options->skip_stat_unmatch && !options->find_copies_harder)
+ diffcore_skip_stat_unmatch(options);
if (options->break_opt != -1)
diffcore_break(options->break_opt);
if (options->detect_rename)
diff --git a/diff.h b/diff.h
index 9fd6d44..de21f8e 100644
--- a/diff.h
+++ b/diff.h
@@ -65,6 +65,7 @@ struct diff_options {
int context;
int break_opt;
int detect_rename;
+ int skip_stat_unmatch;
int line_termination;
int output_format;
int pickaxe_opts;
^ permalink raw reply related
* Re: RPMs for latest release
From: Junio C Hamano @ 2007-08-03 20:37 UTC (permalink / raw)
To: rdavid274; +Cc: git
In-Reply-To: <46B38125.9060805@centurytel.net>
rdavid274 <rdavid274@centurytel.net> writes:
> Every rpm that I have downloaded depends on at 1 other rpm to have
> been already installed.
>
> So, how does a newbie deal with this issue?
A newbie will probably learn how to use rpm to deal with this
issue, I would presume.
Sorry, I do not run rpm based distro myself, but I would imagine
"rpm -i" (if -i is the "install" subcommand, I dunno) would take
more than one package name on the command line to be told to
install all of them at once?
^ permalink raw reply
* bug in t3700-add.sh?
From: Nguyen Thai Ngoc Duy @ 2007-08-03 20:51 UTC (permalink / raw)
To: Git Mailing List, Johannes Sixt
Hi,
Running test 17, I got this output:
* expecting success:
git rm --cached -f file symlink &&
(
echo "100644 $(git hash-object -w stage1) 1 file"
echo "100755 $(git hash-object -w stage2) 2 file"
echo "100644 $(printf $s | git hash-object -w -t blob
--stdin) 1 symlink"
echo "120000 $(printf $s | git hash-object -w -t blob
--stdin) 2 symlink"
) | git update-index --index-info &&
git config core.filemode 0 &&
git config core.symlinks 0 &&
echo new > file &&
echo new > symlink &&
git add file symlink &&
git ls-files --stage | grep "^100755 .* 0 file$" &&
git ls-files --stage | grep "^120000 .* 0 symlink$"
rm 'file'
rm 'symlink'
printf: usage: printf [-v var] format [arguments]
printf: usage: printf [-v var] format [arguments]
100755 3e757656cf36eca53338e520d134963a44f793f8 0 file
120000 3e757656cf36eca53338e520d134963a44f793f8 0 symlink
* ok 17: git add with filemode=0, symlinks=0 prefers stage 2 over stage 1
I don't know if "printf $s" was intentional because $s was empty and
caused printf to print out help usage. I have feeling that there is
something wrong here. Anyone can clarify?
Johannes Sixt CC'd as he added this code.
--
Duy
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox