* Re: Windows support
From: Shawn O. Pearce @ 2007-07-26 7:13 UTC (permalink / raw)
To: hanwen
Cc: Johannes Schindelin, git, Junio C Hamano, Dmitry Kakurin,
Nguyen Thai Ngoc Duy
In-Reply-To: <f329bf540707260002p117937tc9bc70050ef87838@mail.gmail.com>
Han-Wen Nienhuys <hanwenn@gmail.com> wrote:
> 2007/7/25, Johannes Schindelin <Johannes.Schindelin@gmx.de>:
> >Did you succeed in adding perl?
>
> >It is not that important, because I plan
> >to make git-gui the main user interface with this installer. But Junio
> >keeps adding Perl scripts (ATM add -i and remote) that I have to convert
> >later...
>
> I don't see what this is good for.
What git-gui is good for? Its a GUI. For people who perfer to use
mice and push buttons over keys and a command prompt. A large number
of people in this world (many of them on Windows) like these things.
Me, I'm more command line than I am GUI, yet I develop git-gui.
So I find myself using it a lot, just so I can eat my own dogfood.
Or do you mean Dscho's other point about rewriting tools into C?
> I would suggest to making a clear
> decision of what are recommended languages, and move everything else
> to contrib/ .. Currently, C and bash seem the most reasonable choice,
> but you could decide for perl, but then the consequence should be that
> the bash scripts are translated into perl. Having both bash and perl
> serves no purpose, and will lead to duplication of library code to
> interact with the git binary.
Sure, but there's some stuff that shell is good at, and other stuff
that Perl is good at. Forcing everything into one mold while we
prototype new features is really limiting.
But both are slower on fork challenged systems than using native C.
Look at git-fetch for example; my ~400+ branch repository is taking
upwards of 5 minutes to run a no-argument, no-changes git-fetch in.
All sh and fork overhead.
--
Shawn.
^ permalink raw reply
* Re: [PATCH] Teach git-gui to split hunks
From: Shawn O. Pearce @ 2007-07-26 7:07 UTC (permalink / raw)
To: David Kastrup; +Cc: Johannes Schindelin, git
In-Reply-To: <85ir8790lj.fsf@lola.goethe.zz>
David Kastrup <dak@gnu.org> wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>
> > When you select the context menu item "Split Hunk" in the diff area,
> > git-gui will now split the current hunk so that a new hunk starts at
> > the current position.
> >
> > For this to work, apply has to be called with --unidiff-zero, since
> > the new hunks can start or stop with a "-" or "+" line.
>
> Unless one splits right at the beginning or end of an existing hunk,
> wouldn't there be context which one could use? Or does it confuse
> patch when adjacent hunks have overlapping contexts? At least if the
> first hunk patches what is to be used as context in the second hunk, I
> could imagine this. And there is really no danger of losing synch in
> this situation, anyhow. So it would be more of a convenience thing
> than anything else to be able to omit --unidiff-zero.
Yea, there's context there. Junio and I talked about this patch on
#git a few minutes ago. I really appreciate that Dscho wrote it,
especially given that he hasn't really been into Tcl hacking for
Git much before. But I'd really like to save/create context, like
`git add -i` does, so that we don't have to use --unidiff-zero here.
It won't matter if git-apply rejected overlapping context in this
case. git-gui will only ever feed one hunk at a time to git-apply.
And if things get really f'd in the diff buffer the user can easily
regenerate it (right click, Refresh).
Right now git-gui's apply doesn't correctly update the other hunk
headers when you apply a hunk. I've seen git-apply fail on some
hunks just for this reason. Refreshing the diff (so git recomputes
the headers) works around the issue. So I'm a little worried about
using --unidiff-zero here.
--
Shawn.
^ permalink raw reply
* Re: [PATCH 3/5] Clean up work-tree handling
From: Junio C Hamano @ 2007-07-26 7:06 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0707260729150.14781@racer.site>
This seems to break t1020 and t1500, probably among other
things.
^ permalink raw reply
* Re: problem after cvsimport
From: Junio C Hamano @ 2007-07-26 7:02 UTC (permalink / raw)
To: Bert Douglas; +Cc: git
In-Reply-To: <46A8459C.7030202@tplogic.com>
Bert Douglas <bertd@tplogic.com> writes:
> Am I going to have to do "-f" a lot?
> How will I know when to do it?
> Why not do it all the time?
With recent enough git, you shouldn't even have to do that extra
"git checkout". It was noticed and fixed quite a while ago.
^ permalink raw reply
* Re: Windows support
From: Han-Wen Nienhuys @ 2007-07-26 7:02 UTC (permalink / raw)
To: Johannes Schindelin
Cc: git, Junio C Hamano, Shawn O. Pearce, Dmitry Kakurin,
Nguyen Thai Ngoc Duy
In-Reply-To: <Pine.LNX.4.64.0707260737170.14781@racer.site>
2007/7/25, Johannes Schindelin <Johannes.Schindelin@gmx.de>:
> Hi,
>
> [Funny, you quoted me, but culled _me_ from the Cc: list]
It's because gmane does not do SMTP
> > If you supply me with a shell script that will x-compile bash, I'll
> > hapily code the python spec. IMO the real problem is that bash is a unix
> > shell (tied to unix internals) and therefore, compiling it for something
> > as horrid as windows is far from trivial.
>
> Will do.
>
> Did you succeed in adding perl?
God forbid no. Perl is enormous, and I shudder at the thought of
making all those modules compile, or even worse, writing actual perl
code.
> It is not that important, because I plan
> to make git-gui the main user interface with this installer. But Junio
> keeps adding Perl scripts (ATM add -i and remote) that I have to convert
> later...
I don't see what this is good for. I would suggest to making a clear
decision of what are recommended languages, and move everything else
to contrib/ .. Currently, C and bash seem the most reasonable choice,
but you could decide for perl, but then the consequence should be that
the bash scripts are translated into perl. Having both bash and perl
serves no purpose, and will lead to duplication of library code to
interact with the git binary.
--
Han-Wen Nienhuys - hanwen@xs4all.nl - http://www.xs4all.nl/~hanwen
^ permalink raw reply
* Re: [PATCH 3/5] Clean up work-tree handling
From: Shawn O. Pearce @ 2007-07-26 6:56 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git, gitster
In-Reply-To: <Pine.LNX.4.64.0707260729150.14781@racer.site>
Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> In related news, there is a long standing bug fixed: when in
> .git/bla/x.git/, which is a bare repository, git formerly assumed
> ../.. to be the appropriate git dir.
Heh. I spent about 10 minutes last week trying to understand why
git-new-workdir was failing horribly on one user's system.
Turns out they once managed to do:
cd /
git init
a long, long, long time ago and just didn't notice it until now. git
kept finding /.git rather than the .git it was supposed to locate,
which was a bare repository in $HOME/.storage-pool/dayjob.git.
--
Shawn.
^ permalink raw reply
* Re: problem after cvsimport
From: Bert Douglas @ 2007-07-26 6:56 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vlkd3c16z.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
> Bert Douglas <bertd@tplogic.com> writes:
>
>
>> I am new to git, so probably doing something wrong.
>> Hope somebody can enlighten me.
>> Here is what happened so far.
>>
>> Followed instructions here:
>> http://www.kernel.org/pub/software/scm/git/docs/cvs-migration.html
>>
>> Did command like this:
>>
>> $ git cvsimport -C <destination> <module>
>>
>> This was done from top level of existing cvs working directory.
>> Destination was new empty directory, outside the cvs tree.
>>
>> It worked for several hours and seemed to complete ok.
>> I can look at history in destination git directory with gitk and git log.
>> All the stuff in ".git" looks normal, as far as I can tell.
>>
>> But I have no files in the working directory.
>> When I do command:
>> $git checkout master
>>
>> I get a bunch of lines to console with "D" in front.
>> Btw, what does that mean? Nothing about it in "man git-checkout" or elsewhere that I can find.
>> Then it says -- Already on branch "master"
>>
>> But working directory is still empty.
>>
>
> Have you tried "git checkout -f" after that? With recent enough
> git, "git cvsimport -C <destination> <module>" from the top
> level of existing cvs working directory, with nonexistent
> destination directory (that is, you let "git cvsimport -C" to
> create that destination directory) would run "git checkout -f"
> for you.
>
Somehow I missed that option.
That worked. Very fast. Thanks.
Am I going to have to do "-f" a lot?
How will I know when to do it?
Why not do it all the time?
^ permalink raw reply
* Re: Windows support
From: Shawn O. Pearce @ 2007-07-26 6:53 UTC (permalink / raw)
To: Steffen Prohaska; +Cc: Dmitry Kakurin, Steven Grimm, git
In-Reply-To: <08588116-8E66-4F40-BC77-E0B272BE7776@zib.de>
Steffen Prohaska <prohaska@zib.de> wrote:
> On Jul 26, 2007, at 5:15 AM, Shawn O. Pearce wrote:
> >git-gui is fairly well supported under Cygwin, as I use it a lot
> >in my day-job. As do a lot of my coworkers. Which actually gives
> >me a pretty good testing ground; ~20 people all beating on git-gui
> >all day long is a pretty sizable testing group. I actually wonder
> >some days if git-gui is better tested on Cygwin than it is on Linux.
>
> So apparently you're working in a reasonably sized group of people all
> testing git on cygwin. I'd be completely satisfied if git ran rock solid
> on cygwin.
It is just as rock solid as it is on Mac OS X (my real Git
development system) and Solaris. If your Cygwin DLL does not
support pread() you do need to compile with NO_PREAD=1, but that's
a minor issue. Personally I build Git on Cygwin with pread() and
mmap() enabled and it runs fine. Of course we only use it on local
drives, and only on NTFS drives.
As has been stated already, Git's checksums work nicely to make
sure data hasn't been corrupted. I've seen one user have trouble
with checksums failing in his repository. Usually he recopies it
from another user and picks up where he left off. Twice I've seen
his packfile corrupted and Git caught the corruption. We seriously
suspect some bad blocks on his drive. But budget says we cannot
replace the disk for another 4 years.
> I found the following list of warnings about cygwin in the wiki
> entry WindowsInstall [1]. Some points look quite scary to me.
>
> What is your real-world experience? Are the warning still valid?
> Must I really fear to break cygwin if I press Ctrl-C?
Its not that Cygwin breaks. Its that sometimes pressing Ctrl-C
doesn't actually stop the process, e.g. the signal isn't sent or
just gets ignored. So its annoying because you can't abort things
as readily as you might on a good UNIX. Sometimes you get weird
stack traces from a Git process when you Ctrl-C it. But I also see
this same garbage out of a native Windows JVM when I Ctrl-C it from
a Cygwin bash. Its just general Cygwin-ism or something.
Despite those failures I've never seen that stack dump actually
corrupt Git data. Think about it. Git needs to be safe on any
platform, even if the running Git program terminates unexpectedly
in the middle of an operation, such as because of an OOM from the
kernel, or an angry admin `kill -9`ing it. So this little stack
spew is just annoying more than anything.
> Do I really need to reboot regularly? I don't think this is an
> option. Nowadays our Windows boxes run for months, too. I can't
> seriously tell people that they need to regularly reboot if they
> want to use git.
I *never* reboot my Windows system at day-job. Except when our
local adminstration staff shoves some Microsoft uber-patch down
onto our systems and that patch forces us to reboot the machine.
So I never reboot for Cygwin (or Git's) sake. Ever.
> Here's the list, copied from http://git.or.cz/gitwiki/WindowsInstall
>
> * Use git on local NTFS disks -- Network drives disks don't
> support the filesystem semantics GIT needs; for interoperability
> purposes you can store bare repositories on FAT32 disks.
Still true. Network drives have some issues as the SMB protocol
doesn't support everything nicely. NTFS locally is fine. FAT32 has
issues with mmap() not being well supported. If you must use
FAT32 compile Git with NO_MMAP. Which is the default on Cygwin,
as a lot of people still use FAT32.
> * Be careful with the case in filenames. Similarly, avoid special
> chars in filenames.
This is true. Git doesn't like getting file names with case only
differences on such a platform. E.g. just today I wanted to do
the following:
git mv foo.c Foo.c
but had to instead do:
git mv foo.c CRAP && git mv CRAP Foo.c
because the former won't work on a filesystem that ignores case.
I have the same problem on my Mac OS X HFS+ volume as it also
ignores case.
> * Run git gc early and often. There are slowdowns with many
> unpacked objects. Be careful to not create very big packfiles (bigger
> than 2 Gb).
Both of these are still true. git-gui on Windows suggests a repack
if you have ~256 loose objects, on UNIX platforms it suggest a repack
at ~2048 loose objects. The problem is really just a performance
issue, the more files we have to open to access data the slower
things go. The loose objects tend to be the really recent stuff
(that's why they aren't packed yet) and the really recent stuff
tends to be what is accessed most.
Opening 200 files takes time on Windows. Its just a limitation
of the OS apparently. And its a fundamental property of the Git
object store that we always write to loose objects first, as its
fast and easy to make safe.
Another aside to this is `git grep --cached` or `git grep ... TREE`
is *always* faster for me then grepping the working directory.
The first two will return nearly instantly (tiny lag) while the
working directory grep will take days. On Linux and Mac OS X the
exact reverse is true, the working directory grep is usually faster
if the disk cache is hot.
> * Avoid using ActiveState Perl if possible. Ask in the
> MailingLists if you must.
Yea, we've had some issues with that. This comes from one particular
user (Alex Riesen) who uses Cygwin but for strange reasons is
not allowed to use the Cygwin perl and instead must only use the
ActiveState Perl. We've had some issues in the past with our Perl
scripts running on that perl port. Alex has fixed many of them,
but some may still be lurking.
> * Try to avoid interrupting (Ctrl-C) processes - it breaks cygwin.
Already talked about above.
> * Consider setting core.fileMode to false (git repo-config
> core.fileMode false) if file modes are frequently the only
> differences detected by Git. Many Windows applications make the
> execute bit be set in Cygwin when they save a file. Besides Cygwin
> detects file mode by stupid combination of content analysis, file
> name extension and moon phase.
We currently default core.fileMode to false on Cygwin, for this
very reason. We used to not do that. We got smarter and realized
that although Cygwin itself (and all Cygwin tools) will properly
handle the executable bit on NTFS native Windows tools (e.g. Eclipse)
won't. Users use the native Windows tools, then blame Git. So we
disable it.
> * Insert "set CYGWIN=tty binmode" after the first line of C:
> \cygwin\cygwin.bat, so you can use Ctrl-z in cygwin's bash to suspend
> a program.
Oooooh. I did not know this tip. I still just cuss at Cygwin
anytime I want to suspend a job and cannot.
> * Windows usually writes end-of-line as CRLF, while Unix/POSIX
> writes LF. This can cause a variety of problems. There are current
> efforts to address this.
See the crlf feature in gitattributes. You can now have Git create
working tree files in CRLF format, but check them into the object
database with only LF.
> * Setup binary mode for cygwin (there is an option in cygwin's
> setup program), otherwise Cygwin mangles everything read and written
> (Git repos have binary files in control structures).
I think binary mode is the default now on Cygwin. It used to not
be. Because of this problem.
> * Avoid big repos.
Yea, sort of. I'm using about 180M (fully packed as best as I can
make Git do) and its fine. I don't know what a definition of "big"
is.
> * Avoid big blobs (very big files. Basically anything larger than
> 10Mb is too big).
This I can't speak to. All of my blobs are source code, so they
are small-ish.
> * Avoid big trees (directories with many files in them).
Probably true. Most of my trees are reasonably well distributed
(they aren't that big). I think my largest is 900 files in the
same directory.
> * Avoid deep hierarchies.
I/use/java/programs/on/windows/and/much/of/my/source/is/in/that/format.
:-) I don't really have issues with deep trees, and I have some
pretty darn deep source code trees.
> * Reboot regularly (memory fragmentation)
Don't see that.
> * Defragment often (filesystems fragmentation)
Yes! Very much so. The packfiles are the first things to fragment,
and what with all of the small files that Git creates, especially
with frequent branch switching, and then the small object files
that my build system creates, my drive is almost always completely
fragmented.
Which reminds me, I need to defrag again...
--
Shawn.
^ permalink raw reply
* Re: [PATCH 1/5] Add is_absolute_path(), make_absolute_path() and normalize_path()
From: Junio C Hamano @ 2007-07-26 6:53 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git, gitster
In-Reply-To: <Pine.LNX.4.64.0707260724010.14781@racer.site>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> +/* strip out .. and . */
> +char *normalize_path(char *path)
> +{
This always makes one worry what should happen when foo/../bar
is _not_ bar in reality (i.e. foo is symlink to a directory
elsewhere).
It depends on what kind of "path" you feed to the function (and
its caller, make_absolute_path()). If you always feed a path
from the index (or a path obtained by recursively reading a
tree), it is Ok. If it is arbitrary path obtained from the user
or the filesystem, it is not.
^ permalink raw reply
* Re: [PATCH] rebase -i: fix overzealous output redirection
From: Johannes Schindelin @ 2007-07-26 6:48 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vejivacun.fsf@assigned-by-dhcp.cox.net>
Hi,
On Wed, 25 Jul 2007, Junio C Hamano wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>
> > When squashing, you no longer saw what the editor had to say to you
> > after commit 'Shut "git rebase -i" up when no --verbose was given'
> > (if you used a console based editor, at least).
> >
> > Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
> > ---
> > This bit me real hard when cleaning up the work-tree patch
> > series.
>
> Heh, good catch.
>
> At least you are eating your own dog food, which is a very
> assuring thing before the feature release. Thanks.
I try my very best! Though I have to go to bed without having had a
chance to work on the send-pack bug :-(
Good night, and good luck,
Dscho
^ permalink raw reply
* Re: Windows support
From: Junio C Hamano @ 2007-07-26 6:48 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Noel Grandin, Steffen Prohaska, Dmitry Kakurin, git
In-Reply-To: <Pine.LNX.4.64.0707260745030.14781@racer.site>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> On Wed, 25 Jul 2007, Noel Grandin wrote:
>
>> Cygwin tries to make Windows look like unix (from a command-line POV),
>> so it very much runs against the grain of "real" windows programs.
>
> Okay, just because you insist, I will introduce a crash, so that it does
> not look too much like Unix. Maybe I will do this as an alternate
> hang/crash.
You forgot an obligatory smiley. That is not amusing.
^ permalink raw reply
* Re: Windows support
From: Johannes Schindelin @ 2007-07-26 6:46 UTC (permalink / raw)
To: Noel Grandin; +Cc: Steffen Prohaska, Dmitry Kakurin, git
In-Reply-To: <46A76D83.6020005@peralex.com>
Hi,
On Wed, 25 Jul 2007, Noel Grandin wrote:
> Cygwin tries to make Windows look like unix (from a command-line POV),
> so it very much runs against the grain of "real" windows programs.
Okay, just because you insist, I will introduce a crash, so that it does
not look too much like Unix. Maybe I will do this as an alternate
hang/crash.
Ciao,
Dscho
^ permalink raw reply
* Re: Windows support
From: Johannes Schindelin @ 2007-07-26 6:40 UTC (permalink / raw)
To: Han-Wen Nienhuys
Cc: git, Junio C Hamano, Shawn O. Pearce, Dmitry Kakurin,
Nguyen Thai Ngoc Duy
In-Reply-To: <46A8378A.6050201@xs4all.nl>
Hi,
[Funny, you quoted me, but culled _me_ from the Cc: list]
On Wed, 25 Jul 2007, Han-Wen Nienhuys wrote:
> Johannes Schindelin wrote:
> >> If that is the case, "Git for Windows" probably should package MSYS as
> >> part of it, I would think, to match the expectation of the users there.
> >> I know two Johannes'es and Han-Wen spent quite a lot of effort on
> >> Windows port and packaging, but perhaps that little (well, I should not
> >> be judging if that is a little or huge, as I do not do Windows)
> >> finishing touch would make Windows users much happier?
> >
> > Windows users are only happy when they can bug developers.
> >
> > Seriously again, the biggest problem with Han-Wen's installer was that it
> > insists on cross-compiling _all_ the packages. This makes it easy for
> > Han-Wen to upgrade packages and compile the thing on Linux in one go.
> > However, it never worked with bash, and I could not fix it: I can read
> > Python, but not _that_ Python.
> >
>
> The problem is not really the python.
For me, it is. Probably you know by now that I am not really a fan of
Python, mainly because people can write unelegant code which looks
elegant.
> If you supply me with a shell script that will x-compile bash, I'll
> hapily code the python spec. IMO the real problem is that bash is a unix
> shell (tied to unix internals) and therefore, compiling it for something
> as horrid as windows is far from trivial.
Will do.
Did you succeed in adding perl? It is not that important, because I plan
to make git-gui the main user interface with this installer. But Junio
keeps adding Perl scripts (ATM add -i and remote) that I have to convert
later...
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] rebase -i: fix overzealous output redirection
From: Junio C Hamano @ 2007-07-26 6:38 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0707260735150.14781@racer.site>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> When squashing, you no longer saw what the editor had to say to you
> after commit 'Shut "git rebase -i" up when no --verbose was given'
> (if you used a console based editor, at least).
>
> Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
> ---
> This bit me real hard when cleaning up the work-tree patch
> series.
Heh, good catch.
At least you are eating your own dog food, which is a very
assuring thing before the feature release. Thanks.
^ permalink raw reply
* [PATCH] rebase -i: fix overzealous output redirection
From: Johannes Schindelin @ 2007-07-26 6:35 UTC (permalink / raw)
To: git, gitster
When squashing, you no longer saw what the editor had to say to you
after commit 'Shut "git rebase -i" up when no --verbose was given'
(if you used a console based editor, at least).
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---
This bit me real hard when cleaning up the work-tree patch
series.
git-rebase--interactive.sh | 4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/git-rebase--interactive.sh b/git-rebase--interactive.sh
index 93289c0..9a88335 100755
--- a/git-rebase--interactive.sh
+++ b/git-rebase--interactive.sh
@@ -250,10 +250,12 @@ do_next () {
case "$(peek_next_command)" in
squash)
EDIT_COMMIT=
+ USE_OUTPUT=output
cp "$MSG" "$SQUASH_MSG"
;;
*)
EDIT_COMMIT=-e
+ USE_OUTPUT=
test -f "$SQUASH_MSG" && rm "$SQUASH_MSG"
esac
@@ -267,7 +269,7 @@ do_next () {
# This is like --amend, but with a different message
eval "$author_script"
export GIT_AUTHOR_NAME GIT_AUTHOR_EMAIL GIT_AUTHOR_DATE
- output git commit -F "$MSG" $EDIT_COMMIT
+ $USE_OUTPUT git commit -F "$MSG" $EDIT_COMMIT
;;
t)
cp "$MSG" "$GIT_DIR"/MERGE_MSG
--
1.5.3.rc2.42.gda8d-dirty
^ permalink raw reply related
* [PATCH 5/5] With work-trees possibly inside git-dir, be more generous
From: Johannes Schindelin @ 2007-07-26 6:32 UTC (permalink / raw)
To: git, gitster
The earlier work-tree behaviour was seriously bogus. For regular working
tree operations, it checked if inside git dir. That makes no sense, of
course, since the check should be for a work tree, and nothing else.
Fix that.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---
Please consider giving this a real hard beating. I think the
old series was so bad only because nobody cared (including me).
builtin-ls-files.c | 8 +++++---
builtin-rev-parse.c | 6 ++++++
git-sh-setup.sh | 3 +--
git.c | 7 +++++--
4 files changed, 17 insertions(+), 7 deletions(-)
diff --git a/builtin-ls-files.c b/builtin-ls-files.c
index 61577ea..d36181a 100644
--- a/builtin-ls-files.c
+++ b/builtin-ls-files.c
@@ -469,9 +469,11 @@ int cmd_ls_files(int argc, const char **argv, const char *prefix)
break;
}
- if (require_work_tree &&
- (!is_inside_work_tree() || is_inside_git_dir()))
- die("This operation must be run in a work tree");
+ if (require_work_tree && !is_inside_work_tree()) {
+ const char *work_tree = get_git_work_tree();
+ if (!work_tree || chdir(work_tree))
+ die("This operation must be run in a work tree");
+ }
pathspec = get_pathspec(prefix, argv + i);
diff --git a/builtin-rev-parse.c b/builtin-rev-parse.c
index 497903a..3804541 100644
--- a/builtin-rev-parse.c
+++ b/builtin-rev-parse.c
@@ -320,7 +320,13 @@ int cmd_rev_parse(int argc, const char **argv, const char *prefix)
continue;
}
if (!strcmp(arg, "--show-cdup")) {
+ const char *work_tree = get_git_work_tree();
const char *pfx = prefix;
+
+ if (work_tree) {
+ printf("%s\n", work_tree);
+ continue;
+ }
while (pfx) {
pfx = strchr(pfx, '/');
if (pfx) {
diff --git a/git-sh-setup.sh b/git-sh-setup.sh
index c51985e..7bef43f 100755
--- a/git-sh-setup.sh
+++ b/git-sh-setup.sh
@@ -59,8 +59,7 @@ cd_to_toplevel () {
}
require_work_tree () {
- test $(git rev-parse --is-inside-work-tree) = true &&
- test $(git rev-parse --is-inside-git-dir) = false ||
+ test $(git rev-parse --is-inside-work-tree) = true ||
die "fatal: $0 cannot be used without a working tree."
}
diff --git a/git.c b/git.c
index 5df10d3..03ce3bb 100644
--- a/git.c
+++ b/git.c
@@ -273,8 +273,11 @@ static int run_command(struct cmd_struct *p, int argc, const char **argv)
if (p->option & USE_PAGER)
setup_pager();
if ((p->option & NEED_WORK_TREE) &&
- (!is_inside_work_tree() || is_inside_git_dir()))
- die("%s must be run in a work tree", p->cmd);
+ !is_inside_work_tree()) {
+ const char *work_tree = get_git_work_tree();
+ if (!work_tree || chdir(work_tree))
+ die("%s must be run in a work tree", p->cmd);
+ }
trace_argv_printf(argv, argc, "trace: built-in: git");
status = p->fn(argc, argv, prefix);
--
1.5.3.rc2.42.gda8d-dirty
^ permalink raw reply related
* [PATCH 4/5] Add test for sanitized work-tree behaviour
From: Johannes Schindelin @ 2007-07-26 6:32 UTC (permalink / raw)
To: git, gitster
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---
This test was also something that I almost got eye cancer from.
I am very willing to extend this script with many more test
cases. Just give me a recipe what you would like to have tested.
t/t1501-worktree.sh | 157 ++++++++++++++++++++++++++++----------------------
1 files changed, 88 insertions(+), 69 deletions(-)
diff --git a/t/t1501-worktree.sh b/t/t1501-worktree.sh
index aadeeab..145c28e 100755
--- a/t/t1501-worktree.sh
+++ b/t/t1501-worktree.sh
@@ -3,90 +3,109 @@
test_description='test separate work tree'
. ./test-lib.sh
+i=1
+
test_rev_parse() {
- name=$1
- shift
-
- test_expect_success "$name: is-bare-repository" \
- "test '$1' = \"\$(git rev-parse --is-bare-repository)\""
- shift
- [ $# -eq 0 ] && return
-
- test_expect_success "$name: is-inside-git-dir" \
- "test '$1' = \"\$(git rev-parse --is-inside-git-dir)\""
- shift
- [ $# -eq 0 ] && return
-
- test_expect_success "$name: is-inside-work-tree" \
- "test '$1' = \"\$(git rev-parse --is-inside-work-tree)\""
- shift
- [ $# -eq 0 ] && return
-
- test_expect_success "$name: prefix" \
- "test '$1' = \"\$(git rev-parse --show-prefix)\""
- shift
- [ $# -eq 0 ] && return
+ name="$1"
+ for option in --is-bare-repository --is-inside-git-dir \
+ --is-inside-work-tree --show-prefix
+ do
+ shift
+ test_expect_success "$name: $option" \
+ "test '$1' = \"\$(git rev-parse $option)\""
+i=$(($i+1))
+test $i = $STOPI && gdb --args git rev-parse $option
+ test $# -eq 1 && return
+ done
+}
+
+# usage: set_repo <working directory> [<git dir> [<work tree> [env]]]
+set_repo () {
+ cd "$1"
+ say "switching to $(pwd) with GIT_DIR $2"
+
+ test -z "$2" || {
+ GIT_DIR="$2"
+ GIT_CONFIG="$2"/config
+ export GIT_DIR GIT_CONFIG
+ }
+
+ test -z "$3" ||
+ case "$4" in
+ env)
+ GIT_WORK_TREE="$3"
+ export GIT_WORK_TREE
+ git config core.workTree non-existent
+ ;;
+ *)
+ git config core.workTree "$3"
+ esac
}
-mkdir -p work/sub/dir || exit 1
-mv .git repo.git || exit 1
+test_expect_success 'setup' '
+ mkdir -p work/sub/dir &&
+ mv .git repo.git
+'
say "core.worktree = relative path"
-export GIT_DIR=repo.git
-export GIT_CONFIG=$GIT_DIR/config
-unset GIT_WORK_TREE
-git config core.worktree ../work
-test_rev_parse 'outside' false false false
-cd work || exit 1
-export GIT_DIR=../repo.git
-export GIT_CONFIG=$GIT_DIR/config
-test_rev_parse 'inside' false false true ''
-cd sub/dir || exit 1
-export GIT_DIR=../../../repo.git
-export GIT_CONFIG=$GIT_DIR/config
+
+set_repo . repo.git ../work
+test_rev_parse 'outside git dir' false false false
+
+set_repo work ../repo.git
+test_rev_parse 'inside git dir' false false true ''
+
+set_repo sub/dir ../../../repo.git
test_rev_parse 'subdirectory' false false true sub/dir/
-cd ../../.. || exit 1
+cd ../../..
say "core.worktree = absolute path"
-export GIT_DIR=$(pwd)/repo.git
-export GIT_CONFIG=$GIT_DIR/config
-git config core.worktree "$(pwd)/work"
-test_rev_parse 'outside' false false false
-cd work || exit 1
-test_rev_parse 'inside' false false true ''
-cd sub/dir || exit 1
+set_repo . $(pwd)/repo.git $(pwd)/work
+test_rev_parse 'outside git dir' false false false
+
+set_repo work
+test_rev_parse 'inside git dir' false false true ''
+
+set_repo sub/dir
test_rev_parse 'subdirectory' false false true sub/dir/
-cd ../../.. || exit 1
+cd ../../..
say "GIT_WORK_TREE=relative path (override core.worktree)"
-export GIT_DIR=$(pwd)/repo.git
-export GIT_CONFIG=$GIT_DIR/config
-git config core.worktree non-existent
-export GIT_WORK_TREE=work
-test_rev_parse 'outside' false false false
-cd work || exit 1
-export GIT_WORK_TREE=.
-test_rev_parse 'inside' false false true ''
-cd sub/dir || exit 1
-export GIT_WORK_TREE=../..
+
+set_repo . $(pwd)/repo.git work env
+test_rev_parse 'outside git dir' false false false
+
+set_repo work "" . env
+test_rev_parse 'inside git dir' false false true ''
+
+set_repo sub/dir "" ../../ env
test_rev_parse 'subdirectory' false false true sub/dir/
cd ../../.. || exit 1
+say "GIT_WORK_TREE=absolute path, work tree below git dir"
+
mv work repo.git/work
-say "GIT_WORK_TREE=absolute path, work tree below git dir"
-export GIT_DIR=$(pwd)/repo.git
-export GIT_CONFIG=$GIT_DIR/config
-export GIT_WORK_TREE=$(pwd)/repo.git/work
-test_rev_parse 'outside' false false false
-cd repo.git || exit 1
-test_rev_parse 'in repo.git' false true false
-cd objects || exit 1
-test_rev_parse 'in repo.git/objects' false true false
-cd ../work || exit 1
-test_rev_parse 'in repo.git/work' false false true ''
-cd sub/dir || exit 1
-test_rev_parse 'in repo.git/sub/dir' false false true sub/dir/
-cd ../../../.. || exit 1
+set_repo . $(pwd)/repo.git $(pwd)/repo.git/work env
+test_rev_parse 'outside git dir' false false false
+
+set_repo repo.git
+test_rev_parse 'in repo.git' false true false
+
+set_repo objects
+test_rev_parse 'in repo.git/objects' false true false
+
+set_repo ../work
+test_rev_parse 'in repo.git/work' false true true ''
+
+set_repo sub/dir
+test_rev_parse 'in repo.git/sub/dir' false true true sub/dir/
+cd ../../../..
+
+test_expect_success 'repo finds its work tree' '
+ (cd repo.git &&
+ : > work/sub/dir/untracked &&
+ test sub/dir/untracked = "$(git ls-files --others)")
+'
test_done
--
1.5.3.rc2.42.gda8d-dirty
^ permalink raw reply related
* Re: Windows support
From: Noel Grandin @ 2007-07-25 15:34 UTC (permalink / raw)
To: Steffen Prohaska; +Cc: Dmitry Kakurin, git
In-Reply-To: <693D0FFF-B271-4781-BCE2-3BF00C8BF426@zib.de>
Cygwin tries to make Windows look like unix (from a command-line POV),
so it very much runs against the grain of "real" windows programs.
Plus, it's a pain to install and invoke,
and doesn't deal nicely with real windows paths (it maps the windows
filesystem to a unix-y style single root path structure),
Steffen Prohaska wrote:
>
> On Jul 25, 2007, at 12:35 PM, Dmitry Kakurin wrote:
>
>> How serious are you guys about Windows support?
>> I'm talking fully-functional port, not Cygwin.
>
> What's wrong with the Cygwin port?
>
> Is it just that windows developer hate cygwin because it's to
> complex to install or is there any severe limitation?
> functionality? stability? performance?
>
> I'm personally only working on Windows if force to, but people
> are asking me the same question that you have. Does git
> seriously and fully support Windows?
>
> Steffen
> -
> 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
>
Disclaimer: http://www.peralex.com/disclaimer.html
^ permalink raw reply
* [PATCH 3/5] Clean up work-tree handling
From: Johannes Schindelin @ 2007-07-26 6:30 UTC (permalink / raw)
To: git, gitster
The old version of work-tree support was an unholy mess, barely readable,
and not to the point.
For example, why do you have to provide a worktree, when it is not used?
As in "git status". Now it works.
Another riddle was: if you can have work trees inside the git dir, why
are some programs complaining that they need a work tree?
IOW when inside repo.git/work, where GIT_DIR points to repo.git
and GIT_WORK_TREE to work, and cwd is work, --is-inside-git-dir _must_
return true, because it is _in the git dir_, but scripts _must_ test
for the right thing.
In related news, there is a long standing bug fixed: when in
.git/bla/x.git/, which is a bare repository, git formerly assumed
../.. to be the appropriate git dir.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---
Okay, this diffstat looks so good also because I refactored some
useful stuff out. So it is only half cheating.
However, from the diff you only can see how horrible the code
looked like. The new version of setup_git_directory_gently()
actually resembles the pre-work-tree version very much,
with the notable exception that it is tested for bare repo
right after testing .git/, and only after both failed, continue
to assume that we're in a subdirectory.
cache.h | 2 +
environment.c | 31 +++++--
git.c | 2 +-
setup.c | 242 +++++++++++++++++++-------------------------------------
4 files changed, 107 insertions(+), 170 deletions(-)
diff --git a/cache.h b/cache.h
index b242147..7c55a1d 100644
--- a/cache.h
+++ b/cache.h
@@ -208,12 +208,14 @@ enum object_type {
extern int is_bare_repository_cfg;
extern int is_bare_repository(void);
extern int is_inside_git_dir(void);
+extern char *git_work_tree_cfg;
extern int is_inside_work_tree(void);
extern const char *get_git_dir(void);
extern char *get_object_directory(void);
extern char *get_refs_directory(void);
extern char *get_index_file(void);
extern char *get_graft_file(void);
+extern const char *get_git_work_tree(void);
#define ALTERNATE_DB_ENVIRONMENT "GIT_ALTERNATE_OBJECT_DIRECTORIES"
diff --git a/environment.c b/environment.c
index f83fb9e..fa177ac 100644
--- a/environment.c
+++ b/environment.c
@@ -35,6 +35,10 @@ int pager_in_use;
int pager_use_color = 1;
int auto_crlf = 0; /* 1: both ways, -1: only when adding git objects */
+/* This is set by setup_git_dir_gently() and/or git_default_config() */
+char *git_work_tree_cfg;
+static const char *work_tree;
+
static const char *git_dir;
static char *git_object_dir, *git_index_file, *git_refs_dir, *git_graft_file;
@@ -62,15 +66,7 @@ static void setup_git_env(void)
int is_bare_repository(void)
{
- const char *dir, *s;
- if (0 <= is_bare_repository_cfg)
- return is_bare_repository_cfg;
-
- dir = get_git_dir();
- if (!strcmp(dir, DEFAULT_GIT_DIR_ENVIRONMENT))
- return 0;
- s = strrchr(dir, '/');
- return !s || strcmp(s + 1, DEFAULT_GIT_DIR_ENVIRONMENT);
+ return !get_git_work_tree();
}
const char *get_git_dir(void)
@@ -80,6 +76,23 @@ const char *get_git_dir(void)
return git_dir;
}
+const char *get_git_work_tree(void)
+{
+ static int initialized = 0;
+ if (!initialized) {
+ work_tree = getenv(GIT_WORK_TREE_ENVIRONMENT);
+ if (!work_tree) {
+ work_tree = git_work_tree_cfg;
+ if (work_tree && !is_absolute_path(work_tree))
+ work_tree = git_path(work_tree);
+ }
+ if (work_tree && !is_absolute_path(work_tree))
+ work_tree = xstrdup(make_absolute_path(work_tree));
+ initialized = 1;
+ }
+ return work_tree;
+}
+
char *get_object_directory(void)
{
if (!git_object_dir)
diff --git a/git.c b/git.c
index a647f9c..5df10d3 100644
--- a/git.c
+++ b/git.c
@@ -75,7 +75,7 @@ static int handle_options(const char*** argv, int* argc, int* envchanged)
*envchanged = 1;
} else if (!strcmp(cmd, "--work-tree")) {
if (*argc < 2) {
- fprintf(stderr, "No directory given for --work-tree.\n" );
+ error("No directory given for --work-tree.\n");
usage(git_usage_string);
}
setenv(GIT_WORK_TREE_ENVIRONMENT, (*argv)[1], 1);
diff --git a/setup.c b/setup.c
index 7b07144..9c0f5f6 100644
--- a/setup.c
+++ b/setup.c
@@ -1,4 +1,8 @@
#include "cache.h"
+#include "dir.h"
+
+static int inside_git_dir = -1;
+static int inside_work_tree = -1;
const char *prefix_path(const char *prefix, int len, const char *path)
{
@@ -170,100 +174,41 @@ static int is_git_directory(const char *suspect)
return 1;
}
-static int inside_git_dir = -1;
-
int is_inside_git_dir(void)
{
- if (inside_git_dir >= 0)
- return inside_git_dir;
- die("BUG: is_inside_git_dir called before setup_git_directory");
+ if (inside_git_dir < 0)
+ inside_git_dir = is_inside_dir(get_git_dir());
+ return inside_git_dir;
}
-static int inside_work_tree = -1;
-
int is_inside_work_tree(void)
{
- if (inside_git_dir >= 0)
- return inside_work_tree;
- die("BUG: is_inside_work_tree called before setup_git_directory");
-}
-
-static char *gitworktree_config;
-
-static int git_setup_config(const char *var, const char *value)
-{
- if (!strcmp(var, "core.worktree")) {
- if (gitworktree_config)
- strlcpy(gitworktree_config, value, PATH_MAX);
- return 0;
- }
- return git_default_config(var, value);
+ if (inside_work_tree < 0)
+ inside_work_tree = is_inside_dir(get_git_work_tree());
+ return inside_work_tree;
}
+/*
+ * We cannot decide in this function whether we are in the work tree or
+ * not, since the config can only be read _after_ this function was called.
+ */
const char *setup_git_directory_gently(int *nongit_ok)
{
static char cwd[PATH_MAX+1];
- char worktree[PATH_MAX+1], gitdir[PATH_MAX+1];
- const char *gitdirenv, *gitworktree;
- int wt_rel_gitdir = 0;
+ const char *gitdirenv;
+ int len, offset;
+ /*
+ * If GIT_DIR is set explicitly, we're not going
+ * to do any discovery, but we still do repository
+ * validation.
+ */
gitdirenv = getenv(GIT_DIR_ENVIRONMENT);
- if (!gitdirenv) {
- int len, offset;
-
- if (!getcwd(cwd, sizeof(cwd)-1))
- die("Unable to read current working directory");
-
- offset = len = strlen(cwd);
- for (;;) {
- if (is_git_directory(".git"))
- break;
- if (offset == 0) {
- offset = -1;
- break;
- }
- chdir("..");
- while (cwd[--offset] != '/')
- ; /* do nothing */
- }
-
- if (offset >= 0) {
- inside_work_tree = 1;
- git_config(git_default_config);
- if (offset == len) {
- inside_git_dir = 0;
- return NULL;
- }
-
- cwd[len++] = '/';
- cwd[len] = '\0';
- inside_git_dir = !prefixcmp(cwd + offset + 1, ".git/");
- return cwd + offset + 1;
- }
-
- if (chdir(cwd))
- die("Cannot come back to cwd");
- if (!is_git_directory(".")) {
- if (nongit_ok) {
- *nongit_ok = 1;
- return NULL;
- }
- die("Not a git repository");
- }
- setenv(GIT_DIR_ENVIRONMENT, cwd, 1);
- gitdirenv = getenv(GIT_DIR_ENVIRONMENT);
- if (!gitdirenv)
- die("getenv after setenv failed");
- }
-
- if (PATH_MAX - 40 < strlen(gitdirenv)) {
- if (nongit_ok) {
- *nongit_ok = 1;
+ if (gitdirenv) {
+ if (PATH_MAX - 40 < strlen(gitdirenv))
+ die("'$%s' too big", GIT_DIR_ENVIRONMENT);
+ if (is_git_directory(gitdirenv))
return NULL;
- }
- die("$%s too big", GIT_DIR_ENVIRONMENT);
- }
- if (!is_git_directory(gitdirenv)) {
if (nongit_ok) {
*nongit_ok = 1;
return NULL;
@@ -273,92 +218,58 @@ const char *setup_git_directory_gently(int *nongit_ok)
if (!getcwd(cwd, sizeof(cwd)-1))
die("Unable to read current working directory");
- if (chdir(gitdirenv)) {
- if (nongit_ok) {
- *nongit_ok = 1;
- return NULL;
- }
- die("Cannot change directory to $%s '%s'",
- GIT_DIR_ENVIRONMENT, gitdirenv);
- }
- if (!getcwd(gitdir, sizeof(gitdir)-1))
- die("Unable to read current working directory");
- if (chdir(cwd))
- die("Cannot come back to cwd");
/*
- * In case there is a work tree we may change the directory,
- * therefore make GIT_DIR an absolute path.
+ * Test in the following order (relative to the cwd):
+ * - .git/
+ * - . (bare)
+ * - ../.git/
+ * - ../../.git/
+ * etc.
*/
- if (gitdirenv[0] != '/') {
- setenv(GIT_DIR_ENVIRONMENT, gitdir, 1);
- gitdirenv = getenv(GIT_DIR_ENVIRONMENT);
- if (!gitdirenv)
- die("getenv after setenv failed");
- if (PATH_MAX - 40 < strlen(gitdirenv)) {
- if (nongit_ok) {
- *nongit_ok = 1;
- return NULL;
- }
- die("$%s too big after expansion to absolute path",
- GIT_DIR_ENVIRONMENT);
- }
- }
-
- strcat(cwd, "/");
- strcat(gitdir, "/");
- inside_git_dir = !prefixcmp(cwd, gitdir);
-
- gitworktree = getenv(GIT_WORK_TREE_ENVIRONMENT);
- if (!gitworktree) {
- gitworktree_config = worktree;
- worktree[0] = '\0';
- }
- git_config(git_setup_config);
- if (!gitworktree) {
- gitworktree_config = NULL;
- if (worktree[0])
- gitworktree = worktree;
- if (gitworktree && gitworktree[0] != '/')
- wt_rel_gitdir = 1;
+ offset = len = strlen(cwd);
+ if (is_git_directory(DEFAULT_GIT_DIR_ENVIRONMENT)) {
+ inside_git_dir = 0;
+ git_work_tree_cfg = xstrdup(cwd);
+ return NULL;
}
-
- if (wt_rel_gitdir && chdir(gitdirenv))
- die("Cannot change directory to $%s '%s'",
- GIT_DIR_ENVIRONMENT, gitdirenv);
- if (gitworktree && chdir(gitworktree)) {
- if (nongit_ok) {
- if (wt_rel_gitdir && chdir(cwd))
- die("Cannot come back to cwd");
- *nongit_ok = 1;
- return NULL;
- }
- if (wt_rel_gitdir)
- die("Cannot change directory to working tree '%s'"
- " from $%s", gitworktree, GIT_DIR_ENVIRONMENT);
- else
- die("Cannot change directory to working tree '%s'",
- gitworktree);
+ if (is_git_directory(".")) {
+ setenv(GIT_DIR_ENVIRONMENT, ".", 1);
+ inside_git_dir = 1;
+ inside_work_tree = 0;
+ return NULL;
}
- if (!getcwd(worktree, sizeof(worktree)-1))
- die("Unable to read current working directory");
- strcat(worktree, "/");
- inside_work_tree = !prefixcmp(cwd, worktree);
- if (gitworktree && inside_work_tree && !prefixcmp(worktree, gitdir) &&
- strcmp(worktree, gitdir)) {
- inside_git_dir = 0;
+ chdir("..");
+ for (;;) {
+ if (is_git_directory(DEFAULT_GIT_DIR_ENVIRONMENT))
+ break;
+ chdir("..");
+ do {
+ if (!offset) {
+ if (nongit_ok) {
+ if (chdir(cwd))
+ die("Cannot come back to cwd");
+ *nongit_ok = 1;
+ return NULL;
+ }
+ die("Not a git repository");
+ }
+ } while (cwd[--offset] != '/');
}
- if (!inside_work_tree) {
- if (chdir(cwd))
- die("Cannot come back to cwd");
+ if (offset == len)
return NULL;
- }
- if (!strcmp(cwd, worktree))
- return NULL;
- return cwd+strlen(worktree);
+ /* Make "offset" point to past the '/', and add a '/' at the end */
+ offset++;
+ cwd[len++] = '/';
+ cwd[len] = 0;
+ inside_git_dir = !prefixcmp(cwd + offset,
+ DEFAULT_GIT_DIR_ENVIRONMENT "/");
+ if (!inside_git_dir)
+ git_work_tree_cfg = xstrdup(cwd);
+ return cwd + offset;
}
int git_config_perm(const char *var, const char *value)
@@ -382,11 +293,16 @@ int git_config_perm(const char *var, const char *value)
int check_repository_format_version(const char *var, const char *value)
{
- if (strcmp(var, "core.repositoryformatversion") == 0)
- repository_format_version = git_config_int(var, value);
+ if (strcmp(var, "core.repositoryformatversion") == 0)
+ repository_format_version = git_config_int(var, value);
else if (strcmp(var, "core.sharedrepository") == 0)
shared_repository = git_config_perm(var, value);
- return 0;
+ else if (strcmp(var, "core.worktree") == 0) {
+ if (git_work_tree_cfg)
+ free(git_work_tree_cfg);
+ git_work_tree_cfg = xstrdup(value);
+ }
+ return 0;
}
int check_repository_format(void)
@@ -400,7 +316,13 @@ int check_repository_format(void)
const char *setup_git_directory(void)
{
- const char *retval = setup_git_directory_gently(NULL);
+ const char *retval = setup_git_directory_gently(NULL), *work_tree;
check_repository_format();
+ work_tree = get_git_work_tree();
+ if (work_tree) {
+ static char buffer[PATH_MAX + 1];
+ char *rel = get_relative_cwd(buffer, PATH_MAX, work_tree);
+ return rel && *rel ? strcat(normalize_path(rel), "/") : NULL;
+ }
return retval;
}
--
1.5.3.rc2.42.gda8d-dirty
^ permalink raw reply related
* Re: Windows support
From: Steffen Prohaska @ 2007-07-26 6:25 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Dmitry Kakurin, Steven Grimm, git
In-Reply-To: <20070726031546.GN32566@spearce.org>
On Jul 26, 2007, at 5:15 AM, Shawn O. Pearce wrote:
> Why Cygwin? Because I have to use Windows, but I'd rather use Linux.
> No, Linux isn't permitted. And Solaris/x86 is only allowed on
> "servers". I have yet to find a way to classify my desktop as
> a server. :-|
>
> git-gui is fairly well supported under Cygwin, as I use it a lot
> in my day-job. As do a lot of my coworkers. Which actually gives
> me a pretty good testing ground; ~20 people all beating on git-gui
> all day long is a pretty sizable testing group. I actually wonder
> some days if git-gui is better tested on Cygwin than it is on Linux.
>
> But as has been stated on this thread, Cygwin isn't native Windows.
So apparently you're working in a reasonably sized group of people all
testing git on cygwin. I'd be completely satisfied if git ran rock solid
on cygwin.
I found the following list of warnings about cygwin in the wiki
entry WindowsInstall [1]. Some points look quite scary to me.
What is your real-world experience? Are the warning still valid?
Must I really fear to break cygwin if I press Ctrl-C?
Do I really need to reboot regularly? I don't think this is an
option. Nowadays our Windows boxes run for months, too. I can't
seriously tell people that they need to regularly reboot if they
want to use git.
Here's the list, copied from http://git.or.cz/gitwiki/WindowsInstall
* Use git on local NTFS disks -- Network drives disks don't
support the filesystem semantics GIT needs; for interoperability
purposes you can store bare repositories on FAT32 disks.
* Be careful with the case in filenames. Similarly, avoid special
chars in filenames.
* Run git gc early and often. There are slowdowns with many
unpacked objects. Be careful to not create very big packfiles (bigger
than 2 Gb).
* Avoid using ActiveState Perl if possible. Ask in the
MailingLists if you must.
* Try to avoid interrupting (Ctrl-C) processes - it breaks cygwin.
* Consider setting core.fileMode to false (git repo-config
core.fileMode false) if file modes are frequently the only
differences detected by Git. Many Windows applications make the
execute bit be set in Cygwin when they save a file. Besides Cygwin
detects file mode by stupid combination of content analysis, file
name extension and moon phase.
* Insert "set CYGWIN=tty binmode" after the first line of C:
\cygwin\cygwin.bat, so you can use Ctrl-z in cygwin's bash to suspend
a program.
* Windows usually writes end-of-line as CRLF, while Unix/POSIX
writes LF. This can cause a variety of problems. There are current
efforts to address this.
* Setup binary mode for cygwin (there is an option in cygwin's
setup program), otherwise Cygwin mangles everything read and written
(Git repos have binary files in control structures).
* Avoid big repos.
* Avoid big blobs (very big files. Basically anything larger than
10Mb is too big).
* Avoid big trees (directories with many files in them).
* Avoid deep hierarchies.
* Reboot regularly (memory fragmentation)
* Defragment often (filesystems fragmentation)
Steffen
^ permalink raw reply
* [PATCH 2/5] Add functions get_relative_cwd() and is_inside_dir()
From: Johannes Schindelin @ 2007-07-26 6:24 UTC (permalink / raw)
To: git, gitster
The function get_relative_cwd() works just as getcwd(), only that it
takes an absolute path as additional parameter, returning the prefix
of the current working directory relative to the given path. If the
cwd is no subdirectory of the given path, it returns NULL.
is_inside_dir() is just a trivial wrapper over get_relative_cwd().
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---
dir.c | 27 +++++++++++++++++++++++++++
dir.h | 3 +++
2 files changed, 30 insertions(+), 0 deletions(-)
diff --git a/dir.c b/dir.c
index 8d8faf5..cb95538 100644
--- a/dir.c
+++ b/dir.c
@@ -642,3 +642,30 @@ file_exists(const char *f)
struct stat sb;
return stat(f, &sb) == 0;
}
+
+char *get_relative_cwd(char *buffer, int size, const char *dir)
+{
+ char *cwd = buffer;
+
+ if (!dir)
+ return 0;
+
+ if (!getcwd(buffer, PATH_MAX))
+ return 0;
+
+ while (*dir && *dir == *cwd) {
+ dir++;
+ cwd++;
+ }
+ if (*dir)
+ return NULL;
+ if (*cwd == '/')
+ return cwd + 1;
+ return cwd;
+}
+
+int is_inside_dir(const char *dir)
+{
+ char buffer[PATH_MAX];
+ return get_relative_cwd(buffer, sizeof(buffer), dir) != NULL;
+}
diff --git a/dir.h b/dir.h
index ec0e8ab..f55a87b 100644
--- a/dir.h
+++ b/dir.h
@@ -61,4 +61,7 @@ extern void add_exclude(const char *string, const char *base,
extern int file_exists(const char *);
extern struct dir_entry *dir_add_name(struct dir_struct *dir, const char *pathname, int len);
+extern char *get_relative_cwd(char *buffer, int size, const char *dir);
+extern int is_inside_dir(const char *dir);
+
#endif
--
1.5.3.rc2.42.gda8d-dirty
^ permalink raw reply related
* [PATCH 1/5] Add is_absolute_path(), make_absolute_path() and normalize_path()
From: Johannes Schindelin @ 2007-07-26 6:24 UTC (permalink / raw)
To: git, gitster
This patch adds convenience functions to work with absolute paths.
The function is_absolute_path() should help the efforts to integrate
the MinGW fork.
Note that make_absolute_path() returns a pointer to a static buffer.
Given a path which possibly contains "/../" and "/./", or which end
in "/", normalize_path() returns a normalized path.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---
cache.h | 6 ++++++
path.c | 54 ++++++++++++++++++++++++++++++++++++++++++++++++++++++
2 files changed, 60 insertions(+), 0 deletions(-)
diff --git a/cache.h b/cache.h
index 53801b8..b242147 100644
--- a/cache.h
+++ b/cache.h
@@ -358,6 +358,12 @@ int git_config_perm(const char *var, const char *value);
int adjust_shared_perm(const char *path);
int safe_create_leading_directories(char *path);
char *enter_repo(char *path, int strict);
+static inline int is_absolute_path(const char *path)
+{
+ return path[0] == '/';
+}
+const char *make_absolute_path(const char *path);
+char *normalize_path(char *path);
/* Read and unpack a sha1 file into memory, write memory to a sha1 file */
extern int sha1_object_info(const unsigned char *, unsigned long *);
diff --git a/path.c b/path.c
index c4ce962..92ce688 100644
--- a/path.c
+++ b/path.c
@@ -292,3 +292,57 @@ int adjust_shared_perm(const char *path)
return -2;
return 0;
}
+
+const char *make_absolute_path(const char *path)
+{
+ static char buf[PATH_MAX];
+ const int size = sizeof(buf);
+ int len;
+
+ if (is_absolute_path(path))
+ return path;
+
+ if (!getcwd(buf, size))
+ die ("Could not get current working directory");
+ if (!strcmp(path, "."))
+ return buf;
+
+ len = strlen(buf);
+ if (snprintf(buf + len, size - len, "/%s", path) > size - 1)
+ die ("Could not make absolute path from '%s'", path);
+ return normalize_path(buf);
+}
+
+/* strip out .. and . */
+char *normalize_path(char *path)
+{
+ int i, j;
+
+ for (i = 0, j = 0; path[i]; i++, j++) {
+ if (path[i] == '.') {
+ if (path[i + 1] == '/') {
+ i++; j--;
+ continue;
+ }
+ if (path[i + 1] == '.' && (path[i + 2] == '/' ||
+ !path[i + 2])) {
+ i += 1 + !!path[i + 2];
+ j--;
+ while (j > 0 && path[--j] != '/')
+ ; /* do nothing */
+ continue;
+ }
+ }
+ for (; path[i + 1]; i++, j++) {
+ path[j] = path[i];
+ if (path[i] == '/')
+ break;
+ }
+ path[j] = path[i];
+ }
+ if (j > 0 && path[j - 1] == '/')
+ j--;
+ path[j] = '\0';
+
+ return path;
+}
--
1.5.3.rc2.42.gda8d-dirty
^ permalink raw reply related
* Re: Windows support
From: Henning Rogge @ 2007-07-26 6:08 UTC (permalink / raw)
To: git
In-Reply-To: <Pine.LNX.4.64.0707260629260.14781@racer.site>
On 7/26/07, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> > Use git-gui. ;-) It doesn't need a shell to make commits.
>
> Of course. Ever since I saw git-gui, I was convinced that _this_ is the
> tool Windows users should use.
QGit might be a good alternative too, especially because QT4 is
available for Windows.
Henning
^ permalink raw reply
* Re: Windows support
From: Han-Wen Nienhuys @ 2007-07-26 5:56 UTC (permalink / raw)
To: git
Cc: Junio C Hamano, Shawn O. Pearce, Dmitry Kakurin,
Nguyen Thai Ngoc Duy, git
In-Reply-To: <Pine.LNX.4.64.0707260614500.14781@racer.site>
Johannes Schindelin wrote:
>> If that is the case, "Git for Windows" probably should package MSYS as
>> part of it, I would think, to match the expectation of the users there.
>> I know two Johannes'es and Han-Wen spent quite a lot of effort on
>> Windows port and packaging, but perhaps that little (well, I should not
>> be judging if that is a little or huge, as I do not do Windows)
>> finishing touch would make Windows users much happier?
>
> Windows users are only happy when they can bug developers.
>
> Seriously again, the biggest problem with Han-Wen's installer was that it
> insists on cross-compiling _all_ the packages. This makes it easy for
> Han-Wen to upgrade packages and compile the thing on Linux in one go.
> However, it never worked with bash, and I could not fix it: I can read
> Python, but not _that_ Python.
>
The problem is not really the python. If you supply me with a shell
script that will x-compile bash, I'll hapily code the python spec. IMO
the real problem is that bash is a unix shell (tied to unix internals)
and therefore, compiling it for something as horrid as windows is far
from trivial.
fwiw, I briefly tried compiling msys, but I couldn't even find its
sources, so I quickly gave up.
A second option is that someone supplies me with an unpacked, installed
tree of msys' bash shell. I can easily package that up along with the
rest of the installer, if it doesnt' require further trickery (setting
registry entries, etc.)
^ permalink raw reply
* Re: Bug in gitk search box
From: Junio C Hamano @ 2007-07-26 5:49 UTC (permalink / raw)
To: Paul Mackerras; +Cc: Brian Downing, git
In-Reply-To: <18088.10039.780711.708582@cargo.ozlabs.ibm.com>
Paul Mackerras <paulus@samba.org> writes:
> Junio C Hamano writes:
>
>> There was a recent message from Linus on the list, stating that
>> NUL in -z format is inter-record separator, not after-record
>> terminator.
>
> OK, I'll have to change gitk then. It looks like both Marco and I got
> tricked by this. I suggest it's worth a mention in the documentation.
I think that is indeed necessary. How about this?
---
diff --git a/Documentation/diff-options.txt b/Documentation/diff-options.txt
index 8216576..228ccaf 100644
--- a/Documentation/diff-options.txt
+++ b/Documentation/diff-options.txt
@@ -43,7 +43,9 @@
Synonym for "-p --stat".
-z::
- \0 line termination on output
+ NUL-line termination on output. This affects the --raw
+ output field terminator. Also output from commands such
+ as "git-log" will be delimited with NUL between commits.
--name-only::
Show only names of changed files.
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox