RE: Feature Request - Hide ignored files before checkout
I'm glad we are on the same page now and thanks for bringing in others. Not wanting the files in the repository seems to be in conflict with the desire to have them under its control (i.e., disappear/reappear behavior.) Sorry, when I said I didn't want them in the repository, I meant I wanted them there (in the repository folder), but not within Git commit logs and not being tracked, etc. Committing binary/OS specific files just doesn't sit right with me and I am sure many others. ... but why do you need them to disappear? Why not just put them somewhere where they can be used when needed and left alone when not? I could do that (keep them in a folder that will be left alone), but in my specific case it would mean the executable files (ignored files placed in this new folder) will not execute because of the change in location and hence would require a lot of code change to suit. From my perspective I don't see the harm in having this as a new feature (via flags in the .gitignore file, if you don't want to make it default behaviour). Is there some reason I don't know about, maybe to do with the Git source code? -Original Message- From: chris.rorv...@gmail.com [mailto:chris.rorv...@gmail.com] On Behalf Of Chris Rorvick Sent: Sunday, 9 December 2012 4:54 PM To: Matthew Ciancio Cc: git@vger.kernel.org Subject: Re: Feature Request - Hide ignored files before checkout On Sat, Dec 8, 2012 at 6:06 PM, Matthew Ciancio matthew.cianci...@gmail.com wrote: Hi Chris, Yes, I don't think I have explained myself well enough. When I say disappear I do not mean get deleted, I mean: go out of view just like foo.txt does, as it is committed to branchB and not merged into branchA. So I am saying that I think .gitignored files should behave partly like committed and un-merged files, in the sense that they disappear when checking out to a different branch. I don't want to commit these files (which would give me the behaviour I want), because they are binary/OS specific and really do not belong in the repository, BUT I need them to run/build certain committed files. To be concrete: I want ignore.txt to be ignored in branchB and hence disappear (in the same way that foo.txt will), when checking out to branchA. When I checkout back to branchB I want ignore.txt to reappear (in the same way that foo.txt will). I understand why this behaviour is not happening (because my .gitignore files are different between the branches), but I am saying that I would like to have the option to keep my .gitignore'd files local to the branch they are in. E.g. I currently have a branch with all these binary files that are required to run an application on my OS, but when I checkout to another branch I do not need or want those binary files anymore (at least not until I checkout back into the branch I just came from). Please tell me if that still doesn't make sense. Hi Matthew, Cc'ing the list to benefit from the review of others. Not wanting the files in the repository seems to be in conflict with the desire to have them under its control (i.e., disappear/reappear behavior.) I understand not wanting to commit dependencies, but why do you need them to disappear? Why not just put them somewhere where they can be used when needed and left alone when not? If you do want this behavior, it seems like you should just commit the files on the respective branch. Maybe someone else will have a better idea, though. Chris -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Feature Request - Hide ignored files before checkout
Chris Rorvick ch...@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. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] gitk: read and write a repository specific configuration file
Łukasz Stelmach stl...@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. 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. 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; 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. In any case, the filename .git/k may be _cute_, but I do not think we would want to see: $ ls .git branchesconfig 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). Thanks. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] shortlog: Fix wrapping lines of wraplen
Steffen Prohaska proha...@zib.de writes:
A recent commit [1] fixed a off-by-one wrapping error. As
a side-effect, add_wrapped_shortlog_msg() needs to be changed to always
append a newline.
Could you clarify As a side effect a bit more? Do you mean
something like this?
Earlier strbuf_add_wrapped_text() ended its output with a
newline only when the end of the text exactly fitted in wrap
length, due to the off-by-one error fixed with 14e1a4e (utf8:
fix off-by-one wrapping of text, 2012-10-18). There was a hack
in add_wrapped_shortlog_msg() function to compensate for this
bug.
With the bug fixed, the function never ends its output with a
newline, and the caller needs to unconditionally add one.
[1] 14e1a4e1ff70aff36db3f5d2a8b806efd0134d50 utf8: fix off-by-one
wrapping of text
Signed-off-by: Steffen Prohaska proha...@zib.de
---
builtin/shortlog.c | 3 +--
t/t4201-shortlog.sh | 24
2 files changed, 25 insertions(+), 2 deletions(-)
diff --git a/builtin/shortlog.c b/builtin/shortlog.c
index b316cf3..db5b57d 100644
--- a/builtin/shortlog.c
+++ b/builtin/shortlog.c
@@ -307,8 +307,7 @@ static void add_wrapped_shortlog_msg(struct strbuf *sb,
const char *s,
const struct shortlog *log)
{
int col = strbuf_add_wrapped_text(sb, s, log-in1, log-in2, log-wrap);
- if (col != log-wrap)
- strbuf_addch(sb, '\n');
+ strbuf_addch(sb, '\n');
}
void shortlog_output(struct shortlog *log)
diff --git a/t/t4201-shortlog.sh b/t/t4201-shortlog.sh
index 6872ba1..02ac978 100755
--- a/t/t4201-shortlog.sh
+++ b/t/t4201-shortlog.sh
@@ -120,6 +120,30 @@ test_expect_success 'shortlog from non-git directory' '
test_cmp expect out
'
+test_expect_success 'shortlog should add newline when input line matches
wraplen' '
+ cat expect \EOF
+A U Thor (2):
+ bb: bbb bbb bb bbb b bb
+ aa: aa aa aa aa aaa
+
+EOF
+ git shortlog -w out \EOF
+commit 0001
+Author: A U Thor aut...@example.com
+Date: Thu Apr 7 15:14:13 2005 -0700
+
+aa: aa aa aa aa aaa
+
+commit 0002
+Author: A U Thor aut...@example.com
+Date: Thu Apr 7 15:14:13 2005 -0700
+
+bb: bbb bbb bb bbb b bb
+
+EOF
+ test_cmp expect out
+'
+
iconvfromutf8toiso88591() {
printf %s $* | iconv -f UTF-8 -t ISO8859-1
}
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 8/8] t9402: Use TABs for indentation
Torsten Bögershausen tbo...@web.de writes: Use TAB's for indentation Put the closing ' at the begin of the line Signed-off-by: Torsten Bögershausen tbo...@web.de --- The entire series looked cleanly done. I've tweaked the last patch a bit to wrap overlong lines, though. Thanks. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 8/8] t9402: Use TABs for indentation
On 09.12.12 10:43, Junio C Hamano wrote: Torsten Bögershausen tbo...@web.de writes: Use TAB's for indentation Put the closing ' at the begin of the line Signed-off-by: Torsten Bögershausen tbo...@web.de --- The entire series looked cleanly done. I've tweaked the last patch a bit to wrap overlong lines, though. Thanks. Thanks Junio, 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? -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] Makefile: whitespace style fixes in macro definitions
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.lattar...@gmail.com --- 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 :=
Re: [PATCH] gitk: read and write a repository specific configuration file
On Sun, Dec 09, 2012 at 01:18:08AM -0800, Junio C Hamano wrote: Łukasz Stelmach stl...@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). But I think it should be an opt-in thing. In any case, the filename .git/k may be _cute_, but I do not think we would want to see: $ ls .git branchesconfig 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. Paul. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] git-clean: Display more accurate delete messages
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 -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 8/8] t9402: Use TABs for indentation
On Sun, Dec 9, 2012 at 5:01 AM, Torsten Bögershausen tbo...@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 -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] gitk: read and write a repository specific configuration file
W dniu 09.12.2012 10:18, Junio C Hamano pisze: Łukasz Stelmach stl...@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 branchesconfig 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 -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] gitk: read and write a repository specific configuration file
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 stl...@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 branchesconfig 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 -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] git(1): remove a defunct link to list of authors
On Sat, Dec 8, 2012 at 12:59 AM, Junio C Hamano gits...@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 -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Weird problem with git-submodule.sh
Hi Junio, Marc. On 12/07/2012 10:08 PM, Junio C Hamano wrote: Marc Branchaud marcn...@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 -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: Feature Request - Hide ignored files before checkout
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:gits...@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 ch...@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. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: exit code from git reset
Martin von Zweigbergk martinv...@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. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: exit code from git reset
On Sun, Dec 9, 2012 at 3:04 PM, Junio C Hamano gits...@pobox.com wrote: Martin von Zweigbergk martinv...@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. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Feature Request - Hide ignored files before checkout
Hi Matt, On 8 December 2012 11:50, Matthew Ciancio matthew.cianci...@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 -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: Feature Request - Hide ignored files before checkout
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.ard...@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.cianci...@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 -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] gitweb: Sort projects with undefined ages last
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 mat...@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
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] gitweb: Sort projects with undefined ages last
Matthew Daley mat...@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 mat...@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.
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] git(1): remove a defunct link to list of authors
Nguyen Thai Ngoc Duy pclo...@gmail.com writes: On Sat, Dec 8, 2012 at 12:59 AM, Junio C Hamano gits...@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. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] cache-tree: invalidate i-t-a paths after generating trees
Nguyễn Thái Ngọc Duy pclo...@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
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] git-clean: Display more accurate delete messages
Zoltan Klinger zoltan.klin...@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. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
