We have a parallel build that occasionally fails with the error message
"make: write error". Make prints that error message as it is exiting when
it detects that it has seen errors while writing to stdout. The error it
is enountering is an EAGAIN error, which implies that something has made
its s
Rebasing normally updates the current branch to the rewritten version.
If any other branches point to commits rewritten along the way, those
remain untouched. This commit adds an `--update-branches` option, which
instructs the command to update any such branches that it encounters to
point to the r
Everyone in this thread, thanks for your support and encouragement.
Johannes, thanks for reviewing.
> Maybe `s/reapplied/rebased/`?
Ok. I've changed most occurrences, except in Documentation/git-rebase.txt, where
the term 'reapplied' is already in use.
> drop this hunk and only keep the next on
Phillip, thanks for the comments. Indeed other branches that are not in the todo
list are still not updated.
I'm collecting the arguments about deferring the branch updates and issue with
worktrees for discussion along with Johannes's review.
Brian, thanks for looking. The only thing I can come up with to say about having
lots of refs is that at least that part of this isn't brand new code. The part
that collects ref info uses the same routines as `git log --decorate`. Do you
recall how long that took in the repository with 80,000 refs?
On Sat, Sep 07, 2019 at 07:28:21PM -0400, Taylor Blau wrote:
> ...
Oh, great. I was pretty sure that vger accidentally ate my last mail,
but I guess not. Sorry for the re-send.
Thanks,
Taylor
Hi Eric,
On Sat, Sep 07, 2019 at 03:36:46PM -0600, Eric Freese wrote:
> Using the new flag will omit symbolic refs from the output.
>
> Without this flag, it is possible to get this behavior by using the
> `%(symref)` formatting field name and piping output through grep to
> include only those ref
Hi Eric,
On Sat, Sep 07, 2019 at 03:36:46PM -0600, Eric Freese wrote:
> Using the new flag will omit symbolic refs from the output.
>
> Without this flag, it is possible to get this behavior by using the
> `%(symref)` formatting field name and piping output through grep to
> include only those ref
Hi Eric,
On Sat, Sep 07, 2019 at 03:36:45PM -0600, Eric Freese wrote:
> Hi,
>
> I was recently using git-for-each-ref in a script to get a list of
> remote refs that pointed at a particular commit so that they could
> automatically be updated and pushed back to that remote. This fails when
> it co
Hi,
I was recently using git-for-each-ref in a script to get a list of
remote refs that pointed at a particular commit so that they could
automatically be updated and pushed back to that remote. This fails when
it comes across refs/remotes/origin/HEAD, which is a symbolic link.
I was able to solv
Using the new flag will omit symbolic refs from the output.
Without this flag, it is possible to get this behavior by using the
`%(symref)` formatting field name and piping output through grep to
include only those refs that do not output a value for `%(symref)`, but
having this flag is more elega
On Sat, 7 Sep 2019 17:20:33 +0530 Rohit Ashiwal
wrote:
> [...]
> +test_expect_success '--ignore-date works with rebase -r' '
> + git checkout side &&
> + git merge commit3 &&
Should use --no-ff option to be sure that it handles "merge"
commits properly. Same for [3/6]. Please Junio chan
On Sat, Sep 07, 2019 at 01:04:40AM -0400, Jeff King wrote:
> The commit-graph tool may read a lot of commits, but it only cares about
> parsing their metadata (parents, trees, etc) and doesn't ever show the
> messages to the user. And so it should not need save_commit_buffer,
> which is meant for h
On Sat, Sep 07, 2019 at 12:34:07PM +0200, SZEDER Gábor wrote:
> On Sat, Sep 07, 2019 at 01:01:33AM -0400, Jeff King wrote:
> > From: SZEDER Gábor
> >
> > Commit 49bbc57a57 (commit-graph write: emit a percentage for all
> > progress, 2019-01-19) was a bit overeager when it added progress
> > percen
Here are the topics that have been cooking. Commits prefixed with
'-' are only in 'pu' (proposed updates) while commits prefixed with
'+' are in 'next'. The ones marked with '.' do not appear in any of
the integration branches, but I am still holding onto them.
The tip of 'next' has been rewound
Our documentation toolchain has traditionally been built around DocBook
4.5. This version of DocBook is the last DTD-based version of DocBook.
In 2009, DocBook 5 was introduced using namespaces and its syntax is
expressed in RELAX-NG, which is more expressive and allows a wider
variety of syntax f
On 2019-09-07 at 04:40:22, Jeff King wrote:
> On Fri, Sep 06, 2019 at 11:29:47PM +, brian m. carlson wrote:
> > I'll look into this. I requested the upgrade in sid.
> >
> > If it's the lack of DocBook 4.5 support, then I'll probably need to
> > patch xmlto for that. DocBook 5 has been around
The example output of `git merge-index` has been enriched by a second
"column" of helpful comments. When Asciidoctor renders this, the cells
in that second column aren't aligned.
Fix this by marking the example shell session as a code listing by
wrapping it in "". Also drop some of the horizon
This paragraph uses a lot of +pluses+ to render text as monospace. That
works fine with AsciiDoc (8.6.10), and almost fine with Asciidoctor
(1.5.5), which renders the third of these literally ("+$projname+"). The
reason seems to be that Asciidoctor trips on the lone plus a bit
earlier, even though
The indented lines in these example config-file listings are indented
differently by AsciiDoc and Asciidoctor.
Fix this by marking the example config-files as code listings by
wrapping them in "". Because this gives us some extra indentation,
we can remove the one that we have been carrying ex
There are several graphs in this document. For most of them, we use a
single leading tab to indent the whole graph, and then we use spaces
(possibly eight or more) to align things within the graph.
In the larger graph, we use a different strategy: We use 1-N tabs and
just a small number of spaces
The second "column" in the output of `git ls-remote` is typeset
differently by AsciiDoc and Asciidoctor, similar to various examples
touched by the last few commits.
Fix this by marking the example shell session as a code listing by
wrapping it in "". Because this gives us some extra indentat
The indented lines in the example shell script listing are indented
differently by AsciiDoc and Asciidoctor.
Fix this by marking the example shell script as a code listing by
wrapping it in "". Because this gives us some extra indentation, we
can remove the one that we have been carrying expl
The documentation for each of these options contains a list. After the
list, AsciiDoc interprets the continuation as a continuation of the
*list*, not as a continution of the larger block. As a result, we get
too much indentation. Wrap the entire blocks in "--" to fix this. With
Asciidoctor, this c
This series roughly halves the line count of `./doc-diff --from-asciidoc
--to-asciidoctor --cut-header-footer HEAD HEAD`. Together with my recent
(independent) mini-series [1], I claim that Asciidoctor 1.5.5 now
processes the manpages better than AsciiDoc 8.6.10 does.
Patch 6/7 actually changes th
On Sat, 7 Sep 2019 at 08:45, Jeff King wrote:
>
> On Thu, Sep 05, 2019 at 09:35:10PM +0200, Martin Ågren wrote:
>
> > > Yeah, I do still like that as an endgame, but I like what you have here
> > > as an intermediate step in the right direction.
> >
> > Hmm, so this sounds like once I am happy wit
rebase am already has this flag to "lie" about the author date
by changing it to the committer (current) date. Let's add the same
for interactive machinery.
Signed-off-by: Rohit Ashiwal
---
Documentation/git-rebase.txt| 6 +--
builtin/rebase.c| 18 ++---
The purpose of amend_author was to free() the malloc()'d string
obtained from get_author() while amending a commit. But we can
also use the variable to free() the author at our convenience.
Rename it to convey this meaning.
Signed-off-by: Rohit Ashiwal
---
sequencer.c | 6 +++---
1 file changed,
The previous commit introduced --ignore-date flag to interactive
rebase, but the name is actually very vague in context of rebase -i
since there are two dates we can work with. Add an alias to convey
the precise purpose.
Signed-off-by: Rohit Ashiwal
---
Documentation/git-rebase.txt | 1 +
builti
There are two backends available for rebasing, viz, the am and the
interactive. Naturally, there shall be some features that are
implemented in one but not in the other. One such flag is
--ignore-whitespace which indicates merge mechanism to treat lines
with only whitespace changes as unchanged. Wi
Following the suggestion of Phillip I've rebased my patch on master (745f681289)
and cherry-picking b0a3186140.
Base: 745f6812895b31c02b29bdfe4ae8e5498f776c26
with cherry-picked b0a3186140dbc7bd64cbc6ef733386a0f1eb6a4d
Outline:
2/6:
- Change commit message and description
3/6:
The current callers of the read_author_script() function read name,
email and date from the author script. Allow callers to signal that
they are not interested in some among these three fields by passing
NULL.
Note that fields that are ignored still must exist and be formatted
correctly in the au
rebase am already has this flag to "lie" about the committer date
by changing it to the author date. Let's add the same for
interactive machinery.
Signed-off-by: Rohit Ashiwal
---
Documentation/git-rebase.txt| 10 ++--
builtin/rebase.c| 17 +--
sequencer.c
On Sat, Sep 07, 2019 at 01:01:33AM -0400, Jeff King wrote:
> From: SZEDER Gábor
>
> Commit 49bbc57a57 (commit-graph write: emit a percentage for all
> progress, 2019-01-19) was a bit overeager when it added progress
> percentages to the "Expanding reachable commits in commit graph" phase
> as wel
On Fri, Sep 06, 2019 at 03:13:01PM -0400, Jeff King wrote:
> On Fri, Sep 06, 2019 at 02:13:26PM +0200, SZEDER Gábor wrote:
>
> > Once upon a time GIT_TEST_HTTPD was a tristate variable and we
> > exported 'GIT_TEST_HTTPD=YesPlease' in our CI scripts to make sure
> > that we run the httpd tests in
On Fri, Sep 6, 2019 at 11:40 PM Jeff King wrote:
>
> I just wrote a response to Emily, but I think a lot of it applies to
> you, as well.
With the exception of course that Emily can definitely write better
code than my attempted hacks
> In particular, I think both of you are a bit newer to the p
36 matches
Mail list logo
