Git development
 help / color / mirror / Atom feed
* Re: [RESEND] [PATCH] Endianness bug in index cache logic
From: Junio C Hamano @ 2009-12-27 18:24 UTC (permalink / raw)
  To: Nathaniel W Filardo; +Cc: git
In-Reply-To: <20091227061121.GP14941@gradx.cs.jhu.edu>

Nathaniel W Filardo <nwf@cs.jhu.edu> writes:

> I got some free time and tracked it down.  The following one-line delta
> fixes this issue for me; AIUI on sparc64 "unsigned long" is 8 bits and in
> the wrong endianness for the memcpy trick to work as written?  I could be
> sligntly off in my assessment of the problem, tho'.
>
> index 1bbaf1c..9033dd3 100644
> --- a/read-cache.c
> +++ b/read-cache.c
> @@ -1322,7 +1322,7 @@ int read_index_from(struct index_state *istate, const char *path)
>                  * extension name (4-byte) and section length
>                  * in 4-byte network byte order.
>                  */
> -               unsigned long extsize;
> +               uint32_t extsize;
>                 memcpy(&extsize, (char *)mmap + src_offset + 4, 4);
>                 extsize = ntohl(extsize);
>                 if (read_index_extension(istate,

Good catch.

The original is broken on big endian 64-bit platforms, and your sparc64
indeed is one.  The code expects to see a signature (4-byte) at src_offset
followed by length (4-byte int in network byte order) and it is trying to
read read the latter in extsize.

Thanks for the fix.  The bug dates back to late April 2006, and I am kind
of surprised that nobody reported this since then (perhaps nobody runs git
on big endian 64-bit boxes?).

^ permalink raw reply

* Re: Newbie to git
From: mysql.jorge @ 2009-12-27 17:45 UTC (permalink / raw)
  To: git
In-Reply-To: <1435.87.196.47.196.1261932152.squirrel@webmail.decimal.pt>

> I'm a using of git for several time, but now I have the need to a git
> server.
> My question, where can get a howto for reallyyyy newbies on git server?

One question:

I've created a project on the server with:

mkdir project.git
cd project.git
git init

-and now locally, created a directory, and cloned this, it said that i was
cloning an empty repo, fine about that.
-now i added something locally, i get: (locally this is on a windows
machine with tortoiso git)

--
git.exe push  --tags  "origin" master:git://192.168.1.206/projects.git

error: src refspec master:git does not match any.
error: failed to push some refs to 'git://192.168.1.206/projects.git'
--

I've read somewhere that i have to init both repos, remote and local to
the same branch, is it correct?

My idea is:

- clone remote repo
- add projects locally and commit them to remote

how can this be done easylly?

^ permalink raw reply

* Re: [PATCH RESEND] gitk: add "--no-replace-objects" option
From: Christian Couder @ 2009-12-27 17:26 UTC (permalink / raw)
  To: Paul Mackerras
  Cc: git, Michael J Gruber, Jakub Narebski, Johannes Sixt, bill lam,
	Andreas Schwab, Junio C Hamano
In-Reply-To: <20091213230923.GB8135@brick.ozlabs.ibm.com>

On lundi 14 décembre 2009, Paul Mackerras wrote:
> On Sat, Dec 12, 2009 at 05:52:39AM +0100, Christian Couder wrote:
> > Replace refs are useful to change some git objects after they
> > have started to be shared between different repositories. One
> > might want to ignore them to see the original state, and
> > "--no-replace-objects" option can be used from the command
> > line to do so.
> >
> > This option simply sets the GIT_NO_REPLACE_OBJECTS environment
> > variable, and that is enough to make gitk ignore replace refs.
> >
> > The GIT_NO_REPLACE_OBJECTS is set to "1" instead of "" as it is
> > safer on some platforms, thanks to Johannes Sixt and Michael J
> > Gruber.
> >
> > Tested-by: Michael J Gruber <git@drmicha.warpmail.net>
> > Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
>
> Thanks, applied.

Thanks, but it looks like the patch is not in v1.6.6.
Could you ask Junio to pull from you?

Best regards,
Christian.

^ permalink raw reply

* Newbie to git
From: Jorge Bastos @ 2009-12-27 16:42 UTC (permalink / raw)
  To: git

Howdy people,

I'm a using of git for several time, but now I have the need to a git server.
My question, where can get a howto for reallyyyy newbies on git server?

I have part of it setup but still not working.

Thanks in advanced,
Jorge,

^ permalink raw reply

* Re: [RESEND] [PATCH] Endianness bug in index cache logic
From: Nathaniel W Filardo @ 2009-12-27 16:12 UTC (permalink / raw)
  To: kusmabite; +Cc: Nathaniel W Filardo, git
In-Reply-To: <40aa078e0912270439i3948a38fw9784e23e7cdc4407@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 378 bytes --]

On Sun, Dec 27, 2009 at 01:39:24PM +0100, Erik Faye-Lund wrote:
> On Sun, Dec 27, 2009 at 7:11 AM, Nathaniel W Filardo <nwf@cs.jhu.edu> wrote:
> > I got some free time and tracked it down.  The following one-line delta
> > fixes this issue for me; AIUI on sparc64 "unsigned long" is 8 bits and in
> 
> You mean 8 bytes, right?

Yes, sorry.  How embarrassing. :)
--nwf;

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

^ permalink raw reply

* [PATCH] Fix core.worktree being used when GIT_DIR is not set
From: Nguyễn Thái Ngọc Duy @ 2009-12-27 13:28 UTC (permalink / raw)
  To: git, Junio C Hamano, Johannes Schindelin, Robin Rosenberg
  Cc: Nguyễn Thái Ngọc Duy
In-Reply-To: <200912071115.48085.robin.rosenberg.lists@dewire.com>

According to config.txt:
> core.worktree::
>         Set the path to the working tree.  The value will not be
>         used in combination with repositories found automatically in
>         a .git directory (i.e. $GIT_DIR is not set).

This behavior was changed after e90fdc3 (Clean up work-tree handling -
2007-08-01) and 9459aa7 (Do check_repository_format() early (re-fix) -
2007-12-05). If core.worktree is set, even if git_dir automatically
found (and git_work_tree_cfg set), git_work_tree_cfg will be reset to
core.worktree. This makes core.worktree effective even if GIT_DIR is
not set, in contrast to config.txt.

