* Re: git notes: notes
From: Jeff King @ 2010-01-20 21:36 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Michael J Gruber, Joey Hess, git
In-Reply-To: <7veilk1o3s.fsf@alter.siamese.dyndns.org>
On Wed, Jan 20, 2010 at 01:08:07PM -0800, Junio C Hamano wrote:
> > No, but outputting the note as part of the log is the standard. So for
> > example, when you do a format-patch | apply cycle, format-patch will
> > insert the note as part of the commit message, and apply will *store*
> > the note text (including Note:\n) as part of the commit message of the
> > new commit.
>
> Thanks; that was the kind of breakage report I was looking for (and wished
> to have heard a lot earlier). Personally I find it is unexcusable that
> format-patch defaults to giving notes.
I agree. I noticed this while doing the "don't show in raw" feature
elsewhere in the thread and wanted to ask: which formats _should_ have
notes by default?
To be honest, I am not sure _any_ format should have it by default. If I
am running "git log" and my notes are filled with random automatically
generated bisection cruft, I don't want to see that cluttering my
output. Yes, all of our test notes are human-written annotations, but I
think we really don't know yet what sorts of things people will be
putting in them.
Long ago I proposed a set of notes namespaces to deal with this (so
automatic bisection cruft would go into its own notes namespace, and
human-readable ones would be in some default namespace), but I don't
know how much of that idea (if any) survived into the current
implementation.
> > I'm not complaining, I actually have this on a maybe-to-do list, but the
> > way the series went kept me from investing time.
>
> Hmm, that hints there is a failure in the review and merge process. Care
> to explain how we could have done better please?
Personally, I stopped paying attention simply because it was gigantic
and I am not all that interested in using the feature personally.
-Peff
^ permalink raw reply
* Re: git notes: notes
From: Jeff King @ 2010-01-20 21:31 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Joey Hess, git
In-Reply-To: <7viqaw1ohx.fsf@alter.siamese.dyndns.org>
On Wed, Jan 20, 2010 at 12:59:38PM -0800, Junio C Hamano wrote:
> Jeff King <peff@peff.net> writes:
>
> > Is splitting on blank lines an error? I don't think so. The original
> > format was never strictly defined, but given the --pretty=raw format, it
> > seems like a fairly obvious thing to do.
> >
> > I am inclined to cut the notes output from --pretty=raw, and let callers
> > ask for them explicitly with --show-notes or something similar. We can
> > leave them on by default in the "normal" output. This will still break
> > scripts doing "git log | ./script", but I don't think we have ever
> > condoned that practice.
>
> Sounds like a plan.
We can start with this patch, which clears up Joey's problem.
-- >8 --
Subject: [PATCH] don't show notes for --pretty=raw
The --pretty=raw format of the log family is likely to be
used by scripts. Such scripts may parse the output into
records on blank lines, since doing so in the past has
always worked. However, with the recently added notes
output, such parsers will see an extra stanza for any
commits that have notes.
This patch turns off the notes output for the raw format to
avoid breaking such scripts.
Signed-off-by: Jeff King <peff@peff.net>
---
pretty.c | 2 +-
t/t3301-notes.sh | 14 ++++++++++++++
2 files changed, 15 insertions(+), 1 deletions(-)
diff --git a/pretty.c b/pretty.c
index 9001379..0674027 100644
--- a/pretty.c
+++ b/pretty.c
@@ -1094,7 +1094,7 @@ void pretty_print_commit(enum cmit_fmt fmt, const struct commit *commit,
if (fmt == CMIT_FMT_EMAIL && sb->len <= beginning_of_body)
strbuf_addch(sb, '\n');
- if (fmt != CMIT_FMT_ONELINE)
+ if (fmt != CMIT_FMT_ONELINE && fmt != CMIT_FMT_RAW)
get_commit_notes(commit, sb, encoding,
NOTES_SHOW_HEADER | NOTES_INDENT);
diff --git a/t/t3301-notes.sh b/t/t3301-notes.sh
index 1e34f48..4c3de9d 100755
--- a/t/t3301-notes.sh
+++ b/t/t3301-notes.sh
@@ -147,4 +147,18 @@ test_expect_success 'show -m and -F notes' '
test_cmp expect-m-and-F output
'
+cat >expect << EOF
+commit 15023535574ded8b1a89052b32673f84cf9582b8
+tree e070e3af51011e47b183c33adf9736736a525709
+parent 1584215f1d29c65e99c6c6848626553fdd07fd75
+author A U Thor <author@example.com> 1112912173 -0700
+committer C O Mitter <committer@example.com> 1112912173 -0700
+
+ 4th
+EOF
+test_expect_success 'git log --pretty=raw does not show notes' '
+ git log -1 --pretty=raw >output &&
+ test_cmp expect output
+'
+
test_done
--
1.6.6.510.g159cf
^ permalink raw reply related
* Re: git equivalent to clearcase wink-in
From: Robin Rosenberg @ 2010-01-20 21:24 UTC (permalink / raw)
To: Jamie Wellnitz; +Cc: Richard Assal, git
In-Reply-To: <7938b46a1001201305j499e05bg2654d634d7b26d76@mail.gmail.com>
onsdagen den 20 januari 2010 22.05.46 skrev Jamie Wellnitz:
> Would something like ccache (compiler cache) help you out? It's not
> the same as wink-in (which, as I understand it, copies an already
> built object file from someone else who has built it). Instead each
> user has their own cache, so everyone has to pay the expensive build
> price at least once.
>
> It also only works for C/C++, I think.
Judging from the documentation you can share the cache with others.
-- robin
^ permalink raw reply
* Re: git equivalent to clearcase wink-in
From: Mike Hommey @ 2010-01-20 21:12 UTC (permalink / raw)
To: Jamie Wellnitz; +Cc: Richard Assal, git
In-Reply-To: <7938b46a1001201305j499e05bg2654d634d7b26d76@mail.gmail.com>
On Wed, Jan 20, 2010 at 04:05:46PM -0500, Jamie Wellnitz wrote:
> Would something like ccache (compiler cache) help you out? It's not
> the same as wink-in (which, as I understand it, copies an already
> built object file from someone else who has built it). Instead each
> user has their own cache, so everyone has to pay the expensive build
> price at least once.
Surely the ccache directory could be shared on nfs or some other network
filesystem. Or object file could be checked in, which is imho ugly, but
should work (better to do that on a separate branch)
Mike
^ permalink raw reply
* Re: git notes: notes
From: Junio C Hamano @ 2010-01-20 21:08 UTC (permalink / raw)
To: Michael J Gruber; +Cc: Junio C Hamano, Joey Hess, git
In-Reply-To: <4B576F5C.2050102@drmicha.warpmail.net>
Michael J Gruber <git@drmicha.warpmail.net> writes:
> Junio C Hamano venit, vidit, dixit 20.01.2010 21:10:
>> Joey Hess <joey@kitenet.net> writes:
>>
>>> Do you think it makes sense for even git log --format=format:%s to be
>>> porcelain and potentially change when new features are used?
>>
>> If the series changed the meaning of "%s" format to mean "the subject of
>> the commit and notes information", with or without documenting it, then it
>> is just a bug we would like to fix.
>
> No, but outputting the note as part of the log is the standard. So for
> example, when you do a format-patch | apply cycle, format-patch will
> insert the note as part of the commit message, and apply will *store*
> the note text (including Note:\n) as part of the commit message of the
> new commit.
Thanks; that was the kind of breakage report I was looking for (and wished
to have heard a lot earlier). Personally I find it is unexcusable that
format-patch defaults to giving notes.
> So, I would say the notes feature is not that well integrated right now,
No question about it.
> I'm not complaining, I actually have this on a maybe-to-do list, but the
> way the series went kept me from investing time.
Hmm, that hints there is a failure in the review and merge process. Care
to explain how we could have done better please?
^ permalink raw reply
* Re: git equivalent to clearcase wink-in
From: Jamie Wellnitz @ 2010-01-20 21:05 UTC (permalink / raw)
To: Richard Assal; +Cc: git
In-Reply-To: <810256.84037.qm@web45111.mail.sp1.yahoo.com>
Would something like ccache (compiler cache) help you out? It's not
the same as wink-in (which, as I understand it, copies an already
built object file from someone else who has built it). Instead each
user has their own cache, so everyone has to pay the expensive build
price at least once.
It also only works for C/C++, I think.
-- Jamie
On Wed, Jan 20, 2010 at 3:20 PM, Richard Assal <richard_assal@yahoo.com> wrote:
> To whom it may concer,
>
> I have been playing with git recently, and I like it very much. I was wondering if you can tell me if git has something that is equivalent to clearcase wink-in functionality. The reason I ask, if it takes 1 hour to build my repository, then every clone of my repository will also take one hour to build at the remote location. In clearcase you can wink in objects that have already been built. time to wink in could just be minutes rather than waiting a full hour for all the binaries to build.
>
> Can you help me out here? I would like to know if git has something similar.
>
> Richard.
>
>
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply
* Re: git notes: notes
From: Michael J Gruber @ 2010-01-20 21:02 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Joey Hess, git
In-Reply-To: <7vska01qrt.fsf@alter.siamese.dyndns.org>
Junio C Hamano venit, vidit, dixit 20.01.2010 21:10:
> Joey Hess <joey@kitenet.net> writes:
>
>> Do you think it makes sense for even git log --format=format:%s to be
>> porcelain and potentially change when new features are used?
>
> If the series changed the meaning of "%s" format to mean "the subject of
> the commit and notes information", with or without documenting it, then it
> is just a bug we would like to fix.
No, but outputting the note as part of the log is the standard. So for
example, when you do a format-patch | apply cycle, format-patch will
insert the note as part of the commit message, and apply will *store*
the note text (including Note:\n) as part of the commit message of the
new commit.
So, I would say the notes feature is not that well integrated right now,
and either log has to learn --no-notes (and format-patch has to use it,
or rather the corresponding internal flag), or apply has to learn to
parse "Note:" headers. Or, depending on how you use notes, it may be
better if format-patch puts the note after the "--"; that way you can
store the usual "after-the-message" patch comments in a note.
Similarly, I don't think rebasing and cherry-picking adjust the notes
tree for commits with notes whose sha1 changes - which may or may not be
the appropriate behaviour.
In both cases, the "right" way depends on how you use notes, and there
should be an easy way to specify your choice.
I'm not complaining, I actually have this on a maybe-to-do list, but the
way the series went kept me from investing time.
Cheers,
Michael
^ permalink raw reply
* Re: git notes: notes
From: Junio C Hamano @ 2010-01-20 20:59 UTC (permalink / raw)
To: Jeff King; +Cc: Joey Hess, git
In-Reply-To: <20100120205452.GA8843@coredump.intra.peff.net>
Jeff King <peff@peff.net> writes:
> Is splitting on blank lines an error? I don't think so. The original
> format was never strictly defined, but given the --pretty=raw format, it
> seems like a fairly obvious thing to do.
>
> I am inclined to cut the notes output from --pretty=raw, and let callers
> ask for them explicitly with --show-notes or something similar. We can
> leave them on by default in the "normal" output. This will still break
> scripts doing "git log | ./script", but I don't think we have ever
> condoned that practice.
Sounds like a plan.
^ permalink raw reply
* Re: [PATCH 0/4] misc. msvc patches
From: Junio C Hamano @ 2010-01-20 20:57 UTC (permalink / raw)
To: Ramsay Jones; +Cc: Junio C Hamano, Johannes Sixt, GIT Mailing-list
In-Reply-To: <4B57573E.2050006@ramsay1.demon.co.uk>
I only looked at regex/regex.c and it really is a real bugfix as the
structure fields are of pointer type ;-).
I'll wait for Hannes, Sebastian Shuberth and/or Marius Storm-Olsen, as
they appear in "git shortlog compat/vcbuild contrib/buildsystems", for
their Acks.
Thanks.
^ permalink raw reply
* Re: [PATCH 1/4] engine.pl: Fix a recent breakage of the buildsystem generator
From: Pete Harlan @ 2010-01-20 20:57 UTC (permalink / raw)
To: Ramsay Jones; +Cc: Junio C Hamano, Johannes Sixt, sschuberth, GIT Mailing-list
In-Reply-To: <4B575838.2010504@ramsay1.demon.co.uk>
On 01/20/2010 11:23 AM, Ramsay Jones wrote:
> diff --git a/contrib/buildsystems/engine.pl b/contrib/buildsystems/engine.pl
> index d506717..245af73 100644
> --- a/contrib/buildsystems/engine.pl
> +++ b/contrib/buildsystems/engine.pl
> @@ -135,6 +135,11 @@ sub parseMakeOutput
> }
> } while($ate_next);
>
> + if ($text =~ /^test / && $text =~ /|| rm -f /) {
That test on the right needs to escape its pipes or it will always match.
--Pete
> + # commands removing executables, if they exist
> + next;
> + }
> +
> if($text =~ / -c /) {
> # compilation
> handleCompileLine($text, $line);
^ permalink raw reply
* Re: git notes: notes
From: Jeff King @ 2010-01-20 20:54 UTC (permalink / raw)
To: Joey Hess; +Cc: git
In-Reply-To: <20100120203636.GA9221@gnu.kitenet.net>
On Wed, Jan 20, 2010 at 03:36:36PM -0500, Joey Hess wrote:
> I was asking hypothetically, trying to point out that parts of git log
> seem to make sense to be used as plumbing, with the hope I can continue
> to use it that way.
>
> (Note that git instaweb parses output of git log --pretty=format:%H --raw
> like it's plumbing.)
I think this is a valid point. Note that "gitk" uses "git log
--pretty=raw". However, I believe it splits the entries on "^commit". So
I think there is some precedent for scripting "git log"; it has features
that are simply not available through other interfaces. And scripting
around "--pretty=raw" seems pretty reasonable to me, too. Why else would
you want the raw format?
Is splitting on blank lines an error? I don't think so. The original
format was never strictly defined, but given the --pretty=raw format, it
seems like a fairly obvious thing to do.
I am inclined to cut the notes output from --pretty=raw, and let callers
ask for them explicitly with --show-notes or something similar. We can
leave them on by default in the "normal" output. This will still break
scripts doing "git log | ./script", but I don't think we have ever
condoned that practice.
-Peff
^ permalink raw reply
* Re: git notes: notes
From: Joey Hess @ 2010-01-20 20:36 UTC (permalink / raw)
To: git
In-Reply-To: <7vska01qrt.fsf@alter.siamese.dyndns.org>
[-- Attachment #1: Type: text/plain, Size: 754 bytes --]
Junio C Hamano wrote:
> Joey Hess <joey@kitenet.net> writes:
>
> > Do you think it makes sense for even git log --format=format:%s to be
> > porcelain and potentially change when new features are used?
>
> If the series changed the meaning of "%s" format to mean "the subject of
> the commit and notes information", with or without documenting it, then it
> is just a bug we would like to fix.
>
> But I cannot reproduce such a bug. In my tree locally:
I was asking hypothetically, trying to point out that parts of git log
seem to make sense to be used as plumbing, with the hope I can continue
to use it that way.
(Note that git instaweb parses output of git log --pretty=format:%H --raw
like it's plumbing.)
--
see shy jo
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 828 bytes --]
^ permalink raw reply
* [PATCH 4/4] msvc: Add a definition of NORETURN compatible with msvc compiler
From: Ramsay Jones @ 2010-01-20 19:45 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Johannes Sixt, GIT Mailing-list, kusmabite
Signed-off-by: Ramsay Jones <ramsay@ramsay1.demon.co.uk>
---
I thought that Erik had already submitted this patch along with
those that resulted in commits a4f3131c and 18660bc9. However, I
don't seem to be able to find it anywhere! (maybe I only imagined
it).
If you find Erik's patch, please apply that instead...
ATB,
Ramsay Jones
git-compat-util.h | 3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/git-compat-util.h b/git-compat-util.h
index 5c59687..6efea29 100644
--- a/git-compat-util.h
+++ b/git-compat-util.h
@@ -177,6 +177,9 @@ extern char *gitbasename(char *);
#ifdef __GNUC__
#define NORETURN __attribute__((__noreturn__))
#define NORETURN_PTR __attribute__((__noreturn__))
+#elif defined(_MSC_VER)
+#define NORETURN __declspec(noreturn)
+#define NORETURN_PTR
#else
#define NORETURN
#define NORETURN_PTR
--
1.6.6
^ permalink raw reply related
* [PATCH 2/4] msvc: Fix an "unrecognized option" linker warning
From: Ramsay Jones @ 2010-01-20 19:25 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Johannes Sixt, GIT Mailing-list
Having recently added support for building git-imap-send on
Windows, we now link against OpenSSL libraries, and the linker
issues the following warning:
warning LNK4044: unrecognized option '/lssl'; ignored
In order to suppress the warning, we change the msvc linker
script to translate an '-lssl' parameter to the ssleay32.lib
library.
Note that the linker script was already including ssleay32.lib
(along with libeay32.lib) as part of the translation of the
'-lcrypto' library parameter. However, libeay32.dll does not
depend on ssleay32.dll and can be used stand-alone, so we remove
ssleay32.lib from the '-lcrypto' translation.
The dependence of ssleay32.dll on libeay32.dll is represented in
the Makefile by the NEEDS_CRYPTO_WITH_SSL build variable.
Also, add the corresponding change to the buildsystem generator.
Signed-off-by: Ramsay Jones <ramsay@ramsay1.demon.co.uk>
---
compat/vcbuild/scripts/clink.pl | 1 +
contrib/buildsystems/engine.pl | 1 +
2 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/compat/vcbuild/scripts/clink.pl b/compat/vcbuild/scripts/clink.pl
index 8a2112f..4374771 100644
--- a/compat/vcbuild/scripts/clink.pl
+++ b/compat/vcbuild/scripts/clink.pl
@@ -31,6 +31,7 @@ while (@ARGV) {
push(@args, "iconv.lib");
} elsif ("$arg" eq "-lcrypto") {
push(@args, "libeay32.lib");
+ } elsif ("$arg" eq "-lssl") {
push(@args, "ssleay32.lib");
} elsif ("$arg" =~ /^-L/ && "$arg" ne "-LTCG") {
$arg =~ s/^-L/-LIBPATH:/;
diff --git a/contrib/buildsystems/engine.pl b/contrib/buildsystems/engine.pl
index 245af73..ce4eb1e 100644
--- a/contrib/buildsystems/engine.pl
+++ b/contrib/buildsystems/engine.pl
@@ -322,6 +322,7 @@ sub handleLinkLine
push(@libs, "zlib.lib");
} elsif ("$part" eq "-lcrypto") {
push(@libs, "libeay32.lib");
+ } elsif ("$part" eq "-lssl") {
push(@libs, "ssleay32.lib");
} elsif ($part =~ /^-/) {
push(@lflags, $part);
--
1.6.6
^ permalink raw reply related
* [PATCH 3/4] msvc: Fix a compiler warning due to an incorrect pointer cast
From: Ramsay Jones @ 2010-01-20 19:34 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Johannes Sixt, GIT Mailing-list
Signed-off-by: Ramsay Jones <ramsay@ramsay1.demon.co.uk>
---
The warning in question being:
.../regex.c(2811) : warning C4047: '=' : 'regoff_t *' differs in levels \
of indirection from 'int'
Note also that the final line of context in the diff below contains an ^L
character, which will hopefully find it's way to the list...
ATB,
Ramsay Jones
compat/regex/regex.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/compat/regex/regex.c b/compat/regex/regex.c
index 67d5c37..556d8ab 100644
--- a/compat/regex/regex.c
+++ b/compat/regex/regex.c
@@ -2808,7 +2808,7 @@ re_set_registers (bufp, regs, num_regs, starts, ends)
{
bufp->regs_allocated = REGS_UNALLOCATED;
regs->num_regs = 0;
- regs->start = regs->end = (regoff_t) 0;
+ regs->start = regs->end = (regoff_t *) 0;
}
}
\f
--
1.6.6
^ permalink raw reply related
* [PATCH 1/4] engine.pl: Fix a recent breakage of the buildsystem generator
From: Ramsay Jones @ 2010-01-20 19:23 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Johannes Sixt, sschuberth, GIT Mailing-list
Commit ade2ca0c (Do not try to remove directories when removing
old links, 27-10-2009) added an expression to a 'test' using an
'-o' or connective. This resulted in the buildsystem generator
mistaking the conditional 'rm' for a linker command. In order
to fix the breakage, we filter the out the conditional 'rm'
commands before attempting to identify other commands.
Signed-off-by: Ramsay Jones <ramsay@ramsay1.demon.co.uk>
---
contrib/buildsystems/engine.pl | 5 +++++
1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/contrib/buildsystems/engine.pl b/contrib/buildsystems/engine.pl
index d506717..245af73 100644
--- a/contrib/buildsystems/engine.pl
+++ b/contrib/buildsystems/engine.pl
@@ -135,6 +135,11 @@ sub parseMakeOutput
}
} while($ate_next);
+ if ($text =~ /^test / && $text =~ /|| rm -f /) {
+ # commands removing executables, if they exist
+ next;
+ }
+
if($text =~ / -c /) {
# compilation
handleCompileLine($text, $line);
--
1.6.6
^ permalink raw reply related
* [PATCH 0/4] misc. msvc patches
From: Ramsay Jones @ 2010-01-20 19:19 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Johannes Sixt, GIT Mailing-list
Hi Junio,
Since we can now build git on Cygwin using msvc, I've been looking to
suppress the *many* compiler warnings issued by msvc; OK I haven't been
trying too hard, since Windows is not my main platform and msvc is not
my primary compiler! ;-) However, every little helps...
The following patches have been hanging around for several weeks, so I
decided to pass them on now rather than wait until I get around to finishing
the other patches.
[PATCH 1/4] engine.pl: Fix a recent breakage of the buildsystem generator
[PATCH 2/4] msvc: Fix an "unrecognized option" linker warning
[PATCH 3/4] msvc: Fix a compiler warning due to an incorrect pointer cast
[PATCH 4/4] msvc: Add a definition of NORETURN compatible with msvc compiler
These patches remove 86 warnings for me (84 of those due to patch #4).
I have another (small) patch which avoids 109 further warnings, but I
want to provide an alternative solution; this solution is currently a
4 patch series which only removes about 60 warnings so far...
ATB,
Ramsay Jones
^ permalink raw reply
* Dangerous new server status for deleted files
From: Pal-Kristian Engstad @ 2010-01-20 20:16 UTC (permalink / raw)
To: Simon Hausmann; +Cc: Junio C Hamano, git
[-- Attachment #1: Type: text/plain, Size: 674 bytes --]
Hi,
Our new Perforce server (P4D/NTX64/2009.2/228098 2009/12/16) seems to be
giving out 'move/delete' instead of the old 'delete' status for files
that are moved within the repo. Attached is the simple patch to fix it.
(By the way: How do you "sign off" a patch?) This is urgent, as it will
corrupt git repos trying to track a Perforce depot.
Thanks,
PKE.
--
Pål-Kristian Engstad (engstad@naughtydog.com),
Lead Graphics & Engine Programmer,
Naughty Dog, Inc., 1601 Cloverfield Blvd, 6000 North,
Santa Monica, CA 90404, USA. Ph.: (310) 633-9112.
"Emacs would be a far better OS if it was shipped with
a halfway-decent text editor." -- Slashdot, Dec 13. 2005.
[-- Attachment #2: 0001-git-p4-Fix-sync-errors-due-to-new-server-version.patch --]
[-- Type: text/plain, Size: 1079 bytes --]
From bbc0cf2dbd318faaf5731b684d67c5b2126cb1e0 Mon Sep 17 00:00:00 2001
From: Pal-Kristian Engstad <pal_engstad@naughtydog.com>
Date: Wed, 20 Jan 2010 12:07:21 -0800
Subject: [PATCH] git-p4: Fix sync errors due to new server version.
New server P4D/NTX64/2009.2/228098 (2009/12/16) reports 'move/delete' instead of 'delete'. This causes files that are
moved to leave their old file in git. Fixed by adding the new status string.
---
contrib/fast-import/git-p4 | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/contrib/fast-import/git-p4 b/contrib/fast-import/git-p4
index 6303449..ef7c23b 100755
--- a/contrib/fast-import/git-p4
+++ b/contrib/fast-import/git-p4
@@ -1089,7 +1089,7 @@ class P4Sync(Command):
if includeFile:
filesForCommit.append(f)
- if f['action'] not in ('delete', 'purge'):
+ if f['action'] not in ('delete', 'move/delete', 'purge'):
filesToRead.append(f)
else:
filesToDelete.append(f)
--
1.6.5.2.6.gc3c1e.dirty
^ permalink raw reply related
* git equivalent to clearcase wink-in
From: Richard Assal @ 2010-01-20 20:20 UTC (permalink / raw)
To: git
To whom it may concer,
I have been playing with git recently, and I like it very much. I was wondering if you can tell me if git has something that is equivalent to clearcase wink-in functionality. The reason I ask, if it takes 1 hour to build my repository, then every clone of my repository will also take one hour to build at the remote location. In clearcase you can wink in objects that have already been built. time to wink in could just be minutes rather than waiting a full hour for all the binaries to build.
Can you help me out here? I would like to know if git has something similar.
Richard.
^ permalink raw reply
* Re: git notes: notes
From: Junio C Hamano @ 2010-01-20 20:10 UTC (permalink / raw)
To: Joey Hess; +Cc: git
In-Reply-To: <20100120195626.GA6641@gnu.kitenet.net>
Joey Hess <joey@kitenet.net> writes:
> Do you think it makes sense for even git log --format=format:%s to be
> porcelain and potentially change when new features are used?
If the series changed the meaning of "%s" format to mean "the subject of
the commit and notes information", with or without documenting it, then it
is just a bug we would like to fix.
But I cannot reproduce such a bug. In my tree locally:
$ git notes show a97a74
Origin of commit notes feature was at
a97a74).
$ git show -s --pretty=short a97a74
commit a97a74686d70a318cd802003498054cc1e8b0ae2
Author: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Introduce commit notes
Notes:
Origin of commit notes feature was at
a97a74).
$ git show -s --pretty=format:%s a97a74
Introduce commit notes
Puzzled...
^ permalink raw reply
* Re: git notes: notes
From: Joey Hess @ 2010-01-20 19:56 UTC (permalink / raw)
To: git
In-Reply-To: <7vhbqg376b.fsf@alter.siamese.dyndns.org>
[-- Attachment #1: Type: text/plain, Size: 1037 bytes --]
Junio C Hamano wrote:
> Let me ask a stupid question. Did the output change before and after the
> notes code even when your history does not have notes?
No.
> >> > Might be worth documenting in release notes, maybe too late now though.
>
> This depends on the answer to the above question. If the answers is "No",
> then I don't see the need to say much more than "New 'git notes' feature
> allows comments applied to existing commits after the fact to be shown by
> log and friends". If it is "Yes", we should fix the code not to change
> the output.
>
> In any case, "log" is still a Porcelain, so it is understandable that by
> triggering a new feature you would get output from the new feature. It is
> called progress ;-)
Do you think it makes sense for even git log --format=format:%s to be
porcelain and potentially change when new features are used? Seems to
me that parts of git log walk the line between porcelain and plumbing.
So it's not clear which parts are safe to use.
--
see shy jo
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 828 bytes --]
^ permalink raw reply
* Re: [PATCH] Fix memory corruption when .gitignore does not end by \n
From: Junio C Hamano @ 2010-01-20 19:51 UTC (permalink / raw)
To: Nguyễn Thái Ngọc Duy
Cc: git, Jeff King, Jonathan del Strother
In-Reply-To: <1263996556-9712-1-git-send-email-pclouds@gmail.com>
Nguyễn Thái Ngọc Duy <pclouds@gmail.com> writes:
> This patch causes a crash for me. Not sure if it does for anybody else.
I am puzzled. What do you mean by this? If this patch makes the code
crash, then it is not a fix. Is this meant as "Jonathan, can you try this
patch and tell me what happens, so that I can diagnose the issue better?"
patch?
Is it better/safer to revert the entire nd/sparse topic from the master in
the meantime before we know what is going on?
^ permalink raw reply
* Re: [RFC] What to you think about a loose status for submodules?
From: Junio C Hamano @ 2010-01-20 19:45 UTC (permalink / raw)
To: Heiko Voigt; +Cc: git, Jens Lehmann, Lars Hjemli
In-Reply-To: <20100120181652.GA10803@book.hvoigt.net>
Heiko Voigt <hvoigt@hvoigt.net> writes:
> Even though there has not been much more work on this item the idea has
> become much clearer for me since the last discussion. Now that sparse
> checkout is in master I would like to generalize this idea a little
> further.
Selective init/update of submodules is a fundamental design element and
the presense of "sparse checkout" does not affect it.
In the remainder of your message
> How about ...
you are talking about a change that would also apply to a project that
does not have submodules at all, and you would want to involve Nguyễn in
the discussion.
I have no strong opinion if attributes is the right vehicle to carry this
information, except for this part:
> Does the current sparse implementation work with submodule entries as
> well? Then it could be even more straightforward to implement than the
> previous idea.
What the project ships as grouping suggestions to cloners is merely a
small part of the information on submodules (others such as URL and name
are already found in .gitmodules, and .gitmodules are designed to be
extensible by allowing other "config"-ish items in it). Separating only
the grouping info into a different file (I don't particularly care if you
use .gitattributes or something else; as long as it is not .gitmodules,
the argument is the same) is not such a good idea.
^ permalink raw reply
* Re: git notes: notes
From: Junio C Hamano @ 2010-01-20 19:30 UTC (permalink / raw)
To: Joey Hess; +Cc: git
In-Reply-To: <20100120182438.GB31507@gnu.kitenet.net>
Joey Hess <joey@kitenet.net> writes:
> Johan Herland wrote:
>> As Thomas already stated, git log is porcelain, and its output format is not
>> set in stone. If you need a stable, script-friendly format, you should
>> probably use the --format option, or use plumbing instead (such as e.g. git
>> rev-list, which also has a --format option).
>
> But git log --format=raw --raw output was changed by notes.
Let me ask a stupid question. Did the output change before and after the
notes code even when your history does not have notes?
>> > Might be worth documenting in release notes, maybe too late now though.
This depends on the answer to the above question. If the answers is "No",
then I don't see the need to say much more than "New 'git notes' feature
allows comments applied to existing commits after the fact to be shown by
log and friends". If it is "Yes", we should fix the code not to change
the output.
In any case, "log" is still a Porcelain, so it is understandable that by
triggering a new feature you would get output from the new feature. It is
called progress ;-)
^ permalink raw reply
* Re: git-merge segfault in 1.6.6 and master
From: Junio C Hamano @ 2010-01-20 19:13 UTC (permalink / raw)
To: Tim Olsen; +Cc: git, Miklos Vajna, Johannes Schindelin
In-Reply-To: <hj7abm$5vc$1@ger.gmane.org>
Tim Olsen <tim@brooklynpenguin.com> writes:
> The following happens on 1.6.6 and master as of
> 5b15950ac414a8a2d4f5eb480712abcc9fe176d2. The problem goes away if I
> use the resolve merge strategy instead.
Thanks.
Since you can build and run git yourself, can I ask you to run another
experiment with this one-liner patch applied?
diff --git a/builtin-merge.c b/builtin-merge.c
index 82e2a04..08a8f24 100644
--- a/builtin-merge.c
+++ b/builtin-merge.c
@@ -550,7 +550,7 @@ static int try_merge_strategy(const char *strategy, struct commit_list *common,
return error("Unable to write index.");
rollback_lock_file(lock);
- if (!strcmp(strategy, "recursive") || !strcmp(strategy, "subtree")) {
+ if (0) {
int clean;
struct commit *result;
struct lock_file *lock = xcalloc(1, sizeof(struct lock_file));
This disables the codepath that special-cases the calling convention for
these merge strategies, and was introduce by 18668f5 (builtin-merge: avoid
run_command_v_opt() for recursive and subtree, 2008-08-28 -- authors Cc'ed
to ask for help in diagnosing).
If this experiment "fixes" the failure for you, then it would be a sign
that the caller (not necessarily in the code in this "if()" block) may be
doing something wrong (or more likely, not doing enough) before calling
into merge_recursive(). I am suspecting that it is not parsing some
commit objects properly, e.g. using lookup_commit(SHA-1) and using the
result without calling parse_object() on it first, or something similar
that is silly but trivial to fix.
After the experiment, please revert the above one-liner. I don't want to
use a work-around forever; we'd be better off finding where in the code it
goes wrong. Looking at your gdb trace, I notice...
> (gdb) r
> Starting program: /usr/local/bin/git merge origin/deployed
> [Thread debugging using libthread_db enabled]
> ...
> #3 0x0000000000499523 in merge_trees (o=0x7fffffffd5b0, head=0x77b058,
> merge=0x77b030, common=0x0, result=0x7fffffffd548) at merge-recursive.c:1209
> code = 8076320
> clean = 13064
"common = NULL" means merged_common_ancestors->tree is NULL in the caller.
Somebody is passing a bogus commit in "ca" (aka common ancestors) list
when calling merge_recursive(), or forgetting to parse them before calling
it. In your debugger could you find out where it comes from and what it
has before this call into merge_trees() is made? Specifically, what the
"ca" list at 0x7b3c00 contains, and how "merged_common_ancestors" at
0x121e360 looks like. in this trace we see below:
> #4 0x0000000000499a46 in merge_recursive (o=0x7fffffffd5b0,
> h1=0x7932d0, h2=0x793240, ca=0x7b3c00, result=0x7fffffffd628) at
> merge-recursive.c:1343
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox