Re: 2.10.0: git log --oneline prints gpg signatures in 4 lines
On Tue, 20 Sep 2016 19:15:33 -0400 Jeff King <p...@peff.net> wrote: > On Tue, Sep 20, 2016 at 05:09:54PM +0200, Leandro Lucarella wrote: > > > Hi, starting from 2.10.0 I noticed that when using git log > > --oneline, if commits are signed with GPG, now the signatures are > > printed too, and it takes 3 lines for the signature information + 1 > > line for the title of the commit, so suddenly --oneline became > > --fourline :) > > > > Is this really intended? > > I don't think anything has changed here in 2.10. Running "git log > --oneline --show-signature" has _always_ been horribly ugly. However, > 2.10 did introduce the "log.showsignature" config, which makes "git > log --oneline" pretty unusable when it is enabled. Ditto for > one-liner uses of "--format". > > I think we should probably ignore the config entirely when using any > of the one-liner formats (and I'd include --format, too, even though > it can sometimes be multi-line; it already has %GG to include that > information as appropriate). Woops! Definitely it shouldn't be added when --format is used, this is also breaking some scripts I have using git log --format to get some information about commits, and GPG information is being output even when there is anything about GPG requested in the chosen format. I guess I will disable log.showsignatures for now... :( -- Leandro Lucarella Technical Development Lead Sociomantic Labs GmbH <http://www.sociomantic.com>
Re: 2.10.0: git log --oneline prints gpg signatures in 4 lines
On Tue, 20 Sep 2016 19:15:33 -0400 Jeff King <p...@peff.net> wrote: > On Tue, Sep 20, 2016 at 05:09:54PM +0200, Leandro Lucarella wrote: > > > Hi, starting from 2.10.0 I noticed that when using git log > > --oneline, if commits are signed with GPG, now the signatures are > > printed too, and it takes 3 lines for the signature information + 1 > > line for the title of the commit, so suddenly --oneline became > > --fourline :) > > > > Is this really intended? > > I don't think anything has changed here in 2.10. Running "git log > --oneline --show-signature" has _always_ been horribly ugly. However, > 2.10 did introduce the "log.showsignature" config, which makes "git > log --oneline" pretty unusable when it is enabled. Ditto for > one-liner uses of "--format". Right! Now I remember, I changed my configuration when I read the release notes, before I upgraded. Now that I did upgrade I'm seeing the results. Anyway, yeah, using the new configuration makes --oneline pretty unusable, so ignoring that option for --oneline seems like a good idea. > I think we should probably ignore the config entirely when using any > of the one-liner formats (and I'd include --format, too, even though > it can sometimes be multi-line; it already has %GG to include that > information as appropriate). > > Another option would be to somehow represent the signature information > in the --oneline output, but I think I'd rather leave that for people > to experiment with using "--format". I think it might be nice to show the information in one line in a ver succinct way, like just showing a green unicode check mark (✓) or a red cross mark (❌) if it failed (or just colour the commit subject in green/red if a signature is present and is passing/failing). Thanks! -- Leandro Lucarella Technical Development Lead Sociomantic Labs GmbH <http://www.sociomantic.com>
2.10.0: git log --oneline prints gpg signatures in 4 lines
Hi, starting from 2.10.0 I noticed that when using git log --oneline, if commits are signed with GPG, now the signatures are printed too, and it takes 3 lines for the signature information + 1 line for the title of the commit, so suddenly --oneline became --fourline :) Is this really intended? -- Leandro Lucarella Technical Development Lead Sociomantic Labs GmbH <http://www.sociomantic.com>
Re: [PATCH] transport: report missing submodule pushes consistently on stderr
On Tue, 23 Aug 2016 14:40:08 -0700 Stefan Beller <sbel...@google.com> wrote: > The surrounding advice is printed to stderr, but the list of > submodules is not. Make the report consistent by reporting everything > to stderr. > > Signed-off-by: Stefan Beller <sbel...@google.com> > --- > > This fixes one of the bugs mentioned in > > https://public-inbox.org/git/cagz79kbkyupbjfvyx3hj_r5zw36+3ufonnlc-dpic40npja...@mail.gmail.com/T/#t > > How to fix the other was not as obvious to me as I do not > understand the philosophy on verbosity in the transport code. I had a look and I would say just enclose all the fprintf() inside a: if (transport->verbose > 0) But then this is the first time I look at the code. I was about to send a patch too but it will conflict with this one :) Anyway, thanks for the quick fix to the inconsistent printing with --quiet. -- Leandro Lucarella Technical Development Lead Sociomantic Labs GmbH <http://www.sociomantic.com> -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Getting "The following submodule paths contain changes that can not be found on any remote" when they are in the remote
On Tue, 23 Aug 2016 20:34:46 +0200 Leandro Lucarella <leandro.lucare...@sociomantic.com> wrote: > This even happens after doing a: > > git submodule deinit > rm -fr > rm -fr .git/modules/ > git submodule update --init One more thing, doing a clean new clone seems to work, but I have this issue in many many repos, which are old clones, from before Git had the ability to check for submodules. Could it be some incompatibility in old clones with this? Is there anything I can look for in the .git/ directory or elsewhere to fix them? Thanks again! -- Leandro Lucarella Technical Development Lead Sociomantic Labs GmbH <http://www.sociomantic.com> -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Getting "The following submodule paths contain changes that can not be found on any remote" when they are in the remote
Hi, I'm getting very often, but not always, with many different projects using submodules, the message: The following submodule paths contain changes that can not be found on any remote: Please try git push --recurse-submodules=on-demand or cd to the path and use git push to push them to a remote. fatal: Aborting. This even happens after doing a: git submodule deinit rm -fr rm -fr .git/modules/ git submodule update --init So I am getting the reference from the remote, but when pushing a new change (that doesn't touch the submodules) I keep getting this error. I tried to get more information about why this is happening but I couldn't. Googling didn't help either, so I'm resorting to ask here. I would also like to report a tiny bug, when using push --quiet, I do get all the message above except for the name, which is quite confusing. $ git --version git version 2.9.3 (running under Ubuntu 14.04) Please CC me, and thanks a lot in advance! -- Leandro Lucarella Technical Development Lead Sociomantic Labs GmbH <http://www.sociomantic.com> -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
branch.name.pushremote not working with push.default simple or upstream
Hi, I tried to use the new Git feature to push by default to a different remote you normally pull but I had some problems. I asked in the #git IRC channel and been told it looks like a bug and to report it here. I have 2 remotes, origin and upstream. origin is my private fork (and I can push to it) while upstream is read-only for me. I have only one branch, 'master' (present in all the remotes), originally tracking origin/master. I changed branch.master.remote to upstream and set branch.master.pushremote to origin, but when I do I git push I get an error: $ git push --dry-run --verbose fatal: You are pushing to remote 'origin', which is not the upstream of your current branch 'master', without telling me what to push to update which remote branch. I'm using push.default 'simple' to stay forward compatible with Git 2.0. In the IRC channel they suggested to try with other push.default settings and I did. 'matching' and 'current' works, but 'simple' and 'upstream' fail with the error message above. Thank you. -- Leandro Lucarella Senior RD Developer sociomantic labs GmbH http://www.sociomantic.com -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: branch.name.pushremote not working with push.default simple or upstream
On Fri, Jun 07, 2013 at 08:47:59AM -0700, Junio C Hamano wrote: When branch.$name.push mechanism is introduced and the user uses it, then upstream, simple, or any other setting for that matter would be ignored. With [branch master] remote = upstream merge = refs/heads/master pushremote = origin push = refs/heads/master it is clear that git push while on 'master' should push to origin to update its master branch. Thanks for the detailed explanations, I think this would cover my use case. Just for clarification, here are some more details on this use case, which I think is becoming very popular among github users. We have a blessed repository (upstream in my case) and only a few people is able to push to it (let's call them maintainers). Every developer, including the ones with push access, have to go through peer reviewing and are not allowed to push their own commits to upstream. For peer reviewing, each have it's own public fork, that other people can review and merge/push if is good. In this scheme, you always pull from the blessed repository and only push to your personal fork, with the exceptions of the maintainers that need to push from time to time other people pull requests. My ideal would be to be able to just do 'git pull' to get the new stuff and 'git push' to push to my fork. Since pushing to the blessed repository is more critical, is perfect that I need to explicitly push to it with 'git push upstream master'. Thank you. -- Leandro Lucarella Senior RD Developer sociomantic labs GmbH http://www.sociomantic.com -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: branch.name.pushremote not working with push.default simple or upstream
On Fri, Jun 07, 2013 at 10:27:58PM +0530, Ramkumar Ramachandra wrote: Leandro Lucarella wrote: Thanks for the detailed explanations, I think this would cover my use case. Just for clarification, here are some more details on this use case, which I think is becoming very popular among github users. We have a blessed repository (upstream in my case) and only a few people is able to push to it (let's call them maintainers). Every developer, including the ones with push access, have to go through peer reviewing and are not allowed to push their own commits to upstream. For peer reviewing, each have it's own public fork, that other people can review and merge/push if is good. Yes, and I wrote it precisely to address this itch. git/git is origin, and artagnon/git is ram. I just set remote.pushdefault to ram and continue working as usual. I apologize for not having thought hard enough about other push.default modes: I personally use current, and like it very much. As an added bonus, even new branches created with git checkout -b hot-branch will get push to go to the right place; no need to set upstream before pushing. I might try to just switch to current, I feel more comfortable with simple because I feel is safer to explicitly set the upstream branch, but is true that most of the time is not necessary. -- Leandro Lucarella Senior RD Developer sociomantic labs GmbH http://www.sociomantic.com -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