This patch makes sure it only checks for core.worktree if GIT_DIR is set.

Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
---
 setup.c             |   19 +++++++++++++------
 t/t1501-worktree.sh |    4 ++++
 2 files changed, 17 insertions(+), 6 deletions(-)

diff --git a/setup.c b/setup.c
index 2cf0f19..35b7915 100644
--- a/setup.c
+++ b/setup.c
@@ -283,6 +283,18 @@ const char *read_gitfile_gently(const char *path)
 	return path;
 }
 
+static int check_repository_work_tree(const char *var, const char *value, void *cb)
+{
+	if (strcmp(var, "core.worktree") == 0) {
+		if (!value)
+			return config_error_nonbool(var);
+		free(git_work_tree_cfg);
+		git_work_tree_cfg = xstrdup(value);
+		inside_work_tree = -1;
+	}
+	return 0;
+}
+
 /*
  * 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.
@@ -320,6 +332,7 @@ const char *setup_git_directory_gently(int *nongit_ok)
 			if (!work_tree_env) {
 				retval = set_work_tree(gitdirenv);
 				/* config may override worktree */
+				git_config(check_repository_work_tree, NULL);
 				if (check_repository_format_gently(nongit_ok))
 					return NULL;
 				return retval;
@@ -474,12 +487,6 @@ int check_repository_format_version(const char *var, const char *value, void *cb
 		is_bare_repository_cfg = git_config_bool(var, value);
 		if (is_bare_repository_cfg == 1)
 			inside_work_tree = -1;
-	} else if (strcmp(var, "core.worktree") == 0) {
-		if (!value)
-			return config_error_nonbool(var);
-		free(git_work_tree_cfg);
-		git_work_tree_cfg = xstrdup(value);
-		inside_work_tree = -1;
 	}
 	return 0;
 }
