[GIT PULL] l10n updates for 2.17.0 round 1
Hi Junio, Would you please pull the following git l10n updates. The following changes since commit 0afbf6caa5b16dcfa3074982e5b48e27d452dbbb: Git 2.17-rc0 (2018-03-15 15:01:05 -0700) are available in the Git repository at: git://github.com/git-l10n/git-po tags/l10n-2.17.0-rnd1 for you to fetch changes up to 8bb6d60dd6b6f2f72fe091cb03d571dbdc01aa3e: l10n: de.po: translate 132 new messages (2018-03-31 13:21:09 +0200) l10n for Git 2.17.0 round 1 Alexander Shopov (1): l10n: bg.po: Updated Bulgarian translation (3376t) Changwoo Ryu (1): l10n: ko.po: Update Korean translation Christopher Diaz Riveros (2): l10n: es.po: fixes to Spanish translation l10n: es.po: Update Spanish translation 2.17.0 Jean-Noël Avila (2): l10n: fr.po v2.17.0 round 1 l10n: fr.po: v2.17.0 no fuzzy Jiang Xin (10): Merge branch 'merge' of https://github.com/ChrisADR/git-po into maint l10n: git.pot: v2.17.0 round 1 (132 new, 44 removed) Merge remote-tracking branch 'git-po/maint' Merge branch 'master' of git://github.com/alshopov/git-po Merge branch 'master' of https://github.com/vnwildman/git Merge branch 'fr_v2.17.0' of git://github.com/jnavila/git Merge branch 'master' of https://github.com/Softcatala/git-po Merge branch 'master' of git://github.com/nafmo/git-l10n-sv Merge branch 'fr_v2.17.0' of git://github.com/jnavila/git l10n: zh_CN: for git v2.17.0 l10n round 1 Jordi Mas (1): l10n: Update Catalan translation Peter Krefting (1): l10n: sv.po: Update Swedish translation (3376t0f0u) Ralf Thielow (1): l10n: de.po: translate 132 new messages Ray Chen (1): l10n: zh_CN: review for git v2.17.0 l10n round 1 Trần Ngọc Quân (1): l10n: vi.po(3376t): Updated Vietnamese translation for v2.17 po/bg.po| 4598 po/ca.po| 7551 ++- po/de.po| 4670 +++- po/es.po| 5213 ++--- po/fr.po| 4586 +++- po/git.pot | 4396 ++ po/ko.po| 4583 po/sv.po| 4571 po/vi.po| 4591 po/zh_CN.po | 4561 10 files changed, 26709 insertions(+), 22611 deletions(-)
URGENT
Re: PRIVATE Dear Madam/Sir, I trust this email finds you in good health. I write in respect of an amount held in the account of an expatriate investor, an associate physician, working on Cancer Vaccines Immunotherapy Research. The closing balance is the sum of US$13, 400, 000 (Thirteen Million and Four Hundred Thousand). He was aged 68 when he left the country for the US in 2001. It has been well over 16 years and nobody has since then come for the claim over the time. The bank does not have record of contact information of his family relatives in the file for the claim and the funds will be credited to the government treasury as “unclaimed”, unless someone shows up with corresponding data to authorize the payment. Please I need your cooperation on this urgent confidential matter. I am willing to provide all relevant data details. This will be disbursed or shared in percentage of 45% to me, 15% to the accountant and 40% to you. Dr. K.Dankwa Anissan.M.D., D.G.O., F.I.C.S., Sonologist in obstetrics Gynecology St. Nicholas Hospital, Lagos. dr.anissa...@gmail.com
[PATCH v6 6.5/6] fixup! worktree: teach "add" to check out existing branches
Signed-off-by: Thomas Gummerer --- So while playing with it a bit more I found one case where the new UI is not ideal and a bit confusing. Namely when the new check out dwim kicks in, but there is already a file/directory at the path we're giving to 'git worktree add'. In that case something like the following would be printed: $ g worktree add ../next Checking out branch 'next' fatal: '../next' already exists Instead I think we'd just want the error without the "Checking out branch" message, which is what this fixup here does. One thing that gets a bit strange is that the "Checking out branch" message and the "Creating branch" messages are printed from different places. But without doing quite some refactoring I don't think there's a good way to do that, and I think having the UI do the right thing is more important. One thing I also noticed is that if a branch is created by 'git worktree add', but we fail, we never clean up that branch again, which I'm not sure is ideal. As a pre-existing problem I'd like to keep fixing that out of the scope of this series though (at least after this series the user would get some output showing that this happened, even when the branch is not set up to track a remote), so I'd like to keep fixing that out of the scope of this series. Junio: could you please squash this in in 6/6 while queuing? I'd prefer not to re-send the whole series just for fixing this up, but obviously can if that makes your life easier :) Thanks! builtin/worktree.c | 8 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/builtin/worktree.c b/builtin/worktree.c index 511d0aa370..ccc2e63e0f 100644 --- a/builtin/worktree.c +++ b/builtin/worktree.c @@ -27,6 +27,7 @@ struct add_opts { int detach; int checkout; int keep_locked; + int checkout_existing_branch; }; static int show_only; @@ -316,6 +317,8 @@ static int add_worktree(const char *path, const char *refname, if (ret) goto done; + if (opts->checkout_existing_branch) + fprintf_ln(stderr, _("Checking out branch '%s'"), refname); if (opts->checkout) { cp.argv = NULL; argv_array_clear(&cp.args); @@ -397,7 +400,6 @@ static int add(int ac, const char **av, const char *prefix) const char *branch; const char *new_branch = NULL; const char *opt_track = NULL; - int checkout_existing_branch = 0; struct option options[] = { OPT__FORCE(&opts.force, N_("checkout even if already checked out in other worktree")), OPT_STRING('b', NULL, &new_branch, N_("branch"), @@ -443,7 +445,7 @@ static int add(int ac, const char **av, const char *prefix) if (ac < 2 && !new_branch && !opts.detach) { const char *s = dwim_branch(path, &new_branch, - &checkout_existing_branch); + &opts.checkout_existing_branch); if (s) branch = s; } @@ -478,8 +480,6 @@ static int add(int ac, const char **av, const char *prefix) if (run_command(&cp)) return -1; branch = new_branch; - } else if (checkout_existing_branch) { - fprintf_ln(stderr, _("Checking out branch '%s'"), branch); } else if (opt_track) { die(_("--[no-]track can only be used if a new branch is created")); } -- 2.16.1.78.g71f731ae26.dirty
Re: What's cooking in git.git (Mar 2018, #05; Wed, 28)
> On 30 Mar 2018, at 12:32, Lars Schneider wrote: > > >> On 30 Mar 2018, at 11:24, Ævar Arnfjörð Bjarmason wrote: >> >> >> On Wed, Mar 28 2018, Junio C. Hamano wrote: >> >>> * ls/checkout-encoding (2018-03-16) 10 commits >>> - convert: add round trip check based on 'core.checkRoundtripEncoding' >>> - convert: add tracing for 'working-tree-encoding' attribute >>> - convert: check for detectable errors in UTF encodings >>> - convert: add 'working-tree-encoding' attribute >>> - utf8: add function to detect a missing UTF-16/32 BOM >>> - utf8: add function to detect prohibited UTF-16/32 BOM >>> - utf8: teach same_encoding() alternative UTF encoding names >>> - strbuf: add a case insensitive starts_with() >>> - strbuf: add xstrdup_toupper() >>> - strbuf: remove unnecessary NUL assignment in xstrdup_tolower() >>> >>> The new "checkout-encoding" attribute can ask Git to convert the >>> contents to the specified encoding when checking out to the working >>> tree (and the other way around when checking in). >> >> There's an issue in ca16fc3635 ("convert: check for detectable errors in >> UTF encodings", 2018-03-15) flagged by Coverity: >> https://public-inbox.org/git/CAGZ79kbAOcwaRzjuMtZ_HVsYvUr_7UAPbOcnrmPgsdE19q=p...@mail.gmail.com/ > > Thanks a lot for pointing me at this! > I'll prepare a new round soonish. The report says: >>> CID 1433528: Null pointer dereferences (FORWARD_NULL) >>> Passing null pointer "src" to "validate_encoding", which dereferences it. 411 if (validate_encoding(path, enc, src, src_len, die_on_error)) However, validate_encoding() does not dereference it. It just passes the pointer to has_prohibited_utf_bom() and is_missing_required_utf_bom(). These functions just pass the pointer to has_bom_prefix(). In has_bom_prefix() we pass the pointer to memcmp() which is undefined for null pointers. I think that is what Coverity is complaining about, right? - Lars
Re: [PATCH v11 06/10] convert: add 'working-tree-encoding' attribute
> On 18 Mar 2018, at 08:24, Torsten Bögershausen wrote: > > Some comments inline > > On Fri, Mar 09, 2018 at 06:35:32PM +0100, lars.schnei...@autodesk.com wrote: >> From: Lars Schneider >> >> Git recognizes files encoded with ASCII or one of its supersets (e.g. >> UTF-8 or ISO-8859-1) as text files. All other encodings are usually >> interpreted as binary and consequently built-in Git text processing >> tools (e.g. 'git diff') as well as most Git web front ends do not >> visualize the content. >> >> Add an attribute to tell Git what encoding the user has defined for a >> given file. If the content is added to the index, then Git converts the > > Minor comment: > "Git converts the content" > Everywhere else (?) "encodes or reencodes" is used. > "Git reencodes the content" may be more consistent. OK, will change. >> >> +static const char *default_encoding = "UTF-8"; >> + >> +static int encode_to_git(const char *path, const char *src, size_t src_len, >> + struct strbuf *buf, const char *enc, int conv_flags) >> +{ >> +char *dst; >> +int dst_len; >> +int die_on_error = conv_flags & CONV_WRITE_OBJECT; >> + >> +/* >> + * No encoding is specified or there is nothing to encode. >> + * Tell the caller that the content was not modified. >> + */ >> +if (!enc || (src && !src_len)) >> +return 0; > > (This may have been discussed before. > As we checked (enc != NULL) I think we can add here:) > if (is_encoding_utf8(enc)) > return 0; This should be covered in git_path_check_encoding(), introduced in v12: /* Don't encode to the default encoding */ if (same_encoding(value, default_encoding)) return NULL; In that function the encoding of a certain file is read from the .gitattributes. If the encoding matches the compile-time defined default encoding (= UTF-8), then the encoding is set to NULL. >> >> + >> +static int encode_to_worktree(const char *path, const char *src, size_t >> src_len, >> + struct strbuf *buf, const char *enc) >> +{ >> +char *dst; >> +int dst_len; >> + >> +/* >> + * No encoding is specified or there is nothing to encode. >> + * Tell the caller that the content was not modified. >> + */ >> +if (!enc || (src && !src_len)) >> +return 0; > > Same as above: > if (is_encoding_utf8(enc)) > return 0; > >> + >> +dst = reencode_string_len(src, src_len, enc, default_encoding, >> + &dst_len); >> +if (!dst) { >> +error("failed to encode '%s' from %s to %s", >> +path, default_encoding, enc); >> +return 0; >> +} >> + >> +strbuf_attach(buf, dst, dst_len, dst_len + 1); >> +return 1; >> +} >> + >> static int crlf_to_git(const struct index_state *istate, >> const char *path, const char *src, size_t len, >> struct strbuf *buf, >> @@ -978,6 +1051,25 @@ static int ident_to_worktree(const char *path, const >> char *src, size_t len, >> return 1; >> } >> >> +static const char *git_path_check_encoding(struct attr_check_item *check) >> +{ >> +const char *value = check->value; >> + >> +if (ATTR_UNSET(value) || !strlen(value)) >> +return NULL; >> + > > >> +if (ATTR_TRUE(value) || ATTR_FALSE(value)) { >> +error(_("working-tree-encoding attribute requires a value")); >> +return NULL; >> +} > > TRUE or false are values, but just wrong ones. > If this test is removed, the user will see "failed to encode "TRUE" to > "UTF-8", > which should give enough information to fix it. I see your point. However, I would like to stop the processing right there for these invalid values. How about error(_("true/false are no valid working-tree-encodings")); I think that is the most straight forward/helpful error message for the enduser (I consider the term "boolean" but dismissed it as potentially confusing to folks not familiar with the term). OK with you? > >> + >> +/* Don't encode to the default encoding */ >> +if (!strcasecmp(value, default_encoding)) >> +return NULL; > Same as above ?: > if (is_encoding_utf8(value)) > return 0; Yes, that was fixed in v12 as mentioned above :-) - Lars
[PATCH] builtin/commit.c: prevent bad commits
These commits which have hashes starting with the hex string 'bad', always give me the chills. Why should a perfectly good commit be jinxed? Statistically, one of 4096 commits may be 'bad'. This change adds a '--prevent-bad' switch to the commit command in order to prevent such commit hashes from being generated. Internally, the commit is retried with a slight commit meta-data modification - a newline is added to the end of the commit message. The meta-data change results in a different hash, that if we are lucky enough (4095/4096 chance) may not be 'bad'. Note that this change does not affect actual software quality maintained using Git. Thus, it is recommended keep testing all generated versions regardless of commit hash jinxes. Signed-off-by: Dan Aloni --- builtin/commit.c | 34 +- 1 file changed, 29 insertions(+), 5 deletions(-) diff --git a/builtin/commit.c b/builtin/commit.c index 37fcb55ab0a0..afaa7cefaedf 100644 --- a/builtin/commit.c +++ b/builtin/commit.c @@ -89,6 +89,7 @@ static int edit_flag = -1; /* unspecified */ static int quiet, verbose, no_verify, allow_empty, dry_run, renew_authorship; static int config_commit_verbose = -1; /* unspecified */ static int no_post_rewrite, allow_empty_message; +static int prevent_bad; static char *untracked_files_arg, *force_date, *ignore_submodule_arg, *ignored_arg; static char *sign_commit; @@ -1449,6 +1450,7 @@ int cmd_commit(int argc, const char **argv, const char *prefix) OPT_BOOL('z', "null", &s.null_termination, N_("terminate entries with NUL")), OPT_BOOL(0, "amend", &amend, N_("amend previous commit")), + OPT_BOOL(0, "prevent-bad", &prevent_bad, N_("prevent a bad commit")), OPT_BOOL(0, "no-post-rewrite", &no_post_rewrite, N_("bypass post-rewrite hook")), { OPTION_STRING, 'u', "untracked-files", &untracked_files_arg, N_("mode"), N_("show untracked files, optional modes: all, normal, no. (Default: all)"), PARSE_OPT_OPTARG, NULL, (intptr_t)"all" }, /* end commit contents options */ @@ -1583,12 +1585,34 @@ int cmd_commit(int argc, const char **argv, const char *prefix) append_merge_tag_headers(parents, &tail); } - if (commit_tree_extended(sb.buf, sb.len, &active_cache_tree->oid, -parents, &oid, author_ident.buf, sign_commit, -extra)) { - rollback_index_files(); - die(_("failed to write commit object")); + for (;;) { + char *oid_hex; + struct commit_list *copy_parents; + + copy_parents = copy_commit_list(parents); + + if (commit_tree_extended(sb.buf, sb.len, &active_cache_tree->oid, +parents, &oid, author_ident.buf, sign_commit, +extra)) { + rollback_index_files(); + die(_("failed to write commit object")); + } + + oid_hex = oid_to_hex(&oid); + if (prevent_bad && + oid_hex[0] == 'b' && + oid_hex[1] == 'a' && + oid_hex[2] == 'd' ) + { + parents = copy_parents; + strbuf_add(&sb, "\n", 1); + continue; + } + + free_commit_list(copy_parents); + break; } + strbuf_release(&author_ident); free_commit_extra_headers(extra); -- 2.14.3
Re: [PATCH v12 04/10] utf8: teach same_encoding() alternative UTF encoding names
> On 16 Mar 2018, at 19:19, Eric Sunshine wrote: > > On Fri, Mar 16, 2018 at 1:50 PM, Junio C Hamano wrote: >> Eric Sunshine writes: >>> However, I'm having a tough time imagining cases in which callers >>> would want same_encoding() to return true if both arguments are NULL, >>> but outright crash if only one is NULL (which is the behavior even >>> before this patch). In other words, same_encoding() takes advantage of >>> is_encoding_utf8() for its convenience, not for its NULL-handling. >>> Given that view, the two explicit is_encoding_utf8() calls in >>> same_encoding() seem redundant once the same_utf_encoding() call is >>> added. >> >> So... does that mean we'd want something like this, or do you have >> something else in mind? >> >>int same_encoding(const char *src, const char *dst) >>{ >>static const char utf8[] = "UTF-8"; >> >>if (!src) >>src = utf8; >>if (!dst) >>dst = utf8; >>if (same_utf_encoding(src, dst)) >>return 1; >>return !strcasecmp(src, dst); >>} > > I am not proposing anything like that for this patch or patch series. > I'm merely asking why, after this patch, same_encoding() still > contains the (in my mind) now-unneeded conditional: > >if (is_encoding_utf8(src) && is_encoding_utf8(dst)) >return 1; My main motivation was to keep the existing behavior "as-is" to avoid any regressions. However, I agree with your critic of the inconsistencies. Therefore, I will use Junio's suggestion above as it makes the intented behaivior clear. Thanks, Lars
Re: [GSoC] [PATCH] travis-ci: added clang static analysis
> On 13 Mar 2018, at 18:45, Siddhartha Mishra wrote: > > On Mon, Mar 12, 2018 at 3:49 PM, Lars Schneider > wrote: >> Hi, >> >> That looks interesting but I agree with Dscho that we should not limit >> this to master/maint. >> >> I assume you did run this on TravisCI already? Can you share a link? >> I assume you did find errors? Can we fix them or are there too many? >> If there are existing errors, how do we define a "successful" build? >> >> Thanks for working on this, >> Lars >> > > Thanks for the reply, > > I assume there will be false positives in the code which we can't fix > by making small modifications to the code as recommended in the FAQ > (https://clang-analyzer.llvm.org/faq.html). According to the FAQ, > there is no solid mechanism for suppressing a specific warning, so are > options are limited. Some of the things which might help reduce the > noise are: > > 1) To add specific tags in our source code to tell the analyzer to > ignore the code. This is probably a bad idea since it is intrusive and > forces changes to the actual source code which only affect one task. > > 2) Count the number of bugs in the previous pushed build and fail the > build if the number of bugs increases. It doesn't help remove the > noise from the error log but it does tell you if you've added more > bugs. However if you add a bug and remove one, it'll pass the job and > might mislead you into thinking that the code is correct. > > 3) Write a script to check the diff of the error log from that of the > previous pushed build(ignoring the line numbers). I haven't thought > about how exactly it would be implemented so I'm not commenting on it. > > Is there a better solution that I'm missing or should I try coming up > with a script to come up the diff? That's a good summary and I don't see a better solution. While (3) sounds nice, I think (2) is the fastest/most pragmatic solution. We already use the Travis cache [1]. You could use that mechanism to store a file with the latest number of bugs in the cache directory $HOME/travis-cache If the "number of bugs" file does not exist, then create it and don't complain. If the file exists and the previous number of bugs is higher or equal, then don't complain either. If the file exists and the previous number of bugs is lower, then let the build fail. Do you think that could work? Cheers, Lars [1] https://docs.travis-ci.com/user/caching/ > > Thanks for the time, > Siddhartha > > On Mon, Mar 12, 2018 at 3:49 PM, Lars Schneider > wrote: >> Hi, >> >> That looks interesting but I agree with Dscho that we should not limit >> this to master/maint. >> >> I assume you did run this on TravisCI already? Can you share a link? >> I assume you did find errors? Can we fix them or are there too many? >> If there are existing errors, how do we define a "successful" build? >> >> Thanks for working on this, >> Lars >> >>> On 05 Mar 2018, at 21:04, SiddharthaMishra wrote: >>> >>> Added a job to run clang static code analysis on the master and maint branch >>> >>> Signed-off-by: SiddharthaMishra >>> --- >>> .travis.yml | 17 - >>> ci/run-static-analysis.sh | 9 - >>> 2 files changed, 24 insertions(+), 2 deletions(-) >>> >>> diff --git a/.travis.yml b/.travis.yml >>> index 4684b3f4f..9b891d182 100644 >>> --- a/.travis.yml >>> +++ b/.travis.yml >>> @@ -48,7 +48,7 @@ matrix: >>> before_install: >>> before_script: >>> script: ci/run-linux32-docker.sh >>> -- env: jobname=StaticAnalysis >>> +- env: jobname=CocciStaticAnalysis >>> os: linux >>> compiler: >>> addons: >>> @@ -59,6 +59,21 @@ matrix: >>> before_script: >>> script: ci/run-static-analysis.sh >>> after_failure: >>> +- if: branch IN (master, maint) >>> + env: jobname=ClangStaticAnalysis >>> + os: linux >>> + compiler: >>> + add_ons: >>> +apt: >>> + sources: >>> + - ubuntu-toolchain-r-test >>> + - llvm-toolchain-trusty >>> + packages: >>> + - clang >>> + before_install: >>> + before_script: >>> + script: ci/run-static-analysis.sh >>> + after_failure: >>>- env: jobname=Documentation >>> os: linux >>> compiler: >>> diff --git a/ci/run-static-analysis.sh b/ci/run-static-analysis.sh >>> index fe4ee4e06..6ae032f54 100755 >>> --- a/ci/run-static-analysis.sh >>> +++ b/ci/run-static-analysis.sh >>> @@ -5,6 +5,13 @@ >>> >>> . ${0%/*}/lib-travisci.sh >>> >>> -make coccicheck >>> +case "$jobname" in >>> +ClangStaticAnalysis) >>> + scan-build -analyze-headers --status-bugs make >>> + ;; >>> +CocciStaticAnalysis) >>> + make coccicheck >>> + ;; >>> +esac >>> >>> save_good_tree >>> -- >>> 2.16.2.248.ge2408a6f7.dirty >>> >>
Greetings,
Hello Greetings to you today i asked before but i did't get a response please i know this might come to you as a surprise because you do not know me personally so i will give you a video call to explain more but did you get my previous email ? Let me know asap. Best Regards, miss meryem ramazan. Esentepe Mahallesi Büyükdere Caddesi Kristal Kule Binasi No:215 Sisli - Istanbul, Turkey
Re: [PATCH] builtin/commit.c: prevent bad commits
Dan Aloni writes: > These commits which have hashes starting with the hex string 'bad', > always give me the chills. Why should a perfectly good commit be > jinxed? > ... > Note that this change does not affect actual software quality maintained > using Git. Thus, it is recommended keep testing all generated versions > regardless of commit hash jinxes. > > Signed-off-by: Dan Aloni > --- Ah, I forgot that it's that time of the year again. > + ... > + oid_hex = oid_to_hex(&oid); > + if (prevent_bad && > + oid_hex[0] == 'b' && > + oid_hex[1] == 'a' && > + oid_hex[2] == 'd' ) > + { > + parents = copy_parents; > + strbuf_add(&sb, "\n", 1); > + continue; We used to allow a variant of this that lets you append invisible cruft at the end of the log message by hiding it after a NUL. You also could loop here to turn the abbreviated commit object name to an actively good one, not just "not bad" name ;-). > + } > + > + free_commit_list(copy_parents); > + break; > } > + > strbuf_release(&author_ident); > free_commit_extra_headers(extra);
Proposal
Hello Greetings to you today i asked before but i did't get a response please i know this might come to you as a surprise because you do not know me personally so i will give you a video call to explain more but did you get my previous email ? Let me know asap. Best Regards, Miss Melisa Mehmet Esentepe Mahallesi Büyükdere Caddesi Kristal Kule Binasi No:215 Sisli - Istanbul, Turkey
[ANNOUNCE] Git developers contacted by an advanced alien species
Members of an Alien species that have a far superior technology have recently privately contacted some Git developers. They said that they are amazed by Git technology and mostly wanted to thank us all for our hard work on Git, as they are surely going to use it due to its free software nature. At the same time they expressed that they are a bit appalled by the state of our free software operating systems like Linux, though they told us Windows might have been used by them if it was not proprietary and especially if it was faster at running the awesome Git test suite. The Git developers are all the more amazed by the fact that Dscho, the Git for Windows maintainer, had written just a few days before this contact (https://public-inbox.org/git/nycvar.qro.7.76.6.1803301415240.5...@qfpub.tvgsbejvaqbjf.bet/): "An alien digging up ancient Earth history in the far future might be tempted to assume that Git was developed to develop Linux which was developed to develop Git, and then ask herself why humans bothered at all."
[PATCH] graph.c: log.showRootMark to indicate root commits
When log.showRootMark is set, root commits are marked with the at sign (@). When log.showRootMark is not set, root commits are marked with the asterisk sign (*). This is the default behavior. Signed-off-by: Lyubomyr Shaydariv --- Documentation/config.txt | 5 + Documentation/git-log.txt | 5 + graph.c | 20 t/t4202-log.sh| 16 4 files changed, 46 insertions(+) diff --git a/Documentation/config.txt b/Documentation/config.txt index 4e0cff87f62f5..0a32357e3c625 100644 --- a/Documentation/config.txt +++ b/Documentation/config.txt @@ -2254,6 +2254,11 @@ log.showRoot:: Tools like linkgit:git-log[1] or linkgit:git-whatchanged[1], which normally hide the root commit will now show it. True by default. +log.showRootMark:: + If true, the initial commit in `git log --graph` will be marked + with the at sign (`@`). Otherwise the initial commit will be + marked with the default asterisk sign (`*`). False by default. + log.showSignature:: If true, makes linkgit:git-log[1], linkgit:git-show[1], and linkgit:git-whatchanged[1] assume `--show-signature`. diff --git a/Documentation/git-log.txt b/Documentation/git-log.txt index 5437f8b0f0e66..7f5436231b6d7 100644 --- a/Documentation/git-log.txt +++ b/Documentation/git-log.txt @@ -205,6 +205,11 @@ log.showRoot:: `git log -p` output would be shown without a diff attached. The default is `true`. +log.showRootMark:: + If true, the initial commit in `git log --graph` will be marked + with the at sign (`@`). Otherwise the initial commit will be + marked with the default asterisk sign (`*`). False by default. + log.showSignature:: If `true`, `git log` and related commands will act as if the `--show-signature` option was passed to them. diff --git a/graph.c b/graph.c index e1f6d3bddb38a..d14ffec7a975c 100644 --- a/graph.c +++ b/graph.c @@ -80,6 +80,7 @@ static void graph_show_line_prefix(const struct diff_options *diffopt) static const char **column_colors; static unsigned short column_colors_max; +static int show_root_mark; static void parse_graph_colors_config(struct argv_array *colors, const char *string) { @@ -256,6 +257,16 @@ void graph_setup_line_prefix(struct diff_options *diffopt) } +static int git_graph_config(const char *var, const char *value, void *cb) +{ + if (!strcmp(var, "log.showrootmark")) { + show_root_mark = git_config_bool(var, value); + return 0; + } + + return git_default_config(var, value, cb); +} + struct git_graph *graph_init(struct rev_info *opt) { struct git_graph *graph = xmalloc(sizeof(struct git_graph)); @@ -276,6 +287,7 @@ struct git_graph *graph_init(struct rev_info *opt) custom_colors.argc - 1); } } + git_config(git_graph_config, NULL); graph->commit = NULL; graph->revs = opt; @@ -835,6 +847,14 @@ static void graph_output_commit_char(struct git_graph *graph, struct strbuf *sb) return; } + /* +* If the commit has no parents, it's a root commit +*/ + if (show_root_mark && !graph->num_parents) { + strbuf_addch(sb, '@'); + return; + } + /* * get_revision_mark() handles all other cases without assert() */ diff --git a/t/t4202-log.sh b/t/t4202-log.sh index 25b1f8cc73bc3..350e35264362f 100755 --- a/t/t4202-log.sh +++ b/t/t4202-log.sh @@ -455,6 +455,22 @@ test_expect_success 'simple log --graph' ' test_cmp expect actual ' +cat > expectexpect
Re: [PATCH] builtin/commit.c: prevent bad commits
On Sun, Apr 01, 2018 at 05:06:50PM +0300, Dan Aloni wrote: > These commits which have hashes starting with the hex string 'bad', > always give me the chills. Why should a perfectly good commit be > jinxed? > > Statistically, one of 4096 commits may be 'bad'. This change adds a > '--prevent-bad' switch to the commit command in order to prevent such > commit hashes from being generated. Internally, the commit is retried > with a slight commit meta-data modification - a newline is added to the > end of the commit message. The meta-data change results in a different > hash, that if we are lucky enough (4095/4096 chance) may not be 'bad'. > > Note that this change does not affect actual software quality maintained > using Git. Thus, it is recommended keep testing all generated versions > regardless of commit hash jinxes. Cute. A while back we had patches to generate "desirable" commit prefixes, and they were focused on making the brute-forcing as fast as possible. I don't think I've seen this reverse case, but it's much easier: we can be fairly slow since the probability of hitting the bad case repeatedly is low. > @@ -1583,12 +1585,34 @@ int cmd_commit(int argc, const char **argv, const > char *prefix) > append_merge_tag_headers(parents, &tail); > } > > - if (commit_tree_extended(sb.buf, sb.len, &active_cache_tree->oid, > - parents, &oid, author_ident.buf, sign_commit, > - extra)) { > - rollback_index_files(); > - die(_("failed to write commit object")); > + for (;;) { > + char *oid_hex; > + struct commit_list *copy_parents; > + > + copy_parents = copy_commit_list(parents); > + > + if (commit_tree_extended(sb.buf, sb.len, > &active_cache_tree->oid, > + parents, &oid, author_ident.buf, > sign_commit, > + extra)) { > + rollback_index_files(); > + die(_("failed to write commit object")); > + } You could still have a "bad" tree. :) -Peff
Need help debugging issue in git
I'm struggling with a bug that I found introduced in git v2.13.2. The bug was not reproducible in v2.13.1. The issue is that using arguments like "@{-1}" to aliases causes those curly braces to be removed, so once the command is executed after alias processing the argument looks like "@-1". This breaks any aliases you have that wrap `git log` and such. I originally opened the bug on the Git for Windows project (since I use Git mostly on Windows): https://github.com/git-for-windows/git/issues/1220 After digging into the code of run-command.c some more, I have a change that fixes the issue but it doesn't feel like the right solution. Furthermore, the function I'm modifying doesn't seem to have been changed in the diff between v2.13.1 and v2.13.2. I'll provide my diff at the bottom of this email for those curious as to what I've modified. I was not able to reproduce this bug on Linux. However, the way aliases get expanded seems extremely wasteful. Essentially if an alias already has $@ in it, Git shouldn't try to insert another one. This results in the alias being repeated multiple times. I'll give you an example (Note there's a ton of detail in the github post linked earlier, and most of this is already there). Here is the alias being used for a test: [alias] lgtest = !git log --oneline \"$@\" And here is the command I invoke for the test: $ git lgtest @{-1} I should get logs for the previously-checked-out branch. When `prepare_shell_cmd()` is called in run-command.c, it gets expanded like so: + [0] "sh" const char * + [1] "-c" const char * + [2] "git log --oneline \"$@\" \"$@\"" const char * + [3] "git log --oneline \"$@\"" const char * + [4] "@{-1}" const char * With my modifications (again, patch inline below) I get this: + [0] "sh" const char * + [1] "-c" const char * + [2] "git log --oneline \"$@\"" const char * + [3] "@{-1}" const char * The second version looks much better. I think the constant nesting of commands inside each other that the first version does is somehow causing curly braces to be removed. I don't understand enough about shell processing to know why it would do this. Essentially I don't feel like I'm addressing the root cause here. I hope that someone has the time to take a peek and point me in the right direction. If I can make sense of this maybe I can make a proper fix somewhere. Here is the patch: diff --git a/run-command.c b/run-command.c index 31fc5ea86e..39bab7f5b2 100644 --- a/run-command.c +++ b/run-command.c @@ -261,10 +261,10 @@ static const char **prepare_shell_cmd(struct argv_array *out, const char **argv) if (!argv[1]) argv_array_push(out, argv[0]); else - argv_array_pushf(out, "%s \"$@\"", argv[0]); + argv_array_pushf(out, "%s", argv[0]); } - argv_array_pushv(out, argv); + argv_array_pushv(out, argv+1); return out->argv; }
[PATCH] ls-remote: create option to sort by versions
Create the options '-V ' and '--version-sort' to sort 'git ls-remote' output by version semantics. This is useful e.g. for the Go repository after the release of version 1.10, where otherwise v1.10 is sorted before v1.2. See: $ git ls-remote -t https://go.googlesource.com/go ... 205f850ceacfc39d1e9d76a9569416284594ce8crefs/tags/go1.1 d260448f6b6ac10efe4ae7f6dfe944e72bc2a676refs/tags/go1.1.1 1d6d8fca241bb611af51e265c1b5a2e9ae904702refs/tags/go1.1.2 bf86aec25972f3a100c3aa58a6abcbcc35bdea49refs/tags/go1.10 ac7c0ee26dda18076d5f6c151d8f920b43340ae3refs/tags/go1.10.1 9ce6b5c2ed5d3d5251b9a6a0c548d5fb2c8567e8refs/tags/go1.10beta1 594668a5a96267a46282ce3007a584ec07adf705refs/tags/go1.10beta2 5348aed83e39bd1d450d92d7f627e994c2db6ebfrefs/tags/go1.10rc1 20e228f2fdb44350c858de941dff4aea9f3127b8refs/tags/go1.10rc2 1c5438aae896edcd1e9f9618f4776517f08053b3refs/tags/go1.1rc2 46a6097aa7943a490e9bd2e04274845d0e5e200frefs/tags/go1.1rc3 402d3590b54e4a0df9fb51ed14b2999e85ce0b76refs/tags/go1.2 9c9802fad57c1bcb72ea98c5c55ea2652efc5772refs/tags/go1.2.1 ... Signed-off-by: Harald Nordgren --- builtin/ls-remote.c | 27 +-- 1 file changed, 25 insertions(+), 2 deletions(-) diff --git a/builtin/ls-remote.c b/builtin/ls-remote.c index 540d56429..740c6f117 100644 --- a/builtin/ls-remote.c +++ b/builtin/ls-remote.c @@ -1,6 +1,7 @@ #include "builtin.h" #include "cache.h" #include "transport.h" +#include "ref-filter.h" #include "remote.h" static const char * const ls_remote_usage[] = { @@ -33,11 +34,20 @@ static int tail_match(const char **pattern, const char *path) return 0; } +static int cmp_ref_versions(const void *_a, const void *_b) +{ + const struct ref *a = *(const struct ref **)_a; + const struct ref *b = *(const struct ref **)_b; + + return versioncmp(a->name, b->name); +} + int cmd_ls_remote(int argc, const char **argv, const char *prefix) { const char *dest = NULL; unsigned flags = 0; int get_url = 0; + int version_sort = 0; int quiet = 0; int status = 0; int show_symref_target = 0; @@ -47,6 +57,8 @@ int cmd_ls_remote(int argc, const char **argv, const char *prefix) struct remote *remote; struct transport *transport; const struct ref *ref; + const struct ref **refs = NULL; + int nr = 0; struct option options[] = { OPT__QUIET(&quiet, N_("do not print remote URL")), @@ -60,6 +72,8 @@ int cmd_ls_remote(int argc, const char **argv, const char *prefix) OPT_BIT(0, "refs", &flags, N_("do not show peeled tags"), REF_NORMAL), OPT_BOOL(0, "get-url", &get_url, N_("take url..insteadOf into account")), + OPT_BOOL('V', "version-sort", &version_sort, +N_("sort tags by version numbers")), OPT_SET_INT_F(0, "exit-code", &status, N_("exit with exit code 2 if no matching refs are found"), 2, PARSE_OPT_NOCOMPLETE), @@ -101,13 +115,22 @@ int cmd_ls_remote(int argc, const char **argv, const char *prefix) if (transport_disconnect(transport)) return 1; - if (!dest && !quiet) - fprintf(stderr, "From %s\n", *remote->url); for ( ; ref; ref = ref->next) { if (!check_ref_type(ref, flags)) continue; if (!tail_match(pattern, ref->name)) continue; + REALLOC_ARRAY(refs, nr + 1); + refs[nr++] = ref; + } + + if (version_sort) + QSORT(refs, nr, cmp_ref_versions); + + if (!dest && !quiet) + fprintf(stderr, "From %s\n", *remote->url); + for (int i = 0; i < nr; i++) { + const struct ref *ref = refs[i]; if (show_symref_target && ref->symref) printf("ref: %s\t%s\n", ref->symref, ref->name); printf("%s\t%s\n", oid_to_hex(&ref->old_oid), ref->name); -- 2.14.3 (Apple Git-98)
Re: [PATCH] Support long format for log-based submodule diff
On Tue, Mar 27, 2018 at 5:17 PM, Stefan Beller wrote: >> >> $ git diff --submodule=log --submodule-log-detail=(long|short) >> >> >> >> I'm not sure what makes sense here. I welcome thoughts/discussion and >> >> will provide follow-up patches. >> > >> > The case of merges is usually configured with --[no-]merges, or >> > --min-parents=. > >> But that is a knob that controls an irrelevant aspect of the detail >> in the context of this discussion, isn't it? This code is about "to >> what degree the things that happened between two submodule commits >> in an adjacent pair of commits in the superproject are summarized?" > > And I took it a step further and wanted to give a general solution, which > allows giving any option that the diff machinery accepts to only apply > to the submodule diffing part of the current diff. > >> The hack Robert illustrates below is to change it to stop favouring >> such projects with "clean" histories, and show "log --oneline >> --no-merges --left-right". When presented that way, clean histories >> of topic-branch based projects will suffer by losing conciseness, >> but clean histories of totally linear projects will still be shown >> the same way, and messy history that sometimes merges, sometimes >> merges mergy histories, and sometimes directly builds on the trunk >> will be shown as an enumeration of individual commits in a flat way >> by ignoring merges and not restricting the traversal to the first >> parent chains, which would appear more uniform than what the current >> code shows. > > Oh, I realize this is in the *summary* code path, I was thinking about the > show_submodule_inline_diff, which would benefit from more diff options. > >> I do not see a point in introducing --min/max-parents as a knob to >> control how the history is summarized. > > For a summary a flat list of commits may be fine, ignoring > (ideally non-evil) merges. > >> This is a strongly related tangent, but I wonder if we can and/or >> want to share more code with the codepath that prepares the log >> message for a merge. It summarizes what happened on the side branch >> since it forked from the history it is joining back to (I think it >> is merge.c::shortlog() that computes this) > > I do not find code there. To me it looks like builtin/fmt-merge-msg.c > is responsible for coming up with a default merge message? > In that file there is a shortlog() function, which walks revisions > and puts together the subject lines of commits. > >> and it is quite similar >> to what Robert wants to use for submodules here. On the other hand, >> in a project _without_ submodule, if you are pulling history made by >> your lieutenant whose history is full of linear merges of topic >> branches to the mainline, it may not be a bad idea to allow >> fmt-merge-msg to alternatively show something similar to the "diff >> --submodule=log" gives us, i.e. summarize the history of the side >> branch being merged by just listing the commits on the first-parent >> chain. So I sense some opportunity for cross pollination here. > > The cross pollination that I sense is the desire in both cases to freely > specify the format as it may depend on the workflow. First I want to apologize for having taken so long to get back with each of you about this. I actually have a lot of work started to expand the --submodule option to add a "full-log" option in addition to the existing "log". This is a pretty big task for me already, mostly because I'm unfamiliar with git and have limited personal time to do this at home (this is part of what I am apologizing for). I kind of get what Stefan and Junio are saying. There's a lot of opportunity for cleanup. More specific to my use case, adding some functionality to generate a log message (although I've developed a bash script to do this since I wrote my original email. I'll attach it to this email for those interested). Also I get that taking this a notch higher and adding a new option to pass options down to submodules also addresses my case. Before I waste anyone's time on this, I want to make sure that my very narrow and specific implementation will be ideal. By all means I do not want to do things the easy way which ends up adding "cruft" you'll have to deal with later. If there's a larger effort to generalize this and other things related to submodules maybe I can just wait for that to happen instead? What direction would you guys recommend? Junio basically hit the nail on the head with the comparisons of different mainlines. I think some repositories are more disciplined than others. At my workplace, I deal with a lot of folks that aren't interested in learning git beyond the required day to day responsibilities. It's difficult to enforce very specific branching, rebase, and merge habits. As such, the best I can do to work around that for building release notes is to exclude merge commits (since most of the time, people keep the default message which is generally useless) and include all
[RFC] git clone add option to track all remote branches
Hi, I am writing to ask that whether or not you think will be appropriate to add an option to "git clone" so that whenever a repo is cloned, branches are created automatically to track corresponding remote branches. (or is there any equivelant option?) You can obviously do this by a bash command like this git branch -r | grep -v '\->' | while read remote; do git branch --track "${remote#origin/}" "$remote"; done but it will be better if we can have an option in "git clone". Regards, Yubin
Re: [RFC] git clone add option to track all remote branches
Yubin Ruan writes: > I am writing to ask that whether or not you think will be appropriate to add > an option to "git clone" so that whenever a repo is cloned, branches are > created automatically to track corresponding remote branches. (or is there any > equivelant option?) > > You can obviously do this by a bash command like this > > git branch -r | grep -v '\->' | while read remote; do git branch --track > "${remote#origin/}" "$remote"; done > > but it will be better if we can have an option in "git clone". I am not sure how it will be more useful than what you already have. In short, you are getting "all of the remote branches" but with a twist. You get them "on demand". With your hypothetical "clone" command that makes copies of each and every remote branch to a local one, you can ask "git branch" to show all of them (i.e. "please list what is happening at the central repository"). With the current system, you would instead need to ask "git branch -r", which may be a bit more to type. Also when you want to look at or work on top of a remote branch, say "frotz", you do not have to do "git checkout -b frotz origin/frotz" to create one, as your hypothetical "clone" would have already created it when you cloned. But I think "git checkout frotz" in such a situation would create a local "frotz" branch out of the "origin/frotz" remote-tracking branch with the current system, so I do not think your hypothetical "clone" is all that more useful. And there certainly is a huge downside. If you are really doing your own development, then you would have some topic branches of your own, with forks of some (but most likely not all, especiallyi when there are many branches at the upstream) branches you got from the upstream, and "git branch --list" that shows only your own and what you are interested in (i.e. those that you actually bothered to "git checkout ") without showing random other branches that exist at the remote but do not interest you is a feature. Your hypothetical "clone" that indiscriminatedly forks all branches at remote locally will destroy the usefulness of it.
Re: [RFC] git clone add option to track all remote branches
Junio C Hamano writes: > If you are really doing your own development, then you would have > some topic branches of your own, with forks of some (but most likely > not all, especiallyi when there are many branches at the upstream) > branches you got from the upstream, and "git branch --list" that > shows only your own and what you are interested in (i.e. those that > you actually bothered to "git checkout ") without > showing random other branches that exist at the remote but do not > interest you is a feature. Your hypothetical "clone" that > indiscriminatedly forks all branches at remote locally will destroy > the usefulness of it. Related to this, a feature I have long thought we wished to have is complete opposite of this. After creating and working on a local topic branch and then concluding the work on it, a user would "git push" the branch out to a remote, and then check out a different branch (e.g. the 'master' branch). I wish we had a mode that would automatically *delete* the local topic branch that has already been pushed out (and more importantly, a branch that I have *done* with, at least for now), to unclutter my local branch namespace. When I want to further work on it, I can ask "git checkout" to dwim to recreate one on demand. Of course, there are some wrinkles due to pesky impleemntation details (e.g. the "autonuke-and-recreate" would lose reflog), but I do not think it is fundamental hurdle.
[PATCH 2/2] ls-remote: create option to sort by versions
Updating tests and documentation Signed-off-by: Harald Nordgren --- Documentation/git-ls-remote.txt | 5 + t/t5512-ls-remote.sh| 19 ++- 2 files changed, 23 insertions(+), 1 deletion(-) diff --git a/Documentation/git-ls-remote.txt b/Documentation/git-ls-remote.txt index 5f2628c8f..81c518a90 100644 --- a/Documentation/git-ls-remote.txt +++ b/Documentation/git-ls-remote.txt @@ -30,6 +30,11 @@ OPTIONS both, references stored in refs/heads and refs/tags are displayed. +-V:: +--version-sort:: + Sort ref names by version semantics, so that refs/tags/v1.2 is sorted + before refs/tags/v1.10. + --refs:: Do not show peeled tags or pseudorefs like HEAD in the output. diff --git a/t/t5512-ls-remote.sh b/t/t5512-ls-remote.sh index 02106c922..680a31223 100755 --- a/t/t5512-ls-remote.sh +++ b/t/t5512-ls-remote.sh @@ -10,6 +10,9 @@ test_expect_success setup ' test_tick && git commit -m initial && git tag mark && + git tag mark1.1 && + git tag mark1.2 && + git tag mark1.10 && git show-ref --tags -d | sed -e "s/ / /" >expected.tag && ( echo "$(git rev-parse HEAD) HEAD" @@ -39,6 +42,17 @@ test_expect_success 'ls-remote self' ' test_cmp expected.all actual ' +test_expect_success 'ls-remote --version-sort --tags self' ' + cat >expect <<-\EOF && + 1bd44cb9d13204b0fe1958db0082f5028a16eb3arefs/tags/mark + 1bd44cb9d13204b0fe1958db0082f5028a16eb3arefs/tags/mark1.1 + 1bd44cb9d13204b0fe1958db0082f5028a16eb3arefs/tags/mark1.2 + 1bd44cb9d13204b0fe1958db0082f5028a16eb3arefs/tags/mark1.10 + EOF + git ls-remote --version-sort --tags self >actual && + test_cmp expect actual +' + test_expect_success 'dies when no remote specified and no default remotes found' ' test_must_fail git ls-remote ' @@ -131,7 +145,7 @@ test_expect_success 'Report no-match with --exit-code' ' test_expect_success 'Report match with --exit-code' ' git ls-remote --exit-code other.git "refs/tags/*" >actual && - git ls-remote . tags/mark >expect && + git ls-remote . tags/mark* >expect && test_cmp expect actual ' @@ -178,6 +192,9 @@ test_expect_success 'ls-remote --symref' ' 1bd44cb9d13204b0fe1958db0082f5028a16eb3arefs/remotes/origin/HEAD 1bd44cb9d13204b0fe1958db0082f5028a16eb3a refs/remotes/origin/master 1bd44cb9d13204b0fe1958db0082f5028a16eb3arefs/tags/mark + 1bd44cb9d13204b0fe1958db0082f5028a16eb3arefs/tags/mark1.1 + 1bd44cb9d13204b0fe1958db0082f5028a16eb3arefs/tags/mark1.10 + 1bd44cb9d13204b0fe1958db0082f5028a16eb3arefs/tags/mark1.2 EOF git ls-remote --symref >actual && test_cmp expect actual -- 2.14.3 (Apple Git-98)
RE: [RFC] git clone add option to track all remote branches
On April 1, 2018 11:22 PM Junio C Hamano wrote: > Junio C Hamano writes: > > If you are really doing your own development, then you would have some > > topic branches of your own, with forks of some (but most likely not > > all, especiallyi when there are many branches at the upstream) > > branches you got from the upstream, and "git branch --list" that shows > > only your own and what you are interested in (i.e. those that you > > actually bothered to "git checkout ") without showing > > random other branches that exist at the remote but do not interest you > > is a feature. Your hypothetical "clone" that indiscriminatedly forks > > all branches at remote locally will destroy the usefulness of it. > > Related to this, a feature I have long thought we wished to have is complete > opposite of this. After creating and working on a local topic branch and then > concluding the work on it, a user would "git push" the branch out to a > remote, and then check out a different branch (e.g. the 'master' branch). I > wish we had a mode that would automatically *delete* the local topic branch > that has already been pushed out (and more importantly, a branch that I > have *done* with, at least for now), to unclutter my local branch > namespace. When I want to further work on it, I can ask "git checkout" to > dwim to recreate one on demand. > > Of course, there are some wrinkles due to pesky impleemntation details > (e.g. the "autonuke-and-recreate" would lose reflog), but I do not think it is > fundamental hurdle. I'm a little skeptical and confused here. The original RFC does not appear to stipulate that this is isolated to a single bare. If B,C,D all clone A.git from one server, it might be ok. If B clones A.git, and C clones B, and D mirrors C, where would the remote tracking occur. The main value, as a repo admin of A.git would be to know everything, but that's unlikely. Stating the obvious rub is, in a DVCS, where connections are not guaranteed, one can easily move a clone or delete a clone, and your tracking branch becomes worthless. You might never know about C/D mirrors or even be able to establish a connection between A.git and those two, in practice - I have examples of those. OTOH I have been toying with suggesting a solution to this for a couple of years, differentiating a transient clone from a (pick a term) authentic clone, the latter which has some blockchainish so that git will whine without a valid signature on the clone. Changing the clone without communicating with the upstream to revalidate it (deferrals could be implemented), temporarily or permanently invalidates the authentic clone so it effective becomes pruneable, like a worktree. I see a very deep potential rabbit hole here that detracts from DVCS principles unless we do have the conceptual split of the two classes of clones. rm .git is just too easy and too frequent an operation to just ignore the implication of the deliberate loss of tracking that is highly unlikely to be trackable by the farthest upstream, resulting in a whole lot of clutter with no way back. Alternatively, if the downstreams periodically are forced to revalidate the tracking branches, then you have sometime potentially workable but annoying at best, and impractical in some security policies at worst. Just my $0.02 from managing boat-loads of 4 and 5 level deep repositories. Cheers, Randall
Re: [RFC] Rebasing merges: a jorney to the ultimate solution(RoadClear)
Hi Johannes, Johannes Schindelin writes: > Hi Sergey, > [...] > In the parlance of your RFC v2, where you start with this history (which I > translated into the left-to-right notation that is used in pretty much all > of Git's own documentation about interactive rebases, which you apparently > either did not read, or chose *not* to imitate, creating yet another > unnecessary diversion): > > > - B1 > \ > - B2 - M First, it should rather be: - B1 \ M / - B2 as RFC presents essentially symmetric approach and I'd like it to be explicit. Representation in RFC simply saves some vertical space: M / \ B1 B2 Another reason to use it is that I liked to somehow indicate that this is about abstract DAG representation of Git history, not to be confused with some actual practical Git history. So that, for example, the reader can't be tempted to even try to assume that M has been necessarily created by "git merge" operation in the first place. That said, I'm sorry if it upsets you. I'll stick to your preferred notation below. > > You now insert U1 and U2 with trees identical to M: > > - B1 - U1 > \ > - B2 - U2 - M - B1 - U1 \ UM / - B2 - U2 _YES_. You've slightly screwed RFC as UM is not M anymore, having different parents, but otherwise it's still right. > So U1 is essentially B2 cherry-picked on top of B1, and U2 is essentially > B1 cherry-picked on top of B2. _NO_. No any cherry-picking has been involved, and I see absolutely no reason to pretend there has, except to intentionally make otherwise simple thing look tricky. U1 tree is still M tree, and U2 tree is still M tree, and UM tree is still M tree. That's what actually matters from RFC POV. > These U1/U2 commits are now to be cherry-picked on top of the rebased B1' > and B2'. I spare you more diagrams, you get the idea. _YES_. Exactly 2 cherry-picks. > Now, the changes in U1/U2 *are* the changes of the merge parents, that's > how they were constructed. Either _YES_, or _NO_, depending on the exact meaning of the term "the changes of the merge parents" you've used, but I suspect it's _NO_, taking into account your further inferences. The U1/U2 are constructed by simply duplicating the tree of the original merge commit M and thus they represent the changes _to_ the merge parents B1/B2 introduced by M, and not the changes "_of_ the merge parents" B1/B2, provided the latter meant to have some relation to the changes introduced by the merge parents B1/B2 themselves. > > Since they repeat what B1 and B2 are about, _NO_, they do not repeat what B1 and B2 are about at all. They rather represent what M is about. In other words, whatever B1 and B2 are about, the RFC method doesn't care. And as this is fundamental misinterpretation of the RFC on your side, it starts to be big _NO_ from now on... > and since B1'/B2' means they are rebased, and since U1'/U2' are *also* > rebased, but independently... > > ... you essentially have to rebase *every parent's changes > twice*. _NO_. U1' is rebase of U1 (on top of B1'), and U2' is rebase of U2 (on top of B2'). Each of U1/U2 is rebased only once. > The answer "No" to this is... astonishing. It's still _NO_, sorry. In fact, I could have said _NO_ the first time you started to assign some arbitrary "meaning" to the commits, as RFC is about somewhat formal proof of the method, using already well-known operations on the DAG, and to criticize the RFC, you need to either find and show a _formal_ mistake somewhere in the proof logic, or to show a use-case where it fails, as you did for RFC v1. Assigning arbitrary "meaning" to the DAG nodes and operations on them won't do the trick, sorry. I'd like to reach some agreement on formal correctness of the RFC first, and then discuss the meanings, the implementations, and other consequences based on well-established formal base. -- Sergey
Re: [PATCH] ls-remote: create option to sort by versions
On Mon, Apr 02 2018, Harald Nordgren wrote: > Create the options '-V ' and '--version-sort' to sort > 'git ls-remote' output by version semantics. This is useful e.g. for > the Go repository after the release of version 1.10, where otherwise > v1.10 is sorted before v1.2. See: > > $ git ls-remote -t https://go.googlesource.com/go > ... > 205f850ceacfc39d1e9d76a9569416284594ce8crefs/tags/go1.1 > d260448f6b6ac10efe4ae7f6dfe944e72bc2a676refs/tags/go1.1.1 > 1d6d8fca241bb611af51e265c1b5a2e9ae904702refs/tags/go1.1.2 > bf86aec25972f3a100c3aa58a6abcbcc35bdea49refs/tags/go1.10 > ac7c0ee26dda18076d5f6c151d8f920b43340ae3refs/tags/go1.10.1 > 9ce6b5c2ed5d3d5251b9a6a0c548d5fb2c8567e8refs/tags/go1.10beta1 > 594668a5a96267a46282ce3007a584ec07adf705refs/tags/go1.10beta2 > 5348aed83e39bd1d450d92d7f627e994c2db6ebfrefs/tags/go1.10rc1 > 20e228f2fdb44350c858de941dff4aea9f3127b8refs/tags/go1.10rc2 > 1c5438aae896edcd1e9f9618f4776517f08053b3refs/tags/go1.1rc2 > 46a6097aa7943a490e9bd2e04274845d0e5e200frefs/tags/go1.1rc3 > 402d3590b54e4a0df9fb51ed14b2999e85ce0b76refs/tags/go1.2 > 9c9802fad57c1bcb72ea98c5c55ea2652efc5772refs/tags/go1.2.1 > ... This is a sensible thing to want, but why not follow the UI we have for this with git-tag? I.e. --sort= & -i (or --ignore-case)? Of course ls-remote doesn't just show tags, so maybe we'd want --tag-sort= and --ignore-tag-case or something, but the rest should be equivalent, no? > [...] > @@ -101,13 +115,22 @@ int cmd_ls_remote(int argc, const char **argv, const > char *prefix) > if (transport_disconnect(transport)) > return 1; > > - if (!dest && !quiet) > - fprintf(stderr, "From %s\n", *remote->url); > for ( ; ref; ref = ref->next) { > if (!check_ref_type(ref, flags)) > continue; > if (!tail_match(pattern, ref->name)) > continue; > + REALLOC_ARRAY(refs, nr + 1); > + refs[nr++] = ref; > + } > + > + if (version_sort) > + QSORT(refs, nr, cmp_ref_versions); > + > + if (!dest && !quiet) > + fprintf(stderr, "From %s\n", *remote->url); Is there some subtlety here I'm missing which means that when sorting we'd now need to print this "From" line later (i.e. after sorting?
Re: Need help debugging issue in git
Am 02.04.2018 um 02:36 schrieb Robert Dailey: I'm struggling with a bug that I found introduced in git v2.13.2. The bug was not reproducible in v2.13.1. The issue is that using arguments like "@{-1}" to aliases causes those curly braces to be removed, so once the command is executed after alias processing the argument looks like "@-1". This breaks any aliases you have that wrap `git log` and such. I originally opened the bug on the Git for Windows project (since I use Git mostly on Windows): https://github.com/git-for-windows/git/issues/1220 ... Here is the alias being used for a test: [alias] lgtest = !git log --oneline \"$@\" And here is the command I invoke for the test: $ git lgtest @{-1} I should get logs for the previously-checked-out branch. When `prepare_shell_cmd()` is called in run-command.c, it gets expanded like so: + [0] "sh" const char * + [1] "-c" const char * + [2] "git log --oneline \"$@\" \"$@\"" const char * + [3] "git log --oneline \"$@\"" const char * + [4] "@{-1}" const char * With my modifications (again, patch inline below) I get this: + [0] "sh" const char * + [1] "-c" const char * + [2] "git log --oneline \"$@\"" const char * + [3] "@{-1}" const char * The second version looks much better. But this is wrong. Try this on the command line: sh -c 'echo "$@"' a b c Notice how this prints only 'b c', not 'a b c'. The reason is that the argument 'a' is treated like a "script" name, i.e. what you get for "$0", and 'b' and 'c' as the actual arguments to the "script". That is, you must fill in some dummy "script" name at slot [3], and run_command chooses to put the alias text there. I think the constant nesting of commands inside each other that the first version does is somehow causing curly braces to be removed. I don't understand enough about shell processing to know why it would do this. Some shells expand the curly braces. They must get lost somewhere by one of the two shell invocations that happen on the way. BTW, you don't happen to have a file named '@-1' in your directory, most likely by accident? -- Hannes