submodule..ignore vs git add -u

Hi, Let's say I have a fairly simple submodule setup where I do 'git checkout' inside the submodule to check out a different commit, so the outer repo 'git diff' shows a submodule update. In that case git config submodule..ignore all makes 'git diff' or 'git commit -a' ignore the

Re: Signed-off-by vs Reviewed-by

Hi, On Thu, Mar 31, 2016 at 09:28:44AM -0700, Junio C Hamano wrote: > The internal "parse the existing trailer block and manipulate it by > adding, conditionally adding, replacing and deleting it" logic was > done as an experimental "interpret-trailers" program, but polishing

Re: Signed-off-by vs Reviewed-by

Hi, On Thu, Mar 31, 2016 at 07:54:47PM +0530, Pranit Bauva wrote: > Are you suggesting to use a different email address for commiting, > signing off and reviewing? Let's say project A has a workflow where patch authors and maintainers add a "Signed-off-by: A B

Signed-off-by vs Reviewed-by

Hi, Some projects like LibreOffice don't use Signed-off-by, instead usually use Gerrit for code review, and reviewers add a Reviewed-by line when they are OK with a patch. In this workflow it's a bit unfortunate that adding a Signed-off-by line is just a command-line switch, but adding a

Re: [PATCH v1 02/25] contrib: remove 'hg-to-git'

On Thu, May 08, 2014 at 07:58:13PM -0500, Felipe Contreras felipe.contre...@gmail.com wrote: There hasn't been any real activity on it since 2010. Plus there are better out-of-tree tools. No tests and no real documentation either. ACK, git clone hg::... is what one is supposed to use

git log history simplification problem

Hi, I was trying to understand the history of a piece of code in LibreOffice and I'm facing a behaviour of git-log which is not something I can explain. I'm not sure if this is a git bug or a user error. ;) Here is the situation: git clone git://anongit.freedesktop.org/libreoffice/core cd core

Re: git log history simplification problem

On Tue, Feb 04, 2014 at 06:37:13PM +0100, Miklos Vajna vmik...@collabora.co.uk wrote: But then I run: git grep 'mnTitleBarHeight =' sd and it's not there. Am I missing something, as in e.g. even with --full-history git-log does some simplification? I tried to reproduce this with a repo

Re: git log history simplification problem

Hi Jonathan, On Tue, Feb 04, 2014 at 11:48:42AM -0800, Jonathan Nieder jrnie...@gmail.com wrote: Luckily '-m -p' without --first-parent worked and the first commit it showed was the right one. It produces more hits than I'd like, too, though. Ah, excellent! :-) '-m' does what I need.

Re: [PATCH] Documentation/Makefile: make AsciiDoc dblatex dir configurable

On Thu, Oct 03, 2013 at 08:17:32PM +0100, John Keeping j...@keeping.me.uk wrote: On my system this is in /usr/share/asciidoc/dblatex not /etc/asciidoc/dblatex. Extract this portion of the path to a variable so that is can be set in config.mak. Sure, makes sense. -- To unsubscribe from this

Re: What's cooking in git.git (Jul 2013, #03; Tue, 9)

Hi, On Tue, Jul 23, 2013 at 12:53:25PM +0530, Ramkumar Ramachandra artag...@gmail.com wrote: Junio C Hamano wrote: * mv/merge-ff-tristate (2013-07-02) 1 commit (merged to 'next' on 2013-07-09 at c32b95d) + merge: handle --ff/--no-ff/--ff-only as a tri-state option Sorry I didn't

[PATCH v2] merge: handle --ff/--no-ff/--ff-only as a tri-state option

This has multiple benefits: with more than one of {--ff, --no-ff, --ff-only} respects the last option; also the command-line option to always take precedence over the config file option. Signed-off-by: Miklos Vajna vmik...@suse.cz --- builtin/merge.c | 55

[PATCH] merge: allow using --no-ff and --ff-only at the same time

these options together in some workflow, e.g. when branches are integrated by rebasing then merging, and the maintainer wants to be sure the branch is rebased. Signed-off-by: Miklos Vajna vmik...@suse.cz --- builtin/merge.c | 12 t/t7600-merge.sh | 11 --- 2 files changed, 16

Re: [PATCH] merge: allow using --no-ff and --ff-only at the same time

Hi Michael, On Mon, Jul 01, 2013 at 04:52:29PM +0200, Michael Haggerty mhag...@alum.mit.edu wrote: On 07/01/2013 09:01 AM, Miklos Vajna wrote: 1347483 (Teach 'git merge' and 'git pull' the option --ff-only, 2009-10-29) says this is not allowed, as they contradict each other. However

Re: [PATCH] merge: allow using --no-ff and --ff-only at the same time

On Mon, Jul 01, 2013 at 08:38:21AM -0700, Junio C Hamano gits...@pobox.com wrote: As to --no-ff vs --ff-only, --ff-only has always meant only fast-forward updates are allowed. We do not want to create a merge commit with this operation. I do agree with you that the proposed patch changes

[PATCH] merge: handle --ff/--no-ff/--ff-only as a tri-state option

This has multiple benefits: with more than one of {--ff, --no-ff, --ff-only} respects the last option; also the command-line option to always take precedence over the config file option. Signed-off-by: Miklos Vajna vmik...@suse.cz --- On Mon, Jul 01, 2013 at 04:52:29PM +0200, Michael Haggerty

