* Draft of Git Rev News edition 22
From: Christian Couder @ 2016-12-11 22:24 UTC (permalink / raw)
To: git
Cc: Thomas Ferris Nicolaisen, Jakub Narebski, Markus Jansen,
Johannes Schindelin, Junio C Hamano, Jeff King, Michael Haggerty,
David Aguilar, Dun Peal, Stefan Beller, Robert Dailey,
Jacob Keller
Hi,
A draft of a new Git Rev News edition is available here:
https://github.com/git/git.github.io/blob/master/rev_news/drafts/edition-22.md
Everyone is welcome to contribute in any section either by editing the
above page on GitHub and sending a pull request, or by commenting on
this GitHub issue:
https://github.com/git/git.github.io/issues/208
You can also reply to this email.
I tried to cc everyone who appears in this edition but maybe I missed
some people, sorry about that.
Thomas, Jakub, Markus (who is now part of the team, welcome Markus!)
and myself plan to publish this edition on Wednesday December 14.
Thanks,
Christian.
^ permalink raw reply
* [PATCH 2/3] update_unicode.sh: remove the plane filters
From: Beat Bolli @ 2016-12-11 23:34 UTC (permalink / raw)
To: git; +Cc: Beat Bolli
In-Reply-To: <1481499265-18361-1-git-send-email-dev+git@drbeat.li>
The uniset upstream has accepted my patches that eliminate the Unicode
plane offsets from the output in '--32' mode.
Remove the corresponding filter in update_unicode.sh.
Signed-off-by: Beat Bolli <dev+git@drbeat.li>
---
update_unicode.sh | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/update_unicode.sh b/update_unicode.sh
index 9ca7d8b..e595bf8 100755
--- a/update_unicode.sh
+++ b/update_unicode.sh
@@ -31,11 +31,10 @@ fi &&
UNICODE_DIR=. && export UNICODE_DIR &&
cat >$UNICODEWIDTH_H <<-EOF
static const struct interval zero_width[] = {
- $(uniset/uniset --32 cat:Me,Mn,Cf + U+1160..U+11FF - U+00AD |
- grep -v plane)
+ $(uniset/uniset --32 cat:Me,Mn,Cf + U+1160..U+11FF - U+00AD)
};
static const struct interval double_width[] = {
- $(uniset/uniset --32 eaw:F,W | grep -v plane)
+ $(uniset/uniset --32 eaw:F,W)
};
EOF
)
--
2.7.2
^ permalink raw reply related
* [PATCH 3/3] update_unicode.sh: restore hexadecimal output
From: Beat Bolli @ 2016-12-11 23:34 UTC (permalink / raw)
To: git; +Cc: Beat Bolli
In-Reply-To: <1481499265-18361-1-git-send-email-dev+git@drbeat.li>
The uniset upstream has decided that decimal numbers are The True Way, so
let's convert them back to the usual format that's closer to the U+nnnn
standard.
The generated unicode_widths.h file again looks exactly the same as two
commits ago.
Signed-off-by: Beat Bolli <dev+git@drbeat.li>
---
update_unicode.sh | 8 +++++++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/update_unicode.sh b/update_unicode.sh
index e595bf8..d7720d5 100755
--- a/update_unicode.sh
+++ b/update_unicode.sh
@@ -5,6 +5,12 @@
#Mn Nonspacing_Mark a nonspacing combining mark (zero advance width)
#Cf Format a format control character
#
+
+dec_to_hex() {
+ # convert any decimal numbers to 4-digit hex
+ perl -pe 's/(\d+)/sprintf("0x%04X", $1)/ge'
+}
+
UNICODEWIDTH_H=../unicode_width.h
if ! test -d unicode; then
mkdir unicode
@@ -29,7 +35,7 @@ fi &&
make
) &&
UNICODE_DIR=. && export UNICODE_DIR &&
- cat >$UNICODEWIDTH_H <<-EOF
+ dec_to_hex >$UNICODEWIDTH_H <<-EOF
static const struct interval zero_width[] = {
$(uniset/uniset --32 cat:Me,Mn,Cf + U+1160..U+11FF - U+00AD)
};
--
2.7.2
^ permalink raw reply related
* [PATCH 1/3] update_unicode.sh: update the uniset repo if it exists
From: Beat Bolli @ 2016-12-11 23:34 UTC (permalink / raw)
To: git; +Cc: Beat Bolli
We need to track the new commits in uniset, otherwise their and our code
get out of sync.
Signed-off-by: Beat Bolli <dev+git@drbeat.li>
---
Junio, these go on top of my bb/unicode-9.0 branch, please.
Thanks!
update_unicode.sh | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/update_unicode.sh b/update_unicode.sh
index 4c1ec8d..9ca7d8b 100755
--- a/update_unicode.sh
+++ b/update_unicode.sh
@@ -14,6 +14,11 @@ fi &&
http://www.unicode.org/Public/UCD/latest/ucd/EastAsianWidth.txt &&
if ! test -d uniset; then
git clone https://github.com/depp/uniset.git
+ else
+ (
+ cd uniset &&
+ git pull
+ )
fi &&
(
cd uniset &&
--
2.7.2
^ permalink raw reply related
* Re: [PATCH v3 1/2] gitk: alter the ordering for the "Tags and heads" view
From: Paul Mackerras @ 2016-12-11 23:25 UTC (permalink / raw)
To: Michael Rappazzo; +Cc: git
In-Reply-To: <1459091168-46908-2-git-send-email-rappazzo@gmail.com>
On Sun, Mar 27, 2016 at 11:06:07AM -0400, Michael Rappazzo wrote:
> In the "Tags and heads" view, the list of refs is globally sorted.
> Because of this, the list of local refs (heads) can be interrupted by the
> list of remote refs. This change re-orders the view to be: local refs,
> remote refs tracked by local refs, remote refs, tags, and then other refs.
>
> Signed-off-by: Michael Rappazzo <rappazzo@gmail.com>
This all looks OK except for the fact that the loop immediately below
the code you've modified (the loop that adds or deletes lines from the
actual displayed list) relies on the entries being in sorted order.
With your patch the entries are no longer strictly in sorted order, so
that display update loop will have to become a bit smarter too. As it
is, I think that there will be cases where we will delete a lot of
lines and then re-add them. If the user had scrolled the list to a
particular point that was within these deleted lines, the display will
scroll away from that point, which will be annoying.
Paul.
^ permalink raw reply
* Re: [PATCH] gitk: Makefile: create install bin directory
From: Paul Mackerras @ 2016-12-12 0:01 UTC (permalink / raw)
To: Vasco Almeida; +Cc: git
In-Reply-To: <1462470392-19991-1-git-send-email-vascomalmeida@sapo.pt>
On Thu, May 05, 2016 at 05:46:32PM +0000, Vasco Almeida wrote:
> Force creation of destination bin directory. Before this commit, gitk
> would fail to install if this directory didn't already exist.
>
> Signed-off-by: Vasco Almeida <vascomalmeida@sapo.pt>
Thanks, applied (with slight tweak to commit message).
Paul.
^ permalink raw reply
* Re: [PATCH v2 0/2] gitk: Two improvements to the branch context menu
From: Paul Mackerras @ 2016-12-12 0:02 UTC (permalink / raw)
To: Rogier Goossens; +Cc: git
In-Reply-To: <10662590.KWXHt2RUKZ@wiske>
On Sat, Mar 19, 2016 at 07:31:32PM +0100, Rogier Goossens wrote:
> Hi,
>
> Hereby the revised patches.
>
> Changes since v1:
> - Rebased on latest master
> - Made the changes you suggested
> - Moved 'rename branch' menu option above 'delete branch'
> - Cleaned up some code duplication that the previous patches
> introduced.
Thanks, series applied.
Paul.
^ permalink raw reply
* Re: [PATCH v3] gitk: Fix missing commits when using -S or -G
From: Paul Mackerras @ 2016-12-12 0:39 UTC (permalink / raw)
To: Stefan Dotterweich; +Cc: git
In-Reply-To: <1f857709-3c47-d4a1-b858-3288347416f8@gmx.de>
On Sat, Jun 04, 2016 at 10:47:16AM +0200, Stefan Dotterweich wrote:
> When -S or -G is used as a filter option, the resulting commit list
> rarely contains all matching commits. Only a certain number of commits
> are displayed and the rest are missing.
>
> "git log --boundary -S" does not return as many boundary commits as you
> might expect. gitk makes up for this in closevargs() by adding missing
> parent (boundary) commits. However, it does not change $numcommits,
> which limits how many commits are shown. In the end, some commits at the
> end of the commit list are simply not shown.
>
> Change $numcommits whenever a missing parent is added.
>
> Signed-off-by: Stefan Dotterweich <stefandotterweich@gmx.de>
Thanks, applied, with slight tweaks to the commit message.
Paul.
^ permalink raw reply
* Re: [PATCH] Gitk Inotify support
From: Paul Mackerras @ 2016-12-12 1:58 UTC (permalink / raw)
To: Florian Schüller; +Cc: git@vger.kernel.org
In-Reply-To: <CAHdOBFpOm3hf4XPjpSZ0+8rVgyKj+e3qT0cecU4j9ms=+chnDg@mail.gmail.com>
On Sat, Jun 11, 2016 at 04:06:36PM +0200, Florian Schüller wrote:
> >From 74d2f4c1ec560b358fb50b8b7fe8282e7e1457b0 Mon Sep 17 00:00:00 2001
> From: =?UTF-8?q?Florian=20Sch=C3=BCller?= <florian.schueller@gmail.com>
> Date: Thu, 9 Jun 2016 22:54:43 +0200
> Subject: [PATCH] first support for inotify
> MIME-Version: 1.0
> Content-Type: text/plain; charset=UTF-8
> Content-Transfer-Encoding: 8bit
>
> Just automatically update gitk when working in a terminal on the same repo
>
> Open points for now:
> - release watches for deleted directories seems to
> cause problems in tcl-inotify (so I don't)
> I'm not sure how often that happens in ".git/"
> - I only call "updatecommits" and I don't know if there is a usecase
> where I should be calling "reloadcommits"
Thanks for the patch. It's a nice idea. I think it needs a couple of
improvements, though, to make it work even better:
* Some users might not want this behaviour, so we need an option in
the preferences pane to enable/disable this.
* I would expect that the updates to the files in .git would come in
bursts, so we should probably do something like wait until (say) one
second has elapsed since the last notification, without any more
notifications, before starting the update.
* We probably want to rate-limit the updates, since on a large tree
(e.g. the Linux kernel) the update can take several seconds and the
UI is less responsive during that time.
Paul.
^ permalink raw reply
* Re: [PATCH v4] gitk: Add Portuguese translation
From: Paul Mackerras @ 2016-12-12 0:35 UTC (permalink / raw)
To: Vasco Almeida; +Cc: git
In-Reply-To: <1462996893-24341-1-git-send-email-vascomalmeida@sapo.pt>
On Wed, May 11, 2016 at 08:01:33PM +0000, Vasco Almeida wrote:
> Signed-off-by: Vasco Almeida <vascomalmeida@sapo.pt>
> ---
>
> Oops, fix typo.
Thanks, applied.
Paul.
^ permalink raw reply
* [PATCH] submodule--helper: set alternateLocation for cloned submodules
From: vi0oss @ 2016-12-12 2:45 UTC (permalink / raw)
To: gitster; +Cc: git, stefanbeller, Vitaly "_Vi" Shukela
From: "Vitaly \"_Vi\" Shukela" <vi0oss@gmail.com>
In 31224cbdc7 (clone: recursive and reference option triggers
submodule alternates, 2016-08-17) a mechanism was added to
have submodules referenced. It did not address _nested_
submodules, however.
This patch makes all not just the root repository, but also
all submodules (recursively) have submodule.alternateLocation
and submodule.alternateErrorStrategy configured, making Git
search for possible alternates for nested submodules as well.
As submodule's alternate target does not end in .git/objects
(rather .git/modules/qqqqqq/objects), this alternate target
path restriction for in add_possible_reference_from_superproject
relates from "*.git/objects" to just */objects".
New tests have been added to t7408-submodule-reference.
Signed-off-by: Vitaly _Vi Shukela <vi0oss@gmail.com>
---
Notes:
Reviewed by Stefan Beller <sbeller@google.com>
For "maint" branch.
builtin/submodule--helper.c | 19 ++++++++++--
t/t7408-submodule-reference.sh | 66 ++++++++++++++++++++++++++++++++++++++++++
2 files changed, 83 insertions(+), 2 deletions(-)
diff --git a/builtin/submodule--helper.c b/builtin/submodule--helper.c
index 4beeda5..92fd676 100644
--- a/builtin/submodule--helper.c
+++ b/builtin/submodule--helper.c
@@ -498,9 +498,9 @@ static int add_possible_reference_from_superproject(
/*
* If the alternate object store is another repository, try the
- * standard layout with .git/modules/<name>/objects
+ * standard layout with .git/(modules/<name>)+/objects
*/
- if (ends_with(alt->path, ".git/objects")) {
+ if (ends_with(alt->path, "/objects")) {
char *sm_alternate;
struct strbuf sb = STRBUF_INIT;
struct strbuf err = STRBUF_INIT;
@@ -583,6 +583,7 @@ static int module_clone(int argc, const char **argv, const char *prefix)
struct strbuf rel_path = STRBUF_INIT;
struct strbuf sb = STRBUF_INIT;
struct string_list reference = STRING_LIST_INIT_NODUP;
+ char *sm_alternate = NULL, *error_strategy = NULL;
struct option module_clone_options[] = {
OPT_STRING(0, "prefix", &prefix,
@@ -672,6 +673,20 @@ static int module_clone(int argc, const char **argv, const char *prefix)
die(_("could not get submodule directory for '%s'"), path);
git_config_set_in_file(p, "core.worktree",
relative_path(path, sm_gitdir, &rel_path));
+
+ /* setup alternateLocation and alternateErrorStrategy in the cloned submodule if needed */
+ git_config_get_string("submodule.alternateLocation", &sm_alternate);
+ if (sm_alternate)
+ git_config_set_in_file(p, "submodule.alternateLocation",
+ sm_alternate);
+ git_config_get_string("submodule.alternateErrorStrategy", &error_strategy);
+ if (error_strategy)
+ git_config_set_in_file(p, "submodule.alternateErrorStrategy",
+ error_strategy);
+
+ free(sm_alternate);
+ free(error_strategy);
+
strbuf_release(&sb);
strbuf_release(&rel_path);
free(sm_gitdir);
diff --git a/t/t7408-submodule-reference.sh b/t/t7408-submodule-reference.sh
index 1c1e289..e159fc5 100755
--- a/t/t7408-submodule-reference.sh
+++ b/t/t7408-submodule-reference.sh
@@ -125,4 +125,70 @@ test_expect_success 'ignoring missing submodule alternates passes clone and subm
)
'
+test_expect_success 'preparing second superproject with a nested submodule plus partial clone' '
+ test_create_repo supersuper &&
+ (
+ cd supersuper &&
+ echo "I am super super." >file &&
+ git add file &&
+ git commit -m B-super-super-initial
+ git submodule add "file://$base_dir/super" subwithsub &&
+ git commit -m B-super-super-added &&
+ git submodule update --init --recursive &&
+ git repack -ad
+ ) &&
+ git clone supersuper supersuper2 &&
+ (
+ cd supersuper2 &&
+ git submodule update --init
+ )
+'
+
+# At this point there are three root-level positories: A, B, super and super2
+
+test_expect_success 'nested submodule alternate in works and is actually used' '
+ test_when_finished "rm -rf supersuper-clone" &&
+ git clone --recursive --reference supersuper supersuper supersuper-clone &&
+ (
+ cd supersuper-clone &&
+ # test superproject has alternates setup correctly
+ test_alternate_is_used .git/objects/info/alternates . &&
+ # immediate submodule has alternate:
+ test_alternate_is_used .git/modules/subwithsub/objects/info/alternates subwithsub &&
+ # nested submodule also has alternate:
+ test_alternate_is_used .git/modules/subwithsub/modules/sub/objects/info/alternates subwithsub/sub
+ )
+'
+
+check_that_two_of_three_alternates_are_used() {
+ test_alternate_is_used .git/objects/info/alternates . &&
+ # immediate submodule has alternate:
+ test_alternate_is_used .git/modules/subwithsub/objects/info/alternates subwithsub &&
+ # but nested submodule has no alternate:
+ test_must_fail test_alternate_is_used .git/modules/subwithsub/modules/sub/objects/info/alternates subwithsub/sub
+}
+
+
+test_expect_success 'missing nested submodule alternate fails clone and submodule update' '
+ test_when_finished "rm -rf supersuper-clone" &&
+ test_must_fail git clone --recursive --reference supersuper2 supersuper2 supersuper-clone &&
+ (
+ cd supersuper-clone &&
+ check_that_two_of_three_alternates_are_used &&
+ # update of the submodule fails
+ test_must_fail git submodule update --init --recursive
+ )
+'
+
+test_expect_success 'missing nested submodule alternate in --reference-if-able mode' '
+ test_when_finished "rm -rf supersuper-clone" &&
+ git clone --recursive --reference-if-able supersuper2 supersuper2 supersuper-clone &&
+ (
+ cd supersuper-clone &&
+ check_that_two_of_three_alternates_are_used &&
+ # update of the submodule succeeds
+ git submodule update --init --recursive
+ )
+'
+
test_done
--
2.10.2
^ permalink raw reply related
* Re: [PATCH] submodule--helper: set alternateLocation for cloned submodules
From: Stefan Beller @ 2016-12-12 5:35 UTC (permalink / raw)
To: vi0oss; +Cc: Stefan Beller, git@vger.kernel.org
In-Reply-To: <12000496-2191-2915-8a9e-fe7c314c5676@gmail.com>
On Sat, Dec 10, 2016 at 5:41 AM, vi0oss <vi0oss@gmail.com> wrote:
> On 12/08/2016 04:38 AM, vi0oss@gmail.com wrote:
>>
>> Third review: missing && in test fixed.
>>
>
> Shall something more be done about this or just wait until the patch gets
> reviewed and integrated?
I have no further comments and think the most recent version you sent
to the list
is fine. However others are invited to comment as well. :)
Thanks,
Stefan
^ permalink raw reply
* Re: [PATCH v2 12/16] pathspec: create parse_long_magic function
From: Stefan Beller @ 2016-12-12 5:38 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Brandon Williams, git@vger.kernel.org, Duy Nguyen
In-Reply-To: <xmqqk2b7ps08.fsf@gitster.mtv.corp.google.com>
On Sat, Dec 10, 2016 at 10:18 AM, Junio C Hamano <gitster@pobox.com> wrote:
> Stefan Beller <sbeller@google.com> writes:
>
>> Jonathan Nieder mentioned off list that he prefers to see that
>> series rerolled without mutexes if possible. That is possible by
>> creating the questions "struct attr_check" before preloading the
>> index and then using the read only questions in the threaded code,
>> to obtain answers fast; also no need for a mutex.
>
> I do not see how it would work without further splitting the
> attr_stack. I think you made it per check[], but you would further
> split it per <check, thread> before losing the mutex, no?
Well I have not yet looked into it again, so my memories are
rusty, but the <check> is read only, such that the answers only
need to be per thread?
^ permalink raw reply
* Re: [PATCH 1/3] update_unicode.sh: update the uniset repo if it exists
From: Torsten Bögershausen @ 2016-12-12 5:53 UTC (permalink / raw)
To: Beat Bolli, git
In-Reply-To: <1481499265-18361-1-git-send-email-dev+git@drbeat.li>
On 2016-12-12 00:34, Beat Bolli wrote:
> We need to track the new commits in uniset, otherwise their and our code
> get out of sync.
>
> Signed-off-by: Beat Bolli <dev+git@drbeat.li>
> ---
>
> Junio, these go on top of my bb/unicode-9.0 branch, please.
>
> Thanks!
>
> update_unicode.sh | 5 +++++
> 1 file changed, 5 insertions(+)
>
> diff --git a/update_unicode.sh b/update_unicode.sh
> index 4c1ec8d..9ca7d8b 100755
> --- a/update_unicode.sh
> +++ b/update_unicode.sh
> @@ -14,6 +14,11 @@ fi &&
> http://www.unicode.org/Public/UCD/latest/ucd/EastAsianWidth.txt &&
> if ! test -d uniset; then
> git clone https://github.com/depp/uniset.git
> + else
> + (
> + cd uniset &&
> + git pull
If upstream has accepted your patches, that's nice.
Minor question, especially to the next commit:
Should we make sure to checkout the exact version, which has been tested?
In this case cb97792880625e24a9f581412d03659091a0e54f
And this is for both a fresh clone and the git pull
needs to be replaced by
git fetch && git checkout cb97792880625e24a9f581412d03659091a0e54f
(Which of course is a shell variable
^ permalink raw reply
* Re: [PATCH v2 12/16] pathspec: create parse_long_magic function
From: Junio C Hamano @ 2016-12-12 6:19 UTC (permalink / raw)
To: Stefan Beller; +Cc: Brandon Williams, git@vger.kernel.org, Duy Nguyen
In-Reply-To: <CAGZ79kbbk4vdW_mbC0riXOf=31V9AQV7zKEh56G+sxjjzAr2-g@mail.gmail.com>
Stefan Beller <sbeller@google.com> writes:
>> I do not see how it would work without further splitting the
>> attr_stack. I think you made it per check[], but you would further
>> split it per <check, thread> before losing the mutex, no?
>
> Well I have not yet looked into it again, so my memories are
> rusty, but the <check> is read only, such that the answers only
> need to be per thread?
<check> is read-only, so as long as you populate the singleton
attr's beforehand, they can be shared across threads. <answer>
of course needs an instance per thread, and that is why you have
them typically on stack.
The process of filling <answer> by asking for a set of attrs in
<check> for one <path> goes roughly like:
- make sure attr_stack is set up for <path>, namely, the
info/attributes and .gitattributes files for each leading
directory are parsed.
- go over the attr_stack entries and see what entries match <path>,
and collect the result for <check> in <answer>
Before d90675c151 ("attr: keep attr stack for each check",
2016-11-10), I had only one instance of an attr stack [*1*], but
with that commit, you made it per <check>, which is a good move to
allow us to optimize by keeping only the attributes relevant to
<check> on the attr stack.
But it does not solve the threading issue.
If multiple threads are asking for the same set of attrs
(i.e. running the same codepath using the same <check>) but for
<path>s in different parts of the working tree (e.g. "git checkout"
that is multi-threaded, each thread asking for eol related
attributes and checking out different subdirectories), you'd need
mutex for correct operation at least, but that won't perform well
because you'd end up thrashing the attr stack. You'd need to split
attr stack further and make it per (<check>, thread) tuple and you
no longer need mutex at that point, but not before that.
[footnote]
*1* This is because the attr subsystem originally wasn't designed to
be used from multiple threads at the same time hence it was
sufficient to have a single "currently interested are of the
directory hierarchy".
^ permalink raw reply
* Re: [PATCH 2/2] mergetools/tortoisemerge: simplify can_diff() by using "false"
From: David Aguilar @ 2016-12-12 7:16 UTC (permalink / raw)
To: Johannes Sixt; +Cc: Junio C Hamano, Git ML
In-Reply-To: <37d8bc43-9f24-b8e8-cb52-de9cc9b2adde@kdbg.org>
On Sat, Dec 10, 2016 at 09:15:34AM +0100, Johannes Sixt wrote:
> Am 10.12.2016 um 04:21 schrieb David Aguilar:
> > Signed-off-by: David Aguilar <davvid@gmail.com>
> > ---
> > This patch builds upon da/mergetool-trust-exit-code
> >
> > mergetools/tortoisemerge | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/mergetools/tortoisemerge b/mergetools/tortoisemerge
> > index d7ab666a59..9067d8a4e5 100644
> > --- a/mergetools/tortoisemerge
> > +++ b/mergetools/tortoisemerge
> > @@ -1,5 +1,5 @@
> > can_diff () {
> > - return 1
> > + false
> > }
>
> Why is this a simplification?
>
> My concern is that 'false' is not necessarily a shell built-in. Then this is
> actually a pessimization.
The "simplification" is semantic only.
Motivation: if someone reads the implementation of can_diff()
and it says "false" then that communicates intent moreso than
reading "return 1", which a programmer unfamiliar with shell
conventions might misinterpret as boolean "true".
I care less about semantics then I do about making things better
for Windows, so we can forget about these two patches.
--
David
^ permalink raw reply
* [RFC/PATCH] merge: Add '--continue' option as a synonym for 'git commit'
From: Chris Packham @ 2016-12-12 8:34 UTC (permalink / raw)
To: git; +Cc: peff, jacob.keller, gitster, Chris Packham
In-Reply-To: <CAFOYHZAsU_gNb=_K=iMFKFdt60SJ4Wm=Ag5=XMXuQgxNxCqWLA@mail.gmail.com>
Teach 'git merge' the --continue option which allows 'continuing' a
merge by completing it. The traditional way of completing a merge after
resolving conflicts is to use 'git commit'. Now with commands like 'git
rebase' and 'git cherry-pick' having a '--continue' option adding such
an option to 'git merge' presents a consistent UI.
Signed-off-by: Chris Packham <judge.packham@gmail.com>
---
So here is a quick patch that adds the --continue option. I need to add
some tests (suggestions for where to start are welcome).
Documentation/git-merge.txt | 13 ++++++++++++-
builtin/merge.c | 17 ++++++++++++++++-
2 files changed, 28 insertions(+), 2 deletions(-)
diff --git a/Documentation/git-merge.txt b/Documentation/git-merge.txt
index b758d5556..765b0f26e 100644
--- a/Documentation/git-merge.txt
+++ b/Documentation/git-merge.txt
@@ -15,6 +15,7 @@ SYNOPSIS
[--[no-]rerere-autoupdate] [-m <msg>] [<commit>...]
'git merge' <msg> HEAD <commit>...
'git merge' --abort
+'git merge' --continue
DESCRIPTION
-----------
@@ -61,6 +62,9 @@ reconstruct the original (pre-merge) changes. Therefore:
discouraged: while possible, it may leave you in a state that is hard to
back out of in the case of a conflict.
+The fourth syntax ("`git merge --continue`") can only be run after the
+merge has resulted in conflicts. 'git merge --continue' will take the
+currently staged changes and complete the merge.
OPTIONS
-------
@@ -99,6 +103,12 @@ commit or stash your changes before running 'git merge'.
'git merge --abort' is equivalent to 'git reset --merge' when
`MERGE_HEAD` is present.
+--continue::
+ Take the currently staged changes and complete the merge.
++
+'git merge --continue' is equivalent to 'git commit' when
+`MERGE_HEAD` is present.
+
<commit>...::
Commits, usually other branch heads, to merge into our branch.
Specifying more than one commit will create a merge with
@@ -277,7 +287,8 @@ After seeing a conflict, you can do two things:
* Resolve the conflicts. Git will mark the conflicts in
the working tree. Edit the files into shape and
- 'git add' them to the index. Use 'git commit' to seal the deal.
+ 'git add' them to the index. Use 'git merge --continue' to seal the
+ deal.
You can work through the conflict with a number of tools:
diff --git a/builtin/merge.c b/builtin/merge.c
index b65eeaa87..1ce18cbbe 100644
--- a/builtin/merge.c
+++ b/builtin/merge.c
@@ -65,6 +65,7 @@ static int option_renormalize;
static int verbosity;
static int allow_rerere_auto;
static int abort_current_merge;
+static int continue_current_merge;
static int allow_unrelated_histories;
static int show_progress = -1;
static int default_to_upstream = 1;
@@ -223,6 +224,8 @@ static struct option builtin_merge_options[] = {
OPT__VERBOSITY(&verbosity),
OPT_BOOL(0, "abort", &abort_current_merge,
N_("abort the current in-progress merge")),
+ OPT_BOOL(0, "continue", &continue_current_merge,
+ N_("continue the current in-progress merge")),
OPT_BOOL(0, "allow-unrelated-histories", &allow_unrelated_histories,
N_("allow merging unrelated histories")),
OPT_SET_INT(0, "progress", &show_progress, N_("force progress reporting"), 1),
@@ -739,7 +742,7 @@ static void abort_commit(struct commit_list *remoteheads, const char *err_msg)
if (err_msg)
error("%s", err_msg);
fprintf(stderr,
- _("Not committing merge; use 'git commit' to complete the merge.\n"));
+ _("Not committing merge; use 'git merge --continue' to complete the merge.\n"));
write_merge_state(remoteheads);
exit(1);
}
@@ -1166,6 +1169,18 @@ int cmd_merge(int argc, const char **argv, const char *prefix)
goto done;
}
+ if (continue_current_merge) {
+ int nargc = 1;
+ const char *nargv[] = {"commit", NULL};
+
+ if (!file_exists(git_path_merge_head()))
+ die(_("There is no merge in progress (MERGE_HEAD missing)."));
+
+ /* Invoke 'git commit' */
+ ret = cmd_commit(nargc, nargv, prefix);
+ goto done;
+ }
+
if (read_cache_unmerged())
die_resolve_conflict("merge");
--
2.11.0
^ permalink raw reply related
* Re: [PATCH 1/3] update_unicode.sh: update the uniset repo if it exists
From: Beat Bolli @ 2016-12-12 8:54 UTC (permalink / raw)
To: Torsten Bögershausen; +Cc: git
In-Reply-To: <64bc846c-0304-dd7b-73bf-a6c3a4135381@web.de>
On 2016-12-12 06:53, Torsten Bögershausen wrote:
> On 2016-12-12 00:34, Beat Bolli wrote:
>> We need to track the new commits in uniset, otherwise their and our
>> code
>> get out of sync.
>>
>> Signed-off-by: Beat Bolli <dev+git@drbeat.li>
>> ---
>>
>> Junio, these go on top of my bb/unicode-9.0 branch, please.
>>
>> Thanks!
>>
>> update_unicode.sh | 5 +++++
>> 1 file changed, 5 insertions(+)
>>
>> diff --git a/update_unicode.sh b/update_unicode.sh
>> index 4c1ec8d..9ca7d8b 100755
>> --- a/update_unicode.sh
>> +++ b/update_unicode.sh
>> @@ -14,6 +14,11 @@ fi &&
>> http://www.unicode.org/Public/UCD/latest/ucd/EastAsianWidth.txt &&
>> if ! test -d uniset; then
>> git clone https://github.com/depp/uniset.git
>> + else
>> + (
>> + cd uniset &&
>> + git pull
> If upstream has accepted your patches, that's nice.
>
> Minor question, especially to the next commit:
> Should we make sure to checkout the exact version, which has been
> tested?
> In this case cb97792880625e24a9f581412d03659091a0e54f
>
> And this is for both a fresh clone and the git pull
> needs to be replaced by
> git fetch && git checkout cb97792880625e24a9f581412d03659091a0e54f
>
>
> (Which of course is a shell variable)
I was actually wondering what the policy was for adding submodules to
the Git repo,
but then decided against it. Another option would be to fork uniset on
GitHub and
just let it stay on a working commit.
Junio, what's your stance on this?
Beat
^ permalink raw reply
* Re: [RFC/PATCH] merge: Add '--continue' option as a synonym for 'git commit'
From: Markus Hitter @ 2016-12-12 9:02 UTC (permalink / raw)
To: Chris Packham, git; +Cc: peff, jacob.keller, gitster
In-Reply-To: <20161212083413.7334-1-judge.packham@gmail.com>
Am 12.12.2016 um 09:34 schrieb Chris Packham:
> Teach 'git merge' the --continue option which allows 'continuing' a
> merge by completing it. The traditional way of completing a merge after
> resolving conflicts is to use 'git commit'. Now with commands like 'git
> rebase' and 'git cherry-pick' having a '--continue' option adding such
> an option to 'git merge' presents a consistent UI.
Like.
While Junio is entirely right that this is redundant, the inner workings of Git are just voodoo for a (guessed) 95% of users out there, so a consistent UI is important.
> DESCRIPTION
> -----------
> @@ -61,6 +62,9 @@ reconstruct the original (pre-merge) changes. Therefore:
> discouraged: while possible, it may leave you in a state that is hard to
> back out of in the case of a conflict.
>
> +The fourth syntax ("`git merge --continue`") can only be run after the
> +merge has resulted in conflicts. 'git merge --continue' will take the
> +currently staged changes and complete the merge.
I think this should mention the equivalence to 'git commit'.
Markus
--
- - - - - - - - - - - - - - - - - - -
Dipl. Ing. (FH) Markus Hitter
http://www.jump-ing.de/
^ permalink raw reply
* Re: Proposal for an increased `gitk` cohesion with `git stash`.
From: Paul Mackerras @ 2016-12-12 9:36 UTC (permalink / raw)
To: Uxío Prego; +Cc: git
In-Reply-To: <CANidDKZRisodpQgqyYaG_tCi0+EyxYv+t8+Entp0joMSetd3oA@mail.gmail.com>
Hi Uxio,
On Thu, Sep 08, 2016 at 03:41:29PM +0200, Uxío Prego wrote:
> Hello, please forgive me for not introducing me.
>
> +-----------+
> |Description|
> +-----------+
>
> Patch for showing all stashes in `gitk`.
>
> +-----------+
> |The problem|
> +-----------+
>
> Being `gitk` one of the best tools for navigating and understanding graphs
> of git repo revs, I got used to have it for home use, some years ago, soon
> for office use too.
>
> At some point I got used to invoke always `gitk --all` in order to keep
> tracking of tags when using the program for building, when possible, stable
> versions of any GNU/Linux software I would want to use.
>
> It seems `gitk --all` uses `git show-ref` for showing remotes information.
> A side effect of this is that the most recent stash gets shown in `gitk
> --all`. After learning what the stash was, I got used to it.
>
> Later, when at jobs, I got used to have a stash on all working branch tips.
> So I often would have several stashes in `git stash list` but only the last
> one in `gitk --all`. That annoyed me for about a year, finally I got
> working in `gitk` to show a stash status more similar to what `git stash
> list` shows.
>
> +-----------+
> |The feature|
> +-----------+
>
> Show all stashes in `gitk` instead of only the last one.
This seems like a good feature, although I don't use stashes myself.
> +------------------+
> |Why it's desirable|
> +------------------+
>
> In order to have better visual control when working on repos that have
> several active branches and there are needed quick context changes between
> them with the features that `git stash [apply [STASHNAME]| list | pop
> [STASHNAME]| push | save | show [[-p] STASHNAME]]`.
>
> In order to have a better cohesion between the mentioned features and `gitk
> --all`.
>
> +------------------------+
> |Caveats and side effects|
> +------------------------+
>
> With this patch several side effects happen:
>
> * Stashes are shown even invoking `gitk`, not only when running `gitk
> --all`. If this is a problem, I can keep working in the patch to avoid this.
>
> * The most recent stash, which was previously shown as 'stash' because its
> corresponding `git show-ref` output line reads 'refs/stash', gets shown as
> 'stash@{0}'. Not removing lines with 'stash' when calling `git show-ref`
> gets it shown both as 'stash' as usual and as 'stash@{0}'.
>
> +--------------------------+
> |Non-obvious design choices|
> +--------------------------+
>
> There are many improvable things consequence of never having edited
> anything Tcl before this. Besides, its working for me as a proof of
> concept, both in Debian 7 Wheezy and 8 Jessie.
>
> The origin document of the following diff is `gitk` as it ships in Debian 8
> Jessie. I have not tried yet but if required I would be willing to rework
> it for the repo master.
A patch against the latest version in my git repo at
git://ozlabs.org/~paulus/gitk would be better.
> `gitk-stash-list-ids.sh` is a shell script that performs `git stash list
> --pretty=format:"%H"`, i.e. show rev hashes for all stashes in the fashion
> that `git rev-list --all` does its default output. I did this because I
> could not work out a better pure Tcl solution.
Hmmm, I don't want gitk to have to depend on an external script.
It should be possible to make Tcl execute the git command directly,
though (see below).
> +--------------------+
> |Unified diff follows|
> +--------------------+
>
> 0:10:1473338052:uprego@uxio:~$ diff -u /usr/bin/gitk-deb8-vanilla
> /usr/bin/gitk-deb8-multistash
> --- /usr/bin/gitk-deb8-vanilla 2016-08-29 10:07:06.507344629 +0200
> +++ /usr/bin/gitk-deb8-multistash 2016-09-08 14:36:35.382476634 +0200
> @@ -401,6 +401,10 @@
>
> if {$vcanopt($view)} {
> set revs [parseviewrevs $view $vrevs($view)]
> + set stashesfd [open [concat | gitk-stash-list-ids.sh] r]
set stashesfd [open [list | git stash list {--pretty=format:%H}] r]
> + while {[gets $stashesfd stashline] >= 0} {
> + set revs [lappend revs $stashline]
> + }
Could this ever take a long time? The UI is unresponsive while we're
in this loop. If this is always quick (even on large repos), OK. If
it could take a long time then we'll need a file event handler.
> if {$revs eq {}} {
> return 0
> }
> @@ -1778,7 +1782,7 @@
> foreach v {tagids idtags headids idheads otherrefids idotherrefs} {
> catch {unset $v}
> }
> - set refd [open [list | git show-ref -d] r]
> + set refd [open [list | git show-ref -d | grep -v stash] r]
If I had a branch called "dont-use-a-stash-for-this", would it get
filtered out by this grep? It seems like it would, and we don't want
it to. So the filtering needs to be more exact here.
> while {[gets $refd line] >= 0} {
> if {[string index $line 40] ne " "} continue
> set id [string range $line 0 39]
> @@ -1811,6 +1815,16 @@
> }
> }
> catch {close $refd}
> + set stashesidsrefsd [open [list | gitk-stash-list-ids-refs.sh] r]
set stashesidsrefsd [open [list | \
git stash list {--pretty=format:%H %gD}] r]
Paul.
^ permalink raw reply
* Re: [PATCH] gitk: Fix Japanese translation for "marked commit"
From: Paul Mackerras @ 2016-12-12 9:37 UTC (permalink / raw)
To: Satoshi Yasushima; +Cc: git
In-Reply-To: <20161024153510.9212-1-s.yasushima@gmail.com>
On Tue, Oct 25, 2016 at 12:35:10AM +0900, Satoshi Yasushima wrote:
> Signed-off-by: Satoshi Yasushima <s.yasushima@gmail.com>
> ---
> po/ja.po | 9 +++++----
> 1 file changed, 5 insertions(+), 4 deletions(-)
Applied, thanks,
Paul.
^ permalink raw reply
* Re: [RFC/PATCH] merge: Add '--continue' option as a synonym for 'git commit'
From: Jeff King @ 2016-12-12 9:40 UTC (permalink / raw)
To: Chris Packham; +Cc: git, jacob.keller, gitster
In-Reply-To: <20161212083413.7334-1-judge.packham@gmail.com>
On Mon, Dec 12, 2016 at 09:34:13PM +1300, Chris Packham wrote:
> Teach 'git merge' the --continue option which allows 'continuing' a
> merge by completing it. The traditional way of completing a merge after
> resolving conflicts is to use 'git commit'. Now with commands like 'git
> rebase' and 'git cherry-pick' having a '--continue' option adding such
> an option to 'git merge' presents a consistent UI.
>
> Signed-off-by: Chris Packham <judge.packham@gmail.com>
> ---
> So here is a quick patch that adds the --continue option. I need to add
> some tests (suggestions for where to start are welcome).
I'm not sure if there's much to test besides concluding a successful
merge, and possibly some error cases where --continue should complain.
Probably that could go at the end of t7600.
> @@ -1166,6 +1169,18 @@ int cmd_merge(int argc, const char **argv, const char *prefix)
> goto done;
> }
>
> + if (continue_current_merge) {
> + int nargc = 1;
> + const char *nargv[] = {"commit", NULL};
> +
> + if (!file_exists(git_path_merge_head()))
> + die(_("There is no merge in progress (MERGE_HEAD missing)."));
> +
> + /* Invoke 'git commit' */
> + ret = cmd_commit(nargc, nargv, prefix);
> + goto done;
> + }
> +
I know this block is just adapted from the "--abort" one above, but
should both of these complain when other arguments are given? I can't
imagine what the user might mean with "git merge --no-commit
--continue", but probably it should be an error. :)
-Peff
^ permalink raw reply
* Re: [PATCH 0/3] gitk: memory consumption improvements
From: Paul Mackerras @ 2016-12-12 9:51 UTC (permalink / raw)
To: Markus Hitter; +Cc: git@vger.kernel.org
In-Reply-To: <de7cd593-0c10-4e93-1681-7e123504f5d5@jump-ing.de>
On Mon, Nov 07, 2016 at 07:54:28PM +0100, Markus Hitter wrote:
>
> List, Paul,
>
> after searching for a while on why Gitk sometimes consumes exorbitant amounts of memory I found a pair of minor issues and also a big one: the text widget comes with an unlimited undo manager, which is turned on be default. Considering that each line is inserted seperately, this piles up a huuuge undo stack ... for a read-only text widget. Simply turning off this undo manager saves about 95% of memory when viewing large commits (with tens of thousands of diff lines).
>
> 3 patches are about to follow:
>
> - turn off the undo manager,
>
> - forget already closed file descriptors and
>
> - forget the 'commitinfo' array on a reload to enforce reloading it.
>
> I hope this finds you appreciation.
Thanks for the good work in tracking this down and making the patches.
I have applied the series. Apologies for slow response (life has been
extremely busy for me this year).
Paul.
^ permalink raw reply
* Re: [PATCH 0/1] Fix a long-standing isatty() problem on Windows
From: Johannes Schindelin @ 2016-12-12 9:59 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Pranit Bauva
In-Reply-To: <xmqqmvg2nyo6.fsf@gitster.mtv.corp.google.com>
Hi Junio,
On Sun, 11 Dec 2016, Junio C Hamano wrote:
> Johannes Schindelin <johannes.schindelin@gmx.de> writes:
>
> > I finally got a chance to debug the problems with the ever-timing-out
> > test runs of `pu` on Windows. Turns out that pb/bisect uncovered a
> > really old, really bad bug: on Windows, isatty() does not do what Git
> > expects, at least not completely: it detects interactive terminals *and
> > character devices*.
>
> Sounds as if somebody who did Windows at Microsoft had a good sense
> of humor to mimick the misnamed ENOTTY gotcha ;-)
Hehe...
> This is a great find, and a very impactful fix, as redirecting from
> /dev/null is how we try to force a "go interactive if talking to
> tty" program to realize that it is not talking to a tty.
Can we fast-track this to maint?
I will definitely ship this fix in the next Git for Windows version, but
still, it would be nice to have this in git.git as soon as possible.
Thanks,
Dscho
^ permalink raw reply
* Re: [PATCH v8 00/19] port branch.c to use ref-filter's printing options
From: Karthik Nayak @ 2016-12-12 10:42 UTC (permalink / raw)
To: Jacob Keller; +Cc: Git mailing list, Junio C Hamano, Jakub Narębski
In-Reply-To: <CA+P7+xquordVY19dypqNcAuQqoRbFmHhzb0w+HXCaJmm_Ex7zQ@mail.gmail.com>
On Thu, Dec 8, 2016 at 5:31 AM, Jacob Keller <jacob.keller@gmail.com> wrote:
>> diff --git a/Documentation/git-for-each-ref.txt b/Documentation/git-for-each-ref.txt
>> index f4ad297..c72baeb 100644
>> --- a/Documentation/git-for-each-ref.txt
>> +++ b/Documentation/git-for-each-ref.txt
>> @@ -92,13 +92,14 @@ refname::
>> The name of the ref (the part after $GIT_DIR/).
>> For a non-ambiguous short name of the ref append `:short`.
>> The option core.warnAmbiguousRefs is used to select the strict
>> - abbreviation mode. If `strip=<N>` is appended, strips `<N>`
>> - slash-separated path components from the front of the refname
>> - (e.g., `%(refname:strip=2)` turns `refs/tags/foo` into `foo`.
>> - `<N>` must be a positive integer. If a displayed ref has fewer
>> - components than `<N>`, the command aborts with an error. For the base
>> - directory of the ref (i.e. foo in refs/foo/bar/boz) append
>> - `:base`. For the entire directory path append `:dir`.
>> + abbreviation mode. If `lstrip=<N>` or `rstrip=<N>` option can
>
> Grammar here, drop the If before `lstrip since you're referring to
> multiples and you say "x can be appended to y" rather than "if x is
> added, do y"
>
Will do. Thanks.
>> + be appended to strip `<N>` slash-separated path components
>> + from or end of the refname respectively (e.g.,
>> + `%(refname:lstrip=2)` turns `refs/tags/foo` into `foo` and
>> + `%(refname:rstrip=2)` turns `refs/tags/foo` into `refs`). if
>> + `<N>` is a negative number, then only `<N>` path components
>> + are left behind. If a displayed ref has fewer components than
>> + `<N>`, the command aborts with an error.
>>
>
> Would it make more sense to not die and instead just return the empty
> string? On the one hand, if we die() it's obvious that you tried to
> strip too many components. But on the other hand, it's also somewhat
> annoying to have the whole command fail because we happen upon a
> single ref that has fewer components?
>
> So, for positive numbers, we simply strip what we can, which may
> result in the empty string, and for negative numbers, we keep up to
> what we said, while potentially keeping the entire string. I feel
> that's a better alternative than a die() in the middle of a ref
> filter..
>
> What are other people's thoughts on this?
I am _for_ this. Even I think it'd be better to return an empty string rather
than just die in the middle.
--
Regards,
Karthik Nayak
^ 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