* RE: Switching from CVS to GIT
From: Dave Korn @ 2007-10-14 22:59 UTC (permalink / raw)
To: 'Alex Riesen', 'Johannes Schindelin'
Cc: 'Andreas Ericsson', 'Make Windows',
'git list'
In-Reply-To: <20071014221446.GC2776@steel.home>
On 14 October 2007 23:15, Alex Riesen wrote:
> Interprocess communication:
>
> - no reliable text environment (I'm programming in the damn thing for
> 10 years and I still don't know how to pass an environment variable
> _for_sure_)
>
> - it has only one argument (limited in size) passed to started
> programs, which means that there is no possible way to safely pass
> file and text arguments on command line (more than one, that is)
Whuh?
http://msdn2.microsoft.com/en-us/library/y5zz48s1(VS.80).aspx
cheers,
DaveK
--
Can't think of a witty .sigline today....
^ permalink raw reply
* git-svn and submodules, was Re: [PATCH] parse-options: Allow abbreviated options when unambiguous
From: Johannes Schindelin @ 2007-10-14 22:59 UTC (permalink / raw)
To: Eric Wong; +Cc: Pierre Habouzit, git
In-Reply-To: <20071014224959.GA17828@untitled>
Hi,
On Sun, 14 Oct 2007, Eric Wong wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
>
> > While I have your attention: last weekend, I spoke to a guy from the
> > ffmpeg project, and he said that the only thing preventing them from
> > switching to git was the lack of svn:external support...
> >
> > (Of course I know that it is more difficult than that: ffmpeg itself
> > is an svn:external of MPlayer, but maybe we can get both of them to
> > switch ;-)
> >
> > Do you have any idea when/if you're coming around to add that to
> > git-svn?
>
> Soonish, possibly within a next week, even. I have actually have
> started a project (using git) that wants to use SVN-hosted repositories
> directly submodules; so the fact that I'll actually need something like
> it bodes well for getting it implemented :)
Hehe. Thanks!
Ciao,
Dscho
^ permalink raw reply
* Re: Switching from CVS to GIT
From: Johannes Schindelin @ 2007-10-14 23:45 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: Alex Riesen, ae, tsuna, git, make-w32
In-Reply-To: <u7ilpjp3x.fsf@gnu.org>
Hi,
On Mon, 15 Oct 2007, Eli Zaretskii wrote:
> Alex Riesen said:
>
> > - no proper VFS
>
> I'm not sure what you are talking about. What VFS do you use on
> GNU/Linux that cannot work on Windows, and why do you use it?
The problem is that on Windows, you cannot keep a file open and delete it
at the same time. This is an issue in Windows' equivalent of VFS.
A neat trick to work with temporary files without permission issues is to
open the file and delete it right after that. This does not work on
Windows.
> > - no proper filename semantics (case-insensitivity and stupid rules for
> > allowed characters in filenames, like ":" in filenames in
> > cross-platform projects)
>
> There's a flag on Windows to open files case-sensitively, if you need
> that.
The problem is not so much opening, but determining if an existing file
and a file in the index have the same name.
For example, "README" in the index, but "readme" in the working directory,
will be handled as "deleted/untracked" by the current machinery. IOW git
will not know that what it gets from readdir() as "readme" really is the
same file as "README" in the index.
> > - no acceptable level of performance in filesystem and VFS (readdir,
> > stat, open and read/write are annoyingly slow)
>
> With what libraries? Native `stat' and `readdir' are quite fast.
> Perhaps you mean the ported glibc (libgw32c), where `readdir' is indeed
> painfully slow, but then you don't need to use it.
No, native.
Once you experienced the performance of git on Linux, then rebooted into
Windows on the same box, you will grow a beard while waiting for trivial
operations.
Sure, git kicks ass on Windows, but only as compared to other programs _on
Windows_.
> > - it is the only OS in the world with multi-root (/a/b/c and /a/b/c
> > can be not the same, depending on what current "drive" is)
>
> So what? on Unix "a/b/c" can be not the same. Both cases are simply not
> complete file names, that's all. No one said there must be a single
> root for all volumes, it's the Posix jingoism creeping in again.
I think Alex means this: you can have C:\a\b\c and D:\a\b\c. So depending
on which drive you are, you mean one or the other. Just comparing the
paths is not enough.
> > - no real "mmap" (which kills perfomance and complicates code)
>
> You only need mmap because you are accustomed to use it on GNU/Linux.
Yes. And we rely on the performance very much.
Hth,
Dscho
^ permalink raw reply
* Re: Switching from CVS to GIT
From: Andreas Ericsson @ 2007-10-14 23:55 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: Alex Riesen, Johannes.Schindelin, tsuna, git, make-w32
In-Reply-To: <u7ilpjp3x.fsf@gnu.org>
Eli Zaretskii wrote:
>> Date: Mon, 15 Oct 2007 00:14:46 +0200
>> From: Alex Riesen <raa.lkml@gmail.com>
>> Cc: Andreas Ericsson <ae@op5.se>, Benoit SIGOURE <tsuna@lrde.epita.fr>,
>> git list <git@vger.kernel.org>, Eli Zaretskii <eliz@gnu.org>,
>> Make Windows <make-w32@gnu.org>
>>
>> Re "functional". Have to remind something (besides the fork):
>
> That's a 20-20 hindsight: if you deliberately write a program to rely
> heavily on Posix-isms, don't be surprised when you discover that it
> cannot be easily ported to other platforms.
>
True. It was originally developed because Linux kernel development came
to a stand-still and needed an scm quickly. Since the original design
worked out nicely, nobody bothered (then) about possible future porting
issues. Windows is still a second class citizen, but that's true for
pretty much every unix-born application out there, so I'm not all that
stressed out about it.
>
>> - no proper filename semantics (case-insensitivity and stupid rules for
>> allowed characters in filenames, like ":" in filenames in
>> cross-platform projects)
>
> There's a flag on Windows to open files case-sensitively, if you need
> that. In any case, I don't see how this can be of any real relevance
> to porting GIT.
Because having
Path/foo
path/Foo
PATH
path/foo
is possible in git's native playground, but not on windows, so it can
quite seriously hamper cross-platform cooperation. When that happens,
users usually start blaming the tools in use. Browse the list archives
for HFS and you'll see what I mean, although come to think of it, the
HFS problems might actually be worse, since HFS reports case-changes
while not actually being case-sensitive.
> As for ":" in file names, simply don't use it, like
> you don't use white space or characters below 32 decimal: it's
> inconvenient, even if it's allowed.
>
It's still a real problem because sooner or later someone will use that,
and it needs to be handled with a bit more grace than just bombing out.
>
>> - no real "mmap" (which kills perfomance and complicates code)
>
> You only need mmap because you are accustomed to use it on GNU/Linux.
>
Not really. mmap() provides a real performance boost when reading large
repos, due to the sliding window code that handles pack-files. mmap
was invented for occasions like that, and was allowed to endure because
it was a much better solution than simply read(fd, buf, st.st_size) and
moving pointers around.
>> Interprocess communication:
>>
>> - no reliable text environment (I'm programming in the damn thing for
>> 10 years and I still don't know how to pass an environment variable
>> _for_sure_)
>>
>> - it has only one argument (limited in size) passed to started
>> programs, which means that there is no possible way to safely pass
>> file and text arguments on command line (more than one, that is)
>
> Not enough context, so I cannot talk intelligently about this. Why do
> you need interprocess communication in the first place?
Because some of the commands operate on large data-sets that are best
passed as a stream. It's ridiculously easy to set that up on unix, but
(afaiu) quite troublesome under windows.
> why not simply
> give birth to a subsidiary process and pass it a command line (which
> can be up to 32KB)?
I believe work is in progress that will run things as threads rather
than using fork()+execve(). 32KiB of data is nowhere near enough to
sustain many of the more data-hungry commands. Or rather, it won't be
once the repository has grown passed 50-odd revisions.
All that being said, welcome to the git mailing list. Hopefully you
can help iron out the wrinkles on windows. You seem to have a fairly
good grasp of what's available there, and I'm sure the msys team would
be pretty happy to get a few patches to speed them on their way.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* RE: Switching from CVS to GIT
From: Johannes Schindelin @ 2007-10-15 0:01 UTC (permalink / raw)
To: Dave Korn
Cc: 'Alex Riesen', 'Andreas Ericsson',
'git list', 'Make Windows'
In-Reply-To: <023101c80eb5$e3b6b310$2e08a8c0@CAM.ARTIMI.COM>
Hi,
On Sun, 14 Oct 2007, Dave Korn wrote:
> On 14 October 2007 23:15, Alex Riesen wrote:
>
> > Interprocess communication:
> >
> > - no reliable text environment (I'm programming in the damn thing for
> > 10 years and I still don't know how to pass an environment variable
> > _for_sure_)
> >
> > - it has only one argument (limited in size) passed to started
> > programs, which means that there is no possible way to safely pass
> > file and text arguments on command line (more than one, that is)
>
> Whuh?
>
> http://msdn2.microsoft.com/en-us/library/y5zz48s1(VS.80).aspx
It does have an exec() call, yes, since that is required by the C
standard. But internally, it converts that into one single command line.
In corner cases, you find problems with that.
Hth,
Dscho
^ permalink raw reply
* Re: Switching from CVS to GIT
From: David Brown @ 2007-10-15 0:03 UTC (permalink / raw)
To: Dave Korn
Cc: 'Alex Riesen', 'Johannes Schindelin',
'Andreas Ericsson', 'git list',
'Make Windows'
In-Reply-To: <023101c80eb5$e3b6b310$2e08a8c0@CAM.ARTIMI.COM>
On Sun, Oct 14, 2007 at 11:59:35PM +0100, Dave Korn wrote:
>On 14 October 2007 23:15, Alex Riesen wrote:
>
>> Interprocess communication:
>>
>> - it has only one argument (limited in size) passed to started
>> programs, which means that there is no possible way to safely pass
>> file and text arguments on command line (more than one, that is)
>
> Whuh?
>
>http://msdn2.microsoft.com/en-us/library/y5zz48s1(VS.80).aspx
The MS exec* calls just concatenate all of the argv arguments, separating
them with a space into a single buffer.
Look at the general _exec* page:
http://msdn2.microsoft.com/en-us/library/431x4c1w(VS.80).aspx
and read the first "Note" section.
If you know what the library on the other end is doing to re-parse the
arguments back into separate strings, it might be possible to quote things
enough to handle names with spaces, but it is hard.
David
^ permalink raw reply
* Re: Switching from CVS to GIT
From: Brian Dessent @ 2007-10-15 0:36 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Alex Riesen, make-w32, ae, git
In-Reply-To: <Pine.LNX.4.64.0710150039120.25221@racer.site>
Johannes Schindelin wrote:
> The problem is that on Windows, you cannot keep a file open and delete it
> at the same time. This is an issue in Windows' equivalent of VFS.
>
> A neat trick to work with temporary files without permission issues is to
> open the file and delete it right after that. This does not work on
> Windows.
You can achieve the same thing on Windows with CreateFile() by setting
the dwShareMode parameter to zero and setting the
FILE_FLAG_DELETE_ON_CLOSE attribute on dwFlagsAndAttributes. This
results in a file that cannot be opened or read by any other process and
that will be automatically deleted when all open handles are closed.
> I think Alex means this: you can have C:\a\b\c and D:\a\b\c. So depending
> on which drive you are, you mean one or the other. Just comparing the
> paths is not enough.
This just means that you have to consider the drive letter as part of
the filename.
> > > - no real "mmap" (which kills perfomance and complicates code)
> >
> > You only need mmap because you are accustomed to use it on GNU/Linux.
>
> Yes. And we rely on the performance very much.
Windows may not call it mmap() but it most certainly has memory-mapped
file IO:
<http://msdn2.microsoft.com/en-us/library/aa366781.aspx#file_mapping_functions>.
Brian
^ permalink raw reply
* Re: Switching from CVS to GIT
From: Johannes Schindelin @ 2007-10-15 1:22 UTC (permalink / raw)
To: git; +Cc: Eli Zaretskii, Alex Riesen, ae, tsuna, make-w32
In-Reply-To: <4712B616.165BBF8D@dessent.net>
Hi,
On Sun, 14 Oct 2007, Brian Dessent wrote:
> Johannes Schindelin wrote:
>
> > The problem is that on Windows, you cannot keep a file open and delete
> > it at the same time. This is an issue in Windows' equivalent of VFS.
> >
> > A neat trick to work with temporary files without permission issues is
> > to open the file and delete it right after that. This does not work
> > on Windows.
>
> You can achieve the same thing on Windows with CreateFile() by setting
> the dwShareMode parameter to zero and setting the
> FILE_FLAG_DELETE_ON_CLOSE attribute on dwFlagsAndAttributes. This
> results in a file that cannot be opened or read by any other process and
> that will be automatically deleted when all open handles are closed.
Aha. So to support Windows, we have to wrap all sites that use that
trick, and special case that #ifdef __MINGW32__.
> > I think Alex means this: you can have C:\a\b\c and D:\a\b\c. So
> > depending on which drive you are, you mean one or the other. Just
> > comparing the paths is not enough.
>
> This just means that you have to consider the drive letter as part of
> the filename.
So to support Windows, we have to special case having a ":" as second
character in the filename.
> > > > - no real "mmap" (which kills perfomance and complicates code)
> > >
> > > You only need mmap because you are accustomed to use it on GNU/Linux.
> >
> > Yes. And we rely on the performance very much.
>
> Windows may not call it mmap() but it most certainly has memory-mapped
> file IO:
> <http://msdn2.microsoft.com/en-us/library/aa366781.aspx#file_mapping_functions>.
Yes, but there are still incompatibilities with POSIX. Again, when you
did not close the file, you cannot delete (or rename) it. So, to support
Windows, ...
All this supporting Windows business is certainly possible, if tedious.
Ciao,
Dscho
^ permalink raw reply
* Re: Switching from CVS to GIT
From: Johannes Schindelin @ 2007-10-15 1:24 UTC (permalink / raw)
To: git; +Cc: Eli Zaretskii, Alex Riesen, ae, tsuna, make-w32
In-Reply-To: <Pine.LNX.4.64.0710150217120.25221@racer.site>
Hi,
On Mon, 15 Oct 2007, Johannes Schindelin wrote:
> All this supporting Windows business is certainly possible, if tedious.
To clarify: git works on Windows. Most of the time, that is. But all
those changes that were necessary to go there have not yet found their way
into the official git.git repository.
Ciao,
Dscho
^ permalink raw reply
* Re: Switching from CVS to GIT
From: Michael Gebetsroither @ 2007-10-15 0:46 UTC (permalink / raw)
To: git; +Cc: make-w32
In-Reply-To: <20071014221446.GC2776@steel.home>
["Followup-To:" header set to gmane.comp.version-control.git.]
> - it is the only OS in the world with multi-root (/a/b/c and /a/b/c
> can be not the same, depending on what current "drive" is) and
> multi-cwd, which hasn't had formed itself into a problem yet, but
> surely will
Thats true for linux too.
/a/b/c and /a/b/c can be 2 totally different files depending on the vfs
namespace you are one.
cu,
michael
--
It's already too late!
^ permalink raw reply
* Re: [PATCH 5/7] Bisect: factorise some logging into "bisect_write".
From: Christian Couder @ 2007-10-15 3:35 UTC (permalink / raw)
To: Lars Hjemli; +Cc: Johannes Schindelin, Junio Hamano, git
In-Reply-To: <8c5c35580710141540j6f93a08j2179c5c394bfacd5@mail.gmail.com>
Le lundi 15 octobre 2007, Lars Hjemli a écrit :
> On 10/14/07, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> >
> > Isn't a nolog="$3" missing from bisect_write()?
Yes, you are right. I forgot this line when reorganizing patches before
submitting. Thanks.
> Good catch, I've amended the commit and replaced q/cc/bisect-dunno
> with this series.
Thanks,
Christian.
^ permalink raw reply
* Re: [PATCH 6/7] Bisect: factorise "bisect_{bad,good,dunno}" into "bisect_state".
From: Christian Couder @ 2007-10-15 3:42 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Junio Hamano, git
In-Reply-To: <Pine.LNX.4.64.0710141710230.25221@racer.site>
Le dimanche 14 octobre 2007, Johannes Schindelin a écrit :
> Hi,
>
> On Sun, 14 Oct 2007, Christian Couder wrote:
> > -bisect_bad() {
> > +bisect_state() {
> > bisect_autostart
> > - case "$#" in
> > - 0)
> > - rev=$(git rev-parse --verify HEAD) ;;
> > - 1)
> > - rev=$(git rev-parse --verify "$1^{commit}") ;;
> > + state=$1
> > + case "$#,$state" in
> > + 0,*)
> > + die "Please call 'bisect_state' with at least one argument." ;;
> > + 1,bad|1,good|1,dunno)
> > + rev=$(git rev-parse --verify HEAD) ||
> > + die "Bad rev input: HEAD"
> > + bisect_write "$state" "$rev" ;;
> > + 2,bad)
> > + rev=$(git rev-parse --verify "$2^{commit}") ||
> > + die "Bad rev input: $2"
> > + bisect_write "$state" "$rev" ;;
>
> Really? As far as I see, "2,bad" is an error in the current bisect.
But the new "bisect_state" takes one more argument, because the first one
must be "good" "bad" or "dunno".
So when there is only one argument HEAD is used, and when there are 2
arguments, $2 is used as the good|bad|dunno rev.
> > @@ -404,17 +390,15 @@ bisect_run () {
> > exit $res
> > fi
> >
> > - # Use "bisect_good" or "bisect_bad"
> > - # depending on run success or failure.
> > + # Find current state depending on run success or failure.
> > if [ $res -gt 0 ]; then
> > - next_bisect='bisect_bad'
> > + state='bad'
> > else
> > - next_bisect='bisect_good'
> > + state='good'
> > fi
>
> Maybe it is time to have a special exit status for "dunno"? But this is
> not something to fix in your patch, just an idea for a future patch.
Yes, I will think about it.
Thanks,
Christian.
^ permalink raw reply
* Re: [PATCH] Color support added to git-add--interactive.
From: Jeff King @ 2007-10-15 3:43 UTC (permalink / raw)
To: Dan Zwell
Cc: Wincent Colaiuta, Git Mailing List, Jonathan del Strother,
Johannes Schindelin, Frank Lichtenheld
In-Reply-To: <47112491.8070309@gmail.com>
On Sat, Oct 13, 2007 at 03:03:29PM -0500, Dan Zwell wrote:
> The importance of the diff coloring pales in comparison to the prompt
> coloring. Diff coloring is useful, but prompt coloring is a basic usability
> concern (if people can't easily tell where a hunk begins, the tool becomes
> annoying). Perhaps we could split this into two patches, merging the first
> after a few small changes can be taken care of, while the second may need
Yes, I think it is worth splitting into two patches, here. There seems
to be orthogonal discussion on (colorizing and configuration of prompts versus
how to handle colorized diffs).
-Peff
^ permalink raw reply
* Re: Switching from CVS to GIT
From: Eli Zaretskii @ 2007-10-15 4:06 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: raa.lkml, ae, tsuna, git, make-w32
In-Reply-To: <Pine.LNX.4.64.0710150039120.25221@racer.site>
> Date: Mon, 15 Oct 2007 00:45:47 +0100 (BST)
> From: Johannes Schindelin <Johannes.Schindelin@gmx.de>
> cc: Alex Riesen <raa.lkml@gmail.com>, ae@op5.se, tsuna@lrde.epita.fr,
> git@vger.kernel.org, make-w32@gnu.org
>
> The problem is that on Windows, you cannot keep a file open and delete it
> at the same time.
That is no longer true, for quite some time. NT4 and later versions
support that almost exactly like Posix filesystems.
> > > - no acceptable level of performance in filesystem and VFS (readdir,
> > > stat, open and read/write are annoyingly slow)
> >
> > With what libraries? Native `stat' and `readdir' are quite fast.
> > Perhaps you mean the ported glibc (libgw32c), where `readdir' is indeed
> > painfully slow, but then you don't need to use it.
>
> No, native.
>
> Once you experienced the performance of git on Linux, then rebooted into
> Windows on the same box, you will grow a beard while waiting for trivial
> operations.
Maybe GIT assumes too much about `readdir' and `stat', and should
refactor its code into better abstractions.
> > > - it is the only OS in the world with multi-root (/a/b/c and /a/b/c
> > > can be not the same, depending on what current "drive" is)
> >
> > So what? on Unix "a/b/c" can be not the same. Both cases are simply not
> > complete file names, that's all. No one said there must be a single
> > root for all volumes, it's the Posix jingoism creeping in again.
>
> I think Alex means this: you can have C:\a\b\c and D:\a\b\c. So depending
> on which drive you are, you mean one or the other. Just comparing the
> paths is not enough.
What _I_ meant is that the C: part is part of the full file name,
exactly like the leading / is on Unix.
> > > - No real "mmap" (which kills perfomance and complicates code)
> >
> > You only need mmap because you are accustomed to use it on GNU/Linux.
>
> Yes. And we rely on the performance very much.
There's no need for mmap to get memory performance, except if sbrk and
friends are too slow.
^ permalink raw reply
* Re: [PATCH] Color support added to git-add--interactive.
From: Jeff King @ 2007-10-15 4:12 UTC (permalink / raw)
To: Wincent Colaiuta
Cc: Dan Zwell, Git Mailing List, Jonathan del Strother,
Johannes Schindelin, Frank Lichtenheld
In-Reply-To: <19271E58-5C4F-41AF-8F9D-F114F36A34AC@wincent.com>
On Sat, Oct 13, 2007 at 04:45:41PM +0200, Wincent Colaiuta wrote:
> - changed the regex as suggested by Johannes, and a couple of others
> that are used when splitting hunks
BTW, this approach is totally bogus. The hunks that we store end up
getting fed back to git-apply when we stage them (which doesn't
understand the color codes).
Just try using your patch to actually stage a hunk; nothing happens (and
the error is almost impossible to see, since we show the bogus diff on
stderr).
So now I am doubly convinced that colorizing the diffs in
add--interactive is the right thing (and it looks like Tom Tobin has
already done a fair bit of the work).
-Peff
^ permalink raw reply
* Re: Switching from CVS to GIT
From: Eli Zaretskii @ 2007-10-15 4:12 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: ae, raa.lkml, git, make-w32
In-Reply-To: <Pine.LNX.4.64.0710150217120.25221@racer.site>
> Date: Mon, 15 Oct 2007 02:22:53 +0100 (BST)
> From: Johannes Schindelin <Johannes.Schindelin@gmx.de>
> cc: Eli Zaretskii <eliz@gnu.org>, Alex Riesen <raa.lkml@gmail.com>, ae@op5.se,
> tsuna@lrde.epita.fr, make-w32@gnu.org
>
> > You can achieve the same thing on Windows with CreateFile() by setting
> > the dwShareMode parameter to zero and setting the
> > FILE_FLAG_DELETE_ON_CLOSE attribute on dwFlagsAndAttributes. This
> > results in a file that cannot be opened or read by any other process and
> > that will be automatically deleted when all open handles are closed.
>
> Aha. So to support Windows, we have to wrap all sites that use that
> trick, and special case that #ifdef __MINGW32__.
No, you need to think in abstractions rather than POSIX-isms, and then
let each platform implement those abstractions as appropriate.
> > > I think Alex means this: you can have C:\a\b\c and D:\a\b\c. So
> > > depending on which drive you are, you mean one or the other. Just
> > > comparing the paths is not enough.
> >
> > This just means that you have to consider the drive letter as part of
> > the filename.
>
> So to support Windows, we have to special case having a ":" as second
> character in the filename.
No, you need to think abstractions like `absolute_file_name' and
`dir_separator'.
> > > > > - no real "mmap" (which kills perfomance and complicates code)
> > > >
> > > > You only need mmap because you are accustomed to use it on GNU/Linux.
> > >
> > > Yes. And we rely on the performance very much.
> >
> > Windows may not call it mmap() but it most certainly has memory-mapped
> > file IO:
> > <http://msdn2.microsoft.com/en-us/library/aa366781.aspx#file_mapping_functions>.
>
> Yes, but there are still incompatibilities with POSIX.
Stop thinking POSIX. Think abstractions that are common to POSIX and
non-POSIX systems. If you think POSIX, don't be surprised that it
won't port.
> Again, when you did not close the file, you cannot delete (or
> rename) it.
Yes, you can, nowadays. But that doesn't mean it was TRT to use such
dirty tricks to implement temporary files or security. One needs to
think in abstractions again, and leave the implementation to each
platform.
> All this supporting Windows business is certainly possible, if tedious.
Only if the program was written with disregard to anything but POSIX.
^ permalink raw reply
* Re: [PATCH] git-add (-a|-u) and -n support
From: Jeff King @ 2007-10-15 4:20 UTC (permalink / raw)
To: Michael Witten; +Cc: git
In-Reply-To: <E1DCA1D1-1ED3-498A-A919-9EBAF3BA0870@mit.edu>
On Sun, Oct 14, 2007 at 06:26:28AM -0400, Michael Witten wrote:
> The patch is below, but you can also download it from
> http://web.mit.edu/mfwitten/git/0001-git-add-now-understands-two-kinds-of-update.patch
Hi Michael,
Thank you for submitting a patch! However, please make sure you read
SubmittingPatches carefully. Your message should consist of the regular
mail headers (as generated by git-format-patch + whatever else you want
to add), the commit message, a line containing "---", and then the diff.
Any cover letter material should go after the "---".
IOW, the format the git-format-patch generates is actually a mail in the
correct format. If you can convince your mailer to use that as a
template for sending a mail, that is the best bet.
I know these seem like little things, but they make the life of the
maintainer much easier, as it means your patch and commit message can be
applied directly by the git tools.
-Peff "policing the list with an iron fist in Junio's absence" King
^ permalink raw reply
* [PATCH] git-rebase: document suppression of duplicate commits
From: Jeff King @ 2007-10-15 4:47 UTC (permalink / raw)
To: Michael Witten; +Cc: git, Lars Hjemli
git-rebase uses format-patch's --ignore-if-in-upstream
option, but we never document the user-visible behavior. The
example is placed near the top of the example list rather
than at the bottom because it is:
a. a simple example
b. a reasonably common scenario for many projects (mail
some patches which get accepted upstream, then rebase)
Signed-off-by: Jeff King <peff@peff.net>
---
On Sat, Oct 13, 2007 at 07:04:52PM -0400, Michael Witten wrote:
> I can make a patch, but at the moment I'm swamped and I don't want to
> think about doing that.
And whoever said procrastination didn't get things done?
Documentation/git-rebase.txt | 25 ++++++++++++++++++++++++-
1 files changed, 24 insertions(+), 1 deletions(-)
diff --git a/Documentation/git-rebase.txt b/Documentation/git-rebase.txt
index e8e7579..b6efb48 100644
--- a/Documentation/git-rebase.txt
+++ b/Documentation/git-rebase.txt
@@ -28,7 +28,10 @@ The current branch is reset to <upstream>, or <newbase> if the
`git reset --hard <upstream>` (or <newbase>).
The commits that were previously saved into the temporary area are
-then reapplied to the current branch, one by one, in order.
+then reapplied to the current branch, one by one, in order. Note that
+any commits in HEAD which introduce the same textual changes as a commit
+in <upstream>..HEAD are omitted (i.e., a patch already accepted upstream
+with a different commit message or timestamp will be skipped).
It is possible that a merge failure will prevent this process from being
completely automatic. You will have to resolve any such merge failure
@@ -62,6 +65,26 @@ would be:
The latter form is just a short-hand of `git checkout topic`
followed by `git rebase master`.
+If the upstream branch already contains a change you have made (e.g.,
+because you mailed a patch which was applied upstream), then that commit
+will be skipped. For example, running `git-rebase master` on the
+following history (in which A' and A introduce the same set of changes,
+but have different committer information):
+
+------------
+ A---B---C topic
+ /
+ D---E---A'---F master
+------------
+
+will result in:
+
+------------
+ B'---C' topic
+ /
+ D---E---A'---F master
+------------
+
Here is how you would transplant a topic branch based on one
branch to another, to pretend that you forked the topic branch
from the latter branch, using `rebase --onto`.
--
1.5.3.4.1155.gfe96ee-dirty
^ permalink raw reply related
* Re: git-fast-import crashes
From: Shun Kei Leung @ 2007-10-15 4:53 UTC (permalink / raw)
To: git; +Cc: Pierre Habouzit, Shawn O. Pearce
In-Reply-To: <20071013075027.GD7110@artemis.corp>
Hi,
Sorry for the late reply. I was away from my computer in the weekend.
Hi Pierre,
I didn't try:
http://git.madism.org/?p=git.git;a=commit;h=7406e83342cd445ac38c1753c5fce75377737e2f
because the bad commit turns out to be b449f4c according to `git bisect'.
Hi Shawn,
I include the output of `git count-objects -v' for your information:
count: 104
size: 552
in-pack: 10652
packs: 12
prune-packable: 0
garbage: 0
Regards,
Kevin Leung
^ permalink raw reply
* Re: Switching from CVS to GIT
From: Martin Langhoff @ 2007-10-15 5:35 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Benoit SIGOURE, git list, Eli Zaretskii, Make Windows
In-Reply-To: <Pine.LNX.4.64.0710141916510.25221@racer.site>
On 10/15/07, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> There is msysGit. This project is nearing to its first beta, being
> self-hosted since mid-August IIRC.
I've been using it recently, I have to say it's pretty impressive -
you can use it from cmd.com or from a bash window (courtesy of the
msys environment included). The GUIs that ship with git are there
(git-gui, gitk).
I use gitk extensively, and it works *great*. My work-style is of a
shell window for status/diff/commit actions and one or more gitk
windows for browsing of proj history. You can use git-gui for a visual
status/git/commit workflow, or qgit. qgit is more integrated, and
might feel more "at home" for users that expect something more
MDI-ish.
cheers.
martin
^ permalink raw reply
* Re: Switching from CVS to GIT
From: Martin Langhoff @ 2007-10-15 5:43 UTC (permalink / raw)
To: Andreas Ericsson
Cc: Johannes Schindelin, Benoit SIGOURE, git list, Eli Zaretskii,
Make Windows
In-Reply-To: <47126957.1020204@op5.se>
On 10/15/07, Andreas Ericsson <ae@op5.se> wrote:
> > And I have to disagree strongly with the "black": In msysGit (which brings
> > its own minimal version of MSys), it is very smooth.
> >
>
> Oh? I didn't know that. Windows and its unixifying toolboxes is unknown
> territory to me, as I happily spend all my time on various unices.
I'm a unix-head too. Last couple of weeks had to work on a windows
server, and installed msysGit. Very impressed - all the needed
dependencies are there, from an end-user POV it "just works".
> I was under the impression that the windows port suffers from Windows'
> lack of a proper fork() and friends and that a proper library would
> help solving those problems. Perhaps I was misinformed.
I think msys' DLLs might be doing what cygwin does, an emulated fork.
A quite surprising thing is that msysgit manages to be very fast. Not
as fast as the same git, same hw running on a recent Linux, but pretty
usable fast for a tree with a few thousand files. Earlier/other git
ports to win32 are pretty slow (still faster than svn and friends, but
slooow).
cheers,
m
^ permalink raw reply
* Re: Switching from CVS to GIT
From: Eli Zaretskii @ 2007-10-15 5:56 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: ae, raa.lkml, git, make-w32
In-Reply-To: <Pine.LNX.4.64.0710150039120.25221@racer.site>
> Date: Mon, 15 Oct 2007 00:45:47 +0100 (BST)
> From: Johannes Schindelin <Johannes.Schindelin@gmx.de>
> cc: Alex Riesen <raa.lkml@gmail.com>, ae@op5.se, tsuna@lrde.epita.fr,
> git@vger.kernel.org, make-w32@gnu.org
>
> The problem is not so much opening, but determining if an existing file
> and a file in the index have the same name.
>
> For example, "README" in the index, but "readme" in the working directory,
> will be handled as "deleted/untracked" by the current machinery. IOW git
> will not know that what it gets from readdir() as "readme" really is the
> same file as "README" in the index.
That's because you think file names are simple strings and can be
compared by simple string comparison. This naìve view is not true
even on POSIX systems: "foo/bar" and "/a/b/foo/bar" can be the same
file, as well as "/a/b/c/d" and "/x/y/z", given the right symlinks.
But for some reason that eludes me, people who are accustomed to POSIX
stop right there and in effect say "file names are strings, if we only
make them absolute and resolve links". Instead, recognize that file
names are not strings (although they inherit some of the strings'
traits), and think in terms of "file-name comparison" abstraction;
then everything will fall in place just fine.
> > > - no acceptable level of performance in filesystem and VFS (readdir,
> > > stat, open and read/write are annoyingly slow)
> >
> > With what libraries? Native `stat' and `readdir' are quite fast.
> > Perhaps you mean the ported glibc (libgw32c), where `readdir' is indeed
> > painfully slow, but then you don't need to use it.
>
> No, native.
Can you show a test case where this penalty is clearly visible? I'm
curious to see the numbers. TIA
^ permalink raw reply
* Re: [PATCH 0/7] Bisect dunno
From: Marius Storm-Olsen @ 2007-10-15 6:04 UTC (permalink / raw)
To: David Kastrup
Cc: Christian Couder, Wincent Colaiuta, René Scharfe,
Junio Hamano, Johannes Schindelin, git
In-Reply-To: <85d4vhlh8y.fsf@lola.goethe.zz>
[-- Attachment #1: Type: text/plain, Size: 1355 bytes --]
David Kastrup said the following on 14.10.2007 19:48:
> Marius Storm-Olsen <marius@trolltech.com> writes:
>
>> Wincent Colaiuta said the following on 14.10.2007 18:35:
>>
>>> "undecided" sounds good to me. It should be clear to non-native
>>> speakers of English (at least, clearer than "dunno").
>> What about just "unknown"?
>
> I tend to nitpick to the degree of silliness when my own suggestions
> are concerned, but "unknown" sounds to me like the state _before_ the
> test. If a person says he is "undecided" about something that means
> that he _has_ thought about it already. "Undecidable" might bring
> this distinction across more strongly, but it is a more complicated
> word and it insinuates that it is _impossible_ to come to a decision
> regardless of the spent effort.
>
> "unknown" clearly is much better than "dunno" though even if my own
> favorite would be "undecided".
What then about a good'ol programming favorite, "void"? :-)
I agree that "unknown" might be a state even _before_ a person has
determined if a case is good or bad (same for 'dunno' actually: "- Do
you know if it works? - I dunno yet") When I think more about it, I
really like "void"..
"Argh, this test is void, because someone messed with it"
"We can't make heads or tails of this one, so it must be void"
--
.marius
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 187 bytes --]
^ permalink raw reply
* Re: Switching from CVS to GIT
From: Eli Zaretskii @ 2007-10-15 6:04 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: ae, raa.lkml, git, make-w32
In-Reply-To: <Pine.LNX.4.64.0710150223230.25221@racer.site>
> Date: Mon, 15 Oct 2007 02:24:53 +0100 (BST)
> From: Johannes Schindelin <Johannes.Schindelin@gmx.de>
> cc: Eli Zaretskii <eliz@gnu.org>, Alex Riesen <raa.lkml@gmail.com>, ae@op5.se,
> tsuna@lrde.epita.fr, make-w32@gnu.org
>
> To clarify: git works on Windows. Most of the time, that is. But all
> those changes that were necessary to go there have not yet found their way
> into the official git.git repository.
I, for one, appreciate all the hard work invested in that.
While we are at that: can you (or someone else) point me to
instructions on how to build the MinGW port of GIT? I found a tarball
of the MinGW-ported GIT (v1.5.3, I think), but what I don't seem to be
able to find is some kind of HOWTO: what tools I need to have
installed, how to configure them (if there are any special issues
there), what command(s) to type, etc. Is there anything like that out
there, or can someone post such instructions?
TIA
^ permalink raw reply
* Re: Switching from CVS to GIT
From: Eli Zaretskii @ 2007-10-15 6:08 UTC (permalink / raw)
To: David Brown; +Cc: raa.lkml, make-w32, Johannes.Schindelin, ae, git
In-Reply-To: <20071015000347.GA13033@old.davidb.org>
> Date: Sun, 14 Oct 2007 17:03:47 -0700
> From: David Brown <git@davidb.org>
> Cc: 'Andreas Ericsson' <ae@op5.se>, 'Alex Riesen' <raa.lkml@gmail.com>,
> 'git list' <git@vger.kernel.org>,
> 'Johannes Schindelin' <Johannes.Schindelin@gmx.de>,
> 'Make Windows' <make-w32@gnu.org>
>
> The MS exec* calls just concatenate all of the argv arguments, separating
> them with a space into a single buffer.
True.
> If you know what the library on the other end is doing to re-parse the
> arguments back into separate strings, it might be possible to quote things
> enough to handle names with spaces, but it is hard.
It's not hard, it's just a bit of work. And it needs to be done
exactly once.
^ 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