On Tue, Oct 11, 2016 at 11:12 PM, Junio C Hamano wrote:
> Stefan Beller writes:
>
>> I think this patch is the most interesting patch, so I'll refrain from
>> resending the other 27 patches, though I have adressed the review comments
>> locally. I'll resend everything once we are in agreement for
On Tue, Oct 11, 2016 at 6:52 PM, Jeff King wrote:
> On Tue, Oct 11, 2016 at 09:34:28PM -0400, Jeff King wrote:
>
>> > Ok, time to present data... Let's assume a degenerate case first:
>> > "up-to-date with all remotes" because that is easy to reproduce.
>> >
>> > I have 14 remotes currently:
>> >
Jonathan Tan writes:
> Currently, interpret-trailers requires that a trailer be only on 1 line.
> For example:
>
> a: first line
> second line
>
> would be interpreted as one trailer line followed by one non-trailer line.
>
> Make interpret-trailers support RFC 822-style folding, treating
Stefan Beller writes:
> I think this patch is the most interesting patch, so I'll refrain from
> resending the other 27 patches, though I have adressed the review comments
> locally. I'll resend everything once we are in agreement for this one.
What is the primary purpose of this patch? Is it t
Jeremy Huddleston Sequoia writes:
>> diff --git a/t/t3700-add.sh b/t/t3700-add.sh
>> index 924a266126..53c0cb6dea 100755
>> --- a/t/t3700-add.sh
>> +++ b/t/t3700-add.sh
>> @@ -350,6 +350,7 @@ test_expect_success POSIXPERM,SYMLINKS 'git add
>> --chmod=+x with symlinks' '
>> '
>>
>> test_expect_s
On 10/11/2016 11:18 AM, Matthieu Moy wrote:
Larry Finger writes:
That added information at the end is intended to be passed on to the
stable group. In this case, the patch needs to be applied to kernel
versions 4.8 and later.
OK, but where do people fetch this information from?
This format
On Tue, Oct 11, 2016 at 09:34:28PM -0400, Jeff King wrote:
> > Ok, time to present data... Let's assume a degenerate case first:
> > "up-to-date with all remotes" because that is easy to reproduce.
> >
> > I have 14 remotes currently:
> >
> > $ time git fetch --all
> > real 0m18.016s
> > user 0m
Improve type safety by making arguments (whether from configuration or
from the command line) have their own "struct arg_item" type, separate
from the "struct trailer_item" type used to represent the trailers in
the buffer being manipulated.
Also take the opportunity to refine the "struct trailer_
On Tue, Oct 11, 2016 at 04:18:15PM -0700, Stefan Beller wrote:
> >> At the very least we would need a similar thing as Jeff recently sent for
> >> the
> >> push case with objects quarantined and then made available in one go?
> >
> > I don't think so. The object database is perfectly happy with m
Currently, creation and addition (to a list) of trailer items are spread
across multiple functions. Streamline this by only having 2 functions:
one to parse the user-supplied string, and one to add the parsed
information to a list.
---
trailer.c | 135 +-
Currently, interpret-trailers requires all lines of a trailer block to
be trailers (or comments) - if not it would not identify that block as a
trailer block, and thus create its own trailer block, inserting a blank
line. For example:
echo -e "\na: b\nnot trailer" |
git interpret-trailers --t
Use singly-linked lists (instead of doubly-linked lists) in trailer to
keep track of arguments (whether implicit from configuration or explicit
from the command line) and trailer items.
This change significantly reduces the code length and simplifies the code.
There are now fewer pointers to be ma
In [1], Junio explained a possible redesign of trailer support in
interpret-trailers and cherry-pick, something along these lines:
1. Support non-trailers and multi-line trailers in interpret-trailers
2. Create a helper function so that the new interpretation can be used
elsewhere (e.g. in s
Currently, interpret-trailers requires that a trailer be only on 1 line.
For example:
a: first line
second line
would be interpreted as one trailer line followed by one non-trailer line.
Make interpret-trailers support RFC 822-style folding, treating those
lines as one logical trailer.
--
Signed-off-by: Ramsay Jones
---
Hi Johannes,
If you need to re-roll your 'js/prepare-sequencer' branch, could you
please squash this into commit 53f8024e ("sequencer: completely revamp
the "todo" script parsing", 10-10-2016).
Thanks.
ATB,
Ramsay Jones
sequencer.c | 2 +-
1 file changed, 1 i
This revamps the API of the attr subsystem to be thread safe.
Before we had the question and its results in one struct type.
The typical usage of the API was
static struct git_attr_check check;
if (!check)
check = git_attr_check_initl("text", NULL);
git_check_attr(path, check
Signed-off-by: Ramsay Jones
---
Hi Lars,
If you need to re-roll your 'ls/filter-process' branch, could you
please squash this into commit 85290197
("convert: add filter..process option", 08-10-2016).
Thanks.
ATB,
Ramsay Jones
convert.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
> On Oct 10, 2016, at 10:41, Junio C Hamano wrote:
>
> Jeremy Huddleston Sequoia writes:
>
>> Actually, looks like that as just a rabbit hole. The real issue
>> looks to be because an earlier test drops down xfoo3 as a symlink,
>> which causes this test to fail due to the collision. I'll get
On Tue, Oct 11, 2016 at 3:59 PM, Jeff King wrote:
> On Tue, Oct 11, 2016 at 03:50:36PM -0700, Stefan Beller wrote:
>
>> I agree. Though even for implementing the "dumb" case of fetching
>> objects twice we'd have to take care of some racing issues, I would assume.
>>
>> Why did you put a "sleep 2"
On Wed, Oct 12, 2016 at 12:59 AM, Jeff King wrote:
> I'm not altogether convinced that parallel fetch would be that much
> faster, though.
I have local aliases to use GNU parallel for stuff like this, on my
git.git which has accumulated 17 remotes:
$ time parallel -j1 'git fetch {}' ::: $(g
On Tue, Oct 11, 2016 at 03:50:36PM -0700, Stefan Beller wrote:
> I agree. Though even for implementing the "dumb" case of fetching
> objects twice we'd have to take care of some racing issues, I would assume.
>
> Why did you put a "sleep 2" below?
> * a slow start to better spread load locally? (
> I dunno, if documented though.
http://stackoverflow.com/questions/26373995/how-to-control-the-order-of-fetching-when-fetching-all-remotes-by-git-fetch-al
We do not give promises about the order of --all (checked with our
documentation as well), however there seems to be a
grouping scheme for re
Stefan Beller writes:
> Why did you put a "sleep 2" below?
The assumption was to fetch from faster and near the center of the
project universe early, so by giving them head-start, fetches that
start in later rounds may have chance to see newly updated remote
tracking refs when telling the poorer
On Tue, Oct 11, 2016 at 3:37 PM, Junio C Hamano wrote:
> Stefan Beller writes:
>
>> So I do think it would be much faster, but I also think patches for this
>> would
>> require some thought and a lot of refactoring of the fetch code.
>> ...
>> During the negotiation phase a client would have to
Stefan Beller writes:
> So I do think it would be much faster, but I also think patches for this would
> require some thought and a lot of refactoring of the fetch code.
> ...
> During the negotiation phase a client would have to be able to change its
> mind (add more "haves", or in case of the p
> On 09 Oct 2016, at 01:06, Jakub Narębski wrote:
>
> Part 1 of review, starting with the protocol v2 itself.
>
> W dniu 08.10.2016 o 13:25, larsxschnei...@gmail.com pisze:
>> From: Lars Schneider
>>
>> +upon checkin. By default these commands process only a single
>> +blob and terminate. If
> On 09 Oct 2016, at 07:32, Torsten Bögershausen wrote:
>
> On 09.10.16 01:06, Jakub Narębski wrote:
>>> +
+packet: git< status=abort
+packet: git<
+
+
+After the filter has processed a blob it is exp
On Tue, Oct 11, 2016 at 10:37 AM, Brandon Williams wrote:
> On 10/10, Stefan Beller wrote:
>> It's not used outside the attr code, so let's keep it private.
>>
>> Change-Id: I0d15e0f2ea944b31d68b9cf1a4edecac0ca2170d
>
> Looks like you forgot to remove this :)
will be fixed in a reroll.
thanks!
>
Stefan Beller writes:
> On Tue, Oct 11, 2016 at 2:06 PM, Junio C Hamano wrote:
>>
>> * sb/submodule-ignore-trailing-slash (2016-10-10) 2 commits
>> (merged to 'next' on 2016-10-11 at e37425ed17)
>> + submodule: ignore trailing slash in relative url
>> + submodule: ignore trailing slash on su
Jeff King writes:
> Anyway, the existence of this discussion is probably a good argument in
> favor of Dscho's patch. I was mostly curious how close our plumbing
> tools could come.
Sure, in 100% agreement.
On Tue, Oct 11, 2016 at 02:36:31PM -0700, Junio C Hamano wrote:
> > True. I'd have done something more like:
> >
> > git ls-tree -r $paths | git update-index --index-info
> >
> > but there are some corner cases around deleting paths from the index.
>
> Ah, I would think read-tree has the exact
On Tue, Oct 11, 2016 at 2:39 PM, Stefan Beller wrote:
> On Tue, Oct 11, 2016 at 2:06 PM, Junio C Hamano wrote:
>>
>> * sb/submodule-ignore-trailing-slash (2016-10-10) 2 commits
>> (merged to 'next' on 2016-10-11 at e37425ed17)
>> + submodule: ignore trailing slash in relative url
>> + submodu
On Tue, Oct 11, 2016 at 2:06 PM, Junio C Hamano wrote:
>
> * sb/submodule-ignore-trailing-slash (2016-10-10) 2 commits
> (merged to 'next' on 2016-10-11 at e37425ed17)
> + submodule: ignore trailing slash in relative url
> + submodule: ignore trailing slash on superproject URL
>
> A minor reg
Jeff King writes:
>> If read-tree had pathspec support (i.e. "read these and only these
>> paths given from the command line into the index from a given
>> tree-ish"), that would have been the most natural place to extend
>> with "oh, by the way, instead of the command line, you can feed the
>> p
On Tue, Oct 11, 2016 at 12:27:21PM -0700, Junio C Hamano wrote:
> Jeff King writes:
>
> > Is git-reset the right layer to add scripting features? I thought we
> > usually pushed people doing mass index manipulation to use update-index
> > or read-tree. Is there something that reset makes easy th
Jeff King writes:
> Like a lot of old commit-traversal code, this keeps a
> commit_list in commit-date order, and and inserts parents
> into the list. This means each insertion is potentially
> linear, and the whole thing is quadratic (though the exact
> runtime depends on the relationship betwee
On Tue, Oct 11, 2016 at 12:07 PM, Joshua N Pritikin wrote:
> As of GIT 2.8.1, if you do an interactive rebase and get some conflict
> in the stack of patches then the commit with the conflict is buried in
> 4-5 lines of output. It is visually difficult to immediately pick out
> which commit did no
Like a lot of old commit-traversal code, this keeps a
commit_list in commit-date order, and and inserts parents
into the list. This means each insertion is potentially
linear, and the whole thing is quadratic (though the exact
runtime depends on the relationship between the commit dates
and the par
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.
A handful of topics have been merg
W dniu 11.10.2016 o 18:09, Johannes Schindelin pisze:
> SYNOPSIS
>
> [verse]
> -'git reset' [-q] [] [--] ...
> +'git reset' [-q] [--stdin [-z]] [] [--] ...
I think you meant here
+'git reset' [-q] [--stdin [-z]] []
Because you say "*Instead*" below.
> +--stdin::
> + Instead o
On Tue, Oct 11, 2016 at 12:07 PM, Joshua N Pritikin wrote:
> I assume somebody familiar with GIT's code base could make this change
> in about 10 minutes.
Can you elaborate how you come to that estimate?
On Tue, Oct 11, 2016 at 1:12 PM, Ram Rachum wrote:
> Hi everyone!
>
> I have a repo that has a bunch of different remotes, and I noticed
> slowness when doing `git fetch --all`. Is it currently made
> sequentially? Do you think that maybe it could be done in parallel so
> it could be much faster?
On Tue, 2016-10-11 at 13:13 -0700, Junio C Hamano wrote:
> Dennis Kaarsemaker writes:
>
> > On Tue, 2016-10-11 at 22:48 +0300, Mantas Mikulėnas wrote:
> > > On 2016-10-11 22:36, Junio C Hamano wrote:
> > > > Thanks for a review. I'll wait until one of (1) a squashable patch
> > > > to address th
Junio C Hamano writes:
> Dennis Kaarsemaker writes:
>
>> On Tue, 2016-10-11 at 22:48 +0300, Mantas Mikulėnas wrote:
>>> On 2016-10-11 22:36, Junio C Hamano wrote:
>>> > Thanks for a review. I'll wait until one of (1) a squashable patch
>>> > to address the "we do not want unconditional overwrit
Dennis Kaarsemaker writes:
> On Tue, 2016-10-11 at 22:48 +0300, Mantas Mikulėnas wrote:
>> On 2016-10-11 22:36, Junio C Hamano wrote:
>> > Thanks for a review. I'll wait until one of (1) a squashable patch
>> > to address the "we do not want unconditional overwrite" issue, (2) a
>> > reroll from
Hi everyone!
I have a repo that has a bunch of different remotes, and I noticed
slowness when doing `git fetch --all`. Is it currently made
sequentially? Do you think that maybe it could be done in parallel so
it could be much faster?
Thanks,
Ram.
On Tue, 2016-10-11 at 22:48 +0300, Mantas Mikulėnas wrote:
> On 2016-10-11 22:36, Junio C Hamano wrote:
> > Thanks for a review. I'll wait until one of (1) a squashable patch
> > to address the "we do not want unconditional overwrite" issue, (2) a
> > reroll from Mantas to do the same, or (3) a co
Junio C Hamano wrote:
> Jeremy Huddleston Sequoia writes:
>
> > CC: Josh Triplett
> > CC: Junio C Hamano
>
> Please don't do this in your log message. These belong to your
> e-mail headers, not here.
Fwiw, I prefer having these trailers. It makes it easier to
maintain the Cc: list through
On 2016-10-11 22:48, Mantas Mikulėnas wrote:
> On 2016-10-11 22:36, Junio C Hamano wrote:
>> Thanks for a review. I'll wait until one of (1) a squashable patch
>> to address the "we do not want unconditional overwrite" issue, (2) a
>> reroll from Mantas to do the same, or (3) a counter-argument fr
On 2016-10-11 22:36, Junio C Hamano wrote:
> Thanks for a review. I'll wait until one of (1) a squashable patch
> to address the "we do not want unconditional overwrite" issue, (2) a
> reroll from Mantas to do the same, or (3) a counter-argument from
> somebody to explain why unconditional overwri
Stefan Beller writes:
>> You can have many different callsites (think: hits "git grep" finds)
>> that call git_attr_check_initl() and they all may be asking for
>> different set of attributes. As long as they are using different
>> "check" instance to receive these sets of attributes, they are O
Jeff King writes:
> Is git-reset the right layer to add scripting features? I thought we
> usually pushed people doing mass index manipulation to use update-index
> or read-tree. Is there something that reset makes easy that is hard with
> those tools (I could imagine "--hard", but I see it is no
Dennis Kaarsemaker writes:
> On Sun, 2016-10-09 at 15:34 +0300, Mantas Mikulėnas wrote:
>
>> +s = g_hash_table_lookup(attributes, "user");
>> +if (s) {
>> +g_free(c->username);
>> +c->username = g_strdup(s);
>> +}
>
> Thi
As of GIT 2.8.1, if you do an interactive rebase and get some conflict
in the stack of patches then the commit with the conflict is buried in
4-5 lines of output. It is visually difficult to immediately pick out
which commit did not apply cleanly. I suggest highlighting the 1 line
commit summar
Johannes Schindelin writes:
> The `git-rebase-todo` file contains a list of commands. Most of those
> commands have the form
>
>
>
> The is displayed primarily for the user's convenience, as
> rebase -i really interprets only the part. However, there
> are *some* places in interactive
> @@ -370,19 +383,79 @@ static int is_index_unchanged(void)
> }
>
> /*
> + * Read the author-script file into an environment block, ready for use in
> + * run_command(), that can be free()d afterwards.
> + */
> +static char **read_author_script(void)
> +{
> + struct strbuf script = STRBUF_I
On Tue, Oct 11, 2016 at 12:07:40PM -0700, Linus Torvalds wrote:
> On Tue, Oct 11, 2016 at 12:01 PM, Jeff King wrote:
> >
> > My implementation is a little more complicated because it's also setting
> > things up for grouping by trailers (so you can group by "signed-off-by",
> > for example). I do
On Tue, Oct 11, 2016 at 12:01 PM, Jeff King wrote:
>
> My implementation is a little more complicated because it's also setting
> things up for grouping by trailers (so you can group by "signed-off-by",
> for example). I don't know if that's useful to your or not.
Hmm. Maybe in theory. But probab
On Tue, Oct 11, 2016 at 06:08:56PM +0200, Johannes Schindelin wrote:
> This feature was missing, and made it cumbersome for third-party
> tools to reset a lot of paths in one go.
>
> Support for --stdin has been added, following builtin/checkout-index.c's
> example.
Is git-reset the right layer
On Tue, Oct 11, 2016 at 11:45:58AM -0700, Linus Torvalds wrote:
> In some situations you may want to group the commits not by author,
> but by committer instead.
>
> For example, when I just wanted to look up what I'm still missing from
> linux-next in the current merge window, I don't care so mu
Johannes Schindelin writes:
> It is not unheard of that editors on Windows write CR/LF even if the
> file originally had only LF. This is particularly awkward for exec lines
> of a rebase -i todo sheet. Take for example the insn "exec echo": The
> shell script parser splits at the LF and leaves t
On Tue, Oct 11, 2016 at 11:23 AM, Junio C Hamano wrote:
> Stefan Beller writes:
>
>>> I find this description a bit confusing. At least the way I
>>> envisioned was that when this piece of code is run by multiple
>>> people at the same time,
>>>
>>> static struct git_attr_check *check =
On 10/11, Stefan Beller wrote:
> On Tue, Oct 11, 2016 at 11:40 AM, Brandon Williams wrote:
>
> > Wouldn't a +1 indicate that the attr name is valid while the 0
> > indicates that it is invalid?
>
> Right.
>
> > It looks to me like we are checking each
> > character and if we run into one that
On 10/11, Stefan Beller wrote:
> On Tue, Oct 11, 2016 at 10:28 AM, Brandon Williams wrote:
> > On 10/10, Stefan Beller wrote:
> >> From: Junio C Hamano
> >> -static int invalid_attr_name(const char *name, int namelen)
> >> +int attr_name_valid(const char *name, size_t namelen)
> >> {
> >>
In some situations you may want to group the commits not by author,
but by committer instead.
For example, when I just wanted to look up what I'm still missing from
linux-next in the current merge window, I don't care so much about who
wrote a patch, as what git tree it came from, which generally
On Tue, Oct 11, 2016 at 11:40 AM, Brandon Williams wrote:
> Wouldn't a +1 indicate that the attr name is valid while the 0
> indicates that it is invalid?
Right.
> It looks to me like we are checking each
> character and if we run into one that doesn't work then we have an error
> and return 0
On Tue, Oct 11, 2016 at 10:28 AM, Brandon Williams wrote:
> On 10/10, Stefan Beller wrote:
>> From: Junio C Hamano
>> -static int invalid_attr_name(const char *name, int namelen)
>> +int attr_name_valid(const char *name, size_t namelen)
>> {
>> /*
>>* Attribute name cannot begin wi
On 10/10, Stefan Beller wrote:
> From: Junio C Hamano
> -static int invalid_attr_name(const char *name, int namelen)
> +int attr_name_valid(const char *name, size_t namelen)
> {
> /*
>* Attribute name cannot begin with '-' and must consist of
>* characters from [-A-Za-z0-9_.
Stefan Beller writes:
>> I find this description a bit confusing. At least the way I
>> envisioned was that when this piece of code is run by multiple
>> people at the same time,
>>
>> static struct git_attr_check *check = NULL;
>> git_attr_check_initl(&check, ...);
>>
>> we won'
Stefan Beller writes:
> This revamps the API of the attr subsystem to be thread safe.
> Before we had the question and its results in one struct type.
> The typical usage of the API was
>
> static struct git_attr_check;
I think you meant "*check" at the end, perhaps?
>
> if (!check)
>
On Tue, Oct 11, 2016 at 10:40 AM, Junio C Hamano wrote:
> Stefan Beller writes:
>
>> This revamps the API of the attr subsystem to be thread safe.
>> Before we had the question and its results in one struct type.
>> The typical usage of the API was
>>
>> static struct git_attr_check;
>
> I th
Johannes Schindelin writes:
> + if (read_from_stdin) {
> + strbuf_getline_fn getline_fn = nul_term_line ?
> + strbuf_getline_nul : strbuf_getline_lf;
> + int flags = PATHSPEC_PREFER_FULL |
> + PATHSPEC_STRIP_SUBMODULE_SLASH_CHEAP
On 10/10, Stefan Beller wrote:
> be initalized once as that part will be read only after its
initialized
> initialisation, the answer may be different for each path.
should this be the US spelling 'initialization'?
--
Brandon Williams
Hi,
I noticed there were no replies for this thread. I was curious if it got
buried because I sent it on the Friday evening before a long weekend.
I don't mean to pressure or anything.
Thanks!
-Santiago.
On Fri, Oct 07, 2016 at 05:07:14PM -0400, santi...@nyu.edu wrote:
> From: Santiago Torres
Brandon Williams writes:
> On 10/10, Stefan Beller wrote:
>> From: Junio C Hamano
>>
>> A common pattern to check N attributes for many paths is to
>>
>> (1) prepare an array A of N git_attr_check_elem items;
>> (2) call git_attr() to intern the N attribute names and fill A;
>
> Does the wor
On 10/10, Stefan Beller wrote:
> It's not used outside the attr code, so let's keep it private.
>
> Change-Id: I0d15e0f2ea944b31d68b9cf1a4edecac0ca2170d
Looks like you forgot to remove this :)
--
Brandon Williams
Johannes Schindelin writes:
> In the end, I decided to actually *not* use strbuf_add_unique_abbrev()
> here because it really makes the code very much too ugly after the
> introduction of short_commit_name():
It's perfectly fine not to use that function when it does not make
sense; we shouldn't
On 10/10, Stefan Beller wrote:
> From: Junio C Hamano
>
> A common pattern to check N attributes for many paths is to
>
> (1) prepare an array A of N git_attr_check_elem items;
> (2) call git_attr() to intern the N attribute names and fill A;
Does the word 'intern' here mean internalize? It
David Aguilar writes:
>> I only see 4/4 in v4; am I correct to assume that 1-3/4 of v4 are
>> the same as their counterparts in v3?
>
> Yes, 1-3 are unchanged since v3.
> Thanks for checking,
I'll queue these four with Reviewed-by's from j6t.
Thanks, both.
Signed-off-by: Satoshi Yasushima
---
po/ja.po | 9 +
1 file changed, 5 insertions(+), 4 deletions(-)
diff --git a/po/ja.po b/po/ja.po
index f143753..510306b 100644
--- a/po/ja.po
+++ b/po/ja.po
@@ -2,16 +2,17 @@
# Copyright (C) 2005-2015 Paul Mackerras
# This file is distributed under
Johannes Schindelin writes:
>> I am personally fine with this line; two things come to mind:
>>
>> - This would work just fine as-is with Linus's change to turn
>>DEFAULT_ABBREV to -1.
>>
>> - It appears that it is more fashionable to use
>>strbuf_add_unique_abbrev() these days.
>
> R
On Mon, Oct 10, 2016 at 12:14:14PM -0700, Junio C Hamano wrote:
> Jeff King writes:
>
> > On Mon, Oct 10, 2016 at 11:24:01AM -0700, Junio C Hamano wrote:
> >
> >> I no longer have preference either way myself, even though I was in
> >> favor of no-quotes simply because I had an alias to produce t
Hi,
On Fri, Oct 07, 2016 at 10:25:04AM -0700, Stefan Beller wrote:
> On Fri, Oct 7, 2016 at 5:52 AM, Heiko Voigt wrote:
> > On Thu, Oct 06, 2016 at 01:11:20PM -0700, Junio C Hamano wrote:
> >> Stefan Beller writes:
> >>
> >> > Currently the force flag in `git submodule add` takes care of possibl
Junio C Hamano writes:
> This certainly is good, but I wonder if a new variant of OPT_STRING
> and OPTION_STRING that does the strdup for you, something along the
> lines of ...
> ... may make it even more pleasant to use? Only for two fields in
> this patch that may probably be an overkill, but
Larry Finger writes:
> That added information at the end is intended to be passed on to the
> stable group. In this case, the patch needs to be applied to kernel
> versions 4.8 and later.
OK, but where do people fetch this information from?
When you use git send-email, the content of the Cc: tr
Just like with other Git commands, this option makes it read the paths
from the standard input. It comes in handy when resetting many, many
paths at once and wildcards are not an option (e.g. when the paths are
generated by a tool).
Note: to keep things simple, we first parse the entire list and p
This feature was missing, and made it cumbersome for third-party
tools to reset a lot of paths in one go.
Support for --stdin has been added, following builtin/checkout-index.c's
example.
Johannes Schindelin (2):
reset: fix usage
reset: support the --stdin option
Documentation/git-reset.tx
The parameter is actually optional (see man page).
Signed-off-by: Johannes Schindelin
---
builtin/reset.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/builtin/reset.c b/builtin/reset.c
index 5aa8607..c04ac07 100644
--- a/builtin/reset.c
+++ b/builtin/reset.c
@@ -24,7 +24,
On Tue, Oct 11, 2016 at 09:39:58AM +0200, Matthieu Moy wrote:
> >> I can't reproduce the problem with this simple setup:
> >>
> >>git init
> >>echo content >file && git add file
> >>git commit -F- <<-\EOF
> >>the subject
> >>
> >>the body
> >>
> >>Cc: Stable [4.8+]
>
>
W dniu 10.10.2016 o 19:52, Paul Smith pisze:
> On Mon, 2016-10-10 at 10:19 +, Eduard Egorov wrote:
>> # ~/gitbuild/git-2.10.1/git merge -s subtree --squash ceph_ansible
>>
>> Can somebody confirm this please? Doesn't "merge -s subtree" really
>> merges branches?
>
> I think possibly you're not
On 10/11/2016 02:39 AM, Matthieu Moy wrote:
Jeff King writes:
[+cc authors of b1c8a11, which regressed this case; I'll quote liberally
to give context]
On Mon, Oct 10, 2016 at 05:48:56PM -0400, Jeff King wrote:
I can't reproduce the problem with this simple setup:
git init
On Mon, Oct 10, 2016 at 08:06:47AM -0500, Michael Tutty wrote:
>
> > If source repo's HEAD is "master", I got the same behavior (worktree add
> > fails)
>
> So if it's possible for a bare repo to have HEAD pointing at master,
> is there a safe way for me to change this (e.g., as a cleanup step
>
On Mon, 2016-10-10 at 16:46 -0400, Jeff King wrote:
> On Mon, Oct 10, 2016 at 10:20:50PM +0200, Dennis Kaarsemaker wrote:
>
> > On Sun, 2016-10-09 at 15:34 +0300, Mantas Mikulėnas wrote:
> > > This is based on the existing gnome-keyring helper, but instead of
> > > libgnome-keyring (which was spec
On Tue, Oct 11, 2016 at 11:44:50AM +0200, Johannes Schindelin wrote:
> > Yeah, that's reasonable, too. So:
> >
> > [alias]
> > d2u = "!dos2unix"
> >
> > acts exactly as if:
> >
> > [alias "d2u"]
> > command = dos2unix
> > type = shell
> >
> > was specified at that point, which
On Sun, 2016-10-09 at 15:34 +0300, Mantas Mikulėnas wrote:
> + s = g_hash_table_lookup(attributes, "user");
> + if (s) {
> + g_free(c->username);
> + c->username = g_strdup(s);
> + }
This always overwrites c->username, th
On Mon, Oct 10, 2016 at 7:19 PM, Jeff King wrote:
> On Mon, Oct 10, 2016 at 05:12:25PM +0100, Seaders Oloinsigh wrote:
>
>> Due to the structure of this repo, it looks like there are some
>> branches that never had anything to do with the android/ subdirectory,
>> so they're not getting wiped out.
W dniu 11.10.2016 o 13:51, SZEDER Gábor pisze:
> Quoting Duy Nguyen :
>> On Fri, Oct 7, 2016 at 10:55 PM, Jakub Narębski wrote:
>>> W dniu 07.10.2016 o 16:19, Johannes Schindelin pisze:
On Fri, 7 Oct 2016, Jakub Narębski wrote:
>>>
> Note that we would have to teach git completion about n
Hi Lars,
On Sat, 8 Oct 2016, larsxschnei...@gmail.com wrote:
> @@ -31,6 +32,15 @@ static void cleanup_children(int sig, int in_signal)
> while (children_to_clean) {
> struct child_to_clean *p = children_to_clean;
> children_to_clean = p->next;
> +
> +
Quoting Duy Nguyen :
On Fri, Oct 7, 2016 at 10:55 PM, Jakub Narębski wrote:
W dniu 07.10.2016 o 16:19, Johannes Schindelin pisze:
On Fri, 7 Oct 2016, Jakub Narębski wrote:
Note that we would have to teach git completion about new syntax;
or new configuration variable if we go that route.
Hi Duy,
On Tue, 11 Oct 2016, Duy Nguyen wrote:
> On Tue, Oct 11, 2016 at 4:44 PM, Johannes Schindelin
> wrote:
> >
> > On Sun, 9 Oct 2016, Jeff King wrote:
> >
> >> On Sun, Oct 09, 2016 at 06:32:38PM +0700, Duy Nguyen wrote:
> >>
> >> > > If you mean ambiguity between the old "alias.X" and the n
1 - 100 of 112 matches
Mail list logo