Create a function that, taking a string, describes the position of its
trailer block (if available) and the contents thereof, and make trailer
use it. This makes it easier for other Git components, in the future, to
interpret trailer blocks in the same way as trailer.
In a subsequent patch, anothe
Make sequencer use trailer.c's trailer layout definition, as opposed to
parsing the footer by itself. This makes "commit -s", "cherry-pick -x",
and "format-patch --signoff" consistent with trailer, allowing
non-trailer lines and multiple-line trailers in trailer blocks under
certain conditions, and
Matt McCutchen writes:
> Then the server generates a commit X3 that lists Y2 as a parent, even
> though it doesn't have Y2, and advances 'x' to X3. The victim fetches
> 'x':
>
>victim server
>
> Y1---Y2 (Y2)
> /
Jonathan Tan writes:
> This is built off jt/trailer-with-cruft (commit 60ef86a).
>
> This patch set makes "commit -s", "cherry-pick -x", and
> "format-patch --signoff" use the new trailer definition implemented in
> jt/trailer-with-cruft, with some refactoring along the way. With this
> patch set
Linus Torvalds writes:
> Apparently windows doesn't even support it, at least not mingw
Assuming that the above was a misunderstanding, assuming that we can
do O_CLOEXEC (but not FD_CLOEXEC) on Windows just fine, where stray
file descriptors held open in the children matter more, and ...
>
On Thu, Oct 27, 2016 at 11:13 PM, Junio C Hamano wrote:
>> git-gc just can't match this because while it's running, somebody else
>> may be updating $GIT_DIR/index. Handling races would be a lot harder.
>
> It could attempt to take a lock on the primary index while it runs,
> and refrain to do any
On Fri, 2016-10-28 at 18:11 -0700, Junio C Hamano wrote:
> Ah, I see. My immediate reaction is that you can do worse things in
> the reverse direction compared to this, but your scenario does sound
> bad already.
Are you saying that clients connecting to untrusted servers already
face worse risks
The latest maintenance release Git v2.10.2 is now available at
the usual places.
The tarballs are found at:
https://www.kernel.org/pub/software/scm/git/
The following public repositories all have a copy of the 'v2.10.2'
tag and the 'maint' branch that the tag points at:
url = https://kern
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.
Git v2.10.2, the second maintenanc
101 - 109 of 109 matches
Mail list logo
