From: Johannes Schindelin
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
From: Johannes Schindelin
This patch lets `git range-diff` use the same order as tbdiff.
The idea is simple: for left-to-right readers, it is natural to assume
that the `git range-diff` is performed between an older vs a newer
version of the branch. As such, the user is probably more interested
Hi,
On Fri, 20 Jul 2018, Stefan Beller wrote:
> +cc list
> On Fri, Jul 20, 2018 at 2:29 PM Junio C Hamano wrote:
> > ... which means that it does not matter if I have an elaborate rewrite hook
> > that constantly updates the reverse mapping or if the reverse mapping is
> > made immediately
Hi Junio,
On Fri, 20 Jul 2018, Junio C Hamano wrote:
> Johannes Schindelin writes:
>
> > AFAICT there is at least one scenario where you run `rebase -i`, the notes
> > get updated, and of course the *reverse mapping* does *not* get updated:
>
> It turns out that I
Hi Stefan,
On Tue, 10 Jul 2018, Stefan Beller wrote:
> On Tue, Jul 10, 2018 at 3:08 AM Johannes Schindelin
> wrote:
> >
> > On Mon, 9 Jul 2018, Junio C Hamano wrote:
> >
> > > I also wonder if we should be feeding the context lines to ws.c
> >
Hi Stefan,
On Tue, 10 Jul 2018, Stefan Beller wrote:
> This is developed on top of 4a68b95ce2a6 (your series here)
>
> This is an attempt to explain the previous email better,
> specially the second (yet unfinished) patch, but the resulting
> emit_line_0 is way clearer in my mind, dropping the
Hi Stefan,
On Tue, 17 Jul 2018, Stefan Beller wrote:
> > > It's nice to see that the bulk of the range-diff functionality has
> > > been libified in this re-roll (residing in range-diff.c rather than
> >
> > Can we *please* stop calling it "re-roll"? Thanks.
>
> Fun fact of the day:
>
> First
Hi Junio,
On Thu, 19 Jul 2018, Junio C Hamano wrote:
> Junio C Hamano writes:
>
> > Johannes Schindelin writes:
> >
> >> I would like to ask you to reinstate the post-rewrite hook, as it still
> >> improves the situation over the current one.
> >
>
Hi Junio,
On Mon, 16 Jul 2018, Junio C Hamano wrote:
> Jeff King writes:
>
> > None of which is too surprising. The root of the bug is in the
> > conversion to rebase--helper, I think, when presumably we started
> > setting GIT_DIR at all (but I didn't dig further). Then 09d7b6c6fa fixed
> >
Hi,
On Tue, 17 Jul 2018, Duy Nguyen wrote:
> On Tue, Jul 17, 2018 at 6:39 PM Duy Nguyen wrote:
> >
> > On Fri, Jul 13, 2018 at 10:19 PM Johannes Schindelin via GitGitGadget
> > wrote:
> > >
> > > From: Johannes Schindelin
> > >
> > &g
Hi Peff,
On Tue, 17 Jul 2018, Jeff King wrote:
> On Tue, Jul 17, 2018 at 03:15:31PM -0400, Jeff King wrote:
>
> > > - Also trigger `prune_shallow()` when
> > > `--unpack-unreachable=` was passed to `git repack`.
> > > - No need to trigger `prune_shallow()` when `git repack` was called with
>
Hi Junio,
On Tue, 17 Jul 2018, Junio C Hamano wrote:
> Jeff King writes:
>
> > I'm OK with having a partial fix, or one that fixes immediate pain
> > without doing a big cleanup, as long as it doesn't make anything _worse_
> > in a user-visible way. And that's really my question: is pruning
Hi Stolee,
On Wed, 18 Jul 2018, Derrick Stolee wrote:
> On 7/18/2018 1:01 PM, Junio C Hamano wrote:
> > No, fixing a tool that throws such a harder-to-read patch series in
> > reader's mailbox is *not* something I'd spend my primary focus on,
> > especially when many contributors are perfectly
Hi Peff,
On Wed, 18 Jul 2018, Jeff King wrote:
> On Wed, Jul 18, 2018 at 02:23:11PM +0200, Johannes Schindelin wrote:
>
> > > Yeah, they're out of order in mutt's threaded display. And the
> > > back-dating means there's a much higher chance of them getting blocked
&
Hi Junio,
On Wed, 18 Jul 2018, Junio C Hamano wrote:
> That won't stop those who want to improve the tool. But I'd wish
> those who want to make Git better spend their time on making Git,
> over making GitGitGadget, better.
And I'd wish that you would not make this task harder by refusing to
Hi Eric & Peff,
On Mon, 16 Jul 2018, Eric Sunshine wrote:
> On Mon, Jul 16, 2018 at 2:56 PM Jeff King wrote:
> > On Mon, Jul 16, 2018 at 02:40:21PM -0400, Eric Sunshine wrote:
> > > On Mon, Jul 16, 2018 at 12:18 PM Jeff King wrote:
> > > > git-send-email uses the current time minus an offset,
Hi,
On Mon, 16 Jul 2018, Derrick Stolee wrote:
> On 7/16/2018 2:44 PM, Eric Sunshine wrote:
> > On Mon, Jul 16, 2018 at 1:27 PM Stefan Beller wrote:
> > > Another pain point of the Gadget is that CC's in the cover letter
> > > do not work as I would imagine. The line
> > >
> > > CC:
Hi Peff,
On Mon, 16 Jul 2018, Jeff King wrote:
> On Mon, Jul 16, 2018 at 02:54:38PM +0100, Ramsay Jones wrote:
>
> > On 16/07/18 14:00, Derrick Stolee via GitGitGadget wrote:
> > > There are many places in Git that use a commit walk to determine
> > > reachability between commits and/or refs. A
Hi,
[dropping Perry's non-working email address again]
On Sat, 14 Jul 2018, brian m. carlson wrote:
> On Tue, Jul 10, 2018 at 10:03:10AM -0400, Jeff King wrote:
> > My point is that aside from RUNTIME_PREFIX, we don't need /proc. So
> > somebody who currently builds Git with a static path like
ny new
> > leaks in this patch (just use existing ones), I decided to put this
> > part on a review and fix leaks as a separate task.
>
> UPDATES since v1:
> add init to eaten variable (thanks to Szeder Gabor, Johannes Schindelin)
> improve second commit message (thanks to J
Hi Daniel,
On Mon, 16 Jul 2018, Daniel Harding wrote:
> On Mon, 16 Jul 2018 at 18:59:03 +0300, Johannes Schindelin wrote:
> >
> > On Mon, 16 Jul 2018, Aaron Schrab wrote:
> > >
> > > Looking into that a bit further, it does seem like my explanation above
>
Hi Eric,
On Mon, 16 Jul 2018, Eric Sunshine wrote:
> On Tue, Jul 3, 2018 at 7:26 AM Johannes Schindelin via GitGitGadget
> wrote:
> > After using this command extensively for the last two months, this
> > developer came to the conclusion that even if the dual color mode stil
Hi Eric,
On Mon, 16 Jul 2018, Eric Sunshine wrote:
> On Tue, Jul 3, 2018 at 7:27 AM Johannes Schindelin via GitGitGadget
> wrote:
> > The bulk of this patch consists of a heavily butchered version of
> > tbdiff's README written by Thomas Rast and Thomas Gummerer, lif
, only one test case needed
> > to be adjusted: 11 - 'changed message'.
> > [...]
> > Signed-off-by: Johannes Schindelin
> > ---
> > diff --git a/t/.gitattributes b/t/.gitattributes
> > @@ -18,5 +18,6 @@ t[0-9][0-9][0-9][0-9]/* -whitespace
> > /t7500/* eo
Hi Eric,
On Mon, 16 Jul 2018, Eric Sunshine wrote:
> On Tue, Jul 3, 2018 at 7:26 AM Johannes Schindelin via GitGitGadget
> wrote:
> > This change brings `git range-diff` yet another step closer to
> > feature parity with tbdiff: it now shows the oneline, too, and indicates
From: Johannes Schindelin
A `git fetch --prune` can turn previously-reachable objects unreachable,
even commits that are in the `shallow` list. A subsequent `git repack
-ad` will then unceremoniously drop those unreachable commits, and the
`shallow` list will become stale. This means that when
From: Johannes Schindelin
While it is true that we never add unreachable commits into pack files
intentionally (as `git repack`'s documentation states), we must not
forget that a `git fetch --prune` (or even a `git fetch` when a ref was
force-pushed in the meantime) can make a commit unreachable
`--unpack-unreachable=` was
passed to `git repack`.
- No need to trigger `prune_shallow()` when `git repack` was called with `-k`.
Johannes Schindelin (2):
repack: point out a bug handling stale shallow info
repack -ad: prune the list of shallow commits
builtin/repack.c | 6 ++
t/t5537
Hi Eric,
On Wed, 30 May 2018, Eric Sunshine wrote:
> When generating a range-diff, matching up commits between two version of
> a patch series involves heuristics, thus may give unexpected results.
> git-branch-diff allows tweaking the heuristic via --creation-weight.
> Follow suit by accepting
Hi Eric,
On Wed, 30 May 2018, Eric Sunshine wrote:
> diff --git a/builtin/log.c b/builtin/log.c
> index 460c31a293..e38cf06050 100644
> --- a/builtin/log.c
> +++ b/builtin/log.c
> @@ -995,10 +995,20 @@ static char *find_branch_name(struct rev_info *rev)
>
> static void
Hi Eric,
On Wed, 30 May 2018, Eric Sunshine wrote:
> diff --git a/builtin/log.c b/builtin/log.c
> index e01a256c11..460c31a293 100644
> --- a/builtin/log.c
> +++ b/builtin/log.c
> @@ -28,6 +28,7 @@
> #include "mailmap.h"
> #include "gpg-interface.h"
> #include "progress.h"
> +#include
Hi Eric,
On Wed, 30 May 2018, Eric Sunshine wrote:
> make_cover_letter() returns early when it lacks sufficient state to emit
> a diffstat, which makes it difficult to extend the function to reliably
> emit additional generated content. Work around this shortcoming by
> factoring
Hi Eric,
On Mon, 16 Jul 2018, Eric Sunshine wrote:
> On Mon, Jul 16, 2018 at 02:37:32PM -0700, Junio C Hamano wrote:
> > Eric Sunshine writes:
> > > On Mon, Jul 16, 2018 at 11:51 AM Johannes Schindelin
> > > wrote:
> > >> On Mon,
Hi Eric,
On Wed, 30 May 2018, Eric Sunshine wrote:
> Dscho recently implemented a 'tbdiff' replacement as a Git builtin named
> git-branch-diff[1] which computes differences between two versions of a
> patch series. Such a diff can be a useful aid for reviewers when
> inserted into a cover
Hi Eric,
On Mon, 16 Jul 2018, Eric Sunshine wrote:
> On Tue, Jul 3, 2018 at 7:27 AM Johannes Schindelin via GitGitGadget
> wrote:
> > At this stage, `git range-diff` can determine corresponding commits
> > of two related commit ranges. This makes use of the r
Hi Jonathan,
[had to drop Perry Hutchinson, as the email address is apparently invalid,
and I only realized now that I never sent this out.]
On Tue, 10 Jul 2018, Jonathan Nieder wrote:
> If this [/proc issue] is the main obstacle to enabling RUNTIME_PREFIX by
> default, one option would be to
Hi Eric,
On Mon, 16 Jul 2018, Johannes Schindelin wrote:
> On Sun, 1 Jul 2018, Eric Sunshine wrote:
>
> > This test has been dysfunctional since it was added by 619acfc78c
> > (submodule add: extend force flag to add existing repos, 2016-10-06),
> > however, two problem
Hi Eric,
On Sun, 1 Jul 2018, Eric Sunshine wrote:
> This test has been dysfunctional since it was added by 619acfc78c
> (submodule add: extend force flag to add existing repos, 2016-10-06),
> however, two problems early in the test went unnoticed due to a broken
> &&-chain later in the test.
>
From: Johannes Schindelin
In 60f487ac0ef (Remove common-cmds.h, 2018-05-10), we forgot to adjust
this README when removing the common-cmds.h file.
Signed-off-by: Johannes Schindelin
---
compat/vcbuild/README | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/compat
In 60f487ac0ef (Remove common-cmds.h, 2018-05-10), we forgot to adjust
this README when removing the common-cmds.h file.
Signed-off-by: Johannes Schindelin
Johannes Schindelin (1):
vcbuild/README: update to accommodate for missing common-cmds.h
compat/vcbuild/README | 4 ++--
1 file changed
Hi Elijah,
On Fri, 13 Jul 2018, Elijah Newren wrote:
> On Thu, Jul 12, 2018 at 8:49 AM, Johannes Schindelin
> wrote:
> >
> > On Wed, 27 Jun 2018, Elijah Newren wrote:
> >
> >> Signed-off-by: Elijah Newren
> >> ---
> >>
> >> Changes si
Hi Junio,
On Thu, 12 Jul 2018, Junio C Hamano wrote:
> Ben Peart writes:
>
> >> > Thanks. I thought it was strange as well until I realized you only
> >> > see the error message if there _isn't_ a valid drive letter so seeing
> >> > the entire path makes sense as it will likely be something
Hi Peff,
On Fri, 13 Jul 2018, Jeff King wrote:
> On Thu, Jul 12, 2018 at 12:23:28AM +0200, Johannes Schindelin via
> GitGitGadget wrote:
>
> > This is particularly important to keep in mind when looking at the
> > `.git/shallow` file: if any commits listed in that file b
Hi David,
On Thu, 12 Jul 2018, David Brown wrote:
> Howdy, I want to hack the getweb_make_index.perl script to create a string
> search using: https://github.com/git/git/blob/master/levenshtein.c.
>
> How do i reference the compiled code?
>
> I would like to call this routine using Java and
Hi Brian,
On Sat, 14 Jul 2018, brian m. carlson wrote:
> The sequencer currently passes GIT_DIR, but not GIT_WORK_TREE, to exec
> commands. In that configuration, we assume that whatever directory
> we're in is the top level of the work tree, and git rev-parse
> --show-toplevel responds
From: Johannes Schindelin
While it is true that we never add unreachable commits into pack files
intentionally (as `git repack`'s documentation states), we must not
forget that a `git fetch --prune` (or even a `git fetch` when a ref was
force-pushed in the meantime) can make a commit unreachable
gc`)
prunes them.
This is a problem when the `shallow` file still lists them, which is the reason
why `git prune` edits that file. And with the proposed changes, `git repack
-ad` will now do the same.
Reported by Alejandro Pauly.
Johannes Schindelin (2):
repack: point out a bug handling
From: Johannes Schindelin
A `git fetch --prune` can turn previously-reachable objects unreachable,
even commits that are in the `shallow` list. A subsequent `git repack
-ad` will then unceremoniously drop those unreachable commits, and the
`shallow` list will become stale. This means that when
Hi Elijah,
On Wed, 27 Jun 2018, Elijah Newren wrote:
> Signed-off-by: Elijah Newren
> ---
>
> Changes since v1:
> - Fixed up commit message (move below comment to below diffstat as
> originally intended)
>
> Long term I just want to make git-rebase--merge go away, so this patch
> will
Hi Elijah,
On Wed, 27 Jun 2018, Elijah Newren wrote:
> git-rebase.sh wrote strategy options to .git/rebase/merge/strategy_opts
> in the following format:
> '--ours' '--renormalize'
> Note the double spaces.
>
> git-rebase--interactive uses sequencer.c to parse that file, and
> sequencer.c
Hi Junio,
On Wed, 11 Jul 2018, Junio C Hamano wrote:
> Johannes Schindelin writes:
>
> > To summarize, there are two commits recorded for that Message-Id, the
> > later one not mapped back, and neither is the correct commit that made it
> > into `master`.
> >
>
Hi Gábor,
On Wed, 11 Jul 2018, SZEDER Gábor wrote:
> > diff --git a/linear-assignment.c b/linear-assignment.c
> > new file mode 100644
> > index 0..0b0344b5f
> > --- /dev/null
> > +++ b/linear-assignment.c
> > @@ -0,0 +1,203 @@
> > +/*
> > + * Based on: Jonker, R., & Volgenant, A.
Hi,
On Thu, 12 Jul 2018, Johannes Schindelin wrote:
> On Wed, 11 Jul 2018, Vitali Lovich wrote:
>
> > On Wed, Jul 11, 2018 at 7:50 PM Vitali Lovich wrote:
> > >
> > > Typically git rev-parse --show-toplevel prints the folder containing
> > > the .git
Hi Vitali,
[please avoid top-posting on this mailing list]
On Wed, 11 Jul 2018, Vitali Lovich wrote:
> On Wed, Jul 11, 2018 at 7:50 PM Vitali Lovich wrote:
> >
> > Typically git rev-parse --show-toplevel prints the folder containing
> > the .git folder regardless what subdirectory one is in.
Hi Ben,
On Wed, 11 Jul 2018, Ben Peart wrote:
> Teach test-drop-caches to handle lower case drive letters on Windows.
Maybe mention that you can trigger this by using a lower case drive letter
in Powershell (CMD normalizes your path, Powershell does not).
> diff --git
Hi,
On Wed, 11 Jul 2018, Junio C Hamano wrote:
> Beat Bolli writes:
>
> > Should we add a "pedantic" flag to DEVOPTS that would simplify
> > building pedantically? It would also have to set
> > USE_PARENS_AROUND_GETTEXT_N so as to not overwhelm the developer with
> > too much output.
>
> That
Hi Junio,
On Wed, 11 Jul 2018, Junio C Hamano wrote:
> Eric Sunshine writes:
>
> >> @@ -2956,28 +2991,76 @@ static int do_merge(struct commit *commit, const
> >> char *arg, int arg_len,
> >> + cmd.git_cmd = 1;
> >> + argv_array_push(, "merge");
> >> +
Hi Eric,
On Wed, 11 Jul 2018, Eric Sunshine wrote:
> On Wed, Jul 11, 2018 at 8:38 AM Johannes Schindelin via GitGitGadget
> wrote:
> > diff --git a/sequencer.c b/sequencer.c
> > @@ -2932,7 +2966,8 @@ static int do_merge(struct commit *commit, const char
>
Hi Junio,
On Wed, 11 Jul 2018, Junio C Hamano wrote:
> "Johannes Schindelin via GitGitGadget"
> writes:
>
> > diff --git a/builtin/merge.c b/builtin/merge.c
> > index 4a4c09496..b0e907751 100644
> > --- a/builtin/merge.c
> > +++ b/builtin/
Hi Stefan,
On Wed, 11 Jul 2018, Stefan Beller wrote:
> On Wed, Jul 11, 2018 at 10:35 AM Junio C Hamano wrote:
> > To be honest, I am not sure if there still are people who use
> > octopus
>
> The latest merge with more than 2 parents in linux.git is df958569dbaa
> (Merge branches 'acpi-tables'
Hi Junio,
On Wed, 11 Jul 2018, Junio C Hamano wrote:
> "Johannes Schindelin via GitGitGadget"
> writes:
>
> > The `--rebase-merges` option of `git rebase` generates todo lists that
> > include the merge commits that are to be rebased.
> >
> >
Hi Elijah,
On Wed, 11 Jul 2018, Elijah Newren wrote:
> On Fri, Mar 9, 2018 at 8:36 AM, Johannes Schindelin via GitGitGadget
> wrote:
>
> > diff --git a/Documentation/git-rebase.txt b/Documentation/git-rebase.txt
> > index 0e20a66e7..c4bcd24bb 100644
> > --- a/D
Hi Alban,
On Tue, 10 Jul 2018, Alban Gruin wrote:
> I published a new blog post:
>
> https://blog.pa1ch.fr/posts/2018/07/10/en/gsoc2018-week-10.html
Very pleasant read, and awesome news about the current state of your
project!
Thanks,
Dscho
From: Johannes Schindelin
Previously, we introduced the `merge` command for use in todo lists,
to allow to recreate and modify branch topology.
For ease of implementation, and to make review easier, the initial
implementation only supported merge commits with exactly two parents.
This patch
.
Johannes Schindelin (3):
merge: allow reading the merge commit message from a file
rebase --rebase-merges: add support for octopus merges
rebase --rebase-merges: adjust man page for octopus support
Documentation/git-merge.txt | 10 ++-
Documentation/git-rebase.txt | 7 +-
builtin
From: Johannes Schindelin
This is consistent with `git commit` which, like `git merge`, supports
passing the commit message via `-m ` and, unlike `git merge` before
this patch, via `-F `.
It is useful to allow this for scripted use, or for the upcoming patch
to allow (re-)creating octopus
From: Johannes Schindelin
Now that we support octopus merges in the `--rebase-merges` mode,
we should give users who actually read the manuals a chance to know
about this fact.
Signed-off-by: Johannes Schindelin
---
Documentation/git-rebase.txt | 7 ---
1 file changed, 4 insertions(+), 3
Hi Peff,
On Tue, 10 Jul 2018, Jeff King wrote:
> On Mon, Jul 09, 2018 at 10:15:05PM -0400, Jeff King wrote:
>
> > > Should this not rather be
> > >
> > > - if (!cmit || get_revision(opts->revs))
> > > - return error("BUG: expected exactly one commit from
> > > walk");
Hi Peff,
On Mon, 2 Jul 2018, Jeff King wrote:
> On Mon, Jul 02, 2018 at 09:29:41PM +0200, Christian Couder wrote:
>
> > When people complained a month ago about the MacOS package on
> > https://git-scm.com/ not being up-to-date after the Git security
> > release, I got in touch with Apple
Hi,
On Tue, 10 Jul 2018, SZEDER Gábor wrote:
> > diff --git a/t/helper/test-repository.c b/t/helper/test-repository.c
> > new file mode 100644
> > index 00..5fff540a26
> > --- /dev/null
> > +++ b/t/helper/test-repository.c
> > @@ -0,0 +1,88 @@
> > +#include "test-tool.h"
> > +#include
Hi Daniel,
On Tue, 10 Jul 2018, Daniel Harding wrote:
> On Mon, 09 Jul 2018 at 22:14:58 +0300, Johannes Schindelin wrote:
> >
> > On Mon, 9 Jul 2018, Daniel Harding wrote:
> > >
> > > On Mon, 09 Jul 2018 at 00:02:00 +0300, brian m. carlson wrote:
> > >
Hi Phillip,
On Wed, 14 Jun 2017, Philipp Gortan wrote:
> thanks for following up,
>
> > Indeed. Why don't you give it a try?
>
> Actually, I already did: https://github.com/patthoyts/git-gui/pull/12
>
> You might want to post your analysis and patch there as well...
I wonder what good
Hi Peff,
On Mon, 9 Jul 2018, Jeff King wrote:
> On Mon, Jul 09, 2018 at 10:26:54PM +0200, Johannes Schindelin wrote:
>
> > > Would it be reasonable to make RUNTIME_PREFIX the default on systems
> > > where we _do_ have that support? AFAIK there is no downside to having
Hi Junio,
On Mon, 9 Jul 2018, Junio C Hamano wrote:
> Johannes Schindelin writes:
>
> > Speaking of GitGitGadget: I just encoutered a problem with your
> > `refs/notes/amlog` and I hope you can help me with that.
> > ...
> > When I ask `git notes --ref
Hi Junio,
On Mon, 9 Jul 2018, Junio C Hamano wrote:
> I also wonder if we should be feeding the context lines to ws.c
> machinery in the first place though.
It *is* confusing, I know. The entire "diff of diffs" concept *is*
confusing. I just don't know about a better alternative.
So hear me
Hi Olga,
On Mon, 9 Jul 2018, Оля Тележная wrote:
> [2]
> https://public-inbox.org/git/010201637254c969-a346030e-0b75-41ad-8ef3-2ac7e04ba4fb-000...@eu-west-1.amazonses.com/
This type of Message-Id makes me think that you used SubmitGit to send
this patch series.
The main problem I see here is
Hi Olga,
On Mon, 9 Jul 2018, Olga Telezhnaya wrote:
> diff --git a/ref-filter.c b/ref-filter.c
> index 27733ef013bed..f04169f0ea0e3 100644
> --- a/ref-filter.c
> +++ b/ref-filter.c
> @@ -1437,20 +1419,24 @@ static const char *get_refname(struct used_atom
> *atom, struct ref_array_item *re
> }
Hi Junio,
On Sun, 8 Jul 2018, Johannes Schindelin wrote:
> I just encoutered a problem with your `refs/notes/amlog` and I hope you
> can help me with that.
>
> Concretely, I want GitGitGadget to be able to identify the commit that
> corresponds to a given mail that contained a pa
Hi Stefan,
On Mon, 9 Jul 2018, Stefan Beller wrote:
> On Mon, Jul 9, 2018 at 1:00 PM Johannes Schindelin
> wrote:
> >
> > On Mon, 9 Jul 2018, Stefan Beller wrote:
> >
> > > On Tue, Jul 3, 2018 at 4:26 AM Johannes Schindelin via GitGitGadget
> > > wrote
Hi Peff,
On Mon, 9 Jul 2018, Jeff King wrote:
> On Sun, Jul 08, 2018 at 11:52:22PM +0200, Johannes Schindelin wrote:
>
> > Now, if you care to have a look at Dan's (and my) patches to implement
> > RUNTIME_PREFIX so that it looks for a directory *relative to the Git
> &g
Hi Peff,
On Mon, 9 Jul 2018, Jeff King wrote:
> diff --git a/sequencer.c b/sequencer.c
> index f692b2ef44..234666b980 100644
> --- a/sequencer.c
> +++ b/sequencer.c
> @@ -3637,7 +3637,7 @@ int sequencer_pick_revisions(struct replay_opts *opts)
> return error(_("revision
Hi Peff,
On Mon, 9 Jul 2018, Jeff King wrote:
> If the user gives us a set that prepare_revision_walk()
> takes to be empty, like:
>
> git cherry-pick base..base
>
> then we report an error. It's nonsense, and there's nothing
> to pick.
>
> But if they use revision options that later cull
Hi Beat,
On Mon, 9 Jul 2018, Beat Bolli wrote:
> Am 09.07.2018 15:14, schrieb Johannes Schindelin:
> >
> > On Sun, 8 Jul 2018, Beat Bolli wrote:
> >
> > > In ISO C, char constants must be in the range -128..127. Change the BOM
> > > const
Hi Stefan,
On Mon, 9 Jul 2018, Stefan Beller wrote:
> On Tue, Jul 3, 2018 at 4:26 AM Johannes Schindelin via GitGitGadget
> wrote:
>
> > +'git range-diff' [--color=[]] [--no-color] []
> > + [--dual-color] [--creation-factor=]
> > + ( | ... |
Hi Daniel,
On Mon, 9 Jul 2018, Daniel Harding wrote:
> On Mon, 09 Jul 2018 at 00:02:00 +0300, brian m. carlson wrote:
> > On Sun, Jul 08, 2018 at 09:41:11PM +0300, Daniel Harding wrote:
> > > Signed-off-by: Daniel Harding
> >
> > > diff --git a/t/t3430-rebase-merges.sh
Hi Daniel,
On Mon, 9 Jul 2018, Daniel Harding wrote:
> One question about my original patch - there I had replaced a "grep -v"
> call with a "git stripspace" call in the 'generate correct todo list'
> test. Is relying on "git stripspace" in a test acceptable, or should
> external text
Hi Beat,
On Sun, 8 Jul 2018, Beat Bolli wrote:
> While developing 6aaded550 ("builtin/config: work around an unsized
> array forward declaration", 2018-07-05), I have compiled Git with
> CFLAGS="-std=c99 -pedantic".
>
> This is an RFC patch series that fixes a few compiler warnings when
>
Hi Beat,
On Sun, 8 Jul 2018, Beat Bolli wrote:
> In ISO C, char constants must be in the range -128..127. Change the BOM
> constants to unsigned char to avoid overflow.
>
> Signed-off-by: Beat Bolli
> ---
> utf8.c | 10 +-
> 1 file changed, 5 insertions(+), 5 deletions(-)
>
> diff
Hi Daniel,
On Sun, 8 Jul 2018, Daniel Harding wrote:
> I have core.commentChar set in my .gitconfig, and when I tried to run
> git rebase -i -r, I received an error message like the following:
>
> error: invalid line 3: # Branch
>
> To fix this, I updated sequencer.c to use the configured
Hi Brian,
On Sun, 8 Jul 2018, brian m. carlson wrote:
> On Sun, Jul 08, 2018 at 09:41:11PM +0300, Daniel Harding wrote:
> > Signed-off-by: Daniel Harding
>
> I think maybe, as you suggested, a separate test for this would be
> beneficial. It might be as simple as modifying
Hi Paul,
On Sun, 8 Jul 2018, Paul Smith wrote:
> On Fri, 2018-07-06 at 09:18 -0400, Daniel Jacques wrote:
> > I forewent autoconf because I was concerned that the option was too
> > obscure and the configuration too nuanced to be worth adding via
> > flag, as RUNTIME_PREFIX requires some degree
Hi Pratik,
On Sun, 8 Jul 2018, Pratik Karki wrote:
> + strbuf_addf(_snippet,
> + ". git-rebase--common && . %s && %s",
> + backend, backend_func);
In my quick test (on top of `wip-rebase`), this line needed this change:
-- snip --
@@ -269,7 +279,8 @@ static
Hi Pratik,
On Sun, 8 Jul 2018, Pratik Karki wrote:
> diff --git a/checkout.c b/checkout.c
> index bdefc888ba..da68915fd7 100644
> --- a/checkout.c
> +++ b/checkout.c
> @@ -2,6 +2,11 @@
> #include "remote.h"
> #include "refspec.h"
> #include "checkout.h"
> +#include "unpack-trees.h"
>
Hi Pratik,
On Sun, 8 Jul 2018, Pratik Karki wrote:
> As a GSoC project, I have been working on the builtin rebase.
>
> The motivation behind the rewrite of rebase i.e. from shell script to C
> are for following reasons:
>
> 1. Writing shell scripts and getting it to production is much faster
Hi Junio,
On Sat, 7 Jul 2018, Johannes Schindelin wrote:
> On Sat, 7 Jul 2018, Junio C Hamano wrote:
>
> > Johannes Schindelin writes:
> >
> > >> Does the "gitgitgadget" thing lie on the Date: e-mail header?
> > >
> > > No, GitGitGadge
Hi Junio,
On Sat, 7 Jul 2018, Junio C Hamano wrote:
> Johannes Schindelin writes:
>
> >> Does the "gitgitgadget" thing lie on the Date: e-mail header?
> >
> > No, GitGitGadget takes the literal output from `git format-patch`, as far
> > as I
Hi Elijah,
On Fri, 6 Jul 2018, Elijah Newren wrote:
> On Fri, Jul 6, 2018 at 3:57 PM, Junio C Hamano wrote:
> > I'll be pushing out the integration branches with some updates, but
> > there is no change in 'next' and below. The following topics I gave
> > a quick look and gave them topic
Hi Junio,
On Fri, 6 Jul 2018, Junio C Hamano wrote:
> I'll be pushing out the integration branches with some updates, but
> there is no change in 'next' and below. The following topics I gave
> a quick look and gave them topic branches, but I had trouble merging
> them in 'pu' and making them
Hi Christian,
On Sat, 7 Jul 2018, Christian Couder wrote:
> On Fri, Jul 6, 2018 at 2:08 PM, Pratik Karki wrote:
>
> > + switch (opts->type) {
> > + case REBASE_AM:
> > + backend = "git-rebase--am";
> > + backend_func = "git_rebase__am";
> > +
Hi Junio,
On Fri, 6 Jul 2018, Junio C Hamano wrote:
> "Johannes Schindelin via GitGitGadget"
> writes:
>
> > From: Johannes Schindelin
> >
> > Tab completion of `git range-diff` is very convenient, especially
> > given that the revision arguments
701 - 800 of 5954 matches
Mail list logo
