Greeting to you and how is your family? sorry for my way of approach to
you, it is because i do not have choice. I am Aniccet Ibrahim From
Ivory Coast. My story is connected to the fight with the Republican
Forces. I have a business proposals for you. If your interested i want
you to reply me
On Thu, May 03 2018, Junio C Hamano wrote:
> Ævar Arnfjörð Bjarmason writes:
>
>> But ^{tree} shows just the trees, but would previously be equivalent
>> to the above:
>>
>> $ git rev-parse e8f2^{tree}
>> error: short SHA1 e8f2 is ambiguous
>> hint: The candidates are:
>> hint:
Thanks I will amend and re-submit (this time with -v$N, I apologize
for creating a confusing mess in everyone's email clients :))
On Wed, May 2, 2018 at 1:59 AM, Junio C Hamano wrote:
> Casey Fitzpatrick writes:
>
>> 'recommend_shallow' and 'jobs' variables do not need quotes (they never
>> co
The '--progress' was introduced in 72c5f88311d (clone: pass --progress
decision to recursive submodules, 2016-09-22) to fix the progress reporting
of the clone command. Also add the progress option to the 'submodule add'
command. The update command already supports the progress flag, but it
is not
These patches add --progress and --dissociate options to git submodule.
The --progress option existed beforehand, but only for the update command and
it was left undocumented.
Both add and update submodule commands supported --reference, but not its pair
option --dissociate which allows for indep
'recommend_shallow' and 'jobs' variables do not need quotes. They only hold a
single token value, and even if they were multi-token it is likely we would want
them split at IFS rather than pass a single string.
'progress' is a boolean value. Treat it like the other boolean values in the
script by
Add --dissociate option to add and update commands, both clone helper commands
that already have the --reference option --dissociate pairs with.
Signed-off-by: Casey Fitzpatrick
---
Documentation/git-submodule.txt | 10 +-
builtin/submodule--helper.c | 16 +---
git-submod
Derrick Stolee writes:
> Most of the changes from v4 are cosmetic, but there is one new commit:
>
> commit: use generation number in remove_redundant()
>
> Other changes are non-functional, but do clarify things.
I wonder if out perf framework in t/perf could help here to show
performance
I am Mavis Wanczyk i know you may not know me but am the latest
largest US Powerball lottery winner of $758.7m just of recent, am
currently helping out people in need of financial assistance, i know
it's hard to believe anything on the internet, so if you don't need
my help please don
Junio C Hamano writes:
> Shin Kojima writes:
>
>> Offset positions should not be counted by byte length, but by actual
>> character length.
>> ...
>> # escape tabs (convert tabs to spaces)
>> sub untabify {
>> -my $line = shift;
>> +my $line = to_utf8(shift);
>>
>> while ((my $po
Introduce a checkout.implicitRemote setting which can be used to
designate a remote to prefer (via checkout.implicitRemote=origin) when
running e.g. "git checkout master" to mean origin/master, even though
there's other remotes that have the "master" branch.
I want this because it's very handy to
On 03/05/18 01:53, Stefan Beller wrote:
> From: Prathamesh Chavan
>
> When running 'git submodule foreach --recursive' from a subdirectory of
> your repository, nested submodules get a bogus value for $path:
> For a submodule 'sub' that contains a nested submodule 'nested',
> running 'git -C di
On Tue, May 1, 2018 at 11:34 PM, Stefan Beller wrote:
> @@ -501,9 +516,12 @@ void raw_object_store_clear(struct raw_object_store *o)
> void object_parser_clear(struct object_parser *o)
> {
> /*
> -* TOOD free objects in o->obj_hash.
> -*
You need to free(o->obj_hash) too
On Thu, May 3, 2018 at 3:18 PM, Ævar Arnfjörð Bjarmason
wrote:
> Introduce a checkout.implicitRemote setting which can be used to
> designate a remote to prefer (via checkout.implicitRemote=origin) when
> running e.g. "git checkout master" to mean origin/master, even though
> there's other remotes
> One solution would be to force conversion to UTF-8 on input via "open"
> pragma (e.g. "use open ':encoding(UTF-8)';"). But there is no
> UTF-8-with_fallback encoding available - we would have to write one, and
> install it as module (or fake it via Perl trickery). This mechanism is
> almost the
The incredibly useful `git-tbdiff` tool to compare patch series (say, to see
what changed between two iterations sent to the Git mailing list) is slightly
less useful for this developer due to the fact that it requires the `hungarian`
and `numpy` Python packages which are for some reason really har
This builtin does not do a whole lot so far, apart from showing a usage
that is oddly similar to that of `git tbdiff`. And for a good reason:
the next commits will turn `branch-diff` into a full-blown replacement
for `tbdiff`.
At this point, we ignore tbdiff's color options, as they will all be
im
The Jonker-Volgenant algorithm was implemented to answer questions such
as: given two different versions of a topic branch (or iterations of a
patch series), what is the best pairing of commits/patches between the
different versions?
Signed-off-by: Johannes Schindelin
---
Makefile| 1 +
hu
This patch lets branch-diff use the same order as tbdiff.
The idea is simple: for left-to-right readers, it is natural to assume
that the branch-diff is performed between an older vs a newer version of
the branch. As such, the user is probably more interested in the
question "where did this come f
When comparing commit messages, we need to keep in mind that they are
indented by four spaces. That is, empty lines are no longer empty, but
have "trailing whitespace". When displaying them in color, that results
in those nagging red lines.
Let's just right-trim the lines in the commit message, it
At this stage, `git branch-diff` can determine corresponding commits of
two related commit ranges. This makes use of the recently introduced
implementation of the Hungarian algorithm.
The core of this patch is a straight port of the ideas of tbdiff, the
seemingly dormant project at https://github.
Just like tbdiff, we now show the diff between matching patches. This is
a "diff of two diffs", so it can be a bit daunting to read for the
beginnger.
This brings branch-diff closer to be feature-complete with regard to
tbdiff.
An alternative would be to display an interdiff, i.e. the hypothetica
Arguably the most important part of branch-diff's output is the list of
commits in the two branches, together with their relationships.
For that reason, tbdiff introduced color-coding that is pretty
intuitive, especially for unchanged patches (all dim yellow, like the
first line in `git show`'s ou
When showing the diff between corresponding patches of the two branch
versions, we have to make up a fake filename to run the diff machinery.
That filename does not carry any meaningful information, hence tbdiff
suppresses it. So we should, too.
Signed-off-by: Johannes Schindelin
---
builtin/br
This change brings branch-diff yet another step closer to feature parity
with tbdiff: it now shows the oneline, too, and indicates with `=` when
the commits have identical diffs.
Signed-off-by: Johannes Schindelin
---
builtin/branch-diff.c | 67 +--
1 file
From: Thomas Rast
These are essentially lifted from https://github.com/trast/tbdiff, with
light touch-ups to account for the new command name.
Apart from renaming `tbdiff` to `branch-diff`, only one test case needed
to be adjusted: 11 - 'changed message'.
The underlying reason it had to be adju
The main information in the branch-diff view comes from the list of
matching and non-matching commits, the diffs are additional information.
Indenting them helps with the reading flow.
Signed-off-by: Johannes Schindelin
---
builtin/branch-diff.c | 9 +
1 file changed, 9 insertions(+)
di
We are comparing complete, formatted commit messages with patches. There
are no function names here, so stop looking for them.
Signed-off-by: Johannes Schindelin
---
builtin/branch-diff.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/builtin/branch-diff.c b/builtin/branch-diff.c
inde
When showing what changed between old and new commits, we show a diff of
the patches. This diff is a diff between diffs, therefore there are
nested +/- signs, and it can be relatively hard to understand what is
going on.
With the --dual-color option, the preimage and the postimage are colored
like
For every regular color, there exists the inverted equivalent where
background and foreground colors are exchanged.
We will use this in the next commit to allow inverting *just* the +/-
signs in a diff.
Signed-off-by: Johannes Schindelin
---
color.h | 6 ++
1 file changed, 6 insertions(+)
This is a heavily butchered version of the README written by Thomas
Rast and Thomas Gummerer, lifted from https://github.com/trast/tbdiff.
Signed-off-by: Johannes Schindelin
---
Documentation/git-branch-diff.txt | 239 ++
1 file changed, 239 insertions(+)
create mode
When diffing diffs, it can be quite daunting to figure out what the heck
is going on, as there are nested +/- signs.
Let's make this easier by adding a flag in diff_options that allows
color-coding the outer diff sign with inverted colors, so that the
preimage and postimage is colored like the dif
When displaying a diff of diffs, it is possible that there is an outer
`+` before a context line. That happens when the context changed between
old and new commit. When that context line starts with a tab (after the
space that marks it as context line), our diff machinery spits out a
white-space er
Tab completion of `branch-diff` is very convenient, especially given
that the revision arguments that need to be passed to `git branch-diff`
are typically more complex than, say, your grandfather's `git log`
arguments.
Without this patch, we would only complete the `branch-diff` part but
not the o
On Tue, Apr 17, 2018 at 12:33 PM, Taylor Blau wrote:
>
> On Tue, Apr 17, 2018 at 12:08:20PM -0600, Ben Toews wrote:
> > On Mon, Apr 16, 2018 at 7:54 PM, Junio C Hamano wrote:
> > > "brian m. carlson" writes:
> > >
> > >> If we just want to add gpgsm support, that's fine, but we should be
> > >>
On 03/05/18 16:30, Johannes Schindelin wrote:
> This builtin does not do a whole lot so far, apart from showing a usage
> that is oddly similar to that of `git tbdiff`. And for a good reason:
> the next commits will turn `branch-diff` into a full-blown replacement
> for `tbdiff`.
>
> At this poi
Another I noticed in the jm/mem-pool series is this loop in mem_pool_alloc()
for (p = mem_pool->mp_block; p; p = p->next_block)
if (p->end - p->next_free >= len)
break;
You always go from the start (mp_block) but at some point those first
blocks are filled up and we don't
On Mon, Apr 30, 2018 at 5:31 PM, Jameson Miller wrote:
> Add an option (controlled by an environment variable) perform extra
> validations on mem_pool allocated cache entries. When set:
>
> 1) Invalidate cache_entry memory when discarding cache_entry.
>
> 2) When discarding index_state struct,
On 03/05/18 16:30, Johannes Schindelin wrote:
> At this stage, `git branch-diff` can determine corresponding commits of
> two related commit ranges. This makes use of the recently introduced
> implementation of the Hungarian algorithm.
>
> The core of this patch is a straight port of the ideas o
On Mon, Apr 30, 2018 at 5:31 PM, Jameson Miller wrote:
> This patch series improves the performance of loading indexes by
> reducing the number of malloc() calls. Loading the index from disk is
> partly dominated by the time in malloc(), which is called for each
> index entry. This patch series re
On Thu, May 3, 2018 at 5:30 PM, Johannes Schindelin
wrote:
> diff --git a/command-list.txt b/command-list.txt
> index a1fad28fd82..c89ac8f417f 100644
> --- a/command-list.txt
> +++ b/command-list.txt
> @@ -19,6 +19,7 @@ git-archive mainporcelain
> git-bisect
Hi Johannes,
On Thu, May 3, 2018 at 8:30 AM, Johannes Schindelin
wrote:
> This builtin does not do a whole lot so far, apart from showing a usage
> that is oddly similar to that of `git tbdiff`. And for a good reason:
> the next commits will turn `branch-diff` into a full-blown replacement
> for
Hi,
On Wed, May 02, 2018 at 07:30:25AM +, Middelschulte, Leif wrote:
> Am Montag, den 30.04.2018, 19:02 +0200 schrieb Heiko Voigt:
> > On Thu, Apr 26, 2018 at 03:19:36PM -0700, Stefan Beller wrote:
> > > Stefan wrote:
> > > > See
> > > > https://github.com/git/git/commit/68d03e4a6e448aa557f52
On Thu, May 03 2018, Johannes Schindelin wrote:
> *before* the existing emtpy line. And apparently xdiff picks a different
s/emtpy/empty/
On Thu, May 3, 2018 at 8:30 AM, Johannes Schindelin
wrote:
> Note: due to differences in the diff algorithm (`tbdiff` uses the
> Pythong module `difflib`, Git uses its xdiff fork), the cost matrix
> calculated by `branch-diff` is different (but very similar) to the one
> calculated by `tbdiff`. T
On Thu, May 3, 2018 at 8:30 AM, Johannes Schindelin
wrote:
> From: Thomas Rast
>
> These are essentially lifted from https://github.com/trast/tbdiff, with
> light touch-ups to account for the new command name.
>
> Apart from renaming `tbdiff` to `branch-diff`, only one test case needed
> to be ad
It is possible to configure 'less', the pager, to use an alternate
screen to show the content, for example, by setting LESS=RS in the
environment. When it is closed in this configuration, it switches
back to the original screen, and all content is gone.
It is not uncommon to request that the outpu
On Thu, May 3, 2018 at 9:35 AM, Duy Nguyen wrote:
> On Mon, Apr 30, 2018 at 5:31 PM, Jameson Miller wrote:
>> This patch series improves the performance of loading indexes by
>> reducing the number of malloc() calls. Loading the index from disk is
>> partly dominated by the time in malloc(), whic
On Wed, May 2, 2018 at 10:44 AM, Duy Nguyen wrote:
> On Tue, May 1, 2018 at 11:34 PM, Stefan Beller wrote:
>> #include "cache.h"
>> #include "object.h"
>> @@ -30,8 +31,25 @@ struct alloc_state {
>> int count; /* total number of nodes allocated */
>> int nr;/* number of nodes
On Wed, May 2, 2018 at 1:50 PM, Jonathan Tan wrote:
> On Tue, 1 May 2018 14:34:03 -0700
> Stefan Beller wrote:
>
>> +void *allocate_alloc_state(void)
>> +{
>> + return xcalloc(1, sizeof(struct alloc_state));
>> +}
>> +
>> +void clear_alloc_state(struct alloc_state *s)
>> +{
>> + while (s
On Thu, May 3, 2018 at 7:24 PM, Stefan Beller wrote:
>>> +void clear_alloc_state(struct alloc_state *s)
>>> +{
>>> + while (s->slab_nr > 0) {
>>> + s->slab_nr--;
>>> + free(s->slabs[s->slab_nr]);
>>
>> I think you're leaking memory here. Commit and tree objects ma
On Wed, 2 May 2018 17:53:54 -0700
Stefan Beller wrote:
> From: Prathamesh Chavan
>
> When running 'git submodule foreach --recursive' from a subdirectory of
> your repository, nested submodules get a bogus value for $path:
I know I said in a previous e-mail [1] that we should use $path instea
On Wed, 2 May 2018 17:53:55 -0700
Stefan Beller wrote:
> foreach [--recursive] ::
> Evaluates an arbitrary shell command in each checked out submodule.
> - The command has access to the variables $name, $path, $sha1 and
> + The command has access to the variables $name, $sm_path,
On Wed, 2 May 2018 17:53:56 -0700
Stefan Beller wrote:
> $name is the name of the relevant submodule section in `.gitmodules`,
> $sm_path is the path of the submodule as recorded in the superproject,
> $sha1 is the commit as recorded in the superproject, and
> - $toplevel i
On Wed, 2 May 2018 17:53:58 -0700
Stefan Beller wrote:
> + argv_array_pushf(&cp.args, "path=%s; %s",
> + path, info->argv[0]);
Do we need to quote the path here? (For example, what if path has a
quotation mark?)
Also, would it be useful to have a test te
On Thu, May 03 2018, Johannes Schindelin wrote:
> The incredibly useful `git-tbdiff` tool to compare patch series (say, to see
> what changed between two iterations sent to the Git mailing list) is slightly
> less useful for this developer due to the fact that it requires the
> `hungarian`
> and
On Thu, May 3, 2018 at 10:47 AM, Jonathan Tan wrote:
> On Wed, 2 May 2018 17:53:54 -0700
> Stefan Beller wrote:
>
>> From: Prathamesh Chavan
>>
>> When running 'git submodule foreach --recursive' from a subdirectory of
>> your repository, nested submodules get a bogus value for $path:
>
> I kno
Derrick Stolee writes:
> The static remove_redundant() method is used to filter a list
> of commits by removing those that are reachable from another
> commit in the list. This is used to remove all possible merge-
> bases except a maximal, mutually independent set.
>
> To determine these commits
Changes since the last reroll:
- Better commit comment for "doc: align 'diff --no-index' in text and synopsis"
This includes Martin's `s/with/and/` comment.
- Eric's typo fix in "doc: add note about shell quoting to revision.txt"
- Added new patch for git-diff.txt with s/--options/options/.
Th
Typeset commands and similar things with as `git foo` instead of
'git foo' or 'git-foo' and add linkgit to the commands which run
the hooks.
Signed-off-by: Andreas Heiduk
Reviewed-by: Martin Ågren
---
Documentation/githooks.txt | 115 +++--
1 file changed
SYNOPSIS and other manuals use [options] but DESCRIPTION
used [--options].
Signed-off-by: Andreas Heiduk
---
Documentation/git-diff.txt | 14 +++---
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/Documentation/git-diff.txt b/Documentation/git-diff.txt
index 6593b58299..7c2
Make the two '' parameters in DESCRIPTION mandatory and
move the `--options` part to the same place where the other
variants show them. And finally make `--no-index` in SYNOPSIS
as mandatory as in DESCRIPTION.
Signed-off-by: Andreas Heiduk
Reviewed-by: Martin Ågren
---
Documentation/git-diff.tx
The subcommand 'commit-diff' does not support the option
'--add-author-from'.
Signed-off-by: Andreas Heiduk
Signed-off-by: Eric Wong
---
Documentation/git-svn.txt | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Documentation/git-svn.txt b/Documentation/git-svn.txt
index d593
Explain that `git ls-files --ignored` requires at least one
of the `--exclude*` options to do its job.
Signed-off-by: Andreas Heiduk
---
Documentation/git-ls-files.txt | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/Documentation/git-ls-files.txt b/Documentation/git-ls-file
Signed-off-by: Andreas Heiduk
Reviewed-by: Junio C Hamano
---
Documentation/revisions.txt | 6 ++
1 file changed, 6 insertions(+)
diff --git a/Documentation/revisions.txt b/Documentation/revisions.txt
index dfcc49c72c..e760416d07 100644
--- a/Documentation/revisions.txt
+++ b/Documentation/
Add the missing `-o` shortcut for `--push-option` to the synopsis.
Add the missing `-d` shortcut for `--delete` in the main section.
Signed-off-by: Andreas Heiduk
Reviewed-by: Martin Ågren
---
Documentation/git-push.txt | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/Docum
On Tue, May 1, 2018 at 5:31 PM, Jonathan Tan wrote:
> Fix a typo in an error message.
>
> Also, this line was introduced in 3145ea957d2c ("upload-pack: introduce
> fetch server command", 2018-03-15), which did not contain a test for the
> case which causes this error to be printed, so introduce a
On Tue, May 1, 2018 at 5:31 PM, Jonathan Tan wrote:
> The upload-pack code paths never call git_config() with
> upload_pack_config() when protocol v2 is used, causing options like
> uploadpack.packobjectshook to not take effect. Ensure that this function
> is called.
>
> Signed-off-by: Jonathan Ta
On Thu, May 3, 2018 at 7:21 PM, Stefan Beller wrote:
> On Thu, May 3, 2018 at 9:35 AM, Duy Nguyen wrote:
>> On Mon, Apr 30, 2018 at 5:31 PM, Jameson Miller wrote:
>>> This patch series improves the performance of loading indexes by
>>> reducing the number of malloc() calls. Loading the index fro
On Thu, May 3, 2018 at 1:15 PM, Johannes Sixt wrote:
> It is possible to configure 'less', the pager, to use an alternate
> screen to show the content, for example, by setting LESS=RS in the
> environment. When it is closed in this configuration, it switches
> back to the original screen, and all
Hi Jonathan,
On Tue, May 1, 2018 at 5:31 PM, Jonathan Tan wrote:
> The fetch-pack/upload-pack protocol v2 was developed independently of
> the filter parameter (used in partial fetches), thus it did not include
> support for it. Add support for the filter parameter.
>
> Like in the legacy protoco
Hi Ramsay,
On Thu, 3 May 2018, Ramsay Jones wrote:
> On 03/05/18 16:30, Johannes Schindelin wrote:
> > This builtin does not do a whole lot so far, apart from showing a usage
> > that is oddly similar to that of `git tbdiff`. And for a good reason:
> > the next commits will turn `branch-diff` int
Hi Duy,
On Thu, 3 May 2018, Duy Nguyen wrote:
> On Thu, May 3, 2018 at 5:30 PM, Johannes Schindelin
> wrote:
> > diff --git a/command-list.txt b/command-list.txt
> > index a1fad28fd82..c89ac8f417f 100644
> > --- a/command-list.txt
> > +++ b/command-list.txt
> > @@ -19,6 +19,7 @@ git-archive
Hi Duy,
On Thu, 3 May 2018, Johannes Schindelin wrote:
> On Thu, 3 May 2018, Duy Nguyen wrote:
>
> > On Thu, May 3, 2018 at 5:30 PM, Johannes Schindelin
> > wrote:
> > > diff --git a/command-list.txt b/command-list.txt
> > > index a1fad28fd82..c89ac8f417f 100644
> > > --- a/command-list.txt
> >
Hi Stefan,
On Thu, 3 May 2018, Stefan Beller wrote:
> On Thu, May 3, 2018 at 8:30 AM, Johannes Schindelin
> wrote:
> > This builtin does not do a whole lot so far, apart from showing a
> > usage that is oddly similar to that of `git tbdiff`. And for a good
> > reason: the next commits will turn
Hi Ramsay,
On Thu, 3 May 2018, Ramsay Jones wrote:
> On 03/05/18 16:30, Johannes Schindelin wrote:
> > At this stage, `git branch-diff` can determine corresponding commits of
> > two related commit ranges. This makes use of the recently introduced
> > implementation of the Hungarian algorithm.
>
On Thu, May 3, 2018 at 12:17 PM, Duy Nguyen wrote:
>
>> To me it is also a clear yes when it comes to combining these
>> two memory pools.
>
> I also did not notice that jm/mem-pool already landed in master.
Oh, thanks for telling! Now that I look at it, I am doubting it;
The reason for my doubt
Hi Stefan,
On Thu, 3 May 2018, Stefan Beller wrote:
> On Thu, May 3, 2018 at 8:30 AM, Johannes Schindelin
> wrote:
>
> > Note: due to differences in the diff algorithm (`tbdiff` uses the
> > Pythong module `difflib`, Git uses its xdiff fork), the cost matrix
> > calculated by `branch-diff` is d
Hi Ævar,
On Thu, 3 May 2018, Ævar Arnfjörð Bjarmason wrote:
> On Thu, May 03 2018, Johannes Schindelin wrote:
>
> > *before* the existing emtpy line. And apparently xdiff picks a different
>
> s/emtpy/empty/
Thanks for the spell check!
Dscho
Hi Stefan,
On Thu, 3 May 2018, Stefan Beller wrote:
> On Thu, May 3, 2018 at 8:30 AM, Johannes Schindelin
> wrote:
> > From: Thomas Rast
> >
> > These are essentially lifted from https://github.com/trast/tbdiff, with
> > light touch-ups to account for the new command name.
> >
> > Apart from re
Hi Ævar,
On Thu, 3 May 2018, Ævar Arnfjörð Bjarmason wrote:
> On Thu, May 03 2018, Johannes Schindelin wrote:
>
> > The incredibly useful `git-tbdiff` tool to compare patch series (say,
> > to see what changed between two iterations sent to the Git mailing
> > list) is slightly less useful for t
> -Original Message-
> From: git-ow...@vger.kernel.org On Behalf Of
> Stefan Beller
> Sent: Thursday, May 3, 2018 4:59 PM
> To: Duy Nguyen
> Cc: Jameson Miller ; git@vger.kernel.org;
> gits...@pobox.com; jonathanta...@google.com
> Subject: Re: [PATCH v2 0/5] Allocate cache entries from
On Thu, May 3, 2018 at 1:42 PM, Johannes Schindelin
wrote:
>> Speaking of colors, for origin/sb/blame-color Junio hinted at re-using
>> cyan for "uninteresting" parts to deliver a consistent color scheme for
>> Git. Eventually he dreams of having 2 layers of indirection IIUC, with
>> "uninter
> To be honest, the main reason I spawn here is that I did not want to be
> bothered with resetting the commit flags after traversing the first commit
> range. But I guess I was just too cheap and should really do it?
Oh right, you'd have to do multiple revision walks.
> OTOH spawning here is a l
Hello everybody,
The community bonding period started. It is well known that for a
greater rate of success, it is recommended to send weekly reports
regarding project status. But, what would be a good form for such a
report? I, for one, think that starting a blog is one of the best
options be
Hi Stefan,
On Thu, 3 May 2018, Stefan Beller wrote:
> On Thu, May 3, 2018 at 1:42 PM, Johannes Schindelin
> wrote:
>
> >> Speaking of colors, for origin/sb/blame-color Junio hinted at re-using
> >> cyan for "uninteresting" parts to deliver a consistent color scheme for
> >> Git. Eventually he d
On Thu, May 3, 2018 at 11:05 AM, Ævar Arnfjörð Bjarmason
wrote:
>
> On Thu, May 03 2018, Johannes Schindelin wrote:
>
>> The incredibly useful `git-tbdiff` tool to compare patch series (say, to see
>> what changed between two iterations sent to the Git mailing list) is slightly
>> less useful for
Hi Stefan,
On Thu, 3 May 2018, Stefan Beller wrote:
> >> In addition to that patch, we'd have to buffer commit messages and
> >> buffer multiple commits, as that only buffers a diff of a single
> >> commit.
> >
> > ... and make sure that the moved-code logic (which is currently the
> > only user
Hi Paul,
On Fri, 4 May 2018, Paul-Sebastian Ungureanu wrote:
> The community bonding period started. It is well known that for a
> greater rate of success, it is recommended to send weekly reports
> regarding project status. But, what would be a good form for such a
> report? I, for one, think t
Signed-off-by: Stefan Beller
---
>> The reason for my doubt is the potential quadratic behavior for new
>> allocations,
>> in mem_pool_alloc() we walk all mp_blocks to see if we can fit the requested
>> allocation in one of the later blocks.
>> So if we call mem_pool_alloc a million times, we ge
On Wed, May 2, 2018 at 11:22 AM, Duy Nguyen wrote:
> I think the two have quite different characteristics. alloc.c code is
> driven by overhead. struct blob is only 24 bytes each and about 1/3
> the repo is blobs, and each malloc has 16 bytes overhead or so if I
> remember correctly. struct cache
In this developer's earlier attempt to accelerate interactive rebases by
converting large parts from Unix shell script into portable, performant
C, the --root handling was specifically excluded (to simplify the task a
little bit; it still took over a year to get that reduced set of patches
into Git
When an interactive rebase wants to recreate a root commit, it
- first creates a new, empty root commit,
- checks it out,
- converts the next `pick` command so that it amends the empty root
commit
Introduce support in the sequencer to handle such an empty root commit,
by looking for the file /re
When I reimplemented the most performance-critical bits of the
interactive rebase in the sequencer, to speed up `git rebase -i`
particularly on Windows (even if the benefits are still quite notable on
Linux or macOS), I punted on the --root part.
I had always hoped that some other contributor (or
In the context of the new --rebase-merges mode, which was designed
specifically to allow for changing the existing branch topology
liberally, a user may want to extract commits into a completely fresh
branch that starts with a newly-created root commit.
This is now possible by inserting the comman
When a user provides a todo list containing something like
reset [new root]
merge my-branch
let's do the same as if pulling into an orphan branch: simply
fast-forward.
Signed-off-by: Johannes Schindelin
---
sequencer.c | 12
t/t3430-rebase-merges.sh |
This patch extracts the code from is_index_unchanged() to initialize or
update the index' cache tree (i.e. a tree object reflecting the current
index' top-level tree).
The new helper will be used in the upcoming code to support `git rebase
-i --root` via the sequencer.
Signed-off-by: Johannes Sch
Reported by Wink Saville: when rebasing with no-rebase-cousins, we
will want to refrain from rebasing all of them, even when they are
root commits.
Signed-off-by: Johannes Schindelin
---
sequencer.c | 3 ++-
t/t3430-rebase-merges.sh | 25 +
2 files changed,
On 03/05/18 21:25, Johannes Schindelin wrote:
> On Thu, 3 May 2018, Ramsay Jones wrote:
>> On 03/05/18 16:30, Johannes Schindelin wrote:
[snip]
>>> diff --git a/builtin/branch-diff.c b/builtin/branch-diff.c
>>> new file mode 100644
>>> index 000..97266cd326d
>>> --- /dev/null
>>> +++ b
From: "Johannes Schindelin"
From: Thomas Rast
These are essentially lifted from https://github.com/trast/tbdiff, with
light touch-ups to account for the new command name.
Apart from renaming `tbdiff` to `branch-diff`, only one test case needed
to be adjusted: 11 - 'changed message'.
The unde
1 - 100 of 127 matches
Mail list logo
