* Re: [1.8.0] Change branch --set-uptream to take an argument
From: Jay Soffian @ 2011-02-01 21:14 UTC (permalink / raw)
To: Matthieu Moy; +Cc: Junio C Hamano, git
In-Reply-To: <vpqzkqg5dsq.fsf@bauges.imag.fr>
On Tue, Feb 1, 2011 at 4:01 AM, Matthieu Moy
<Matthieu.Moy@grenoble-inp.fr> wrote:
> Jay Soffian <jaysoffian@gmail.com> writes:
>
>> Currently it is very easy to misinvoke --set-upstream if you assume it
>> takes an argument:
>
> Your proposal sounds interesting, but I'd like to see something more
> global: right now, some commands take a --track option and other take
> a --set-upstream. In short, I'd like to see this --track deprecated
> (since it's not actually about remote-tracking ...).
There are a few things at work here. --track/--no-track are used to
override the branch.autosetupmerge configuration and are supported by
checkout and branch. --set-upstream is only supported by branch, and
is subtly different from --track.
There is also branch.autosetuprebase, for which there is no
command-line option to override.
These options/configs control how branch.<name>.{merge,remote,rebase}
are set. --track/--no-track only take effect when the branch is
created. --set-upstream can be used when the branch is created, or
after the fact.
(Aside, the names of the config params are starting to look
sub-optimal, but it's probably not worth the pain of changing them.)
I suppose a more comprehensive proposal looks like this:
1. Deprecate --track and --no-track (remove from documentation and
usage). I wonder if anyone ever uses them?
2. Deprecate --set-upstream as its usage is confusing.
3. Add -u <name> to both checkout and branch to specify the upstream
branch. It is used with checkout -b in cases where an upstream would
not normally be configured, either because it's not the default
according to branch.autosetupmerge or because the start-point is not a
branch. It is used with branch when creating a branch in a similar
manner to how it's used with checkout when creating a branch, but may
also be used to reset the upstream after the fact like so:
$ git branch -u <upstream> [<branch>]
4. Add --pull-default={rebase,merge} to both checkout and branch used
for setting/unsetting branch.<name>.rebase during initial branch
creation, or after the fact in the case of git-branch. It is an error
to try to set --pull-default if the upstream is not configured, either
automatically or via -u.
>> (Though I'm not sure whether the options parser allows for both
>> --set-upstream and --set-upstream=<arg>)
>
> There are already many instances of this. When <arg> is mandatory, you
> can write either --option <arg> or --option=<arg> (like "git log
> --grep pattern" Vs "git log --grep=pattern"), and when <arg> is
> optional, you can write either --option alone, or --option=<arg> (like
> "git diff --color-words" and "git diff --color-words=.").
Sorry. What I meant was that you'd need the ability to differentiate
between "--set-upstream=foo" and "--set-upstream foo" due to
git-branch's existing semantics. Right now:
$ git branch --set-upstream topic origin/master
Creates topic from origin/master and sets topic's upstream to
origin/master. If --set-upstream suddenly starts taking an argument,
that means something completely different: create a new branch named
origin/master starting at HEAD and set its upstream to "topic".
I think we're better off just deprecating --set-upstream and
introducing the more convenient -u.
j.
^ permalink raw reply
* Re: [1.8.0] make two-argument fetch update remote branches
From: A Large Angry SCM @ 2011-02-01 21:05 UTC (permalink / raw)
To: Thomas Rast; +Cc: Junio C Hamano, git
In-Reply-To: <201101312244.10047.trast@student.ethz.ch>
On 01/31/2011 04:44 PM, Thomas Rast wrote:
> Proposal:
>
> Running "git fetch origin master" only updates FETCH_HEAD, not
> origin/master, which turns out to be quite confusing for newcomers
> especially after running 'git pull origin master'.
>
> Since the remote branches in some sense reflect the "last known state"
> of the remote, it would make sense to also update them to whatever a
> two-argument fetch got.
>
If this is proposing to break:
get-fetch ${REPO} ${SRC_REF}:${DST_REF}
then I am against this since that form _is_ used and *is* plumbing.
^ permalink raw reply
* Re: [1.8.0] forbid full fetchspecs in git-pull
From: Dmitry Potapov @ 2011-02-01 20:23 UTC (permalink / raw)
To: Thomas Rast; +Cc: Junio C Hamano, git, Sean Estabrooks, Björn Steinbrink
In-Reply-To: <201102011614.57366.trast@student.ethz.ch>
On Tue, Feb 01, 2011 at 04:14:57PM +0100, Thomas Rast wrote:
> Dmitry Potapov wrote:
> > As to disallowing ':' in refspec completely, I am not so sure... Not
> > that I think it is very useful, but also I don't see how it can hurt
> > someone provided that the target branch cannot be the current branch.
>_
> IRC experience shows that people, while on some topic branch, run
>_
> git pull origin master:master
>_
> expecting it to "pull master into master" (or even worse with three
> different branch names). So no, the current branch safeguard does
> not prevent the fundamental mistake.
I am not sure what you mean by three different branches names. You
referred to item 1, and I agree it is confusing, but it can be prevented
by the current branch safeguard.
and the current semantic of "git pull" is very clear:
"git pull repo refspec" = "git fetch repo refspec && git merge FETCH_HEAD"
IMHO, the full confusion was caused by incorrect information on github,
which was corrected a long time ago. Have you heard about any new
users who are confused by git-pull?
And if we really want to disallow ':' in git pull refspec then the
documentation should be corrected too. For instance, if there are
options to git fetch that make no sense if you cannot specify lbranch.
Also description of refspec should be corrected in git pull man page.
Dmitry
^ permalink raw reply
* Re: Features from GitSurvey 2010
From: Matthieu Moy @ 2011-02-01 20:23 UTC (permalink / raw)
To: Jonathan Nieder; +Cc: Dmitry S. Kravtsov, git, Jakub Narebski
In-Reply-To: <20110201184213.GF3771@burratino>
Jonathan Nieder <jrnieder@gmail.com> writes:
> An rcs-style workflow (lockable files absent from worktree until
> locked) on top of git sounds fun.
They need not be absent, they can just be read-only (and lock would do
a chmod u+w on the file).
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
^ permalink raw reply
* Re: [1.8.0] reorganize the mess that the source tree has become
From: Jonathan Nieder @ 2011-02-01 11:22 UTC (permalink / raw)
To: Thomas Rast; +Cc: Nicolas Pitre, Jeff King, Junio C Hamano, git
In-Reply-To: <20110201111429.GA10165@elie>
Jonathan Nieder wrote:
> mkdir output
> cd output
> echo COMPUTE_HEADER_DIRECTORIES=1 >config.mak
> make -f ../Makefile GIT_SRC=$(pwd)/../ -j2
Erm, COMPUTE_HEADER_DEPENDENCIES. Anyway, if someone wants to make
setting GIT_SRC take care of making the directories automatically, I
wouldn't mind. ;-)
^ permalink raw reply
* Re: [1.8.0] reorganize the mess that the source tree has become
From: Jonathan Nieder @ 2011-02-01 11:14 UTC (permalink / raw)
To: Thomas Rast; +Cc: Nicolas Pitre, Jeff King, Junio C Hamano, git
In-Reply-To: <201102011342.06910.trast@student.ethz.ch>
Thomas Rast wrote:
> In particular a prospective git hacker would not care whether
> something is a source file or a script (you seem to imply the
> opposite). He would instead expect to find git-foo implemented in
> something named of that sort, so we could probably help him by mapping
>
> git-foo.sh -> git-foo.sh
> builtin/bar.c -> git-bar.c
> baz.c -> lib/baz.c
I agree. This sets off my "time to resist change" alarms much
less than "git mv *.c *.sh src/", for what it's worth.
> baz.o -> build/baz.o (or whatever, just elsewhere)
> baz.gcov -> build/baz.gcov (ditto)
Maybe something like this to start?
-- 8< --
Subject: Makefile: basic support for separate build dir
- python and perl machinery haven't been tweaked yet
- requires good VPATH support
- relies on COMPUTE_HEADER_DIRECTORIES to make the object file
directories
- does not support paths with spaces
Usage:
mkdir output
cd output
echo COMPUTE_HEADER_DIRECTORIES=1 >config.mak
make -f ../Makefile GIT_SRC=$(pwd)/../ -j2
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
---
Makefile | 41 ++++++++++++++++++++++++++---------------
generate-cmdlist.sh | 4 ++--
perl/Makefile | 2 +-
3 files changed, 29 insertions(+), 18 deletions(-)
diff --git a/Makefile b/Makefile
index 775ee83..b258a24 100644
--- a/Makefile
+++ b/Makefile
@@ -243,8 +243,18 @@ all::
#
# Define NATIVE_CRLF if your platform uses CRLF for line endings.
+# Absolute path to the toplevel of the git sources, with trailing /.
+# Leave empty for an in-place build.
+GIT_SRC =
+ifdef GIT_SRC
+ NO_PYTHON = YesPlease
+ NO_PERL_MAKEMAKER = YesPlease
+endif
+
+VPATH := $(if $(GIT_SRC),$(GIT_SRC),$(CURDIR))
+
GIT-VERSION-FILE: FORCE
- @$(SHELL_PATH) ./GIT-VERSION-GEN
+ @$(SHELL_PATH) $(GIT_SRC)/GIT-VERSION-GEN
-include GIT-VERSION-FILE
uname_S := $(shell sh -c 'uname -s 2>/dev/null || echo not')
@@ -305,6 +315,7 @@ lib = lib
pathsep = :
export prefix bindir sharedir sysconfdir gitwebdir
+export GIT_SRC
CC = gcc
AR = ar
@@ -333,7 +344,7 @@ SPARSE_FLAGS = -D__BIG_ENDIAN__ -D__powerpc__
# Those must not be GNU-specific; they are shared with perl/ which may
# be built by a different compiler. (Note that this is an artifact now
# but it still might be nice to keep that distinction.)
-BASIC_CFLAGS = -I.
+BASIC_CFLAGS = -I$(GIT_SRC). -I.
BASIC_LDFLAGS =
# Guard against environment variables
@@ -1562,7 +1573,7 @@ ifeq ($(PYTHON_PATH),)
NO_PYTHON=NoThanks
endif
-QUIET_SUBDIR0 = +$(MAKE) -C # space to separate -C and subdir
+QUIET_SUBDIR0 = +$(MAKE) -C $(GIT_SRC)# no space before subdir
QUIET_SUBDIR1 =
ifneq ($(findstring $(MAKEFLAGS),w),w)
@@ -1582,7 +1593,7 @@ ifndef V
QUIET_GCOV = @echo ' ' GCOV $@;
QUIET_SUBDIR0 = +@subdir=
QUIET_SUBDIR1 = ;$(NO_SUBDIR) echo ' ' SUBDIR $$subdir; \
- $(MAKE) $(PRINT_DIR) -C $$subdir
+ $(MAKE) $(PRINT_DIR) -C $(GIT_SRC)$$subdir
export V
export QUIET_GEN
export QUIET_BUILT_IN
@@ -1696,10 +1707,10 @@ $(BUILT_INS): git$X
ln -s git$X $@ 2>/dev/null || \
cp git$X $@
-common-cmds.h: ./generate-cmdlist.sh command-list.txt
+common-cmds.h: generate-cmdlist.sh command-list.txt
common-cmds.h: $(wildcard Documentation/git-*.txt)
- $(QUIET_GEN)./generate-cmdlist.sh > $@+ && mv $@+ $@
+ $(QUIET_GEN)$(GIT_SRC)./generate-cmdlist.sh > $@+ && mv $@+ $@
define cmd_munge_script
$(RM) $@ $@+ && \
@@ -1709,7 +1720,7 @@ sed -e '1s|#!.*/sh|#!$(SHELL_PATH_SQ)|' \
-e 's/@@GIT_VERSION@@/$(GIT_VERSION)/g' \
-e 's/@@NO_CURL@@/$(NO_CURL)/g' \
-e $(BROKEN_PATH_FIX) \
- $@.sh >$@+
+ $(GIT_SRC)$@.sh >$@+
endef
$(patsubst %.sh,%,$(SCRIPT_SH)) : % : %.sh
@@ -1729,7 +1740,7 @@ perl/perl.mak: GIT-CFLAGS perl/Makefile perl/Makefile.PL
$(patsubst %.perl,%,$(SCRIPT_PERL)): % : %.perl
$(QUIET_GEN)$(RM) $@ $@+ && \
- INSTLIBDIR=`MAKEFLAGS= $(MAKE) -C perl -s --no-print-directory instlibdir` && \
+ INSTLIBDIR=`MAKEFLAGS= $(MAKE) -C $(GIT_SRC)perl -s --no-print-directory instlibdir` && \
sed -e '1{' \
-e ' s|#!.*perl|#!$(PERL_PATH_SQ)|' \
-e ' h' \
@@ -1738,7 +1749,7 @@ $(patsubst %.perl,%,$(SCRIPT_PERL)): % : %.perl
-e ' x' \
-e '}' \
-e 's/@@GIT_VERSION@@/$(GIT_VERSION)/g' \
- $@.perl >$@+ && \
+ $(GIT_SRC)$@.perl >$@+ && \
chmod +x $@+ && \
mv $@+ $@
@@ -1780,7 +1791,7 @@ git-instaweb: git-instaweb.sh gitweb/gitweb.cgi gitweb/static/gitweb.css gitweb/
-e 's/@@NO_CURL@@/$(NO_CURL)/g' \
-e 's|@@GITWEBDIR@@|$(gitwebdir_SQ)|g' \
-e 's|@@PERL@@|$(PERL_PATH_SQ)|g' \
- $@.sh > $@+ && \
+ $(GIT_SRC)$@.sh > $@+ && \
chmod +x $@+ && \
mv $@+ $@
else # NO_PERL
@@ -1788,7 +1799,7 @@ $(patsubst %.perl,%,$(SCRIPT_PERL)) git-instaweb: % : unimplemented.sh
$(QUIET_GEN)$(RM) $@ $@+ && \
sed -e '1s|#!.*/sh|#!$(SHELL_PATH_SQ)|' \
-e 's|@@REASON@@|NO_PERL=$(NO_PERL)|g' \
- unimplemented.sh >$@+ && \
+ $(GIT_SRC)unimplemented.sh >$@+ && \
chmod +x $@+ && \
mv $@+ $@
endif # NO_PERL
@@ -1803,7 +1814,7 @@ $(patsubst %.py,%,$(SCRIPT_PYTHON)): % : %.py
sed -e '1s|#!.*python|#!$(PYTHON_PATH_SQ)|' \
-e 's|\(os\.getenv("GITPYTHONLIB"\)[^)]*)|\1,"@@INSTLIBDIR@@")|' \
-e 's|@@INSTLIBDIR@@|'"$$INSTLIBDIR"'|g' \
- $@.py >$@+ && \
+ $(GIT_SRC)$@.py >$@+ && \
chmod +x $@+ && \
mv $@+ $@
else # NO_PYTHON
@@ -1811,7 +1822,7 @@ $(patsubst %.py,%,$(SCRIPT_PYTHON)): % : unimplemented.sh
$(QUIET_GEN)$(RM) $@ $@+ && \
sed -e '1s|#!.*/sh|#!$(SHELL_PATH_SQ)|' \
-e 's|@@REASON@@|NO_PYTHON=$(NO_PYTHON)|g' \
- unimplemented.sh >$@+ && \
+ $(GIT_SRC)unimplemented.sh >$@+ && \
chmod +x $@+ && \
mv $@+ $@
endif # NO_PYTHON
@@ -2142,7 +2153,7 @@ test-%$X: test-%.o $(GITLIBS)
$(QUIET_LINK)$(CC) $(ALL_CFLAGS) -o $@ $(ALL_LDFLAGS) $(filter %.o,$^) $(filter %.a,$^) $(LIBS)
check-sha1:: test-sha1$X
- ./test-sha1.sh
+ $(GIT_SRC)./test-sha1.sh
check: common-cmds.h
if sparse; \
@@ -2229,7 +2240,7 @@ endif
ln -s "git-remote-http$X" "$$execdir/$$p" 2>/dev/null || \
cp "$$execdir/git-remote-http$X" "$$execdir/$$p" || exit; \
done && \
- ./check_bindir "z$$bindir" "z$$execdir" "$$bindir/git-add$X"
+ $(GIT_SRC)./check_bindir "z$$bindir" "z$$execdir" "$$bindir/git-add$X"
install-gitweb:
$(MAKE) -C gitweb install
diff --git a/generate-cmdlist.sh b/generate-cmdlist.sh
index 75c68d9..f718633 100755
--- a/generate-cmdlist.sh
+++ b/generate-cmdlist.sh
@@ -9,7 +9,7 @@ struct cmdname_help
static struct cmdname_help common_cmds[] = {"
-sed -n -e 's/^git-\([^ ]*\)[ ].* common.*/\1/p' command-list.txt |
+sed -n -e 's/^git-\([^ ]*\)[ ].* common.*/\1/p' "$GIT_SRC"command-list.txt |
sort |
while read cmd
do
@@ -19,6 +19,6 @@ do
x
s/.*git-'"$cmd"' - \(.*\)/ {"'"$cmd"'", "\1"},/
p
- }' "Documentation/git-$cmd.txt"
+ }' "${GIT_SRC}Documentation/git-$cmd.txt"
done
echo "};"
diff --git a/perl/Makefile b/perl/Makefile
index a2ffb64..7c3a82a 100644
--- a/perl/Makefile
+++ b/perl/Makefile
@@ -44,4 +44,4 @@ endif
# this is just added comfort for calling make directly in perl dir
# (even though GIT-CFLAGS aren't used yet. If ever)
../GIT-CFLAGS:
- $(MAKE) -C .. GIT-CFLAGS
+ $(MAKE) -C $(GIT_SRC).. GIT-CFLAGS
--
1.7.2.3
^ permalink raw reply related
* moving to a git-backed wiki
From: Jeff King @ 2011-02-01 20:11 UTC (permalink / raw)
To: Scott Chacon; +Cc: Junio C Hamano, git
In-Reply-To: <AANLkTimHCp_JKUw1keJoA4zD_q7Sci+rOwPeAs_T=7xH@mail.gmail.com>
On Tue, Feb 01, 2011 at 10:34:24AM -0800, Scott Chacon wrote:
> > GitHub's wiki gets this right. I'm not saying we should host our wiki
> > there (well, it _would_ make setting it up pretty damn easy). But their
> > wiki system (gollum) is open-source, albeit in ruby. And surely there
> > are other git-backed alternatives (it's been a while since I've looked).
>
> If you want to use the wiki on the git/git repo on GitHub that is
> being mirrored from the canonical repository, I've added Junio and
> peff to the account. If you want to use that wiki, anyone with a
> github account can edit wiki pages on the site or clone and edit it
> locally and push changes up. You can also turn off site edits so
> people have to send Junio a patch instead. It's up to you guys, but
> the access is there now if you want.
Out of curiosity, I scraped the kernel wiki and put it into gollum. The
results are here, if people want to see what it looks like:
https://github.com/peff/foo/wiki
It's extremely quick and dirty, which is why I didn't put it in the
actual git/git/wiki spot you made. Some of the formatting is off (note
that I didn't do any conversion; it understands mediawiki natively), and
some of the content is probably missing (my scraper was extremely
naive). For a real import I would try to get the actual wiki db from
kernel.org and import the entire history.
I dunno what the next step would be. I would really prefer a git-backed
wiki, but moving to something like this is a pretty big step in workflow
for people who use the current wiki. I would be curious to hear general
opinions (on the idea of moving, assuming we did a conversion that
actually looked good). I'll change the subject and see if we get any
comments.
-Peff
^ permalink raw reply
* Re: [PATCH] Consistent use of AC_LANG_PROGRAM in configure.ac and aclocal.m4.
From: Ralf Wildenhues @ 2011-02-01 19:39 UTC (permalink / raw)
To: Jonathan Nieder, git
In-Reply-To: <20110102102455.GD10365@gmx.de>
* Ralf Wildenhues wrote on Sun, Jan 02, 2011 at 11:24:55AM CET:
> This avoids warnings from Autoconf 2.68 about missing use of
> AC_LANG_PROGRAM and friends.
I'd like to ping this patch:
http://thread.gmane.org/gmane.comp.version-control.git/164409/focus=164416
which IIUC addresses all previous comments in the thread and was
otherwise noncontroversial. If there is anything else left to do,
I'd be happy to hear about it.
Thanks,
Ralf
^ permalink raw reply
* Re: Tracking empty directories
From: Ilari Liusvaara @ 2011-02-01 19:09 UTC (permalink / raw)
To: Jakub Narebski
Cc: Nguyen Thai Ngoc Duy, Jonathan Nieder, Dmitry S. Kravtsov, git,
Shawn Pearce
In-Reply-To: <201102011931.40559.jnareb@gmail.com>
On Tue, Feb 01, 2011 at 07:31:38PM +0100, Jakub Narebski wrote:
> Dnia wtorek 1. lutego 2011 19:15, Ilari Liusvaara napisał:
> >
> > Worse problem than the index: Tree entries. Those are actually transferable
> > and IIRC older (current?) git versions don't handle empty subdirectories
> > (pointing entry of type directory to empty tree hash) all too well...
>
> What did you mean by "don't handle" here? The following entry
>
> 040000 tree 22d5826c087c4b9dcc72e2131c2cfb061403f7eb empty
>
> should be not a problem; empty tree is hardcoded and also shouldn't there
> be a problem with such object. Is the problem when checking out such tree
> (writing to index and/or working area)?
Yes, writing to index/working area. IIRC, having such entry in tree causes
a "ghost directory". I don't exactly recall what such thing broke, but I
remember that it broke something (merging?)...
Those ghosts also had annoying tendency to persist between commits. Commits
didn't kill them. Rm didn't work. You had to create something on top/inside to
get rid of them.
> > Worse yet, there isn't easy way to break the tree parser to avoid current
> > git versions from screwing things up (IIRC, when I tested, invalid octal
> > numbers finally broke it, invalid file types didn't do the trick)...
>
> Well, then 1.8.0 version could be good place to break backwards
> compatibility; we did similar thing when introducing submodule entries,
> isn't it?
Hint: Entry of mode "88888" blows up the tree parser nicely... :-)
At the same time, it could be useful to have manually tracked directories
(incidate via "sticky" bit of tree entry mode?)
-Ilari
^ permalink raw reply
* Re: Tracking empty directories
From: Jakub Narebski @ 2011-02-01 19:03 UTC (permalink / raw)
To: Jonathan Nieder
Cc: Nguyen Thai Ngoc Duy, Dmitry S. Kravtsov, git, Shawn Pearce
In-Reply-To: <20110201183508.GE3771@burratino>
Dnia wtorek 1. lutego 2011 19:35, Jonathan Nieder napisał:
> Nguyen Thai Ngoc Duy wrote:
>> On Wed, Feb 2, 2011 at 12:28 AM, Jonathan Nieder <jrnieder@gmail.com> wrote:
>
>>> I have ideas about how to resolve those tricky corner cases, but not
>>> about what the UI should look like. How does one go about adding a
>>> directory? Does it ever get implicitly removed?
>>
>> I suppose a special command for it is appropriate (git-keepdir?). Many
>> index-related commands are recursive by default and hard to change.
>>
>> Yes I think it should be automatically removed from index when a file
>> is added inside tracked directories. Removing those files will also
>> remove the containing directory though.
>
> Okay, I'm convinced. This fits a "worse is better" point of view
> nicely.
>
> To add, one would use "git update-index --add".
Porcelain version could be "git add -N <directory>", don't you agree?
> The magic disappears when you register a file within that directory;
> to tell git you want to keep it, one would mkdir and
> "git update-index --add" again. Once it's working, we can think about
> if there is a need for making that last step automatic after all
> (my guess: "no"). ;-)
Hmmm... could we use mechanism similar to assume-unchanged to mark
directory as explicitely tracked, and that git should not remove it
when it becomes empty?
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: [PATCH 2/3] t9010-svn-fi: Add tests for svn-fi
From: Jonathan Nieder @ 2011-02-01 18:58 UTC (permalink / raw)
To: Ramkumar Ramachandra
Cc: Git List, David Barr, Sverre Rabbelier, Junio C Hamano
In-Reply-To: <1296570403-9082-3-git-send-email-artagnon@gmail.com>
Ramkumar Ramachandra wrote:
> Create a test-svn-fi in toplevel directory, add rules to build it, and
> add some basic tests.
Thanks. Probably this should be squashed with patch #1?
> --- /dev/null
> +++ b/t/t9010-svn-fi.sh
Test number's already taken. 9012 is free, though.
> @@ -0,0 +1,303 @@
> +#!/bin/sh
> +
> +test_description='check svn dumpfile exporter'
> +
> +. ./test-lib.sh
> +
> +if ! svnadmin -h >/dev/null 2>&1
> +then
> + skip_all='skipping svn-fi tests, svn not available'
> + test_done
> +fi
Is it impossible to test without svn present or otherwise speed
these up? Some random ideas:
- feed svn-fi output into svn-fe and compare git repos
- check if "svn-fi after svn-fe" is idempotent (should it be?)
- check for individual salient features from svn-fi output, using
"grep", "sed", or "awk" to ignore the rest
- use svnrdump in place of "svnadmin load" if available (is it
faster?)
- find the bottleneck in svnadmin and fix it
Of course at least one test of the "svn-fe | svnadmin load"
pipeline seems worthwhile; I'm just thinking we should avoid
habits that slow down the test suite too much.
> +svn_look () {
> + subcommand=$1 &&
> + shift &&
> + svnlook "$subcommand" "$svnrepo" "$@"
> +}
Needed? The svn_cmd function exists to point to a configuration
directory.
> +test_expect_success 'normal empty files' '
> + reinit_svn &&
> + cat >expect.tree <<-\EOF &&
> + /
> + foo
> + bar
> + EOF
> + cat >input <<-\EOF &&
> + reset refs/heads/master
> + commit refs/heads/master
> + mark :1
> + author nobody <nobody@localhost> 1170199019 +0100
> + committer nobody <nobody@localhost> 1170199019 +0100
Where do the dates come from? Why should I (the reader) expect
them?
> +# TODO: How to test date? Need to convert from local timestamp
Ah, you saw. :)
One possibility is to fuzz away whatever is unimportant when
comparing results (and using tools like "awk" to extract the
date to perform whatever tests on it are appropriate where it
matters).
> +test_expect_success 'malformed fast-import stream: author 2' '
> + reinit_svn &&
> + cat >input <<-\EOF &&
> + reset refs/heads/master
> + commit refs/heads/master
> + mark :1
> + author nobody <localhost> 1170199019 +0100
> + committer nobody <nobody@localhost> 1170199019 +0100
> + data 0
> + M 100644 inline foo
> + data 0
> +
> + EOF
> + try_load input must_fail
What's wrong with this stream?
> +test_expect_success 'svn:special and svn:executable' '
> + reinit_svn &&
> + cat >input <<-\EOF &&
> + reset refs/heads/master
> + commit refs/heads/master
> + mark :1
> + author nobody <nobody@localhost> 1170199019 +0100
> + committer nobody <nobody@localhost> 1170199019 +0100
> + data 7
> + nothing
> + M 100755 inline foo
> + data 0
> + M 755 inline moo
> + data 0
> + M 120000 inline bar
> + data 0
> +
> + EOF
> + try_load input &&
> + svn_look propget svn:executable foo &&
> + svn_look propget svn:executable moo &&
> + svn_look propget svn:special bar
Maybe worth checking for the absence of svn:executable +
svn:special from an ordinary file, too?
> +test_expect_success 'replace symlink with normal file' '
Nice. "replace symlink with executable" and "replace symlink
with directory" might also be interesting.
Regards,
Jonathan
^ permalink raw reply
* Re: Features from GitSurvey 2010
From: Jonathan Nieder @ 2011-02-01 18:42 UTC (permalink / raw)
To: Matthieu Moy; +Cc: Dmitry S. Kravtsov, git, Jakub Narebski
In-Reply-To: <vpq62t3ejje.fsf@bauges.imag.fr>
Matthieu Moy wrote:
>>> support for tracking empty directories
[...]
> http://thread.gmane.org/gmane.comp.version-control.git/56310/focus=56348
Thanks! I followed up a bit on this lead in the "tracking empty
directories" thread.
>>> advisory locking / "this file is being edited"
[...]
> That needs to be integrated with Git, but it should probably still
> remain out of the Git core, because different users would want
> different locking databases. Hooks and git-* commands in the $PATH are
> probably sufficient.
Yes, a nice side effect could be the addition of a couple of hooks.
An rcs-style workflow (lockable files absent from worktree until
locked) on top of git sounds fun.
^ permalink raw reply
* [1.8.0] Remove deprecated commands
From: René Scharfe @ 2011-02-01 18:37 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vwrll57ha.fsf@alter.siamese.dyndns.org>
The following four commands have been marked as deprecated in
command-list.txt for quite some time[*]:
command deprecated since replaced by
---------------- ---------------- ---------------------
git-lost-found 2007-11-08 git fsck --lost-found
git-peek-remote 2007-11-24 git ls-remote
git-repo-config 2008-01-17 git config
git-tar-tree 2007-11-08 git archive
Let's just remove them. There's a risk that someone is still using the
old commands, of course, but they have been deprecated long enough now.
[*] data source:
git blame -C command-list.txt |
sed -n 's/.*\(....-..-..\).*\(git-[^ ]*\).*deprecated.*/\2\t\1/p'
^ permalink raw reply
* Re: Tracking empty directories
From: Jonathan Nieder @ 2011-02-01 18:35 UTC (permalink / raw)
To: Nguyen Thai Ngoc Duy
Cc: Jakub Narebski, Dmitry S. Kravtsov, git, Shawn Pearce
In-Reply-To: <AANLkTi=u6=mhOd9LFYRy48y41xRcXmYDtktOKoBjjMgO@mail.gmail.com>
Nguyen Thai Ngoc Duy wrote:
> On Wed, Feb 2, 2011 at 12:28 AM, Jonathan Nieder <jrnieder@gmail.com> wrote:
>> I have ideas about how to resolve those tricky corner cases, but not
>> about what the UI should look like. How does one go about adding a
>> directory? Does it ever get implicitly removed?
>
> I suppose a special command for it is appropriate (git-keepdir?). Many
> index-related commands are recursive by default and hard to change.
>
> Yes I think it should be automatically removed from index when a file
> is added inside tracked directories. Removing those files will also
> remove the containing directory though.
Okay, I'm convinced. This fits a "worse is better" point of view
nicely.
To add, one would use "git update-index --add". The magic disappears
when you register a file within that directory; to tell git you want
to keep it, one would mkdir and "git update-index --add" again. Once
it's working, we can think about if there is a need for making that
last step automatic after all (my guess: "no"). ;-)
Use case: [1]
Nice starting point: [2]
Motivational word of wisdom: [3]
This treatment leaves out the backward compatibility detail. I still
think that's the easy part (at worst, we can always implement read
support, wait a year, and then turn on write support).
Jonathan
[1] http://thread.gmane.org/gmane.comp.version-control.git/46947/focus=47278
[2] http://thread.gmane.org/gmane.comp.version-control.git/52813/focus=52908
[3] http://thread.gmane.org/gmane.comp.version-control.git/53494
^ permalink raw reply
* Re: [1.8.0] (v2) default "git merge" without argument to "git merge @{u}"
From: Scott Chacon @ 2011-02-01 18:34 UTC (permalink / raw)
To: Jeff King; +Cc: Junio C Hamano, git, Miles Bader
In-Reply-To: <20110131225529.GC14419@sigill.intra.peff.net>
Hey,
On Mon, Jan 31, 2011 at 2:55 PM, Jeff King <peff@peff.net> wrote:
> On Mon, Jan 31, 2011 at 12:50:30PM -0800, Junio C Hamano wrote:
>
>> Perhaps I should start a new directory in todo branch (say, 1.8.0), accept
>> patches from people? I'd grudgingly admit that using Wiki on k.org may be
>> less burdensome (I hate editing inside the browser myself), but I'd want
>> to keep the mailing list the center of discussion and am afraid that
>> forcing people to go to Wiki would fragment the discussion.
>
> I really wish we had a git-backed wiki. I also hate using the browser
> for such things (though browser extensions to edit textareas in a Real
> Editor at least make it tolerable, it still ends up clunky).
>
> GitHub's wiki gets this right. I'm not saying we should host our wiki
> there (well, it _would_ make setting it up pretty damn easy). But their
> wiki system (gollum) is open-source, albeit in ruby. And surely there
> are other git-backed alternatives (it's been a while since I've looked).
If you want to use the wiki on the git/git repo on GitHub that is
being mirrored from the canonical repository, I've added Junio and
peff to the account. If you want to use that wiki, anyone with a
github account can edit wiki pages on the site or clone and edit it
locally and push changes up. You can also turn off site edits so
people have to send Junio a patch instead. It's up to you guys, but
the access is there now if you want.
Scott
^ permalink raw reply
* Re: Tracking empty directories
From: Jakub Narebski @ 2011-02-01 18:31 UTC (permalink / raw)
To: Ilari Liusvaara
Cc: Nguyen Thai Ngoc Duy, Jonathan Nieder, Dmitry S. Kravtsov, git,
Shawn Pearce
In-Reply-To: <20110201181509.GA2370@LK-Perkele-VI.localdomain>
Dnia wtorek 1. lutego 2011 19:15, Ilari Liusvaara napisał:
> On Wed, Feb 02, 2011 at 12:54:35AM +0700, Nguyen Thai Ngoc Duy wrote:
> > On Wed, Feb 2, 2011 at 12:28 AM, Jonathan Nieder <jrnieder@gmail.com> wrote:
> >
> > Could it be done with an index extension? Interesting.
> >
> > > Certainly one ought to register an extension name or bump the version
> > > number to avoid confusing gits that don't know about the feature.
> >
> > Index extension with lowercase name are "necessary for correct
> > operation". Older git will abort on unknown required extensions. If
> > you add to the main part of the index, better bump version number.
>
> Worse problem than the index: Tree entries. Those are actually transferable
> and IIRC older (current?) git versions don't handle empty subdirectories
> (pointing entry of type directory to empty tree hash) all too well...
What did you mean by "don't handle" here? The following entry
040000 tree 22d5826c087c4b9dcc72e2131c2cfb061403f7eb empty
should be not a problem; empty tree is hardcoded and also shouldn't there
be a problem with such object. Is the problem when checking out such tree
(writing to index and/or working area)?
> Worse yet, there isn't easy way to break the tree parser to avoid current
> git versions from screwing things up (IIRC, when I tested, invalid octal
> numbers finally broke it, invalid file types didn't do the trick)...
Well, then 1.8.0 version could be good place to break backwards
compatibility; we did similar thing when introducing submodule entries,
isn't it?
--
Jakub Narebski
Poland
^ permalink raw reply
* [1.8.0] split largest remaining scripts, gitk and gitweb
From: Jakub Narebski @ 2011-02-01 18:26 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: Junio C Hamano, git
In-Reply-To: <alpine.LFD.2.00.1101311459000.8580@xanadu.home>
Two largest files in git repository are gitk and gitweb, see the
output of the following command
$ git ls-tree --abbrev -r -t -l v1.7.4 | sort -k4,4 -n | tail
I can't say much about splitting gitk, besides the fact that git-gui
which was of comparable size IIRC got split into smaller files; I
guess similar thing could be done for gitk.
There was an attempt (ultimately failed) on splitting gitweb during
Google Summer of Code 2010. At least providing infrastructure for
multiple gitweb modules is very much required for adding
code-intensive new features, like gitweb output caching.
On the other hand this might make gitweb harder to install...
Next in size is compat/nedmalloc/malloc.c.h (I don't know if it can be
reduced in size), and git-svn. I think we could separate core
functionality into Git::Svn module or something, and make git-svn
smaller (perhaps reusing some code in/from svn remote helper).
What do you think?
--
Jakub Narebski
Poland
ShadeHawk on #git
^ permalink raw reply
* Re: Tracking empty directories
From: Ilari Liusvaara @ 2011-02-01 18:15 UTC (permalink / raw)
To: Nguyen Thai Ngoc Duy
Cc: Jonathan Nieder, Jakub Narebski, Dmitry S. Kravtsov, git,
Shawn Pearce
In-Reply-To: <AANLkTi=u6=mhOd9LFYRy48y41xRcXmYDtktOKoBjjMgO@mail.gmail.com>
On Wed, Feb 02, 2011 at 12:54:35AM +0700, Nguyen Thai Ngoc Duy wrote:
> On Wed, Feb 2, 2011 at 12:28 AM, Jonathan Nieder <jrnieder@gmail.com> wrote:
>
> Could it be done with an index extension? Interesting.
>
> > Certainly one ought to register an extension name or bump the version
> > number to avoid confusing gits that don't know about the feature.
>
> Index extension with lowercase name are "necessary for correct
> operation". Older git will abort on unknown required extensions. If
> you add to the main part of the index, better bump version number.
Worse problem than the index: Tree entries. Those are actually transferable
and IIRC older (current?) git versions don't handle empty subdirectories
(pointing entry of type directory to empty tree hash) all too well...
Worse yet, there isn't easy way to break the tree parser to avoid current
git versions from screwing things up (IIRC, when I tested, invalid octal
numbers finally broke it, invalid file types didn't do the trick)...
-Ilari
^ permalink raw reply
* Re: [1.8.0] Remote tag namespace
From: Jeff King @ 2011-02-01 18:14 UTC (permalink / raw)
To: Nguyen Thai Ngoc Duy; +Cc: Git Mailing List, Nicolas Pitre
In-Reply-To: <AANLkTi=yFwOAQMHhvLsB1_xmYOE9HHP2YB4H4TQzwwc8@mail.gmail.com>
On Tue, Feb 01, 2011 at 05:44:50PM +0700, Nguyen Thai Ngoc Duy wrote:
> OK I'm not familiar with tag code, but I can try.
>
> Proposal:
>
> Reserve refs/remote-tags namespace to store tags from remotes. Its
> structure is the same as in refs/remotes. When pulling tags, put them
> in refs/remote-tags/<remote> instead of refs/tags.
> Tag dereference code will be taught about refs/remote-tags with
> similar deref order as in remote branches.
There are similar questions around remote notes refs. Should there also
be a refs/remote-notes? And there was some discussion recently about
fetching remote replace refs.
Should we perhaps be massaging refs/remotes into a structure to handle
all of these things? Like:
refs/remotes/origin/HEAD (-> refs/remotes/origin/heads/master)
refs/remotes/origin/heads/master
refs/remotes/origin/tags/v1.7.4
refs/remotes/origin/notes/commit
refs/remotes/origin/replace/f67e92af477a2255b64a1ece33d9d126e763fe9b
i.e., make refs/remotes/* an actual mirror of selected parts of the
remote's refs/ hierarchy. And then figure out sane rules for merging
those namespaces into the ref lookup procedure. For heads and tags,
probably some tweaking of the lookup rules in dwim_ref; for
replacements, probably you would want to manually say "I am interested
in this replace" and copy or symref-link it into your refs/ hierarchy.
And probably something similar with notes.
Obviously I haven't thought it all the way through, but it just seems a
shame not to deal with other similar issues when looking at tags.
-Peff
^ permalink raw reply
* Re: Tracking empty directories
From: Nguyen Thai Ngoc Duy @ 2011-02-01 17:54 UTC (permalink / raw)
To: Jonathan Nieder; +Cc: Jakub Narebski, Dmitry S. Kravtsov, git, Shawn Pearce
In-Reply-To: <20110201172835.GA3771@burratino>
On Wed, Feb 2, 2011 at 12:28 AM, Jonathan Nieder <jrnieder@gmail.com> wrote:
> Jakub Narebski wrote:
>
>> Also one needs to remember that this would require adding extension
>> to git index, because currently it tracks only files, and not
>> directories. Explicitly tracking directories in the index could be
>> useful for other purposes...
>>
>> The major difficulty of this is IMHO not the UI, but tracking all those
>> tricky corner cases (like directory/file conflict, etc.).
>
> I have ideas about how to resolve those tricky corner cases, but not
> about what the UI should look like. How does one go about adding a
> directory? Does it ever get implicitly removed?
I suppose a special command for it is appropriate (git-keepdir?). Many
index-related commands are recursive by default and hard to change.
Yes I think it should be automatically removed from index when a file
is added inside tracked directories. Removing those files will also
remove the containing directory though.
> Would this actually require an index extension, strictly speaking?
Could it be done with an index extension? Interesting.
> Certainly one ought to register an extension name or bump the version
> number to avoid confusing gits that don't know about the feature.
Index extension with lowercase name are "necessary for correct
operation". Older git will abort on unknown required extensions. If
you add to the main part of the index, better bump version number.
> But after that, couldn't we (e.g.) allow the directory name (ending
> with '/') as index entry?
You could. You also need to strip '/' sometimes because certain part
of git does not expect '/' to be there (traverse_trees or
unpack_trees, I don't remember).
--
Duy
^ permalink raw reply
* Re: Features from GitSurvey 2010
From: Matthieu Moy @ 2011-02-01 17:44 UTC (permalink / raw)
To: Jonathan Nieder; +Cc: Dmitry S. Kravtsov, git, Jakub Narebski
In-Reply-To: <20110129231310.GA11088@burratino>
Jonathan Nieder <jrnieder@gmail.com> writes:
>> support for tracking empty directories
>
> Tricky to get the UI right. I am interested in and would be glad to
> help with this one.
A starting point, with some proposed (broken) patches:
http://thread.gmane.org/gmane.comp.version-control.git/56310/focus=56348
>> advisory locking / "this file is being edited"
>
> Probably better to implement out of band (using hooks?). I don't
> know of any work or documentation in that direction.
File locking and distributed tool are conflicting interests. A
file-locking tool for git should be able to use a centralized locks
database (for example, one can imagine a simple PHP script hosted
somewhere independantly of the Git repo, keeping a list of locked
files up to date).
That needs to be integrated with Git, but it should probably still
remain out of the Git core, because different users would want
different locking databases. Hooks and git-* commands in the $PATH are
probably sufficient.
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
^ permalink raw reply
* problem when pulling a specific branch from origin
From: Ivan Kanis @ 2011-02-01 17:25 UTC (permalink / raw)
To: git
Hello,
When I pull a specific branch from a repository I get in a state where
git thinks I am ahead of the branch by one commit. The use case is a
programmer that doesn't want to pull all the branches of the server.
I have made a small script to reproduce the problem:
----
#!/bin/sh
rm -rf foo bar
git --version
mkdir foo
cd foo
git init
echo foo > foo.txt
git add foo.txt
git commit -am"foo"
git checkout -b branch
cd ..
git clone foo bar
cd foo
echo bar > foo.txt
git commit -am"bar"
cd ..
cd bar
git pull origin branch
git status
git branch -rv
----
I get the following output:
----
git version 1.7.3.5
Initialized empty Git repository in /home/ivan/tmp/foo/.git/
[master (root-commit) eefa065] foo
1 files changed, 1 insertions(+), 0 deletions(-)
create mode 100644 foo.txt
Switched to a new branch 'branch'
Cloning into bar...
done.
[branch 7ecd065] bar
1 files changed, 1 insertions(+), 1 deletions(-)
remote: Counting objects: 5, done.
remote: Total 3 (delta 0), reused 0 (delta 0)
Unpacking objects: 100% (3/3), done.
From /home/ivan/tmp/foo
* branch branch -> FETCH_HEAD
Updating eefa065..7ecd065
Fast-forward
foo.txt | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
# On branch master
# Your branch is ahead of 'origin/master' by 1 commit.
#
nothing to commit (working directory clean)
origin/HEAD -> origin/master
origin/branch eefa065 foo
origin/master eefa065 foo
----
I expected to not be ahead of origin/master and that origin/branch
points to 7ecd065. Is this a bug?
Take care,
--
Ivan Kanis
Sure, ninety percent of science fiction is crud. That's because ninety
percent of everything is crud.
-- Theodore Sturgeon
^ permalink raw reply
* Re: [PATCH 3/3] vcs-svn: Refactor dump_export code into dispatch table
From: Jonathan Nieder @ 2011-02-01 17:42 UTC (permalink / raw)
To: Ramkumar Ramachandra
Cc: Git List, David Barr, Sverre Rabbelier, Junio C Hamano
In-Reply-To: <1296570403-9082-4-git-send-email-artagnon@gmail.com>
Ramkumar Ramachandra wrote:
> +++ b/vcs-svn/dump_export.c
> @@ -11,6 +11,48 @@
[...]
> +static state_fn *const dispatch_table[NODE_KIND_COUNT][NODE_ACTION_COUNT] = {
> + /* NODE_KIND_UNKNOWN */
> + {abort, abort, abort, Adelete, abort},
> + /* NODE_KIND_NORMAL */
> + {abort, Nchange, Nadd, Adelete, Nreplace},
> + /* NODE_KIND_EXECUTABLE */
> + {abort, Echange, Eadd, Adelete, Ereplace},
> + /* NODE_KIND_SYMLINK */
> + {abort, Schange, Sadd, Adelete, Sreplace},
> + /* NODE_KIND_GITLINK */
> + {abort, abort, abort, abort, abort},
> + /* NODE_KIND_DIR */
> + {abort, Dchange, Dadd, Adelete, Dreplace},
> + /* NODE_KIND_SUBDIR */
> + {abort, abort, abort, abort, abort}
> +};
Heh. I think that Junio was suggesting making the _parser_
table-driven, meaning something like
... node_kinds[] = {
{ "100644", sizeof("100644"), "file" },
{ "100755", sizeof("100755"), "file", "svn:executable" },
{ "120000", sizeof("120000"), "file", "svn:special" },
{ "160000", sizeof("160000"), "file" }, /* NEEDSWORK: seems wrong" */
{ "040000", sizeof("040000"), "dir" }
};
(Side note: remember that 644 and 755 are permitted synonyms for
100644 and 100755!)
I personally think that simple state machines tend to be easier to
follow if the current state is represented by the instruction pointer
rather than a variable, as in the current fast-import.c. But maybe
that's a matter of taste?
Anyway, my other complaints about this dispatch_table are that the
function names leave me rubbing my head and I can't keep the list
of states you're transitioning between straight in my head. I guess
"Adelete" is an abbreviation for print_delete_node_action? Is a
callback needed at all (rather than just a string) for such actions?
Hope that helps,
Jonathan
^ permalink raw reply
* Re: Features from GitSurvey 2010
From: Shawn Pearce @ 2011-02-01 17:34 UTC (permalink / raw)
To: Nguyen Thai Ngoc Duy
Cc: Jakub Narebski, Jonathan Nieder, Dmitry S. Kravtsov, git
In-Reply-To: <AANLkTi=_DPSp2P3MuFOPgua2nH7U+RUt4AfAHSyPVv-G@mail.gmail.com>
On Tue, Feb 1, 2011 at 09:11, Nguyen Thai Ngoc Duy <pclouds@gmail.com> wrote:
> On Tue, Feb 1, 2011 at 11:27 PM, Shawn Pearce <spearce@spearce.org> wrote:
>> On Tue, Feb 1, 2011 at 05:51, Jakub Narebski <jnareb@gmail.com> wrote:
>>>
>>>> > resumable clone/fetch (and other remote operations)
>>>>
>>>> Jakub Narebski seems to be interested in this and Nicolas Pitre has
>>>> given some good advice about it. You can get something usable today
>>>> by putting up a git bundle for download over HTTP or rsync, so it is
>>>> possible that this just involves some UI (porcelain) and documentation
>>>> work to become standard practice.
>>>
>>> I wouldn't say that: it is Nicolas Pitre (IIRC) who was doing the work;
>>> I was only interested party posting comments, but no code.
>>>
>>> Again, this feature is not very easy to implement, and would require
>>> knowledge of git internals including "smart" git transport ("Pro Git"
>>> book can help there).
>>
>> I think Nico and I have mostly solved this with the pack caching idea.
>> If we cache the pack file, we can resume anywhere in about 97% of the
>> transfer. The first 3% cannot be resumed easily, its back to the old
>> "git cannot be resumed" issue. Fixing that last 3% is incredibly
>
> I thought the cached pack contained anything and for initial clone, we
> simply send the pack. What is this 3%? Commit list? Initial commit?
Its the recent changes. If the cached pack starts from the tip of
master, its probably 0%. But if the repository owner pushes new
changes since the cached pack was created, these are sent as a thin
pack in front of the cached pack... and make up that ~3% guess. For
linux-2.6 I tested a 2 week period when the merge window as open right
after a release, and the new delta was about 3% of the overall
repository size.
> Narrow/Subtree clone is still just an idea, but can pack cache support
> be made to resumable initial narrow clone too?
This would be very hard to do. We could do cached packs for a popular
set of path specifications (e.g. Documentation/ if documentation only
editing is common), but once we start getting random requests for path
specifications that we cannot predict in advance and pre-pack we'd
have to fall back to the normal enumerate code path.
--
Shawn.
^ permalink raw reply
* Tracking empty directories
From: Jonathan Nieder @ 2011-02-01 17:28 UTC (permalink / raw)
To: Jakub Narebski
Cc: Dmitry S. Kravtsov, git, Nguyen Thai Ngoc Duy, Shawn Pearce
In-Reply-To: <201102011451.17456.jnareb@gmail.com>
Jakub Narebski wrote:
> Also one needs to remember that this would require adding extension
> to git index, because currently it tracks only files, and not
> directories. Explicitly tracking directories in the index could be
> useful for other purposes...
>
> The major difficulty of this is IMHO not the UI, but tracking all those
> tricky corner cases (like directory/file conflict, etc.).
I have ideas about how to resolve those tricky corner cases, but not
about what the UI should look like. How does one go about adding a
directory? Does it ever get implicitly removed?
Would this actually require an index extension, strictly speaking?
Certainly one ought to register an extension name or bump the version
number to avoid confusing gits that don't know about the feature.
But after that, couldn't we (e.g.) allow the directory name (ending
with '/') as index entry?
A related question is backward compatibility (both for alternative git
implementations and for scripts that did not know that "git ls-files"
might mention an empty directory) which somehow seems less
daunting. ;-)
Jonathan
^ 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