diff --git a/t/t1501-worktree.sh b/t/t1501-worktree.sh
index 74e6443..9756f35 100755
--- a/t/t1501-worktree.sh
+++ b/t/t1501-worktree.sh
@@ -30,6 +30,10 @@ test_rev_parse() {
 
 EMPTY_TREE=$(git write-tree)
 mkdir -p work/sub/dir || exit 1
+
+git config core.worktree work
+test_rev_parse 'core.worktree without GIT_DIR' false false true ''
+
 mv .git repo.git || exit 1
 
 say "core.worktree = relative path"
-- 
1.6.5.2.216.g9c1ec

^ permalink raw reply related

* Re: [RESEND] [PATCH] Endianness bug in index cache logic
From: Erik Faye-Lund @ 2009-12-27 12:39 UTC (permalink / raw)
  To: Nathaniel W Filardo; +Cc: git
In-Reply-To: <20091227061121.GP14941@gradx.cs.jhu.edu>

On Sun, Dec 27, 2009 at 7:11 AM, Nathaniel W Filardo <nwf@cs.jhu.edu> wrote:
> I got some free time and tracked it down.  The following one-line delta
> fixes this issue for me; AIUI on sparc64 "unsigned long" is 8 bits and in

You mean 8 bytes, right?

-- 
Erik "kusma" Faye-Lund

^ permalink raw reply

* [RESEND] [PATCH] Endianness bug in index cache logic
From: Nathaniel W Filardo @ 2009-12-27  6:11 UTC (permalink / raw)
  To: git
In-Reply-To: <20091204202928.GW17192@gradx.cs.jhu.edu>

[-- Attachment #1: Type: text/plain, Size: 2214 bytes --]

On Fri, Dec 04, 2009 at 03:29:28PM -0500, Nathaniel W Filardo wrote:
> On Fri, Dec 04, 2009 at 09:16:40PM +0100, Andreas Schwab wrote:
> > Nathaniel W Filardo <nwf@cs.jhu.edu> writes:
> > 
> > > On this machine,
> > >
> > > mirrors hydra:/tank0/mirrors/misc% uname -a
> > > FreeBSD hydra.priv.oc.ietfng.org 9.0-CURRENT FreeBSD 9.0-CURRENT #13: Sat Nov 14 19:40:25 EST 2009 root@hydra.priv.oc.ietfng.org:/systank/obj/systank/src/sys/NWFKERN  sparc64
> > >
> > > attempting to fetch from an svn source yields the following error:
> > >
> > > rs hydra:/tank0/mirrors/misc% git svn init -s https://joshua.svn.sourceforge.net/svnroot/joshua test-joshua
> > > Initialized empty Git repository in /tank0/mirrors/misc/test-joshua/.git/                                       
> > > mirrors hydra:/tank0/mirrors/misc% cd test-joshua                                                               
> > > mirrors hydra:/tank0/mirrors/misc/test-joshua% git svn fetch
> > >         A       scripts/distributedLM/config.template       
> > > [...]
> > >         A       build.xml
> > > r1 = fe84a7d821ec6d92da75133ac7ad1deb476b6484 (refs/remotes/trunk)
> > > error: index uses  extension, which we do not understand
> > > fatal: index file corrupt
> > > write-tree: command returned error: 128
> > 
> > I could not reproduce that on powerpc (both 32bit and 64bit).
> > 
> > Andreas.

I got some free time and tracked it down.  The following one-line delta
fixes this issue for me; AIUI on sparc64 "unsigned long" is 8 bits and in
the wrong endianness for the memcpy trick to work as written?  I could be
sligntly off in my assessment of the problem, tho'.

index 1bbaf1c..9033dd3 100644
--- a/read-cache.c
+++ b/read-cache.c
@@ -1322,7 +1322,7 @@ int read_index_from(struct index_state *istate, const char *path)
                 * extension name (4-byte) and section length
                 * in 4-byte network byte order.
                 */
-               unsigned long extsize;
+               uint32_t extsize;
                memcpy(&extsize, (char *)mmap + src_offset + 4, 4);
                extsize = ntohl(extsize);
                if (read_index_extension(istate,

--nwf;

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

^ permalink raw reply related

* [PATCH] Don't pass CFLAGS to the linker
From: Tomas Carnecky @ 2009-12-27  6:55 UTC (permalink / raw)
  To: git

Signed-off-by: Tomas Carnecky <tom@dbservice.com>
---

I don't remember exactly which tool had problems with CFLAGS being passed
to the linker. Maybe it was the clang static analyzer, or some other
tool that I let run on git.git. Anyway, I don't think there's any
reason to pass CFLAGS to the linker.

 Makefile |   15 +++++++--------
 1 files changed, 7 insertions(+), 8 deletions(-)

diff --git a/Makefile b/Makefile
index c11719c..d9cd189 100644
--- a/Makefile
+++ b/Makefile
@@ -1473,8 +1473,7 @@ git.o: git.c common-cmds.h GIT-CFLAGS
 		$(ALL_CFLAGS) -o $@ -c $(filter %.c,$^)
 
 git$X: git.o $(BUILTIN_OBJS) $(GITLIBS)
-	$(QUIET_LINK)$(CC) $(ALL_CFLAGS) -o $@ git.o \
-		$(BUILTIN_OBJS) $(ALL_LDFLAGS) $(LIBS)
+	$(QUIET_LINK)$(CC) -o $@ git.o $(BUILTIN_OBJS) $(ALL_LDFLAGS) $(LIBS)
 
 builtin-help.o: builtin-help.c common-cmds.h GIT-CFLAGS
 	$(QUIET_CC)$(CC) -o $*.o -c $(ALL_CFLAGS) \
@@ -1660,10 +1659,10 @@ http-walker.o: http-walker.c http.h GIT-CFLAGS
 endif
 
 git-%$X: %.o $(GITLIBS)
-	$(QUIET_LINK)$(CC) $(ALL_CFLAGS) -o $@ $(ALL_LDFLAGS) $(filter %.o,$^) $(LIBS)
+	$(QUIET_LINK)$(CC) -o $@ $(ALL_LDFLAGS) $(filter %.o,$^) $(LIBS)
 
 git-imap-send$X: imap-send.o $(GITLIBS)
-	$(QUIET_LINK)$(CC) $(ALL_CFLAGS) -o $@ $(ALL_LDFLAGS) $(filter %.o,$^) \
+	$(QUIET_LINK)$(CC) -o $@ $(ALL_LDFLAGS) $(filter %.o,$^) \
 		$(LIBS) $(OPENSSL_LINK) $(OPENSSL_LIBSSL)
 
 http.o http-walker.o http-push.o: http.h
@@ -1671,14 +1670,14 @@ http.o http-walker.o http-push.o: http.h
 http.o http-walker.o: $(LIB_H)
 
 git-http-fetch$X: revision.o http.o http-walker.o http-fetch.o $(GITLIBS)
-	$(QUIET_LINK)$(CC) $(ALL_CFLAGS) -o $@ $(ALL_LDFLAGS) $(filter %.o,$^) \
+	$(QUIET_LINK)$(CC) -o $@ $(ALL_LDFLAGS) $(filter %.o,$^) \
 		$(LIBS) $(CURL_LIBCURL)
 git-http-push$X: revision.o http.o http-push.o $(GITLIBS)
-	$(QUIET_LINK)$(CC) $(ALL_CFLAGS) -o $@ $(ALL_LDFLAGS) $(filter %.o,$^) \
+	$(QUIET_LINK)$(CC) -o $@ $(ALL_LDFLAGS) $(filter %.o,$^) \
 		$(LIBS) $(CURL_LIBCURL) $(EXPAT_LIBEXPAT)
 
 git-remote-curl$X: remote-curl.o http.o http-walker.o $(GITLIBS)
-	$(QUIET_LINK)$(CC) $(ALL_CFLAGS) -o $@ $(ALL_LDFLAGS) $(filter %.o,$^) \
+	$(QUIET_LINK)$(CC) -o $@ $(ALL_LDFLAGS) $(filter %.o,$^) \
 		$(LIBS) $(CURL_LIBCURL) $(EXPAT_LIBEXPAT)
 
 $(LIB_OBJS) $(BUILTIN_OBJS): $(LIB_H)
@@ -1798,7 +1797,7 @@ test-parse-options.o: parse-options.h
 .PRECIOUS: $(patsubst test-%$X,test-%.o,$(TEST_PROGRAMS))
 
 test-%$X: test-%.o $(GITLIBS)
-	$(QUIET_LINK)$(CC) $(ALL_CFLAGS) -o $@ $(ALL_LDFLAGS) $(filter %.o,$^) $(LIBS)
+	$(QUIET_LINK)$(CC) -o $@ $(ALL_LDFLAGS) $(filter %.o,$^) $(LIBS)
 
 check-sha1:: test-sha1$X
 	./test-sha1.sh
-- 
1.6.6

^ permalink raw reply related

* Re: [PATCH 0/4] clone: use --progress to mean -v
From: Tay Ray Chuan @ 2009-12-27  3:27 UTC (permalink / raw)
  To: Johannes Schindelin; +Cc: git, Miklos Vajna, Nicolas Pitre, Junio C Hamano
In-Reply-To: <alpine.DEB.1.00.0912260952020.4985@pacific.mpi-cbg.de>

Hi,

On Sat, Dec 26, 2009 at 4:53 PM, Johannes Schindelin
<Johannes.Schindelin@gmx.de> wrote:
> On Sat, 26 Dec 2009, Tay Ray Chuan wrote:
>
>> This series makes git-clone follow the "argument convention" of
>> git-pack-objects, where the option --progress is used to force reporting
>> of reporting. This was previously done with -v/--verbose.
>
> No objections from my side, although you might want to advertise more that
> this is a change in behavior.  (Meaning in the release notes)

Indeed, -v/--verbose to force reporting of progress was done sometime
last year (Thu Oct 9 2008) so there may be scripts/applications
dependent on this option.

Junio, do you have any advice on this front?

>> PS. If someone can enlighten me on the proper noun for the git
>>     executable (I said "main git"), I would be very thankful.
>
> I call it the "Git wrapper", although less polite words exist, too.

I see. Thanks!

-- 
Cheers,
Ray Chuan

^ permalink raw reply

* Re: [PATCH 4/4] clone: use --progress to force progress reporting
From: Tay Ray Chuan @ 2009-12-27  3:22 UTC (permalink / raw)
  To: Miklos Vajna; +Cc: git, Nicolas Pitre, Johannes Schindelin, Junio C Hamano
In-Reply-To: <20091227012032.GE25474@genesis.frugalware.org>

Hi,

On Sun, Dec 27, 2009 at 9:20 AM, Miklos Vajna <vmiklos@frugalware.org> wrote:
> On Sat, Dec 26, 2009 at 01:12:06AM +0800, Tay Ray Chuan <rctay89@gmail.com> wrote:
>> -v/--verbose now does not force progress reporting. Make git-clone.txt
>> say so.
>>
>> This should cover all the bases in 21188b1 (Implement git clone -v),
>> which implemented the option to force progress reporting.
>>
>> Signed-off-by: Tay Ray Chuan <rctay89@gmail.com>
>> ---
>>  Documentation/git-clone.txt |    3 +++
>>  builtin-clone.c             |    8 ++++++--
>>  t/t5702-clone-options.sh    |    3 ++-
>>  3 files changed, 11 insertions(+), 3 deletions(-)
>>
>> diff --git a/Documentation/git-clone.txt b/Documentation/git-clone.txt
>> index e722e6c..f43c8b2 100644
>> --- a/Documentation/git-clone.txt
>> +++ b/Documentation/git-clone.txt
>> @@ -102,6 +102,9 @@ objects from the source repository into a pack in the cloned repository.
>>
>>  --verbose::
>>  -v::
>> +     Run verbosely.
>
> What about mentioning this "does not force progress reporting" behaviour
> in documentation of the "new" -v option?

Ok.

-- 
Cheers,
Ray Chuan

^ permalink raw reply

* Re: [PATCH] Smart-http documentation: add example of how to execute  from userdir
From: Tay Ray Chuan @ 2009-12-27  3:19 UTC (permalink / raw)
  To: Tarmigan Casebolt; +Cc: Junio C Hamano, git, Shawn O. Pearce
In-Reply-To: <1261847255-13970-1-git-send-email-tarmigan+git@gmail.com>

Hi,

On Sun, Dec 27, 2009 at 1:07 AM, Tarmigan Casebolt
<tarmigan+git@gmail.com> wrote:
> @@ -60,8 +60,8 @@ automatically by the web server.
>
>  EXAMPLES
>  --------
> -All of the following examples map 'http://$hostname/git/foo/bar.git'
> -to '/var/www/git/foo/bar.git'.
> +Unless otherwise noted, the following examples map
> +'http://$hostname/git/foo/bar.git' to '/var/www/git/foo/bar.git'.

This rephrase seems to be unrelated (to providing an example of
serving smart http).

> @@ -144,6 +144,42 @@ ScriptAliasMatch \
>  ScriptAlias /git/ /var/www/cgi-bin/gitweb.cgi/
>  ----------------------------------------------------------------
>
> +In the following example, a repository at
> +'/home/$username/devel/foo/bar.git' will be accessible at
> +'http://$hostname/\~$username/cgi-bin/git/foo/bar.git'
> +
> +From UserDir on Apache 2.x::
> +       One way to configure 'git-http-backend' to execute and serve
> +       from a user directory (for example, on a shared hosting
> +       provider), is to have a symbolic link that points from the cgi
> +       directory to the 'git-http-backend' executable in libexec.  The
> +       advantage of the symblic link is that any updates to the

s/symblic/symbolic/.

> +       installed version of 'git-http-backend' also update the version

s/update/updates/.

> +       that is run in the userdir.  Depending on the configuration of
> +       the server, the symbolic link may be able to point to a global
> +       installation of git.  If, for security reasons, the server is

At this point, the user dealing with the "easy" case (ie. the user
just symlinks the shared git installation and doesn't have to create
symlinks in his own home directory) should have enough configuration
details without having to read any further. So, you could tell the
user about the symlinks to create and the configuration lines in
.htaccess.

It might also be a good idea to start a new paragraph for the "hard"
case, for better readability.

-- 
Cheers,
Ray Chuan

^ permalink raw reply

* Re: [PATCH 4/4] clone: use --progress to force progress reporting
From: Miklos Vajna @ 2009-12-27  1:20 UTC (permalink / raw)
  To: Tay Ray Chuan; +Cc: git, Nicolas Pitre, Johannes Schindelin, Junio C Hamano
In-Reply-To: <1261761126-5784-5-git-send-email-rctay89@gmail.com>

[-- Attachment #1: Type: text/plain, Size: 1006 bytes --]

On Sat, Dec 26, 2009 at 01:12:06AM +0800, Tay Ray Chuan <rctay89@gmail.com> wrote:
> -v/--verbose now does not force progress reporting. Make git-clone.txt
> say so.
> 
> This should cover all the bases in 21188b1 (Implement git clone -v),
> which implemented the option to force progress reporting.
> 
> Signed-off-by: Tay Ray Chuan <rctay89@gmail.com>
> ---
>  Documentation/git-clone.txt |    3 +++
>  builtin-clone.c             |    8 ++++++--
>  t/t5702-clone-options.sh    |    3 ++-
>  3 files changed, 11 insertions(+), 3 deletions(-)
> 
> diff --git a/Documentation/git-clone.txt b/Documentation/git-clone.txt
> index e722e6c..f43c8b2 100644
> --- a/Documentation/git-clone.txt
> +++ b/Documentation/git-clone.txt
> @@ -102,6 +102,9 @@ objects from the source repository into a pack in the cloned repository.
>  
>  --verbose::
>  -v::
> +	Run verbosely.

What about mentioning this "does not force progress reporting" behaviour
in documentation of the "new" -v option?

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

^ permalink raw reply

* [PATCH 2/2] Smart-http: check if repository is OK to export before serving it
From: Tarmigan Casebolt @ 2009-12-26 23:29 UTC (permalink / raw)
  To: Junio C Hamano; +Cc: spearce, git, rctay89, drizzd, warthog9, Tarmigan Casebolt
In-Reply-To: <1261870153-57572-1-git-send-email-tarmigan+git@gmail.com>

Similar to how git-daemon checks whether a repository is OK to be
exported, smart-http should also check.  This check can be satisfied
in two different ways: the environmental variable GIT_HTTP_EXPORT_ALL
may be set to export all repositories, or the individual repository
may have the file git-daemon-export-ok.

Signed-off-by: Tarmigan Casebolt <tarmigan+git@gmail.com>
---
 http-backend.c |    3 +++
 1 files changed, 3 insertions(+), 0 deletions(-)

diff --git a/http-backend.c b/http-backend.c
index f729488..345c12b 100644
--- a/http-backend.c
+++ b/http-backend.c
@@ -648,6 +648,9 @@ int main(int argc, char **argv)
 	setup_path();
 	if (!enter_repo(dir, 0))
 		not_found("Not a git repository: '%s'", dir);
+	if (!getenv("GIT_HTTP_EXPORT_ALL") &&
+	    access("git-daemon-export-ok", F_OK) )
+		not_found("Repository not exported: '%s'", dir);
 
 	git_config(http_config, NULL);
 	cmd->imp(cmd_arg);
-- 
1.6.6.2.g5daf2

^ permalink raw reply related

* [PATCH 1/2] Smart-http: Add tests and documentation for export-ok
From: Tarmigan Casebolt @ 2009-12-26 23:29 UTC (permalink / raw)
  To: Junio C Hamano; +Cc: spearce, git, rctay89, drizzd, warthog9, Tarmigan Casebolt
In-Reply-To: <7vk4w963np.fsf@alter.siamese.dyndns.org>

Add some tests for having smart-http check whether a repository is ok
to export.  Add tests for the GIT_HTTP_EXPORT_ALL environmental
variable and checking the git-daemon-export-ok file, while leaving
existing tests still functional.

Signed-off-by: Tarmigan Casebolt <tarmigan+git@gmail.com>
---
 Documentation/git-http-backend.txt |   10 +++++++++
 t/lib-httpd/apache.conf            |    5 ++++
 t/t5560-http-backend.sh            |   39 ++++++++++++++++++++++++++++++++++-
 3 files changed, 52 insertions(+), 2 deletions(-)

diff --git a/Documentation/git-http-backend.txt b/Documentation/git-http-backend.txt
index 67aec06..c8fe08a 100644
--- a/Documentation/git-http-backend.txt
+++ b/Documentation/git-http-backend.txt
@@ -18,6 +18,11 @@ The program supports clients fetching using both the smart HTTP protcol
 and the backwards-compatible dumb HTTP protocol, as well as clients
 pushing using the smart HTTP protocol.
 
+It verifies that the directory has the magic file
+"git-daemon-export-ok", and it will refuse to export any git directory
+that hasn't explicitly been marked for export this way (unless the
+GIT_HTTP_EXPORT_ALL environmental variable is set).
+
 By default, only the `upload-pack` service is enabled, which serves
 'git-fetch-pack' and 'git-ls-remote' clients, which are invoked from
 'git-fetch', 'git-pull', and 'git-clone'.  If the client is authenticated,
@@ -70,6 +75,7 @@ Apache 2.x::
 +
 ----------------------------------------------------------------
 SetEnv GIT_PROJECT_ROOT /var/www/git
+SetEnv GIT_HTTP_EXPORT_ALL
 ScriptAlias /git/ /usr/libexec/git-core/git-http-backend/
 ----------------------------------------------------------------
 +
@@ -157,6 +163,10 @@ by the invoking web server, including:
 * QUERY_STRING
 * REQUEST_METHOD
 
+The GIT_HTTP_EXPORT_ALL environmental variable may be passed to
+'git-http-backend' to bypass the check for the "git-daemon-export-ok"
+file in each repository before allowing export of that repository.
+
 The backend process sets GIT_COMMITTER_NAME to '$REMOTE_USER' and
 GIT_COMMITTER_EMAIL to '$\{REMOTE_USER}@http.$\{REMOTE_ADDR\}',
 ensuring that any reflogs created by 'git-receive-pack' contain some
diff --git a/t/lib-httpd/apache.conf b/t/lib-httpd/apache.conf
index 0fe3fd0..4961505 100644
--- a/t/lib-httpd/apache.conf
+++ b/t/lib-httpd/apache.conf
@@ -22,8 +22,13 @@ Alias /dumb/ www/
 
 <Location /smart/>
 	SetEnv GIT_EXEC_PATH ${GIT_EXEC_PATH}
+	SetEnv GIT_HTTP_EXPORT_ALL
+</Location>
+<Location /smart_noexport/>
+	SetEnv GIT_EXEC_PATH ${GIT_EXEC_PATH}
 </Location>
 ScriptAlias /smart/ ${GIT_EXEC_PATH}/git-http-backend/
+ScriptAlias /smart_noexport/ ${GIT_EXEC_PATH}/git-http-backend/
 <Directory ${GIT_EXEC_PATH}>
 	Options None
 </Directory>
diff --git a/t/t5560-http-backend.sh b/t/t5560-http-backend.sh
index ed034bc..f763880 100755
--- a/t/t5560-http-backend.sh
+++ b/t/t5560-http-backend.sh
@@ -23,7 +23,7 @@ config() {
 }
 
 GET() {
-	curl --include "$HTTPD_URL/smart/repo.git/$1" >out 2>/dev/null &&
+	curl --include "$HTTPD_URL/$SMART/repo.git/$1" >out 2>/dev/null &&
 	tr '\015' Q <out |
 	sed '
 		s/Q$//
@@ -91,6 +91,20 @@ get_static_files() {
 	GET $IDX_URL "$1"
 }
 
+SMART=smart_noexport
+test_expect_success 'no export by default' '
+	log_div "no git-daemon-export-ok"
+	get_static_files "404 Not Found"
+'
+test_expect_success 'export if git-daemon-export-ok' '
+	log_div "git-daemon-export-ok"
+        (cd "$HTTPD_DOCUMENT_ROOT_PATH/repo.git" &&
+	 touch git-daemon-export-ok
+	) &&
+        get_static_files "200 OK"
+'
+
+SMART=smart
 test_expect_success 'direct refs/heads/master not found' '
 	log_div "refs/heads/master"
 	GET refs/heads/master "404 Not Found"
@@ -145,7 +159,6 @@ test_expect_success 'http.receivepack false' '
 	GET info/refs?service=git-receive-pack "403 Forbidden" &&
 	POST git-receive-pack 0000 "403 Forbidden"
 '
-
 run_backend() {
 	REQUEST_METHOD=GET \
 	GIT_PROJECT_ROOT="$HTTPD_DOCUMENT_ROOT_PATH" \
@@ -179,6 +192,28 @@ test_expect_success 'http-backend blocks bad PATH_INFO' '
 
 cat >exp <<EOF
 
+###  no git-daemon-export-ok
+###
+GET  /smart_noexport/repo.git/HEAD HTTP/1.1 404 -
+GET  /smart_noexport/repo.git/info/refs HTTP/1.1 404 -
+GET  /smart_noexport/repo.git/objects/info/packs HTTP/1.1 404 -
+GET  /smart_noexport/repo.git/objects/info/alternates HTTP/1.1 404 -
+GET  /smart_noexport/repo.git/objects/info/http-alternates HTTP/1.1 404 -
+GET  /smart_noexport/repo.git/$LOOSE_URL HTTP/1.1 404 -
+GET  /smart_noexport/repo.git/$PACK_URL HTTP/1.1 404 -
+GET  /smart_noexport/repo.git/$IDX_URL HTTP/1.1 404 -
+
+###  git-daemon-export-ok
+###
+GET  /smart_noexport/repo.git/HEAD HTTP/1.1 200
+GET  /smart_noexport/repo.git/info/refs HTTP/1.1 200
+GET  /smart_noexport/repo.git/objects/info/packs HTTP/1.1 200
+GET  /smart_noexport/repo.git/objects/info/alternates HTTP/1.1 200 -
+GET  /smart_noexport/repo.git/objects/info/http-alternates HTTP/1.1 200 -
+GET  /smart_noexport/repo.git/$LOOSE_URL HTTP/1.1 200
+GET  /smart_noexport/repo.git/$PACK_URL HTTP/1.1 200
+GET  /smart_noexport/repo.git/$IDX_URL HTTP/1.1 200
+
 ###  refs/heads/master
 ###
 GET  /smart/repo.git/refs/heads/master HTTP/1.1 404 -
-- 
1.6.6.2.g5daf2

^ permalink raw reply related

* [PATCH] t1200: work around a bug in some implementations of "find"
From: Junio C Hamano @ 2009-12-26 21:53 UTC (permalink / raw)
  To: git

"find path ..." command should exit with zero status only when all path
operands were traversed successfully.  When a non-existent path is given,
however, some implementations of "find" (e.g. OpenBSD 4.6) exit with zero
status and break the last test in t1200.

Rewrite the test to check that there is no regular files in the objects
fan-out directories to work around this bug; it is closer to what we are
testing anyway.

Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
 t/t1200-tutorial.sh |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/t/t1200-tutorial.sh b/t/t1200-tutorial.sh
index 238c2f1..ab55eda 100755
--- a/t/t1200-tutorial.sh
+++ b/t/t1200-tutorial.sh
@@ -259,7 +259,7 @@ test_expect_success 'git repack' 'git repack'
 test_expect_success 'git prune-packed' 'git prune-packed'
 test_expect_success '-> only packed objects' '
 	git prune && # Remove conflict marked blobs
-	! find .git/objects/[0-9a-f][0-9a-f] -type f
+	test $(find .git/objects/[0-9a-f][0-9a-f] -type f -print 2>/dev/null | wc -l) = 0
 '
 
 test_done

^ permalink raw reply related

* [PATCH] t4019 "grep" portability fix
From: Junio C Hamano @ 2009-12-26 21:53 UTC (permalink / raw)
  To: git

Input to "grep" is supposed to be "text", but we deliberately feed output
from "git diff --color" to sift it into two sets of lines (ones with
errors, the other without).  Some implementations of "grep" only report
matches with the exit status, without showing the matched lines in their
output (e.g. OpenBSD 4.6, which says "Binary file .. matches").

Fortunately, "grep -a" is often a way to force the command to treat its
input as text.

Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
 t/t4019-diff-wserror.sh |   56 +++++++++++++++++++++++-----------------------
 1 files changed, 28 insertions(+), 28 deletions(-)

diff --git a/t/t4019-diff-wserror.sh b/t/t4019-diff-wserror.sh
index 3a3663f..f6d1f1e 100755
--- a/t/t4019-diff-wserror.sh
+++ b/t/t4019-diff-wserror.sh
@@ -20,11 +20,27 @@ test_expect_success setup '
 
 blue_grep='7;34m' ;# ESC [ 7 ; 3 4 m
 
+printf "\033[%s" "$blue_grep" >check-grep
+if (grep "$blue_grep" <check-grep | grep "$blue_grep") >/dev/null 2>&1
+then
+	grep_a=grep
+elif (grep -a "$blue_grep" <check-grep | grep -a "$blue_grep") >/dev/null 2>&1
+then
+	grep_a='grep -a'
+else
+	grep_a=grep ;# expected to fail...
+fi
+rm -f check-grep
+
+prepare_output () {
+	git diff --color >output
+	$grep_a "$blue_grep" output >error
+	$grep_a -v "$blue_grep" output >normal
+}
+
 test_expect_success default '
 
-	git diff --color >output
-	grep "$blue_grep" output >error
-	grep -v "$blue_grep" output >normal
+	prepare_output
 
 	grep Eight normal >/dev/null &&
 	grep HT error >/dev/null &&
@@ -37,9 +53,7 @@ test_expect_success default '
 test_expect_success 'without -trail' '
 
 	git config core.whitespace -trail
-	git diff --color >output
-	grep "$blue_grep" output >error
-	grep -v "$blue_grep" output >normal
+	prepare_output
 
 	grep Eight normal >/dev/null &&
 	grep HT error >/dev/null &&
@@ -53,9 +67,7 @@ test_expect_success 'without -trail (attribute)' '
 
 	git config --unset core.whitespace
 	echo "F whitespace=-trail" >.gitattributes
-	git diff --color >output
-	grep "$blue_grep" output >error
-	grep -v "$blue_grep" output >normal
+	prepare_output
 
 	grep Eight normal >/dev/null &&
 	grep HT error >/dev/null &&
@@ -69,9 +81,7 @@ test_expect_success 'without -space' '
 
 	rm -f .gitattributes
 	git config core.whitespace -space
-	git diff --color >output
-	grep "$blue_grep" output >error
-	grep -v "$blue_grep" output >normal
+	prepare_output
 
 	grep Eight normal >/dev/null &&
 	grep HT normal >/dev/null &&
@@ -85,9 +95,7 @@ test_expect_success 'without -space (attribute)' '
 
 	git config --unset core.whitespace
 	echo "F whitespace=-space" >.gitattributes
-	git diff --color >output
-	grep "$blue_grep" output >error
-	grep -v "$blue_grep" output >normal
+	prepare_output
 
 	grep Eight normal >/dev/null &&
 	grep HT normal >/dev/null &&
@@ -101,9 +109,7 @@ test_expect_success 'with indent-non-tab only' '
 
 	rm -f .gitattributes
 	git config core.whitespace indent,-trailing,-space
-	git diff --color >output
-	grep "$blue_grep" output >error
-	grep -v "$blue_grep" output >normal
+	prepare_output
 
 	grep Eight error >/dev/null &&
 	grep HT normal >/dev/null &&
@@ -117,9 +123,7 @@ test_expect_success 'with indent-non-tab only (attribute)' '
 
 	git config --unset core.whitespace
 	echo "F whitespace=indent,-trailing,-space" >.gitattributes
-	git diff --color >output
-	grep "$blue_grep" output >error
-	grep -v "$blue_grep" output >normal
+	prepare_output
 
 	grep Eight error >/dev/null &&
 	grep HT normal >/dev/null &&
@@ -133,9 +137,7 @@ test_expect_success 'with cr-at-eol' '
 
 	rm -f .gitattributes
 	git config core.whitespace cr-at-eol
-	git diff --color >output
-	grep "$blue_grep" output >error
-	grep -v "$blue_grep" output >normal
+	prepare_output
 
 	grep Eight normal >/dev/null &&
 	grep HT error >/dev/null &&
@@ -149,9 +151,7 @@ test_expect_success 'with cr-at-eol (attribute)' '
 
 	git config --unset core.whitespace
 	echo "F whitespace=trailing,cr-at-eol" >.gitattributes
-	git diff --color >output
-	grep "$blue_grep" output >error
-	grep -v "$blue_grep" output >normal
+	prepare_output
 
 	grep Eight normal >/dev/null &&
 	grep HT error >/dev/null &&
@@ -195,7 +195,7 @@ test_expect_success 'color new trailing blank lines' '
 	git add x &&
 	{ echo a; echo; echo; echo; echo c; echo; echo; echo; echo; } >x &&
 	git diff --color x >output &&
-	cnt=$(grep "${blue_grep}" output | wc -l) &&
+	cnt=$($grep_a "${blue_grep}" output | wc -l) &&
 	test $cnt = 2
 '
 

^ permalink raw reply related

* Re: Does smart-http need git-daemon-export-ok?
From: Junio C Hamano @ 2009-12-26 17:33 UTC (permalink / raw)
  To: Tarmigan
  Cc: Shawn O. Pearce, Git Mailing List, Tay Ray Chuan,
	Clemens Buchacher, J.H.
In-Reply-To: <905315640912260821k2fb149b3je69dbea5463afaa3@mail.gmail.com>

Tarmigan <tarmigan+git@gmail.com> writes:

> Should the git-http-backend check something like git-daemon-export-ok
> before serving a repository?

I'd agree that it would make sense to have a way to mark individual
repository for (or not for) export.

In "native" case, the chain of events are: client talks to the daemon, the
daemon checks and decides to (or not to) export, and it runs upload-pack.

In "smart http" case, http-backend is one half of what corresponds to the
daemon (the other half being your http server configuration), and it is
more flexible and git specific half, so I'd say it would make sense to
implement the check that honors the same git-daemon-export-ok flag file in
it.

^ permalink raw reply

* [PATCH] Smart-http documentation: add example of how to execute from userdir
From: Tarmigan Casebolt @ 2009-12-26 17:07 UTC (permalink / raw)
  To: Junio C Hamano; +Cc: git, Tarmigan Casebolt, Shawn O. Pearce

Smart-http may be an attactive and easy way for people to setup git
hosting on shared servers whose primary web server configuration they
do not control.  To facilite this, provide an example of how it may be
done.

cc: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Tarmigan Casebolt <tarmigan+git@gmail.com>
---
 Documentation/git-http-backend.txt |   40 ++++++++++++++++++++++++++++++++++-
 1 files changed, 38 insertions(+), 2 deletions(-)

diff --git a/Documentation/git-http-backend.txt b/Documentation/git-http-backend.txt
index 67aec06..0cca5ba 100644
--- a/Documentation/git-http-backend.txt
+++ b/Documentation/git-http-backend.txt
@@ -60,8 +60,8 @@ automatically by the web server.
 
 EXAMPLES
 --------
-All of the following examples map 'http://$hostname/git/foo/bar.git'
-to '/var/www/git/foo/bar.git'.
+Unless otherwise noted, the following examples map
+'http://$hostname/git/foo/bar.git' to '/var/www/git/foo/bar.git'.
 
 Apache 2.x::
 	Ensure mod_cgi, mod_alias, and mod_env are enabled, set
@@ -144,6 +144,42 @@ ScriptAliasMatch \
 ScriptAlias /git/ /var/www/cgi-bin/gitweb.cgi/
 ----------------------------------------------------------------
 
+In the following example, a repository at
+'/home/$username/devel/foo/bar.git' will be accessible at
+'http://$hostname/\~$username/cgi-bin/git/foo/bar.git'
+
+From UserDir on Apache 2.x::
+       One way to configure 'git-http-backend' to execute and serve
+       from a user directory (for example, on a shared hosting
+       provider), is to have a symbolic link that points from the cgi
+       directory to the 'git-http-backend' executable in libexec.  The
+       advantage of the symblic link is that any updates to the
+       installed version of 'git-http-backend' also update the version
+       that is run in the userdir.  Depending on the configuration of
+       the server, the symbolic link may be able to point to a global
+       installation of git.  If, for security reasons, the server is
+       configured to follow symbolic links only if the owner matches,
+       an installation of git into the user directory may be required.
+       In that case, install git as that user into \~/bin, \~/libexec
+       etc.  Then create a symlink named 'git' in the cgi-bin
+       directory that points to
+       \~/libexec/git-core/git-http-backend. Put the following in
+       \~/public_html/cgi-bin/.htaccess:
++
+----------------------------------------------------------------
+SetHandler cgi-script
+Options +SymLinksIfOwnerMatch
+SetEnv GIT_PROJECT_ROOT /home/$username/devel
+----------------------------------------------------------------
++
+Also add any needed authentication to the .htaccess file as discussed
+in earlier examples.
++
+If the web server does not follow any symbolic links, the
+'git-http-backend' executable may be copied into the cgi-bin directory
+and renamed to 'git' to acheive the same effect, but it will also need
+to be manually updated whenever a new version of 'git-http-backend' is
+installed.
 
 ENVIRONMENT
 -----------
-- 
1.6.6

^ permalink raw reply related

* [PATCH] Add git-http-backend to command-list.
From: Tarmigan Casebolt @ 2009-12-26 17:01 UTC (permalink / raw)
  To: Junio C Hamano; +Cc: git, Tarmigan Casebolt

Signed-off-by: Tarmigan Casebolt <tarmigan+git@gmail.com>
---
 command-list.txt |    1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/command-list.txt b/command-list.txt
index cc5d48b..95bf18c 100644
--- a/command-list.txt
+++ b/command-list.txt
@@ -49,6 +49,7 @@ git-grep                                mainporcelain common
 git-gui                                 mainporcelain
 git-hash-object                         plumbingmanipulators
 git-help				ancillaryinterrogators
+git-http-backend                        synchingrepositories
 git-http-fetch                          synchelpers
 git-http-push                           synchelpers
 git-imap-send                           foreignscminterface
-- 
1.6.6

^ permalink raw reply related

* Does smart-http need git-daemon-export-ok?
From: Tarmigan @ 2009-12-26 16:21 UTC (permalink / raw)
  To: Shawn O. Pearce; +Cc: Git Mailing List, Tay Ray Chuan, Clemens Buchacher, J.H.

Hi all,

Should the git-http-backend check something like git-daemon-export-ok
before serving a repository?  It would have been better to discuss
this a month or two ago, but it's probably not too late since
smart-http is still so new in released versions.

I think it's very similar to git-daemon which requires that to be set,
and I think the same arguments could be made for the same kind of
check.  There are already parallels for the upload-pack and
receive-pack services between the two.

Just as git-daemon may be invoked with --export-all, for
git-http-backend we could have an environmental variable to export all
repositories.

Thoughts?

Thanks,
Tarmigan

^ permalink raw reply

* Re: Set the repository as it was on an earlier commit
From: Matthieu Moy @ 2009-12-26 14:28 UTC (permalink / raw)
  To: Santi Béjar; +Cc: Sergio Belkin, git
In-Reply-To: <adf1fd3d0912251536kbf25272ob0ab8ee90e53861d@mail.gmail.com>

Santi Béjar <santi@agolina.net> writes:

> I don't know if it is possible with porcelain commands, but with
> plumbing you can:
>
> # begin with a clean working dir
> git read-tree B
> git commit
> git reset --hard

I guess

(at the root of the repo)

git checkout B -- .
# git status if you want to check.
git commit

does this. The "-- ." part of "git checkout" asks Git to checkout the
files, but the path limiter prevents it from updating HEAD, so the
HEAD still points to the tip of the branch.

-- 
Matthieu Moy
http://www-verimag.imag.fr/~moy/

^ permalink raw reply

* [PATCH/RFC] FreeBSD iconv function signature is "old"
From: Junio C Hamano @ 2009-12-26  9:09 UTC (permalink / raw)
  To: git
In-Reply-To: <7v7hxysie9.fsf@alter.siamese.dyndns.org>

Junio C Hamano <gitster@pobox.com> writes:

> I noticed that my build on FreeBSD-7.2-RELEASE-i386 fails without
> OLD_ICONV=YesPlease.
>
> Is it just me and my installation (i.e. I might have failed to install
> saner iconv from the port that everybody uses), or is everybody who runs
> on FreeBSD using this option himself because our Makefile doesn't do that
> automatically for them?
>
> Just in case it is the latter, here is a proposed patch.

By the way, FreeBSD-8.0-RELEASE-i386 has the same issue.  I'll queue it to
'maint' unless anybody objects...

>  Makefile |    1 +
>  1 files changed, 1 insertions(+), 0 deletions(-)
>
> diff --git a/Makefile b/Makefile
> index bde27ed..9a25c08 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -777,6 +777,7 @@ ifeq ($(uname_O),Cygwin)
>  endif
>  ifeq ($(uname_S),FreeBSD)
>  	NEEDS_LIBICONV = YesPlease
> +	OLD_ICONV = YesPlease
>  	NO_MEMMEM = YesPlease
>  	BASIC_CFLAGS += -I/usr/local/include
>  	BASIC_LDFLAGS += -L/usr/local/lib

^ permalink raw reply

* Re: [PATCH 0/4] clone: use --progress to mean -v
From: Johannes Schindelin @ 2009-12-26  8:53 UTC (permalink / raw)
  To: Tay Ray Chuan; +Cc: git, Miklos Vajna, Nicolas Pitre, Junio C Hamano
In-Reply-To: <1261761126-5784-1-git-send-email-rctay89@gmail.com>

Hi,

On Sat, 26 Dec 2009, Tay Ray Chuan wrote:

> This series makes git-clone follow the "argument convention" of 
> git-pack-objects, where the option --progress is used to force reporting 
> of reporting. This was previously done with -v/--verbose.

No objections from my side, although you might want to advertise more that 
this is a change in behavior.  (Meaning in the release notes)

> PS. If someone can enlighten me on the proper noun for the git
>     executable (I said "main git"), I would be very thankful.

I call it the "Git wrapper", although less polite words exist, too.

Ciao,
Dscho

^ permalink raw reply

* Re: Branch shuffling after 1.6.6 release plans
From: Jeff King @ 2009-12-26  8:01 UTC (permalink / raw)
  To: Thomas Rast; +Cc: Junio C Hamano, git
In-Reply-To: <200912251230.48243.trast@student.ethz.ch>

On Fri, Dec 25, 2009 at 12:30:34PM +0100, Thomas Rast wrote:

> >      * tr/reset-checkout-patch (2009-11-19) 1 commit
> >       - {checkout,reset} -p: make patch direction configurable
> > 
> >      I do not particularly like a configuration like this that changes the
> >      behaviour of a command in a drastic way---it will make helping others
> >      much harder.
> 
> I think it's not quite as drastic as you make it sound ;-)
> 
> But I don't need this feature, and Peff mentioned something about
> being happy except for the patch editing mode.  Unfortunately the
> above pretty much hits the limits of add--interactive's flexibility,
> so an interactive direction toggling feature would need some rewiring.

Let's drop it for now. I'm reasonably happy, and I don't want to waste
your time trying to do something more invasive. And I haven't seen any
evidence that anybody else is dissatisfied with what's in master.

-Peff

^ permalink raw reply


This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox