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 change
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
> it (both its desi
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 " line. This is well-supported
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
Reviewed
On Thu, May 08, 2014 at 07:58:13PM -0500, Felipe Contreras
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 today, I guess.
signat
Hi Jonathan,
On Tue, Feb 04, 2014 at 11:48:42AM -0800, Jonathan Nieder
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.
Thanks a lot,
Miklos
On Tue, Feb 04, 2014 at 06:37:13PM +0100, Miklos Vajna
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 t
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
g
On Thu, Oct 03, 2013 at 08:17:32PM +0100, John Keeping
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 list: send the li
Hi,
On Tue, Jul 23, 2013 at 12:53:25PM +0530, Ramkumar Ramachandra
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 notice sooner
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 Vaj
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
---
On Mon, Jul 01, 2013 at 04:52:29PM +
On Mon, Jul 01, 2013 at 08:38:21AM -0700, Junio C Hamano
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 the esta
Hi Michael,
On Mon, Jul 01, 2013 at 04:52:29PM +0200, Michael Haggerty
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 ot
t makes sense to use 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
---
builtin/merge.c | 12
t/t7600-merge.sh | 11 ---
2 files changed,
On Thu, May 09, 2013 at 01:27:49PM -0700, Junio C Hamano
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 sha1_object_info() call in t
-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: : Can't cherry-pick a
Signed-off-by: Miklos Vajna
---
On Thu, Apr 11, 2013 at 05:12:06PM +0530, Ramkumar Ramachandra
wrote:
> Then wh
On Thu, Apr 11, 2013 at 03:52:44PM +0530, Ramkumar Ramachandra
wrote:
> > + for (i = 0; i < opts->revs->pending.nr; i++) {
> > + unsigned char sha1[20];
> > + const char *name = opts->revs->pending.objects[i].name;
> > +
> > + if (!get_sha1(name, sh
-commits, we ignored those
arguments. Instead, now make sure all arguments are commits, and for
the first non-commit, error out with:
fatal: : Can't cherry-pick a
Signed-off-by: Miklos Vajna
---
On Mon, Apr 08, 2013 at 09:56:55AM -0700, Junio C Hamano
wrote:
> In other words,
Hi,
On Wed, Apr 03, 2013 at 11:27:04AM +0200, Miklos Vajna wrote:
> When copy&paste 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:
>
>
When copy&paste 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
---
sequencer.c | 9
Hi,
On Fri, Mar 29, 2013 at 10:41:17AM -0700, Brandon Casey
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 separate "(cherr
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.
x27;, so that in case 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
---
On Thu, Sep 13, 2012 at 02:13:46PM -0700
x27;, so that in case 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
---
> This is somewhat iffy. Shouldn&#x
x27;, so that in case 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
---
On Wed, Sep 12, 2012 at 03:45:10PM -0700, Junio C Hamano
wrote:
> - The additional S-o-b should come imme
In case 'git cherry-pick -s ' failed, the user had to use 'git
commit -s' (i.e. state the -s option again), which is easy to forget
about. Instead, write the signed-off-by line early, so plain 'git
commit' will have the same result.
Signed-off-by: Mi
On Thu, Aug 16, 2012 at 11:18:40PM -0700, Junio C Hamano
wrote:
> From: Miklos Vajna
> 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 o
On Thu, Aug 16, 2012 at 02:09:33PM -0700, Junio C Hamano
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 would _alw
Hi,
On Thu, Aug 16, 2012 at 09:22:14AM -0700, Junio C Hamano
wrote:
> I am not sure if this is worth it, as it comes from a natural
> "abbreviated options" support, i.e.
>
> -r|--r|--re|--reb|--reba|--rebas|--rebase)
> rebase=true
I sent the patch as a (newcomer) friend tod
---
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 @@ include::merge-options
31 matches
Mail list logo
