All of lore.kernel.org
 help / color / mirror / Atom feed
* What's cooking in git.git (Jul 2014, #04; Tue, 22)
@ 2014-07-22 21:44 Junio C Hamano
  2014-07-23  6:56 ` Philip Oakley
  2014-07-23 14:17 ` What's cooking in git.git (Jul 2014, #04; Tue, 22) Karsten Blees
  0 siblings, 2 replies; 19+ messages in thread
From: Junio C Hamano @ 2014-07-22 21:44 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'.

We would need to start slowing down to prepare for -rc0 preview at
the end of this week and then feature freeze.  Some topics that
joined 'next' late may want to stay there for the remainder of this
cycle.  Many of the accumulated fixes have been flushed to 'maint'
and Git 2.0.2 has been tagged.

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

--------------------------------------------------
[Graduated to "master"]

* ak/profile-feedback-build (2014-07-08) 4 commits
  (merged to 'next' on 2014-07-14 at c40e86e)
 + Fix profile feedback with -jN and add profile-fast
 + Run the perf test suite for profile feedback too
 + Don't define away __attribute__ on gcc
 + Use BASIC_FLAGS for profile feedback

 The support for the profile-feedback build, which has been left
 bit-rotten for quite a while, has been updated.


* cc/for-each-mergetag (2014-07-07) 1 commit
  (merged to 'next' on 2014-07-15 at c5dd3ee)
 + commit: add for_each_mergetag()
 (this branch is used by cc/replace-graft.)


* ek/alt-odb-entry-fix (2014-07-15) 1 commit
  (merged to 'next' on 2014-07-17 at a5f43e2)
 + sha1_file: do not add own object directory as alternate


* jk/alloc-commit-id (2014-07-13) 8 commits
  (merged to 'next' on 2014-07-16 at f14c01a)
 + diff-tree: avoid lookup_unknown_object
 + object_as_type: set commit index
 + alloc: factor out commit index
 + add object_as_type helper for casting objects
 + parse_object_buffer: do not set object type
 + move setting of object->type to alloc_* functions
 + alloc: write out allocator definitions
 + alloc.c: remove the alloc_raw_commit_node() function

 Make sure all in-core commit objects are assigned a unique number
 so that they can be annotated using the commit-slab API.


* jk/remote-curl-squelch-extra-errors (2014-07-10) 3 commits
  (merged to 'next' on 2014-07-14 at a2efa2f)
 + remote-curl: mark helper-protocol errors more clearly
 + remote-curl: use error instead of fprintf(stderr)
 + remote-curl: do not complain on EOF from parent git

 Show HTTP transfer errors from remote-curl helper more clearly to
 help avoid user confusion.


* jl/submodule-tests (2014-07-14) 14 commits
  (merged to 'next' on 2014-07-14 at 0c750bb)
 + revert: add t3513 for submodule updates
 + stash: add t3906 for submodule updates
 + am: add t4255 for submodule updates
 + cherry-pick: add t3512 for submodule updates
 + pull: add t5572 for submodule updates
 + rebase: add t3426 for submodule updates
 + merge: add t7613 for submodule updates
 + bisect: add t6041 for submodule updates
 + reset: add t7112 for submodule updates
 + read-tree: add t1013 for submodule updates
 + apply: add t4137 for submodule updates
 + checkout: call the new submodule update test framework
 + submodules: add the lib-submodule-update.sh test library
 + test-lib: add test_dir_is_empty()


* kb/avoid-fchmod-for-now (2014-07-16) 1 commit
  (merged to 'next' on 2014-07-17 at fc26c4b)
 + config: use chmod() instead of fchmod()

 Replace the only two uses of fchmod() with chmod() because the
 former does not work on Windows port and because luckily we can.


* kb/hashmap-updates (2014-07-07) 4 commits
  (merged to 'next' on 2014-07-15 at 6dd6611)
 + hashmap: add string interning API
 + hashmap: add simplified hashmap_get_from_hash() API
 + hashmap: improve struct hashmap member documentation
 + hashmap: factor out getting a hash code from a SHA1


* kb/perf-trace (2014-07-13) 17 commits
  (merged to 'next' on 2014-07-15 at 09ade08)
 + api-trace.txt: add trace API documentation
 + progress: simplify performance measurement by using getnanotime()
 + wt-status: simplify performance measurement by using getnanotime()
 + git: add performance tracing for git's main() function to debug scripts
 + trace: add trace_performance facility to debug performance issues
 + trace: add high resolution timer function to debug performance issues
 + trace: add 'file:line' to all trace output
 + trace: move code around, in preparation to file:line output
 + trace: add current timestamp to all trace output
 + trace: disable additional trace output for unit tests
 + trace: add infrastructure to augment trace output with additional info
 + sha1_file: change GIT_TRACE_PACK_ACCESS logging to use trace API
 + Documentation/git.txt: improve documentation of 'GIT_TRACE*' variables
 + trace: improve trace performance
 + trace: remove redundant printf format attribute
 + trace: consistently name the format parameter
 + trace: move trace declarations from cache.h to new trace.h

 Show timestamps in GIT_TRACE output.


* nd/path-max-must-go (2014-07-14) 3 commits
  (merged to 'next' on 2014-07-15 at ce68dde)
 + prep_exclude: remove the artificial PATH_MAX limit
 + dir.h: move struct exclude declaration to top level
 + dir.c: coding style fix

 Lift arbitrary PATH_MAX limit in the code to enumerate paths in the
 working tree.


* rs/code-cleaning (2014-07-18) 7 commits
  (merged to 'next' on 2014-07-21 at 7312ddc)
 + remote-testsvn: use internal argv_array of struct child_process in cmd_import()
 + bundle: use internal argv_array of struct child_process in create_bundle()
 + fast-import: use hashcmp() for SHA1 hash comparison
 + transport: simplify fetch_objs_via_rsync() using argv_array
 + run-command: use internal argv_array of struct child_process in run_hook_ve()
 + use commit_list_count() to count the members of commit_lists
 + strbuf: use strbuf_addstr() for adding C strings


* rs/ref-transaction-0 (2014-07-14) 19 commits
  (merged to 'next' on 2014-07-14 at b21bcee)
 + refs.c: change ref_transaction_update() to do error checking and return status
 + refs.c: remove the onerr argument to ref_transaction_commit
 + update-ref: use err argument to get error from ref_transaction_commit
 + refs.c: make update_ref_write update a strbuf on failure
 + refs.c: make ref_update_reject_duplicates take a strbuf argument for errors
 + refs.c: log_ref_write should try to return meaningful errno
 + refs.c: make resolve_ref_unsafe set errno to something meaningful on error
 + refs.c: commit_packed_refs to return a meaningful errno on failure
 + refs.c: make remove_empty_directories always set errno to something sane
 + refs.c: verify_lock should set errno to something meaningful
 + refs.c: make sure log_ref_setup returns a meaningful errno
 + refs.c: add an err argument to repack_without_refs
 + lockfile.c: make lock_file return a meaningful errno on failurei
 + lockfile.c: add a new public function unable_to_lock_message
 + refs.c: add a strbuf argument to ref_transaction_commit for error logging
 + refs.c: allow passing NULL to ref_transaction_free
 + refs.c: constify the sha arguments for ref_transaction_create|delete|update
 + refs.c: ref_transaction_commit should not free the transaction
 + refs.c: remove ref_transaction_rollback
 (this branch is used by rs/ref-transaction and rs/ref-transaction-1.)

 Early part of the "ref transaction" topic.


* rs/unify-is-branch (2014-07-16) 1 commit
  (merged to 'next' on 2014-07-17 at 55f530b)
 + refs.c: add a public is_branch function


* sk/mingw-uni-fix (2014-07-15) 2 commits
  (merged to 'next' on 2014-07-17 at ffef7a1)
 + Win32: Unicode file name support (dirent)
 + Win32: Unicode file name support (except dirent)
 (this branch is used by sk/mingw-uni-fix-more.)

--------------------------------------------------
[New Topics]

* mb/local-clone-after-applying-insteadof (2014-07-17) 1 commit
  (merged to 'next' on 2014-07-21 at ebe07c2)
 + use local cloning if insteadOf makes a local URL

 Apply the "if cloning from a local disk, physically copy repository
 using hardlinks, unless otherwise told not to with --no-local"
 optimization when url.*.insteadOf mechanism rewrites a "git clone
 $URL" that refers to a repository over the network to a clone from
 a local disk.

 Will merge to 'master'.


* nd/path-max-is-better-than-hardcoded-magic-1024 (2014-07-17) 1 commit
 - abspath.c: use PATH_MAX in real_path_internal()

 Still being discussed.


* sk/mingw-uni-fix-more (2014-07-21) 14 commits
 - Win32: enable color output in Windows cmd.exe
 - Win32: patch Windows environment on startup
 - Win32: keep the environment sorted
 - Win32: use low-level memory allocation during initialization
 - Win32: reduce environment array reallocations
 - Win32: don't copy the environment twice when spawning child processes
 - Win32: factor out environment block creation
 - Win32: unify environment function names
 - Win32: unify environment case-sensitivity
 - Win32: fix environment memory leaks
 - Win32: Unicode environment (incoming)
 - Win32: Unicode environment (outgoing)
 - Revert "Windows: teach getenv to do a case-sensitive search"
 - tests: do not pass iso8859-1 encoded parameter

 Most of these are battle-tested in msysgit and are needed to
 complete what has been merged to 'master' already.

 A fix has been squashed into "Unicode environ (outgoing)"; is this
 now ready to go?


* sk/mingw-tests-workaround (2014-07-21) 6 commits
 - t800[12]: work around MSys limitation
 - t9902: mingw-specific fix for gitfile link files
 - t4210: skip command-line encoding tests on mingw
 - MinGW: disable legacy encoding tests
 - t0110/MinGW: skip tests that pass arbitrary bytes on the command line
 - MinGW: Skip test redirecting to fd 4
 (this branch is used by jc/not-mingw-cygwin.)

 Make tests pass on msysgit by mostly disabling ones that are
 infeasible on that platform.

 The t0110 one has been replaced; is this now ready to go?


* ta/string-list-init (2014-07-21) 2 commits
  (merged to 'next' on 2014-07-21 at 63e8891)
 + replace memset with string-list initializers
 + string-list: add string_list initializer helper function
 (this branch is tangled with ta/config-set.)

 Will merge to 'master'.


* cb/mergetool-difftool (2014-07-21) 2 commits
 - difftool: don't assume that default sh is sane
 - mergetool: don't require a work tree for --tool-help


* rs/fix-unlink-unix-socket (2014-07-21) 1 commit
  (merged to 'next' on 2014-07-22 at fad8c29)
 + unix-socket: remove stale socket before calling chdir()

 The unix-domain socket used by the sample credential cache daemon
 tried to unlink an existing stale one at a wrong path, if the path
 to the socket was given as an overlong path that does not fit in
 sun_path member of the sockaddr_un structure.

 Will merge to 'master'.


* rs/strbuf-getcwd (2014-07-21) 4 commits
 - use xgetcwd() get the current directory or die
 - wrapper: add xgetcwd()
 - use strbuf_getcwd() to get the current working directory without fixed-sized buffers
 - strbuf: add strbuf_getcwd()

 Still being discussed.


* jc/not-mingw-cygwin (2014-07-21) 2 commits
 - test prerequisites: enumerate with commas
 - test prerequisites: eradicate NOT_FOO
 (this branch uses sk/mingw-tests-workaround.)

 We have been using NOT_{MINGW,CYGWIN} test prerequisites long
 before Peff invented support for negated prerequisites e.g. !MINGW
 and we still add more uses of the former.  Convert them to the
 latter to avoid confusion.


* jk/more-push-completion (2014-07-22) 3 commits
 - completion: complete `git push --force-with-lease=`
 - completion: add some missing options to `git push`
 - completion: complete "unstuck" `git push --recurse-submodules`

--------------------------------------------------
[Stalled]

* jk/tag-contains (2014-06-30) 8 commits
 . perf: add tests for tag --contains
 . tag: use commit_contains
 . commit: provide a fast multi-tip contains function
 . string-list: add pos to iterator callback
 . add functions for memory-efficient bitmaps
 . paint_down_to_common: use prio_queue
 . tag: factor out decision to stream tags
 . tag: allow --sort with -n

 Expecting a reroll.


* ab/add-interactive-show-diff-func-name (2014-05-12) 2 commits
 - SQUASH??? git-add--interactive: Preserve diff heading when splitting hunks
 - git-add--interactive: Preserve diff heading when splitting hunks

 Waiting for a reroll.


* jn/gitweb-utf8-in-links (2014-05-27) 1 commit
 - gitweb: Harden UTF-8 handling in generated links

 $gmane/250758?


* rh/prompt-tests (2014-06-05) 11 commits
 - t9904: new __git_ps1 tests for Zsh
 - test-lib: make it possible to override how test code is eval'd
 - lib-prompt-tests.sh: add variable for string that encodes percent in PS1
 - lib-prompt-tests.sh: put all tests inside a function
 - t9903: move prompt tests to a new lib-prompt-tests.sh file
 - t9903: move PS1 color code variable definitions to lib-bash.sh
 - t9903: include "Bash" in test names via new $shellname var
 - t9903: run pc mode tests again with PS1 expansion disabled
 - t9903: move test name prefix to a separate variable
 - t9903: put the Bash pc mode prompt test cases in a function
 - t9903: remove Zsh test from the suite of Bash prompt tests

 Expecting a reroll to limit the damage to test_eval_; also reported
 to be broken with older zsh that are still in the field ($gmane/251231).


* ss/userdiff-update-csharp-java (2014-06-02) 2 commits
 - userdiff: support Java try keyword
 - userdiff: support C# async methods and correct C# keywords

 Reviews sent; waiting for a response.


* cc/interpret-trailers (2014-05-28) 11 commits
 - Documentation: add documentation for 'git interpret-trailers'
 - trailer: add tests for commands in config file
 - trailer: execute command from 'trailer.<name>.command'
 - trailer: add tests for "git interpret-trailers"
 - trailer: add interpret-trailers command
 - trailer: put all the processing together and print
 - trailer: parse trailers from file or stdin
 - trailer: process command line trailer arguments
 - trailer: read and process config information
 - trailer: process trailers from input message and arguments
 - trailer: add data structures and basic functions

 A new filter to programatically edit the tail end of the commit log
 messages.

 What is the status of this one?  I think I saw reviews by Michael
 but after that I do not recall seeing any updates.


* mh/lockfile (2014-04-15) 25 commits
 . trim_last_path_elm(): replace last_path_elm()
 . resolve_symlink(): take a strbuf parameter
 . resolve_symlink(): use a strbuf for internal scratch space
 . change lock_file::filename into a strbuf
 . commit_lock_file(): use a strbuf to manage temporary space
 . try_merge_strategy(): use a statically-allocated lock_file object
 . try_merge_strategy(): remove redundant lock_file allocation
 . struct lock_file: declare some fields volatile
 . lockfile: avoid transitory invalid states
 . commit_lock_file(): die() if called for unlocked lockfile object
 . commit_lock_file(): inline temporary variable
 . remove_lock_file(): call rollback_lock_file()
 . lock_file(): exit early if lockfile cannot be opened
 . write_packed_entry_fn(): convert cb_data into a (const int *)
 . prepare_index(): declare return value to be (const char *)
 . delete_ref_loose(): don't muck around in the lock_file's filename
 . cache.h: define constants LOCK_SUFFIX and LOCK_SUFFIX_LEN
 . lockfile.c: document the various states of lock_file objects
 . lock_file(): always add lock_file object to lock_file_list
 . hold_lock_file_for_append(): release lock on errors
 . lockfile: unlock file if lockfile permissions cannot be adjusted
 . rollback_lock_file(): set fd to -1
 . rollback_lock_file(): do not clear filename redundantly
 . api-lockfile: expand the documentation
 . unable_to_lock_die(): rename function from unable_to_lock_index_die()

 Ejected from 'pu' to unclutter.
 Expecting a reroll.


* bg/rebase-off-of-previous-branch (2014-04-16) 1 commit
 - git-rebase: print name of rev when using shorthand

 Teach "git rebase -" to report the concrete name of the branch
 (i.e. the previous one).

 But it stops short and does not do the same for "git rebase @{-1}".
 Expecting a reroll.


* tr/merge-recursive-index-only (2014-02-05) 3 commits
 - merge-recursive: -Xindex-only to leave worktree unchanged
 - merge-recursive: internal flag to avoid touching the worktree
 - merge-recursive: remove dead conditional in update_stages()
 (this branch is used by tr/remerge-diff.)


* tr/remerge-diff (2014-02-26) 5 commits
 . log --remerge-diff: show what the conflict resolution changed
 . name-hash: allow dir hashing even when !ignore_case
 . merge-recursive: allow storing conflict hunks in index
 . revision: fold all merge diff variants into an enum merge_diff_mode
 . combine-diff: do not pass revs->dense_combined_merges redundantly
 (this branch uses tr/merge-recursive-index-only.)

 "log -p" output learns a new way to let users inspect a merge
 commit by showing the differences between the automerged result
 with conflicts the person who recorded the merge would have seen
 and the final conflict resolution that was recorded in the merge.

 Needs to be rebased, now kb/fast-hashmap topic is in.


* jk/makefile (2014-02-05) 16 commits
 . FIXUP
 . move LESS/LV pager environment to Makefile
 . Makefile: teach scripts to include make variables
 . FIXUP
 . Makefile: auto-build C strings from make variables
 . Makefile: drop *_SQ variables
 . FIXUP
 . Makefile: add c-quote helper function
 . Makefile: introduce sq function for shell-quoting
 . Makefile: always create files via make-var
 . Makefile: store GIT-* sentinel files in MAKE/
 . Makefile: prefer printf to echo for GIT-*
 . Makefile: use tempfile/mv strategy for GIT-*
 . Makefile: introduce make-var helper function
 . Makefile: fix git-instaweb dependency on gitweb
 . Makefile: drop USE_GETTEXT_SCHEME from GIT-CFLAGS

 Simplify the Makefile rules and macros that exist primarily for
 quoting purposes, and make it easier to robustly express the
 dependency rules.

 Expecting a reroll.


* po/everyday-doc (2014-01-27) 1 commit
 - Make 'git help everyday' work

 This may make the said command to emit something, but the source is
 not meant to be formatted into a manual pages to begin with, and
 also its contents are a bit stale.  It may be a good first step in
 the right direction, but needs more work to at least get the
 mark-up right before public consumption.

 Will hold.


* rb/merge-prepare-commit-msg-hook (2014-01-10) 4 commits
 - merge: drop unused arg from abort_commit method signature
 - merge: make prepare_to_commit responsible for write_merge_state
 - t7505: ensure cleanup after hook blocks merge
 - t7505: add missing &&

 Expose more merge states (e.g. $GIT_DIR/MERGE_MODE) to hooks that
 run during "git merge".  The log message stresses too much on one
 hook, prepare-commit-msg, but it would equally apply to other hooks
 like post-merge, I think.

 Waiting for a reroll.


* jc/graph-post-root-gap (2013-12-30) 3 commits
 - WIP: document what we want at the end
 - graph: remove unused code a bit
 - graph: stuff the current commit into graph->columns[]

 This was primarily a RFH ($gmane/239580).


* tg/perf-lib-test-perf-cleanup (2013-09-19) 2 commits
 - perf-lib: add test_perf_cleanup target
 - perf-lib: split starting the test from the execution

 Add test_perf_cleanup shell function to the perf suite, that allows
 the script writers to define a test with a clean-up action.

 Will hold.


* jc/show-branch (2014-03-24) 5 commits
 - show-branch: use commit slab to represent bitflags of arbitrary width
 - show-branch.c: remove "all_mask"
 - show-branch.c: abstract out "flags" operation
 - show-branch.c: lift all_mask/all_revs to a global static
 - show-branch.c: update comment style

 Waiting for the final step to lift the hard-limit before sending it out.


* jh/submodule-tests (2014-04-17) 1 commit
 - t7410: 210 tests for various 'git submodule update' scenarios

 More or less abandoned.  Will drop.

--------------------------------------------------
[Cooking]

* jk/rebase-am-fork-point (2014-07-16) 2 commits
  (merged to 'next' on 2014-07-22 at 7648293)
 + rebase: omit patch-identical commits with --fork-point
 + rebase--am: use --cherry-pick instead of --ignore-if-in-upstream

 "git rebase --fork-point" did not filter out patch-identical
 commits correctly.

 Will merge to 'master'.


* jk/stable-prio-queue (2014-07-15) 4 commits
  (merged to 'next' on 2014-07-22 at 46e9bc3)
 + t5539: update a flaky test
 + paint_down_to_common: use prio_queue
 + prio-queue: make output stable with respect to insertion
 + prio-queue: factor out compare and swap operations

 Will merge to 'master'.


* jk/tag-sort (2014-07-17) 2 commits
  (merged to 'next' on 2014-07-21 at bc34738)
 + tag: support configuring --sort via .gitconfig
 + tag: fix --sort tests to use cat<<-\EOF format

 Will merge to 'master'.


* ta/config-set (2014-07-21) 3 commits
 - test-config: add tests for the config_set API
 - add `config_set` API for caching config-like files
 + string-list: add string_list initializer helper function
 (this branch is tangled with ta/string-list-init.)

 Almost there.


* rs/ref-transaction-1 (2014-07-16) 20 commits
 - refs.c: make delete_ref use a transaction
 - refs.c: make prune_ref use a transaction to delete the ref
 - refs.c: remove lock_ref_sha1
 - refs.c: remove the update_ref_write function
 - refs.c: remove the update_ref_lock function
 - refs.c: make lock_ref_sha1 static
 - walker.c: use ref transaction for ref updates
 - fast-import.c: use a ref transaction when dumping tags
 - receive-pack.c: use a reference transaction for updating the refs
 - refs.c: change update_ref to use a transaction
 - branch.c: use ref transaction for all ref updates
 - fast-import.c: change update_branch to use ref transactions
 - sequencer.c: use ref transactions for all ref updates
 - commit.c: use ref transactions for updates
 - replace.c: use the ref transaction functions for updates
 - tag.c: use ref transactions when doing updates
 - refs.c: add transaction.status and track OPEN/CLOSED/ERROR
 - refs.c: make ref_transaction_begin take an err argument
 - refs.c: update ref_transaction_delete to check for error and return status
 - refs.c: change ref_transaction_create to do error checking and return status
 (this branch is used by rs/ref-transaction.)

 The second batch of the transactional ref update series.


* jc/reopen-lock-file (2014-07-14) 1 commit
  (merged to 'next' on 2014-07-21 at 8277dc9)
 + lockfile: allow reopening a closed but still locked file

 Needed in the "commit -p" code path to update the cache tree in the
 index.


* nd/multiple-work-trees (2014-07-17) 31 commits
  (merged to 'next' on 2014-07-17 at a29d310)
 + checkout: don't require a work tree when checking out into a new one
 + git_path(): keep "info/sparse-checkout" per work-tree
 + count-objects: report unused files in $GIT_DIR/repos/...
 + gc: support prune --repos
 + gc: factor out gc.pruneexpire parsing code
 + gc: style change -- no SP before closing parenthesis
 + prune: strategies for linked checkouts
 + checkout: detach if the branch is already checked out elsewhere
 + checkout: clean up half-prepared directories in --to mode
 + checkout: support checking out into a new working directory
 + use new wrapper write_file() for simple file writing
 + wrapper.c: wrapper to open a file, fprintf then close
 + setup.c: support multi-checkout repo setup
 + setup.c: detect $GIT_COMMON_DIR check_repository_format_gently()
 + setup.c: convert check_repository_format_gently to use strbuf
 + setup.c: detect $GIT_COMMON_DIR in is_git_directory()
 + setup.c: convert is_git_directory() to use strbuf
 + git-stash: avoid hardcoding $GIT_DIR/logs/....
 + *.sh: avoid hardcoding $GIT_DIR/hooks/...
 + git-sh-setup.sh: use rev-parse --git-path to get $GIT_DIR/objects
 + $GIT_COMMON_DIR: a new environment variable
 + commit: use SEQ_DIR instead of hardcoding "sequencer"
 + fast-import: use git_path() for accessing .git dir instead of get_git_dir()
 + reflog: avoid constructing .lock path with git_path
 + *.sh: respect $GIT_INDEX_FILE
 + git_path(): be aware of file relocation in $GIT_DIR
 + path.c: group git_path(), git_pathdup() and strbuf_git_path() together
 + path.c: rename vsnpath() to do_git_path()
 + git_snpath(): retire and replace with strbuf_git_path()
 + path.c: make get_pathname() call sites return const char *
 + path.c: make get_pathname() return strbuf instead of static buffer

 A replacement for contrib/workdir/git-new-workdir that does not
 rely on symbolic links and make sharing of objects and refs safer
 by making the borrowee and borrowers aware of each other.

 Will cook in 'next'.


* dt/cache-tree-repair (2014-07-14) 4 commits
  (merged to 'next' on 2014-07-21 at e83db34)
 + cache-tree: Write updated cache-tree after commit
 + cache-tree: subdirectory tests
 + test-dump-cache-tree: invalid trees are not errors
 + cache-tree: create/update cache-tree on checkout

 Add a few more places in "commit" and "checkout" that make sure
 that the cache-tree is fully populated in the index.

 Will cook in 'next'.


* cc/replace-graft (2014-07-21) 9 commits
  (merged to 'next' on 2014-07-22 at 9b14090)
 + replace: add test for --graft with a mergetag
 + replace: check mergetags when using --graft
 + replace: add test for --graft with signed commit
 + replace: remove signature when using --graft
 + contrib: add convert-grafts-to-replace-refs.sh
 + Documentation: replace: add --graft option
 + replace: add test for --graft
 + replace: add --graft option
 + replace: cleanup redirection style in tests

 "git replace" learned a "--graft" option to rewrite parents of a
 commit.

 Will merge to 'master'.


* hv/submodule-config (2014-06-30) 4 commits
  (merged to 'next' on 2014-07-17 at 5e0ce45)
 + do not die on error of parsing fetchrecursesubmodules option
 + use new config API for worktree configurations of submodules
 + extract functions for submodule config set and lookup
 + implement submodule config cache for lookup of submodule names

 Will cook in 'next'.


* rs/ref-transaction (2014-07-17) 12 commits
 - refs.c: fix handling of badly named refs
 - refs.c: make write_ref_sha1 static
 - fetch.c: change s_update_ref to use a ref transaction
 - refs.c: propagate any errno==ENOTDIR from _commit back to the callers
 - refs.c: pass a skip list to name_conflict_fn
 - refs.c: call lock_ref_sha1_basic directly from commit
 - refs.c: move the check for valid refname to lock_ref_sha1_basic
 - refs.c: pass NULL as *flags to read_ref_full
 - refs.c: pass the ref log message to _create/delete/update instead of _commit
 - refs.c: add an err argument to delete_ref_loose
 - wrapper.c: add a new function unlink_or_msg
 - wrapper.c: simplify warn_if_unremovable
 (this branch uses rs/ref-transaction-1.)


* jc/test-lazy-prereq (2014-06-13) 1 commit
 - tests: drop GIT_*_TIMING_TESTS environment variable support

 Test-script clean-up.

 Will hold.


* mt/patch-id-stable (2014-06-10) 1 commit
 - patch-id: change default to stable

 Teaches "git patch-id" to compute the patch ID that does not change
 when the files in a single patch is reordered. As this new algorithm
 is backward incompatible, the last bit to flip it to be the default
 is left out of 'master' for now.

 Will hold.

^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: What's cooking in git.git (Jul 2014, #04; Tue, 22)
  2014-07-22 21:44 What's cooking in git.git (Jul 2014, #04; Tue, 22) Junio C Hamano
@ 2014-07-23  6:56 ` Philip Oakley
  2014-07-23 18:10   ` Junio C Hamano
  2014-07-23 14:17 ` What's cooking in git.git (Jul 2014, #04; Tue, 22) Karsten Blees
  1 sibling, 1 reply; 19+ messages in thread
From: Philip Oakley @ 2014-07-23  6:56 UTC (permalink / raw)
  To: Junio C Hamano, git

From: "Junio C Hamano" <gitster@pobox.com>
> --------------------------------------------------
> [Stalled]
>
>
> * po/everyday-doc (2014-01-27) 1 commit
> - Make 'git help everyday' work
>
> This may make the said command to emit something, but the source is
> not meant to be formatted into a manual pages to begin with, and
> also its contents are a bit stale.

> It may be a good first step in
> the right direction, but needs more work to at least get the
> mark-up right before public consumption.
>
> Will hold.
>

It's not clear to me which bits of mark-up are 'wrong' and must be 
reworked,
and which markup styles are just unusal and could wait until better eyes 
can
review the detailed content.

At the moment I'm guessing as to what changes to do, and falling down 
various
Asciidoc rabbit holes. I'd judged my initial changes as 'adequate' 
rather than
'good' because of that issue.

Philip
-- 

^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: What's cooking in git.git (Jul 2014, #04; Tue, 22)
  2014-07-22 21:44 What's cooking in git.git (Jul 2014, #04; Tue, 22) Junio C Hamano
  2014-07-23  6:56 ` Philip Oakley
@ 2014-07-23 14:17 ` Karsten Blees
  2014-07-23 18:24   ` Junio C Hamano
  2014-07-25 12:30   ` Duy Nguyen
  1 sibling, 2 replies; 19+ messages in thread
From: Karsten Blees @ 2014-07-23 14:17 UTC (permalink / raw)
  To: Junio C Hamano, git

Am 22.07.2014 23:44, schrieb Junio C Hamano:
> 
> * sk/mingw-uni-fix-more (2014-07-21) 14 commits
>  - Win32: enable color output in Windows cmd.exe
>  - Win32: patch Windows environment on startup
>  - Win32: keep the environment sorted
>  - Win32: use low-level memory allocation during initialization
>  - Win32: reduce environment array reallocations
>  - Win32: don't copy the environment twice when spawning child processes
>  - Win32: factor out environment block creation
>  - Win32: unify environment function names
>  - Win32: unify environment case-sensitivity
>  - Win32: fix environment memory leaks
>  - Win32: Unicode environment (incoming)
>  - Win32: Unicode environment (outgoing)
>  - Revert "Windows: teach getenv to do a case-sensitive search"
>  - tests: do not pass iso8859-1 encoded parameter
> 
>  Most of these are battle-tested in msysgit and are needed to
>  complete what has been merged to 'master' already.
> 
>  A fix has been squashed into "Unicode environ (outgoing)"; is this
>  now ready to go?
> 
> 
> * sk/mingw-tests-workaround (2014-07-21) 6 commits
>  - t800[12]: work around MSys limitation
>  - t9902: mingw-specific fix for gitfile link files
>  - t4210: skip command-line encoding tests on mingw
>  - MinGW: disable legacy encoding tests
>  - t0110/MinGW: skip tests that pass arbitrary bytes on the command line
>  - MinGW: Skip test redirecting to fd 4
>  (this branch is used by jc/not-mingw-cygwin.)
> 
>  Make tests pass on msysgit by mostly disabling ones that are
>  infeasible on that platform.
> 
>  The t0110 one has been replaced; is this now ready to go?
> 

Yes, I think both series are ready.

Compiles with msysgit and MSVC (with NO_CURL=1).

With the version in pu, three tests fail. t7001 is fixed with a newer 'cp'.
The other two are unrelated (introduced by nd/multiple-work-trees topic).

* t1501-worktree: failed 1
  As of 5bbcb072 "setup.c: support multi-checkout repo setup"
  Using $TRASH_DIRECTORY doesn't work on Windows.
  
* t2026-prune-linked-checkouts: failed 1
  As of 404a45f1 "prune: strategies for linked checkouts"
  Dito.

* t7001-mv: failed 6
  'cp -P' doesn't work due to outdated cp.exe.

^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: What's cooking in git.git (Jul 2014, #04; Tue, 22)
  2014-07-23  6:56 ` Philip Oakley
@ 2014-07-23 18:10   ` Junio C Hamano
  2014-07-24 22:37     ` Philip Oakley
  0 siblings, 1 reply; 19+ messages in thread
From: Junio C Hamano @ 2014-07-23 18:10 UTC (permalink / raw)
  To: Philip Oakley; +Cc: git

"Philip Oakley" <philipoakley@iee.org> writes:

>> * po/everyday-doc (2014-01-27) 1 commit
>> - Make 'git help everyday' work
>>
>> This may make the said command to emit something, but the source is
>> not meant to be formatted into a manual pages to begin with, and
>> also its contents are a bit stale.
>
>> It may be a good first step in
>> the right direction, but needs more work to at least get the
>> mark-up right before public consumption.
>>
>> Will hold.
>>
>
> It's not clear to me which bits of mark-up are 'wrong' and must be
> reworked,

It's been too long since I wrote the above and I left it without
updates (these comments are by default carried over from one issue
to the next of "What's cooking" report, unless there is some
development on the topic).  Now I read the output (admittedly, I
skimmed only the HTML version), I think the formatting / mark-up is
fine.

I at the same time found various command sequences used there are
rather classical and there are better ways to do the same with
modern tools, which still makes me feel hesitant to promote this
document without updating its contents, though.

^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: What's cooking in git.git (Jul 2014, #04; Tue, 22)
  2014-07-23 14:17 ` What's cooking in git.git (Jul 2014, #04; Tue, 22) Karsten Blees
@ 2014-07-23 18:24   ` Junio C Hamano
  2014-07-25 12:30   ` Duy Nguyen
  1 sibling, 0 replies; 19+ messages in thread
From: Junio C Hamano @ 2014-07-23 18:24 UTC (permalink / raw)
  To: Karsten Blees; +Cc: git

Karsten Blees <karsten.blees@gmail.com> writes:

> Am 22.07.2014 23:44, schrieb Junio C Hamano:
>> 
>> * sk/mingw-uni-fix-more (2014-07-21) 14 commits
>> ...
>> * sk/mingw-tests-workaround (2014-07-21) 6 commits
>> ...
>
> Yes, I think both series are ready.
>
> Compiles with msysgit and MSVC (with NO_CURL=1).

Thanks.

> With the version in pu, three tests fail. t7001 is fixed with a newer 'cp'.

It seems that the only use of the "copy symlinks as-is" in that test
are to move trash/submodule/.git to trash/.git/modules/submodule;
as the longer-term direction is not to rely on symlinks in .git/
(and we have got rid of HEAD -> refs/heads/master long time ago),
perhaps we do not even want to have "-P" there?

> The other two are unrelated (introduced by nd/multiple-work-trees topic).
>
> * t1501-worktree: failed 1
>   As of 5bbcb072 "setup.c: support multi-checkout repo setup"
>   Using $TRASH_DIRECTORY doesn't work on Windows.
>   
> * t2026-prune-linked-checkouts: failed 1
>   As of 404a45f1 "prune: strategies for linked checkouts"
>   Dito.
>
> * t7001-mv: failed 6
>   'cp -P' doesn't work due to outdated cp.exe.

^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: What's cooking in git.git (Jul 2014, #04; Tue, 22)
  2014-07-23 18:10   ` Junio C Hamano
@ 2014-07-24 22:37     ` Philip Oakley
  2014-07-24 22:45       ` Junio C Hamano
  0 siblings, 1 reply; 19+ messages in thread
From: Philip Oakley @ 2014-07-24 22:37 UTC (permalink / raw)
  To: Junio C Hamano; +Cc: git

From: "Junio C Hamano" <gitster@pobox.com>
Sent: Wednesday, July 23, 2014 7:10 PM
> "Philip Oakley" <philipoakley@iee.org> writes:
>
>>> * po/everyday-doc (2014-01-27) 1 commit
>>> - Make 'git help everyday' work
>>>
>>> This may make the said command to emit something, but the source is
>>> not meant to be formatted into a manual pages to begin with, and
>>> also its contents are a bit stale.
>>
>>> It may be a good first step in
>>> the right direction, but needs more work to at least get the
>>> mark-up right before public consumption.
>>>
>>> Will hold.
>>>
>>
>> It's not clear to me which bits of mark-up are 'wrong' and must be
>> reworked,
>
> It's been too long since I wrote the above and I left it without
> updates (these comments are by default carried over from one issue
> to the next of "What's cooking" report, unless there is some
> development on the topic).  Now I read the output (admittedly, I
> skimmed only the HTML version), I think the formatting / mark-up is
> fine.

Thanks for the clarification - I hadn't been sure which way to go on the 
formatting aspect.
>
> I at the same time found various command sequences used there are
> rather classical and there are better ways to do the same with
> modern tools,

I can have a look at the 'standalone' and 'participant' developer 
command lists but would shy away from any claims about the 'integrator' 
and 'administrator' roles ;-)

> which still makes me feel hesitant to promote this
> document without updating its contents, though.
>

I hadn't viewed it as a 'promotion', rather it was simply ensuring 
access to the guide via the help system, instead of leaving it somewhat 
hidden.

--
Philip 

^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: What's cooking in git.git (Jul 2014, #04; Tue, 22)
  2014-07-24 22:37     ` Philip Oakley
@ 2014-07-24 22:45       ` Junio C Hamano
  2014-07-25 22:08         ` Junio C Hamano
  0 siblings, 1 reply; 19+ messages in thread
From: Junio C Hamano @ 2014-07-24 22:45 UTC (permalink / raw)
  To: Philip Oakley; +Cc: git

"Philip Oakley" <philipoakley@iee.org> writes:

>> which still makes me feel hesitant to promote this
>> document without updating its contents, though.
>>
>
> I hadn't viewed it as a 'promotion', rather it was simply ensuring
> access to the guide via the help system, instead of leaving it
> somewhat hidden.

Stale or incorrect pieces of advice that are hidden will not harm
(non-)readers.  Making them more available would mean giving them
more chances to do harm ;-).

^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: What's cooking in git.git (Jul 2014, #04; Tue, 22)
  2014-07-23 14:17 ` What's cooking in git.git (Jul 2014, #04; Tue, 22) Karsten Blees
  2014-07-23 18:24   ` Junio C Hamano
@ 2014-07-25 12:30   ` Duy Nguyen
  2014-07-29 19:43     ` [RFC/PATCH] Windows tests: let $TRASH_DIRECTORY point to native Windows path Karsten Blees
  1 sibling, 1 reply; 19+ messages in thread
From: Duy Nguyen @ 2014-07-25 12:30 UTC (permalink / raw)
  To: Karsten Blees; +Cc: Junio C Hamano, Git Mailing List

On Wed, Jul 23, 2014 at 9:17 PM, Karsten Blees <karsten.blees@gmail.com> wrote:
> With the version in pu, three tests fail. t7001 is fixed with a newer 'cp'.
> The other two are unrelated (introduced by nd/multiple-work-trees topic).
>
> * t1501-worktree: failed 1
>   As of 5bbcb072 "setup.c: support multi-checkout repo setup"
>   Using $TRASH_DIRECTORY doesn't work on Windows.
>
> * t2026-prune-linked-checkouts: failed 1
>   As of 404a45f1 "prune: strategies for linked checkouts"
>   Dito.

I need your help here. Would saving $(pwd) to a variable and using it
instead of $TRASH_DIRECTORY work? Some tests "cd" around and $(pwd)
may not be the same as $TRASH_DIRECTORY.
-- 
Duy

^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: What's cooking in git.git (Jul 2014, #04; Tue, 22)
  2014-07-24 22:45       ` Junio C Hamano
