* [ANNOUNCE] TortoiseGit 0.4.1.0 release
From: Frank Li @ 2009-03-05 15:10 UTC (permalink / raw)
To: tortoisegit-dev, tortoisegit-users, git, tortoisegit-announce
TortoiseGit 0.3.3 released.
http://code.google.com/p/tortoisegit/downloads/list
Features:
*Full Overlay Icon Support.
Show "Conflict, ignore file, untracked file, modified, Add, staged"
icon according to file status.
*Rebase Support.
Support "Pick" "Sqaush" "Edit" and "Skip" commit when
rebase branch.
Support abort.
*Combine Multi-commits to one commit.
Combine continous commits to one commit. The limition is the only
single line(no merge point) above combined commit.
*Cherry Pick multi commits.
User can use multi commits at log dialog and then choose cherry pick
these. Cherry Pick dialog guide you finish whole work.
Support "Pick" "Squash" "Edit" and "Skip" commits.
*First x64 version.
*Support version "browse" at switch, export, new branch/tag and merge dialogs.
*Add context menu item "Revert" at Commit dialog File List.
*Show bold font for HEAD at log dialog.
*Add "Whole Project" checkbox at commit dialog
*First Version Help Document.
Bug Fix:
*Fix issue 36, Push not working if no remote branch is specified
*Default UnCheck untrack file at commit dialog
*Issue 40: Commit from subfolder shows unversioned files in parent
*Fix diff problem when filenames have embedded spaces
*Fix Issue 24,45, Commit results not in window with scroll bars
*Fix for win2k context menu icons
*Fix Issue 46, The about window title still displays TortoiseSVN
*Fix Issue 37, When the file name contains Chinese char, Diff doesn't work.
*Fix Issue 28, "Add" status icon overlay is not correct.
*Fixed x64 build of TortoiseProc crashed due to
received unexpected messages
*Fix tag to head when *force* check box checked
*Add Git document to help
Known Issue:
*Git clone can't support git protocol. SSH need enable
TortoisePLink
as SSH client. User should use setting dialog network
page to setup
TortoisePLink as SSH client.
*Git clone can't capture TortoisePLink output. So there are no
progress info during download from remote repository.
*64bit setup package can not auto installed MFC 9.0
and ATL 9.0 Redistribute package.
Work around: install MFC 9.0 and ATL 9.0 redistribute
package before install 64bit tortoisegit.
^ permalink raw reply
* Re: [PATCH] http authentication via prompts
From: Mike Gaffney @ 2009-03-05 15:15 UTC (permalink / raw)
To: git
In-Reply-To: <alpine.DEB.1.00.0903051149280.6524@intel-tinevez-2-302>
My thought was that if you had a password you didn't care about you could put it in the config.
It does ask you for a password with getpass, It compiles under cygwin, I havent tried it under
windows. However the man page for getpass shows the source so coding up getpass directly isn't a
big deal.
Junio, I'm new to this patch game and using Thunderbird. What's the best way
to wrap the patch?
-Mike
Johannes Schindelin wrote:
> Hi,
>
> Disclaimer: if you are offended by constructive criticism, or likely to
> answer with insults to the comments I offer, please stop reading this mail
> now (and please do not answer my mail, either). :-)
>
> Still with me? Good. Nice to meet you.
>
> Just for the record: responding to a patch is my strongest way of saying
> that I appreciate your work.
>
> On Wed, 4 Mar 2009, Mike Gaffney wrote:
>
>> Currently git over http only works with a .netrc file which required
>> that you store your password on the file system in plaintext. This
>> commit adds to configuration options for http for a username and an
>> optional password. If a http.username is set, then the .netrc file is
>> ignored and the username is used instead. If a http.password is set,
>> then that is used as well, otherwise the user is prompted for their
>> password.
>
> From the subject, I would have expected a way to type in the password
> instead of storing it. (Think getpass()... which would pose problems
> with Windows support, of course.)
>
> FWIW by having it in .git/config (which is most likely more world-readable
> than $HOME/.netrc ever will be) does not provide any security over .netrc.
>
> And I doubt that http.username is a good choice: what if you have multiple
> http:// URLs with different usernames/passwords? So would it not make
> more sense to make this remote.<name>.user and ...password?
>
> Ciao,
> Dscho
--
-Mike Gaffney (http://rdocul.us)
^ permalink raw reply
* Re: What's cooking in git.git (Mar 2009, #02; Thu, 05)
From: Michael Haggerty @ 2009-03-05 15:18 UTC (permalink / raw)
To: Jeff King; +Cc: Junio C Hamano, git, Heiko Voigt
In-Reply-To: <20090305110051.GA17921@coredump.intra.peff.net>
Jeff King wrote:
> On Thu, Mar 05, 2009 at 02:07:26AM -0800, Junio C Hamano wrote:
>
>> * mh/cvsimport-tests (Mon Feb 23 06:08:14 2009 +0100) 5 commits
>> - Add a test of "git cvsimport"'s handling of tags and branches
>> - Add some tests of git-cvsimport's handling of vendor branches
>> - Test contents of entire cvsimported "master" tree contents
>> - Use CVS's -f option if available (ignore user's ~/.cvsrc file)
>> - Start a library for cvsimport-related tests
>>
>> Tests without fixes are of dubious value. Any takers?
>
> [...]
>
> The final two introduce the new tests. They look fine as far as fitting
> into the test infrastructure, but I have to admit that I haven't
> actually looked closely at _what_ they are testing. I assumed since they
> are adapted from Michael's cvs2svn tests that they are showing real
> problems that he had faced there. If they are meant to show failings of
> cvsps-based conversion (which is my understanding from Michael's other
> messages), then I'm not even sure they _are_ fixable without a total
> rewrite.
The test script added by this patch:
Add some tests of git-cvsimport's handling of vendor branches
indicates a breakage that will occur for any CVS repository that used
the CVS "vendor branch" feature by importing a vendor tree more than
once. This is a standard-vanilla use of CVS, though probably used in a
minority of repositories. In such a case, the master branch of the
cvsimported git repository will have different contents than the HEAD
branch of the CVS repository. I don't know enough to say whether this
is fixable without ditching cvsps.
The test script added by this patch:
Add a test of "git cvsimport"'s handling of tags and branches
is even more basic. In CVS it is possible, and common, to add some
files but not others to a branch or tag, or to add files from multiple
source branches to a branch or tag. For some workflows, this is
recommended practice in the CVS world. AFAIK cvsps does not attempt to
figure out what files were added to a branch but rather assumes that an
entire source branch was tagged/branched at a single moment in time.
The result of this false assumption is that the contents of the
branch/tag as checked out of git are different than those in the same
branch/tag in CVS.
The following patch by Heiko Voigt:
* hv/cvsimport-tests (Mon Mar 2 18:59:36 2009 +0100) 1 commit
- cvsimport: add test illustrating a bug in cvsps
occurs due to out-of-order timestamps in the CVS repo, which can occur
whenever CVS *client* clocks are not synchronized.
I have another failing test (patch not yet submitted) that reveals a
conversion failure whenever CVS commits are applied to different files
in different orders (even if the timestamps are in order). This occurs
shockingly often in CVS repositories because commits are not atomic, so
commits from two clients can be interleaved. It can also occur if two
commits within cvsps's time window coincidentally have the same author
and commit message (e.g., a blank commit message). In this case
git-cvsimport commits changes *to a single file* in the wrong
topological order (e.g., revision 1.3 is overwritten by revision 1.2),
also potentially leaving obsolete file contents at HEAD.
In all of these cases *the git content is objectively wrong*. These are
not quality-of-conversion quibbles, they are egregious correctness
problems that will occur in most nontrivial CVS repositories.
> So I don't know whether it makes sense to apply them if we never plan on
> fixing them. [...]
IMHO there are only two intellectually honest alternatives:
1. Commit the new tests in the hope that somebody will try to fix them,
which probably requires ditching cvsps and starting almost from scratch.
Until they are fixed add a disclaimer, in big red letters, to the
git-cvsimport documentation, saying that it *should not be trusted* to
make accurate conversions (though it might be useful in very restricted
scenarios requiring incremental synchronization with a CVS repo). In
this case the tests should be retained as documentation, though perhaps
they should not be run unless the user turns on a particular flag.
2. Remove the git-cvsimport command altogether.
The status quo is untenable. git-cvsimport is broken in ways that
casual users might easily overlook. Their source tree might be altered,
possibly on HEAD but even more likely on branches and historical tags.
By the time they notice, sometime in the future, that their repository
is corrupt, it will be too late to fix because git development has taken
place on top of the faulty converted repository.
Michael
^ permalink raw reply
* [PATCH 0/2] 2GB fixes for Windows
From: Johannes Schindelin @ 2009-03-05 16:05 UTC (permalink / raw)
To: git, gitster; +Cc: Johannes Sixt
On Windows, we can actually have files larger than 2 gigabyte, just not
using off_t, but off64_t instead.
This came up as issue 194 on the msysGit tracker, and as I first brushed
the people off saying that it is not an msysGit issue, by way of an
apology, I started working on this myself.
The first patch adds a test for cloning repositories larger than 2
gigabyte, which is disabled by default, since it is quite expensive (both
in terms of time and in terms of space), and since it must fail when the
underlying filesystem does not allow files larger than 2 gigabyte.
The second patch convinces msysGit (AKA the MinGW port of Git) to make use
of the 64-bit file offsets.
Johannes Schindelin (2):
Add an (optional, since expensive) test for >2g clones
MinGW: 64-bit file offsets
compat/mingw.c | 8 +++++---
compat/mingw.h | 5 ++++-
t/t5705-clone-2gb.sh | 45 +++++++++++++++++++++++++++++++++++++++++++++
3 files changed, 54 insertions(+), 4 deletions(-)
create mode 100755 t/t5705-clone-2gb.sh
^ permalink raw reply
* [PATCH 1/2] Add an (optional, since expensive) test for >2g clones
From: Johannes Schindelin @ 2009-03-05 16:05 UTC (permalink / raw)
To: git, gitster; +Cc: Johannes Sixt
In-Reply-To: <cover.1236268730u.git.johannes.schindelin@gmx.de>
Define GIT_TEST_CLONE_2GB=t if you want the test not to be skipped.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---
t/t5705-clone-2gb.sh | 45 +++++++++++++++++++++++++++++++++++++++++++++
1 files changed, 45 insertions(+), 0 deletions(-)
create mode 100755 t/t5705-clone-2gb.sh
diff --git a/t/t5705-clone-2gb.sh b/t/t5705-clone-2gb.sh
new file mode 100755
index 0000000..dd4a8ec
--- /dev/null
+++ b/t/t5705-clone-2gb.sh
@@ -0,0 +1,45 @@
+#!/bin/sh
+
+test_description='Test cloning a repository larger than 2 gigabyte'
+. ./test-lib.sh
+
+test -z "$GIT_TEST_CLONE_2GB" &&
+say "Skipping expensive 2GB clone test; enable it with GIT_TEST_CLONE_2GB=t" &&
+test_done &&
+exit
+
+test_expect_success 'setup' '
+
+ git config pack.compression 0 &&
+ git config pack.depth 0 &&
+ blobsize=$((20*1024*1024))
+ blobcount=$((2*1024*1024*1024/$blobsize+1))
+ i=1
+ (while test $i -le $blobcount
+ do
+ printf "Generating blob $i/$blobcount\r" >&2 &&
+ printf "blob\nmark :$i\ndata $blobsize\n" &&
+ #test-genrandom $i $blobsize &&
+ printf "%-${blobsize}s" $i &&
+ echo "M 100644 :$i $i" >> commit
+ i=$(($i+1)) ||
+ echo $? > exit-status
+ done &&
+ echo "commit refs/heads/master" &&
+ echo "author A U Thor <author@email.com> 123456789 +0000" &&
+ echo "committer C O Mitter <committer@email.com> 123456789 +0000" &&
+ echo "data 5" &&
+ echo ">2gb" &&
+ cat commit) |
+ git fast-import &&
+ test ! -f exit-status
+
+'
+
+test_expect_success 'clone' '
+
+ git clone --bare --no-hardlinks . clone
+
+'
+
+test_done
--
1.6.2.rc1.493.g27ad8
^ permalink raw reply related
* [PATCH 2/2] MinGW: 64-bit file offsets
From: Johannes Schindelin @ 2009-03-05 16:05 UTC (permalink / raw)
To: git, gitster; +Cc: Johannes Sixt, Sickboy
In-Reply-To: <cover.1236268730u.git.johannes.schindelin@gmx.de>
The type 'off_t' should be used everywhere so that the bit-depth of that
type can be adjusted in the standard C library, and you just need to
recompile your program to benefit from the extended precision.
Only that it was not done that way in the MS runtime library.
This patch reroutes off_t to off64_t and provides the other necessary
changes so that finally, clones larger than 2 gigabyte work on Windows
(provided you are on a file system that allows files larger than 2gb).
Initial patch by Sickboy <sb@dev-heaven.net>.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---
compat/mingw.c | 8 +++++---
compat/mingw.h | 5 ++++-
2 files changed, 9 insertions(+), 4 deletions(-)
diff --git a/compat/mingw.c b/compat/mingw.c
index 3dbe6a7..27bcf3f 100644
--- a/compat/mingw.c
+++ b/compat/mingw.c
@@ -46,7 +46,8 @@ static int do_lstat(const char *file_name, struct stat *buf)
buf->st_uid = 0;
buf->st_nlink = 1;
buf->st_mode = file_attr_to_st_mode(fdata.dwFileAttributes);
- buf->st_size = fdata.nFileSizeLow; /* Can't use nFileSizeHigh, since it's not a stat64 */
+ buf->st_size = fdata.nFileSizeLow |
+ (((off_t)fdata.nFileSizeHigh)<<32);
buf->st_dev = buf->st_rdev = 0; /* not used by Git */
buf->st_atime = filetime_to_time_t(&(fdata.ftLastAccessTime));
buf->st_mtime = filetime_to_time_t(&(fdata.ftLastWriteTime));
@@ -101,7 +102,7 @@ int mingw_fstat(int fd, struct stat *buf)
}
/* direct non-file handles to MS's fstat() */
if (GetFileType(fh) != FILE_TYPE_DISK)
- return fstat(fd, buf);
+ return _fstati64(fd, buf);
if (GetFileInformationByHandle(fh, &fdata)) {
buf->st_ino = 0;
@@ -109,7 +110,8 @@ int mingw_fstat(int fd, struct stat *buf)
buf->st_uid = 0;
buf->st_nlink = 1;
buf->st_mode = file_attr_to_st_mode(fdata.dwFileAttributes);
- buf->st_size = fdata.nFileSizeLow; /* Can't use nFileSizeHigh, since it's not a stat64 */
+ buf->st_size = fdata.nFileSizeLow |
+ (((off_t)fdata.nFileSizeHigh)<<32);
buf->st_dev = buf->st_rdev = 0; /* not used by Git */
buf->st_atime = filetime_to_time_t(&(fdata.ftLastAccessTime));
buf->st_mtime = filetime_to_time_t(&(fdata.ftLastWriteTime));
diff --git a/compat/mingw.h b/compat/mingw.h
index a255898..cb9c4d4 100644
--- a/compat/mingw.h
+++ b/compat/mingw.h
@@ -163,11 +163,14 @@ int mingw_rename(const char*, const char*);
/* Use mingw_lstat() instead of lstat()/stat() and
* mingw_fstat() instead of fstat() on Windows.
*/
+#define off_t off64_t
+#define stat _stati64
+#define lseek _lseeki64
int mingw_lstat(const char *file_name, struct stat *buf);
int mingw_fstat(int fd, struct stat *buf);
#define fstat mingw_fstat
#define lstat mingw_lstat
-#define stat(x,y) mingw_lstat(x,y)
+#define stat64(x,y) mingw_lstat(x,y)
int mingw_utime(const char *file_name, const struct utimbuf *times);
#define utime mingw_utime
--
1.6.2.rc1.493.g27ad8
^ permalink raw reply related
* Re: counting the number of connections?
From: David Kågedal @ 2009-03-05 16:18 UTC (permalink / raw)
To: git; +Cc: Tay Ray Chuan
In-Reply-To: <be6fef0d0902272244q468b1fa4sacdc15afa9a65f15@mail.gmail.com>
Tay Ray Chuan <rctay89@gmail.com> writes:
> Hi,
>
> some time ago I noticed curl doesn't remember your credentials (apart
> from those it can get from ~/.netrc), and very recently there was an
> thread on repeated prompting for credentials while pushing to https.
>
> I've written a simple patch series, which allows git to play nice
> without curl_multi. That is, git uses a single persistent connection
> throughout.
>
> However, I'm at a loss at how to test for this. How does one count the
> number of connections made during the lifespan of a program's
> execution? So far, I've been relying on my firewall log (Comodo on
> windows). Perhaps there a more operating system/software-agnostic
> method to do this?
You could set up a single-use tcp forwarder which will make any second
connection fail. Using socat, for instance:
$ socat tcp-listen:2222,bind=localhost tcp:my.server:22 &
$ nc localhost 2222
SSH-2.0-OpenSSH_5.1p1 Debian-3ubuntu1
^C
$ nc localhost 2222
localhost [127.0.0.1] 2222 (?) : Connection refused
--
David Kågedal
^ permalink raw reply
* Re: What's cooking in git.git (Mar 2009, #02; Thu, 05)
From: Jeff King @ 2009-03-05 16:28 UTC (permalink / raw)
To: Michael Haggerty; +Cc: Junio C Hamano, git, Heiko Voigt
In-Reply-To: <49AFED56.3030102@alum.mit.edu>
On Thu, Mar 05, 2009 at 04:18:46PM +0100, Michael Haggerty wrote:
> In all of these cases *the git content is objectively wrong*. These are
> not quality-of-conversion quibbles, they are egregious correctness
> problems that will occur in most nontrivial CVS repositories.
Thanks for the detailed descriptions. I don't think anyone is denying
that the results are objectively wrong; it is clear that cvsimport
doesn't handle complex cases well.
> IMHO there are only two intellectually honest alternatives:
>
> 1. Commit the new tests in the hope that somebody will try to fix them,
> which probably requires ditching cvsps and starting almost from scratch.
> Until they are fixed add a disclaimer, in big red letters, to the
> git-cvsimport documentation, saying that it *should not be trusted* to
> make accurate conversions (though it might be useful in very restricted
> scenarios requiring incremental synchronization with a CVS repo). In
> this case the tests should be retained as documentation, though perhaps
> they should not be run unless the user turns on a particular flag.
I think committing the tests and putting a big warning onto cvsimport
are two separate things. I don't want to hide the fact that cvsimport
sucks, and I don't think anyone does. But I also don't want to bog down
the test suite with useless cruft that nobody is actually going to look
at.
I think your suggestion of disabling the tests unless flagged is
reasonable. The tests themselves don't take up much space in the
repository, it's only running them that is painful.
As far as marking cvsimport with a disclaimer, I don't have an objection
to warning people in the documentation. It seems like most people who
come to the list with a cvsimport problem end up getting the advice to
try something else, and then they end up happy. Putting a
not-inflammatory disclaimer into the documentation to check results and
to consider some other options would save the list a little work.
> 2. Remove the git-cvsimport command altogether.
I don't think this is a good idea. It still has two uses which make it
better than nothing:
1. It's the only (AFAIK) importer that is incremental. When you are
tracking relatively simple development on an existing CVS repo,
it is the only choice. Taking that choice away seems
counterproductive.
2. It _does_ work on relatively mundane cases, and there _are_ mundane
CVS repositories. Yes, other tools can also handle these cases, but
using the bundled cvsimport is much easier using an intermediate
svn.
I am less sure of (2) above, because naive users might not _know_ that
they're screwing up their repository. So safety would dictate spending
the extra effort (which is the point you were making, I think).
But certainly cvsimport should hang around for (1), even it is with a
disclaimer.
For how long, I don't know. It seems like most people are putting their
CVS repos to rest at this point, moving at least to SVN. I know there
will be people hanging on to CVS for at least a decade, but I'm not sure
at what point we say "there are not enough of you to care; go use a less
convenient one-time tool". cvsimport is already suffering from bit-rot
as people who like git enough to work on it converted their repos years
ago.
-Peff
^ permalink raw reply
* Re: [PATCH] http authentication via prompts
From: Jeff King @ 2009-03-05 16:37 UTC (permalink / raw)
To: Mike Gaffney; +Cc: git
In-Reply-To: <49AFEC91.10009@gmail.com>
On Thu, Mar 05, 2009 at 09:15:29AM -0600, Mike Gaffney wrote:
> My thought was that if you had a password you didn't care about you
> could put it in the config. It does ask you for a password with
> getpass, It compiles under cygwin, I havent tried it under windows.
I think part of the confusion is that your patch does two things, which
means it is probably more sensible as two separate patches:
1. support http.username and http.password in the git config instead
of the .netrc
2. support getpass() if http.password (or .netrc password) is not
available
-Peff
^ permalink raw reply
* Re: [PATCH 1/2] Add an (optional, since expensive) test for >2g clones
From: Jeff King @ 2009-03-05 16:41 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git, gitster, Johannes Sixt
In-Reply-To: <96a26f3a883890b3e56c867e8183618784837d4d.1236268730u.git.johannes.schindelin@gmx.de>
On Thu, Mar 05, 2009 at 05:05:09PM +0100, Johannes Schindelin wrote:
> + (while test $i -le $blobcount
> + do
> + printf "Generating blob $i/$blobcount\r" >&2 &&
> + printf "blob\nmark :$i\ndata $blobsize\n" &&
> + #test-genrandom $i $blobsize &&
> + printf "%-${blobsize}s" $i &&
Leftover cruft using genrandom? (I'm guessing you tried random at first
to avoid compression, but I think your pack.compression=0 technique is
more sensible).
-Peff
^ permalink raw reply
* Cute bug in gitweb
From: Johannes Schindelin @ 2009-03-05 16:46 UTC (permalink / raw)
To: git, Jakub 'CC-me' Narebski
Hi,
this was just pointed out by one of my users: if you have a blob called
'tree', gitweb's tree view displays '(base|diff)' just after the name of
the blob.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH 1/2] Add an (optional, since expensive) test for >2g clones
From: Johannes Schindelin @ 2009-03-05 16:58 UTC (permalink / raw)
To: Jeff King; +Cc: git, gitster, Johannes Sixt
In-Reply-To: <20090305164153.GD4213@coredump.intra.peff.net>
Hi,
On Thu, 5 Mar 2009, Jeff King wrote:
> On Thu, Mar 05, 2009 at 05:05:09PM +0100, Johannes Schindelin wrote:
>
> > + (while test $i -le $blobcount
> > + do
> > + printf "Generating blob $i/$blobcount\r" >&2 &&
> > + printf "blob\nmark :$i\ndata $blobsize\n" &&
> > + #test-genrandom $i $blobsize &&
> > + printf "%-${blobsize}s" $i &&
>
> Leftover cruft using genrandom? (I'm guessing you tried random at first
> to avoid compression, but I think your pack.compression=0 technique is
> more sensible).
Actually, I left it in on purpose. Yes, it happens to work right now, as
the packs are built with 0 compression and with 0 deltification.
However, there might be a day when we cannot guarantee anymore that a
single number padded with spaces to a certain width really makes the pack
grow by that many bytes. Then we would need something like test-genrandom
(which is substantially slower, though).
Interesting random note: it took me quite a while to figure out that both
pack.compression and pack.depth need to be set to 0. In hindsight, it is
obvious, but that does not really help the time I lost due to Windows'
slowness.
Ciao,
Dscho
^ permalink raw reply
* Re: counting the number of connections?
From: Johannes Schindelin @ 2009-03-05 17:00 UTC (permalink / raw)
To: David Kågedal; +Cc: git, Tay Ray Chuan
In-Reply-To: <87ab80j649.fsf@krank.kagedal.org>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 1415 bytes --]
Hi,
On Thu, 5 Mar 2009, David Kågedal wrote:
> Tay Ray Chuan <rctay89@gmail.com> writes:
>
> > some time ago I noticed curl doesn't remember your credentials (apart
> > from those it can get from ~/.netrc), and very recently there was an
> > thread on repeated prompting for credentials while pushing to https.
> >
> > I've written a simple patch series, which allows git to play nice
> > without curl_multi. That is, git uses a single persistent connection
> > throughout.
> >
> > However, I'm at a loss at how to test for this. How does one count the
> > number of connections made during the lifespan of a program's
> > execution? So far, I've been relying on my firewall log (Comodo on
> > windows). Perhaps there a more operating system/software-agnostic
> > method to do this?
>
> You could set up a single-use tcp forwarder which will make any second
> connection fail. Using socat, for instance:
>
> $ socat tcp-listen:2222,bind=localhost tcp:my.server:22 &
> $ nc localhost 2222
> SSH-2.0-OpenSSH_5.1p1 Debian-3ubuntu1
> ^C
> $ nc localhost 2222
> localhost [127.0.0.1] 2222 (?) : Connection refused
AFAICT Ray wants to provide tests for Git's test suite, and introducing
socat as a dependency for our tests does not really fly all that well.
But IIRC somebody convinced Ray that it is better to require a new-enough
cURL version so that the patch becomes moot itself.
Ciao,
Dscho
^ permalink raw reply
* Re: linux-firmware binary corruption with gitweb
From: Pavel Roskin @ 2009-03-05 17:26 UTC (permalink / raw)
To: Dave
Cc: orinoco-users-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
John 'Warthog9' Hawley, dwmw2-wEGCiKHe2LqWVfeAwA7xHQ,
git-u79uwXL29TY76Z2rM5mHXA, Jakub Narebski
In-Reply-To: <49AF1429.9080009-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
On Wed, 2009-03-04 at 23:52 +0000, Dave wrote:
> binmode STDOUT, ':raw';
> - print <$fd>;
> + #print <$fd>;
> + $output .= <$fd>;
> binmode STDOUT, ':utf8'; # as set at the beginning of
> gitweb.cgi
Nice catch!
Looking at the gitweb repository from kernel.org, two instances of
circumventing binmode were introduced by this commit:
commit c79ae555fb3c89d91b4cafbfce306e695720507b
Author: John Hawley <warthog9-v8g9t7APwQevveQcA6InS3zaFgp7qdfK@public.gmane.org>
Date: Thu Dec 28 21:59:43 2006 -0800
Last of the changes to deal with channeling the text through the caching
engine. Wow is this a total hack.
The original behavior was restored in git_snapshot() by the recent
commit c15229acd9bedf165f1eb05d99fa989d3b9f3e32, but git_blob_plain()
remains broken.
I don't see an easy fix. We cannot manipulate the blob to counteract
the encoding, as it may not be valid utf-8, and therefore won't be
output in the utf-8 mode.
Maybe binmode should be raw everywhere, and adding to $output should
recode data to utf-8 from other encodings where needed, but it would be
a massive patch, I'm afraid. Or it would be a small patch requiring
massive testing.
Adding John Hawley to cc:
--
Regards,
Pavel Roskin
------------------------------------------------------------------------------
Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA
-OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise
-Strategies to boost innovation and cut costs with open source participation
-Receive a $600 discount off the registration fee with the source code: SFAD
http://p.sf.net/sfu/XcvMzF8H
^ permalink raw reply
* Re: [PATCH] git-p4: improve performance with large files
From: Sam Hocevar @ 2009-03-05 17:23 UTC (permalink / raw)
To: git
In-Reply-To: <20090305100527.shmtfbdvk0ggsk4s@webmail.fussycoder.id.au>
On Thu, Mar 05, 2009, thestar@fussycoder.id.au wrote:
> > The current git-p4 way of concatenating strings performs in O(n^2)
> >and is therefore terribly slow with large files because of unnecessary
> >memory copies. The following patch makes the operation O(n).
>
> The reason why it uses simple concatenation is to cut down on memory usage.
> - It is a tradeoff.
>
> I think the modification you have made below is reasonable, however be
> aware that memory usage could double, which substantially reduce the
> size of the changesets that git-p4 would be able to import /at all/,
> rather than to merely be slow.
Uhm, no. The memory usage could be an additional X, where X is the
size of the biggest file in the commit. Remember that commit() stores
the complete commit data in memory before sending it to fast-import.
Also, on my machine the extra memory is already used because at some
point, "text += foo" calls realloc() anyway and often duplicates the
memory used by text.
The ideal solution is to use a generator and refactor the commit
handling as a stream. I am working on that but it involves deeper
changes, so as I am not sure it will be accepted, I'm providing the
attached compromise patch first. At least it solves the appaling speed
issue. I tuned it so that it never uses more than 32 MiB extra memory.
Signed-off-by: Sam Hocevar <sam@zoy.org>
---
contrib/fast-import/git-p4 | 10 +++++++++-
1 files changed, 9 insertions(+), 1 deletions(-)
diff --git a/contrib/fast-import/git-p4 b/contrib/fast-import/git-p4
index 3832f60..151ae1c 100755
--- a/contrib/fast-import/git-p4
+++ b/contrib/fast-import/git-p4
@@ -984,11 +984,19 @@ class P4Sync(Command):
while j < len(filedata):
stat = filedata[j]
j += 1
+ data = []
text = ''
while j < len(filedata) and filedata[j]['code'] in ('text', 'unicod
e', 'binary'):
- text += filedata[j]['data']
+ data.append(filedata[j]['data'])
del filedata[j]['data']
+ # p4 sends 4k chunks, make sure we don't use more than 32 MiB
+ # of additional memory while rebuilding the file data.
+ if len(data) > 8192:
+ text += ''.join(data)
+ data = []
j += 1
+ text += ''.join(data)
+ del data
if not stat.has_key('depotFile'):
sys.stderr.write("p4 print fails with: %s\n" % repr(stat))
--
Sam.
^ permalink raw reply related
* Re: git-svn and repository hierarchy?
From: Josef Wolf @ 2009-03-05 18:05 UTC (permalink / raw)
To: git
In-Reply-To: <eaa105840903041406k36088763w5a70fe1d7458dfb1@mail.gmail.com>
On Wed, Mar 04, 2009 at 05:06:06PM -0500, Peter Harris wrote:
> On Wed, Mar 4, 2009 at 2:27 PM, Josef Wolf wrote:
> > On Tue, Mar 03, 2009 at 07:18:04PM -0500, Peter Harris wrote:
> >>
> >> Sounds like subversion isn't properly caching your credentials, or
> >> your admin is paranoid and turned off the svn credential cache. I
> >> can't remember the last time I had to enter a password.
> >
> > What credential cache are you talking about? I don't know of any
> > worth to be mentioned. If you talk about "store-passwords=yes" in
> > subversion's config
>
> Yes, that's the one.
>
> > you might be interested to read
> > http://curl.haxx.se/docs/adv_20090303.html
>
> Not really, since I use svn:// :-)
Doesn't help ;-) Many applications are using curllib, and all of them
can reveal your .netrc or subversion config. For example, zypper and
apt use curllib, AFAIR.
> > BTW: The paranoid admin is myself. ;-)
> > BTW1: I know there's the possibility of client certificates. But AFAIK,
> > there's no equivalent to ssh-agent, so it's pointless.
>
> I thought that this was already a part of svn, but it appears in the
> 1.6 (not quite final yet) release notes: "SSL client certificate
> passphrases can be stored in KWallet, GNOME Keyring, Mac OS Keychain,
> a Windows CryptoAPI encrypted form or in plaintext form."
Ummm, I always found it hard to find their changelog. At least
http://svn.collab.net/viewvc/svn/trunk/CHANGES?view=markup&pathrev=36138
don't mention those features. Do you have a pointer?
> > Within svn, the author field seems to be correct (at least, it is
> > identical to those of the commits that were done directly to svn)
> > But when the commits come back to git, it is set to
> > "jw <jw@041dc122-08ea-11de-a769-bddc3e64b585>" with the host-part being
> > the uuid of the svn-repo.
> >
> > Any ideas how to fix that?
>
> "git help svn" and look for "--authors-file", maybe. I don't use it
> myself, so I'm afraid I can't help with that one.
Ah, I missed that.
> > Oh, and what happens if svn's rev-properties (commit log, author, date...)
> > are changed?
>
> Too late. git svn will ignore the change to the history, since git
> forces you to rewrite your entire history if any part changes. Cue
> standard "log messages should [not] be mutable" flamewar.
>
> Ah, here it is... <flamebait version>: Nothing happens. git will
> correctly store your *true* log/author/date, ignoring any and all
> attempts by malicious parties to destroy useful historical
> information.
>
> Of course, you're a paranoid admin, so you already have a
> pre-revprop-change hook in your svn server that prevents
> log/author/date changes. Right? ;-)
Well, actually it allows the changes for a very limited user group (that
is: only me 8-). While I agree that author/date should not be changed,
I like to be able to fix silly typos in the log. After all, we all do
typos now and then ;-)
> > In contrast, working directly against an svn repository is _very_
> > tedious.
>
> Tell me about it. Fortunately, we have git-svn to save us from the
> default svn client. ;-)
Fortunately, the default client asks me for the password only once when
I commit something. git-svn is different here ;-)
> (Sorry, couldn't resist pulling that one out of context)
(Me too)
> > With a dozen commits pending, you have to enter your password
> > about 30..50 times in "git svn dcommit".
>
> Maybe svn 1.6 will fix that for you?
I don't think the problem is svn here. Me tends to think git uses
curllib not in the way it was meant to be used. And git-svn should
reuse the existing connection instead of creating a new one for every
bit it is going to transport.
> > # 2. move commits from clone to subversion
> > #
> > cd git-svn-repos
> > git svn rebase
> > git pull ../clone$clone topic-branch # need rebase?
>
> Yeah, a "git svn rebase -l" after this line wouldn't hurt, and is
> suggested by "git help svn".
>
> Or even reverse those two lines, to save adding a third:
> git pull ../clone$clone topic-branch
> git svn rebase
With this, I get twice as much conflicts (half of them being spurious).
But the history is linear on the clones, thus reflecting the svn history
more accurately, I guess.
> Alternatively, you can avoid potential pull conflicts by using a
> temporary branch to avoid the merge you are about to throw away with
> rebase -- remember that 'pull' is short for 'fetch && merge':
>
> git fetch ../clone$clone topic-branch:scratch
> git checkout scratch
> git rebase trunk
> git svn dcommit
> git checkout master
> git svn rebase -l # fast-forward master to where scratch is
> git branch -d scratch
>
> ...which should result in seeing only the rebase conflict(s). And
> ought to work if cloneN's topic-branch is on a different svn branch
> from master (although you'd need to -D scratch instead of -d).
I guess you meant "git svn rebase trunk", since dcommit complains about
outdated transactions if "git rebase trunk" is used.
Overall, this looks very good, since the history is linear and I get
only spurious conflicts, which I can get rid of with "git rebase --skip".
Maybe there's room for more improvement: Since the merge is done on a
scratch branch anyway, why not letting the clones _push_ into branches
with random names: cloneX-`uuidgen` or something. So the clones could
do the push whenever they have net access. The actual merge can be done
completely decoupled from the push operation.
^ permalink raw reply
* Re: [PATCH 1/2] Add an (optional, since expensive) test for >2g clones
From: Jeff King @ 2009-03-05 18:50 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git, gitster, Johannes Sixt
In-Reply-To: <alpine.DEB.1.00.0903051754260.6524@intel-tinevez-2-302>
On Thu, Mar 05, 2009 at 05:58:23PM +0100, Johannes Schindelin wrote:
> > Leftover cruft using genrandom? (I'm guessing you tried random at first
> > to avoid compression, but I think your pack.compression=0 technique is
> > more sensible).
>
> Actually, I left it in on purpose. Yes, it happens to work right now, as
> the packs are built with 0 compression and with 0 deltification.
Fair enough. A comment in the commit message or in the code might have
made that more clear, though...
-Peff
^ permalink raw reply
* Re: [PATCH 2/2] better introduction of GIT with USE_NSEC defined
From: Junio C Hamano @ 2009-03-05 18:55 UTC (permalink / raw)
To: Johannes Sixt; +Cc: Kjetil Barvik, git
In-Reply-To: <49AFBDAD.5040501@viscovery.net>
Johannes Sixt <j.sixt@viscovery.net> writes:
> Yes, it breaks. You can test this on Linux by commenting out these two
> lines in git-compat-util.h:
>
> diff --git a/git-compat-util.h b/git-compat-util.h
> index dcf4127..ab4b615 100644
> --- a/git-compat-util.h
> +++ b/git-compat-util.h
> @@ -44,8 +44,8 @@
> #define _XOPEN_SOURCE_EXTENDED 1 /* AIX 5.3L needs this */
> #endif
> #define _ALL_SOURCE 1
> -#define _GNU_SOURCE 1
> -#define _BSD_SOURCE 1
> +/*#define _GNU_SOURCE 1*/
> +/*#define _BSD_SOURCE 1*/
>
> #include <unistd.h>
> #include <stdio.h>
>
> The result even passes the test suite (as long as I don't merge
> kb/checkout-optim, of course).
Isn't it better to separate "do we want to use that information if we can
nanosecocond timestamps" and "is the API available for reading nanosecond
timestamps" into separete switches, like this partial patch on top of the
patch we are discussing, then? It is partial because it shows the way to
convert only one call site as an example and of course you need to update
the Makefile and autoconf.
diff --git a/git-compat-util.h b/git-compat-util.h
index 079cbe9..910aa03 100644
--- a/git-compat-util.h
+++ b/git-compat-util.h
@@ -384,4 +384,12 @@ void git_qsort(void *base, size_t nmemb, size_t size,
# define FORCE_DIR_SET_GID 0
#endif
+#ifdef HAS_NSEC
+#define ST_CTIME_NSEC(st) ((unsigned ing)((st).st_ctim.tv_nsec))
+#define ST_MTIME_NSEC(st) ((unsigned ing)((st).st_mtim.tv_nsec))
+#else
+#define ST_CTIME_NSEC(st) 0
+#define ST_MTIME_NSEC(st) 0
+#endif
+
#endif
diff --git a/read-cache.c b/read-cache.c
index 91f1d03..bb5cb2b 100644
--- a/read-cache.c
+++ b/read-cache.c
@@ -69,13 +69,8 @@ void fill_stat_cache_info(struct cache_entry *ce, struct stat *st)
{
ce->ce_ctime.sec = (unsigned int)st->st_ctime;
ce->ce_mtime.sec = (unsigned int)st->st_mtime;
-#ifdef USE_NSEC
- ce->ce_ctime.nsec = (unsigned int)st->st_ctim.tv_nsec;
- ce->ce_mtime.nsec = (unsigned int)st->st_mtim.tv_nsec;
-#else
- ce->ce_ctime.nsec = 0;
- ce->ce_mtime.nsec = 0;
-#endif
+ ce->ce_ctime.nsec = ST_CTIME_NSEC(*st);
+ ce->ce_mtime.nsec = ST_MTIME_NSEC(*st);
ce->ce_dev = st->st_dev;
ce->ce_ino = st->st_ino;
ce->ce_uid = st->st_uid;
^ permalink raw reply related
* Re: notes, was Re: What's cooking in git.git (Mar 2009, #02; Thu, 05)
From: Junio C Hamano @ 2009-03-05 19:23 UTC (permalink / raw)
To: Jonas Fonseca; +Cc: Johannes Schindelin, git
In-Reply-To: <2c6b72b30903050440k6f9533bbq605d5f06161dff92@mail.gmail.com>
Jonas Fonseca <jonas.fonseca@gmail.com> writes:
> On Thu, Mar 5, 2009 at 12:04, Johannes Schindelin
> <Johannes.Schindelin@gmx.de> wrote:
>> On Thu, 5 Mar 2009, Junio C Hamano wrote:
>>
>>> * js/notes (Wed Feb 18 11:17:27 2009 -0800) 14 commits
>>>
>>> Rebased and then kicked back to 'pu' to give the author a chance to
>>> rearrange if necessary. I might do some trivial squashing myself.
>>
>> Will do.
>
> Although laziness should not be rewarded, this might be something that
> you could squash in as well.
Whose laziness are you accusing? Me giving Dscho a chance to make trivial
clean-up of his own series instead of doing it myself???
In any case, I won't be squashing "oops - fixup" patch(es) in the original
series to the early parts of the sequence that introduced the "oops"
myself, as it would likely end up Dscho and I stepping on each other's
paws. I won't be squashing this patch in myself, either.
> --- a/Documentation/git-notes.txt
> +++ b/Documentation/git-notes.txt
> @@ -43,4 +43,4 @@ Documentation by Johannes Schindelin
>
> GIT
> ---
> -Part of the gitlink:git[7] suite
> +Part of the linkgit:git[7] suite
^ permalink raw reply
* Re: [PATCH] '%S' option for pretty printing to support --source
From: Deskin Miller @ 2009-03-05 19:41 UTC (permalink / raw)
To: Petri Hodju; +Cc: Jeff King, git, gitster, Johannes Schindelin
In-Reply-To: <20090305091758.GC30445@coredump.intra.peff.net>
On Thu, Mar 5, 2009 at 04:17, Jeff King <peff@peff.net> wrote:
> On Thu, Mar 05, 2009 at 09:18:28AM +0200, Petri Hodju wrote:
>
>> +static void format_source(struct strbuf *sb, const struct commit *commit)
>> +{
>> + if (commit->util)
>> + strbuf_addstr(sb, (char *) commit->util);
>> +}
>> +
>
> Hmm. This is the second patch in the last few weeks to use commit->util
> to carry information for --pretty=format: (I am cc'ing Deskin Miller,
> who wrote the first).
Thanks Jeff. Fortunately I managed to catch this one anyway.
Petri, the patch series from me which Jeff is referring to is viewable at
http://thread.gmane.org/gmane.comp.version-control.git/111524/
for reference.
I am in the middle of a move and ought to be packing right now, so
needless to say my git budget at the moment is pretty much nil, and
will be so for at least another week I'd guess. This is to say, I've
not done any additional work in light of Jeff's or Dscho's comments on
my series, though I intend to once I'm relocated.
> They cannot both work, obviously. So we need to do one of:
>
> - refactor the information out of commit->util to somewhere else
>
> - allow multiple commit->util users somehow (which I think is a
> potential performance problem -- the simplistic design is meant to
> avoid things like allocation overhead)
I'm inclined to do as Dscho suggests here: glancing at the current
struct decoration usage briefly I think my reflog printing could work
that way with no problem. However, this would largely ignore your
other comments about prettifying the pretty-printing code. If a new
series using struct decoration isn't useful, let me know, otherwise
I'll plan on doing this once I have a chance.
> - gracefully block concurrent use of conflicting features
I agree that any blocking should be graceful, but ultimately I find
the idea of disallowing features because they happen to use the same
underlying implementation distasteful. With a little work we should
be able to allow both with no problem.
Deskin Miller
^ permalink raw reply
* Re: git-svn and repository hierarchy?
From: Peter Harris @ 2009-03-05 19:48 UTC (permalink / raw)
To: Josef Wolf, git
In-Reply-To: <20090305180529.GD11278@raven.wolf.lan>
On Thu, Mar 5, 2009 at 1:05 PM, Josef Wolf wrote:
> On Wed, Mar 04, 2009 at 05:06:06PM -0500, Peter Harris wrote:
>>
>> I thought that this was already a part of svn, but it appears in the
>> 1.6 (not quite final yet) release notes: "SSL client certificate
>> passphrases can be stored in KWallet, GNOME Keyring, Mac OS Keychain,
>> a Windows CryptoAPI encrypted form or in plaintext form."
>
> Ummm, I always found it hard to find their changelog. At least
> http://svn.collab.net/viewvc/svn/trunk/CHANGES?view=markup&pathrev=36138
> don't mention those features. Do you have a pointer?
http://subversion.tigris.org/svn_1.6_releasenotes.html#auth-related-improvements
>> Of course, you're a paranoid admin, so you already have a
>> pre-revprop-change hook in your svn server that prevents
>> log/author/date changes. Right? ;-)
>
> Well, actually it allows the changes for a very limited user group (that
> is: only me 8-). While I agree that author/date should not be changed,
> I like to be able to fix silly typos in the log. After all, we all do
> typos now and then ;-)
True, but in my experience it happens considerably less often with
git. I find and fix most of my typos when reviewing my change-set
before doing a "git push" or "git svn dcommit".
> Maybe there's room for more improvement: Since the merge is done on a
> scratch branch anyway, why not letting the clones _push_ into branches
> with random names: cloneX-`uuidgen` or something. So the clones could
> do the push whenever they have net access. The actual merge can be done
> completely decoupled from the push operation.
Indeed. Or even not-so-random names, such as cloneX/topic-name if you prefer.
Peter Harris
^ permalink raw reply
* Re: [PATCH 2/2] better introduction of GIT with USE_NSEC defined
From: Junio C Hamano @ 2009-03-05 20:02 UTC (permalink / raw)
To: Johannes Sixt; +Cc: Kjetil Barvik, git
In-Reply-To: <7v4oy7241g.fsf@gitster.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> Johannes Sixt <j.sixt@viscovery.net> writes:
>
>> Yes, it breaks. You can test this on Linux by commenting out these two
>> lines in git-compat-util.h:
>>
>> diff --git a/git-compat-util.h b/git-compat-util.h
>> index dcf4127..ab4b615 100644
>> --- a/git-compat-util.h
>> +++ b/git-compat-util.h
>> @@ -44,8 +44,8 @@
>> #define _XOPEN_SOURCE_EXTENDED 1 /* AIX 5.3L needs this */
>> #endif
>> #define _ALL_SOURCE 1
>> -#define _GNU_SOURCE 1
>> -#define _BSD_SOURCE 1
>> +/*#define _GNU_SOURCE 1*/
>> +/*#define _BSD_SOURCE 1*/
>> #include <unistd.h>
>> #include <stdio.h>
>>
>> The result even passes the test suite (as long as I don't merge
>> kb/checkout-optim, of course).
This actually will trigger more compilation breakages than that. For
example, it hides memmem() and strchrnul() from everybody, and makes the
compilation error out with this subtract as the compiler has to assume you
are subtracting a pointer from an integer:
linelen = strchrnul(msg_p, '\n') - msg_p;
I cannot test the result myself to see if it still works this way.
> Isn't it better to separate "do we want to use that information if we can
> nanosecocond timestamps" and "is the API available for reading nanosecond
> timestamps" into separete switches, like this partial patch on top of the
> patch we are discussing, then? It is partial because it shows the way to
> convert only one call site as an example and of course you need to update
> the Makefile and autoconf.
And here is what I did. It is meant to replace the patch in discussion.
-- >8 --
Record ns-timestamps if possible, but do not use it without USE_NSEC
Traditionally, the lack of USE_NSEC meant "do not record nor use the
nanosecond resolution part of the file timestamps". To avoid problems on
filesystems that lose the ns part when the metadata is flushed to the disk
and then later read back in, disabling USE_NSEC has been a good idea in
general.
If you are on a filesystem without such an issue, it does not hurt to read
and store them in the cached stat data in the index entries even if your
git is compiled without USE_NSEC. The index left with such a version of
git can be read by git compiled with USE_NSEC and it can make use of the
nanosecond part to optimize the check to see if the path on the filesystem
hsa been modified since we last looked at.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
Makefile | 7 +++++++
builtin-fetch-pack.c | 4 +---
git-compat-util.h | 9 +++++++++
read-cache.c | 29 ++++-------------------------
unpack-trees.c | 2 --
5 files changed, 21 insertions(+), 30 deletions(-)
diff --git a/Makefile b/Makefile
index 27b9569..e63034d 100644
--- a/Makefile
+++ b/Makefile
@@ -126,6 +126,9 @@ all::
# randomly break unless your underlying filesystem supports those sub-second
# times (my ext3 doesn't).
#
+# Define NO_NSEC if your "struct stat" does not have "st_ctim.tv_nsec"
+# available. This automatically turns USE_NSEC off.
+#
# Define USE_STDEV below if you want git to care about the underlying device
# change being considered an inode change from the update-index perspective.
#
@@ -802,6 +805,7 @@ ifneq (,$(findstring MINGW,$(uname_S)))
RUNTIME_PREFIX = YesPlease
NO_POSIX_ONLY_PROGRAMS = YesPlease
NO_ST_BLOCKS_IN_STRUCT_STAT = YesPlease
+ NO_NSEC = YesPlease
COMPAT_CFLAGS += -D__USE_MINGW_ACCESS -DNOGDI -Icompat -Icompat/regex -Icompat/fnmatch
COMPAT_CFLAGS += -DSNPRINTF_SIZE_CORR=1
COMPAT_CFLAGS += -DSTRIP_EXTENSION=\".exe\"
@@ -923,6 +927,9 @@ endif
ifdef NO_ST_BLOCKS_IN_STRUCT_STAT
BASIC_CFLAGS += -DNO_ST_BLOCKS_IN_STRUCT_STAT
endif
+ifdef NO_NSEC
+ BASIC_CFLAGS += -DNO_NSEC
+endif
ifdef NO_C99_FORMAT
BASIC_CFLAGS += -DNO_C99_FORMAT
endif
diff --git a/builtin-fetch-pack.c b/builtin-fetch-pack.c
index 3b210c7..59b0b0a 100644
--- a/builtin-fetch-pack.c
+++ b/builtin-fetch-pack.c
@@ -801,9 +801,7 @@ struct ref *fetch_pack(struct fetch_pack_args *my_args,
int fd;
mtime.sec = st.st_mtime;
-#ifdef USE_NSEC
- mtime.nsec = st.st_mtim.tv_nsec;
-#endif
+ mtime.nsec = ST_MTIME_NSEC(st);
if (stat(shallow, &st)) {
if (mtime.sec)
die("shallow file was removed during fetch");
diff --git a/git-compat-util.h b/git-compat-util.h
index 079cbe9..9b495dc 100644
--- a/git-compat-util.h
+++ b/git-compat-util.h
@@ -384,4 +384,13 @@ void git_qsort(void *base, size_t nmemb, size_t size,
# define FORCE_DIR_SET_GID 0
#endif
+#ifdef NO_NSEC
+#undef USE_NSEC
+#define ST_CTIME_NSEC(st) 0
+#define ST_MTIME_NSEC(st) 0
+#else
+#define ST_CTIME_NSEC(st) ((unsigned int)((st).st_ctim.tv_nsec))
+#define ST_MTIME_NSEC(st) ((unsigned int)((st).st_mtim.tv_nsec))
+#endif
+
#endif
diff --git a/read-cache.c b/read-cache.c
index 91f1d03..b819abb 100644
--- a/read-cache.c
+++ b/read-cache.c
@@ -69,13 +69,8 @@ void fill_stat_cache_info(struct cache_entry *ce, struct stat *st)
{
ce->ce_ctime.sec = (unsigned int)st->st_ctime;
ce->ce_mtime.sec = (unsigned int)st->st_mtime;
-#ifdef USE_NSEC
- ce->ce_ctime.nsec = (unsigned int)st->st_ctim.tv_nsec;
- ce->ce_mtime.nsec = (unsigned int)st->st_mtim.tv_nsec;
-#else
- ce->ce_ctime.nsec = 0;
- ce->ce_mtime.nsec = 0;
-#endif
+ ce->ce_ctime.nsec = ST_CTIME_NSEC(*st);
+ ce->ce_mtime.nsec = ST_MTIME_NSEC(*st);
ce->ce_dev = st->st_dev;
ce->ce_ino = st->st_ino;
ce->ce_uid = st->st_uid;
@@ -1183,13 +1178,8 @@ static void convert_from_disk(struct ondisk_cache_entry *ondisk, struct cache_en
ce->ce_ctime.sec = ntohl(ondisk->ctime.sec);
ce->ce_mtime.sec = ntohl(ondisk->mtime.sec);
-#ifdef USE_NSEC
ce->ce_ctime.nsec = ntohl(ondisk->ctime.nsec);
ce->ce_mtime.nsec = ntohl(ondisk->mtime.nsec);
-#else
- ce->ce_ctime.nsec = 0;
- ce->ce_mtime.nsec = 0;
-#endif
ce->ce_dev = ntohl(ondisk->dev);
ce->ce_ino = ntohl(ondisk->ino);
ce->ce_mode = ntohl(ondisk->mode);
@@ -1309,11 +1299,7 @@ int read_index_from(struct index_state *istate, const char *path)
dst_offset += ce_size(ce);
}
istate->timestamp.sec = st.st_mtime;
-#ifdef USE_NSEC
- istate->timestamp.nsec = (unsigned int)st.st_mtim.tv_nsec;
-#else
- istate->timestamp.nsec = 0;
-#endif
+ istate->timestamp.nsec = ST_MTIME_NSEC(st);
while (src_offset <= mmap_size - 20 - 8) {
/* After an array of active_nr index entries,
@@ -1500,13 +1486,8 @@ static int ce_write_entry(git_SHA_CTX *c, int fd, struct cache_entry *ce)
ondisk->ctime.sec = htonl(ce->ce_ctime.sec);
ondisk->mtime.sec = htonl(ce->ce_mtime.sec);
-#ifdef USE_NSEC
ondisk->ctime.nsec = htonl(ce->ce_ctime.nsec);
ondisk->mtime.nsec = htonl(ce->ce_mtime.nsec);
-#else
- ondisk->ctime.nsec = 0;
- ondisk->mtime.nsec = 0;
-#endif
ondisk->dev = htonl(ce->ce_dev);
ondisk->ino = htonl(ce->ce_ino);
ondisk->mode = htonl(ce->ce_mode);
@@ -1583,9 +1564,7 @@ int write_index(struct index_state *istate, int newfd)
if (ce_flush(&c, newfd) || fstat(newfd, &st))
return -1;
istate->timestamp.sec = (unsigned int)st.st_ctime;
-#ifdef USE_NSEC
- istate->timestamp.nsec = (unsigned int)st.st_ctim.tv_nsec;
-#endif
+ istate->timestamp.nsec = ST_CTIME_NSEC(st);
return 0;
}
diff --git a/unpack-trees.c b/unpack-trees.c
index 9fe0cd5..da2e3c0 100644
--- a/unpack-trees.c
+++ b/unpack-trees.c
@@ -362,9 +362,7 @@ int unpack_trees(unsigned len, struct tree_desc *t, struct unpack_trees_options
o->result.initialized = 1;
if (o->src_index) {
o->result.timestamp.sec = o->src_index->timestamp.sec;
-#ifdef USE_NSEC
o->result.timestamp.nsec = o->src_index->timestamp.nsec;
-#endif
}
o->merge_size = len;
^ permalink raw reply related
* Re: [ANNOUNCE] TortoiseGit 0.4.1.0 release
From: John Dlugosz @ 2009-03-05 20:02 UTC (permalink / raw)
To: git; +Cc: lznuaa
>> TortoiseGit 0.3.3 released.
That should be 0.4.1 ?
I just downloaded the 64-bit version, and can't get it to come up. I
started a thread there, but don't know if anyone is following since
there are zero messages in the discussion group.
--John
TradeStation Group, Inc. is a publicly-traded holding company (NASDAQ GS: TRAD) of three operating subsidiaries, TradeStation Securities, Inc. (Member NYSE, FINRA, SIPC and NFA), TradeStation Technologies, Inc., a trading software and subscription company, and TradeStation Europe Limited, a United Kingdom, FSA-authorized introducing brokerage firm. None of these companies provides trading or investment advice, recommendations or endorsements of any kind. The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited.
If you received this in error, please contact the sender and delete the material from any computer.
^ permalink raw reply
* Re: notes, was Re: What's cooking in git.git (Mar 2009, #02; Thu, 05)
From: Jonas Fonseca @ 2009-03-05 20:17 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Johannes Schindelin, git
In-Reply-To: <7vwsb3zsc5.fsf@gitster.siamese.dyndns.org>
On Thu, Mar 5, 2009 at 20:23, Junio C Hamano <gitster@pobox.com> wrote:
> Jonas Fonseca <jonas.fonseca@gmail.com> writes:
>> On Thu, Mar 5, 2009 at 12:04, Johannes Schindelin
>> <Johannes.Schindelin@gmx.de> wrote:
>>> On Thu, 5 Mar 2009, Junio C Hamano wrote:
>>>> * js/notes (Wed Feb 18 11:17:27 2009 -0800) 14 commits
>>
>> Although laziness should not be rewarded, this might be something that
>> you could squash in as well.
>
> Whose laziness are you accusing? Me giving Dscho a chance to make trivial
> clean-up of his own series instead of doing it myself???
I was referring to my own laziness of not sending a proper patch.
Sorry for the confusion.
--
Jonas Fonseca
^ permalink raw reply
* Help designing work flow
From: John Dlugosz @ 2009-03-05 20:17 UTC (permalink / raw)
To: git
I know we (my group) should use "topic" branches and apply them back to
the dev branch when done. There is concern that the commit history gets
too full of detailed stuff, especially with several developers, that you
can't tell what "really changed". So, our dev branch should appear to
contain only commit nodes representing completed assignments; not every
day's checkpoint and trying to keep one's own stuff on top to avoid
merging later.
I guess that's how it is on these Open Source projects where patches are
submitted by email and applied by the maintainer. We don't see the
details, just the final patch. But, my situation will be developers
gathered around an in-house master repo, and everyone should be able to
push their own changes as assignments are completed.
What is the best procedure to achieve that? Or what are some good
alternatives with trade-offs?
I see that if a topic branch is merged (disabling FF if applicable), the
main line (leftmost parent) will be a history of completed topics. But,
we don't need to keep the detailed side-branches forever, and even if
gitk and other visualization tools can be told to just show the main
line, advanced use such as git log this..that will forever be packed
with the micro-details.
So, unless someone has more input along that line, I'm assuming that we
want to apply the completed topic as a single-parent commit. That is
the natural result if preparing patches and then applying them, but is
there a simpler, direct way to do that in git?
The detailed topic branches can be kept around for a while, for the
original author to extend if it needs to be returned to, and to examine
if the gestalt change in the single commit is too overwhelming to
understand, or to help figure out what might have broken. But after a
while they can be deleted and then gc will free up the disk space.
Anything else I should look into?
--John
TradeStation Group, Inc. is a publicly-traded holding company (NASDAQ GS: TRAD) of three operating subsidiaries, TradeStation Securities, Inc. (Member NYSE, FINRA, SIPC and NFA), TradeStation Technologies, Inc., a trading software and subscription company, and TradeStation Europe Limited, a United Kingdom, FSA-authorized introducing brokerage firm. None of these companies provides trading or investment advice, recommendations or endorsements of any kind. The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited.
If you received this in error, please contact the sender and delete the material from any computer.
^ 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