date:20180815

Re: Measuring Community Involvement (was Re: Contributor Summit planning)

2018-08-15 Thread Eric Wong

Jeff King  wrote:
> On Tue, Aug 14, 2018 at 12:47:59PM -0700, Stefan Beller wrote:
> > With the advent of public inbox, this is easy to obtain?
> 
> For our project, yes. But I was thinking of a tool that could be used
> for other projects, too.

Nothing prevents public-inbox from being adopted by other projects :)
Fwiw, Linux Foundation has LKML at https://lore.kernel.org/lkml

Re: [PATCH 1/2] store submodule in common dir

2018-08-15 Thread Joakim Tjernlund

On Tue, 2018-08-14 at 16:20 -0700, Junio C Hamano wrote:
> CAUTION: This email originated from outside of the organization. Do not click 
> links or open attachments unless you recognize the sender and know the 
> content is safe.
> 
> 
> Junio C Hamano  writes:
> 
> > My understanding of what Joakim wants to do is to have a top-level
> > project that has three subdirectories, e.g. kernel/v2.2, kernel/v2.4
> > and kernel/v2.6, each of which is a submodule that houses these
> > versions of Linux kernel source, but only clone Linus's repository
> > (as the up-to-late tree has all the necessary history to check out
> > these past development tracks).  And that should be doable with
> > just the main checkout, without any additional worktree (it's just
> > the matter of having .git/modules/kernel%2fv2.6/ directory pointed
> > by two symlinks from .git/modules/kernel%2fv2.[24], or something
> > like that).
> 
> Actually I take the last part of that back.  When thought naively
> about, it may appear that it should be doable, but because each of
> the modules/* directory in the top-level project has to serve as the
> $GIT_DIR for each submodule checkout, and the desire is to have
> these three directories to have checkout of three different
> branches, a single directory under modules/. that is shared among
> three submodules would *not* work---they must have separate index,
> HEAD, etc.
> 
> Theoretically we should be able to make modules/kernel%2fv2.[24]
> additional "worktree"s of modules/kernel%2fv2.6, but given that
> these are all "bare" repositories without an attached working tree,
> I am not sure how that would supposed to work.  Thinking about
> having multiple worktrees on a single bare repository makes me head
> spin and ache X-<;-)

You nailed it ! :)
My head spins just reading this so I think I got my answer. I can be done
but will be tricky to impl. 
I will keep an eye on how submodules develops, sure would be a welcome feature.

 Jocke

Re: [PATCH 1/2] store submodule in common dir

2018-08-15 Thread Joakim Tjernlund

On Wed, 2018-08-15 at 10:28 +0200, Joakim Tjernlund wrote:
> On Tue, 2018-08-14 at 16:20 -0700, Junio C Hamano wrote:
> > CAUTION: This email originated from outside of the organization. Do not 
> > click links or open attachments unless you recognize the sender and know 
> > the content is safe.
> > 
> > 
> > Junio C Hamano  writes:
> > 
> > > My understanding of what Joakim wants to do is to have a top-level
> > > project that has three subdirectories, e.g. kernel/v2.2, kernel/v2.4
> > > and kernel/v2.6, each of which is a submodule that houses these
> > > versions of Linux kernel source, but only clone Linus's repository
> > > (as the up-to-late tree has all the necessary history to check out
> > > these past development tracks).  And that should be doable with
> > > just the main checkout, without any additional worktree (it's just
> > > the matter of having .git/modules/kernel%2fv2.6/ directory pointed
> > > by two symlinks from .git/modules/kernel%2fv2.[24], or something
> > > like that).
> > 
> > Actually I take the last part of that back.  When thought naively
> > about, it may appear that it should be doable, but because each of
> > the modules/* directory in the top-level project has to serve as the
> > $GIT_DIR for each submodule checkout, and the desire is to have
> > these three directories to have checkout of three different
> > branches, a single directory under modules/. that is shared among
> > three submodules would *not* work---they must have separate index,
> > HEAD, etc.
> > 
> > Theoretically we should be able to make modules/kernel%2fv2.[24]
> > additional "worktree"s of modules/kernel%2fv2.6, but given that
> > these are all "bare" repositories without an attached working tree,
> > I am not sure how that would supposed to work.  Thinking about
> > having multiple worktrees on a single bare repository makes me head
> > spin and ache X-<;-)
> 
> You nailed it ! :)
> My head spins just reading this so I think I got my answer. I can be done
> but will be tricky to impl. 
> I will keep an eye on how submodules develops, sure would be a welcome 
> feature.
> 
>  Jocke

On a related note, it would be great if git could support sparse checkout/clone
for submodules, now one have to manually add .git/info/sparse-checkout.
If sparse clone and sparse checkout could be saved in the submodule, then there
would be no problem with 3 copies of the same repo in my submodules.

 Jocke

[PATCH 2/2] rebase -i: fix SIGSEGV when 'merge ' fails

2018-08-15 Thread Phillip Wood

From: Phillip Wood 

If a merge command in the todo list specifies just a branch to merge
with no -C/-c argument then item->commit is NULL. This means that if
there are merge conflicts error_with_patch() is passed a NULL commit
which causes a segmentation fault when make_patch() tries to look it up.

This commit implements a minimal fix which fixes the crash and allows
the user to successfully commit a conflict resolution with 'git rebase
--continue'. It does not write .git/rebase-merge/patch,
.git/rebase-merge/stopped-sha or update REBASE_HEAD. To sensibly get the
hashes of the merge parents would require refactoring do_merge() to
extract the code that parses the merge parents into a separate function
which error_with_patch() could then use to write the parents into the
stopped-sha file. To create meaningful output make_patch() and 'git
rebase --show-current-patch' would also need to be modified to diff the
merge parent and merge base in this case.

Signed-off-by: Phillip Wood 
---
 sequencer.c  | 24 +++-
 t/t3430-rebase-merges.sh | 15 ++-
 2 files changed, 33 insertions(+), 6 deletions(-)

diff --git a/sequencer.c b/sequencer.c
index 4034c0461b..df49199175 100644
--- a/sequencer.c
+++ b/sequencer.c
@@ -2590,8 +2590,12 @@ static int error_with_patch(struct commit *commit,
const char *subject, int subject_len,
struct replay_opts *opts, int exit_code, int to_amend)
 {
-   if (make_patch(commit, opts))
-   return -1;
+   if (commit) {
+   if (make_patch(commit, opts))
+   return -1;
+   } else if (copy_file(rebase_path_message(), git_path_merge_msg(), 0666))
+   return error(_("unable to copy '%s' to '%s'"),
+git_path_merge_msg(), rebase_path_message());
 
if (to_amend) {
if (intend_to_amend())
@@ -2604,9 +2608,19 @@ static int error_with_patch(struct commit *commit,
"Once you are satisfied with your changes, run\n"
"\n"
"  git rebase --continue\n", gpg_sign_opt_quoted(opts));
-   } else if (exit_code)
-   fprintf(stderr, "Could not apply %s... %.*s\n",
-   short_commit_name(commit), subject_len, subject);
+   } else if (exit_code) {
+   if (commit)
+   fprintf(stderr, "Could not apply %s... %.*s\n",
+   short_commit_name(commit),
+   subject_len, subject);
+   else
+   /*
+* We don't have the hash of the parent so
+* just print the line from the todo file.
+*/
+   fprintf(stderr, "Could not merge %.*s\n",
+   subject_len, subject);
+   }
 
