* What's cooking in git.git (Dec 2012, #02; Mon, 10)
From: Junio C Hamano @ 2012-12-10 23:16 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'.
A new maintenance release 1.8.0.2 was tagged with accumulated fixes
we have already been using on the 'master' front for a while. The
tip of the 'master' is a bit beyond 1.8.1-rc1 and many topics are
getting into good shape in 'next', hopefully ready to be merged soon
after the 1.8.1 final.
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-rmdir (2012-12-10) 1 commit
- mingw_rmdir: do not prompt for retry when non-empty
MinGW has a workaround when rmdir unnecessarily fails to retry with
a prompt, but the logic was kicking in when the rmdir failed with
ENOTEMPTY, i.e. was expected to fail and there is no point retrying.
Will fast-track to 'master'.
* jc/maint-fbsd-sh-ifs-workaround (2012-12-10) 1 commit
- sh-setup: work around "unset IFS" bug in some shells
Will merge to 'next'.
* jc/merge-blobs (2012-12-09) 4 commits
- merge-tree: add comments to clarify what these functions are doing
- merge-tree: lose unused "resolve_directories"
- merge-tree: lose unused "flags" from merge_list
- Which merge_file() function do you mean?
A beginning of a new merge strategy based on the disused merge-tree
proof-of-concept code.
* jc/same-encoding (2012-12-10) 1 commit
- format_commit_message(): simplify calls to logmsg_reencode()
Finishing touches to the series to unify "Do we need to reencode
between these two encodings?" logic.
* nd/invalidate-i-t-a-cache-tree (2012-12-09) 1 commit
- cache-tree: invalidate i-t-a paths after generating trees
Writing out a tree object when you still have intent-to-add entries
in the index left an incorrect cache-tree data there.
--------------------------------------------------
[Graduated to "master"]
* 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.
--------------------------------------------------
[Stalled]
* 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'.
* mo/cvs-server-updates (2012-12-09) 18 commits
- t9402: Use TABs for indentation
- t9402: Rename check.cvsCount and check.list
- t9402: Simplify git ls-tree
- t9402: Add missing &&; Code style
- t9402: No space after IO-redirection
- t9402: Dont use test_must_fail cvs
- t9402: improve check_end_tree() and check_end_full_tree()
- t9402: sed -i is not portable
- 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]
* ef/mingw-tty-getpass (2012-12-04) 6 commits
(merged to 'next' on 2012-12-07 at 1737ff1)
+ 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 fast-track to 'master'.
* jl/submodule-deinit (2012-12-04) 1 commit
(merged to 'next' on 2012-12-07 at ea772f0)
+ 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 cook in 'next'.
* sl/git-svn-docs (2012-12-05) 4 commits
(merged to 'next' on 2012-12-07 at 5bfbb73)
+ 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 cook in 'next'.
* pf/editor-ignore-sigint (2012-12-02) 5 commits
(merged to 'next' on 2012-12-07 at 6b04419)
+ 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 cook in '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.
Will cook in 'next'.
* 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-12-07) 6 commits
(merged to 'next' on 2012-12-07 at 7ac8c25)
+ 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
Will cook in 'next'.
* 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'.
* 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.
Will cook in 'next'.
^ permalink raw reply
* [ANNOUNCE] Git v1.8.0.2
From: Junio C Hamano @ 2012-12-10 22:17 UTC (permalink / raw)
To: git; +Cc: Linux Kernel
The latest maintenance release Git v1.8.0.2 is now available at
the usual places.
The release tarballs are found at:
http://code.google.com/p/git-core/downloads/list
and their SHA-1 checksums are:
1e1640794596da40f35194c29a8cc4e41c6b4f6d git-1.8.0.2.tar.gz
6b9e14c5b19b2e27605014252febd61a700012a3 git-htmldocs-1.8.0.2.tar.gz
ce0673256ce90451269a82a2464eab060adbfec6 git-manpages-1.8.0.2.tar.gz
Also the following public repositories all have a copy of the v1.8.0.2
tag and the maint branch that the tag points at:
url = git://repo.or.cz/alt-git.git
url = https://code.google.com/p/git-core/
url = git://git.sourceforge.jp/gitroot/git-core/git.git
url = git://git-core.git.sourceforge.net/gitroot/git-core/git-core
url = https://github.com/gitster/git
Git v1.8.0.2 Release Notes
==========================
Fixes since v1.8.0.1
--------------------
* Various codepaths have workaround for a common misconfiguration to
spell "UTF-8" as "utf8", but it was not used uniformly. Most
notably, mailinfo (which is used by "git am") lacked this support.
* We failed to mention a file without any content change but whose
permission bit was modified, or (worse yet) a new file without any
content in the "git diff --stat" output.
* When "--stat-count" hides a diffstat for binary contents, the total
number of added and removed lines at the bottom was computed
incorrectly.
* When "--stat-count" hides a diffstat for unmerged paths, the total
number of affected files at the bottom of the "diff --stat" output
was computed incorrectly.
* "diff --shortstat" miscounted the total number of affected files
when there were unmerged paths.
* "git p4" used to try expanding malformed "$keyword$" that spans
across multiple lines.
* "git update-ref -d --deref SYM" to delete a ref through a symbolic
ref that points to it did not remove it correctly.
* Syntax highlighting in "gitweb" was not quite working.
Also contains other minor fixes and documentation updates.
----------------------------------------------------------------
Changes since v1.8.0.1 are as follows:
Antoine Pelisse (1):
Fix typo in remote set-head usage
Eric S. Raymond (1):
doc/fast-import: clarify how content states are built
Johan Herland (2):
t1400-update-ref: Add test verifying bug with symrefs in delete_ref()
Fix failure to delete a packed ref through a symref
Junio C Hamano (13):
reencode_string(): introduce and use same_encoding()
test: add failing tests for "diff --stat" to t4049
diff --stat: status of unmodified pair in diff-q is not zero
diff --stat: use "file" temporary variable to refer to data->files[i]
diff --stat: move the "total count" logic to the last loop
diff --stat: do not count "unmerged" entries
diff --shortstat: do not count "unmerged" entries
Documentation/git-push.txt: clarify the "push from satellite" workflow
Start preparing for 1.8.0.2
t4049: refocus tests
Update draft release notes to 1.8.0.2
git(1): remove a defunct link to "list of authors"
Git 1.8.0.2
Linus Torvalds (1):
Fix "git diff --stat" for interesting - but empty - file changes
Mark Szepieniec (1):
Documentation: improve phrasing in git-push.txt
Matthieu Moy (2):
git-remote-mediawiki: escape ", \, and LF in file names
git-fast-import.txt: improve documentation for quoted paths
Nguyễn Thái Ngọc Duy (1):
compat/fnmatch: fix off-by-one character class's length check
Paul Gortmaker (1):
Makefile: hide stderr of curl-config test
Pete Wyckoff (1):
git p4: RCS expansion should not span newlines
Ralf Thielow (1):
completion: add options --single-branch and --branch to "git clone"
Richard Hubbell (1):
gitweb.perl: fix %highlight_ext mappings
Sébastien Loriot (1):
Documentation/git-stash.txt: add a missing verb
W. Trevor King (1):
git-submodule: wrap branch option with "<>" in usage strings.
^ permalink raw reply
* Re: Millisecond precision in timestamps?
From: James Cloos @ 2012-12-10 20:56 UTC (permalink / raw)
To: Eric S. Raymond
Cc: Junio C Hamano, Jeff King, Shawn Pearce, Felipe Contreras, git
In-Reply-To: <20121128075807.GA9912@thyrsus.com>
>>>>> "ESR" == Eric S Raymond <esr@thyrsus.com> writes:
ESR> I've never seen a software project under version control with bits
ESR> that old,
They do exist, but the vcs timestamps are (at least for those in git :)
not (always) correlated to when the files were first added to the project.
Maxima, as an example, has code which was written in the '60s. (A
couple of years ago a bug was fixed in a contrib module which had
been added to MACSYMA back in '62 or so.)
I beleive axiom also has some similarly ancient code.
Those two are now managed in git. (Except for the openaxiom fork.)
And there is a high-energy physics package still under development
with code going back to the '50s. I'm pretty sure they moved to a
vcs sometime in the last decade or two. :)
-JimC
--
James Cloos <cloos@jhcloos.com> OpenPGP: 1024D/ED7DAEA6
^ permalink raw reply
* [PATCH] format_commit_message(): simplify calls to logmsg_reencode()
From: Junio C Hamano @ 2012-12-10 20:57 UTC (permalink / raw)
To: git
All the other callers of logmsg_reencode() pass return value of
get_commit_output_encoding() or get_log_output_encoding(). Teach
the function to optionally take NULL as a synonym to "" aka "no
conversion requested" so that we can simplify the only remaining
calling site.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
pretty.c | 16 ++++------------
1 file changed, 4 insertions(+), 12 deletions(-)
diff --git a/pretty.c b/pretty.c
index e87fe9f..732e2a2 100644
--- a/pretty.c
+++ b/pretty.c
@@ -500,7 +500,7 @@ char *logmsg_reencode(const struct commit *commit,
char *encoding;
char *out;
- if (!*output_encoding)
+ if (!output_encoding || !*output_encoding)
return NULL;
encoding = get_header(commit, "encoding");
use_encoding = encoding ? encoding : utf8;
@@ -1184,23 +1184,15 @@ void format_commit_message(const struct commit *commit,
const struct pretty_print_context *pretty_ctx)
{
struct format_commit_context context;
- static const char utf8[] = "UTF-8";
const char *output_enc = pretty_ctx->output_encoding;
memset(&context, 0, sizeof(context));
context.commit = commit;
context.pretty_ctx = pretty_ctx;
context.wrap_start = sb->len;
- context.message = commit->buffer;
- if (output_enc) {
- char *enc = get_header(commit, "encoding");
- if (strcmp(enc ? enc : utf8, output_enc)) {
- context.message = logmsg_reencode(commit, output_enc);
- if (!context.message)
- context.message = commit->buffer;
- }
- free(enc);
- }
+ context.message = logmsg_reencode(commit, output_enc);
+ if (!context.message)
+ context.message = commit->buffer;
strbuf_expand(sb, format, format_commit_item, &context);
rewrap_message_tail(sb, &context, 0, 0, 0);
--
1.8.1.rc1.123.gf61cb86
^ permalink raw reply related
* Re: Use of a mailmap file with git-log
From: Junio C Hamano @ 2012-12-10 20:16 UTC (permalink / raw)
To: Antoine Pelisse; +Cc: Rich Midwinter, git
In-Reply-To: <CALWbr2ydMkR_O-Gev7k-HjGadRJMv0UH3XdqtM0Jt=vC82GwJw@mail.gmail.com>
Antoine Pelisse <apelisse@gmail.com> writes:
> It could indeed be very interesting to have mailmap applied to git-log and
> especially to git-log --author/--committer.
> ...
> The choice of parse_commit_buffer to do the modification is due to
> the grepping being done directly on buffer when grepping author/committerer.
For pattern matching, I think revision.c::commit_match() is probably
the right place to do this kind of thing. I just noticed that we
grep for the string inside a raw buffer, even when "encoding" is
specified, which I think is a bug.
^ permalink raw reply
* Re: Use of a mailmap file with git-log
From: Junio C Hamano @ 2012-12-10 20:05 UTC (permalink / raw)
To: Antoine Pelisse; +Cc: Rich Midwinter, git
In-Reply-To: <CALWbr2ydMkR_O-Gev7k-HjGadRJMv0UH3XdqtM0Jt=vC82GwJw@mail.gmail.com>
Antoine Pelisse <apelisse@gmail.com> writes:
> Yet I'm afraid it could be:
> 1. expensive to rewrite all commit log (reallocating the buffer)
> 2. Inappropriate to change the value in function that is supposed to
> read
In my suggestion I avoided rewriting the log buffer, primarily
because of #2 (in addition to "read" cleanliness, such a change may
break the gpg signature checking for merges).
We do reencode the contents before we write it out when "encoding"
is present, so logically such a rewrite of authors and committers
belongs to where that happens, in pretty_print_commit(). Note that
this existing rewrite is not done to the commit log buffer but is to
a separate buffer meant to be used only for output.
^ permalink raw reply
* Re: Use of a mailmap file with git-log
From: Antoine Pelisse @ 2012-12-10 19:47 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Rich Midwinter, git
In-Reply-To: <7v38zdbv6d.fsf@alter.siamese.dyndns.org>
Hi,
I was thinking about that last week.
It could indeed be very interesting to have mailmap applied to git-log and
especially to git-log --author/--committer.
My first look at the code let me think that we would need to change the
parse_commit_buffer to replace, at reading time, the name of author and
committer if an option (--use-mailmap seems like a wise choice) and
probably a config option.
The choice of parse_commit_buffer to do the modification is due to
the grepping being done directly on buffer when grepping author/committerer.
Yet I'm afraid it could be:
1. expensive to rewrite all commit log (reallocating the buffer)
2. Inappropriate to change the value in function that is supposed to
read
My 2 cents.
Cheers,
On Mon, Dec 10, 2012 at 7:48 PM, Junio C Hamano <gitster@pobox.com> wrote:
> Rich Midwinter <rich.midwinter@gmail.com> writes:
>
>> I'm working on a project for a large organisation that wants to make
>> widespread use of git and the mailmap feature.
>>
>> This seems to be supported by default in git-shortlog but not git-log
>> (and other variants) without specifying custom formats, which isn't
>> really something I want to try and 'fix' across the organisation. Is
>> there a reason for this feature omission or has it just evolved that
>> way and could it be fixed?
>
> I think it was pretty much the latter, but people may already be
> depending on the command to give them the "true as recorded back
> then" names in the output. A fix may have to involve inventing a
> new option "log --use-mailmap" that is explicitly given from the
> command line.
>
> --
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: Use of a mailmap file with git-log
From: Junio C Hamano @ 2012-12-10 19:43 UTC (permalink / raw)
To: git; +Cc: Rich Midwinter
In-Reply-To: <7v38zdbv6d.fsf@alter.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> Rich Midwinter <rich.midwinter@gmail.com> writes:
>
>> I'm working on a project for a large organisation that wants to make
>> widespread use of git and the mailmap feature.
>>
>> This seems to be supported by default in git-shortlog but not git-log
>> (and other variants) without specifying custom formats, which isn't
>> really something I want to try and 'fix' across the organisation. Is
>> there a reason for this feature omission or has it just evolved that
>> way and could it be fixed?
>
> I think it was pretty much the latter, but people may already be
> depending on the command to give them the "true as recorded back
> then" names in the output. A fix may have to involve inventing a
> new option "log --use-mailmap" that is explicitly given from the
> command line.
If somebody wants to do this, I think the overall design should go
like this:
* We may want to rewrite blame.c::get_ac_line() and the code in
pretty.c::pp_user_info() that parse author/committer lines by
using ident.c::split_ident_line() for better code reuse as a
preparation step before all of the below.
* We may want to lift the buffer length limit from the implementation
of mailmap.c::map_user() by using the strbuf API as a preparation
step before all of the below.
* We may also want to rethink its signature (we may want to get a
single strbuf and have the function parse out "Name <mail>"; I
didn't check the existing callers to see if that would make it
easier to use, and if it does not, this obviously shouldn't be done)
as a preparation step before all of the below.
* Introduce a new "struct string_list *mailmap" member to "struct
pretty_print_context" and "struct rev_info" (default to NULL);
* In log-tree.c::show_log(), copy opt->mailmap to ctx.mailmap;
* Update pretty.c::pp_user_info() to convert the email address on
"line" (between the beginning and "namelen") by calling
map_user() immediately after it parses time/tz out, and adjust
the remainder of the function to use it, when pp->mailmap is
present;
* Teach log.c::cmd_log_init_finosh() about "--use-mailmap" option.
Allocate one "struct string_list" instance and use read_mailmap()
on it when the option is used, and store it in rev->mailmap.
^ permalink raw reply
* Re: [PATCH] git-clean: Display more accurate delete messages
From: Junio C Hamano @ 2012-12-10 18:53 UTC (permalink / raw)
To: Soren Brinkmann; +Cc: Zoltan Klinger, git
In-Reply-To: <aecaf65e-2b7f-4309-a7b5-622c7779de17@DB3EHSMHS018.ehs.local>
Soren Brinkmann <soren.brinkmann@xilinx.com> writes:
> But either
> way, the output of git clean should match what it is doing. And at least tell me
> if it didn't remove certain dirs or files.
Oh, no question about that part. I was reacting to --force --force
in general, and an unrelated git repository inside a working tree is
just a subset of the issue.
^ permalink raw reply
* Re: Use of a mailmap file with git-log
From: Junio C Hamano @ 2012-12-10 18:48 UTC (permalink / raw)
To: Rich Midwinter; +Cc: git
In-Reply-To: <CALKB1SXdNVsQop5VYmShOMx93+j5SPdkGF9yNU5k7nXg87TwMw@mail.gmail.com>
Rich Midwinter <rich.midwinter@gmail.com> writes:
> I'm working on a project for a large organisation that wants to make
> widespread use of git and the mailmap feature.
>
> This seems to be supported by default in git-shortlog but not git-log
> (and other variants) without specifying custom formats, which isn't
> really something I want to try and 'fix' across the organisation. Is
> there a reason for this feature omission or has it just evolved that
> way and could it be fixed?
I think it was pretty much the latter, but people may already be
depending on the command to give them the "true as recorded back
then" names in the output. A fix may have to involve inventing a
new option "log --use-mailmap" that is explicitly given from the
command line.
^ permalink raw reply
* Use of a mailmap file with git-log
From: Rich Midwinter @ 2012-12-10 18:22 UTC (permalink / raw)
To: git
Hi
I'm working on a project for a large organisation that wants to make
widespread use of git and the mailmap feature.
This seems to be supported by default in git-shortlog but not git-log
(and other variants) without specifying custom formats, which isn't
really something I want to try and 'fix' across the organisation. Is
there a reason for this feature omission or has it just evolved that
way and could it be fixed?
Thanks
Rich
^ permalink raw reply
* Re: [PATCH] git-clean: Display more accurate delete messages
From: Soren Brinkmann @ 2012-12-10 18:16 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Soren Brinkmann, Zoltan Klinger, git
In-Reply-To: <7va9tlbx8v.fsf@alter.siamese.dyndns.org>
On Mon, Dec 10, 2012 at 10:03:28AM -0800, Junio C Hamano wrote:
> Soren Brinkmann <soren.brinkmann@xilinx.com> writes:
>
> >> > 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.
> > As I mentioned in my email where I reported this incorrect git clean output, I
> > have a use case where I want git clean to remove embedded repositories.
> > Whether it is a sane one is probably a different discussion.
>
> Why is it a different discussion? If something is not sane, the
> tool shouldn't encourage users to do such an insane thing.
>
Well, ok. So I have a repository which essentially consists of a bunch of
scripts which then pull sources via git to build root filesystems, busybox,
kernel etc.
So I have the master repository I'm actually interested in. And then all the
other projects which are pulled in to build stuff from.
looking somehow like this:
top.git
|-src
| |-proj1.git
| |-proj2.git
| |-projn.git
|-build
|-proj1
|-proj2
...
Since the scripts are not perfect I usually used 'git clean -xdf' to wipe
everything and build from scratch. And I had to experience that the git clean
behavior somehow changed recently and the 'projn.git' directories were no longer
removed anymore, despite git indicating otherwise in its output.
So, I think having 'git clean -ff' removing embedded git repos is okay. But either
way, the output of git clean should match what it is doing. And at least tell me
if it didn't remove certain dirs or files.
Soren
^ permalink raw reply
* Re: [PATCH] git-clean: Display more accurate delete messages
From: Junio C Hamano @ 2012-12-10 18:03 UTC (permalink / raw)
To: Soren Brinkmann; +Cc: Zoltan Klinger, git
In-Reply-To: <5b69a9f1-0860-41da-914c-d55a17e54092@TX2EHSMHS026.ehs.local>
Soren Brinkmann <soren.brinkmann@xilinx.com> writes:
>> > 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.
> As I mentioned in my email where I reported this incorrect git clean output, I
> have a use case where I want git clean to remove embedded repositories.
> Whether it is a sane one is probably a different discussion.
Why is it a different discussion? If something is not sane, the
tool shouldn't encourage users to do such an insane thing.
^ permalink raw reply
* Re: [PATCH] git-clean: Display more accurate delete messages
From: Soren Brinkmann @ 2012-12-10 17:33 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Zoltan Klinger, Soren Brinkmann, git
In-Reply-To: <7v38zecrqc.fsf@alter.siamese.dyndns.org>
Hi,
On Sun, Dec 09, 2012 at 11:04:59PM -0800, Junio C Hamano wrote:
> Zoltan Klinger <zoltan.klinger@gmail.com> writes:
>
> > Would like to get some more feedback on the proposed output in case of
> > (1) an untracked subdirectory with multiple files where at least one of them
> > cannot be removed.
> > (2) reporting ignored untracked git subdirectories
> >
> > Suppose we have a repo like the one below:
> > test.git/
> > |-- tracked_file
> > |-- untracked_file
> > |-- untracked_foo/
> > | |-- bar/
> > | | |-- bar.txt
> > | |-- emptydir/
> > | |-- frotz.git/
> > | | |-- frotx.txt
> > | |-- quux/
> > | |-- failedquux.txt
> > | |-- quux.txt
> > |-- untracked_unreadable_dir/
> > | |-- afile
> > |-- untracked_some.git/
> > |-- some.txt
> >
> > $ git clean -fd
> > Removing untracked_file
> > Removing untracked_foo/bar
> > Removing untracked_foo/emptydir
> > Removing untracked_foo/quux/quux.txt
> > warning: failed to remove untracked_foo/quux/failedquux.txt
> > warning: failed to remove remove untracked_unreadable_dir/
>
> "remove remove" is a typo, I presume.
>
> > warning: ignoring untracked git repository untracked_foo/frotz.git/
> > warning: ignoring untracked git repository untracked_some.git/
>
> If you mean "we report the topmost directory and nothing about
> (recursive) contents in it if everything is removed successfully"
> (in other words, if we had subdirectories and files inside
> untracked_foo/bar/ and we successfully removed all of them, the
> above output does not change), it seems quite reasonable.
>
> > Use git clean --force --force to delete all untracked git repositories
>
> But I am not sure if this is ever sane. Especially the one that
> removes an embedded repository is suspicious. "git clean" should
> not ever touch it with or without --superforce or any other command.
As I mentioned in my email where I reported this incorrect git clean output, I
have a use case where I want git clean to remove embedded repositories.
Whether it is a sane one is probably a different discussion.
Soren
^ permalink raw reply
* Re: [PATCHv2] mingw_rmdir: do not prompt for retry when non-empty
From: Junio C Hamano @ 2012-12-10 17:26 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Erik Faye-Lund, git, msysgit
In-Reply-To: <alpine.DEB.1.00.1212101804290.32206@s15462909.onlinehome-server.info>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> My preference would be to fix it in both branches. I will fix the merge
> conflicts when rebasing onto Junio's master branch next time.
OK, then I'll queue the following to my tree.
Thanks for a quick turnaround.
-- >8 --
From: Erik Faye-Lund <kusmabite@gmail.com>
Date: Mon, 10 Dec 2012 15:42:27 +0100
Subject: [PATCH] mingw_rmdir: do not prompt for retry when non-empty
in ab1a11be ("mingw_rmdir: set errno=ENOTEMPTY when appropriate"),
a check was added to prevent us from retrying to delete a directory
that is both in use and non-empty.
However, this logic was slightly flawed; since we didn't return
immediately, we end up falling out of the retry-loop, but right into
the prompting-loop.
Fix this by setting errno, and guarding the prompting-loop with an
errno-check.
Signed-off-by: Erik Faye-Lund <kusmabite@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
compat/mingw.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/compat/mingw.c b/compat/mingw.c
index 4e63838..28527ab 100644
--- a/compat/mingw.c
+++ b/compat/mingw.c
@@ -256,6 +256,8 @@ int mingw_rmdir(const char *pathname)
while ((ret = rmdir(pathname)) == -1 && tries < ARRAY_SIZE(delay)) {
if (!is_file_in_use_error(GetLastError()))
+ errno = err_win_to_posix(GetLastError());
+ if (errno != EACCES)
break;
if (!is_dir_empty(pathname)) {
errno = ENOTEMPTY;
@@ -271,7 +273,7 @@ int mingw_rmdir(const char *pathname)
Sleep(delay[tries]);
tries++;
}
- while (ret == -1 && is_file_in_use_error(GetLastError()) &&
+ while (ret == -1 && errno == EACCES && is_file_in_use_error(GetLastError()) &&
ask_yes_no_if_possible("Deletion of directory '%s' failed. "
"Should I try again?", pathname))
ret = rmdir(pathname);
--
1.8.1.rc1.123.gf61cb86
--
*** Please reply-to-all at all times ***
*** (do not pretend to know who is subscribed and who is not) ***
*** Please avoid top-posting. ***
The msysGit Wiki is here: https://github.com/msysgit/msysgit/wiki - Github accounts are free.
You received this message because you are subscribed to the Google
Groups "msysGit" group.
To post to this group, send email to msysgit@googlegroups.com
To unsubscribe from this group, send email to
msysgit+unsubscribe@googlegroups.com
For more options, and view previous threads, visit this group at
http://groups.google.com/group/msysgit?hl=en_US?hl=en
^ permalink raw reply related
* Re: [PATCH v2] cache-tree: invalidate i-t-a paths after generating trees
From: Junio C Hamano @ 2012-12-10 17:22 UTC (permalink / raw)
To: Nguyen Thai Ngoc Duy; +Cc: git, Jeff King, Jonathon Mah
In-Reply-To: <CACsJy8CW1UGgQcgHa11XP71XZGaTxytrGmJmrtdNvy=N7cUyMw@mail.gmail.com>
Nguyen Thai Ngoc Duy <pclouds@gmail.com> writes:
> Yeah I use entry_count for two different things here. In the previous
> (unsent) version of the patch I had "entry_count = -1" right after "i
> -= entry_count"
>
>>> + if (sub->cache_tree->entry_count < 0) {
>>> + i -= sub->cache_tree->entry_count;
>>> + sub->cache_tree->entry_count = -1;
>>> + to_invalidate = 1;
>>> + }
>
>
> which makes it clearer that the use of negative entry count is only
> valid within update_one. Then I changed my mind because it says
> 'negative means "invalid"' in cache-tree.h.
But you make it to mean not just 'negative means invalid' but
'negate it and you can learn how many index entries to skip to reach
the entry outside the subtree'. That is what I was wondering about.
I do not think that new invariant does not hold in general; it may
hold true while inside this function, but immediately after somebody
else calls cache_tree_invalidate_path() it won't be true anymore.
Leaking the information to outside callers that can easily be
mistaken as if it may mean something without any comment looks like
we are asking for trouble.
> So, put "entry_count = -1"
> back or just add another field to struct cache_tree for this?
As long as it is made clear with in-code comment that says "negative
entry count, when negated, will give us how many index entries are
covered by this invalid cache tree, only inside this function", and
such a negative entry_count is reset to -1 to avoid leaking out the
value that will soon go stale to the outside world in the "write
this tree out" loop, I think the v2 patch is OK, if not ideal.
If we were to commit to keep the new invariant true throughout the
system, on the other hand, I suspect that a boolean flag "valid" may
help people who keep i-t-a entries around across write-tree calls.
The first if () statement in the update_one() function can check the
validity, and you can say the cache tree is valid even if the
section in the index that is covered by the cache-tree contains
i-t-a entries _after_ you wrote it out as a tree, no? That may make
the semantics a lot cleaner, I suspect.
The new semantics might be:
* update_one() returns negative only when the section of the index
given to it cannot be written out as a tree (i.e. not merged, or
corrupt index);
* update_one() returns the number of entries in the index covered
by the tree, including i-t-a entries (but not REMOVED, as these
entries will not be in the index after the cache-tree has been
written out);
* cache_tree->valid tells if the cache_tree->sha1 is valid; the
section of the index the tree covers may or may not have i-t-a
entries in it;
* cache_tree->entry_count holds the number of index entries the
tree covers, couting i-t-a entries. This field is only meaningful
when cache_tree->valid is true.
or something like that.
I noticed that the recent "ignore i-t-a only while writing trees
instead of erroring out" broke 331fcb5 (git add --intent-to-add: do
not let an empty blob be committed by accident, 2008-11-28) in
another way, by the way. In verify_cache(), there is an unreachable
else clause to warn about "not added yet" entries that should have
been removed but is left behind.
^ permalink raw reply
* Re: [PATCHv2] mingw_rmdir: do not prompt for retry when non-empty
From: Johannes Schindelin @ 2012-12-10 17:05 UTC (permalink / raw)
To: Erik Faye-Lund; +Cc: Junio C Hamano, git, msysgit
In-Reply-To: <CABPQNSZL-edn4izfMuss1-3KbLBSrGm8J08wn0TbETtsn2nn+A@mail.gmail.com>
Hi kusma,
On Mon, 10 Dec 2012, Erik Faye-Lund wrote:
> On Mon, Dec 10, 2012 at 5:25 PM, Junio C Hamano <gitster@pobox.com> wrote:
> > Erik Faye-Lund <kusmabite@gmail.com> writes:
> >
> >> in ab1a11be ("mingw_rmdir: set errno=ENOTEMPTY when appropriate"), a
> >> check was added to prevent us from retrying to delete a directory
> >> that is both in use and non-empty.
> >>
> >> However, this logic was slightly flawed; since we didn't return
> >> immediately, we end up falling out of the retry-loop, but right into
> >> the prompting-loop.
> >>
> >> Fix this by setting errno, and guarding the prompting-loop with an
> >> errno-check.
> >>
> >> Signed-off-by: Erik Faye-Lund <kusmabite@gmail.com>
> >> ---
> >>
> >> Here's the second version of this patch, sorry for the slight delay.
> >
> > Is this meant for me, or is it to be applied to msysgit and later
> > somehow fed to me in different form?
> >
> > I can s/_wrmdir/rmdir/;s/wpathname/pathname/ if that is what you
> > want me to do, but otherwise this patch does not apply.
> >
>
> Ugh, you are right. I intended for you to apply it, but I didn't realize
> that my patch was based on the msysGit-master, where Karsten's UTF-8
> patches has been applied.
>
> I'm not entirely sure what the best approach would be. The issue is
> present in both branches, but we only build installers from the
> msysGit-branch. But I think there are other people who builds Git from
> the upstream source code, so it would be slightly less annoying for them
> if the patch was fixed up and applied. But on the other hand, that
> causes some annoyance when (if?) Karsten's UTF-8 patches gets
> upstreamed.
>
> Thoughts?
My preference would be to fix it in both branches. I will fix the merge
conflicts when rebasing onto Junio's master branch next time.
Ciao,
Dscho
--
*** Please reply-to-all at all times ***
*** (do not pretend to know who is subscribed and who is not) ***
*** Please avoid top-posting. ***
The msysGit Wiki is here: https://github.com/msysgit/msysgit/wiki - Github accounts are free.
You received this message because you are subscribed to the Google
Groups "msysGit" group.
To post to this group, send email to msysgit@googlegroups.com
To unsubscribe from this group, send email to
msysgit+unsubscribe@googlegroups.com
For more options, and view previous threads, visit this group at
http://groups.google.com/group/msysgit?hl=en_US?hl=en
^ permalink raw reply
* Re: [PATCH] git-clean: Display more accurate delete messages
From: Soren Brinkmann @ 2012-12-10 17:04 UTC (permalink / raw)
To: Zoltan Klinger; +Cc: Soren Brinkmann, Junio C Hamano, git
In-Reply-To: <CAKJhZwROXsTa4wu-C9rhfGysetL+cZRDECyFUn5VTb833pWzMQ@mail.gmail.com>
Hi Zoltan,
On Sun, Dec 09, 2012 at 10:18:19PM +1100, Zoltan Klinger wrote:
> >> Hrm, following your discussion (ellided above), I would have
> >> expected that you would show
> >>
> >> Removing directory foo/bar
> >> Removing untracked_file1
> >
> > Also it would be nice to have warnings about undeleted directories since this git
> > clean behavior (or the work around to pass -f twice) is not documented.
> > Without a warning you would probably miss that something was _not_ deleted.
>
> Thanks for the feedback. I think you're right. Showing 'foo/bar/bar.txt' in
> the list when 'foo/bar/' directory has been successfully deleted is just noise.
>
> Would like to get some more feedback on the proposed output in case of
> (1) an untracked subdirectory with multiple files where at least one of them
> cannot be removed.
> (2) reporting ignored untracked git subdirectories
>
> Suppose we have a repo like the one below:
> test.git/
> |-- tracked_file
> |-- untracked_file
> |-- untracked_foo/
> | |-- bar/
> | | |-- bar.txt
> | |-- emptydir/
> | |-- frotz.git/
> | | |-- frotx.txt
> | |-- quux/
> | |-- failedquux.txt
> | |-- quux.txt
> |-- untracked_unreadable_dir/
> | |-- afile
> |-- untracked_some.git/
> |-- some.txt
>
> $ git clean -fd
> Removing untracked_file
> Removing untracked_foo/bar
> Removing untracked_foo/emptydir
> Removing untracked_foo/quux/quux.txt
> warning: failed to remove untracked_foo/quux/failedquux.txt
> warning: failed to remove remove untracked_unreadable_dir/
> warning: ignoring untracked git repository untracked_foo/frotz.git/
> warning: ignoring untracked git repository untracked_some.git/
> Use git clean --force --force to delete all untracked git repositories
>
> $ # use forced remove
> $ git clean --force --force -d
> Removing untracked_foo/frotz.git
> Removing untracked_foo/quux/quux.txt
> Removing untracked_some.git/
> warning: failed to remove untracked_foo/quux/failedquux.txt
> warning: failed to remove untracked_unreadable_dir/
>
> Can you see any issues with the proposed output, wording above? If
> everyone is happy,
> I'm going to prepare patch V2 for it.
Looks good to me.
Thanks,
Soren
^ permalink raw reply
* Re: [PATCHv2] mingw_rmdir: do not prompt for retry when non-empty
From: Erik Faye-Lund @ 2012-12-10 16:50 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, msysgit, johannes.schindelin
In-Reply-To: <7vr4mxc1rd.fsf@alter.siamese.dyndns.org>
On Mon, Dec 10, 2012 at 5:25 PM, Junio C Hamano <gitster@pobox.com> wrote:
> Erik Faye-Lund <kusmabite@gmail.com> writes:
>
>> in ab1a11be ("mingw_rmdir: set errno=ENOTEMPTY when appropriate"),
>> a check was added to prevent us from retrying to delete a directory
>> that is both in use and non-empty.
>>
>> However, this logic was slightly flawed; since we didn't return
>> immediately, we end up falling out of the retry-loop, but right into
>> the prompting-loop.
>>
>> Fix this by setting errno, and guarding the prompting-loop with an
>> errno-check.
>>
>> Signed-off-by: Erik Faye-Lund <kusmabite@gmail.com>
>> ---
>>
>> Here's the second version of this patch, sorry for the slight delay.
>
> Is this meant for me, or is it to be applied to msysgit and later
> somehow fed to me in different form?
>
> I can s/_wrmdir/rmdir/;s/wpathname/pathname/ if that is what you
> want me to do, but otherwise this patch does not apply.
>
Ugh, you are right. I intended for you to apply it, but I didn't
realize that my patch was based on the msysGit-master, where Karsten's
UTF-8 patches has been applied.
I'm not entirely sure what the best approach would be. The issue is
present in both branches, but we only build installers from the
msysGit-branch. But I think there are other people who builds Git from
the upstream source code, so it would be slightly less annoying for
them if the patch was fixed up and applied. But on the other hand,
that causes some annoyance when (if?) Karsten's UTF-8 patches gets
upstreamed.
Thoughts?
--
*** Please reply-to-all at all times ***
*** (do not pretend to know who is subscribed and who is not) ***
*** Please avoid top-posting. ***
The msysGit Wiki is here: https://github.com/msysgit/msysgit/wiki - Github accounts are free.
You received this message because you are subscribed to the Google
Groups "msysGit" group.
To post to this group, send email to msysgit@googlegroups.com
To unsubscribe from this group, send email to
msysgit+unsubscribe@googlegroups.com
For more options, and view previous threads, visit this group at
http://groups.google.com/group/msysgit?hl=en_US?hl=en
^ permalink raw reply
* Re: [PATCH] Makefile: whitespace style fixes in macro definitions
From: Junio C Hamano @ 2012-12-10 16:37 UTC (permalink / raw)
To: Stefano Lattarini; +Cc: git
In-Reply-To: <0544836357d56c05188941ef5a471605fa6d4881.1355049367.git.stefano.lattarini@gmail.com>
Stefano Lattarini <stefano.lattarini@gmail.com> writes:
> Consistently use a single space before and after the "=" (or ":=", "+=",
> etc.) in assignments to make macros. Granted, this was not a big deal,
> but I did find the needless inconsistency quite distracting.
>
> Signed-off-by: Stefano Lattarini <stefano.lattarini@gmail.com>
> ---
Makes sense to do this kind of clean-up when these files are
quiescent (and they are).
Thanks.
> Makefile | 56 ++++++++++++++++++++++++++++----------------------------
> config.mak.in | 2 +-
> t/Makefile | 2 +-
> 3 files changed, 30 insertions(+), 30 deletions(-)
>
> diff --git a/Makefile b/Makefile
> index 4ad6fbd..736ecd4 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -374,7 +374,7 @@ htmldir = share/doc/git-doc
> ETC_GITCONFIG = $(sysconfdir)/gitconfig
> ETC_GITATTRIBUTES = $(sysconfdir)/gitattributes
> lib = lib
> -# DESTDIR=
> +# DESTDIR =
> pathsep = :
>
> export prefix bindir sharedir sysconfdir gitwebdir localedir
> @@ -575,9 +575,9 @@ endif
> export PERL_PATH
> export PYTHON_PATH
>
> -LIB_FILE=libgit.a
> -XDIFF_LIB=xdiff/lib.a
> -VCSSVN_LIB=vcs-svn/lib.a
> +LIB_FILE = libgit.a
> +XDIFF_LIB = xdiff/lib.a
> +VCSSVN_LIB = vcs-svn/lib.a
>
> LIB_H += xdiff/xinclude.h
> LIB_H += xdiff/xmacros.h
> @@ -1139,7 +1139,7 @@ ifeq ($(uname_S),NetBSD)
> endif
> ifeq ($(uname_S),AIX)
> DEFAULT_PAGER = more
> - NO_STRCASESTR=YesPlease
> + NO_STRCASESTR = YesPlease
> NO_MEMMEM = YesPlease
> NO_MKDTEMP = YesPlease
> NO_MKSTEMPS = YesPlease
> @@ -1147,7 +1147,7 @@ ifeq ($(uname_S),AIX)
> NO_NSEC = YesPlease
> FREAD_READS_DIRECTORIES = UnfortunatelyYes
> INTERNAL_QSORT = UnfortunatelyYes
> - NEEDS_LIBICONV=YesPlease
> + NEEDS_LIBICONV = YesPlease
> BASIC_CFLAGS += -D_LARGE_FILES
> ifeq ($(shell expr "$(uname_V)" : '[1234]'),1)
> NO_PTHREADS = YesPlease
> @@ -1155,13 +1155,13 @@ ifeq ($(uname_S),AIX)
> PTHREAD_LIBS = -lpthread
> endif
> ifeq ($(shell expr "$(uname_V).$(uname_R)" : '5\.1'),3)
> - INLINE=''
> + INLINE = ''
> endif
> GIT_TEST_CMP = cmp
> endif
> ifeq ($(uname_S),GNU)
> # GNU/Hurd
> - NO_STRLCPY=YesPlease
> + NO_STRLCPY = YesPlease
> NO_MKSTEMPS = YesPlease
> HAVE_PATHS_H = YesPlease
> LIBC_CONTAINS_LIBINTL = YesPlease
> @@ -1187,9 +1187,9 @@ ifeq ($(uname_S),IRIX)
> NEEDS_LIBGEN = YesPlease
> endif
> ifeq ($(uname_S),IRIX64)
> - NO_SETENV=YesPlease
> + NO_SETENV = YesPlease
> NO_UNSETENV = YesPlease
> - NO_STRCASESTR=YesPlease
> + NO_STRCASESTR = YesPlease
> NO_MEMMEM = YesPlease
> NO_MKSTEMPS = YesPlease
> NO_MKDTEMP = YesPlease
> @@ -1203,14 +1203,14 @@ ifeq ($(uname_S),IRIX64)
> NO_REGEX = YesPlease
> NO_FNMATCH_CASEFOLD = YesPlease
> SNPRINTF_RETURNS_BOGUS = YesPlease
> - SHELL_PATH=/usr/gnu/bin/bash
> + SHELL_PATH = /usr/gnu/bin/bash
> NEEDS_LIBGEN = YesPlease
> endif
> ifeq ($(uname_S),HP-UX)
> INLINE = __inline
> - NO_IPV6=YesPlease
> - NO_SETENV=YesPlease
> - NO_STRCASESTR=YesPlease
> + NO_IPV6 = YesPlease
> + NO_SETENV = YesPlease
> + NO_STRCASESTR = YesPlease
> NO_MEMMEM = YesPlease
> NO_MKSTEMPS = YesPlease
> NO_STRLCPY = YesPlease
> @@ -1386,10 +1386,10 @@ ifeq ($(uname_S),NONSTOP_KERNEL)
> MKDIR_WO_TRAILING_SLASH = YesPlease
> # RFE 10-120912-4693 submitted to HP NonStop development.
> NO_SETITIMER = UnfortunatelyYes
> - SANE_TOOL_PATH=/usr/coreutils/bin:/usr/local/bin
> - SHELL_PATH=/usr/local/bin/bash
> + SANE_TOOL_PATH = /usr/coreutils/bin:/usr/local/bin
> + SHELL_PATH = /usr/local/bin/bash
> # as of H06.25/J06.14, we might better use this
> - #SHELL_PATH=/usr/coreutils/bin/bash
> + #SHELL_PATH = /usr/coreutils/bin/bash
> endif
> ifneq (,$(findstring MINGW,$(uname_S)))
> pathsep = ;
> @@ -1437,7 +1437,7 @@ ifneq (,$(findstring MINGW,$(uname_S)))
> X = .exe
> SPARSE_FLAGS = -Wno-one-bit-signed-bitfield
> ifneq (,$(wildcard ../THIS_IS_MSYSGIT))
> - htmldir=doc/git/html/
> + htmldir = doc/git/html/
> prefix =
> INSTALL = /bin/install
> EXTLIBS += /mingw/lib/libz.a
> @@ -1559,7 +1559,7 @@ else
> CURL_LIBCURL = -lcurl
> endif
> ifdef NEEDS_SSL_WITH_CURL
> - CURL_LIBCURL += -lssl
> + CURL_LIBCURL += -lssl
> ifdef NEEDS_CRYPTO_WITH_SSL
> CURL_LIBCURL += -lcrypto
> endif
> @@ -1768,7 +1768,7 @@ ifdef OBJECT_CREATION_USES_RENAMES
> endif
> ifdef NO_STRUCT_ITIMERVAL
> COMPAT_CFLAGS += -DNO_STRUCT_ITIMERVAL
> - NO_SETITIMER=YesPlease
> + NO_SETITIMER = YesPlease
> endif
> ifdef NO_SETITIMER
> COMPAT_CFLAGS += -DNO_SETITIMER
> @@ -1920,15 +1920,15 @@ ifneq (,$(XDL_FAST_HASH))
> endif
>
> ifeq ($(TCLTK_PATH),)
> -NO_TCLTK=NoThanks
> +NO_TCLTK = NoThanks
> endif
>
> ifeq ($(PERL_PATH),)
> -NO_PERL=NoThanks
> +NO_PERL = NoThanks
> endif
>
> ifeq ($(PYTHON_PATH),)
> -NO_PYTHON=NoThanks
> +NO_PYTHON = NoThanks
> endif
>
> QUIET_SUBDIR0 = +$(MAKE) -C # space to separate -C and subdir
> @@ -1975,13 +1975,13 @@ PROFILE_DIR := $(CURDIR)
> ifeq ("$(PROFILE)","GEN")
> CFLAGS += -fprofile-generate=$(PROFILE_DIR) -DNO_NORETURN=1
> EXTLIBS += -lgcov
> - export CCACHE_DISABLE=t
> - V=1
> + export CCACHE_DISABLE = t
> + V = 1
> else
> ifneq ("$(PROFILE)","")
> CFLAGS += -fprofile-use=$(PROFILE_DIR) -fprofile-correction -DNO_NORETURN=1
> - export CCACHE_DISABLE=t
> - V=1
> + export CCACHE_DISABLE = t
> + V = 1
> endif
> endif
>
> @@ -2830,7 +2830,7 @@ git.spec: git.spec.in GIT-VERSION-FILE
> sed -e 's/@@VERSION@@/$(GIT_VERSION)/g' < $< > $@+
> mv $@+ $@
>
> -GIT_TARNAME=git-$(GIT_VERSION)
> +GIT_TARNAME = git-$(GIT_VERSION)
> dist: git.spec git-archive$(X) configure
> ./git-archive --format=tar \
> --prefix=$(GIT_TARNAME)/ HEAD^{tree} > $(GIT_TARNAME).tar
> diff --git a/config.mak.in b/config.mak.in
> index 69d4838..e8a9bb4 100644
> --- a/config.mak.in
> +++ b/config.mak.in
> @@ -18,7 +18,7 @@ datarootdir = @datarootdir@
> template_dir = @datadir@/git-core/templates
> sysconfdir = @sysconfdir@
>
> -mandir=@mandir@
> +mandir = @mandir@
>
> srcdir = @srcdir@
> VPATH = @srcdir@
> diff --git a/t/Makefile b/t/Makefile
> index 88e289f..3025418 100644
> --- a/t/Makefile
> +++ b/t/Makefile
> @@ -6,7 +6,7 @@
> -include ../config.mak.autogen
> -include ../config.mak
>
> -#GIT_TEST_OPTS=--verbose --debug
> +#GIT_TEST_OPTS = --verbose --debug
> SHELL_PATH ?= $(SHELL)
> PERL_PATH ?= /usr/bin/perl
> TAR ?= $(TAR)
^ permalink raw reply
* Re: [PATCHv2] mingw_rmdir: do not prompt for retry when non-empty
From: Junio C Hamano @ 2012-12-10 16:25 UTC (permalink / raw)
To: Erik Faye-Lund; +Cc: git, msysgit, johannes.schindelin
In-Reply-To: <1355150547-8212-1-git-send-email-kusmabite@gmail.com>
Erik Faye-Lund <kusmabite@gmail.com> writes:
> in ab1a11be ("mingw_rmdir: set errno=ENOTEMPTY when appropriate"),
> a check was added to prevent us from retrying to delete a directory
> that is both in use and non-empty.
>
> However, this logic was slightly flawed; since we didn't return
> immediately, we end up falling out of the retry-loop, but right into
> the prompting-loop.
>
> Fix this by setting errno, and guarding the prompting-loop with an
> errno-check.
>
> Signed-off-by: Erik Faye-Lund <kusmabite@gmail.com>
> ---
>
> Here's the second version of this patch, sorry for the slight delay.
Is this meant for me, or is it to be applied to msysgit and later
somehow fed to me in different form?
I can s/_wrmdir/rmdir/;s/wpathname/pathname/ if that is what you
want me to do, but otherwise this patch does not apply.
>
> compat/mingw.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/compat/mingw.c b/compat/mingw.c
> index 1eb974f..440224c 100644
> --- a/compat/mingw.c
> +++ b/compat/mingw.c
> @@ -260,6 +260,8 @@ int mingw_rmdir(const char *pathname)
>
> while ((ret = _wrmdir(wpathname)) == -1 && tries < ARRAY_SIZE(delay)) {
> if (!is_file_in_use_error(GetLastError()))
> + errno = err_win_to_posix(GetLastError());
> + if (errno != EACCES)
> break;
> if (!is_dir_empty(wpathname)) {
> errno = ENOTEMPTY;
> @@ -275,7 +277,7 @@ int mingw_rmdir(const char *pathname)
> Sleep(delay[tries]);
> tries++;
> }
> - while (ret == -1 && is_file_in_use_error(GetLastError()) &&
> + while (ret == -1 && errno == EACCES && is_file_in_use_error(GetLastError()) &&
> ask_yes_no_if_possible("Deletion of directory '%s' failed. "
> "Should I try again?", pathname))
> ret = _wrmdir(wpathname);
--
*** Please reply-to-all at all times ***
*** (do not pretend to know who is subscribed and who is not) ***
*** Please avoid top-posting. ***
The msysGit Wiki is here: https://github.com/msysgit/msysgit/wiki - Github accounts are free.
You received this message because you are subscribed to the Google
Groups "msysGit" group.
To post to this group, send email to msysgit@googlegroups.com
To unsubscribe from this group, send email to
msysgit+unsubscribe@googlegroups.com
For more options, and view previous threads, visit this group at
http://groups.google.com/group/msysgit?hl=en_US?hl=en
^ permalink raw reply
* [PATCHv2] mingw_rmdir: do not prompt for retry when non-empty
From: Erik Faye-Lund @ 2012-12-10 14:42 UTC (permalink / raw)
To: git; +Cc: msysgit, johannes.schindelin, gitster
in ab1a11be ("mingw_rmdir: set errno=ENOTEMPTY when appropriate"),
a check was added to prevent us from retrying to delete a directory
that is both in use and non-empty.
However, this logic was slightly flawed; since we didn't return
immediately, we end up falling out of the retry-loop, but right into
the prompting-loop.
Fix this by setting errno, and guarding the prompting-loop with an
errno-check.
Signed-off-by: Erik Faye-Lund <kusmabite@gmail.com>
---
Here's the second version of this patch, sorry for the slight delay.
compat/mingw.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/compat/mingw.c b/compat/mingw.c
index 1eb974f..440224c 100644
--- a/compat/mingw.c
+++ b/compat/mingw.c
@@ -260,6 +260,8 @@ int mingw_rmdir(const char *pathname)
while ((ret = _wrmdir(wpathname)) == -1 && tries < ARRAY_SIZE(delay)) {
if (!is_file_in_use_error(GetLastError()))
+ errno = err_win_to_posix(GetLastError());
+ if (errno != EACCES)
break;
if (!is_dir_empty(wpathname)) {
errno = ENOTEMPTY;
@@ -275,7 +277,7 @@ int mingw_rmdir(const char *pathname)
Sleep(delay[tries]);
tries++;
}
- while (ret == -1 && is_file_in_use_error(GetLastError()) &&
+ while (ret == -1 && errno == EACCES && is_file_in_use_error(GetLastError()) &&
ask_yes_no_if_possible("Deletion of directory '%s' failed. "
"Should I try again?", pathname))
ret = _wrmdir(wpathname);
--
1.8.0.msysgit.0.3.gafa53b0.dirty
--
*** Please reply-to-all at all times ***
*** (do not pretend to know who is subscribed and who is not) ***
*** Please avoid top-posting. ***
The msysGit Wiki is here: https://github.com/msysgit/msysgit/wiki - Github accounts are free.
You received this message because you are subscribed to the Google
Groups "msysGit" group.
To post to this group, send email to msysgit@googlegroups.com
To unsubscribe from this group, send email to
msysgit+unsubscribe@googlegroups.com
For more options, and view previous threads, visit this group at
http://groups.google.com/group/msysgit?hl=en_US?hl=en
^ permalink raw reply related
* Re: [PATCH] git(1): remove a defunct link to "list of authors"
From: Nguyen Thai Ngoc Duy @ 2012-12-10 12:04 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vboe2ct9p.fsf@alter.siamese.dyndns.org>
On Mon, Dec 10, 2012 at 1:31 PM, Junio C Hamano <gitster@pobox.com> wrote:
> Nguyen Thai Ngoc Duy <pclouds@gmail.com> writes:
>
>> On Sat, Dec 8, 2012 at 12:59 AM, Junio C Hamano <gitster@pobox.com> wrote:
>>>> * If somebody has a working replacement URL, we could use that
>>>> instead, of course. Takers?
>>>
>>> A possible alternative could be https://www.ohloh.net/p/git/contributors/summary
>>
>> Nice charts!
>
> Yup.
>
> Their numbers seem to be just 'any commit by the author, with
> mailmap applied', and I am of two minds with it. Counting without
> "shortlog --no-merges", depending on the management style of the
> project, tends to credit the integrator too much. Even though
> vetting the patches and choosing when to merge the topics is a
> significant contribution, it isn't *that* big compared to the work
> done by the contributor who took initiative to scratch that itch.
>
> With or without "--no-merges", the big picture you can get out of
> "git shortlog -s -n --since=1.year" does not change very much, but
> the headline numbers give a wrong impression.
These numbers are approximate anyway. Commit counts or the number of
changed lines do not accurately reflect the effort in many cases. And
about merges, in this particular case of Git where the maintainer imo
has done an excellent job as a guard, I'd say it's the credit for
reviewing, not simply merging.
But not using the link is fine too. We can wait for Jeff's patch to be merged.
> And of course, application of the mailmap is very important, if you
> want to get meaningful numbers out of shortlog over a longer period.
--
Duy
^ permalink raw reply
* Re: [PATCH v2] cache-tree: invalidate i-t-a paths after generating trees
From: Nguyen Thai Ngoc Duy @ 2012-12-10 11:53 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Jeff King, Jonathon Mah
In-Reply-To: <7v7goqcsdy.fsf@alter.siamese.dyndns.org>
On Mon, Dec 10, 2012 at 1:50 PM, Junio C Hamano <gitster@pobox.com> wrote:
> Nguyễn Thái Ngọc Duy <pclouds@gmail.com> writes:
>
>> diff --git a/cache-tree.c b/cache-tree.c
>> index 28ed657..989a7ff 100644
>> --- a/cache-tree.c
>> +++ b/cache-tree.c
>> @@ -248,6 +248,7 @@ static int update_one(struct cache_tree *it,
>> int missing_ok = flags & WRITE_TREE_MISSING_OK;
>> int dryrun = flags & WRITE_TREE_DRY_RUN;
>> int i;
>> + int to_invalidate = 0;
>>
>> if (0 <= it->entry_count && has_sha1_file(it->sha1))
>> return it->entry_count;
>> @@ -324,7 +325,13 @@ static int update_one(struct cache_tree *it,
>> if (!sub)
>> die("cache-tree.c: '%.*s' in '%s' not found",
>> entlen, path + baselen, path);
>> - i += sub->cache_tree->entry_count - 1;
>> + i--; /* this entry is already counted in "sub" */
>> + if (sub->cache_tree->entry_count < 0) {
>> + i -= sub->cache_tree->entry_count;
>> + to_invalidate = 1;
>> + }
>> + else
>> + i += sub->cache_tree->entry_count;
>
> Hrm. update_one() is prepared to see a cache-tree whose entry count
> is zero (see the context lines in the previous hunk) and the
> invariant for the rest of the code is "if 0 <= entry_count, the
> cached tree is valid; invalid cache-tree has -1 in entry_count.
> More importantly, entry_count negated does not in general express
> how many entries there are in the subtree and does not tell us how
> many index entries to skip.
Yeah I use entry_count for two different things here. In the previous
(unsent) version of the patch I had "entry_count = -1" right after "i
-= entry_count"
>> + if (sub->cache_tree->entry_count < 0) {
>> + i -= sub->cache_tree->entry_count;
>> + sub->cache_tree->entry_count = -1;
>> + to_invalidate = 1;
>> + }
which makes it clearer that the use of negative entry count is only
valid within update_one. Then I changed my mind because it says
'negative means "invalid"' in cache-tree.h. So, put "entry_count = -1"
back or just add another field to struct cache_tree for this?
--
Duy
^ permalink raw reply
* Re: Feature Request - Hide ignored files before checkout
From: Erik Faye-Lund @ 2012-12-10 9:47 UTC (permalink / raw)
To: Matthew Ciancio; +Cc: Andrew Ardill, git
In-Reply-To: <000001cdd67a$39be9d40$ad3bd7c0$@gmail.com>
On Mon, Dec 10, 2012 at 3:01 AM, Matthew Ciancio
<matthew.ciancio16@gmail.com> wrote:
> Thanks for explaining that Andrew. I guess that was my intention: to have an "ignored file snapshot", but I can see now that it goes against Git's definitions and is not really needed.
>
I have played around with the idea of backing up files deleted by
git-clean in the object database, maintained by a reflog (similar to
git-stash). I did this to protect my code against my fat fingers, but
perhaps this could also have been useful in your case?
https://github.com/kusma/git/tree/work/clean-backup
^ permalink raw reply
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