Stefan Beller writes:
> Signed-off-by: Stefan Beller
> ---
> read-cache.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/read-cache.c b/read-cache.c
> index 89dbc08..a3df665 100644
> --- a/read-cache.c
> +++ b/read-cache.c
> @@ -1653,7 +1653,7 @@ int read_index_from(st
Jeff King writes:
> Yeah, my first instinct on seeing the bitfield was that it would
> probably be much simpler to keep the enum pure, and add a bit to the
> struct. A patch in that direction is below. ...
I found it a much cleaner approach from my cursory look. John, what
do you think?
--
To u
David Turner writes:
>> Christian, thanks for raising this one.
>>
>> I do recall the thread and I might be the somebody like Michael you
>> remember, e.g. $gmane/275105---which did mention that "git bisect"
>> would not need changing if we kept refs/bisect/.
>>
>> What was the reason why we ch
Torsten Bögershausen writes:
> On 2015-08-31 19.40, Junio C Hamano wrote:
>> larsxschnei...@gmail.com writes:
>
>>> +test_expect_success 'Create a repo containing cp1251 encoded paths' '
>>> + cd "$cli" &&
>>>
Stefan Beller writes:
>> I'll queue it for this time, but in general, I'd prefer if people
>> refrained from touching code only for style fixes in an area that is
>> touched actively in topics, unless it is done inside a topic that
>> has to touch that area of the code in order to do something mo
Stefan Beller writes:
> One of the mistakes I made last week was mixing these quite stable patches
> with highly RFC/WIP patches and not pointing out loud which is which.
I think it was very clear which is which to people who have been
following (which are the only people you would care about an
Stefan Beller writes:
> usage:
> - usage("git submodule--helper module_list\n");
> + usage("git submodule--helper [module_list | module_name]\n");
To me, the above reads as if saying:
The command takes one of the two subcommands at this stage,
module_list that does not take any
larsxschnei...@gmail.com writes:
> From: Lars Schneider
>
> Diff to v1:
> * switch example conversions from cp1252 to iso8859-1 (thanks Torsten!)
> * fix git-p4.txt line length and double dashes (thanks Junio!)
> * remove bare UTF-8 sequence (thanks Junio!)
>
> As with v1, I ensured the unit test
larsxschnei...@gmail.com writes:
> From: Lars Schneider
>
> Signed-off-by: Lars Schneider
> ---
> Documentation/git-p4.txt| 5 +
> git-p4.py | 6 ++
> t/t9821-git-p4-path-encoding.sh | 39 +++
> 3 files changed, 50 inse
larsxschnei...@gmail.com writes:
> From: Lars Schneider
>
Here is a space for you to describe what it does and why it is a
good idea to have it.
> Signed-off-by: Lars Schneider
> ---
> Documentation/git-p4.txt| 5 +
> git-p4.py | 6 ++
> t/t9821-git-p4-
Here are the topics that have been cooking. Commits prefixed with
'-' are only in 'pu' (proposed updates) while commits prefixed with
'+' are in 'next'.
A handful of topics have been merged to 'master'. Because there
still are a few obviously good and trivially safe fixes cooking in
'next', it w
erik elfström writes:
> On Mon, Aug 31, 2015 at 6:58 PM, Junio C Hamano wrote:
>>
>> ... It may have been
>> better if you didn't do "while we are here" and corrected only the
>> &&-chain in patch 1/2 and then updated the style of the tests t
David Turner writes:
> This version of the patch series squashes in Junio's comment fix and
> the xstrndup fix.
>
> In addition, it removes refs/worktree, and just makes refs/bisect
> per-worktree. If we later discover that other things need to be
> per-worktree, we can do refs/worktree, but for
(Administrivia) please do not cull CC list when replying.
Barry Warsaw writes:
> On Sep 01, 2015, at 02:28 AM, David Aguilar wrote:
>
>>While a script writer could write, "git -c core.cliversion=1 ...",
>>no one does that, no one wants to do that, and it just seems
>>like a bad idea that's best
Josh Rabinowitz writes:
> Change so 'git push --porcelain --quiet' emits no text when there
> is no error. This makes the --quiet option here more consistent with
> other git commands.
>
> Signed-off-by: josh rabinowitz
> ---
The rationale given in 77555854 (git-push: make git push --porcelain
Lars Schneider writes:
>> I'll move this to 9822, as 9821 is taken by another git-p4 test,
>> while queuing.
> OK. I wasn’t sure how this is handled. Just for my understanding: As
> soon as a TC number is occupied in one of the official branches
> (master/next/pu/maint) then the next number shoul
Lars Schneider writes:
> On 01 Sep 2015, at 01:13, Junio C Hamano wrote:
>
>> larsxschnei...@gmail.com writes:
>>
>>> From: Lars Schneider
>>>
>>
>> Here is a space for you to describe what it does and why it is a
>> good idea to have it
Ramsay Jones writes:
> Commit 04afda89 ("refs: clean up common_list", 26-08-2015) changed
> the type of the 'common_list' symbol from an array of 'formatted'
> strings to an array of struct containing the same data. However, in
> addition it also (inadvertently) changed the visibility of the
> sy
Juerg Haefliger writes:
> The quilt series file doesn't have to be located in the same directory
> with the patches and can be named differently than 'series' as well. This
> patch adds a commandline option to allow for a non-standard series
> filename and location.
>
> Signed-off-by: Juerg Haefl
Lars Schneider writes:
> I searched the Internet for clues around cp1252 and found that a
> similar patch was submitted to Mercurial just a month ago. The author
> seconds my cp1252 observation:
> http://mercurial.808500.n3.nabble.com/PATCH-stable-convert-use-original-local-encoding-when-converti
Eric Sunshine writes:
> On Tue, Sep 1, 2015 at 2:24 PM, Stefan Beller wrote:
>> This converts implements the helper `module_clone`. This functionality is
>
> Mentioned previously[1]: "converts implements"?
>
> [1]: http://article.gmane.org/gmane.comp.version-control.git/276966
Stefan, perhaps a
Stefan Beller writes:
> +static int module_list_compute(int argc, const char **argv,
> + const char *prefix,
> + struct pathspec *pathspec)
> +{
> + int i, result = 0;
> + char *max_prefix, *ps_matched = NULL;
> + int max_prefix_
Karthik Nayak writes:
> We have an `at_end` function for each element of the stack which is to
> be called when the `end` atom is encountered. Using this we implement
> the aling_handler() for the `align` atom, this aligns the final strbuf
align_handler().
> struct ref_formatting_stack {
>
Karthik Nayak writes:
> + if (!filter->kind)
> die("filter_refs: invalid type");
> + else {
> + if (filter->kind == FILTER_REFS_BRANCHES)
> + ret = for_each_fullref_in("refs/heads/",
> ref_filter_handler, &ref_cbdata, broken);
> +
Jeff King writes:
> It's not easy for arbitrary code to find out whether it is
> running in an async process or not. A top-level function
> which is fed to start_async() can know (you just pass down
> an argument saying "you are async"). But that function may
> call other global functions, and we
Jeff King writes:
> What we really need is thread-local storage for
> packet_trace_identity. But the async code does not provide
> an interface for that, and it would be messy to add it here
> (we'd have to care about pthreads, initializing our
> pthread_key_t ahead of time, etc).
True.
> So in
John Keeping writes:
> This is Jeff's original patch with my fixup for DATE_STRFTIME squashed
> in and a new change to reject "raw-local" (in both Documentation/ and
> date.c).
Even in --date=raw, we do show the timezone offset, so I do not
necessarily agree that raw-local is nonsensical. That'
Nicely done.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
OK by me. Thanks, I also forgot that need for preparatory code movement.
On Tue, Sep 1, 2015 at 3:39 PM, Jeff King wrote:
> On Tue, Sep 01, 2015 at 11:33:08PM +0100, John Keeping wrote:
>
>> > Even in --date=raw, we do show the timezone offset, so I do not
>> > necessarily agree that raw-local is
Karthik Nayak writes:
>>> + if (filter->kind == FILTER_REFS_BRANCHES)
>>> + ret = for_each_fullref_in("refs/heads/", ref_filter_handler,
>>> &ref_cbdata, broken);
>>> + else if (filter->kind == FILTER_REFS_REMOTES)
>>> + ret = for_each_fullref_in("refs/remotes/", ref_filte
Junio C Hamano writes:
> Stefan Beller writes:
>
>> +static int module_list_compute(int argc, const char **argv,
>> +const char *prefix,
>> +struct pathspec *pathspec)
>> +{
>> ...
Karthik Nayak writes:
>>> + die(_("format: `end` atom used without a supporting atom"));
>>
>> Not a show-stopper, but we may need some wordsmithing for "a
>> supporting atom" here; an end-user would not know what it is.
>
> Probably something like "format: `end` atom should only be
>
Karthik Nayak writes:
> + if (filter->lines)
> + format = to_free =
> xstrfmt("%%(align:15,left)%%(refname:short)%%(end) %%(contents:lines=%d)",
> +filter->lines);
I recall hearing that you were more in favor of
"%(align:16)%(refn
Jeff King writes:
> On Wed, Sep 02, 2015 at 08:48:26AM +0100, John Keeping wrote:
>
>> On Tue, Sep 01, 2015 at 06:44:31PM -0400, Jeff King wrote:
>> > [1] I do think the error message for "relative-local is nonsense" could
>> > perhaps be more explanatory, but I couldn't come up with any bett
Karthik Nayak writes:
> On Wed, Sep 2, 2015 at 8:31 PM, Junio C Hamano wrote:
>> Karthik Nayak writes:
>>
>>>>> + die(_("format: `end` atom used without a supporting atom"));
>>>>
>>>> Not a show-stopper, but we may
larsxschnei...@gmail.com writes:
> From: Lars Schneider
>
> Perforce keeps the encoding of a path as given by the originating OS.
> Git expects paths encoded as UTF-8. Add a config to tell git-p4 what
> encoding Perforce had used for the paths. This encoding is used to
> transcode the paths to UT
Matthieu Moy writes:
> I actually found the other more readable, as it reads "display the
> refname aligned on 15 columns, and then a space",
FWIW, I too find the "15-col followed by a space" easier to
understand. I was merely being curious when/why Karthik changed
preference, not objecting to
Matthieu Moy writes:
> Junio C Hamano writes:
>
>> Karthik Nayak writes:
>>
>>> On Wed, Sep 2, 2015 at 8:31 PM, Junio C Hamano wrote:
>>>> Karthik Nayak writes:
>>>>
>>>>>>> + die(_("format: `end` atom
John Keeping writes:
> diff --git a/Documentation/rev-list-options.txt
> b/Documentation/rev-list-options.txt
> index a9b808f..5d28133 100644
> --- a/Documentation/rev-list-options.txt
> +++ b/Documentation/rev-list-options.txt
> @@ -702,12 +702,16 @@ include::pretty-options.txt[]
> --date=(rel
Jeff King writes:
> + /* historical alias */
> + if (!strcmp(format, "local"))
> + format = "default-local";
> +
> + mode->type = parse_date_type(format, &p);
> + mode->local = 0;
> +
> + if (skip_prefix(p, "-local", &p)) {
> + if (mode->type == DATE_RE
Matthieu Moy writes:
> I consider this GSoC as a great success and a pleasant experience.
> Congratulation to Paul and Karthik, and a warm "thank you" to everybody
> who contributed: administrators, mentors, reviewers, and obviously
> Junio! (not to mention Google, who made all this possible)
>
>
Matthieu Prat writes:
> A test was designed for "git diff-index --cached -M" but the command is
> run without the "-M" option (which makes the test essentially identical
> to its preceding counterpart).
Very true and it seems that it has been that way from the day these
trio of tests were introd
Jeff King writes:
> There's a bug in builtin/am.c in which we take a lock on
> MERGE_RR recursively. But rather than fix am.c, this patch
> fixes the confusing interface from rerere.c that caused the
> bug. Read on for the gory details.
>
> The setup_rerere() function both reads the existing MERG
John Keeping writes:
> On Wed, Sep 02, 2015 at 08:16:59AM -0700, Junio C Hamano wrote:
>> Jeff King writes:
>>
>> > I guess "relative dates do not depend on timezones, so -local is
>> > meaningless" would be the closest thing.
>
> The discussion
John Keeping writes:
> In which case, should we just support it now?
>
> Normally I'd suggest banning controversial options on the basis that
> it's easier in the future to allow something that was previously banned
> than change the meaning of an options, but in this case I can't see any
> other
, Clemens Buchacher, Dave Borowitz, David
Aguilar, David Turner, Elia Pinto, Eric Sunshine, Heiko
Voigt, Ilya Bobyr, Jacob Keller, Jeff King, Jiang Xin, Jim
Hill, Johannes Schindelin, Johannes Sixt, Junio C Hamano,
Karsten Blees, Karthik Nayak, Kevin Daudt, Matthieu Moy,
Michael Haggerty, Mike
Atul Sowani writes:
> Hello!
>
> Any help/pointers/advise regarding my request about dockerfile?
[jc: "Gawade P" Cc'ed.]
Perhaps you can learn to ask the list archive ;-)
Going to http://news.gmane.org/gmane.comp.version-control.git/
and then asking for "dockerfile" in the search box at the bo
John Keeping writes:
> On Wed, Sep 02, 2015 at 05:30:14PM -0400, Jeff King wrote:
>> I think the error message would be a lot nicer if we indicate that "-"
>> is syntactically interesting, and say:
>>
>> fatal: unknown date-mode modifier: locale
>
> I wonder if we'd be better just saying:
>
>
Eric Sunshine writes:
> On Tue, Sep 1, 2015 at 2:26 PM, Karthik Nayak wrote:
>> Implement an `align` atom which left-, middle-, or right-aligns the
>> content between %(align:..) and %(end).
>
> Spell this either %(align:) or %(align:...) with three dots, not two.
> I, personally, think %(align:
Eric Sunshine writes:
> Also, if 'buf' is indeed unconditionally NUL-terminated, then the (sp
> <= buf + size) check is wasted code since the result of strstr() will
> always be either NULL or pointing somewhere within the NUL-terminated
> string.
A caller can give a buf that is NUL terminated b
Kirill Likhodedov writes:
> Is it intended behavior that the default git log output (without
> ordering parameters) can show parents before children?
>
> The man says:
> Commit Ordering
>By default, the commits are shown in reverse chronological order.
> so it tells nothing about pare
Lars Schneider writes:
> On 03 Sep 2015, at 15:04, Eric Sunshine wrote:
>
>> On Thu, Sep 3, 2015 at 5:34 AM, wrote:
>>> From: Lars Schneider
>>>
>>> Signed-off-by: Lars Schneider
>>> ---
>>> diff --git a/t/t9821-git-p4-path-variations.sh
>>> b/t/t9821-git-p4-path-variations.sh
>>> index 81
larsxschnei...@gmail.com writes:
> +test_expect_success 'Clone repo containing iso8859-1 encoded paths without
> git-p4.pathEncoding' '
> + git p4 clone --destination="$git" //depot &&
> + test_when_finished cleanup_git &&
> + (
> + cd "$git" &&
> + UTF8="$(pri
Michael J Gruber writes:
>> Is the design of your independent implementation the same except
>> that 'o' is used instead of 'x'? Independent implementation does
>> not make the same design magically better, if that is the case ;-)
>
> Interestingly, the patch to the tests lists * to o changes on
Takashi Iwai writes:
> we've got a bug report of git-log stall in below:
> https://bugzilla.opensuse.org/show_bug.cgi?id=942297
>
> In short, git-log is left unterminated sometimes when pager is
> aborted. When this happens, git process can't be killed by SIGTERM,
> but only by SIGKILL. And,
Lars Schneider writes:
> On 03 Sep 2015, at 19:03, Junio C Hamano wrote:
>
>> I'm tempted to suggest squashing the following in. Thoughts?
>
> OK. The diff looks good to me. For some reason I can’t apply the
> patch though. git patch gives me "fatal: corrupt pa
Johannes Schindelin writes:
> I have a couple of fixes lined up for bugs in Git for Windows 2.5.1. Do
> you plan to release 2.5.2 any time soon? If yes, I would hold off,
> otherwise I will just do a Git for Windows 2.5.1 (Rel 2).
Among the topics marked for possible later merging to 'maint' in
Stefan Beller writes:
> diff --git a/builtin/submodule--helper.c b/builtin/submodule--helper.c
> new file mode 100644
> index 000..e97403e
> --- /dev/null
> +++ b/builtin/submodule--helper.c
> @@ -0,0 +1,124 @@
> +#include "builtin.h"
> +#include "cache.h"
> +#include "parse-options.h"
> +#in
ga...@freebsd.org writes:
> From: Renato Botelho
>
> git-submodule and git-request-pull are written in sh but use perl
> internally. Add them to be replaced by unimplemented.sh when NO_PERL
> flag is set
> ---
Missing sign-off.
You also may want to hold off the "git-submodule" bit, as I expect
Renato Botelho writes:
>> You also may want to hold off the "git-submodule" bit, as I expect
>> http://thread.gmane.org/gmane.comp.version-control.git/277128/focus=277129
>> would be one of the first changes to be in 'master' after the
>> upcoming release 2.6 (that is, it is likely that perl depe
ga...@freebsd.org writes:
> From: Renato Botelho
>
> git-submodule and git-request-pull are written in sh but use perl
> internally. Add them to be replaced by unimplemented.sh when NO_PERL
> flag is set
>
> Signed-off-by: Renato Botelho
> ---
> Makefile | 2 +-
> 1 file changed, 1 insertion(+)
Renato Botelho writes:
>> Not really. Anything brand-new that comes this late in the cycle
>> will not be in 2.6, so the earliest release this NO_PERL change can
>> appear in is one after the upcoming release.
>
> Even if it’s a bug that produce a broken installation?
Absolutely.
The way we do
Lars Schneider writes:
> On 03 Sep 2015, at 21:55, Luke Diamand wrote:
>
>> On 03/09/15 17:35, larsxschnei...@gmail.com wrote:
>>> From: Lars Schneider
>>>
>>
>> I think this commit may need some explanation!
>
> The functions “gitConfig” and “gitConfigBool” are almost
> identical. Make “gitC
Lars Schneider writes:
> In case I agree with a reviewer. What is the more appropriate action?
> A response like the one above or a new role that includes the change
> right away? I don’t want to spam the list with lots of tiny changes…
Responding to review comment like you did with "will do" is
Stefan Beller writes:
> @@ -119,6 +120,140 @@ static int module_name(int argc, const char **argv,
> const char *prefix)
>
> return 0;
> }
> +static int clone_submodule(const char *path, const char *gitdir, const char
> *url,
> +const char *depth, const char *ref
Jeff King writes:
> Frankly, this feels a bit like a step backwards to me. I am tempted to
> suggest instead that git start sending the newlines, but I'm not sure
> it's worth any potential fallout.
I actually think we should do both in the longer term.
If we say sender "SHOULD" and we know no
Jeff King writes:
> Since the discussion seemed to end up in this "let's make PKT-LINE more
> clear" direction, here is an attempt to do that.
Ah, I was confused while reading the other one ;-)
Will queue this one instead. Thanks.
> -- >8 --
> Subject: pack-protocol: clarify LF-handling in PK
John Keeping writes:
> We are about to add several new date formats which will make this list
> too long to display in a single line.
>
> Signed-off-by: John Keeping
> ---
> Documentation/git-rev-list.txt | 2 +-
> Documentation/rev-list-options.txt | 2 +-
> 2 files changed, 2 insertions(+
John Keeping writes:
> In a following commit we will make "local" orthogonal to the format.
> Although this will not apply to "relative", which does not use the
> timezone, it applies to all other formats so move the timezone
> conversion to the start of the function.
"local" is a request to sho
David Turner writes:
> @@ -2827,7 +2831,7 @@ int pack_refs(unsigned int flags)
> *
> * The refs in 'refnames' needn't be sorted. `err` must not be NULL.
> */
> -static int repack_without_refs(struct string_list *refnames, struct strbuf
> *err)
> +int repack_without_refs(struct string_list
David Turner writes:
> I think I've broken about all of the standalone stuff out, so here's
> the main enchilada.
>
> This series depends on at least the following topics in pu:
> dt/refs-bisection
> dt/refs-pseudo
> dt/reflog-tests
> kn/for-each-tag (patch 21 and corresponding bits of 42 depend
David Turner writes:
> Add a database backend for refs using LMDB. This backend runs git
> for-each-ref about 30% faster than the files backend with fully-packed
> refs on a repo with ~120k refs.
Nice ;-)
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a messag
Jeff King writes:
> Right, it was the second "we know..." that made me worry. It is really
> "we assume". :) Whether it is right according to the spec or not, the
> real world is sometimes more complicated. And given that there is no
> real advantage to changing the sending behavior now, I didn't
Michael J Gruber writes:
> How would it? "--left-right" information is requested specifically and
> not overridden. Root information is not requested specifically [by the
> user].
If this "highlight root prominently" were a config, then using both
config and --left-right would mean one of them n
Jeff King writes:
> On Thu, Sep 03, 2015 at 12:00:58PM +0200, Johannes Schindelin wrote:
>
>> In short: for users and contributors of Git for Windows, nothing
>> changes. Except that Pull Requests and issues may be dealt with more
>> swiftly, and that I will actively work on keeping Git for Windo
On Fri, Sep 4, 2015 at 11:00 AM, Phil Susi wrote:
> If you have a commit that exists on two branches, in gitk you can mark one,
> then select the other and choose to compare the two. This results in a diff
> of the two diffs, rather than a diff between the two trees, which include
> many other ch
Jeff King writes:
> It shouldn't be necessary for $GIT_DIR, but it makes sense for other git
> variables. E.g., with "AcceptEnv GIT_*", "git -c" config is propagated.
> E.g.:
> ...
Just to make sure I got you correctly, you are saying that "we
propagate, but that is not correct. We should stop d
Gábor Bernát writes:
> @@ -277,9 +277,43 @@ test $commits -eq 0 && die "Found nothing to rewrite"
> # Rewrite the commits
>
> git_filter_branch__commit_count=0
This is not a new problem, but I wonder why we need such a
cumbersomely long variable name. It is not like this is a part of
some s
John Keeping writes:
> All are harmless at the moment and t7610 and t5801 can be fixed by
> moving the test_when_finished call out of the subshell relatively
> easily.
>
> t7800 (in its final test) calls test_config in a subshell which has cd'd
> into a submodule.
>
> Is this something worth worr
Josh Rabinowitz writes:
> Hi Junio and other recipients:
>
> Junio, thanks for your response. I think you may have misunderstood my
> patch though (or I am misunderstanding your responses), because it
> seems we are actually in agreement.
>
> 1) My original patch is to make 'git push --porcelain
Jeff King writes:
> Perhaps we should reconsider whether f4c3edc (vreportf: avoid
> intermediate buffer, 2015-08-11) is a good idea. Note that snprintf is
> not on the list of safe functions, but I imagine that in practice it is
> fine. Though just avoiding error()/warning() in signal handlers m
John Medema writes:
> Option D has the downside that it changes the behavior of more code
> (cmdline and gui), which is why I didn't suggest it before. It also
> has the downside of making the branch list longer. But that's the
> nature of cloning; if I copy a full directory of files to a new
>
Ben Boeckel writes:
> + url_nr = 0;
> + if (push_mode) {
> + url = remote->pushurl;
> + url_nr = remote->pushurl_nr;
> + }
> +
> + /* Fall back to the fetch URL if no push URLs are set. */
> + if (!url_nr) {
> + url = remote->url;
> +
Alexey Shumkin writes:
> Some repositories may have spaces in their paths. Currently `git-subtree`
> raises an error in such cases.
> Also, `git-subtree` currently does not have tests for its 'push' command.
> Following patches are to fix these statements.
>
> Alexey Shumkin (2):
> t7900-subtre
Linus Torvalds writes:
> So I think that logic should basically be extended to saying
>
> - if any line in the last chunk has a "Signed-off-by:", set a flag.
>
> - at the end of the loop, if that flag wasn't set, return 0.
I am reluctant to special case S-o-b: too much, even though this is
abo
Linus Torvalds writes:
> but the failing cases have a comment by Andrew:
>
> [a...@linux-foundation.org: coding-style fixes]
> Signed-off-by: Tang Chen
> Cc: Xishi Qiu
> Cc: Yasuaki Ishimatsu
> Cc: Kamezawa Hiroyuki
> Cc: Taku Izumi
> Cc: Gu Zheng
> Cc: Naoya
Linus Torvalds writes:
> The thing is, and that was what the report was all about, not every
> line _is_ of that format. We have commetns from the sign-off people.
> Things like this:
>
> Signed-off-by: Noam Camus
> Acked-by: Vineet Gupta
> [ Also removed pointless cast from "void *
Linus Torvalds writes:
> On Fri, Sep 4, 2015 at 6:06 PM, Junio C Hamano wrote:
>>
>> that rule would still not think this is a signature block, but at
>> that point, do we really want to consider such a block of text a
>> signature block?
>
> So exactly why are
Johannes Sixt writes:
> Why do we need a new rule? The old git-am had a logic that pleased
> everyone, and it must have been implemented somewhere. Shouldn't it be
> sufficient to just re-implement or re-use that logic?
If you look at the helper the rewritten "am" calls, you will notice
that it
Junio C Hamano writes:
> Johannes Sixt writes:
>
>> Why do we need a new rule? The old git-am had a logic that pleased
>> everyone, and it must have been implemented somewhere. Shouldn't it be
>> sufficient to just re-implement or re-use that logic?
> ...
Linus Torvalds writes:
> That said, the original "git am" rules actually seem to be rather
> straightforward: it's never an issue about "last block of text", and
> it's simply an issue of "is there a sign-ff _anywhere_ in the text".
>
> That simplicity has a certain appeal to me. I don't think it
Jeff King writes:
> [1] I think part of the reason people are interested in "fancy" here is
> that this topic extends beyond "git am". There's "commit -s", of
> course, but there's also the generic "interpret-trailers" command,
> which is supposed to be a generalization of the "--sign
Junio C Hamano writes:
> But for the purpose of 2.6-rc period, I think we should start from
> doing a separate implementation inside builtin/am.c without touching
> append_signoff().
> ...
> Here is a quick attempt to do the "just fix am regression without
> changing anyth
Junio C Hamano writes:
> And a quick attempt without even compilation testing has flaws as
> expected X-<.
>
> Second attempt.
... and I forget the de-dup logic. The third attempt.
builtin/am.c | 32 ++--
1 file changed, 30 insertions(+), 2 del
On Sat, Sep 5, 2015 at 6:12 AM, John Keeping wrote:
>
> I don't think it's worth trying to clear $BASH_SUBSHELL before the tests
> start because to do so we have to reliably detect that we're not running
> under Bash, and if we don't trust people not to set $BASH_SUBSHELL why
> do we trust them no
Junio C Hamano writes:
> To salvage "interpret-trailers" needs a lot more, as we are
> realizing that the definition that led to its external design does
> not match the way users use footers in the real world. This affects
> the internal data representation and the w
>> Isn't it just the matter of resetting the variable regardless of $BASH
>> (and ignoring
>> a possible refusal to do so under bash) at the beginning of the test, or do
>> you
>> really have to rely on the value of $BASH and do things differently?
>
> Bash doesn't refuse to set it, it lets you up
Karthik Nayak writes:
> On Sun, Sep 6, 2015 at 3:55 AM, Jacob Keller wrote:
>> On Sat, Sep 5, 2015 at 10:52 AM, Rudy Matela wrote:
>>>
>>> Allow -n and --sort=version:refname to be used together
>>> instead of failing with:
>>>
>>> fatal: --sort and -n are incompatible
>>>
>>> Signed-off-by:
t is a task for post-release.
Reported-by: Linus Torvalds
Signed-off-by: Junio C Hamano
---
* So this is essentially that "third try", but with a bit of test
to cast in stone that we expect things that are not "key: value"
in the trailer block. Let's have this (
Paul Tan writes:
> s/reimplementated/reimplemented/ ?
> s/resulting an/resulting in an/ ?
> s/extra blank/extra blank line/ ?
Thanks.
>> +static void am_signoff(struct strbuf *sb)
>> +{
>
> Hmm, okay, but now we have two similarly named functions am_signoff()
> and am_append_signoff() which bot
401 - 500 of 31372 matches
Mail list logo
