wo
environment variables. Demote the error to a warning, so that you
can say something like
make GETTEXT_POISON=Yes GIT_TEST_GETTEXT_POISON test
during the transition period, without having to worry about whether
exact version you are testing has or does not have this topic.
Signe
"Force Charlie via GitGitGadget" writes:
> From: Force Charlie
>
> Signed-off-by: Force Charlie
> ---
> http.c | 12
> 1 file changed, 12 insertions(+)
>
> diff --git a/http.c b/http.c
> index 3dc8c560d6..99cb04faba 100644
> --- a/http.c
> +++ b/http.c
> @@ -48,6 +48,7 @@ char
Rafael Ascensão writes:
> print_current_branch_name() tries to resolve HEAD and die() when it
> doesn't resolve it successfully. But the conditions being tested are
> always unreachable because early in branch:cmd_branch() the same logic
> is performed.
>
> Eliminate the duplicate and
Duy Nguyen writes:
> There is still one thing to settle. "revert -m1" could produce
> something like this
>
> This reverts commit , reversing
> changes made to .
I do not think it is relevant, with or without multiple parents, to
even attempt to read this message.
The description is
Jeff King writes:
> On Wed, Nov 07, 2018 at 10:36:52PM +0100, Johannes Sixt wrote:
>
> All that said, if we're just interested in allowing this for config,
> then we already have such a wrapper function: git_config_pathname().
>
> So I don't think it's a big deal to implement it in any of these
Ramsay Jones writes:
>> The cute thing is: your absolute paths would not be moved because we are
>> talking about Windows. Therefore your absolute paths would not start with
>> a forward slash.
>
> Ah, sorry, I must have misunderstood a comment in your cover letter:
>
> The reason is this:
Stephen & Linda Smith writes:
>> +This is particularly true when passing in diff options. Currently some
>> +options like `--stat` can as an emergent effect produce output that's
>
> "`--stat` can as an emergent": I read that for times to decided it was
> correct
> grammar. Should it be
Duy Nguyen writes:
> On Wed, Nov 7, 2018 at 2:09 PM SZEDER Gábor wrote:
>>
>> On Wed, Nov 07, 2018 at 06:41:45PM +0900, Junio C Hamano wrote:
>> > * nd/i18n (2018-11-06) 16 commits
>> > - fsck: mark strings for translation
>> > - fsck: reduce w
Ævar Arnfjörð Bjarmason writes:
> On Wed, Nov 07 2018, Junio C Hamano wrote:
>
>> * ab/range-diff-no-patch (2018-11-07) 1 commit
>> - range-diff: add a --no-patch option to show a summary
>>
>> "range-diff" learns the "--no-patch" option,
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.
You can find the changes
Johannes Sixt writes:
> Am 07.11.18 um 02:32 schrieb Junio C Hamano:
>> Johannes Sixt writes:
>>> On Linux, when I recompile for a different architecture, CFLAGS would
>>> change, so I would have thought that GIT-CFLAGS were the natural
>>> choice
Junio C Hamano writes:
> The fix here is similar to 4c30d50 "rev-list: disable object/refname
> ambiguity check with --stdin". While the get_object_list() method
> reads the objects from stdin, turn warn_on_object_refname_ambiguity
> flag (which is usually true) to false.
Jeff King writes:
> On Tue, Nov 06, 2018 at 04:48:28PM -0800, Carlo Arenas wrote:
>
> I think date_yesterday() is the only one of those special functions that
> gets called like this. Here's what I think we should do to fix it (this
> can go right on top of jk/misc-unused-fixes, which is already
t for code hygiene, save
away the original at the beginning and restore it once we are done.
Helped-by: Jeff King
Signed-off-by: Derrick Stolee
Signed-off-by: Junio C Hamano
---
builtin/pack-objects.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/builtin/pack-objects.c b/builtin/pack-obj
Johannes Sixt writes:
> Am 06.11.18 um 15:55 schrieb Johannes Schindelin via GitGitGadget:
>> From: Johannes Schindelin
>>
>> When git.rc is compiled into git.res, the result is actually dependent
>> on the architecture. That is, you cannot simply link a 32-bit git.res
>> into a 64-bit git.exe.
Ramsay Jones writes:
> On 06/11/2018 14:53, Johannes Schindelin via GitGitGadget wrote:
>> From: Johannes Schindelin
>>
>> On Windows, an absolute POSIX path needs to be turned into a Windows
>> one.
>>
>> Signed-off-by: Johannes Schindelin
>> ---
>> path.c | 5 +
>> 1 file changed, 5
Ævar Arnfjörð Bjarmason writes:
> diff --git a/builtin/range-diff.c b/builtin/range-diff.c
> index f01a0be851..05d1f6b6b6 100644
> --- a/builtin/range-diff.c
> +++ b/builtin/range-diff.c
> @@ -16,11 +16,14 @@ int cmd_range_diff(int argc, const char **argv, const
> char *prefix)
> int
Jeff King writes:
> Could we help the reading scripts by normalizing old and new output via
> interpret-trailers, %(trailers), etc?
>
> I think "(cherry picked from ...)" is already considered a trailer by
> the trailer code.
;-)
Great minds think alike, I guess. I think it is a great idea
Nguyễn Thái Ngọc Duy writes:
> OK here is a less constroversal attempt to add new trailers. Instead
> of changing the default behavior (which could be done incrementally
> later), this patch simply adds a new option --append-trailer to revert
> and cherry-pick.
I almost agree, except that the
Christian Halstrick writes:
> I am trying to teach JGit [1] to behave like native git regarding some
> corner cases during "git checkout". I am reading the "git read-tree"
> documentation and I am not sure about the case [2]. Git should behave
> differently during a normal checkout than when you
Eric Sunshine writes:
>> Calling this --[no-]patch might make it harder to integrate it to
>> format-patch later, though. I suspect that people would expect
>> "format-patch --no-patch ..." to omit both the patch part of the
>> range-diff output *AND* the patch that should be applied to the
>>
Nguyễn Thái Ngọc Duy writes:
> Changes since v2
>
> - more cleanups in grep.c, read-cache.c and index-pack.c
> - the send-pack.c changes are back, but this time I just add
> async_with_fork() to move NO_PTHREADS back in run-command.c
The patches all looked sensible; I'll wait for a few more
org...@gmail.com writes:
> From: Orgad Shaneh
>
> Signed-off-by: Orgad Shaneh
> ---
> Documentation/RelNotes/2.20.0.txt | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
Thanks.
>
> diff --git a/Documentation/RelNotes/2.20.0.txt
> b/Documentation/RelNotes/2.20.0.txt
> index
Ævar Arnfjörð Bjarmason writes:
> This change doesn't update git-format-patch with a --no-patch
> option. That can be added later similar to how format-patch first
> learned --range-diff, and then --creation-factor in
> 8631bf1cdd ("format-patch: add --creation-factor tweak for
> --range-diff",
Nguyễn Thái Ngọc Duy writes:
> static const char *describe_object(struct object *obj)
> {
> - static struct strbuf buf = STRBUF_INIT;
> - char *name = name_objects ?
> - lookup_decoration(fsck_walk_options.object_names, obj) : NULL;
> + static struct strbuf bufs[4] = {
Nguyễn Thái Ngọc Duy writes:
> diff --git a/parse-options.c b/parse-options.c
> index 0bf817193d..3f5f985c1e 100644
> --- a/parse-options.c
> +++ b/parse-options.c
> @@ -197,7 +197,7 @@ static int get_value(struct parse_opt_ctx_t *p,
> return 0;
>
> default:
> -
Nguyễn Thái Ngọc Duy writes:
> There are a few issues with opterror()
>
> - it tries to assemble an English sentence from pieces. This is not
> great for translators because we give them pieces instead of a full
> sentence.
>
> - It's a wrapper around error() and needs some hack to let the
Nguyễn Thái Ngọc Duy writes:
> The first error, "internal error", is clearly a BUG(). The second two
> are meant to catch calls with invalid parameters and should never
> happen outside the test suite.
Sounds as if it would happen inside test suites.
I guess by "inside the test suite" you
Nguyễn Thái Ngọc Duy writes:
> if (argc - i < 1)
> - return error("Nothing to delete?");
> + return error(_("no reflog specified to delete"));
Better. Thanks.
Nguyễn Thái Ngọc Duy writes:
> typechange_fmt and added_fmt should have a colon before "needs
> update". Align the statements to make it easier to read and see. Also
> drop the unnecessary ().
>
> Signed-off-by: Nguyễn Thái Ngọc Duy
> ---
> read-cache.c | 10 +-
> 1 file changed, 5
Nguyễn Thái Ngọc Duy writes:
> Signed-off-by: Nguyễn Thái Ngọc Duy
> ---
> read-cache.c | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
Makes sense; thanks.
>
> diff --git a/read-cache.c b/read-cache.c
> index d57958233e..0c37f4885e 100644
> --- a/read-cache.c
> +++
Nguyễn Thái Ngọc Duy writes:
> Two messages also print extra information to be more useful
>
> Signed-off-by: Nguyễn Thái Ngọc Duy
> ---
> archive.c | 8
> 1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/archive.c b/archive.c
> index 9d16b7fadf..d8f6e1ce30 100644
>
Nguyễn Thái Ngọc Duy writes:
> One string is slightly updated to keep consistency with the rest:
> die() should with lowercase.
s/should/& begin/, I think, in which case I could locally touch up.
>
> Signed-off-by: Nguyễn Thái Ngọc Duy
> ---
> git.c | 30 +++---
> 1
Anders Waldenborg writes:
> AFAICU strbuf_expand doesn't suffer from the worst things that printf(3)
> suffers from wrt untrusted format string (i.e no printf style %n which
> can write to memory, and no vaargs on stack which allows leaking random
> stuff).
>
> The separator option is part of
Anders Waldenborg writes:
> Junio C Hamano writes:
>> I do not think "fundamental" is the best name for this, but I agree
>> that it would be useful to split the helpers into one that is
>> "constant across commits" and the other one that is "per
Duy Nguyen writes:
> I think the intent of writing "This reverts " to encourage
> writing "because ..." is good, but in practice many people just simply
> not do it. And by not describing anything at all (footers don't count)
> some commit hook can force people to actually write something.
Ævar Arnfjörð Bjarmason writes:
> After all sometimes "other" is just the repo on my laptop or server. I
> shouldn't need to jump through hoops to re-push stuff from my "other"
> repo anymore than from the local repo.
>
> Yes refs/remotes/* isn't guaranteed to be "other repo's branches" in the
>
Jeff King writes:
> The options callback for "git apply --no-include" is not ready to handle
> the "unset" parameter, and as a result will segfault when it adds a NULL
> argument to the include list (likewise for "--no-exclude").
>
> In theory this might be used to clear the list, but since both
Jeff King writes:
> Running "git am --no-patch-format" will currently segfault, since it
> tries to parse a NULL argument. Instead, let's have it cancel any
> previous --patch-format option.
Makes perfect sense.
>
> Signed-off-by: Jeff King
> ---
> builtin/am.c | 4 +++-
> 1 file changed, 3
Junio C Hamano writes:
> Stefan Beller writes:
>
>>
>> -static int parse_color_moved_ws(const char *arg)
>> +static unsigned parse_color_moved_ws(const char *arg)
>> {
>> int ret = 0;
>> struct string_list l = STRING_LIST_INI
Anders Waldenborg writes:
> + if (opts->separator && first_printed)
> + strbuf_addbuf(out, opts->separator);
> if (opts->no_key)
> - strbuf_addf(out, "%s\n",
Anders Waldenborg writes:
> + else if (skip_prefix(arg, "key=", )) {
> + const char *end = arg + strcspn(arg,
> ",)");
> +
> + if (opts.filter_key)
> +
Eric Sunshine writes:
> On Sun, Nov 4, 2018 at 6:26 PM Junio C Hamano wrote:
>> OK, thanks. It seems that the relative silence after this message
>> is a sign that the resulting patch after squashing is what everybody
>> is happey with?
>>
>> -- >8 --
>
Eric Sunshine writes:
> Does the user have to include the colon when specifying of
> 'key='? I can see from peeking at the implementation that the
> colon must not be used, but this should be documented. Should the code
> tolerate a trailing colon? (Genuine question; it's easy to do and
> would
"brian m. carlson" writes:
> This series provides a functional SHA-256 implementation and wires it
> up, along with some housekeeping patches to make it suitable for
> testing.
>
> Changes from v4:
> * Downcase hex constants for consistency.
> * Remove needless parentheses in return statement.
>
"brian m. carlson" writes:
> I'm currently working on getting Git to support multiple hash algorithms
> in the same binary (SHA-1 and SHA-256). In order to have a fully
> functional binary, we'll need to have some way of indicating to certain
> commands (such as init and show-index) that they
Anders Waldenborg writes:
> @@ -1352,6 +1353,17 @@ static size_t format_commit_one(struct strbuf *sb, /*
> in UTF-8 */
> arg++;
>
> opts.only_trailers = 1;
> + } else if
Anders Waldenborg writes:
> No functional change intended
>
> Signed-off-by: Anders Waldenborg
> ---
> pretty.c | 37 ++---
> 1 file changed, 26 insertions(+), 11 deletions(-)
I do not think "fundamental" is the best name for this, but I agree
that it would be
Eric Sunshine writes:
> Junio labeled the "-2" trick "cute", and while it is optimal in that
> it only traverses the key/value list once, it also increases cognitive
> load since the reader has to spend a good deal more brain cycles
> understanding what is going on than would be the case with
Nguyễn Thái Ngọc Duy writes:
> tree_entry_interesting() is used for matching pathspec on a tree. The
> interesting thing about this function is that, because the tree
> entries are known to be sorted, this function can return more than
> just "yes, matched" and "no, not matched". It can also
Nguyễn Thái Ngọc Duy writes:
> Signed-off-by: Nguyễn Thái Ngọc Duy
> ---
> On top of ag/rebase-i-in-c
Thanks.
Nguyễn Thái Ngọc Duy writes:
> Noticed-by: SZEDER Gábor
> Signed-off-by: Nguyễn Thái Ngọc Duy
> ---
> On top of nd/per-worktree-ref-iteration
Thanks.
>
> Documentation/git-worktree.txt | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/Documentation/git-worktree.txt
James Knight writes:
> Changes v1 -> v2:
> - Improved support for detecting curl linker flags when not using a
> configure-based build (mentioned by Junio C Hamano).
> - Adding a description on how to explicitly use the CURL_LDFLAGS
> define when not using configure (
Matthias Urlichs writes:
> A recent discussion on LWN https://lwn.net/Articles/770642/ noted that
> "git checkout " does not warn if one if the files has
> been modified locally, nor is there an option to do so.
>
> IMHO that should be fixed, preferably by somebody who knows git's
> internals
Michał Górny writes:
>> It's my understanding that GnuPG will use the most recent subkey
>> suitable for a particular purpose, and I think the test relies on that
>> behavior. However, I'm not sure that's documented. Do we want to rely
>> on that behavior or be more explicit? (This is a
Nguyễn Thái Ngọc Duy writes:
> A reverted commit will have a new trailer
>
> Revert:
Please don't, unless you are keeping the current "the effect of
commit X relative to its parent Y was reverted" writtein in prose,
which is meant to be followed up with a manually written "because
..."
Mikkel Kjeldsen writes:
> Add --new-branch as a long-form synonym of -b. I occasionally encounter
> some confusion in new users having interpreted "checkout -b" to mean
> "checkout branch", or internalized it as "the way to create a new
> branch" rather than merely a convenience for "branch &&
Ævar Arnfjörð Bjarmason writes:
> I.e. you seemingly have no interest in using "git commit" to produce
> empty commits, but are just trying to cherry-pick something and it's
> failing because it (presumably, or am I missing something) cherry picks
> an existing commit content ends up not
Ben Peart writes:
>>> + if (*dtype == DT_UNKNOWN)
>>> + *dtype = get_dtype(NULL, istate, pathname, pathlen);
>>
>> We try to defer paying cost to determine unknown *dtype as late as
>> possible by having this call in last_exclude_matching_from_list(),
>> and not here. If we are
o int cannot overflow.
Signed-off-by: Johannes Sixt
Acked-by: Steve Hoelzer
Signed-off-by: Junio C Hamano
---
compat/poll/poll.c | 12
1 file changed, 8 insertions(+), 4 deletions(-)
diff --git a/compat/poll/poll.c b/compat/poll/poll.c
index ad5dcde439..4459408c7d 100644
--- a/
Michał Górny writes:
> I've just did a little research and came to the following results:
Wonderful.
> 1. modifying the 'C. O. Mitter' key would require changes to 4 tests,
>
> 2. modifying the 'Eris Discordia' key would require changes to 2 tests
>(both in 7510).
>
> Do you think 2. would
Duy Nguyen writes:
>> Would it make sense to make send-email's completion helper print these
>> out directly? That way, if someone were to modify send-email in the
>> future, they'd only have to look through one file instead of both
>> send-email and the completions script.
>
> I did think about
Michał Górny writes:
> As for how involved... we'd just have to use a key that has split
> signing subkey. Would it be fine to add the subkey to the existing key?
> It would imply updating keyids/fingerprints everywhere.
Yes, that "everywhere" is exactly what I meant by "how involved",
and
Derrick Stolee writes:
> Uncovered code in 'next' not in 'master'
>
>
> pretty.c
> 4de9394dcb 1264) if (c->signature_check.primary_key_fingerprint)
> 4de9394dcb 1265) strbuf_addstr(sb,
> c->signature_check.primary_key_fingerprint);
> 4de9394dcb 1266)
Stefan Beller writes:
>
> -static int parse_color_moved_ws(const char *arg)
> +static unsigned parse_color_moved_ws(const char *arg)
> {
> int ret = 0;
> struct string_list l = STRING_LIST_INIT_DUP;
> @@ -312,15 +312,19 @@ static int parse_color_moved_ws(const char *arg)
>
Ævar Arnfjörð Bjarmason writes:
> Although I'm on the fence with the approach in 1/5. Should this be a
> giant getopt switch statement like that in a helper script?
>
> An alternative would be to write out a shell file similar to
> GIT-BUILD-OPTIONS and source that from this thing. I don't
Junio C Hamano writes:
> Johannes Sixt writes:
>
>>> Yep, correct on all counts. I'm in favor of changing the commit message to
>>> only say that this patch removes Warning C28159.
>>
>> How about this fixup instead?
>
> Isn't that already in 'next'?
Johannes Sixt writes:
>> Yep, correct on all counts. I'm in favor of changing the commit message to
>> only say that this patch removes Warning C28159.
>
> How about this fixup instead?
Isn't that already in 'next'? I didn't check, though.
Duy Nguyen writes:
> On Fri, Nov 2, 2018 at 2:32 PM Ben Peart wrote:
>>
>> From: Ben Peart
>>
>> During an "add", a call is made to run_diff_files() which calls
>> check_remove() for each index-entry. The preload_index() code distributes
>> some of the costs across multiple threads.
>
>
Jeff King writes:
>> to have *some* names there, for the sake of a
>> simply described coding style without many exceptions
>> (especially those exceptions that rely on judgement).
>
> Fair enough.
For the record, there aren't "many" exceptions to the rule that was
suggested earlier: if you
Ben Peart writes:
> From: Ben Peart
>
> During an "add", a call is made to run_diff_files() which calls
> check_remove() for each index-entry. The preload_index() code
> distributes some of the costs across multiple threads.
Nice. I peeked around and noticed that we already do this in
James Knight writes:
> Makefile | 21 +++--
> config.mak.uname | 5 ++---
> configure.ac | 17 +++--
> 3 files changed, 16 insertions(+), 27 deletions(-)
>
> diff --git a/Makefile b/Makefile
> index b08d5ea25..c3be87b0e 100644
> --- a/Makefile
> +++
Jeff King writes:
> There's another mention in Documentation/technical/api-object-access.txt.
Yes, and we are on the same page on that one.
>
> But since the entire API is undocumented, I'm not sure it matters much.
> That file has been a placeholder since 2007. Maybe we should just delete
>
Jeff King writes:
> ... it seems rather silly that we have xdiff generate a string
> just so that we can parse it from within the same process. So instead I
> improved the xdiff interface to pass the actual integers out, made use
> of it as appropriate, and then in the final patch we can just
Farhan Khan writes:
> ...Where is this in the git code? That might
> serve as a good guide.
There are two major codepaths. One is used at runtime, giving us
random access into the packfile with the help with .idx file. The
other is used when receiving a new packstream to create an .idx
file.
Remnant of the old name of the function still remains in comments.
Update them all.
Signed-off-by: Junio C Hamano
---
apply.c | 2 +-
builtin/gc.c | 2 +-
fast-import.c | 4 ++--
notes.c | 2 +-
object.h | 2 +-
sha1-file.c | 2 +-
6 files changed, 7 insertions(+), 7
Junio C Hamano writes:
> As we currently have no idea when builtin/stash.c becomes ready for
> 'next', how about doing something like this instead, in order to
> help end-users without waiting in the meantime? The fix can be
> picked up and ported when the C rewrite is updated, o
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 eighth batch is all about
the stashes in a more permanent history by
committing, and they must do "git config user.{name,email}" at that
point anyway, so arguably this change is only delaying a step that
is necessary to work in the repository.
Signed-off-by: Junio C Hamano
---
* This time with a proposed commit log mes
Junio C Hamano writes:
> Rather than adding this fallback trap, can't we do it more like
> this?
>
> - At the beginning of "git stash", after parsing the command
> line, we know what subcommand of "git stash" we are going to
> run.
>
>
Ævar Arnfjörð Bjarmason writes:
> Change the GETTEXT_POISON compile-time + runtime GIT_GETTEXT_POISON
> test parameter to only be a GIT_TEST_GETTEXT_POISON=
> runtime parameter, to be consistent with other parameters documented
> in "Running tests with special setups" in t/README.
> ...
>
Sirio Balmelli writes:
> It appears that git ignores the GIT_CONFIG environment variable,
> while git-config *does* consider it.
Yup, that is exactly how it is designed and documented. These
dasys, with "git config" taking "--file" to work on any arbitrary
filename, you do not necessarily need
Slavica Djukic writes:
> Usually, when creating a commit, ident is needed to record the author
> and commiter.
> But, when there is commit not intended to published, e.g. when stashing
> changes, valid ident is not necessary.
> To allow creating commits in such scenario, let's introduce helper
SZEDER Gábor writes:
> Ever since we started using Travis CI, we specified the list of
> packages to install in '.travis.yml' via the APT addon. While running
> our builds on Travis CI's container-based infrastructure we didn't
> have another choice, because that environment didn't support
Stefan Beller writes:
>> What was posted would have been perfectly fine as a "how about doing
>> it this way" weatherbaloon patch, but as a part of real series, it
>> needs to explain to the developers what the distinctions between two
>> classes are, and who is to use the cocci patch at what
Derrick Stolee writes:
> We could do this, but it does come with a performance hit when the following
> are all true:
>
> 1. 'to' is not reachable from any 'from' commits.
>
> 2. The 'to' and 'from' commits are close in commit-date.
>
> 3. Generation numbers are not available, or the topology is
Derrick Stolee writes:
> On 11/1/2018 5:59 AM, Junio C Hamano wrote:
>> --
>> [Graduated to "master"]
>
> I see that several topics graduated, but it appears the master branch
> was not update
Derrick Stolee writes:
>> Review discussions seem to have petered out. Would we merge this to
>> 'next' and start cooking, perhaps for the remainder of this cycle?
>
> Thanks, but I've just sent a v5 responding to Jakub's feedback on v4. [1]
>
> I'd be happy to let it sit in next until you feel
Duy Nguyen writes:
>> > I have no comment about this. In an ideal world, sendemail.perl could
>> > be taught to support --git-completion-helper but I don't think my
>> > little remaining Perl knowledge (or time) is enough to do it. Perhaps
>> > this will do. I don't know.
>>
>> So "all",
Johannes Sixt writes:
> Am 01.11.18 um 07:12 schrieb Junio C Hamano:
>> "Johannes Schindelin via GitGitGadget"
>> writes:
>>
>>> The `--preserve-merges` mode of the `rebase` command is slated to be
>>> deprecated soon, ...
>>
>&g
Ævar Arnfjörð Bjarmason writes:
> Could you please pick up
> https://public-inbox.org/git/20181024114725.3927-1-ava...@gmail.com/ ?
> It seems to have fallen between the cracks and addressed the feedback on
> v1, and looks good to me (and nobody's objected so far...).
If this is the
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.
Two groups of "rewrite
"Johannes Schindelin via GitGitGadget"
writes:
> The `--preserve-merges` mode of the `rebase` command is slated to be
> deprecated soon, ...
Is everybody on board on this statement? I vaguely recall that some
people wanted to have something different from what rebase-merges
does (e.g. wrt
"brian m. carlson" writes:
> I need to do a reroll to address some other issues people brought up, so
> I can remove this line.
OK. I actually do not feel too strongly about this one, by the way.
"Derrick Stolee via GitGitGadget" writes:
> This patch series performs a decently-sized refactoring of the revision-walk
> machinery. Well, "refactoring" is probably the wrong word, as I don't
> actually remove the old code. Instead, when we see certain options in the
> 'rev_info' struct, we
Ævar Arnfjörð Bjarmason writes:
>> On the other hand, I do not think I mind all that much if a src that
>> is a tag object to automatically go to refs/tags/ (having a tag
>> object in refs/remotes/** is rare enough to matter in the first
>> place).
>
> Yeah maybe this is going too far. I don't
Ævar Arnfjörð Bjarmason writes:
> Mark the tests where "git fsck" fails at the end with extra test code
> to check the fsck output. There fsck.{err,out} has been created for
> us.
>
> A later change will add the support for GIT_TEST_FSCK_TESTS. They're
> being added first to ensure the test
-by: Junio C Hamano
---
builtin/am.c | 86 +
sequencer.c | 105 +++
sequencer.h | 3 ++
3 files changed, 110 insertions(+), 84 deletions(-)
diff --git a/builtin/am.c b/builtin/am.c
index c78a745289..83685180e0
of 'rebase --interactive'.
Signed-off-by: Phillip Wood
Signed-off-by: Junio C Hamano
---
builtin/am.c | 49 +++--
1 file changed, 39 insertions(+), 10 deletions(-)
diff --git a/builtin/am.c b/builtin/am.c
index 4f7f28a9dc..ffca4479d7 100644
Phillip Wood writes:
> From: Phillip Wood
>
> Sorry for the confusion with v3, here are the updated patches.
>
> Thanks to Junio for the feedback on v2. I've updated patch 4 based on
> those comments, the rest are unchanged.
The mistake of overwriting -1 (i.e. earlier we detected dup) with
the
301 - 400 of 27729 matches
Mail list logo
