* Re: [PATCH 4/5] attr: do not respect symlinks for in-tree .gitattributes
From: Junio C Hamano @ 2016-11-10 0:18 UTC (permalink / raw)
To: Jeff King; +Cc: Duy Nguyen, Git Mailing List
In-Reply-To: <20161109231720.luuhezzziuhx4r75@sigill.intra.peff.net>
Jeff King <peff@peff.net> writes:
> On Wed, Nov 09, 2016 at 02:58:37PM -0800, Junio C Hamano wrote:
>
> I'm slightly confused. Did you mean "supporting any in-tree symlink to
> an out-of-tree destination" in your first sentence?
I was trying to say that these "control files used solely by git"
have no business being a symbolic link pointing at anywhere, even
inside the same tree; actually, especially if it is inside the same
tree.
^ permalink raw reply
* Re: [PATCH 5/6] config docs: Provide for config to specify tags not to abbreviate
From: Markus Hitter @ 2016-11-10 0:36 UTC (permalink / raw)
To: Ian Jackson, Junio C Hamano
Cc: Jeff King, Jacob Keller, Git mailing list, Paul Mackerras
In-Reply-To: <22563.45501.383303.374430@chiark.greenend.org.uk>
Am 10.11.2016 um 00:31 schrieb Ian Jackson:
> I am proposing to set this configuration setting automatically in
> dgit. Other tools that work with particular git tags would do the
> same. There would be no need for users to do anything.
>
> Having this as an option in a menu would be quite wrong, because it
> would end up with the user and the tooling fighting. This is why I
> don't want to put this in gitk's existing config file mechanism.
Having this conversation watched for a while I get the impression that your point is essentially about introducing another type of references, next to branches and (ordinary) tags. Let's call them "interesting tags", "itags".
The logical path to get this, IMHO, isn't to add some configuration variable, but to store such interesting tags in .git/refs/itags/, just like the other reference types. Then one would create such interesting tags with
git tag -i <name>
or
git tag --interesting <name>
To reduce the backwards compatibility problem these itags could be stored in .git/refs/tags as well, itag-aware tools would sort the duplicates out.
Markus
--
- - - - - - - - - - - - - - - - - - -
Dipl. Ing. (FH) Markus Hitter
http://www.jump-ing.de/
^ permalink raw reply
* What's cooking in git.git (Nov 2016, #01; Wed, 9)
From: Junio C Hamano @ 2016-11-10 0: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'. The ones marked with '.' do not appear in any of
the integration branches, but I am still holding onto them.
Hopefully 2.11-rc1 can be tagged by the end of the week. Sorry for
the delay (and thanks for great help from y'all, especially Peff).
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"]
* cc/split-index-typofix (2016-11-01) 1 commit
- split-index: s/eith/with/ typo fix
Typofix in a comment in code
* jk/no-looking-at-dotgit-outside-repo (2016-11-01) 1 commit
- sha1_name: make wraparound of the index into ring-buffer explicit
A small code cleanup.
* rs/cocci (2016-11-01) 1 commit
- cocci: avoid self-references in object_id transformations
Improve the rule to convert "unsigned char [20]" into "struct
object_id *" in contrib/coccinelle/
--------------------------------------------------
[New Topics]
* as/merge-attr-sleep (2016-11-08) 1 commit
(merged to 'next' on 2016-11-09 at 17fbe796e6)
+ t6026-merge-attr: don't fail if sleep exits early
Fix for a racy false-positive test failure.
Will merge to 'master'.
* jk/alt-odb-cleanup (2016-11-08) 1 commit
(merged to 'next' on 2016-11-09 at f7463a1abc)
+ alternates: re-allow relative paths from environment
Fix a corner-case regression in a topic that graduated during the
v2.11 cycle.
Will merge to 'master'.
* jk/filter-process-fix (2016-11-02) 4 commits
(merged to 'next' on 2016-11-09 at 535b4f4de9)
+ t0021: fix filehandle usage on older perl
+ t0021: use $PERL_PATH for rot13-filter.pl
+ t0021: put $TEST_ROOT in $PATH
+ t0021: use write_script to create rot13 shell script
Test portability improvements and cleanups for t0021.
Will merge to 'master'.
* js/prepare-sequencer (2016-11-08) 1 commit
- sequencer: silence -Wtautological-constant-out-of-range-compare
Silence a clang warning introduced by a recently graduated topic.
Will merge to 'master'.
* ls/filter-process (2016-11-08) 2 commits
(merged to 'next' on 2016-11-09 at 7d217ebb5e)
+ t0021: compute file size with a single process instead of a pipeline
+ t0021: expect more variations in the output of uniq -c
Test portability improvements and optimization for an
already-graduated topic.
Will merge to 'master'.
* jc/retire-compaction-heuristics (2016-11-02) 3 commits
- SQUASH???
- SQUASH???
- diff: retire the original experimental "compaction" heuristics
* jc/abbrev-autoscale-config (2016-11-01) 1 commit
- config.abbrev: document the new default that auto-scales
* jk/nofollow-attr-ignore (2016-11-02) 5 commits
- exclude: do not respect symlinks for in-tree .gitignore
- attr: do not respect symlinks for in-tree .gitattributes
- exclude: convert "check_index" into a flags field
- attr: convert "macro_ok" into a flags field
- add open_nofollow() helper
* sb/submodule-config-cleanup (2016-11-02) 3 commits
- submodule-config: clarify parsing of null_sha1 element
- submodule-config: rename commit_sha1 to commit_or_tree
- submodule config: inline config_from_{name, path}
--------------------------------------------------
[Stalled]
* hv/submodule-not-yet-pushed-fix (2016-10-10) 3 commits
- batch check whether submodule needs pushing into one call
- serialize collection of refs that contain submodule changes
- serialize collection of changed submodules
The code in "git push" to compute if any commit being pushed in the
superproject binds a commit in a submodule that hasn't been pushed
out was overly inefficient, making it unusable even for a small
project that does not have any submodule but have a reasonable
number of refs.
Waiting for review.
cf. <cover.1475851621.git.hvoigt@hvoigt.net>
* sb/push-make-submodule-check-the-default (2016-10-10) 2 commits
- push: change submodule default to check when submodules exist
- submodule add: extend force flag to add existing repos
Turn the default of "push.recurseSubmodules" to "check" when
submodules seem to be in use.
Will hold to wait for hv/submodule-not-yet-pushed-fix
* jc/bundle (2016-03-03) 6 commits
- index-pack: --clone-bundle option
- Merge branch 'jc/index-pack' into jc/bundle
- bundle v3: the beginning
- bundle: keep a copy of bundle file name in the in-core bundle header
- bundle: plug resource leak
- bundle doc: 'verify' is not about verifying the bundle
The beginning of "split bundle", which could be one of the
ingredients to allow "git clone" traffic off of the core server
network to CDN.
While I think it would make it easier for people to experiment and
build on if the topic is merged to 'next', I am at the same time a
bit reluctant to merge an unproven new topic that introduces a new
file format, which we may end up having to support til the end of
time. It is likely that to support a "prime clone from CDN", it
would need a lot more than just "these are the heads and the pack
data is over there", so this may not be sufficient.
Will discard.
* mh/connect (2016-06-06) 10 commits
- connect: [host:port] is legacy for ssh
- connect: move ssh command line preparation to a separate function
- connect: actively reject git:// urls with a user part
- connect: change the --diag-url output to separate user and host
- connect: make parse_connect_url() return the user part of the url as a separate value
- connect: group CONNECT_DIAG_URL handling code
- connect: make parse_connect_url() return separated host and port
- connect: re-derive a host:port string from the separate host and port variables
- connect: call get_host_and_port() earlier
- connect: document why we sometimes call get_port after get_host_and_port
Rewrite Git-URL parsing routine (hopefully) without changing any
behaviour.
It has been two months without any support. We may want to discard
this.
* kn/ref-filter-branch-list (2016-05-17) 17 commits
- branch: implement '--format' option
- branch: use ref-filter printing APIs
- branch, tag: use porcelain output
- ref-filter: allow porcelain to translate messages in the output
- ref-filter: add `:dir` and `:base` options for ref printing atoms
- ref-filter: make remote_ref_atom_parser() use refname_atom_parser_internal()
- ref-filter: introduce symref_atom_parser() and refname_atom_parser()
- ref-filter: introduce refname_atom_parser_internal()
- ref-filter: make "%(symref)" atom work with the ':short' modifier
- ref-filter: add support for %(upstream:track,nobracket)
- ref-filter: make %(upstream:track) prints "[gone]" for invalid upstreams
- ref-filter: introduce format_ref_array_item()
- ref-filter: move get_head_description() from branch.c
- ref-filter: modify "%(objectname:short)" to take length
- ref-filter: implement %(if:equals=<string>) and %(if:notequals=<string>)
- ref-filter: include reference to 'used_atom' within 'atom_value'
- ref-filter: implement %(if), %(then), and %(else) atoms
The code to list branches in "git branch" has been consolidated
with the more generic ref-filter API.
Rerolled.
Needs review.
* ec/annotate-deleted (2015-11-20) 1 commit
- annotate: skip checking working tree if a revision is provided
Usability fix for annotate-specific "<file> <rev>" syntax with deleted
files.
Has been waiting for a review for too long without seeing anything.
Will discard.
* dk/gc-more-wo-pack (2016-01-13) 4 commits
- gc: clean garbage .bitmap files from pack dir
- t5304: ensure non-garbage files are not deleted
- t5304: test .bitmap garbage files
- prepare_packed_git(): find more garbage
Follow-on to dk/gc-idx-wo-pack topic, to clean up stale
.bitmap and .keep files.
Has been waiting for a reroll for too long.
cf. <xmqq60ypbeng.fsf@gitster.mtv.corp.google.com>
Will discard.
* jc/diff-b-m (2015-02-23) 5 commits
. WIPWIP
. WIP: diff-b-m
- diffcore-rename: allow easier debugging
- diffcore-rename.c: add locate_rename_src()
- diffcore-break: allow debugging
"git diff -B -M" produced incorrect patch when the postimage of a
completely rewritten file is similar to the preimage of a removed
file; such a resulting file must not be expressed as a rename from
other place.
The fix in this patch is broken, unfortunately.
Will discard.
--------------------------------------------------
[Cooking]
* jc/push-default-explicit (2016-10-31) 2 commits
(merged to 'next' on 2016-11-01 at 8dc3a6cf25)
+ push: test pushing ambiguously named branches
+ push: do not use potentially ambiguous default refspec
A lazy "git push" without refspec did not internally use a fully
specified refspec to perform 'current', 'simple', or 'upstream'
push, causing unnecessary "ambiguous ref" errors.
Will hold.
* jt/use-trailer-api-in-commands (2016-11-02) 6 commits
- sequencer: use trailer's trailer layout
- trailer: have function to describe trailer layout
- trailer: avoid unnecessary splitting on lines
- commit: make ignore_non_trailer take buf/len
- SQUASH???
- trailer: be stricter in parsing separators
Commands that operate on a log message and add lines to the trailer
blocks, such as "format-patch -s", "cherry-pick (-x|-s)", and
"commit -s", have been taught to use the logic of and share the
code with "git interpret-trailer".
* nd/rebase-forget (2016-10-28) 1 commit
- rebase: add --forget to cleanup rebase, leave HEAD untouched
"git rebase" learned "--forget" option, which allows a user to
remove the metadata left by an earlier "git rebase" that was
manually aborted without using "git rebase --abort".
Waiting for a reroll.
* jc/git-open-cloexec (2016-11-02) 3 commits
- sha1_file: stop opening files with O_NOATIME
- git_open_cloexec(): use fcntl(2) w/ FD_CLOEXEC fallback
- git_open(): untangle possible NOATIME and CLOEXEC interactions
The codeflow of setting NOATIME and CLOEXEC on file descriptors Git
opens has been simplified.
We may want to drop the tip one.
* jk/no-looking-at-dotgit-outside-repo-final (2016-10-26) 1 commit
(merged to 'next' on 2016-10-26 at 220e160451)
+ setup_git_env: avoid blind fall-back to ".git"
This is the endgame of the topic to avoid blindly falling back to
".git" when the setup sequence said we are _not_ in Git repository.
A corner case that happens to work right now may be broken by a
call to die("BUG").
Will cook in 'next'.
* jc/reset-unmerge (2016-10-24) 1 commit
- reset: --unmerge
After "git add" is run prematurely during a conflict resolution,
"git diff" can no longer be used as a way to sanity check by
looking at the combined diff. "git reset" learned a new
"--unmerge" option to recover from this situation.
* jc/merge-base-fp-only (2016-10-19) 8 commits
. merge-base: fp experiment
- merge: allow to use only the fp-only merge bases
- merge-base: limit the output to bases that are on first-parent chain
- merge-base: mark bases that are on first-parent chain
- merge-base: expose get_merge_bases_many_0() a bit more
- merge-base: stop moving commits around in remove_redundant()
- sha1_name: remove ONELINE_SEEN bit
- commit: simplify fastpath of merge-base
An experiment of merge-base that ignores common ancestors that are
not on the first parent chain.
* tb/convert-stream-check (2016-10-27) 2 commits
- convert.c: stream and fast search for binary
- read-cache: factor out get_sha1_from_index() helper
End-of-line conversion sometimes needs to see if the current blob
in the index has NULs and CRs to base its decision. We used to
always get a full statistics over the blob, but in many cases we
can return early when we have seen "enough" (e.g. if we see a
single NUL, the blob will be handled as binary). The codepaths
have been optimized by using streaming interface.
Waiting for review.
The tip seems to do too much in a single commit and may be better split.
cf. <20161012134724.28287-1-tboegi@web.de>
cf. <xmqqd1il5w4e.fsf@gitster.mtv.corp.google.com>
* pb/bisect (2016-10-18) 27 commits
- bisect--helper: remove the dequote in bisect_start()
- bisect--helper: retire `--bisect-auto-next` subcommand
- bisect--helper: retire `--bisect-autostart` subcommand
- bisect--helper: retire `--bisect-write` subcommand
- bisect--helper: `bisect_replay` shell function in C
- bisect--helper: `bisect_log` shell function in C
- bisect--helper: retire `--write-terms` subcommand
- bisect--helper: retire `--check-expected-revs` subcommand
- bisect--helper: `bisect_state` & `bisect_head` shell function in C
- bisect--helper: `bisect_autostart` shell function in C
- bisect--helper: retire `--next-all` subcommand
- bisect--helper: retire `--bisect-clean-state` subcommand
- bisect--helper: `bisect_next` and `bisect_auto_next` shell function in C
- t6030: no cleanup with bad merge base
- bisect--helper: `bisect_start` shell function partially in C
- bisect--helper: `get_terms` & `bisect_terms` shell function in C
- bisect--helper: `bisect_next_check` & bisect_voc shell function in C
- bisect--helper: `check_and_set_terms` shell function in C
- bisect--helper: `bisect_write` shell function in C
- bisect--helper: `is_expected_rev` & `check_expected_revs` shell function in C
- bisect--helper: `bisect_reset` shell function in C
- wrapper: move is_empty_file() and rename it as is_empty_or_missing_file()
- t6030: explicitly test for bisection cleanup
- bisect--helper: `bisect_clean_state` shell function in C
- bisect--helper: `write_terms` shell function in C
- bisect: rewrite `check_term_format` shell function in C
- bisect--helper: use OPT_CMDMODE instead of OPT_BOOL
Move more parts of "git bisect" to C.
Waiting for review.
* st/verify-tag (2016-10-10) 7 commits
- t/t7004-tag: Add --format specifier tests
- t/t7030-verify-tag: Add --format specifier tests
- builtin/tag: add --format argument for tag -v
- builtin/verify-tag: add --format to verify-tag
- tag: add format specifier to gpg_verify_tag
- ref-filter: add function to print single ref_array_item
- gpg-interface, tag: add GPG_VERIFY_QUIET flag
"git tag" and "git verify-tag" learned to put GPG verification
status in their "--format=<placeholders>" output format.
Waiting for a reroll.
cf. <20161007210721.20437-1-santiago@nyu.edu>
* sb/attr (2016-11-09) 38 commits
- completion: clone can initialize specific submodules
- clone: add --init-submodule=<pathspec> switch
- SQUASH to: submodule update: add `--init-default-path` switch
- submodule update: add `--init-default-path` switch
- pathspec: allow escaped query values
- pathspec: allow querying for attributes
- pathspec: move prefix check out of the inner loop
- pathspec: move long magic parsing out of prefix_pathspec
- Documentation: fix a typo
- attr: keep attr stack for each check
- SQUASH???
- attr: convert to new threadsafe API
- attr: make git_check_attr_counted static
- attr.c: outline the future plans by heavily commenting
- attr.c: always pass check[] to collect_some_attrs()
- attr.c: introduce empty_attr_check_elems()
- attr.c: correct ugly hack for git_all_attrs()
- attr.c: rename a local variable check
- attr.c: pass struct git_attr_check down the callchain
- attr.c: add push_stack() helper
- attr: support quoting pathname patterns in C style
- attr: expose validity check for attribute names
- attr: add counted string version of git_attr()
- attr: add counted string version of git_check_attr()
- attr: retire git_check_attrs() API
- attr: convert git_check_attrs() callers to use the new API
- attr: convert git_all_attrs() to use "struct git_attr_check"
- attr: (re)introduce git_check_attr() and struct git_attr_check
- attr: rename function and struct related to checking attributes
- attr.c: plug small leak in parse_attr_line()
- attr.c: tighten constness around "git_attr" structure
- attr.c: simplify macroexpand_one()
- attr.c: mark where #if DEBUG ends more clearly
- attr.c: complete a sentence in a comment
- attr.c: explain the lack of attr-name syntax check in parse_attr()
- attr.c: update a stale comment on "struct match_attr"
- attr.c: use strchrnul() to scan for one line
- commit.c: use strchrnul() to scan for one line
The attributes API has been updated so that it can later be
optimized using the knowledge of which attributes are queried.
Building on top of the updated API, the pathspec machinery learned
to select only paths with given attributes set.
Waiting for review.
* va/i18n-perl-scripts (2016-10-20) 14 commits
- i18n: difftool: mark warnings for translation
- i18n: send-email: mark string with interpolation for translation
- i18n: send-email: mark warnings and errors for translation
- i18n: send-email: mark strings for translation
- i18n: add--interactive: mark status words for translation
- i18n: add--interactive: remove %patch_modes entries
- i18n: add--interactive: mark edit_hunk_manually message for translation
- i18n: add--interactive: i18n of help_patch_cmd
- i18n: add--interactive: mark patch prompt for translation
- i18n: add--interactive: mark plural strings
- i18n: clean.c: match string with git-add--interactive.perl
- i18n: add--interactive: mark strings with interpolation for translation
- i18n: add--interactive: mark simple here-documents for translation
- i18n: add--interactive: mark strings for translation
Porcelain scripts written in Perl are getting internationalized.
Waiting for review.
cf. <20161010125449.7929-1-vascomalmeida@sapo.pt>
* jc/latin-1 (2016-09-26) 2 commits
(merged to 'next' on 2016-09-28 at c8673e03c2)
+ utf8: accept "latin-1" as ISO-8859-1
+ utf8: refactor code to decide fallback encoding
Some platforms no longer understand "latin-1" that is still seen in
the wild in e-mail headers; replace them with "iso-8859-1" that is
more widely known when conversion fails from/to it.
Will hold to see if people scream.
* sg/fix-versioncmp-with-common-suffix (2016-09-08) 5 commits
- versioncmp: cope with common leading parts in versionsort.prereleaseSuffix
- versioncmp: pass full tagnames to swap_prereleases()
- t7004-tag: add version sort tests to show prerelease reordering issues
- t7004-tag: use test_config helper
- t7004-tag: delete unnecessary tags with test_when_finished
The prereleaseSuffix feature of version comparison that is used in
"git tag -l" did not correctly when two or more prereleases for the
same release were present (e.g. when 2.0, 2.0-beta1, and 2.0-beta2
are there and the code needs to compare 2.0-beta1 and 2.0-beta2).
Waiting for a reroll.
cf. <20160908223727.Horde.jVOOJ278ssZ3qkyjkmyqZD-@webmail.informatik.kit.edu>
* jc/pull-rebase-ff (2016-07-28) 1 commit
- pull: fast-forward "pull --rebase=true"
"git pull --rebase", when there is no new commits on our side since
we forked from the upstream, should be able to fast-forward without
invoking "git rebase", but it didn't.
Needs a real log message and a few tests.
* jc/merge-drop-old-syntax (2015-04-29) 1 commit
(merged to 'next' on 2016-10-11 at 8928c8b9b3)
+ merge: drop 'git merge <message> HEAD <commit>' syntax
Stop supporting "git merge <message> HEAD <commit>" syntax that has
been deprecated since October 2007, and issues a deprecation
warning message since v2.5.0.
It has been reported that git-gui still uses the deprecated syntax,
which needs to be fixed before this final step can proceed.
cf. <5671DB28.8020901@kdbg.org>
Will cook in 'next'.
^ permalink raw reply
* Re: [PATCH v1 0/2] Fix default macOS build locally and on Travis CI
From: Torsten Bögershausen @ 2016-11-10 6:41 UTC (permalink / raw)
To: Junio C Hamano, larsxschneider; +Cc: git
In-Reply-To: <xmqqwpgc6x4t.fsf@gitster.mtv.corp.google.com>
On 10/11/16 00:39, Junio C Hamano wrote:
>
> I've followed what was available at the public-inbox archive, but it
> is unclear what the conclusion was.
>
> For the first one your "how about" non-patch, to which Peff said
> "that's simple and good", looked good to me as well, but is it
> available as a final patch that I can just take and apply (otherwise
> I think I can do the munging myself, but I'd rather be spoon-fed
> when able ;-).
If you can munge the Peff version that may be easiest ?
I couldn't find a branch in your repo, but am happy to review
whatever shows up there and in pu.
^ permalink raw reply
* Re: [ANNOUNCE] Prerelease: Git for Windows v2.11.0-rc0
From: stefan.naewe @ 2016-11-10 8:12 UTC (permalink / raw)
To: Johannes.Schindelin, git-for-windows, git
In-Reply-To: <alpine.DEB.2.20.1611051025030.3108@virtualbox>
Am 05.11.2016 um 10:50 schrieb Johannes Schindelin:
> Dear Git users,
>
> I finally got around to rebase the Windows-specific patches (which seem to
> not make it upstream as fast as we get new ones) on top of upstream Git
> v2.11.0-rc0, and to bundle installers, portable Git and MinGit [*1*]:
>
> https://github.com/git-for-windows/git/releases/tag/v2.11.0-rc0.windows.1
>
> It would be really nice if those of you who have access to Windows [*2*]
> could try it out and report bugs before v2.11.0 final.
I tried that version on 64bit Win7.
Somehow the PATH env. variable does no longer get set correctly.
On git-for-windows 2.10.2 my PATH (inside git bash) contains ~75 Entries.
With the above installer I only get ~17 !
(Inside cmd.exe I get 61 entries. I set some more entries with by ~/.bashrc)
It seems that all entries that contain a path with whitespace (e.g. 'c:\program files (x86)' )
are no longer there.
Any ideas ?
Thanks,
Stefan
--
----------------------------------------------------------------
/dev/random says: Oxymoron: Stuck in traffic.
python -c "print '73746566616e2e6e616577654061746c61732d656c656b74726f6e696b2e636f6d'.decode('hex')"
GPG Key fingerprint = 2DF5 E01B 09C3 7501 BCA9 9666 829B 49C5 9221 27AF
^ permalink raw reply
* [PATCH v2] t6026-merge-attr: don't fail if sleep exits early
From: Andreas Schwab @ 2016-11-10 8:31 UTC (permalink / raw)
To: Jeff King; +Cc: Johannes Schindelin, Johannes Sixt, git
In-Reply-To: <20161109153128.aqm2lgdntdlycnaq@sigill.intra.peff.net>
Commit 5babb5bdb3 ("t6026-merge-attr: clean up background process at end
of test case") added a kill command to clean up after the test, but this
can fail if the sleep command exits before the cleanup is executed.
Ignore the error from the kill command.
Explicitly check for the existence of the pid file to test that the merge
driver was actually called.
Signed-off-by: Andreas Schwab <schwab@suse.de>
---
t/t6026-merge-attr.sh | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/t/t6026-merge-attr.sh b/t/t6026-merge-attr.sh
index 7a6e33e673..03d13d00b5 100755
--- a/t/t6026-merge-attr.sh
+++ b/t/t6026-merge-attr.sh
@@ -187,13 +187,14 @@ test_expect_success 'custom merge does not lock index' '
sleep 1 &
echo $! >sleep.pid
EOF
- test_when_finished "kill \$(cat sleep.pid)" &&
+ test_when_finished "kill \$(cat sleep.pid) || :" &&
test_write_lines >.gitattributes \
"* merge=ours" "text merge=sleep-one-second" &&
test_config merge.ours.driver true &&
test_config merge.sleep-one-second.driver ./sleep-one-second.sh &&
- git merge master
+ git merge master &&
+ test -f sleep.pid
'
test_done
--
2.10.2
--
Andreas Schwab, SUSE Labs, schwab@suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."
^ permalink raw reply related
* Re: Cleaning ignored files
From: John Szakmeister @ 2016-11-10 9:19 UTC (permalink / raw)
To: Roman Terekhov; +Cc: git
In-Reply-To: <CALbGNxUahc0b151niqS3Qd6N8wapY5RWJs1w0ZSf6ZW1=id6vA@mail.gmail.com>
On Wed, Nov 9, 2016 at 1:23 PM, Roman Terekhov <roman.terekhov@gmail.com> wrote:
> Hi,
>
> I want to ask about git clean -dXf command behaviour.
>
> I do the following:
>
> $ mkdir gitignore_test
> $ cd gitignore_test/
> $ git init
> Initialized empty Git repository in ~/gitignore_test/.git/
>
> $ echo *.sln > .gitignore
> $ git add .gitignore
> $ git commit -m "add gitignore"
> [master (root-commit) ef78a3c] add gitignore
> 1 file changed, 1 insertion(+)
> create mode 100644 .gitignore
>
> $ mkdir src
> $ touch test.sln
> $ touch src/test.sln
> $ tree
> .
> ├── src
> │ └── test.sln
> └── test.sln
>
> 1 directory, 2 files
>
> $ git clean -dXf
> Removing test.sln
>
> $ tree
> .
> └── src
> └── test.sln
>
> 1 directory, 1 file
>
>
> Why git clean -dXf does not remove all my test.sln files, but just one of them?
src/ is not under version control, and currently git does not descend
into unknown folders to remove ignored files. If you had a tracked or
staged file in src/, then git would descend into src/ and remove
test.sln as expected. In your example, try doing:
$ touch src/foo.c
$ git add src/foo.c
$ git clean -dXf
Removing src/test.sln
Removing test.sln
Hope that helps!
-John
^ permalink raw reply
* Re: [PATCH 4/5] attr: do not respect symlinks for in-tree .gitattributes
From: Duy Nguyen @ 2016-11-10 11:00 UTC (permalink / raw)
To: Jeff King; +Cc: Junio C Hamano, Git Mailing List
In-Reply-To: <20161110002335.z2z2stjtzgspikxe@sigill.intra.peff.net>
On Thu, Nov 10, 2016 at 7:23 AM, Jeff King <peff@peff.net> wrote:
> On Wed, Nov 09, 2016 at 04:18:29PM -0800, Junio C Hamano wrote:
>
>> Jeff King <peff@peff.net> writes:
>>
>> > On Wed, Nov 09, 2016 at 02:58:37PM -0800, Junio C Hamano wrote:
>> >
>> > I'm slightly confused. Did you mean "supporting any in-tree symlink to
>> > an out-of-tree destination" in your first sentence?
>>
>> I was trying to say that these "control files used solely by git"
>> have no business being a symbolic link pointing at anywhere, even
>> inside the same tree; actually, especially if it is inside the same
>> tree.
>
> OK. That is what my patch does (modulo .gitmodules, which I did not
> think of). But I think that is the opposite of Duy's opinion, as his
> review seemed to object to that.
I only objected the rationale (to be consistent with reading index).
If you sold it as malicious symlinks, or even put it like Junio "no,
the design makes more sense to be this way", I would be ok.
On the implementation side, we should print something friendlier than
strerror(ELOOP) if we decide that "symlinks on .git* files are wrong".
The standard ELOOP message does not communicate our design decision
well to the users. But this is a minor thing and can be ignored.
> As you know my ulterior motive is dealing with malicious out-of-tree
> symlinks, and I would be happy to deal with that directly. That still
> leaves symlinked ".gitmodules" etc in a funny state (they work in the
> filesystem but not in the index), but since nobody is _complaining_,
> it's a bug we could leave for another day.
The discussion trailed off a bit to symlinks in general in worktree
too, I think. But it's not my itch, we can leave it for another day.
--
Duy
^ permalink raw reply
* Re: [PATCH v1 2/2] travis-ci: disable GIT_TEST_HTTPD for macOS
From: Lars Schneider @ 2016-11-10 11:07 UTC (permalink / raw)
To: Jeff King; +Cc: Junio C Hamano, Torsten Bögershausen, git
In-Reply-To: <20161107212004.x4y7bcl2p4chfkm6@sigill.intra.peff.net>
> On 07 Nov 2016, at 22:20, Jeff King <peff@peff.net> wrote:
>
> On Sun, Nov 06, 2016 at 10:42:36PM +0100, Lars Schneider wrote:
>
>>> From: Lars Schneider <larsxschneider@gmail.com>
>>>
>>> TravisCI changed their default macOS image from 10.10 to 10.11 [1].
>>> Unfortunately the HTTPD tests do not run out of the box using the
>>> pre-installed Apache web server anymore. Therefore we enable these
>>> tests only for Linux and disable them for macOS.
>> [...]
>> Hi Junio,
>>
>> the patch above is one of two patches to make TravisCI pass, again.
>> Could you queue it?
>
> I don't really mind disabling tests if they don't run on a platform. But
> the more interesting question to me is: why don't they run any more? Is
> there some config tweak needed, or is it an insurmountable problem?
I can't really remember what the problem was. I think some apache config
required some module that was not present and I wasn't able to get this
working quickly.
> Using Apache in the tests has been the source of frequent portability
> problems and configuration headaches. I do wonder if we'd be better off
> using some small special-purpose web server (even a short perl script
> written around HTTP::Server::Simple or something).
>
> On the other hand, testing against Apache approximates a more real-world
> case, which has value. It might be nice if our tests supported multiple
> web servers, but that would mean duplicating the config for each
> manually.
I agree that the real-world Apache test is more valuable and I really want
to keep the Linux Apache test running. However, I don't think many people
use macOS as Git web server and therefore I thought it is not worth the
effort to investigate this problem further.
- Lars
^ permalink raw reply
* Re: [PATCH v2] rebase: add --forget to cleanup rebase, leave everything else untouched
From: Duy Nguyen @ 2016-11-10 11:09 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Git Mailing List
In-Reply-To: <xmqqh97g9zut.fsf@gitster.mtv.corp.google.com>
On Thu, Nov 10, 2016 at 3:12 AM, Junio C Hamano <gitster@pobox.com> wrote:
> Nguyễn Thái Ngọc Duy <pclouds@gmail.com> writes:
>
>> ---
>> v2 changes just the subject line
>
> That's not sufficient, is it? What you did in the documentation
> would raise the same "Hmph, is this only about HEAD?" and unlike the
> commit subject, it will carve it in stone for end-users.
Oops. I forgot about git-rebase.txt. How about this?
--forget::
Abort the rebase operation but leave HEAD, the index and
working tree untouched.
And think that's all the things rebase touches.
--
Duy
^ permalink raw reply
* [PATCH v2] Makefile: set NO_OPENSSL on macOS by default
From: larsxschneider @ 2016-11-10 11:13 UTC (permalink / raw)
To: git; +Cc: peff, gitster, tboegi, Lars Schneider
In-Reply-To: <1fdc5333-79a8-7c1d-f7e5-e8150d0ad9cc@web.de>
From: Lars Schneider <larsxschneider@gmail.com>
Apple removed the OpenSSL header files in macOS 10.11 and above. OpenSSL
was deprecated since macOS 10.7.
Set `NO_OPENSSL` and `APPLE_COMMON_CRYPTO` to `YesPlease` as default for
macOS. It is possible to override this and use OpenSSL by defining
`NO_APPLE_COMMON_CRYPTO`.
Signed-off-by: Lars Schneider <larsxschneider@gmail.com>
---
Makefile | 1 +
1 file changed, 1 insertion(+)
diff --git a/Makefile b/Makefile
index 9d6c245..f53fcc9 100644
--- a/Makefile
+++ b/Makefile
@@ -1047,6 +1047,7 @@ ifeq ($(uname_S),Darwin)
endif
endif
ifndef NO_APPLE_COMMON_CRYPTO
+ NO_OPENSSL = YesPlease
APPLE_COMMON_CRYPTO = YesPlease
COMPAT_CFLAGS += -DAPPLE_COMMON_CRYPTO
endif
--
2.10.2
^ permalink raw reply related
* Re: [PATCH v1 0/2] Fix default macOS build locally and on Travis CI
From: Lars Schneider @ 2016-11-10 11:19 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, tboegi
In-Reply-To: <xmqqwpgc6x4t.fsf@gitster.mtv.corp.google.com>
> On 10 Nov 2016, at 00:39, Junio C Hamano <gitster@pobox.com> wrote:
>
> larsxschneider@gmail.com writes:
>
>> From: Lars Schneider <larsxschneider@gmail.com>
>>
>> Apple removed the OpenSSL header files in macOS and therefore Git does
>> not build out of the box on macOS anymore. See previous discussion with
>> Torsten here: http://public-inbox.org/git/565B3036.8000604@web.de/
>>
>> This mini series makes Git build out of the box on macOS, again, and
>> disables the HTTPD tests on macOS TravisCI as they don't work anymore
>> with the new macOS TravisCI default image:
>> https://blog.travis-ci.com/2016-10-04-osx-73-default-image-live/
>>
>> Thanks,
>> Lars
>>
>>
>> Lars Schneider (2):
>> config.mak.in: set NO_OPENSSL and APPLE_COMMON_CRYPTO for macOS >10.11
>> travis-ci: disable GIT_TEST_HTTPD for macOS
>>
>> .travis.yml | 3 ++-
>> config.mak.uname | 6 ++++++
>> 2 files changed, 8 insertions(+), 1 deletion(-)
>
> I've followed what was available at the public-inbox archive, but it
> is unclear what the conclusion was.
>
> For the first one your "how about" non-patch, to which Peff said
> "that's simple and good", looked good to me as well, but is it
> available as a final patch that I can just take and apply (otherwise
> I think I can do the munging myself, but I'd rather be spoon-fed
> when able ;-).
Sure! Here you go:
http://public-inbox.org/git/20161110111348.61580-1-larsxschneider@gmail.com/
> I do not have a strong opinion on the second one. For an interim
> solution, disabling webserver tests certainly is expedite and safe,
> so I am fine taking it as-is, but I may have missed strong
> objections.
I haven't seen strong objections either. Just for reference, here is the patch:
http://public-inbox.org/git/20161017002550.88782-3-larsxschneider@gmail.com/
I hope you're well, again!!
- Lars
^ permalink raw reply
* Re: [PATCH v2] rebase: add --forget to cleanup rebase, leave everything else untouched
From: Duy Nguyen @ 2016-11-10 11:22 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Git Mailing List
In-Reply-To: <CACsJy8D9SHjwb2Ug_DYKmSO+dDxkkqwBFViQrW4eDqbJFjHESw@mail.gmail.com>
On Thu, Nov 10, 2016 at 6:09 PM, Duy Nguyen <pclouds@gmail.com> wrote:
> On Thu, Nov 10, 2016 at 3:12 AM, Junio C Hamano <gitster@pobox.com> wrote:
>> Nguyễn Thái Ngọc Duy <pclouds@gmail.com> writes:
>>
>>> ---
>>> v2 changes just the subject line
>>
>> That's not sufficient, is it? What you did in the documentation
>> would raise the same "Hmph, is this only about HEAD?" and unlike the
>> commit subject, it will carve it in stone for end-users.
>
> Oops. I forgot about git-rebase.txt. How about this?
>
> --forget::
> Abort the rebase operation but leave HEAD, the index and
> working tree untouched.
Or, since --abort describes it as "reset HEAD to the original branch",
we could write "Abort the rebase operation. Unlike --abort, HEAD is
not restored back to the original branch". Index and worktree are
implied by "not restored". Not sure if it's too subtle.
--
Duy
^ permalink raw reply
* [RFC] Add way to make Git credentials accessible from clean/smudge filter
From: Lars Schneider @ 2016-11-10 11:52 UTC (permalink / raw)
To: git; +Cc: Jeff King, me
Hi,
we just implemented the first "real-world" user of the new clean/smudge
"filter protocol" interface (see "convert: add filter.<driver>.process option"
edcc858 for details) and the results are fantastic. Filtering 12,000 files in
my artificial test repo is more than 60x faster (depending on the platform).
On Windows that means the clean/smudge operations runs in 57 seconds instead
of 55 minutes [1]!
I have a number of ideas to improve the protocol even further and I am seeking
early feedback on the following - possibly most controversial - idea:
Some filters might want to perform additional network interactions and these
filters would like to use the Git credentials to perform these actions. If
such a filter is configured with "offerCredentials = true" then the filter
could request the current Git credentials via the "filter-protocol".
A configuration could look like this:
------------------------
[filter "myfilter"]
process = my-filter-process
required = true
offerCredentials = true
------------------------
The default would, of course, be "offerCredentials = false".
I haven't looked at an implemenation approach at all. I wonder if this could
be OK from a conceptional point of view or if there are obvious security
problems that I am missing.
Thanks,
Lars
[1] https://github.com/github/git-lfs/pull/1617#issuecomment-259411850
^ permalink raw reply
* Re: [RFC] Add way to make Git credentials accessible from clean/smudge filter
From: Matthieu Moy @ 2016-11-10 12:10 UTC (permalink / raw)
To: Lars Schneider; +Cc: git, Jeff King, me
In-Reply-To: <4C8C5650-7221-4F62-A9CC-81AE01EF6DC7@gmail.com>
Lars Schneider <larsxschneider@gmail.com> writes:
> I haven't looked at an implemenation approach at all. I wonder if this could
> be OK from a conceptional point of view or if there are obvious security
> problems that I am missing.
Did you consider just running "git credential" from the filter? It may
not be the perfect solution, but it should work. I already used it to
get credential from a remote-helper (git-remote-mediawiki). When
prompting credentials interactively, it grabs the terminal directly, so
it work even if stdin/stdout are used for the protocol.
Asking the main git process to get the credentials probably has added
value like the ability to prompt once and use the same for several
filter processes.
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
^ permalink raw reply
* Re: [RFC] Add way to make Git credentials accessible from clean/smudge filter
From: Jeff King @ 2016-11-10 16:08 UTC (permalink / raw)
To: Matthieu Moy; +Cc: Lars Schneider, git, me
In-Reply-To: <vpqoa1n1qom.fsf@anie.imag.fr>
On Thu, Nov 10, 2016 at 01:10:17PM +0100, Matthieu Moy wrote:
> Lars Schneider <larsxschneider@gmail.com> writes:
>
> > I haven't looked at an implemenation approach at all. I wonder if this could
> > be OK from a conceptional point of view or if there are obvious security
> > problems that I am missing.
>
> Did you consider just running "git credential" from the filter? It may
> not be the perfect solution, but it should work. I already used it to
> get credential from a remote-helper (git-remote-mediawiki). When
> prompting credentials interactively, it grabs the terminal directly, so
> it work even if stdin/stdout are used for the protocol.
Yeah, that is the solution I was going to suggest. The credentials are
totally orthogonal to the filters, and I would rather not shove them
into the protocol. It's an extra process, but with the new multi-use
smudge filter, it's one per git invocation, not one per file.
-Peff
^ permalink raw reply
* Re: [PATCH v1 2/2] travis-ci: disable GIT_TEST_HTTPD for macOS
From: Jeff King @ 2016-11-10 16:10 UTC (permalink / raw)
To: Lars Schneider; +Cc: Junio C Hamano, Torsten Bögershausen, git
In-Reply-To: <CBAF806C-7E1E-4490-A07C-F98DB7488F5F@gmail.com>
On Thu, Nov 10, 2016 at 12:07:14PM +0100, Lars Schneider wrote:
> > Using Apache in the tests has been the source of frequent portability
> > problems and configuration headaches. I do wonder if we'd be better off
> > using some small special-purpose web server (even a short perl script
> > written around HTTP::Server::Simple or something).
> >
> > On the other hand, testing against Apache approximates a more real-world
> > case, which has value. It might be nice if our tests supported multiple
> > web servers, but that would mean duplicating the config for each
> > manually.
>
> I agree that the real-world Apache test is more valuable and I really want
> to keep the Linux Apache test running. However, I don't think many people
> use macOS as Git web server and therefore I thought it is not worth the
> effort to investigate this problem further.
IMHO, the value in the http tests is not testing the server side, but
the client side. Without being able to set up a dummy HTTP server, we do
not have any way to exercise the client side of git-over-http at all.
And people on macOS _do_ use that. :)
-Peff
^ permalink raw reply
* Re: [PATCH v7 01/17] ref-filter: implement %(if), %(then), and %(else) atoms
From: Karthik Nayak @ 2016-11-10 17:11 UTC (permalink / raw)
To: Jacob Keller; +Cc: Git mailing list
In-Reply-To: <CA+P7+xoAmYqi0OazZux+rooXW+D_N9L5s+2BzUyJJJXtmLZX-Q@mail.gmail.com>
Hey,
On Wed, Nov 9, 2016 at 4:43 AM, Jacob Keller <jacob.keller@gmail.com> wrote:
> On Tue, Nov 8, 2016 at 12:11 PM, Karthik Nayak <karthik.188@gmail.com> wrote:
>> From: Karthik Nayak <karthik.188@gmail.com>
>>
>> +Some atoms like %(align) and %(if) always require a matching %(end).
>> +We call them "opening atoms" and sometimes denote them as %($open).
>> +
>> +When a scripting language specific quoting is in effect (i.e. one of
>> +`--shell`, `--perl`, `--python`, `--tcl` is used), except for opening
>> +atoms, replacement from every %(atom) is quoted when and only when it
>> +appears at the top-level (that is, when it appears outside
>> +%($open)...%(end)).
>> +
>> +When a scripting language specific quoting is in effect, everything
>> +between a top-level opening atom and its matching %(end) is evaluated
>> +according to the semantics of the opening atom and its result is
>> +quoted.
>> +
>>
>
> Nice, I like the explanation above.
>
All thanks to Eric, Junio, Christian, Matthieu and everyone else who
helped me phrase
these.
>>
>> + }
>> + } else if (!if_then_else->condition_satisfied)
>
> Minor nit. I'm not sure what standard we use here at Git, but
> traditionally, I prefer to see { } blocks on all sections even if only
> one of them needs it. (That is, only drop the braces when every
> section is one line.) It also looks weird with a comment since it
> appears as multiple lines to the reader. I think the braces improve
> readability.
>
> I don't know whether that's Git's code base standard or not, however.
> It's not really worth a re-roll unless something else would need to
> change.
>
I believe this is the syntax followed in Git, xdiff/xmerge.c:173 and so on.
You're comments are right on though.
--
Regards,
Karthik Nayak
^ permalink raw reply
* Re: [PATCH v7 02/17] ref-filter: include reference to 'used_atom' within 'atom_value'
From: Karthik Nayak @ 2016-11-10 17:16 UTC (permalink / raw)
To: Jacob Keller; +Cc: Git mailing list
In-Reply-To: <CA+P7+xqVAEuc12eQJ7-Et0CtXc12t5zDUg3Qsh3214cTh_brbA@mail.gmail.com>
>>
>> /*
>> @@ -370,7 +368,7 @@ static void align_atom_handler(struct atom_value *atomv, struct ref_formatting_s
>> push_stack_element(&state->stack);
>> new = state->stack;
>> new->at_end = end_align_handler;
>> - new->at_end_data = &atomv->u.align;
>> + new->at_end_data = &atomv->atom->u.align;
>
> At first, this confused me. I was like "we dropped the union, why are
> we still referencing it. But I realized that the "used_atom" struct
> actually contains the same union and we were copying it.
>
> Ok, so this looks good.
>
It is confusing if one only looks at the patch without actually going
through ref-filter.c. I'm sure your comment will help
anyone going through these patches.
--
Regards,
Karthik Nayak
^ permalink raw reply
* Re: [PATCH v7 04/17] ref-filter: modify "%(objectname:short)" to take length
From: Karthik Nayak @ 2016-11-10 17:36 UTC (permalink / raw)
To: Jacob Keller; +Cc: Git mailing list
In-Reply-To: <CA+P7+xqG5ACT2ZB=M8gLmDaYgSgX202+afJmZJKat6NzbFzL=g@mail.gmail.com>
On Wed, Nov 9, 2016 at 4:57 AM, Jacob Keller <jacob.keller@gmail.com> wrote:
> On Tue, Nov 8, 2016 at 12:11 PM, Karthik Nayak <karthik.188@gmail.com> wrote:
>> From: Karthik Nayak <karthik.188@gmail.com>
>>
>> Add support for %(objectname:short=<length>) which would print the
>> abbreviated unique objectname of given length. When no length is
>> specified, the length is 'DEFAULT_ABBREV'. The minimum length is
>> 'MINIMUM_ABBREV'. The length may be exceeded to ensure that the provided
>> object name is unique.
>>
>
> Ok this makes sense. It may be annoying that the length might go
> beyond the size that we wanted, but I think it's better than printing
> a non-unique short abbreviation.
>
> I have one suggested change, which is to drop O_LENGTH and have
> O_SHORT store the length always, setting it to DEFAULT_ABBREV when no
> length provided. This allows you to drop some code. I don't think it's
> actually worth a re-roll by itself since the current code is correct.
>
> Thanks,
> Jake
>
That does make sense, It would also not error out when we use
%(objectname:short=) and
not specify the length. Idk, if that's desirable or not. But it does
make the code a little more
confusing to read at the same time.
So since its a small change, I'd be okay going either ways with this.
--
Regards,
Karthik Nayak
^ permalink raw reply
* Re: [PATCH v7 03/17] ref-filter: implement %(if:equals=<string>) and %(if:notequals=<string>)
From: Karthik Nayak @ 2016-11-10 17:31 UTC (permalink / raw)
To: Jacob Keller; +Cc: Git mailing list
In-Reply-To: <CA+P7+xoavgQ=NK8GGGXf90ESuPs+mFwHzEWbsnjWjZ4V7TWpjw@mail.gmail.com>
On Wed, Nov 9, 2016 at 4:52 AM, Jacob Keller <jacob.keller@gmail.com> wrote:
> On Tue, Nov 8, 2016 at 12:11 PM, Karthik Nayak <karthik.188@gmail.com> wrote:
>
> Ok. How does this handle whitespace? The previous if implementation
> treated whitespace as trimming to ignore. Does this require an exact
> whitespace match? It appears by the code that strings must match
> exactly. Would it make more sense to always trim the value of
> whitespace first before comparison? Hmm.. I think we should avoid
> doing that actually.
>
This does not trim whitespace what so ever and requires an exact match.
I don't see the reason behind trimming whitespace though.
>> In addition to the above, for commit and tag objects, the header
>> field names (`tree`, `parent`, `object`, `type`, and `tag`) can
>> diff --git a/ref-filter.c b/ref-filter.c
>> index 8392303..44481c3 100644
>> --- a/ref-filter.c
>> +++ b/ref-filter.c
>> @@ -22,6 +22,8 @@ struct align {
>> };
>>
>> struct if_then_else {
>> + const char *if_equals,
>> + *not_equals;
>
> Ok so we add both if_equals and not_equals values. Could we re-use the
> same string?
If we use an union then we'll be saving space, but that comes at the
disadvantage that
we'd need an indicator to show which subatom we're using (i.e
if_equals or not_equals)
for the checks made in the code below.
At the expense of keeping two pointers we avoid the extra indicator
while keeping the code
elegant. Either ways not too keen on this, up for discussion :)
>
>> unsigned int then_atom_seen : 1,
>> else_atom_seen : 1,
>> condition_satisfied : 1;
>> @@ -49,6 +51,10 @@ static struct used_atom {
>> enum { C_BARE, C_BODY, C_BODY_DEP, C_LINES, C_SIG, C_SUB } option;
>> unsigned int nlines;
>> } contents;
>> + struct {
>> + const char *if_equals,
>> + *not_equals;
>
>
> Same here, why do we need both strings here stored separately? Could
> we instead store which state to check and store the string once? I'm
> not sure that really buys us any storage.
>
same as above, we utilize the fact that its easier to check the strings like
if (if_equals)
...
else (not_equals)
...
else we'd have to have an indicator to know which to check.
--
Regards,
Karthik Nayak
^ permalink raw reply
* Re: [PATCH v7 05/17] ref-filter: move get_head_description() from branch.c
From: Karthik Nayak @ 2016-11-10 19:01 UTC (permalink / raw)
To: Jacob Keller; +Cc: Git mailing list
In-Reply-To: <CA+P7+xo4M5g15B7zKzC-zJvd6O0Wfpks142-+C8tAqTfyEJ+nA@mail.gmail.com>
On Wed, Nov 9, 2016 at 5:01 AM, Jacob Keller <jacob.keller@gmail.com> wrote:
> On Tue, Nov 8, 2016 at 12:11 PM, Karthik Nayak <karthik.188@gmail.com> wrote:
>
>>
>> - if (starts_with(name, "refname"))
>> + if (starts_with(name, "refname")) {
>> refname = ref->refname;
>> - else if (starts_with(name, "symref"))
>> + if (ref->kind & FILTER_REFS_DETACHED_HEAD)
>> + refname = get_head_description();
>
> Since this (I think?) changes behavior of refname would it make sense
> to add a test for this?
>
At the moment there is no way to check this, since this option is not used by
git for-each-ref or git tag (both of which completely use ref-filter
ATM). This is
however tested as eventually git branch uses ref-filter.
--
Regards,
Karthik Nayak
^ permalink raw reply
* Re: [PATCH v2] rebase: add --forget to cleanup rebase, leave everything else untouched
From: Junio C Hamano @ 2016-11-10 19:07 UTC (permalink / raw)
To: Duy Nguyen; +Cc: Git Mailing List
In-Reply-To: <CACsJy8CHWZyFgZu1=VKCQc+hbHUmZiAQ9ToL=NDF=YBEkLfbog@mail.gmail.com>
Duy Nguyen <pclouds@gmail.com> writes:
> On Thu, Nov 10, 2016 at 6:09 PM, Duy Nguyen <pclouds@gmail.com> wrote:
>> On Thu, Nov 10, 2016 at 3:12 AM, Junio C Hamano <gitster@pobox.com> wrote:
>>> Nguyễn Thái Ngọc Duy <pclouds@gmail.com> writes:
>>>
>>>> ---
>>>> v2 changes just the subject line
>>>
>>> That's not sufficient, is it? What you did in the documentation
>>> would raise the same "Hmph, is this only about HEAD?" and unlike the
>>> commit subject, it will carve it in stone for end-users.
>>
>> Oops. I forgot about git-rebase.txt. How about this?
>>
>> --forget::
>> Abort the rebase operation but leave HEAD, the index and
>> working tree untouched.
>
> Or, since --abort describes it as "reset HEAD to the original branch",
> we could write "Abort the rebase operation. Unlike --abort, HEAD is
> not restored back to the original branch". Index and worktree are
> implied by "not restored". Not sure if it's too subtle.
I think you are moving in the right direction, even though "Abort
it; unlike --abort, does this instead" is a bit hard to follow.
^ permalink raw reply
* Re: [PATCH v2] t6026-merge-attr: don't fail if sleep exits early
From: Junio C Hamano @ 2016-11-10 19:20 UTC (permalink / raw)
To: Andreas Schwab; +Cc: Jeff King, Johannes Schindelin, Johannes Sixt, git
In-Reply-To: <mvm8tsrbusp.fsf_-_@hawking.suse.de>
Andreas Schwab <schwab@suse.de> writes:
> Commit 5babb5bdb3 ("t6026-merge-attr: clean up background process at end
> of test case") added a kill command to clean up after the test, but this
> can fail if the sleep command exits before the cleanup is executed.
> Ignore the error from the kill command.
>
> Explicitly check for the existence of the pid file to test that the merge
> driver was actually called.
>
> Signed-off-by: Andreas Schwab <schwab@suse.de>
> ---
OK. sleep.pid is a reasonable easy-to-access side effect we can
observe to make sure that the sleep-one-second merge driver was
indeed invoked, which was missing from the earlier round.
Thanks, will apply.
> t/t6026-merge-attr.sh | 5 +++--
> 1 file changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/t/t6026-merge-attr.sh b/t/t6026-merge-attr.sh
> index 7a6e33e673..03d13d00b5 100755
> --- a/t/t6026-merge-attr.sh
> +++ b/t/t6026-merge-attr.sh
> @@ -187,13 +187,14 @@ test_expect_success 'custom merge does not lock index' '
> sleep 1 &
> echo $! >sleep.pid
> EOF
> - test_when_finished "kill \$(cat sleep.pid)" &&
> + test_when_finished "kill \$(cat sleep.pid) || :" &&
>
> test_write_lines >.gitattributes \
> "* merge=ours" "text merge=sleep-one-second" &&
> test_config merge.ours.driver true &&
> test_config merge.sleep-one-second.driver ./sleep-one-second.sh &&
> - git merge master
> + git merge master &&
> + test -f sleep.pid
> '
>
> test_done
> --
> 2.10.2
^ permalink raw reply
* [PATCHv3 00/35] Revamp the attr subsystem!
From: Stefan Beller @ 2016-11-10 20:33 UTC (permalink / raw)
To: gitster, bmwill, pclouds; +Cc: git, Stefan Beller
previous discussion: https://public-inbox.org/git/20161028185502.8789-1-sbeller@google.com/
Changes since v2:
* dropped one patch (that exposes git_attr_counted, nobody uses
it throughout the series )
* added pathspec guarding and added a test with git-add to see if it works.
* squashed "SQUASH" commits.
* changed test for multithreaded tests as git-status makes use of pathspec
code that doesn't support this new magic yet.
interdiff to currently queued at the bottom of this email.
v2 was:
previous discussion at https://public-inbox.org/git/20161022233225.8883-1-sbeller@google.com
This implements the discarded series':
jc/attr
jc/attr-more
sb/pathspec-label
sb/submodule-default-paths
This includes
* The fixes for windows
* Junios latest suggestion to use git_attr_check_initv instead of
alloc/append.
* I implemented the thread safe attr API in patch 27 (attr: convert to new threadsafe API)
* patch 28 (attr: keep attr stack for each check) makes it actually possible
to run in a multithreaded environment.
* I added a test for the multithreaded when it is introduced in patch 32
(pathspec: allow querying for attributes) as well as a test to disallow
multiple "attr"s in a pathspec.
Thanks,
Stefan
Junio C Hamano (23):
commit.c: use strchrnul() to scan for one line
attr.c: use strchrnul() to scan for one line
attr.c: update a stale comment on "struct match_attr"
attr.c: explain the lack of attr-name syntax check in parse_attr()
attr.c: complete a sentence in a comment
attr.c: mark where #if DEBUG ends more clearly
attr.c: simplify macroexpand_one()
attr.c: tighten constness around "git_attr" structure
attr.c: plug small leak in parse_attr_line()
attr: rename function and struct related to checking attributes
attr: (re)introduce git_check_attr() and struct git_attr_check
attr: convert git_all_attrs() to use "struct git_attr_check"
attr: convert git_check_attrs() callers to use the new API
attr: retire git_check_attrs() API
attr: add counted string version of git_check_attr()
attr: expose validity check for attribute names
attr.c: add push_stack() helper
attr.c: pass struct git_attr_check down the callchain
attr.c: rename a local variable check
attr.c: correct ugly hack for git_all_attrs()
attr.c: introduce empty_attr_check_elems()
attr.c: always pass check[] to collect_some_attrs()
attr.c: outline the future plans by heavily commenting
Nguyễn Thái Ngọc Duy (1):
attr: support quoting pathname patterns in C style
Stefan Beller (11):
attr: make git_check_attr_counted static
attr: convert to new threadsafe API
attr: keep attr stack for each check
Documentation: fix a typo
pathspec: move long magic parsing out of prefix_pathspec
pathspec: move prefix check out of the inner loop
pathspec: allow querying for attributes
pathspec: allow escaped query values
submodule update: add `--init-default-path` switch
clone: add --init-submodule=<pathspec> switch
completion: clone can initialize specific submodules
Documentation/config.txt | 5 +
Documentation/git-clone.txt | 23 +-
Documentation/git-submodule.txt | 17 +-
Documentation/gitattributes.txt | 10 +-
Documentation/glossary-content.txt | 20 +
Documentation/technical/api-gitattributes.txt | 140 ++++---
archive.c | 25 +-
attr.c | 517 ++++++++++++++++++--------
attr.h | 71 ++--
builtin/check-attr.c | 74 ++--
builtin/clone.c | 36 +-
builtin/pack-objects.c | 27 +-
commit.c | 3 +-
common-main.c | 2 +
contrib/completion/git-completion.bash | 1 +
convert.c | 46 ++-
dir.c | 41 +-
git-submodule.sh | 21 +-
hashmap.h | 2 +
ll-merge.c | 35 +-
pathspec.c | 228 ++++++++++--
pathspec.h | 19 +-
t/t0003-attributes.sh | 26 ++
t/t6134-pathspec-with-labels.sh | 201 ++++++++++
t/t7400-submodule-basic.sh | 134 +++++++
userdiff.c | 21 +-
ws.c | 19 +-
27 files changed, 1354 insertions(+), 410 deletions(-)
create mode 100755 t/t6134-pathspec-with-labels.sh
-- interdiff to current origin/sb/attr:
diff --git a/attr.c b/attr.c
index cf15e76..979bd3c 100644
--- a/attr.c
+++ b/attr.c
@@ -135,7 +135,7 @@ static void report_invalid_attr(const char *name, size_t len,
strbuf_release(&err);
}
-struct git_attr *git_attr_counted(const char *name, size_t len)
+static struct git_attr *git_attr_internal(const char *name, int len)
{
unsigned hval = hash_name(name, len);
unsigned pos = hval % HASHSIZE;
@@ -171,7 +171,7 @@ struct git_attr *git_attr_counted(const char *name, size_t len)
struct git_attr *git_attr(const char *name)
{
- return git_attr_counted(name, strlen(name));
+ return git_attr_internal(name, strlen(name));
}
/* What does a matched pattern decide? */
@@ -259,7 +259,7 @@ static const char *parse_attr(const char *src, int lineno, const char *cp,
else {
e->setto = xmemdupz(equals + 1, ep - equals - 1);
}
- e->attr = git_attr_counted(cp, len);
+ e->attr = git_attr_internal(cp, len);
}
return ep + strspn(ep, blank);
}
@@ -320,7 +320,7 @@ static struct match_attr *parse_attr_line(const char *line, const char *src,
sizeof(struct attr_state) * num_attr +
(is_macro ? 0 : namelen + 1));
if (is_macro) {
- res->u.attr = git_attr_counted(name, namelen);
+ res->u.attr = git_attr_internal(name, namelen);
res->u.attr->maybe_macro = 1;
} else {
char *p = (char *)&(res->state[num_attr]);
diff --git a/attr.h b/attr.h
index e7534da..ab381ae 100644
--- a/attr.h
+++ b/attr.h
@@ -2,7 +2,7 @@
#define ATTR_H
/*
- * Must be called on platforms that do not support static initialisation
+ * Must be called on platforms that do not support static initialization
* of mutexes.
*/
extern void attr_start(void);
diff --git a/dir.c b/dir.c
index 3ec9117..c56d2ee 100644
--- a/dir.c
+++ b/dir.c
@@ -140,7 +140,8 @@ static size_t common_prefix_len(const struct pathspec *pathspec)
PATHSPEC_LITERAL |
PATHSPEC_GLOB |
PATHSPEC_ICASE |
- PATHSPEC_EXCLUDE);
+ PATHSPEC_EXCLUDE |
+ PATHSPEC_ATTR);
for (n = 0; n < pathspec->nr; n++) {
size_t i = 0, len = 0, item_len;
@@ -349,7 +350,8 @@ static int do_match_pathspec(const struct pathspec *ps,
PATHSPEC_LITERAL |
PATHSPEC_GLOB |
PATHSPEC_ICASE |
- PATHSPEC_EXCLUDE);
+ PATHSPEC_EXCLUDE |
+ PATHSPEC_ATTR);
if (!ps->nr) {
if (!ps->recursive ||
diff --git a/pathspec.c b/pathspec.c
index 8ea5dcb..d702803 100644
--- a/pathspec.c
+++ b/pathspec.c
@@ -232,6 +232,7 @@ static void eat_long_magic(struct pathspec_item *item, const char *elt,
char *attr_body = xmemdupz(body, len - strlen("attr:"));
parse_pathspec_attr_match(item, attr_body);
free(attr_body);
+ *magic |= PATHSPEC_ATTR;
continue;
}
diff --git a/pathspec.h b/pathspec.h
index ebef4bf..c2d046d 100644
--- a/pathspec.h
+++ b/pathspec.h
@@ -8,13 +8,15 @@
#define PATHSPEC_GLOB (1<<3)
#define PATHSPEC_ICASE (1<<4)
#define PATHSPEC_EXCLUDE (1<<5)
+#define PATHSPEC_ATTR (1<<6)
#define PATHSPEC_ALL_MAGIC \
(PATHSPEC_FROMTOP | \
PATHSPEC_MAXDEPTH | \
PATHSPEC_LITERAL | \
PATHSPEC_GLOB | \
PATHSPEC_ICASE | \
- PATHSPEC_EXCLUDE)
+ PATHSPEC_EXCLUDE | \
+ PATHSPEC_ATTR)
#define PATHSPEC_ONESTAR 1 /* the pathspec pattern satisfies GFNM_ONESTAR */
diff --git a/t/t6134-pathspec-with-labels.sh b/t/t6134-pathspec-with-labels.sh
index 3d03e0a..5aafc0c 100755
--- a/t/t6134-pathspec-with-labels.sh
+++ b/t/t6134-pathspec-with-labels.sh
@@ -160,7 +160,23 @@ test_expect_success 'fail on multiple attr specifiers in one pathspec item' '
'
test_expect_success 'checking attributes in a multithreaded process' '
- git status ":(attr:labelB)"
+ cat <<-EOF >expect &&
+ fileA:A
+ EOF
+ echo A >fileA &&
+ echo A >fileB &&
+ git grep A -- ":(attr:labelA)" >actual &&
+ test_cmp expect actual
+'
+
+test_expect_success 'fail if attr magic is used places not implemented' '
+ # The main purpose of this test is to check that we actually fail
+ # when you attempt to use attr magic in commands that do not implement
+ # attr magic. This test does not advocate git-add to stay that way,
+ # though, but git-add is convenient as it has its own internal pathspec
+ # parsing.
+ test_must_fail git add ":(attr:labelB)" 2>actual &&
+ test_i18ngrep "unsupported magic" actual
'
test_expect_success 'abort on giving invalid label on the command line' '
--
2.10.1.469.g00a8914
^ permalink raw reply related
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