* [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: [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
* 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] 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: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 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: [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 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: 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: 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: 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: 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: 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: 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: 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-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
* 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: 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
* Re: Git User's Survey 2007 summary - git homepage improvements
From: Frank Lichtenheld @ 2007-10-14 22:56 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git, Petr Baudis
In-Reply-To: <8fe92b430710141505y75ab61c4l50688fc9530e4f90@mail.gmail.com>
On Mon, Oct 15, 2007 at 12:05:22AM +0200, Jakub Narebski wrote:
> Generic:
> # Dedicated domain name / site name, e.g. git.org or git.com
> to have it look less like mirror or unofficial page
>
> (git.or.cz still comes first when searching Google for "git";
> current domain name was available to homepage admin - historical
> reason)
Hmm, I guess most names that would qualify are already taken
(most of them by squatters, though). So someone
would have to pay money for this...
(And I guess something like git-scm.org wouldn't qualify as more
"official", would it?)
However, I have to admit I had quite some problems remembering the
domain name myself in the beginning...
> Downloads:
> # More up-to-date about new git versions.
>
> (With one person updating homepage, who is not git maintainer...)
There are use-cases for shared repositories. Maybe this is one of them?
Gruesse,
--
Frank Lichtenheld <frank@lichtenheld.de>
www: http://www.djpig.de/
^ permalink raw reply
* Re: [PATCH] parse-options: Allow abbreviated options when unambiguous
From: Eric Wong @ 2007-10-14 22:49 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Pierre Habouzit, git
In-Reply-To: <Pine.LNX.4.64.0710142309010.25221@racer.site>
Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> Hi,
>
> On Sun, 14 Oct 2007, Eric Wong wrote:
>
> > Pierre Habouzit <madcoder@debian.org> wrote:
> > > On Sun, Oct 14, 2007 at 06:02:33PM +0000, Johannes Schindelin wrote:
> > > > Hi,
> > > >
> > > > On Sun, 14 Oct 2007, Johannes Schindelin wrote:
> > > >
> > > > > When there is an option "--amend", the option parser now recognizes
> > > > > "--am" for that option, provided that there is no other option beginning
> > > > > with "--am".
> > > >
> > > > And an amend for ultra-abbreviated options (as you noticed on IRC):
> > > >
> > > > diff --git a/parse-options.c b/parse-options.c
> > > > index afc6c89..acabb98 100644
> > > > --- a/parse-options.c
> > > > +++ b/parse-options.c
> > > > @@ -137,6 +137,11 @@ is_abbreviated:
> > > > abbrev_flags = flags;
> > > > continue;
> > > > }
> > > > + /* negated and abbreviated very much? */
> > > > + if (!prefixcmp("no-", arg)) {
> > > > + flags |= OPT_UNSET;
> > > > + goto is_abbreviated;
> > > > + }
> > > > /* negated? */
> > > > if (strncmp(arg, "no-", 3))
> > > > continue;
> > >
> > > squashed on top on the previous, and pushed to my ph/parseopt branch.
> >
> > Awesome. Thanks to both of you.
>
> Hehe, you're welcome. Pierre even realised that my patch was not complete
> (it did not catch overly short abbreviations "--n" and "--no"), and that
> has been fixed, too.
> 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 :)
--
Eric Wong
^ permalink raw reply
* Re: Switching from CVS to GIT
From: Eli Zaretskii @ 2007-10-14 22:41 UTC (permalink / raw)
To: Alex Riesen; +Cc: git, ae, Johannes.Schindelin, make-w32
In-Reply-To: <20071014221446.GC2776@steel.home>
> 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.
> - 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?
> - 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. 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.
> - 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.
> - 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.
> and multi-cwd
No longer a problem on Windows versions since 2000.
> - no real "mmap" (which kills perfomance and complicates code)
You only need mmap because you are accustomed to use it on GNU/Linux.
> 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? why not simply
give birth to a subsidiary process and pass it a command line (which
can be up to 32KB)?
^ permalink raw reply
* Re: [PATCH 5/7] Bisect: factorise some logging into "bisect_write".
From: Lars Hjemli @ 2007-10-14 22:40 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Christian Couder, Junio Hamano, git
In-Reply-To: <Pine.LNX.4.64.0710141706440.25221@racer.site>
On 10/14/07, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> On Sun, 14 Oct 2007, Christian Couder wrote:
> > diff --git a/git-bisect.sh b/git-bisect.sh
> > index 847250c..e12125f 100755
> > --- a/git-bisect.sh
> > +++ b/git-bisect.sh
> > @@ -132,6 +131,7 @@ bisect_write() {
> > esac
> > echo "$rev" >"$GIT_DIR/refs/bisect/$tag"
> > echo "# $state: "$(git show-branch $rev) >>"$GIT_DIR/BISECT_LOG"
> > + test -z "$nolog" && echo "git-bisect $state $rev" >>"$GIT_DIR/BISECT_LOG"
> > }
>
> Isn't a nolog="$3" missing from bisect_write()?
Good catch, I've amended the commit and replaced q/cc/bisect-dunno
with this series.
--
larsh
^ permalink raw reply
* Re: [PATCH 1/7] rev-list: implement --bisect-all
From: Frank Lichtenheld @ 2007-10-14 22:39 UTC (permalink / raw)
To: Christian Couder; +Cc: Junio Hamano, Johannes Schindelin, git
In-Reply-To: <20071014142852.2516e083.chriscool@tuxfamily.org>
On Sun, Oct 14, 2007 at 02:28:52PM +0200, Christian Couder wrote:
> This is Junio's patch with some stuff to make --bisect-all
> compatible with --bisect-vars.
>
> This option makes it possible to see all the potential
> bisection points. The best ones are displayed first.
--bisect-all is still missing a Documentation/ patch.
Gruesse,
--
Frank Lichtenheld <frank@lichtenheld.de>
www: http://www.djpig.de/
^ permalink raw reply
* Re: Git User's Survey 2007 unfinished summary continued
From: David Kastrup @ 2007-10-14 22:30 UTC (permalink / raw)
To: Matthew Andrews; +Cc: Jakub Narebski, Johannes Schindelin, git
In-Reply-To: <3a5d78af0710141523u4330a0fcnbc76a6b18354181e@mail.gmail.com>
"Matthew Andrews" <matthew.andrews@gmail.com> writes:
> I'm trying to see this negative tone that apparently exists on the
> list. As a long-time lurker, I only see a fairly standard
> open-source expectation of basic knowledge and strong opinion. The
> list is fairly good about point people to existing documentation. If
> you do something that somebody thinks is stupid, they'll tell you
> so. They don't coddle you here, but they are more than willing to
> help.
I never said that this list was not competent or helpful.
Anyway: if everybody had the same impression, we would not need a
survey, right?
--
David Kastrup, Kriemhildstr. 15, 44793 Bochum
^ permalink raw reply
* Re: Git User's Survey 2007 unfinished summary continued
From: Matthew Andrews @ 2007-10-14 22:23 UTC (permalink / raw)
To: David Kastrup; +Cc: Jakub Narebski, Johannes Schindelin, git
In-Reply-To: <85k5ppjqfu.fsf@lola.goethe.zz>
I'm trying to see this negative tone that apparently exists on the
list. As a long-time lurker, I only see a fairly standard open-source
expectation of basic knowledge and strong opinion. The list is fairly
good about point people to existing documentation. If you do something
that somebody thinks is stupid, they'll tell you so. They don't coddle
you here, but they are more than willing to help.
On 10/14/07, David Kastrup <dak@gnu.org> wrote:
> "Jakub Narebski" <jnareb@gmail.com> writes:
>
> > On 10/13/07, David Kastrup <dak@gnu.org> wrote:
> >
> >> I find it a pity that my suggestion to ask about how comfortable
> >> people are with the tone on the list did not make it into the survey.
> >> Enough core developers make the tone sufficiently unconstructive to
> >> make it quite understandable that people are unwilling to ask
> >> questions here, in order to avoid getting their heads banged against a
> >> wall, virtual or not.
> >
> > I think next to last question in the survey
> >
> > 61. Did you have problems getting GIT help on mailing list or on
> > IRC channel? What were it? What could be improved?
> >
> > was the place to put complaints about git mailing list.
>
> What if there are no problems getting help once you submit to letting
> your head get bashed in?
>
> The problem is not with getting help on the list: the list is
> bristling with competent people. The problem is the price to pay in
> self-esteem and comfort.
>
> --
> David Kastrup, Kriemhildstr. 15, 44793 Bochum
> -
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply
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