* Re: [PATCH] Respect crlf attribute even if core.autocrlf has not been set
From: Eyvind Bernhardsen @ 2008-07-23 19:20 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Avery Pennarun, Joshua Jensen, Junio C Hamano, git
In-Reply-To: <alpine.DEB.1.00.0807231956280.8986@racer>
On 23. juli. 2008, at 20.57, Johannes Schindelin wrote:
> Hi,
>
> On Wed, 23 Jul 2008, Avery Pennarun wrote:
>
>> 1. always CRLF on all platforms (eg. for .bat files)
>> 2. always LF on all platforms (eg. for shell scripts and perl
>> scripts)
>> 3. just leave it alone no matter what (eg. for binary files)
>
> These are not different, but equal. "Do no harm to the contents of
> this
> file".
That is only true until someone edits the file in an editor which
prefers the wrong end-of-line marker, and converts to it when saving.
It will be obvious that this has happened if the user does a "git
diff" before committing, but I think the intent of nos. 1 and 2 is for
git to automatically convert the line endings back instead of kicking
up a fuss.
Might be too magical, though.
Eyvind Bernhardsen
^ permalink raw reply
* [FYI PATCH v2] Added a git search and replace command
From: Sverre Rabbelier @ 2008-07-23 19:55 UTC (permalink / raw)
To: git; +Cc: Sverre Rabbelier
A simple script that uses 'git ls-files' and a bash for
loop to search and replace (using sed) all the specified
files. There is a config option for the pathspec. This
allows the user to set 'sar.pathspec' and then specify only
the sed on the commandline.
---
Not meant for inclusion, just a simple script I wrote up
when I wanted to change a function name in my repository
but didn't want to figure out which magic argument to
find does what I want. Another advantage of using git
ls-files is that it will prevent that any unrevertable
changes will be made (since the script checks if the tree
is dirty or not). I'm sure there's plenty of room for
improvement here, it's probably not portable at all
either, so comments are welcome :).
Changes since v2, the use of xargs was taken out and
replaced by a bash for loop. Also I added a config value
because I'm too lazy to type the pathspec each time.
Interdiff below:
diff --git a/git-sar.sh b/git-sar.sh
index db6317b..e64b9bd 100755
--- a/git-sar.sh
+++ b/git-sar.sh
@@ -1,24 +1,26 @@
#!/bin/bash
-do_sed () {
- sed "$2" $3 > $3.replaced
- mv $3.replaced $3
-}
-
do_git_find() {
# Sanity check
if is_dirty_tree
then
echo "Refusing to work on a dirty tree"
+ exit 1
fi
files=`git ls-files "$1"`
+
+ # See if there were any matching files
if test -z "$files"
then
echo "Your pathspec did not match any files."
exit 1
fi
- echo "$files" | xargs -n 1 git-sar --replace $2
+
+ # Change them in-place
+ for file in $files; do
+ sed -i "$2" "$file";
+ done
}
is_dirty_tree () {
@@ -33,27 +35,28 @@ do_show_usage() {
do_main() {
# Verify argument size
- if test "$#" -le 1 -o "$#" -ge 4
+ if test "$#" -ge 3
then
do_show_usage
fi
- # Two argument form
- if test "$#" -eq 2
+ if test "$#" -eq 1
then
- do_git_find "$@"
- fi
+ glob=`git config --get sar.pathspec`
- # Three argument form, we're calling ourselves through sed
- if test "$#" -eq 3
- then
- # Double check if the user typoed or if we are indeed meta-calling
- if test "$1" != "--replace"
+ if test -z "$glob"
then
+ echo "No sar.pathspec set"
do_show_usage
fi
- do_sed "$@"
+ do_git_find "$glob" "$1"
+ fi
+
+ # Two argument form
+ if test "$#" -eq 2
+ then
+ do_git_find "$@"
fi
}
.gitignore | 1 +
Makefile | 1 +
git-sar.sh | 64 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
3 files changed, 66 insertions(+), 0 deletions(-)
create mode 100755 git-sar.sh
diff --git a/.gitignore b/.gitignore
index a213e8e..451cb93 100644
--- a/.gitignore
+++ b/.gitignore
@@ -108,6 +108,7 @@ git-rev-list
git-rev-parse
git-revert
git-rm
+git-sar
git-send-email
git-send-pack
git-sh-setup
diff --git a/Makefile b/Makefile
index b01cf1c..979e9ea 100644
--- a/Makefile
+++ b/Makefile
@@ -252,6 +252,7 @@ SCRIPT_SH += git-sh-setup.sh
SCRIPT_SH += git-stash.sh
SCRIPT_SH += git-submodule.sh
SCRIPT_SH += git-web--browse.sh
+SCRIPT_SH += git-sar.sh
SCRIPT_PERL += git-add--interactive.perl
SCRIPT_PERL += git-archimport.perl
diff --git a/git-sar.sh b/git-sar.sh
new file mode 100755
index 0000000..e64b9bd
--- /dev/null
+++ b/git-sar.sh
@@ -0,0 +1,64 @@
+#!/bin/bash
+
+do_git_find() {
+ # Sanity check
+ if is_dirty_tree
+ then
+ echo "Refusing to work on a dirty tree"
+ exit 1
+ fi
+
+ files=`git ls-files "$1"`
+
+ # See if there were any matching files
+ if test -z "$files"
+ then
+ echo "Your pathspec did not match any files."
+ exit 1
+ fi
+
+ # Change them in-place
+ for file in $files; do
+ sed -i "$2" "$file";
+ done
+}
+
+is_dirty_tree () {
+ `git diff --quiet`
+ test $? -ne 0
+}
+
+do_show_usage() {
+ echo "usage: git-sar pathspec sed"
+ exit 128
+}
+
+do_main() {
+ # Verify argument size
+ if test "$#" -ge 3
+ then
+ do_show_usage
+ fi
+
+ if test "$#" -eq 1
+ then
+ glob=`git config --get sar.pathspec`
+
+ if test -z "$glob"
+ then
+ echo "No sar.pathspec set"
+ do_show_usage
+ fi
+
+ do_git_find "$glob" "$1"
+ fi
+
+ # Two argument form
+ if test "$#" -eq 2
+ then
+ do_git_find "$@"
+ fi
+}
+
+do_main "$@"
+
--
1.6.0.rc0.15.gc85d5
^ permalink raw reply related
* Re: git-svn - failed to clone repository
From: Avery Pennarun @ 2008-07-23 19:49 UTC (permalink / raw)
To: SZEDER Gábor; +Cc: Derek Fawcus, git
In-Reply-To: <20080723170838.GK22606@neumann>
On 7/23/08, SZEDER Gábor <szeder@fzi.de> wrote:
> It might not help you, but with svn version 1.4.6 (r28521) (from
> Ubuntu 8.04) and current git master the above command has just
> finished successfully.
I believe this was fixed by my patch
29c70e0b3e3183f86f93500882177d0c74069988, which was included in git
1.5.6.2.
Avery
^ permalink raw reply
* Re: [PATCH] Respect crlf attribute even if core.autocrlf has not been set
From: Johannes Schindelin @ 2008-07-23 19:44 UTC (permalink / raw)
To: Eyvind Bernhardsen; +Cc: Avery Pennarun, Joshua Jensen, Junio C Hamano, git
In-Reply-To: <FB7ABDC5-8505-4FD1-8082-9BB5013E73C6@orakel.ntnu.no>
Hi,
On Wed, 23 Jul 2008, Eyvind Bernhardsen wrote:
> On 23. juli. 2008, at 20.57, Johannes Schindelin wrote:
>
> >On Wed, 23 Jul 2008, Avery Pennarun wrote:
> >
> > >1. always CRLF on all platforms (eg. for .bat files)
> > >2. always LF on all platforms (eg. for shell scripts and perl scripts)
> > >3. just leave it alone no matter what (eg. for binary files)
> >
> >These are not different, but equal. "Do no harm to the contents of this
> >file".
>
> That is only true until someone edits the file in an editor which
> prefers the wrong end-of-line marker, and converts to it when saving.
> It will be obvious that this has happened if the user does a "git diff"
> before committing, but I think the intent of nos. 1 and 2 is for git to
> automatically convert the line endings back instead of kicking up a
> fuss.
>
> Might be too magical, though.
I deem it not, uhm, magical. By your reasoning there should be a way for
Git to convert a file to UTF-8 when some entertaining person converted the
working directory file to ISO-8859-15.
Really, either it is CR/LF on all platforms (and then the project members
have to live by it), or it is not. You cannot have both.
If it is CR/LF on all platforms, you just _commit_ it as CR/LF. No
conversion, not even a brain required.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] Respect crlf attribute even if core.autocrlf has not been set
From: Johannes Schindelin @ 2008-07-23 19:41 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Robin Rosenberg, Joshua Jensen, git
In-Reply-To: <7vd4l4cs24.fsf@gitster.siamese.dyndns.org>
Hi,
On Wed, 23 Jul 2008, Junio C Hamano wrote:
> Robin Rosenberg <robin.rosenberg.lists@dewire.com> writes:
>
> >> There are certain file formats, such as a Visual Studio .sln file,
> >> that MUST be CRLF. When a .sln file is not CRLF, Visual Studio
> >> refuses to read it. I want to be able to set into the committed
> >> .gitattributes file the list of files that must be translated to the
> >> proper format regardless of the autocrlf setting. An example is
> >> below:
> >>
> >> *.bat crlf
> >...
> >> *.vcw crlf
> >
> > Wouldn't "*bat -crlf " etc be good for these, and thus store CRLF in
> > the repo.
>
> I'd agree. And I do not think we would want to introduce "crlf=force"
> that converts working tree files that could be LF terminated to CRLF
> upon checking in. That is as bad as some helpful editors that adds CR
> at the end of line without being asked.
You can say that only because you are not in the situation having a lot of
CR/LF files in your _public_ repository _in spite of_ setting the
gitattributes correctly.
That seriously sucks.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH v2] git daemon: avoid waking up too often
From: Johannes Schindelin @ 2008-07-23 19:39 UTC (permalink / raw)
To: Avery Pennarun; +Cc: Johannes Sixt, git, Junio C Hamano
In-Reply-To: <32541b130807231226m73fcc874ub72f69adeb5d26c3@mail.gmail.com>
Hi,
On Wed, 23 Jul 2008, Avery Pennarun wrote:
> On 7/23/08, Johannes Sixt <j.sixt@viscovery.net> wrote:
> > This makes porting this beast to Windows practically impossible
> > because we cannot have a poll() implementation that waits both on a
> > listening socket and a pipe. :-(
>
> I have worked around such problems in the past by having a thread whose
> job it is to read from the pipe and simply write it to a socket. The
> trick works for "console" objects, too, which in win32 are even less
> agreeable than pipes.
>
> (In case your life wasn't disgusting enough already today :))
Thanks. I thought the code I looked at today was ugly, but you convinced
me that there is no limit.
> Alternatively, you could use something like socketpair() instead of a
> pipe for this purpose. Naturally, Win32 helps you out here by somehow
> forgetting to include socketpair() in winsock, although it's sort of
> easy to emulate.
Or alternatively, you could read my response to Hannes where I explain
that the pipe() is not even needed with threaded start_async() (as opposed
to fork()ed one).
Ciao,
Dscho
^ permalink raw reply
* Re: git merge after git cherry-pick?
From: "Peter Valdemar Mørch (Lists)" @ 2008-07-23 19:35 UTC (permalink / raw)
To: SZEDER Gábor; +Cc: git
In-Reply-To: <20080723175600.GL22606@neumann>
SZEDER Gábor szeder-at-ira.uka.de |Lists| wrote:
> You could use 'git rebase' for that.
*Exactly* what I was looking for. Now I know what rebase is for! Thanks.
Peter
--
Peter Valdemar Mørch
http://www.morch.com
^ permalink raw reply
* Re: [PATCH] Respect crlf attribute even if core.autocrlf has not been set
From: Junio C Hamano @ 2008-07-23 19:35 UTC (permalink / raw)
To: Robin Rosenberg; +Cc: Joshua Jensen, Johannes Schindelin, git
In-Reply-To: <200807232122.38471.robin.rosenberg.lists@dewire.com>
Robin Rosenberg <robin.rosenberg.lists@dewire.com> writes:
>> There are certain file formats, such as a Visual Studio .sln file, that
>> MUST be CRLF. When a .sln file is not CRLF, Visual Studio refuses to
>> read it. I want to be able to set into the committed .gitattributes
>> file the list of files that must be translated to the proper format
>> regardless of the autocrlf setting. An example is below:
>>
>> *.bat crlf
>...
>> *.vcw crlf
>
> Wouldn't "*bat -crlf " etc be good for these, and thus store CRLF in the repo.
I'd agree. And I do not think we would want to introduce "crlf=force"
that converts working tree files that could be LF terminated to CRLF upon
checking in. That is as bad as some helpful editors that adds CR at the
end of line without being asked.
^ permalink raw reply
* Re: [PATCH 2/2] sort_in_topological_order(): avoid setting a commit flag
From: Johannes Schindelin @ 2008-07-23 19:33 UTC (permalink / raw)
To: Junio C Hamano; +Cc: pasky, git
In-Reply-To: <7vprp4ctkp.fsf@gitster.siamese.dyndns.org>
Hi,
On Wed, 23 Jul 2008, Junio C Hamano wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>
> > @@ -494,7 +493,8 @@ void sort_in_topological_order(struct commit_list ** list, int lifo)
> > * when all their children have been emitted thereby
> > * guaranteeing topological order.
> > */
> > - if (!--parent->indegree) {
> > + if (--parent->indegree == 1) {
> > + parent->indegree = 0;
> > if (!lifo)
> > insert_by_date(parent, &work);
> > else
> > @@ -505,7 +505,6 @@ void sort_in_topological_order(struct commit_list ** list, int lifo)
> > * work_item is a commit all of whose children
> > * have already been emitted. we can emit it now.
> > */
> > - commit->object.flags &= ~TOPOSORT;
> > *pptr = work_item;
> > pptr = &work_item->next;
> > }
>
> These two hunks look suspicious.
>
> The "tips" used to enter that while() loop with zero indegree, its
> parents examined and then entered the final list pointed by pptr with
> the toposort scratch variables removed and indegree set to zero. Now
> with the new +1 based code, they enter the while() loop with 1 indegree,
> and enter the final list with indegree set to 1.
Almost correct. The way I did it the if() is entered with indegree ==
1, but is set indegree to 0 right away.
I did it this way because of these two lines before the if():
if (!parent->indegree)
continue;
These are the replacement for the previous
if (!(parent->object.flags & TOPOSORT))
continue;
Now, if indegree was not set to 0, that if () would not trigger, but in
the next one (the first hunk you quoted), indegree was decremented and
failed the test == 1.
However, that is correct only by pure chance; I certainly missed that.
The correct fix according to my thinking would be to set the indegree to 0
when the tips are inserted, too.
> A parent that has only one child that is "tip" is discovered in the
> while() loop, its indegree decremented (so it goes down to zero in the
> original code and 1 in yours) and enters work queue to be processed.
> It used to have the toposort scratch variable removed in the second hunk
> above, but that is done in the first hunk in your version.
>
> So after this patch, indegree will be all zero for non-tip commits but
> will be one for tip commits. Is this intended?
No.
> I'd suggest dropping the "parent->indegree = 0" assignment and turn the
> second hunk into "commit->indgree = 0" assignment.
Yeah, that is much simpler.
Thanks,
Dscho
^ permalink raw reply
* Re: [PATCH] Respect crlf attribute even if core.autocrlf has not been set
From: Dmitry Potapov @ 2008-07-23 19:33 UTC (permalink / raw)
To: Joshua Jensen; +Cc: Johannes Schindelin, Junio C Hamano, git
In-Reply-To: <488772BC.80207@workspacewhiz.com>
On Wed, Jul 23, 2008 at 10:04 PM, Joshua Jensen
<jjensen@workspacewhiz.com> wrote:
>
> There are certain file formats, such as a Visual Studio .sln file, that MUST
> be CRLF. When a .sln file is not CRLF, Visual Studio refuses to read it.
I wonder what exactly version of Visual Studio you use? All version that
I have seen had no problem reading .sln with LF ending, though they always
wrote it back with CRLF. In any case, you can define as binary, so Git will
not do anything about their EOLs.
Dmitry
^ permalink raw reply
* Re: [PATCH v2] git daemon: avoid waking up too often
From: Avery Pennarun @ 2008-07-23 19:26 UTC (permalink / raw)
To: Johannes Sixt; +Cc: Johannes Schindelin, git, Junio C Hamano
In-Reply-To: <4886D503.7030106@viscovery.net>
On 7/23/08, Johannes Sixt <j.sixt@viscovery.net> wrote:
> This makes porting this beast to Windows practically impossible because we
> cannot have a poll() implementation that waits both on a listening socket
> and a pipe. :-(
I have worked around such problems in the past by having a thread
whose job it is to read from the pipe and simply write it to a socket.
The trick works for "console" objects, too, which in win32 are even
less agreeable than pipes.
(In case your life wasn't disgusting enough already today :))
Alternatively, you could use something like socketpair() instead of a
pipe for this purpose. Naturally, Win32 helps you out here by somehow
forgetting to include socketpair() in winsock, although it's sort of
easy to emulate.
Have fun,
Avery
^ permalink raw reply
* Re: [PATCH] Respect crlf attribute even if core.autocrlf has not been set
From: Robin Rosenberg @ 2008-07-23 19:22 UTC (permalink / raw)
To: Joshua Jensen; +Cc: Johannes Schindelin, Junio C Hamano, git
In-Reply-To: <488772BC.80207@workspacewhiz.com>
onsdagen den 23 juli 2008 20.04.44 skrev Joshua Jensen:
> ----- Original Message -----
> From: Johannes Schindelin
> Date: 7/23/2008 11:22 AM
> > On msys we do that. A few users decided they know better and switched it
> > off. Me for example. But I wouldn't do something as stupid as editing a
> > file with an editor that tries to be helpful and adds CR/LFs.
> >
> There are certain file formats, such as a Visual Studio .sln file, that
> MUST be CRLF. When a .sln file is not CRLF, Visual Studio refuses to
> read it. I want to be able to set into the committed .gitattributes
> file the list of files that must be translated to the proper format
> regardless of the autocrlf setting. An example is below:
>
> *.bat crlf
> *.def crlf
> *.dsp crlf
> *.dsw crlf
> *.rc crlf
> *.sln crlf
> *.vcproj crlf
> *.vcp crlf
> *.vcw crlf
Wouldn't "*bat -crlf " etc be good for these, and thus store CRLF in the repo.
-- robin
^ permalink raw reply
* Re: [PATCH] Respect crlf attribute even if core.autocrlf has not been set
From: Junio C Hamano @ 2008-07-23 19:23 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <alpine.DEB.1.00.0807231817460.8986@racer>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> On Wed, 23 Jul 2008, Junio C Hamano wrote:
> ...
>> If you are on a sane system, you do not even want to pay the price of
>> conversion. Only people on systems with CRLF line endings should pay
>> the price (because your aim is to convert on such systems). Are we
>> throwing that out of the window when the project decides to use
>> gitattributes?
>
> Well, if you do not want that, why do you set crlf in the gitattributes to
> begin with?
It is not _me_ but the project upstream that needs to interact also with
Windows people who manages gitattributes. And me personally knows my
editors are not helpful to add CR at the end of lines, so I do not need
the conversion.
That was the situation I had in mind.
^ permalink raw reply
* Re: [PATCH] Build configuration to skip ctime for modification test
From: Alex Riesen @ 2008-07-23 19:16 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Junio C Hamano, Johannes Sixt, git
In-Reply-To: <alpine.DEB.1.00.0807231757550.8986@racer>
Johannes Schindelin, Wed, Jul 23, 2008 18:59:02 +0200:
> On Wed, 23 Jul 2008, Alex Riesen wrote:
>
> > Because exactly the file mode (the executable bit) is the reason for
> > checking ctime.
>
> But ctime is broken on Windows. Because ctime is supposed to change
> whenever the _inode_ changes.
It is not that it is broken. We just don't need it, because the st_mode
is not used, and the rest of inode information is not used anyway.
> You have to admit that saying "I ignore the ctime because the executable
> bit is broken" must leave the reader puzzled.
This is conclusion. I said "file mode" and "file attributes", which
is how reason for ctime update is defined in SUSv3. man 2 stat says:
The field st_ctime is changed by writing or by setting inode
information (i.e., owner, group, link count, mode, etc.).
Not just "inode" but "inode information". Only mode is used, and even
that is ignored on Windows.
^ permalink raw reply
* [PATCH 5/9 v2] Allow the built-in exec path to be relative to the command invocation path
From: Johannes Sixt @ 2008-07-23 19:12 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vfxq0e9lk.fsf@gitster.siamese.dyndns.org>
If GIT_EXEC_PATH (the macro that is defined in the Makefile) is relative,
it is interpreted relative to the command's invocation path, which usually
is $(bindir).
The Makefile rules were written with the assumption that $(gitexecdir) is
an absolute path. We introduce a separate variable that names the
(absolute) installation directory.
Signed-off-by: Johannes Sixt <johannes.sixt@telecom.at>
---
On Mittwoch, 23. Juli 2008, Junio C Hamano wrote:
> Johannes Sixt <johannes.sixt@telecom.at> writes:
> > If $(gitexecdir) is relative, it is interpreted relative to the command's
> > invocation path, which usually is $(bindir).
> >
> > The Makefile rules were written with the assumption that $(gitexecdir) is
> > an absolute path. We introduce a separate variable that names the
> > (absolute) installation directory.
> > ...
> > +ifeq ($(firstword $(subst /, ,$(gitexecdir))),..)
> > +gitexec_instdir = $(bindir)/$(gitexecdir)
> > +else
>
> Can we please have a brief comment in the Makefile near we define mandir,
> infodir, gitexecdir and friends about this "relative to $(bindir)"
> business?
Here it is.
It also fixes 'make install' of git-gui as well (sigh!) by not exporting
gitexecdir - assuming that Shawn applies the git-gui patch.
The first two hunks are new compared to v1 of this patch.
-- Hannes
Makefile | 28 +++++++++++++++++++++++-----
exec_cmd.c | 38 ++------------------------------------
2 files changed, 25 insertions(+), 41 deletions(-)
diff --git a/Makefile b/Makefile
index 23f2185..4f19b52 100644
--- a/Makefile
+++ b/Makefile
@@ -170,6 +170,16 @@ ALL_CFLAGS = $(CFLAGS)
ALL_LDFLAGS = $(LDFLAGS)
STRIP ?= strip
+# Among the variables below, these:
+# gitexecdir
+# template_dir
+# htmldir
+# ETC_GITCONFIG (but not sysconfdir)
+# can be specified as a relative path ../some/where/else (which must begin
+# with ../); this is interpreted as relative to $(bindir) and "git" at
+# runtime figures out where they are based on the path to the executable.
+# This can help installing the suite in a relocatable way.
+
prefix = $(HOME)
bindir = $(prefix)/bin
mandir = $(prefix)/share/man
@@ -205,7 +215,7 @@ GITWEB_FAVICON = git-favicon.png
GITWEB_SITE_HEADER =
GITWEB_SITE_FOOTER =
-export prefix bindir gitexecdir sharedir htmldir sysconfdir
+export prefix bindir sharedir htmldir sysconfdir
CC = gcc
AR = ar
@@ -1316,10 +1326,18 @@ template_instdir = $(template_dir)
endif
export template_instdir
+ifeq ($(firstword $(subst /, ,$(gitexecdir))),..)
+gitexec_instdir = $(bindir)/$(gitexecdir)
+else
+gitexec_instdir = $(gitexecdir)
+endif
+gitexec_instdir_SQ = $(subst ','\'',$(gitexec_instdir))
+export gitexec_instdir
+
install: all
$(INSTALL) -d -m 755 '$(DESTDIR_SQ)$(bindir_SQ)'
- $(INSTALL) -d -m 755 '$(DESTDIR_SQ)$(gitexecdir_SQ)'
- $(INSTALL) $(ALL_PROGRAMS) '$(DESTDIR_SQ)$(gitexecdir_SQ)'
+ $(INSTALL) -d -m 755 '$(DESTDIR_SQ)$(gitexec_instdir_SQ)'
+ $(INSTALL) $(ALL_PROGRAMS) '$(DESTDIR_SQ)$(gitexec_instdir_SQ)'
$(INSTALL) git$X git-upload-pack$X git-receive-pack$X
git-upload-archive$X '$(DESTDIR_SQ)$(bindir_SQ)'
$(MAKE) -C templates DESTDIR='$(DESTDIR_SQ)' install
$(MAKE) -C perl prefix='$(prefix_SQ)' DESTDIR='$(DESTDIR_SQ)' install
@@ -1328,10 +1346,10 @@ ifndef NO_TCLTK
$(MAKE) -C git-gui install
endif
ifneq (,$X)
- $(foreach p,$(patsubst %$X,%,$(filter %$X,$(ALL_PROGRAMS) $(BUILT_INS) git$X)),
$(RM) '$(DESTDIR_SQ)$(gitexecdir_SQ)/$p';)
+ $(foreach p,$(patsubst %$X,%,$(filter %$X,$(ALL_PROGRAMS) $(BUILT_INS) git$X)),
$(RM) '$(DESTDIR_SQ)$(gitexec_instdir_SQ)/$p';)
endif
bindir=$$(cd '$(DESTDIR_SQ)$(bindir_SQ)' && pwd) && \
- execdir=$$(cd '$(DESTDIR_SQ)$(gitexecdir_SQ)' && pwd) && \
+ execdir=$$(cd '$(DESTDIR_SQ)$(gitexec_instdir_SQ)' && pwd) && \
if test "z$$bindir" != "z$$execdir"; \
then \
ln -f "$$bindir/git$X" "$$execdir/git$X" || \
diff --git a/exec_cmd.c b/exec_cmd.c
index 45f92eb..c236034 100644
--- a/exec_cmd.c
+++ b/exec_cmd.c
@@ -7,40 +7,6 @@ extern char **environ;
static const char *argv_exec_path;
static const char *argv0_path;
-static const char *builtin_exec_path(void)
-{
-#ifndef __MINGW32__
- return GIT_EXEC_PATH;
-#else
- int len;
- char *p, *q, *sl;
- static char *ep;
- if (ep)
- return ep;
-
- len = strlen(_pgmptr);
- if (len < 2)
- return ep = ".";
-
- p = ep = xmalloc(len+1);
- q = _pgmptr;
- sl = NULL;
- /* copy program name, turn '\\' into '/', skip last part */
- while ((*p = *q)) {
- if (*q == '\\' || *q == '/') {
- *p = '/';
- sl = p;
- }
- p++, q++;
- }
- if (sl)
- *sl = '\0';
- else
- ep[0] = '.', ep[1] = '\0';
- return ep;
-#endif
-}
-
const char *system_path(const char *path)
{
if (!is_absolute_path(path) && argv0_path) {
@@ -75,7 +41,7 @@ const char *git_exec_path(void)
return env;
}
- return builtin_exec_path();
+ return system_path(GIT_EXEC_PATH);
}
static void add_path(struct strbuf *out, const char *path)
@@ -99,7 +65,7 @@ void setup_path(void)
add_path(&new_path, argv_exec_path);
add_path(&new_path, getenv(EXEC_PATH_ENVIRONMENT));
- add_path(&new_path, builtin_exec_path());
+ add_path(&new_path, system_path(GIT_EXEC_PATH));
add_path(&new_path, argv0_path);
if (old_path)
--
1.6.0.rc0.18.g6aef2
^ permalink raw reply related
* Re: [PATCH/RFC] git add: do not add files from a submodule
From: Pierre Habouzit @ 2008-07-23 19:11 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Junio C Hamano, git
In-Reply-To: <alpine.DEB.1.00.0807232009310.8986@racer>
[-- Attachment #1: Type: text/plain, Size: 382 bytes --]
On Wed, Jul 23, 2008 at 07:10:09PM +0000, Johannes Schindelin wrote:
> Hi,
>
> On Wed, 23 Jul 2008, Pierre Habouzit wrote:
>
> > Though it'd be great to say e.g. that we won't do a 1.7.0 release[0]
> > until we have an UI for submodules we are prood of.
>
> Or until we have everything ported over to parse_options?
hahah, okay, fair enough, I deserve this one ;)
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: [PATCH/RFC] git add: do not add files from a submodule
From: Johannes Schindelin @ 2008-07-23 19:10 UTC (permalink / raw)
To: Pierre Habouzit; +Cc: Junio C Hamano, git
In-Reply-To: <20080723190227.GF20614@artemis.madism.org>
Hi,
On Wed, 23 Jul 2008, Pierre Habouzit wrote:
> Though it'd be great to say e.g. that we won't do a 1.7.0 release[0]
> until we have an UI for submodules we are prood of.
Or until we have everything ported over to parse_options?
Ciao,
Dscho
^ permalink raw reply
* Re: q: faster way to integrate/merge lots of topic branches?
From: Pierre Habouzit @ 2008-07-23 19:09 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Ingo Molnar, git
In-Reply-To: <alpine.LFD.1.10.0807231027030.4754@woody.linux-foundation.org>
[-- Attachment #1: Type: text/plain, Size: 1457 bytes --]
On Wed, Jul 23, 2008 at 05:59:01PM +0000, Linus Torvalds wrote:
> In fact, the two top entries in a profile look roughly like:
>
> 102161 70.2727 libz.so.1.2.3 libz.so.1.2.3 (no symbols)
> 7685 5.2862 git git find_pack_entry_one
> ...
>
> ie 70% of the time is just purely unpacking the data, and another 5% is
> just finding it. We could perhaps improve on it, but not a whole lot.
Well there is an easy way though, that could reduce that: using
adaptative compression. I proposed a patch once upon a time, that set
the compression strengh to 0 for "small" objects with a configurable
cut-off. If you do that, most trees, commits messages and so on aren't
compressed, and it will reduce (with IIRC a 5-liner) this time quite
dramatically.
I could maybe resurect it to see if for people that do the kind of
things Ingo does it helps. By setting the cut-off at 1k, I had packs
being less than 1% bigger IIRC. I'll try to find it again and run your
tests with it to see how much it helps.
[ Of course, it doesn't invalidate the rest of your mail about being
more clever with git-merge, but still, we could reduce this 70% of
zlib time quite a lot with that ]
--
·O· Pierre Habouzit
··O madcoder@debian.org
OOO http://www.madism.org
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: [PATCH] Fix git-svnimport against libsvn_ra.
From: Junio C Hamano @ 2008-07-23 19:09 UTC (permalink / raw)
To: P. Christeas; +Cc: git, Gerrit Pape
In-Reply-To: <200807231008.39455.p_christ@hol.gr>
Thanks.
But the one line description is not descriptive enough, don't you think?
Imagine this line (and nothing else from what you wrote in the body text)
appearing among 100 other commits. Can you tell what this commit is about
3 months from now on?
Perhaps:
svnimport: newer libsvn wants us to ask for the root with "", not "/"
> In r27729, libsvn introduced an assert which explicitly
> forbids searching the tree at "/". Luckily enough, it
> still accepts an empty string "" as the starting point.
I think you implied by saying "still", asking with an empty string had the
same effect as asking for the root "/" in earlier versions of SVN, and the
patch will not break people with older libsvn. Is that correct?
> http://svn.collab.net/viewvc/svn/trunk/subversion/libsvn_ra/ra_loader.c?r1=27653&r2=27729
> ---
Sign-off, please?
^ permalink raw reply
* Re: [PATCH 02/12] git-grep: support --no-external-grep
From: Petr Baudis @ 2008-07-23 19:05 UTC (permalink / raw)
To: Nguy???n Thái Ng???c Duy; +Cc: git
In-Reply-To: <20080723190129.GM32184@machine.or.cz>
Hi!
On Wed, Jul 23, 2008 at 09:01:30PM +0200, Petr Baudis wrote:
> (Which is also why is it useful to write cover letters for
> patch series.)
sorry, I did not notice the cover letter, already separated from the
rest by a sprouting thread. Which is also why it is useful to thread up
all the patches. ;-)
Petr "Pasky" Baudis
^ permalink raw reply
* Re: [PATCH] Add help.autocorrect to enable/disable autocorrecting
From: Johannes Schindelin @ 2008-07-23 19:04 UTC (permalink / raw)
To: Alex Riesen; +Cc: git
In-Reply-To: <alpine.DEB.1.00.0807231958210.8986@racer>
Hi,
On Wed, 23 Jul 2008, Johannes Schindelin wrote:
> On Wed, 23 Jul 2008, Alex Riesen wrote:
>
> > Johannes Schindelin, Wed, Jul 23, 2008 18:44:49 +0200:
> > > > + n = 1;
> > > > + while (n < main_cmds.cnt &&
> > > > + best_similarity == similarity(main_cmds.names[n]->name))
> > > > + ++n;
> > >
> > > Mini-nit: you never ask for the value of n, only if it is 1 or larger. So
> > > you do not need to count...
> >
> > But I do, don't I? AFAICS, I use 0, 1 and >1 (this-these).
>
> Yes. So check cnt > 0 && best_similarity > 5 says if it is 0,
Oh, I just realized that my patch is bogus anyway. It only checks for
best_similarity > 5 in the case that the first two commands have equal
similarity. D'oh.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH 2/2] sort_in_topological_order(): avoid setting a commit flag
From: Junio C Hamano @ 2008-07-23 19:02 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: pasky, git
In-Reply-To: <alpine.DEB.1.00.0807230150480.8986@racer>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> @@ -494,7 +493,8 @@ void sort_in_topological_order(struct commit_list ** list, int lifo)
> * when all their children have been emitted thereby
> * guaranteeing topological order.
> */
> - if (!--parent->indegree) {
> + if (--parent->indegree == 1) {
> + parent->indegree = 0;
> if (!lifo)
> insert_by_date(parent, &work);
> else
> @@ -505,7 +505,6 @@ void sort_in_topological_order(struct commit_list ** list, int lifo)
> * work_item is a commit all of whose children
> * have already been emitted. we can emit it now.
> */
> - commit->object.flags &= ~TOPOSORT;
> *pptr = work_item;
> pptr = &work_item->next;
> }
These two hunks look suspicious.
The "tips" used to enter that while() loop with zero indegree, its parents
examined and then entered the final list pointed by pptr with the toposort
scratch variables removed and indegree set to zero. Now with the new +1
based code, they enter the while() loop with 1 indegree, and enter the
final list with indegree set to 1.
A parent that has only one child that is "tip" is discovered in the
while() loop, its indegree decremented (so it goes down to zero in the
original code and 1 in yours) and enters work queue to be processed. It
used to have the toposort scratch variable removed in the second hunk
above, but that is done in the first hunk in your version.
So after this patch, indegree will be all zero for non-tip commits but
will be one for tip commits. Is this intended?
I'd suggest dropping the "parent->indegree = 0" assignment and turn the
second hunk into "commit->indgree = 0" assignment.
^ permalink raw reply
* Re: [PATCH/RFC] git add: do not add files from a submodule
From: Pierre Habouzit @ 2008-07-23 19:02 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Johannes Schindelin, git
In-Reply-To: <7v8wvse9l7.fsf@gitster.siamese.dyndns.org>
[-- Attachment #1: Type: text/plain, Size: 2719 bytes --]
On Wed, Jul 23, 2008 at 06:31:16PM +0000, Junio C Hamano wrote:
> Pierre Habouzit <madcoder@debian.org> writes:
>
> > On Wed, Jul 23, 2008 at 06:40:20AM +0000, Junio C Hamano wrote:
> > ...
> >> If we started the process of diagnosing and fixing these issues earlier,
> >> and had plausible code to address the issue already in 'next' before the
> >> current -rc cycle started, the topic would have been an obvious candidate
> >> for the coming release and I'd further say it would be even worth delaying
> >> the release for a few weeks if it takes more time. But I have to say it
> >> is too late for 1.6.0 now if we are just noticing and starting the
> >> discussion.
> >
> > Well given that we now use submodules at work, and that git is
> > nowadays somewhere in the top 5 of my most consciously (as opposed to
> > the compiler that I rarely call by hand) used software suites (among my
> > editor, my MUA, my shell and my tiling WM), I'm very much interested in
> > tackling some things about what is (not) done with submodules yet.
>
> Surely the effort is appreciated.
okay I'll try to work on this on the git wiki so that collaboration is
possible.
>
> >> This comment goes to the issue Pierre raised last night as well.
> >
> > You mean the git checkout issue?
>
> Oh, no; that misuse of parse_opt() that forgot KEEP_DASHDASH one was not
> what I had in mind. I meant to say that your "switch branches between an
> old pre-submodule rev and a new one that has a submodule at where a blob
> or directory used to be" issue with a good explanation material was a good
> starting point for submodule improvements for the next cycle.
ohh that :)
> I'd like the release schedule not too heavily based on "per feature", but
> more time-based.
Yeah, we've seen in the past how it makes a release slip. Though it'd
be great to say e.g. that we won't do a 1.7.0 release[0] until we have
an UI for submodules we are prood of. It doesn't mean that we won't have
a 1.6.21 because it's slow to get into shape ;)
IOW I'm all for time based releases, with some big milestones that
when completed bump the git version significantly. And hinting on what
are those milestones would probably be quite nice. I mean git
developpement is kind of a hit and run thing: people have an issue, come
with patches, and go back to their lives (except for a mere 20 regular
contributors with more than 50 patches). Maybe we should hint some
direction we would like to see a bit more. examples of such big
directions are:
* submodules UI ;
* sparse checkouts ;
* ...
[0] I don't really *mean* we must do it for 1.7.0, It's merely an
example.
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: [PATCH 02/12] git-grep: support --no-external-grep
From: Petr Baudis @ 2008-07-23 19:01 UTC (permalink / raw)
To: Nguy???n Thái Ng???c Duy; +Cc: git
In-Reply-To: <20080723145549.GA29067@laptop>
Hi,
the patches 2, 3, 8 and 10 of your series introduce config options,
commandline switches and environment variables that are not documented
anywhere - can you please include documentation updates in your patch
series as well? It might be worth it to find some suitable place in the
documentation where to explain the concept itself; it took me quite
sometime before I actually realized (I think) what are your patches
about. (Which is also why is it useful to write cover letters for
patch series.)
--
Petr "Pasky" Baudis
As in certain cults it is possible to kill a process if you know
its true name. -- Ken Thompson and Dennis M. Ritchie
^ permalink raw reply
* Re: [PATCH] Add help.autocorrect to enable/disable autocorrecting
From: Johannes Schindelin @ 2008-07-23 19:00 UTC (permalink / raw)
To: Alex Riesen; +Cc: git
In-Reply-To: <20080723184443.GD5283@blimp.local>
Hi,
On Wed, 23 Jul 2008, Alex Riesen wrote:
> Johannes Schindelin, Wed, Jul 23, 2008 18:44:49 +0200:
> > > + n = 1;
> > > + while (n < main_cmds.cnt &&
> > > + best_similarity == similarity(main_cmds.names[n]->name))
> > > + ++n;
> >
> > Mini-nit: you never ask for the value of n, only if it is 1 or larger. So
> > you do not need to count...
>
> But I do, don't I? AFAICS, I use 0, 1 and >1 (this-these).
Yes. So check cnt > 0 && best_similarity > 5 says if it is 0, and
cnt > 1 && best_similarity < similarity(...[1]...) says if it is 1.
Ergo: no need to count,
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