* Re: [PATCH] unpack-trees.c: assume submodules are clean during check-out
From: Sven Verdoolaege @ 2007-08-07 8:51 UTC (permalink / raw)
To: Eran Tromer; +Cc: Junio C Hamano, git
In-Reply-To: <46B7E5FE.7050006@tromer.org>
On Mon, Aug 06, 2007 at 11:24:46PM -0400, Eran Tromer wrote:
> On 2007-08-06 15:03, Sven Verdoolaege wrote:
> >>>> Another approach is for pull, checkout etc. to automatically update the
> >>>> submodule' head ref, but no more.
> >>> Then everything, including "git submodule update", would assume
> >>> that the submodule is up-to-date.
> >> With that approach, "git submodule update" would fetch the submodule's
> >> head commit (which could be missing), and then check it against the
> >> submodule's index (and maybe its work tree).
> > And how is anyone supposed to figure out what HEAD the submodule's
> > index and working tree correspond to?
>
> What HEAD corresponds to any other dirty index or dirty working tree?
> It's irrelevant and may not exist. You just have some random dirty state.
The only way to know that it's dirty is if you know the HEAD.
How can that not be relevant.
> > I can only hope that "git submodule update" would never blindly assume
> > that the submodule is clean and so the user would have to manually
> > sync the HEAD and the working tree.
>
> Why would it assume that? In this approach, and ignoring submodule
> merging for now, "git submodule update" should mean roughly "cd
> submodule && git fetch HEAD && git reset --hard HEAD".
If you're doing that, then that is exactly what you are assuming.
> After all, this
> is really the only way to end up with the prescribed commit sha1.
That's the best way of losing all you precious changes in the submodule.
And there is no way to get them back!
Surely this is a lot worse than occasionally committing something you
didn't plan to commit, and only if you are performing a known "dangerous"
operation.
> I agree that for safety it makes sense to warn or abort if the index
> doesn't match ORIG_HEAD (saved by the supermodule checkout) or if the
> index doesn't match the work tree.
You may have done several supermodule checkouts since you last changed
the submodule.
skimo
^ permalink raw reply
* git on Cygwin: Not a valid object name HEAD
From: Sebastian Schuberth @ 2007-08-07 9:02 UTC (permalink / raw)
To: git
Hi,
I'm running git 1.5.2.2 under Cygwin on Windows XP. This is what I'm
(reproducibly) getting if I try to clone QGit's repository:
sschuber@xp-sschuber2 ~
$ git clone git://git.kernel.org/pub/scm/qgit/qgit4.git
Initialized empty Git repository in /home/sschuber/qgit4/.git/
remote: Generating pack...
remote: Done counting 2295 objects.
remote: Deltifying 2295 objects...
remote: 100% (2295/2295) done
Indexing 2295 objects...
remote: Total 2295 (delta 1793), reused 1218 (delta 955)
100% (2295/2295) done
Resolving 1793 deltas...
100% (1793/1793) done
: not a valid SHA1b870df7cde1e05ee76d1d15ea428f
fatal: Not a valid object name HEAD
sschuber@xp-sschuber2 ~
$ git --version
git version 1.5.2.2
I'm not sure whether the cause for this is the same as mentioned at
http://article.gmane.org/gmane.comp.version-control.git/54825
However, the most recent msysGit worked fine for me. Any clues whether
this is a repository problem, a Cygwin problem, or a git problem?
Thanks.
--
Sebastian Schuberth
^ permalink raw reply
* Re: [PATCH v2] git-diff: Output a warning about stale files in the index
From: Jakub Narebski @ 2007-08-07 9:04 UTC (permalink / raw)
To: git
In-Reply-To: <7vbqdj7poi.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
> After starting to edit a working tree file but later when your
> edit ends up identical to the original (this can also happen
> when you ran a wholesale regexp replace with something like
> "perl -i" that does not touch many of the paths),
Does touch the file (makes file stat-dirty, changes file mtime),
but doesn't change it.
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: [PATCH] git-p4: Fix support for symlinks.
From: Brian Swetland @ 2007-08-07 9:10 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Simon Hausmann, git, Han-Wen Nienhuys
In-Reply-To: <7vtzrb68kq.fsf@assigned-by-dhcp.cox.net>
[Junio C Hamano <gitster@pobox.com>]
> Simon Hausmann <simon@lst.de> writes:
>
> [ patch for correct symlink handling ]
>
> Thanks for a quick fix.
>
> Brian, does this resolve the issue for you? I do not have an
> access to p4 myself so I won't make a good judge in this area
> myself. An Ack is appreciated.
Ack.
Looks good here. I can now sync from the p4 tree into git, check out
from git and do a clean build, and everything's happy.
Thanks for the quick fix, Simon!
One observation on git-p4 -- it's a little memory hungry when processing
large syncs. I haven't tried incremental syncs on top of the initial
one though -- if it's only the initial that's expensive it's not that
big a deal.
It seemed to top out around 988MB resident. The branch I was importing
is about 562MB when checked out and the resulting git repository is
about 175MB.
Brian
^ permalink raw reply
* [Q]Which Bug tracking system is best for Git ??
From: pradeep singh @ 2007-08-07 9:52 UTC (permalink / raw)
To: git
Hello All,
I am using Git for my internal project at work, after convincing my
employer to switch to git.
I am enjoying working with git but now as the project is about to
complete we are faced with the issues of bug tracking and issuing
system.
I would like to get a general view from the git developers and
experienced users on this.
Especially i would like to know of any good defect tracking systems
which can work really well with git.
thanks in advance.
[PS: please CC me as i am not subscribed to git devel list]
--
Pradeep
^ permalink raw reply
* Re: git-sh-setup.sh:cd_to_toplevel problematic with symlinks
From: Matthias Lederhofer @ 2007-08-07 10:11 UTC (permalink / raw)
To: Uwe Kleine-König; +Cc: git
In-Reply-To: <20070806211238.GA27363@informatik.uni-freiburg.de>
Your mail did not make it to the list, therefore I quote the full
mail.
Uwe Kleine-König <ukleinek@informatik.uni-freiburg.de> wrote:
> Matthias Lederhofer wrote:
> > cd_to_toplevel takes the output of git rev-parse --show-cdup and feeds
> > it to cd. The problem is that cd uses PWD to do what the user means
> > when saying cd .., i.e. it goes to /foo when in /foo/bar even though
> > /foo/bar might be a symlink. Example:
> >
> > (in an existing git repository)
> > /tmp/foo$ mkdir -p a/b
> > /tmp/foo$ ln -s a/b c
> > /tmp/foo$ cd c
> > /tmp/foo/c$ git fetch . master:master
> > git-fetch: line 108: /FETCH_HEAD: Permission denied
> >
> > Is there any way to tell cd to ignore $PWD?
> cd -P ... does the trick. IIRC it's in SUSv3, but once more, Solaris
> /bin/sh doesn't know about that option:
>
> login@~ > uname -a
> SunOS login 5.10 Generic_125100-10 sun4u sparc
>
> login@~ > /bin/sh
>
> $ mkdir /tmp/foo; cd /tmp/foo
>
> $ git init
> Initialized empty Git repository in .git/
>
> $ mkdir -p a/b; ln -s a/b c; cd c
>
> $ git rev-parse --show-cdup
> ../../
>
> $ cd -P ../../
> -P: does not exist
Do we care about that shell? There was another thread about shell
script cleanup where the default sun /bin/sh doesn't support some
other features from the git shell scripts too.
^ permalink raw reply
* [PATCH] git-p4: Fix support for symlinks.
From: Simon Hausmann @ 2007-08-07 10:28 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
Detect symlinks as file type, set the git file mode accordingly and strip off the trailing newline in the p4 print output.
Make the mode handling a bit more readable at the same time.
Signed-off-by: Simon Hausmann <simon@lst.de>
Acked-by: Brian Swetland <swetland@google.com>
---
contrib/fast-import/git-p4 | 14 +++++++++-----
1 files changed, 9 insertions(+), 5 deletions(-)
diff --git a/contrib/fast-import/git-p4 b/contrib/fast-import/git-p4
index 41e86e7..3cbb2da 100755
--- a/contrib/fast-import/git-p4
+++ b/contrib/fast-import/git-p4
@@ -839,16 +839,20 @@ class P4Sync(Command):
if file["action"] == "delete":
self.gitStream.write("D %s\n" % relPath)
else:
- mode = 644
- if file["type"].startswith("x"):
- mode = 755
-
data = file['data']
+ mode = "644"
+ if file["type"].startswith("x"):
+ mode = "755"
+ elif file["type"] == "symlink":
+ mode = "120000"
+ # p4 print on a symlink contains "target\n", so strip it off
+ data = data[:-1]
+
if self.isWindows and file["type"].endswith("text"):
data = data.replace("\r\n", "\n")
- self.gitStream.write("M %d inline %s\n" % (mode, relPath))
+ self.gitStream.write("M %s inline %s\n" % (mode, relPath))
self.gitStream.write("data %s\n" % len(data))
self.gitStream.write(data)
self.gitStream.write("\n")
--
1.5.3.rc3.91.g5c75
^ permalink raw reply related
* Re: [PATCH] Documentation/Makefile: remove cmd-list.made before redirecting to it.
From: David Kastrup @ 2007-08-07 10:29 UTC (permalink / raw)
To: git
In-Reply-To: <7vlkcn97ll.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <gitster@pobox.com> writes:
> Although I understand that it would be a problem if you built as
> root earlier, which would have left files unmodifyable by you, I
> think this is getting out of hand. The cmd-list.perl script itself,
> for example, does "creat in $out+, if the contents have changed from
> the last round then rename $out+ to $out" sequence in order to avoid
> unnecessary rebuild of files that depend on the generated command
> list. If it is interrupted in the middle while running as root, and
> then you try to do another build, I suspect "creat in $out+" part
> would fail.
No, creat is only interested in the directory permissions. It is
open(..., O_TRUNC) that causes the problem. There are not many
programs that actually use that for their output files, but shell
output redirection is one of them, and some editors tend to do this as
well in order to easily preserve permissions.
There are no other shell output redirections to an undeleted file in
the Makefile.
--
David Kastrup
^ permalink raw reply
* [install info (using perl) 1/2] Add support for an info version of the user manual
From: David Kastrup @ 2007-08-06 10:22 UTC (permalink / raw)
To: git
These patches use docbook2x in order to create an info version of the
git user manual. No existing Makefile targets (including "all") are
touched, so you need to explicitly say
make info
sudo make install-info
to get git.info created and installed. If the info target directory
does not already contain a "dir" file, no directory entry is created.
This facilitates $(DESTDIR)-based installations. The same could be
achieved with
sudo make INSTALL_INFO=: install-info
explicitly.
perl is used for patching up sub-par file and directory information in
the Texinfo file. It would be cleaner to place the respective info
straight into user-manual.txt or the conversion configurations, but I
find myself unable to find out how to do this with Asciidoc/Texinfo.
Signed-off-by: David Kastrup <dak@gnu.org>
---
COMMIT_EDITMSG | 57 ++++++++++++++++++++++++++++++++++++++++++++++++
Documentation/Makefile | 27 ++++++++++++++++++++++
Makefile | 6 +++++
3 files changed, 90 insertions(+), 0 deletions(-)
create mode 100644 COMMIT_EDITMSG
diff --git a/COMMIT_EDITMSG b/COMMIT_EDITMSG
new file mode 100644
index 0000000..1718ad5
--- /dev/null
+++ b/COMMIT_EDITMSG
@@ -0,0 +1,57 @@
+Add support for an info version of the user manual
+
+These patches use docbook2x in order to create an info version of the
+git user manual. No existing Makefile targets (including "all") are
+touched, so you need to explicitly say
+
+make info
+sudo make install-info
+
+to get git.info created and installed. If the info target directory
+does not already contain a "dir" file, no directory entry is created.
+This facilitates $(DESTDIR)-based installations. The same could be
+achieved with
+
+sudo make INSTALL_INFO=: install-info
+
+explicitly.
+
+perl is used for patching up sub-par file and directory information in
+the Texinfo file. It would be cleaner to place the respective info
+straight into user-manual.txt or the conversion configurations, but I
+find myself unable to find out how to do this with Asciidoc/Texinfo.
+
+# Please enter the commit message for your changes.
+# (Comment lines starting with '#' will not be included)
+# On branch master
+# Changes to be committed:
+# (use "git reset HEAD^1 <file>..." to unstage)
+#
+# modified: Documentation/Makefile
+# modified: Makefile
+#
+# Untracked files:
+# (use "git add <file>..." to include in what will be committed)
+#
+# 0001-Add-support-for-an-info-version-of-the-user-manual.patch
+# 0001-Documentation-git-commit.txt-correct-bad-list-forma.patch
+# 0001-Introduce-ediff-option-for-mergetool.patch
+# 0002-Documentation-Makefile-remove-cmd-list.made-before.patch
+# Documentation/git.info
+# Documentation/git.texi
+# TAGS
+# contrib/emacs/0010-vc-git-previous-version-vc-git-next-version.patch
+# contrib/emacs/0011-contrib-emacs-vc-git.el-a-few-more-tentative-change.patch
+# contrib/emacs/0012-contrib-emacs-vc-git.el-further-improvements.patch
+# contrib/emacs/ChangeLog
+# contrib/emacs/ChangeLog~
+# contrib/emacs/Makefile.orig
+# contrib/emacs/vc-git.el.BACKUP.17026
+# contrib/emacs/vc-git.el.BASE.17026
+# contrib/emacs/vc-git.el.LOCAL.17026
+# contrib/emacs/vc-git.el.REMOTE.17026
+# contrib/emacs/vc-git.el.rej
+# contrib/emacs/vc-git.el.rej~
+# contrib/emacs/vc-git.el~
+# svn-commit.tmp~
+# texput.log
diff --git a/Documentation/Makefile b/Documentation/Makefile
index 91a437d..71b7056 100644
--- a/Documentation/Makefile
+++ b/Documentation/Makefile
@@ -44,6 +44,11 @@ INSTALL?=install
RM ?= rm -f
DOC_REF = origin/man
+infodir?=$(prefix)/share/info
+MAKEINFO=makeinfo
+INSTALL_INFO=install-info
+DOCBOOK2X_TEXI=docbook2x-texi
+
-include ../config.mak.autogen
-include ../config.mak
@@ -67,6 +72,8 @@ man1: $(DOC_MAN1)
man5: $(DOC_MAN5)
man7: $(DOC_MAN7)
+info: git.info
+
install: man
$(INSTALL) -d -m755 $(DESTDIR)$(man1dir)
$(INSTALL) -d -m755 $(DESTDIR)$(man5dir)
@@ -75,6 +82,14 @@ install: man
$(INSTALL) -m644 $(DOC_MAN5) $(DESTDIR)$(man5dir)
$(INSTALL) -m644 $(DOC_MAN7) $(DESTDIR)$(man7dir)
+install-info: info
+ $(INSTALL) -d -m755 $(DESTDIR)$(infodir)
+ $(INSTALL) -m644 git.info $(DESTDIR)$(infodir)
+ if test -r $(DESTDIR)$(infodir)/dir; then \
+ $(INSTALL_INFO) --info-dir=$(DESTDIR)$(infodir) git.info ;\
+ else \
+ echo "No directory found in $(DESTDIR)$(infodir)" >&2 ; \
+ fi
../GIT-VERSION-FILE: .FORCE-GIT-VERSION-FILE
$(MAKE) -C ../ GIT-VERSION-FILE
@@ -139,6 +154,18 @@ XSLTOPTS = --xinclude --stringparam html.stylesheet docbook-xsl.css
user-manual.html: user-manual.xml
xsltproc $(XSLTOPTS) -o $@ $(XSLT) $<
+git.info: user-manual.xml
+ $(RM) $@ $*.texi
+ $(DOCBOOK2X_TEXI) user-manual.xml --to-stdout | \
+ perl -ne 'if (/^\@setfilename/) {$$_="\@setfilename git.info\
+"} elsif (/^\@direntry/) {print "\@dircategory Development\
+\@direntry\
+* Git: (git). A fast distributed revision control system\
+\@end direntry\
+"} print unless (/^\@direntry/ .. /^\@end direntry/)' > $*.texi
+ $(MAKEINFO) --no-split $*.texi
+ $(RM) $*.texi
+
howto-index.txt: howto-index.sh $(wildcard howto/*.txt)
$(RM) $@+ $@
sh ./howto-index.sh $(wildcard howto/*.txt) >$@+
diff --git a/Makefile b/Makefile
index 2f3b9b2..b685c7e 100644
--- a/Makefile
+++ b/Makefile
@@ -913,6 +913,9 @@ perl/Makefile: perl/Git.pm perl/Makefile.PL GIT-CFLAGS
doc:
$(MAKE) -C Documentation all
+info:
+ $(MAKE) -C Documentation info
+
TAGS:
$(RM) TAGS
$(FIND) . -name '*.[hcS]' -print | xargs etags -a
@@ -1005,6 +1008,9 @@ endif
install-doc:
$(MAKE) -C Documentation install
+install-info:
+ $(MAKE) -C Documentation install-info
+
quick-install-doc:
$(MAKE) -C Documentation quick-install
--
1.5.3.rc4.21.ga63eb
^ permalink raw reply related
* [install info (using perl) 2/2] INSTALL: explain info installation and dependencies.
From: David Kastrup @ 2007-08-07 10:02 UTC (permalink / raw)
To: git
In-Reply-To: <f61195c2c46468565b52f86e285cfda8c4ae9a3e.1186483533.git.dak@gnu.org>
Signed-off-by: David Kastrup <dak@gnu.org>
---
INSTALL | 14 +++++++++-----
1 files changed, 9 insertions(+), 5 deletions(-)
diff --git a/INSTALL b/INSTALL
index c62b12c..289b046 100644
--- a/INSTALL
+++ b/INSTALL
@@ -5,8 +5,8 @@ Normally you can just do "make" followed by "make install", and that
will install the git programs in your own ~/bin/ directory. If you want
to do a global install, you can do
- $ make prefix=/usr all doc ;# as yourself
- # make prefix=/usr install install-doc ;# as root
+ $ make prefix=/usr all doc info ;# as yourself
+ # make prefix=/usr install install-doc install-info ;# as root
(or prefix=/usr/local, of course). Just like any program suite
that uses $prefix, the built results have some paths encoded,
@@ -91,9 +91,13 @@ Issues of note:
- To build and install documentation suite, you need to have
the asciidoc/xmlto toolchain. Because not many people are
inclined to install the tools, the default build target
- ("make all") does _not_ build them. The documentation is
- written for AsciiDoc 7, but "make ASCIIDOC8=YesPlease doc"
- will let you format with AsciiDoc 8.
+ ("make all") does _not_ build them.
+
+ Building and installing the info file additionally requires
+ makeinfo and docbook2X. Version 0.8.3 is known to work.
+
+ The documentation is written for AsciiDoc 7, but "make
+ ASCIIDOC8=YesPlease doc" will let you format with AsciiDoc 8.
Alternatively, pre-formatted documentation are available in
"html" and "man" branches of the git repository itself. For
--
1.5.3.rc4.21.ga63eb
^ permalink raw reply related
* Re: [install info (using perl) 1/2] Add support for an info version of the user manual
From: David Kastrup @ 2007-08-07 10:49 UTC (permalink / raw)
To: git
In-Reply-To: <f61195c2c46468565b52f86e285cfda8c4ae9a3e.1186483533.git.dak@gnu.org>
David Kastrup <dak@gnu.org> writes:
> COMMIT_EDITMSG | 57 ++++++++++++++++++++++++++++++++++++++++++++++++
> Documentation/Makefile | 27 ++++++++++++++++++++++
> Makefile | 6 +++++
> 3 files changed, 90 insertions(+), 0 deletions(-)
I hate life. Fixing this.
--
David Kastrup
^ permalink raw reply
* [install info (using perl) 2/2] INSTALL: explain info installation and dependencies.
From: David Kastrup @ 2007-08-07 10:02 UTC (permalink / raw)
To: git
In-Reply-To: <591c5679ea79b76cd5db57443b1d691bde842351.1186484406.git.dak@gnu.org>
Signed-off-by: David Kastrup <dak@gnu.org>
---
INSTALL | 14 +++++++++-----
1 files changed, 9 insertions(+), 5 deletions(-)
diff --git a/INSTALL b/INSTALL
index c62b12c..289b046 100644
--- a/INSTALL
+++ b/INSTALL
@@ -5,8 +5,8 @@ Normally you can just do "make" followed by "make install", and that
will install the git programs in your own ~/bin/ directory. If you want
to do a global install, you can do
- $ make prefix=/usr all doc ;# as yourself
- # make prefix=/usr install install-doc ;# as root
+ $ make prefix=/usr all doc info ;# as yourself
+ # make prefix=/usr install install-doc install-info ;# as root
(or prefix=/usr/local, of course). Just like any program suite
that uses $prefix, the built results have some paths encoded,
@@ -91,9 +91,13 @@ Issues of note:
- To build and install documentation suite, you need to have
the asciidoc/xmlto toolchain. Because not many people are
inclined to install the tools, the default build target
- ("make all") does _not_ build them. The documentation is
- written for AsciiDoc 7, but "make ASCIIDOC8=YesPlease doc"
- will let you format with AsciiDoc 8.
+ ("make all") does _not_ build them.
+
+ Building and installing the info file additionally requires
+ makeinfo and docbook2X. Version 0.8.3 is known to work.
+
+ The documentation is written for AsciiDoc 7, but "make
+ ASCIIDOC8=YesPlease doc" will let you format with AsciiDoc 8.
Alternatively, pre-formatted documentation are available in
"html" and "man" branches of the git repository itself. For
--
1.5.3.rc4.21.ga63eb
^ permalink raw reply related
* [install info (using perl) 1/2] Add support for an info version of the user manual
From: David Kastrup @ 2007-08-06 10:22 UTC (permalink / raw)
To: git
These patches use docbook2x in order to create an info version of the
git user manual. No existing Makefile targets (including "all") are
touched, so you need to explicitly say
make info
sudo make install-info
to get git.info created and installed. If the info target directory
does not already contain a "dir" file, no directory entry is created.
This facilitates $(DESTDIR)-based installations. The same could be
achieved with
sudo make INSTALL_INFO=: install-info
explicitly.
perl is used for patching up sub-par file and directory information in
the Texinfo file. It would be cleaner to place the respective info
straight into user-manual.txt or the conversion configurations, but I
find myself unable to find out how to do this with Asciidoc/Texinfo.
Signed-off-by: David Kastrup <dak@gnu.org>
---
Documentation/Makefile | 27 +++++++++++++++++++++++++++
Makefile | 6 ++++++
2 files changed, 33 insertions(+), 0 deletions(-)
diff --git a/Documentation/Makefile b/Documentation/Makefile
index 91a437d..71b7056 100644
--- a/Documentation/Makefile
+++ b/Documentation/Makefile
@@ -44,6 +44,11 @@ INSTALL?=install
RM ?= rm -f
DOC_REF = origin/man
+infodir?=$(prefix)/share/info
+MAKEINFO=makeinfo
+INSTALL_INFO=install-info
+DOCBOOK2X_TEXI=docbook2x-texi
+
-include ../config.mak.autogen
-include ../config.mak
@@ -67,6 +72,8 @@ man1: $(DOC_MAN1)
man5: $(DOC_MAN5)
man7: $(DOC_MAN7)
+info: git.info
+
install: man
$(INSTALL) -d -m755 $(DESTDIR)$(man1dir)
$(INSTALL) -d -m755 $(DESTDIR)$(man5dir)
@@ -75,6 +82,14 @@ install: man
$(INSTALL) -m644 $(DOC_MAN5) $(DESTDIR)$(man5dir)
$(INSTALL) -m644 $(DOC_MAN7) $(DESTDIR)$(man7dir)
+install-info: info
+ $(INSTALL) -d -m755 $(DESTDIR)$(infodir)
+ $(INSTALL) -m644 git.info $(DESTDIR)$(infodir)
+ if test -r $(DESTDIR)$(infodir)/dir; then \
+ $(INSTALL_INFO) --info-dir=$(DESTDIR)$(infodir) git.info ;\
+ else \
+ echo "No directory found in $(DESTDIR)$(infodir)" >&2 ; \
+ fi
../GIT-VERSION-FILE: .FORCE-GIT-VERSION-FILE
$(MAKE) -C ../ GIT-VERSION-FILE
@@ -139,6 +154,18 @@ XSLTOPTS = --xinclude --stringparam html.stylesheet docbook-xsl.css
user-manual.html: user-manual.xml
xsltproc $(XSLTOPTS) -o $@ $(XSLT) $<
+git.info: user-manual.xml
+ $(RM) $@ $*.texi
+ $(DOCBOOK2X_TEXI) user-manual.xml --to-stdout | \
+ perl -ne 'if (/^\@setfilename/) {$$_="\@setfilename git.info\
+"} elsif (/^\@direntry/) {print "\@dircategory Development\
+\@direntry\
+* Git: (git). A fast distributed revision control system\
+\@end direntry\
+"} print unless (/^\@direntry/ .. /^\@end direntry/)' > $*.texi
+ $(MAKEINFO) --no-split $*.texi
+ $(RM) $*.texi
+
howto-index.txt: howto-index.sh $(wildcard howto/*.txt)
$(RM) $@+ $@
sh ./howto-index.sh $(wildcard howto/*.txt) >$@+
diff --git a/Makefile b/Makefile
index 2f3b9b2..b685c7e 100644
--- a/Makefile
+++ b/Makefile
@@ -913,6 +913,9 @@ perl/Makefile: perl/Git.pm perl/Makefile.PL GIT-CFLAGS
doc:
$(MAKE) -C Documentation all
+info:
+ $(MAKE) -C Documentation info
+
TAGS:
$(RM) TAGS
$(FIND) . -name '*.[hcS]' -print | xargs etags -a
@@ -1005,6 +1008,9 @@ endif
install-doc:
$(MAKE) -C Documentation install
+install-info:
+ $(MAKE) -C Documentation install-info
+
quick-install-doc:
$(MAKE) -C Documentation quick-install
--
1.5.3.rc4.21.ga63eb
^ permalink raw reply related
* Re: git on Cygwin: Not a valid object name HEAD
From: Johannes Schindelin @ 2007-08-07 11:58 UTC (permalink / raw)
To: Sebastian Schuberth; +Cc: git
In-Reply-To: <f99cem$4a4$1@sea.gmane.org>
Hi,
On Tue, 7 Aug 2007, Sebastian Schuberth wrote:
> 100% (2295/2295) done
> Resolving 1793 deltas...
> 100% (1793/1793) done
> : not a valid SHA1b870df7cde1e05ee76d1d15ea428f
> fatal: Not a valid object name HEAD
I suspect that there is no master branch on the remote side, but the
remote's HEAD points there. Try "git ls-remote <url>" to find out.
Ciao,
Dscho
^ permalink raw reply
* Re: [ANNOUNCE] GIT 1.5.3-rc4
From: David Kågedal @ 2007-08-07 12:11 UTC (permalink / raw)
To: git
In-Reply-To: <7vzm18jg7p.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <gitster@pobox.com> writes:
> GIT v1.5.3 Release Notes (draft)
> ========================
>
> Updates since v1.5.2
> --------------------
>
> * The commit walkers other than http are officially deprecated,
> but still supported for now.
This will not make sense to a lot of people. I've been around here
since git was invented, and I think I can guess what it means, but I'm
not completely sure. A "commit walker" is something that probably
only a few core git developers know what it is.
Please remember to give a second of thought to who will be reading
this. It is very hard to determine from this short message who will
be affected, and in what way.
--
David Kågedal
^ permalink raw reply
* Re: git on Cygwin: Not a valid object name HEAD
From: Sebastian Schuberth @ 2007-08-07 12:13 UTC (permalink / raw)
To: git
In-Reply-To: <Pine.LNX.4.64.0708071257350.14781@racer.site>
>> 100% (2295/2295) done
>> Resolving 1793 deltas...
>> 100% (1793/1793) done
>> : not a valid SHA1b870df7cde1e05ee76d1d15ea428f
>> fatal: Not a valid object name HEAD
>
> I suspect that there is no master branch on the remote side, but the
> remote's HEAD points there. Try "git ls-remote <url>" to find out.
I'm not too familiar with git yet, but to me this looks alright:
sschuber@xp-sschuber2 ~
$ git ls-remote git://git.kernel.org/pub/scm/qgit/qgit4.git
6c4444edbc4b870df7cde1e05ee76d1d15ea428f HEAD
6c4444edbc4b870df7cde1e05ee76d1d15ea428f refs/heads/master
70cd59500e8113901333741d82bbd055f96787f6 refs/tags/qgit-2.0rc1
1fe8ecc6a47d47a883beab1afa4607b1ca5da698 refs/tags/qgit-2.0rc1^{}
29bb10bf0397924489a51adb759f2df4b17fc31f refs/tags/qgit-2.0rc2
243cd78b72b1a4021d63829f62419f5483e70c7d refs/tags/qgit-2pre1
738063eb6f0f8f706e5f8609eab003ab19628617 refs/tags/qgit-2pre1^{}
17245c4248feab0d0425355ab5ff1cd4d7f83872 refs/tags/qgit2-pre2
7e02b07bc910a1d49b2cb4846641e01b7f6512aa refs/tags/qgit2-pre2^{}
--
Sebastian Schuberth
^ permalink raw reply
* Re: git-sh-setup.sh:cd_to_toplevel problematic with symlinks
From: Uwe Kleine-König @ 2007-08-07 12:45 UTC (permalink / raw)
To: Matthias Lederhofer; +Cc: git
In-Reply-To: <20070807101155.GA19233@moooo.ath.cx>
Hello Matthias,
Matthias Lederhofer wrote:
> Your mail did not make it to the list, therefore I quote the full
> mail.
Ops, thanks.
> Uwe Kleine-König <ukleinek@informatik.uni-freiburg.de> wrote:
> > > Is there any way to tell cd to ignore $PWD?
> > cd -P ... does the trick. IIRC it's in SUSv3, but once more, Solaris
> > /bin/sh doesn't know about that option:
> >
[...]
>
> Do we care about that shell? There was another thread about shell
> script cleanup where the default sun /bin/sh doesn't support some
> other features from the git shell scripts too.
Ah, I see, Makefile defines SHELL_PATH for SunOS to /bin/bash anyhow.
OK, then maybe just use it and if it breaks for someone we will notice
it ...
Best regards
Uwe
--
Uwe Kleine-König
http://www.google.com/search?q=12+mol+in+dozen
^ permalink raw reply
* [PATCH] send-email: don't add sender to Cc: if --suppress-from is given.
From: Uwe Kleine-König @ 2007-08-07 13:12 UTC (permalink / raw)
To: Git Mailing List
Up to now the sender is added to the Cc: list for Signed-off-by and Cc
lines even if --suppress-from is requested.
Signed-off-by: Uwe Kleine-König <ukleinek@informatik.uni-freiburg.de>
---
Hello,
Maybe the address should be added for a Cc: line, but not for
Signed-off-by?
Best regards
Uwe
git-send-email.perl | 8 +++++---
1 files changed, 5 insertions(+), 3 deletions(-)
diff --git a/git-send-email.perl b/git-send-email.perl
index 39e433b..9d7f6a8 100755
--- a/git-send-email.perl
+++ b/git-send-email.perl
@@ -646,9 +646,11 @@ foreach my $t (@files) {
if (/^(Signed-off-by|Cc): (.*)$/i && $signed_off_cc) {
my $c = $2;
chomp $c;
- push @cc, $c;
- printf("(sob) Adding cc: %s from line '%s'\n",
- $c, $_) unless $quiet;
+ if (not $suppress_from or unquote_rfc2047($c) eq $from) {
+ push @cc, $c;
+ printf("(sob) Adding cc: %s from line '%s'\n",
+ $c, $_) unless $quiet;
+ }
}
}
}
--
1.5.3.rc3.13.g7ab3
^ permalink raw reply related
* Re: git on Cygwin: Not a valid object name HEAD
From: Sebastian Schuberth @ 2007-08-07 13:18 UTC (permalink / raw)
To: git
In-Reply-To: <f99nm6$9vi$1@sea.gmane.org>
>>> 100% (2295/2295) done
>>> Resolving 1793 deltas...
>>> 100% (1793/1793) done
>>> : not a valid SHA1b870df7cde1e05ee76d1d15ea428f
>>> fatal: Not a valid object name HEAD
As Mark Levedahl assumed by e-mail, the problem is with Cygwin's binary
vs. text mount mode feature. Thanks Mark.
I'm running on NTFS and I did try the "binary mount" stuff before "git
clone" by issuing
mount -bc /cygdrive
but I overlooked that this command only affects /cygdrive paths, and I
did clone into a non /cygdrive path. So cloning to a /cygdrive mounted
path works now.
I wonder if this happens because git never passes "b" to any fopen()
calls (as there is no such thing like opening a file in binary mode
under Linux, because files are always opened "binary"). If fopen()
safely ignores the "b" option under Linux, I think it should always be
specified so Cygwin's git will work with text mode mounts when compiled
from the original git sources.
--
Sebastian Schuberth
^ permalink raw reply
* resumable git-clone?
From: Nguyen Thai Ngoc Duy @ 2007-08-07 13:23 UTC (permalink / raw)
To: Git Mailing List
I was on a crappy connection and it was frustrated seeing git-clone
reached 80% then failed, then started over again. Can we support
resumable git-clone at some level? I think we could split into several
small packs, keep fetched ones, just get missing packs until we have
all.
I didn't clone via http so I don't know if http supports resumable.
--
Duy
^ permalink raw reply
* Re: [PATCH] Add --show-touched option to show "diff --git" line when contents are unchanged
From: J. Bruce Fields @ 2007-08-07 13:34 UTC (permalink / raw)
To: David Kastrup; +Cc: git
In-Reply-To: <86k5s7am7c.fsf@lola.quinscape.zz>
On Tue, Aug 07, 2007 at 08:32:55AM +0200, David Kastrup wrote:
> Junio C Hamano <gitster@pobox.com> writes:
>
> > Matthieu Moy <Matthieu.Moy@imag.fr> writes:
> >
> >> Unfortunately, the patch solves the "large and irrelevant output"
> >> of git-diff, but not the performance problem (see the rest of the
> >> thread, I failed to convince Junio that updating the index was a
> >> performance improvement while keeping the same user semantics).
> >
> > That's what update-index --refresh (or status if you insist) are
> > for, and the coalmine canary you are so dead set to kill are helping
> > you realize the need for running.
>
> That does not convince me. Cache staleness should be a problem of
> git, not of the user. In particular if the user is just using
> porcelain. If letting the cache get stale impacts performance, then
> git should clean up its act on its own without barfing when using
> unrelated commands. If it notices this during diff (presumably by
> overstepping some staleness ratio), then it can set a "regenerate on
> next opportunity" flag on the index, and then the next command wanting
> to process the index from the start can rewrite a refreshed version.
The last time I had a serious problem with "cache staleness", it was
with Beagle, which modifies the files it indexes (by writing some
extended attributes). I figured out what was happening when I noticed
that the list of touched files was growing each time I did a diff
(implying the something was working on them right then), so I ran top,
noticed beagled, eventually thought to query the extended attributes,
and finally turned off beagled's indexing to solve the problem.
So, in this case:
- If git had fixed up the problem silently, I probably would
have just assumed git was slow and not found the problem.
- Seeing the actual list of files for which the index was dirty
helped me identify the problem. I probably would have
eventually figured it out even if all I'd had was a single
"index is stale" message, but I suspect it would have taken
longer.
Draw whatever moral you'd like....
--b.
^ permalink raw reply
* git-svn: "Malformed network data" issue
From: Gerrit Pape @ 2007-08-07 13:42 UTC (permalink / raw)
To: git, Eric Wong
In-Reply-To: <20070704210526.GA9582@muzzle>
On Wed, Jul 04, 2007 at 02:07:42PM -0700, Eric Wong wrote:
> Although this fixes blocking reads, this does *not* fix the
> "Malformed network data" issue, which has been around for a
> while...
>
> I'll try to find time to fix the "Malformed network data" bug
> in a few days time, but it's not fatal (just restart git-svn,
> this error happens at a point where it's not possible to have
> a corrupted import).
Hi, this still is a problem we face on Debian with 1.5.3-rc3
http://bugs.debian.org/436142
http://bugs.debian.org/430091
I'm sorry, I didn't manage to provide a patch.
Thanks, Gerrit.
^ permalink raw reply
* Re: [PATCH] (Really) Fix install-doc-quick target
From: René Scharfe @ 2007-08-07 13:55 UTC (permalink / raw)
To: Junio C Hamano
Cc: Mark Levedahl, Johannes Schindelin, Mark Levedahl,
Git Mailing List
In-Reply-To: <7vd4y09f07.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano schrieb:
> Mark Levedahl <mlevedahl@gmail.com> writes:
>
>> + printf "$mandir/%s\n" $(git ls-tree -r --name-only $head) | xargs
>> gzip -f
>
> No risk that ls-tree output is too long to fit within the exec
> args limit to run printf?
Perhaps this instead?
git ls-tree -r --name-only $head | (cd "$mandir" && xargs gzip -f)
René
^ permalink raw reply
* [PATCH] post-receive-email hook: handle order of arguments consistently
From: Gerrit Pape @ 2007-08-07 13:58 UTC (permalink / raw)
To: git, Junio C Hamano
In-Reply-To: <200706141119.18724.andyparkins@gmail.com>
The post-receive-email hook usually gets its arguments through stdin,
but also supports them to be specified at the command line. The order
of the arguments should consistently follow the documentation no matter
how they are passed to the script.
This was noticed and suggested by martin f krafft through
http://bugs.debian.org/428413
Signed-off-by: Gerrit Pape <pape@smarden.org>
---
On Thu, Jun 14, 2007 at 11:19:17AM +0100, Andy Parkins wrote:
> On Thursday 2007 June 14, Gerrit Pape wrote:
> > The post-receive-email hook usually gets its arguments through stdin, but
> > also supports them to be specified at the command line. The order of the
> > arguments should consistently follow the documentation no matter how they
> > are passed to the script.
>
> That wasn't done casually. It was done so that the same script would work as
> an update hook as well.
>
> I have no objection to the change, as the update hook was not the right place
> for generating emails. However, it let me use that same update hook on a
> system that did not have a git with support for the post-receive hook.
Hi, I suggest to apply this patch for 1.5.3. Thanks, Gerrit.
contrib/hooks/post-receive-email | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/contrib/hooks/post-receive-email b/contrib/hooks/post-receive-email
index c589a39..f84532f 100644
--- a/contrib/hooks/post-receive-email
+++ b/contrib/hooks/post-receive-email
@@ -605,7 +605,7 @@ envelopesender=$(git-repo-config hooks.envelopesender)
if [ -n "$1" -a -n "$2" -a -n "$3" ]; then
# Output to the terminal in command line mode - if someone wanted to
# resend an email; they could redirect the output to sendmail themselves
- PAGER= generate_email $2 $3 $1
+ PAGER= generate_email $1 $2 $3
else
if [ -n "$envelopesender" ]; then
envelopesender="-f '$envelopesender'"
--
1.5.3.GIT
^ permalink raw reply related
* Re: [PATCH] (Really) Fix install-doc-quick target
From: Johannes Schindelin @ 2007-08-07 14:08 UTC (permalink / raw)
To: René Scharfe
Cc: Junio C Hamano, Mark Levedahl, Mark Levedahl, Git Mailing List
In-Reply-To: <46B879DB.4090504@lsrfire.ath.cx>
Hi,
On Tue, 7 Aug 2007, Ren? Scharfe wrote:
> Junio C Hamano schrieb:
> > Mark Levedahl <mlevedahl@gmail.com> writes:
> >
> >> + printf "$mandir/%s\n" $(git ls-tree -r --name-only $head) | xargs
> >> gzip -f
> >
> > No risk that ls-tree output is too long to fit within the exec
> > args limit to run printf?
>
> Perhaps this instead?
>
> git ls-tree -r --name-only $head | (cd "$mandir" && xargs gzip -f)
I would have done
git ls-tree -r --name-only $head | sed "s|^|$mandir|" | xargs gzip -f
but I like your version better.
Thanks for teaching me,
Dscho
^ 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