return exit_code;
 }
diff --git a/t/t3430-rebase-merges.sh b/t/t3430-rebase-merges.sh
index 31fe4268d5..2e767d4f1e 100755
--- a/t/t3430-rebase-merges.sh
+++ b/t/t3430-rebase-merges.sh
@@ -129,7 +129,7 @@ test_expect_success '`reset` refuses to overwrite untracked 
files' '
git rebase --abort
 '
 
-test_expect_success 'failed `merge` writes patch (may be rescheduled, too)' '
+test_expect_success 'failed `merge -C` writes patch (may be rescheduled, too)' 
'
test_when_finished "test_might_fail git rebase --abort" &&
git checkout -b conflicting-merge A &&
 
@@ -151,6 +151,19 @@ test_expect_success 'failed `merge` writes patch (may be 
rescheduled, too)' '
test_path_is_file .git/rebase-merge/patch
 '
 
+SQ="'"
+test_expect_success 'failed `merge ` does not crash' '
+   test_when_finished "test_might_fail git rebase --abort" &&
+   git checkout conflicting-G &&
+
+   echo "merge G" >script-from-scratch &&
+   test_config sequence.editor \""$PWD"/replace-editor.sh\" &&
+   test_tick &&
+   test_must_fail git rebase -ir HEAD &&
+   ! grep "^merge G$" .git/rebase-merge/git-rebase-todo &&
+   grep "^Merge branch ${SQ}G${SQ}$" .git/rebase-merge/message
+'
+
 test_expect_success 'with a branch tip that was cherry-picked already' '
git checkout -b already-upstream master &&
base="$(git rev-parse --verify HEAD)" &&
-- 
2.18.0

[PATCH 0/2] rebase -i: fix SIGSEGV when 'merge ' fails

2018-08-15 Thread Phillip Wood

From: Phillip Wood 

As they fix a bug these patches are based on maint. Unfortunately
the second patch has semantic conflicts with master

s/git_path_merge_msg()/git_path_merge_msg(the_repository)/

There are additional textual conflicts with pu/next due to some
messages being marked for translation. The new message here should be
marked for translation to match them.

Phillip Wood (2):
  t3430: add conflicting commit
  rebase -i: fix SIGSEGV when 'merge ' fails

 sequencer.c  | 24 +++-
 t/t3430-rebase-merges.sh | 30 +++---
 2 files changed, 42 insertions(+), 12 deletions(-)

-- 
2.18.0

[PATCH 1/2] t3430: add conflicting commit

2018-08-15 Thread Phillip Wood

From: Phillip Wood 

Move the creation of conflicting-G from a test to the setup so that it
can be used in subsequent tests without creating the kind of implicit
dependencies that plague t3404. While we're at it simplify the
arguments to the test_commit() call the creates the conflicting commit.

Signed-off-by: Phillip Wood 
---
 t/t3430-rebase-merges.sh | 15 +--
 1 file changed, 9 insertions(+), 6 deletions(-)

diff --git a/t/t3430-rebase-merges.sh b/t/t3430-rebase-merges.sh
index 78f7c99580..31fe4268d5 100755
--- a/t/t3430-rebase-merges.sh
+++ b/t/t3430-rebase-merges.sh
@@ -13,8 +13,10 @@ Initial setup:
 -- B --   (first)
/   \
  A - C - D - E - H(master)
-   \   /
- F - G(second)
+   \\   /
+\F - G(second)
+ \
+  Conflicting-G
 '
 . ./test-lib.sh
 . "$TEST_DIRECTORY"/lib-rebase.sh
@@ -49,7 +51,9 @@ test_expect_success 'setup' '
git merge --no-commit G &&
test_tick &&
git commit -m H &&
-   git tag -m H H
+   git tag -m H H &&
+   git checkout A &&
+   test_commit conflicting-G G.t
 '
 
 test_expect_success 'create completely different structure' '
@@ -72,7 +76,7 @@ test_expect_success 'create completely different structure' '
EOF
test_config sequence.editor \""$PWD"/replace-editor.sh\" &&
test_tick &&
-   git rebase -i -r A &&
+   git rebase -i -r A master &&
test_cmp_graph <<-\EOF
*   Merge the topic branch '\''onebranch'\''
|\
@@ -141,8 +145,7 @@ test_expect_success 'failed `merge` writes patch (may be 
rescheduled, too)' '
 
: fail because of merge conflict &&
rm G.t .git/rebase-merge/patch &&
-   git reset --hard &&
-   test_commit conflicting-G G.t not-G conflicting-G &&
+   git reset --hard conflicting-G &&
test_must_fail git rebase --continue &&
! grep "^merge -C .* G$" .git/rebase-merge/git-rebase-todo &&
test_path_is_file .git/rebase-merge/patch
-- 
2.18.0

[PATCH] rebase -i: fix numbering in squash message

2018-08-15 Thread Phillip Wood

From: Phillip Wood 

Commit e12a7ef597 ("rebase -i: Handle "combination of  commits" with
GETTEXT_POISON", 2018-04-27) changed the way that individual commit
messages are labelled when squashing commits together. In doing so a
regression was introduced where the numbering of the messages is off by
one. This commit fixes that and adds a test for the numbering.

Signed-off-by: Phillip Wood 
---
 sequencer.c| 4 ++--
 t/t3418-rebase-continue.sh | 4 +++-
 2 files changed, 5 insertions(+), 3 deletions(-)

diff --git a/sequencer.c b/sequencer.c
index 2eb5ec7227..77d3c2346f 100644
--- a/sequencer.c
+++ b/sequencer.c
@@ -1387,13 +1387,13 @@ static int update_squash_messages(enum todo_command 
command,
unlink(rebase_path_fixup_msg());
strbuf_addf(&buf, "\n%c ", comment_line_char);
strbuf_addf(&buf, _("This is the commit message #%d:"),
-   ++opts->current_fixup_count);
+   ++opts->current_fixup_count + 1);
strbuf_addstr(&buf, "\n\n");
strbuf_addstr(&buf, body);
} else if (command == TODO_FIXUP) {
strbuf_addf(&buf, "\n%c ", comment_line_char);
strbuf_addf(&buf, _("The commit message #%d will be skipped:"),
-   ++opts->current_fixup_count);
+   ++opts->current_fixup_count + 1);
strbuf_addstr(&buf, "\n\n");
strbuf_add_commented_lines(&buf, body, strlen(body));
} else
diff --git a/t/t3418-rebase-continue.sh b/t/t3418-rebase-continue.sh
index e9fd029160..ee871dd1bb 100755
--- a/t/t3418-rebase-continue.sh
+++ b/t/t3418-rebase-continue.sh
@@ -128,13 +128,15 @@ test_expect_success '--skip after failed fixup cleans 
commit message' '
: The first squash was skipped, therefore: &&
git show HEAD >out &&
test_i18ngrep "# This is a combination of 2 commits" out &&
+   test_i18ngrep "# This is the commit message #2:" out &&
 
(test_set_editor "$PWD/copy-editor.sh" && git rebase --skip) &&
git show HEAD >out &&
test_i18ngrep ! "# This is a combination" out &&
 
: Final squash failed, but there was still a squash &&
-   test_i18ngrep "# This is a combination of 2 commits" .git/copy.txt
+   test_i18ngrep "# This is a combination of 2 commits" .git/copy.txt &&
+   test_i18ngrep "# This is the commit message #2:" .git/copy.txt
 '
 
 test_expect_success 'setup rerere database' '
-- 
2.18.0

[PATCH] branch: support configuring --sort via .gitconfig

2018-08-15 Thread samuel . maftoul

From: Samuel Maftoul 

Add support for configuring default sort ordering for git branches. Command
line option will override this configured value, using the exact same
syntax.
---
 Documentation/config.txt |  5 +
 Documentation/git-branch.txt |  4 
 builtin/branch.c | 10 +-
 t/t3200-branch.sh| 46 
 4 files changed, 64 insertions(+), 1 deletion(-)

diff --git a/Documentation/config.txt b/Documentation/config.txt
index 63365dcf3..82e306d20 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -1034,6 +1034,11 @@ branch.autoSetupRebase::
branch to track another branch.
This option defaults to never.
 
+branch.sort::
+   This variable controls the sort ordering of branches when displayed by
+   linkgit:git-branch[1]. Without the "--sort=" option provided, the
+   value of this variable will be used as the default.
+
 branch..remote::
When on branch , it tells 'git fetch' and 'git push'
which remote to fetch from/push to.  The remote to push to
diff --git a/Documentation/git-branch.txt b/Documentation/git-branch.txt
index 1072ca0eb..9212a8d5d 100644
--- a/Documentation/git-branch.txt
+++ b/Documentation/git-branch.txt
@@ -272,6 +272,10 @@ start-point is either a local or remote-tracking branch.
full refname (including `refs/...` prefix). This lists
detached HEAD (if present) first, then local branches and
finally remote-tracking branches.
+   The keys supported are the same as those in `git for-each-ref`.
+   Sort order defaults to the value configured for the `tag.sort`
+   variable if it exists, or lexicographic order otherwise. See
+   linkgit:git-config[1].
 
 
 --points-at ::