@ 2014-07-25 22:08         ` Junio C Hamano
  2014-07-28 22:12           ` Philip Oakley
                             ` (2 more replies)
  0 siblings, 3 replies; 19+ messages in thread
From: Junio C Hamano @ 2014-07-25 22:08 UTC (permalink / raw)
  To: Philip Oakley; +Cc: git

Junio C Hamano <gitster@pobox.com> writes:

> "Philip Oakley" <philipoakley@iee.org> writes:
>
>>> which still makes me feel hesitant to promote this
>>> document without updating its contents, though.
>>>
>>
>> I hadn't viewed it as a 'promotion', rather it was simply ensuring
>> access to the guide via the help system, instead of leaving it
>> somewhat hidden.
>
> Stale or incorrect pieces of advice that are hidden will not harm
> (non-)readers.  Making them more available would mean giving them
> more chances to do harm ;-).

Let's disect it.  I do not have time/concentration to finish all in
one message, so I'll do the first two.

| Everyday Git With 20 Commands Or So
| ===================================
| 
| <<Individual Developer (Standalone)>> commands are essential for
| anybody who makes a commit, even for somebody who works alone.
| 
| If you work with other people, you will need commands listed in
| the <<Individual Developer (Participant)>> section as well.
| 
| People who play the <<Integrator>> role need to learn some more
| commands in addition to the above.
| 
| <<Repository Administration>> commands are for system
| administrators who are responsible for the care and feeding
| of Git repositories.

Let's assume the categorization above is sensible for now.

| Individual Developer (Standalone)[[Individual Developer (Standalone)]]
| ----------------------------------------------------------------------
| 
| A standalone individual developer does not exchange patches with
| other people, and works alone in a single repository, using the
| following commands.
| ...

Everything in the enumeration looks OK except for this one,

|   * linkgit:git-show-branch[1] to see where you are.

which is probably no longer the case, for two reasons.  In the
original design of Git UI, you see many things that encourage you to
view and think about the whole collection of your branches as a whole.
"git show-branch" whose default is to show all of your branches is
just one of them (other examples include "git push" whose default
used to be "matching", expecting that you will work on completing
all the branches before you push the result out for all of them).

Over time, Git UI mutated into put a lot more focus and stress on
the current branch, disregarding what are on the branches you are
not corrently on.  "git log @{u}.." to see how much more you have
done on top of others' work would be more in line with such an
attitude.

I'd suggest dropping this command from this enumeration.

| Examples
| ~~~~~~~~
| 
| Use a tarball as a starting point for a new repository.::
| ...

Perfectly fine.

| Create a topic branch and develop.::
| +
| ------------
| $ git checkout -b alsa-audio <1>
| $ edit/compile/test
| $ git checkout -- curses/ux_audio_oss.c <2>
| $ git add curses/ux_audio_alsa.c <3>
| $ edit/compile/test
| $ git diff HEAD <4>
| $ git commit -a -s <5>

Perefectly fine up to this point.

| $ edit/compile/test
| $ git reset --soft HEAD^ <6>
| $ edit/compile/test
| $ git diff ORIG_HEAD <7>
| $ git commit -a -c ORIG_HEAD <8>

This shows how a typical sequence "I try to further tweak what I
committed" looked like.  With the modern Git, you would do

    $ edit/compile/test
    $ git diff HEAD^ <7>
    $ git commit -a --amend

without the soft reset, which was invented solely because there
wasn't "commit --amend" available.

The example is perfectly fine after this step, but <6> and <8> need
to be dropped and others renumbered.

| Individual Developer (Participant)[[Individual Developer (Participant)]]
| ------------------------------------------------------------------------
| ...
|   * linkgit:git-format-patch[1] to prepare e-mail submission, if
|     you adopt Linux kernel-style public forum workflow.

Probably git-send-email needs to be appended to the end of the
enumeration.

| Examples
| ~~~~~~~~
| 
| Clone the upstream and work on it.  Feed changes to upstream.::
| +
| ------------
| $ git clone git://git.kernel.org/pub/scm/.../torvalds/linux-2.6 my2.6
| $ cd my2.6
| $ edit/compile/test; git commit -a -s <1>
| $ git format-patch origin <2>
| $ git pull <3>
| $ git log -p ORIG_HEAD.. arch/i386 include/asm-i386 <4>
| $ git pull git://git.kernel.org/pub/.../jgarzik/libata-dev.git ALL <5>
| $ git reset --hard ORIG_HEAD <6>
| $ git gc <7>
| $ git fetch --tags <8>
| ------------
| +
| <1> repeat as needed.
| <2> extract patches from your branch for e-mail submission.
| <3> `git pull` fetches from `origin` by default and merges into the
| current branch.
| <4> immediately after pulling, look at the changes done upstream
| since last time we checked, only in the
| area we are interested in.
| <5> fetch from a specific branch from a specific repository and merge.
| <6> revert the pull.
| <7> garbage collect leftover objects from reverted pull.
| <8> from time to time, obtain official tags from the `origin`
| and store them under `.git/refs/tags/`.

This example works directly on 'master', which is not ideal.  If I
were writing this today, I would have made it work on 'mine' branch,
produced a patch series out of that branch relative to @{u}, threw
in 'git send-email' invocation, and had "git pull" update the
pristine 'mater' branch after "git checkout master".  Merging of
work by jgarzik (i.e. not your upstream) would also have gone to its
own branch, not to 'master'.

| Push into another repository.::
| +
| ------------
| satellite$ git clone mothership:frotz frotz <1>
| satellite$ cd frotz
| satellite$ git config --get-regexp '^(remote|branch)\.' <2>
| remote.origin.url mothership:frotz
| remote.origin.fetch refs/heads/*:refs/remotes/origin/*
| branch.master.remote origin
| branch.master.merge refs/heads/master

Perfectly fine up to this opint.

| satellite$ git config remote.origin.push \
|            master:refs/remotes/satellite/master <3>

Somewhat iffy; "+refs/heads/*:refs/remotes/satellite/*" would have
been better.  Need to adjust the explanation below.

| satellite$ edit/compile/test/commit
| satellite$ git push origin <4>

Fine, except that the explanation below needs adjustment.

| <3> arrange `git push` to push local `master` branch to
| `remotes/satellite/master` branch of the mothership machine.
| <4> push will stash our work away on `remotes/satellite/master`
| remote-tracking branch on the mothership machine.  You could use this
| as a back-up method.

With wildcarding, we would be backing up all our local branches, not
just master.

| Branch off of a specific tag.::
| +
| ------------
| $ git checkout -b private2.6.14 v2.6.14 <1>
| $ edit/compile/test; git commit -a
| $ git checkout master
| $ git format-patch -k -m --stdout v2.6.14..private2.6.14 |
|   git am -3 -k <2>
| ------------
| +
| <1> create a private branch based on a well known (but somewhat behind)
| tag.
| <2> forward port all changes in `private2.6.14` branch to `master` branch
| without a formal "merging".

The last one is fine, but "cherry-pick v2.6.14..private2.6.14" would
be more common with today's Git.

^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: What's cooking in git.git (Jul 2014, #04; Tue, 22)
  2014-07-25 22:08         ` Junio C Hamano
@ 2014-07-28 22:12           ` Philip Oakley
  2014-07-30 17:13           ` Everyday contents (was Re: What's cooking in git.git (Jul 2014, #04; Tue, 22)) Junio C Hamano
  2014-08-02 17:28           ` Everday contents (was part of " Philip Oakley
  2 siblings, 0 replies; 19+ messages in thread
From: Philip Oakley @ 2014-07-28 22:12 UTC (permalink / raw)
  To: Junio C Hamano; +Cc: git

From: "Junio C Hamano" <gitster@pobox.com>
Sent: Friday, July 25, 2014 11:08 PM
>> * po/everyday-doc (2014-01-27) 1 commit
>> - Make 'git help everyday' work

> Let's disect it.  I do not have time/concentration to finish all in
> one message, so I'll do the first two.
>
<snip>

Thanks for the guidance. I'll work on updating the patch in line with 
your comments and see how far I get.

--
Philip 

^ permalink raw reply	[flat|nested] 19+ messages in thread

* [RFC/PATCH] Windows tests: let $TRASH_DIRECTORY point to native Windows path
  2014-07-25 12:30   ` Duy Nguyen
@ 2014-07-29 19:43     ` Karsten Blees
  2014-08-27 13:08       ` Duy Nguyen
  0 siblings, 1 reply; 19+ messages in thread
From: Karsten Blees @ 2014-07-29 19:43 UTC (permalink / raw)
  To: Duy Nguyen; +Cc: Junio C Hamano, Git Mailing List, msysGit

MSYS programs typically understand native Windows paths (e.g C:/git), but
native Windows programs (including MinGW) don't understand MSYS paths (e.g.
/c/git).

On Windows, set TRASH_DIRECTORY to the absolute native path so that it can
be used more easily in tests.

MSYS 'tar -f' interprets everything before ':' as hostname, not as drive
letter. Change respective tests to use stdin / stdout instead of '-f'. Also
use $TAR from GIT-BUILD-OPTIONS rather than hardcoded tar.

Signed-off-by: Karsten Blees <blees@dcon.de>
---

Am 25.07.2014 14:30, schrieb Duy Nguyen:
> On Wed, Jul 23, 2014 at 9:17 PM, Karsten Blees <karsten.blees@gmail.com> wrote:
>> With the version in pu, three tests fail. t7001 is fixed with a newer 'cp'.
>> The other two are unrelated (introduced by nd/multiple-work-trees topic).
>>
>> * t1501-worktree: failed 1
>>   As of 5bbcb072 "setup.c: support multi-checkout repo setup"
>>   Using $TRASH_DIRECTORY doesn't work on Windows.
>>
>> * t2026-prune-linked-checkouts: failed 1
>>   As of 404a45f1 "prune: strategies for linked checkouts"
>>   Dito.
> 
> I need your help here. Would saving $(pwd) to a variable and using it
> instead of $TRASH_DIRECTORY work? Some tests "cd" around and $(pwd)
> may not be the same as $TRASH_DIRECTORY.
> 

Yes, that would work.

