Re: [PATCH] printk: Remove no longer used second struct cont
On Thu, 2016-12-15 at 21:00 -0800, Junio C Hamano wrote: > Joe Percheswrites: > > > grep 2.5.4 was the last version that supported the -P option to > > grep through for multiple lines. > > Does anybody know why it was dropped? perl compatible regexes in grep have always been "experimental" and never officially supported. >From the grep manual https://www.gnu.org/software/grep/manual/grep.html --perl-regexp Interpret the pattern as a Perl-compatible regular expression (PCRE). This is highly experimental, particularly when combined with the -z (--null-data) option, and ‘grep -P’ may warn of unimplemented features. See Other Options. It wasn't dropped so much as "enhanced" away. Oh well.
Re: [PATCH] printk: Remove no longer used second struct cont
Joe Percheswrites: > grep 2.5.4 was the last version that supported the -P option to > grep through for multiple lines. Does anybody know why it was dropped?
Re: Allow "git shortlog" to group by committer information
Linus Torvaldswrites: > On Thu, Dec 15, 2016 at 4:19 PM, Junio C Hamano wrote: >> >> This fell off the radar partly because of the distractions like >> "there are other attempts and other ways", and also because the >> message was not a text-plain that can be reviewed inline. Let me >> try to dig it up from the mail archive to see if I can find it. > > Sorry, I'll just re-send it without the attachment. I prefer inline > myself, but I thought you didn't care (and gmail makes it > unnecessarily hard). Thanks. I do care, but I try to be lenient for inexperienced contriburors, which you don't qualify ;-) Experienced ones are held to a higher standard.
Re: [PATCH] printk: Remove no longer used second struct cont
On Thu, 2016-12-15 at 18:10 -0800, Linus Torvalds wrote: > On Thu, Dec 15, 2016 at 5:57 PM, Joe Percheswrote: > > > > > > In fact, I thought we already upped the check-patch limit to 100? > > > > Nope, CodingStyle neither. > > > > Last time I tried was awhile ago. > > Ok, it must have been just talked about, and with the exceptions for > strings etc I may not have seen as many of the really annoying line > breaks lately. > > I don't mind a 80-column "soft limit" per se: if some code > consistently goes over 80 columns, there really is something seriously > wrong there. So 80 columns may well be the right limit for that kind > of check (or even less). Newspaper column widths were relatively small for a good reason. I think most of the uses of simple statements should be on a single line. I'd rather see just a few arguments on a single line than a dozen though. Especially those with long identifiers, functions with many arguments are just difficult to visually scan. > But if we have just a couple of lines that are longer (in a file that > is 3k+ lines), I'd rather not break those. > > I tend use "git grep" a lot, and it's much easier to see function > argument use if it's all on one line. > > Of course, some function calls really are *so* long that they have to > be broken up, but that's where the "if it's a couple of lines that go > a bit over the 80 column limit..." exception basically comes in. > > Put another way: long lines definitely aren't good. But breaking long > lines has some downsides too, so there should be a balance between the > two, rather than some black-and-white limit. > > In fact, we've seldom had cases where black-and-white limits work well. One thing that _would_ be useful is some enhancement to git grep that would look for multi-line statements more easily. The git grep -P option doesn't span lines. grep 2.5.4 was the last version that supported the -P option to grep through for multiple lines. It'd be nice to have something like git grep --code_style=c90 --function that'd show all multiple line uses/definitions/declarations of a particular function. I played with extending git grep a bit once, mostly to get the \s mechanism to span lines. It kinda worked. Still, it seems like real work to implement well.
[PATCH 3/3] t: use nongit() function where applicable
Many tests want to run a command outside of any git repo; with the nongit() function this is now a one-liner. It saves a few lines, but more importantly, it's immediately obvious what the code is trying to accomplish. This doesn't convert every such case in the test suite; it just covers those that want to do a one-off command. Other cases, such as the ones in t4035, are part of a larger scheme of outside-repo files, and it's less confusing for them to stay consistent with the surrounding tests. Signed-off-by: Jeff King--- This one is obviously not necessary for the rest of the series, but the diffstat is certainly pleasing. t/t1308-config-set.sh| 10 ++ t/t9100-git-svn-basic.sh | 17 ++--- t/t9902-completion.sh| 7 +-- 3 files changed, 5 insertions(+), 29 deletions(-) diff --git a/t/t1308-config-set.sh b/t/t1308-config-set.sh index 7655c94c28..ff50960cca 100755 --- a/t/t1308-config-set.sh +++ b/t/t1308-config-set.sh @@ -219,14 +219,8 @@ test_expect_success 'check line errors for malformed values' ' ' test_expect_success 'error on modifying repo config without repo' ' - mkdir no-repo && - ( - GIT_CEILING_DIRECTORIES=$(pwd) && - export GIT_CEILING_DIRECTORIES && - cd no-repo && - test_must_fail git config a.b c 2>err && - grep "not in a git directory" err - ) + nongit test_must_fail git config a.b c 2>err && + grep "not in a git directory" err ' cmdline_config="'foo.bar=from-cmdline'" diff --git a/t/t9100-git-svn-basic.sh b/t/t9100-git-svn-basic.sh index 92a3aa8063..8a8ba65a2a 100755 --- a/t/t9100-git-svn-basic.sh +++ b/t/t9100-git-svn-basic.sh @@ -17,25 +17,12 @@ case "$GIT_SVN_LC_ALL" in ;; esac -deepdir=nothing-above -ceiling=$PWD - test_expect_success 'git svn --version works anywhere' ' - mkdir -p "$deepdir" && ( - GIT_CEILING_DIRECTORIES="$ceiling" && - export GIT_CEILING_DIRECTORIES && - cd "$deepdir" && - git svn --version - ) + nongit git svn --version ' test_expect_success 'git svn help works anywhere' ' - mkdir -p "$deepdir" && ( - GIT_CEILING_DIRECTORIES="$ceiling" && - export GIT_CEILING_DIRECTORIES && - cd "$deepdir" && - git svn help - ) + nongit git svn help ' test_expect_success \ diff --git a/t/t9902-completion.sh b/t/t9902-completion.sh index 2ba62fbc17..a34e55f874 100755 --- a/t/t9902-completion.sh +++ b/t/t9902-completion.sh @@ -257,12 +257,7 @@ test_expect_success SYMLINKS '__gitdir - resulting path avoids symlinks' ' ' test_expect_success '__gitdir - not a git repository' ' - ( - cd subdir/subsubdir && - GIT_CEILING_DIRECTORIES="$TRASH_DIRECTORY" && - export GIT_CEILING_DIRECTORIES && - test_must_fail __gitdir - ) + nongit test_must_fail __gitdir ' test_expect_success '__gitcomp - trailing space - options' ' -- 2.11.0.348.g960a0b554
[PATCH 2/3] index-pack: complain when --stdin is used outside of a repo
The index-pack builtin is marked as RUN_SETUP_GENTLY, because it's perfectly fine to index a pack in the filesystem outside of any repository. However, --stdin mode will write the result to the object database, which does not make sense outside of a repository. Doing so creates a bogus ".git" directory with nothing in it except the newly-created pack and its index. Instead, let's flag this as an error and abort. Signed-off-by: Jeff King--- builtin/index-pack.c | 2 ++ t/t5300-pack-object.sh | 15 +++ 2 files changed, 17 insertions(+) diff --git a/builtin/index-pack.c b/builtin/index-pack.c index 0a27bab11b..d450a6ada2 100644 --- a/builtin/index-pack.c +++ b/builtin/index-pack.c @@ -1730,6 +1730,8 @@ int cmd_index_pack(int argc, const char **argv, const char *prefix) usage(index_pack_usage); if (fix_thin_pack && !from_stdin) die(_("--fix-thin cannot be used without --stdin")); + if (from_stdin && !startup_info->have_repository) + die(_("--stdin requires a git repository")); if (!index_name && pack_name) index_name = derive_filename(pack_name, ".idx", _name_buf); if (keep_msg && !keep_name && pack_name) diff --git a/t/t5300-pack-object.sh b/t/t5300-pack-object.sh index 899e52d50f..43a672c345 100755 --- a/t/t5300-pack-object.sh +++ b/t/t5300-pack-object.sh @@ -406,6 +406,21 @@ test_expect_success 'verify resulting packs' ' git verify-pack test-11-*.pack ' +test_expect_success 'set up pack for non-repo tests' ' + # make sure we have a pack with no matching index file + cp test-1-*.pack foo.pack +' + +test_expect_success 'index-pack --stdin complains of non-repo' ' + nongit test_must_fail git index-pack --stdin works in non-repo' ' + nongit git index-pack ../foo.pack && + test_path_is_file foo.idx +' + # # WARNING! # -- 2.11.0.348.g960a0b554
[PATCH 1/3] t5000: extract nongit function to test-lib-functions.sh
This function abstracts the idea of running a command outside of any repository (which is slightly awkward to do because even if you make a non-repo directory, git may keep walking up outside of the trash directory). There are several scripts that use the same technique, so let's make the function available for everyone. Signed-off-by: Jeff King--- I waffled on the name. Something like test_outside_repo() is more descriptive, but as this is prepended to existing commands, the lines already end up quite long. t/t5000-tar-tree.sh | 14 -- t/test-lib-functions.sh | 14 ++ 2 files changed, 14 insertions(+), 14 deletions(-) diff --git a/t/t5000-tar-tree.sh b/t/t5000-tar-tree.sh index 830bf2a2f6..886b6953e4 100755 --- a/t/t5000-tar-tree.sh +++ b/t/t5000-tar-tree.sh @@ -94,20 +94,6 @@ check_tar() { ' } -# run "$@" inside a non-git directory -nongit () { - test -d non-repo || - mkdir non-repo || - return 1 - - ( - GIT_CEILING_DIRECTORIES=$(pwd) && - export GIT_CEILING_DIRECTORIES && - cd non-repo && - "$@" - ) -} - test_expect_success \ 'populate workdir' \ 'mkdir a && diff --git a/t/test-lib-functions.sh b/t/test-lib-functions.sh index fdaeb3a96b..adab7f51f4 100644 --- a/t/test-lib-functions.sh +++ b/t/test-lib-functions.sh @@ -994,3 +994,17 @@ test_copy_bytes () { } ' - "$1" } + +# run "$@" inside a non-git directory +nongit () { + test -d non-repo || + mkdir non-repo || + return 1 + + ( + GIT_CEILING_DIRECTORIES=$(pwd) && + export GIT_CEILING_DIRECTORIES && + cd non-repo && + "$@" + ) +} -- 2.11.0.348.g960a0b554
Re: index-pack outside of repository?
On Thu, Dec 15, 2016 at 08:37:28PM -0500, Jeff King wrote: > But if this case really is just "if (from_stdin)" that's quite easy, > too. So here is that patch (with some associated refactoring and cleanups). This is conceptually independent of jk/no-looking-at-dotgit-outside-repo-final, though it should be fine to merge with that topic. The BUG will actually pass the new test, because it calls die, too. I wonder if we should die with a unique error code on BUGs, and catch them in test_must_fail similar to the way we catch signal death. [1/3]: t5000: extract nongit function to test-lib-functions.sh [2/3]: index-pack: complain when --stdin is used outside of a repo [3/3]: t: use nongit() function where applicable builtin/index-pack.c | 2 ++ t/t1308-config-set.sh| 10 ++ t/t5000-tar-tree.sh | 14 -- t/t5300-pack-object.sh | 15 +++ t/t9100-git-svn-basic.sh | 17 ++--- t/t9902-completion.sh| 7 +-- t/test-lib-functions.sh | 14 ++ 7 files changed, 36 insertions(+), 43 deletions(-) -Peff
Re: Allow "git shortlog" to group by committer information
On Thursday, December 15, 2016 5:39:53 PM MST Linus Torvalds wrote: > On Thu, Dec 15, 2016 at 4:19 PM, Junio C Hamanowrote: > > Sorry, I'll just re-send it without the attachment. I prefer inline > myself, but I thought you didn't care (and gmail makes it > unnecessarily hard). > > Linus Why does gmail make it unnecessarily hard? I thought that a good percentage of the kernel maintainers use git send-email. what would make that command easier to use with gmail? sps
Re: Allow "git shortlog" to group by committer information
On Thu, Dec 15, 2016 at 5:51 PM, Stephen & Linda Smithwrote: > > Why does gmail make it unnecessarily hard? I read email with the gmail web interface, which is wonderful because of the server-side searching etc. The only real downside is the weak threading, but you get used to it. I personally find IMAP and POP to be a tool of the devil, and have never had a good experience with them as a mail interface. In theory IMAP is supposed to support server-side searches, in practice it never worked for me. But the problem with sending patches using the web interface is that you cannot attach things inline without gmail screwing up whitespace. I suggested to some googler that a "attach inline" checkbox in the would be a wonderful option for text attachments, but considering that the android gmail app still has no text-only option I don't think that suggestion went anywhere. > I thought that a good percentage of the kernel maintainers use git send-email. > what would make that command easier to use with gmail? Oh, I can send inline stuff (as I just re-sent that patch), but then I have to fire up alpine and do it the old-fashioned way. So it's an extra step. So since I spend all my time at the gmail web interface _anyway_, the attachment model ends up being the slightly more convenient one. And sure, I could use git-send-email as that extra step instead, but I'd rather just use alpine. That's the extra step I do for some other things (ie the "200-email patch-bomb from Andrew Morton" things - I'm not using the web interface for _that_). Linus
[PATCH 1/1] Allow "git shortlog" to group by committer information
From: Linus TorvaldsSubject: Allow "git shortlog" to group by committer information Date: Tue, 11 Oct 2016 11:45:58 -0700 In some situations you may want to group the commits not by author, but by committer instead. For example, when I just wanted to look up what I'm still missing from linux-next in the current merge window, I don't care so much about who wrote a patch, as what git tree it came from, which generally boils down to "who committed it". So make git shortlog take a "-c" or "--committer" option to switch grouping to that. During the merge window this allows me to do things like git shortlog -cnse linus..next | head -20 | cut -f2 | sed 's/$/,/' to easily create a list of the top-20 committers that I haven't gotten pull requests from yet (the committer is not necessarily the person who will send the pull request, but it's a reasonably good approximation). Signed-off-by: Linus Torvalds --- builtin/shortlog.c | 15 --- shortlog.h | 1 + 2 files changed, 13 insertions(+), 3 deletions(-) diff --git a/builtin/shortlog.c b/builtin/shortlog.c index ba0e1154a..c9585d475 100644 --- a/builtin/shortlog.c +++ b/builtin/shortlog.c @@ -117,11 +117,15 @@ static void read_from_stdin(struct shortlog *log) { struct strbuf author = STRBUF_INIT; struct strbuf oneline = STRBUF_INIT; + static const char *author_match[2] = { "Author: ", "author " }; + static const char *committer_match[2] = { "Commit: ", "committer " }; + const char **match; + match = log->committer ? committer_match : author_match; while (strbuf_getline_lf(, stdin) != EOF) { const char *v; - if (!skip_prefix(author.buf, "Author: ", ) && - !skip_prefix(author.buf, "author ", )) + if (!skip_prefix(author.buf, match[0], ) && + !skip_prefix(author.buf, match[1], )) continue; while (strbuf_getline_lf(, stdin) != EOF && oneline.len) @@ -140,6 +144,7 @@ void shortlog_add_commit(struct shortlog *log, struct commit *commit) struct strbuf author = STRBUF_INIT; struct strbuf oneline = STRBUF_INIT; struct pretty_print_context ctx = {0}; + const char *fmt; ctx.fmt = CMIT_FMT_USERFORMAT; ctx.abbrev = log->abbrev; @@ -148,7 +153,9 @@ void shortlog_add_commit(struct shortlog *log, struct commit *commit) ctx.date_mode.type = DATE_NORMAL; ctx.output_encoding = get_log_output_encoding(); - format_commit_message(commit, "%an <%ae>", , ); + fmt = log->committer ? "%cn <%ce>" : "%an <%ae>"; + + format_commit_message(commit, fmt, , ); if (!log->summary) { if (log->user_format) pretty_print_commit(, commit, ); @@ -238,6 +245,8 @@ int cmd_shortlog(int argc, const char **argv, const char *prefix) int nongit = !startup_info->have_repository; const struct option options[] = { + OPT_BOOL('c', "committer", , +N_("Group by committer rather than author")), OPT_BOOL('n', "numbered", _by_number, N_("sort output according to the number of commits per author")), OPT_BOOL('s', "summary", , diff --git a/shortlog.h b/shortlog.h index 5a326c686..5d64cfe92 100644 --- a/shortlog.h +++ b/shortlog.h @@ -13,6 +13,7 @@ struct shortlog { int in2; int user_format; int abbrev; + int committer; char *common_repo_prefix; int email;
Re: Allow "git shortlog" to group by committer information
On Thu, Dec 15, 2016 at 4:19 PM, Junio C Hamanowrote: > > This fell off the radar partly because of the distractions like > "there are other attempts and other ways", and also because the > message was not a text-plain that can be reviewed inline. Let me > try to dig it up from the mail archive to see if I can find it. Sorry, I'll just re-send it without the attachment. I prefer inline myself, but I thought you didn't care (and gmail makes it unnecessarily hard). Linus
Re: index-pack outside of repository?
On Thu, Dec 15, 2016 at 04:13:38PM -0800, Junio C Hamano wrote: > > So I think complaining to the user is the right thing to do here. I > > started to write a patch to have index-pack notice when it needs a repo > > and doesn't have one, but the logic is actually a bit unclear. Do we > > need to complain early _just_ when --stdin is specified, or does that > > miss somes cases? Likewise, are there cases where --stdin can operate > > without a repo? I couldn't think of any. > > I think there are two and only two major modes; --stdin wants to put > the result in the repository it is working on, while the other mode > takes a filename to deposit the result in, so the latter does not > technically need a repository. OK. That's easy to check for, then. Reverse-engineering that logic from the actual calls in index-pack.c:final() is complicated. But certainly basing it on --stdin is what I would have expected. > > That strategy _might_ be a problem for some programs, which would want > > to notice the issue early before doing work. But it seems like a > > reasonable outcome for index-pack. Thoughts? > > That is, once we know which codepaths should require a repository, I > think it is reasonable to add a check that is done earlier than the > place where we currently try to see where we have one (which could > be deep in the callchain). But we are all human and can miss things, > so the BUG() thing is probably fine. We are cooking it exactly because > we would want to find such corner cases we missed, no? Right, that was my original intent in adding the BUG(): to catch unhandled cases, and then do the appropriate thing earlier. I was just questioning whether the appropriate thing in some cases might be dying at the BUG(), just with a more friendly message. That has the benefit of being very easy to implement, and never wrong (e.g., forbidding a case that actually _doesn't_ need to look at the repo). But if this case really is just "if (from_stdin)" that's quite easy, too. -Peff
Re: Allow "git shortlog" to group by committer information
Linus Torvaldswrites: > Just a ping on this patch.. > > Jeff had apparently done something similar as part of a bigger > patch-series, but I don't see that either. I really don't care very > much how this is done, but I do find this very useful, ... > > Yes, I can just maintain this myself, and maybe nobody else needs it, > but it's pretty simple and straightforward, and there didn't seem to > be any real reason not to have the option.. This fell off the radar partly because of the distractions like "there are other attempts and other ways", and also because the message was not a text-plain that can be reviewed inline. Let me try to dig it up from the mail archive to see if I can find it.
Re: index-pack outside of repository?
Jeff Kingwrites: > In older versions of git will just blindly write into > ".git/objects/pack", even though there's no repository there. > > So I think complaining to the user is the right thing to do here. I > started to write a patch to have index-pack notice when it needs a repo > and doesn't have one, but the logic is actually a bit unclear. Do we > need to complain early _just_ when --stdin is specified, or does that > miss somes cases? Likewise, are there cases where --stdin can operate > without a repo? I couldn't think of any. I think there are two and only two major modes; --stdin wants to put the result in the repository it is working on, while the other mode takes a filename to deposit the result in, so the latter does not technically need a repository. > I'm actually wondering if the way it calls die() in 'next' is a pretty > reasonable way for things to work in general. It happens when we lazily > try to ask for the repository directory. So we don't have to replicate > logic to say "are we going to need a repo"; at the moment we need it, we > notice we don't have it and die. The only problem is that it says "BUG" > and not "this operation must be run in a git repository". Isn't what we currently have is a good way to discover which codepaths we missed to add a check to issue the latter error? > That strategy _might_ be a problem for some programs, which would want > to notice the issue early before doing work. But it seems like a > reasonable outcome for index-pack. Thoughts? That is, once we know which codepaths should require a repository, I think it is reasonable to add a check that is done earlier than the place where we currently try to see where we have one (which could be deep in the callchain). But we are all human and can miss things, so the BUG() thing is probably fine. We are cooking it exactly because we would want to find such corner cases we missed, no?
Re: Is there a way to have local changes in a branch 'bake' while working in different branches?
Larry Mintonwrites: > Lars Schneider recommended I ask you this question. > > My question: > > Let's say I have a code change that I want to 'bake' for a while > locally, just to make sure some edge case doesn't pop up while I > am working on other things. Is there any practical way of doing > that? That sounds exactly like what I have been doing for the past several years in public around here ;-)
[RFC/PATCH] Makefile: suppress some cppcheck false-positives
Pass a list of suppressions to cppcheck so that legitimate errors are more obvious. Signed-off-by: Chris Packham--- On Thu, Dec 15, 2016 at 12:24 AM, Jeff King wrote: > The patch itself is OK to me, I guess. The interesting part will be > whether people start actually _using_ cppcheck and squelching the false > positives. I'm not sure how I feel about the in-code annotations. I'd > have to see a patch first. So here's a patch that adds supression files. It would work well for things in contrib/compat that don't change that often. It would be a nightmare to maintain for high-touch code. Makefile | 7 ++- nedmalloc.supp | 4 regcomp.supp | 8 3 files changed, 18 insertions(+), 1 deletion(-) create mode 100644 nedmalloc.supp create mode 100644 regcomp.supp diff --git a/Makefile b/Makefile index e5c86decf..bb335ca0f 100644 --- a/Makefile +++ b/Makefile @@ -2637,7 +2637,12 @@ cover_db_html: cover_db .PHONY: cppcheck -CPPCHECK_FLAGS = --force --quiet --inline-suppr $(if $(CPPCHECK_ADD),--enable=$(CPPCHECK_ADD)) +CPPCHECK_SUPP = --suppressions-list=nedmalloc.supp \ + --suppressions-list=regcomp.supp + +CPPCHECK_FLAGS = --force --quiet --inline-suppr \ + $(if $(CPPCHECK_ADD),--enable=$(CPPCHECK_ADD)) \ + $(CPPCHECK_SUPP) cppcheck: @cppcheck --version diff --git a/nedmalloc.supp b/nedmalloc.supp new file mode 100644 index 0..37bd54def --- /dev/null +++ b/nedmalloc.supp @@ -0,0 +1,4 @@ +nullPointer:compat/nedmalloc/malloc.c.h:4093 +nullPointer:compat/nedmalloc/malloc.c.h:4106 +memleak:compat/nedmalloc/malloc.c.h:4646 + diff --git a/regcomp.supp b/regcomp.supp new file mode 100644 index 0..3ae023c26 --- /dev/null +++ b/regcomp.supp @@ -0,0 +1,8 @@ +memleak:compat/regex/regcomp.c:3086 +memleak:compat/regex/regcomp.c:3634 +memleak:compat/regex/regcomp.c:3086 +memleak:compat/regex/regcomp.c:3634 +uninitvar:compat/regex/regcomp.c:2802 +uninitvar:compat/regex/regcomp.c:2805 +memleak:compat/regex/regcomp.c:532 + -- 2.11.0.24.ge6920cf
Re: Is there a way to have local changes in a branch 'bake' while working in different branches?
At 20:14 + 15 Dec 2016, Larry Mintonwrote: Let's say I have a code change that I want to 'bake' for a while locally, just to make sure some edge case doesn't pop up while I am working on other things. Is there any practical way of doing that? I could constantly merge that 'bake me' branch into other branches as I work on them and then remove those changes from the branches before sending them out for code review, but sooner or later pretty much guaranteed to screw that up That sounds like the best way to me. How do you envision screwing it up? If you anticipate messing up while removing the changes, that's only likely if there are conflicts and any other strategy is likely to be worse there. If you suspect you'll forget to remove them before sending for code review there may be ways to help with that. Easiest you can add a large notice in the commit message(s) and/or comments; this may not prevent going for review but reviewers should catch it pretty quickly. To help prevent it even getting that far you may be able to add a pre-push hook to prevent such commits from being pushed to somewhere other than a private fork or a branch with a name that clearly indicates that it contains experimental code.
Re: [PATCH] README: replace gmane link with public-inbox
Jeff Kingwrote: > On Thu, Dec 15, 2016 at 02:57:18PM +0100, Chiel ten Brinke wrote: > > > Btw, the link in the README > > http://news.gmane.org/gmane.comp.version-control.git/ is dead. > > Yes, the status of gmane was up in the air for a while, but I think we > can give it up as dead now (at least for our purposes). s/http/nntp/ still works for gmane. > -- >8 -- > Subject: README: replace gmane link with public-inbox > > The general status and future of gmane is unclear at this > point, but certainly it does not seem to be carrying > gmane.comp.version-control.git at all anymore. Let's point > to public-inbox.org, which seems to be the favored archive > on the list these days (and which uses message-ids in its > URLs, making the links somewhat future-proof). No objections, here. There's also https://mail-archive.com/git@vger.kernel.org Where https://mid.mail-archive.com/ also works
Re: Allow "git shortlog" to group by committer information
Just a ping on this patch.. On Tue, Oct 11, 2016 at 11:45 AM, Linus Torvaldswrote: > In some situations you may want to group the commits not by author, > but by committer instead. > > For example, when I just wanted to look up what I'm still missing from > linux-next in the current merge window [..] It's another merge window later for the kernel, and I just re-applied this patch to my git tree because I still want to know teh committer information rather than the authorship information, and it still seems to be the simplest way to do that. Jeff had apparently done something similar as part of a bigger patch-series, but I don't see that either. I really don't care very much how this is done, but I do find this very useful, I do things like git shortlog -cnse linus..next | head -20 | cut -f2 | sed 's/$/,/' to generate a nice list of the top-20 committers that I haven't gotten pull requests from yet. Yes, I can just maintain this myself, and maybe nobody else needs it, but it's pretty simple and straightforward, and there didn't seem to be any real reason not to have the option.. Linus
index-pack outside of repository?
Running git on 'next', you can trigger a BUG: $ cd /some/repo $ git pack-objects --all --stdout /tmp/foo.pack $ cd /not-a-git-repo $ git index-pack --stdin
Is there a way to have local changes in a branch 'bake' while working in different branches?
Lars Schneider recommended I ask you this question. My question: Let's say I have a code change that I want to 'bake' for a while locally, just to make sure some edge case doesn't pop up while I am working on other things. Is there any practical way of doing that? I could constantly merge that 'bake me' branch into other branches as I work on them and then remove those changes from the branches before sending them out for code review, but sooner or later pretty much guaranteed to screw that up His response: Good question. Your merging idea would work but I agree it might be cumbersome. In this situation I keep modified files in my tree. That would work for you too, but this would be inconvenient if you have many changed files. I wonder how the Git core guys manage this kind of situation. Thanks, Larry Minton 3ds Max Core team LiveDesign Group Media & Entertainment, Education Experiences, Impact (MEI)
Re: [PATCH v2 07/34] sequencer (rebase -i): add support for the 'fixup' and 'squash' commands
On Thu, Dec 15, 2016 at 11:07:34AM -0800, Stefan Beller wrote: > On Thu, Dec 15, 2016 at 11:03 AM, Jeff Kingwrote: > > wonder if it would be helpful to send that output to the list. > > Sure we can try. > > Another project I used to run through coverity (Gerrit), shows > similar characteristics w.r.t. false positives, so people complained > when I was force feeding them the niceties of static analysis. > > I'll just try to set it up and see how the mailing list reacts. > (Not sure if you can just add emails there or if the email has > to be verified or such.) I see you added it, but I don't see the confirmation email on the list. I wonder if it was HTML mail and vger ate it. -Peff
Re: [PATCH v2 07/34] sequencer (rebase -i): add support for the 'fixup' and 'squash' commands
On Thu, Dec 15, 2016 at 11:20 AM, Jeff Kingwrote: > On Thu, Dec 15, 2016 at 11:07:34AM -0800, Stefan Beller wrote: > >> On Thu, Dec 15, 2016 at 11:03 AM, Jeff King wrote: >> > wonder if it would be helpful to send that output to the list. >> >> Sure we can try. >> >> Another project I used to run through coverity (Gerrit), shows >> similar characteristics w.r.t. false positives, so people complained >> when I was force feeding them the niceties of static analysis. >> >> I'll just try to set it up and see how the mailing list reacts. >> (Not sure if you can just add emails there or if the email has >> to be verified or such.) > > I see you added it, but I don't see the confirmation email on the list. > I wonder if it was HTML mail and vger ate it. > > -Peff I think I'll setup a dummy gmail account to use for subscription and then I'll configure that to forward all email from coverity to the list. (the actual complaints about memleaks etc are plain text, so that forwarding then should work)
Re: [PATCH v2 10/34] sequencer (rebase -i): allow continuing with staged changes
Johannes Schindelinwrites: > When an interactive rebase is interrupted, the user may stage changes > before continuing, and we need to commit those changes in that case. > > Please note that the nested "if" added to the sequencer_continue() is > not combined into a single "if" because it will be extended with an > "else" clause in a later patch in this patch series. > > Signed-off-by: Johannes Schindelin > --- > sequencer.c | 40 > 1 file changed, 40 insertions(+) > > diff --git a/sequencer.c b/sequencer.c > index 80469b6954..855d3ba503 100644 > --- a/sequencer.c > +++ b/sequencer.c > @@ -1829,6 +1829,42 @@ static int continue_single_pick(void) > return run_command_v_opt(argv, RUN_GIT_CMD); > } > > +static int commit_staged_changes(struct replay_opts *opts) > +{ > + int amend = 0; > + > + if (has_unstaged_changes(1)) > + return error(_("cannot rebase: You have unstaged changes.")); The scripted one from 'master' seems to say $path_to_the_file: needs update You must edit all merge conflicts and then mark them as resolved using git add when editing an existing commit in this case. The updated message looks more sensible for the situation, but I wonder if the control should even reach at this point. One bad thing about reviewing this series is that all the comments are about codepaths that are not exercised, so they cannot be more than "they look good". A comment "If the caller does X, this will be better than the original" (or this will regress, for that matter) cannot be validated for its relevance because we won't know the what the caller does in the endgame while reviewing these earlier steps.
Re: [PATCH v2 07/34] sequencer (rebase -i): add support for the 'fixup' and 'squash' commands
On Thu, Dec 15, 2016 at 11:03 AM, Jeff Kingwrote: > wonder if it would be helpful to send that output to the list. Sure we can try. Another project I used to run through coverity (Gerrit), shows similar characteristics w.r.t. false positives, so people complained when I was force feeding them the niceties of static analysis. I'll just try to set it up and see how the mailing list reacts. (Not sure if you can just add emails there or if the email has to be verified or such.) Thanks, Stefan
Re: [PATCH v2 07/34] sequencer (rebase -i): add support for the 'fixup' and 'squash' commands
On Tue, Dec 13, 2016 at 04:30:01PM +0100, Johannes Schindelin wrote: > + else { > + unsigned char head[20]; > + struct commit *head_commit; > + const char *head_message, *body; > + > + if (get_sha1("HEAD", head)) > + return error(_("need a HEAD to fixup")); > + if (!(head_commit = lookup_commit_reference(head))) > + return error(_("could not read HEAD")); > + if (!(head_message = get_commit_buffer(head_commit, NULL))) > + return error(_("could not read HEAD's commit message")); This get_commit_buffer() may allocate a fresh buffer... > + body = strstr(head_message, "\n\n"); > + if (!body) > + body = ""; > + else > + body = skip_blank_lines(body + 2); > + if (write_message(body, strlen(body), > + rebase_path_fixup_msg(), 0)) > + return error(_("cannot write '%s'"), > + rebase_path_fixup_msg()); ...and then this return leaks the result (the other code path hits unuse_commit_buffer(), and is fine). This leak was noticed by Coverity. It has a _ton_ of false positives across the whole project, but it sends out a mail with new ones every few days, which is usually short enough that I can process it in 30 seconds or so. I _think_ that email just goes to me and Stefan right now. You can add yourself at: https://scan.coverity.com/projects/git?tab=project_settings if you already have admin access to the project (which I think you (Dscho) do). I wonder if it would be helpful to send that output to the list. -Peff
Re: [PATCH v2 07/34] sequencer (rebase -i): add support for the 'fixup' and 'squash' commands
On Thu, Dec 15, 2016 at 10:42:53AM -0800, Junio C Hamano wrote: > > + sprintf((char *)p, "%d", ++count); > > Do we know the area pointed at p (which is inside buf) long enough > not to overflow? If the original were 9 and you incremented to get > 10, you would need one extra byte. Even if it is enough, I'd ask to please use xsnprintf(). In the off chance that there's a programming error, we'd get a nice die("BUG") instead of a buffer overflow (and it makes the code base easier to audit for other overflows). -Peff
Re: [PATCH v2 09/34] sequencer (rebase -i): write an author-script file
Johannes Schindelinwrites: > + strbuf_addstr(, "GIT_AUTHOR_NAME='"); > + while (*message && *message != '\n' && *message != '\r') > + if (skip_prefix(message, " <", )) > + break; > + else if (*message != '\'') > + strbuf_addch(, *(message++)); > + else > + strbuf_addf(, "'%c'", *(message++)); > + strbuf_addstr(, "'\nGIT_AUTHOR_EMAIL='"); > + while (*message && *message != '\n' && *message != '\r') > + if (skip_prefix(message, "> ", )) > + break; > + else if (*message != '\'') > + strbuf_addch(, *(message++)); > + else > + strbuf_addf(, "'%c'", *(message++)); Aren't these reading from an in-core commit object? If so, it should use split_ident_line() for consistency with other parts of the system to do this parsing. We should also already have a helper for simple shell-quoting in quote.c and you would want to use that instead of open coding like this.
Re: [PATCH v2 08/34] sequencer (rebase -i): implement the short commands
Johannes Schindelinwrites: > For users' convenience, most rebase commands can be abbreviated, e.g. > 'p' instead of 'pick' and 'x' instead of 'exec'. Let's teach the > sequencer to handle those abbreviated commands just fine. > > Signed-off-by: Johannes Schindelin > --- Sensible.
Re: [PATCH v2 07/34] sequencer (rebase -i): add support for the 'fixup' and 'squash' commands
Johannes Schindelinwrites: > diff --git a/sequencer.c b/sequencer.c > index f6e20b142a..271c21581d 100644 > --- a/sequencer.c > +++ b/sequencer.c > @@ -45,6 +45,35 @@ static GIT_PATH_FUNC(rebase_path_todo, > "rebase-merge/git-rebase-todo") > */ > static GIT_PATH_FUNC(rebase_path_done, "rebase-merge/done") > /* > + * The commit message that is planned to be used for any changes that > + * need to be committed following a user interaction. > + */ > +static GIT_PATH_FUNC(rebase_path_message, "rebase-merge/message") > +/* > + * The file into which is accumulated the suggested commit message for > + * squash/fixup commands. When the first of a series of squash/fixups The same comment as 03/34 applies here, regarding blank line to separate logical unit. > +static int update_squash_messages(enum todo_command command, > + struct commit *commit, struct replay_opts *opts) > +{ > + struct strbuf buf = STRBUF_INIT; > + int count, res; > + const char *message, *body; > + > + if (file_exists(rebase_path_squash_msg())) { > + char *p, *p2; > + > + if (strbuf_read_file(, rebase_path_squash_msg(), 2048) <= 0) > + return error(_("could not read '%s'"), > + rebase_path_squash_msg()); > + > + if (buf.buf[0] != comment_line_char || > + !skip_prefix(buf.buf + 1, " This is a combination of ", > + (const char **))) > + return error(_("unexpected 1st line of squash message:" > +"\n\n\t%.*s"), > + (int)(strchrnul(buf.buf, '\n') - buf.buf), > + buf.buf); > + count = strtol(p, , 10); > + > + if (count < 1 || *p2 != ' ') > + return error(_("invalid 1st line of squash message:\n" > +"\n\t%.*s"), > + (int)(strchrnul(buf.buf, '\n') - buf.buf), > + buf.buf); > + > + sprintf((char *)p, "%d", ++count); Do we know the area pointed at p (which is inside buf) long enough not to overflow? If the original were 9 and you incremented to get 10, you would need one extra byte. > + if (!*p2) > + *p2 = ' '; > + else { > + *(++p2) = 'c'; p2 points into buf; do we know this increment does not step beyond its end? What is the meaning of a letter 'c' here (I do not see a corresponding one in the scripted update_squash_messages)? > + strbuf_insert(, p2 - buf.buf, " ", 1); > + } > + } > + else { Style: "} else {" (I won't repeat this, as it will become too noisy). > + unsigned char head[20]; > + struct commit *head_commit; > + const char *head_message, *body; > + > + if (get_sha1("HEAD", head)) > + return error(_("need a HEAD to fixup")); > + if (!(head_commit = lookup_commit_reference(head))) > + return error(_("could not read HEAD")); > + if (!(head_message = get_commit_buffer(head_commit, NULL))) > + return error(_("could not read HEAD's commit message")); > + > + body = strstr(head_message, "\n\n"); > + if (!body) > + body = ""; > + else > + body = skip_blank_lines(body + 2); I think I saw you used a helper function find_commit_subject() to do the above in an earlier patch for "edit" in this series. Would it make this part (and another one for "commit" we have after this if/else) shorter? > static int do_pick_commit(enum todo_command command, struct commit *commit, > - struct replay_opts *opts) > + struct replay_opts *opts, int final_fixup) > { > + int edit = opts->edit, cleanup_commit_message = 0; > + const char *msg_file = edit ? NULL : git_path_merge_msg(); > unsigned char head[20]; > struct commit *base, *next, *parent; > const char *base_label, *next_label; > struct commit_message msg = { NULL, NULL, NULL, NULL }; > struct strbuf msgbuf = STRBUF_INIT; > - int res, unborn = 0, allow; > + int res, unborn = 0, amend = 0, allow; > > if (opts->no_commit) { > /* > @@ -749,7 +885,7 @@ static int do_pick_commit(enum todo_command command, > struct commit *commit, > else > parent = commit->parents->item; > > - if (opts->allow_ff && > + if (opts->allow_ff && !is_fixup(command) && > ((parent && !hashcmp(parent->object.oid.hash, head)) || >(!parent && unborn))) > return fast_forward_to(commit->object.oid.hash, head, unborn, > opts); > @@ -813,6 +949,28 @@ static int do_pick_commit(enum todo_command command, > struct
Re: git bug - merging JS / Node.js code with "git merge --squash"
Alexander Millswrites: > basically it is doing the merge with this line: > > git merge --squash -Xtheirs dev -m "squashing" && The order of command line parameters are "dashed options and their arguments first, then refs (and then pathspecs if exists), so you should make it a habit to move that "dev" at the end of the command line. This does not have anything to do with the issue you are asking for help, though. I suspect the problem is not in --squash but with -Xtheirs. It is "I give up correctly resolving conflicts and blindly take whatever comes from their side, discarding what I did". The "git merge" command stops and asks a human to help resolving a conflict using their brain when it needs to because the command knows it itself does not have any but the human user has a better one ;-). -Xtheirs and -Xours disables this safety/sanity. If you punt, it is expected that you would get garbage. For example, your side may have introduced a new function (or renamed an existing one) near where their side made a change that resulted in conflicts. Naturally, your side also would have added new callsites to that new function (you wouldn't be adding an unused function). Imagine in such a scenario that you asked "discard what I did in the conflicted section and blindly take whatever they did". What happens? They may not have done anything near the places you added calls to the new function and these sections of the code would merge cleanly with or without -Xtheirs, but the actual new function you added may be in the conflicted section that you asked to discard, taking their changes.
Assalamu`Alaikum.
Dear Sir/Madam. Assalamu`Alaikum. I am Dr mohammad ouattara, I have ($10.6 Million us dollars) to transfer into your account, I will send you more details about this deal and the procedures to follow when I receive a positive response from you, Have a great day, Dr mohammad ouattara.
Re: [PATCH v2 3/6] update_unicode.sh: pin the uniset repo to a known good commit
Dennis Kaarsemakerwrites: > On Wed, 2016-12-14 at 00:31 +0100, Beat Bolli wrote: >> + ( cd uniset && git checkout 4b186196dd ) > > Micronit, but this is perhaps better written as > > git -C uniset checkout 4b186196dd > > to avoid the subshell and cd. > > D. In the context of this script, I would say that is not even a micronit. It is "you could do this if you wanted to".
Re: [PATCHv3 1/3] merge: Add '--continue' option as a synonym for 'git commit'
On Thu, Dec 15, 2016 at 09:36:17AM -0800, Junio C Hamano wrote: > > Did you want me to send a v4 to mark the strings for translation or > > will you apply a fixup your end? > > I didn't follow the _() discussion (was there any?) I think the discussion was just "we should do that". > I do not think lack of _() is a show-stopper and my preference is to > keep what I queued that does not have _(), and receive a separate > follow-up patch that changes "msg" to _("msg") and does nothing > else. Here's a patch. -- >8 -- Subject: merge: mark usage error strings for translation The nearby error messages are already marked for translation, but these new ones aren't. Signed-off-by: Jeff King--- builtin/merge.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/builtin/merge.c b/builtin/merge.c index 668aaffb8..599d25c4c 100644 --- a/builtin/merge.c +++ b/builtin/merge.c @@ -1164,7 +1164,7 @@ int cmd_merge(int argc, const char **argv, const char *prefix) const char *nargv[] = {"reset", "--merge", NULL}; if (orig_argc != 2) - usage_msg_opt("--abort expects no arguments", + usage_msg_opt(_("--abort expects no arguments"), builtin_merge_usage, builtin_merge_options); if (!file_exists(git_path_merge_head())) @@ -1180,7 +1180,7 @@ int cmd_merge(int argc, const char **argv, const char *prefix) const char *nargv[] = {"commit", NULL}; if (orig_argc != 2) - usage_msg_opt("--continue expects no arguments", + usage_msg_opt(_("--continue expects no arguments"), builtin_merge_usage, builtin_merge_options); if (!file_exists(git_path_merge_head())) -- 2.11.0.348.g960a0b554
Re: [PATCH v2] fix pushing to //server/share/dir on Windows
Jeff Kingwrites: > I don't have an opinion either way on what Windows would want, but note > that the function already _does_ convert separators to slashes. With > Johannes's original patch, you'd end up with a mix, like: > > \\server\share/dir1/file > > So this conversion is really just retaining the original behavior, and > making it consistent throughout the path. > > Which isn't to say that the function as it currently exists isn't a > little bit buggy. :) > > One of the points of normalizing, though, is that Git can then do > textual comparisons between the output. So I think there's value in > having a canonical internal representation, even if the OS could handle > more exotic ones. E.g. the log message of d53c2c6738 ("mingw: fix t9700's assumption about directory separators", 2016-01-27) says the two kinds of slashes are equivalent over there, but the patch text ends up doing exactly that normalization. 5ca6b7bb47 ("config --show-origin: report paths with forward slashes", 2016-03-23) is an example of us trying to normalize in order to give consistent output to the users. Having said all that, I do not have an opinion either way on what Windows would want, either ;-)
Re: [PATCHv3 1/3] merge: Add '--continue' option as a synonym for 'git commit'
Chris Packhamwrites: > On Thu, Dec 15, 2016 at 7:04 AM, Junio C Hamano wrote: >> The last one 3/3 is a nice touch that makes sure that we do not >> forget what we discovered during the discussion. Very much >> appreciated. >> >> Will queue. Thanks. > > Did you want me to send a v4 to mark the strings for translation or > will you apply a fixup your end? I didn't follow the _() discussion (was there any?) I do not think lack of _() is a show-stopper and my preference is to keep what I queued that does not have _(), and receive a separate follow-up patch that changes "msg" to _("msg") and does nothing else. Thanks.
Re: [PATCH v10 2/6] http: always warn if libcurl version is too old
Jeff Kingwrites: > On Wed, Dec 14, 2016 at 02:39:51PM -0800, Brandon Williams wrote: > >> Always warn if libcurl version is too old because: >> >> 1. Even without a protocol whitelist, newer versions of curl have all >>non-http protocols disabled by default. > > Technically, non-http and non-ftp. Maybe just "non-standard" would be > more accurate. > > Not worth a re-roll, but if Junio hasn't applied yet, maybe worth fixing > up while applying. I just did a "rebase -i"; thanks always for your careful reading.
[PATCH] git-p4: Fix multi-path changelist empty commits
From: George VanburghWhen importing from multiple perforce paths - we may attempt to import a changelist that contains files from two (or more) of these depot paths. Currently, this results in multiple git commits - one containing the changes, and the other(s) as empty commits. This behavior was introduced in commit 1f90a64 ("git-p4: reduce number of server queries for fetches", 2015-12-19). Reproduction Steps: 1. Have a git repo cloned from a perforce repo using multiple depot paths (e.g. //depot/foo and //depot/bar). 2. Submit a single change to the perforce repo that makes changes in both //depot/foo and //depot/bar. 3. Run "git p4 sync" to sync the change from #2. Change is synced as multiple commits, one for each depot path that was affected. Using a set, instead of a list inside p4ChangesForPaths() ensures that each changelist is unique to the returned list, and therefore only a single commit is generated for each changelist. Reported-by: James Farwell Signed-off-by: George Vanburgh --- git-p4.py | 4 ++-- t/t9800-git-p4-basic.sh | 22 +- 2 files changed, 23 insertions(+), 3 deletions(-) diff --git a/git-p4.py b/git-p4.py index fd5ca52..6307bc8 100755 --- a/git-p4.py +++ b/git-p4.py @@ -822,7 +822,7 @@ def p4ChangesForPaths(depotPaths, changeRange, requestedBlockSize): die("cannot use --changes-block-size with non-numeric revisions") block_size = None -changes = [] +changes = set() # Retrieve changes a block at a time, to prevent running # into a MaxResults/MaxScanRows error from the server. @@ -841,7 +841,7 @@ def p4ChangesForPaths(depotPaths, changeRange, requestedBlockSize): # Insert changes in chronological order for line in reversed(p4_read_pipe_lines(cmd)): -changes.append(int(line.split(" ")[1])) +changes.add(int(line.split(" ")[1])) if not block_size: break diff --git a/t/t9800-git-p4-basic.sh b/t/t9800-git-p4-basic.sh index 0730f18..4d72e0b 100755 --- a/t/t9800-git-p4-basic.sh +++ b/t/t9800-git-p4-basic.sh @@ -131,6 +131,26 @@ test_expect_success 'clone two dirs, @all, conflicting files' ' ) ' +test_expect_success 'clone two dirs, each edited by submit, single git commit' ' + ( + cd "$cli" && + echo sub1/f4 >sub1/f4 && + p4 add sub1/f4 && + echo sub2/f4 >sub2/f4 && + p4 add sub2/f4 && + p4 submit -d "sub1/f4 and sub2/f4" + ) && + git p4 clone --dest="$git" //depot/sub1@all //depot/sub2@all && + test_when_finished cleanup_git && + ( + cd "$git" + git ls-files >lines && + test_line_count = 4 lines && + git log --oneline p4/master >lines && + test_line_count = 5 lines + ) +' + revision_ranges="2000/01/01,#head \ 1,2080/01/01 \ 2000/01/01,2080/01/01 \ @@ -147,7 +167,7 @@ test_expect_success 'clone using non-numeric revision ranges' ' ( cd "$git" && git ls-files >lines && - test_line_count = 6 lines + test_line_count = 8 lines ) done ' -- https://github.com/git/git/pull/311
Re: Additional git hooks
On Thu, Dec 15, 2016 at 09:14:30AM -0500, Jeff King wrote: > On Thu, Dec 15, 2016 at 02:57:18PM +0100, Chiel ten Brinke wrote: > > > Would patches introducing new git hooks, e.g. for post-fetch, be > > eligible for acceptance? > > The general guidelines for adding hooks is laid out here: > > http://public-inbox.org/git/7vbq7ibxhh@gitster.siamese.dyndns.org/ One interesting follow-up, though (which seems sensible to me): http://public-inbox.org/git/7vr5fraxbf@alter.siamese.dyndns.org/ -Peff
[PATCH] README: replace gmane link with public-inbox
On Thu, Dec 15, 2016 at 02:57:18PM +0100, Chiel ten Brinke wrote: > Btw, the link in the README > http://news.gmane.org/gmane.comp.version-control.git/ is dead. Yes, the status of gmane was up in the air for a while, but I think we can give it up as dead now (at least for our purposes). -- >8 -- Subject: README: replace gmane link with public-inbox The general status and future of gmane is unclear at this point, but certainly it does not seem to be carrying gmane.comp.version-control.git at all anymore. Let's point to public-inbox.org, which seems to be the favored archive on the list these days (and which uses message-ids in its URLs, making the links somewhat future-proof). Reported-by: Chiel ten BrinkeSigned-off-by: Jeff King --- README.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/README.md b/README.md index bd8a918a9..c0cd5580e 100644 --- a/README.md +++ b/README.md @@ -33,7 +33,7 @@ requests, comments and patches to git@vger.kernel.org (read [Documentation/SubmittingPatches][] for instructions on patch submission). To subscribe to the list, send an email with just "subscribe git" in the body to majord...@vger.kernel.org. The mailing list archives are -available at http://news.gmane.org/gmane.comp.version-control.git/, +available at https://public-inbox.org/git, http://marc.info/?l=git and other archival sites. The maintainer frequently sends the "What's cooking" reports that -- 2.11.0.348.g960a0b554
Re: Additional git hooks
On Thu, Dec 15, 2016 at 02:57:18PM +0100, Chiel ten Brinke wrote: > Would patches introducing new git hooks, e.g. for post-fetch, be > eligible for acceptance? The general guidelines for adding hooks is laid out here: http://public-inbox.org/git/7vbq7ibxhh@gitster.siamese.dyndns.org/ -Peff
Additional git hooks
Would patches introducing new git hooks, e.g. for post-fetch, be eligible for acceptance? If a more detailed explanation about a specific use case is required, I'd be happy to provide it. Btw, the link in the README http://news.gmane.org/gmane.comp.version-control.git/ is dead. Chiel
[PATCH 3/6] Add a tree view to the local branches, remote branches and tags, where / is treated as a directory seperator.
Signed-off-by: Pierre Dumuid--- gitk | 117 +++ 1 file changed, 117 insertions(+) diff --git a/gitk b/gitk index 36cba49..a894f1d 100755 --- a/gitk +++ b/gitk @@ -2089,6 +2089,10 @@ proc makewindow {} { {mc "Reread re" command rereadrefs} {mc " references" command showrefs -accelerator F2} {xx "" separator} + {mc "List Local Branches" command {show_tree_of_references_dialog "localBranches"} -accelerator F6} + {mc "List Remote Branches" command {show_tree_of_references_dialog "remoteBranches"} -accelerator F7} + {mc "List Tags"command {show_tree_of_references_dialog "tags"} -accelerator F8} + {xx "" separator} {mc "Start git " command {exec git gui &}} {xx "" separator} {mc "" command doquit -accelerator Meta1-Q} @@ -2601,6 +2605,9 @@ proc makewindow {} { bind . updatecommits bindmodfunctionkey Shift 5 reloadcommits bind . showrefs +bind . {show_tree_of_references_dialog "localBranches"} +bind . {show_tree_of_references_dialog "remoteBranches"} +bind . {show_tree_of_references_dialog "tags"} bindmodfunctionkey Shift 4 {newview 0} bind . edit_or_newview bind . <$M1B-q> doquit @@ -10146,6 +10153,116 @@ proc rmbranch {} { run refill_reflist } +# Display a tree view of local branches, remote branches, and tags according to view_type. +# +# @param string view_type +#Must be one of "localBranches", "remoteBranches", or "tags". +# +proc show_tree_of_references_dialog {view_type} { +global NS +global treefilelist +global headids tagids + +switch -- $view_type { + "localBranches" { + set dialogName "Local Branches" + set top .show_tree_of_local_branches + set listOfReferences [lsort [array names headids -regexp {^(?!remotes/)} ]] + set truncateFrom 0 + } + "remoteBranches" { + set dialogName "Remote Branches" + set top .show_tree_of_remote_branches + set listOfReferences [lsort [array names headids -regexp {^remotes/} ]] + set truncateFrom 8 + } + "tags" { + set dialogName "Tags" + set top .show_tree_of_tags + set listOfReferences [lsort [array names tagids]] + set truncateFrom 0 + } +} + +if {[winfo exists $top]} { + raise $top + return +} + +ttk_toplevel $top +wm title $top [mc "$dialogName: %s" [file tail [pwd]]] +wm geometry $top "600x900" + +make_transient $top . + +## See http://www.tkdocs.com/tutorial/tree.html +ttk::treeview $top.referenceList -xscrollcommand "$top.horizontalScrollBar set" -yscrollcommand "$top.verticalScrollBar set" + +# Populate the dialog +foreach reference $listOfReferences { + # The display name omits some leading characters (such as "remotes/") + set referenceDisplayName [string range $reference $truncateFrom end] + + # Split the branch/tag by slashes, and incrementally ensure that each leaf in the treeview exists.. + # otherwise add it. + set treeLeaves [split $referenceDisplayName "/"] + for {set i 0} {$i < [llength $treeLeaves]} {} { + set leafReferenceId [join [lrange $treeLeaves 0 $i] "/"] + if {![$top.referenceList exists $leafReferenceId]} { + if {$i > 0} { + set parentLeafId [join [lrange $treeLeaves 0 $i-1] "/"] + } else { + set parentLeafId {} + } + $top.referenceList insert $parentLeafId end -id $leafReferenceId -text [lindex $treeLeaves $i] + } + incr i + } +} + +${NS}::scrollbar $top.verticalScrollBar -command "$top.referenceList yview" -orient vertical +${NS}::scrollbar $top.horizontalScrollBar -command "$top.referenceList xview" -orient horizontal + +grid $top.referenceList $top.verticalScrollBar -sticky nsew +grid $top.horizontalScrollBar x -sticky ew + +bind $top [list destroy $top] + +bind $top.referenceList <> {callback_tree_of_references_item_selected %W; break} + +grid columnconfigure $top 0 -weight 1 +grid rowconfigure$top 0 -weight 1 +} + +# Call back for selecting a branch / tag in the tree of references +# +# @param w +# +proc callback_tree_of_references_item_selected {w} { +global headids tagids + +set itemId [$w focus] +switch -- $w { + ".show_tree_of_local_branches.referenceList" { + if {[info exists headids($itemId)]} { + selbyid $headids($itemId) + } + } + ".show_tree_of_remote_branches.referenceList" { + set itemId "remotes/$itemId" + if {[info exists headids($itemId)]} { + selbyid $headids($itemId) + } + } +
[PATCH 5/6] gitk: Add a "Save file as" menu item
Previously, there was no easy way to save a particular file from the currently selected revision. This patch adds a menu item "Save file as" to the file list popup menu, which opens a file selection dialog to determine the name under which a file should be saved. The default filename is of the form "[shortid] basename". If the current revision is the index, the default pattern is of the form "[index] basename". This works for both, the "Patch" and "Tree" view. The menu item is disabled for the "local uncommitted changes" fake revision. Signed-off-by: Andreas AmannSigned-off-by: Pierre Dumuid --- gitk | 36 1 file changed, 36 insertions(+) diff --git a/gitk b/gitk index 5f27716..0903d2d 100755 --- a/gitk +++ b/gitk @@ -2693,6 +2693,7 @@ proc makewindow {} { {mc "Highlight this too" command {flist_hl 0}} {mc "Highlight this only" command {flist_hl 1}} {mc "External diff" command {external_diff}} + {mc "Save file as" command {save_file_as}} {mc "Blame parent commit" command {external_blame 1}} {mc "Copy path" command {clipboard clear; clipboard append $flist_menu_file}} } @@ -3504,6 +3505,7 @@ proc sel_flist {w x y} { proc pop_flist_menu {w X Y x y} { global ctext cflist cmitmode flist_menu flist_menu_file global treediffs diffids +global nullid stopfinding set l [lindex [split [$w index "@$x,$y"] "."] 0] @@ -3521,6 +3523,12 @@ proc pop_flist_menu {w X Y x y} { } # Disable "External diff" item in tree mode $flist_menu entryconf 2 -state $xdiffstate +set savefilestate "normal" +if {[lindex $diffids 0] eq $nullid} { + set savefilestate "disabled" +} +# Disable "Save file as" item "local uncommited changes" revision +$flist_menu entryconf 3 -state $savefilestate tk_popup $flist_menu $X $Y } @@ -3632,6 +3640,34 @@ proc external_diff_get_one_file {diffid filename diffdir} { "revision $diffid"] } +proc save_file_as {} { +global nullid nullid2 +global flist_menu_file cmitmode +global diffids + +set diffid [lindex $diffids 0] +if {$diffid == $nullid} { + return +} elseif {$diffid == $nullid2} { + set diffidtext [mc "index"] + set diffid "" + set whattext $diffidtext +} else { + set diffidtext [shortids $diffid] + set whattext "[mc "revision"] $diffidtext" +} +set diffid $diffid: +if {$cmitmode eq "tree"} { + set diffid $diffid./ +} +set difffile "\[$diffidtext\] [file tail $flist_menu_file]" +set difffile [tk_getSaveFile -initialfile $difffile -title [mc "Save file as"] -parent .] +if {$difffile eq {}} { + return +} +save_file_from_commit $diffid$flist_menu_file $difffile $whattext +} + proc external_diff {} { global nullid nullid2 global flist_menu_file -- 2.10.2
[PATCH 6/6] Rename 'remotes/' to 'r../' in heads
Signed-off-by: Pierre Dumuid--- gitk | 19 ++- 1 file changed, 14 insertions(+), 5 deletions(-) diff --git a/gitk b/gitk index 0903d2d..6f50b06 100755 --- a/gitk +++ b/gitk @@ -6731,22 +6731,28 @@ proc drawtags {id x xt y1} { set yb [expr {$yt + $linespc - 1}] set xvals {} set wvals {} +set newTags {} + set i -1 foreach tag $marks { incr i + set newTag $tag + regsub {^remotes} $newTag "r.." newTag + if {$i >= $ntags && $i < $ntags + $nheads && $tag eq $mainhead} { - set wid [font measure mainfontbold $tag] + set wid [font measure mainfontbold $newTag] } else { - set wid [font measure mainfont $tag] + set wid [font measure mainfont $newTag] } lappend xvals $xt lappend wvals $wid + lappend newTags $newTag set xt [expr {$xt + $wid + $extra}] } set t [$canv create line $x $y1 [lindex $xvals end] $y1 \ -width $lthickness -fill $reflinecolor -tags tag.$id] $canv lower $t -foreach tag $marks x $xvals wid $wvals { +foreach tag $marks x $xvals wid $wvals newTag $newTags { set tag_quoted [string map {% %%} $tag] set xl [expr {$x + $delta}] set xr [expr {$x + $delta + $wid + $lthickness}] @@ -6778,7 +6784,10 @@ proc drawtags {id x xt y1} { $canv create polygon $x $yt $xr $yt $xr $yb $x $yb \ -width 1 -outline black -fill $col -tags tag.$id if {[regexp {^(remotes/.*/|remotes/)} $tag match remoteprefix]} { - set rwid [font measure mainfont $remoteprefix] + set newRemotePrefix $remoteprefix + regsub {^remotes} $newRemotePrefix "r.." newRemotePrefix + + set rwid [font measure mainfont $newRemotePrefix] set xi [expr {$x + 1}] set yti [expr {$yt + 1}] set xri [expr {$x + $rwid}] @@ -6786,7 +6795,7 @@ proc drawtags {id x xt y1} { -width 0 -fill $remotebgcolor -tags tag.$id } } - set t [$canv create text $xl $y1 -anchor w -text $tag -fill $headfgcolor \ + set t [$canv create text $xl $y1 -anchor w -text $newTag -fill $headfgcolor \ -font $font -tags [list tag.$id text]] if {$ntags >= 0} { $canv bind $t <1> $tagclick -- 2.10.2
[PATCH 4/6] Add DirDiffTool as additional option
Signed-off-by: Pierre Dumuid--- gitk | 17 + 1 file changed, 17 insertions(+) diff --git a/gitk b/gitk index a894f1d..5f27716 100755 --- a/gitk +++ b/gitk @@ -2661,6 +2661,9 @@ proc makewindow {} { {mc "Diff this -> marked commit" command {diffvsmark 0}} {mc "Diff marked commit -> this" command {diffvsmark 1}} {mc "Revert this commit" command revert} + + {mc "DirDiffTool this -> selected" command {externalDiffToolVsSel 0}} + {mc "DirDiffTool selected -> this" command {externalDiffToolVsSel 1}} } $rowctxmenu configure -tearoff 0 @@ -9254,6 +9257,20 @@ proc diffvssel {dirn} { doseldiff $oldid $newid } +proc externalDiffToolVsSel {diffDirection} { +global rowmenuid selectedline + +if {$selectedline eq {}} return +if {$diffDirection} { + set oldid [commitonrow $selectedline] + set newid $rowmenuid +} else { + set oldid $rowmenuid + set newid [commitonrow $selectedline] +} +[exec git difftool -d $oldid $newid] +} + proc diffvsmark {dirn} { global rowmenuid markedid -- 2.10.2
[PATCH 1/6] Enable ability to visualise the results of git cherry C1 C2
It's a bit clunky but it works!! Usage: - mark commit one (e.g. v45) - Select commit two. - Switch the gdttype to the option, "git-cherry between marked commit and:" Signed-off-by: Pierre Dumuid--- gitk | 110 +-- 1 file changed, 107 insertions(+), 3 deletions(-) diff --git a/gitk b/gitk index a14d7a1..50d1ef4 100755 --- a/gitk +++ b/gitk @@ -2319,7 +2319,9 @@ proc makewindow {} { [mc "containing:"] \ [mc "touching paths:"] \ [mc "adding/removing string:"] \ - [mc "changing lines matching:"]] + [mc "changing lines matching:"] \ + [mc "git-cherry between marked commit and:"] \ + ] trace add variable gdttype write gdttype_change pack .tf.lbar.gdttype -side left -fill y @@ -4707,6 +4709,18 @@ proc gdttype_change {name ix op} { global gdttype highlight_files findstring findpattern stopfinding + +if {$gdttype eq [mc "git-cherry between marked commit and:"]} { + if {$highlight_files ne {}} { + set highlight_files {} + hfiles_change + } + findcom_change + update_gitcherrylist + drawvisible + return +} + if {$findstring ne {}} { if {$gdttype eq [mc "containing:"]} { if {$highlight_files ne {}} { @@ -4733,6 +4747,9 @@ proc find_change {name ix op} { stopfinding if {$gdttype eq [mc "containing:"]} { findcom_change +} elseif {$gdttype eq [mc "git-cherry between marked commit and:"]} { + findcom_change + update_gitcherrylist } else { if {$highlight_files ne $findstring} { set highlight_files $findstring @@ -4742,6 +4759,54 @@ proc find_change {name ix op} { drawvisible } +proc update_gitcherrylist {} { +global gitcherryids +global markedid +global findstring +global fstring +global currentid +global iddrawn + +unset -nocomplain gitcherryids +set fs $findstring + +if {$findstring eq {}} { + $fstring delete 0 end + $fstring insert 0 $currentid +} + +if {![info exists markedid]} { + error_popup [mc "Please mark a git commit before using this find method!"] + return +} + +#puts [join [list "Running cherry between: `" $markedid "` and `" $findstring "`"] ""] + +if {[catch {set cherryOutput [exec git cherry $markedid $findstring]}]} { + puts "ERROR: An error occured running git-cherry!" + return +} + +set cherryLines [split $cherryOutput "\n"] +foreach cherryLine $cherryLines { + set op [lindex [split $cherryLine " "] 0] + set gitSha [lindex [split $cherryLine " "] 1] + + #puts [join [list "line is: `" $cherryLine "`, op:`" $op "`, gitSha:`" $gitSha "`"] ""] + if {$op eq "+"} { + set gitcherryids($gitSha) 1 + if ([info exists iddrawn($gitSha)]) { + bolden $gitSha mainfontbold + } + + } +} +# puts "list is as follows" +#foreach {gitsha setBold} [array get gitcherryids] { +# puts [concat $gitsha = $setBold] +#} +} + proc findcom_change args { global nhighlights boldnameids global findpattern findtype findstring gdttype @@ -4802,6 +4867,9 @@ proc do_file_hl {serial} { set gdtargs [list "-S$highlight_files"] } elseif {$gdttype eq [mc "changing lines matching:"]} { set gdtargs [list "-G$highlight_files"] +} elseif {$gdttype eq [mc "git-cherry between marked commit and:"]} { + # Skipping opening the file handle, filehighlight + return } else { # must be "containing:", i.e. we're searching commit info return @@ -4882,6 +4950,17 @@ proc doesmatch {f} { } } +proc askcherryhighlight {row id} { +global nhighlights gitcherryids + +set isbold 0 +if {[info exists gitcherryids($id)]} { + set isbold 1 +} + +set nhighlights($id) $isbold +} + proc askfindhighlight {row id} { global nhighlights commitinfo iddrawn global findloc @@ -6216,6 +6295,7 @@ proc drawcmitrow {row} { global filehighlight fhighlights findpattern nhighlights global hlview vhighlights global highlight_related rhighlights +global gdttype if {$row >= $numcommits} return @@ -6226,6 +6306,11 @@ proc drawcmitrow {row} { if {[info exists filehighlight] && ![info exists fhighlights($id)]} { askfilehighlight $row $id } + +if {$gdttype eq [mc "git-cherry between marked commit and:"] && ![info exists nhighlights($id)]} { + askcherryhighlight $row $id +} + if {$findpattern ne {} && ![info exists nhighlights($id)]} { askfindhighlight $row $id } @@ -6776,7 +6861,9 @@ proc dofind {{dirn 1} {wrap 1}} { } set findcurline $findstartline nowbusy finding [mc "Searching"] -if {$gdttype ne [mc "containing:"] &&
[PATCH 2/6] Add ability to follow a remote branch with a dialog
A suggested name is provided when creating a new "following" branch. Signed-off-by: Pierre Dumuid--- gitk | 86 1 file changed, 82 insertions(+), 4 deletions(-) diff --git a/gitk b/gitk index 50d1ef4..36cba49 100755 --- a/gitk +++ b/gitk @@ -2673,6 +2673,7 @@ proc makewindow {} { {mc "Rename this branch" command mvbranch} {mc "Remove this branch" command rmbranch} {mc "Copy branch name" command {clipboard clear; clipboard append $headmenuhead}} + {mc "Follow this branch" command follow_remote_branch_dialog} } $headctxmenu configure -tearoff 0 @@ -9947,23 +9948,100 @@ proc headmenu {x y id head} { stopfinding set headmenuid $id set headmenuhead $head -array set state {0 normal 1 normal 2 normal} +array set state {0 normal 1 normal 2 normal 3 normal} if {[string match "remotes/*" $head]} { set localhead [string range $head [expr [string last / $head] + 1] end] if {[info exists headids($localhead)]} { set state(0) disabled } - array set state {1 disabled 2 disabled} + array set state {1 disabled 2 disabled 3 normal} } if {$head eq $mainhead} { - array set state {0 disabled 2 disabled} + array set state {0 disabled 2 disabled 3 disabled} +} else { + set state(3) disabled } -foreach i {0 1 2} { +foreach i {0 1 2 3} { $headctxmenu entryconfigure $i -state $state($i) } tk_popup $headctxmenu $x $y } +proc follow_remote_branch_dialog {} { +global headmenuhead NS + +# check the tree is clean first?? +nowbusy createFollowingBranch [mc "Creating following branch"] +update +dohidelocalchanges + +set top .create_following_branch +catch {destroy $top} +ttk_toplevel $top +make_transient $top . + +${NS}::label $top.title -text [mc "Create following branch"] +grid $top.title - -pady 10 + +${NS}::label $top.remote_branch_name_label -text [mc "Remote Branch:"] +${NS}::entry $top.remote_branch_name -width 40 +$top.remote_branch_name insert 0 $headmenuhead +$top.remote_branch_name conf -state readonly +grid $top.remote_branch_name_label $top.remote_branch_name -sticky w + +${NS}::label $top.new_branch_name_label -text [mc "Name:"] +${NS}::entry $top.new_branch_name -width 40 +set suggested_name $headmenuhead +regsub {^remotes/[^/]*/} $suggested_name {} suggested_name +$top.new_branch_name insert 0 $suggested_name +grid $top.new_branch_name_label $top.new_branch_name -sticky w + +set actionCreate [list follow_remote_branch_callback $top] +set actionCancel "catch {notbusy createFollowingBranch; destroy $top}" + +${NS}::frame $top.buts +${NS}::button $top.buts.go -text [mc "Create"] -command $actionCreate +${NS}::button $top.buts.can -text [mc "Cancel"] -command $actionCancel +grid $top.buts.go $top.buts.can +grid columnconfigure $top.buts 0 -weight 1 -uniform a +grid columnconfigure $top.buts 1 -weight 1 -uniform a +grid $top.buts - -pady 10 -sticky ew + +bind $top $actionCreate +bind $top $actionCancel + +focus $top.new_branch_name +} + +proc follow_remote_branch_callback {top} { +global headids idheads NS +set new_branch_name[$top.new_branch_name get] +set remote_branch_name [$top.remote_branch_name get] +set cmdargs {} + +if {$new_branch_name eq {}} { + error_popup [mc "Please specify a name for the new branch"] $top + return +} +if {[info exists headids($new_branch_name)]} { + error_popup [mc "The branch name you specified already exists, please specify a new name"] $top + return +} +catch {destroy $top} + +lappend cmdargs $new_branch_name $remote_branch_name + +if {[catch { + eval exec git branch --track $cmdargs +} err]} { + notbusy createFollowingBranch + error_popup $err +} else { + notbusy createFollowingBranch + updatecommits +} +} + proc cobranch {} { global headmenuid headmenuhead headids global showlocalchanges -- 2.10.2
Re: [PATCH v2] fix pushing to //server/share/dir on Windows
On Thu, Dec 15, 2016 at 08:30:52AM +0100, Torsten Bögershausen wrote: > > > Would it be reasonable to > > > write: > > > > > >/* Copy initial part of absolute path, converting separators on > > > Windows */ > > >const char *end = src + offset_1st_component(src); > > >while (src < end) { > > > char c = *src++; > > > if (c == '\\') > > > c = '/'; > > > *dst++ = c; > > >} > > Makes a lot of sense! I haven't had an opportunity, though, to test > > on Windows. > I'm not sure, if a conversion should be done here, in this part of code. > To my knowledge, > > C:\dir1\file > is the same > as > C:/dir1/file > and that is handled by windows. I don't have an opinion either way on what Windows would want, but note that the function already _does_ convert separators to slashes. With Johannes's original patch, you'd end up with a mix, like: \\server\share/dir1/file So this conversion is really just retaining the original behavior, and making it consistent throughout the path. Which isn't to say that the function as it currently exists isn't a little bit buggy. :) One of the points of normalizing, though, is that Git can then do textual comparisons between the output. So I think there's value in having a canonical internal representation, even if the OS could handle more exotic ones. -Peff
Re: [RFC/PATCH v3 00/16] Add initial experimental external ODB support
On Tue, Dec 13, 2016 at 9:05 PM, Junio C Hamanowrote: > Christian Couder writes: > >> In general I think that having a lot of refs is really a big problem >> right now in Git as many big organizations using Git are facing this >> problem in one form or another. >> So I think that support for a big number of refs is a separate and >> important problem that should and hopefully will be solved. > > But you do not have to make it worse. > > Is "refs" a good match for the problem you are solving? Or is it > merely an expedient thing to use? I think it is the latter, judging > by your mentioning RefTree. Whatever mechanism we choose, that will > be carved into stone in users' repositories and you'd end up having > to support it, and devise the migration path out of it if the initial > selection is too problematic. > > That is why people (not just me) pointed out upfront that using refs > for this purose would not scale. What I should perhaps have clarified in my previous answer, and also in the documentation of the patch series, is that in what I have done and what I propose, the external odb helper is responsible for using and creating the refs in refs/odbs//. So this helper is free to just create one ref, as it is also free to create many refs. Git is just transmitting the refs that have been created by this helper. Right now people are already free to use whatever external script or software to create whatever refs/stuff/* they want, pointing to whatever objects they want, and have Git transmit that. And indeed I know that it is already a problem out there, as then people often get into trouble related to having many refs. But it is a different problem that is not going to be solved anyway in this patch series. So if some people want to use a specific external odb, it's their responsibility to use an helper that will not create too many refs. If they know that they just need their external odb to handle around 10 big files, why wouldn't they use a simple helper that creates one odb ref per big file/blob? On the contrary if they know that they will need to handle thousands of big files, then, yeah, they should find or implement a helper that will, as I suggested in my previous email, just create one ref in refs/odbs// that points to a blob that contains a list (maybe a json list with information attached to each item) of the blobs stored in the external odb. For testing purposes in what I have done in the patch series, I use only simple helpers that create one odb ref per big file/blob. So yes, it gives a bad example, because, if people just copy this design while they need the e-odb to handle a big number of files, then they will be in trouble. But this does not by itself carve anything into stone. One thing that could help is perhaps to put big warnings into the simple helpers saying "Be careful!!! This will not scale if you want to handle more than a small number of large files!!! You'd better use an helper that does if you want to handle many large files!!! You have been warned!!!". So I am reluctant at this point to write a complex helper just for the purpose of showing a good example to people who want to use e-odb to store a big number of files, as these people anyway would probably need something like Lars' "filter process protocol" too.
Re: [PATCH v2 3/6] update_unicode.sh: pin the uniset repo to a known good commit
On Wed, 2016-12-14 at 00:31 +0100, Beat Bolli wrote: > + ( cd uniset && git checkout 4b186196dd ) Micronit, but this is perhaps better written as git -C uniset checkout 4b186196dd to avoid the subshell and cd. D.
Cherry-pick applied X times
Hi Git community, I'm new to GIT and responsible of a project to migrate our SVN repo to GIT. I've made the migration with the git-svn tools ... it was long, but everything seems fine ; source code is correct and all its history is there. It happen with our delivery workflow that we will have to use cherry-picks to prepare our patches, so I made some test on it. During those tests I saw a strange behaviour: I tried to cherry-pick onto a release branch a commit from the master that had been previously already merged onto this branch with SVN. GIT did not detect it and added the code a second time in the source file modified. I supposed this was du the fact the first merge had been made with SVN. I tried to cherry pick the same commit again ... and GIT add one more time the code of the commit. It appears I could cherry-pick this commit X times with GIT, and each time he added the code again. I looked in SVN, the merge property of the first commit from master to the release branch is ok. Our SVN repo has more than 22K revisions I found out that some other commits had the same behaviour. Is there a direction onto which I should investigate to determine where the problem comes from ? Here is an example of the multiple cherry pick. Branches: > git branch master * release/15.0.0 release/15.3.0 Check commit already exist on release (cb8c480) and get master hash (bee110c): > git log --oneline |grep GTX-20264 cb8c480 GTX-20264 : Missing end of string in field hostReference for custom network ack > git checkout master Switched to branch 'master' Your branch is up-to-date with 'origin/master'. > git log --oneline |grep GTX-20264 bee110c GTX-20264 : Missing end of string in field hostReference for custom network ack > git checkout release/15.0.0 Switched to branch 'release/15.0.0' Your branch is up-to-date with 'origin/release/15.0.0'. And now I cherry-pick the master commit onto the release/15.0.0 a multiple of times: > git cherry-pick bee110c [release/15.0.0 e8bfc33] GTX-20264 : Missing end of string in field hostReference for custom network ack Author: Yann Delanoe1 file changed, 3 insertions(+) > git cherry-pick bee110c [release/15.0.0 2b98c8d] GTX-20264 : Missing end of string in field hostReference for custom network ack Author: Yann Delanoe 1 file changed, 3 insertions(+) > git cherry-pick bee110c [release/15.0.0 820cd8a] GTX-20264 : Missing end of string in field hostReference for custom network ack Author: Yann Delanoe 1 file changed, 3 insertions(+) Best regards Yann DELANOE - Product engineer - Bottomline technologies