diff --git a/builtin/branch.c b/builtin/branch.c
index 4fc55c350..bbd006aab 100644
--- a/builtin/branch.c
+++ b/builtin/branch.c
@@ -74,6 +74,14 @@ define_list_config_array(color_branch_slots);
 static int git_branch_config(const char *var, const char *value, void *cb)
 {
const char *slot_name;
+   struct ref_sorting **sorting_tail = (struct ref_sorting **)cb;
+
+   if (!strcmp(var, "branch.sort")) {
+   if (!value)
+   return config_error_nonbool(var);
+   parse_ref_sorting(sorting_tail, value);
+   return 0;
+   }
 
if (starts_with(var, "column."))
return git_column_config(var, value, "branch", &colopts);
@@ -653,7 +661,7 @@ int cmd_branch(int argc, const char **argv, const char 
*prefix)
if (argc == 2 && !strcmp(argv[1], "-h"))
usage_with_options(builtin_branch_usage, options);
 
-   git_config(git_branch_config, NULL);
+   git_config(git_branch_config, sorting_tail);
 
track = git_branch_track;
 
diff --git a/t/t3200-branch.sh b/t/t3200-branch.sh
index dbca665da..8bd42e9c6 100755
--- a/t/t3200-branch.sh
+++ b/t/t3200-branch.sh
@@ -1305,4 +1305,50 @@ test_expect_success 'tracking with unexpected .fetch 
refspec' '
)
 '
 
+test_expect_success 'configured committerdate sort' '
+   git init sort &&
+   (
+   cd sort &&
+   git config branch.sort committerdate &&
+   test_commit initial &&
+   git checkout -b a &&
+   test_commit a &&
+   git checkout -b c &&
+   test_commit c &&
+   git checkout -b b &&
+   test_commit b &&
+   git branch >actual &&
+   cat >expect <<-\EOF &&
+ master
+ a
+ c
+   * b
+   EOF
+   test_cmp expect actual
+   )
+'
+
+test_expect_success 'option override configured sort' '
+   (
+   cd sort &&
+   git branch --sort=refname >actual &&
+   cat >expect <<-\EOF &&
+ a
+   * b
+ c
+ master
+   EOF
+   test_cmp expect actual
+   )
+'
+
+test_expect_success 'invalid sort parameter in configuration' '
+   (
+   cd sort &&
+   git config branch.sort "v:notvalid" &&
+   test_must_fail git branch
+
+   )
+'
+
 test_done
-- 
2.14.3 (Apple Git-98)

Re: [PATCH 4/7] for_each_packed_object: support iterating in pack-order

2018-08-15 Thread Derrick Stolee


On 8/10/2018 7:15 PM, Jeff King wrote:

diff --git a/commit-graph.c b/commit-graph.c
index b0a55ad128..69a0d1c203 100644
--- a/commit-graph.c
+++ b/commit-graph.c
@@ -730,7 +730,7 @@ void write_commit_graph(const char *obj_dir,
die("error adding pack %s", packname.buf);
if (open_pack_index(p))
die("error opening index for %s", packname.buf);
-   for_each_object_in_pack(p, add_packed_commits, &oids);
+   for_each_object_in_pack(p, add_packed_commits, &oids, 
0);
close_pack(p);
}


This use in write_commit_graph() is actually a good candidate for 
pack-order, since we are checking each object to see if it is a commit. 
This is only used when running `git commit-graph write --stdin-packs`, 
which is how VFS for Git maintains the commit-graph.


I have a note to run performance tests on this case and follow up with a 
change on top of this series that adds the FOR_EACH_OBJECT_PACK_ORDER flag.


Thanks,

-Stolee

Re: [PATCH 0/7] speeding up cat-file by reordering object access

2018-08-15 Thread Derrick Stolee

On 8/10/2018 7:07 PM, Jeff King wrote:

The general idea is that accessing objects in packfile order is way
kinder to the delta base cache, and thus way more efficient. See patches
4 and 7 in particular for discussion and numbers.

I'm primarily interested in cat-file, so this series is focused there.
But there may be other callers of for_each_packed_object() who could
benefit. Most of the existing ones just care about getting the oid, so
they're better off as-is. It's possible the call in is_promisor_object()
could benefit, since it calls parse_object() on each entry it visits. I
didn't experiment with it.

I like this series, and the follow-up. I could not find any problems
with it.

One thing that I realized while reading it is that the multi-pack-index
is not integrated into the for_each_packed_object method. I was already
going to work on some cleanups in that area [1][2].

When using the new flag with the multi-pack-index, I expect that we will
want to load the pack-files that are covered by the multi-pack-index
(simply, the 'packs' array) and use the same mechanism to traverse them
in order. The only "strange" thing about this is that we would see
duplicate objects when traversing the pack-files directly but not when
traversing the multi-pack-index (since it de-duplicates when indexing).

1 2 >

1 - 100 of 139 matches

Mail list logo