Re: [PATCH v3] cherry-pick: make sure all input objects are commits

On Thu, May 09, 2013 at 01:27:49PM -0700, Junio C Hamano gits...@pobox.com wrote: I'd apply this before -rc2. I _think_ it is also OK to just let lookup_commit_reference_gently() barf with its standard message error: Object %s is a %s, not a commit without an extra

[PATCH v2] cherry-pick: make sure all input objects are commits

-commits, we ignored those arguments. Instead, now make sure all arguments are commits, and for the first non-commit, error out with: fatal: name: Can't cherry-pick a type Signed-off-by: Miklos Vajna vmik...@suse.cz --- On Mon, Apr 08, 2013 at 09:56:55AM -0700, Junio C Hamano gits

Re: [PATCH v2] cherry-pick: make sure all input objects are commits

On Thu, Apr 11, 2013 at 03:52:44PM +0530, Ramkumar Ramachandra artag...@gmail.com wrote: + for (i = 0; i opts-revs-pending.nr; i++) { + unsigned char sha1[20]; + const char *name = opts-revs-pending.objects[i].name; + + if

[PATCH v3] cherry-pick: make sure all input objects are commits

-commits, we ignored those arguments. Fix this bug and make sure all arguments are commits, and for the first non-commit, error out with: fatal: name: Can't cherry-pick a type Signed-off-by: Miklos Vajna vmik...@suse.cz --- On Thu, Apr 11, 2013 at 05:12:06PM +0530, Ramkumar Ramachandra

Re: [PATCH] cherry-pick: better error message when the parameter is a non-commit

Hi, On Wed, Apr 03, 2013 at 11:27:04AM +0200, Miklos Vajna vmik...@suse.cz wrote: When copypaste goes wrong, and the user e.g. tries to cherry-pick a blob, the error message used to be: fatal: BUG: expected exactly one commit from walk Instead, now it is: fatal: Can't

[PATCH] cherry-pick: better error message when the parameter is a non-commit

When copypaste goes wrong, and the user e.g. tries to cherry-pick a blob, the error message used to be: fatal: BUG: expected exactly one commit from walk Instead, now it is: fatal: Can't cherry-pick a blob Signed-off-by: Miklos Vajna vmik...@suse.cz --- sequencer.c | 9

[PATCH] cherry-pick -x: improve handling of one-liner commit messages

git cherry-pick -x normally just appends the cherry picked from commit line at the end of the message, which is fine. However, in case the original commit message had only one line, first append a newline, otherwise the second line won't be empty, which is against recommendations. --- sequencer.c

Re: [PATCH] cherry-pick -x: improve handling of one-liner commit messages

Hi, On Fri, Mar 29, 2013 at 10:41:17AM -0700, Brandon Casey draf...@gmail.com wrote: Sign-off? Indeed, I forgot about it, my bad. I think this is part of the bc/append-signed-off-by topic that is about to graduate to 'master'; more specifically, b971e04f54e7 (sequencer.c: always

[PATCH v4] cherry-pick: don't forget -s on failure

there is already a relevant Signed-off-by line before the Conflicts: line, it won't add one more at the end of the message. If there is no such line, then add it before the the Conflicts: line. Signed-off-by: Miklos Vajna vmik...@suse.cz --- On Thu, Sep 13, 2012 at 02:13:46PM -0700, Junio C Hamano gits

[PATCH v2] cherry-pick: don't forget -s on failure

there is already a relevant Signed-off-by line before the Conflicts: line, it won't add one more at the end of the message. Signed-off-by: Miklos Vajna vmik...@suse.cz --- On Wed, Sep 12, 2012 at 03:45:10PM -0700, Junio C Hamano gits...@pobox.com wrote: - The additional S-o-b should come immediately after

[PATCH v3] cherry-pick: don't forget -s on failure

there is already a relevant Signed-off-by line before the Conflicts: line, it won't add one more at the end of the message. If there is no such line, then add it before the the Conflicts: line. Signed-off-by: Miklos Vajna vmik...@suse.cz --- This is somewhat iffy. Shouldn't test_commit --signoff --notick

Re: [PATCH] man: git pull -r is a short for --rebase

On Thu, Aug 16, 2012 at 11:18:40PM -0700, Junio C Hamano gits...@pobox.com wrote: From: Miklos Vajna vmik...@suse.cz Date: Thu, 16 Aug 2012 11:50:18 +0200 Subject: [PATCH] man: git pull -r is a short for --rebase Letting the --rebase option squat on the short-and-sweet single letter option

[PATCH] man: git pull -r is a short for --rebase

--- Documentation/git-pull.txt |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/Documentation/git-pull.txt b/Documentation/git-pull.txt index defb544..67fa5ee 100644 --- a/Documentation/git-pull.txt +++ b/Documentation/git-pull.txt @@ -101,6 +101,7 @@

Re: [PATCH] man: git pull -r is a short for --rebase

On Thu, Aug 16, 2012 at 02:09:33PM -0700, Junio C Hamano gits...@pobox.com wrote: The reason I do not think pull -r gives much value to the users to trigger pull --rebase is because the use of pull --rebase is very project specific. If you are working on a project that forbids merges, you