A core dump occurred while trying to interactively apply (3-way) a
series of patches from a mailbox.
git version 2.20.1
Steps to reproduce:
alex@polaris:~/slurm/source$ git am -3 -i
~/Downloads/6033-18.08-final-patchset-v2.patch
Commit Body is:
--
Use correct signed/unsig
Hi Stolee,
On Fri, 17 May 2019, Derrick Stolee via GitGitGadget wrote:
> In Windows, the way we rename a lock file to replace the underlying file
> does not work when a process holds a read handle. For this reason, we call
> close_all_packs() everywhere before starting a git gc --auto subprocess.
"Eric S. Raymond" writes:
> Jakub Narebski :
>> As far as I understand it this would slow down receiving new commits
>> tremendously. Currently great care is taken to not have to parse the
>> commit object during fetch or push if it is not necessary (thanks to
>> things such as reachability bitm
Hi everyone!
A draft of a new Git Rev News edition is available here:
https://github.com/git/git.github.io/blob/master/rev_news/drafts/edition-51.md
Everyone is welcome to contribute in any section either by editing the
above page on GitHub and sending a pull request, or by commenting on
this
On Mon, May 20, 2019 at 10:35:53AM +0200, Alejandro Sanchez wrote:
> alex@polaris:~/slurm/source$ git add -u
> alex@polaris:~/slurm/source$ git am -i --continue
> Applying: Handle duplicate archive file names.
> error: object 861d3c6f689a3ca5eb5fb5c409d46de0ade1 is a commit, not a tree
> BUG:
Hi Stolee,
*really* minor nit: the commit subject probably wants to have a "rename"
after the colon ;-)
The patch looks sensible to me. Since Junio asked for a sanity check
whether all of the call sites of `close_all_packs()` actually want to
close the MIDX and the commit graph, too, I'll do the
On Mon, May 20 2019, Jakub Narebski wrote:
> "Eric S. Raymond" writes:
>> Jakub Narebski :
>
>>> As far as I understand it this would slow down receiving new commits
>>> tremendously. Currently great care is taken to not have to parse the
>>> commit object during fetch or push if it is not nec
Hi Junio,
On Sun, 19 May 2019, Junio C Hamano wrote:
> "Derrick Stolee via GitGitGadget" writes:
>
> > This series adds close_commit_graph() to close_all_packs() and then renames
> > close_all_packs() to close_object_store(). This name is more descriptive of
> > its larger purpose.
>
> OK. Some
Derrick Stolee writes:
> On 5/18/2019 12:17 AM, Mike Hommey wrote:
>> On Sat, May 18, 2019 at 12:58:28PM +0900, Mike Hommey wrote:
>>> On Sat, May 18, 2019 at 03:50:05AM +0200, SZEDER Gábor wrote:
All the above is without commit-graph, I presume? If so, then you
should give it a tr
On 5/18/2019 10:04 PM, Junio C Hamano wrote:
> "Derrick Stolee via GitGitGadget" writes:
>
>> This series adds close_commit_graph() to close_all_packs() and then renames
>> close_all_packs() to close_object_store(). This name is more descriptive of
>> its larger purpose.
>
> OK. Somebody needs
On 5/20/2019 7:02 AM, Jakub Narebski wrote:
>
> Are there any blockers that prevent the switch to this
> "generation number v2"?
>
> - Is it a problem with insufficient data to choose the correct numbering
> as "generation number v2' (there can be only one)?
> - Is it a problem with selected "ge
On Sun, May 19, 2019 at 2:42 PM Jeff King wrote:
> If the user clones with a URL containing a password and has no
> credential helper configured, we're stuck. We don't want to write the
> password into .git/config because that risks accidentally disclosing it.
> But if we don't record it somewhere
On 5/20/2019 6:01 AM, Johannes Schindelin wrote:
> Hi Stolee,
>
> *really* minor nit: the commit subject probably wants to have a "rename"
> after the colon ;-)
I did put that there, but then the subject line was too long. I'm not
opposed to putting it back.
> The patch looks sensible to me. Si
On Mon, May 20, 2019 at 06:02:11AM -0400, Jeff King wrote:
> I haven't tried to reproduce yet. Is the repository (and patch) that you
> used to demonstrate this publicly available? Or alternatively, is it
> possible to show a backtrace from the coredump?
Never mind. It reproduces quite easily, be
We'll never see a NULL returned from git_prompt(); if it can't produce
any input for us (e.g., because the terminal got EOF) then it will just
die().
So there's no need for us to handle NULL here. And even if there was, it
doesn't make sense to continue; on a true terminal hangup we'd just loop
in
In the conversion of git-am from shell script to C, we switched to using
git_prompt(). Unlike the original shell command "read reply", this
doesn't read from stdin at all, but rather from /dev/tty.
In most cases this distinction wouldn't matter. We require (as the shell
script did) that stdin is a
We have required that the stdin of "am --interactive" be a tty since
a1451104ac (git-am: interactive should fail gracefully., 2005-10-12).
However, this isn't strictly necessary, and makes the tool harder to
test (and is unlike all of our other --interactive commands).
The goal of that commit was
In interactive mode, "git am -i --resolved" will try to generate a patch
based on what is in the index, so that it can prompt "apply this
patch?". To do so it needs the tree of HEAD, which it tries to get with
get_oid_tree(). However, this doesn't yield a tree oid; the "tree" part
just means "if yo
On Mon, May 20, 2019 at 07:28:08AM -0400, Eric Sunshine wrote:
> > The biggest downside is that it's a bit magical from the user's
> > perspective, because now the password is off in some other file (usually
> > ~/.git-credentials, but sometimes in $XDG_CONFIG_HOME). Which
> > complicates things i
On Mon, May 20, 2019 at 11:43:14AM +0200, Jakub Narebski wrote:
> You can receive new commits in the repository by creating them, and from
> other repository (via push or fetch). In the second case you often get
> many commits at once.
>
> In [1] it is described how using "bitmap index" you can
On Mon, May 20, 2019 at 08:11:13AM -0400, Jeff King wrote:
> We have required that the stdin of "am --interactive" be a tty since
> a1451104ac (git-am: interactive should fail gracefully., 2005-10-12).
> However, this isn't strictly necessary, and makes the tool harder to
> test (and is unlike all
On Sun, May 19, 2019 at 09:56:36AM +0700, Nguyễn Thái Ngọc Duy wrote:
> This patch goes with the second option, making sure that 'index' is
> always allocated after initialization. It's less effort than the first
> one, and also safer because you could still miss things during the code
> audit. Th
Derrick Stolee writes:
> On 5/20/2019 7:02 AM, Jakub Narebski wrote:
>>
>> Are there any blockers that prevent the switch to this
>> "generation number v2"?
>>
>> - Is it a problem with insufficient data to choose the correct numbering
>> as "generation number v2' (there can be only one)?
>> -
Elijah Newren writes:
> On Wed, May 15, 2019 at 8:30 AM Ævar Arnfjörð Bjarmason
> wrote:
>> On Wed, May 15 2019, Piotr Krukowiecki wrote:
>>>
>>> I'm migrating two repositories from svn. I already did svn->git
>>> migration (git-svn clone) and now have two git repositories.
>>>
>>> I would like t
On Sun, May 19 2019, Jeff King wrote:
> If the user clones with a URL containing a password and has no
> credential helper configured, we're stuck. We don't want to write the
> password into .git/config because that risks accidentally disclosing it.
> But if we don't record it somewhere, subsequ
On Mon, May 20, 2019 at 03:56:14PM +0200, Ævar Arnfjörð Bjarmason wrote:
> > -test_expect_failure 'fetch of password-URL clone uses stored auth' '
> > +test_expect_success 'fetch of password-URL clone uses stored auth' '
> > set_askpass wrong &&
> > git -C clone-auth-none fetch &&
> >
Jakub Narebski :
> > What "commits that follow it?" By hypothesis, the incoming commit's
> > timestamp is bumped (if it's bumped) when it's first added to a branch
> > or branches, before there are following commits in the DAG.
>
> Errr... the main problem is with distributed nature of Git, i.e. w
On Mon, 20 May 2019 10:14:17 -0400
"Eric S. Raymond" wrote:
> Jakub Narebski :
> > > What "commits that follow it?" By hypothesis, the incoming commit's
> > > timestamp is bumped (if it's bumped) when it's first added to a branch
> > > or branches, before there are following commits in the DAG.
Hi Peff,
On Sun, 19 May 2019, Jeff King wrote:
> On Fri, May 17, 2019 at 06:20:31PM -0400, Jeff King wrote:
>
> > What if we did this:
> >
> > 1. Do not ever write the password part of a URL into config.
> >
> > 2. When we extract the user/pass out of a URL, put them into the
> > credent
On Wed, 15 May 2019 21:25:46 -0400
Derrick Stolee wrote:
> On 5/15/2019 8:28 PM, Eric S. Raymond wrote:
> > Derrick Stolee :
> >> What problem are you trying to solve where commit date is important?
> > B. Unique canonical form of import-stream representation.
> >
> > Reposurgeon is a very
On Mon, May 20 2019, Jeff King wrote:
> On Mon, May 20, 2019 at 03:56:14PM +0200, Ævar Arnfjörð Bjarmason wrote:
>
>> > -test_expect_failure 'fetch of password-URL clone uses stored auth' '
>> > +test_expect_success 'fetch of password-URL clone uses stored auth' '
>> >set_askpass wrong &&
>>
On Mon, May 20, 2019 at 05:17:20PM +0200, Ævar Arnfjörð Bjarmason wrote:
> > There are more cases beyond that, too. You might have a helper defined
> > which doesn't actually store passwords, but just sometimes tries to
> > provide one. My thinking was that if you're clueful enough to have
> > con
Am 19.05.19 um 07:10 schrieb Jeff King:
> diff --git a/transport.c b/transport.c
> index f1fcd2c4b0..ba61e57295 100644
> --- a/transport.c
> +++ b/transport.c
> @@ -1373,7 +1372,15 @@ char *transport_anonymize_url(const char *url)
> cp = strchr(scheme_prefix + 3, '/');
>
Hi Peff,
On Sun, 19 May 2019, Jeff King wrote:
> When we anonymize URLs to show in messages, we strip out both the
> username and password (if any). But there are also contexts where we
> should strip out the password (to avoid leaking it) but retain the
> username.
>
> Let's generalize transport
Michal Suchánek :
> On Wed, 15 May 2019 21:25:46 -0400
> Derrick Stolee wrote:
>
> > On 5/15/2019 8:28 PM, Eric S. Raymond wrote:
> > > Derrick Stolee :
> > >> What problem are you trying to solve where commit date is important?
>
> > > B. Unique canonical form of import-stream representatio
Whoops. Meant to comment on this:
On Sun, 19 May 2019, Jeff King wrote:
> diff --git a/transport.c b/transport.c
> index f1fcd2c4b0..ba61e57295 100644
> --- a/transport.c
> +++ b/transport.c
> @@ -1335,11 +1335,7 @@ int transport_disconnect(struct transport *transport)
> return ret;
> }
>
Hi Peff,
On Mon, 20 May 2019, Jeff King wrote:
> On Mon, May 20, 2019 at 07:28:08AM -0400, Eric Sunshine wrote:
>
> > > The biggest downside is that it's a bit magical from the user's
> > > perspective, because now the password is off in some other file
> > > (usually ~/.git-credentials, but some
On 5/10/2019 9:37 AM, Ævar Arnfjörð Bjarmason wrote:
Fix a trivial bug that's been here since the shared/do_write_index
tracing was added in 42fee7a388 ("trace2:data: add trace2
instrumentation to index read/write", 2019-02-22). We should have
enter/leave points, not two enter/enter points. Th
Hi Duy,
On Sat, 18 May 2019, Nguyễn Thái Ngọc Duy wrote:
> Another round because apparently the test case is not perfect.
Test cases are never perfect. But at least the good ones are "actionable",
i.e. when they fail, you know there is a regression, it helps you figure
out easily why it broke, a
From: Marc-André Lureau
This adds xfuncname and word_regex patterns for Rust, a quite
popular programming language. It also includes test cases for the
xfuncname regex (t4018) and updated documentation.
The word_regex pattern finds identifiers, integers, floats and
operators, according to the Ru
On Sun, May 19 2019, Jeff King wrote:
> If the user clones with a URL containing a password and has no
> credential helper configured, we're stuck. We don't want to write the
> password into .git/config because that risks accidentally disclosing it.
> But if we don't record it somewhere, subsequ
IP
“< asawaqoh...@icloud.com >”
“ tonyomont...@gmail.com.org “
“ reyesapriljo...@gmail.com.org “
“ gabriel...@gmail.com.org “
“ ( +63 2 730 1212 ) “.
“ ( +49 6386 9423 ) “
“
On 5/20/2019 12:36 PM, Eric S. Raymond wrote:
> Michal Suchánek :
>> On Wed, 15 May 2019 21:25:46 -0400
>> Derrick Stolee wrote:
>>
>>> On 5/15/2019 8:28 PM, Eric S. Raymond wrote:
Derrick Stolee :
> What problem are you trying to solve where commit date is important?
>>
B. Uniqu
Safari - 21 May 2562 BE at 12_36 AM.pdf
Description: Adobe PDF document
“< asawaqoh...@icloud.com >”
“ tonyomont...@gmail.com.org “
“ reyesapriljo...@gmail.com.org “
“ gabriel...@gmail.com.org “
Hi Duy,
On Sat, 18 May 2019, Nguyễn Thái Ngọc Duy wrote:
> diff --git a/t/t7600-merge.sh b/t/t7600-merge.sh
> index 106148254d..625a24a980 100755
> --- a/t/t7600-merge.sh
> +++ b/t/t7600-merge.sh
> @@ -822,4 +822,30 @@ test_expect_success EXECKEEPSPID 'killed merge can be
> completed with --cont
On 5/10/2019 5:57 PM, Ævar Arnfjörð Bjarmason wrote:
On Fri, May 10 2019, Jeff King wrote:
On Fri, May 10, 2019 at 05:09:58PM +0200, Ævar Arnfjörð Bjarmason wrote:
As noted in TODOs in the script there's various stuff I'd like to do
better, and this also shows how we need a lot more trace
Hi, Ævar
> Give "rebase -i" some option so when you "reword" the patch is
> included in the message.
>
> I keep going to the shell because I have no idea what change I'm
> describing.
I have the same problem, so I wanted to try solving this. The patch
bellow creates a "rebase.verboseCommit" confi
> On 2019/05/17, at 6:17, Matthew DeVore wrote:
>
>
>
>> On May 16, 2019, at 8:25 PM, Junio C Hamano wrote:
>>>
>>> $ git rev-list --filter=tree:2 --filter:blob:limit=32k
>>
>> Shouldn't the second one say "--filter=blob:limit=32k" (i.e. the
>> first colon should be an equal sign)?
>
> On 2019/05/17, at 6:17, Matthew DeVore wrote:
>
> We do have to require the combine operator (& or +) and % be encoded. For
> other operators, there are three options:
>
> ...
> 3. Require encoding of a couple of "reserved" characters that don't appear in
> filters now, and don't typically
On 5/10/2019 1:00 PM, SZEDER Gábor wrote:
On Fri, May 10, 2019 at 12:38:52PM -0400, Derrick Stolee wrote:
export GIT_TR2_EVENT=~/git-tr2-event.txt
Hrm, better late than never, or at least better late than after it's
in a release...
Why does an environment variable that is supposed to be s
On Sun, May 19, 2019 at 10:00 AM Junio C Hamano wrote:
>
> * The diff machinery, one of the oldest parts of the system, which
>long predates the parse-options API, uses fairly long and complex
>handcrafted option parser. This is being rewritten to use the
>parse-options API.
It look
Am 18.05.19 um 05:46 schrieb Boxuan Li:
> Octave pattern is almost the same as matlab, except
> that '%%%' and '##' can also be used to begin code sections,
> in addition to '%%' that is understood by both. Octave
> pattern is merged into Matlab pattern. Test cases for
> the hunk header patterns of
Am 20.05.19 um 19:04 schrieb marcandre.lur...@redhat.com:
> From: Marc-André Lureau
>
> This adds xfuncname and word_regex patterns for Rust, a quite
> popular programming language. It also includes test cases for the
> xfuncname regex (t4018) and updated documentation.
>
> The word_regex patter
Hi Junio,
The SQUASH??? patches look good to me. Please squash away!
Thanks,
-Michael
On Fri, 17 May 2019 at 06:12, Junio C Hamano wrote:
>
> Barret Rhoden writes:
>
> > From: Michael Platings
> >
> > ...
> > Michael removed the bashisms from the tests.
>
> Will replace what's queued.
>
> Note
Hi -
On 5/20/19 4:32 PM, Michael Platings wrote:
Hi Junio,
The SQUASH??? patches look good to me. Please squash away!
Thanks,
-Michael
I can squash them into the next version of the patch set too, pending
other comments / changes.
Thanks,
Barret
[snip]
> > + - You can launch gdb around your program using the shorthand GIT_DEBUGGER.
> > + Run `GIT_DEBUGGER=1 ./bin-wrappers/git foo` to simply use gdb as is, or
> > + run `GIT_DEBUGGER=debugger-binary some-args ./bin-wrappers/git foo` to
>
> Missing some quotes around debugger-binary and
Jeff King wrote:
> The patch itself looks good to me.
For what it's worth,
Reviewed-by: Jonathan Nieder
as well. It's a straightforward patch and solves the reader-facing
problem. Thanks.
For the curious, the upstream discussion in docbook-xsl is
https://lists.oasis-open.org/archives/docboo
Derrick Stolee :
> What it sounds like you are doing is piping a 'git fast-import' process into
> reposurgeon, and testing that reposurgeon does the same thing every time.
> Of course this won't be consistent if 'git fast-import' isn't consistent.
It's not actually import that fails to have consis
Hi,
On Mon, May 20, 2019 at 11:09 AM Eric S. Raymond wrote:
> > For cookie to be unique among all forks / clones of the same repository
> > you need either centralized naming server, or for the cookie to be based
> > on contents of the commit (i.e. be a hash function).
>
> I don't need uniquess
Remove a reference to git-cvsimport in the intro. As can be seen from
the history of this command[1] it was originally intended for use with
git-cvsimport, but how it uses it (and that it uses it at all) is
irrelevant trivia at this point.
1. See 7672db20c2 ("[PATCH] Expose object ID computation f
Clarify the hash-object docs to explicitly note that the --literally
option guarantees that a loose object will be written, but that a
normal -w ("write") invocation doesn't.
At first I thought talking about "loose object" in the docs was a
mistake in 83115ac4a8 ("git-hash-object.txt: document --l
Small doc fixes. Maybe trivial enough to land in 2.22, but there's no
rush.
A pair of #leftoverbits I noticed is that we've implemented the
"--stdin-paths" option via unquote_c_style() from day one, so our
current docs lie (and still do with this series) about wanting
\n-delimited files, you can't
Amend the intro to note that it's better to ask the index about files
already tracked by it.
I've seen uses of this in the wild where the use-case was finding
object IDs for files found in a freshly cloned repo, i.e. something
like "git ls-files | git hash-object --stdin-paths".
Signed-off-by: Æv
On Mon, May 20 2019, Bryan Turner wrote:
> On Sun, May 19, 2019 at 10:00 AM Junio C Hamano wrote:
>>
>> * The diff machinery, one of the oldest parts of the system, which
>>long predates the parse-options API, uses fairly long and complex
>>handcrafted option parser. This is being rew
When hash-object hashes something the size of core.bigFileThreshold or
larger (512MB by default) it'll be streamed through
stream_to_pack().
That added in 568508e765 ("bulk-checkin: replace fast-import based
implementation", 2011-10-28) would compress the file with zlib, but
was oblivious as to wh
Hi,
On 20/05/2019 15:41, Michal Suchánek wrote:
But you were talking as though all those commits
have to be modified*after they're in the DAG*, and that's not the case.
If any timestamp has to be modified, it only has to happen*once*, at the
time its commit enters the repo.
And that's where y
On Sat, 18 May 2019, Duy Nguyen wrote:
> On Fri, May 17, 2019 at 3:55 PM Jeff King wrote:
> >
> > On Fri, May 17, 2019 at 02:20:42PM +0700, Duy Nguyen wrote:
> >
> > > On Fri, May 17, 2019 at 12:35 PM Jeff King wrote:
> > > > As it turns out, index-pack does not handle these complicated cases at
Elijah Newren :
> Hi,
>
> On Mon, May 20, 2019 at 11:09 AM Eric S. Raymond wrote:
>
> > > For cookie to be unique among all forks / clones of the same repository
> > > you need either centralized naming server, or for the cookie to be based
> > > on contents of the commit (i.e. be a hash functio
Jakub Narebski writes:
> Derrick Stolee writes:
>> On 5/20/2019 7:02 AM, Jakub Narebski wrote:
>>>
>>> Are there any blockers that prevent the switch to this
>>> "generation number v2"?
[...]
>> Using the generation number column for the corrected
>> commit-date offsets (ass
On 2019-05-19 at 06:03:11, Olegzandr von Denman (ORESoftware) wrote:
> I was expected an env var like:
>
> GIT_DESIRED_COMMIT_MESSAGE
>
> to show up when .git/hooks/pre-commit is run
>
> but as described here, there doesn't appear to be any args to the
> script and the environment variable isn't
On Mon, May 20 2019, Matheus Tavares wrote:
> Hi, Ævar
>
>> Give "rebase -i" some option so when you "reword" the patch is
>> included in the message.
>>
>> I keep going to the shell because I have no idea what change I'm
>> describing.
>
> I have the same problem, so I wanted to try solving thi
"Eric S. Raymond" writes:
> Jakub Narebski :
>>> What "commits that follow it?" By hypothesis, the incoming commit's
>>> timestamp is bumped (if it's bumped) when it's first added to a branch
>>> or branches, before there are following commits in the DAG.
>>
>> Errr... the main problem is with d
We check for a handy environment variable GIT_DEBUGGER when running via
bin-wrappers/, but this feature is undocumented. Add a hint to how to
use it into the CodingGuidelines (which is where other useful
environment settings like DEVELOPER are documented).
It looks like you can use GIT_DEBUGGER to
Jakub Narebski :
> Errr... how did you get that the hash of a commit is not portable???
OK. You're telling me that premise was wrong. Thank you,
accepted.
I've since had a better idea. Expect mail soon.
--
http://www.catb.org/~esr/";>Eric S. Raymond
On 5/20/2019 7:27 PM, Jakub Narebski wrote:
> Jakub Narebski writes:
>> Derrick Stolee writes:
>>> On 5/20/2019 7:02 AM, Jakub Narebski wrote:
Are there any blockers that prevent the switch to this
"generation number v2"?
> [...]
>
>>> Using the generation num
I have been thinking hard about the problems raised during my
request for unique timestamps. I think I've found a better way
to bust the box I was trying to break out of. I am therefore
withdrawing that proposal and replacing it with this one.
It's time to separate commit identification from Mer
Hi!
Eric S. Raymond wrote:
> One reason I am sure of this is the SHA-1 to whatever transition.
> We can't count on the successor hash to survive attack forever.
> Accordingly, git's design needs to be stable against the possibility
> of having to accommodate multiple future hash algorithms in the
SZEDER Gábor wrote:
> On Sat, May 18, 2019 at 09:54:12AM +0900, Mike Hommey wrote:
>> There are established corner cases, where in a repo where commit dates
>> are not monotonically increasing,
[...]
> All the above is without commit-graph, I presume? If so, then you
> should give it a try, as it
On Sat, May 18, 2019 at 06:38:39PM +0200, Johannes Sixt wrote:
> Am 18.05.19 um 14:58 schrieb Ax Da:
> > You can rename files like this:
> > git mv File.txt file.txt
>
> On a case-insensitive, case-preserving filesystem, a case-only rename
> operation is better performed in two steps that do not ju
Jonathan Nieder :
> Hi!
>
> Eric S. Raymond wrote:
>
> > One reason I am sure of this is the SHA-1 to whatever transition.
> > We can't count on the successor hash to survive attack forever.
> > Accordingly, git's design needs to be stable against the possibility
> > of having to accommodate mult
Hi,
Eric S. Raymond wrote:
> Jonathan Nieder :
>> Eric S. Raymond wrote:
>>> One reason I am sure of this is the SHA-1 to whatever transition.
>>> We can't count on the successor hash to survive attack forever.
[...]
>> Have you read through Documentation/technical/hash-function-transition? It
>
When using GIT_NAMESPACE, it appears the "symref" added to the
capabilities advertisement doesn't get the namespace stripped. The
namespace is stripped for the advertised refs, including "HEAD", but
not on the "symref".
Lafiel:test bturner$ GIT_NAMESPACE=foo GIT_TRACE_PACKET=1 git ls-remote origin
Jonathan Nieder :
> > I think it's a weakness, though, that most of it is written as though it
> > assumes only one hash transition will be necessary. (This is me thinking
> > on long timescales again.)
>
> Hm, can you point to what part of the doc suggested that? Best to make
> the text clearer
On Mon, May 20, 2019 at 8:49 PM Ævar Arnfjörð Bjarmason
wrote:
>
>
> On Mon, May 20 2019, Matheus Tavares wrote:
>
> > Hi, Ævar
> >
> >> Give "rebase -i" some option so when you "reword" the patch is
> >> included in the message.
> >>
> >> I keep going to the shell because I have no idea what chan
84 matches
Mail list logo
