* Re: [PATCH] git-clean: Display more accurate delete messages
From: Soren Brinkmann @ 2012-12-10 17:04 UTC (permalink / raw)
To: Zoltan Klinger; +Cc: Soren Brinkmann, Junio C Hamano, git
In-Reply-To: <CAKJhZwROXsTa4wu-C9rhfGysetL+cZRDECyFUn5VTb833pWzMQ@mail.gmail.com>
Hi Zoltan,
On Sun, Dec 09, 2012 at 10:18:19PM +1100, Zoltan Klinger wrote:
> >> Hrm, following your discussion (ellided above), I would have
> >> expected that you would show
> >>
> >> Removing directory foo/bar
> >> Removing untracked_file1
> >
> > Also it would be nice to have warnings about undeleted directories since this git
> > clean behavior (or the work around to pass -f twice) is not documented.
> > Without a warning you would probably miss that something was _not_ deleted.
>
> Thanks for the feedback. I think you're right. Showing 'foo/bar/bar.txt' in
> the list when 'foo/bar/' directory has been successfully deleted is just noise.
>
> Would like to get some more feedback on the proposed output in case of
> (1) an untracked subdirectory with multiple files where at least one of them
> cannot be removed.
> (2) reporting ignored untracked git subdirectories
>
> Suppose we have a repo like the one below:
> test.git/
> |-- tracked_file
> |-- untracked_file
> |-- untracked_foo/
> | |-- bar/
> | | |-- bar.txt
> | |-- emptydir/
> | |-- frotz.git/
> | | |-- frotx.txt
> | |-- quux/
> | |-- failedquux.txt
> | |-- quux.txt
> |-- untracked_unreadable_dir/
> | |-- afile
> |-- untracked_some.git/
> |-- some.txt
>
> $ git clean -fd
> Removing untracked_file
> Removing untracked_foo/bar
> Removing untracked_foo/emptydir
> Removing untracked_foo/quux/quux.txt
> warning: failed to remove untracked_foo/quux/failedquux.txt
> warning: failed to remove remove untracked_unreadable_dir/
> warning: ignoring untracked git repository untracked_foo/frotz.git/
> warning: ignoring untracked git repository untracked_some.git/
> Use git clean --force --force to delete all untracked git repositories
>
> $ # use forced remove
> $ git clean --force --force -d
> Removing untracked_foo/frotz.git
> Removing untracked_foo/quux/quux.txt
> Removing untracked_some.git/
> warning: failed to remove untracked_foo/quux/failedquux.txt
> warning: failed to remove untracked_unreadable_dir/
>
> Can you see any issues with the proposed output, wording above? If
> everyone is happy,
> I'm going to prepare patch V2 for it.
Looks good to me.
Thanks,
Soren
^ permalink raw reply
* Re: [PATCHv2] mingw_rmdir: do not prompt for retry when non-empty
From: Erik Faye-Lund @ 2012-12-10 16:50 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, msysgit, johannes.schindelin
In-Reply-To: <7vr4mxc1rd.fsf@alter.siamese.dyndns.org>
On Mon, Dec 10, 2012 at 5:25 PM, Junio C Hamano <gitster@pobox.com> wrote:
> Erik Faye-Lund <kusmabite@gmail.com> writes:
>
>> in ab1a11be ("mingw_rmdir: set errno=ENOTEMPTY when appropriate"),
>> a check was added to prevent us from retrying to delete a directory
>> that is both in use and non-empty.
>>
>> However, this logic was slightly flawed; since we didn't return
>> immediately, we end up falling out of the retry-loop, but right into
>> the prompting-loop.
>>
>> Fix this by setting errno, and guarding the prompting-loop with an
>> errno-check.
>>
>> Signed-off-by: Erik Faye-Lund <kusmabite@gmail.com>
>> ---
>>
>> Here's the second version of this patch, sorry for the slight delay.
>
> Is this meant for me, or is it to be applied to msysgit and later
> somehow fed to me in different form?
>
> I can s/_wrmdir/rmdir/;s/wpathname/pathname/ if that is what you
> want me to do, but otherwise this patch does not apply.
>
Ugh, you are right. I intended for you to apply it, but I didn't
realize that my patch was based on the msysGit-master, where Karsten's
UTF-8 patches has been applied.
I'm not entirely sure what the best approach would be. The issue is
present in both branches, but we only build installers from the
msysGit-branch. But I think there are other people who builds Git from
the upstream source code, so it would be slightly less annoying for
them if the patch was fixed up and applied. But on the other hand,
that causes some annoyance when (if?) Karsten's UTF-8 patches gets
upstreamed.
Thoughts?
--
*** Please reply-to-all at all times ***
*** (do not pretend to know who is subscribed and who is not) ***
*** Please avoid top-posting. ***
The msysGit Wiki is here: https://github.com/msysgit/msysgit/wiki - Github accounts are free.
You received this message because you are subscribed to the Google
Groups "msysGit" group.
To post to this group, send email to msysgit@googlegroups.com
To unsubscribe from this group, send email to
msysgit+unsubscribe@googlegroups.com
For more options, and view previous threads, visit this group at
http://groups.google.com/group/msysgit?hl=en_US?hl=en
^ permalink raw reply
* Re: [PATCH] Makefile: whitespace style fixes in macro definitions
From: Junio C Hamano @ 2012-12-10 16:37 UTC (permalink / raw)
To: Stefano Lattarini; +Cc: git
In-Reply-To: <0544836357d56c05188941ef5a471605fa6d4881.1355049367.git.stefano.lattarini@gmail.com>
Stefano Lattarini <stefano.lattarini@gmail.com> writes:
> Consistently use a single space before and after the "=" (or ":=", "+=",
> etc.) in assignments to make macros. Granted, this was not a big deal,
> but I did find the needless inconsistency quite distracting.
>
> Signed-off-by: Stefano Lattarini <stefano.lattarini@gmail.com>
> ---
Makes sense to do this kind of clean-up when these files are
quiescent (and they are).
Thanks.
> Makefile | 56 ++++++++++++++++++++++++++++----------------------------
> config.mak.in | 2 +-
> t/Makefile | 2 +-
> 3 files changed, 30 insertions(+), 30 deletions(-)
>
> diff --git a/Makefile b/Makefile
> index 4ad6fbd..736ecd4 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -374,7 +374,7 @@ htmldir = share/doc/git-doc
> ETC_GITCONFIG = $(sysconfdir)/gitconfig
> ETC_GITATTRIBUTES = $(sysconfdir)/gitattributes
> lib = lib
> -# DESTDIR=
> +# DESTDIR =
> pathsep = :
>
> export prefix bindir sharedir sysconfdir gitwebdir localedir
> @@ -575,9 +575,9 @@ endif
> export PERL_PATH
> export PYTHON_PATH
>
> -LIB_FILE=libgit.a
> -XDIFF_LIB=xdiff/lib.a
> -VCSSVN_LIB=vcs-svn/lib.a
> +LIB_FILE = libgit.a
> +XDIFF_LIB = xdiff/lib.a
> +VCSSVN_LIB = vcs-svn/lib.a
>
> LIB_H += xdiff/xinclude.h
> LIB_H += xdiff/xmacros.h
> @@ -1139,7 +1139,7 @@ ifeq ($(uname_S),NetBSD)
> endif
> ifeq ($(uname_S),AIX)
> DEFAULT_PAGER = more
> - NO_STRCASESTR=YesPlease
> + NO_STRCASESTR = YesPlease
> NO_MEMMEM = YesPlease
> NO_MKDTEMP = YesPlease
> NO_MKSTEMPS = YesPlease
> @@ -1147,7 +1147,7 @@ ifeq ($(uname_S),AIX)
> NO_NSEC = YesPlease
> FREAD_READS_DIRECTORIES = UnfortunatelyYes
> INTERNAL_QSORT = UnfortunatelyYes
> - NEEDS_LIBICONV=YesPlease
> + NEEDS_LIBICONV = YesPlease
> BASIC_CFLAGS += -D_LARGE_FILES
> ifeq ($(shell expr "$(uname_V)" : '[1234]'),1)
> NO_PTHREADS = YesPlease
> @@ -1155,13 +1155,13 @@ ifeq ($(uname_S),AIX)
> PTHREAD_LIBS = -lpthread
> endif
> ifeq ($(shell expr "$(uname_V).$(uname_R)" : '5\.1'),3)
> - INLINE=''
> + INLINE = ''
> endif
> GIT_TEST_CMP = cmp
> endif
> ifeq ($(uname_S),GNU)
> # GNU/Hurd
> - NO_STRLCPY=YesPlease
> + NO_STRLCPY = YesPlease
> NO_MKSTEMPS = YesPlease
> HAVE_PATHS_H = YesPlease
> LIBC_CONTAINS_LIBINTL = YesPlease
> @@ -1187,9 +1187,9 @@ ifeq ($(uname_S),IRIX)
> NEEDS_LIBGEN = YesPlease
> endif
> ifeq ($(uname_S),IRIX64)
> - NO_SETENV=YesPlease
> + NO_SETENV = YesPlease
> NO_UNSETENV = YesPlease
> - NO_STRCASESTR=YesPlease
> + NO_STRCASESTR = YesPlease
> NO_MEMMEM = YesPlease
> NO_MKSTEMPS = YesPlease
> NO_MKDTEMP = YesPlease
> @@ -1203,14 +1203,14 @@ ifeq ($(uname_S),IRIX64)
> NO_REGEX = YesPlease
> NO_FNMATCH_CASEFOLD = YesPlease
> SNPRINTF_RETURNS_BOGUS = YesPlease
> - SHELL_PATH=/usr/gnu/bin/bash
> + SHELL_PATH = /usr/gnu/bin/bash
> NEEDS_LIBGEN = YesPlease
> endif
> ifeq ($(uname_S),HP-UX)
> INLINE = __inline
> - NO_IPV6=YesPlease
> - NO_SETENV=YesPlease
> - NO_STRCASESTR=YesPlease
> + NO_IPV6 = YesPlease
> + NO_SETENV = YesPlease
> + NO_STRCASESTR = YesPlease
> NO_MEMMEM = YesPlease
> NO_MKSTEMPS = YesPlease
> NO_STRLCPY = YesPlease
> @@ -1386,10 +1386,10 @@ ifeq ($(uname_S),NONSTOP_KERNEL)
> MKDIR_WO_TRAILING_SLASH = YesPlease
> # RFE 10-120912-4693 submitted to HP NonStop development.
> NO_SETITIMER = UnfortunatelyYes
> - SANE_TOOL_PATH=/usr/coreutils/bin:/usr/local/bin
> - SHELL_PATH=/usr/local/bin/bash
> + SANE_TOOL_PATH = /usr/coreutils/bin:/usr/local/bin
> + SHELL_PATH = /usr/local/bin/bash
> # as of H06.25/J06.14, we might better use this
> - #SHELL_PATH=/usr/coreutils/bin/bash
> + #SHELL_PATH = /usr/coreutils/bin/bash
> endif
> ifneq (,$(findstring MINGW,$(uname_S)))
> pathsep = ;
> @@ -1437,7 +1437,7 @@ ifneq (,$(findstring MINGW,$(uname_S)))
> X = .exe
> SPARSE_FLAGS = -Wno-one-bit-signed-bitfield
> ifneq (,$(wildcard ../THIS_IS_MSYSGIT))
> - htmldir=doc/git/html/
> + htmldir = doc/git/html/
> prefix =
> INSTALL = /bin/install
> EXTLIBS += /mingw/lib/libz.a
> @@ -1559,7 +1559,7 @@ else
> CURL_LIBCURL = -lcurl
> endif
> ifdef NEEDS_SSL_WITH_CURL
> - CURL_LIBCURL += -lssl
> + CURL_LIBCURL += -lssl
> ifdef NEEDS_CRYPTO_WITH_SSL
> CURL_LIBCURL += -lcrypto
> endif
> @@ -1768,7 +1768,7 @@ ifdef OBJECT_CREATION_USES_RENAMES
> endif
> ifdef NO_STRUCT_ITIMERVAL
> COMPAT_CFLAGS += -DNO_STRUCT_ITIMERVAL
> - NO_SETITIMER=YesPlease
> + NO_SETITIMER = YesPlease
> endif
> ifdef NO_SETITIMER
> COMPAT_CFLAGS += -DNO_SETITIMER
> @@ -1920,15 +1920,15 @@ ifneq (,$(XDL_FAST_HASH))
> endif
>
> ifeq ($(TCLTK_PATH),)
> -NO_TCLTK=NoThanks
> +NO_TCLTK = NoThanks
> endif
>
> ifeq ($(PERL_PATH),)
> -NO_PERL=NoThanks
> +NO_PERL = NoThanks
> endif
>
> ifeq ($(PYTHON_PATH),)
> -NO_PYTHON=NoThanks
> +NO_PYTHON = NoThanks
> endif
>
> QUIET_SUBDIR0 = +$(MAKE) -C # space to separate -C and subdir
> @@ -1975,13 +1975,13 @@ PROFILE_DIR := $(CURDIR)
> ifeq ("$(PROFILE)","GEN")
> CFLAGS += -fprofile-generate=$(PROFILE_DIR) -DNO_NORETURN=1
> EXTLIBS += -lgcov
> - export CCACHE_DISABLE=t
> - V=1
> + export CCACHE_DISABLE = t
> + V = 1
> else
> ifneq ("$(PROFILE)","")
> CFLAGS += -fprofile-use=$(PROFILE_DIR) -fprofile-correction -DNO_NORETURN=1
> - export CCACHE_DISABLE=t
> - V=1
> + export CCACHE_DISABLE = t
> + V = 1
> endif
> endif
>
> @@ -2830,7 +2830,7 @@ git.spec: git.spec.in GIT-VERSION-FILE
> sed -e 's/@@VERSION@@/$(GIT_VERSION)/g' < $< > $@+
> mv $@+ $@
>
> -GIT_TARNAME=git-$(GIT_VERSION)
> +GIT_TARNAME = git-$(GIT_VERSION)
> dist: git.spec git-archive$(X) configure
> ./git-archive --format=tar \
> --prefix=$(GIT_TARNAME)/ HEAD^{tree} > $(GIT_TARNAME).tar
> diff --git a/config.mak.in b/config.mak.in
> index 69d4838..e8a9bb4 100644
> --- a/config.mak.in
> +++ b/config.mak.in
> @@ -18,7 +18,7 @@ datarootdir = @datarootdir@
> template_dir = @datadir@/git-core/templates
> sysconfdir = @sysconfdir@
>
> -mandir=@mandir@
> +mandir = @mandir@
>
> srcdir = @srcdir@
> VPATH = @srcdir@
> diff --git a/t/Makefile b/t/Makefile
> index 88e289f..3025418 100644
> --- a/t/Makefile
> +++ b/t/Makefile
> @@ -6,7 +6,7 @@
> -include ../config.mak.autogen
> -include ../config.mak
>
> -#GIT_TEST_OPTS=--verbose --debug
> +#GIT_TEST_OPTS = --verbose --debug
> SHELL_PATH ?= $(SHELL)
> PERL_PATH ?= /usr/bin/perl
> TAR ?= $(TAR)
^ permalink raw reply
* Re: [PATCHv2] mingw_rmdir: do not prompt for retry when non-empty
From: Junio C Hamano @ 2012-12-10 16:25 UTC (permalink / raw)
To: Erik Faye-Lund; +Cc: git, msysgit, johannes.schindelin
In-Reply-To: <1355150547-8212-1-git-send-email-kusmabite@gmail.com>
Erik Faye-Lund <kusmabite@gmail.com> writes:
> in ab1a11be ("mingw_rmdir: set errno=ENOTEMPTY when appropriate"),
> a check was added to prevent us from retrying to delete a directory
> that is both in use and non-empty.
>
> However, this logic was slightly flawed; since we didn't return
> immediately, we end up falling out of the retry-loop, but right into
> the prompting-loop.
>
> Fix this by setting errno, and guarding the prompting-loop with an
> errno-check.
>
> Signed-off-by: Erik Faye-Lund <kusmabite@gmail.com>
> ---
>
> Here's the second version of this patch, sorry for the slight delay.
Is this meant for me, or is it to be applied to msysgit and later
somehow fed to me in different form?
I can s/_wrmdir/rmdir/;s/wpathname/pathname/ if that is what you
want me to do, but otherwise this patch does not apply.
>
> compat/mingw.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/compat/mingw.c b/compat/mingw.c
> index 1eb974f..440224c 100644
> --- a/compat/mingw.c
> +++ b/compat/mingw.c
> @@ -260,6 +260,8 @@ int mingw_rmdir(const char *pathname)
>
> while ((ret = _wrmdir(wpathname)) == -1 && tries < ARRAY_SIZE(delay)) {
> if (!is_file_in_use_error(GetLastError()))
> + errno = err_win_to_posix(GetLastError());
> + if (errno != EACCES)
> break;
> if (!is_dir_empty(wpathname)) {
> errno = ENOTEMPTY;
> @@ -275,7 +277,7 @@ int mingw_rmdir(const char *pathname)
> Sleep(delay[tries]);
> tries++;
> }
> - while (ret == -1 && is_file_in_use_error(GetLastError()) &&
> + while (ret == -1 && errno == EACCES && is_file_in_use_error(GetLastError()) &&
> ask_yes_no_if_possible("Deletion of directory '%s' failed. "
> "Should I try again?", pathname))
> ret = _wrmdir(wpathname);
--
*** Please reply-to-all at all times ***
*** (do not pretend to know who is subscribed and who is not) ***
*** Please avoid top-posting. ***
The msysGit Wiki is here: https://github.com/msysgit/msysgit/wiki - Github accounts are free.
You received this message because you are subscribed to the Google
Groups "msysGit" group.
To post to this group, send email to msysgit@googlegroups.com
To unsubscribe from this group, send email to
msysgit+unsubscribe@googlegroups.com
For more options, and view previous threads, visit this group at
http://groups.google.com/group/msysgit?hl=en_US?hl=en
^ permalink raw reply
* [PATCHv2] mingw_rmdir: do not prompt for retry when non-empty
From: Erik Faye-Lund @ 2012-12-10 14:42 UTC (permalink / raw)
To: git; +Cc: msysgit, johannes.schindelin, gitster
in ab1a11be ("mingw_rmdir: set errno=ENOTEMPTY when appropriate"),
a check was added to prevent us from retrying to delete a directory
that is both in use and non-empty.
However, this logic was slightly flawed; since we didn't return
immediately, we end up falling out of the retry-loop, but right into
the prompting-loop.
Fix this by setting errno, and guarding the prompting-loop with an
errno-check.
Signed-off-by: Erik Faye-Lund <kusmabite@gmail.com>
---
Here's the second version of this patch, sorry for the slight delay.
compat/mingw.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/compat/mingw.c b/compat/mingw.c
index 1eb974f..440224c 100644
--- a/compat/mingw.c
+++ b/compat/mingw.c
@@ -260,6 +260,8 @@ int mingw_rmdir(const char *pathname)
while ((ret = _wrmdir(wpathname)) == -1 && tries < ARRAY_SIZE(delay)) {
if (!is_file_in_use_error(GetLastError()))
+ errno = err_win_to_posix(GetLastError());
+ if (errno != EACCES)
break;
if (!is_dir_empty(wpathname)) {
errno = ENOTEMPTY;
@@ -275,7 +277,7 @@ int mingw_rmdir(const char *pathname)
Sleep(delay[tries]);
tries++;
}
- while (ret == -1 && is_file_in_use_error(GetLastError()) &&
+ while (ret == -1 && errno == EACCES && is_file_in_use_error(GetLastError()) &&
ask_yes_no_if_possible("Deletion of directory '%s' failed. "
"Should I try again?", pathname))
ret = _wrmdir(wpathname);
--
1.8.0.msysgit.0.3.gafa53b0.dirty
--
*** Please reply-to-all at all times ***
*** (do not pretend to know who is subscribed and who is not) ***
*** Please avoid top-posting. ***
The msysGit Wiki is here: https://github.com/msysgit/msysgit/wiki - Github accounts are free.
You received this message because you are subscribed to the Google
Groups "msysGit" group.
To post to this group, send email to msysgit@googlegroups.com
To unsubscribe from this group, send email to
msysgit+unsubscribe@googlegroups.com
For more options, and view previous threads, visit this group at
http://groups.google.com/group/msysgit?hl=en_US?hl=en
^ permalink raw reply related
* Re: [PATCH] git(1): remove a defunct link to "list of authors"
From: Nguyen Thai Ngoc Duy @ 2012-12-10 12:04 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vboe2ct9p.fsf@alter.siamese.dyndns.org>
On Mon, Dec 10, 2012 at 1:31 PM, Junio C Hamano <gitster@pobox.com> wrote:
> Nguyen Thai Ngoc Duy <pclouds@gmail.com> writes:
>
>> On Sat, Dec 8, 2012 at 12:59 AM, Junio C Hamano <gitster@pobox.com> wrote:
>>>> * If somebody has a working replacement URL, we could use that
>>>> instead, of course. Takers?
>>>
>>> A possible alternative could be https://www.ohloh.net/p/git/contributors/summary
>>
>> Nice charts!
>
> Yup.
>
> Their numbers seem to be just 'any commit by the author, with
> mailmap applied', and I am of two minds with it. Counting without
> "shortlog --no-merges", depending on the management style of the
> project, tends to credit the integrator too much. Even though
> vetting the patches and choosing when to merge the topics is a
> significant contribution, it isn't *that* big compared to the work
> done by the contributor who took initiative to scratch that itch.
>
> With or without "--no-merges", the big picture you can get out of
> "git shortlog -s -n --since=1.year" does not change very much, but
> the headline numbers give a wrong impression.
These numbers are approximate anyway. Commit counts or the number of
changed lines do not accurately reflect the effort in many cases. And
about merges, in this particular case of Git where the maintainer imo
has done an excellent job as a guard, I'd say it's the credit for
reviewing, not simply merging.
But not using the link is fine too. We can wait for Jeff's patch to be merged.
> And of course, application of the mailmap is very important, if you
> want to get meaningful numbers out of shortlog over a longer period.
--
Duy
^ permalink raw reply
* Re: [PATCH v2] cache-tree: invalidate i-t-a paths after generating trees
From: Nguyen Thai Ngoc Duy @ 2012-12-10 11:53 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Jeff King, Jonathon Mah
In-Reply-To: <7v7goqcsdy.fsf@alter.siamese.dyndns.org>
On Mon, Dec 10, 2012 at 1:50 PM, Junio C Hamano <gitster@pobox.com> wrote:
> Nguyễn Thái Ngọc Duy <pclouds@gmail.com> writes:
>
>> diff --git a/cache-tree.c b/cache-tree.c
>> index 28ed657..989a7ff 100644
>> --- a/cache-tree.c
>> +++ b/cache-tree.c
>> @@ -248,6 +248,7 @@ static int update_one(struct cache_tree *it,
>> int missing_ok = flags & WRITE_TREE_MISSING_OK;
>> int dryrun = flags & WRITE_TREE_DRY_RUN;
>> int i;
>> + int to_invalidate = 0;
>>
>> if (0 <= it->entry_count && has_sha1_file(it->sha1))
>> return it->entry_count;
>> @@ -324,7 +325,13 @@ static int update_one(struct cache_tree *it,
>> if (!sub)
>> die("cache-tree.c: '%.*s' in '%s' not found",
>> entlen, path + baselen, path);
>> - i += sub->cache_tree->entry_count - 1;
>> + i--; /* this entry is already counted in "sub" */
>> + if (sub->cache_tree->entry_count < 0) {
>> + i -= sub->cache_tree->entry_count;
>> + to_invalidate = 1;
>> + }
>> + else
>> + i += sub->cache_tree->entry_count;
>
> Hrm. update_one() is prepared to see a cache-tree whose entry count
> is zero (see the context lines in the previous hunk) and the
> invariant for the rest of the code is "if 0 <= entry_count, the
> cached tree is valid; invalid cache-tree has -1 in entry_count.
> More importantly, entry_count negated does not in general express
> how many entries there are in the subtree and does not tell us how
> many index entries to skip.
Yeah I use entry_count for two different things here. In the previous
(unsent) version of the patch I had "entry_count = -1" right after "i
-= entry_count"
>> + if (sub->cache_tree->entry_count < 0) {
>> + i -= sub->cache_tree->entry_count;
>> + sub->cache_tree->entry_count = -1;
>> + to_invalidate = 1;
>> + }
which makes it clearer that the use of negative entry count is only
valid within update_one. Then I changed my mind because it says
'negative means "invalid"' in cache-tree.h. So, put "entry_count = -1"
back or just add another field to struct cache_tree for this?
--
Duy
^ permalink raw reply
* Re: Feature Request - Hide ignored files before checkout
From: Erik Faye-Lund @ 2012-12-10 9:47 UTC (permalink / raw)
To: Matthew Ciancio; +Cc: Andrew Ardill, git
In-Reply-To: <000001cdd67a$39be9d40$ad3bd7c0$@gmail.com>
On Mon, Dec 10, 2012 at 3:01 AM, Matthew Ciancio
<matthew.ciancio16@gmail.com> wrote:
> Thanks for explaining that Andrew. I guess that was my intention: to have an "ignored file snapshot", but I can see now that it goes against Git's definitions and is not really needed.
>
I have played around with the idea of backing up files deleted by
git-clean in the object database, maintained by a reflog (similar to
git-stash). I did this to protect my code against my fat fingers, but
perhaps this could also have been useful in your case?
https://github.com/kusma/git/tree/work/clean-backup
^ permalink raw reply
* Re: [PATCH] git-clean: Display more accurate delete messages
From: Junio C Hamano @ 2012-12-10 7:04 UTC (permalink / raw)
To: Zoltan Klinger; +Cc: Soren Brinkmann, git
In-Reply-To: <CAKJhZwROXsTa4wu-C9rhfGysetL+cZRDECyFUn5VTb833pWzMQ@mail.gmail.com>
Zoltan Klinger <zoltan.klinger@gmail.com> writes:
> Would like to get some more feedback on the proposed output in case of
> (1) an untracked subdirectory with multiple files where at least one of them
> cannot be removed.
> (2) reporting ignored untracked git subdirectories
>
> Suppose we have a repo like the one below:
> test.git/
> |-- tracked_file
> |-- untracked_file
> |-- untracked_foo/
> | |-- bar/
> | | |-- bar.txt
> | |-- emptydir/
> | |-- frotz.git/
> | | |-- frotx.txt
> | |-- quux/
> | |-- failedquux.txt
> | |-- quux.txt
> |-- untracked_unreadable_dir/
> | |-- afile
> |-- untracked_some.git/
> |-- some.txt
>
> $ git clean -fd
> Removing untracked_file
> Removing untracked_foo/bar
> Removing untracked_foo/emptydir
> Removing untracked_foo/quux/quux.txt
> warning: failed to remove untracked_foo/quux/failedquux.txt
> warning: failed to remove remove untracked_unreadable_dir/
"remove remove" is a typo, I presume.
> warning: ignoring untracked git repository untracked_foo/frotz.git/
> warning: ignoring untracked git repository untracked_some.git/
If you mean "we report the topmost directory and nothing about
(recursive) contents in it if everything is removed successfully"
(in other words, if we had subdirectories and files inside
untracked_foo/bar/ and we successfully removed all of them, the
above output does not change), it seems quite reasonable.
> Use git clean --force --force to delete all untracked git repositories
But I am not sure if this is ever sane. Especially the one that
removes an embedded repository is suspicious. "git clean" should
not ever touch it with or without --superforce or any other command.
I do not think trying to remove something that cannot be removed due
to filesystem permissions is sensible, either. We simply should treat
such a case a grave error and have the user sort things out, instead
of blindly attempt to "chmod" them ourselves (which may still fail).
Thanks.
^ permalink raw reply
* Re: [PATCH v2] cache-tree: invalidate i-t-a paths after generating trees
From: Junio C Hamano @ 2012-12-10 6:50 UTC (permalink / raw)
To: Nguyễn Thái Ngọc Duy; +Cc: git, Jeff King, Jonathon Mah
In-Reply-To: <1354939803-8466-1-git-send-email-pclouds@gmail.com>
Nguyễn Thái Ngọc Duy <pclouds@gmail.com> writes:
> diff --git a/cache-tree.c b/cache-tree.c
> index 28ed657..989a7ff 100644
> --- a/cache-tree.c
> +++ b/cache-tree.c
> @@ -248,6 +248,7 @@ static int update_one(struct cache_tree *it,
> int missing_ok = flags & WRITE_TREE_MISSING_OK;
> int dryrun = flags & WRITE_TREE_DRY_RUN;
> int i;
> + int to_invalidate = 0;
>
> if (0 <= it->entry_count && has_sha1_file(it->sha1))
> return it->entry_count;
> @@ -324,7 +325,13 @@ static int update_one(struct cache_tree *it,
> if (!sub)
> die("cache-tree.c: '%.*s' in '%s' not found",
> entlen, path + baselen, path);
> - i += sub->cache_tree->entry_count - 1;
> + i--; /* this entry is already counted in "sub" */
> + if (sub->cache_tree->entry_count < 0) {
> + i -= sub->cache_tree->entry_count;
> + to_invalidate = 1;
> + }
> + else
> + i += sub->cache_tree->entry_count;
Hrm. update_one() is prepared to see a cache-tree whose entry count
is zero (see the context lines in the previous hunk) and the
invariant for the rest of the code is "if 0 <= entry_count, the
cached tree is valid; invalid cache-tree has -1 in entry_count.
More importantly, entry_count negated does not in general express
how many entries there are in the subtree and does not tell us how
many index entries to skip.
> @@ -339,8 +346,23 @@ static int update_one(struct cache_tree *it,
> mode, sha1_to_hex(sha1), entlen+baselen, path);
> }
>
> - if (ce->ce_flags & (CE_REMOVE | CE_INTENT_TO_ADD))
> - continue; /* entry being removed or placeholder */
> + /*
> + * CE_REMOVE entries are removed before the index is
> + * written to disk. Skip them to remain consistent
> + * with the future on-disk index.
> + */
> + if (ce->ce_flags & CE_REMOVE)
> + continue;
> +
> + /*
> + * CE_INTENT_TO_ADD entries exist on on-disk index but
> + * they are not part of generated trees. Invalidate up
> + * to root to force cache-tree users to read elsewhere.
> + */
> + if (ce->ce_flags & CE_INTENT_TO_ADD) {
> + to_invalidate = 1;
> + continue;
> + }
Thanks for documenting these.
> @@ -360,7 +382,7 @@ static int update_one(struct cache_tree *it,
> }
>
> strbuf_release(&buffer);
> - it->entry_count = i;
> + it->entry_count = to_invalidate ? -i : i;
See above. I am not fundamentally opposed to a change to redefine
entry_count so that it always maintains how many index entries the
subtree covers, even for invalidated subtree, but I do not think
this patch alone is sufficient to maintain such invariant.
> #if DEBUG
> fprintf(stderr, "cache-tree update-one (%d ent, %d subtree) %s\n",
> it->entry_count, it->subtree_nr,
> diff --git a/t/t2203-add-intent.sh b/t/t2203-add-intent.sh
> index ec35409..2a4a749 100755
> --- a/t/t2203-add-intent.sh
> +++ b/t/t2203-add-intent.sh
> @@ -62,5 +62,25 @@ test_expect_success 'can "commit -a" with an i-t-a entry' '
> git commit -a -m all
> '
>
> +test_expect_success 'cache-tree invalidates i-t-a paths' '
> + git reset --hard &&
> + mkdir dir &&
> + : >dir/foo &&
> + git add dir/foo &&
> + git commit -m foo &&
> +
> + : >dir/bar &&
> + git add -N dir/bar &&
> + git diff --cached --name-only >actual &&
> + echo dir/bar >expect &&
> + test_cmp expect actual &&
> +
> + git write-tree >/dev/null &&
> +
> + git diff --cached --name-only >actual &&
> + echo dir/bar >expect &&
> + test_cmp expect actual
> +'
> +
> test_done
^ permalink raw reply
* Re: [PATCH] git(1): remove a defunct link to "list of authors"
From: Junio C Hamano @ 2012-12-10 6:31 UTC (permalink / raw)
To: Nguyen Thai Ngoc Duy; +Cc: git
In-Reply-To: <CACsJy8A7AYpZs7mTc+B-F7BBLPdACim=gHCg8sK1Aci8YSEB4Q@mail.gmail.com>
Nguyen Thai Ngoc Duy <pclouds@gmail.com> writes:
> On Sat, Dec 8, 2012 at 12:59 AM, Junio C Hamano <gitster@pobox.com> wrote:
>>> * If somebody has a working replacement URL, we could use that
>>> instead, of course. Takers?
>>
>> A possible alternative could be https://www.ohloh.net/p/git/contributors/summary
>
> Nice charts!
Yup.
Their numbers seem to be just 'any commit by the author, with
mailmap applied', and I am of two minds with it. Counting without
"shortlog --no-merges", depending on the management style of the
project, tends to credit the integrator too much. Even though
vetting the patches and choosing when to merge the topics is a
significant contribution, it isn't *that* big compared to the work
done by the contributor who took initiative to scratch that itch.
With or without "--no-merges", the big picture you can get out of
"git shortlog -s -n --since=1.year" does not change very much, but
the headline numbers give a wrong impression.
And of course, application of the mailmap is very important, if you
want to get meaningful numbers out of shortlog over a longer period.
^ permalink raw reply
* Re: [PATCH] gitweb: Sort projects with undefined ages last
From: Junio C Hamano @ 2012-12-10 6:16 UTC (permalink / raw)
To: Matthew Daley; +Cc: git
In-Reply-To: <1355114061-4652-1-git-send-email-mattjd@gmail.com>
Matthew Daley <mattjd@gmail.com> writes:
> Sorting gitweb's project list by age ('Last Change') currently shows
> projects with undefined ages at the head of the list. This results in a
> less useful result when there are a number of projects that are missing
> or otherwise faulty and one is trying to see what projects have been
> updated recently.
>
> Fix by sorting these projects with undefined ages at the bottom of the
> list when sorting by age.
>
> Signed-off-by: Matthew Daley <mattjd@gmail.com>
> ---
> I realize this might be a bit bikesheddy, but it does improve the listing
> in the given use case. For an example of the problem, see ie.
> http://git.kernel.org/?o=age or http://repo.or.cz/w?a=project_list;o=age .
Yeah, it could be argued that in a very minor corner case showing
new and empty ones at the top might attract more attention to them,
but new and empty ones can stay inactive, so this change would be an
overall improvement for these two sites. An alternative could be to
give the mtime of the git directory to the age field if there is no
commits in the repository, to sink the empty and inactive ones to
the bottom quickly while showing newly created ones at the top, but
it shouldn't make any practical difference.
> I'm also not a Perl native, so any advice on making the patch good Perl is
> appreciated.
>
> gitweb/gitweb.perl | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
> index 0f207f2..21da1b5 100755
> --- a/gitweb/gitweb.perl
> +++ b/gitweb/gitweb.perl
> @@ -5541,7 +5541,9 @@ sub sort_projects_list {
> if ($oi->{'type'} eq 'str') {
> @projects = sort {$a->{$oi->{'key'}} cmp $b->{$oi->{'key'}}} @$projlist;
> } else {
> - @projects = sort {$a->{$oi->{'key'}} <=> $b->{$oi->{'key'}}} @$projlist;
> + @projects = sort {$a->{$oi->{'key'}} <=> $b->{$oi->{'key'}}}
> + grep {defined $_->{$oi->{'key'}}} @$projlist;
> + push @projects, grep {!defined $_->{$oi->{'key'}}} @$projlist;
> }
Two observations:
* This iterates over the same @$projlist twice with grep, with one
"defined" and the other "!defined", which may risk these two
complementary grep conditions to go out of sync (it also may
affect performance but that is a lessor issue).
An alternative may be to change the expression used inside sort()
to treat an undef as if it were a very large value, something
like:
sort {
defined $a->{$oi->{'key'}}
? (defined $b->{$oi->{'key'}}
? ($a->{$oi->{'key'}} <=> $b->{$oi->{'key'}})
: -1)
: (defined $b->{$oi->{'key'}} ? 1 : 0);
}
* This "sort undefs at the end is better than at the beginning" is
good only for the "age" field, and we wouldn't know if we would
add other keys for which it may be better to sort undef at the
beginning. The order_info{} currently has only one field of the
'num' type, so this is not an immediate issue, but in order to
future proof, it may make sense to rewrite the sort_projects_list
function to map the order field name to a function given to sort,
e.g.
my %order_sort = (
project => sub { $a->{'path'} cmp $b->{'path'} },
descr => sub { $a->{'descr_long'} cmp $b->{'descr_long'} },
owner => sub { $a->{'owner'} cmp $b->{'owner'} },
age => sub { ... the num cmp with undef above ... },
);
if (!exists $order_sort{$order}) {
return @$projlist;
}
return sort $order_sort{$order} @$projlist;
I am not sure the second one is worth it, though.
^ permalink raw reply
* [PATCH] gitweb: Sort projects with undefined ages last
From: Matthew Daley @ 2012-12-10 4:34 UTC (permalink / raw)
To: git; +Cc: Matthew Daley
Sorting gitweb's project list by age ('Last Change') currently shows
projects with undefined ages at the head of the list. This results in a
less useful result when there are a number of projects that are missing
or otherwise faulty and one is trying to see what projects have been
updated recently.
Fix by sorting these projects with undefined ages at the bottom of the
list when sorting by age.
Signed-off-by: Matthew Daley <mattjd@gmail.com>
---
I realize this might be a bit bikesheddy, but it does improve the listing
in the given use case. For an example of the problem, see ie.
http://git.kernel.org/?o=age or http://repo.or.cz/w?a=project_list;o=age .
I'm also not a Perl native, so any advice on making the patch good Perl is
appreciated.
gitweb/gitweb.perl | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index 0f207f2..21da1b5 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -5541,7 +5541,9 @@ sub sort_projects_list {
if ($oi->{'type'} eq 'str') {
@projects = sort {$a->{$oi->{'key'}} cmp $b->{$oi->{'key'}}} @$projlist;
} else {
- @projects = sort {$a->{$oi->{'key'}} <=> $b->{$oi->{'key'}}} @$projlist;
+ @projects = sort {$a->{$oi->{'key'}} <=> $b->{$oi->{'key'}}}
+ grep {defined $_->{$oi->{'key'}}} @$projlist;
+ push @projects, grep {!defined $_->{$oi->{'key'}}} @$projlist;
}
return @projects;
--
1.7.10.4
^ permalink raw reply related
* RE: Feature Request - Hide ignored files before checkout
From: Matthew Ciancio @ 2012-12-10 2:01 UTC (permalink / raw)
To: 'Andrew Ardill'; +Cc: git
In-Reply-To: <CAH5451m-JcgLtvVER1UgvsFzemb=otG3XttR4j2s=eFnPrPyEQ@mail.gmail.com>
Thanks for explaining that Andrew. I guess that was my intention: to have an "ignored file snapshot", but I can see now that it goes against Git's definitions and is not really needed.
I have overcome the problem by re-organising my repository and "... using more 'traditional' git workflows.".
-----Original Message-----
From: Andrew Ardill [mailto:andrew.ardill@gmail.com]
Sent: Monday, 10 December 2012 12:46 PM
To: Matthew Ciancio
Cc: git@vger.kernel.org
Subject: Re: Feature Request - Hide ignored files before checkout
Hi Matt,
On 8 December 2012 11:50, Matthew Ciancio <matthew.ciancio16@gmail.com> wrote:
> Problem: ignore.txt does not "disappear" like foo.txt does and is now
> just sitting in branchA (and now any other branch I checkout into).
>
> When I first started using Git, I genuinely thought this was a bug,
> because it seems so logical to me that ignore files should
> hide/reappear just like tracked files do, when switching branches.
Let me address this by asking a few questions; *why* do files hide/reappear, what is the mechanism behind that and does it really make sense to apply it to ignored files.
For each commit, git stores a snapshot of your files. When we switch branches we are telling git to restore the previously saved snapshot so we can work with those files. This means resetting the working directory so that it looks like what we had committed; git will delete files that were part of the current checked out snapshot but not the new one, and create files that need to be created. As a convenience to users, files that are not tracked are left 'as-is' when switching branches.
So we see that in order to hide/reappear a file it has to be tracked in a snapshot, and so has to be committed *somewhere*. An ignored file is by definition not included in commits, and furthermore you hope to keep these files out of your commit history.
> I have been told ways of circumventing this (using commits and
> un-commits OR using stash), but my reason for avoiding commits is: say
> you have binary/OS specific files which really do not belong in the
> commit logs (even locally) and hence should be ignored. What if you
> want those files in only one branch and not all?
> Stashing doesn't seem appropriate either, because it would get messy.
I am not sure how viable a suggestion this is, but perhaps you can have two separate repositories, one tracking your standard branches, and another tracking the ignored files. These repositories could be kept in sync through submodules or some similar mechanism. This could also allow you to, for example, publish the histories of these independently, for example releasing the non-ignored repository publicly.
I haven't heard of anyone doing this, but if you need to keep the history clean it might be a way of achieving it.
I also don't know what the implications of checking out two repositories into the same tree might be, or even if git would allow it in general (maybe if you ignored everything belonging to the other
repository?) In any case, this solution could quickly become messy, but if carefully controlled might solve your problem. Then again, maybe you can achieve what you want using more 'traditional' git workflows.
Regards,
Andrew Ardill
^ permalink raw reply
* Re: Feature Request - Hide ignored files before checkout
From: Andrew Ardill @ 2012-12-10 1:46 UTC (permalink / raw)
To: Matthew Ciancio; +Cc: git@vger.kernel.org
In-Reply-To: <000301cdd4dd$f8554090$e8ffc1b0$@gmail.com>
Hi Matt,
On 8 December 2012 11:50, Matthew Ciancio <matthew.ciancio16@gmail.com> wrote:
> Problem: ignore.txt does not "disappear" like foo.txt does and is now just
> sitting in branchA (and now any other branch I checkout into).
>
> When I first started using Git, I genuinely thought this was a bug, because
> it seems so logical to me that ignore files should hide/reappear just like
> tracked files do, when switching branches.
Let me address this by asking a few questions; *why* do files
hide/reappear, what is the mechanism behind that and does it really
make sense to apply it to ignored files.
For each commit, git stores a snapshot of your files. When we switch
branches we are telling git to restore the previously saved snapshot
so we can work with those files. This means resetting the working
directory so that it looks like what we had committed; git will delete
files that were part of the current checked out snapshot but not the
new one, and create files that need to be created. As a convenience to
users, files that are not tracked are left 'as-is' when switching
branches.
So we see that in order to hide/reappear a file it has to be tracked
in a snapshot, and so has to be committed *somewhere*. An ignored file
is by definition not included in commits, and furthermore you hope to
keep these files out of your commit history.
> I have been told ways of circumventing this (using commits and un-commits OR
> using stash), but my reason for avoiding commits is: say you have binary/OS
> specific files which really do not belong in the commit logs (even locally)
> and hence should be ignored. What if you want those files in only one branch
> and not all?
> Stashing doesn't seem appropriate either, because it would get messy.
I am not sure how viable a suggestion this is, but perhaps you can
have two separate repositories, one tracking your standard branches,
and another tracking the ignored files. These repositories could be
kept in sync through submodules or some similar mechanism. This could
also allow you to, for example, publish the histories of these
independently, for example releasing the non-ignored repository
publicly.
I haven't heard of anyone doing this, but if you need to keep the
history clean it might be a way of achieving it.
I also don't know what the implications of checking out two
repositories into the same tree might be, or even if git would allow
it in general (maybe if you ignored everything belonging to the other
repository?) In any case, this solution could quickly become messy,
but if carefully controlled might solve your problem. Then again,
maybe you can achieve what you want using more 'traditional' git
workflows.
Regards,
Andrew Ardill
^ permalink raw reply
* Re: exit code from git reset
From: Martin von Zweigbergk @ 2012-12-09 23:12 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vzk1mddzo.fsf@alter.siamese.dyndns.org>
On Sun, Dec 9, 2012 at 3:04 PM, Junio C Hamano <gitster@pobox.com> wrote:
> Martin von Zweigbergk <martinvonz@gmail.com> writes:
>
>> "git reset" currently returns 0 (if successful) while "git reset
>> $pathspec" returns 0 iff the index matches HEAD after resetting (on
>> all paths, not just those matching $pathspec).
>
> So in short, you observed that either of them reports with its exit
> code if the resulting index (not just any subpart, but always the
> entire thing) matches the HEAD, e.g. "do we have change that will be
> listed on 'will be committed' section in git status output?"
>
> Sounds like one sane and consistent semantics to me.
Heh, true, the behavior according to my description does make sense,
it's just that my description was wrong; sorry :-(.
What "git reset $pathspec" returns is not "whether HEAD differs from
index" (as I wrote), but "whether worktree differs from index". So
"git reset" and "git reset ." will return different exit codes if
there are changes in the worktree as compared to HEAD before the
invocation. I hope that's clearer.
^ permalink raw reply
* Re: exit code from git reset
From: Junio C Hamano @ 2012-12-09 23:04 UTC (permalink / raw)
To: Martin von Zweigbergk; +Cc: git
In-Reply-To: <CANiSa6i0LXE18Pyb5norRTm7PM+TMo3JvxDjoS5JOWt_qjHLHw@mail.gmail.com>
Martin von Zweigbergk <martinvonz@gmail.com> writes:
> "git reset" currently returns 0 (if successful) while "git reset
> $pathspec" returns 0 iff the index matches HEAD after resetting (on
> all paths, not just those matching $pathspec).
So in short, you observed that either of them reports with its exit
code if the resulting index (not just any subpart, but always the
entire thing) matches the HEAD, e.g. "do we have change that will be
listed on 'will be committed' section in git status output?"
Sounds like one sane and consistent semantics to me. I am not
saying that there cannot be other behaviours that are internally
consistent (e.g. the error code could have matched the number of
paths that are different between the index and the HED, or the error
code could have been zero for successful reset, non-zero for some
failure), but I am saying that the current behaviour gives _one_
sane and consistent meanings regardless of how you ran the command.
> The exit code doesn't seem to be documented.
Please make it so.
> Changing "git reset $pathspec" to return 0 on success, regardless of
> diff between HEAD and index, breaks 10 test cases (in
> t2013-checkout-submodule.sh and t7102-reset.sh). These seem to do
> "test_must_fail git reset $pathspec", but I have not been able to find
> any motivation for expecting the failure.
See above.
^ permalink raw reply
* RE: Feature Request - Hide ignored files before checkout
From: Matthew Ciancio @ 2012-12-09 22:37 UTC (permalink / raw)
To: 'Junio C Hamano'; +Cc: git, 'Chris Rorvick'
In-Reply-To: <7vhanvegvu.fsf@alter.siamese.dyndns.org>
I appreciate your involvement, Mr Hamano.
You have made me realise that my intentions were flawed from the beginning,
because I had been misusing the branch feature.
Thank you for your time.
-----Original Message-----
From: Junio C Hamano [mailto:gitster@pobox.com]
Sent: Sunday, 9 December 2012 8:04 PM
To: Chris Rorvick
Cc: Matthew Ciancio; git@vger.kernel.org
Subject: Re: Feature Request - Hide ignored files before checkout
Chris Rorvick <chris@rorvick.com> writes:
> It's not in branchA, it's just no longer ignored because your changes
> to .gitignore were effectively reverted by jumping back to the commit
> that branchA points to.
> ...
> "hide/reappear" is the equivalent to saying "deleted/created" in the
> case of a tracked file in your working tree. But how would Git cause
> an untracked file to reappear? By definition, it doesn't know
> anything about the file.
Nicely explained. To make something simply disappear, you could remove it,
but that is obviously not enough to make it reappear. It has to be stashed
away somewhere before it gets removed, and in the context of (any) SCM, that
is done by committing.
You may have Mac and Windows branches, each of which needs to link with
vendor supplied object file blackbox.o with the rest of the source. It is
understandable if a project does not want to mix such platform specific
black box binaries in the history of the source.
But that does not necessarily mean the project can totally ignore what
specific black box binary was meant to be used with the rest of the source.
After you released the v1.0 of your product for both Macintosh and Windows,
the vendor may supply updated versions of the blackbox.o binary for these
platforms, and you would start working toward v1.1 of your product using
these updated copies of objects. Then you find problems in the released
v1.0 software. Without keeping track of which version of the object was
used to build the released v1.0, you cannot diagnose, build and test a
maintenance update v1.0.1.
The project may add new Macintosh (or Windows) developers. You can tell new
Macintosh developers to clone and checkout mac branch, and in the same
e-mail, give them the untracked blackbox.o file for that platform, but you
have to rely on human not making mistakes (you may mistakenly send Windows
version of blackbox.o to him, you may send stale Macintosh version, the
developer may misplace the new one and keep using the stale one, etc. etc.).
Some people commit blackbox.o on each platform-specific branch, or all
branches share blackbox-win.o and blackbox-mac.o, only one of which is used
at any given branch, for this exact reason.
The project, for licensing reasons, may not have rights to distribute such a
blackbox object file along with its sources, but the vendor of the blackbox
object may allow individual developer to download and link it from vendor's
site. In such a case, the project would not want to (and is not allowed to)
commit such object file. One approach I have seen used in such a case is to
arrange the build procedure so that these individual developers can drop
such an external object next to the project directory, and refer to it as
../blackbox.o when linking.
So "these files are moved away from the working tree upon checking another
branch out, and moved back into the working tree upon checking out this
branch" is pretty much outside the scope of any SCM. It is not very
interesting, as it is not necessary to solve any real world problem.
Of course, the users can do whatever moving/copying/renaming of untracked
files in their post-checkout hook to be run when a new branch is checked
out.
^ permalink raw reply
* exit code from git reset
From: Martin von Zweigbergk @ 2012-12-09 22:23 UTC (permalink / raw)
To: git
Hi,
"git reset" currently returns 0 (if successful) while "git reset
$pathspec" returns 0 iff the index matches HEAD after resetting (on
all paths, not just those matching $pathspec). The exit code doesn't
seem to be documented. Is there a reason they should behave
differently? If not, what would be the better behavior? I don't see
when the "git reset $pathspec" behavior" would be useful and it seems
safer for any existing scripts out there not to change the status code
for "git reset" (w/o paths). Scripts that run "git reset $pathspec"
probably already know to ignore (or use?) the exit code. Also, having
any non-zero exit code signal failure might actually be useful.
Changing "git reset $pathspec" to return 0 on success, regardless of
diff between HEAD and index, breaks 10 test cases (in
t2013-checkout-submodule.sh and t7102-reset.sh). These seem to do
"test_must_fail git reset $pathspec", but I have not been able to find
any motivation for expecting the failure.
It seems like this behavior has been there at least since the tests
were added in 359048d (Add tests for documented features of "git
reset"., 2007-09-11), just before reset became built-in.
Would a patch to change the exit code from "git reset $pathspec" be appreciated?
Martin
^ permalink raw reply
* Re: Weird problem with git-submodule.sh
From: Stefano Lattarini @ 2012-12-09 21:05 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Marc Branchaud, Git Mailing List
In-Reply-To: <7vobi5fu3c.fsf@alter.siamese.dyndns.org>
Hi Junio, Marc.
On 12/07/2012 10:08 PM, Junio C Hamano wrote:
> Marc Branchaud <marcnarc@xiplink.com> writes:
>
>> It's FreeBSD 7.2, which I know is an obsolete version but I'm not able to
>> upgrade the machine. I believe FreeBSD's sh is, or is derived from, dash.
>
> Finally. Yes, as you suspected, I am perfectly fine to explicitly
> set IFS to the default values.
>
> I wanted to have specific names to write in the commit log message,
> in-code comments and possibly release notes. That way, people can
> decide if the issue affects them and they should upgrade once the
> fix is made.
>
The Autoconf manual suggests against unsetting IFS instead of resetting
it to the default sequence for yet another reason: if IFS is unset, code
that tries to save and restore its value will incorrectly reset it to an
empty value, thus disabling field splitting:
unset IFS
# default separators used for field splitting
# ...
saved_IFS=$IFS
IFS=:
# code using the new IFS
IFS=$saved_IFS
# no field splitting performed from now on!
Not sure how this is relevant for the Git codebase, but maybe it is
something worth reporting in the commit message of a proposed patch.
Regards,
Stefano
^ permalink raw reply
* Re: [PATCH] git(1): remove a defunct link to "list of authors"
From: Nguyen Thai Ngoc Duy @ 2012-12-09 13:29 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vk3sthhfy.fsf@alter.siamese.dyndns.org>
On Sat, Dec 8, 2012 at 12:59 AM, Junio C Hamano <gitster@pobox.com> wrote:
>> * If somebody has a working replacement URL, we could use that
>> instead, of course. Takers?
>
> A possible alternative could be https://www.ohloh.net/p/git/contributors/summary
Nice charts!
--
Duy
^ permalink raw reply
* Re: [PATCH] gitk: read and write a repository specific configuration file
From: Lukasz Stelmach @ 2012-12-09 13:25 UTC (permalink / raw)
To: Paul Mackerras; +Cc: gitster, git, mbranchaud
In-Reply-To: <20121209104426.GA20818@bloggs.ozlabs.ibm.com>
W dniu 09.12.2012 11:44, Paul Mackerras pisze:
> On Sun, Dec 09, 2012 at 01:18:08AM -0800, Junio C Hamano wrote:
>> Łukasz Stelmach <stlman@poczta.fm> writes:
>>
>>> Enable gitk read and write repository specific configuration
>>> file: ".git/k" if the file exists. To make gitk use the local
>>> file simply create one, e.g. with the touch(1) command.
>>>
>>> This is very useful if one uses different views for different
>>> repositories. Now there is no need to store all of them in
>>> ~/.gitk and make the views list needlessly long.
>>
>> I do not use gitk heavily myself, but I have a mixed feeling about
>> this patch.
>
> I agree, I think this would be surprising to people who are used to
> the way gitk works now.
>
> I could imagine having a checkbox in the Edit->Preferences dialog to
> say "Save configuration settings locally", and if you check that box,
> then it writes the configuration to .git/gitkconfig or whatever
> (having first saved that setting in the global ~/.gitk).
No this isn't a good idea. When you choose to save configuration locally
it means you've alredy changed it to match your local needs and making
it global does not seem reasonable.
> But I think it should be an opt-in thing.
It is opt-in now definitely. One needs to create the local config file,
even an empty one, for gitk to choose it upon doquit/savestuff. I agree
a checkbox may be more convenient but is it "opty" (as in opt-in) enough?
Then, the checkbox should be added to both "Preferences" and "Edit View"
dialogs, anything more?
>> In any case, the filename .git/k may be _cute_, but I do not think
>> we would want to see:
>>
>> $ ls .git
>> branches config HEAD index k objects
>> COMMIT_EDITMSG description hooks info logs refs
>>
>> It is too cryptic, unless the user _knows_ 'k' is for gitk. I'd
>> call it $GIT_DIR/gitkconfig or something, if I were supportive for
>> this feature (which I am not enthusiastic, yet).
>
> I agree with this too.
Sure, let's vote:
a) .git/gitk
b) .git/gitkconfig
c) .git/gitkrc
--
Było mi bardzo miło. Czwarta pospolita klęska, [...]
>Łukasz< Już nie katolicka lecz złodziejska. (c)PP
^ permalink raw reply
* Re: [PATCH] gitk: read and write a repository specific configuration file
From: Lukasz Stelmach @ 2012-12-09 13:13 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, mbranchaud, paulus
In-Reply-To: <7vd2yjeg8f.fsf@alter.siamese.dyndns.org>
W dniu 09.12.2012 10:18, Junio C Hamano pisze:
> Łukasz Stelmach <stlman@poczta.fm> writes:
>
>> Enable gitk read and write repository specific configuration
>> file: ".git/k" if the file exists. To make gitk use the local
>> file simply create one, e.g. with the touch(1) command.
>>
>> This is very useful if one uses different views for different
>> repositories. Now there is no need to store all of them in
>> ~/.gitk and make the views list needlessly long.
>
> I do not use gitk heavily myself, but I have a mixed feeling about
> this patch.
>
> Forking the configuration from the one true ~/.gitk is easy; it is
> just the matter of copying it to repository specific location. Once
> forked, however, it is very hard to merge these configuration files
> sprinkled across repositories back, or more importantly, change the
> settings globally.
For the record, I assumed someone using git is capable of doing some
simple tricks with find, sed and the like.
Merging configuration from the global file (~/.gitk) is quite easy as
the file is sourced just before the local file. If any option is not set
in the local file the global value is effective.
To handle the case you describe below...
> Imagine you just got a new monitor that is a lot
> finer grained than the one you have been usingq, and your choice of
> font size has been specified in terms of pixels; you would want to
> show all gitk windows in larger font now, regardless of the
> repository, but you now have to go to 47 different configuration
> files and update them.
you need to (assume one keeps git repositoris below $HOME)
1. Enter a random repository
2. mv .git/gitk .git/gitk-local (see below)
3. Run gitk, configure fonts to your taste, save config (it will be
saved globally)
4. mv .git/gitk-local .git/gitk
4 Do a trick
$ find ../ -name gitk -type f -path '*/.git/gitk' -print0 | \
xargs -0 sed -i -e '/^set [a-z]\+font /d'
Now the font settings from ~/.gitk will be applied (and saved locally
when gitk exits) in every repository find(1) found.
> So I suspect that this may introduce more trouble than it is worth
> for users and should not be sold with a "This is very useful" label.
> At best, it is "This may be useful";
I work with more than two dozen different repositories and saving the
list of branches I want to see upon startup is quite important for me.
> otherwise the feature may end
> up harming our users. I'd phrase it without judging if it is good
> or bad for the users, perhaps like this:
>
> This allows one to specify different views for different
> repositories.
At present the code won't harm anyone not willing to get harmed. To make
gitk save the configuration locally user needs to create the
configuration file manually, outside of gitk, for example with touch(1)
(yes it may be empty).
> In any case, the filename .git/k may be _cute_, but I do not think
> we would want to see:
>
> $ ls .git
> branches config HEAD index k objects
> COMMIT_EDITMSG description hooks info logs refs
I agree this was just to draw your attention ;-)
> It is too cryptic, unless the user _knows_ 'k' is for gitk. I'd
> call it $GIT_DIR/gitkconfig or something, if I were supportive for
> this feature (which I am not enthusiastic, yet).
I think simply $GIT_DIR/gitk as in ~/.gitk is going to be fine.
--
Było mi bardzo miło. Czwarta pospolita klęska, [...]
>Łukasz< Już nie katolicka lecz złodziejska. (c)PP
^ permalink raw reply
* Re: [PATCH 8/8] t9402: Use TABs for indentation
From: John Szakmeister @ 2012-12-09 11:19 UTC (permalink / raw)
To: Torsten Bögershausen; +Cc: Junio C Hamano, git, mmogilvi_git
In-Reply-To: <50C4616D.9010801@web.de>
On Sun, Dec 9, 2012 at 5:01 AM, Torsten Bögershausen <tboegi@web.de> wrote:
[snip]
> PS: for some reason I don't get any mails to my
> (google) account any more, which I use to read the list.
> Am I the only one having this problem?
I noticed that the kernel.org lists are pretty unaccommodating. If
something hiccups in the delivery, it'll drop (or disable?) sending
emails to you. I've got some spam protection on my server that was
causing some issues occasionally when a lookup took to long. I
wouldn't be surprised if a hiccup occurs now and then with gmail, and
the same thing happens.
-John
^ permalink raw reply
* Re: [PATCH] git-clean: Display more accurate delete messages
From: Zoltan Klinger @ 2012-12-09 11:18 UTC (permalink / raw)
To: Soren Brinkmann; +Cc: Junio C Hamano, git
In-Reply-To: <7d290bdc-8654-4526-ba73-89408fa99a16@DB3EHSMHS002.ehs.local>
>> Hrm, following your discussion (ellided above), I would have
>> expected that you would show
>>
>> Removing directory foo/bar
>> Removing untracked_file1
>
> Also it would be nice to have warnings about undeleted directories since this git
> clean behavior (or the work around to pass -f twice) is not documented.
> Without a warning you would probably miss that something was _not_ deleted.
Thanks for the feedback. I think you're right. Showing 'foo/bar/bar.txt' in
the list when 'foo/bar/' directory has been successfully deleted is just noise.
Would like to get some more feedback on the proposed output in case of
(1) an untracked subdirectory with multiple files where at least one of them
cannot be removed.
(2) reporting ignored untracked git subdirectories
Suppose we have a repo like the one below:
test.git/
|-- tracked_file
|-- untracked_file
|-- untracked_foo/
| |-- bar/
| | |-- bar.txt
| |-- emptydir/
| |-- frotz.git/
| | |-- frotx.txt
| |-- quux/
| |-- failedquux.txt
| |-- quux.txt
|-- untracked_unreadable_dir/
| |-- afile
|-- untracked_some.git/
|-- some.txt
$ git clean -fd
Removing untracked_file
Removing untracked_foo/bar
Removing untracked_foo/emptydir
Removing untracked_foo/quux/quux.txt
warning: failed to remove untracked_foo/quux/failedquux.txt
warning: failed to remove remove untracked_unreadable_dir/
warning: ignoring untracked git repository untracked_foo/frotz.git/
warning: ignoring untracked git repository untracked_some.git/
Use git clean --force --force to delete all untracked git repositories
$ # use forced remove
$ git clean --force --force -d
Removing untracked_foo/frotz.git
Removing untracked_foo/quux/quux.txt
Removing untracked_some.git/
warning: failed to remove untracked_foo/quux/failedquux.txt
warning: failed to remove untracked_unreadable_dir/
Can you see any issues with the proposed output, wording above? If
everyone is happy,
I'm going to prepare patch V2 for it.
Thanks,
Zoltan
^ 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