* Re: What's cooking in git.git (Nov 2016, #06; Mon, 28)
From: Brandon Williams @ 2016-11-29 1:05 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <xmqqk2bngn03.fsf@gitster.mtv.corp.google.com>
On 11/28, Junio C Hamano wrote:
> * bw/grep-recurse-submodules (2016-11-22) 6 commits
> - grep: search history of moved submodules
> - grep: enable recurse-submodules to work on <tree> objects
> - grep: optionally recurse into submodules
> - grep: add submodules as a grep source type
> - submodules: load gitmodules file from commit sha1
> - submodules: add helper functions to determine presence of submodules
>
> "git grep" learns to optionally recurse into submodules
>
> Has anybody else seen t7814 being flakey with this series?
Which tests in particular are you seeing issues with? I can't see any
issues running it locally.
--
Brandon Williams
^ permalink raw reply
* [ANNOUNCE] git-cinnabar 0.4.0 release candidate
From: Mike Hommey @ 2016-11-29 0:22 UTC (permalink / raw)
To: git
Hi,
Git-cinnabar is a git remote helper to interact with mercurial
repositories. It allows to clone, pull and push from/to mercurial remote
repositories, using git.
Code on https://github.com/glandium/git-cinnabar
This release on
https://github.com/glandium/git-cinnabar/releases/tag/0.4.0rc
[ Previous announcements:
http://marc.info/?l=git&m=146943537220142
http://marc.info/?l=git&m=146762932928309
http://marc.info/?l=git&m=146179749105388 (...)]
What's new since 0.4.0b3?
- Updated git to 2.10.2 for cinnabar-helper.
- Added a new `git cinnabar download` command to download a helper on
platforms where one is available.
- Fixed some corner cases with pack windows in the helper. This prevented
cloning mozilla-central with the helper.
- Fixed bundle2 support that broke cloning from a mercurial 4.0 server in
some cases.
- Fixed some corner cases involving empty files. This prevented cloning
Mozilla's stylo incubator repository.
- Fixed some correctness issues in file parenting when pushing changesets
pulled from one mercurial repository to another.
- Various improvements to the rules to build the helper.
- Experimental (and slow) support for pushing merges, with caveats. See
https://github.com/glandium/git-cinnabar/issues/20 for details about
the current status.
And since I realize I didn't announce beta 3:
What's new since 0.4.0b2?
- Properly handle bundle2 errors, avoiding git to believe a push
happened when it didn't. (0.3.x is unaffected)
Mike
^ permalink raw reply
* Re: cherry-pick -Xrenormalize fails with formerly CRLF files
From: Eevee (Lexy Munroe) @ 2016-11-29 0:27 UTC (permalink / raw)
To: Torsten Bögershausen; +Cc: git
In-Reply-To: <20161128155415.GA9966@tb-raspi>
On 11/28/2016 07:54 AM, Torsten Bögershausen wrote:
> On Sun, Nov 27, 2016 at 10:19:35PM -0800, Eevee (Lexy Munroe) wrote:
>> I'm working with a repo that used to be all CRLF. At some point it
>> was changed to all LF, with `text=auto` in .gitattributes for the
>> sake of Windows devs. I'm on Linux and have never touched any
>> twiddles relating to line endings. I'm trying to cherry-pick some
>> commits from before the switchover.
>>
>> Straightforward cherry-picking causes entire files at a time to
>> conflict, which I've seen before when switching from tabs to spaces.
>> So I tried -Xrenormalize and got:
>>
>> fatal: CRLF would be replaced by LF in [path]
>>
>
> Which version of Git are you using, what does
> git --version
> say?
Oh, sorry. 2.10.2, but I also tried building next (c8190e7) with the
same result.
>> The error comes from check_safe_crlf, which warns if checksafe is
>> CRLF_SAFE_WARN and dies if it's (presumably) CRLF_SAFE_FAIL. The
>> funny thing is that it's CRLF_SAFE_RENORMALIZE.
>>
>> I don't know what the semantics of this value are, but the caller
>> (crlf_to_git) explicitly checks for CRLF_SAFE_RENORMALIZE and
>> changes it to CRLF_SAFE_FALSE instead. But that check only happens
>> if crlf_action is CRLF_AUTO*, and for me it's CRLF_TEXT_INPUT.
>>
>> I moved the check to happen regardless of the value of crlf_action,
>> and at least in this case, git appears to happily do the right
>> thing. So I think this is a bug, but line endings are such a tangle
>> that I'm really not sure. :)
>>
> I am not sure either.
> Could you send me the diff you made ?
> git diff
>
> I am happy to look into it, (in the amount of time I have).
It's pretty straightforward:
diff --git a/convert.c b/convert.c
index be91358..f9ff6a5 100644
--- a/convert.c
+++ b/convert.c
@@ -275,6 +275,8 @@ static int crlf_to_git(const char *path, const char
*src, size_t len,
/* Optimization: No CRLF? Nothing to convert, regardless. */
convert_crlf_into_lf = !!stats.crlf;
+ if (checksafe == SAFE_CRLF_RENORMALIZE)
+ checksafe = SAFE_CRLF_FALSE;
if (crlf_action == CRLF_AUTO || crlf_action == CRLF_AUTO_INPUT
|| crlf_action == CRLF_AUTO_CRLF) {
if (convert_is_binary(len, &stats))
return 0;
(The new lines are copied from the block immediately following, just
past where the context ends.)
>> The repository in question is ZDoom: https://github.com/rheit/zdoom
>> I'm trying to cherry-pick commits from the 3dfloors3 branch (e.g.,
>> 9fb2daf58e9d512170859302a1ac0ea9c2ec5993) onto a slightly outdated
>> master, 6384e81d0f135a2c292ac3e874f6fe26093f45b1.
>
> This is what I tried:
>
> ...
>
> The patch did not apply, but for different reasons.
>
> Could you send us, what exactly you did, to help me out ?
I did notice it works when there's a conflict, but I thought I
specifically named a commit that applied cleanly. Apparently not,
sorry. Try ddba3dd325054e71d48634cb19708cb7bcd8f20b:
eevee@perushian ~/dev-foreign/zdoom.git/src ⚘ git checkout -b
git-renormalize-test 6384e81d0f135a2c292ac3e874f6fe26093f45b1
Switched to a new branch 'git-renormalize-test'
eevee@perushian ~/dev-foreign/zdoom.git/src ⚘ git cherry-pick
-Xrenormalize ddba3dd325054e71d48634cb19708cb7bcd8f20b
fatal: CRLF would be replaced by LF in src/r_plane.cpp.
^ permalink raw reply related
* What's cooking in git.git (Nov 2016, #06; Mon, 28)
From: Junio C Hamano @ 2016-11-29 0:15 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.
You can find the changes described here in the integration branches
of the repositories listed at
http://git-blame.blogspot.com/p/git-public-repositories.html
--------------------------------------------------
[New Topics]
* jc/renormalize-merge-kill-safer-crlf (2016-11-28) 2 commits
- merge-recursive: handle NULL in add_cacheinfo() correctly
- cherry-pick: demonstrate a segmentation fault
Fix a corner case in merge-recursive regression that crept in
during 2.10 development cycle.
Will merge to 'next'.
* js/difftool-builtin (2016-11-28) 2 commits
- difftool: implement the functionality in the builtin
- difftool: add a skeleton for the upcoming builtin
Rewrite a scripted porcelain "git difftool" in C.
Under discussion.
* nd/qsort-in-merge-recursive (2016-11-28) 1 commit
- merge-recursive.c: use string_list_sort instead of qsort
Code simplification.
Will merge to 'next'.
--------------------------------------------------
[Stalled]
* jc/retire-compaction-heuristics (2016-11-02) 3 commits
- SQUASH???
- SQUASH???
- diff: retire the original experimental "compaction" heuristics
Waiting for a reroll.
* jc/abbrev-autoscale-config (2016-11-01) 1 commit
- config.abbrev: document the new default that auto-scales
Waiting for a reroll.
* 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
As we do not follow symbolic links when reading control files like
.gitignore and .gitattributes from the index, match the behaviour
and not follow symbolic links when reading them from the working
tree. This also tightens security a bit by not leaking contents of
an unrelated file in the error messages when it is pointed at by
one of these files that is a symbolic link.
Perhaps we want to cover .gitmodules too with the same mechanism?
* nd/worktree-move (2016-11-28) 11 commits
. worktree remove: new command
. worktree move: refuse to move worktrees with submodules
. worktree move: accept destination as directory
. worktree move: new command
. worktree.c: add update_worktree_location()
. worktree.c: add validate_worktree()
. copy.c: convert copy_file() to copy_dir_recursively()
. copy.c: style fix
. copy.c: convert bb_(p)error_msg to error(_errno)
. copy.c: delete unused code in copy_file()
. copy.c: import copy_file() from busybox
(this branch uses nd/worktree-list-fixup.)
"git worktree" learned move and remove subcommands.
Reported to break builds on Windows.
* 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.
* 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]
* bw/push-dry-run (2016-11-23) 2 commits
- push: fix --dry-run to not push submodules
- push: --dry-run updates submodules when --recurse-submodules=on-demand
(this branch uses hv/submodule-not-yet-pushed-fix.)
"git push --dry-run --recurse-submodule=on-demand" wasn't
"--dry-run" in the submodules.
Will merge to 'next'.
* 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.
Need to rebase on hv/submodule-not-yet-pushed-fix and then consider
merging to 'next'.
* jk/rev-parse-symbolic-parents-fix (2016-11-16) 1 commit
- rev-parse: fix parent shorthands with --symbolic
"git rev-parse --symbolic" failed with a more recent notation like
"HEAD^-1" and "HEAD^!".
Will merge to 'next'.
* nd/worktree-list-fixup (2016-11-28) 5 commits
- worktree list: keep the list sorted
- worktree.c: get_worktrees() takes a new flag argument
- get_worktrees() must return main worktree as first item even on error
- worktree: reorder an if statement
- worktree.c: zero new 'struct worktree' on allocation
(this branch is used by nd/worktree-move.)
The output from "git worktree list" was made in readdir() order,
and was unstable.
Will merge to 'next'.
* jk/trailers-placeholder-in-pretty (2016-11-21) 2 commits
- ref-filter: add support to display trailers as part of contents
- pretty: add %(trailers) format for displaying trailers of a commit message
In addition to %(subject), %(body), "log --pretty=format:..."
learned a new placeholder %(trailers).
Will merge to 'next'.
* sb/submodule-intern-gitdir (2016-11-22) 5 commits
- SQUASH
- submodule: add embed-git-dir function
- test-lib-functions.sh: teach test_commit -C <dir>
- submodule helper: support super prefix
- submodule: use absolute path for computing relative path connecting
A new submodule helper "git submodule embedgitdirs" to make it
easier to move embedded .git/ directory for submodules in a
superproject to .git/modules/ (and point the latter with the former
that is turned into a "gitdir:" file) has been added.
Need to read it over again, deal with SQUASH, and may ask for a
reroll.
* dt/empty-submodule-in-merge (2016-11-17) 1 commit
- submodules: allow empty working-tree dirs in merge/cherry-pick
An empty directory in a working tree that can simply be nuked used
to interfere while merging or cherry-picking a change to create a
submodule directory there, which has been fixed..
Waiting for review.
* bw/grep-recurse-submodules (2016-11-22) 6 commits
- grep: search history of moved submodules
- grep: enable recurse-submodules to work on <tree> objects
- grep: optionally recurse into submodules
- grep: add submodules as a grep source type
- submodules: load gitmodules file from commit sha1
- submodules: add helper functions to determine presence of submodules
"git grep" learns to optionally recurse into submodules
Has anybody else seen t7814 being flakey with this series?
* dt/smart-http-detect-server-going-away (2016-11-18) 2 commits
(merged to 'next' on 2016-11-21 at d502523347)
+ upload-pack: optionally allow fetching any sha1
+ remote-curl: don't hang when a server dies before any output
When the http server gives an incomplete response to a smart-http
rpc call, it could lead to client waiting for a full response that
will never come. Teach the client side to notice this condition
and abort the transfer.
An improvement counterproposal has failed.
cf. <20161114194049.mktpsvgdhex2f4zv@sigill.intra.peff.net>
Will cook in 'next'.
* mm/push-social-engineering-attack-doc (2016-11-14) 1 commit
(merged to 'next' on 2016-11-16 at b7c1b27563)
+ doc: mention transfer data leaks in more places
Doc update on fetching and pushing.
Will cook in 'next'.
* jc/compression-config (2016-11-15) 1 commit
(merged to 'next' on 2016-11-23 at b3c9254897)
+ compression: unify pack.compression configuration parsing
Compression setting for producing packfiles were spread across
three codepaths, one of which did not honor any configuration.
Unify these so that all of them honor core.compression and
pack.compression variables the same way.
Will cook in 'next'.
* mm/gc-safety-doc (2016-11-16) 1 commit
(merged to 'next' on 2016-11-17 at fc0d225b6b)
+ git-gc.txt: expand discussion of races with other processes
Doc update.
Will cook in 'next'.
* hv/submodule-not-yet-pushed-fix (2016-11-16) 4 commits
(merged to 'next' on 2016-11-21 at 1a599af962)
+ submodule_needs_pushing(): explain the behaviour when we cannot answer
+ batch check whether submodule needs pushing into one call
+ serialize collection of refs that contain submodule changes
+ serialize collection of changed submodules
(this branch is used by bw/push-dry-run.)
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.
Will cook in 'next'.
* kn/ref-filter-branch-list (2016-11-15) 18 commits
- for-each-ref: do not segv with %(HEAD) on an unborn branch
- 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, reviewed, looking good.
Expecting a reroll.
cf. <20161108201211.25213-1-Karthik.188@gmail.com>
cf. <CAOLa=ZQqe3vEj_428d41vd_4kfjzsm87Wam6Zm2dhXWkPdJ8Rw@mail.gmail.com>
cf. <xmqq7f84tqa7.fsf_-_@gitster.mtv.corp.google.com>
* bw/transport-protocol-policy (2016-11-09) 2 commits
(merged to 'next' on 2016-11-16 at 1391d3eeed)
+ transport: add protocol policy config option
+ lib-proto-disable: variable name fix
Finer-grained control of what protocols are allowed for transports
during clone/fetch/push have been enabled via a new configuration
mechanism.
Will cook in 'next'.
* jt/fetch-no-redundant-tag-fetch-map (2016-11-11) 1 commit
(merged to 'next' on 2016-11-16 at 5846c27cc5)
+ fetch: do not redundantly calculate tag refmap
Code cleanup to avoid using redundant refspecs while fetching with
the --tags option.
Will cook in 'next'.
* sb/submodule-config-cleanup (2016-11-22) 3 commits
(merged to 'next' on 2016-11-23 at c02e578b49)
+ submodule-config: clarify parsing of null_sha1 element
+ submodule-config: rename commit_sha1 to treeish_name
+ submodule config: inline config_from_{name, path}
Minor code clean-up.
Will cook in 'next'.
* 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 cook in 'next'.
* 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".
Will merge to 'next' after dealing with the SQUASH???
* nd/rebase-forget (2016-11-28) 1 commit
- rebase: add --forget to cleanup rebase, leave everything else 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".
Will merge to 'next'.
* 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.
Will discard.
This may not be needed, given that update-index has a similar
option.
* 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.
Will discard.
The whole premise feels wrong.
* 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.
Will discard.
Retracted.
cf. <20161102071646.GA5094@tb-raspi>
* 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-11) 35 commits
- completion: clone can initialize specific submodules
- clone: add --init-submodule=<pathspec> 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
- 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_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-11-11) 16 commits
- i18n: difftool: mark warnings for translation
- i18n: send-email: mark composing message 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
- Git.pm: add subroutines for commenting lines
Porcelain scripts written in Perl are getting internationalized.
Waiting for review.
* 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 cook in 'next'.
* 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.
Will cook in 'next'.
^ permalink raw reply
* Re: What's cooking in git.git (Nov 2016, #05; Wed, 23)
From: Junio C Hamano @ 2016-11-29 0:06 UTC (permalink / raw)
To: Jonathan Tan; +Cc: git, Stefan Beller
In-Reply-To: <732c0e78-74b5-befa-e3c5-5ed9f221fa3a@google.com>
Jonathan Tan <jonathantanmy@google.com> writes:
> On 11/23/2016 03:21 PM, Junio C Hamano wrote:
>> * 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".
>>
>> What's the doneness of this topic?
>
> Stefan Beller mentioned [1] that this seemed OK to him from a cursory
> read. Do I need to look for another reviewer (or a more thorough
> review)?
I gave it a cursory review when it was queued, too, so another
cursory read does not help very much ;) If I recall correctly, I
got an impression that it was reasonably well done.
I haven't had a chance to look at the series again to see if the
SQUASH is just the simple matter of squashing it into the one
previous, which is the main reason why I haven't decided if it is
ready to be in 'next'.
Thanks.
^ permalink raw reply
* Re: What's cooking in git.git (Nov 2016, #05; Wed, 23)
From: Jonathan Tan @ 2016-11-29 0:01 UTC (permalink / raw)
To: Junio C Hamano, git; +Cc: Stefan Beller
In-Reply-To: <xmqqk2btlr3x.fsf@gitster.mtv.corp.google.com>
On 11/23/2016 03:21 PM, Junio C Hamano wrote:
> * 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".
>
> What's the doneness of this topic?
Stefan Beller mentioned [1] that this seemed OK to him from a cursory
read. Do I need to look for another reviewer (or a more thorough review)?
[1] <CAGZ79kY8AUwOYAQX=PEHU3H+AhLAuxtC9+hb42da6TrSdz4BzA@mail.gmail.com>
^ permalink raw reply
* Re: [PATCH] Release note spelling and phrasing fixups.
From: Junio C Hamano @ 2016-11-28 23:56 UTC (permalink / raw)
To: Marc Branchaud; +Cc: git
In-Reply-To: <20161124165900.30605-1-marcnarc@xiplink.com>
Marc Branchaud <marcnarc@xiplink.com> writes:
> Signed-off-by: Marc Branchaud <marcnarc@xiplink.com>
> ---
>
> Mostly just missing words and what I feel are clarifications.
>
> The biggest change is to the "git add -N" item. Not 100% sure
> I got it right.
>
> M.
> - * When new paths were added by "git add -N" to the index, it was
> - enough to circumvent the check by "git commit" to refrain from
> - making an empty commit without "--allow-empty". The same logic
> - prevented "git status" to show such a path as "new file" in the
> + * "git commit" created an empty commit when invoked with an index
> + consisting solely of intend-to-add paths (added with "git add -N").
> + It now requires the "--allow-empty" option to create such a commit.
> + The same logic prevented "git status" from showing such paths as "new files" in the
> "Changes not staged for commit" section.
Yes this is much easier to read. Greatly appreciated.
> * Codepaths that read from an on-disk loose object were too loose in
> - validating what they are reading is a proper object file and
> + validating that they are reading a proper object file and
> sometimes read past the data they read from the disk, which has
> been corrected. H/t to Gustavo Grieco for reporting.
> ...
> - * An author name, that spelled a backslash-quoted double quote in the
> - human readable part "My \"double quoted\" name", was not unquoted
> + * An author name that has a backslash-quoted double quote in the
> + human readable part ("My \"double quoted\" name"), was not unquoted
> correctly while applying a patch from a piece of e-mail.
> ...
> - * It is a common mistake to say "git blame --reverse OLD path",
> - expecting that the command line is dwimmed as if asking how lines
> + * "git blame --reverse OLD path" is now DWIMmed to show how lines
> in path in an old revision OLD have survived up to the current
> commit.
> (merge e1d09701a4 jc/blame-reverse later to maint).
> ...
> * The "submodule.<name>.path" stored in .gitmodules is never copied
> to .git/config and such a key in .git/config has no meaning, but
> - the documentation described it and submodule.<name>.url next to
> - each other as if both belong to .git/config. This has been fixed.
> + the documentation described it next to submodule.<name>.url
> + as if both belong to .git/config. This has been fixed.
These, too.
> - * In a worktree connected to a repository elsewhere, created via "git
> + * In a worktree created via "git
> worktree", "git checkout" attempts to protect users from confusion
> by refusing to check out a branch that is already checked out in
> another worktree. However, this also prevented checking out a
> - branch, which is designated as the primary branch of a bare
> + branch which is designated as the primary branch of a bare
> reopsitory, in a worktree that is connected to the bare
> repository. The check has been corrected to allow it.
This 'reopsitory' may already have been fixed ;-)
... goes and looks ...
Oops, no it hasn't. I'll patch it up while queuing this.
> - * A hot-fix for a test added by a recent topic that went to both
> + * Hot-fixed a test added by a recent topic that went to both
> 'master' and 'maint' already.
Oops; an entry like this shouldn't have been in the release notes in
the first place, because those who are seeing the released versions
would have never seen such breakages. Will try to remember removing
it.
Thanks, I missed this one completely even though you sent it out
last week and didn't have a chance to read it over before starting
today's integration cycle.
^ permalink raw reply
* Re: [PATCH] diff: handle --no-abbrev outside of repository
From: Junio C Hamano @ 2016-11-28 23:03 UTC (permalink / raw)
To: Jack Bates; +Cc: git, Jack Bates
In-Reply-To: <20161128182508.10570-1-jack@nottheoilrig.com>
Jack Bates <bk874k@nottheoilrig.com> writes:
> The "git diff --no-index" codepath doesn't handle the --no-abbrev
> option.
>
> Signed-off-by: Jack Bates <jack@nottheoilrig.com>
> ---
This patch also needs a new test to protect the fix from future
breakages.
It is unfortunate that parsing of these options that are done in
diff_opt_parse() are not used by most of the codepaths; they instead
rely on revision.c parser to parse them into revs->abbrev and then
copied to revs->diffopt.abbrev in setup_revisions(). We would want
to rethink the structure of the code around this, and possibly move
towards using setup_revisions() more when appropriate and removing
diff_opt_parse() or something like that; the three-way fallback
codepath in builtin/am.c is the only other caller of this function
and it uses it to parse a fixed "--diff-filter=AM" option into
rev_info.diffopt and manually sets up rev_info as if revision parser
was given "diff --cached HEAD", which we should be able to replace
with a call to setup_revisions() of "--diff-filter=AM --cached HEAD",
I would suspect. But that is a much larger change.
In any case, for now, the fix in this patch is a single best step
that moves us forward.
Thanks.
> diff.c | 5 ++++-
> 1 file changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/diff.c b/diff.c
> index ec87283..0447eff 100644
> --- a/diff.c
> +++ b/diff.c
> @@ -3106,7 +3106,8 @@ static const char *diff_abbrev_oid(const struct object_id *oid, int abbrev)
> abbrev = FALLBACK_DEFAULT_ABBREV;
> if (abbrev > GIT_SHA1_HEXSZ)
> die("BUG: oid abbreviation out of range: %d", abbrev);
> - hex[abbrev] = '\0';
> + if (abbrev)
> + hex[abbrev] = '\0';
> return hex;
> }
> }
> @@ -4024,6 +4025,8 @@ int diff_opt_parse(struct diff_options *options,
> offending, optarg);
> return argcount;
> }
> + else if (!strcmp(arg, "--no-abbrev"))
> + options->abbrev = 0;
> else if (!strcmp(arg, "--abbrev"))
> options->abbrev = DEFAULT_ABBREV;
> else if (skip_prefix(arg, "--abbrev=", &arg)) {
^ permalink raw reply
* Re: [PATCH 31/35] pathspec: allow querying for attributes
From: Brandon Williams @ 2016-11-28 22:11 UTC (permalink / raw)
To: Stefan Beller; +Cc: gitster, pclouds, git
In-Reply-To: <20161110203428.30512-32-sbeller@google.com>
On 11/10, Stefan Beller wrote:
> @@ -500,6 +586,18 @@ void copy_pathspec(struct pathspec *dst, const struct pathspec *src)
>
> void clear_pathspec(struct pathspec *pathspec)
> {
> + int i, j;
> + for (i = 0; i < pathspec->nr; i++) {
> + if (!pathspec->items[i].attr_match_nr)
> + continue;
> + for (j = 0; j < pathspec->items[j].attr_match_nr; j++)
> + free(pathspec->items[i].attr_match[j].value);
> + free(pathspec->items[i].attr_match);
> + if (pathspec->items[i].attr_check)
> + git_attr_check_clear(pathspec->items[i].attr_check);
> + free(pathspec->items[i].attr_check);
> + }
> +
> free(pathspec->items);
> pathspec->items = NULL;
You may also want to add logic like this to the 'copy_pathspec' function
so that when a pathspec struct is copied, the destination also has
ownership of its own attribute items.
--
Brandon Williams
^ permalink raw reply
* [GIT PULL] l10n updates for 2.11.0 round 3
From: Jiang Xin @ 2016-11-28 21:56 UTC (permalink / raw)
To: Junio C Hamano
Cc: Git List, Changwoo Ryu, Dimitriy Ryazantcev, Jean-Noel Avila,
Jiang Xin, Peter Krefting, Ralf Thielow, Tran Ngoc Quan,
Vasco Almeida, jfbu
Hi Junio,
The following changes since commit e2b2d6a172b76d44cb7b1ddb12ea5bfac9613a44:
Git 2.11-rc3 (2016-11-23 11:24:59 -0800)
are available in the git repository at:
git://github.com/git-l10n/git-po tags/l10n-2.11.0-rnd3
for you to fetch changes up to 6366c34b895613482fa32f1abe1c3ca043905ad2:
l10n: de.po: translate 210 new messages (2016-11-28 18:49:25 +0100)
----------------------------------------------------------------
l10n-2.11.0-rnd3
----------------------------------------------------------------
Jiang Xin (1):
l10n: fix unmatched single quote in error message
Ralf Thielow (1):
l10n: de.po: translate 210 new messages
po/de.po | 9112 +++++++++++++++++++++++++++++++++--------------------------
po/fr.po | 6 +-
po/git.pot | 128 +-
po/ko.po | 6 +-
po/pt_PT.po | 6 +-
po/sv.po | 6 +-
po/vi.po | 6 +-
po/zh_CN.po | 6 +-
8 files changed, 5125 insertions(+), 4151 deletions(-)
--
Jiang Xin
^ permalink raw reply
* Re: RFC: Enable delayed responses to Git clean/smudge filter requests
From: Junio C Hamano @ 2016-11-28 21:48 UTC (permalink / raw)
To: Lars Schneider; +Cc: Eric Wong, git
In-Reply-To: <249EE7A4-F297-4537-92A9-0EF75A3B1AEE@gmail.com>
Lars Schneider <larsxschneider@gmail.com> writes:
> What way do you think is better from a maintenance point of view?
> I prefer option 2 but I fear that these "special" values could confuse
> future readers of the code.
I recall getting confused by the redefinition of the meaning of
return value from the grep_directory() function when we started
threading the working-tree grep codepath at around 5b594f457a;
compared to that, as long as the "special" (and "normal") values are
made symbolic constants, I do not think it is too bad.
^ permalink raw reply
* Re: [PATCH v2 0/5] nd/worktree-list-fixup
From: Junio C Hamano @ 2016-11-28 21:25 UTC (permalink / raw)
To: Nguyễn Thái Ngọc Duy; +Cc: git, rappazzo
In-Reply-To: <20161128093656.15744-1-pclouds@gmail.com>
Nguyễn Thái Ngọc Duy <pclouds@gmail.com> writes:
> This version
>
> * changes get_worktrees() to take a flag, and adds one flag for
> sorting.
>
> * adds tests for both the 'main worktree always present' and the
> sorting problems.
>
> * reworks 3/5 a bit, keep changes closer, easier to see the cause and
> consequence.
>
> Nguyễn Thái Ngọc Duy (5):
> worktree.c: zero new 'struct worktree' on allocation
> worktree: reorder an if statement
> get_worktrees() must return main worktree as first item even on error
> worktree.c: get_worktrees() takes a new flag argument
> worktree list: keep the list sorted
>
> branch.c | 2 +-
> builtin/branch.c | 2 +-
> builtin/worktree.c | 14 ++++++++------
> t/t2027-worktree-list.sh | 40 ++++++++++++++++++++++++++++++++++++++++
> worktree.c | 42 +++++++++++++++++++++---------------------
> worktree.h | 4 +++-
> 6 files changed, 74 insertions(+), 30 deletions(-)
Thanks for a pleasant read. Will replace what has been queued.
^ permalink raw reply
* Re: [PATCH v2 00/11] git worktree (re)move
From: Johannes Sixt @ 2016-11-28 21:25 UTC (permalink / raw)
To: Junio C Hamano, Nguyễn Thái Ngọc Duy
Cc: Johannes Schindelin, git
In-Reply-To: <xmqqshqbicga.fsf@gitster.mtv.corp.google.com>
Am 28.11.2016 um 21:20 schrieb Junio C Hamano:
> Junio C Hamano <gitster@pobox.com> writes:
>
>> Does this round address the issue raised in
>>
>> http://public-inbox.org/git/alpine.DEB.2.20.1611161041040.3746@virtualbox
>>
>> by Dscho?
>>
>> Even if you are not tracking a fifo, for example, your working tree
>> may have one created in t/trash* directory during testing, and
>> letting platform "cp -r" taking care of it (if that is possible---I
>> didn't look at the code that calls busybox copy to see if you are
>> doing something exotic or just blindly copying everything in the
>> directory) may turn out to be a more portable way to do this, and I
>> suspect that the cost of copying one whole-tree would dominate the
>> run_command() overhead.
>
> Please do not take the above as me saying "you must spawn the
> platform cp -r".
copy_dir_recursively is used in 'worktree move' when the move is across
file systems. My stance on it is to punt in this case. *I* would not
trust Git, or any other program that is not *specifically* made to copy
a whole directory structure, to get all cases right when a simple
rename() is not sufficent. And, uh, oh, it does a
remove_dir_recursively() after it has finshed copying. No, Git is not a
tool to move directories, thank you very much!
-- Hannes
^ permalink raw reply
* Partial fetch?
From: Dāvis Mosāns @ 2016-11-28 20:34 UTC (permalink / raw)
To: git
I'm trying to fetch a remote repository over https but sadly it
timeouts too soon.
$ git fetch -v upstream
POST git-upload-pack (gzip 1148 to 641 bytes)
POST git-upload-pack (gzip 1148 to 644 bytes)
POST git-upload-pack (gzip 1948 to 1038 bytes)
POST git-upload-pack (gzip 3548 to 1845 bytes)
POST git-upload-pack (gzip 6748 to 3431 bytes)
POST git-upload-pack (gzip 13148 to 6659 bytes)
POST git-upload-pack (gzip 25948 to 13084 bytes)
POST git-upload-pack (gzip 51548 to 25997 bytes)
POST git-upload-pack (gzip 102748 to 51375 bytes)
POST git-upload-pack (gzip 205148 to 101973 bytes)
POST git-upload-pack (gzip 409948 to 203200 bytes)
POST git-upload-pack (gzip 82248 to 41185 bytes)
POST git-upload-pack (gzip 90448 to 45257 bytes)
POST git-upload-pack (gzip 99448 to 49719 bytes)
POST git-upload-pack (gzip 109348 to 54623 bytes)
POST git-upload-pack (gzip 120248 to 59937 bytes)
POST git-upload-pack (gzip 132248 to 65839 bytes)
POST git-upload-pack (gzip 145448 to 72450 bytes)
POST git-upload-pack (gzip 159948 to 79682 bytes)
POST git-upload-pack (gzip 175898 to 87436 bytes)
POST git-upload-pack (gzip 193448 to 96171 bytes)
POST git-upload-pack (gzip 212748 to 105783 bytes)
POST git-upload-pack (gzip 233998 to 116207 bytes)
POST git-upload-pack (gzip 257398 to 127793 bytes)
POST git-upload-pack (gzip 283098 to 140511 bytes)
POST git-upload-pack (gzip 311348 to 154447 bytes)
POST git-upload-pack (gzip 342448 to 169815 bytes)
POST git-upload-pack (gzip 376648 to 186850 bytes)
POST git-upload-pack (gzip 414298 to 205408 bytes)
POST git-upload-pack (gzip 455698 to 225879 bytes)
POST git-upload-pack (gzip 501248 to 248389 bytes)
POST git-upload-pack (gzip 551298 to 273131 bytes)
POST git-upload-pack (gzip 606398 to 300334 bytes)
POST git-upload-pack (gzip 666998 to 330414 bytes)
POST git-upload-pack (gzip 733698 to 363387 bytes)
POST git-upload-pack (gzip 807048 to 399647 bytes)
POST git-upload-pack (gzip 689453 to 341449 bytes)
error: RPC failed; HTTP 504 curl 22 The requested URL returned error:
504 Gateway Time-out
fatal: The remote end hung up unexpectedly
Is there some way to fetch partially by smaller chunks and then repeat
that again till everything is fetched?
Thanks!
^ permalink raw reply
* Re: [PATCH v2 00/11] git worktree (re)move
From: Junio C Hamano @ 2016-11-28 20:20 UTC (permalink / raw)
To: Nguyễn Thái Ngọc Duy; +Cc: Johannes Schindelin, git
In-Reply-To: <xmqqwpfnidxm.fsf@gitster.mtv.corp.google.com>
Junio C Hamano <gitster@pobox.com> writes:
> Does this round address the issue raised in
>
> http://public-inbox.org/git/alpine.DEB.2.20.1611161041040.3746@virtualbox
>
> by Dscho?
>
> Even if you are not tracking a fifo, for example, your working tree
> may have one created in t/trash* directory during testing, and
> letting platform "cp -r" taking care of it (if that is possible---I
> didn't look at the code that calls busybox copy to see if you are
> doing something exotic or just blindly copying everything in the
> directory) may turn out to be a more portable way to do this, and I
> suspect that the cost of copying one whole-tree would dominate the
> run_command() overhead.
Please do not take the above as me saying "you must spawn the
platform cp -r".
A more traditional alternative solution seen on this list is to work
together, leveraging expertise of each participant. From the build
log Dscho gave us, it seems that his Windows port lack at least
POSIX emulation for lchown, mknod, utimes and chown. It is hard to
decide without involving Windows expert what the best way to deal
with it in the code (e.g. To stub or #ifdef out these calls?
Provide suitable emulation in compat/? Something else?), and what
things other than these four are still missing.
^ permalink raw reply
* Re: [PATCH v2 00/11] git worktree (re)move
From: Junio C Hamano @ 2016-11-28 19:48 UTC (permalink / raw)
To: Nguyễn Thái Ngọc Duy, Johannes Schindelin; +Cc: git
In-Reply-To: <20161128094319.16176-1-pclouds@gmail.com>
Nguyễn Thái Ngọc Duy <pclouds@gmail.com> writes:
> v2 contains some style fix and adapts to the new get_worktrees() api
> from nd/worktree-list-fixup (which means it can't be built without
> that series).
>
> Nguyễn Thái Ngọc Duy (11):
> copy.c: import copy_file() from busybox
> copy.c: delete unused code in copy_file()
> copy.c: convert bb_(p)error_msg to error(_errno)
> copy.c: style fix
> copy.c: convert copy_file() to copy_dir_recursively()
> worktree.c: add validate_worktree()
> worktree.c: add update_worktree_location()
> worktree move: new command
> worktree move: accept destination as directory
> worktree move: refuse to move worktrees with submodules
> worktree remove: new command
>
> Documentation/git-worktree.txt | 28 ++-
> builtin/worktree.c | 181 ++++++++++++++++
> cache.h | 1 +
> contrib/completion/git-completion.bash | 5 +-
> copy.c | 369 +++++++++++++++++++++++++++++++++
> t/t2028-worktree-move.sh | 56 +++++
> worktree.c | 84 ++++++++
> worktree.h | 11 +
> 8 files changed, 724 insertions(+), 11 deletions(-)
Does this round address the issue raised in
http://public-inbox.org/git/alpine.DEB.2.20.1611161041040.3746@virtualbox
by Dscho?
Even if you are not tracking a fifo, for example, your working tree
may have one created in t/trash* directory during testing, and
letting platform "cp -r" taking care of it (if that is possible---I
didn't look at the code that calls busybox copy to see if you are
doing something exotic or just blindly copying everything in the
directory) may turn out to be a more portable way to do this, and I
suspect that the cost of copying one whole-tree would dominate the
run_command() overhead.
^ permalink raw reply
* Re: [PATCH 0/3] Minor fixes on 'git worktree'
From: Junio C Hamano @ 2016-11-28 19:36 UTC (permalink / raw)
To: Duy Nguyen; +Cc: Git Mailing List, Mike Rappazzo
In-Reply-To: <CACsJy8CpySQs07cfioOnoxoH1TALRePGbeVCc45ZqDr43519qQ@mail.gmail.com>
Duy Nguyen <pclouds@gmail.com> writes:
> An interesting thing maybe worth
> sharing is, if HEAD is broken (the only reason we would fail to create
> "struct worktree" for main worktree), then "git worktree list" from
> main worktree would fail too, because repo setup code fails to parse
> HEAD as well and die().
Yeah, that makes sense.
> That makes the "always show main worktree"
> patch useless, since we won't get far enough to execute
> get_worktrees() in the first place. However, you can still do "git
> worktree list" from a linked worktree, gitdir setup code will not stop
> you (how can it). And the patch is still needed.
Yes.
^ permalink raw reply
* Re: [PATCH] l10n: de.po: translate 210 new message
From: Junio C Hamano @ 2016-11-28 19:29 UTC (permalink / raw)
To: Ralf Thielow
Cc: Jiang Xin, Git List, Thomas Rast, Jan Krüger,
Christian Stimming, Phillip Sz, Matthias Rüster,
Magnus Görlitz
In-Reply-To: <CAN0XMOJ0mQ7KF_f2dh9YFA62a4RxoYJMkT7HXUpArK5CdHimew@mail.gmail.com>
Ralf Thielow <ralf.thielow@gmail.com> writes:
> 2016-11-28 15:21 GMT+01:00 Jiang Xin <worldhello.net@gmail.com>:
>> 2016-11-25 2:25 GMT+08:00 Ralf Thielow <ralf.thielow@gmail.com>:
>>> #: sequencer.c:251
>>> -#, fuzzy, c-format
>>> +#, c-format
>>> msgid "could not write eol to '%s"
>>
>> Unmatched single quote has been fixed in l10n round 3.
>> You can rebase and update de.po file.
>>
>> BTW, Git 2.11.0 will be released tomorrow, please send PR in time.
>
> I've rebased, fixed the subject line and send a pull request to you.
Thanks, both.
^ permalink raw reply
* Re: [PATCH v3 1/2] difftool: add a skeleton for the upcoming builtin
From: Junio C Hamano @ 2016-11-28 19:27 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Jeff King, git, David Aguilar, Dennis Kaarsemaker
In-Reply-To: <alpine.DEB.2.20.1611281830040.117539@virtualbox>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> However, I have been bitten time and again by problems that occurred only
> in production, our test suite (despite taking already waaaaaay too long to
> be truly useful in my daily development) was simply not good enough.
>
> So my plan was different: to let end users opt-in to test this new beast
> thoroughly, more thoroughly than any review would.
I agree with that 100%.
We need to ensure "fallback to known working code" escape hatch is
robust for that plan to work well, and that is why (1) I have been
more focused on getting 1/2 right, and (2) I do not think it should
be Windows-only like in your early plan, and (3) I do not think it
would be "this will merely be there for only a month or so", like
you said earlier.
> And for that, environment variables are just not an option. I need
> something that can be configured in a portable application, so that the
> main Git for Windows installation is unaffected.
I am not sure I follow here.
Are you saying that the users who are opting into the experiment
will keep two installations, one for daily use that avoids getting
hit by the experimental code and the other that is used for testing?
How are they switching between the two? By using different %PATH%?
I am not sure how it is different from setting an environment
$GIT_TEST_BUILTIN_DIFFTOOL.
In any case, I do not have strong preference between environment and
configuration. If you can make 1/2 robust with configuration, that
is just as well. My message you are responding to was merely to
suggest another possibility.
The latter two points in my four-bullet list are hopefully still
viable if you go with the configuration; it may go something like:
- The bulk of the tests is moved into a common dot-sourced file,
with (1) PERL prerequite stripped and (2) "git difftool" replaced
with $git_difftool
- Two test files do one of
git_difftool="git difftool"
git_difftool="git -c difftool.useBuiltin=true difftool"
and include the dot-sourced file. The one that does the former
needs to give up early depending on PERL prerequisite.
perhaps.
> My original "create a file in libexec/git-core/" was simple, did the job
> reliably, and worked also for testing.
It may have been OK for quick-and-dirty hack during development, but
I do not think it was good in anything released.
^ permalink raw reply
* Re: [PATCH] allow git-p4 to create shelved changelists
From: Junio C Hamano @ 2016-11-28 19:06 UTC (permalink / raw)
To: Vinicius Kursancew, Luke Diamand, Lars Schneider; +Cc: git
In-Reply-To: <1480325598-12344-1-git-send-email-viniciusalexandre@gmail.com>
Vinicius Kursancew <viniciusalexandre@gmail.com> writes:
> This patch adds a "--shelve" option to the submit subcommand, it will
> save the changes to a perforce shelve instead of commiting them.
>
> Vinicius Kursancew (1):
> git-p4: allow submit to create shelved changelists.
>
> Documentation/git-p4.txt | 5 +++++
> git-p4.py | 36 ++++++++++++++++++++++--------------
> t/t9807-git-p4-submit.sh | 31 +++++++++++++++++++++++++++++++
> 3 files changed, 58 insertions(+), 14 deletions(-)
Thanks, but I am a wrong person to review this change, so I'll
summon two people who appear in "git shortlog --since=18.months"
output to help review it.
^ permalink raw reply
* [PATCH] diff: handle --no-abbrev outside of repository
From: Jack Bates @ 2016-11-28 18:25 UTC (permalink / raw)
To: git; +Cc: Jack Bates
The "git diff --no-index" codepath
doesn't handle the --no-abbrev option.
Signed-off-by: Jack Bates <jack@nottheoilrig.com>
---
diff.c | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/diff.c b/diff.c
index ec87283..0447eff 100644
--- a/diff.c
+++ b/diff.c
@@ -3106,7 +3106,8 @@ static const char *diff_abbrev_oid(const struct object_id *oid, int abbrev)
abbrev = FALLBACK_DEFAULT_ABBREV;
if (abbrev > GIT_SHA1_HEXSZ)
die("BUG: oid abbreviation out of range: %d", abbrev);
- hex[abbrev] = '\0';
+ if (abbrev)
+ hex[abbrev] = '\0';
return hex;
}
}
@@ -4024,6 +4025,8 @@ int diff_opt_parse(struct diff_options *options,
offending, optarg);
return argcount;
}
+ else if (!strcmp(arg, "--no-abbrev"))
+ options->abbrev = 0;
else if (!strcmp(arg, "--abbrev"))
options->abbrev = DEFAULT_ABBREV;
else if (skip_prefix(arg, "--abbrev=", &arg)) {
--
2.10.2
^ permalink raw reply related
* Re: [PATCH v2 2/2] Avoid a segmentation fault with renaming merges
From: Junio C Hamano @ 2016-11-28 18:59 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git, Markus Klein
In-Reply-To: <xmqqmvgjjvk5.fsf@gitster.mtv.corp.google.com>
Junio C Hamano <gitster@pobox.com> writes:
> Looking at the commit you blamed, what happened in this case before
> that change was that
>
> (1) make_cache_entry() would have called refresh_cache_entry() with
> CE_MATCH_REFRESH and returned a NULL;
>
> (2) merge-recursive.c::add_cacheinfo() noticed NULL and did
>
> return error(_("addinfo_cache failed for path '%s'"), path)
>
> But the updated code forgot that refresh_cache_entry() could return
> NULL. So 1335d76e45 ("merge: avoid "safer crlf" during recording of
> merge results", 2016-07-08) was not a faithful rewrite.
I'd tentatively queue the two patches fro you on top of the
jc/renormalize-merge-kill-safer-crlf topic that ends at 1335d76e45
("merge: avoid "safer crlf" during recording of merge results",
2016-07-08). The real "fix" became like this with the above
analysis. Semantic adjustment "error(" -> "err(o," between the old
codebase and the current one will be handled when merging.
Thanks for catching my incorrect refactoring.
-- >8 --
From: Johannes Schindelin <johannes.schindelin@gmx.de>
Date: Sat, 26 Nov 2016 13:48:06 +0100
Subject: [PATCH] merge-recursive: handle NULL in add_cacheinfo() correctly
1335d76e45 ("merge: avoid "safer crlf" during recording of merge
results", 2016-07-08) tried to split make_cache_entry() call made
with CE_MATCH_REFRESH into a call to make_cache_entry() without one,
followed by a call to add_cache_entry(), refresh_cache() and another
add_cache_entry() as needed. However the conversion was botched in
that it forgot that refresh_cache() can return NULL, which was handled
correctly in make_cache_entry() but not in the updated code.
This fixes https://github.com/git-for-windows/git/issues/952
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
merge-recursive.c | 2 ++
t/t3501-revert-cherry-pick.sh | 2 +-
2 files changed, 3 insertions(+), 1 deletion(-)
diff --git a/merge-recursive.c b/merge-recursive.c
index de37e5153c..56385d4c01 100644
--- a/merge-recursive.c
+++ b/merge-recursive.c
@@ -213,6 +213,8 @@ static int add_cacheinfo(unsigned int mode, const unsigned char *sha1,
struct cache_entry *nce;
nce = refresh_cache_entry(ce, CE_MATCH_REFRESH | CE_MATCH_IGNORE_MISSING);
+ if (!nce)
+ return error(_("addinfo_cache failed for path '%s'"), path);
if (nce != ce)
ret = add_cache_entry(nce, options);
}
diff --git a/t/t3501-revert-cherry-pick.sh b/t/t3501-revert-cherry-pick.sh
index 5bef564ff1..22970d2223 100755
--- a/t/t3501-revert-cherry-pick.sh
+++ b/t/t3501-revert-cherry-pick.sh
@@ -141,7 +141,7 @@ test_expect_success 'cherry-pick "-" works with arguments' '
test_cmp expect actual
'
-test_expect_failure 'cherry-pick works with dirty renamed file' '
+test_expect_success 'cherry-pick works with dirty renamed file' '
test_commit to-rename &&
git checkout -b unrelated &&
test_commit unrelated &&
--
2.11.0-rc3-172-gc8d0e450d3
^ permalink raw reply related
* Re: [PATCH v2 2/2] Avoid a segmentation fault with renaming merges
From: Junio C Hamano @ 2016-11-28 18:42 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git, Markus Klein
In-Reply-To: <alpine.DEB.2.20.1611261348420.117539@virtualbox>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> On Sat, 26 Nov 2016, Johannes Schindelin wrote:
>
>> diff --git a/merge-recursive.c b/merge-recursive.c
>> index 9041c2f149..609061f58a 100644
>> --- a/merge-recursive.c
>> +++ b/merge-recursive.c
>> @@ -235,6 +235,8 @@ static int add_cacheinfo(struct merge_options *o,
>> struct cache_entry *nce;
>>
>> nce = refresh_cache_entry(ce, CE_MATCH_REFRESH | CE_MATCH_IGNORE_MISSING);
>> + if (!nce)
>> + return err(o, _("addinfo: '%s' is not up-to-date"), path);
>> if (nce != ce)
>> ret = add_cache_entry(nce, options);
>> }
>
> BTW I was not quite sure why we need to refresh the cache entry here, and
> 1335d76e45 (merge: avoid "safer crlf" during recording of merge results,
> 2016-07-08) has a commit message for which I need some time to wrap my
> head around.
This callsite used to call make_cache_entry() with CE_MATCH_REFRESH,
which creates a new cache entry, calls refresh_cache_ent, and
returns the cache entry"; the log message attempts to explain why we
avoid passing CE_MATCH_REFRESH and instead first add it as a merged
entry and then refresh it (and re-add it if ce got changed). We
used to leave the old (possibly conflicted) entries for the same
path in the index while refreshing the new cache entry, which has
correctly converted result, and the old entries got in the way,
attempting a wrong eol conversion and declaring that the new entry
out-of-date. By adding the correctly converted result as a merged
entry, which gets rid of the old entries, the refresh operation will
not be corrupted by them.
> Also, an error here may be overkill. Maybe we should simply change the "if
> (nce != ce)" to an "if (nce && nce != ce)" here, as a locally-modified
> file will give a nicer message later, anyway.
Looking at the commit you blamed, what happened in this case before
that change was that
(1) make_cache_entry() would have called refresh_cache_entry() with
CE_MATCH_REFRESH and returned a NULL;
(2) merge-recursive.c::add_cacheinfo() noticed NULL and did
return error(_("addinfo_cache failed for path '%s'"), path)
But the updated code forgot that refresh_cache_entry() could return
NULL. So 1335d76e45 ("merge: avoid "safer crlf" during recording of
merge results", 2016-07-08) was not a faithful rewrite.
So I agree that your patch is the right fix; using the old message
lost by mistake in 1335d76e45 may have made it more clear that this
is a fix for a misconversion in that commit, though.
In any case, this does not seem like a new regression (1/2 applied
on v2.10.0 dies the same way), so I am inclined to queue these two
but not ship in the upcoming release for now.
Thanks.
^ permalink raw reply
* Re: What's cooking in git.git (Nov 2016, #05; Wed, 23)
From: Junio C Hamano @ 2016-11-28 18:08 UTC (permalink / raw)
To: Duy Nguyen; +Cc: Git Mailing List
In-Reply-To: <CACsJy8DaOB=ybWFbcqFgZ_U_JYWFUXNDJRmG6_-S3raWh6AWaQ@mail.gmail.com>
Duy Nguyen <pclouds@gmail.com> writes:
> On Thu, Nov 24, 2016 at 6:21 AM, Junio C Hamano <gitster@pobox.com> wrote:
>> * 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.
>
> The reroll was http://public-inbox.org/git/%3C20161112020041.2335-1-pclouds@gmail.com%3E/
Thanks.
^ permalink raw reply
* Re: [PATCH v2] date-formats.txt: Typo fix
From: Junio C Hamano @ 2016-11-28 18:06 UTC (permalink / raw)
To: Luis Ressel; +Cc: git
In-Reply-To: <20161125173657.9656-1-aranea@aixah.de>
Luis Ressel <aranea@aixah.de> writes:
> Last time I checked, I was living in the UTC+01:00 time zone. UTC+02:00
> would be Central European _Summer_ Time.
> ---
Thanks; please sign-off your patches, even a trivial ones like this.
> Documentation/date-formats.txt | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/Documentation/date-formats.txt b/Documentation/date-formats.txt
> index 35e8da2..6926e0a 100644
> --- a/Documentation/date-formats.txt
> +++ b/Documentation/date-formats.txt
> @@ -11,7 +11,7 @@ Git internal format::
> It is `<unix timestamp> <time zone offset>`, where `<unix
> timestamp>` is the number of seconds since the UNIX epoch.
> `<time zone offset>` is a positive or negative offset from UTC.
> - For example CET (which is 2 hours ahead UTC) is `+0200`.
> + For example CET (which is 1 hour ahead of UTC) is `+0100`.
>
> RFC 2822::
> The standard email format as described by RFC 2822, for example
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox