* Re: [PATCH] git(1): remove a defunct link to "list of authors"
From: Junio C Hamano @ 2012-12-07 17:59 UTC (permalink / raw)
To: git
In-Reply-To: <7vobi5hhn9.fsf@alter.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> The linked page has not been showing the promised "more complete
> list" for more than 6 months by now, and nobody has resurrected
> the list there nor elsewhere since then.
>
> Signed-off-by: Junio C Hamano <gitster@pobox.com>
> ---
> * 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
^ permalink raw reply
* [PATCH] git(1): remove a defunct link to "list of authors"
From: Junio C Hamano @ 2012-12-07 17:54 UTC (permalink / raw)
To: git
The linked page has not been showing the promised "more complete
list" for more than 6 months by now, and nobody has resurrected
the list there nor elsewhere since then.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
* If somebody has a working replacement URL, we could use that
instead, of course. Takers?
Documentation/git.txt | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git c/Documentation/git.txt w/Documentation/git.txt
index cbe0883..5133952 100644
--- c/Documentation/git.txt
+++ w/Documentation/git.txt
@@ -868,8 +868,7 @@ Authors
-------
Git was started by Linus Torvalds, and is currently maintained by Junio
C Hamano. Numerous contributions have come from the git mailing list
-<git@vger.kernel.org>. For a more complete list of contributors, see
-http://git-scm.com/about. If you have a clone of git.git itself, the
+<git@vger.kernel.org>. If you have a clone of git.git itself, the
output of linkgit:git-shortlog[1] and linkgit:git-blame[1] can show you
the authors for specific parts of the project.
^ permalink raw reply related
* Re: Weird problem with git-submodule.sh
From: Junio C Hamano @ 2012-12-07 17:54 UTC (permalink / raw)
To: Marc Branchaud; +Cc: Git Mailing List
In-Reply-To: <50C22B15.1030607@xiplink.com>
Marc Branchaud <marcnarc@xiplink.com> writes:
> This is with git 1.8.0.1 on all the machines involved.
>
> One of our build machines is having trouble with "git submodule":
> ...
> Any ideas?
How and why is the IFS set differently only on one of your build
machines?
^ permalink raw reply
* Weird problem with git-submodule.sh
From: Marc Branchaud @ 2012-12-07 17:44 UTC (permalink / raw)
To: Git Mailing List
Hi all,
This is with git 1.8.0.1 on all the machines involved.
One of our build machines is having trouble with "git submodule":
$ git submodule init external/openssl
No submodule mapping found in .gitmodules for path ''
(.gitmodules and other aspects of the repo are fine -- the submodules work
perfectly on other machines.)
The problem seems to be in cmd_init() with the construct
module_list "$@" |
while read mode sha1 stage sm_path
do
...
Explicitly setting IFS before the call to module_list makes it work:
IFS=" "
module_list "$@" |
while read mode sha1 stage sm_path
do
...
If IFS is unset, the "while read" loop ends up with everything in the $mode
variable, and the other 3 variables are empty.
If I isolate module_list() and a simple "while read" loop into a standalone
script, like this:
module_list()
{
...
}
module_list "$@" |
while read mode sha1 stage sm_path
do
echo - $mode - $sha1 - $stage - $sm_path -
done
It works -- each individual variable is set properly.
It seems that the problem only occurs inside git-submodule.sh.
Any ideas?
M.
^ permalink raw reply
* Re: [PATCH] completion: add option --recurse-submodules to "git push"
From: Junio C Hamano @ 2012-12-07 17:21 UTC (permalink / raw)
To: Steffen Jaeckel; +Cc: git, Heiko Voigt, Felipe Contreras
In-Reply-To: <1354883304-6860-1-git-send-email-steffen.jaeckel@stzedn.de>
Steffen Jaeckel <steffen.jaeckel@stzedn.de> writes:
> Signed-off-by: Steffen Jaeckel <steffen.jaeckel@stzedn.de>
> ---
> contrib/completion/git-completion.bash | 9 +++++++++
> 1 file changed, 9 insertions(+)
>
> diff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash
> index 0b77eb1..5b4d2e1 100644
> --- a/contrib/completion/git-completion.bash
> +++ b/contrib/completion/git-completion.bash
> @@ -1434,6 +1434,10 @@ _git_pull ()
> __git_complete_remote_or_refspec
> }
>
> +__git_push_recurse_submodules_options="
> + check on-demand
> +"
Most of the existing completion functions do not seem to define
separate variables like this; instead, they literally embed their
choices at the point of use.
Is it expected that the same set of choices will appear in the
completion of many other subcommand options? [jc: Cc'ed Heiko so
that we can sanity check the answer to this question]. If so, the
variable may be justified; otherwise, not.
> _git_push ()
> {
> case "$prev" in
> @@ -1446,10 +1450,15 @@ _git_push ()
> __gitcomp_nl "$(__git_remotes)" "" "${cur##--repo=}"
> return
> ;;
> + --recurse-submodules=*)
> + __gitcomp "$__git_push_recurse_submodules_options" "" "${cur##--recurse-submodules=}"
> + return
> + ;;
Owners of the completion script, does this look reasonable?
[jc: Cc'ed Felipe for this]
This is a tangent, but why is it a double-hash "##" not a
single-hash "#", other than "because all others use ##"?
> --*)
> __gitcomp "
> --all --mirror --tags --dry-run --force --verbose
> --receive-pack= --repo= --set-upstream
> + --recurse-submodules=
> "
> return
> ;;
^ permalink raw reply
* RE: any way to re-release git's block sha1 implementation under a different license?
From: Pyeron, Jason J CTR (US) @ 2012-12-07 14:39 UTC (permalink / raw)
To: git@vger.kernel.org
In-Reply-To: <CAFBatg3AcjOjQqKJrRe_fkva8OD=F=5aS7kczF3e1ePw_KcJng@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 746 bytes --]
> -----Original Message-----
> From: Liu Liu
> Sent: Friday, December 07, 2012 2:52 AM
>
> Hi,
>
> I am reaching out because in my personal project (
> https://github.com/liuliu/ccv
> ), I used the block sha1 implementation (
> https://github.com/git/git/blob/master/block-sha1/sha1.c) in git. It is
> a
> fast, generalized and standalone implementation, however, since it is a
> part of git, it is under GPL license. Is there any possibilities for
> the
> original author/authors to release this particular piece of code under
> BSD
> / MIT or Apache license? Thanks!
Worse comes to worse, use the Mozilla code it was based on. Assumption is that the original code was under the http://en.wikipedia.org/wiki/Mozilla_Public_License
-Jason
[-- Attachment #2: smime.p7s --]
[-- Type: application/x-pkcs7-signature, Size: 5615 bytes --]
^ permalink raw reply
* [PATCH 2/2] fetch-pack: avoid repeatedly re-scanning pack directory
From: Jeff King @ 2012-12-07 14:04 UTC (permalink / raw)
To: git
In-Reply-To: <20121207135351.GA10538@sigill.intra.peff.net>
When we look up a sha1 object for reading, we first check
packfiles, and then loose objects. If we still haven't found
it, we re-scan the list of packfiles in `objects/pack`. This
final step ensures that we can co-exist with a simultaneous
repack process which creates a new pack and then prunes the
old object.
This extra re-scan usually does not have a performance
impact for two reasons:
1. If an object is missing, then typically the re-scan
will find a new pack, then no more misses will occur.
Or if it truly is missing, then our next step is
usually to die().
2. Re-scanning is cheap enough that we do not even notice.
However, these do not always hold. The assumption in (1) is
that the caller is expecting to find the object. This is
usually the case, but the call to `parse_object` in
`everything_local` does not follow this pattern. It is
looking to see whether we have objects that the remote side
is advertising, not something we expect to have. Therefore
if we are fetching from a remote which has many refs
pointing to objects we do not have, we may end up
re-scanning the pack directory many times.
Even with this extra re-scanning, the impact is often not
noticeable due to (2); we just readdir() the packs directory
and skip any packs that are already loaded. However, if
there are a large number of packs, then even enumerating the
directory directory can be expensive (especially if we do it
repeatedly). Having this many packs is a good sign the user
should run `git gc`, but it would still be nice to avoid
having to scan the directory at all.
This patch checks has_sha1_file (which does not have the
re-scan and re-check behavior) in the critical loop, and
avoids calling parse_object at all if we do not have the
object.
Signed-off-by: Jeff King <peff@peff.net>
---
I'm lukewarm on this patch. The re-scan _shouldn't_ be that expensive,
so maybe patch 1 is enough to be a reasonable fix. The fact that we
re-scan repeatedly seems ugly and hacky to me, but it really is just
opendir/readdir/closedir in the case that nothing has changed (and if
something has changed, then it's a good thing to be checking). And with
my patch, fetch-pack would not notice new packs from a simultaneous
repack process (although it's OK, as the result is not incorrect, but
merely that we may ask for the object from the server).
Another option would be to make the reprepare_packed_git re-scan less
expensive by checking the mtime of the directory before scanning it.
fetch-pack.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/fetch-pack.c b/fetch-pack.c
index 099ff4d..b4383c6 100644
--- a/fetch-pack.c
+++ b/fetch-pack.c
@@ -594,6 +594,9 @@ static int everything_local(struct fetch_pack_args *args,
for (ref = *refs; ref; ref = ref->next) {
struct object *o;
+ if (!has_sha1_file(ref->old_sha1))
+ continue;
+
o = parse_object(ref->old_sha1);
if (!o)
continue;
--
1.8.1.rc0.4.g5948dfd.dirty
^ permalink raw reply related
* [PATCH 1/2] fetch: run gc --auto after fetching
From: Jeff King @ 2012-12-07 13:58 UTC (permalink / raw)
To: git
In-Reply-To: <20121207135351.GA10538@sigill.intra.peff.net>
We generally try to run "gc --auto" after any commands that
might introduce a large number of new objects. An obvious
place to do so is after running "fetch", which may introduce
new loose objects or packs (depending on the size of the
fetch).
While an active developer repository will probably
eventually trigger a "gc --auto" on another action (e.g.,
git-rebase), there are two good reasons why it is nicer to
do it at fetch time:
1. Read-only repositories which track an upstream (e.g., a
continuous integration server which fetches and builds,
but never makes new commits) will accrue loose objects
and small packs, but never coalesce them into a more
efficient larger pack.
2. Fetching is often already perceived to be slow to the
user, since they have to wait on the network. It's much
more pleasant to include a potentially slow auto-gc as
part of the already-long network fetch than in the
middle of productive work with git-rebase or similar.
Signed-off-by: Jeff King <peff@peff.net>
---
The original "gc --auto" patch in 2007 suggested adding this to fetch,
but we never did (there was some brief mention that maybe tweaking
fetch.unpacklimit would be relevant, but I think you would eventually
want to gc, whether you are accruing packs or loose objects).
I didn't bother protecting this with an option (as we do for
receive.gc). I don't see much point, as anybody who doesn't want gc on
their client repos will already have set gc.auto to prevent it from
triggering via other commands).
builtin/fetch.c | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/builtin/fetch.c b/builtin/fetch.c
index 4b5a898..1ddbf0d 100644
--- a/builtin/fetch.c
+++ b/builtin/fetch.c
@@ -959,6 +959,9 @@ int cmd_fetch(int argc, const char **argv, const char *prefix)
struct string_list list = STRING_LIST_INIT_NODUP;
struct remote *remote;
int result = 0;
+ static const char *argv_gc_auto[] = {
+ "gc", "--auto", NULL,
+ };
packet_trace_identity("fetch");
@@ -1026,5 +1029,7 @@ int cmd_fetch(int argc, const char **argv, const char *prefix)
list.strdup_strings = 1;
string_list_clear(&list, 0);
+ run_command_v_opt(argv_gc_auto, RUN_GIT_CMD);
+
return result;
}
--
1.8.1.rc0.4.g5948dfd.dirty
^ permalink raw reply related
* [PATCH 0/2] make repeated fetch faster on "read only" repos
From: Jeff King @ 2012-12-07 13:53 UTC (permalink / raw)
To: git
Like many dev shops, we run a CI server that basically does:
git fetch $some_branch &&
git checkout $some_branch &&
make test
all day long. Sometimes the fetches would get very slow, and the problem
turned out to be a combination of:
1. Never running "git gc". This means you can end up with a ton of
loose objects, or even a bunch of small packs[1].
2. One of the loops in fetch caused us to re-scan the entire
objects/pack directory repeatedly, proportional to the number of
refs on the remote.
I think the fundamental fix is to gc more often, as it makes the re-scans
less expensive, along with making general object lookup faster. But the
repeated re-scans strike me as kind of hacky. This series tries to
address both:
[1/2]: fetch: run gc --auto after fetching
[2/2]: fetch-pack: avoid repeatedly re-scanning pack directory
-Peff
[1] It turns out we had our transfer.unpacklimit set unreasonably low,
leading to a large number of tiny packs, but even with the defaults,
you will end up with a ton of loose objects if you do repeated small
fetches.
^ permalink raw reply
* [PATCH] completion: add option --recurse-submodules to "git push"
From: Steffen Jaeckel @ 2012-12-07 12:28 UTC (permalink / raw)
To: git; +Cc: Steffen Jaeckel
Signed-off-by: Steffen Jaeckel <steffen.jaeckel@stzedn.de>
---
contrib/completion/git-completion.bash | 9 +++++++++
1 file changed, 9 insertions(+)
diff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash
index 0b77eb1..5b4d2e1 100644
--- a/contrib/completion/git-completion.bash
+++ b/contrib/completion/git-completion.bash
@@ -1434,6 +1434,10 @@ _git_pull ()
__git_complete_remote_or_refspec
}
+__git_push_recurse_submodules_options="
+ check on-demand
+"
+
_git_push ()
{
case "$prev" in
@@ -1446,10 +1450,15 @@ _git_push ()
__gitcomp_nl "$(__git_remotes)" "" "${cur##--repo=}"
return
;;
+ --recurse-submodules=*)
+ __gitcomp "$__git_push_recurse_submodules_options" "" "${cur##--recurse-submodules=}"
+ return
+ ;;
--*)
__gitcomp "
--all --mirror --tags --dry-run --force --verbose
--receive-pack= --repo= --set-upstream
+ --recurse-submodules=
"
return
;;
--
1.8.0.msysgit.0
^ permalink raw reply related
* Re: Please pull l10n updates for 1.8.1 round 2
From: Jiang Xin @ 2012-12-07 9:41 UTC (permalink / raw)
To: Peter Krefting, Junio C Hamano
Cc: Ralf Thielow, Tr¥n Ng÷c Quân, Git List
In-Reply-To: <alpine.DEB.2.00.1212061249040.25550@ds9.cixit.se>
oops, I missed Peter's email, and the following pull request includes
both Peter and Ralf commits.
The following changes since commit f94c3251e1400c3cf349f7f84fea4db66b540113:
Update draft release notes to 1.8.1 (2012-11-29 13:57:09 -0800)
are available in the git repository at:
git://github.com/git-l10n/git-po master
for you to fetch changes up to 167e2f91150304ed1f7b24659101aae19c01e30d:
Merge branch git://github.com/ralfth/git-po-de (2012-12-07 17:30:02 +0800)
----------------------------------------------------------------
Jiang Xin (2):
l10n: Update git.pot (5 new, 1 removed messages)
Merge branch git://github.com/ralfth/git-po-de
Peter Krefting (1):
l10n: Update Swedish translation (1979t0f0u)
Ralf Thielow (2):
l10n: de.po: translate 825 new messages
l10n: de.po: translate 22 new messages
Tran Ngoc Quan (1):
l10n: vi.po: update to git-v1.8.0.1-347-gf94c3
po/de.po | 5157 ++++++++++++++++++++++++++++++++++++++++++++++++++----------
po/git.pot | 46 +-
po/sv.po | 53 +-
po/vi.po | 63 +-
4 files changed, 4466 insertions(+), 853 deletions(-)
2012/12/6 Peter Krefting <peter@softwolves.pp.se>:
> Jiang Xin:
>
>
>> The following changes since commit
>> f94c3251e1400c3cf349f7f84fea4db66b540113:
>>
>> Update draft release notes to 1.8.1 (2012-11-29 13:57:09 -0800)
>>
>> are available in the git repository at:
>>
>> git://github.com/git-l10n/git-po master
>>
>> for you to fetch changes up to 77cc392d6d60c5d22930174904adae182502b8a9:
>>
>> l10n: vi.po: update to git-v1.8.0.1-347-gf94c3 (2012-11-30 13:43:11
>> +0700)
>
>
> This doesn't seem to contain the update to the Swedish translation that I
> committed in https://github.com/nafmo/git-l10n-sv (commit
> bf3e8fe0c718b64b7e88bd3d74564c54f923aaed). Did I forgot to post a pull
> request to you, or what happened?
>
> --
> \\// Peter - http://www.softwolves.pp.se/
--
蒋鑫
北京群英汇信息技术有限公司
邮件: worldhello.net@gmail.com
网址: http://www.ossxp.com/
博客: http://www.worldhello.net/
微博: http://weibo.com/gotgit/
电话: 010-51262007, 18601196889
^ permalink raw reply
* any way to re-release git's block sha1 implementation under a different license?
From: Liu Liu @ 2012-12-07 7:51 UTC (permalink / raw)
To: git
Hi,
I am reaching out because in my personal project (
https://github.com/liuliu/ccv
), I used the block sha1 implementation (
https://github.com/git/git/blob/master/block-sha1/sha1.c) in git. It is a
fast, generalized and standalone implementation, however, since it is a
part of git, it is under GPL license. Is there any possibilities for the
original author/authors to release this particular piece of code under BSD
/ MIT or Apache license? Thanks!
---
Liu Liu
http://liuliu.me
http://facebook.com/liu.ll
^ permalink raw reply
* Re: [PATCH] git-clean: Display more accurate delete messages
From: Soren Brinkmann @ 2012-12-07 0:15 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Zoltan Klinger, git
In-Reply-To: <7v8v9bjd44.fsf@alter.siamese.dyndns.org>
Hi,
On Thu, Dec 06, 2012 at 09:37:31AM -0800, Junio C Hamano wrote:
> Zoltan Klinger <zoltan.klinger@gmail.com> writes:
>
> > Only print out the names of the files and directories that got actually
> > deleted.
> >
> > Consider the following repo layout:
> > |-- test.git/
> > |-- foo/
> > |-- bar/
> > |-- bar.txt
> > |-- frotz.git/
> > |-- frotz.txt
> > |-- tracked_file1
> > |-- untracked_file1
> > ...
> > Consider the output of the improved version:
> >
> > $ git clean -fd
> > Removed foo/bar/bar.txt
> > Removed foo/bar
> > Removed untracked_file1
>
> 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.
So something like:
Removing foo
Removing bar
...
Warning: Not all untracked objects have been deleted:
<list objects here> (optional)
Use git clean --force --force to delete all objects.
But clearly going into a good direction. Thanks.
Soren
^ permalink raw reply
* What's cooking in git.git (Dec 2012, #01; Thu, 6)
From: Junio C Hamano @ 2012-12-06 22:01 UTC (permalink / raw)
To: git
Here are the topics that have been cooking. Commits prefixed with
'-' are only in 'pu' (proposed updates) while commits prefixed with
'+' are in 'next'.
All the topics still in 'next' are high-impact enough to deserve
getting cooked a bit longer, rather than risking potential
regression to the upcoming release. v1.8.1-rc1 will be tagged
sometime this weekend (cf. http://tinyurl.com/gitCal).
You can find the changes described here in the integration branches of the
repositories listed at
http://git-blame.blogspot.com/p/git-public-repositories.html
--------------------------------------------------
[New Topics]
* ef/mingw-tty-getpass (2012-12-04) 6 commits
- mingw: get rid of getpass implementation
- mingw: reuse tty-version of git_terminal_prompt
- compat/terminal: separate input and output handles
- compat/terminal: factor out echo-disabling
- mingw: make fgetc raise SIGINT if apropriate
- mingw: correct exit-code for SIGALRM's SIG_DFL
Update getpass() emulation for MinGW.
Will merge to 'next'.
* jl/submodule-deinit (2012-12-04) 1 commit
- submodule: add 'deinit' command
There was no Porcelain way to say "I no longer am interested in
this submodule", once you express your interest in a submodule with
"submodule init". "submodule deinit" is the way to do so.
Will merge to 'next'.
* sl/git-svn-docs (2012-12-05) 4 commits
- git-svn: Note about tags.
- git-svn: Expand documentation for --follow-parent
- git-svn: Recommend use of structure options.
- git-svn: Document branches with at-sign(@).
Will merge to 'next'.
--------------------------------------------------
[Stalled]
* mo/cvs-server-updates (2012-10-16) 10 commits
- cvsserver Documentation: new cvs ... -r support
- cvsserver: add t9402 to test branch and tag refs
- cvsserver: support -r and sticky tags for most operations
- cvsserver: Add version awareness to argsfromdir
- cvsserver: generalize getmeta() to recognize commit refs
- cvsserver: implement req_Sticky and related utilities
- cvsserver: add misc commit lookup, file meta data, and file listing functions
- cvsserver: define a tag name character escape mechanism
- cvsserver: cleanup extra slashes in filename arguments
- cvsserver: factor out git-log parsing logic
Needs review by folks interested in cvsserver.
* as/check-ignore (2012-11-08) 14 commits
- t0007: fix tests on Windows
- Documentation/check-ignore: we show the deciding match, not the first
- Add git-check-ignore sub-command
- dir.c: provide free_directory() for reclaiming dir_struct memory
- pathspec.c: move reusable code from builtin/add.c
- dir.c: refactor treat_gitlinks()
- dir.c: keep track of where patterns came from
- dir.c: refactor is_path_excluded()
- dir.c: refactor is_excluded()
- dir.c: refactor is_excluded_from_list()
- dir.c: rename excluded() to is_excluded()
- dir.c: rename excluded_from_list() to is_excluded_from_list()
- dir.c: rename path_excluded() to is_path_excluded()
- dir.c: rename cryptic 'which' variable to more consistent name
Duy helped to reroll this.
Expecting a re-roll.
* aw/rebase-am-failure-detection (2012-10-11) 1 commit
- rebase: Handle cases where format-patch fails
I am unhappy a bit about the possible performance implications of
having to store the output in a temporary file only for a rare case
of format-patch aborting.
* jk/lua-hackery (2012-10-07) 6 commits
- pretty: fix up one-off format_commit_message calls
- Minimum compilation fixup
- Makefile: make "lua" a bit more configurable
- add a "lua" pretty format
- add basic lua infrastructure
- pretty: make some commit-parsing helpers more public
Interesting exercise. When we do this for real, we probably would want
to wrap a commit to make it more like an "object" with methods like
"parents", etc.
* fc/remote-testgit-feature-done (2012-10-29) 1 commit
- remote-testgit: properly check for errors
Needs review and Ack (or Nack) from people involved in the remote
helper interface for this to move forward.
* rc/maint-complete-git-p4 (2012-09-24) 1 commit
(merged to 'next' on 2012-10-29 at af52cef)
+ Teach git-completion about git p4
Comment from Pete will need to be addressed in a follow-up patch.
* as/test-tweaks (2012-09-20) 7 commits
- tests: paint unexpectedly fixed known breakages in bold red
- tests: test the test framework more thoroughly
- [SQUASH] t/t0000-basic.sh: quoting of TEST_DIRECTORY is screwed up
- tests: refactor mechanics of testing in a sub test-lib
- tests: paint skipped tests in bold blue
- tests: test number comes first in 'not ok $count - $message'
- tests: paint known breakages in bold yellow
Various minor tweaks to the test framework to paint its output
lines in colors that match what they mean better.
Has the "is this really blue?" issue Peff raised resolved???
* jc/maint-name-rev (2012-09-17) 7 commits
- describe --contains: use "name-rev --algorithm=weight"
- name-rev --algorithm=weight: tests and documentation
- name-rev --algorithm=weight: cache the computed weight in notes
- name-rev --algorithm=weight: trivial optimization
- name-rev: --algorithm option
- name_rev: clarify the logic to assign a new tip-name to a commit
- name-rev: lose unnecessary typedef
"git name-rev" names the given revision based on a ref that can be
reached in the smallest number of steps from the rev, but that is
not useful when the caller wants to know which tag is the oldest one
that contains the rev. This teaches a new mode to the command that
uses the oldest ref among those which contain the rev.
I am not sure if this is worth it; for one thing, even with the help
from notes-cache, it seems to make the "describe --contains" even
slower. Also the command will be unusably slow for a user who does
not have a write access (hence unable to create or update the
notes-cache).
Stalled mostly due to lack of responses.
* jc/xprm-generation (2012-09-14) 1 commit
- test-generation: compute generation numbers and clock skews
A toy to analyze how bad the clock skews are in histories of real
world projects.
Stalled mostly due to lack of responses.
* jc/blame-no-follow (2012-09-21) 2 commits
- blame: pay attention to --no-follow
- diff: accept --no-follow option
Teaches "--no-follow" option to "git blame" to disable its
whole-file rename detection.
Stalled mostly due to lack of responses.
* jc/doc-default-format (2012-11-26) 2 commits
- [SQAUSH] allow "cd Doc* && make DEFAULT_DOC_TARGET=..."
- Allow generating a non-default set of documentation
Need to address the installation half if this is to be any useful.
* mk/maint-graph-infinity-loop (2012-09-25) 1 commit
- graph.c: infinite loop in git whatchanged --graph -m
The --graph code fell into infinite loop when asked to do what the
code did not expect ;-)
Anybody who worked on "--graph" wants to comment?
Stalled mostly due to lack of responses.
* jc/add-delete-default (2012-08-13) 1 commit
- git add: notice removal of tracked paths by default
"git add dir/" updated modified files and added new files, but does
not notice removed files, which may be "Huh?" to some users. They
can of course use "git add -A dir/", but why should they?
Resurrected from graveyard, as I thought it was a worthwhile thing
to do in the longer term.
Waiting for comments.
* mb/remote-default-nn-origin (2012-07-11) 6 commits
- Teach get_default_remote to respect remote.default.
- Test that plain "git fetch" uses remote.default when on a detached HEAD.
- Teach clone to set remote.default.
- Teach "git remote" about remote.default.
- Teach remote.c about the remote.default configuration setting.
- Rename remote.c's default_remote_name static variables.
When the user does not specify what remote to interact with, we
often attempt to use 'origin'. This can now be customized via a
configuration variable.
Expecting a re-roll.
"The first remote becomes the default" bit is better done as a
separate step.
--------------------------------------------------
[Cooking]
* pf/editor-ignore-sigint (2012-12-02) 5 commits
- launch_editor: propagate signals from editor to git
- run-command: do not warn about child death from terminal
- launch_editor: ignore terminal signals while editor has control
- launch_editor: refactor to use start/finish_command
- run-command: drop silent_exec_failure arg from wait_or_whine
Avoid confusing cases where the user hits Ctrl-C while in the editor
session, not realizing git will receive the signal. Since most editors
will take over the terminal and will block SIGINT, this is not likely
to confuse anyone.
Will merge to 'next'.
* bc/append-signed-off-by (2012-11-26) 11 commits
- Unify appending signoff in format-patch, commit and sequencer
- format-patch: update append_signoff prototype
- format-patch: stricter S-o-b detection
- t4014: more tests about appending s-o-b lines
- sequencer.c: teach append_signoff to avoid adding a duplicate newline
- sequencer.c: teach append_signoff how to detect duplicate s-o-b
- sequencer.c: always separate "(cherry picked from" from commit body
- sequencer.c: recognize "(cherry picked from ..." as part of s-o-b footer
- t/t3511: add some tests of 'cherry-pick -s' functionality
- t/test-lib-functions.sh: allow to specify the tag name to test_commit
- sequencer.c: remove broken support for rfc2822 continuation in footer
Expecting a re-roll after a review.
* mh/unify-xml-in-imap-send-and-http-push (2012-12-02) 8 commits
(merged to 'next' on 2012-12-03 at d677090)
+ wrap_in_html(): process message in bulk rather than line-by-line
+ wrap_in_html(): use strbuf_addstr_xml_quoted()
+ imap-send: change msg_data from storing (ptr, len) to storing strbuf
+ imap-send: correctly report errors reading from stdin
+ imap-send: store all_msgs as a strbuf
+ lf_to_crlf(): NUL-terminate msg_data::data
+ xml_entities(): use function strbuf_addstr_xml_quoted()
+ Add new function strbuf_add_xml_quoted()
Update imap-send to reuse xml quoting code from http-push codepath,
clean up some code, and fix a small bug.
* rr/t4041-cleanup (2012-12-02) 4 commits
(merged to 'next' on 2012-12-04 at ecee35d)
+ t4041 (diff-submodule-option): modernize style
+ t4041 (diff-submodule-option): rewrite add_file() routine
+ t4041 (diff-submodule-option): parse digests sensibly
+ t4041 (diff-submodule-option): don't hardcode SHA-1 in expected outputs
Test clean-up.
* jc/doc-maintainer (2012-11-27) 1 commit
- update "howto maintain git"
An early draft that is still incomplete.
* jk/fsck-dot-in-trees (2012-11-28) 2 commits
(merged to 'next' on 2012-11-28 at 519dabc)
+ fsck: warn about ".git" in trees
+ fsck: warn about '.' and '..' in trees
Will cook in 'next'.
* mh/doc-remote-helpers (2012-11-27) 6 commits
- git-remote-helpers.txt: clarify options & ref list attributes
- git-remote-helpers.txt: clarify command <-> capability correspondences
- git-remote-helpers.txt: rearrange description of capabilities
- git-remote-helpers.txt: minor grammar fix
- git-remote-helpers.txt: document missing capabilities
- git-remote-helpers.txt: document invocation before input format
Need comment and Ack from people who have worked on remote-helpers
before this goes forward.
* mh/pthreads-autoconf (2012-11-27) 1 commit
(merged to 'next' on 2012-11-28 at 780600e)
+ configure.ac: fix pthreads detection on Mac OS X
Will cook in 'next'.
* jn/warn-on-inaccessible-loosen (2012-10-14) 4 commits
(merged to 'next' on 2012-11-28 at 43d51c2)
+ config: exit on error accessing any config file
+ doc: advertise GIT_CONFIG_NOSYSTEM
+ config: treat user and xdg config permission problems as errors
+ config, gitignore: failure to access with ENOTDIR is ok
An RFC to deal with a situation where .config/git is a file and we
notice .config/git/config is not readable due to ENOTDIR, not
ENOENT.
Will cook in 'next'.
* mh/ceiling (2012-10-29) 8 commits
(merged to 'next' on 2012-11-26 at d1ce76a)
+ string_list_longest_prefix(): remove function
+ setup_git_directory_gently_1(): resolve symlinks in ceiling paths
+ longest_ancestor_length(): require prefix list entries to be normalized
+ longest_ancestor_length(): take a string_list argument for prefixes
+ longest_ancestor_length(): use string_list_split()
+ Introduce new function real_path_if_valid()
+ real_path_internal(): add comment explaining use of cwd
+ Introduce new static function real_path_internal()
Elements of GIT_CEILING_DIRECTORIES list may not match the real
pathname we obtain from getcwd(), leading the GIT_DIR discovery
logic to escape the ceilings the user thought to have specified.
Resurrected from Stalled; the earlier performance fear was
unwarranted.
Will cook in 'next'.
* fc/fast-export-fixes (2012-12-03) 15 commits
(merged to 'next' on 2012-12-03 at f9df523)
+ fast-export: make sure updated refs get updated
+ fast-export: don't handle uninteresting refs
+ fast-export: fix comparison in tests
+ fast-export: trivial cleanup
+ remote-testgit: implement the "done" feature manually
+ remote-testgit: report success after an import
+ remote-testgit: exercise more features
+ remote-testgit: cleanup tests
+ remote-testgit: remove irrelevant test
+ remote-testgit: remove non-local functionality
+ Add new simplified git-remote-testgit
+ Rename git-remote-testgit to git-remote-testpy
+ remote-helpers: fix failure message
+ remote-testgit: fix direction of marks
+ fast-export: avoid importing blob marks
Will cook in 'next'.
* jc/apply-trailing-blank-removal (2012-10-12) 1 commit
(merged to 'next' on 2012-11-26 at 3af69e7)
+ apply.c:update_pre_post_images(): the preimage can be truncated
Fix to update_pre_post_images() that did not take into account the
possibility that whitespace fix could shrink the preimage and
change the number of lines in it.
Will cook in 'next'.
* nd/pathspec-wildcard (2012-11-26) 4 commits
(merged to 'next' on 2012-12-03 at eca0fcb)
+ tree_entry_interesting: do basedir compare on wildcard patterns when possible
+ pathspec: apply "*.c" optimization from exclude
+ pathspec: do exact comparison on the leading non-wildcard part
+ pathspec: save the non-wildcard length part
Will cook in 'next'.
* nd/wildmatch (2012-11-20) 14 commits
(merged to 'next' on 2012-11-21 at 151288f)
+ test-wildmatch: avoid Windows path mangling
(merged to 'next' on 2012-10-25 at 510e8df)
+ Support "**" wildcard in .gitignore and .gitattributes
+ wildmatch: make /**/ match zero or more directories
+ wildmatch: adjust "**" behavior
+ wildmatch: fix case-insensitive matching
+ wildmatch: remove static variable force_lower_case
+ wildmatch: make wildmatch's return value compatible with fnmatch
+ t3070: disable unreliable fnmatch tests
+ Integrate wildmatch to git
+ wildmatch: follow Git's coding convention
+ wildmatch: remove unnecessary functions
+ Import wildmatch from rsync
+ ctype: support iscntrl, ispunct, isxdigit and isprint
+ ctype: make sane_ctype[] const array
Allows pathname patterns in .gitignore and .gitattributes files
with double-asterisks "foo/**/bar" to match any number of directory
hierarchies.
I suspect that this needs to be plugged to pathspec matching code;
otherwise "git log -- 'Docum*/**/*.txt'" would not show the log for
commits that touch Documentation/git.txt, which would be confusing
to the users.
Will cook in 'next'.
* fc/remote-bzr (2012-11-28) 10 commits
- (fixup) test-bzr.sh: fix multi-line string assignment
- remote-bzr: detect local repositories
- remote-bzr: add support for older versions of bzr
- remote-bzr: add support to push special modes
- remote-bzr: add support for fecthing special modes
- remote-bzr: add simple tests
- remote-bzr: update working tree
- remote-bzr: add support for remote repositories
- remote-bzr: add support for pushing
- Add new remote-bzr transport helper
New remote helper for bzr (v3). With minor fixes, this may be ready
for 'next'.
* cr/push-force-tag-update (2012-12-03) 10 commits
(merged to 'next' on 2012-12-04 at af2e3a9)
+ push: allow already-exists advice to be disabled
+ push: rename config variable for more general use
+ push: cleanup push rules comment
+ push: clarify rejection of update to non-commit-ish
+ push: require force for annotated tags
+ push: require force for refs under refs/tags/
+ push: flag updates that require force
+ push: keep track of "update" state separately
+ push: add advice for rejected tag reference
+ push: return reject reasons as a bitset
Require "-f" for push to update a tag, even if it is a fast-forward.
^ permalink raw reply
* Re: Git repository and Maven project
From: Junio C Hamano @ 2012-12-06 21:35 UTC (permalink / raw)
To: Aleks; +Cc: git
In-Reply-To: <50C1075E.1060407@gmail.com>
Aleks <oles.slosko@gmail.com> writes:
> Can you help to clarify such question.
> We have 2 different projects.
> Name of first project say "server".
> Second - "client".
> Every project has own maven build structure.
> Server produces the war archive for deployment.
> The Client project produces the client jar for testing Server application.
> Aside from these projects we should store different artefacts like
> prototypes for developing pages for server project.
It depends on how tightly coupled the versions of these three
"potentially separate but could be combined" pieces you would want
to make. Is a particular version of the "server" software meant to
work with any random version of "prototypes"? Is a particular
version of the "client" software meant to be used to test any random
version of "server"?
Having all three in the same repository means you are guaranteed,
and more importantly, your developers are *forced* to guarantee, a
checkout of a single commit will contain the state of these three
pieces that work well together. A commit that changes only the
"server" subtree portion, without updating the corresponding assets
in "prototypes" hierarchy that are needed to support what was added
to the "server" part, would break the entire system, and hopefully
your QA procedure can detect and reject it.
Having all three in separate repositories means your developers can
be more loose but it may lead to QA nightmare if a proper procedure
is arranged around the entire process (which Git is only a small
part of).
> I believe the second approach more proper git-approach.
> Such approach allows team to use such advanced git features like
> branging, merging, stash etc.
There is no single "more proper git-approach"; it depends on your
requirements, which the above "how tightly coupled?" question is
an example of. Branching, merging, etc. are orthogonal and can and
will be useful regardless of the repository arrangement you choose.
^ permalink raw reply
* Git repository and Maven project
From: Aleks @ 2012-12-06 21:00 UTC (permalink / raw)
To: git
Can you help to clarify such question.
We have 2 different projects.
Name of first project say "server".
Second - "client".
Every project has own maven build structure.
Server produces the war archive for deployment.
The Client project produces the client jar for testing Server application.
Aside from these projects we should store different artefacts like
prototypes for developing pages for server project.
There are two opinions about approach to arrangement git repository.
1) Create one repository https://git.org/my-project/src
Create 3 separate folders inside of src directory. So we will have such
structure :
root of repository https://git.org/my-project/src/
contains 2 different maven projects and folder for prototypes files
https://git.org/my-project/src/server
https://git.org/my-project/src/client
https://git.org/my-project/src/prototypes
2)Create for every maven project and prototypes separate repository.
https://git.org/my-server/src
https://git.org/my-client/src
https://git.org/prototypes/src
The root of maven project begins from src folder in every repository (
https://git.org/my-server/src and https://git.org/my-client/src)
The xml files and images of prototypes will be inside of
https://git.org/prototypes/src
I believe the second approach more proper git-approach.
Such approach allows team to use such advanced git features like
branging, merging, stash etc.
What approach is proper?
--
Best regards
Aleks
^ permalink raw reply
* Re: [PATCH v2] If `egrep` is aliased, temporary disable it in bash.completion
From: Junio C Hamano @ 2012-12-06 18:01 UTC (permalink / raw)
To: Adam Tkac; +Cc: git, SZEDER Gábor, Felipe Contreras
In-Reply-To: <20121206140541.GA4892@redhat.com>
Adam Tkac <atkac@redhat.com> writes:
> On Thu, Nov 29, 2012 at 09:33:53AM -0800, Junio C Hamano wrote:
> ...
>> IOW, something along this line?
>
> This won't work, unfortunately, because shopt settings aren't inherited by
> subshell (and for example egrep is called in subshell).
>
> I discussed this issue with colleagues and we found basically two "fixes":
>
> 1. Tell people "do not use aliases which breaks completion script"
> 2. Prefix all commands with "command", i.e. `command egrep` etc.
>
> In my opinion "2." is better long time solution, what do you think?
Judging from what is in /etc/bash_completion.d/ (I am on Debian), I
think that others are divided. Many but not all prefix "command" in
front of "grep", but nobody does the same for "egrep", "cut", "tr",
"sed", etc.
If it were up to me, I would say we pick #1, but I cc'ed the people
who have been more involved in our bash-completion code because they
are in a better position to argue between the two than I am.
Thoughts?
^ permalink raw reply
* Re: [PATCH] git-clean: Display more accurate delete messages
From: Junio C Hamano @ 2012-12-06 17:37 UTC (permalink / raw)
To: Zoltan Klinger; +Cc: git
In-Reply-To: <1354788938-26804-1-git-send-email-zoltan.klinger@gmail.com>
Zoltan Klinger <zoltan.klinger@gmail.com> writes:
> Only print out the names of the files and directories that got actually
> deleted.
>
> Consider the following repo layout:
> |-- test.git/
> |-- foo/
> |-- bar/
> |-- bar.txt
> |-- frotz.git/
> |-- frotz.txt
> |-- tracked_file1
> |-- untracked_file1
> ...
> Consider the output of the improved version:
>
> $ git clean -fd
> Removed foo/bar/bar.txt
> Removed foo/bar
> Removed untracked_file1
Hrm, following your discussion (ellided above), I would have
expected that you would show
Removing directory foo/bar
Removing untracked_file1
^ permalink raw reply
* Re: [PATCH v2] If `egrep` is aliased, temporary disable it in bash.completion
From: Adam Tkac @ 2012-12-06 14:05 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, SZEDER Gábor, Felipe Contreras
In-Reply-To: <7vk3t4qpoe.fsf@alter.siamese.dyndns.org>
On Thu, Nov 29, 2012 at 09:33:53AM -0800, Junio C Hamano wrote:
> Junio C Hamano <gitster@pobox.com> writes:
>
> > Adam Tkac <atkac@redhat.com> writes:
> >
> >> Subject: Re: [PATCH v2] If `egrep` is aliased, temporary disable it in bash.completion
> >
> > The code does not seem to do anything special if it is not aliased,
> > though, so "If ..." part does not sound correct; perhaps you meant
> > "just in case egrep is aliased to something totally wacky" or
> > something?
> >
> > The script seems to use commands other than 'egrep' that too can be
> > aliased to do whatever unexpected things. How does this patch get
> > away without backslashing them all, like
> >
> > \echo ...
> > \sed ...
> > \test ...
> > \: comment ...
> > \git args ...
> >
> > and still fix problems for users? Can't the same solution you would
> > give to users who alias one of the above to do something undesirable
> > be applied to those who alias egrep?
> >
> > Puzzled...
>
> Sorry for having been more snarky than necessary (blame it to lack
> of caffeine). What I was trying to get at were:
>
> * I have this suspicion that this patch exists only because you saw
> somebody who aliases egrep to something unexpected by the use of
> it in this script, and egrep *happened* to be the only such
> "unreasonable" alias. The reporter may not have aliased echo or
> sed away, or the aliases to these command *happened* to produce
> "acceptable" output (even though it might have been slightly
> different from unaliased one, the difference *happened* not to
> matter for the purpose of this script).
>
> * To the person who observes the same aliasing breakage due to his
> aliasing sed to something else, you would solve his problem by
> telling him "don't do that, then". If that is the solution, why
> wouldn't it work for egrep?
>
> * The next person who aliased other commands this script uses in
> such a way that the behaviour of the alias differs sufficiently
> from the unaliased version, you will have to patch the file
> again, with the same backslashing. This patch is not a solution,
> but a band-aid that only works for a particular case you
> *happened* to have seen.
>
> * A complete solution that follows the direction this patch
> suggests would involve backslashing *all* commands that can
> potentially aliased away. Is that really the direction we would
> want to go in (answer: I doubt it)? Is that the only approach to
> solve this aliasing issue (answer: I don't know, but we should
> try to pursue it before applying a band-aid that is not a
> solution)?
>
> Is there a way to tell bash "do not alias-expand from here up to
> there"? Perhaps "shopt -u expand_aliases" upon entry and restore
> its original value when we exit, or something?
>
> IOW, something along this line?
This won't work, unfortunately, because shopt settings aren't inherited by
subshell (and for example egrep is called in subshell).
I discussed this issue with colleagues and we found basically two "fixes":
1. Tell people "do not use aliases which breaks completion script"
2. Prefix all commands with "command", i.e. `command egrep` etc.
In my opinion "2." is better long time solution, what do you think?
Regards, Adam
>
> contrib/completion/git-completion.bash | 13 +++++++++++++
> 1 file changed, 13 insertions(+)
>
> diff --git i/contrib/completion/git-completion.bash w/contrib/completion/git-completion.bash
> index 0b77eb1..193f53c 100644
> --- i/contrib/completion/git-completion.bash
> +++ w/contrib/completion/git-completion.bash
> @@ -23,6 +23,14 @@
> # 3) Consider changing your PS1 to also show the current branch,
> # see git-prompt.sh for details.
>
> +if shopt -q expand_aliases
> +then
> + _git__aliases_were_enabled=yes
> +else
> + _git__aliases_were_enabled=
> +fi
> +shopt -u expand_aliases
> +
> case "$COMP_WORDBREAKS" in
> *:*) : great ;;
> *) COMP_WORDBREAKS="$COMP_WORDBREAKS:"
> @@ -2504,3 +2512,8 @@ __git_complete gitk __gitk_main
> if [ Cygwin = "$(uname -o 2>/dev/null)" ]; then
> __git_complete git.exe __git_main
> fi
> +
> +if test -n "$_git__aliases_were_enabled"
> +then
> + shopt -s expand_aliases
> +fi
>
>
--
Adam Tkac, Red Hat, Inc.
^ permalink raw reply
* Re: [PATCH] RFC Optionally handle symbolic links as copies
From: Robin Rosenberg @ 2012-12-06 11:51 UTC (permalink / raw)
To: Johannes Sixt; +Cc: git
In-Reply-To: <50C04255.8050209@viscovery.net>
----- Ursprungligt meddelande -----
> Am 12/5/2012 23:46, schrieb Robin Rosenberg:
> > - git status - when do we report a diff.
> > - After checkout we should probably not
>
> Are you saying that it should be ignored that the index records a
> symbolic
> link, but the worktree contains a regular file and that the regular
> file
> does not even contain the value of the symbolic link (like it would
> in the
> core.symlinks=false case)?
Well we should have some notion of clean state. That could be handled
in more than one way. We could just ignore it, or compare the copy with
the content of the link target. The first is good enough for a proof-of
concept, but perhaps not as a solution since we don't have good other
means to check that the copy is stale.
-- robin
^ permalink raw reply
* Re: Please pull l10n updates for 1.8.1 round 2
From: Peter Krefting @ 2012-12-06 11:50 UTC (permalink / raw)
To: Jiang Xin; +Cc: Junio C Hamano, Trần Ngọc Quân, Git List
In-Reply-To: <CANYiYbGG8DeneCRyxyfVoZ+O2yBm9ywOGZwQMZC9=VYVN5Pf=A@mail.gmail.com>
Jiang Xin:
> The following changes since commit f94c3251e1400c3cf349f7f84fea4db66b540113:
>
> Update draft release notes to 1.8.1 (2012-11-29 13:57:09 -0800)
>
> are available in the git repository at:
>
> git://github.com/git-l10n/git-po master
>
> for you to fetch changes up to 77cc392d6d60c5d22930174904adae182502b8a9:
>
> l10n: vi.po: update to git-v1.8.0.1-347-gf94c3 (2012-11-30 13:43:11 +0700)
This doesn't seem to contain the update to the Swedish translation
that I committed in https://github.com/nafmo/git-l10n-sv (commit
bf3e8fe0c718b64b7e88bd3d74564c54f923aaed). Did I forgot to post a pull
request to you, or what happened?
--
\\// Peter - http://www.softwolves.pp.se/
^ permalink raw reply
* Re: [PATCH] Perform minimal stat comparison when some stat fields are not set
From: Robin Rosenberg @ 2012-12-06 11:16 UTC (permalink / raw)
To: Johannes Sixt; +Cc: Junio C Hamano, git, spearce
In-Reply-To: <50C0475F.1030206@viscovery.net>
----- Ursprungligt meddelande -----
> Am 12/6/2012 2:09, schrieb Robin Rosenberg:
> >> Robin Rosenberg <robin.rosenberg@dewire.com> writes:
> >>> At least JGit does sets uid, gid, ctime, ino and dev fields to
> >>> zero
> >>> on update. To Git this looks like the stat data does not match
> >>> and
> >>> a full file compare will be forced even it size and mtime match.
> >>> This
> >>> is in practice unnecessary. Sense JGit's presence by checking if
> >>> ino
> >>> and dev is zero.
>
> Is this meant to better support C git and JGit working on the same
> repository?
>
> MinGW git sets these two stat fields to zero as well. But we have
> less of
> an interoparability problem between different git implementations in
> practice on Windows, I think.
It is purely for performance in some situations.
> >> Besides, is it sane to do this unconditionally to affect people
> >> who
> >> do not use JGit?
> >
> > Would a config option like core.minstat be better? The name would
> > imply no dynamic detection.
>
> A configuration option is the way to go. We already have
> core.trustctime,
> core.symlinks, core.filemode, core.ignoreCygwinFSTricks.
>
> But your new mode is not "minimal". In some implementations or on
> some
> filesystems, even more bits of stat information could be meaningless
> (think of atime, rdev, nlink, uid, gid). Perhaps core.trustdevandino?
I already excluded uid and gid so the only thing left is mtime and size.
I can't see any reason for anyone to look at atime (somebody read the file,
so what?), ok for rdev and nlink, but we don not look at them my patch
does not avoid looking at them.
> Or
> an enumeration core.ignoreCacheStat=ctime,dev,ino?
That would mean only one configuration option. Good.
-- robin
^ permalink raw reply
* Re: [PATCH] Add new git-cc-cmd helper to contrib
From: Ramkumar Ramachandra @ 2012-12-06 11:15 UTC (permalink / raw)
To: Felipe Contreras; +Cc: git, Junio C Hamano
In-Reply-To: <CAMP44s1--1i+ZtG7eKe0ZpRizcBfq+wJv_VOVZfU+A+gpjLyhQ@mail.gmail.com>
Felipe Contreras wrote:
> [...]
What happened to this code? I don't see it in `pu`.
Ram
^ permalink raw reply
* [PATCH] git-clean: Display more accurate delete messages
From: Zoltan Klinger @ 2012-12-06 10:15 UTC (permalink / raw)
To: git; +Cc: Zoltan Klinger
Only print out the names of the files and directories that got actually
deleted.
Consider the following repo layout:
|-- test.git/
|-- foo/
|-- bar/
|-- bar.txt
|-- frotz.git/
|-- frotz.txt
|-- tracked_file1
|-- untracked_file1
Suppose the user issues 'git clean -fd' from the test.git directory.
When -d option is used and untracked directory 'foo' contains a
subdirectory 'frotz.git' that is managed by a different git repository
therefore it will not be removed.
$ git clean -fd
Removing foo/
Removing untracked_file1
The message displayed to the user is slightly misleading. The foo/
directory has not been removed because of foo/frotz.git still exists.
On the other hand the subdirectory bar has been deleted but it's not
mentioned anywhere.
This behaviour is the result of the way the deletion of untracked
directories are reported. In the current implementation they are
deleted recursively but only the name of the top most directory is
printed out. The calling function does not know about any
subdirectories that could not be removed during the recursion.
Improve the way the deleted directories are reported back to
the user:
(1) Modify the recursive delete function to run in both dry_run and
delete modes.
(2) During the recursion collect the name of the files and
directories that will be or have been removed. Also collect the
names of files and directories that could not be removed.
(3) After finishing the deletes print out the names of all deleted
files and any files or directories that failed to delete.
Consider the output of the improved version:
$ git clean -fd
Removed foo/bar/bar.txt
Removed foo/bar
Removed untracked_file1
Now it displays only the file and directory names that got actually
deleted.
Signed-off-by: Zoltan Klinger <zoltan.klinger@gmail.com>
---
Hi there,
My first patch. Hope you find it useful.
Looking forward to your feedback.
Cheers,
Zoltan
builtin/clean.c | 64 +++++++++++++++++++++++++++++++------------------------
dir.c | 58 ++++++++++++++++++++++++++++++++++++++++---------
dir.h | 3 +++
3 files changed, 87 insertions(+), 38 deletions(-)
diff --git a/builtin/clean.c b/builtin/clean.c
index 69c1cda..9b056b9 100644
--- a/builtin/clean.c
+++ b/builtin/clean.c
@@ -34,22 +34,31 @@ static int exclude_cb(const struct option *opt, const char *arg, int unset)
return 0;
}
+static void print_result(const char *msg, struct string_list *lst)
+{
+ int i;
+ for (i = 0; i < lst->nr; i++)
+ printf("%s %s\n", msg, lst->items[i].string);
+}
+
int cmd_clean(int argc, const char **argv, const char *prefix)
{
int i;
- int show_only = 0, remove_directories = 0, quiet = 0, ignored = 0;
+ int dry_run = 0, remove_directories = 0, quiet = 0, ignored = 0;
int ignored_only = 0, config_set = 0, errors = 0;
int rm_flags = REMOVE_DIR_KEEP_NESTED_GIT;
struct strbuf directory = STRBUF_INIT;
struct dir_struct dir;
static const char **pathspec;
struct strbuf buf = STRBUF_INIT;
+ struct string_list dels = STRING_LIST_INIT_DUP;
+ struct string_list errs = STRING_LIST_INIT_DUP;
struct string_list exclude_list = STRING_LIST_INIT_NODUP;
const char *qname;
char *seen = NULL;
struct option options[] = {
OPT__QUIET(&quiet, N_("do not print names of files removed")),
- OPT__DRY_RUN(&show_only, N_("dry run")),
+ OPT__DRY_RUN(&dry_run, N_("dry run")),
OPT__FORCE(&force, N_("force")),
OPT_BOOLEAN('d', NULL, &remove_directories,
N_("remove whole directories")),
@@ -77,7 +86,7 @@ int cmd_clean(int argc, const char **argv, const char *prefix)
if (ignored && ignored_only)
die(_("-x and -X cannot be used together"));
- if (!show_only && !force) {
+ if (!dry_run && !force) {
if (config_set)
die(_("clean.requireForce set to true and neither -n nor -f given; "
"refusing to clean"));
@@ -150,43 +159,42 @@ int cmd_clean(int argc, const char **argv, const char *prefix)
if (S_ISDIR(st.st_mode)) {
strbuf_addstr(&directory, ent->name);
qname = quote_path_relative(directory.buf, directory.len, &buf, prefix);
- if (show_only && (remove_directories ||
- (matches == MATCHED_EXACTLY))) {
- printf(_("Would remove %s\n"), qname);
- } else if (remove_directories ||
- (matches == MATCHED_EXACTLY)) {
- if (!quiet)
- printf(_("Removing %s\n"), qname);
- if (remove_dir_recursively(&directory,
- rm_flags) != 0) {
- warning(_("failed to remove %s"), qname);
- errors++;
- }
- } else if (show_only) {
- printf(_("Would not remove %s\n"), qname);
- } else {
- printf(_("Not removing %s\n"), qname);
+ if (remove_directories || (matches == MATCHED_EXACTLY)) {
+ remove_dir_recursively_with_dryrun(&directory, rm_flags, dry_run,
+ &dels, &errs, prefix);
}
strbuf_reset(&directory);
} else {
if (pathspec && !matches)
continue;
qname = quote_path_relative(ent->name, -1, &buf, prefix);
- if (show_only) {
- printf(_("Would remove %s\n"), qname);
- continue;
- } else if (!quiet) {
- printf(_("Removing %s\n"), qname);
- }
- if (unlink(ent->name) != 0) {
- warning(_("failed to remove %s"), qname);
- errors++;
+ if (dry_run)
+ string_list_append(&dels, qname);
+ else {
+ if (unlink(ent->name) != 0)
+ string_list_append(&errs, qname);
+ else
+ string_list_append(&dels, qname);
}
}
}
+
+ if (!quiet) {
+ if (dry_run)
+ print_result("Would remove", &dels);
+ else
+ print_result("Removed", &dels);
+ }
+
+ errors = errs.nr;
+ if (errors)
+ print_result("Failed to remove", &errs);
+
free(seen);
strbuf_release(&directory);
+ string_list_clear(&dels, 0);
+ string_list_clear(&errs, 0);
string_list_clear(&exclude_list, 0);
return (errors != 0);
}
diff --git a/dir.c b/dir.c
index 5a83aa7..f580c51 100644
--- a/dir.c
+++ b/dir.c
@@ -7,7 +7,9 @@
*/
#include "cache.h"
#include "dir.h"
+#include "quote.h"
#include "refs.h"
+#include "string-list.h"
struct path_simplify {
int len;
@@ -1294,11 +1296,25 @@ int is_empty_dir(const char *path)
return ret;
}
-static int remove_dir_recurse(struct strbuf *path, int flag, int *kept_up)
+static void append_dir_name(struct string_list *dels, struct string_list *errs,
+ char *name, const char * prefix, int failed)
+{
+ struct strbuf buf = STRBUF_INIT;
+ const char *qname;
+ qname = quote_path_relative(name, strlen(name), &buf, prefix);
+ if (!failed && dels)
+ string_list_append(dels, qname);
+ else if (errs)
+ string_list_append(errs, qname);
+}
+
+static int remove_dir_recurse(struct strbuf *path, int flag, int *kept_up,
+ int dry_run, struct string_list *dels, struct string_list *errs,
+ const char *prefix)
{
DIR *dir;
struct dirent *e;
- int ret = 0, original_len = path->len, len, kept_down = 0;
+ int ret = 0, original_len = path->len, len, kept_down = 0, res = 0;
int only_empty = (flag & REMOVE_DIR_EMPTY_ONLY);
int keep_toplevel = (flag & REMOVE_DIR_KEEP_TOPLEVEL);
unsigned char submodule_head[20];
@@ -1315,8 +1331,13 @@ static int remove_dir_recurse(struct strbuf *path, int flag, int *kept_up)
dir = opendir(path->buf);
if (!dir) {
/* an empty dir could be removed even if it is unreadble */
- if (!keep_toplevel)
- return rmdir(path->buf);
+ if (!keep_toplevel) {
+ res = 0;
+ if (!dry_run)
+ res = rmdir(path->buf);
+ append_dir_name(dels, errs, path->buf, prefix, res);
+ return res;
+ }
else
return -1;
}
@@ -1334,10 +1355,16 @@ static int remove_dir_recurse(struct strbuf *path, int flag, int *kept_up)
if (lstat(path->buf, &st))
; /* fall thru */
else if (S_ISDIR(st.st_mode)) {
- if (!remove_dir_recurse(path, flag, &kept_down))
+ if (!remove_dir_recurse(path, flag, &kept_down, dry_run, dels, errs, prefix))
continue; /* happy */
- } else if (!only_empty && !unlink(path->buf))
- continue; /* happy, too */
+ } else if (!only_empty) {
+ res = 0;
+ if (!dry_run)
+ res = unlink(path->buf);
+ append_dir_name(dels, errs, path->buf, prefix, res);
+ if (!res)
+ continue; /* happy, too */
+ }
/* path too long, stat fails, or non-directory still exists */
ret = -1;
@@ -1346,8 +1373,12 @@ static int remove_dir_recurse(struct strbuf *path, int flag, int *kept_up)
closedir(dir);
strbuf_setlen(path, original_len);
- if (!ret && !keep_toplevel && !kept_down)
- ret = rmdir(path->buf);
+ if (!ret && !keep_toplevel && !kept_down) {
+ ret = 0;
+ if (!dry_run)
+ ret = rmdir(path->buf);
+ append_dir_name(dels, errs, path->buf, prefix, res);
+ }
else if (kept_up)
/*
* report the uplevel that it is not an error that we
@@ -1359,7 +1390,14 @@ static int remove_dir_recurse(struct strbuf *path, int flag, int *kept_up)
int remove_dir_recursively(struct strbuf *path, int flag)
{
- return remove_dir_recurse(path, flag, NULL);
+ return remove_dir_recurse(path, flag, NULL, 0, NULL, NULL, NULL);
+}
+
+int remove_dir_recursively_with_dryrun(struct strbuf *path, int flag,
+ int dry_run, struct string_list *dels, struct string_list *errs,
+ const char *prefix)
+{
+ return remove_dir_recurse(path, flag, NULL, dry_run, dels, errs, prefix);
}
void setup_standard_excludes(struct dir_struct *dir)
diff --git a/dir.h b/dir.h
index f5c89e3..828bd49 100644
--- a/dir.h
+++ b/dir.h
@@ -131,6 +131,9 @@ extern void setup_standard_excludes(struct dir_struct *dir);
#define REMOVE_DIR_KEEP_NESTED_GIT 02
#define REMOVE_DIR_KEEP_TOPLEVEL 04
extern int remove_dir_recursively(struct strbuf *path, int flag);
+extern int remove_dir_recursively_with_dryrun(struct strbuf *path,
+ int flag, int dryrun, struct string_list *dels,
+ struct string_list *errs, const char *prefix);
/* tries to remove the path with empty directories along it, ignores ENOENT */
extern int remove_path(const char *path);
--
1.7.9.5
^ permalink raw reply related
* Re: [PATCH] Add directory pattern matching to attributes
From: Jean-Noël Avila @ 2012-12-06 9:02 UTC (permalink / raw)
To: git
In-Reply-To: <7vlidcjcm9.fsf@alter.siamese.dyndns.org>
On 06/12/2012 00:35, Junio C Hamano wrote:
> "Jean-Noël AVILA" <jn.avila@free.fr> writes:
>
>> -static void prepare_attr_stack(const char *path)
>> +static void prepare_attr_stack(const char *path, unsigned mode)
>> {
>> struct attr_stack *elem, *info;
>> int dirlen, len;
>> @@ -645,28 +645,43 @@ static void prepare_attr_stack(const char *path)
>> }
> Why?
>
> The new "mode" parameter does not seem to be used in this function
> at all.
>
>> static int path_matches(const char *pathname, int pathlen,
>> - const char *pattern,
>> + const unsigned mode, char *pattern,
>> const char *base, int baselen)
>> {
>> - if (!strchr(pattern, '/')) {
>> + size_t len;
>> + char buf[PATH_MAX];
>> + char * lpattern = buf;
>> + len = strlen(pattern);
>> + if (PATH_MAX <= len)
>> + return 0;
>> + strncpy(buf,pattern,len);
>> + buf[len] ='\0';
>> + if (len && lpattern[len - 1] == '/') {
>> + if (S_ISDIR(mode))
>> + lpattern[len - 1] = '\0';
>> + else
>> + return 0;
>> + }
>> + if (!strchr(lpattern, '/')) {
>> /* match basename */
>> const char *basename = strrchr(pathname, '/');
>> basename = basename ? basename + 1 : pathname;
>> - return (fnmatch_icase(pattern, basename, 0) == 0);
>> + return (fnmatch_icase(lpattern, basename, 0) == 0);
>> }
>> /*
>> * match with FNM_PATHNAME; the pattern has base implicitly
>> * in front of it.
>> */
>> - if (*pattern == '/')
>> - pattern++;
>> + if (*lpattern == '/')
>> + lpattern++;
>> if (pathlen < baselen ||
>> (baselen && pathname[baselen] != '/') ||
>> strncmp(pathname, base, baselen))
>> return 0;
>> if (baselen != 0)
>> baselen++;
>> - return fnmatch_icase(pattern, pathname + baselen, FNM_PATHNAME) == 0;
>> + return fnmatch_icase(lpattern, pathname + baselen, FNM_PATHNAME) == 0;
>> }
> It appears to me that you are forcing the caller to tell this
> function if the path is a directory, but in the attribute system,
> the caller does not necessarily know if the path it is passing is
> meant to be a directory or a regular file. "check-attr" is meant to
> be usable against a path that does not even exist on the working
> tree, so using stat() or lstat() in it is not a solution. In other
> words, it is unfair (read: unworkable) to force it to append a
> trailing slash after the path it calls this function with.
Thank you for your comments. Changing the whole attr.h interface header
is definitely not a good option, but at some point, we may need more
information
on the path to be able to match a path pattern against it.
>
> If you are interested in export-subst, all is not lost, though:
>
> $ git init
> $ mkdir a
> $ >a/b
> $ echo a export-ignore >.gitattributes
> $ git add a/b .gitattributes
> $ git commit -m initial
> $ git archive HEAD | tar tf -
> .gitattributes
> $ exit
>
> You could change the "echo" to
>
> $ echo "a/*" export-ignore >.gitattributes
>
> as well, but it seems to create an useless empty directory "a/" in
> the output, which I think is an unrelated bug in "git archive".
This is quite different from the pattern matching documented for gitignore.
Moreover,
$ mkdir -p not-ignored-dir/ignored-dir
$ echo test >not-ignored-dir/ignored-dir/ignored
$ echo 'ignored-dir/*' >.gitattributes
$ git add not-ignored-dir .gitattributes
$ git commit -m '.'
$ git archive HEAD | tar tf -
.gitattributes
not-ignored-dir/
not-ignored-dir/ignored-dir/
not-ignored-dir/ignored-dir/ignored
>
> This patch seems to be based on a stale codebase.
Sorry. I thought the patch submissions had to be based on the 'maint'
branch.
> I do not think
> I'd be opposed to change the sementics to allow the callers that
> know that a path is a directory to optionally pass mode parameter by
> ending the pathname with slash (in other words, have "git
> check-attr" ask about a directory 'a' by saying "git check-attr
> export-subst a/", and lose the "mode" argument in this patch), or
> keep the "mode" parameter and instead allow "git check-attr" to ask
> about a directory that does not exist in the working tree by a more
> explicit "git check-attr --directory export-ignore a" or something.
> Such an enhancement should be done on top of the current codebase.
OK. I like the idea of proposing a path ending with '/' when it is meant
to be
directory. This would not change the interface attr.h . I will rework
with this idea.
Thank you.
^ 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