* 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
* Re: How to Import a bitkeeper repo into git
From: Pete/Piet Delaney @ 2007-10-16 3:45 UTC (permalink / raw)
To: Linus Torvalds; +Cc: VMiklos, free cycle, git
In-Reply-To: <alpine.LFD.0.999.0710151711280.6887@woody.linux-foundation.org>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Linus Torvalds wrote:
>
> On Mon, 15 Oct 2007, Pete/Piet Delaney wrote:
>> I imported the CVS repository to git and it worked great. Since all
>> of our other repository are in bitkeeper the management would like to
>> stick with CVS. With git apparently still being weak in the area of
>> supporting difftool on different version that seems somewhat reasonable
>> for the time being.
>
> I can't see how bk's difftool could possibly have any relevance to the
> "reasonable to stick with CVS" decision, but hey, I'm always surprised by
> peoples inventiveness in rationalizing their decisions ;)
>
> I don't know what difftool does that a simple
>
> git diff -U99 | viewdiff -
Sigh, no help for git diff.
>
> wouldn't do, but in all honesty, I don't think I ever used difftool (I
> found the other tools in bk much more useful - eg mergetool, renametool)
Wondering if adding a file dimension to gitk might help and adding the
ability to diff different version of a file git gitk by doing something
like holding down the shift key and/or adding a new view pull down.
>
> I don't actually know of any sane programs to view unified diffs, but you
> can script one with little trouble. Here's a really hacky one I just came
> up with:
>
> #!/bin/sh
> cat "$@" > /tmp/diff
> grep '^[ -]' /tmp/diff > /tmp/orig
> grep '^[ +]' /tmp/diff > /tmp/result
> meld /tmp/orig /tmp/result
>
> which fools 'meld' into showing a unified diff in a nice graphical manner.
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'.
>
> [ Quite frankly, I don't understand why tools like meld and kdiff3 can't
> just take the unified diff directly - they have *all* the logic, it
> should be trivial to do, and very useful to view diffs for those people
> who like that graphical bling. ]
>
>> The folks at bitmover are converting you kernels to bk and it's
>> maintaining the branch history and I'd like to do the same. So far
>> they haven't help us convert the git repository to bk. Do you happen
>> to know of someone else that might now how to do this in case the
>> folks at bitmover can't provide the scripts to convert this git
>> repository to bk?
>
> Hmm. Converting from git to bk should not be that hard at least
> conceptually, but no, I have no idea how to script it sanely and
> efficiently. The obvious solutions all would want to have multiple active
> heads of development open at the same time (Larry calls them "LOD's" not
> branches), and would also require some way to set the result of a merge.
> Neither of which I would know how to do in BK (I created a lot of merges
> in BK, but I always let BK do the merging - I wouldn't know how to specify
> the merge result by hand).
Hmm, actually I'm only seeing rev topology up to 2.6.13,
later version seem to be linear and when I try to use a larger
time window something seems to crashing, the gui goes away,
and 'bk revtool' returns. Sigh.
I'll try keeping it real simple and just import our release branch
and hope for the best. Hopefully Johnannes, or perhaps folks more
involved with gitk can add a bit more graphical bling soon to the
cheetah release. BTW, is this the right mailing list for discussing
gitk as well as git?
- -piet
>
> Linus
> -
> 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
>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFHFDPyJICwm/rv3hoRAsU0AJ9o6rHtu5rkiUeNlheRNUpwd4bfagCdHEK8
hDeVvRCyD8Xf8INbdMpuDDU=
=XB2c
-----END PGP SIGNATURE-----
^ permalink raw reply
* Re: [PATCH 0/7] Bisect dunno
From: Christian Couder @ 2007-10-16 3:41 UTC (permalink / raw)
To: David Symonds
Cc: Marius Storm-Olsen, David Kastrup, Wincent Colaiuta,
René Scharfe, Junio Hamano, Johannes Schindelin, git
In-Reply-To: <ee77f5c20710142315j192b9f65m22d7980769a46cec@mail.gmail.com>
Le lundi 15 octobre 2007, David Symonds a écrit :
> On 15/10/2007, Marius Storm-Olsen <marius@trolltech.com> wrote:
> > David Kastrup said the following on 14.10.2007 19:48:
> > > "unknown" clearly is much better than "dunno" though even if my own
> > > favorite would be "undecided".
> >
> > What then about a good'ol programming favorite, "void"? :-)
>
> "skip"? That would make semantic sense, right?
Yeah, or "avoid".
Christian.
^ permalink raw reply
* should git command and git-command be equivalent?
From: franky @ 2007-10-16 3:22 UTC (permalink / raw)
To: git
I use git-init frequently and it confuses me for a long time that I
can't init a bare repository.
I just found I can do that by "git -bare init". However, I get used
to "git-init" and I always tried "git-init -bare" (of course failed)
And I thought git-init and "git init" were always the same as most
newbies of git. So, should git init and git-init be equivalent? If not, I
think the document should be supplemented to clarify this.
franky
^ permalink raw reply
* Is there any plan to support partial checkout or submoudule improvement?
From: franky @ 2007-10-16 3:20 UTC (permalink / raw)
To: git
Here is my pain when using git without partial checkout and submodule
improvement.
I want to manage src and compiled bin together consistently. And
when deploying, I don't need the src directory.
My directory structure is like
Project
Src
Bin
Following is two schemes I have considered
1. src, bin as two submoudles
When changes are made in src, compiled binaries are put in bin
directory. So when I commit, I have to commit 3 times and write 3 commit
comments separately (in Project, src, bin).
I think if some improvement in submodule, this problem can be
avoided. For example, when committing in Project directory, all changes in
submoules are also automatically committed. Maybe a new subcommand
"git-submodule commit" to commit all submodules but share a single comment
and "git-commit -A" to commit both files and submodule?
2. src, bin not submoudle, just sub directory
When src changes, compiled binaries are still put in bin directory.
However, only one commit is required. Perfect? No, another problem when
deploying. I don't want the src directory to appear in the deployment
directory. However, without partial checkout, I can't do that, since every
time bin and src directories are checked out together.
^ permalink raw reply
* Re: Git User's Survey 2007 unfinished summary continued
From: Nicolas Pitre @ 2007-10-16 2:48 UTC (permalink / raw)
To: Shawn O. Pearce
Cc: Steven Grimm, Reece Dunn, Linus Torvalds, Johannes Schindelin,
J. Bruce Fields, Jakub Narebski, git
In-Reply-To: <20071015232017.GS27899@spearce.org>
On Mon, 15 Oct 2007, Shawn O. Pearce wrote:
> Nicolas Pitre <nico@cam.org> wrote:
> > BTW I have patches here reworking the progress code for a more compact
> > display which should mitigate this issue quite a bit.
>
> git-gui is scraping the output of the current progress meter using
> a regex and then building a graphical progress bar from that output.
Erk!
> Any change in how git produces the progress bar should still keep
> it in a form that git-gui can regex match and scrape, preferably
> without needing to know what version of git it is pulling that
> output from. For example just teach git-gui to try two different
> regexps, new format and if that doesn't match then try the old
> (aka current) format.
I think my new format might be easier for you as the "title" and the
actual percentage and count is now on the same line.
Nicolas
^ permalink raw reply
* Re: [PATCH] Git homepage: remove all the references to Cogito
From: Petr Baudis @ 2007-10-16 2:19 UTC (permalink / raw)
To: Paolo Ciarrocchi; +Cc: git
In-Reply-To: <20071015233800.6306e414@paolo-desktop>
On Mon, Oct 15, 2007 at 11:38:00PM +0200, Paolo Ciarrocchi wrote:
> @@ -286,15 +285,6 @@ a gitweb interface, at <a href="http://repo.or.cz/">http://repo.or.cz/</a>.</p>
>
> <dl>
>
> -<dt id="cogito">Cogito</dt>
> -<dd>
> -<a href="http://git.or.cz/cogito/">Cogito</a>
> -is a popular version control system on top of Git.
> -It aims at seamless user interface and ease of use, providing
> -generally smoother user experience than the "raw" Git interface
> -and indeed also many other version control systems. However, it
> -also lacks many advanced capabilities of Git and is currently
> -being slowly phased out.</dd>
>
> <dt id="stgit">StGIT</dt>
> <dd><a href="http://www.procode.org/stgit/">Stacked Git</a> provides
I'm not sure this is good idea, Cogito is still quite frequently used
and it should be documented that it exists.
--
Petr "Pasky" Baudis
Early to rise and early to bed makes a male healthy and wealthy and dead.
-- James Thurber
^ permalink raw reply
* Re: Switching from CVS to GIT
From: Nguyen Thai Ngoc Duy @ 2007-10-16 2:24 UTC (permalink / raw)
To: Steffen Prohaska
Cc: Git Mailing List, Alex Riesen, Eli Zaretskii, Andreas Ericsson,
tsuna, Johannes Schindelin
In-Reply-To: <7287AD62-3274-4B20-881C-D02E08C4B2EF@zib.de>
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.
> Steffen
>
> [1] http://www.gnuarch.org/gnuarchwiki/Native_WIN32_Support
> [2] http://unxutils.sourceforge.net/
> -
> 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
>
--
Duy
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox