On Sun, May 06, 2018 at 02:35:44AM -0400, Jeff King wrote:
> You'd have to introduce GIT_COLOR_REVERSE. I don't think we have a
> constant for it yet, but it's \x[7m.
Heh, of course you knew that already, as I just noticed your patch is
using the reverse attribute internally (I had thought at fir
On Sun, May 06, 2018 at 12:03:50AM +0200, Johannes Schindelin wrote:
> > There's a "reverse" attribute (which we already parse and support) that
> > can do this without having to repeat the colors. AFAIK it's well
> > supported everywhere, but I could be wrong.
>
> How would I use that here, thou
Johannes Schindelin writes:
> Johannes Schindelin (17):
> Add a function to solve least-cost assignment problems
> Add a new builtin: branch-diff
Perhaps retitling these to
hungarian: a function to solve least-cost assignment problems
branch-diff: a new builtin to compare iterations
Let's say master..feature has 2 commits: A and B.
Then `git cherry-pick -n master..feature` should pick-up A and then B
into the working directory and the index.
If applying A leads to a conflict, then it stops on A, like here:
>>> git cherry-pick -n master..feature
>> error: could not apply 2c11
On Sat, May 5, 2018 at 6:05 PM, Igor Djordjevic
wrote:
> Hi Dscho,
>
> On 05/05/2018 23:57, 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 comm
Drew DeVault writes:
> When shown the email summary, an opportunity is presented for the user
> to edit the email as if they had specified --annotate. This also permits
> them to edit it multiple times.
>
> Signed-off-by: Drew DeVault
> Reviewed-by: Simon Ser
>
> ---
> Thanks for the review Eri
Jeff King writes:
> The files in your checkout would all be consistent, but they might be
> inconsistent with other files _not_ created by Git (e.g., one might be
> saved in your editor). Now you may have introduced skew that cause
> "make" to do the wrong thing, because your source and target fi
Ilya Kantor writes:
> Somewhy cherry-pick --no-commit does not work well with --continue.
>
> Let's say I'm copying changes w/o committing and get a conflict:
>
>> git cherry-pick -n master..feature
> error: could not apply 2c11f12... Run work
>
> Then I fix the conflict, but cherry-pick refuses
Johannes Schindelin writes:
> Hi Peff,
>
> On Sat, 5 May 2018, Jeff King wrote:
>
>> On Fri, May 04, 2018 at 05:34:32PM +0200, 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
Hi Johannes,
On 04/05/2018 17:34, Johannes Schindelin wrote:
> 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
> beginner.
>
> And just like tbdiff, we now also accept the `--no-patches` option
> (which
Hi Dscho,
On 05/05/2018 23:57, 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
I wrote:
> Would it be possible and reasonable to teach 'git branch' to
> call this as a subcommand, i.e. as 'git branch diff'? Then
> the completion wouldn't offer git branch-diff.
Of course right after I sent this, it occurred to me that
'git branch diff' would make mask the ability to create a
Hi Johannes,
Johannes Schindelin wrote:
> On Sat, 5 May 2018, Jeff King wrote:
>> One minor point about the name: will it become annoying as a tab
>> completion conflict with git-branch?
>
> I did mention this in the commit message of 18/18:
>
> Without this patch, we would only complete the
Hi Johannes,
As many others have already said, thanks for this series!
I've used tbdiff a bit over the years, but having a builtin
will make it much more convenient (and the speed boost from
a C implementation will be a very nice bonus).
Johannes Schindelin wrote:
> @@ -430,6 +451,8 @@ int cmd_br
Hi Peff,
On Sat, 5 May 2018, Jeff King wrote:
> On Fri, May 04, 2018 at 05:34:58PM +0200, Johannes Schindelin wrote:
>
> > 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
Hi Peff,
On Sat, 5 May 2018, Jeff King wrote:
> On Fri, May 04, 2018 at 05:34:32PM +0200, 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 t
Hi Peff,
On Sat, 5 May 2018, Jeff King wrote:
> On Fri, May 04, 2018 at 05:34:29PM +0200, Johannes Schindelin wrote:
>
> > 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
Somewhy cherry-pick --no-commit does not work well with --continue.
Let's say I'm copying changes w/o committing and get a conflict:
> git cherry-pick -n master..feature
error: could not apply 2c11f12... Run work
Then I fix the conflict, but cherry-pick refuses to go on:
> git add .
> git cherr
Hi Elijah,
On Fri, 4 May 2018, Elijah Newren wrote:
> On Thu, May 3, 2018 at 11:40 PM, Johannes Schindelin
> wrote:
> > I actually have a hacky script to fixup commits in a patch series. It lets
> > me stage part of the current changes, then figures out which of the
> > commits' changes overlap
Hi Elijah,
On Fri, 4 May 2018, Elijah Newren wrote:
> On Fri, May 4, 2018 at 8:34 AM, 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 usef
Hi Ramsay,
On Fri, 4 May 2018, Ramsay Jones wrote:
> On 04/05/18 07:40, Johannes Schindelin wrote:
> [snip]
> > BTW I ran `make sparse` for the first time, and it spits out tons of
> > stuff. And I notice that they are all non-fatal warnings, but so were the
> > ones you pointed out above. This
Hi Duy,
On Wed, 2 May 2018, Duy Nguyen wrote:
> On Wed, May 2, 2018 at 11:38 AM, Johannes Schindelin
> wrote:
> > When we call BUG(), we signal via SIGABRT that something bad happened,
> > dumping cores if so configured. In some setups these coredumps are
> > redirected to some central place suc
Hi Stefan,
On Fri, 4 May 2018, Stefan Beller wrote:
> > Branch-diff vs v1:
> > 1: 42db734a980 ! 1: 73398da7119 sequencer: learn about the special "fake
> > root commit" handling
> > @@ -54,40 +54,50 @@
> > return NULL;
> >}
> >
> > ++/* Read author-script and return an
Thanks Martin for the quick fix.
On Fri, May 04, 2018 at 08:26:46PM +0200, Martin �gren wrote:
> Anyway, that's not where I'm stuck... Regardless of how I try to write
> tests (in t1400), they just pass beautifully even before this patch. I
> might be able to look into that more on the weekend. If
On Fri, Apr 13, 2018 at 07:01:29PM +0200, Michał Górny wrote:
> In order to avoid unnecessary cache mismatches, force a matching mtime
> between all files created by a single checkout action. This seems to be
> the best course of action. Matching mtimes do not trigger cache
> updates. They also
On Fri, May 04, 2018 at 05:34:58PM +0200, Johannes Schindelin wrote:
> 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.
There's a "rev
On Fri, May 04, 2018 at 05:34:32PM +0200, 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 `tbd
On Fri, May 04, 2018 at 05:34:29PM +0200, Johannes Schindelin wrote:
> 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
> differe
On Sat, May 05, 2018 at 10:47:16AM +0200, Nguyễn Thái Ngọc Duy wrote:
> These options are added in [1] [2] [3]. All these depend on running
> rev-list internally which is normally true since they are always used
> with "--all --objects" which implies --revs. But let's keep this
> dependency explic
On Sat, May 5, 2018 at 5:41 PM, wrote:
> Christian wrote:
>>
>> It looks like git-reintegrate is not managed in Git but in this
>> repository :
>>
>> https://github.com/felipec/git-reintegrate
>>
>> So could be a bit confusing to send those patches to the Git mailing
>> list without telling that
Christian wrote:
> Hi Yann,
>
> On Sat, May 5, 2018 at 3:24 PM, Yann Dirson wrote:
> > ---
> > git-reintegrate | 6 +++---
> > 1 file changed, 3 insertions(+), 3 deletions(-)
> >
> > diff --git a/git-reintegrate b/git-reintegrate
>
> It looks like git-reintegrate is not managed in Git but in th
Hi Pratik and Alban,
On Sat, May 5, 2018 at 2:24 PM, Pratik Karki wrote:
> On Sat, May 5, 2018 at 5:11 PM, Alban Gruin wrote:
>>
>> as my fellow students, I started a blog series about my GSoC project[1].
>> First, I wanted to post them directly on the mailing list, but a blog
>> allows me to ed
Hi Yann,
On Sat, May 5, 2018 at 3:24 PM, Yann Dirson wrote:
> ---
> git-reintegrate | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/git-reintegrate b/git-reintegrate
It looks like git-reintegrate is not managed in Git but in this repository :
https://github.com/f
Ævar Arnfjörð Bjarmason writes:
> On Fri, May 04 2018, Jakub Narebski wrote:
>
> (Just off-the cuff here and I'm surely about to be corrected by
> Derrick...)
>
>> * What to do about merge commits, and octopus merges in particular?
>> Should Bloom filter be stored for each of the parents? How t
---
git-reintegrate | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/git-reintegrate b/git-reintegrate
index da45239..a6e3cff 100755
--- a/git-reintegrate
+++ b/git-reintegrate
@@ -581,7 +581,7 @@ def status_merge(branch_to_merge = nil)
elsif system(*%w[git merge-base --is-an
---
git-reintegrate | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/git-reintegrate b/git-reintegrate
index a1c17d2..da45239 100755
--- a/git-reintegrate
+++ b/git-reintegrate
@@ -338,7 +338,7 @@ class Integration
def finalize_command(cmd, args, message)
begin
On Sat, May 5, 2018 at 5:11 PM, Alban Gruin wrote:
> Hi everybody,
>
> as my fellow students, I started a blog series about my GSoC project[1].
> First, I wanted to post them directly on the mailing list, but a blog
> allows me to edit the content easily if needed.
>
> Any feedback is welcome!
>
>
Hi everybody,
as my fellow students, I started a blog series about my GSoC project[1].
First, I wanted to post them directly on the mailing list, but a blog
allows me to edit the content easily if needed.
Any feedback is welcome!
[1] https://blog.pa1ch.fr/posts/2018/05/05/en/gsoc2018-week-1.html
These options are added in [1] [2] [3]. All these depend on running
rev-list internally which is normally true since they are always used
with "--all --objects" which implies --revs. But let's keep this
dependency explicit.
While at there, add documentation for them. These are mostly used
internal
On Sat, May 5, 2018 at 12:03 AM, Taylor Blau wrote:
> Teach GNU grep(1)'s '-o' ('--only-matching') to 'git-grep'. This option
> prints only the matching components of each line. It writes multiple
> lines if more than one match exists on a given line.
>
> For example:
>
> $ git grep -on --column
On Sat, May 5, 2018 at 12:03 AM, Taylor Blau wrote:
> Teach 'git-grep(1)' how to print a line header multiple times from
> show_line() in preparation for it learning '--only-matching'.
>
> show_line_header() comprises of the code in show_line() executed in
s/of//
> order to produce a line header
41 matches
Mail list logo
