* [PATCH] reset: --unmerge
From: Junio C Hamano @ 2016-10-24 23:10 UTC (permalink / raw)
To: git
The procedure to resolve a merge conflict typically goes like this:
- first open the file in the editor, and with the help of conflict
markers come up with a resolution.
- save the file.
- look at the output from "git diff" to see the combined diff to
double check if the resolution makes sense.
- perform other tests, like trying to build the result with "make".
- finally "git add file" to mark that you are done.
and repeating the above until you are done with all the conflicted
paths. If you, for whatever reason, accidentally "git add file" by
mistake until you are convinced that you resolved it correctly (e.g.
doing "git add file" immediately after saving, without a chance to
peruse the output from "git diff"), there is no good way to recover.
There is "git checkout -m file" but that overwrites the working tree
file to reproduce the conflicted state, which is not exactly what
you want. You only want to reproduce the conflicted state in the
index, so that you can inspect the (proposed) merge resolution you
already have in your working tree.
Add "git reset --unmerge <paths>" command that does just that.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
* Not thought through thoroughly yet about details, such as "should
it always require at least one pathspec?".
builtin/reset.c | 8 +++++++-
t/t7107-reset-unmerged.sh | 36 ++++++++++++++++++++++++++++++++++++
2 files changed, 43 insertions(+), 1 deletion(-)
diff --git a/builtin/reset.c b/builtin/reset.c
index 9020ec66c8..3aa9e0b34a 100644
--- a/builtin/reset.c
+++ b/builtin/reset.c
@@ -21,6 +21,7 @@
#include "parse-options.h"
#include "unpack-trees.h"
#include "cache-tree.h"
+#include "resolve-undo.h"
static const char * const git_reset_usage[] = {
N_("git reset [--mixed | --soft | --hard | --merge | --keep] [-q] [<commit>]"),
@@ -272,6 +273,7 @@ int cmd_reset(int argc, const char **argv, const char *prefix)
struct object_id oid;
struct pathspec pathspec;
int intent_to_add = 0;
+ int unmerge = 0;
const struct option options[] = {
OPT__QUIET(&quiet, N_("be quiet, only report errors")),
OPT_SET_INT(0, "mixed", &reset_type,
@@ -286,6 +288,8 @@ int cmd_reset(int argc, const char **argv, const char *prefix)
OPT_BOOL('p', "patch", &patch_mode, N_("select hunks interactively")),
OPT_BOOL('N', "intent-to-add", &intent_to_add,
N_("record only the fact that removed paths will be added later")),
+ OPT_BOOL(0, "unmerge", &unmerge,
+ N_("recover conflicted stages from an earlier 'git add'")),
OPT_END()
};
@@ -357,7 +361,9 @@ int cmd_reset(int argc, const char **argv, const char *prefix)
hold_locked_index(lock, 1);
if (reset_type == MIXED) {
int flags = quiet ? REFRESH_QUIET : REFRESH_IN_PORCELAIN;
- if (read_from_tree(&pathspec, oid.hash, intent_to_add))
+ if (unmerge)
+ unmerge_cache(&pathspec);
+ else if (read_from_tree(&pathspec, oid.hash, intent_to_add))
return 1;
if (get_git_work_tree())
refresh_index(&the_index, flags, NULL, NULL,
diff --git a/t/t7107-reset-unmerged.sh b/t/t7107-reset-unmerged.sh
new file mode 100755
index 0000000000..57b2e27150
--- /dev/null
+++ b/t/t7107-reset-unmerged.sh
@@ -0,0 +1,36 @@
+#!/bin/sh
+
+test_description='git reset with paths'
+
+. ./test-lib.sh
+
+test_expect_success setup '
+ echo one >file &&
+ git add file &&
+ git commit -m "one" &&
+ git tag initial &&
+
+ echo two >file &&
+ git commit -a -m "two" &&
+
+ git checkout -b side initial &&
+ echo three >file &&
+ git commit -a -m "three"
+'
+
+test_expect_success "cause conflict, resolve, and unresolve" '
+ git reset --hard &&
+ git checkout master &&
+ test_must_fail git merge side &&
+
+ git ls-files -u >expect &&
+
+ echo four >file &&
+ git add file &&
+
+ git reset --unmerge -- file &&
+ git ls-files -u >actual &&
+ test_cmp expect actual
+'
+
+test_done
^ permalink raw reply related
* [PATCH] Allow stashes to be referenced by index only
From: Aaron M Watson @ 2016-10-24 23:40 UTC (permalink / raw)
To: git
Cc: Aaron M Watson, Jon Seymour, David Caldwell, Øystein Walle,
Jeff King, Ævar Arnfjörð Bjarmason, David Aguilar,
Alex Henrie
In-Reply-To: <1473378397-22453-1-git-send-email-watsona4@gmail.com>
Instead of referencing "stash@{n}" explicitly, it can simply be
referenced as "n". Most users only reference stashes by their position
in the stash stask (what I refer to as the "index"). The syntax for the
typical stash (stash@{n}) is slightly annoying and easy to forget, and
sometimes difficult to escape properly in a script. Because of this the
capability to do things with the stash by simply referencing the index
is desirable.
This patch includes the superior implementation provided by Øsse Walle
(thanks for that), with a slight change to fix a broken test in the test
suite. I also merged the test scripts as suggested by Jeff King, and
un-wrapped the documentation as suggested by Junio Hamano.
Signed-off-by: Aaron M Watson <watsona4@gmail.com>
---
Documentation/git-stash.txt | 3 ++-
git-stash.sh | 15 +++++++++++++--
t/t3903-stash.sh | 35 +++++++++++++++++++++++++++++++++++
3 files changed, 50 insertions(+), 3 deletions(-)
diff --git a/Documentation/git-stash.txt b/Documentation/git-stash.txt
index 92df596..2e9cef0 100644
--- a/Documentation/git-stash.txt
+++ b/Documentation/git-stash.txt
@@ -39,7 +39,8 @@ The latest stash you created is stored in `refs/stash`; older
stashes are found in the reflog of this reference and can be named using
the usual reflog syntax (e.g. `stash@{0}` is the most recently
created stash, `stash@{1}` is the one before it, `stash@{2.hours.ago}`
-is also possible).
+is also possible). Stashes may also be referenced by specifying just the
+stash index (e.g. the integer `n` is equivalent to `stash@{n}`).
OPTIONS
-------
diff --git a/git-stash.sh b/git-stash.sh
index 826af18..d7072c8 100755
--- a/git-stash.sh
+++ b/git-stash.sh
@@ -384,9 +384,8 @@ parse_flags_and_rev()
i_tree=
u_tree=
- REV=$(git rev-parse --no-flags --symbolic --sq "$@") || exit 1
-
FLAGS=
+ REV=
for opt
do
case "$opt" in
@@ -404,6 +403,9 @@ parse_flags_and_rev()
die "$(eval_gettext "unknown option: \$opt")"
FLAGS="${FLAGS}${FLAGS:+ }$opt"
;;
+ *)
+ REV="${REV}${REV:+ }'$opt'"
+ ;;
esac
done
@@ -422,6 +424,15 @@ parse_flags_and_rev()
;;
esac
+ case "$1" in
+ *[!0-9]*)
+ :
+ ;;
+ *)
+ set -- "${ref_stash}@{$1}"
+ ;;
+ esac
+
REV=$(git rev-parse --symbolic --verify --quiet "$1") || {
reference="$1"
die "$(eval_gettext "\$reference is not a valid reference")"
diff --git a/t/t3903-stash.sh b/t/t3903-stash.sh
index 2142c1f..f82a8c4 100755
--- a/t/t3903-stash.sh
+++ b/t/t3903-stash.sh
@@ -131,6 +131,26 @@ test_expect_success 'drop middle stash' '
test 1 = $(git show HEAD:file)
'
+test_expect_success 'drop middle stash by index' '
+ git reset --hard &&
+ echo 8 >file &&
+ git stash &&
+ echo 9 >file &&
+ git stash &&
+ git stash drop 1 &&
+ test 2 = $(git stash list | wc -l) &&
+ git stash apply &&
+ test 9 = $(cat file) &&
+ test 1 = $(git show :file) &&
+ test 1 = $(git show HEAD:file) &&
+ git reset --hard &&
+ git stash drop &&
+ git stash apply &&
+ test 3 = $(cat file) &&
+ test 1 = $(git show :file) &&
+ test 1 = $(git show HEAD:file)
+'
+
test_expect_success 'stash pop' '
git reset --hard &&
git stash pop &&
@@ -604,7 +624,21 @@ test_expect_success 'invalid ref of the form stash@{n}, n >= N' '
git stash drop
'
+test_expect_success 'invalid ref of the form "n", n >= N' '
+ git stash clear &&
+ test_must_fail git stash drop 0 &&
+ echo bar5 >file &&
+ echo bar6 >file2 &&
+ git add file2 &&
+ git stash &&
+ test_must_fail git stash drop 1 &&
+ test_must_fail git stash pop 1 &&
+ test_must_fail git stash apply 1 &&
+ test_must_fail git stash show 1 &&
+ test_must_fail git stash branch tmp 1 &&
+ git stash drop
+'
+
test_expect_success 'stash branch should not drop the stash if the branch exists' '
git stash clear &&
echo foo >file &&
--
2.7.4
^ permalink raw reply related
* Re: [PATCH] hex: use unsigned index for ring buffer
From: Junio C Hamano @ 2016-10-24 23:53 UTC (permalink / raw)
To: René Scharfe; +Cc: Jeff King, Git List
In-Reply-To: <b1f9054e-fadb-c2d3-bf95-00e88e1fb85b@web.de>
René Scharfe <l.s.r@web.de> writes:
> Am 24.10.2016 um 19:27 schrieb Junio C Hamano:
>> Junio C Hamano <gitster@pobox.com> writes:
>>
>>>> I think it would be preferable to just fix it inline in each place.
>>>
>>> Yeah, probably.
>>>
>>> My initial reaction to this was
>>>
>>> char *sha1_to_hex(const unsigned char *sha1)
>>> {
>>> - static int bufno;
>>> + static unsigned int bufno;
>>> static char hexbuffer[4][GIT_SHA1_HEXSZ + 1];
>>> return sha1_to_hex_r(hexbuffer[3 & ++bufno], sha1);
>>>
>>> "ah, we do not even need bufno as uint; it could be ushort or even
>>> uchar". If this were a 256 element ring buffer and the index were
>>> uchar, we wouldn't even be having this discussion, and "3 &" is a
>>> way to get a fake type that is a 2-bit unsigned integer that wraps
>>> around when incremented.
>>>
>>> But being explicit, especially when we know that we can rely on the
>>> fact that the compilers are usually intelligent enough, is a good
>>> idea, I would think.
>>>
>>> Isn't size_t often wider than uint, by the way? It somehow makes me
>>> feel dirty to use it when we know we only care about the bottom two
>>> bit, especially with the explicit "bufno %= ARRAY_SIZE(hexbuffer)",
>>> but I may be simply superstitious in this case. I dunno.
>>
>> If we are doing the wrap-around ourselves, I suspect that the index
>> should stay "int" (not even unsigned), as that is supposed to be the
>> most natural and performant type on the architecture. Would it
>> still result in better code to use size_t instead?
>
> Right.
>
> Gcc emits an extra cltq instruction for x86-64 (Convert Long To Quad,
> i.e. 32-bit to 64-bit) if we wrap explicitly and still use an int in
> sha1_to_hex(). It doesn't if we use an unsigned int or size_t. It
> also doesn't for get_pathname(). I guess updating the index variable
> only after use makes the difference there.
>
> But I think we can ignore that; it's just an extra cycle. I only
> even noticed it when verifying that "% 4" is turned into "& 3"..
> Clang and icc don't add the cltq, by the way.
>
> So how about this? It gets rid of magic number 3 and works for array
> size that's not a power of two. And as a nice side effect it can't
> trigger a signed overflow anymore.
Looks good to me. Peff?
> Just adding "unsigned" looks more attractive to me for some reason.
> Perhaps I stared enough at the code to get used to the magic values
> there..
I somehow share that feeling, too.
^ permalink raw reply
* Re: [PATCH] hex: use unsigned index for ring buffer
From: Jeff King @ 2016-10-25 0:30 UTC (permalink / raw)
To: Junio C Hamano; +Cc: René Scharfe, Git List
In-Reply-To: <xmqq60ohtib5.fsf@gitster.mtv.corp.google.com>
On Mon, Oct 24, 2016 at 04:53:50PM -0700, Junio C Hamano wrote:
> > So how about this? It gets rid of magic number 3 and works for array
> > size that's not a power of two. And as a nice side effect it can't
> > trigger a signed overflow anymore.
>
> Looks good to me. Peff?
Any of the variants discussed in this thread is fine by me.
-Peff
^ permalink raw reply
* What's cooking in git.git (Oct 2016, #06; Mon, 24)
From: Junio C Hamano @ 2016-10-25 1:09 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.
Originally I planed to start concluding this cycle today, but
waiting for the conclusion of a few test breakages on Windows, I
didn't tag -rc0 today.
Here are my current thinking on the notable topics.
- the "off-by-one fix" part of sb/submodule-ignore-trailing-slash
needs to be in the upcoming release but the "trailing /. in base
should not affect the resolution of ../relative/path" part that
is still under discussion can wait. Which means we'd need a few
more !MINGW prerequisites in the tests by -rc0.
- js/prepare-sequencer topic is not yet in 'next' but it would be a
nice-to-have in the upcoming release if we can. It does not yet
touch "rebase -i", but does touch the sequencer code that is used
in cherry-pick and revert, so I'd prefer to cook it for at least
a week and half in 'next' before merging.
- ls/filter-process topic has been in 'next' with one known test
breakage on Windows, whose resolution ls/git-open-cloexec is
close to its final shape. Perhaps we can cook them for at least
a week and half in 'next' and have it in the upcoming release.
- ex/deprecate-empty-pathspec-as-match-all topic that makes it
illegal to say 'git add ""' when you mean 'git add .' has been in
'next' for more than a cycle. I am inclined to merge it in the
upcoming release.
- jc/merge-drop-old-syntax is relatively new in 'next' after all
known in-tree dependents have been updated. I am planning to
keep it cooking in 'next' but add a backward incompatibility
notice to the release notes to the upcoming release.
- lt/abbrev-auto and its follow-up jk/abbrev-auto are about auto
scaling the default abbreviation length when Git produces a short
object name to adjust to the modern times. Peff noticed one
fallout from it recently and its fix jc/abbrev-auto is not yet in
'next'. I would not be surprised if there are other uncovered
fallouts remaining in the code, but at the same time, I expect
they are all cosmetic kind that do not affect correctness, so I
am inclined to include all of them in the upcoming release.
I plan to merge other smallish topics that have been in 'next' to
'master' soonish, and relabel the remainder that have been labeled
as "Will merge to 'master'" to "Will hold" and keep cooking them in
'next'. For this reason, please do not take the "Will merge to
'master'" label too literally in this issue of "What's cooking"
report. It is always true that the label only means "the topic will
be in 'master' eventually", not "the topic will be in the upcoming
release", but in this issue that is even more true than usual.
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]
* jk/tap-verbose-fix (2016-10-24) 4 commits
(merged to 'next' on 2016-10-24 at 5073a4de2d)
+ test-lib: bail out when "-v" used under "prove"
(merged to 'next' on 2016-10-21 at 592679411c)
+ travis: use --verbose-log test option
+ test-lib: add --verbose-log option
+ test-lib: handle TEST_OUTPUT_DIRECTORY with spaces
The Travis CI configuration we ship ran the tests with --verbose
option but this risks non-TAP output that happens to be "ok" to be
misinterpreted as TAP signalling a test that passed. This resulted
in unnecessary failure. This has been corrected by introducing a
new mode to run our tests in the test harness to send the verbose
output separately to the log file.
Will merge to 'master'.
* po/fix-doc-merge-base-illustration (2016-10-21) 1 commit
(merged to 'next' on 2016-10-21 at ac6f04a6c5)
+ doc: fix merge-base ASCII art tab spacing
Some AsciiDoc formatter mishandles a displayed illustration with
tabs in it. Adjust a few of them in merge-base documentation to
work around them.
Will merge to 'master'.
* jc/abbrev-auto (2016-10-22) 4 commits
- transport: compute summary-width dynamically
- transport: allow summary-width to be computed dynamically
- fetch: pass summary_width down the callchain
- transport: pass summary_width down the callchain
(this branch uses jk/abbrev-auto and lt/abbrev-auto.)
"git push" and "git fetch" reports from what old object to what new
object each ref was updated, using abbreviated refnames, and they
attempt to align the columns for this and other pieces of
information. The way these codepaths compute how many display
columns to allocate for the object names portion of this output has
been updated to match the recent "auto scale the default
abbreviation length" change.
Will merge to 'next'.
* jc/reset-unmerge (2016-10-24) 1 commit
- reset: --unmerge
After "git add" is run prematurely during a conflict resolution,
"git diff" can no longer be used as a way to sanity check by
looking at the combined diff. "git reset" learned a new
"--unmerge" option to recover from this situation.
* jk/daemon-path-ok-check-truncation (2016-10-24) 1 commit
- daemon: detect and reject too-long paths
"git daemon" used fixed-length buffers to turn URL to the
repository the client asked for into the server side directory
path, using snprintf() to avoid overflowing these buffers, but
allowed possibly truncated paths to the directory. This has been
tightened to reject such a request that causes overlong path to be
required to serve.
Will merge to 'next'.
* ls/git-open-cloexec (2016-10-24) 3 commits
- SQUASH???
- read-cache: make sure file handles are not inherited by child processes
- sha1_file: open window into packfiles with CLOEXEC
Git generally does not explicitly close file descriptors that were
open in the parent process when spawning a child process, but most
of the time the child does not want to access them. As Windows does
not allow removing or renaming a file that has a file descriptor
open, a slow-to-exit child can even break the parent process by
holding onto them. Use O_CLOEXEC flag to open files in various
codepaths.
Under discussion.
cf. <20161024183900.GA12769@starla>
This needs to be merged before ls/filter-process so that it won't
break Windows.
* rs/ring-buffer-wraparound (2016-10-24) 1 commit
- hex: make wraparound of the index into ring-buffer explicit
The code that we have used for the past 10+ years to cycle
4-element ring buffers turns out to be not quite portable in
theoretical world.
Under discussion.
cf. <b1f9054e-fadb-c2d3-bf95-00e88e1fb85b@web.de>
--------------------------------------------------
[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.
* mh/connect (2016-06-06) 10 commits
- connect: [host:port] is legacy for ssh
- connect: move ssh command line preparation to a separate function
- connect: actively reject git:// urls with a user part
- connect: change the --diag-url output to separate user and host
- connect: make parse_connect_url() return the user part of the url as a separate value
- connect: group CONNECT_DIAG_URL handling code
- connect: make parse_connect_url() return separated host and port
- connect: re-derive a host:port string from the separate host and port variables
- connect: call get_host_and_port() earlier
- connect: document why we sometimes call get_port after get_host_and_port
Rewrite Git-URL parsing routine (hopefully) without changing any
behaviour.
It has been two months without any support. We may want to discard
this.
* kn/ref-filter-branch-list (2016-05-17) 17 commits
- branch: implement '--format' option
- branch: use ref-filter printing APIs
- branch, tag: use porcelain output
- ref-filter: allow porcelain to translate messages in the output
- ref-filter: add `:dir` and `:base` options for ref printing atoms
- ref-filter: make remote_ref_atom_parser() use refname_atom_parser_internal()
- ref-filter: introduce symref_atom_parser() and refname_atom_parser()
- ref-filter: introduce refname_atom_parser_internal()
- ref-filter: make "%(symref)" atom work with the ':short' modifier
- ref-filter: add support for %(upstream:track,nobracket)
- ref-filter: make %(upstream:track) prints "[gone]" for invalid upstreams
- ref-filter: introduce format_ref_array_item()
- ref-filter: move get_head_description() from branch.c
- ref-filter: modify "%(objectname:short)" to take length
- ref-filter: implement %(if:equals=<string>) and %(if:notequals=<string>)
- ref-filter: include reference to 'used_atom' within 'atom_value'
- ref-filter: implement %(if), %(then), and %(else) atoms
The code to list branches in "git branch" has been consolidated
with the more generic ref-filter API.
Rerolled.
Needs review.
* ec/annotate-deleted (2015-11-20) 1 commit
- annotate: skip checking working tree if a revision is provided
Usability fix for annotate-specific "<file> <rev>" syntax with deleted
files.
Has been waiting for a review for too long without seeing anything.
Will discard.
* dk/gc-more-wo-pack (2016-01-13) 4 commits
- gc: clean garbage .bitmap files from pack dir
- t5304: ensure non-garbage files are not deleted
- t5304: test .bitmap garbage files
- prepare_packed_git(): find more garbage
Follow-on to dk/gc-idx-wo-pack topic, to clean up stale
.bitmap and .keep files.
Has been waiting for a reroll for too long.
cf. <xmqq60ypbeng.fsf@gitster.mtv.corp.google.com>
Will discard.
* jc/diff-b-m (2015-02-23) 5 commits
. WIPWIP
. WIP: diff-b-m
- diffcore-rename: allow easier debugging
- diffcore-rename.c: add locate_rename_src()
- diffcore-break: allow debugging
"git diff -B -M" produced incorrect patch when the postimage of a
completely rewritten file is similar to the preimage of a removed
file; such a resulting file must not be expressed as a rename from
other place.
The fix in this patch is broken, unfortunately.
Will discard.
--------------------------------------------------
[Cooking]
* jc/merge-base-fp-only (2016-10-19) 8 commits
. merge-base: fp experiment
- merge: allow to use only the fp-only merge bases
- merge-base: limit the output to bases that are on first-parent chain
- merge-base: mark bases that are on first-parent chain
- merge-base: expose get_merge_bases_many_0() a bit more
- merge-base: stop moving commits around in remove_redundant()
- sha1_name: remove ONELINE_SEEN bit
- commit: simplify fastpath of merge-base
An experiment of merge-base that ignores common ancestors that are
not on the first parent chain.
* bw/submodule-branch-dot-doc (2016-10-19) 1 commit
(merged to 'next' on 2016-10-21 at 18aad25ba8)
+ submodules doc: update documentation for "." used for submodule branches
Recent git allows submodule.<name>.branch to use a special token
"." instead of the branch name; the documentation has been updated
to describe it.
Will merge to 'master'.
* tg/add-chmod+x-fix (2016-10-20) 1 commit
(merged to 'next' on 2016-10-21 at 1585ac7139)
+ t3700: fix broken test under !SANITY
A hot-fix for a test added by a recent topic that went to both
'master' and 'maint' already.
Will merge to 'master'.
* jk/diff-submodule-diff-inline (2016-10-20) 1 commit
(merged to 'next' on 2016-10-21 at 13f300805e)
+ rev-list: use hdr_termination instead of a always using a newline
A recently graduated topic regressed "git rev-list --header"
output, breaking "gitweb". This has been fixed.
Will merge to 'master'.
* jk/no-looking-at-dotgit-outside-repo (2016-10-20) 8 commits
- setup_git_env: avoid blind fall-back to ".git"
- diff: handle sha1 abbreviations outside of repository
- diff_aligned_abbrev: use "struct oid"
- diff_unique_abbrev: rename to diff_aligned_abbrev
- find_unique_abbrev: use 4-buffer ring
- test-*-cache-tree: setup git dir
- read info/{attributes,exclude} only when in repository
- Merge branch 'jc/diff-unique-abbrev-comments' into jk/no-looking-at-dotgit-outside-repo
(this branch uses jc/diff-unique-abbrev-comments.)
Update "git diff --no-index" codepath not to try to peek into .git/
directory that happens to be under the current directory, when we
know we are operating outside any repository.
Will wait until 'jc/diff-unique-abbrev-comments' graduates, rebase
onto 'master' and then cook in 'next'.
* pt/gitgui-updates (2016-10-20) 35 commits
(merged to 'next' on 2016-10-21 at 4c8214095a)
+ Merge tag 'gitgui-0.21.0' of git://repo.or.cz/git-gui
+ git-gui: set version 0.21
+ Merge branch 'as/bulgarian' into pu
+ git-gui: Mark 'All' in remote.tcl for translation
+ git-gui i18n: Updated Bulgarian translation (565,0f,0u)
+ Merge branch 'os/preserve-author' into pu
+ git-gui: avoid persisting modified author identity
+ git-gui: Do not reset author details on amend
+ Merge branch 'kb/unicode' into pu
+ git-gui: handle the encoding of Git's output correctly
+ git-gui: unicode file name support on windows
+ Merge branch 'dr/ru' into pu
+ git-gui: Update Russian translation
+ git-gui: maintain backwards compatibility for merge syntax
+ Merge branch 'va/i18n_2' into pu
+ git-gui i18n: mark string in lib/error.tcl for translation
+ git-gui: fix incorrect use of Tcl append command
+ git-gui i18n: mark "usage:" strings for translation
+ git-gui i18n: internationalize use of colon punctuation
+ Merge branch 'pt/non-mouse-usage' into pu
+ Amend tab ordering and text widget border and highlighting.
+ Allow keyboard control to work in the staging widgets.
+ Merge branch 'pt/git4win-mods' into pu
+ git-gui (Windows): use git-gui.exe in `Create Desktop Shortcut`
+ git-gui: fix detection of Cygwin
+ Merge branch 'patches' into pu
+ git-gui: ensure the file in the diff pane is in the list of selected files
+ git-gui: support for $FILENAMES in tool definitions
+ git-gui: fix initial git gui message encoding
+ git-gui/po/glossary/txt-to-pot.sh: use the $( ... ) construct for command substitution
+ Merge branch 'va/i18n' into pu
+ Merge branch 'rs/use-modern-git-merge-syntax' into pu
+ Merge branch 'js/commit-gpgsign' into pu
+ Merge branch 'sy/i18n' into pu
+ git-gui: sort entries in tclIndex
A new version of git-gui, now at its 0.21.0 tag.
Will merge to 'master'.
* yk/git-tag-remove-mention-of-old-layout-in-doc (2016-10-20) 1 commit
(merged to 'next' on 2016-10-21 at 8d9e23b023)
+ doc: remove reference to the traditional layout in git-tag.txt
Shorten description of auto-following in "git tag" by removing a
mention of historical remotes layout which is not relevant to the
main topic.
Will merge to 'master'.
* dk/worktree-dup-checkout-with-bare-is-ok (2016-10-14) 1 commit
(merged to 'next' on 2016-10-17 at 24594d3e56)
+ worktree: allow the main brach of a bare repository to be checked out
In a worktree connected to a repository elsewhere, created via "git
worktree", "git checkout" attempts to protect users from confusion
by refusing to check out a branch that is already checked out in
another worktree. However, this also prevented checking out a
branch, which is designated as the primary branch of a bare
reopsitory, in a worktree that is connected to the bare
repository. The check has been corrected to allow it.
Will merge to 'master'.
* jc/cocci-xstrdup-or-null (2016-10-12) 1 commit
(merged to 'next' on 2016-10-17 at 55ceaa465a)
+ cocci: refactor common patterns to use xstrdup_or_null()
Code cleanup.
Will merge to 'master'.
* tb/convert-stream-check (2016-10-12) 2 commits
- convert.c: stream and fast search for binary
- read-cache: factor out get_sha1_from_index() helper
End-of-line conversion sometimes needs to see if the current blob
in the index has NULs and CRs to base its decision. We used to
always get a full statistics over the blob, but in many cases we
can return early when we have seen "enough" (e.g. if we see a
single NUL, the blob will be handled as binary). The codepaths
have been optimized by using streaming interface.
Waiting for review.
* jk/ambiguous-short-object-names (2016-10-12) 1 commit
(merged to 'next' on 2016-10-19 at e7c55a9da5)
+ t1512: become resilient to GETTEXT_POISON build
A test fixup to recently graduated topic.
Will merge to 'master'.
* jk/merge-base-fork-point-without-reflog (2016-10-12) 1 commit
(merged to 'next' on 2016-10-19 at 00a6797f62)
+ merge-base: handle --fork-point without reflog
"git rebase" immediately after "git clone" failed to find the fork
point from the upstream.
Will merge to 'master'.
* jk/upload-pack-use-prio-queue (2016-10-11) 1 commit
(merged to 'next' on 2016-10-19 at 1d6efb07ac)
+ upload-pack: use priority queue in reachable() check
Code clean-up and performance improvement to reduce use of
timestamp-ordered commit-list by replacing it with a priority
queue.
Will merge to 'master'.
* jk/fetch-quick-tag-following (2016-10-14) 1 commit
(merged to 'next' on 2016-10-19 at d7718dcdf5)
+ fetch: use "quick" has_sha1_file for tag following
When fetching from a remote that has many tags that are irrelevant
to branches we are following, we used to waste way too many cycles
when checking if the object pointed at by a tag (that we are not
going to fetch!) exists in our repository too carefully.
Will merge to 'master'.
* jt/trailer-with-cruft (2016-10-21) 8 commits
- trailer: support values folded to multiple lines
- trailer: forbid leading whitespace in trailers
- trailer: allow non-trailers in trailer block
- trailer: clarify failure modes in parse_trailer
- trailer: make args have their own struct
- trailer: streamline trailer item create and add
- trailer: use list.h for doubly-linked list
- trailer: improve const correctness
Update "interpret-trailers" machinery and teaches it that people in
real world write all sorts of crufts in the "trailer" that was
originally designed to have the neat-o "Mail-Header: like thing"
and nothing else.
Waiting for review.
* mm/send-email-cc-cruft-after-address (2016-10-21) 3 commits
(merged to 'next' on 2016-10-21 at c7ec2b5025)
+ Git.pm: add comment pointing to t9000
+ t9000-addresses: update expected results after fix
(merged to 'next' on 2016-10-19 at 41e3f876cd)
+ parse_mailboxes: accept extra text after <...> address
"git send-email" attempts to pick up valid e-mails from the
trailers, but people in real world write non-addresses there, like
"Cc: Stable <add@re.ss> # 4.8+", which broke the output depending
on the availability and vintage of Mail::Address perl module.
Will merge to 'master'.
* va/i18n (2016-10-17) 7 commits
(merged to 'next' on 2016-10-19 at b7d733698b)
+ i18n: diff: mark warnings for translation
+ i18n: credential-cache--daemon: mark advice for translation
+ i18n: convert mark error messages for translation
+ i18n: apply: mark error message for translation
+ i18n: apply: mark error messages for translation
+ i18n: apply: mark info messages for translation
+ i18n: apply: mark plural string for translation
More i18n.
Will merge to 'master'.
* jk/tighten-alloc (2016-10-17) 2 commits
(merged to 'next' on 2016-10-19 at 548522a520)
+ inline xalloc_flex() into FLEXPTR_ALLOC_MEM
+ avoid pointer arithmetic involving NULL in FLEX_ALLOC_MEM
Protect our code from over-eager compilers.
Will merge to 'master'.
* pb/test-parse-options-expect (2016-10-17) 1 commit
(merged to 'next' on 2016-10-19 at d3517d592f)
+ t0040: convert all possible tests to use `test-parse-options --expect`
Test clean-up.
Will merge to 'master'.
* pb/bisect (2016-10-18) 27 commits
- bisect--helper: remove the dequote in bisect_start()
- bisect--helper: retire `--bisect-auto-next` subcommand
- bisect--helper: retire `--bisect-autostart` subcommand
- bisect--helper: retire `--bisect-write` subcommand
- bisect--helper: `bisect_replay` shell function in C
- bisect--helper: `bisect_log` shell function in C
- bisect--helper: retire `--write-terms` subcommand
- bisect--helper: retire `--check-expected-revs` subcommand
- bisect--helper: `bisect_state` & `bisect_head` shell function in C
- bisect--helper: `bisect_autostart` shell function in C
- bisect--helper: retire `--next-all` subcommand
- bisect--helper: retire `--bisect-clean-state` subcommand
- bisect--helper: `bisect_next` and `bisect_auto_next` shell function in C
- t6030: no cleanup with bad merge base
- bisect--helper: `bisect_start` shell function partially in C
- bisect--helper: `get_terms` & `bisect_terms` shell function in C
- bisect--helper: `bisect_next_check` & bisect_voc shell function in C
- bisect--helper: `check_and_set_terms` shell function in C
- bisect--helper: `bisect_write` shell function in C
- bisect--helper: `is_expected_rev` & `check_expected_revs` shell function in C
- bisect--helper: `bisect_reset` shell function in C
- wrapper: move is_empty_file() and rename it as is_empty_or_missing_file()
- t6030: explicitly test for bisection cleanup
- bisect--helper: `bisect_clean_state` shell function in C
- bisect--helper: `write_terms` shell function in C
- bisect: rewrite `check_term_format` shell function in C
- bisect--helper: use OPT_CMDMODE instead of OPT_BOOL
Move more parts of "git bisect" to C.
Waiting for review.
* ab/gitweb-abbrev-links (2016-10-14) 3 commits
(merged to 'next' on 2016-10-17 at 4868def05e)
+ gitweb: link to "git describe"'d commits in log messages
+ gitweb: link to 7-char+ SHA-1s, not only 8-char+
+ gitweb: fix a typo in a comment
In addition to purely abbreviated commit object names, "gitweb"
learned to turn "git describe" output (e.g. v2.9.3-599-g2376d31787)
into clickable links in its output.
Will merge to 'master'.
* js/prepare-sequencer (2016-10-21) 27 commits
- sequencer: mark all error messages for translation
- sequencer: start error messages consistently with lower case
- sequencer: quote filenames in error messages
- sequencer: mark action_name() for translation
- sequencer: remove overzealous assumption in rebase -i mode
- sequencer: teach write_message() to append an optional LF
- sequencer: refactor write_message() to take a pointer/length
- sequencer: roll back lock file if write_message() failed
- sequencer: stop releasing the strbuf in write_message()
- sequencer: left-trim lines read from the script
- sequencer: support cleaning up commit messages
- sequencer: support amending commits
- sequencer: allow editing the commit message on a case-by-case basis
- sequencer: introduce a helper to read files written by scripts
- sequencer: prepare for rebase -i's commit functionality
- sequencer: remember the onelines when parsing the todo file
- sequencer: get rid of the subcommand field
- sequencer: avoid completely different messages for different actions
- sequencer: strip CR from the todo script
- sequencer: completely revamp the "todo" script parsing
- sequencer: refactor the code to obtain a short commit name
- sequencer: future-proof read_populate_todo()
- sequencer: plug memory leaks for the option values
- sequencer: future-proof remove_sequencer_state()
- sequencer: avoid unnecessary indirection
- sequencer: use memoized sequencer directory path
- sequencer: use static initializers for replay_opts
Update of the sequencer codebase to make it reusable to reimplement
"rebase -i" continues.
Will merge to 'next'.
* sb/submodule-ignore-trailing-slash (2016-10-18) 3 commits
. submodule--helper: normalize funny urls
(merged to 'next' on 2016-10-11 at e37425ed17)
+ submodule: ignore trailing slash in relative url
+ submodule: ignore trailing slash on superproject URL
A minor regression fix for "git submodule".
It seems that POSIX emulation layer of Windows is not cooperating;
this may have to wait (or tentatively reverted in Windows port) for
the resolution of the issue.
cf. <alpine.DEB.2.20.1610131255001.197091@virtualbox>
cf. <CAGZ79kYrKGLEOO72aWuX5OOM-AecdFZFXRqBkRzhdAM-VbPFxA@mail.gmail.com>
What's the current state of this topic?
* st/verify-tag (2016-10-10) 7 commits
- t/t7004-tag: Add --format specifier tests
- t/t7030-verify-tag: Add --format specifier tests
- builtin/tag: add --format argument for tag -v
- builtin/verify-tag: add --format to verify-tag
- tag: add format specifier to gpg_verify_tag
- ref-filter: add function to print single ref_array_item
- gpg-interface, tag: add GPG_VERIFY_QUIET flag
"git tag" and "git verify-tag" learned to put GPG verification
status in their "--format=<placeholders>" output format.
Waiting for review.
cf. <20161007210721.20437-1-santiago@nyu.edu>
* mm/credential-libsecret (2016-10-11) 1 commit
(merged to 'next' on 2016-10-17 at 1b4af03ba4)
+ contrib: add credential helper for libsecret
A new credential helper that talks via "libsecret" with
implementations of XDG Secret Service API has been added to
contrib/credential/.
Will merge to 'master'.
* sb/attr (2016-10-24) 36 commits
- completion: clone can initialize specific submodules
- clone: add --init-submodule=<pathspec> switch
- submodule update: add `--init-default-path` switch
- pathspec: allow escaped query values
- pathspec: allow querying for attributes
- pathspec: move prefix check out of the inner loop
- pathspec: move long magic parsing out of prefix_pathspec
- Documentation: fix a typo
- attr: keep attr stack for each check
- attr: convert to new threadsafe API
- attr: make git_check_attr_counted static
- attr.c: outline the future plans by heavily commenting
- attr.c: always pass check[] to collect_some_attrs()
- attr.c: introduce empty_attr_check_elems()
- attr.c: correct ugly hack for git_all_attrs()
- attr.c: rename a local variable check
- attr.c: pass struct git_attr_check down the callchain
- attr.c: add push_stack() helper
- attr: support quoting pathname patterns in C style
- attr: expose validity check for attribute names
- attr: add counted string version of git_attr()
- attr: add counted string version of git_check_attr()
- attr: retire git_check_attrs() API
- attr: convert git_check_attrs() callers to use the new API
- attr: convert git_all_attrs() to use "struct git_attr_check"
- attr: (re)introduce git_check_attr() and struct git_attr_check
- attr: rename function and struct related to checking attributes
- attr.c: plug small leak in parse_attr_line()
- attr.c: tighten constness around "git_attr" structure
- attr.c: simplify macroexpand_one()
- attr.c: mark where #if DEBUG ends more clearly
- attr.c: complete a sentence in a comment
- attr.c: explain the lack of attr-name syntax check in parse_attr()
- attr.c: update a stale comment on "struct match_attr"
- attr.c: use strchrnul() to scan for one line
- commit.c: use strchrnul() to scan for one line
The attributes API has been updated so that it can later be
optimized using the knowledge of which attributes are queried.
Building on top of the updated API, the pathspec machinery learned
to select only paths with given attributes set.
* jc/ws-error-highlight (2016-10-04) 4 commits
(merged to 'next' on 2016-10-17 at ecbdc57d77)
+ diff: introduce diff.wsErrorHighlight option
+ diff.c: move ws-error-highlight parsing helpers up
+ diff.c: refactor parse_ws_error_highlight()
+ t4015: split out the "setup" part of ws-error-highlight test
"git diff/log --ws-error-highlight=<kind>" lacked the corresponding
configuration variable to set it by default.
Will merge to 'master'.
* jk/abbrev-auto (2016-10-03) 1 commit
(merged to 'next' on 2016-10-21 at 8aa3d760d8)
+ find_unique_abbrev: move logic out of get_short_sha1()
(this branch is used by jc/abbrev-auto; uses lt/abbrev-auto.)
Updates the way approximate count of total objects is computed
while attempting to come up with a unique abbreviated object name,
which in turn needs to estimate how many hexdigits are necessary to
ensure uniqueness.
Undecided.
* nd/ita-empty-commit (2016-10-24) 4 commits
- commit: don't be fooled by ita entries when creating initial commit
- commit: fix empty commit creation when there's no changes but ita entries
- diff: add --ita-[in]visible-in-index
- diff-lib: allow ita entries treated as "not yet exist in index"
When new paths were added by "git add -N" to the index, it was
enough to circumvent the check by "git commit" to refrain from
making an empty commit without "--allow-empty". The same logic
prevented "git status" to show such a path as "new file" in the
"Changes not staged for commit" section.
Will merge to 'next'.
* lt/abbrev-auto (2016-10-03) 3 commits
(merged to 'next' on 2016-10-03 at bb188d00f7)
+ abbrev: auto size the default abbreviation
+ abbrev: prepare for new world order
+ abbrev: add FALLBACK_DEFAULT_ABBREV to prepare for auto sizing
(this branch is used by jc/abbrev-auto and jk/abbrev-auto.)
Allow the default abbreviation length, which has historically been
7, to scale as the repository grows. The logic suggests to use 12
hexdigits for the Linux kernel, and 9 to 10 for Git itself.
Will hold to see if people scream.
* jc/diff-unique-abbrev-comments (2016-09-30) 1 commit
(merged to 'next' on 2016-10-17 at c7fb286102)
+ diff_unique_abbrev(): document its assumption and limitation
(this branch is used by jk/no-looking-at-dotgit-outside-repo.)
A bit more comments in a tricky code.
Will merge to 'master'.
* va/i18n-perl-scripts (2016-10-20) 14 commits
- i18n: difftool: mark warnings for translation
- i18n: send-email: mark string with interpolation for translation
- i18n: send-email: mark warnings and errors for translation
- i18n: send-email: mark strings for translation
- i18n: add--interactive: mark status words for translation
- i18n: add--interactive: remove %patch_modes entries
- i18n: add--interactive: mark edit_hunk_manually message for translation
- i18n: add--interactive: i18n of help_patch_cmd
- i18n: add--interactive: mark patch prompt for translation
- i18n: add--interactive: mark plural strings
- i18n: clean.c: match string with git-add--interactive.perl
- i18n: add--interactive: mark strings with interpolation for translation
- i18n: add--interactive: mark simple here-documents for translation
- i18n: add--interactive: mark strings for translation
Porcelain scripts written in Perl are getting internationalized.
Waiting for review.
cf. <20161010125449.7929-1-vascomalmeida@sapo.pt>
* jc/latin-1 (2016-09-26) 2 commits
(merged to 'next' on 2016-09-28 at c8673e03c2)
+ utf8: accept "latin-1" as ISO-8859-1
+ utf8: refactor code to decide fallback encoding
Some platforms no longer understand "latin-1" that is still seen in
the wild in e-mail headers; replace them with "iso-8859-1" that is
more widely known when conversion fails from/to it.
Will hold to see if people scream.
* mg/gpg-richer-status (2016-10-12) 1 commit
(merged to 'next' on 2016-10-17 at 8843a6a8be)
+ gpg-interface: use more status letters
The GPG verification status shown in "%G?" pretty format specifier
was not rich enough to differentiate a signature made by an expired
key, a signature made by a revoked key, etc. New output letters
have been assigned to express them.
Will merge to 'master'.
* js/libify-require-clean-work-tree (2016-10-07) 6 commits
(merged to 'next' on 2016-10-17 at f5c20df38b)
+ wt-status: begin error messages with lower-case
+ wt-status: teach has_{unstaged,uncommitted}_changes() about submodules
+ wt-status: export also the has_un{staged,committed}_changes() functions
+ wt-status: make the require_clean_work_tree() function reusable
+ pull: make code more similar to the shell script again
+ pull: drop confusing prefix parameter of die_on_unclean_work_tree()
The require_clean_work_tree() helper was recreated in C when "git
pull" was rewritten from shell; the helper is now made available to
other callers in preparation for upcoming "rebase -i" work.
Will merge to 'master'.
* bw/ls-files-recurse-submodules (2016-10-10) 4 commits
(merged to 'next' on 2016-10-17 at f0e398946a)
+ ls-files: add pathspec matching for submodules
+ ls-files: pass through safe options for --recurse-submodules
+ ls-files: optionally recurse into submodules
+ git: make super-prefix option
"git ls-files" learned "--recurse-submodules" option that can be
used to get a listing of tracked files across submodules (i.e. this
only works with "--cached" option, not for listing untracked or
ignored files). This would be a useful tool to sit on the upstream
side of a pipe that is read with xargs to work on all working tree
files from the top-level superproject.
Will merge to 'master'.
* ls/filter-process (2016-10-17) 14 commits
(merged to 'next' on 2016-10-19 at ffd0de042c)
+ contrib/long-running-filter: add long running filter example
+ convert: add filter.<driver>.process option
+ convert: prepare filter.<driver>.process option
+ convert: make apply_filter() adhere to standard Git error handling
+ pkt-line: add functions to read/write flush terminated packet streams
+ pkt-line: add packet_write_gently()
+ pkt-line: add packet_flush_gently()
+ pkt-line: add packet_write_fmt_gently()
+ pkt-line: extract set_packet_header()
+ pkt-line: rename packet_write() to packet_write_fmt()
+ run-command: add clean_on_exit_handler
+ run-command: move check_pipe() from write_or_die to run_command
+ convert: modernize tests
+ convert: quote filter names in error messages
The smudge/clean filter API expect an external process is spawned
to filter the contents for each path that has a filter defined. A
new type of "process" filter API has been added to allow the first
request to run the filter for a path to spawn a single process, and
all filtering need is served by this single process for multiple
paths, reducing the process creation overhead.
Will wait for ls/git-open-cloexec.
* hv/submodule-not-yet-pushed-fix (2016-10-10) 3 commits
- batch check whether submodule needs pushing into one call
- serialize collection of refs that contain submodule changes
- serialize collection of changed submodules
The code in "git push" to compute if any commit being pushed in the
superproject binds a commit in a submodule that hasn't been pushed
out was overly inefficient, making it unusable even for a small
project that does not have any submodule but have a reasonable
number of refs.
Waiting for review.
cf. <cover.1475851621.git.hvoigt@hvoigt.net>
* sg/fix-versioncmp-with-common-suffix (2016-09-08) 5 commits
- versioncmp: cope with common leading parts in versionsort.prereleaseSuffix
- versioncmp: pass full tagnames to swap_prereleases()
- t7004-tag: add version sort tests to show prerelease reordering issues
- t7004-tag: use test_config helper
- t7004-tag: delete unnecessary tags with test_when_finished
The prereleaseSuffix feature of version comparison that is used in
"git tag -l" did not correctly when two or more prereleases for the
same release were present (e.g. when 2.0, 2.0-beta1, and 2.0-beta2
are there and the code needs to compare 2.0-beta1 and 2.0-beta2).
Waiting for a reroll.
cf. <20160908223727.Horde.jVOOJ278ssZ3qkyjkmyqZD-@webmail.informatik.kit.edu>
* sb/push-make-submodule-check-the-default (2016-10-10) 2 commits
- push: change submodule default to check when submodules exist
- submodule add: extend force flag to add existing repos
Turn the default of "push.recurseSubmodules" to "check" when
submodules seem to be in use.
Will hold to wait for hv/submodule-not-yet-pushed-fix
* jc/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-09-21 at e19148ea63)
+ pathspec: warn on empty strings as pathspec
Originally merged to 'next' on 2016-07-13
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.
* jc/merge-drop-old-syntax (2015-04-29) 1 commit
(merged to 'next' on 2016-10-11 at 8928c8b9b3)
+ merge: drop 'git merge <message> HEAD <commit>' syntax
Stop supporting "git merge <message> HEAD <commit>" syntax that has
been deprecated since October 2007, and issues a deprecation
warning message since v2.5.0.
It has been reported that git-gui still uses the deprecated syntax,
which needs to be fixed before this final step can proceed.
cf. <5671DB28.8020901@kdbg.org>
Will merge to 'master'.
^ permalink raw reply
* Re: What's cooking in git.git (Oct 2016, #06; Mon, 24)
From: Stefan Beller @ 2016-10-25 2:27 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git@vger.kernel.org
In-Reply-To: <xmqq1sz5tetv.fsf@gitster.mtv.corp.google.com>
On Mon, Oct 24, 2016 at 6:09 PM, Junio C Hamano <gitster@pobox.com> wrote:
>
> * sb/submodule-ignore-trailing-slash (2016-10-18) 3 commits
> . submodule--helper: normalize funny urls
> (merged to 'next' on 2016-10-11 at e37425ed17)
> + submodule: ignore trailing slash in relative url
> + submodule: ignore trailing slash on superproject URL
>
> A minor regression fix for "git submodule".
>
> It seems that POSIX emulation layer of Windows is not cooperating;
> this may have to wait (or tentatively reverted in Windows port) for
> the resolution of the issue.
>
> cf. <alpine.DEB.2.20.1610131255001.197091@virtualbox>
> cf. <CAGZ79kYrKGLEOO72aWuX5OOM-AecdFZFXRqBkRzhdAM-VbPFxA@mail.gmail.com>
>
> What's the current state of this topic?
The first 2 patches actually fix a bug users run into, and I these are
fine for general consumption IMHO.
The third patch only breaks tests as our test suite is holding it wrong.
I was bike shedding on the list and yak shaving here to come up with
the correct fix for the test suite.
One of the initial ways to work around the bugfix was to
git clone . root # <- add in this step and it works again.
git clone root super
but instead I will do the preparation for the 'super' project not
in '.' but in 'root', just called differently ("super_remote" ?)
An additional new test for cloning from '.' will be introduced, too.
I plan on working on that with highest priority for git after finishing
some attr stuff that I currently have open. So expect a patch (or two)
this week.
Thanks,
Stefan
^ permalink raw reply
* Re: [PATCH] Allow stashes to be referenced by index only
From: Jeff King @ 2016-10-25 8:11 UTC (permalink / raw)
To: Aaron M Watson
Cc: git, Jon Seymour, David Caldwell, Øystein Walle,
Ævar Arnfjörð Bjarmason, David Aguilar,
Alex Henrie
In-Reply-To: <1477352413-4628-1-git-send-email-watsona4@gmail.com>
On Mon, Oct 24, 2016 at 07:40:13PM -0400, Aaron M Watson wrote:
> Instead of referencing "stash@{n}" explicitly, it can simply be
> referenced as "n". Most users only reference stashes by their position
> in the stash stask (what I refer to as the "index"). The syntax for the
> typical stash (stash@{n}) is slightly annoying and easy to forget, and
> sometimes difficult to escape properly in a script. Because of this the
> capability to do things with the stash by simply referencing the index
> is desirable.
>
> This patch includes the superior implementation provided by Øsse Walle
> (thanks for that), with a slight change to fix a broken test in the test
> suite. I also merged the test scripts as suggested by Jeff King, and
> un-wrapped the documentation as suggested by Junio Hamano.
>
> Signed-off-by: Aaron M Watson <watsona4@gmail.com>
> ---
Thanks, this version looks good to me.
Oddly, it does not seem to apply. I get:
$ git am -3 ~/patch
Applying: Allow stashes to be referenced by index only
Using index info to reconstruct a base tree...
M git-stash.sh
error: patch failed: t/t3903-stash.sh:604
error: t/t3903-stash.sh: patch does not apply
error: Did you hand edit your patch?
It does not apply to blobs recorded in its index.
Patch failed at 0001 Allow stashes to be referenced by index only
The culprit seems to be the final hunk header:
> @@ -604,7 +624,21 @@ test_expect_success 'invalid ref of the form stash@{n}, n >= N' '
This should be "604,6", as there are 6 context lines, and your patch
does not remove any lines.
I suspect the maintainer can fix it up while applying, but for my
curiosity: did you hand-edit it, or is there a potential bug in git's
diff code?
-Peff
^ permalink raw reply
* Re: [PATCH] Allow stashes to be referenced by index only
From: Aaron and Ashley Watson @ 2016-10-25 8:20 UTC (permalink / raw)
To: Jeff King
Cc: git, Jon Seymour, David Caldwell, Øystein Walle,
Ævar Arnfjörð Bjarmason, David Aguilar,
Alex Henrie
In-Reply-To: <20161025081149.x5l5zcupva546ssf@sigill.intra.peff.net>
On Tue, Oct 25, 2016 at 4:11 AM, Jeff King <peff@peff.net> wrote:
> On Mon, Oct 24, 2016 at 07:40:13PM -0400, Aaron M Watson wrote:
>
>> Instead of referencing "stash@{n}" explicitly, it can simply be
>> referenced as "n". Most users only reference stashes by their position
>> in the stash stask (what I refer to as the "index"). The syntax for the
>> typical stash (stash@{n}) is slightly annoying and easy to forget, and
>> sometimes difficult to escape properly in a script. Because of this the
>> capability to do things with the stash by simply referencing the index
>> is desirable.
>>
>> This patch includes the superior implementation provided by Øsse Walle
>> (thanks for that), with a slight change to fix a broken test in the test
>> suite. I also merged the test scripts as suggested by Jeff King, and
>> un-wrapped the documentation as suggested by Junio Hamano.
>>
>> Signed-off-by: Aaron M Watson <watsona4@gmail.com>
>> ---
>
> Thanks, this version looks good to me.
>
> Oddly, it does not seem to apply. I get:
>
> $ git am -3 ~/patch
> Applying: Allow stashes to be referenced by index only
> Using index info to reconstruct a base tree...
> M git-stash.sh
> error: patch failed: t/t3903-stash.sh:604
> error: t/t3903-stash.sh: patch does not apply
> error: Did you hand edit your patch?
> It does not apply to blobs recorded in its index.
> Patch failed at 0001 Allow stashes to be referenced by index only
>
> The culprit seems to be the final hunk header:
>
>> @@ -604,7 +624,21 @@ test_expect_success 'invalid ref of the form stash@{n}, n >= N' '
>
> This should be "604,6", as there are 6 context lines, and your patch
> does not remove any lines.
>
> I suspect the maintainer can fix it up while applying, but for my
> curiosity: did you hand-edit it, or is there a potential bug in git's
> diff code?
I did indeed edit the patch by hand (I forgot to remove the spaces
after the > in the test file), but
the bug appears to be in emacs's diff-mode, not in git.
>
> -Peff
--
Aaron and Ashley Watson
^ permalink raw reply
* Re: Reporting Bug in Git Version Control System
From: Pranit Bauva @ 2016-10-25 8:51 UTC (permalink / raw)
To: Yash Jain; +Cc: Git List
In-Reply-To: <CAN8fUZe4iWJCZYqBBDbNyPq1Dz7f4xvTNRVEZgg5AYN2NrKCbg@mail.gmail.com>
Hey Yash,
Junio has explained the problem very well. Since you seem to be a
beginner (guessing purely by your email) I will tell you how to fix
it.
Remember when you would have first installed git, you would have done
something like `git config --global user.name <what ever name>` and
`git config --global user.email <what ever email>`, it gets
permanently stored in the git configuration file (~/.gitconfig). Now
all the commits in git are made with this name and email. If you want
to change this, again run the above commands with your new name and
email. After that commits will be done with a different name and
email. Hope this helps! :)
Regards,
Pranit Bauva
^ permalink raw reply
* Re: [PATCH v1 00/19] Add configuration options for split-index
From: Duy Nguyen @ 2016-10-25 9:30 UTC (permalink / raw)
To: Junio C Hamano
Cc: Christian Couder, Git Mailing List,
Ævar Arnfjörð Bjarmason, Christian Couder
In-Reply-To: <xmqq8ttd7h8g.fsf@gitster.mtv.corp.google.com>
On Tue, Oct 25, 2016 at 1:07 AM, Junio C Hamano <gitster@pobox.com> wrote:
>> - splitIndex.sharedIndexExpire
>>
>> To make sure that old sharedindex files are eventually removed
>> when a new one has been created, we "touch" the shared index file
>> every time it is used by a new split index file. Then we can
>> delete shared indexes with an mtime older than one week (by
>> default), when we create a new shared index file. The new
>> "splitIndex.sharedIndexExpire" config option lets people tweak
>> this grace period.
>
> I do not quite understand this justification. Doesn't each of the
> "this hold only changes since the base index file" files have a
> backpointer that names the base index file it is a delta against?
Yes, but the shared file does not have pointers to all the files that
need it, which could be more than one. We know one of them,
$GIT_DIR/index, and possibly $GIT_DIR/index.lock too. But those files
people generate manually and refer to them with $GIT_INDEX_FILE, we
can't know where they are.
> Is it safe to remove a base index file when there is still a split
> index file that points at it?
>
> IOW, I do not see why it can be safe for the expiration decision to
> be based on timestamp (I would understand it if it were based on a
> refcnt, though).
Problem is we can't maintain these ref counts cheap and simple. We
don't want to update sharedindex file every time somebody references
to it (or stops referencing to it) because that defeats the purpose of
splitting it out and not touching it any more. Adding a separate file
for ref count could work, but it gets complex, especially when we
think about race condition at update time.
Timestamps allow us to say, ok this base index file has not been read
by anybody for N+ hours (or better, days), it's most likely not
referenced by any temporary index files (including
$GIT_DIR/index.lock) anymore because those files, by the definition of
"temporary", must be gone by now. We should definitely check and make
sure the file $GIT_DIR/index points to still exist. I'm going to read
the series now, so I don't know if the previous sentence is true.
It will probably be harder to handle race condition at updating
$GIT_DIR/index, which could be avoided by a sufficiently long grace
period with timestamps.
--
Duy
^ permalink raw reply
* Re: [PATCH 0/4] nd/ita-empty-commit update
From: Duy Nguyen @ 2016-10-25 9:34 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Git Mailing List
In-Reply-To: <xmqqeg357hou.fsf@gitster.mtv.corp.google.com>
On Tue, Oct 25, 2016 at 12:58 AM, Junio C Hamano <gitster@pobox.com> wrote:
>> The name ita-invisible-in-index is not perfect but I could not think
>> of any better. Another name could be diff-cached-ignores-ita, but
>> that's just half of what it does. The other half is diff-files-includes-ita...
>
> I can't either, and it is one of the reasons why I am reluctant.
> Not being able to be named with a short-and-sweet name often is a
> sign that the thing to be named is conceptually not well thought
> out.
It's implementation detail leak, and probably why naming it for
"normal" people is so hard. Whatever the name is must somehow imply
"so these i-t-a markers actually live in the index and considered real
index entries, associated to empty blob, most of the time..."
> But as we need to give it some name to the flat to ease
> experimenting, let's take that name as-is.
--
Duy
^ permalink raw reply
* Re: [PATCH v1 03/19] split-index: add {add,remove}_split_index() functions
From: Duy Nguyen @ 2016-10-25 9:58 UTC (permalink / raw)
To: Christian Couder
Cc: Git Mailing List, Junio C Hamano,
Ævar Arnfjörð Bjarmason, Christian Couder
In-Reply-To: <20161023092648.12086-4-chriscool@tuxfamily.org>
On Sun, Oct 23, 2016 at 4:26 PM, Christian Couder
<christian.couder@gmail.com> wrote:
> +void remove_split_index(struct index_state *istate)
> +{
> + if (istate->split_index) {
> + /*
> + * can't discard_split_index(&the_index); because that
> + * will destroy split_index->base->cache[], which may
> + * be shared with the_index.cache[]. So yeah we're
> + * leaking a bit here.
In the context of update-index, this is a one-time thing and leaking
is tolerable. But because it becomes a library function now, this leak
can become more serious, I think.
The only other (indirect) caller is read_index_from() so probably not
bad most of the time (we read at the beginning of a command only).
sequencer.c may discard and re-read the index many times though,
leaking could be visible there.
> + */
> + istate->split_index = NULL;
> + istate->cache_changed |= SOMETHING_CHANGED;
> + }
> +}
--
Duy
^ permalink raw reply
* Re: [PATCH v1 05/19] update-index: warn in case of split-index incoherency
From: Duy Nguyen @ 2016-10-25 10:00 UTC (permalink / raw)
To: Christian Couder
Cc: Git Mailing List, Junio C Hamano,
Ævar Arnfjörð Bjarmason, Christian Couder
In-Reply-To: <20161023092648.12086-6-chriscool@tuxfamily.org>
On Sun, Oct 23, 2016 at 4:26 PM, Christian Couder
<christian.couder@gmail.com> wrote:
> When users are using `git update-index --(no-)split-index`, they
> may expect the split-index feature to be used or not according to
> the option they just used, but this might not be the case if the
> new "core.splitIndex" config variable has been set. In this case
> let's warn about what will happen and why.
>
> Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
> ---
> builtin/update-index.c | 11 ++++++++++-
> 1 file changed, 10 insertions(+), 1 deletion(-)
>
> diff --git a/builtin/update-index.c b/builtin/update-index.c
> index b75ea03..a14dbf2 100644
> --- a/builtin/update-index.c
> +++ b/builtin/update-index.c
> @@ -1098,12 +1098,21 @@ int cmd_update_index(int argc, const char **argv, const char *prefix)
> }
>
> if (split_index > 0) {
> + if (git_config_get_split_index() == 0)
> + warning("core.splitIndex is set to false; "
> + "remove or change it, if you really want to "
> + "enable split index");
Wrap this string and the one below with _() so they can be translated.
> if (the_index.split_index)
> the_index.cache_changed |= SPLIT_INDEX_ORDERED;
> else
> add_split_index(&the_index);
> - } else if (!split_index)
> + } else if (!split_index) {
> + if (git_config_get_split_index() == 1)
> + warning("core.splitIndex is set to true; "
> + "remove or change it, if you really want to "
> + "disable split index");
> remove_split_index(&the_index);
> + }
>
> switch (untracked_cache) {
> case UC_UNSPECIFIED:
> --
> 2.10.1.462.g7e1e03a
--
Duy
^ permalink raw reply
* Re: [PATCH v1 09/19] config: add git_config_get_max_percent_split_change()
From: Duy Nguyen @ 2016-10-25 10:06 UTC (permalink / raw)
To: Christian Couder
Cc: Git Mailing List, Junio C Hamano,
Ævar Arnfjörð Bjarmason, Christian Couder
In-Reply-To: <20161023092648.12086-10-chriscool@tuxfamily.org>
On Sun, Oct 23, 2016 at 4:26 PM, Christian Couder
<christian.couder@gmail.com> wrote:
> This new function will be used in a following commit to get the
> +int git_config_get_max_percent_split_change(void)
> +{
> + int val = -1;
> +
> + if (!git_config_get_int("splitindex.maxpercentchange", &val)) {
> + if (0 <= val && val <= 100)
> + return val;
> +
> + error("splitindex.maxpercentchange value '%d' "
We should keep camelCase form for easy reading. And wrap this string with _().
> + "should be between 0 and 100", val);
I wonder if anybody would try to put 12.3 here and confused by the
error message, because 0 <= 12.3 <= 100, but it's not an integer..
Ah.. never mind, die_bad_number() would be called first in this case
with a loud and clear complaint.
> + return -1;
> + }
> +
> + return -1; /* default value */
--
Duy
^ permalink raw reply
* Re: [PATCH v1 10/19] read-cache: regenerate shared index if necessary
From: Duy Nguyen @ 2016-10-25 10:16 UTC (permalink / raw)
To: Christian Couder
Cc: Git Mailing List, Junio C Hamano,
Ævar Arnfjörð Bjarmason, Christian Couder
In-Reply-To: <20161023092648.12086-11-chriscool@tuxfamily.org>
On Sun, Oct 23, 2016 at 4:26 PM, Christian Couder
<christian.couder@gmail.com> wrote:
> @@ -2233,7 +2263,8 @@ int write_locked_index(struct index_state *istate, struct lock_file *lock,
> if ((v & 15) < 6)
> istate->cache_changed |= SPLIT_INDEX_ORDERED;
> }
> - if (istate->cache_changed & SPLIT_INDEX_ORDERED) {
> + if (istate->cache_changed & SPLIT_INDEX_ORDERED ||
> + too_many_not_shared_entries(istate)) {
It's probably safer to keep this piece unchanged and add this
somewhere before it
if (too_many_not_shared_entries(istate))
istate->cache_changed |= SPLIT_INDEX_ORDERED;
We could keep cache_changed consistent until the end this way.
> int ret = write_shared_index(istate, lock, flags);
> if (ret)
> return ret;
> diff --git a/t/t1700-split-index.sh b/t/t1700-split-index.sh
> index db8c39f..507a1dd 100755
> --- a/t/t1700-split-index.sh
> +++ b/t/t1700-split-index.sh
> @@ -8,6 +8,7 @@ test_description='split index mode tests'
> sane_unset GIT_TEST_SPLIT_INDEX
>
> test_expect_success 'enable split index' '
> + git config splitIndex.maxPercentChange 100 &&
An alternative name might be splitThreshold. I don't know, maybe
maxPercentChange is better.
> git update-index --split-index &&
> test-dump-split-index .git/index >actual &&
> indexversion=$(test-index-version <.git/index) &&
> --
> 2.10.1.462.g7e1e03a
>
--
Duy
^ permalink raw reply
* Re: [PATCH v1 14/19] read-cache: touch shared index files when used
From: Duy Nguyen @ 2016-10-25 10:26 UTC (permalink / raw)
To: Christian Couder
Cc: Git Mailing List, Junio C Hamano,
Ævar Arnfjörð Bjarmason, Christian Couder
In-Reply-To: <20161023092648.12086-15-chriscool@tuxfamily.org>
On Sun, Oct 23, 2016 at 4:26 PM, Christian Couder
<christian.couder@gmail.com> wrote:
> @@ -2268,6 +2268,12 @@ int write_locked_index(struct index_state *istate, struct lock_file *lock,
Doing this in read_index_from() would keep the shared file even more
"fresher" since read happens a lot more often than write. But I think
our main concern is not the temporary index files created by the user
scripts, but $GIT_DIR/index.lock (make sure we don't accidentally
delete its shared file before it gets renamed to $GIT_DIR/index). For
this case, I think refreshing in write_locked_index is enough.
> int ret = write_shared_index(istate, lock, flags);
> if (ret)
> return ret;
> + } else {
> + /* Signal that the shared index is used */
> + const char *shared_index = git_path("sharedindex.%s",
> + sha1_to_hex(si->base_sha1));
> + if (!check_and_freshen_file(shared_index, 1))
> + warning("could not freshen '%s'", shared_index);
_()
--
Duy
^ permalink raw reply
* Re: [PATCH v2 1/2] sha1_file: open window into packfiles with CLOEXEC
From: Johannes Schindelin @ 2016-10-25 10:27 UTC (permalink / raw)
To: Lars Schneider; +Cc: git, e, jnareb, gitster
In-Reply-To: <20161024180300.52359-2-larsxschneider@gmail.com>
Hi Lars,
On Mon, 24 Oct 2016, larsxschneider@gmail.com wrote:
> From: Lars Schneider <larsxschneider@gmail.com>
>
> All processes that the Git main process spawns inherit the open file
> descriptors of the main process. These leaked file descriptors can
> cause problems.
>
> Use the CLOEXEC flag similar to 05d1ed61 to fix the leaked file
> descriptors. Since `git_open_noatime` does not describe the function
> properly anymore rename it to `git_open`.
The patch series may be a little bit more pleasant to read if you renamed
git_open_noatime() to git_open() first, in a separate commit.
> @@ -1598,12 +1598,18 @@ int git_open_noatime(const char *name)
> if (fd >= 0)
> return fd;
>
> - /* Might the failure be due to O_NOATIME? */
> - if (errno != ENOENT && sha1_file_open_flag) {
> - sha1_file_open_flag = 0;
> + /* Try again w/o O_CLOEXEC: the kernel might not support it */
> + if (O_CLOEXEC && errno == EINVAL &&
> + (sha1_file_open_flag & O_CLOEXEC)) {
> + sha1_file_open_flag &= ~O_CLOEXEC;
How about
if ((O_CLOEXEC & sha1_file_open_flag) && errno == EINVAL) {
sha1_file_open_flag &= ~O_CLOEXEC;
instead? It is shorter and should be just as easily optimized out by a
C compiler if O_CLOEXEC was defined as 0.
> continue;
> }
>
> + /* Might the failure be due to O_NOATIME? */
> + if (errno != ENOENT && (sha1_file_open_flag & O_NOATIME)) {
> + sha1_file_open_flag &= ~O_NOATIME;
> + continue;
> + }
I *think* the --patience diff option would have made that patch a little
more obvious.
Otherwise, the patch looks fine to me,
Dscho
^ permalink raw reply
* Re: [PATCH v2 2/2] read-cache: make sure file handles are not inherited by child processes
From: Johannes Schindelin @ 2016-10-25 10:33 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Eric Wong, larsxschneider, git, jnareb
In-Reply-To: <xmqqwpgx4j89.fsf@gitster.mtv.corp.google.com>
Hi Junio,
On Mon, 24 Oct 2016, Junio C Hamano wrote:
> Eric Wong <e@80x24.org> writes:
>
> > larsxschneider@gmail.com wrote:
> >> +++ b/read-cache.c
> >> @@ -156,7 +156,11 @@ void fill_stat_cache_info(struct cache_entry *ce, struct stat *st)
> >> static int ce_compare_data(const struct cache_entry *ce, struct stat *st)
> >> {
> >> int match = -1;
> >> - int fd = open(ce->name, O_RDONLY);
> >> + int fd = open(ce->name, O_RDONLY | O_CLOEXEC);
> >> +
> >> + if (O_CLOEXEC && fd < 0 && errno == EINVAL)
> >> + /* Try again w/o O_CLOEXEC: the kernel might not support it */
> >> + fd = open(ce->name, O_RDONLY);
> >
> > In the case of O_CLOEXEC != 0 and repeated EINVALs,
> > it'd be good to use something like sha1_file_open_flag as in 1/2
> > so we don't repeatedly hit EINVAL. Thanks.
>
> Sounds sane.
>
> It's just only once, so perhaps we do not mind a recursion like
> this?
>
> read-cache.c | 9 ++++++---
> 1 file changed, 6 insertions(+), 3 deletions(-)
>
> diff --git a/read-cache.c b/read-cache.c
> index b594865d89..a6978b9321 100644
> --- a/read-cache.c
> +++ b/read-cache.c
> @@ -156,11 +156,14 @@ void fill_stat_cache_info(struct cache_entry *ce, struct stat *st)
> static int ce_compare_data(const struct cache_entry *ce, struct stat *st)
> {
> int match = -1;
> - int fd = open(ce->name, O_RDONLY | O_CLOEXEC);
> + static int cloexec = O_CLOEXEC;
> + int fd = open(ce->name, O_RDONLY | cloexec);
>
> - if (O_CLOEXEC && fd < 0 && errno == EINVAL)
> + if ((cloexec & O_CLOEXEC) && fd < 0 && errno == EINVAL) {
> /* Try again w/o O_CLOEXEC: the kernel might not support it */
> - fd = open(ce->name, O_RDONLY);
> + cloexec &= ~O_CLOEXEC;
> + return ce_compare_data(ce, st);
> + }
>
That still looks overly complicated, repeatedly ORing cloexec and
recursing without need. How about this instead?
static int oflags = O_RDONLY | O_CLOEXEC;
int fd = open(ce->name, oflags);
if ((O_CLOEXEC & oflags) && fd < 0 && errno == EINVAL) {
/* Try again w/o O_CLOEXEC: the kernel might not support it */
oflags &= ~O_CLOEXEC;
fd = open(ce->name, oflags);
}
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH v1 00/19] Add configuration options for split-index
From: Duy Nguyen @ 2016-10-25 10:52 UTC (permalink / raw)
To: Christian Couder
Cc: Git Mailing List, Junio C Hamano,
Ævar Arnfjörð Bjarmason, Christian Couder
In-Reply-To: <20161023092648.12086-1-chriscool@tuxfamily.org>
On Sun, Oct 23, 2016 at 4:26 PM, Christian Couder
<christian.couder@gmail.com> wrote:
> Goal
> ~~~~
>
> We want to make it possible to use the split-index feature
> automatically by just setting a new "core.splitIndex" configuration
> variable to true.
Thanks. This definitely should help make split index a lot more
convenient for day-to-day use. The series looks ok (well, except the
pruning logic being discussed elsewhere in this thread, but I still
think it's a good strategy).
> This can be valuable as split-index can help significantly speed up
> `git rebase` especially along with the work to libify `git apply`
> that has been recently merged to master
> (see https://github.com/git/git/commit/81358dc238372793b1590efa149cc1581d1fbd98).
I remember this. Since the apply libification work has landed, we can
now think about not writing index out after every apply step, which
gives the same (or more) speed up without the complication of
split-index. But if split-index is good enough for you, we can leave
it for another time.
--
Duy
^ permalink raw reply
* Re: [PATCH v1 16/19] read-cache: unlink old sharedindex files
From: Duy Nguyen @ 2016-10-25 10:43 UTC (permalink / raw)
To: Christian Couder
Cc: Git Mailing List, Junio C Hamano,
Ævar Arnfjörð Bjarmason, Christian Couder
In-Reply-To: <20161023092648.12086-17-chriscool@tuxfamily.org>
On Sun, Oct 23, 2016 at 4:26 PM, Christian Couder
<christian.couder@gmail.com> wrote:
> +static int can_delete_shared_index(const char *shared_sha1_hex)
> +{
> + struct stat st;
> + unsigned long expiration;
> + const char *shared_index = git_path("sharedindex.%s", shared_sha1_hex);
> +
> + /* Check timestamp */
> + expiration = get_shared_index_expire_date();
> + if (!expiration)
> + return 0;
> + if (stat(shared_index, &st))
> + return error_errno("could not stat '%s", shared_index);
> + if (st.st_mtime > expiration)
I wonder if we should check ctime too, in case mtime is not reliable
(and ctime is less likely to be manipulated by user), just for extra
safety. If (st.st_mtime > expiration || st.st_ctime > expiration).
> + return 0;
> +
> + return 1;
> +}
> +
> +static void clean_shared_index_files(const char *current_hex)
> +{
> + struct dirent *de;
> + DIR *dir = opendir(get_git_dir());
> +
> + if (!dir) {
> + error_errno("unable to open git dir: %s", get_git_dir());
_()
> + return;
Or just do "return error_errno(...)". The caller can ignore the return
value for now.
> + }
> +
> + while ((de = readdir(dir)) != NULL) {
> + const char *sha1_hex;
> + if (!skip_prefix(de->d_name, "sharedindex.", &sha1_hex))
> + continue;
> + if (!strcmp(sha1_hex, current_hex))
> + continue;
Yeah.. make sure that the shared index linked to $GIT_DIR/index stay,
even if mtime is screwed up. I wonder if we should have the same
treatment for $GIT_DIR/index.lock though, as an extra safety measure.
If you call this function in write_locked_index, then
$GIT_DIR/index.lock is definitely there. Hmm.. maybe it _is_
current_hex, current_hex is not the value from $GIT_DIR/index...
> + if (can_delete_shared_index(sha1_hex) > 0 &&
> + unlink(git_path("%s", de->d_name)))
> + error_errno("unable to unlink: %s", git_path("%s", de->d_name));
_()
> static int write_shared_index(struct index_state *istate,
> @@ -2211,8 +2269,11 @@ static int write_shared_index(struct index_state *istate,
> }
> ret = rename_tempfile(&temporary_sharedindex,
> git_path("sharedindex.%s", sha1_to_hex(si->base->sha1)));
> - if (!ret)
> + if (!ret) {
> hashcpy(si->base_sha1, si->base->sha1);
> + clean_shared_index_files(sha1_to_hex(si->base->sha1));
This operation is technically garbage collection and should belong to
"git gc --auto", which is already called automatically in a few
places. Is it not called often enough that we need to do the cleaning
up right after a new shared index is created?
--
Duy
^ permalink raw reply
* Re: [PATCH] reset: --unmerge
From: Duy Nguyen @ 2016-10-25 11:06 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Git Mailing List
In-Reply-To: <xmqqa8dttkbw.fsf@gitster.mtv.corp.google.com>
On Tue, Oct 25, 2016 at 6:10 AM, Junio C Hamano <gitster@pobox.com> wrote:
> The procedure to resolve a merge conflict typically goes like this:
>
> - first open the file in the editor, and with the help of conflict
> markers come up with a resolution.
>
> - save the file.
>
> - look at the output from "git diff" to see the combined diff to
> double check if the resolution makes sense.
>
> - perform other tests, like trying to build the result with "make".
>
> - finally "git add file" to mark that you are done.
>
> and repeating the above until you are done with all the conflicted
> paths. If you, for whatever reason, accidentally "git add file" by
> mistake until you are convinced that you resolved it correctly (e.g.
> doing "git add file" immediately after saving, without a chance to
> peruse the output from "git diff"), there is no good way to recover.
I made this exact mistake on a giant, half-resolved merge conflict the
other day and panicked. While I prepared myself to script update-index
to restore stages 2 and 3, I found "update-index --unresolve". It
sounds like this "reset --unmerge" is the same functionality, right?
I'm not objecting this patch though, update-index is not something a
casual user should use.
> There is "git checkout -m file" but that overwrites the working tree
> file to reproduce the conflicted state, which is not exactly what
> you want. You only want to reproduce the conflicted state in the
> index, so that you can inspect the (proposed) merge resolution you
> already have in your working tree.
--
Duy
^ permalink raw reply
* Re: [PATCH] reset: --unmerge
From: Duy Nguyen @ 2016-10-25 11:11 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Git Mailing List
In-Reply-To: <CACsJy8B-GcMNv7pYYLpaUXc2kKnvyYEYm6w=fiaHy7rt4aug1Q@mail.gmail.com>
On Tue, Oct 25, 2016 at 6:06 PM, Duy Nguyen <pclouds@gmail.com> wrote:
> On Tue, Oct 25, 2016 at 6:10 AM, Junio C Hamano <gitster@pobox.com> wrote:
>> The procedure to resolve a merge conflict typically goes like this:
>>
>> - first open the file in the editor, and with the help of conflict
>> markers come up with a resolution.
>>
>> - save the file.
>>
>> - look at the output from "git diff" to see the combined diff to
>> double check if the resolution makes sense.
>>
>> - perform other tests, like trying to build the result with "make".
>>
>> - finally "git add file" to mark that you are done.
BTW making git-add (and "git commit -a") refuse files with conflict
markers present could prevent this mistake earlier and is probably a
better option because the user won't have to discover 'reset
--unmerge'. If the user likes to add the file with conflict markers
anyway (because those look like conflict markers but are in fact not)
then they can go with "git add -f" or similar.
--
Duy
^ permalink raw reply
* Re: [PATCH v2 0/2] Use CLOEXEC to avoid fd leaks
From: Johannes Schindelin @ 2016-10-25 11:27 UTC (permalink / raw)
To: Lars Schneider; +Cc: git, e, jnareb, gitster
In-Reply-To: <20161024180300.52359-1-larsxschneider@gmail.com>
Hi Lars,
On Mon, 24 Oct 2016, larsxschneider@gmail.com wrote:
> This mini patch series is necessary to make the "ls/filter-process" topic
> work properly for Windows. Right now the topic generates test failures
> on Windows as reported by Dscho:
> http://public-inbox.org/git/alpine.DEB.2.20.1610211457030.3264@virtualbox/
I acknowledge that this fixes the test failures in Git for Windows' SDK.
Thanks,
Dscho
^ permalink raw reply
* Re: [PATCH] doc: fix the 'revert a faulty merge' ASCII art tab spacing
From: Johannes Schindelin @ 2016-10-25 11:39 UTC (permalink / raw)
To: Philip Oakley; +Cc: gitster, git, peff
In-Reply-To: <20161024215432.1384-1-philipoakley@iee.org>
Hi Philip,
On Mon, 24 Oct 2016, Philip Oakley wrote:
> The asciidoctor doc-tool stack does not always respect the 'tab = 8 spaces' rule
> expectation, particularly for the Git-for-Windows generated html pages. This
> follows on from the 'doc: fix merge-base ASCII art tab spacing' fix.
>
> Use just spaces within the block of the ascii art.
>
> All other *.txt ascii art containing three dashes has been checked.
> Asciidoctor correctly formats the other art blocks that do contain tabs.
>
> Signed-off-by: Philip Oakley <philipoakley@iee.org
> ---
> The git-scm doc pages https://git-scm.com/docs/ does not convert this
> how-to document to html, rather it links to the Github text pages, which
> does respect the 8 space tab rule.
I confirm that this fixes the misaligned branches when building the
documentation with asciidoctor 1.5.4 in Git for Windows' SDK.
Ciao,
Dscho
^ permalink raw reply
* Re: [RFH] limiting ref advertisements
From: Duy Nguyen @ 2016-10-25 11:46 UTC (permalink / raw)
To: Jeff King; +Cc: Git Mailing List
In-Reply-To: <20161024132932.i42rqn2vlpocqmkq@sigill.intra.peff.net>
On Mon, Oct 24, 2016 at 8:29 PM, Jeff King <peff@peff.net> wrote:
> I'm looking into the oft-discussed idea of reducing the size of ref
> advertisements by having the client say "these are the refs I'm
> interested in". Let's set aside the protocol complexities for a
> moment and imagine we magically have some way to communicate a set of
> patterns to the server.
>
> What should those patterns look like?
>
> I had hoped that we could keep most of the pattern logic on the
> client-side. Otherwise we risk incompatibilities between how the client
> and server interpret a pattern. I had also hoped we could do some kind
> of prefix-matching, which would let the server look only at the
> interesting bits of the ref tree (so if you don't care about
> refs/changes, and the server has some ref storage that is hierarchical,
> they can literally get away without opening that sub-tree).
>
> The patch at the end of this email is what I came up with in that
> direction. It obviously won't compile without the twenty other patches
> implementing transport->advertise_prefixes
Yes! git-upload-pack-2 is making a come back, one form or another.
> but it gives you a sense of what I'm talking about.
>
> Unfortunately it doesn't work in all cases, because refspec sources may
> be unqualified. If I ask for:
>
> git fetch $remote master:foo
>
> then we have to actually dwim-resolve "master" from the complete list of
> refs we get from the remote. It could be "refs/heads/master",
> "refs/tags/master", etc. Worse, it could be "refs/master". In that case,
> at least, I think we are OK because we avoid advertising refs directly
> below "refs/" in the first place. But if you have a slash, like:
>
> git fetch $remote jk/foo
>
> then that _could_ be "refs/jk/foo". Likewise, we cannot even optimize
> the common case of a fully-qualified ref, like "refs/heads/foo". If it
> exists, we obviously want to use that. But if it doesn't, then it
> could be refs/something-else/refs/heads/foo. That's unlikely, but it
> _does_ work now, and optimizing the advertisement would break it.
>
> So it seems like left-anchoring the refspecs can never be fully correct.
> We can communicate "master" to the server, who can then look at every
> ref it would advertise and ask "could this be called master"? But it
> will be setting in stone the set of "could this be" patterns. Granted,
> those haven't changed much over the history of git, but it seems awfully
> fragile.
The first thought that comes to mind is, if left anchoring does not
work, let's support both left and right anchoring. I guess you
considered and discarded this.
If prefix matching does not work, and assuming "some-prefix" sent by
client to be in fact "**/some-prefix" pattern at server side will set
the "could this be" in stone, how about use wildmatch? It's flexible
enough and we have full control over the pattern matching engine so C
Git <-> C Git should be good regardless of platforms. I understand
that wildmatch is still complicated enough that a re-implementation
can easily divert in behavior. But a pattern with only '*', '/**',
'/**/' and '**/' wildcards (in other words, no [] or ?) could make the
engine a lot simpler and still fit our needs (and give some room for
client-optimization).
> In an ideal world the client and server would negotiate to come to some
> agreement on the patterns being used. But as we are bolting this onto
> the existing protocol, I was really trying to do it without introducing
> an extra capabilities phase or extra round-trips. I.e., something like
> David Turner's "stick the refspec in the HTTP query parameters" trick,
> but working everywhere[1].
--
Duy
^ 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