* 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: Jon Smirl @ 2007-08-03 15:41 UTC (permalink / raw)
To: Patwardhan, Rajesh
Cc: Michael Haggerty, Martin Langhoff, Guilhem Bonnefille, git, users
In-Reply-To: <0BB549C6E74E24409FB20B3B1D1B6644029461C0@ATL1EX11.corp.etradegrp.com>
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
* Git on MSys
From: Mike Pape @ 2007-08-03 15:37 UTC (permalink / raw)
To: git; +Cc: Johannes.Schindelin
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. When GIT-VERSION-GEN runs, it
tries to run 'git diff-index --name-only HEAD' with no .git directory
and that seems to not return. Doing the same operation (git
diff-index with no .git directory) errors and exits correctly in
cygwin. Should there be a check for .git or is the mingw branch
missing something from the main git branch?
Mike
Please cc me.
^ 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 15:34 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Dmitry Kakurin, git
In-Reply-To: <Pine.LNX.4.64.0708031434130.14781@racer.site>
[-- Attachment #1: Type: text/plain, Size: 1278 bytes --]
Johannes Schindelin wrote:
> Done. Please test.
Ok,
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)
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.
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
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.
--
.marius
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 187 bytes --]
^ permalink raw reply
* RE: Re: cvs2svn conversion directly to git ready for experimentation
From: Patwardhan, Rajesh @ 2007-08-03 14:35 UTC (permalink / raw)
To: Michael Haggerty, Martin Langhoff; +Cc: Guilhem Bonnefille, git, users
In-Reply-To: <46B2E8F3.30301@alum.mit.edu>
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.
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
^ permalink raw reply
* Re: Forcing rewrite of files in working tree
From: Andy Parkins @ 2007-08-03 13:39 UTC (permalink / raw)
To: git; +Cc: Rogan Dawes
In-Reply-To: <46B3268C.7060707@dawes.za.net>
On Friday 2007 August 03, Rogan Dawes wrote:
> > The only method I've found is to delete the file in the work tree then do
> > git-checkout again. Even with -f, if the file is not changed git doesn't
> > perform a checkout again, so git-checkout -f is not sufficient. I assume
> > I can do what I want with some clever plumbing, but I don't know any
> > plumbing. :-)
>
> $ git reset --hard
I think that that suffers the same as "git-checkout -f"; if it doesn't see
changes then it doesn't reread. Also, it's not possible to do per-file:
$ git reset --hard HEAD somefile.txt
Cannot do partial --hard reset.
Which is a necessity really; I don't want to accidentally overwrite work
that's not yet checked in in the rest of the tree.
Is git-checkout-index the thing I'm looking for? I'm wondering if the "-n"
switch is the trick?
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: Johannes Schindelin @ 2007-08-03 13:37 UTC (permalink / raw)
To: Marius Storm-Olsen; +Cc: Dmitry Kakurin, git
In-Reply-To: <46B32981.9040904@trolltech.com>
Hi,
On Fri, 3 Aug 2007, Marius Storm-Olsen wrote:
> > > Completely forgot: we might want to do something like this at the end of
> > > /etc/profile:
> > >
> > > test ! -d /git || {
> > > mv /git $HOME/ &&
> > > cd $HOME/git &&
> > > make install &&
> > > git config remote.origin.url \
> > > git://repo.or.cz/git/mingw.git
> > > git config remote.origin.fetch \
> > > '+refs/heads/*:refs/remotes/origin/*'
> > > git config remote.mob.url \
> > > repo.or.cz:/srv/git/git/mingw.git
> > > git config remote.mob.fetch \
> > > +refs/remote/mob:refs/remotes/origin/mob
> > > git config remote.mob.push \
> > > master:mob
> > > git fetch
> > > git reset 51785010a4d3e7f6c3
> > > }
> > >
> > > Please test that, and include it if it works.
>
> Hmmm, I have trouble 'parsing' this.
> You meant
> test ! -d $HOME/git ||
> right?
>
> But, given that he removed the initial git sources, the script won't work. He
> left the git executables to be able to check a new Git out, if I understand
> correctly.
I ended up doing it differently. I test for $HOME/bin/git.exe, and if it
does not exist, the whole compiling && installing && fetching is done.
Actually, I found out by debugging why it did not work as intended that
commit 5178501 was a commit _I_ made, from experimental patches Hannes
sent to the list.
I updated it to origin/devel + patches.
Hopefully these patches will be cleaned up, and submitted to Hannes (hint,
hint).
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 13:34 UTC (permalink / raw)
To: Marius Storm-Olsen; +Cc: Dmitry Kakurin, git
In-Reply-To: <46B32C8D.4060804@trolltech.com>
Hi,
On Fri, 3 Aug 2007, Marius Storm-Olsen wrote:
> Johannes Schindelin said the following on 03.08.2007 15:18:
>
> > Okay, tell you what: I'll let msys.bat start a cmd, and
> > msys-rxvt.bat start an rxvt. Deal?
>
> Sound good to me!
Done. Please test.
Ciao,
Dscho
^ 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 13:24 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Dmitry Kakurin, git
In-Reply-To: <Pine.LNX.4.64.0708031411360.14781@racer.site>
[-- Attachment #1: Type: text/plain, Size: 997 bytes --]
Johannes Schindelin said the following on 03.08.2007 15:18:
>> Normally, people would probably like to stay in their current
>> environment/window. Let's say you're doing something in a cmd
>> windows, then you want to go and compile git. If you run
>> msys.bat, it will kill your current window, and show a rxvt
>> window instead. That's kinda not nice really.
>>
>> If you enable the QuickEdit in the 'CMD' window, you mark with
>> mouse, the right-click to copy, then right-click again to paste.
>> No need to move your hand and hit Enter/Return. (Many people
>> don't know about the right-click to copy, but it's a much better
>> work-flow)
>>
>> You can do all the changes (like changing the scrollback size and
>> edit mode) once, then store it, never to change it again.
>
> Thanks for that good point (staying in your window).
>
> Okay, tell you what: I'll let msys.bat start a cmd, and
> msys-rxvt.bat start an rxvt. Deal?
Sound good to me!
--
.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 13:18 UTC (permalink / raw)
To: Marius Storm-Olsen; +Cc: Dmitry Kakurin, git
In-Reply-To: <46B328EA.4030309@trolltech.com>
Hi,
On Fri, 3 Aug 2007, Marius Storm-Olsen wrote:
> Johannes Schindelin said the following on 03.08.2007 14:37:
> > On Fri, 3 Aug 2007, Dmitry Kakurin wrote:
> > > The changes that I've made:
> > > * removed .git in /git directory to save space
> > > * installed gdb
> > > * applied my Vista fix
> > > * made self-extracting .rar archive
> >
> > * replace rxvt by that stupid cmd window
> > Sneaky.
> > Can you defend the choice?
> > FWIW here are my arguments for rxvt:
> >
> > - it behaves the same on all Windows versions
> > - it has a scroll back (which you have to activate on cmd first)
> > - it is resizable
> > - it has sane copy&paste behaviour (which you have to activate on
> > cmd first, and then still have to hit the Return key after having
> > selected some text)
>
> Normally, people would probably like to stay in their current
> environment/window. Let's say you're doing something in a cmd windows, then
> you want to go and compile git. If you run msys.bat, it will kill your current
> window, and show a rxvt window instead. That's kinda not nice really.
>
> If you enable the QuickEdit in the 'CMD' window, you mark with mouse, the
> right-click to copy, then right-click again to paste. No need to move your
> hand and hit Enter/Return. (Many people don't know about the right-click to
> copy, but it's a much better work-flow)
>
> You can do all the changes (like changing the scrollback size and edit mode)
> once, then store it, never to change it again.
Thanks for that good point (staying in your window).
Okay, tell you what: I'll let msys.bat start a cmd, and msys-rxvt.bat
start an rxvt. Deal?
Ciao,
Dscho
^ 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 13:11 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Dmitry Kakurin, git
In-Reply-To: <Pine.LNX.4.64.0708031347160.14781@racer.site>
[-- Attachment #1: Type: text/plain, Size: 954 bytes --]
>> Completely forgot: we might want to do something like this at the end of
>> /etc/profile:
>>
>> test ! -d /git || {
>> mv /git $HOME/ &&
>> cd $HOME/git &&
>> make install &&
>> git config remote.origin.url \
>> git://repo.or.cz/git/mingw.git
>> git config remote.origin.fetch \
>> '+refs/heads/*:refs/remotes/origin/*'
>> git config remote.mob.url \
>> repo.or.cz:/srv/git/git/mingw.git
>> git config remote.mob.fetch \
>> +refs/remote/mob:refs/remotes/origin/mob
>> git config remote.mob.push \
>> master:mob
>> git fetch
>> git reset 51785010a4d3e7f6c3
>> }
>>
>> Please test that, and include it if it works.
Hmmm, I have trouble 'parsing' this.
You meant
test ! -d $HOME/git ||
right?
But, given that he removed the initial git sources, the script won't
work. He left the git executables to be able to check a new Git out,
if I understand correctly.
--
.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: Marius Storm-Olsen @ 2007-08-03 13:08 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Dmitry Kakurin, git
In-Reply-To: <Pine.LNX.4.64.0708031334530.14781@racer.site>
[-- Attachment #1: Type: text/plain, Size: 1437 bytes --]
Johannes Schindelin said the following on 03.08.2007 14:37:
> On Fri, 3 Aug 2007, Dmitry Kakurin wrote:
>> The changes that I've made:
>> * removed .git in /git directory to save space
>> * installed gdb
>> * applied my Vista fix
>> * made self-extracting .rar archive
>
> * replace rxvt by that stupid cmd window
> Sneaky.
> Can you defend the choice?
> FWIW here are my arguments for rxvt:
>
> - it behaves the same on all Windows versions
> - it has a scroll back (which you have to activate on cmd first)
> - it is resizable
> - it has sane copy&paste behaviour (which you have to activate on
> cmd first, and then still have to hit the Return key after
> having selected some text)
Normally, people would probably like to stay in their current
environment/window. Let's say you're doing something in a cmd windows,
then you want to go and compile git. If you run msys.bat, it will kill
your current window, and show a rxvt window instead. That's kinda not
nice really.
If you enable the QuickEdit in the 'CMD' window, you mark with mouse,
the right-click to copy, then right-click again to paste. No need to
move your hand and hit Enter/Return. (Many people don't know about the
right-click to copy, but it's a much better work-flow)
You can do all the changes (like changing the scrollback size and edit
mode) once, then store it, never to change it again.
--
.marius
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 187 bytes --]
^ permalink raw reply
* Re: Forcing rewrite of files in working tree
From: Rogan Dawes @ 2007-08-03 12:58 UTC (permalink / raw)
To: Andy Parkins; +Cc: git
In-Reply-To: <200708031345.47127.andyparkins@gmail.com>
Andy Parkins wrote:
> Hello,
>
> 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?
>
> The only method I've found is to delete the file in the work tree then do
> git-checkout again. Even with -f, if the file is not changed git doesn't
> perform a checkout again, so git-checkout -f is not sufficient. I assume I
> can do what I want with some clever plumbing, but I don't know any
> plumbing. :-)
>
> Andy
$ git reset --hard
?
Rogan
^ permalink raw reply
* Re: [PATCH] user-manual: mention git gui citool (commit, amend)
From: J. Bruce Fields @ 2007-08-03 12:58 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Steffen Prohaska, git
In-Reply-To: <20070803030459.GJ20052@spearce.org>
On Thu, Aug 02, 2007 at 11:04:59PM -0400, Shawn O. Pearce wrote:
> Online help? In git-gui? :-)
>
> We don't have an online help system yet. Basically no documentation
> has been written for git-gui. No thought has been put into how one
> should be organized, maintained, or displayed to the poor human
> who is just trying to learn more about Git and this gui thing it
> came with.
>
> Yes, Help->Online Documentation is abvailable to most users, but
> that just opens your web browser (if it can find one) and points
> it to kernel.org's git manual. Not exactly the best material for
> learning more about git-gui itself.
Fair enough.
Though I'd like to keep the main body of the manual focused on the major
command line tools, I'd have no objection to a separate chapter (or
appendix?) devoted to git-gui; then you could point directly at that.
Would that make sense?
--b.
^ permalink raw reply
* Re: [PATCH] user-manual: mention git gui citool (commit, amend)
From: J. Bruce Fields @ 2007-08-03 12:56 UTC (permalink / raw)
To: Steffen Prohaska; +Cc: git
In-Reply-To: <B14C42A6-F4BD-40D7-AEAF-66FFF492AB9B@zib.de>
On Fri, Aug 03, 2007 at 07:08:44AM +0200, Steffen Prohaska wrote:
>
> On Aug 3, 2007, at 12:31 AM, J. Bruce Fields wrote:
>
>>>> Also, I like the verb "stage" as a way to explain the part of the index
>>>> file in creating commits, but I've been consistently using the word
>>>> "index" throughout the user manual, and I think that's consistent with
>>>> the rest of the documentation--so don't avoid it here.
>>>
>>> "staging/unstaging" is how git gui calls adding/removing files to and
>>> from the index.
>>
>> I understand what you meant, but a reader of the user manual at this
>> point might not, since it's been consistently saying things like "to add
>> the contents of a new file to the index, use git add". So we should use
>> the same language here. Unless we want to update the whole thing to use
>> "stage" and "unstage". I'd rather not.
>
> Agree. But we could briefly introduce git gui's dialect, something like
>
> "git gui lets you select files (use menu 'Commit > Stage to Commit') or
> individually diff hunks (use 'Stage Hunk For Commit' in context menu of
> diff view) for inclusion in the index."
Sounds good to me. Somebody do that!
--b.
^ permalink raw reply
* Re: [PATCH] user-manual: mention git gui citool (commit, amend)
From: J. Bruce Fields @ 2007-08-03 12:56 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Steffen Prohaska, git
In-Reply-To: <20070803030101.GI20052@spearce.org>
On Thu, Aug 02, 2007 at 11:01:01PM -0400, Shawn O. Pearce wrote:
> Steffen, you seem to be more in-tune with the Mac UI standards
> than I am. Any suggestions on what I can do in git-gui to make
> this feature more obvious to users?
>
> I myself use a Mac OS X based PowerBook as my primary development
> system, but I have to admit, I'm not the best GUI developer that has
> ever walked on this planet. Far far far from it.
You're way ahead of me!
> So I'd really love to do better. But frankly I'm at a loss here
> and just don't know what sort of change to make.
The one thing that struck me when I fired up git-gui was that it wasn't
obvious to me which things I should try clicking on.
For example: the buttons, drop-down menus, and check-boxes all cry out
to be played with. But the filenames in the lists at the top are less
obvious, and it might never have occurred to me on my own to right-click
on the diff hunks at the bottom. That just looks like passive colorized
text to me.
I don't know what sort of user-interface conventions say "play with
me!", though. Random ideas:
- maybe the cursor should change shape over the diff hunks (or
just the headers?)
- maybe buttons, hunk headers, file names, etc., should all be
in the same color?
- maybe the hunk headers could benefit from a little more
decoration? I don't know how to do that without just making
the display look more cluttered, though.
- maybe left-clicking on diff hunks should do something too?
I dunno.
--b.
^ 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 12:47 UTC (permalink / raw)
To: Dmitry Kakurin; +Cc: Marius Storm-Olsen, git
In-Reply-To: <Pine.LNX.4.64.0708031243330.14781@racer.site>
Hi,
On Fri, 3 Aug 2007, Johannes Schindelin wrote:
> Completely forgot: we might want to do something like this at the end of
> /etc/profile:
>
> test ! -d /git || {
> mv /git $HOME/ &&
> cd $HOME/git &&
> make install &&
> git config remote.origin.url \
> git://repo.or.cz/git/mingw.git
> git config remote.origin.fetch \
> '+refs/heads/*:refs/remotes/origin/*'
> git config remote.mob.url \
> repo.or.cz:/srv/git/git/mingw.git
> git config remote.mob.fetch \
> +refs/remote/mob:refs/remotes/origin/mob
> git config remote.mob.push \
> master:mob
> git fetch
> git reset 51785010a4d3e7f6c3
> }
>
> Please test that, and include it if it works.
Oh well, I downloaded your archive, and making the adjustments right now.
Ciao,
Dscho
^ permalink raw reply
* Forcing rewrite of files in working tree
From: Andy Parkins @ 2007-08-03 12:45 UTC (permalink / raw)
To: git
Hello,
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?
The only method I've found is to delete the file in the work tree then do
git-checkout again. Even with -f, if the file is not changed git doesn't
perform a checkout again, so git-checkout -f is not sufficient. I assume I
can do what I want with some clever plumbing, but I don't know any
plumbing. :-)
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: Johannes Schindelin @ 2007-08-03 12:37 UTC (permalink / raw)
To: Dmitry Kakurin; +Cc: Marius Storm-Olsen, git
In-Reply-To: <a1bbc6950708030258h16a6514kf5c637af13874fb7@mail.gmail.com>
Hi,
On Fri, 3 Aug 2007, Dmitry Kakurin wrote:
> The changes that I've made:
> * removed .git in /git directory to save space
> * installed gdb
> * applied my Vista fix
> * made self-extracting .rar archive
* replace rxvt by that stupid cmd window
Sneaky.
Can you defend the choice?
FWIW here are my arguments for rxvt:
- it behaves the same on all Windows versions
- it has a scroll back (which you have to activate on cmd first)
- it is resizable
- it has sane copy&paste behaviour (which you have to activate on
cmd first, and then still have to hit the Return key after
having selected some text)
Ciao,
Dscho
^ 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 12:32 UTC (permalink / raw)
To: Nguyen Thai Ngoc Duy; +Cc: Johannes Schindelin, git
In-Reply-To: <fcaeb9bf0708030514n7f1c4fecqf7c850d216d0583@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 384 bytes --]
Nguyen Thai Ngoc Duy said the following on 03.08.2007 14:14:
>> I would definitely be interested in your config.mak file!
>
> Rename the attached file config.mak and you can "make" right away
> without running configure. You still need to set CFLAGS and LDFLAGS
> to specify location of zlib.h and libz.a though.
Excellent, I'll give that a try.
Thanks!
--
.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: Nguyen Thai Ngoc Duy @ 2007-08-03 12:14 UTC (permalink / raw)
To: Marius Storm-Olsen; +Cc: Johannes Schindelin, git
In-Reply-To: <46B314E6.8030806@trolltech.com>
[-- Attachment #1: Type: text/plain, Size: 1077 bytes --]
[CC'd to git ML so that if anyone needs it again, google might help]
On 8/3/07, Marius Storm-Olsen <marius@trolltech.com> wrote:
> >>> Even if it installs ok under Wine, git may not work properly
> >>> because a bug in dup2() not duplicating to 0-2 and some others
> >>> that I think only affect tests. So get XP if you can or prepare
> >>> to fix Wine along the way.
> >> Yeah, I wasn't going to use it under Wine actually. Just wanted
> >> to see if I could get it building there, to ease automated
> >> packaging later. However, I've given up on it, due to a perl
> >> issue, which might be caused by the issue you describe.
> >
> > You could cross-compile it. You'll need a cross toolchain, zlib
> > stuff and a good config.mak (I can send you one if you have trouble
> > with it).
>
> I would definitely be interested in your config.mak file!
Rename the attached file config.mak and you can "make" right away
without running configure. You still need to set CFLAGS and LDFLAGS to
specify location of zlib.h and libz.a though.
> Thanks!
>
> --
> .marius
>
>
>
--
Duy
[-- Attachment #2: config.mak --]
[-- Type: application/octet-stream, Size: 1608 bytes --]
# git Makefile configuration, included in main Makefile
# config.mak.autogen. Generated from config.mak.in config.mak.append by configure.
CC = mingw32-gcc
CFLAGS = -g -O2
AR = mingw32-ar
TAR = tar
#INSTALL = @INSTALL@ # needs install-sh or install.sh in sources
TCLTK_PATH = wish
prefix = /usr/local
exec_prefix = ${prefix}
bindir = ${exec_prefix}/bin
#gitexecdir = ${exec_prefix}/libexec/git-core/
datarootdir = ${prefix}/share
template_dir = ${datarootdir}/git-core/templates/
mandir=${datarootdir}/man
srcdir = .
export exec_prefix mandir
export srcdir VPATH
NO_MMAP=YesPlease
NO_PREAD=YesPlease
NO_OPENSSL=YesPlease
NO_CURL=YesPlease
NO_SYMLINK_HEAD=YesPlease
NO_IPV6=YesPlease
NO_ETC_PASSWD=YesPlease
NO_SETENV=YesPlease
NO_UNSETENV=YesPlease
NO_STRCASESTR=YesPlease
NO_STRLCPY=YesPlease
NO_ICONV=YesPlease
NO_C99_FORMAT = YesPlease
NO_STRTOUMAX = YesPlease
NO_SYMLINKS=YesPlease
NO_SVN_TESTS=YesPlease
COMPAT_CFLAGS += -DNO_ETC_PASSWD -DNO_ST_BLOCKS -DSTRIP_EXTENSION=\".exe\" -I compat
COMPAT_OBJS += compat/mingw.o compat/fnmatch.o compat/regex.o
EXTLIBS += -lws2_32
X = .exe
NOEXECTEMPL = .noexec
template_dir = ../share/git-core/templates/
ETC_GITCONFIG = ../etc/gitconfig
SCRIPT_SH += cpio.sh
NEEDS_SSL_WITH_CRYPTO=
NO_OPENSSL=YesPlease
NO_CURL=YesPlease
NO_EXPAT=YesPlease
NEEDS_LIBICONV=
NEEDS_SOCKET=
SHELL_PATH=/bin/sh
NO_PERL_MAKEMAKER=
NO_D_INO_IN_DIRENT=
NO_D_TYPE_IN_DIRENT=YesPlease
NO_SOCKADDR_STORAGE=
NO_IPV6=YesPlease
NO_C99_FORMAT=YesPlease
NO_STRCASESTR=YesPlease
NO_STRLCPY=YesPlease
NO_SETENV=YesPlease
NO_ICONV=YesPlease
# config.mak.append. Generated by configure.
^ 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 11:59 UTC (permalink / raw)
To: Nguyen Thai Ngoc Duy; +Cc: Marius Storm-Olsen, git
In-Reply-To: <fcaeb9bf0708030448id1d961dv58264da335526aad@mail.gmail.com>
Hi,
On Fri, 3 Aug 2007, Nguyen Thai Ngoc Duy wrote:
> I attached what I did with Wine until now. You probably only need patch
> 2 but if you are going to test gitbox, you'll need patch 1 as well. It
> is based on wine-0.9.41-313-gd0b21ab. With these patches, I can run git
> tests under Wine.
Thank you very much!
Once the compile finished (my machine is exquisitely slow today), I'll
test if it Works For Me.
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 11:50 UTC (permalink / raw)
To: Dmitry Kakurin; +Cc: Marius Storm-Olsen, git
In-Reply-To: <a1bbc6950708030258h16a6514kf5c637af13874fb7@mail.gmail.com>
Hi,
On Fri, 3 Aug 2007, Dmitry Kakurin wrote:
> The changes that I've made:
> * removed .git in /git directory to save space
> * installed gdb
> * applied my Vista fix
> * made self-extracting .rar archive
Completely forgot: we might want to do something like this at the end of
/etc/profile:
test ! -d /git || {
mv /git $HOME/ &&
cd $HOME/git &&
make install &&
git config remote.origin.url \
git://repo.or.cz/git/mingw.git
git config remote.origin.fetch \
'+refs/heads/*:refs/remotes/origin/*'
git config remote.mob.url \
repo.or.cz:/srv/git/git/mingw.git
git config remote.mob.fetch \
+refs/remote/mob:refs/remotes/origin/mob
git config remote.mob.push \
master:mob
git fetch
git reset 51785010a4d3e7f6c3
}
Please test that, and include it if it works.
It would be a bit easier if perl would work (it is installed, but for some
reason (cd perl && make) does not do its job).
Ciao,
Dscho
^ permalink raw reply
* Re: Git on MSys (or how to make it easy for Windows users to compile git)
From: Nguyen Thai Ngoc Duy @ 2007-08-03 11:48 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Marius Storm-Olsen, git
In-Reply-To: <Pine.LNX.4.64.0708031224530.14781@racer.site>
[-- Attachment #1: Type: text/plain, Size: 1999 bytes --]
On 8/3/07, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> Hi,
>
> On Fri, 3 Aug 2007, Nguyen Thai Ngoc Duy wrote:
>
> > On 8/3/07, Marius Storm-Olsen <marius@trolltech.com> wrote:
> > > > I finally broke down, waiting for the sourceforge project to get
> > > > granted. In the meantime, I registered a project at
> > > >
> > > > http://code.google.com/p/msysgit/
> > > >
> > > > (WARNING: temporary only!)
> > > >
> > > > Would you believe that Google code has a restriction to 20MB per
> > > > file, and 100MB in total, and you cannot remove files? The same
> > > > Google that gives you 1TB mail space and counting? Yes, it is
> > > > ludicrous.
> > > >
> > > > Anyway, you can get a complete Development environment in 3 files
> > > > (because one would be too large), and... oh well, just read what is
> > > > written on the website if you're really interested.
> > >
> > > Great effort Johannes!
> > > The package work perfectly on XP.
> > > I'm trying to get it to work under Wine, but it (Wine) is not playing
> > > nice with me at the moment. (The whole system barfs of "Access Denied"
> > > and other things. Grrr)
> >
> > Even if it installs ok under Wine, git may not work properly because a
> > bug in dup2() not duplicating to 0-2 and some others that I think only
> > affect tests. So get XP if you can or prepare to fix Wine along the
> > way.
>
> I do not have XP. So I very much would appreciate any work done on Wine.
>
> As it happens, I have a hanging rxvt now (still investigating what causes
> it; ever since wine-0.9.30-466-gb0e9d7e it stopped working for me).
I attached what I did with Wine until now. You probably only need
patch 2 but if you are going to test gitbox, you'll need patch 1 as
well. It is based on wine-0.9.41-313-gd0b21ab. With these patches, I
can run git tests under Wine.
Ah, and if you want to run tests under Wine, beware that setting TZ in
scripts has no effect. You have to set TZ before running wine.
>
> Ciao,
> Dscho
>
>
--
Duy
[-- Attachment #2: wine-for-git.tar.gz --]
[-- Type: application/x-gzip, Size: 1393 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 11:43 UTC (permalink / raw)
To: Dmitry Kakurin; +Cc: Marius Storm-Olsen, git
In-Reply-To: <a1bbc6950708030258h16a6514kf5c637af13874fb7@mail.gmail.com>
Hi,
On Fri, 3 Aug 2007, Dmitry Kakurin wrote:
> Johannes, please add me as a user to this Google project and I'll
> upload the files.
Done.
> The changes that I've made:
> * removed .git in /git directory to save space
> * installed gdb
> * applied my Vista fix
> * made self-extracting .rar archive
>
> Tatal size is 19+4 MB.
With Vista fix you mean both adding the USE_MINGW_ACCESS define and
copying cc1.exe to /bin?
And have you tried a 7-zip LZMA self extracting file? I guess it is
smaller: for the moment I have two files there, totalling 30.2M. 15M of
which is the virtually uncompressible pack file in .git/. Which leaves...
Ciao,
Dscho
^ 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