* [PATCH] xdiff: remove unneeded declarations
From: Stefan Beller @ 2016-09-03 3:16 UTC (permalink / raw)
To: gitster; +Cc: git, Stefan Beller
Signed-off-by: Stefan Beller <sbeller@google.com>
---
xdiff/xemit.c | 9 ---------
1 file changed, 9 deletions(-)
diff --git a/xdiff/xemit.c b/xdiff/xemit.c
index 49aa16f..b52b4b9 100644
--- a/xdiff/xemit.c
+++ b/xdiff/xemit.c
@@ -22,15 +22,6 @@
#include "xinclude.h"
-
-
-
-static long xdl_get_rec(xdfile_t *xdf, long ri, char const **rec);
-static int xdl_emit_record(xdfile_t *xdf, long ri, char const *pre, xdemitcb_t *ecb);
-
-
-
-
static long xdl_get_rec(xdfile_t *xdf, long ri, char const **rec) {
*rec = xdf->recs[ri]->ptr;
--
2.10.0.rc2.22.g25cb54d.dirty
^ permalink raw reply related
* Re: [PATCH] sequencer: support folding in rfc2822 footer
From: Junio C Hamano @ 2016-09-03 2:23 UTC (permalink / raw)
To: Jonathan Tan; +Cc: git
In-Reply-To: <1472846322-5592-1-git-send-email-jonathantanmy@google.com>
Jonathan Tan <jonathantanmy@google.com> writes:
> Sample-field: multiple-line field body
> that causes a blank line below
I am not sure this is unconditionally good, or may cause problems to
those with workflows you did not consider when you wrote this patch.
Not being too lenient here historically has been a deliberate
decision to avoid misidentification of non "footers". Does Git
itself produce some folded footer line? If Git itself produced such
folded lines, I'd be a lot more receptive to this change, but I do
not think that is the case here.
A slightly related tangent. An unconditionally good change you
could make is to allow folding of in-body headers. I.e. you can
have e.g.
-- >8 --
Subject: [PATCH] sequencer: support in-body headers that are
folded according to RFC2822 rules
The first paragraph after the above long title begins
here...
in the body of the msssage, and I _think_ we do not fold it properly
when applying such a patch. We should, as that is something that
appears in format-patch output (i.e. something Git itself produces,
unlike the folded "footer").
^ permalink raw reply
* Re: Fixup of a fixup not working right
From: Junio C Hamano @ 2016-09-03 2:22 UTC (permalink / raw)
To: Philip Oakley; +Cc: Robert Dailey, Git
In-Reply-To: <55512A8927384A0790DDC7F526B09053@PhilipOakley>
"Philip Oakley" <philipoakley@iee.org> writes:
> As I understand this it's implied by design. The issue is that the
> rebase is looking for that named commit within its current rebase
> range, and can't find it, so ignores it.
>
> There is a separate issue that all the fixup! fixup! messages are
> essentially treated as being concatenations of the original fixup!, no
> matter how many time the fiup is present.
They can be handled separately, but they come from the same "design"
that could be improved. When the "original" is not in the range to
be rebased for whatever reason (including the most likely one, i.e.
it has already graduated to become part of the public history), the
best thing the user could do at that point may be, as you suggested
to Robert in your message, to turn the "fixup! original" that did
not make in time before "original" hit the public record into a
standalone "fix original" follow-up change, and then to squash
subsequent "fixup! fixup! original" (and other "fixup! original",
too) into that commit. And a good direction forward may be to see
if "rebase -i" can be taught to be more helpful for the user who
wants to do that.
Perhaps a change like this to "rebase -i":
- The search for "original" when handling "pick fixup! original",
when it does not find "original", could turn it into "reword
fixup! original" without changing its position in the instruction
sequence.
- The search for "original" when handling "pick fixup! fixup!
original", could be (probably unconditionally) changed to look
for "fixup! original" to amend, instead of looking for "original"
as the current code (this is your "separate issue"). The same
"if the commit to be amended is not found, turn it into reword"
rule from the above applies to this one, too.
may be an improvement?
^ permalink raw reply
* What's cooking in git.git (Sep 2016, #01; Fri, 2)
From: Junio C Hamano @ 2016-09-03 2:17 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.
Git 2.10 has been tagged. In a few days, many topics that have been
cooking in 'next' would be merged to 'master'; as usual, I plan to
keep the tip of 'next' closed for a week or so and encourage people
to pay more attention to possible regressions than to show their
shiny new toys, and then open the new cycle by rebuilding 'next'
after that.
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/submodule-anchor-git-dir (2016-09-01) 1 commit
- submodule: avoid auto-discovery in prepare_submodule_repo_env()
Having a submodule whose ".git" repository is somehow corrupt
caused a few commands that recurse into submodules loop forever.
Will merge to 'next'.
* jc/forbid-symbolic-ref-d-HEAD (2016-09-02) 1 commit
- symbolic-ref -d: do not allow removal of HEAD
"git symbolic-ref -d HEAD" happily removes the symbolic ref, but
the resulting repository becomes an invalid one. Teach the command
to forbid removal of HEAD.
Will merge to 'next'.
--------------------------------------------------
[Stalled]
* 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.
* jc/blame-reverse (2016-06-14) 2 commits
- blame: dwim "blame --reverse OLD" as "blame --reverse OLD.."
- blame: improve diagnosis for "--reverse NEW"
It is a common mistake to say "git blame --reverse OLD path",
expecting that the command line is dwimmed as if asking how lines
in path in an old revision OLD have survived up to the current
commit.
Has been waiting for positive responses without seeing any.
Will discard.
* jc/attr (2016-05-25) 18 commits
- 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
(this branch is used by jc/attr-more, sb/pathspec-label and sb/submodule-default-paths.)
The attributes API has been updated so that it can later be
optimized using the knowledge of which attributes are queried.
I wanted to polish this topic further to make the attribute
subsystem thread-ready, but because other topics depend on this
topic and they do not (yet) need it to be thread-ready.
As the authors of topics that depend on this seem not in a hurry,
let's discard this and dependent topics and restart them some other
day.
Will discard.
* jc/attr-more (2016-06-09) 8 commits
- 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
- fixup! d5ad6c13
- attr.c: pass struct git_attr_check down the callchain
- attr.c: add push_stack() helper
(this branch uses jc/attr; is tangled with sb/pathspec-label and sb/submodule-default-paths.)
The beginning of long and tortuous journey to clean-up attribute
subsystem implementation.
Needs to be redone.
Will discard.
* sb/submodule-default-paths (2016-06-20) 5 commits
- completion: clone can recurse into submodules
- clone: add --init-submodule=<pathspec> switch
- submodule update: add `--init-default-path` switch
- Merge branch 'sb/pathspec-label' into sb/submodule-default-paths
- Merge branch 'jc/attr' into sb/submodule-default-paths
(this branch uses jc/attr and sb/pathspec-label; is tangled with jc/attr-more.)
Allow specifying the set of submodules the user is interested in on
the command line of "git clone" that clones the superproject.
Will discard.
* sb/pathspec-label (2016-06-03) 6 commits
- pathspec: disable preload-index when attribute pathspec magic is in use
- 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
(this branch is used by sb/submodule-default-paths; uses jc/attr; is tangled with jc/attr-more.)
The pathspec mechanism learned ":(attr:X)$pattern" pathspec magic
to limit paths that match $pattern further by attribute settings.
The preload-index mechanism is disabled when the new pathspec magic
is in use (at least for now), because the attribute subsystem is
not thread-ready.
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.
* sb/bisect (2016-04-15) 22 commits
. SQUASH???
. bisect: get back halfway shortcut
. bisect: compute best bisection in compute_relevant_weights()
. bisect: use a bottom-up traversal to find relevant weights
. bisect: prepare for different algorithms based on find_all
. bisect: rename count_distance() to compute_weight()
. bisect: make total number of commits global
. bisect: introduce distance_direction()
. bisect: extract get_distance() function from code duplication
. bisect: use commit instead of commit list as arguments when appropriate
. bisect: replace clear_distance() by unique markers
. bisect: use struct node_data array instead of int array
. bisect: get rid of recursion in count_distance()
. bisect: make algorithm behavior independent of DEBUG_BISECT
. bisect: make bisect compile if DEBUG_BISECT is set
. bisect: plug the biggest memory leak
. bisect: add test for the bisect algorithm
. t6030: generalize test to not rely on current implementation
. t: use test_cmp_rev() where appropriate
. t/test-lib-functions.sh: generalize test_cmp_rev
. bisect: allow 'bisect run' if no good commit is known
. bisect: write about `bisect next` in documentation
The internal algorithm used in "git bisect" to find the next commit
to check has been optimized greatly.
Was expecting a reroll, but now pb/bisect topic starts removinging
more and more parts from git-bisect.sh, this needs to see a fresh
reroll.
Will discard.
cf. <1460294354-7031-1-git-send-email-s-beyer@gmx.net>
* sg/completion-updates (2016-02-28) 21 commits
. completion: cache the path to the repository
. completion: extract repository discovery from __gitdir()
. completion: don't guard git executions with __gitdir()
. completion: consolidate silencing errors from git commands
. completion: don't use __gitdir() for git commands
. completion: respect 'git -C <path>'
. completion: fix completion after 'git -C <path>'
. completion: don't offer commands when 'git --opt' needs an argument
. rev-parse: add '--absolute-git-dir' option
. completion: list short refs from a remote given as a URL
. completion: don't list 'HEAD' when trying refs completion outside of a repo
. completion: list refs from remote when remote's name matches a directory
. completion: respect 'git --git-dir=<path>' when listing remote refs
. completion: fix most spots not respecting 'git --git-dir=<path>'
. completion: ensure that the repository path given on the command line exists
. completion tests: add tests for the __git_refs() helper function
. completion tests: check __gitdir()'s output in the error cases
. completion tests: consolidate getting path of current working directory
. completion tests: make the $cur variable local to the test helper functions
. completion tests: don't add test cruft to the test repository
. completion: improve __git_refs()'s in-code documentation
Has been waiting for a reroll for too long.
cf. <1456754714-25237-1-git-send-email-szeder@ira.uka.de>
Will discard.
* 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]
* bh/diff-highlight-graph (2016-08-31) 6 commits
(merged to 'next' on 2016-08-31 at 523a15f)
+ diff-highlight: avoid highlighting combined diffs
+ diff-highlight: add multi-byte tests
+ diff-highlight: ignore test cruft
+ diff-highlight: add support for --graph output
+ diff-highlight: add failing test for handling --graph output
+ diff-highlight: add some tests
"diff-highlight" script (in contrib/) learned to work better with
"git log -p --graph" output.
Will merge to 'master'.
* jc/am-read-author-file (2016-08-30) 1 commit
- am: refactor read_author_script()
Extract a small helper out of the function that reads the authors
script file "git am" internally uses.
Will merge to 'next'.
This by itself is not useful until a second caller appears in the
future for "rebase -i" helper.
* jk/test-lib-drop-pid-from-results (2016-08-30) 1 commit
- test-lib: drop PID from test-results/*.count
The test framework left the number of tests and success/failure
count in the t/test-results directory, keyed by the name of the
test script plus the process ID. The latter however turned out not
to serve any useful purpose. The process ID part of the filename
has been removed.
Will merge to 'next'.
* js/sequencer-wo-die (2016-08-29) 14 commits
- sequencer: lib'ify save_opts()
- sequencer: lib'ify save_todo()
- sequencer: lib'ify save_head()
- sequencer: lib'ify create_seq_dir()
- sequencer: lib'ify read_populate_opts()
- sequencer: lib'ify read_populate_todo()
- sequencer: lib'ify read_and_refresh_cache()
- sequencer: lib'ify prepare_revs()
- sequencer: lib'ify walk_revs_populate_todo()
- sequencer: lib'ify do_pick_commit()
- sequencer: lib'ify do_recursive_merge()
- sequencer: lib'ify write_message()
- sequencer: do not die() in do_pick_commit()
- sequencer: lib'ify sequencer_pick_revisions()
Lifts calls to exit(2) and die() higher in the callchain in
sequencer.c files so that more helper functions in it can be used
by callers that want to handle error conditions themselves.
Waiting for a reroll.
* jk/squelch-false-warning-from-gcc-o3 (2016-08-31) 2 commits
- color_parse_mem: initialize "struct color" temporary
- error_errno: use constant return similar to error()
Will merge to 'next'.
* hv/doc-commit-reference-style (2016-08-26) 1 commit
(merged to 'next' on 2016-08-31 at 68fb778)
+ SubmittingPatches: use gitk's "Copy commit summary" format
A small doc update.
Will merge to 'master'.
* cc/receive-pack-limit (2016-08-24) 3 commits
(merged to 'next' on 2016-08-25 at bc74b5b)
+ receive-pack: allow a maximum input size to be specified
+ unpack-objects: add --max-input-size=<size> option
+ index-pack: add --max-input-size=<size> option
An incoming "git push" that attempts to push too many bytes can now
be rejected by setting a new configuration variable at the receiving
end.
Will merge to 'master'.
* jk/format-patch-number-singleton-patch-with-cover (2016-08-23) 1 commit
(merged to 'next' on 2016-08-25 at a4737fb)
+ format-patch: show 0/1 and 1/1 for singleton patch with cover letter
"git format-patch --cover-letter HEAD^" to format a single patch
with a separate cover letter now numbers the output as [PATCH 0/1]
and [PATCH 1/1] by default.
Will merge to 'master'.
* cp/completion-negative-refs (2016-08-24) 1 commit
- completion: support excluding refs
The command-line completion script (in contrib/) learned to
complete "git cmd ^mas<HT>" to complete the negative end of
reference to "git cmd ^master".
Waiting for a review.
* jk/delta-base-cache (2016-08-23) 7 commits
(merged to 'next' on 2016-08-25 at f1c141a)
+ t/perf: add basic perf tests for delta base cache
+ delta_base_cache: use hashmap.h
+ delta_base_cache: drop special treatment of blobs
+ delta_base_cache: use list.h for LRU
+ release_delta_base_cache: reuse existing detach function
+ clear_delta_base_cache_entry: use a more descriptive name
+ cache_or_unpack_entry: drop keep_cache parameter
The delta-base-cache mechanism has been a key to the performance in
a repository with a tightly packed packfile, but it did not scale
well even with a larger value of core.deltaBaseCacheLimit.
Will merge to 'master'.
* js/cat-file-filters (2016-08-24) 4 commits
- cat-file: support --textconv/--filters in batch mode
- cat-file --textconv/--filters: allow specifying the path separately
- cat-file: introduce the --filters option
- cat-file: fix a grammo in the man page
Even though "git hash-objects", which is a tool to take an
on-filesystem data stream and put it into the Git object store,
allowed to perform the "outside-world-to-Git" conversions (e.g.
end-of-line conversions and application of the clean-filter), and
it had the feature on by default from very early days, its reverse
operation "git cat-file", which takes an object from the Git object
store and externalize for the consumption by the outside world,
lacked an equivalent mechanism to run the "Git-to-outside-world"
conversion. The command learned the "--filters" option to do so.
Waiting for a reroll.
cf. <xmqqmvk2qcv8.fsf@gitster.mtv.corp.google.com>
* sb/push-make-submodule-check-the-default (2016-08-24) 1 commit
- push: change submodule default to check
Turn the default of "push.recurseSubmodules" to "check".
Alas, this reveals that the "check" mode is too inefficient to use
in real projects, even in ones as small as git itself.
cf. <xmqqh9aaot49.fsf@gitster.mtv.corp.google.com>
* ak/curl-imap-send-explicit-scheme (2016-08-17) 1 commit
- imap-send: Tell cURL to use imap:// or imaps://
When we started cURL to talk to imap server when a new enough
version of cURL library is available, we forgot to explicitly add
imap(s):// before the destination. To some folks, that didn't work
and the library tried to make HTTP(s) requests instead.
Needs review and testing.
* rt/help-unknown (2016-08-30) 3 commits
(merged to 'next' on 2016-08-30 at db2a5b0)
+ help: make option --help open man pages only for Git commands
+ help: introduce option --exclude-guides
+ Merge branch 'js/no-html-bypass-on-windows' into rt/help-unknown
"git nosuchcommand --help" said "No manual entry for gitnosuchcommand",
which was not intuitive, given that "git nosuchcommand" said "git:
'nosuchcommand' is not a git command".
Will merge to 'master'.
* po/range-doc (2016-08-13) 12 commits
(merged to 'next' on 2016-08-31 at d29870b)
+ doc: revisions: sort examples and fix alignment of the unchanged
+ doc: revisions: show revision expansion in examples
+ doc: revisions - clarify reachability examples
+ doc: revisions - define `reachable`
+ doc: gitrevisions - clarify 'latter case' is revision walk
+ doc: gitrevisions - use 'reachable' in page description
+ doc: revisions: single vs multi-parent notation comparison
+ doc: revisions: extra clarification of <rev>^! notation effects
+ doc: revisions: give headings for the two and three dot notations
+ doc: show the actual left, right, and boundary marks
+ doc: revisions - name the left and right sides
+ doc: use 'symmetric difference' consistently
Clarify various ways to specify the "revision ranges" in the
documentation.
Will merge to 'master'.
* jk/diff-submodule-diff-inline (2016-08-31) 8 commits
(merged to 'next' on 2016-09-02 at 734e42c)
+ diff: teach diff to display submodule difference with an inline diff
+ submodule: refactor show_submodule_summary with helper function
+ submodule: convert show_submodule_summary to use struct object_id *
+ allow do_submodule_path to work even if submodule isn't checked out
+ diff: prepare for additional submodule formats
+ graph: add support for --line-prefix on all graph-aware output
+ diff.c: remove output_prefix_length field
+ cache: add empty_tree_oid object and helper function
The "git diff --submodule={short,log}" mechanism has been enhanced
to allow "--submodule=diff" to show the patch between the submodule
commits bound to the superproject.
Will merge to 'master'.
* jk/reduce-gc-aggressive-depth (2016-08-11) 1 commit
(merged to 'next' on 2016-08-11 at 6810c6f)
+ gc: default aggressive depth to 50
"git gc --aggressive" used to limit the delta-chain length to 250,
which is way too deep for gaining additional space savings and is
detrimental for runtime performance. The limit has been reduced to
50.
Will hold to see if people scream.
* ks/pack-objects-bitmap (2016-08-09) 2 commits
- pack-objects: use reachability bitmap index when generating non-stdout pack
- pack-objects: respect --local/--honor-pack-keep/--incremental when bitmap is in use
Waiting for the review discussion to settle.
cf. <20160818175222.bmm3ivjheokf2qzl@sigill.intra.peff.net>
cf. <20160818180615.q25p57v35m2xxtww@sigill.intra.peff.net>
* sb/submodule-clone-rr (2016-08-17) 8 commits
(merged to 'next' on 2016-08-31 at 08b4b7d)
+ clone: recursive and reference option triggers submodule alternates
+ clone: implement optional references
+ clone: clarify option_reference as required
+ clone: factor out checking for an alternate path
+ submodule--helper update-clone: allow multiple references
+ submodule--helper module-clone: allow multiple references
+ t7408: merge short tests, factor out testing method
+ t7408: modernize style
"git clone --resurse-submodules --reference $path $URL" is a way to
reduce network transfer cost by borrowing objects in an existing
$path repository when cloning the superproject from $URL; it
learned to also peek into $path for presense of corresponding
repositories of submodules and borrow objects from there when able.
Will merge to 'master'.
* jh/status-v2-porcelain (2016-08-12) 9 commits
(merged to 'next' on 2016-08-31 at e71f595)
+ status: unit tests for --porcelain=v2
+ test-lib-functions.sh: add lf_to_nul helper
+ git-status.txt: describe --porcelain=v2 format
+ status: print branch info with --porcelain=v2 --branch
+ status: print per-file porcelain v2 status data
+ status: collect per-file data for --porcelain=v2
+ status: support --porcelain[=<version>]
+ status: cleanup API to wt_status_print
+ status: rename long-format print routines
Enhance "git status --porcelain" output by collecting more data on
the state of the index and the working tree files, which may
further be used to teach git-prompt (in contrib/) to make fewer
calls to git.
Will merge to 'master'.
* mh/diff-indent-heuristic (2016-08-23) 6 commits
- diff: improve positioning of add/delete blocks in diffs
- xdl_change_compact(): introduce the concept of a change group
- recs_match(): take two xrecord_t pointers as arguments
- is_blank_line(): take a single xrecord_t as argument
- xdl_change_compact(): only use heuristic if group can't be matched
- xdl_change_compact(): fix compaction heuristic to adjust ixo
Output from "git diff" can be made easier to read by selecting
which lines are common and which lines are added/deleted
intelligently when the lines before and after the changed section
are the same. A command line option is added to help with the
experiment to find a good heuristics.
Waiting for a reroll.
cf. <a27aa17e-f602-fc49-92b3-2198e4772e47@ramsayjones.plus.com>
* cc/apply-am (2016-08-29) 41 commits
- builtin/am: use apply API in run_apply()
- apply: learn to use a different index file
- apply: pass apply state to build_fake_ancestor()
- apply: refactor `git apply` option parsing
- apply: change error_routine when silent
- usage: add get_error_routine() and get_warn_routine()
- usage: add set_warn_routine()
- apply: don't print on stdout in verbosity_silent mode
- apply: make it possible to silently apply
- apply: use error_errno() where possible
- apply: make some parsing functions static again
- apply: move libified code from builtin/apply.c to apply.{c,h}
- apply: rename and move opt constants to apply.h
- builtin/apply: rename option parsing functions
- builtin/apply: make create_one_file() return -1 on error
- builtin/apply: make try_create_file() return -1 on error
- builtin/apply: make write_out_results() return -1 on error
- builtin/apply: make write_out_one_result() return -1 on error
- builtin/apply: make create_file() return -1 on error
- builtin/apply: make add_index_file() return -1 on error
- builtin/apply: make add_conflicted_stages_file() return -1 on error
- builtin/apply: make remove_file() return -1 on error
- builtin/apply: make build_fake_ancestor() return -1 on error
- builtin/apply: change die_on_unsafe_path() to check_unsafe_path()
- builtin/apply: make gitdiff_*() return -1 on error
- builtin/apply: make gitdiff_*() return 1 at end of header
- builtin/apply: make parse_traditional_patch() return -1 on error
- builtin/apply: make apply_all_patches() return 128 or 1 on error
- builtin/apply: move check_apply_state() to apply.c
- builtin/apply: make check_apply_state() return -1 instead of die()ing
- apply: make init_apply_state() return -1 instead of exit()ing
- builtin/apply: move init_apply_state() to apply.c
- builtin/apply: make parse_ignorewhitespace_option() return -1 instead of die()ing
- builtin/apply: make parse_whitespace_option() return -1 instead of die()ing
- builtin/apply: make parse_single_patch() return -1 on error
- builtin/apply: make parse_chunk() return a negative integer on error
- builtin/apply: make find_header() return -128 instead of die()ing
- builtin/apply: read_patch_file() return -1 instead of die()ing
- builtin/apply: make apply_patch() return -1 or -128 instead of die()ing
- apply: move 'struct apply_state' to apply.h
- apply: make some names more specific
"git am" has been taught to make an internal call to "git apply"'s
innards without spawning the latter as a separate process.
Waiting for a reroll.
* jk/pack-objects-optim-mru (2016-08-11) 4 commits
(merged to 'next' on 2016-08-11 at c0a7dae)
+ pack-objects: use mru list when iterating over packs
+ pack-objects: break delta cycles before delta-search phase
+ sha1_file: make packed_object_info public
+ provide an initializer for "struct object_info"
"git pack-objects" in a repository with many packfiles used to
spend a lot of time looking for/at objects in them; the accesses to
the packfiles are now optimized by checking the most-recently-used
packfile first.
Will hold to see if people scream.
* jk/rebase-i-drop-ident-check (2016-07-29) 1 commit
(merged to 'next' on 2016-08-14 at 6891bcd)
+ rebase-interactive: drop early check for valid ident
Even when "git pull --rebase=preserve" (and the underlying "git
rebase --preserve") can complete without creating any new commit
(i.e. fast-forwards), it still insisted on having a usable ident
information (read: user.email is set correctly), which was less
than nice. As the underlying commands used inside "git rebase"
would fail with a more meaningful error message and advice text
when the bogus ident matters, this extra check was removed.
Will hold to see if people scream.
cf. <20160729224944.GA23242@sigill.intra.peff.net>
* dp/autoconf-curl-ssl (2016-06-28) 1 commit
- ./configure.ac: detect SSL in libcurl using curl-config
The ./configure script generated from configure.ac was taught how
to detect support of SSL by libcurl better.
Needs review.
* 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.
* ex/deprecate-empty-pathspec-as-match-all (2016-06-22) 1 commit
(merged to 'next' on 2016-07-13 at d9ca7fb)
+ pathspec: warn on empty strings as pathspec
An empty string used as a pathspec element has always meant
'everything matches', but it is too easy to write a script that
finds a path to remove in $path and run 'git rm "$paht"', which
ends up removing everything. Start warning about this use of an
empty string used for 'everything matches' and ask users to use a
more explicit '.' for that instead.
The hope is that existing users will not mind this change, and
eventually the warning can be turned into a hard error, upgrading
the deprecation into removal of this (mis)feature.
Will hold to see if people scream.
* mh/ref-store (2016-06-20) 38 commits
- refs: implement iteration over only per-worktree refs
- refs: make lock generic
- refs: add method to rename refs
- refs: add methods to init refs db
- refs: make delete_refs() virtual
- refs: add method for initial ref transaction commit
- refs: add methods for reflog
- refs: add method iterator_begin
- files_ref_iterator_begin(): take a ref_store argument
- split_symref_update(): add a files_ref_store argument
- lock_ref_sha1_basic(): add a files_ref_store argument
- lock_ref_for_update(): add a files_ref_store argument
- commit_ref_update(): add a files_ref_store argument
- lock_raw_ref(): add a files_ref_store argument
- repack_without_refs(): add a files_ref_store argument
- refs: make peel_ref() virtual
- refs: make create_symref() virtual
- refs: make pack_refs() virtual
- refs: make verify_refname_available() virtual
- refs: make read_raw_ref() virtual
- resolve_gitlink_ref(): rename path parameter to submodule
- resolve_gitlink_ref(): avoid memory allocation in many cases
- resolve_gitlink_ref(): implement using resolve_ref_recursively()
- resolve_ref_recursively(): new function
- read_raw_ref(): take a (struct ref_store *) argument
- resolve_gitlink_packed_ref(): remove function
- resolve_packed_ref(): rename function from resolve_missing_loose_ref()
- refs: reorder definitions
- refs: add a transaction_commit() method
- {lock,commit,rollback}_packed_refs(): add files_ref_store arguments
- resolve_missing_loose_ref(): add a files_ref_store argument
- get_packed_ref(): add a files_ref_store argument
- add_packed_ref(): add a files_ref_store argument
- refs: create a base class "ref_store" for files_ref_store
- refs: add a backend method structure
- refs: rename struct ref_cache to files_ref_store
- rename_ref_available(): add docstring
- resolve_gitlink_ref(): eliminate temporary variable
The ref-store abstraction was introduced to the refs API so that we
can plug in different backends to store references.
Needs a fixup.
cf. <576D9885.2020901@ramsayjones.plus.com>
* nd/shallow-deepen (2016-06-13) 27 commits
- fetch, upload-pack: --deepen=N extends shallow boundary by N commits
- upload-pack: add get_reachable_list()
- upload-pack: split check_unreachable() in two, prep for get_reachable_list()
- t5500, t5539: tests for shallow depth excluding a ref
- clone: define shallow clone boundary with --shallow-exclude
- fetch: define shallow boundary with --shallow-exclude
- upload-pack: support define shallow boundary by excluding revisions
- refs: add expand_ref()
- t5500, t5539: tests for shallow depth since a specific date
- clone: define shallow clone boundary based on time with --shallow-since
- fetch: define shallow boundary with --shallow-since
- upload-pack: add deepen-since to cut shallow repos based on time
- shallow.c: implement a generic shallow boundary finder based on rev-list
- fetch-pack: use a separate flag for fetch in deepening mode
- fetch-pack.c: mark strings for translating
- fetch-pack: use a common function for verbose printing
- fetch-pack: use skip_prefix() instead of starts_with()
- upload-pack: move rev-list code out of check_non_tip()
- upload-pack: make check_non_tip() clean things up on error
- upload-pack: tighten number parsing at "deepen" lines
- upload-pack: use skip_prefix() instead of starts_with()
- upload-pack: move "unshallow" sending code out of deepen()
- upload-pack: remove unused variable "backup"
- upload-pack: move "shallow" sending code out of deepen()
- upload-pack: move shallow deepen code out of receive_needs()
- transport-helper.c: refactor set_helper_option()
- remote-curl.c: convert fetch_git() to use argv_array
The existing "git fetch --depth=<n>" option was hard to use
correctly when making the history of an existing shallow clone
deeper. A new option, "--deepen=<n>", has been added to make this
easier to use. "git clone" also learned "--shallow-since=<date>"
and "--shallow-exclude=<tag>" options to make it easier to specify
"I am interested only in the recent N months worth of history" and
"Give me only the history since that version".
Needs review.
Rerolled. What this topic attempts to achieve is worthwhile, I
would think.
* pb/bisect (2016-08-23) 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 `--check-and-set-terms` 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
. 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
GSoC "bisect" topic.
I'd prefer to see early part solidified so that reviews can focus
on the later part that is still in flux. We are almost there but
not quite yet.
* 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.
* jc/merge-drop-old-syntax (2015-04-29) 1 commit
- 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>
^ permalink raw reply
* Re: [PATCH 2/2] connect: know that zero-ID is not a ref
From: Jeff King @ 2016-09-03 2:17 UTC (permalink / raw)
To: Shawn Pearce; +Cc: Jonathan Tan, git
In-Reply-To: <CAJo=hJtg1h1Zvu-TjMtDYVjPB2n0pihA18q3sHBPQ_ZA4dWRKg@mail.gmail.com>
On Fri, Sep 02, 2016 at 07:03:30PM -0700, Shawn Pearce wrote:
> > Is it useful for upload-pack? If we have no refs, there's traditionally
> > been nothing to fetch. Perhaps that's something that could change,
> > though. For example, there could be a capability to allow fetching
> > arbitrary sha1s (we have allowTIPSH1InWant and allowReachableSHA1InWant,
> > which obviously both require some refs, but allowArbitrarySHA1 does not
> > seem outside the realm of possibility).
>
> Its exactly these sort of extra capabilities. We run JGit in modes
> where "out of band" (e.g. URL or higher level protocol framing like an
> undocumented HTTP header) allows the fetch-pack client to say "do not
> send me advertisements, but I want to learn your capabilities". The
> fetch-pack client typically activates the allow-reachable-sha1-in-want
> feature and names specific SHA-1s it wants.
So it sounds like you _could_ enable this only in out-of-band mode,
without loss of functionality.
I don't particularly care either way (I do not run any JGit servers
myself), but if we do it in Git, I think that is the path we should go
for maximum compatibility (and then if we jump to protocol v2, we get to
shed all of the compatibility cruft).
> This allows the fetch-pack client to bypass a very large advertisement
> if it wants only a specific SHA-1 and doesn't care about the ref name
> its bound to, or reachable through.
Yep, definitely a useful thing.
> This is also perhaps a stepping stone towards "client speaks first".
> If we can later standardize an HTTP query parameter or extra HTTP
> header, the server may be able to avoid sending a lot of ref
> advertisements, but would still need to advertise capabilities.
Yes, but that is a big enough jump that we can design it to look like
whatever we want, not shoe-horning it into a pretend ref. Older clients
will be left behind either way, we will need a transition plan, etc.
-Peff
^ permalink raw reply
* [ANNOUNCE] Git v2.10.0
From: Junio C Hamano @ 2016-09-03 2:17 UTC (permalink / raw)
To: git; +Cc: Linux Kernel
The latest feature release Git v2.10.0 is now available at the
usual places. It is comprised of 639 non-merge commits since
v2.9.0, contributed by 76 people, 22 of which are new faces.
The tarballs are found at:
https://www.kernel.org/pub/software/scm/git/
The following public repositories all have a copy of the 'v2.10.0'
tag and the 'master' branch that the tag points at:
url = https://kernel.googlesource.com/pub/scm/git/git
url = git://repo.or.cz/alt-git.git
url = git://git.sourceforge.jp/gitroot/git-core/git.git
url = git://git-core.git.sourceforge.net/gitroot/git-core/git-core
url = https://github.com/gitster/git
New contributors whose contributions weren't in v2.9.0 are as follows.
Welcome to the Git development community!
Alexander Hirsch, Andreas Brauchli, Andrew Oakley, Antoine Queru,
Ben Wijen, Christopher Layne, Dave Nicolson, David Glasser, Ed
Maste, Heiko Becker, Ingo Brückl, Jonathan Tan, Jordan DE GEA,
Josef Kufner, Keith McGuigan, Kevin Willford, LE Manh Cuong,
Michael Stahl, Parker Moore, Peter Colberg, Tom Russello,
and William Duclot.
Returning contributors who helped this release are as follows.
Thanks for your continued support.
Alex Henrie, Alfred Perlstein, Armin Kunaschik, brian m. carlson,
Changwoo Ryu, Charles Bailey, Chris Packham, Christian Couder,
David A. Greene, David Aguilar, David Kastrup, David Turner,
Edward Thomson, Elia Pinto, Eric Sunshine, Eric Wong, Heiko
Voigt, Jacob Keller, Jean-Noel Avila, Jeff King, Jiang Xin,
Joey Hess, Johannes Schindelin, Johannes Sixt, John Keeping,
Jonathan Nieder, Josh Triplett, Junio C Hamano, Lars Schneider,
Lars Vogel, Linus Torvalds, Lukas Fleischer, Matthieu Moy,
Mehul Jain, Michael Haggerty, Michael J Gruber, Mike Hommey,
Nguyễn Thái Ngọc Duy, Nicolas Pitre, Orgad Shaneh, Patrick
Steinhardt, Peter Krefting, Pranit Bauva, Ramsay Jones, René
Scharfe, Ronald Wampler, Stefan Beller, SZEDER Gábor, Thomas
Braun, Thomas Gummerer, Torsten Bögershausen, Trần Ngọc
Quân, Vasco Almeida, and Ville Skyttä.
----------------------------------------------------------------
Git 2.10 Release Notes
======================
Backward compatibility notes
----------------------------
Updates since v2.9
------------------
UI, Workflows & Features
* "git pull --rebase --verify-signature" learned to warn the user
that "--verify-signature" is a no-op when rebasing.
* An upstream project can make a recommendation to shallowly clone
some submodules in the .gitmodules file it ships.
* "git worktree add" learned that '-' can be used as a short-hand for
"@{-1}", the previous branch.
* Update the funcname definition to support css files.
* The completion script (in contrib/) learned to complete "git
status" options.
* Messages that are generated by auto gc during "git push" on the
receiving end are now passed back to the sending end in such a way
that they are shown with "remote: " prefix to avoid confusing the
users.
* "git add -i/-p" learned to honor diff.compactionHeuristic
experimental knob, so that the user can work on the same hunk split
as "git diff" output.
* "upload-pack" allows a custom "git pack-objects" replacement when
responding to "fetch/clone" via the uploadpack.packObjectsHook.
(merge b738396 jk/upload-pack-hook later to maint).
* Teach format-patch and mailsplit (hence "am") how a line that
happens to begin with "From " in the e-mail message is quoted with
">", so that these lines can be restored to their original shape.
(merge d9925d1 ew/mboxrd-format-am later to maint).
* "git repack" learned the "--keep-unreachable" option, which sends
loose unreachable objects to a pack instead of leaving them loose.
This helps heuristics based on the number of loose objects
(e.g. "gc --auto").
(merge e26a8c4 jk/repack-keep-unreachable later to maint).
* "log --graph --format=" learned that "%>|(N)" specifies the width
relative to the terminal's left edge, not relative to the area to
draw text that is to the right of the ancestry-graph section. It
also now accepts negative N that means the column limit is relative
to the right border.
* A careless invocation of "git send-email directory/" after editing
0001-change.patch with an editor often ends up sending both
0001-change.patch and its backup file, 0001-change.patch~, causing
embarrassment and a minor confusion. Detect such an input and
offer to skip the backup files when sending the patches out.
(merge 531220b jc/send-email-skip-backup later to maint).
* "git submodule update" that drives many "git clone" could
eventually hit flaky servers/network conditions on one of the
submodules; the command learned to retry the attempt.
* The output coloring scheme learned two new attributes, italic and
strike, in addition to existing bold, reverse, etc.
* "git log" learns log.showSignature configuration variable, and a
command line option "--no-show-signature" to countermand it.
(merge fce04c3 mj/log-show-signature-conf later to maint).
* More markings of messages for i18n, with updates to various tests
to pass GETTEXT_POISON tests.
* "git archive" learned to handle files that are larger than 8GB and
commits far in the future than expressible by the traditional US-TAR
format.
(merge 560b0e8 jk/big-and-future-archive-tar later to maint).
* A new configuration variable core.sshCommand has been added to
specify what value for GIT_SSH_COMMAND to use per repository.
* "git worktree prune" protected worktrees that are marked as
"locked" by creating a file in a known location. "git worktree"
command learned a dedicated command pair to create and remove such
a file, so that the users do not have to do this with editor.
* A handful of "git svn" updates.
* "git push" learned to accept and pass extra options to the
receiving end so that hooks can read and react to them.
* "git status" learned to suggest "merge --abort" during a conflicted
merge, just like it already suggests "rebase --abort" during a
conflicted rebase.
* "git jump" script (in contrib/) has been updated a bit.
(merge a91e692 jk/git-jump later to maint).
* "git push" and "git clone" learned to give better progress meters
to the end user who is waiting on the terminal.
* An entry "git log --decorate" for the tip of the current branch is
shown as "HEAD -> name" (where "name" is the name of the branch);
the arrow is now painted in the same color as "HEAD", not in the
color for commits.
* "git format-patch" learned format.from configuration variable to
specify the default settings for its "--from" option.
* "git am -3" calls "git merge-recursive" when it needs to fall back
to a three-way merge; this call has been turned into an internal
subroutine call instead of spawning a separate subprocess.
* The command line completion scripts (in contrib/) now knows about
"git branch --delete/--move [--remote]".
(merge 2703c22 vs/completion-branch-fully-spelled-d-m-r later to maint).
* "git rev-parse --git-path hooks/<hook>" learned to take
core.hooksPath configuration variable (introduced during 2.9 cycle)
into account.
(merge 9445b49 ab/hooks later to maint).
* "git log --show-signature" and other commands that display the
verification status of PGP signature now shows the longer key-id,
as 32-bit key-id is so last century.
Performance, Internal Implementation, Development Support etc.
* "git fast-import" learned the same performance trick to avoid
creating too small a packfile as "git fetch" and "git push" have,
using *.unpackLimit configuration.
* When "git daemon" is run without --[init-]timeout specified, a
connection from a client that silently goes offline can hang around
for a long time, wasting resources. The socket-level KEEPALIVE has
been enabled to allow the OS to notice such failed connections.
* "git upload-pack" command has been updated to use the parse-options
API.
* The "git apply" standalone program is being libified; the first
step to move many state variables into a structure that can be
explicitly (re)initialized to make the machinery callable more
than once has been merged.
* HTTP transport gained an option to produce more detailed debugging
trace.
(merge 73e57aa ep/http-curl-trace later to maint).
* Instead of taking advantage of the fact that a struct string_list
that is allocated with all NULs happens to be the INIT_NODUP kind,
the users of string_list structures are taught to initialize them
explicitly as such, to document their behaviour better.
(merge 2721ce2 jk/string-list-static-init later to maint).
* HTTPd tests learned to show the server error log to help diagnosing
a failing tests.
(merge 44f243d nd/test-lib-httpd-show-error-log-in-verbose later to maint).
* The ownership rule for the piece of memory that hold references to
be fetched in "git fetch" was screwy, which has been cleaned up.
* "git bisect" makes an internal call to "git diff-tree" when
bisection finds the culprit, but this call did not initialize the
data structure to pass to the diff-tree API correctly.
* Further preparatory clean-up for "worktree" feature continues.
(merge 0409e0b nd/worktree-cleanup-post-head-protection later to maint).
* Formats of the various data (and how to validate them) where we use
GPG signature have been documented.
* A new run-command API function pipe_command() is introduced to
sanely feed data to the standard input while capturing data from
the standard output and the standard error of an external process,
which is cumbersome to hand-roll correctly without deadlocking.
* The codepath to sign data in a prepared buffer with GPG has been
updated to use this API to read from the status-fd to check for
errors (instead of relying on GPG's exit status).
(merge efee955 jk/gpg-interface-cleanup later to maint).
* Allow t/perf framework to use the features from the most recent
version of Git even when testing an older installed version.
* The commands in the "log/diff" family have had an FILE* pointer in the
data structure they pass around for a long time, but some codepaths
used to always write to the standard output. As a preparatory step
to make "git format-patch" available to the internal callers, these
codepaths have been updated to consistently write into that FILE*
instead.
* Conversion from unsigned char sha1[20] to struct object_id
continues.
* Improve the look of the way "git fetch" reports what happened to
each ref that was fetched.
* The .c/.h sources are marked as such in our .gitattributes file so
that "git diff -W" and friends would work better.
* Code clean-up to avoid using a variable string that compilers may
feel untrustable as printf-style format given to write_file()
helper function.
* "git p4" used a location outside $GIT_DIR/refs/ to place its
temporary branches, which has been moved to refs/git-p4-tmp/.
* Existing autoconf generated test for the need to link with pthread
library did not check all the functions from pthread libraries;
recent FreeBSD has some functions in libc but not others, and we
mistakenly thought linking with libc is enough when it is not.
* When "git fsck" reports a broken link (e.g. a tree object contains
a blob that does not exist), both containing object and the object
that is referred to were reported with their 40-hex object names.
The command learned the "--name-objects" option to show the path to
the containing object from existing refs (e.g. "HEAD~24^2:file.txt").
* Allow http daemon tests in Travis CI tests.
* Makefile assumed that -lrt is always available on platforms that
want to use clock_gettime() and CLOCK_MONOTONIC, which is not a
case for recent Mac OS X. The necessary symbols are often found in
libc on many modern systems and having -lrt on the command line, as
long as the library exists, had no effect, but when the platform
removes librt.a that is a different matter--having -lrt will break
the linkage.
This change could be seen as a regression for those who do need to
specify -lrt, as they now specifically ask for NEEDS_LIBRT when
building. Hopefully they are in the minority these days.
* Further preparatory work on the refs API before the pluggable
backend series can land.
* Error handling in the codepaths that updates refs has been
improved.
* The API to iterate over all the refs (i.e. for_each_ref(), etc.)
has been revamped.
* The handling of the "text=auto" attribute has been corrected.
$ echo "* text=auto eol=crlf" >.gitattributes
used to have the same effect as
$ echo "* text eol=crlf" >.gitattributes
i.e. declaring all files are text (ignoring "auto"). The
combination has been fixed to be equivalent to doing
$ git config core.autocrlf true
* Documentation has been updated to show better example usage
of the updated "text=auto" attribute.
* A few tests that specifically target "git rebase -i" have been
added.
* Dumb http transport on the client side has been optimized.
(merge ecba195 ew/http-walker later to maint).
* Users of the parse_options_concat() API function need to allocate
extra slots in advance and fill them with OPT_END() when they want
to decide the set of supported options dynamically, which makes the
code error-prone and hard to read. This has been corrected by tweaking
the API to allocate and return a new copy of "struct option" array.
* "git fetch" exchanges batched have/ack messages between the sender
and the receiver, initially doubling every time and then falling
back to enlarge the window size linearly. The "smart http"
transport, being an half-duplex protocol, outgrows the preset limit
too quickly and becomes inefficient when interacting with a large
repository. The internal mechanism learned to grow the window size
more aggressively when working with the "smart http" transport.
* Tests for "git svn" have been taught to reuse the lib-httpd test
infrastructure when testing the subversion integration that
interacts with subversion repositories served over the http://
protocol.
(merge a8a5d25 ew/git-svn-http-tests later to maint).
* "git pack-objects" has a few options that tell it not to pack
objects found in certain packfiles, which require it to scan .idx
files of all available packs. The codepaths involved in these
operations have been optimized for a common case of not having any
non-local pack and/or any .kept pack.
* The t3700 test about "add --chmod=-x" have been made a bit more
robust and generally cleaned up.
(merge 766cdc4 ib/t3700-add-chmod-x-updates later to maint).
* The build procedure learned PAGER_ENV knob that lists what default
environment variable settings to export for popular pagers. This
mechanism is used to tweak the default settings to MORE on FreeBSD.
(merge 995bc22 ew/build-time-pager-tweaks later to maint).
* The http-backend (the server-side component of smart-http
transport) used to trickle the HTTP header one at a time. Now
these write(2)s are batched.
(merge b36045c ew/http-backend-batch-headers later to maint).
* When "git rebase" tries to compare set of changes on the updated
upstream and our own branch, it computes patch-id for all of these
changes and attempts to find matches. This has been optimized by
lazily computing the full patch-id (which is expensive) to be
compared only for changes that touch the same set of paths.
(merge ba67504 kw/patch-ids-optim later to maint).
* A handful of tests that were broken under gettext-poison build have
been fixed.
* The recent i18n patch we added during this cycle did a bit too much
refactoring of the messages to avoid word-legos; the repetition has
been reduced to help translators.
Also contains various documentation updates and code clean-ups.
Fixes since v2.9
----------------
Unless otherwise noted, all the fixes since v2.8 in the maintenance
track are contained in this release (see the maintenance releases'
notes for details).
* The commands in `git log` family take %C(auto) in a custom format
string. This unconditionally turned the color on, ignoring
--no-color or with --color=auto when the output is not connected to
a tty; this was corrected to make the format truly behave as
"auto".
* "git rev-list --count" whose walk-length is limited with "-n"
option did not work well with the counting optimized to look at the
bitmap index.
* "git show -W" (extend hunks to cover the entire function, delimited
by lines that match the "funcname" pattern) used to show the entire
file when a change added an entire function at the end of the file,
which has been fixed.
* The documentation set has been updated so that literal commands,
configuration variables and environment variables are consistently
typeset in fixed-width font and bold in manpages.
* "git svn propset" subcommand that was added in 2.3 days is
documented now.
* The documentation tries to consistently spell "GPG"; when
referring to the specific program name, "gpg" is used.
* "git reflog" stopped upon seeing an entry that denotes a branch
creation event (aka "unborn"), which made it appear as if the
reflog was truncated.
* The git-prompt scriptlet (in contrib/) was not friendly with those
who uses "set -u", which has been fixed.
* compat/regex code did not cleanly compile.
* A codepath that used alloca(3) to place an unbounded amount of data
on the stack has been updated to avoid doing so.
* "git update-index --add --chmod=+x file" may be usable as an escape
hatch, but not a friendly thing to force for people who do need to
use it regularly. "git add --chmod=+x file" can be used instead.
* Build improvements for gnome-keyring (in contrib/)
* "git status" used to say "working directory" when it meant "working
tree".
* Comments about misbehaving FreeBSD shells have been clarified with
the version number (9.x and before are broken, newer ones are OK).
* "git cherry-pick A" worked on an unborn branch, but "git
cherry-pick A..B" didn't.
* Fix an unintended regression in v2.9 that breaks "clone --depth"
that recurses down to submodules by forcing the submodules to also
be cloned shallowly, which many server instances that host upstream
of the submodules are not prepared for.
* Fix unnecessarily waste in the idiomatic use of ': ${VAR=default}'
to set the default value, without enclosing it in double quotes.
* Some platform-specific code had non-ANSI strict declarations of C
functions that do not take any parameters, which has been
corrected.
* The internal code used to show local timezone offset is not
prepared to handle timestamps beyond year 2100, and gave a
bogus offset value to the caller. Use a more benign looking
+0000 instead and let "git log" going in such a case, instead
of aborting.
* One among four invocations of readlink(1) in our test suite has
been rewritten so that the test can run on systems without the
command (others are in valgrind test framework and t9802).
* t/perf needs /usr/bin/time with GNU extension; the invocation of it
is updated to "gtime" on Darwin.
* A bug, which caused "git p4" while running under verbose mode to
report paths that are omitted due to branch prefix incorrectly, has
been fixed; the command said "Ignoring file outside of prefix" for
paths that are _inside_.
* The top level documentation "git help git" still pointed at the
documentation set hosted at now-defunct google-code repository.
Update it to point to https://git.github.io/htmldocs/git.html
instead.
* A helper function that takes the contents of a commit object and
finds its subject line did not ignore leading blank lines, as is
commonly done by other codepaths. Make it ignore leading blank
lines to match.
* For a long time, we carried an in-code comment that said our
colored output would work only when we use fprintf/fputs on
Windows, which no longer is the case for the past few years.
* "gc.autoPackLimit" when set to 1 should not trigger a repacking
when there is only one pack, but the code counted poorly and did
so.
* Add a test to specify the desired behaviour that currently is not
available in "git rebase -Xsubtree=...".
* More mark-up updates to typeset strings that are expected to
literally typed by the end user in fixed-width font.
* "git commit --amend --allow-empty-message -S" for a commit without
any message body could have misidentified where the header of the
commit object ends.
* "git rebase -i --autostash" did not restore the auto-stashed change
when the operation was aborted.
* Git does not know what the contents in the index should be for a
path added with "git add -N" yet, so "git grep --cached" should not
show hits (or show lack of hits, with -L) in such a path, but that
logic does not apply to "git grep", i.e. searching in the working
tree files. But we did so by mistake, which has been corrected.
* "git blame -M" missed a single line that was moved within the file.
* Fix recently introduced codepaths that are involved in parallel
submodule operations, which gave up on reading too early, and
could have wasted CPU while attempting to write under a corner
case condition.
* "git grep -i" has been taught to fold case in non-ascii locales
correctly.
* A test that unconditionally used "mktemp" learned that the command
is not necessarily available everywhere.
* There are certain house-keeping tasks that need to be performed at
the very beginning of any Git program, and programs that are not
built-in commands had to do them exactly the same way as "git"
potty does. It was easy to make mistakes in one-off standalone
programs (like test helpers). A common "main()" function that
calls cmd_main() of individual program has been introduced to
make it harder to make mistakes.
(merge de61ceb jk/common-main later to maint).
* The test framework learned a new helper test_match_signal to
check an exit code from getting killed by an expected signal.
* General code clean-up around a helper function to write a
single-liner to a file.
(merge 7eb6e10 jk/write-file later to maint).
* One part of "git am" had an oddball helper function that called
stuff from outside "his" as opposed to calling what we have "ours",
which was not gender-neutral and also inconsistent with the rest of
the system where outside stuff is usuall called "theirs" in
contrast to "ours".
* "git blame file" allowed the lineage of lines in the uncommitted,
unadded contents of "file" to be inspected, but it refused when
"file" did not appear in the current commit. When "file" was
created by renaming an existing file (but the change has not been
committed), this restriction was unnecessarily tight.
* "git add -N dir/file && git write-tree" produced an incorrect tree
when there are other paths in the same directory that sorts after
"file".
* "git fetch http://user:pass@host/repo..." scrubbed the userinfo
part, but "git push" didn't.
* "git merge" with renormalization did not work well with
merge-recursive, due to "safer crlf" conversion kicking in when it
shouldn't.
(merge 1335d76 jc/renormalize-merge-kill-safer-crlf later to maint).
* The use of strbuf in "git rm" to build filename to remove was a bit
suboptimal, which has been fixed.
* An age old bug that caused "git diff --ignore-space-at-eol"
misbehave has been fixed.
* "git notes merge" had a code to see if a path exists (and fails if
it does) and then open the path for writing (when it doesn't).
Replace it with open with O_EXCL.
* "git pack-objects" and "git index-pack" mostly operate with off_t
when talking about the offset of objects in a packfile, but there
were a handful of places that used "unsigned long" to hold that
value, leading to an unintended truncation.
* Recent update to "git daemon" tries to enable the socket-level
KEEPALIVE, but when it is spawned via inetd, the standard input
file descriptor may not necessarily be connected to a socket.
Suppress an ENOTSOCK error from setsockopt().
* Recent FreeBSD stopped making perl available at /usr/bin/perl;
switch the default the built-in path to /usr/local/bin/perl on not
too ancient FreeBSD releases.
* "git commit --help" said "--no-verify" is only about skipping the
pre-commit hook, and failed to say that it also skipped the
commit-msg hook.
* "git merge" in Git v2.9 was taught to forbid merging an unrelated
lines of history by default, but that is exactly the kind of thing
the "--rejoin" mode of "git subtree" (in contrib/) wants to do.
"git subtree" has been taught to use the "--allow-unrelated-histories"
option to override the default.
* The build procedure for "git persistent-https" helper (in contrib/)
has been updated so that it can be built with more recent versions
of Go.
* There is an optimization used in "git diff $treeA $treeB" to borrow
an already checked-out copy in the working tree when it is known to
be the same as the blob being compared, expecting that open/mmap of
such a file is faster than reading it from the object store, which
involves inflating and applying delta. This however kicked in even
when the checked-out copy needs to go through the convert-to-git
conversion (including the clean filter), which defeats the whole
point of the optimization. The optimization has been disabled when
the conversion is necessary.
* "git -c grep.patternType=extended log --basic-regexp" misbehaved
because the internal API to access the grep machinery was not
designed well.
* Windows port was failing some tests in t4130, due to the lack of
inum in the returned values by its lstat(2) emulation.
* The reflog output format is documented better, and a new format
--date=unix to report the seconds-since-epoch (without timezone)
has been added.
(merge 442f6fd jk/reflog-date later to maint).
* "git difftool <paths>..." started in a subdirectory failed to
interpret the paths relative to that directory, which has been
fixed.
* The characters in the label shown for tags/refs for commits in
"gitweb" output are now properly escaped for proper HTML output.
* FreeBSD can lie when asked mtime of a directory, which made the
untracked cache code to fall back to a slow-path, which in turn
caused tests in t7063 to fail because it wanted to verify the
behaviour of the fast-path.
* Squelch compiler warnings for nedmalloc (in compat/) library.
* A small memory leak in the command line parsing of "git blame"
has been plugged.
* The API documentation for hashmap was unclear if hashmap_entry
can be safely discarded without any other consideration. State
that it is safe to do so.
* Not-so-recent rewrite of "git am" that started making internal
calls into the commit machinery had an unintended regression, in
that no matter how many seconds it took to apply many patches, the
resulting committer timestamp for the resulting commits were all
the same.
* "git push --force-with-lease" already had enough logic to allow
ensuring that such a push results in creation of a ref (i.e. the
receiving end did not have another push from sideways that would be
discarded by our force-pushing), but didn't expose this possibility
to the users. It does so now.
(merge 9eed4f3 jk/push-force-with-lease-creation later to maint).
* The mechanism to limit the pack window memory size, when packing is
done using multiple threads (which is the default), is per-thread,
but this was not documented clearly.
(merge 954176c ms/document-pack-window-memory-is-per-thread later to maint).
* "import-tars" fast-import script (in contrib/) used to ignore a
hardlink target and replaced it with an empty file, which has been
corrected to record the same blob as the other file the hardlink is
shared with.
(merge 04e0869 js/import-tars-hardlinks later to maint).
* "git mv dir non-existing-dir/" did not work in some environments
the same way as existing mainstream platforms. The code now moves
"dir" to "non-existing-dir", without relying on rename("A", "B/")
that strips the trailing slash of '/'.
(merge 189d035 js/mv-dir-to-new-directory later to maint).
* The "t/" hierarchy is prone to get an unusual pathname; "make test"
has been taught to make sure they do not contain paths that cannot
be checked out on Windows (and the mechanism can be reusable to
catch pathnames that are not portable to other platforms as need
arises).
(merge c2cafd3 js/test-lint-pathname later to maint).
* When "git merge-recursive" works on history with many criss-cross
merges in "verbose" mode, the names the command assigns to the
virtual merge bases could have overwritten each other by unintended
reuse of the same piece of memory.
(merge 5447a76 rs/pull-signed-tag later to maint).
* "git checkout --detach <branch>" used to give the same advice
message as that is issued when "git checkout <tag>" (or anything
that is not a branch name) is given, but asking with "--detach" is
an explicit enough sign that the user knows what is going on. The
advice message has been squelched in this case.
(merge 779b88a sb/checkout-explit-detach-no-advice later to maint).
* "git difftool" by default ignores the error exit from the backend
commands it spawns, because often they signal that they found
differences by exiting with a non-zero status code just like "diff"
does; the exit status codes 126 and above however are special in
that they are used to signal that the command is not executable,
does not exist, or killed by a signal. "git difftool" has been
taught to notice these exit status codes.
(merge 45a4f5d jk/difftool-command-not-found later to maint).
* On Windows, help.browser configuration variable used to be ignored,
which has been corrected.
(merge 6db5967 js/no-html-bypass-on-windows later to maint).
* The "git -c var[=val] cmd" facility to append a configuration
variable definition at the end of the search order was described in
git(1) manual page, but not in git-config(1), which was more likely
place for people to look for when they ask "can I make a one-shot
override, and if so how?"
(merge ae1f709 dg/document-git-c-in-git-config-doc later to maint).
* The tempfile (hence its user lockfile) API lets the caller to open
a file descriptor to a temporary file, write into it and then
finalize it by first closing the filehandle and then either
removing or renaming the temporary file. When the process spawns a
subprocess after obtaining the file descriptor, and if the
subprocess has not exited when the attempt to remove or rename is
made, the last step fails on Windows, because the subprocess has
the file descriptor still open. Open tempfile with O_CLOEXEC flag
to avoid this (on Windows, this is mapped to O_NOINHERIT).
(merge 05d1ed6 bw/mingw-avoid-inheriting-fd-to-lockfile later to maint).
* Correct an age-old calco (is that a typo-like word for calc)
in the documentation.
(merge 7841c48 ls/packet-line-protocol-doc-fix later to maint).
* Other minor clean-ups and documentation updates
(merge 02a8cfa rs/merge-add-strategies-simplification later to maint).
(merge af4941d rs/merge-recursive-string-list-init later to maint).
(merge 1eb47f1 rs/use-strbuf-add-unique-abbrev later to maint).
(merge ddd0bfa jk/tighten-alloc later to maint).
(merge ecf30b2 rs/mailinfo-lib later to maint).
(merge 0eb75ce sg/reflog-past-root later to maint).
(merge 4369523 hv/doc-commit-reference-style later to maint).
----------------------------------------------------------------
Changes since v2.9.0 are as follows:
Alex Henrie (2):
unpack-trees: fix English grammar in do-this-before-that messages
l10n: ca.po: update translation
Alexander Hirsch (1):
pull: warn on --verify-signatures with --rebase
Alfred Perlstein (1):
git-svn: document the 'git svn propset' command
Andreas Brauchli (1):
gitweb: escape link body in format_ref_marker
Andrew Oakley (1):
git-p4: correct hasBranchPrefix verbose output
Antoine Queru (1):
upload-pack.c: use parse-options API
Armin Kunaschik (2):
t7800: readlink may not be available
t7610: test for mktemp before test execution
Ben Wijen (2):
t6026-merge-attr: child processes must not inherit index.lock handles
mingw: ensure temporary file handles are not inherited by child processes
Changwoo Ryu (1):
l10n: ko.po: Update Korean translation
Charles Bailey (4):
t7810: fix duplicated test title
t7810-grep.sh: fix duplicated test name
t7810-grep.sh: fix a whitespace inconsistency
grep: fix grepping for "intent to add" files
Chris Packham (1):
completion: add option '--recurse-submodules' to 'git clone'
Christian Couder (50):
builtin/apply: make gitdiff_verify_name() return void
builtin/apply: avoid parameter shadowing 'p_value' global
builtin/apply: avoid parameter shadowing 'linenr' global
builtin/apply: avoid local variable shadowing 'len' parameter
builtin/apply: extract line_by_line_fuzzy_match() from match_fragment()
builtin/apply: move 'options' variable into cmd_apply()
builtin/apply: move 'read_stdin' global into cmd_apply()
builtin/apply: introduce 'struct apply_state' to start libifying
builtin/apply: move 'state' init into init_apply_state()
builtin/apply: move 'unidiff_zero' global into 'struct apply_state'
builtin/apply: move 'check' global into 'struct apply_state'
builtin/apply: move 'check_index' global into 'struct apply_state'
builtin/apply: move 'apply_in_reverse' global into 'struct apply_state'
builtin/apply: move 'apply_with_reject' global into 'struct apply_state'
builtin/apply: move 'apply_verbosely' global into 'struct apply_state'
builtin/apply: move 'update_index' global into 'struct apply_state'
builtin/apply: move 'allow_overlap' global into 'struct apply_state'
builtin/apply: move 'cached' global into 'struct apply_state'
builtin/apply: move 'diffstat' global into 'struct apply_state'
builtin/apply: move 'numstat' global into 'struct apply_state'
builtin/apply: move 'summary' global into 'struct apply_state'
builtin/apply: move 'threeway' global into 'struct apply_state'
builtin/apply: move 'no_add' global into 'struct apply_state'
builtin/apply: move 'unsafe_paths' global into 'struct apply_state'
builtin/apply: move 'line_termination' global into 'struct apply_state'
builtin/apply: move 'fake_ancestor' global into 'struct apply_state'
builtin/apply: move 'p_context' global into 'struct apply_state'
builtin/apply: move 'apply' global into 'struct apply_state'
builtin/apply: move 'patch_input_file' global into 'struct apply_state'
builtin/apply: move 'limit_by_name' global into 'struct apply_state'
builtin/apply: move 'has_include' global into 'struct apply_state'
builtin/apply: move 'p_value' global into 'struct apply_state'
builtin/apply: move 'p_value_known' global into 'struct apply_state'
builtin/apply: move 'root' global into 'struct apply_state'
builtin/apply: move 'whitespace_error' global into 'struct apply_state'
builtin/apply: move 'whitespace_option' into 'struct apply_state'
builtin/apply: remove whitespace_option arg from set_default_whitespace_mode()
builtin/apply: move 'squelch_whitespace_errors' into 'struct apply_state'
builtin/apply: move 'applied_after_fixing_ws' into 'struct apply_state'
builtin/apply: move 'ws_error_action' into 'struct apply_state'
builtin/apply: move 'ws_ignore_action' into 'struct apply_state'
builtin/apply: move 'max_change' and 'max_len' into 'struct apply_state'
builtin/apply: move 'state_linenr' global into 'struct apply_state'
builtin/apply: move 'fn_table' global into 'struct apply_state'
builtin/apply: move 'symlink_changes' global into 'struct apply_state'
builtin/apply: move 'state' check into check_apply_state()
builtin/apply: move applying patches into apply_all_patches()
builtin/apply: add 'lock_file' pointer into 'struct apply_state'
builtin/apply: move 'newfd' global into 'struct apply_state'
.mailmap: use Christian Couder's Tuxfamily address
Christopher Layne (1):
git-svn: clone: Fail on missing url argument
Dave Nicolson (1):
Documentation: GPG capitalization
David A. Greene (1):
contrib/subtree: Add a test for subtree rebase that loses commits
David Aguilar (6):
t7900-subtree.sh: fix quoting and broken && chains
subtree: fix "git subtree split --rejoin"
subtree: adjust style to match CodingGuidelines
subtree: adjust function definitions to match CodingGuidelines
difftool: avoid $GIT_DIR and $GIT_WORK_TREE
difftool: use Git::* functions instead of passing around state
David Glasser (1):
doc: mention `git -c` in git-config(1)
David Kastrup (1):
blame: require 0 context lines while finding moved lines with -M
David Turner (3):
refs: allow log-only updates
refs: don't dereference on rename
mailmap: use main email address for dturner
Ed Maste (1):
rebase: update comment about FreeBSD /bin/sh
Edward Thomson (2):
format_commit_message: honor `color=auto` for `%C(auto)`
add: add --chmod=+x / --chmod=-x options
Elia Pinto (2):
http.c: implement the GIT_TRACE_CURL environment variable
imap-send.c: introduce the GIT_TRACE_CURL enviroment variable
Eric Sunshine (1):
blame: drop strdup of string literal
Eric Wong (24):
fast-import: implement unpack limit
daemon: enable SO_KEEPALIVE for all sockets
fast-import: invalidate pack_id references after loosening
pretty: support "mboxrd" output format
mailsplit: support unescaping mboxrd messages
am: support --patch-format=mboxrd
git-svn: skip mergeinfo handling with --no-follow-parent
gc: fix off-by-one error with gc.autoPackLimit
xread: retry after poll on EAGAIN/EWOULDBLOCK
xwrite: poll on non-blocking FDs
git-svn: warn instead of dying when commit data is missing
hoist out handle_nonblock function for xread and xwrite
config.mak.uname: define NEEDS_LIBRT under Linux, for now
http-walker: remove unused parameter from fetch_object
http: avoid disconnecting on 404s for loose objects
http-walker: reduce O(n) ops with doubly-linked list
list: avoid incompatibility with *BSD sys/queue.h
daemon: ignore ENOTSOCK from setsockopt
configure.ac: stronger test for pthread linkage
git-svn: document svn.authorsProg in config
git-svn: allow --version to work anywhere
git svn: migrate tests to use lib-httpd
pager: move pager-specific setup into the build
http-backend: buffer headers before sending
Heiko Becker (1):
gnome-keyring: Don't hard-code pkg-config executable
Heiko Voigt (4):
submodule-config: passing name reference for .gitmodule blobs
submodule-config: combine early return code into one goto
submodule-config: fix test binary crashing when no arguments given
SubmittingPatches: document how to reference previous commits
Ingo Brückl (3):
t3700: remove unwanted leftover files before running new tests
t3700: merge two tests into one
t3700: add a test_mode_in_index helper function
Jacob Keller (1):
completion: add completion for --submodule=* diff option
Jean-Noel Avila (4):
i18n: fix typos for translation
i18n: fix git rebase interactive commit messages
i18n: simplify numeric error reporting
l10n: fr.po v2.10.0-rc2
Jeff King (107):
git_config_with_options: drop "found" counting
git_config_parse_parameter: refactor cleanup code
config: set up config_source for command-line config
config: return configset value for current_config_ functions
config: add a notion of "scope"
upload-pack: provide a hook for running pack-objects
rev-list: "adjust" results of "--count --use-bitmap-index -n"
rev-list: disable bitmaps when "-n" is used with listing objects
tree-diff: avoid alloca for large allocations
send-pack: use buffered I/O to talk to pack-objects
parse_opt_string_list: stop allocating new strings
interpret-trailers: don't duplicate option strings
blame,shortlog: don't make local option variables static
use string_list initializer consistently
fetch: document that pruning happens before fetching
repack: document --unpack-unreachable option
repack: add --keep-unreachable option
repack: extend --keep-unreachable to loose objects
add--interactive: respect diff.compactionHeuristic
bisect: always call setup_revisions after init_revisions
gpg-interface: use child_process.args
verify_signed_buffer: drop pbuf variable
verify_signed_buffer: use tempfile object
run-command: add pipe_command helper
verify_signed_buffer: use pipe_command
sign_buffer: use pipe_command
t0006: rename test-date's "show" to "relative"
t0006: test various date formats
local_tzoffset: detect errors from tm_to_time_t
t/perf: fix regression in testing older versions of git
p4211: explicitly disable renames in no-rename test
color: fix max-size comment
doc: refactor description of color format
add skip_prefix_mem helper
color: refactor parse_attr
color: allow "no-" for negating attributes
color: support "italic" attribute
color: support strike-through attribute
t9300: factor out portable "head -c" replacement
t5000: test tar files that overflow ustar headers
archive-tar: write extended headers for file sizes >= 8GB
archive-tar: write extended headers for far-future mtime
archive-tar: drop return value
add an extra level of indirection to main()
common-main: call git_extract_argv0_path()
common-main: call sanitize_stdfds()
common-main: call restore_sigpipe_to_default()
common-main: call git_setup_gettext()
tests: factor portable signal check out of t0005
t0005: use test_match_signal as appropriate
test_must_fail: use test_match_signal
t/lib-git-daemon: use test_match_signal
parse_options: allocate a new array when concatenating
Makefile: drop extra dependencies for test helpers
Makefile: use VCSSVN_LIB to refer to svn library
config: fix bogus fd check when setting up default config
branch: use non-gentle write_file for branch description
write_file: drop "gently" form
write_file: use xopen
write_file: add pointer+len variant
write_file: add format attribute
use write_file_buf where applicable
branch: use write_file_buf instead of write_file
walker: let walker_say take arbitrary formats
avoid using sha1_to_hex output as printf format
push: anonymize URL in status output
t0006: skip "far in the future" test when unsigned long is not long enough
check_everything_connected: always pass --quiet to rev-list
rev-list: add optional progress reporting
check_everything_connected: convert to argv_array
check_everything_connected: use a struct with named options
check_connected: relay errors to alternate descriptor
check_connected: add progress flag
clone: use a real progress meter for connectivity check
index-pack: add flag for showing delta-resolution progress
receive-pack: turn on index-pack resolving progress
receive-pack: relay connectivity errors to sideband
receive-pack: turn on connectivity progress
receive-pack: send keepalives during quiet periods
t5541: fix url scrubbing test when GPG is not set
diff: do not reuse worktree files that need "clean" conversion
contrib/git-jump: fix greedy regex when matching hunks
contrib/git-jump: add whitespace-checking mode
contrib/git-jump: fix typo in README
doc/rev-list-options: clarify "commit@{Nth}" for "-g" option
doc/rev-list-options: explain "-g" output formats
doc/pretty-formats: describe index/time formats for %gd
doc/pretty-formats: explain shortening of %gd
t4205: drop top-level &&-chaining
t4205: indent here documents
date: document and test "raw-local" mode
date: add "unix" format
t/perf: add tests for many-pack scenarios
sha1_file: drop free_pack_by_name
add generic most-recently-used list
find_pack_entry: replace last_found_pack with MRU cache
pack-objects: break out of want_object loop early
pack-objects: compute local/ignore_pack_keep early
am: reset cached ident date for each patch
trace: handle NULL argument in trace_disable()
trace: stop using write_or_whine_pipe()
trace: use warning() for printing trace errors
trace: cosmetic fixes for error messages
trace: correct variable name in write() error message
trace: disable key after write error
write_or_die: drop write_or_whine_pipe()
trace: do not fall back to stderr
Jiang Xin (3):
l10n: git.pot: v2.10.0 round 1 (248 new, 56 removed)
l10n: git.pot: v2.10.0 round 2 (12 new, 44 removed)
l10n: zh_CN: for git v2.10.0 l10n round 2
Joey Hess (1):
clarify %f documentation
Johannes Schindelin (59):
mingw: let the build succeed with DEVELOPER=1
perf: accommodate for MacOSX
pretty: make the skip_blank_lines() function public
commit.c: make find_commit_subject() more robust
t2300: "git --exec-path" is not usable in $PATH on Windows as-is
log: prepare log/log-tree to reuse the diffopt.close_file attribute
log-tree: respect diffopt's configured output file stream
line-log: respect diffopt's configured output file stream
graph: respect the diffopt.file setting
shortlog: support outputting to streams other than stdout
format-patch: explicitly switch off color when writing to files
format-patch: avoid freopen()
format-patch: use stdout directly
shortlog: respect the --output=<file> setting
t4211: ensure that log respects --output=<file>
color.h: remove obsolete comment about limitations on Windows
diff: do not color output when --color=auto and --output=<file> is given
t3404: fix a grammo (commands are ran -> commands are run)
commit -C: skip blank lines at the beginning of the message
sequencer: use skip_blank_lines() to find the commit subject
reset --hard: skip blank lines when reporting the commit subject
commit -S: avoid invalid pointer with empty message
mingw: declare main()'s argv as const
t3404: add a test for the --gpg-sign option
rebase -i: demonstrate a bug with --autosquash
rebase -i: we allow extra spaces after fixup!/squash!
am: counteract gender bias
diff: demonstrate a bug with --patience and --ignore-space-at-eol
diff: fix a double off-by-one with --ignore-space-at-eol
t/test-lib.sh: fix running tests with --valgrind
mingw: fix the shortlog --output=<file> test
mingw: fix regression in t1308-config-set
fsck: refactor how to describe objects
fsck_walk(): optionally name objects on the go
fsck: give the error function a chance to see the fsck_options
fsck: optionally show more helpful info for broken links
t5520: verify that `pull --rebase` shows the helpful advice when failing
die("bug"): report bugs consistently
die(_("BUG")): avoid translating bug messages
merge-recursive: clarify code in was_tracked()
prepare the builtins for a libified merge_recursive()
merge_recursive: abort properly upon errors
merge-recursive: avoid returning a wholesale struct
merge-recursive: allow write_tree_from_memory() to error out
merge-recursive: handle return values indicating errors
merge-recursive: switch to returning errors instead of dying
am -3: use merge_recursive() directly again
merge-recursive: flush output buffer before printing error messages
merge-recursive: write the commit title in one go
merge-recursive: offer an option to retain the output in 'obuf'
merge_trees(): ensure that the callers release output buffer
merge-recursive: flush output buffer even when erroring out
import-tars: support hard links
t5533: make it pass on case-sensitive filesystems
nedmalloc: fix misleading indentation
git mv: do not keep slash in `git mv dir non-existing-dir/`
t/Makefile: ensure that paths are valid on platforms we care
rev-parse: respect core.hooksPath in --git-path
Revert "display HTML in default browser using Windows' shell API"
Johannes Sixt (7):
Windows: add missing definition of ENOTSOCK
git-submodule: forward exit code of git-submodule--helper more faithfully
submodule-helper: fix indexing in clone retry error reporting path
rebase-interactive: trim leading whitespace from progress count
t4130: work around Windows limitation
config.c: avoid duplicated global static variables
commit-slab.h: avoid duplicated global static variables
John Keeping (5):
difftool: fix argument handling in subdirs
Documentation/git-push: fix placeholder formatting
push: add shorthand for --force-with-lease branch creation
push: allow pushing new branches with --force-with-lease
difftool: always honor fatal error exit codes
Jonathan Nieder (1):
doc: git-htmldocs.googlecode.com is no more
Jonathan Tan (1):
fetch-pack: grow stateless RPC windows exponentially
Jordan DE GEA (1):
worktree: allow "-" short-hand for @{-1} in add command
Josef Kufner (1):
pretty: pass graph width to pretty formatting for use in '%>|(N)'
Josh Triplett (1):
format-patch: format.from gives the default for --from
Junio C Hamano (44):
send-email: detect and offer to skip backup files
pathspec: rename free_pathspec() to clear_pathspec()
t1308: do not get fooled by symbolic links to the source tree
builtin/apply: remove misleading comment on lock_file field
blame, line-log: do not loop around deref_tag()
Start the post-2.9 cycle
clone: do not let --depth imply --shallow-submodules
Start preparing for 2.9.1
Second batch of topics for 2.10
More fixes for 2.9.1
Third batch of topics for 2.10
commit.c: remove print_commit_list()
Fourth batch of topics for 2.10
Git 2.9.1
merge: avoid "safer crlf" during recording of merge results
Fifth batch of topics for 2.10
diff: document diff-filter exclusion
Git 2.9.2
archive-tar: huge offset and future timestamps would not work on 32-bit
Sixth batch of topics for 2.10
grep: further simplify setting the pattern type
Seventh batch of topics for 2.10
date: clarify --date=raw description
Some fixes for 2.9.3
t9100: portability fix
Eighth batch of topics for 2.10
hashmap: clarify that hashmap_entry can safely be discarded
Ninth batch of topics for 2.10
Tenth batch for 2.10
Hopefully final batch for 2.9.3
Eleventh batch for 2.10
Yet another batch for 2.9.3
Twelfth batch for 2.10
Git 2.9.3
Final batch before 2.10-rc0
Git 2.10-rc0
Relnotes: decribe the updates to the "text=auto" attribute
relnotes: redo the description of text=auto fix
RelNotes: final batch of topics before -rc1
Git 2.10-rc1
Prepare for 2.10.0-rc2
Git 2.10-rc2
A few more fixes before the final 2.10
Git 2.10
Keith McGuigan (1):
builtin/fetch.c: don't free remote->name after fetch
Kevin Willford (4):
patch-ids: stop using a hand-rolled hashmap implementation
patch-ids: replace the seen indicator with a commit pointer
patch-ids: add flag to create the diff patch id using header only data
rebase: avoid computing unnecessary patch IDs
LE Manh Cuong (1):
sh-setup: enclose setting of ${VAR=default} in double-quotes
Lars Schneider (3):
git-p4: place temporary refs used for branch import under refs/git-p4-tmp
travis-ci: enable web server tests t55xx on Linux
pack-protocol: fix maximum pkt-line size
Lars Vogel (1):
Use "working tree" instead of "working directory" for git status
Linus Torvalds (1):
gpg-interface: prefer "long" key format output when verifying pgp signatures
Lukas Fleischer (4):
receive-pack: send auto-gc output over sideband 2
sideband.c: make send_sideband() return void
upload-pack.c: make send_client_data() return void
sideband.c: refactor recv_sideband()
Matthieu Moy (9):
Documentation/git-mv.txt: fix whitespace indentation
doc: typeset short command-line options as literal
doc: typeset long command-line options as literal
doc: typeset '--' as literal
doc: typeset long options with argument as literal
CodingGuidelines: formatting HEAD in documentation
doc: typeset HEAD and variants as literal
status: suggest 'git merge --abort' when appropriate
git-multimail: update to release 1.4.0
Mehul Jain (3):
t4202: refactor test
log: add "--no-show-signature" command line option
log: add log.showSignature configuration variable
Michael Haggerty (50):
t1404: demonstrate a bug resolving references
commit_ref(): if there is an empty dir in the way, delete it
read_raw_ref(): don't get confused by an empty directory
safe_create_leading_directories(): improve docstring
remove_dir_recursively(): add docstring
refname_is_safe(): use skip_prefix()
refname_is_safe(): don't allow the empty string
refname_is_safe(): insist that the refname already be normalized
commit_ref_update(): write error message to *err, not stderr
rename_ref(): remove unneeded local variable
ref_transaction_commit(): remove local variables n and updates
read_raw_ref(): rename flags argument to type
read_raw_ref(): clear *type at start of function
read_raw_ref(): rename symref argument to referent
read_raw_ref(): improve docstring
read_raw_ref(): move docstring to header file
lock_ref_sha1_basic(): remove unneeded local variable
refs: make error messages more consistent
ref_transaction_create(): disallow recursive pruning
ref_transaction_commit(): correctly report close_ref() failure
delete_branches(): use resolve_refdup()
verify_refname_available(): adjust constness in declaration
add_update(): initialize the whole ref_update
lock_ref_for_update(): new function
unlock_ref(): move definition higher in the file
ref_transaction_update(): check refname_is_safe() at a minimum
refs: resolve symbolic refs first
lock_ref_for_update(): don't re-read non-symbolic references
lock_ref_for_update(): don't resolve symrefs
commit_ref_update(): remove the flags parameter
lock_ref_sha1_basic(): only handle REF_NODEREF mode
refs: remove unnecessary "extern" keywords
do_for_each_ref(): move docstring to the header file
refs: use name "prefix" consistently
delete_refs(): add a flags argument
remote rm: handle symbolic refs correctly
get_ref_cache(): only create an instance if there is a submodule
entry_resolves_to_object(): rename function from ref_resolves_to_object()
ref_resolves_to_object(): new function
refs: introduce an iterator interface
do_for_each_ref(): reimplement using reference iteration
for_each_reflog(): don't abort for bad references
dir_iterator: new API for iterating over a directory tree
for_each_reflog(): reimplement using iterators
t1404: rename file to t1404-update-ref-errors.sh
t1404: remove "prefix" argument to test_update_rejected
t1404: document function test_update_rejected
t1404: add more tests of update-ref error handling
lock_ref_for_update(): make error handling more uniform
lock_ref_for_update(): avoid a symref resolution
Michael J Gruber (7):
cherry-pick: allow to pick to unborn branches
Documentation/technical: describe signature formats
Documentation/technical: signed tag format
Documentation/technical: signed commit format
Documentation/technical: signed merge tag format
gpg-interface: check gpg signature creation status
t/t91*: do not say how to avoid the tests
Michael Stahl (1):
document git-repack interaction of pack.threads and pack.windowMemory
Mike Hommey (2):
blame: allow to blame paths freshly added to the index
t/t8003-blame-corner-cases.sh: Use here documents
Nguyễn Thái Ngọc Duy (47):
completion: support git-worktree
worktree.c: rewrite mark_current_worktree() to avoid strbuf
git-worktree.txt: keep subcommand listing in alphabetical order
worktree.c: use is_dot_or_dotdot()
worktree: avoid 0{40}, too many zeroes, hard to read
worktree: simplify prefixing paths
worktree.c: add find_worktree()
worktree.c: add is_main_worktree()
lib-httpd.sh: print error.log on error
worktree.c: add is_worktree_locked()
pretty.c: support <direction>|(<negative number>) forms
new-command.txt: correct the command description file
grep: break down an "if" stmt in preparation for next changes
test-regex: isolate the bug test code
test-regex: expose full regcomp() to the command line
grep/icase: avoid kwsset on literal non-ascii strings
git-fetch.txt: document fetch output
fetch: refactor ref update status formatting code
fetch: change flag code for displaying tag update and deleted ref
grep/icase: avoid kwsset when -F is specified
grep: rewrite an if/else condition to avoid duplicate expression
grep/pcre: prepare locale-dependent tables for icase matching
gettext: add is_utf8_locale()
grep/pcre: support utf-8
diffcore-pickaxe: Add regcomp_or_die()
diffcore-pickaxe: support case insensitive match on non-ascii
grep.c: reuse "icase" variable
fetch: align all "remote -> local" output
fetch: reduce duplicate in ref update status lines with placeholder
connect: read $GIT_SSH_COMMAND from config file
worktree: add "lock" command
worktree: add "unlock" command
worktree.c: find_worktree() search by path suffix
pack-objects: pass length to check_pack_crc() without truncation
log: decorate HEAD -> branch with the same color for arrow and HEAD
sha1_file.c: use type off_t* for object_info->disk_sizep
index-pack: correct "len" type in unpack_data()
index-pack: report correct bad object offsets even if they are large
index-pack: correct "offset" type in unpack_entry_data()
pack-objects: do not truncate result in-pack object size on 32-bit systems
fsck: use streaming interface for large blobs in pack
test-lib.sh: introduce and use $EMPTY_TREE
test-lib.sh: introduce and use $EMPTY_BLOB
cache-tree.c: fix i-t-a entry skipping directory updates sometimes
cache-tree: do not generate empty trees as a result of all i-t-a subentries
config.mak.uname: correct perl path on FreeBSD
t7063: work around FreeBSD's lazy mtime update feature
Nicolas Pitre (1):
sideband.c: small optimization of strbuf usage
Orgad Shaneh (1):
commit: describe that --no-verify skips the commit-msg hook in the help text
Parker Moore (2):
contrib/persistent-https: update ldflags syntax for Go 1.7+
contrib/persistent-https: use Git version for build label
Patrick Steinhardt (1):
rebase -i: restore autostash on abort
Peter Colberg (2):
refs.h: fix misspelt "occurred" in a comment
config.c: fix misspelt "occurred" in an error message
Peter Krefting (1):
l10n: sv.po: Update Swedish translation (2757t0f0u)
Pranit Bauva (2):
builtin/commit.c: memoize git-path for COMMIT_EDITMSG
strbuf: describe the return value of strbuf_read_file
Ramsay Jones (2):
regex: fix a SIZE_MAX macro redefinition warning
write_or_die: remove the unused write_or_whine() function
René Scharfe (34):
t4051: rewrite, add more tests
xdiff: factor out match_func_rec()
xdiff: handle appended chunks better with -W
xdiff: ignore empty lines before added functions with -W
xdiff: -W: don't include common trailing empty lines in context
xdiff: don't trim common tail with -W
t7810: add test for grep -W and trailing empty context lines
grep: -W: don't extend context to trailing empty lines
xdiff: fix merging of appended hunk with -W
.gitattributes: set file type for C files
notes-merge: use O_EXCL to avoid overwriting existing files
am: ignore return value of write_file()
rm: reuse strbuf for all remove_dir_recursively() calls
worktree: use strbuf_add_absolute_path() directly
use strbuf_addbuf() for appending a strbuf to another
submodule-config: use explicit empty string instead of strbuf in config_from()
strbuf: avoid calling strbuf_grow() twice in strbuf_addbuf()
use strbuf_addstr() for adding constant strings to a strbuf
pass constants as first argument to st_mult()
use strbuf_addstr() instead of strbuf_addf() with "%s"
use CHILD_PROCESS_INIT to initialize automatic variables
merge-recursive: use STRING_LIST_INIT_NODUP
merge: use string_list_split() in add_strategies()
nedmalloc: work around overzealous GCC 6 warning
archive-tar: make write_extended_header() void
use strbuf_add_unique_abbrev() for adding short hashes
correct FLEXPTR_* example in comment
mailinfo: recycle strbuf in check_header()
commit: use xstrdup() in get_merge_parent()
commit: factor out set_merge_remote_desc()
merge-recursive: fix verbose output for multiple base trees
commit: use FLEX_ARRAY in struct merge_remote_desc
receive-pack: use FLEX_ALLOC_MEM in queue_command()
p3400: make test script executable
Ronald Wampler (1):
Makefile: add NEEDS_LIBRT to optionally link with librt
SZEDER Gábor (2):
reflog: continue walking the reflog past root commits
t1410: remove superfluous 'git reflog' from the 'walk past root' test
Stefan Beller (23):
submodule update: make use of the existing fetch_in_submodule function
submodule-config: keep shallow recommendation around
submodule update: learn `--[no-]recommend-shallow` option
submodule--helper: initial clone learns retry logic
submodule update: continue when a clone fails
t5614: don't use subshells
push options: {pre,post}-receive hook learns about push options
receive-pack: implement advertising and receiving push options
push: accept push options
add a test for push options
Documentation: pack-protocol correct NAK response
submodule deinit: remove outdated comment
t7406: future proof tests with hard coded depth
submodule update: respect depth in subsequent fetches
submodule update: narrow scope of local variable
submodule--helper: fix usage string for relative-path
submodule-config: keep configured branch around
gitmodules: document shallow recommendation
submodule--helper: add remote-branch helper
submodule update: allow '.' for branch value
submodule--helper: use parallel processor correctly
t7406: fix breakage on OSX
checkout: do not mention detach advice for explicit --detach option
Thomas Braun (3):
completion: factor out untracked file modes into a variable
completion: add __git_get_option_value helper
completion: add git status
Thomas Gummerer (1):
blame: fix segfault on untracked files
Tom Russello (4):
doc: clearer rule about formatting literals
doc: change environment variables format
doc: more consistency in environment variables format
doc: change configuration variables format
Torsten Bögershausen (4):
convert: unify the "auto" handling of CRLF
convert: Correct NNO tests and missing `LF will be replaced by CRLF`
git ls-files: text=auto eol=lf is supported in Git 2.10
gitattributes: Document the unified "auto" handling
Trần Ngọc Quân (2):
l10n: Updated Vietnamese translation for v2.10.0 (2789t)
l10n: Updated Vietnamese translation for v2.10.0-rc2 (2757t)
Vasco Almeida (49):
i18n: builtin/remote.c: fix mark for translation
i18n: advice: mark string about detached head for translation
i18n: advice: internationalize message for conflicts
i18n: transport: mark strings for translation
i18n: sequencer: mark entire sentences for translation
i18n: rebase-interactive: mark here-doc strings for translation
i18n: sequencer: mark string for translation
i18n: rebase-interactive: mark comments of squash for translation
i18n: merge-octopus: mark messages for translation
i18n: setup: mark strings for translation
merge-octopus: use die shell function from git-sh-setup.sh
tests: use test_i18n* functions to suppress false positives
i18n: rebase: fix marked string to use eval_gettext variant
tests: unpack-trees: update to use test_i18n* functions
i18n: rebase: mark placeholder for translation
t9003: become resilient to GETTEXT_POISON
i18n: bisect: simplify error message for i18n
t4153: fix negated test_i18ngrep call
t6030: update to use test_i18ncmp
t5523: use test_i18ngrep for negation
i18n: git-sh-setup.sh: mark strings for translation
i18n: bisect: mark strings for translation
i18n: rebase-interactive: mark strings for translation
i18n: transport-helper.c: change N_() call to _()
i18n: notes: mark strings for translation
i18n: notes: mark options for translation
i18n: merge: mark messages for translation
i18n: merge: change command option help to lowercase
i18n: sequencer: add period to error message
i18n: standardise messages
i18n: remote: mark URL fallback text for translation
i18n: remote: allow translations to reorder message
i18n: init-db: join message pieces
i18n: submodule: join strings marked for translation
i18n: submodule: escape shell variables inside eval_gettext
i18n: unmark die messages for translation
i18n: branch: mark comment when editing branch description for translation
t5541: become resilient to GETTEXT_POISON
t5510: skip tests under GETTEXT_POISON build
i18n: notes: mark comment for translation
i18n: config: unfold error messages marked for translation
i18n: setup: mark error messages for translation
i18n: archive: mark errors for translation
i18n: git-stash: mark messages for translation
t3404: become resilient to GETTEXT_POISON
t5520: become resilient to GETTEXT_POISON
t7411: become resilient to GETTEXT_POISON
l10n: pt_PT: merge git.pot
l10n: pt_PT: update Portuguese translation
Ville Skyttä (3):
git-prompt.sh: Don't error on null ${ZSH,BASH}_VERSION, $short_sha
completion: complete --delete, --move, and --remotes for git branch
Spelling fixes
William Duclot (1):
userdiff: add built-in pattern for CSS
brian m. carlson (11):
hex: add oid_to_hex_r()
contrib/coccinelle: add basic Coccinelle transforms
coccinelle: convert hashcpy() with null_sha1 to hashclr()
coccinelle: apply object_id Coccinelle transformations
diff: convert struct diff_filespec to struct object_id
diff: rename struct diff_filespec's sha1_valid member
merge-recursive: convert struct stage_data to use object_id
merge-recursive: convert struct merge_file_info to object_id
merge-recursive: convert leaf functions to use struct object_id
merge-recursive: convert merge_recursive_generic() to object_id
diff: convert prep_temp_blob() to struct object_id
^ permalink raw reply
* A note from the maintainer
From: Junio C Hamano @ 2016-09-03 2:17 UTC (permalink / raw)
To: git
Welcome to the Git development community.
This message is written by the maintainer and talks about how Git
project is managed, and how you can work with it.
* Mailing list and the community
The development is primarily done on the Git mailing list. Help
requests, feature proposals, bug reports and patches should be sent to
the list address <git@vger.kernel.org>. You don't have to be
subscribed to send messages. The convention on the list is to keep
everybody involved on Cc:, so it is unnecessary to say "Please Cc: me,
I am not subscribed".
Before sending patches, please read Documentation/SubmittingPatches
and Documentation/CodingGuidelines to familiarize yourself with the
project convention.
If you sent a patch and you did not hear any response from anybody for
several days, it could be that your patch was totally uninteresting,
but it also is possible that it was simply lost in the noise. Please
do not hesitate to send a reminder message in such a case. Messages
getting lost in the noise may be a sign that those who can evaluate
your patch don't have enough mental/time bandwidth to process them
right at the moment, and it often helps to wait until the list traffic
becomes calmer before sending such a reminder.
The list archive is available at a few public sites:
http://public-inbox.org/git/
http://marc.info/?l=git
http://www.spinics.net/lists/git/
For those who prefer to read it over NNTP:
nntp://news.gmane.org/gmane.comp.version-control.git
nntp://news.public-inbox.org/inbox.comp.version-control.git
are available.
When you point at a message in a mailing list archive, using its
message ID is often the most robust (if not very friendly) way to do
so, like this:
http://public-inbox.org/git/Pine.LNX.4.58.0504150753440.7211@ppc970.osdl.org
Often these web interfaces accept the message ID with enclosing <>
stripped (like the above example to point at one of the most important
message in the Git list).
Some members of the development community can sometimes be found on
the #git and #git-devel IRC channels on Freenode. Their logs are
available at:
http://colabti.org/irclogger/irclogger_log/git
http://colabti.org/irclogger/irclogger_log/git-devel
There is a volunteer-run newsletter to serve our community ("Git Rev
News" http://git.github.io/rev_news/rev_news.html).
Git is a member project of software freedom conservancy, a non-profit
organization (https://sfconservancy.org/). To reach a committee of
liaisons to the conservancy, contact them at <git@sfconservancy.org>.
* Reporting bugs
When you think git does not behave as you expect, please do not stop
your bug report with just "git does not work". "I used git in this
way, but it did not work" is not much better, neither is "I used git
in this way, and X happend, which is broken". It often is that git is
correct to cause X happen in such a case, and it is your expectation
that is broken. People would not know what other result Y you expected
to see instead of X, if you left it unsaid.
Please remember to always state
- what you wanted to achieve;
- what you did (the version of git and the command sequence to reproduce
the behavior);
- what you saw happen (X above);
- what you expected to see (Y above); and
- how the last two are different.
See http://www.chiark.greenend.org.uk/~sgtatham/bugs.html for further
hints.
If you think you found a security-sensitive issue and want to disclose
it to us without announcing it to wider public, please contact us at
our security mailing list <git-security@googlegroups.com>. This is
a closed list that is limited to people who need to know early about
vulnerabilities, including:
- people triaging and fixing reported vulnerabilities
- people operating major git hosting sites with many users
- people packaging and distributing git to large numbers of people
where these issues are discussed without risk of the information
leaking out before we're ready to make public announcements.
* Repositories and documentation.
My public git.git repositories are at:
git://git.kernel.org/pub/scm/git/git.git/
https://kernel.googlesource.com/pub/scm/git/git
git://repo.or.cz/alt-git.git/
https://github.com/git/git/
git://git.sourceforge.jp/gitroot/git-core/git.git/
git://git-core.git.sourceforge.net/gitroot/git-core/git-core/
A few web interfaces are found at:
http://git.kernel.org/cgit/git/git.git
https://kernel.googlesource.com/pub/scm/git/git
http://repo.or.cz/w/alt-git.git
Preformatted documentation from the tip of the "master" branch can be
found in:
git://git.kernel.org/pub/scm/git/git-{htmldocs,manpages}.git/
git://repo.or.cz/git-{htmldocs,manpages}.git/
https://github.com/gitster/git-{htmldocs,manpages}.git/
The manual pages formatted in HTML for the tip of 'master' can be
viewed online at:
https://git.github.io/htmldocs/git.html
* How various branches are used.
There are four branches in git.git repository that track the source tree
of git: "master", "maint", "next", and "pu".
The "master" branch is meant to contain what are very well tested and
ready to be used in a production setting. Every now and then, a
"feature release" is cut from the tip of this branch. They used to be
named with three dotted decimal digits (e.g. "1.8.5"), but recently we
switched the versioning scheme and "feature releases" are named with
three-dotted decimal digits that ends with ".0" (e.g. "1.9.0").
The last such release was 2.10 done on Sep 2nd, 2016. You can expect
that the tip of the "master" branch is always more stable than any of
the released versions.
Whenever a feature release is made, "maint" branch is forked off from
"master" at that point. Obvious and safe fixes after a feature
release are applied to this branch and maintenance releases are cut
from it. Usually the fixes are merged to the "master" branch first,
several days before merged to the "maint" branch, to reduce the chance
of last-minute issues. The maintenance releases used to be named with
four dotted decimal, named after the feature release they are updates
to (e.g. "1.8.5.1" was the first maintenance release for "1.8.5"
feature release). These days, maintenance releases are named by
incrementing the last digit of three-dotted decimal name (e.g. "2.9.3"
is the third maintenance release for the "2.9" series).
New features never go to the 'maint' branch. This branch is also
merged into "master" to propagate the fixes forward as needed.
A new development does not usually happen on "master". When you send a
series of patches, after review on the mailing list, a separate topic
branch is forked from the tip of "master" and your patches are queued
there, and kept out of "master" while people test it out. The quality of
topic branches are judged primarily by the mailing list discussions.
Topic branches that are in good shape are merged to the "next" branch. In
general, the "next" branch always contains the tip of "master". It might
not be quite rock-solid, but is expected to work more or less without major
breakage. The "next" branch is where new and exciting things take place. A
topic that is in "next" is expected to be polished to perfection before it
is merged to "master". Please help this process by building & using the
"next" branch for your daily work, and reporting any new bugs you find to
the mailing list, before the breakage is merged down to the "master".
The "pu" (proposed updates) branch bundles all the remaining topic
branches the maintainer happens to have seen. There is no guarantee that
the maintainer has enough bandwidth to pick up any and all topics that
are remotely promising from the list traffic, so please do not read
too much into a topic being on (or not on) the "pu" branch. This
branch is mainly to remind the maintainer that the topics in them may
turn out to be interesting when they are polished, nothing more. The
topics on this branch aren't usually complete, well tested, or well
documented and they often need further work. When a topic that was
in "pu" proves to be in a testable shape, it is merged to "next".
You can run "git log --first-parent master..pu" to see what topics are
currently in flight. Sometimes, an idea that looked promising turns out
to be not so good and the topic can be dropped from "pu" in such a case.
The two branches "master" and "maint" are never rewound, and "next"
usually will not be either. After a feature release is made from
"master", however, "next" will be rebuilt from the tip of "master"
using the topics that didn't make the cut in the feature release.
Note that being in "next" is not a guarantee to appear in the next
release, nor even in any future release. There were cases that topics
needed reverting a few commits in them before graduating to "master",
or a topic that already was in "next" was reverted from "next" because
fatal flaws were found in it after it was merged to "next".
* Other people's trees.
Documentation/SubmittingPatches outlines to whom your proposed changes
should be sent. As described in contrib/README, I would delegate fixes
and enhancements in contrib/ area to the primary contributors of them.
Although the following are included in git.git repository, they have their
own authoritative repository and maintainers:
- git-gui/ comes from git-gui project, maintained by Pat Thoyts:
git://repo.or.cz/git-gui.git
- gitk-git/ comes from Paul Mackerras's gitk project:
git://ozlabs.org/~paulus/gitk
- po/ comes from the localization coordinator, Jiang Xin:
https://github.com/git-l10n/git-po/
When sending proposed updates and fixes to these parts of the system,
please base your patches on these trees, not git.git (the former two
even have different directory structures).
^ permalink raw reply
* Re: [PATCH 2/2] connect: know that zero-ID is not a ref
From: Shawn Pearce @ 2016-09-03 2:03 UTC (permalink / raw)
To: Jeff King; +Cc: Jonathan Tan, git
In-Reply-To: <20160902201321.35egsg5l6r2fvrtw@sigill.intra.peff.net>
On Fri, Sep 2, 2016 at 1:13 PM, Jeff King <peff@peff.net> wrote:
>
> Hmm. So since this is backwards-compatible, I'm not overly concerned
> with changing the client. But I wonder if you considered that the
> documentation is wrong, and that JGit should stop sending the extra
> capabilities line?
No, JGit needs to keep sending the capabilities^{} line in upload-pack
if there were no refs advertised to the client. (If it advertises at
least one ref it does not send this capabilities^{} line.)
> In either case, there will still be breakage until _somebody_ upgrades
> (with your patch, until clients upgrade; with a JGit patch, until the
> server upgrades). So perhaps an interesting question would be: if we
> were writing this now, what is the correct behavior?
>
> For pushing, it is obviously useful to send capabilities even though
> there are no refs (because the client is going to send _you_ something).
> And that is why "capabilities^{}" exists; it is a receive-pack feature
> (that is actually implemented!), and the documentation (which came after
> the implementation) blindly mentioned it for upload-pack, as well.
>
> Is it useful for upload-pack? If we have no refs, there's traditionally
> been nothing to fetch. Perhaps that's something that could change,
> though. For example, there could be a capability to allow fetching
> arbitrary sha1s (we have allowTIPSH1InWant and allowReachableSHA1InWant,
> which obviously both require some refs, but allowArbitrarySHA1 does not
> seem outside the realm of possibility).
Its exactly these sort of extra capabilities. We run JGit in modes
where "out of band" (e.g. URL or higher level protocol framing like an
undocumented HTTP header) allows the fetch-pack client to say "do not
send me advertisements, but I want to learn your capabilities". The
fetch-pack client typically activates the allow-reachable-sha1-in-want
feature and names specific SHA-1s it wants.
This allows the fetch-pack client to bypass a very large advertisement
if it wants only a specific SHA-1 and doesn't care about the ref name
its bound to, or reachable through.
This is also perhaps a stepping stone towards "client speaks first".
If we can later standardize an HTTP query parameter or extra HTTP
header, the server may be able to avoid sending a lot of ref
advertisements, but would still need to advertise capabilities.
^ permalink raw reply
* Re: [PATCH v2 2/2] connect: advertized capability is not a ref
From: Jeff King @ 2016-09-03 0:56 UTC (permalink / raw)
To: Jonathan Nieder; +Cc: Jonathan Tan, git, spearce, sbeller
In-Reply-To: <20160902235145.GI14758@google.com>
On Fri, Sep 02, 2016 at 04:51:45PM -0700, Jonathan Nieder wrote:
> > I'd be more interested in the pain of this transition if there was a
> > concrete use case for "hide literally all refs, but still allow
> > fetches". Is that a thing that people do?
>
> Sure, it is a thing that people do. For example I've seen replication
> systems that learn what SHA-1s to fetch out-of-band and then use this
> approach to avoid the overhead of a long ref advertisement.
I know that's how those features work. I was more wondering if it ever
comes up that somebody actually has hidden refs, but _no_ non-hidden
ones. Do the systems you've seen hide all the refs?
> However, that is not my motivation. My motivation is being able to
> extend the protocol in the future. The capabilities line has been
> important for that historically.
Sure, I agree it's a nice move forward for compatibility. But that
argues for teaching the clients to handle it (for the future), and then
turning it on in the server only when it becomes useful (i.e., the "in a
year or so" can become "when we find a use for it").
In a similar vein, I'd think that a config to enable this in upload-pack
today could have an "auto" mode, which enables it _only_ when you know
something productive might come of it (namely that you have hidden refs,
one of the uploadpack.allow* features is enabled, and the ref
advertisement is empty). Then requests which could not benefit from it
at all do not have to pay the potential compatibility cost.
> Do you have any objection to the server gaining support for this
> guarded by a configuration option? Then when the time comes to
> consider flipping the default we can use real-world statistics about
> what git client versions people use to make an informed decision.
Guarded by config, no. It's the flipping of the default I care more
about. The config is not necessary in the meantime for getting
real-world statistics; you can add the config and flip the default as
one unit at any time (the thing that is time-critical is teaching the
client to handle _both_ cases gracefully).
The config is useful in the meantime if there are people who could
benefit from it immediately, and don't mind paying the compatibility
cost. With an "auto" as I described above, using that as the default
seems like a decent interim behavior (i.e., why would you set up such a
repository if you didn't expect most clients to use the allowTipSHA1
feature?). I'd still probably give some lag between shipping the client,
and flipping the server default to "auto".
I hoped to share some numbers on what versions people are currently
using against GitHub, to get a sense of how far back most people are.
But I haven't been actively involved in keeping those numbers for a
while, and I'm not sure what we have readily stored. I did show some
numbers a few years ago[1], and it looks like about 2/3 of people were
within 6-12 months of the latest version, but the rest was a long tail.
I don't know if that will have changed with the advent of more client
versions (e.g., lots more people are using libgit2 now via GUI clients,
Visual Studio, etc; how does it fare with the proposed change?).
-Peff
[1] http://public-inbox.org/git/20120531114801.GA21367@sigill.intra.peff.net/
^ permalink raw reply
* Re: Bug Report: Too many untracked files (gitignore)
From: Brian Levinstein @ 2016-09-03 0:52 UTC (permalink / raw)
To: Stefan Beller; +Cc: git@vger.kernel.org
In-Reply-To: <CAGZ79kYhV30AuXUKtp3oewMpnEk5vD=HvRUJTTFaEdsacu3tGw@mail.gmail.com>
The patterns in question do contain a slash, although they don't start
with a slash.
I tried changing it to "!/.vim/colors/*" as you recommended, with no
change in behavior. I even tried adding a leading slash to every
pattern in gitignore, with no effect.
Removing the line with "!/.vim/colors/*" still fixes the problem.
Brian Levinstein
blevinstein@gmail.com | bpl4ab@virginia.edu
(703) 673-8711
Google | Software Engineer
University of Virginia | MS Commerce 2014
University of Virginia | BS Computer Science 2013
Alpha Tau Omega | Delta Chapter
http://www.linkedin.com/pub/brian-levinstein/14/620/6ba
https://github.com/blevinstein
On Fri, Sep 2, 2016 at 4:58 PM, Stefan Beller <sbeller@google.com> wrote:
> On Fri, Sep 2, 2016 at 4:06 PM, Brian Levinstein <blevinstein@gmail.com> wrote:
>> The relevant repo is here:
>> https://github.com/blevinstein/dotfiles
>>
>> My gitignore file looks like this:
>> https://github.com/blevinstein/dotfiles/blob/2400ca8642a7b454a2bfc54e8402343d008836aa/.gitignore
>> It basically ignores all files, except for specifically whitelisted
>> files. However, when I run "git status" (git version
>> 2.8.0.rc3.226.g39d4020), I see the following untracked files:
>>
>> # .bash_history
>> # .bash_logout
>> # .cache/
>> # [private]
>> # [private]
>> # .profile
>> # .viminfo
>> # dev/
>
> For the specific files to be exclued, I'd recommend starting with a slash, e.g.
>
> !/.bashrc
> !/.vim/colors/*
>
> If the pattern does not contain a slash /, Git treats it as a shell
> glob pattern and checks
> for a match against the pathname relative to the location of the
> .gitignore file (relative
> to the toplevel of the work tree if not from a .gitignore file).
>
> See the notes section of https://git-scm.com/docs/gitignore
>
> So I do not quite see the bug?
>
> Stefan
^ permalink raw reply
* Re: [PATCH v2 2/2] connect: advertized capability is not a ref
From: Jonathan Nieder @ 2016-09-03 0:37 UTC (permalink / raw)
To: Stefan Beller; +Cc: Jeff King, Jonathan Tan, git@vger.kernel.org, Shawn Pearce
In-Reply-To: <CAGZ79ka0VvXbkR+JYJwK9oyRzcsDXDoqKXyp4F+moDc4qDuv7w@mail.gmail.com>
Stefan Beller wrote:
> On Fri, Sep 2, 2016 at 4:35 PM, Jeff King <peff@peff.net> wrote:
>> I'd be more interested in the pain of this transition if there was a
>> concrete use case for "hide literally all refs, but still allow
>> fetches". Is that a thing that people do?
[...]
> Not to derail the discussion to much, but let's talk about protocol v2
> for a second:
Uh oh. ;-)
> One of the ideas we floated around for protocol v2 would be exactly
> that: the server advertises only a small portion (could be just master
> or no branch eventually) with a capability "v2" and then the client
> selects that capability and after that there comes protocol 2.
Sounds scary to me. What would happen when I try to clone a
repository with a v1 client? I'd see nothing. I'd want at least a
"master" branch with a README file (or an ERR packet?) saying "please
update your client".
> The advantage of this approach would be have a functional
> v1 server still running, but the meat is found only in v2: e.g. via
> v2 you can obtain all pull requests/changes or even wiki/meta
> information stuff that would be too large to advertise in v1.
This sounds less scary, but it doesn't answer the question Peff
raised. Wouldn't it still be typical to advertise at least one ref,
which can contain a capabilities line?
However, another idea I think you've mentioned before on-list about
changing the ref advertisement could answer it. Suppose that I always
include the ref advertisement in my first reply, but I provide a
capability saying that further requests to this server can use a
different mechanism that skips the long advertisement.
Normally that would work great --- I only pay the cost of the large
advertisement once, and from then on I can cache what the server told
me about how it prefers to be contacted. Except what happens if this
was a new repository and my first contact with the server was to clone
that empty repository?
In that case, getting capabilities with the ref advertisement would
benefit me.
Likewise for other capabilities that may come with such an empty
fetch: for example the server could tell which unborn branch the HEAD
symref points to.
Thanks,
Jonathan
^ permalink raw reply
* Re: Bug Report: Too many untracked files (gitignore)
From: Stefan Beller @ 2016-09-02 23:58 UTC (permalink / raw)
To: Brian Levinstein; +Cc: git@vger.kernel.org
In-Reply-To: <CAMbP-nS_MM0QXgw183DLQPx1YU1BH8ytKCv86p-JSxzdb2jpQA@mail.gmail.com>
On Fri, Sep 2, 2016 at 4:06 PM, Brian Levinstein <blevinstein@gmail.com> wrote:
> The relevant repo is here:
> https://github.com/blevinstein/dotfiles
>
> My gitignore file looks like this:
> https://github.com/blevinstein/dotfiles/blob/2400ca8642a7b454a2bfc54e8402343d008836aa/.gitignore
> It basically ignores all files, except for specifically whitelisted
> files. However, when I run "git status" (git version
> 2.8.0.rc3.226.g39d4020), I see the following untracked files:
>
> # .bash_history
> # .bash_logout
> # .cache/
> # [private]
> # [private]
> # .profile
> # .viminfo
> # dev/
For the specific files to be exclued, I'd recommend starting with a slash, e.g.
!/.bashrc
!/.vim/colors/*
If the pattern does not contain a slash /, Git treats it as a shell
glob pattern and checks
for a match against the pathname relative to the location of the
.gitignore file (relative
to the toplevel of the work tree if not from a .gitignore file).
See the notes section of https://git-scm.com/docs/gitignore
So I do not quite see the bug?
Stefan
^ permalink raw reply
* Re: [PATCH v2 2/2] connect: advertized capability is not a ref
From: Jonathan Nieder @ 2016-09-02 23:51 UTC (permalink / raw)
To: Jeff King; +Cc: Jonathan Tan, git, spearce, sbeller
In-Reply-To: <20160902233547.mzgluioc7hhabalw@sigill.intra.peff.net>
Jeff King wrote:
> On Fri, Sep 02, 2016 at 03:06:12PM -0700, Jonathan Tan wrote:
> But combining hideRefs with
> allowTipSHA1InWant could trigger this case.
Yes.
[...]
> I'd be more interested in the pain of this transition if there was a
> concrete use case for "hide literally all refs, but still allow
> fetches". Is that a thing that people do?
Sure, it is a thing that people do. For example I've seen replication
systems that learn what SHA-1s to fetch out-of-band and then use this
approach to avoid the overhead of a long ref advertisement.
However, that is not my motivation. My motivation is being able to
extend the protocol in the future. The capabilities line has been
important for that historically.
Do you have any objection to the server gaining support for this
guarded by a configuration option? Then when the time comes to
consider flipping the default we can use real-world statistics about
what git client versions people use to make an informed decision.
Thanks,
Jonathan
^ permalink raw reply
* Re: [PATCH v2 2/2] connect: advertized capability is not a ref
From: Stefan Beller @ 2016-09-02 23:48 UTC (permalink / raw)
To: Jeff King
Cc: Jonathan Tan, git@vger.kernel.org, Jonathan Nieder, Shawn Pearce
In-Reply-To: <20160902233547.mzgluioc7hhabalw@sigill.intra.peff.net>
On Fri, Sep 2, 2016 at 4:35 PM, Jeff King <peff@peff.net> wrote:
> I'd be more interested in the pain of this transition if there was a
> concrete use case for "hide literally all refs, but still allow
> fetches". Is that a thing that people do?
>
Not yet, I would think.
Not to derail the discussion to much, but let's talk about protocol v2
for a second:
One of the ideas we floated around for protocol v2 would be exactly
that: the server advertises only a small portion (could be just master
or no branch eventually) with a capability "v2" and then the client
selects that capability and after that there comes protocol 2.
The advantage of this approach would be have a functional
v1 server still running, but the meat is found only in v2: e.g. via
v2 you can obtain all pull requests/changes or even wiki/meta
information stuff that would be too large to advertise in v1.
^ permalink raw reply
* Re: [PATCH v2 2/2] connect: advertized capability is not a ref
From: Jeff King @ 2016-09-02 23:35 UTC (permalink / raw)
To: Jonathan Tan; +Cc: git, jrnieder, spearce, sbeller
In-Reply-To: <174c8ca6638f1cd3145a628925e65655b56af366.1472853827.git.jonathantanmy@google.com>
On Fri, Sep 02, 2016 at 03:06:12PM -0700, Jonathan Tan wrote:
> The cause is that, since v3.1.0.201309270735-rc1~22 (Advertise capabilities
> with no refs in upload service., 2013-08-08), JGit's ref advertisement includes
> a ref named capabilities^{} to advertise its capabilities on, while git's ref
> advertisement is empty in this case. This allows the client to learn about the
> server's capabilities and is needed, for example, for fetch-by-sha1 to work
> when no refs are advertised.
So does JGit actually have a fetch-by-sha1 that works in such a case
(obviously the repository has to have _some_ objects, so is this a
feature where the server hides some of the refs?).
I was thinking we did not have one in git (i.e., we have nothing to
allow fetching arbitrary sha1s). But combining hideRefs with
allowTipSHA1InWant could trigger this case.
> This also affects "ls-remote". For example, against an empty repository served
> by JGit:
>
> $ git ls-remote git://localhost/tmp/empty
> 0000000000000000000000000000000000000000 capabilities^{}
>
> Git advertises the same capabilities^{} ref in its ref advertisement for push
> but since it never remembered to do so for fetch, the client forgot to handle
> this case. Handle it.
As you can probably guess from my previous emails in this thread, I
don't think it is "never remembered to do so". It is more like "never
intended to do so and was documented incorrectly".
That doesn't make things clear cut, of course. But I think the real
story is more like (I dug a little in the history, as you'll see, but
didn't look for conversations in the list archive, so take this with the
appropriate grain of salt):
0. Upload-pack existed without this capabilities^{} trick for some time.
1. Receive-pack learned the capabilities^{} trick, and send-pack on
the client side learned to accept it (this looks like it came along
with the first capability in cfee10a (send-pack/receive-pack: allow
errors to be reported back to pusher., 2005-12-25).
2. Later, b31222c (Update packfile transfer protocol documentation,
2009-11-03) tried to document the upload-pack and receive-pack
protocols, but mistakenly documented both as having
capabilities^{}.
3. In ae1f469 (Advertise capabilities with no refs in upload service.,
2013-08-08), JGit started sending these in its upload-pack
equivalent, according to the documentation from (3).
So now we are in a state where JGit behavior does not match Git
behavior. Since JGit versions have existed in the wild for a few years,
it's a good idea for all clients to be liberal and accept both cases.
> In this aspect, JGit is compliant with the specification in pack-protocol.txt.
> Because git client versions without this fix are expected to exist in the wild
> for a while, we should not change the server to always send the capabilities^{}
> line when there are no refs to advertise yet. A transition will take multiple
> steps:
>
> 1. This patch, which updates the client
>
> 2. Update pack-protocol to clarify that both server behaviors must be
> tolerated.
These two seem like obvious improvements.
> 3. Add a configuration variable to allow git upload-pack to advertise
> capabilities when there are no refs to advertise. Leave it disabled
> by default since git clients can't be counted on to have this patch (1)
> yet.
>
> 4. After a year or so, flip the default for that server configuration
> variable to true.
I think "a year or so" is not nearly long enough, as this is not a
backwards-compatible change. The only thing that mitigates it is that an
older client doesn't barf totally, but just generates funny output.
I'd be more interested in the pain of this transition if there was a
concrete use case for "hide literally all refs, but still allow
fetches". Is that a thing that people do?
-Peff
^ permalink raw reply
* Re: [PATCH 2/2] connect: know that zero-ID is not a ref
From: Jeff King @ 2016-09-02 23:19 UTC (permalink / raw)
To: Jonathan Tan; +Cc: git
In-Reply-To: <84df7985-6c87-9485-261c-e8e9a3bbab7b@google.com>
On Fri, Sep 02, 2016 at 03:11:16PM -0700, Jonathan Tan wrote:
> On 09/02/2016 01:13 PM, Jeff King wrote:
> > On Fri, Sep 02, 2016 at 10:15:39AM -0700, Jonathan Tan wrote:
> > > (git-daemon should probably also be changed to serve zero IDs, but such
> > > a change can be considered independently from this change; even if both
> > > the client and server changes were made in one commit, it is nearly
> > > impossible that all Git installations are updated at the same time - an
> > > updated client would still need to deal with unupdated servers and vice
> > > versa.)
> >
> > I'm really not sure what you mean here. How does git-daemon enter into
> > this at all?
>
> I was comparing the behavior of git daemon and jgit daemon - when serving
> the same repository, the former does not send the zero ID and
> capabilities^{} line, whereas the latter does; and I was stating that git
> daemon's behavior should be changed to JGit's behavior, but not necessarily
> immediately.
Ah, I see. I was confused because it's git-upload-pack, not git-daemon,
which would be modified (git-daemon may also spawn other tools like
receive-pack, which _does_ already have this behavior).
I remain unconvinced that we should transition to the JGit behavior on
the server side (as opposed to "fixing" the documentation). However,
given that JGit versions with this behavior are in the wild, it seems
like a no-brainer to make the receiver more liberal (i.e., this series).
-Peff
^ permalink raw reply
* Bug Report: Too many untracked files (gitignore)
From: Brian Levinstein @ 2016-09-02 23:06 UTC (permalink / raw)
To: git
The relevant repo is here:
https://github.com/blevinstein/dotfiles
My gitignore file looks like this:
https://github.com/blevinstein/dotfiles/blob/2400ca8642a7b454a2bfc54e8402343d008836aa/.gitignore
It basically ignores all files, except for specifically whitelisted
files. However, when I run "git status" (git version
2.8.0.rc3.226.g39d4020), I see the following untracked files:
# .bash_history
# .bash_logout
# .cache/
# [private]
# [private]
# .profile
# .viminfo
# dev/
I can fix this by removing the following line from my gitignore:
!.vim/colors/*
after which all the untracked files disappear. I also tried changing
that line to:
!.vim/colors/twilight256.vim
but it had no effect.
The same effect can be achieved with any directory name starting with a period:
!.tmux/asdf
!.vim/asdf
where .tmux and .vim are real directories. It does not seem to matter
whether the "asdf" subdirectory exists at all.
Brian Levinstein
blevinstein@gmail.com | bpl4ab@virginia.edu
(703) 673-8711
Google | Software Engineer
University of Virginia | MS Commerce 2014
University of Virginia | BS Computer Science 2013
Alpha Tau Omega | Delta Chapter
http://www.linkedin.com/pub/brian-levinstein/14/620/6ba
https://github.com/blevinstein
^ permalink raw reply
* Re: [PATCH v2 2/2] connect: advertized capability is not a ref
From: Jonathan Nieder @ 2016-09-02 22:40 UTC (permalink / raw)
To: Jonathan Tan; +Cc: git, spearce, sbeller, peff
In-Reply-To: <174c8ca6638f1cd3145a628925e65655b56af366.1472853827.git.jonathantanmy@google.com>
Jonathan Tan wrote:
> Signed-off-by: Jonathan Tan <jonathantanmy@google.com>
> ---
> connect.c | 3 +++
> t/t5512-ls-remote.sh | 39 +++++++++++++++++++++++++++++++++++++++
> 2 files changed, 42 insertions(+)
Reviewed-by: Jonathan Nieder <jrnieder@gmail.com>
Thanks.
^ permalink raw reply
* Re: Fixup of a fixup not working right
From: Philip Oakley @ 2016-09-02 22:24 UTC (permalink / raw)
To: Robert Dailey, Git
In-Reply-To: <CAHd499AQFDRps6POF2xuUjbYv5DJYxt3DA8aFFArXF=qQEz_CA@mail.gmail.com>
From: "Robert Dailey" <rcdailey.lists@gmail.com>
> Suppose I have a branch with 4 commits, in the following order (as you
> might see during interactive rebase):
>
> pick 123 Original Change
> pick 789 fixup! Original Change
> pick 456 Some Other Thing
> pick abc fixup! fixup! Original Change
>
> However, let's say the first commit is already pushed upstream on a
> topic branch. Since there are multiple developers on this topic
> branch, I do not want to rebase right now. Instead, I want to document
> future fixups via fixup commits and then when we're ready to merge, do
> a final rebase prior to the merge to master to clean things up after
> we're all done collaborating.
>
> For this specific situation, since the first commit is already pushed,
> I want to perform a fixup on the 1st fixup commit. When I perform an
> interactive rebase against upstream topic, I get the following:
>
> pick 789 fixup! Original Change
> pick 456 Some Other Thing
> pick abc fixup! fixup! Original Change
>
> The tip commit (abc in this case) is not marked as a fixup. What I
> expect to see is:
>
> pick 789 fixup! Original Change
> fixup abc fixup! fixup! Original Change
> pick 456 Some Other Thing
>
> Is this by design, or a defect? I assumed that Git would only look at
> the first occurrence of "fixup!" and treat everything else after as
> the commit description to match. But it seems in this case that it
> stops at the last occurrence of "fixup!", which would explain why it
> isn't matching in the interactive rebase. I haven't looked at the
> code, though.
As I understand this it's implied by design. The issue is that the rebase is
looking for that named commit within its current rebase range, and can't
find it, so ignores it.
There is a separate issue that all the fixup! fixup! messages are
essentially treated as being concatenations of the original fixup!, no
matter how many time the fiup is present.
In the mean time you should reword those commit messages as being
'bug-fixes' as they are (you say) already upstream and hence published. You
can make the first as a bug-fix and the following ones a fixup!s.
>
> Thoughts? Also I'm perfectly willing to accept feedback involving me
> just using the feature wrong or as not intended. Thanks in advance.
>
^ permalink raw reply
* Re: [PATCH 2/2] connect: know that zero-ID is not a ref
From: Jonathan Tan @ 2016-09-02 22:11 UTC (permalink / raw)
To: Jeff King; +Cc: git
In-Reply-To: <20160902201321.35egsg5l6r2fvrtw@sigill.intra.peff.net>
On 09/02/2016 01:13 PM, Jeff King wrote:
> On Fri, Sep 02, 2016 at 10:15:39AM -0700, Jonathan Tan wrote:
>> (git-daemon should probably also be changed to serve zero IDs, but such
>> a change can be considered independently from this change; even if both
>> the client and server changes were made in one commit, it is nearly
>> impossible that all Git installations are updated at the same time - an
>> updated client would still need to deal with unupdated servers and vice
>> versa.)
>
> I'm really not sure what you mean here. How does git-daemon enter into
> this at all?
I was comparing the behavior of git daemon and jgit daemon - when
serving the same repository, the former does not send the zero ID and
capabilities^{} line, whereas the latter does; and I was stating that
git daemon's behavior should be changed to JGit's behavior, but not
necessarily immediately.
(In one of the replies to that email, Jonathan Nieder has suggested a
more detailed transition plan.)
>> diff --git a/t/t5512-ls-remote.sh b/t/t5512-ls-remote.sh
>> index 819b9dd..c6f8b6f 100755
>> --- a/t/t5512-ls-remote.sh
>> +++ b/t/t5512-ls-remote.sh
>> @@ -207,5 +207,27 @@ test_expect_success 'ls-remote --symref omits filtered-out matches' '
>> test_cmp expect actual
>> '
>>
>> +test_lazy_prereq GIT_DAEMON '
>> + test_have_prereq JGIT &&
>> + test_tristate GIT_TEST_GIT_DAEMON &&
>> + test "$GIT_TEST_GIT_DAEMON" != false
>> +'
>
> GIT_DAEMON depends on JGIT? Should this really be the JGIT_DAEMON
> prerequisite?
The JGIT line shouldn't be there - thanks for catching this.
^ permalink raw reply
* [PATCH v2 2/2] connect: advertized capability is not a ref
From: Jonathan Tan @ 2016-09-02 22:06 UTC (permalink / raw)
To: git; +Cc: Jonathan Tan, jrnieder, spearce, sbeller, peff
In-Reply-To: <cover.1472853827.git.jonathantanmy@google.com>
When cloning an empty repository served by standard git, "git clone" produces
the following reassuring message:
$ git clone git://localhost/tmp/empty
Cloning into 'empty'...
warning: You appear to have cloned an empty repository.
Checking connectivity... done.
Meanwhile when cloning an empty repository served by JGit, the output is more
haphazard:
$ git clone git://localhost/tmp/empty
Cloning into 'empty'...
Checking connectivity... done.
warning: remote HEAD refers to nonexistent ref, unable to checkout.
This is a common command to run immediately after creating a remote repository
as preparation for adding content to populate it and pushing. The warning is
confusing and needlessly worrying.
The cause is that, since v3.1.0.201309270735-rc1~22 (Advertise capabilities
with no refs in upload service., 2013-08-08), JGit's ref advertisement includes
a ref named capabilities^{} to advertise its capabilities on, while git's ref
advertisement is empty in this case. This allows the client to learn about the
server's capabilities and is needed, for example, for fetch-by-sha1 to work
when no refs are advertised.
This also affects "ls-remote". For example, against an empty repository served
by JGit:
$ git ls-remote git://localhost/tmp/empty
0000000000000000000000000000000000000000 capabilities^{}
Git advertises the same capabilities^{} ref in its ref advertisement for push
but since it never remembered to do so for fetch, the client forgot to handle
this case. Handle it.
In this aspect, JGit is compliant with the specification in pack-protocol.txt.
Because git client versions without this fix are expected to exist in the wild
for a while, we should not change the server to always send the capabilities^{}
line when there are no refs to advertise yet. A transition will take multiple
steps:
1. This patch, which updates the client
2. Update pack-protocol to clarify that both server behaviors must be
tolerated.
3. Add a configuration variable to allow git upload-pack to advertise
capabilities when there are no refs to advertise. Leave it disabled
by default since git clients can't be counted on to have this patch (1)
yet.
4. After a year or so, flip the default for that server configuration
variable to true.
Signed-off-by: Jonathan Tan <jonathantanmy@google.com>
---
connect.c | 3 +++
t/t5512-ls-remote.sh | 39 +++++++++++++++++++++++++++++++++++++++
2 files changed, 42 insertions(+)
diff --git a/connect.c b/connect.c
index 722dc3f..0c2221e 100644
--- a/connect.c
+++ b/connect.c
@@ -165,6 +165,9 @@ struct ref **get_remote_heads(int in, char *src_buf, size_t src_len,
continue;
}
+ if (!strcmp(name, "capabilities^{}"))
+ continue;
+
if (!check_ref(name, flags))
continue;
ref = alloc_ref(buffer + GIT_SHA1_HEXSZ + 1);
diff --git a/t/t5512-ls-remote.sh b/t/t5512-ls-remote.sh
index 819b9dd..2de52f5 100755
--- a/t/t5512-ls-remote.sh
+++ b/t/t5512-ls-remote.sh
@@ -207,5 +207,44 @@ test_expect_success 'ls-remote --symref omits filtered-out matches' '
test_cmp expect actual
'
+test_lazy_prereq GIT_DAEMON '
+ test_tristate GIT_TEST_GIT_DAEMON &&
+ test "$GIT_TEST_GIT_DAEMON" != false
+'
+
+JGIT_DAEMON_PORT=${JGIT_DAEMON_PORT-${this_test#t}}
+
+# This test spawns a daemon, so run it only if the user would be OK with
+# testing with git-daemon.
+test_expect_success PIPE,JGIT,GIT_DAEMON 'indicate no refs in standards-compliant empty remote' '
+ JGIT_DAEMON_PID= &&
+ git init --bare empty.git &&
+ touch empty.git/git-daemon-export-ok &&
+ mkfifo jgit_daemon_output &&
+ {
+ jgit daemon --port="$JGIT_DAEMON_PORT" . >jgit_daemon_output &
+ JGIT_DAEMON_PID=$!
+ } &&
+ test_when_finished kill "$JGIT_DAEMON_PID" &&
+ {
+ read line &&
+ case $line in
+ Exporting*)
+ ;;
+ *)
+ echo "Expected: Exporting" &&
+ false;;
+ esac &&
+ read line &&
+ case $line in
+ "Listening on"*)
+ ;;
+ *)
+ echo "Expected: Listening on" &&
+ false;;
+ esac
+ } <jgit_daemon_output &&
+ test_expect_code 2 git ls-remote --exit-code git://localhost:$JGIT_DAEMON_PORT/empty.git
+'
test_done
--
2.8.0.rc3.226.g39d4020
^ permalink raw reply related
* [PATCH v2 1/2] tests: move test_lazy_prereq JGIT to test-lib.sh
From: Jonathan Tan @ 2016-09-02 22:06 UTC (permalink / raw)
To: git; +Cc: Jonathan Tan, jrnieder, spearce, sbeller, peff
In-Reply-To: <cover.1472853827.git.jonathantanmy@google.com>
This enables JGIT to be used as a prereq in invocations of
test_expect_success (and other functions) in other test scripts.
Signed-off-by: Jonathan Tan <jonathantanmy@google.com>
---
t/t5310-pack-bitmaps.sh | 4 ----
t/test-lib.sh | 4 ++++
2 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/t/t5310-pack-bitmaps.sh b/t/t5310-pack-bitmaps.sh
index 3893afd..1e376ea 100755
--- a/t/t5310-pack-bitmaps.sh
+++ b/t/t5310-pack-bitmaps.sh
@@ -158,10 +158,6 @@ test_expect_success 'pack with missing parent' '
git pack-objects --stdout --revs <revs >/dev/null
'
-test_lazy_prereq JGIT '
- type jgit
-'
-
test_expect_success JGIT 'we can read jgit bitmaps' '
git clone . compat-jgit &&
(
diff --git a/t/test-lib.sh b/t/test-lib.sh
index d731d66..c9c1037 100644
--- a/t/test-lib.sh
+++ b/t/test-lib.sh
@@ -1072,6 +1072,10 @@ test_lazy_prereq NOT_ROOT '
test "$uid" != 0
'
+test_lazy_prereq JGIT '
+ type jgit
+'
+
# SANITY is about "can you correctly predict what the filesystem would
# do by only looking at the permission bits of the files and
# directories?" A typical example of !SANITY is running the test
--
2.8.0.rc3.226.g39d4020
^ permalink raw reply related
* [PATCH v2 0/2] handle empty spec-compliant remote repos correctly
From: Jonathan Tan @ 2016-09-02 22:06 UTC (permalink / raw)
To: git; +Cc: Jonathan Tan, jrnieder, spearce, sbeller, peff
In-Reply-To: <cover.1472836026.git.jonathantanmy@google.com>
Thanks - I've updated the following:
o better patch description as suggested by Jonathan Nieder
o checking for capabilities^{} - all such lines are ignored without any further
checks, similar to the behavior for .have
o minor fix to test_lazy_prereq GIT_DAEMON
o test waits for output of `jgit daemon` (instead of sleeping)
Jonathan Tan (2):
tests: move test_lazy_prereq JGIT to test-lib.sh
connect: advertized capability is not a ref
connect.c | 3 +++
t/t5310-pack-bitmaps.sh | 4 ----
t/t5512-ls-remote.sh | 39 +++++++++++++++++++++++++++++++++++++++
t/test-lib.sh | 4 ++++
4 files changed, 46 insertions(+), 4 deletions(-)
--
2.8.0.rc3.226.g39d4020
^ permalink raw reply
* Re: [PATCH 01/34] sequencer: support a new action: 'interactive rebase'
From: Kevin Daudt @ 2016-09-02 21:13 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git, Junio C Hamano
In-Reply-To: <5ffec2e588a4edc4902e1ab3a2ec3a73a7c3625b.1472633606.git.johannes.schindelin@gmx.de>
On Wed, Aug 31, 2016 at 10:54:02AM +0200, Johannes Schindelin wrote:
> @@ -43,16 +51,20 @@ static GIT_PATH_FUNC(rebase_path_gpg_sign_opt, "rebase-merge/gpg_sign_opt")
> /* We will introduce the 'interactive rebase' mode later */
> static inline int is_rebase_i(const struct replay_opts *opts)
> {
> - return 0;
> + return opts->action == REPLAY_INTERACTIVE_REBASE;
> }
>
> static const char *get_dir(const struct replay_opts *opts)
> {
> + if (is_rebase_i(opts))
> + return rebase_path();
> return git_path_seq_dir();
> }
>
> static const char *get_todo_path(const struct replay_opts *opts)
> {
> + if (is_rebase_i(opts))
> + return rebase_path_todo();
> return git_path_todo_file();
> }
This patch fails to apply for me because function is_rebase_i has never
been introduced before (no record of it anywhere). Currently, only
IS_REBASE_I macro is present.
^ permalink raw reply
* Re: [PATCH 6/9] rebase -i: check for missing commits in the rebase--helper
From: Dennis Kaarsemaker @ 2016-09-02 20:59 UTC (permalink / raw)
To: Johannes Schindelin, git; +Cc: Junio C Hamano
In-Reply-To: <6d28acb59d7c217f1f8d6d364e5a52c8bde35085.1472833365.git.johannes.schindelin@gmx.de>
On vr, 2016-09-02 at 18:23 +0200, Johannes Schindelin wrote:
> In particular on Windows, where shell scripts are even more expensive
> than on MacOSX or Linux, it makes sense to move a loop that forks
> Git at least once for every line in the todo list into a builtin.
Heh, this was the one thing that made me hesitate sending the
suggestion about rebase-helper --edit-todo, but with this bit already
moved, I think rebase-helper --edit-todo makes even more sense to do.
D.
^ 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