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 c
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 on
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 output I now get, with old/de
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
>> worktree? We can have that wi
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 the
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 && git
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
> which we concatenate the
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
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 in
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 file changed, 3 insertions(+)
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
@@ -70,7 +70,7 @@ if (not @tests)
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 p
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 val
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 +++-
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 214d658172..4e62d6bb3f 100755
--- a/t/
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 environments
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
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 pointi
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
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
>
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 app
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 store
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
> ---
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 co
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 symlink to another directory. Whateve
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 --
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 appear
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 ground
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 wt_status_collect_changed_cb(struct
di
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 wt_longstatus_print_change_data(struct
wt_st
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 +25,18 @@ test_expect_
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
---
wt-status.c | 4
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
---
builtin/commit.c
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
>> > appreciate all of the work that has gone
34 matches
Mail list logo
