Re: Bring together merge and rebase

On Tue, Dec 26, 2017 at 06:49:56PM +0100, Ævar Arnfjörð Bjarmason wrote: > New headers should be added after existing headers, but other than > that it won't choke on it. See 4b2bced559 when the encoding header was > added, this also passes most tests: > > diff --git a/commit.c b/commit.c >

Re: [PATCH v2 6/7] wt-status.c: handle worktree renames

On Wed, Dec 27, 2017 at 1:14 AM, Igor Djordjevic wrote: > I`m afraid "--porcelain=v2" test might be incorrect here, as `git > status --porcelain=v2` output seems to be too, with this v2 series > applied. Test I sent previously[1] fails, and it looks valid. > > This is

[PATCH v2 7/7] wt-status.c: avoid double renames in short/porcelain format

The presence of worktree rename leads to an interesting situation, what if the same index entry is renamed twice, compared to HEAD and to worktree? We can have that with this setup echo first > first && git add first && git commit -m first git mv first second # rename reported in "diff

[PATCH v2 6/7] wt-status.c: handle worktree renames

Before 425a28e0a4 (diff-lib: allow ita entries treated as "not yet exist in index" - 2016-10-24) there are never "new files" in the index, which essentially disables rename detection because we only detect renames when a new file appears in a diff pair. After that commit, an i-t-a entry can

[PATCH v2 1/7] t2203: test status output with porcelain v2 format

Signed-off-by: Nguyễn Thái Ngọc Duy --- t/t2203-add-intent.sh | 12 1 file changed, 12 insertions(+) diff --git a/t/t2203-add-intent.sh b/t/t2203-add-intent.sh index 1bdf38e80d..878e73fe98 100755 --- a/t/t2203-add-intent.sh +++ b/t/t2203-add-intent.sh @@ -25,6

[PATCH v2 4/7] wt-status.c: rename wt_status_change_data::score

We are about to adding support for "diff-files" rename, which has its own rename score in addition to the "diff-index" one. Rename score to head_score to indicate this score comes from diff-index. The new score will be named worktree_score. Signed-off-by: Nguyễn Thái Ngọc Duy

[PATCH v2 2/7] Use DIFF_DETECT_RENAME for detect_rename assignments

This field can have two values (2 for copy). Use this name instead for clarity. Many places have already used this constant. Note, the detect_rename assignments in merge-recursive.c remain unchanged because it's actually a boolean there. Signed-off-by: Nguyễn Thái Ngọc Duy

[PATCH v2 0/7] Renames in git-status "changed not staged" section

The changes in 425a28e0a4 allow new files to show up in "git diff-files" (aka "changed but not staged") which is a problem because status code does not handle renaming in this case. The main change to fix this is 6/7. The interesting corner case is in 7/7 where I decided to go with a middle

[PATCH v2 5/7] wt-status.c: catch unhandled diff status codes

Signed-off-by: Nguyễn Thái Ngọc Duy --- wt-status.c | 8 ++-- 1 file changed, 6 insertions(+), 2 deletions(-) diff --git a/wt-status.c b/wt-status.c index 0f089c5789..c124d7589c 100644 --- a/wt-status.c +++ b/wt-status.c @@ -468,8 +468,8 @@ static void

[PATCH v2 3/7] wt-status.c: coding style fix

Signed-off-by: Nguyễn Thái Ngọc Duy --- wt-status.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/wt-status.c b/wt-status.c index 59338adb8b..db06fc7c85 100644 --- a/wt-status.c +++ b/wt-status.c @@ -406,7 +406,8 @@ static void

Re: [PATCH] status: add a failing test showing a core.untrackedCache bug

On Tue, Dec 26, 2017 at 1:45 AM, Ævar Arnfjörð Bjarmason wrote: > > On Mon, Dec 25 2017, Duy Nguyen jotted: > >> On Fri, Dec 22, 2017 at 9:00 PM, Ævar Arnfjörð Bjarmason >> wrote: >>> The untracked cache gets confused when a directory is swapped out for >>> a

Re: Bring together merge and rebase

On Mon, Dec 25, 2017 at 10:02 PM, Carl Baldwin wrote: > On Mon, Dec 25, 2017 at 05:47:55PM -0800, Jacob Keller wrote: >> On Mon, Dec 25, 2017 at 5:16 PM, Carl Baldwin wrote: >> > Anyway, now I am compelled to use github which is also a fine tool and I >> >

Re: Bring together merge and rebase

On Tue, Dec 26 2017, Carl Baldwin jotted: > On Sat, Dec 23, 2017 at 11:09:59PM +0100, Ævar Arnfjörð Bjarmason wrote: >> >> But I don't see why you think this needs a new "replaces" parent >> >> pointer orthagonal to parent pointers, i.e. something that would >> >> need to be a new field in the

Re: [PATCH] status: handle worktree renames

On 2017-12-25 11:37, Nguyễn Thái Ngọc Duy wrote: [] > wt-status.c | 24 +++- > wt-status.h | 1 + > 3 files changed, 35 insertions(+), 5 deletions(-) > > diff --git a/t/t2203-add-intent.sh b/t/t2203-add-intent.sh > index 1bdf38e80d..41a8874e60 100755 >

Re: Bring together merge and rebase

On Tue, Dec 26, 2017 at 01:04:36PM -0500, Theodore Ts'o wrote: > On Mon, Dec 25, 2017 at 06:16:40PM -0700, Carl Baldwin wrote: > > At this point, you might wonder why I'm not proposing to simply add a > > "change-id" to the commit object. The short answer is that the > > "change-id" Gerrit uses in

Re: Bring together merge and rebase

On Tue, 2017-12-26 at 12:44 -0700, Carl Baldwin wrote: > > Sure, it could be opt in, be a new format etc. But you haven't > > explained why you think a feature like this would need to rely on > > an entirely new parent structure and side-DAG, as opposed to just > > the more minor changes I'm

Re: [PATCH v2 7/7] wt-status.c: avoid double renames in short/porcelain format

On Wed, Dec 27, 2017 at 5:14 AM, Igor Djordjevic wrote: > Hi Duy, > > On 26/12/2017 10:10, Nguyễn Thái Ngọc Duy wrote: >> >> The presence of worktree rename leads to an interesting situation, >> what if the same index entry is renamed twice, compared to HEAD and to >>

Re: Bring together merge and rebase

Very interesting topic, just this one part I wanted to comment on: On 26/12/2017 02:28, Jacob Keller wrote: > > What about some way to take the reflog and turn it into a commit-based > linkage and export that? Rather than tying it into the individual > commit history, keep track of it outside

Re: Bring together merge and rebase

On Mon, Dec 25, 2017 at 06:16:40PM -0700, Carl Baldwin wrote: > At this point, you might wonder why I'm not proposing to simply add a > "change-id" to the commit object. The short answer is that the > "change-id" Gerrit uses in the commit messages cannot stand on its own. > It depends on data

Re: Bring together merge and rebase

On Tue, Dec 26, 2017 at 03:19:02PM -0500, Paul Smith wrote: > As someone working in an environment where we do a lot of rebasing and > very little merging, I read these proposals with interest. I'm not > convinced that we would switch to using a "replaces"-type feature, but > I'm pretty sure that

Re: Bring together merge and rebase

On Fri, Dec 22, 2017 at 11:10:19PM -0700, Carl Baldwin wrote: > The big contention among git users is whether to rebase or to merge > changes [2][3] while iterating. I used to firmly believe that merging > was the way to go and rebase was harmful. More recently, I have worked > in some

Re: [PATCH v2 7/7] wt-status.c: avoid double renames in short/porcelain format

Hi Duy, On 26/12/2017 10:10, Nguyễn Thái Ngọc Duy wrote: > > The presence of worktree rename leads to an interesting situation, > what if the same index entry is renamed twice, compared to HEAD and to > worktree? We can have that with this setup > > echo first > first && git add first &&

Re: [PATCH v2 6/7] wt-status.c: handle worktree renames

Hi Duy, On 26/12/2017 10:10, Nguyễn Thái Ngọc Duy wrote: > Before 425a28e0a4 (diff-lib: allow ita entries treated as "not yet exist > in index" - 2016-10-24) there are never "new files" in the index, which > essentially disables rename detection because we only detect renames > when a new file

[PATCH v2 2/7] perf/aggregate: refactor printing results

As we want to implement another kind of output than the current output for the perf test results, let's refactor the existing code that outputs the results in its own print_default_results() function. Signed-off-by: Christian Couder --- t/perf/aggregate.perl | 96

[PATCH v2 5/7] perf/run: learn about perf.codespeedOutput

Let's make it possible to set in a config file the output format (regular or codespeed) of the perf tests. Signed-off-by: Christian Couder --- t/perf/run | 7 ++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/t/perf/run b/t/perf/run index

[PATCH v2 3/7] perf/aggregate: implement codespeed JSON output

Codespeed (https://github.com/tobami/codespeed/) is an open source project that can be used to track how some software performs over time. It stores performance test results in a database and can show nice graphs and charts on a web interface. As it can be interesting to Codespeed to see how Git

[PATCH v2 4/7] perf/run: add conf_opts argument to get_var_from_env_or_config()

Let's make it possible to use `git config` type specifiers like `--int` or `--bool`, so that config values are converted to the canonical form and easier to use. This additional argument is now the fourth argument of get_var_from_env_or_config() instead of the fifth because we want the default

[PATCH v2 6/7] perf/run: learn to send output to codespeed server

Let's make it possible to set in a config file the URL of a codespeed server. And then let's make the `run` script send the perf test results to this URL at the end of the tests. This should make is possible to easily automate the process of running perf tests and having their results available

[PATCH v2 7/7] perf/run: read GIT_TEST_REPO_NAME from perf.repoName

The GIT_PERF_REPO_NAME env variable is used in the `aggregate.perl` script to set the 'environment' field in the JSON Codespeed output. Let's make it easy to set this variable by setting it in a config file. Signed-off-by: Christian Couder --- t/perf/run | 3 +++ 1

[PATCH v2 1/7] perf/aggregate: fix checking ENV{GIT_PERF_SUBSECTION}

Signed-off-by: Christian Couder --- t/perf/aggregate.perl | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/t/perf/aggregate.perl b/t/perf/aggregate.perl index e401208488..769d418708 100755 --- a/t/perf/aggregate.perl +++ b/t/perf/aggregate.perl @@

[PATCH v2 0/7] Codespeed perf results

This patch series is built on top of cc/perf-run-config which recently graduated to master. It makes it possible to send perf results to a Codespeed server. See https://github.com/tobami/codespeed/ and web sites like http://speed.pypy.org/ which are using Codespeed. The end goal would be to have

Re: [PATCH v2 0/7] Codespeed perf results

On Tue, Dec 26, 2017 at 10:59 PM, Christian Couder wrote: > Changes since previous version > ~~ > > - Fixed the way the 'executable' field sent to Codespeed is set in > `perf/aggregate.perl` in patch 3/7. We now use `uname -s -m` to >

Re: Bring together merge and rebase

On Tue, Dec 26, 2017 at 01:08:45PM +0900, Mike Hommey wrote: > FWIW, your proposal has a lot in common (but is not quite equivalent) > to mercurial's obsolescence markers and changeset evolution features. I've had experience with mercurial but not since about 2009. After reading up a little bit

Re: Bring together merge and rebase

On Sun, Dec 24, 2017 at 10:52:15PM -0500, Theodore Ts'o wrote: > Here's another potential use case. The stable kernels (e.g., 3.18.y, > 4.4.y, 4.9.y, etc.) have cherry picks from the the upstream kernel, > and this is handled by putting in the commit body something like this: > > [ Upstream