(Actually, you'd only need to change 'echo "$TRASH_DIR..."' in two places (both
before cd'ing away). The other instances are parameters to non-msys programs and
are thus automatically mangled by msys.dll.)

However, I wonder why we don't set up TRASH_DIRECTORY to the native Windows path.
I believe we'd get much fewer 'special' cases that way. Ideally, you shouldn't
have to worry about the intricacies of MSYS path mangling when writing tests...

[CCing msysgit for opinions]


 t/t3513-revert-submodule.sh | 4 ++--
 t/t6041-bisect-submodule.sh | 4 ++--
 t/test-lib.sh               | 1 +
 3 files changed, 5 insertions(+), 4 deletions(-)

diff --git a/t/t3513-revert-submodule.sh b/t/t3513-revert-submodule.sh
index a1c4e02..4a44dd6 100755
--- a/t/t3513-revert-submodule.sh
+++ b/t/t3513-revert-submodule.sh
@@ -14,11 +14,11 @@ test_description='revert can handle submodules'
 git_revert () {
 	git status -su >expect &&
 	ls -1pR * >>expect &&
-	tar czf "$TRASH_DIRECTORY/tmp.tgz" * &&
+	"$TAR" cz * >"$TRASH_DIRECTORY/tmp.tgz" &&
 	git checkout "$1" &&
 	git revert HEAD &&
 	rm -rf * &&
-	tar xzf "$TRASH_DIRECTORY/tmp.tgz" &&
+	"$TAR" xz <"$TRASH_DIRECTORY/tmp.tgz" &&
 	git status -su >actual &&
 	ls -1pR * >>actual &&
 	test_cmp expect actual &&
diff --git a/t/t6041-bisect-submodule.sh b/t/t6041-bisect-submodule.sh
index c6b7aa6..0de614f 100755
--- a/t/t6041-bisect-submodule.sh
+++ b/t/t6041-bisect-submodule.sh
@@ -8,7 +8,7 @@ test_description='bisect can handle submodules'
 git_bisect () {
 	git status -su >expect &&
 	ls -1pR * >>expect &&
-	tar czf "$TRASH_DIRECTORY/tmp.tgz" * &&
+	"$TAR" cz * > "$TRASH_DIRECTORY/tmp.tgz" &&
 	GOOD=$(git rev-parse --verify HEAD) &&
 	git checkout "$1" &&
 	echo "foo" >bar &&
@@ -20,7 +20,7 @@ git_bisect () {
 	git bisect start &&
 	git bisect good $GOOD &&
 	rm -rf * &&
-	tar xzf "$TRASH_DIRECTORY/tmp.tgz" &&
+	"$TAR" xz <"$TRASH_DIRECTORY/tmp.tgz" &&
 	git status -su >actual &&
 	ls -1pR * >>actual &&
 	test_cmp expect actual &&
diff --git a/t/test-lib.sh b/t/test-lib.sh
index 5102340..5f6397b 100644
--- a/t/test-lib.sh
+++ b/t/test-lib.sh
@@ -868,6 +868,7 @@ case $(uname -s) in
 		md5sum "$@"
 	}
 	# git sees Windows-style pwd
+	TRASH_DIRECTORY=$(pwd -W)
 	pwd () {
 		builtin pwd -W
 	}
-- 
2.0.2.897.g7f80809.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

--- 
You received this message because you are subscribed to the Google Groups "msysGit" group.
To unsubscribe from this group and stop receiving emails from it, send an email to msysgit+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

^ permalink raw reply related	[flat|nested] 19+ messages in thread

* Everyday contents (was Re: What's cooking in git.git (Jul 2014, #04; Tue, 22))
  2014-07-25 22:08         ` Junio C Hamano
  2014-07-28 22:12           ` Philip Oakley
@ 2014-07-30 17:13           ` Junio C Hamano
  2014-08-05 20:26             ` Junio C Hamano
  2014-08-02 17:28           ` Everday contents (was part of " Philip Oakley
  2 siblings, 1 reply; 19+ messages in thread
From: Junio C Hamano @ 2014-07-30 17:13 UTC (permalink / raw)
  To: Philip Oakley; +Cc: git

Continued: this message only covers the third part (out of the four sections).

| Integrator[[Integrator]]
| ------------------------
| 
| A fairly central person acting as the integrator in a group
| project receives changes made by others, reviews and integrates
| them and publishes the result for others to use, using these
| commands in addition to the ones needed by participants.

This definition of who an "integrator" is, and it being a separate
role when we discuss various workflows, are still sound, I think.

|   * linkgit:git-pull[1] to merge from your trusted lieutenants.

Among these enumerated items, we may want to reword this a little
bit to hint that this section also applies to GitHub pull-request
workflow.  However, I am not sure how their "merge without first
locally checking" action on their website fits in the picture.

| Examples
| ~~~~~~~~
| 
| My typical Git day.::

This probably shouldn't talk about "My" in the first place, but in
any case I work somewhat differently (cf. howto/maintain-git.txt)
these days.

| +
| ------------
| $ git status <1>
| $ git show-branch <2>

This is more like "git branch --no-merged master" (and similarly for
'next' and 'pu'), and is helped by "Meta/cook -w" but this document
is a wrong place to talk about the latter.

| $ mailx <3>
| & s 2 3 4 5 ./+to-apply
| & s 7 8 ./+hold-linus
| & q
| $ git checkout -b topic/one master
| $ git am -3 -i -s -u ./+to-apply <4>

No need to give -u these days.

| $ compile/test
| $ git checkout -b hold/linus && git am -3 -i -s -u ./+hold-linus <5>

Again, no "-u" necessary.

| $ git checkout topic/one && git rebase master <6>
| $ git checkout pu && git reset --hard next <7>
| $ git merge topic/one topic/two && git merge hold/linus <8>
| $ git checkout maint
| $ git cherry-pick master~4 <9>
| $ compile/test
| $ git tag -s -m "GIT 0.99.9x" v0.99.9x <10>
| $ git fetch ko && git show-branch master maint 'tags/ko-*' <11>

This step I still use show-branch, but like this:

    for branch in master maint next pu
    do
        git show-branch ko/$branch $branch
    done

and the purpose explained in the footnote is still valid.

| $ git push ko <12>
| $ git push ko v0.99.9x <13>

I no longer have to do the last step <13>, instead the step <12>
reads more like

	git push --follow-tags ko

| ------------
| +
| <1> see what I was in the middle of doing, if any.
| <2> see what topic branches I have and think about how ready
| they are.

With "show-branch" replaced with "branch --no-merged", the purpose
of this step is still the same.

| <3> read mails, save ones that are applicable, and save others
| that are not quite ready.
| <4> apply them, interactively, with my sign-offs.
| <5> create topic branch as needed and apply, again with my
| sign-offs.
| <6> rebase internal topic branch that has not been merged to the
| master or exposed as a part of a stable branch.
| <7> restart `pu` every time from the next.
| <8> and bundle topic branches still cooking.
| <9> backport a critical fix.
| <10> create a signed tag.
| <11> make sure I did not accidentally rewind master beyond what I
| already pushed out.  `ko` shorthand points at the repository I have
| at kernel.org, and looks like this:

No longer it looks like that ;-)

| +
| ------------
| $ cat .git/remotes/ko
| URL: kernel.org:/pub/scm/git/git.git
| Pull: master:refs/tags/ko-master
| Pull: next:refs/tags/ko-next
| Pull: maint:refs/tags/ko-maint
| Push: master
| Push: next
| Push: +pu
| Push: maint
| ------------
| +

... because we encourage people to use in-config description of
remotes these days, which should look like this:

	(in .git/config)
	[remote "ko"]
        	url = kernel.org:/pub/scm/git/git.git
                fetch = refs/heads/*:refs/remotes/ko/*
                push = refs/heads/master
                push = refs/heads/next
                push = +refs/heads/pu
                push = refs/heads/maint

Also tracking is done via refs/remotes/ko/, no longer with tags/.

| In the output from `git show-branch`, `master` should have
| everything `ko-master` has, and `next` should have
| everything `ko-next` has.

With s|ko-master|ko/master| and s|ko-next|ko/next|, the above is
still valid.

| <12> push out the bleeding edge.

s/edge./edge, together with new tags that point into my history./

| <13> push the tag out, too.

Drop this.

^ permalink raw reply	[flat|nested] 19+ messages in thread

* Everday contents (was part of Re: What's cooking in git.git (Jul 2014, #04; Tue, 22))
  2014-07-25 22:08         ` Junio C Hamano
  2014-07-28 22:12           ` Philip Oakley
  2014-07-30 17:13           ` Everyday contents (was Re: What's cooking in git.git (Jul 2014, #04; Tue, 22)) Junio C Hamano
@ 2014-08-02 17:28           ` Philip Oakley
  2014-08-03 17:29             ` Everday contents Junio C Hamano
  2 siblings, 1 reply; 19+ messages in thread
From: Philip Oakley @ 2014-08-02 17:28 UTC (permalink / raw)
  To: Junio C Hamano; +Cc: git

From: "Junio C Hamano" <gitster@pobox.com>
Sent: Friday, July 25, 2014 11:08 PM
...
>
> | Individual Developer (Participant)[[Individual Developer 
> (Participant)]]
> | ------------------------------------------------------------------------

...
> | $ git pull git://git.kernel.org/pub/.../jgarzik/libata-dev.git ALL 
> <5>

Would I be right that "ALL" can simply be dropped as something from 
'back then' (13 Dec 2005 v0.99.9-516-g44db136) that I'm ignorant of?

...
> | <5> fetch from a specific branch from a specific repository and 
> merge.
> | <6> revert the pull.
> | <7> garbage collect leftover objects from reverted pull.
> | <8> from time to time, obtain official tags from the `origin`
> | and store them under `.git/refs/tags/`.
>
> This example works directly on 'master', which is not ideal.  If I
> were writing this today, I would have made it work on 'mine' branch,
> produced a patch series out of that branch relative to @{u}, threw
> in 'git send-email' invocation, and had "git pull" update the
> pristine 'mater' branch after "git checkout master".  Merging of
> work by jgarzik (i.e. not your upstream) would also have gone to its
> own branch, not to 'master'.
>
Slowly working through it ;-)

Ta.

Philip 

^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: Everday contents
  2014-08-02 17:28           ` Everday contents (was part of " Philip Oakley
@ 2014-08-03 17:29             ` Junio C Hamano
  2014-08-03 18:41               ` Philip Oakley
  0 siblings, 1 reply; 19+ messages in thread
From: Junio C Hamano @ 2014-08-03 17:29 UTC (permalink / raw)
  To: Philip Oakley; +Cc: git

"Philip Oakley" <philipoakley@iee.org> writes:

> From: "Junio C Hamano" <gitster@pobox.com>
> Sent: Friday, July 25, 2014 11:08 PM
> ...
>>
>> | Individual Developer (Participant)[[Individual Developer
>> (Participant)]]
>> | ------------------------------------------------------------------------
>
> ...
>> | $ git pull git://git.kernel.org/pub/.../jgarzik/libata-dev.git ALL
>> <5>
>
> Would I be right that "ALL" can simply be dropped as something from
> back then' (13 Dec 2005 v0.99.9-516-g44db136) that I'm ignorant of?

The answer depends on the reason why you want to drop it from the
example.

That "ALL" is merely a branch name, like "master", etc.  I do not
know how jgarzik names his published branches these days, but back
then ALL there was something that contained all the topics he wanted
others to look at.  And the description of <5> explains it to be
fetching a "specific branch", so that needs to be reworded if we are
to change the example to "from the default branch of a specific
repository" or something.

> ...
>> | <5> fetch from a specific branch from a specific repository and
>> merge.

Thanks.

^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: Everday contents
  2014-08-03 17:29             ` Everday contents Junio C Hamano
@ 2014-08-03 18:41               ` Philip Oakley
  2014-08-04 17:00                 ` Junio C Hamano
  0 siblings, 1 reply; 19+ messages in thread
From: Philip Oakley @ 2014-08-03 18:41 UTC (permalink / raw)
  To: Junio C Hamano; +Cc: git

From: "Junio C Hamano" <gitster@pobox.com>
> "Philip Oakley" <philipoakley@iee.org> writes:
>
>> From: "Junio C Hamano" <gitster@pobox.com>
>> Sent: Friday, July 25, 2014 11:08 PM
>> ...
>>>
>>> | Individual Developer (Participant)[[Individual Developer
>>> (Participant)]]
>>> | ------------------------------------------------------------------------
>>
>> ...
>>> | $ git pull git://git.kernel.org/pub/.../jgarzik/libata-dev.git ALL
>>> <5>
>>
>> Would I be right that "ALL" can simply be dropped as something from
>> back then' (13 Dec 2005 v0.99.9-516-g44db136) that I'm ignorant of?
>
> The answer depends on the reason why you want to drop it from the
> example.
>
> That "ALL" is merely a branch name, like "master", etc.

That was the bit I was missing. I had it in my head that it was possibly 
some historic option as it was in caps.

>  I do not
> know how jgarzik names his published branches these days, but back
> then ALL there was something that contained all the topics he wanted
> others to look at.  And the description of <5> explains it to be
> fetching a "specific branch", so that needs to be reworded if we are

I eventually went with using a lower case 'dev' as a nominal branch 
name, and also named it in the updated <5>. However I hadn't actually 
checked if the repos is still active.

> to change the example to "from the default branch of a specific
> repository" or something.
>
>> ...
>>> | <5> fetch from a specific branch from a specific repository and
>>> merge.
>

Thanks.

Philip 

^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: Everday contents
  2014-08-03 18:41               ` Philip Oakley
@ 2014-08-04 17:00                 ` Junio C Hamano
  0 siblings, 0 replies; 19+ messages in thread
From: Junio C Hamano @ 2014-08-04 17:00 UTC (permalink / raw)
  To: Philip Oakley; +Cc: git

"Philip Oakley" <philipoakley@iee.org> writes:

> From: "Junio C Hamano" <gitster@pobox.com>
>> "Philip Oakley" <philipoakley@iee.org> writes:
>>
>>> From: "Junio C Hamano" <gitster@pobox.com>
>>> Sent: Friday, July 25, 2014 11:08 PM
>>> ...
>>>>
>>>> | Individual Developer (Participant)[[Individual Developer
>>>> (Participant)]]
>>>> | ------------------------------------------------------------------------
>>>
>>> ...
>>>> | $ git pull git://git.kernel.org/pub/.../jgarzik/libata-dev.git ALL
>>>> <5>
>>>
>>> Would I be right that "ALL" can simply be dropped as something from
>>> back then' (13 Dec 2005 v0.99.9-516-g44db136) that I'm ignorant of?
>>
>> The answer depends on the reason why you want to drop it from the
>> example.
>>
>> That "ALL" is merely a branch name, like "master", etc.
>
> That was the bit I was missing. I had it in my head that it was
> possibly some historic option as it was in caps.

Yeah, I suspected as much ;-)  Thanks for a careful reading.

^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: Everyday contents (was Re: What's cooking in git.git (Jul 2014, #04; Tue, 22))
  2014-07-30 17:13           ` Everyday contents (was Re: What's cooking in git.git (Jul 2014, #04; Tue, 22)) Junio C Hamano
@ 2014-08-05 20:26             ` Junio C Hamano
  2014-08-05 21:00               ` Philip Oakley
  0 siblings, 1 reply; 19+ messages in thread
From: Junio C Hamano @ 2014-08-05 20:26 UTC (permalink / raw)
  To: Philip Oakley; +Cc: git

Continued: this message covers the last part.

| Repository Administration[[Repository Administration]]
| ------------------------------------------------------
| 
| A repository administrator uses the following tools to set up
| and maintain access to the repository by developers.
| 
|   * linkgit:git-daemon[1] to allow anonymous download from
|     repository.
| 
|   * linkgit:git-shell[1] can be used as a 'restricted login shell'
|     for shared central repository users.
| 
| link:howto/update-hook-example.html[update hook howto] has a good
| example of managing a shared central repository.

This part is fairly stale.  We only talk about allowing anonymous
fetching via git-daemon and pushing via git-over-ssh.  The readers
would want to be aware that they can set up their hosts for fetching
and pushing via git-over-http aka "Smart http", and browsing via
gitweb.  We should definitely at least mention these, and we may
even want to describe them at the same level of detail as the
existing examples.

I wonder if we also want to mention (but not describe, just make the
readers aware of) widely deployed hosting/browsing solutions such as
gitolite, gerrit code review, and cgit.

Do tasks that are described here have impact on the use of these
third-party tools?  For example, I understand gitolite does not
require one UNIX user per biological human user, but the vanilla
push-over-ssh described in these examples does.  I guess the burden
of telling the users to "unlearn everything you read about setting
up the vanilla git-over-ssh when you use gitolite" falls on gitolite
doc, so in that sense we shouldn't have to worry about doing any of
that here.

| Examples
| ~~~~~~~~
| We assume the following in /etc/services::
| +
| ------------
| $ grep 9418 /etc/services
| git		9418/tcp		# Git Version Control System
| ------------

OK.

| Run git-daemon to serve /pub/scm from inetd.::
| +
| ------------
| $ grep git /etc/inetd.conf
| git	stream	tcp	nowait	nobody \
|   /usr/bin/git-daemon git-daemon --inetd --export-all /pub/scm
| ------------
| +
| The actual configuration line should be on one line.

OK.

| Run git-daemon to serve /pub/scm from xinetd.::
| +
| ------------
| $ cat /etc/xinetd.d/git-daemon
| # default: off
| # description: The Git server offers access to Git repositories
| service git
| {
|         disable = no
|         type            = UNLISTED
|         port            = 9418
|         socket_type     = stream
|         wait            = no
|         user            = nobody
|         server          = /usr/bin/git-daemon
|         server_args     = --inetd --export-all --base-path=/pub/scm
|         log_on_failure  += USERID
| }
| ------------
| +
| Check your xinetd(8) documentation and setup, this is from a Fedora system.
| Others might be different.

OK, but which vintage of Fedora? ;-)

| Give push/pull only access to developers.::

This entry may mislead the readers if the "access" this section
talks about is to the git-daemon we just set up in the above.  We
should clarify that this is about git-over-ssh access, i.e. the
users will be doing this:

	$ git push/pull host.xz:/pub/scm/project

or

	$ git push/pull ssh://host.xz/pub/scm/project

or somesuch.

| +
| ------------
| $ grep git /etc/passwd <1>
| alice:x:1000:1000::/home/alice:/usr/bin/git-shell
| bob:x:1001:1001::/home/bob:/usr/bin/git-shell
| cindy:x:1002:1002::/home/cindy:/usr/bin/git-shell
| david:x:1003:1003::/home/david:/usr/bin/git-shell
| $ grep git /etc/shells <2>
| /usr/bin/git-shell
| ------------
| +
| <1> log-in shell is set to /usr/bin/git-shell, which does not
| allow anything but `git push` and `git pull`.  The users should
| get an ssh access to the machine.
| <2> in many distributions /etc/shells needs to list what is used
| as the login shell.

One possible mis-interpretation of <1> is "Thanks to these git-shell
entries, the users will get `push/pull` accesses to the box; they
separately need ssh access to the box (to do something more than
that, if desired)".

In reality, this configuration _requires_ them to have an ssh access
to the box and these entries restricts them to only run push/pull
against the host.  We may want to rephrase to clarify.

| CVS-style shared repository.::
| +
| ------------
| $ grep git /etc/group <1>
| git:x:9418:alice,bob,cindy,david
| $ cd /home/devo.git
| $ ls -l <2>
|   lrwxrwxrwx   1 david git    17 Dec  4 22:40 HEAD -> refs/heads/master
|   drwxrwsr-x   2 david git  4096 Dec  4 22:40 branches
|   -rw-rw-r--   1 david git    84 Dec  4 22:40 config
|   -rw-rw-r--   1 david git    58 Dec  4 22:40 description
|   drwxrwsr-x   2 david git  4096 Dec  4 22:40 hooks
|   -rw-rw-r--   1 david git 37504 Dec  4 22:40 index
|   drwxrwsr-x   2 david git  4096 Dec  4 22:40 info
|   drwxrwsr-x   4 david git  4096 Dec  4 22:40 objects
|   drwxrwsr-x   4 david git  4096 Nov  7 14:58 refs
|   drwxrwsr-x   2 david git  4096 Dec  4 22:40 remotes
| $ ls -l hooks/update <3>
|   -r-xr-xr-x   1 david git  3536 Dec  4 22:40 update
| $ cat info/allowed-users <4>
| refs/heads/master	alice\|cindy
| refs/heads/doc-update	bob
| refs/tags/v[0-9]*	david
| ------------
| +
| <1> place the developers into the same git group.
| <2> and make the shared repository writable by the group.
| <3> use update-hook example by Carl from Documentation/howto/
| for branch policy control.
| <4> alice and cindy can push into master, only bob can push into doc-update.
| david is the release manager and is the only person who can
| create and push version tags.

OK.

| HTTP server to support dumb protocol transfer.::
| +
| ------------
| dev$ git update-server-info <1>
| dev$ ftp user@isp.example.com <2>
| ftp> cp -r .git /home/user/myproject.git
| ------------
| +
| <1> make sure your info/refs and objects/info/packs are up-to-date
| <2> upload to public HTTP server hosted by your ISP.

This may want to be removed, for two reasons.  Nobody should be
using dumb HTTP anymore, and the "cp" implies that the repository is
not maintained at the isp.example.com site but is synchronized
manually from some other location with _only_ ftp access into it,
which is not a typical way to run your project (I admit I did this
myself in very early days of Git when Linus was still running the
project).

Thanks.

^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: Everyday contents (was Re: What's cooking in git.git (Jul 2014, #04; Tue, 22))
  2014-08-05 20:26             ` Junio C Hamano
@ 2014-08-05 21:00               ` Philip Oakley
  0 siblings, 0 replies; 19+ messages in thread
From: Philip Oakley @ 2014-08-05 21:00 UTC (permalink / raw)
  To: Junio C Hamano; +Cc: git

From: "Junio C Hamano" <gitster@pobox.com>
> Continued: this message covers the last part.
> 
> | Repository Administration[[Repository Administration]]
> | ------------------------------------------------------
> | 
> | A repository administrator uses the following tools to set up
> | and maintain access to the repository by developers.
...

Thanks for this final part. 

I'd just updated the original patch and split it into three steps:
1. update the everday text in it's current place,
2. tweak the Makefile for the Obsolete_Html list ready for next patch
3. swap over to the giteveryday file nameing and fix the linked docs.

I'll add in your guidance on the last part to my patch 1.

Many thanks.
--
Philip

^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: [RFC/PATCH] Windows tests: let $TRASH_DIRECTORY point to native Windows path
  2014-07-29 19:43     ` [RFC/PATCH] Windows tests: let $TRASH_DIRECTORY point to native Windows path Karsten Blees
@ 2014-08-27 13:08       ` Duy Nguyen
  0 siblings, 0 replies; 19+ messages in thread
From: Duy Nguyen @ 2014-08-27 13:08 UTC (permalink / raw)
  To: Git Mailing List, msysGit; +Cc: Junio C Hamano, Karsten Blees

Ping...

On Wed, Jul 30, 2014 at 2:43 AM, Karsten Blees <karsten.blees@gmail.com> wrote:
> MSYS programs typically understand native Windows paths (e.g C:/git), but
> native Windows programs (including MinGW) don't understand MSYS paths (e.g.
> /c/git).
>
> On Windows, set TRASH_DIRECTORY to the absolute native path so that it can
> be used more easily in tests.
>
> MSYS 'tar -f' interprets everything before ':' as hostname, not as drive
> letter. Change respective tests to use stdin / stdout instead of '-f'. Also
> use $TAR from GIT-BUILD-OPTIONS rather than hardcoded tar.
>
> Signed-off-by: Karsten Blees <blees@dcon.de>
> ---
>
> Am 25.07.2014 14:30, schrieb Duy Nguyen:
>> On Wed, Jul 23, 2014 at 9:17 PM, Karsten Blees <karsten.blees@gmail.com> wrote:
>>> With the version in pu, three tests fail. t7001 is fixed with a newer 'cp'.
>>> The other two are unrelated (introduced by nd/multiple-work-trees topic).
>>>
>>> * t1501-worktree: failed 1
>>>   As of 5bbcb072 "setup.c: support multi-checkout repo setup"
>>>   Using $TRASH_DIRECTORY doesn't work on Windows.
>>>
>>> * t2026-prune-linked-checkouts: failed 1
>>>   As of 404a45f1 "prune: strategies for linked checkouts"
>>>   Dito.
>>
>> I need your help here. Would saving $(pwd) to a variable and using it
>> instead of $TRASH_DIRECTORY work? Some tests "cd" around and $(pwd)
>> may not be the same as $TRASH_DIRECTORY.
>>
>
> Yes, that would work.
>
> (Actually, you'd only need to change 'echo "$TRASH_DIR..."' in two places (both
> before cd'ing away). The other instances are parameters to non-msys programs and
> are thus automatically mangled by msys.dll.)
>
> However, I wonder why we don't set up TRASH_DIRECTORY to the native Windows path.
> I believe we'd get much fewer 'special' cases that way. Ideally, you shouldn't
> have to worry about the intricacies of MSYS path mangling when writing tests...
>
> [CCing msysgit for opinions]
>
>
>  t/t3513-revert-submodule.sh | 4 ++--
>  t/t6041-bisect-submodule.sh | 4 ++--
>  t/test-lib.sh               | 1 +
>  3 files changed, 5 insertions(+), 4 deletions(-)
>
> diff --git a/t/t3513-revert-submodule.sh b/t/t3513-revert-submodule.sh
> index a1c4e02..4a44dd6 100755
> --- a/t/t3513-revert-submodule.sh
> +++ b/t/t3513-revert-submodule.sh
> @@ -14,11 +14,11 @@ test_description='revert can handle submodules'
>  git_revert () {
>         git status -su >expect &&
>         ls -1pR * >>expect &&
> -       tar czf "$TRASH_DIRECTORY/tmp.tgz" * &&
> +       "$TAR" cz * >"$TRASH_DIRECTORY/tmp.tgz" &&
>         git checkout "$1" &&
>         git revert HEAD &&
>         rm -rf * &&
> -       tar xzf "$TRASH_DIRECTORY/tmp.tgz" &&
> +       "$TAR" xz <"$TRASH_DIRECTORY/tmp.tgz" &&
>         git status -su >actual &&
>         ls -1pR * >>actual &&
>         test_cmp expect actual &&
> diff --git a/t/t6041-bisect-submodule.sh b/t/t6041-bisect-submodule.sh
> index c6b7aa6..0de614f 100755
> --- a/t/t6041-bisect-submodule.sh
> +++ b/t/t6041-bisect-submodule.sh
> @@ -8,7 +8,7 @@ test_description='bisect can handle submodules'
>  git_bisect () {
>         git status -su >expect &&
>         ls -1pR * >>expect &&
> -       tar czf "$TRASH_DIRECTORY/tmp.tgz" * &&
> +       "$TAR" cz * > "$TRASH_DIRECTORY/tmp.tgz" &&
>         GOOD=$(git rev-parse --verify HEAD) &&
>         git checkout "$1" &&
>         echo "foo" >bar &&
> @@ -20,7 +20,7 @@ git_bisect () {
>         git bisect start &&
>         git bisect good $GOOD &&
>         rm -rf * &&
> -       tar xzf "$TRASH_DIRECTORY/tmp.tgz" &&
> +       "$TAR" xz <"$TRASH_DIRECTORY/tmp.tgz" &&
>         git status -su >actual &&
>         ls -1pR * >>actual &&
>         test_cmp expect actual &&
> diff --git a/t/test-lib.sh b/t/test-lib.sh
> index 5102340..5f6397b 100644
> --- a/t/test-lib.sh
> +++ b/t/test-lib.sh
> @@ -868,6 +868,7 @@ case $(uname -s) in
>                 md5sum "$@"
>         }
>         # git sees Windows-style pwd
> +       TRASH_DIRECTORY=$(pwd -W)
>         pwd () {
>                 builtin pwd -W
>         }
> --
> 2.0.2.897.g7f80809.dirty
>



-- 
Duy

^ permalink raw reply	[flat|nested] 19+ messages in thread

end of thread, other threads:[~2014-08-27 13:09 UTC | newest]

Thread overview: 19+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2014-07-22 21:44 What's cooking in git.git (Jul 2014, #04; Tue, 22) Junio C Hamano
2014-07-23  6:56 ` Philip Oakley
2014-07-23 18:10   ` Junio C Hamano
2014-07-24 22:37     ` Philip Oakley
2014-07-24 22:45       ` Junio C Hamano
2014-07-25 22:08         ` Junio C Hamano
2014-07-28 22:12           ` Philip Oakley
2014-07-30 17:13           ` Everyday contents (was Re: What's cooking in git.git (Jul 2014, #04; Tue, 22)) Junio C Hamano
2014-08-05 20:26             ` Junio C Hamano
2014-08-05 21:00               ` Philip Oakley
2014-08-02 17:28           ` Everday contents (was part of " Philip Oakley
2014-08-03 17:29             ` Everday contents Junio C Hamano
2014-08-03 18:41               ` Philip Oakley
2014-08-04 17:00                 ` Junio C Hamano
2014-07-23 14:17 ` What's cooking in git.git (Jul 2014, #04; Tue, 22) Karsten Blees
2014-07-23 18:24   ` Junio C Hamano
2014-07-25 12:30   ` Duy Nguyen
2014-07-29 19:43     ` [RFC/PATCH] Windows tests: let $TRASH_DIRECTORY point to native Windows path Karsten Blees
2014-08-27 13:08       ` Duy Nguyen

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.