* Re: Switching from CVS to GIT
From: Johannes Sixt @ 2007-10-16 6:42 UTC (permalink / raw)
To: Eli Zaretskii
Cc: Daniel Barkalow, raa.lkml, Johannes.Schindelin, ae,
Benoit SIGOURE, git@vger.kernel.org >> Git Mailing List,
Make Windows
In-Reply-To: <uodezisvg.fsf@gnu.org>
Eli Zaretskii schrieb:
> If that's the issue, then it's not a good idea to call `stat' and
> `readdir' on Windows at all. `stat' is a single system call on Posix
> systems, while on Windows it usually needs to go out of its way
> calling half a dozen system services to gather the `struct stat' info.
Thanks to Marius Storm-Olsen we already have a stat replacement that's twice
as fast as msvcrt's stat. I calls only one API function
(GetFileAttributesEx, but of course I don't know what's going on under its
hood), because we need only a small part of struct stat filled in correctly.
-- Hannes
^ permalink raw reply
* Re: Switching from CVS to GIT
From: Johannes Sixt @ 2007-10-16 6:29 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: git list
In-Reply-To: <20071016062144.GD13801@spearce.org>
Shawn O. Pearce schrieb:
> Johannes Sixt <j.sixt@viscovery.net> wrote:
>>> Johannes Sixt <j.sixt@viscovery.net> wrote:
>>>> Unfortunately, "Fetch" does not yet work[*] from within git-gui, so you
>>>> have to fall back to git-fetch on the command line.
>> It's the scripted fetch that does not work. The symptom is that the output
^^^^^^^^^^^^^^
>> of at least one of the commands (upload-pack, I think, because what I see
>> is wire protocol) goes to a newly spawned console instead of wherever it
>> was redirected to.
>>
>> I didn't bother reporting since builtin-fetch is on the way (which will
>> hopefully make this a moot point) and our team here is comfortable with
>> calling git fetch on the command line.
>
> Hmm. The way the builtin-fetch works this shouldn't happen, but
> I'd appreciate it if you could test and report back before that
> topic merges into master.
This happens with git 1.5.3 plus the git-gui that comes with that.
FWIW, I'm in the process of merging master of git.git into git/mingw.git,
and then the builtin-fetch series (because on top of that there is my
fork/exec removal series, which I'd like to adjust for Windows). And *then*
I'll be able to report back to you.
-- Hannes
^ permalink raw reply
* Re: Switching from CVS to GIT
From: Eli Zaretskii @ 2007-10-16 6:25 UTC (permalink / raw)
To: Andreas Ericsson
Cc: barkalow, raa.lkml, Johannes.Schindelin, tsuna, git, make-w32
In-Reply-To: <471448D0.6080200@op5.se>
> Date: Tue, 16 Oct 2007 07:14:56 +0200
> From: Andreas Ericsson <ae@op5.se>
> CC: Daniel Barkalow <barkalow@iabervon.org>, raa.lkml@gmail.com,
> Johannes.Schindelin@gmx.de, tsuna@lrde.epita.fr, git@vger.kernel.org,
> make-w32@gnu.org
>
> > Sorry I'm asking potentially stupid questions out of ignorance: why
> > would you want readdir to return `README' when you have `readme'?
> >
>
> Because it might have been checked in as README, and since git is case
> sensitive that is what it'll think should be there when it reads the
> directories. If it's not, users get to see
>
> removed: README
> untracked: readme
This is a non-issue, then: Windows filesystems are case-preserving, so
if `README' became `readme', someone deliberately renamed it, in which
case it's okay for git to react as above.
> could be an intentional rename, but we don't know for sure.
It _must_ have been an intentional rename. While years ago there used
to be old DOS programs that could cause such a rename as a side effect
of modifying a file, that time is long gone. There's no longer a need
to cater to such programs, as even DOS programs can support
case-preserving APIs on Windows.
> To be honest though, there are so many places which do the readdir+stat
> that I don't think it'd be worth factoring it out
Something for Windows users to decide, I guess. It's not hard to
refactor this, it just needs a motivated volunteer.
> especially since it
> *works* on windows. It's just slow, and only slow compared to various
> unices.
I think only the Linux filesystem is as fast as you say. But I may be
wrong (did someone compare with *BSD, say?).
> I *think* (correct me if I'm wrong) that git is still faster
> than a whole bunch of other scm's on windows, but to one who's used to
> its performance on Linux that waiting several seconds to scan 10k files
> just feels wrong.
Unless that 10K is a typo and you really meant 100K, I don't think 10K
files should take several seconds to scan on Windows. I just tried
"find -print" on a directory with 32K files in 4K subdirectories, and
it took 8 sec elapsed with a hot cache. So 10K files should take at
most 2 seconds, even without optimizing file traversal code. Doing
the same with native Windows system calls ("dir /s") brings that down
to 4 seconds for 32K files.
On the other hand, what packages have 100K files? If there's only one
-- the Linux kernel -- then I think this kind of performance is for
all practical purposes unimportant on Windows, because while it is
reasonable to assume that someone would like to use git on Windows,
assuming that someone will develop the Linux kernel on Windows is --
how should I put it -- _really_ far-fetched ;-)
As for speed of file ops ``just feeling wrong'': it's not limited to
git in any way. You will see the same with "tar -x", with "find" and
even with "cp -r", when you compare Linux filesystems, especially on a
fast 64-bit machine, with comparable Windows operations. A Windows
user who occasionally works on GNU/Linux already knows that, so seeing
the same in git will not come as a surprise. Again, I wonder how this
compares with other free OSes, like FreeBSD (unless they use the same
filesystem), and with proprietary Unices, like AIX and Solaris.
^ permalink raw reply
* Re: Switching from CVS to GIT
From: Shawn O. Pearce @ 2007-10-16 6:21 UTC (permalink / raw)
To: Johannes Sixt; +Cc: git list
In-Reply-To: <471455ED.8070408@viscovery.net>
Johannes Sixt <j.sixt@viscovery.net> wrote:
> >Johannes Sixt <j.sixt@viscovery.net> wrote:
> >>Unfortunately, "Fetch" does not yet work[*] from within git-gui, so you
> >>have to fall back to git-fetch on the command line.
>
> It's the scripted fetch that does not work. The symptom is that the output
> of at least one of the commands (upload-pack, I think, because what I see
> is wire protocol) goes to a newly spawned console instead of wherever it
> was redirected to.
>
> I didn't bother reporting since builtin-fetch is on the way (which will
> hopefully make this a moot point) and our team here is comfortable with
> calling git fetch on the command line.
Hmm. The way the builtin-fetch works this shouldn't happen, but
I'd appreciate it if you could test and report back before that
topic merges into master.
--
Shawn.
^ permalink raw reply
* Re: [PATCH 6/7] Bisect: factorise "bisect_{bad,good,dunno}" into "bisect_state".
From: Christian Couder @ 2007-10-16 6:28 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Junio Hamano, git
In-Reply-To: <Pine.LNX.4.64.0710151338000.25221@racer.site>
Hi Dscho,
Le lundi 15 octobre 2007, Johannes Schindelin a écrit :
> Hi,
>
> On Mon, 15 Oct 2007, Christian Couder wrote:
> >
> > 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.
>
> Ah, that explains it! But do you not need to do "2,bad|2,good|2,dunno"
> in that case? Or even better: "2,*"?
Perhaps it would be an improvement at least in speed for "2,good"
or "2,dunno".
I wanted to keep exactly the same processing as there was before, in case
something like "git bisect good v1.5.3.3..v1.5.3.4" was supported. But it
seems it doesn't work. I don't know if it's a bug or a feature.
Christian.
^ permalink raw reply
* Re: [PATCH 0/7] Bisect dunno
From: David Kastrup @ 2007-10-16 6:17 UTC (permalink / raw)
To: David Symonds
Cc: Geert Bosch, Wincent Colaiuta, Johan Herland, git,
Marius Storm-Olsen, Christian Couder, René Scharfe,
Junio Hamano, Johannes Schindelin
In-Reply-To: <ee77f5c20710152307n48431a6eu5dc95ee504968e4e@mail.gmail.com>
"David Symonds" <dsymonds@gmail.com> writes:
> On 16/10/2007, David Kastrup <dak@gnu.org> wrote:
>> Geert Bosch <bosch@adacore.com> writes:
>>
>> > On Oct 15, 2007, at 13:53, David Symonds wrote:
>> >> That's also why I suggested "skip"; you might not be able to test a
>> >> particular commit, but you might also not *want* to test a particular
>> >> commit for some reason.
>> >
>> > Skip seems a great choice: it directly expresses the wish to
>> > not consider a certain commit. The reason is unimportant.
>>
>> But it is an _action_, while "good" and "bad" are properties.
>
> "skipped", then.
"good" and "bad" are descriptive. "to be skipped" would be necessary
to fit it.
> Either way, something like this has got to be much better than
> "dunno".
"undecided" still has my vote, and I could live with "unknown".
Everything that has been proposed since then is, in my opinion,
strictly worse.
--
David Kastrup, Kriemhildstr. 15, 44793 Bochum
^ permalink raw reply
* Re: Switching from CVS to GIT
From: Steffen Prohaska @ 2007-10-16 6:17 UTC (permalink / raw)
To: Nguyen Thai Ngoc Duy
Cc: Git Mailing List, Alex Riesen, Eli Zaretskii, Andreas Ericsson,
tsuna, Johannes Schindelin
In-Reply-To: <fcaeb9bf0710151924r258dd561hd13c22319d17f80f@mail.gmail.com>
On Oct 16, 2007, at 4:24 AM, Nguyen Thai Ngoc Duy wrote:
> On 10/16/07, Steffen Prohaska <prohaska@zib.de> wrote:
>>
>> On Oct 15, 2007, at 10:19 PM, Johannes Schindelin wrote:
>>> There is a port of BusyBox' dash, which is nearing completion. Once
>>> Nguyen says it is ready enough, we will try to integrate it into
>>> msysGit.
>>
>> Gnuarch [1] recommends zsh from the unxutils project [2].
>
> All zsh links in [2] are dead. I did try hard to find the legendary
> zsh for Windows before giving up and porting busybox's ash instead. If
> you have zsh source of the port, please send me. Thank you.
It is included in UnxUtilsSrc.zip, updated on 2007-03-01 06:22, from
http://sourceforge.net/projects/unxutils
http://sourceforge.net/project/showfiles.php?group_id=9328
Steffen
^ permalink raw reply
* Re: Switching from CVS to GIT
From: Johannes Sixt @ 2007-10-16 6:10 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: git list
In-Reply-To: <20071015231242.GR27899@spearce.org>
Shawn O. Pearce schrieb:
> Johannes Sixt <j.sixt@viscovery.net> wrote:
>> Unfortunately, "Fetch" does not yet work[*] from within git-gui, so you
>> have to fall back to git-fetch on the command line.
>>
>> [*] Note the distinction between "not available" and "does not work".
>
> What's broken? Is this that Git protocol dump showing up in
> git-gui's console window thing?
>
> Are you using the C based fetch that is in git.git's next branch,
> or the shell script based one that is in master? Which Tcl/Tk
> version are you using to run git-gui?
It's the scripted fetch that does not work. The symptom is that the output
of at least one of the commands (upload-pack, I think, because what I see is
wire protocol) goes to a newly spawned console instead of wherever it was
redirected to.
I didn't bother reporting since builtin-fetch is on the way (which will
hopefully make this a moot point) and our team here is comfortable with
calling git fetch on the command line.
-- Hannes
^ permalink raw reply
* Re: [PATCH 0/7] Bisect dunno
From: David Symonds @ 2007-10-16 6:07 UTC (permalink / raw)
To: David Kastrup
Cc: Geert Bosch, Wincent Colaiuta, Johan Herland, git,
Marius Storm-Olsen, Christian Couder, René Scharfe,
Junio Hamano, Johannes Schindelin
In-Reply-To: <85ve98gl57.fsf@lola.goethe.zz>
On 16/10/2007, David Kastrup <dak@gnu.org> wrote:
> Geert Bosch <bosch@adacore.com> writes:
>
> > On Oct 15, 2007, at 13:53, David Symonds wrote:
> >> That's also why I suggested "skip"; you might not be able to test a
> >> particular commit, but you might also not *want* to test a particular
> >> commit for some reason.
> >
> > Skip seems a great choice: it directly expresses the wish to
> > not consider a certain commit. The reason is unimportant.
>
> But it is an _action_, while "good" and "bad" are properties.
"skipped", then. Either way, something like this has got to be much
better than "dunno".
Dave.
^ permalink raw reply
* Re: Switching from CVS to GIT
From: David Kastrup @ 2007-10-16 6:06 UTC (permalink / raw)
To: Eli Zaretskii
Cc: Daniel Barkalow, raa.lkml, Johannes.Schindelin, ae, tsuna, git,
make-w32
In-Reply-To: <uodezisvg.fsf@gnu.org>
Eli Zaretskii <eliz@gnu.org> writes:
>> Date: Mon, 15 Oct 2007 20:45:02 -0400 (EDT)
>> From: Daniel Barkalow <barkalow@iabervon.org>
>> cc: Alex Riesen <raa.lkml@gmail.com>, Johannes.Schindelin@gmx.de, ae@op5.se,
>> tsuna@lrde.epita.fr, git@vger.kernel.org, make-w32@gnu.org
>>
>> I believe the hassle is that readdir doesn't necessarily report a README in
>> a directory which is supposed to have a README, when it has a readme
>> instead.
>
> Sorry I'm asking potentially stupid questions out of ignorance: why
> would you want readdir to return `README' when you have `readme'?
>
>> I think we want O(n) comparison of sorted lists, which doesn't
>> work if equivalent names don't sort the same.
>
> You comparison function should be case-insensitive on Windows, or am
> I missing something?
Well, are "I" and "i" the same letters? What about "İ" and "i"? Or
"I" and "ı"? What about Greek where uppercasing loses accents
(actually not unusual in literate French, either). And what about
German ß and SS/SZ?
"case-insensitive" is a simple word, but the devil is in the details,
and that means basically requiring a system-provided sorting function.
And actually the _killer_ detail here is that git _must_ have the same
sorting order on every platform, since the order of files in a
directory tree affects its SHA-1 sum. So a system-dependent sorting
order breaks git interoperability.
--
David Kastrup, Kriemhildstr. 15, 44793 Bochum
^ permalink raw reply
* Re: How to Import a bitkeeper repo into git
From: Pete/Piet Delaney @ 2007-10-16 6:05 UTC (permalink / raw)
To: Marco Costalba; +Cc: Linus Torvalds, VMiklos, free cycle, git
In-Reply-To: <e5bfff550710152156t33ba10dam6171e3210c18d3ac@mail.gmail.com>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Marco Costalba wrote:
Hi Marco:
> On 10/16/07, Pete/Piet Delaney <pete@bluelane.com> wrote:
>> I just download 'meld', looks interesting, I didn't know about it or
>> 'kompare'. Linking either one into gitk would be a pleasant graphical
>> 'bling'.
>>
>
> In case you are interested a git GUI viewer called qgit can spawn
> 'Kompare' , 'Meld' or any other diff tool that support 'two files'
> command line interface:
>
> $my_preferred_diff_tool file1.txt file2.txt
>
> And they will show what you are looking for. The input files are
> prepared by qgit that also handles the housekeeping at the end.
Great, I installed Qgit version 1.5.3 a while ago, I didn't
notice these advantages over gitq.
Yea, I just noticed, if I pull down External Diff in the files
window it tosses the diffs to Kompare. Super!
> Another feature you asked, i.e. CTRL + right click to select a
> revision (different from the parent) to diff against the current one
> is also already implemented.
It's not quite a intuitive/familiar as with bitkeeper. I suspect I just
need some practice. I selected a huge list if files that we use to
filter the release with and double clicked on the file I thought showing
to focus on that file. The I pulled down External Diff and it took for
ever; like it's confused.
Often we/I want to see the rev history for a particular file.
How would you do that with Qgit?
>
> And of course the two above features can be integrated: you select two
> random revisions and then call the external diff viewer to check at
> the differences in the way you prefer.
Can I see just the revs for a particular file?
>
> It is possible to download qgit from
>
> http://sourceforge.net/project/showfiles.php?group_id=139897
I'll get the latest and greatest. Thinks. Often the problem is
having the current version of Qt3. My workstation is Mandrake
1005 Limited Edition (X11 Xinerama works on this release).
Looks like I have Qt3 on my workstation. Would it be worthwhile
to install Qt4 from src and try to use qgit-2.0?
>
> Two versions:
>
> qgit-1.5.7 is Qt3 based
>
> qgit-2.0 is Qt4 based (works also under Windows)
What new features are in 2.0 over 1.5.7?
Thanks Marco,
- -piet
>
>
>
> regards
> Marco
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFHFFS0JICwm/rv3hoRAlFIAJsEbp22Fs1fGVlt+RIXOOjJ3ZiqIQCeIQ1/
nG/JJUfuNNyoIL2MUJppId4=
=JQWE
-----END PGP SIGNATURE-----
^ permalink raw reply
* What's cooking in git/spearce.git (topics)
From: Shawn O. Pearce @ 2007-10-16 6:04 UTC (permalink / raw)
To: git
Here are the topics that have been cooking. Commits prefixed
with '-' are only in 'pu' while commits prefixed with '+' are
in 'next'. The topics list the commits in reverse chronological
order.
I know there are a number of other topics that I don't have in my
tree yet (bisect improvements, push refspec matching improvements,
option parser). I plan on loading those into 'pu' tomorrow.
In the meantime we have this in next.
* db/fetch-pack (Thu Oct 11 01:47:55 2007 +0100) 58 commits
+ fetch: if not fetching from default remote, ignore default merge
+ Support 'push --dry-run' for http transport
+ Support 'push --dry-run' for rsync transport
+ Fix 'push --all branch...' error handling
+ Fix compilation when NO_CURL is defined
+ Added a test for fetching remote tags when there is not tags.
+ Fix a crash in ls-remote when refspec expands into nothing
+ Remove duplicate ref matches in fetch
... and many more ...
The above commits are all new since Junio's last published next.
About half of them fix known bugs in the builtin-fetch series.
If you are running next, you want these fixes.
I'm actually really happy with this series, but given the set of
bugs that the above commits had to fix I think it needs to cook
more in next before the topic can safely can graduate into master.
* jc/am-quiet (Mon Oct 1 00:27:51 2007 -0700) 2 commits
+ git-am: fix typo in the previous one.
+ git-am: make the output quieter.
I'm also really happy with this change. If nobody objects I may
move it over to master later this week.
* lt/diff-rename (Tue Oct 2 19:28:19 2007 -0700) 1 commit
+ optimize diffcore-delta by sorting hash entries.
* kh/commit (Mon Sep 17 20:06:47 2007 -0400) 4 commits
+ Export rerere() and launch_editor().
+ Introduce entry point add_interactive and add_files_to_cache
+ Enable wt-status to run against non-standard index file.
+ Enable wt-status output to a given FILE pointer.
* js/stash-create (Mon Jul 9 00:51:23 2007 -0700) 2 commits
+ rebase: allow starting from a dirty tree.
+ stash: implement "stash create"
I inherited the above three topics from Junio. I haven't had a
chance to really look at these yet myself to understand what their
status is and how ready they are for master (or not ready as the
case may be).
^ permalink raw reply
* Re: Switching from CVS to GIT
From: Daniel Barkalow @ 2007-10-16 5:56 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: raa.lkml, Johannes.Schindelin, ae, tsuna, git, make-w32
In-Reply-To: <uodezisvg.fsf@gnu.org>
On Tue, 16 Oct 2007, Eli Zaretskii wrote:
> > Date: Mon, 15 Oct 2007 20:45:02 -0400 (EDT)
> > From: Daniel Barkalow <barkalow@iabervon.org>
> > cc: Alex Riesen <raa.lkml@gmail.com>, Johannes.Schindelin@gmx.de, ae@op5.se,
> > tsuna@lrde.epita.fr, git@vger.kernel.org, make-w32@gnu.org
> >
> > I believe the hassle is that readdir doesn't necessarily report a README in
> > a directory which is supposed to have a README, when it has a readme
> > instead.
>
> Sorry I'm asking potentially stupid questions out of ignorance: why
> would you want readdir to return `README' when you have `readme'?
Say the project upstream has the file being "README", but, for some
reason, it has ended up checked out as "readme" in your directory. Since
your filesystem is case insensitive, it's supposed to be the same file,
but when git goes through the list of files in the directory, it sees
"readme", and there's nothing between reachable.h and read-cache.c in the
list of tracked files. We've got a sorted list of filenames we're tracking
along with their most-recently-seen content, and we want to merge the
results of readdir with them, and this is obviously more straightforward
if the filename that's the match for "README" is provided byte-for-byte
the same, and therefore sorts the same.
> > I think we want O(n) comparison of sorted lists, which doesn't
> > work if equivalent names don't sort the same.
>
> You comparison function should be case-insensitive on Windows, or am I
> missing something?
We want both lists sorted, so that we can step through the pair together
and always reach matches together. This requires that the equivalent names
sort together, as well as comparing equal.
> > > > - 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.
> >
> > We want getting stat info, using readdir to figure out what files exist,
> > for 106083 files in 1603 directories with a hot cache to take under 1s;
> > otherwise "git status" takes a noticeable amount of time with a medium-big
> > project, and we want people to be able to get info on what's changed
> > effectively instantly. My impression is that Windows' native stat and
> > readdir are plenty fast for what normal Windows programs want, but we
> > actually expect reasonable performance on an unreasonably-big
> > metadata-heavy input.
>
> If that's the issue, then it's not a good idea to call `stat' and
> `readdir' on Windows at all. `stat' is a single system call on Posix
> systems, while on Windows it usually needs to go out of its way
> calling half a dozen system services to gather the `struct stat' info.
> You need to call something like FindFirstFile, which can do the job of
> `stat' and `readdir' together (and of `fnmatch', if you need to filter
> only some files) in one go. I don't know whether this will scan 100K
> files under one second (maybe I will try it one of these days), but it
> will definitely be faster than `readdir'+`stat' by maybe as much as an
> order of magnitude.
Ah, that's helpful. We don't actually care too much about the particular
info in stat; we just want to know quickly if the file has changed, so we
can hash only the ones that have been touched and get the actual content
changes.
> > > > - no real "mmap" (which kills perfomance and complicates code)
> > >
> > > You only need mmap because you are accustomed to use it on GNU/Linux.
> >
> > I believe the need here is quick setup and fast access to sparse portions
> > of several 100M files. It's hard to beat a page fault for read speed.
>
> If you need memory-mapped files, they are available on Windows. I
> thought the original comment about `mmap' was because it was used to
> allocate memory, not read files into memory.
No, we get our memory with malloc like normal people. The mmap is because
we want to feed files and parts of files to zlib, and mmap makes that
easy.
> > We also expect to be able to make a sequence of file system operations
> > such that programs starting at any time see the same database as the files
> > containing the database get restructured.
>
> Sorry, I don't understand this; please tell more about the operations,
> ``the same database'' issue (what database?) and what do you mean by
> ``the files containing the database get restructured''.
Git is built around a database of objects, which includes "blobs" (file
content), "trees" (directory structure), "commits" (history linkage), and
"tags" (additional annotations). Each of these objects gets hashed, and is
referenced by hash. So we need to be able to get the object with a given
hash quickly, and write an object and take its hash (ideally, stream the
write and find out the hash at the end, with the database key set at that
point). Also, this database should be compressed effectively, because it
ought to compress really well, since a lot of the blobs and trees are only
slightly different from other blobs or trees (by whatever changes were
made between that revision and other revisions).
The current implementation of the persistant storage of this database is a
bit complicated, with the goal being that creating objects is really fast,
and looking up objects doesn't degrade too quickly, and there are
optimization operations available that take some time and speed up future
lookups and reduce the storage overhead (especially so that data can be
transferred efficiently). The tricky thing is that, while the optimization
process is running, other programs may be reading the database, so (1) the
files that are no longer needed, because better-optimized versions are in
place, may be open in another task, and (2) complete and correct new
files have to appear and be such that pre-existing tasks will find them
before old files can be removed. The optimization creates "pack files" and
"pack indices", where the pack file has a lot of objects with delta
compression between them and zlib compression of them, and the index files
tell where everything in the pack file is. So we mmap the index files to
search through, and mmap portions of the pack files to get the data out
of, and we may be using them as they're replaced with more comprehensive
pack files by another task.
Now, it's entirely possible that a completely different database
implementation would be better on Windows, but our current one does a lot
of creating files under different names, moving them to names where
they'll be seen (since this is atomic under POSIX, and partial files are
never seen by other tasks). Also, once we have new files in place, we
unlink the files that they replace, so that new tasks will use the new
ones and tasks that already have old ones open can still get the data out
of them. Also, the files generally get mmaped,
> > A unixy pipeline was convenient
>
> Windows supports pipelines with almost 100% the same functionality as
> Posix. Again, perhaps I'm missing something.
I'm probably the one missing something here; I don't really know anything
about Windows, and I only know what code other people have had problems
porting. Mostly what we use for IPC is pipelines, so, if they work well, I
don't know what the problem is.
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* What's in git/spearce.git (stable)
From: Shawn O. Pearce @ 2007-10-16 5:56 UTC (permalink / raw)
To: git
* The 'maint' branch has these fixes since the last announcement.
Please note that the last announcement was from Junio and was
for the 1.5.3.4 release.
Frank Lichtenheld (1):
git-config: don't silently ignore options after --list
Gerrit Pape (1):
git-config: handle --file option with relative pathname properly
Jean-Luc Herren (2):
git add -i: Fix parsing of abbreviated hunk headers
git add -i: Remove unused variables
Johannes Schindelin (2):
clear_commit_marks(): avoid deep recursion
rebase -i: use diff plumbing instead of porcelain
Linus Torvalds (2):
Fix embarrassing "git log --follow" bug
Clean up "git log" format with DIFF_FORMAT_NO_OUTPUT
Mathias Megyei (1):
Do not remove distributed configure script
Michele Ballabio (2):
git-reflog: document --verbose
git-archive: document --exec
Shawn O. Pearce (1):
Whip post 1.5.3.4 maintenance series into shape.
* The 'master' branch has these since the last announcement
in addition to the above.
Alex Riesen (1):
fix t5403-post-checkout-hook.sh: built-in test in dash does not
have "=="
Brandon Casey (2):
git-gc: by default use safer "-A" option to repack when not
--prune'ing
git-gc --auto: simplify "repack" command line building
Brian Ewins (2):
Add a --dry-run option to git-send-pack.
Add a --dry-run option to git-push.
Eygene Ryabinkin (1):
git-svn: respect Subversion's [auth] section configuration values
Frederick Akalin (1):
gtksourceview2 support for gitview
Jeff King (1):
git-rebase: document suppression of duplicate commits
Jeff Muizelaar (1):
fix contrib/hooks/post-receive-email hooks.recipients error message
Johannes Schindelin (2):
Support cvs via git-shell
cvsexportcommit: get rid of temporary directory
Josh England (1):
Minor usage update in setgitperms.perl
Kristof Provost (1):
makefile: Add a cscope target
Marius Storm-Olsen (1):
Add 'git-p4 commit' as an alias for 'git-p4 submit'
Michael Gebetsroither (1):
hg-to-git speedup through selectable repack intervals
Michael Olson (1):
Documentation/git-tag.txt: Document how to backdate tags
Michael W. Olson (1):
git-rebase--interactive.sh: Quote arguments to test
Mike Dalessio (2):
instaweb: allow for use of auto-generated scripts
instaweb: support for Ruby's WEBrick server
Pierre Habouzit (1):
Fix in-place editing functions in convert.c
Ralf Wildenhues (6):
manual: Fix or remove em dashes.
Fix some typos, punctuation, missing words, minor markup.
Fix wording in push definition.
manual: Fix example finding commits referencing given content.
manual: add some markup.
manual: use 'URL' instead of 'url'.
^ permalink raw reply
* Re: [PATCH 0/7] Bisect dunno
From: David Kastrup @ 2007-10-15 20:47 UTC (permalink / raw)
To: Geert Bosch
Cc: David Symonds, Wincent Colaiuta, Johan Herland, git,
Marius Storm-Olsen, Christian Couder, René Scharfe,
Junio Hamano, Johannes Schindelin
In-Reply-To: <0C82FD96-2CF9-4E66-91EB-DBC2CFF003E8@adacore.com>
Geert Bosch <bosch@adacore.com> writes:
> On Oct 15, 2007, at 13:53, David Symonds wrote:
>> That's also why I suggested "skip"; you might not be able to test a
>> particular commit, but you might also not *want* to test a particular
>> commit for some reason.
>
> Skip seems a great choice: it directly expresses the wish to
> not consider a certain commit. The reason is unimportant.
But it is an _action_, while "good" and "bad" are properties.
--
David Kastrup, Kriemhildstr. 15, 44793 Bochum
^ permalink raw reply
* A note from the interim Git maintainer
From: Shawn O. Pearce @ 2007-10-16 5:54 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano
As most folks are probably now well aware, Junio has been offline
for about 11 days and may still be offline for a little while more.
Before he dropped offline Junio shared why he left on such a short
notice with both Dscho and myself, as it meant cancelling the
"git together" we were planning to have last weekend in San Jose.
I'm not going to get into the specific details as it is Junio's
business and not mine. But I can say that my thoughts and prayers
to $DEITY are with him and his family at this time, and I don't
expect him to be rushing back to git work tomorrow. However I'm
quite certain that Junio will return when he can.
Lars Hjemli has done a terrific job of stacking up patches from the
mailing list in his "q/*" branches, available for fetching directly
from his tree at [*1*]. I really want to thank Lars for stepping
up and doing this, as I think it has helped the community.
Unfortunately there were quite a few q/* branches, some of which
were not trivial to merge against the other topics that were already
pending in Junio's next. Someone really needed to go through the
branches and merge them together into suitable maint, master and
next branches.
I've decided to step up and try to fill Junio's shoes. To that end
I am publishing a maint, master, next (and soon) pu branch from a
new fork on repo.or.cz:
gitweb: http://repo.or.cz/w/git/spearce.git
git: git://repo.or.cz/git/spearce.git
http://repo.or.cz/r/git/spearce.git
Traditional "What's in" messages will be sent in a minute. I'm
going to try to apply the exact same policies that Junio applies
to these, so maint/master/next won't rewind, but pu may.
I based my branches on top of the last items published by Junio,
and am hoping that he will be open to pulling directly from these
before he starts working again. Junio obviously has the option
not to pull from me, but if I do my job of interim maintainer well
I can probably talk him into it. :)
I won't be publishing a tagged release from maint or master anytime
soon. Primarily because I don't think its time to do that, and also
because I don't have a kernel.org account to upload the tarballs to.
If a month goes by without Junio, well, lets just see what happens.
I probably don't need to say this for the git regulars, but you
can start to track my published branches yourself with git-remote
if you are interested in testing and/or using these versions:
$ git remote add -f spearce git://repo.or.cz/git/spearce.git
$ git pull spearce master ; # or next
*1* git://hjemli.net/pub/git/git
--
Shawn.
^ permalink raw reply
* [PATCH] git-p4 support for perforce renames.
From: Chris Pettitt @ 2007-10-16 5:15 UTC (permalink / raw)
To: Simon Hausmann, Git Mailing List; +Cc: Chris Pettitt
In-Reply-To: <de47e4420710152214k1e74bf5eh5ecbf48d0507322@mail.gmail.com>
The current git-p4 implementation does support file renames. However, because
it does not use the "p4 integrate" command, the history for the renamed file is
not linked to the new file.
This changeset adds support for perforce renames with the integrate command.
Currently this feature is only enabled when calling git-p4 submit with the -M
option. This is intended to look and behave similar to the "detect renames"
feature of other git commands.
The following sequence is used for renamed files:
p4 integrate -Dt x x'
p4 edit x'
rm x'
git apply
p4 delete x
By default, perforce will not allow an integration with a target file that has
been deleted. That is, if x' in the example above is the name of a previously
deleted file then perforce will fail the integrate. The -Dt option tells
perforce to allow the target of integrate to be a previously deleted file.
Signed-off-by: Chris Pettitt <cpettitt@gmail.com>
---
contrib/fast-import/git-p4 | 12 +++++++++++-
1 files changed, 11 insertions(+), 1 deletions(-)
diff --git a/contrib/fast-import/git-p4 b/contrib/fast-import/git-p4
index 557649a..90945b7 100755
--- a/contrib/fast-import/git-p4
+++ b/contrib/fast-import/git-p4
@@ -399,6 +399,7 @@ class P4Submit(Command):
optparse.make_option("--dry-run", action="store_true"),
optparse.make_option("--direct", dest="directSubmit", action="store_true"),
optparse.make_option("--trust-me-like-a-fool", dest="trustMeLikeAFool", action="store_true"),
+ optparse.make_option("-M", dest="detectRename", action="store_true"),
]
self.description = "Submit changes from git to the perforce depot."
self.usage += " [name of git branch to submit into perforce depot]"
@@ -411,6 +412,7 @@ class P4Submit(Command):
self.origin = ""
self.directSubmit = False
self.trustMeLikeAFool = False
+ self.detectRename = False
self.verbose = False
self.isWindows = (platform.system() == "Windows")
@@ -491,7 +493,8 @@ class P4Submit(Command):
diff = self.diffStatus
else:
print "Applying %s" % (read_pipe("git log --max-count=1 --pretty=oneline %s" % id))
- diff = read_pipe_lines("git diff-tree -r --name-status \"%s^\" \"%s\"" % (id, id))
+ diffOpts = ("", "-M")[self.detectRename]
+ diff = read_pipe_lines("git diff-tree -r --name-status %s \"%s^\" \"%s\"" % (diffOpts, id, id))
filesToAdd = set()
filesToDelete = set()
editedFiles = set()
@@ -509,6 +512,13 @@ class P4Submit(Command):
filesToDelete.add(path)
if path in filesToAdd:
filesToAdd.remove(path)
+ elif modifier == "R":
+ src, dest = line.strip().split("\t")[1:3]
+ system("p4 integrate -Dt \"%s\" \"%s\"" % (src, dest))
+ system("p4 edit \"%s\"" % (dest))
+ os.unlink(dest)
+ editedFiles.add(dest)
+ filesToDelete.add(src)
else:
die("unknown modifier %s for %s" % (modifier, path))
--
1.5.3.4.206.g58ba4
^ permalink raw reply related
* Re: Switching from CVS to GIT
From: Andreas Ericsson @ 2007-10-16 5:14 UTC (permalink / raw)
To: Eli Zaretskii
Cc: Daniel Barkalow, raa.lkml, Johannes.Schindelin, tsuna, git,
make-w32
In-Reply-To: <uodezisvg.fsf@gnu.org>
Eli Zaretskii wrote:
>> Date: Mon, 15 Oct 2007 20:45:02 -0400 (EDT)
>> From: Daniel Barkalow <barkalow@iabervon.org>
>> cc: Alex Riesen <raa.lkml@gmail.com>, Johannes.Schindelin@gmx.de, ae@op5.se,
>> tsuna@lrde.epita.fr, git@vger.kernel.org, make-w32@gnu.org
>>
>> I believe the hassle is that readdir doesn't necessarily report a README in
>> a directory which is supposed to have a README, when it has a readme
>> instead.
>
> Sorry I'm asking potentially stupid questions out of ignorance: why
> would you want readdir to return `README' when you have `readme'?
>
Because it might have been checked in as README, and since git is case
sensitive that is what it'll think should be there when it reads the
directories. If it's not, users get to see
removed: README
untracked: readme
and there's really no easy way out of this one, since users on a case-
sensitive filesystem might be involved in this project too, so it
could be an intentional rename, but we don't know for sure. Just
clobbering the in-git file is wrong, but overwriting a file on disk
is wrong too. git tries hard to not ever lose any data for the user.
>
>>>> - 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.
>> We want getting stat info, using readdir to figure out what files exist,
>> for 106083 files in 1603 directories with a hot cache to take under 1s;
>> otherwise "git status" takes a noticeable amount of time with a medium-big
>> project, and we want people to be able to get info on what's changed
>> effectively instantly. My impression is that Windows' native stat and
>> readdir are plenty fast for what normal Windows programs want, but we
>> actually expect reasonable performance on an unreasonably-big
>> metadata-heavy input.
>
> If that's the issue, then it's not a good idea to call `stat' and
> `readdir' on Windows at all. `stat' is a single system call on Posix
> systems, while on Windows it usually needs to go out of its way
> calling half a dozen system services to gather the `struct stat' info.
> You need to call something like FindFirstFile, which can do the job of
> `stat' and `readdir' together (and of `fnmatch', if you need to filter
> only some files) in one go. I don't know whether this will scan 100K
> files under one second (maybe I will try it one of these days), but it
> will definitely be faster than `readdir'+`stat' by maybe as much as an
> order of magnitude.
>
To be honest though, there are so many places which do the readdir+stat
that I don't think it'd be worth factoring it out, especially since it
*works* on windows. It's just slow, and only slow compared to various
unices. I *think* (correct me if I'm wrong) that git is still faster
than a whole bunch of other scm's on windows, but to one who's used to
its performance on Linux that waiting several seconds to scan 10k files
just feels wrong.
>> We also expect to be able to make a sequence of file system operations
>> such that programs starting at any time see the same database as the files
>> containing the database get restructured.
>
> Sorry, I don't understand this; please tell more about the operations,
> ``the same database'' issue (what database?)
The object database, located under .git/objects.
> and what do you mean by
> ``the files containing the database get restructured''.
>
/* I'm on a limb here. Nicolas Pitre knows the git packfile format, so
* perhaps he'll be kind enough to correct me if I'm wrong */
The mmap() stuff is primarily convenient when reading huge packfiles. As
far as I understand it, they're ordered by some sort of delta similarity
score, so mmap()'ing 100MiB or so of a certain packfile will most likely
mean we have a couple of thousand "connected" revisions in memory. That
database gets sort of restructured as the memory-chunk that's mmap()'ed
get moved to read in the next couple of thousand revisions.
In all honesty, this doesn't matter much for already fully packed projects
unless they're significantly larger than the Linux kernel, since git is so
amazingly good at compressing large repos to a small size. Linux is ~180
MiB fully packed, and most developer's systems could just read() that
entire packfile into memory without much problem. But then again, no-one's
ever had problems supporting the "normal" cases.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: How to Import a bitkeeper repo into git
From: Marco Costalba @ 2007-10-16 4:56 UTC (permalink / raw)
To: pete; +Cc: Linus Torvalds, VMiklos, free cycle, git
In-Reply-To: <471433F3.40606@bluelane.com>
On 10/16/07, Pete/Piet Delaney <pete@bluelane.com> wrote:
>
> I just download 'meld', looks interesting, I didn't know about it or
> 'kompare'. Linking either one into gitk would be a pleasant graphical
> 'bling'.
>
In case you are interested a git GUI viewer called qgit can spawn
'Kompare' , 'Meld' or any other diff tool that support 'two files'
command line interface:
$my_preferred_diff_tool file1.txt file2.txt
And they will show what you are looking for. The input files are
prepared by qgit that also handles the housekeeping at the end.
Another feature you asked, i.e. CTRL + right click to select a
revision (different from the parent) to diff against the current one
is also already implemented.
And of course the two above features can be integrated: you select two
random revisions and then call the external diff viewer to check at
the differences in the way you prefer.
It is possible to download qgit from
http://sourceforge.net/project/showfiles.php?group_id=139897
Two versions:
qgit-1.5.7 is Qt3 based
qgit-2.0 is Qt4 based (works also under Windows)
regards
Marco
^ permalink raw reply
* [PATCH] git-p4 support for perforce renames.
From: Chris Pettitt @ 2007-10-16 4:37 UTC (permalink / raw)
To: Simon Hausmann, Git Mailing List; +Cc: Chris Pettitt
The current git-p4 implementation does support file renames. However, because
it does not use the "p4 integrate" command, the history for the renamed file is
not linked to the new file.
This changeset adds support for perforce renames with the integrate command.
Currently this feature is only enabled when calling git-p4 submit with the -M
option. This is intended to look and behave similar to the "detect renames"
feature of other git commands.
The following sequence is used for renamed files:
p4 integrate -Dt x x'
p4 edit x'
rm x'
git apply
p4 delete x
By default, perforce will not allow an integration with a target file that has
been deleted. That is, if x' in the example above is the name of a previously
deleted file then perforce will fail the integrate. The -Dt option tells
perforce to allow the target of integrate to be a previously deleted file.
Signed-off-by: Chris Pettitt <cpettitt@gmail.com>
---
contrib/fast-import/git-p4 | 12 +++++++++++-
1 files changed, 11 insertions(+), 1 deletions(-)
diff --git a/contrib/fast-import/git-p4 b/contrib/fast-import/git-p4
index 557649a..f9a8871 100755
--- a/contrib/fast-import/git-p4
+++ b/contrib/fast-import/git-p4
@@ -399,6 +399,7 @@ class P4Submit(Command):
optparse.make_option("--dry-run", action="store_true"),
optparse.make_option("--direct", dest="directSubmit", action="store_true"),
optparse.make_option("--trust-me-like-a-fool", dest="trustMeLikeAFool", action="store_true"),
+ optparse.make_option("-M", dest="detectRename", action="store_true"),
]
self.description = "Submit changes from git to the perforce depot."
self.usage += " [name of git branch to submit into perforce depot]"
@@ -411,6 +412,7 @@ class P4Submit(Command):
self.origin = ""
self.directSubmit = False
self.trustMeLikeAFool = False
+ self.detectRename = False
self.verbose = False
self.isWindows = (platform.system() == "Windows")
@@ -491,7 +493,8 @@ class P4Submit(Command):
diff = self.diffStatus
else:
print "Applying %s" % (read_pipe("git log --max-count=1 --pretty=oneline %s" % id))
- diff = read_pipe_lines("git diff-tree -r --name-status \"%s^\" \"%s\"" % (id, id))
+ diffOpts = ("", "-M")[self.detectRename]
+ diff = read_pipe_lines("git diff-tree -r --name-status %s \"%s^\" \"%s\"" % (diffOpts, id, id))
filesToAdd = set()
filesToDelete = set()
editedFiles = set()
@@ -509,6 +512,13 @@ class P4Submit(Command):
filesToDelete.add(path)
if path in filesToAdd:
filesToAdd.remove(path)
+ elif modifier == "R":
+ src, dest = line.strip().split("\t")[1:3]
+ system("p4 integrate -Dt \"%s\" \"%s\"" % (src, dest))
+ system("p4 edit \"%s\"" % (dest))
+ system("rm \"%s\"" % dest)
+ editedFiles.add(dest)
+ filesToDelete.add(src)
else:
die("unknown modifier %s for %s" % (modifier, path))
--
1.5.3.4.206.g58ba4
^ permalink raw reply related
* [PATCH] git-p4 support for perforce renames.
From: Chris Pettitt @ 2007-10-16 4:35 UTC (permalink / raw)
To: Simon Hausmann, Git Mailing List; +Cc: Chris Pettitt
The current git-p4 implementation does support file renames. However, because
it does not use the "p4 integrate" command, the history for the renamed file is
not linked to the new file.
This changeset adds support for perforce renames with the integrate command.
Currently this feature is only enabled when calling git-p4 submit with the -M
option. This is intended to look and behave similar to the "detect renames"
feature of other git commands.
The following sequence is used for renamed files:
p4 integrate -Dt x x'
p4 edit x'
rm x'
git apply
p4 delete x
By default, perforce will not allow an integration with a target file that has
been deleted. That is, if x' in the example above is the name of a previously
deleted file then perforce will fail the integrate. The -Dt option tells
perforce to allow the target of integrate to be a previously deleted file.
Signed-off-by: Chris Pettitt <cpettitt@gmail.com>
contrib/fast-import/git-p4 | 12 +++++++++++-
1 files changed, 11 insertions(+), 1 deletions(-)
--
1.5.3.4.206.g58ba4
^ permalink raw reply
* Re: Switching from CVS to GIT
From: Eli Zaretskii @ 2007-10-16 4:30 UTC (permalink / raw)
To: Daniel Barkalow; +Cc: raa.lkml, Johannes.Schindelin, ae, tsuna, git, make-w32
In-Reply-To: <Pine.LNX.4.64.0710151859590.7638@iabervon.org>
> Date: Mon, 15 Oct 2007 20:45:02 -0400 (EDT)
> From: Daniel Barkalow <barkalow@iabervon.org>
> cc: Alex Riesen <raa.lkml@gmail.com>, Johannes.Schindelin@gmx.de, ae@op5.se,
> tsuna@lrde.epita.fr, git@vger.kernel.org, make-w32@gnu.org
>
> I believe the hassle is that readdir doesn't necessarily report a README in
> a directory which is supposed to have a README, when it has a readme
> instead.
Sorry I'm asking potentially stupid questions out of ignorance: why
would you want readdir to return `README' when you have `readme'?
> I think we want O(n) comparison of sorted lists, which doesn't
> work if equivalent names don't sort the same.
You comparison function should be case-insensitive on Windows, or am I
missing something?
> > > - 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.
>
> We want getting stat info, using readdir to figure out what files exist,
> for 106083 files in 1603 directories with a hot cache to take under 1s;
> otherwise "git status" takes a noticeable amount of time with a medium-big
> project, and we want people to be able to get info on what's changed
> effectively instantly. My impression is that Windows' native stat and
> readdir are plenty fast for what normal Windows programs want, but we
> actually expect reasonable performance on an unreasonably-big
> metadata-heavy input.
If that's the issue, then it's not a good idea to call `stat' and
`readdir' on Windows at all. `stat' is a single system call on Posix
systems, while on Windows it usually needs to go out of its way
calling half a dozen system services to gather the `struct stat' info.
You need to call something like FindFirstFile, which can do the job of
`stat' and `readdir' together (and of `fnmatch', if you need to filter
only some files) in one go. I don't know whether this will scan 100K
files under one second (maybe I will try it one of these days), but it
will definitely be faster than `readdir'+`stat' by maybe as much as an
order of magnitude.
> > > - no real "mmap" (which kills perfomance and complicates code)
> >
> > You only need mmap because you are accustomed to use it on GNU/Linux.
>
> I believe the need here is quick setup and fast access to sparse portions
> of several 100M files. It's hard to beat a page fault for read speed.
If you need memory-mapped files, they are available on Windows. I
thought the original comment about `mmap' was because it was used to
allocate memory, not read files into memory.
> We also expect to be able to make a sequence of file system operations
> such that programs starting at any time see the same database as the files
> containing the database get restructured.
Sorry, I don't understand this; please tell more about the operations,
``the same database'' issue (what database?) and what do you mean by
``the files containing the database get restructured''.
> A unixy pipeline was convenient
Windows supports pipelines with almost 100% the same functionality as
Posix. Again, perhaps I'm missing something.
^ permalink raw reply
* [PATCH] Bisect: add a "bisect replay" test case.
From: Christian Couder @ 2007-10-16 4:33 UTC (permalink / raw)
To: Junio Hamano, Johannes Schindelin; +Cc: git
Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
---
t/t6030-bisect-porcelain.sh | 7 +++++++
1 files changed, 7 insertions(+), 0 deletions(-)
There is no bisect log/replay test case right now.
Let's add one.
diff --git a/t/t6030-bisect-porcelain.sh b/t/t6030-bisect-porcelain.sh
index 7f41a46..49f3601 100755
--- a/t/t6030-bisect-porcelain.sh
+++ b/t/t6030-bisect-porcelain.sh
@@ -167,6 +167,13 @@ test_expect_success 'bisect dunno: add line and then a new test' '
git bisect dunno &&
git bisect good > my_bisect_log.txt &&
grep "$HASH5 is first bad commit" my_bisect_log.txt &&
+ git bisect log > log_to_replay.txt
+ git bisect reset
+'
+
+test_expect_success 'bisect dunno and bisect replay' '
+ git bisect replay log_to_replay.txt > my_bisect_log.txt &&
+ grep "$HASH5 is first bad commit" my_bisect_log.txt &&
git bisect reset
'
--
1.5.3.3.136.g591d1-dirty
^ permalink raw reply related
* Re: Switching from CVS to GIT
From: Eli Zaretskii @ 2007-10-16 4:16 UTC (permalink / raw)
To: Nguyen Thai Ngoc Duy
Cc: prohaska, git, raa.lkml, ae, tsuna, Johannes.Schindelin
In-Reply-To: <fcaeb9bf0710151924r258dd561hd13c22319d17f80f@mail.gmail.com>
> Date: Tue, 16 Oct 2007 09:24:50 +0700
> From: "Nguyen Thai Ngoc Duy" <pclouds@gmail.com>
> Cc: "Git Mailing List" <git@vger.kernel.org>, "Alex Riesen" <raa.lkml@gmail.com>,
> "Eli Zaretskii" <eliz@gnu.org>, "Andreas Ericsson" <ae@op5.se>,
> tsuna@lrde.epita.fr,
> "Johannes Schindelin" <Johannes.Schindelin@gmx.de>
>
> I did try hard to find the legendary
> zsh for Windows before giving up and porting busybox's ash instead.
Where can one find this port of busybox's ash?
^ permalink raw reply
* [PATCH] rev-list documentation: add "--bisect-all".
From: Christian Couder @ 2007-10-16 3:59 UTC (permalink / raw)
To: Junio Hamano, Johannes Schindelin, Frank Lichtenheld; +Cc: git
Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
---
Documentation/git-rev-list.txt | 16 ++++++++++++++++
1 files changed, 16 insertions(+), 0 deletions(-)
Le lundi 15 octobre 2007, Frank Lichtenheld a écrit :
>
> --bisect-all is still missing a Documentation/ patch.
Thanks for catching that.
Here is a patch.
diff --git a/Documentation/git-rev-list.txt b/Documentation/git-rev-list.txt
index 7cd0e89..f6dd0c4 100644
--- a/Documentation/git-rev-list.txt
+++ b/Documentation/git-rev-list.txt
@@ -34,6 +34,7 @@ SYNOPSIS
[ \--pretty | \--header ]
[ \--bisect ]
[ \--bisect-vars ]
+ [ \--bisect-all ]
[ \--merge ]
[ \--reverse ]
[ \--walk-reflogs ]
@@ -354,6 +355,21 @@ the expected number of commits to be tested if `bisect_rev`
turns out to be bad to `bisect_bad`, and the number of commits
we are bisecting right now to `bisect_all`.
+--bisect-all::
+
+This outputs all the commit objects between the included and excluded
+commits, ordered by their distance to the included and excluded
+commits. The farthest from them is displayed first. (This is the only
+one displayed by `--bisect`.)
+
+This is usefull because it makes it easy to choose a good commit to
+test when you want to avoid to test some of them for some reason (they
+may not compile for example).
+
+This option can be used along with `--bisect-vars`, in this case,
+after all the sorted commit objects, there will be the same text as if
+`--bisect-vars` has been used alone.
+
--
Commit Ordering
--
1.5.3.4.213.g68ad5
^ permalink raw reply related
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