On Tue, Oct 30, 2012 at 05:37:21PM -0700, Jonathan Nieder wrote:
If the commit does not have the SHOWN or UNINTERESTING flag set but it
is going to get the UNINTERESTING flag set during the walk because of
a negative commit listed on the command line, this patch won't help.
Right, so my
Jeff King wrote:
If so, then this series isn't regressing behavior; the only downside is
that it's an incomplete fix. In theory this could get in the way of the
full fix later on, but given the commit messages and the archive of this
discussion, it would be simple enough to revert it later in
Hi Peff,
On Fri, 2 Nov 2012, Jeff King wrote:
On Tue, Oct 30, 2012 at 05:37:21PM -0700, Jonathan Nieder wrote:
If the commit does not have the SHOWN or UNINTERESTING flag set but it
is going to get the UNINTERESTING flag set during the walk because of
a negative commit listed on the
On Fri, Nov 02, 2012 at 04:17:14PM +0100, Johannes Schindelin wrote:
If so, then this series isn't regressing behavior; the only downside is
that it's an incomplete fix. In theory this could get in the way of the
full fix later on, but given the commit messages and the archive of this
On Fri, Nov 2, 2012 at 2:12 PM, Jeff King p...@peff.net wrote:
On Tue, Oct 30, 2012 at 05:37:21PM -0700, Jonathan Nieder wrote:
If the commit does not have the SHOWN or UNINTERESTING flag set but it
is going to get the UNINTERESTING flag set during the walk because of
a negative commit listed
On Fri, Nov 2, 2012 at 4:19 PM, Jeff King p...@peff.net wrote:
On Fri, Nov 02, 2012 at 04:17:14PM +0100, Johannes Schindelin wrote:
May I just ask to include a summary of that rationale into the commit
message rather than relying on people having internet access and knowing
where to look?
Sverre Rabbelier wrote:
Thanks for the thorough explanation. Perhaps some of that could make
it's way into the commit message?
It's fine with me if it doesn't, since the original commit message
covers the basics (current behavior and intent of the change) in its
first two paragraphs and anyone
When an object has already been exported (and thus is in the marks) it
is flagged as SHOWN, so it will not be exported again, even if this time
it's exported through a different ref.
We don't need the object to be exported again, but we want the ref
updated, which doesn't happen.
Since we can't
Felipe Contreras wrote:
--- a/builtin/fast-export.c
+++ b/builtin/fast-export.c
@@ -523,11 +523,16 @@ static void get_tags_and_duplicates(struct object_array
*pending,
typename(e-item-type));
continue;
}
- if
On Tue, Oct 30, 2012 at 5:37 PM, Jonathan Nieder jrnie...@gmail.com wrote:
Felipe Contreras wrote:
--- a/builtin/fast-export.c
+++ b/builtin/fast-export.c
@@ -523,11 +523,16 @@ static void get_tags_and_duplicates(struct
object_array *pending,
On Wed, Oct 31, 2012 at 1:37 AM, Jonathan Nieder jrnie...@gmail.com wrote:
Felipe Contreras wrote:
--- a/builtin/fast-export.c
+++ b/builtin/fast-export.c
@@ -523,11 +523,16 @@ static void get_tags_and_duplicates(struct
object_array *pending,
11 matches
Mail list logo
