Re: What's cooking in git.git (Mar 2013, #07; Tue, 26)

2013-03-28 Thread Junio C Hamano
John Keeping  writes:

> On Wed, Mar 27, 2013 at 03:15:44PM -0700, Junio C Hamano wrote:
>> John Keeping  writes:
>> 
>> > On Wed, Mar 27, 2013 at 02:47:25PM -0700, Junio C Hamano wrote:
>> >> > * jk/difftool-dir-diff-edit-fix (2013-03-14) 3 commits
>> >> >   (merged to 'next' on 2013-03-19 at e68014a)
>> >> >  + difftool --dir-diff: symlink all files matching the working tree
>> >> >  + difftool: avoid double slashes in symlink targets
>> >> >  + git-difftool(1): fix formatting of --symlink description
>> >> 
>> >> I lost track of various discussions on "difftool" and its "symlink
>> >> so that the user can edit working tree files in the tool".
>> >
>> > Would it be easiest if I send a new series incorporating
>> > jk/difftool-dirr-diff-edit-fix and the proposed change to not overwrite
>> > modified working tree files, built on top of t7800-modernize?
>> 
>> I am somewhat reluctant to rewind a topic that has been cooking in
>> 'next' for over a week (the above says 19th).  Rebuilding the
>> style-fixes on top of the above is fine---that topic is much
>> younger.
>
> Sadly that's easier said than done, since it just introduces further
> conflicts as jk/difftool-dir-diff-edit-fix doesn't include
> da/difftool-fixes (now in master).

OK, let's make it simpler then by merging jk/difftool-dir-diff-edit-fix
to 'master'.  The test tweaks and other work can then built on top.
--
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: What's cooking in git.git (Mar 2013, #07; Tue, 26)

2013-03-28 Thread Thomas Rast
Junio C Hamano  writes:

>> * tr/line-log (2013-03-23) 6 commits
>>  - Speed up log -L... -M
>>  - log -L: :pattern:file syntax to find by funcname
>>  - Implement line-history search (git log -L)
>>  - Export rewrite_parents() for 'log -L'
>>  - fixup
>>  - Refactor parse_loc
>>
>>  Rerolled; collides with nd/magic-pathspecs.
>
> Honestly I am not sure what to make of this one.  I'd say we should
> merge this down as-is to 'master', expecting that in some future we
> would fix "log --follow" to keep the refspecs per history traversal
> path, so that this can be more naturally reimplemented.  Objections?

I was really hoping for something like that to happen :-) but I need to
look into at least one segfault bug in the option parser, noticed by
Antoine Pelisse.  Expect a (final?) reroll soon.

-- 
Thomas Rast
trast@{inf,student}.ethz.ch
--
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: What's cooking in git.git (Mar 2013, #07; Tue, 26)

2013-03-27 Thread John Keeping
On Wed, Mar 27, 2013 at 03:15:44PM -0700, Junio C Hamano wrote:
> John Keeping  writes:
> 
> > On Wed, Mar 27, 2013 at 02:47:25PM -0700, Junio C Hamano wrote:
> >> > * jk/difftool-dir-diff-edit-fix (2013-03-14) 3 commits
> >> >   (merged to 'next' on 2013-03-19 at e68014a)
> >> >  + difftool --dir-diff: symlink all files matching the working tree
> >> >  + difftool: avoid double slashes in symlink targets
> >> >  + git-difftool(1): fix formatting of --symlink description
> >> 
> >> I lost track of various discussions on "difftool" and its "symlink
> >> so that the user can edit working tree files in the tool".
> >
> > Would it be easiest if I send a new series incorporating
> > jk/difftool-dirr-diff-edit-fix and the proposed change to not overwrite
> > modified working tree files, built on top of t7800-modernize?
> 
> I am somewhat reluctant to rewind a topic that has been cooking in
> 'next' for over a week (the above says 19th).  Rebuilding the
> style-fixes on top of the above is fine---that topic is much
> younger.

Sadly that's easier said than done, since it just introduces further
conflicts as jk/difftool-dir-diff-edit-fix doesn't include
da/difftool-fixes (now in master).

So I think the best thing may be to:

1) take only the middle patch from jk/t7800-modernize for now (which
   fixes a test failure on Windows and shouldn't conflict with
   anything else) and discard the other two patches there, to be
   re-sent after other topics in flight graduate

2) add the "don't overwrite modified working tree files" patch built
   on top of jk/difftool-dir-diff-edit-fix (presumably as a new
   topic)
--
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


jn/add-2.0-u-A-sans-pathspec (Re: What's cooking in git.git (Mar 2013, #07; Tue, 26))

2013-03-27 Thread Jonathan Nieder
Junio C Hamano wrote:
> On Tue, Mar 26, 2013 at 03:40:00PM -0700, Junio C Hamano wrote:

>> * jn/add-2.0-u-A-sans-pathspec (2013-03-20) 5 commits
>>  - git add: -u/-A now affects the entire working tree
>>  - add -A: only show pathless 'add -A' warning when changes exist outside cwd
>>  - add -u: only show pathless 'add -u' warning when changes exist outside cwd
>>  - add: make warn_pathless_add() a no-op after first call
>>  - add: make pathless 'add [-u|-A]' warning a file-global function
>>
>>  Replaces jc/add-2.0-u-A-sans-pathspec topic by not warning against
>>  "add -u/-A" that is ran without pathspec when there is no change
>>  outside the current directory.
>
> I recall we had a lengthy discussion on this, but how committed are
> we on the progression of this series?  Are the bottom four ready to
> be merged to 1.8.3, or do they need more polishing?

I wanted to add tests and then other tasks took over.  Sorry.  Probably
best to get the bottom four in "next" and add tests on top later.

I have the following squashed in locally.

-- >8 --
Subject: fixup! add -u: only show pathless 'add -u' warning when changes exist 
outside cwd

Define ADD_CACHE_IMPLICIT_DOT in cache.h alongside the other add_to_index
flags.  This way, authors of patches adding new flags that might want to
use the same bit can know to be careful.

Requested-by: Jeff King 
Signed-off-by: Jonathan Nieder 
---
Thanks,
Jonathan

 builtin/add.c | 1 -
 cache.h   | 1 +
 2 files changed, 1 insertion(+), 1 deletion(-)

diff --git a/builtin/add.c b/builtin/add.c
index ad59182..9f35df7 100644
--- a/builtin/add.c
+++ b/builtin/add.c
@@ -139,7 +139,6 @@ static void update_callback(struct diff_queue_struct *q,
}
 }
 
-#define ADD_CACHE_IMPLICIT_DOT 32
 int add_files_to_cache(const char *prefix, const char **pathspec, int flags)
 {
struct update_callback_data data;
diff --git a/cache.h b/cache.h
index e493563..5de3480 100644
--- a/cache.h
+++ b/cache.h
@@ -459,6 +459,7 @@ extern int remove_file_from_index(struct index_state *, 
const char *path);
 #define ADD_CACHE_IGNORE_ERRORS4
 #define ADD_CACHE_IGNORE_REMOVAL 8
 #define ADD_CACHE_INTENT 16
+#define ADD_CACHE_IMPLICIT_DOT 32  /* internal to "git add -u/-A" */
 extern int add_to_index(struct index_state *, const char *path, struct stat *, 
int flags);
 extern int add_file_to_index(struct index_state *, const char *path, int 
flags);
 extern struct cache_entry *make_cache_entry(unsigned int mode, const unsigned 
char *sha1, const char *path, int stage, int refresh);
-- 
1.8.2.rc3

--
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: What's cooking in git.git (Mar 2013, #07; Tue, 26)

2013-03-27 Thread Junio C Hamano
John Keeping  writes:

> On Wed, Mar 27, 2013 at 02:47:25PM -0700, Junio C Hamano wrote:
>> > * jk/difftool-dir-diff-edit-fix (2013-03-14) 3 commits
>> >   (merged to 'next' on 2013-03-19 at e68014a)
>> >  + difftool --dir-diff: symlink all files matching the working tree
>> >  + difftool: avoid double slashes in symlink targets
>> >  + git-difftool(1): fix formatting of --symlink description
>> 
>> I lost track of various discussions on "difftool" and its "symlink
>> so that the user can edit working tree files in the tool".
>
> Would it be easiest if I send a new series incorporating
> jk/difftool-dirr-diff-edit-fix and the proposed change to not overwrite
> modified working tree files, built on top of t7800-modernize?

I am somewhat reluctant to rewind a topic that has been cooking in
'next' for over a week (the above says 19th).  Rebuilding the
style-fixes on top of the above is fine---that topic is much
younger.
--
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: What's cooking in git.git (Mar 2013, #07; Tue, 26)

2013-03-27 Thread John Keeping
On Wed, Mar 27, 2013 at 02:47:25PM -0700, Junio C Hamano wrote:
> > * jk/difftool-dir-diff-edit-fix (2013-03-14) 3 commits
> >   (merged to 'next' on 2013-03-19 at e68014a)
> >  + difftool --dir-diff: symlink all files matching the working tree
> >  + difftool: avoid double slashes in symlink targets
> >  + git-difftool(1): fix formatting of --symlink description
> 
> I lost track of various discussions on "difftool" and its "symlink
> so that the user can edit working tree files in the tool".

Would it be easiest if I send a new series incorporating
jk/difftool-dirr-diff-edit-fix and the proposed change to not overwrite
modified working tree files, built on top of t7800-modernize?

The "overwrite modified working tree files" issue isn't new, but
jk/difftool-dir-diff-edit-fix makes it more likely to happen so it might
be best to include those in one topic, and building on
jk/t7800-modernize will avoid conflicts in the tests.
--
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: What's cooking in git.git (Mar 2013, #07; Tue, 26)

2013-03-27 Thread Junio C Hamano
Thomas Rast  writes:

> Jeff King  writes:
>
>> On Tue, Mar 26, 2013 at 03:40:00PM -0700, Junio C Hamano wrote:
>>
>>> [Cooking]
>>> [...]
>>> * jk/index-pack-correct-depth-fix (2013-03-20) 1 commit
>>>  - index-pack: always zero-initialize object_entry list
>>> 
>>>  "index-pack --fix-thin" used uninitialize value to compute delta
>>>  depths of objects it appends to the resulting pack.
>>
>> Any reason this is still in pu? I'd have expected it to be fairly
>> uncontroversial and slated for maint.
>
> Me too, along with the other two we found in the same topic:
>
>> * nd/index-pack-threaded-fixes (2013-03-19) 2 commits
>>  - index-pack: guard nr_resolved_deltas reads by lock
>>  - index-pack: protect deepest_delta in multithread code
>>
>>  "index-pack --verify-stat" used a few counters outside protection
>>  of mutex, possibly showing incorrect numbers.

Yes.

Speaking of which... (cc'ed various people involved in the topics
listed below)

> [Stalled]

It may be time to discard all the stalled topics (without
prejudice), except for some.

> * jc/format-patch (2013-02-21) 2 commits
>  - format-patch: --inline-single
>  - format-patch: rename "no_inline" field
>
>  A new option to send a single patch to the standard output to be
>  appended at the bottom of a message.  I personally have no need for
>  this, but it was easy enough to cobble together.  Tests, docs and
>  stripping out more MIMEy stuff are left as exercises to interested
>  parties.
>
>  Not ready for inclusion.

Somebody may want to pick this up to give it finishing touches.

I am reasonably sure that some MIMEy stuff are still leaked to the
output.  From the UI point of view, this does not let you say

git format-patch --inline-single []

with omitted  defalting to HEAD (instead you have to say "-1").

> * po/help-guides (2013-03-03) 5 commits

I know Philip said a reroll is planned, so if it comes, it can be
requeued.

> * mb/gitweb-highlight-link-target (2012-12-20) 1 commit
>  - Highlight the link target line in Gitweb using CSS
>
>  Expecting a reroll.
>  $gmane/211935

Highlighting was cute but the anchor was not.

> [Cooking]
>
> * jc/merge-tag-object (2013-03-19) 1 commit
>  - merge: a random object may not necssarily be a commit

Probably we should eventually merge this as a bugfix to maintenance
track.

> * jk/index-pack-correct-depth-fix (2013-03-20) 1 commit
>  - index-pack: always zero-initialize object_entry list

This is in the same class as the ones you two were wondering about,
I think.

> * jk/difftool-dir-diff-edit-fix (2013-03-14) 3 commits
>   (merged to 'next' on 2013-03-19 at e68014a)
>  + difftool --dir-diff: symlink all files matching the working tree
>  + difftool: avoid double slashes in symlink targets
>  + git-difftool(1): fix formatting of --symlink description

I lost track of various discussions on "difftool" and its "symlink
so that the user can edit working tree files in the tool".

> * tr/line-log (2013-03-23) 6 commits
>  - Speed up log -L... -M
>  - log -L: :pattern:file syntax to find by funcname
>  - Implement line-history search (git log -L)
>  - Export rewrite_parents() for 'log -L'
>  - fixup
>  - Refactor parse_loc
>
>  Rerolled; collides with nd/magic-pathspecs.

Honestly I am not sure what to make of this one.  I'd say we should
merge this down as-is to 'master', expecting that in some future we
would fix "log --follow" to keep the refspecs per history traversal
path, so that this can be more naturally reimplemented.  Objections?


> * jc/push-2.0-default-to-simple (2013-03-18) 15 commits
>  - advice: Remove unused advice_push_non_ff_default
>  - t5570: do not assume the "matching" push is the default
>  - t5551: do not assume the "matching" push is the default
>  - t5550: do not assume the "matching" push is the default
>  - doc: push.default is no longer "matching"
>  - push: switch default from "matching" to "simple"
>  - t9401: do not assume the "matching" push is the default
>  - t9400: do not assume the "matching" push is the default
>  - t7406: do not assume the "matching" push is the default
>  - t5531: do not assume the "matching" push is the default
>  - t5519: do not assume the "matching" push is the default
>  - t5517: do not assume the "matching" push is the default
>  - t5516: do not assume the "matching" push is the default
>  - t5505: do not assume the "matching" push is the default
>  - t5404: do not assume the "matching" push is the default
>
>  Will cook in 'next' until Git 2.0.

At least we should reorder the three test patches near the tip to
come before the "switch the default", and perhaps squash the tip
one and "doc" patch to "switch the default" one, but other than
that, are we ready to commit to this?

> * jn/add-2.0-u-A-sans-pathspec (2013-03-20) 5 commits
>  - git add: -u/-A now affects the entire working tree
>  - add -A: only show pathless 'add -A' warning when changes exist outside cwd
>  - add -u: only show pathless 'add -u' warning when changes exist outside cw

Re: What's cooking in git.git (Mar 2013, #07; Tue, 26)

2013-03-27 Thread Jeff King
On Wed, Mar 27, 2013 at 01:50:29PM -0700, Junio C Hamano wrote:

> Jeff King  writes:
> 
> > I was kind of surprised to see this still in pu, too. I thought it was
> > supposed to cook in next for a while to shake out any interoperability
> > bugs (and it was in next previously). Did it get ejected after the
> > release and then never put back?
> 
> Yes, I've been trying to concentrate on flushing safer and older
> ones first to 'master', and I _think_ I am more or less finished
> with that as of last night.  Many will come back to 'next' in
> today's integration run.

Thanks, I figured it was something like that, but was puzzled.

-Peff
--
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: What's cooking in git.git (Mar 2013, #07; Tue, 26)

2013-03-27 Thread Thomas Rast
Jeff King  writes:

> On Tue, Mar 26, 2013 at 03:40:00PM -0700, Junio C Hamano wrote:
>
>> [Cooking]
>> [...]
>> * jk/index-pack-correct-depth-fix (2013-03-20) 1 commit
>>  - index-pack: always zero-initialize object_entry list
>> 
>>  "index-pack --fix-thin" used uninitialize value to compute delta
>>  depths of objects it appends to the resulting pack.
>
> Any reason this is still in pu? I'd have expected it to be fairly
> uncontroversial and slated for maint.

Me too, along with the other two we found in the same topic:

> * nd/index-pack-threaded-fixes (2013-03-19) 2 commits
>  - index-pack: guard nr_resolved_deltas reads by lock
>  - index-pack: protect deepest_delta in multithread code
>
>  "index-pack --verify-stat" used a few counters outside protection
>  of mutex, possibly showing incorrect numbers.

-- 
Thomas Rast
trast@{inf,student}.ethz.ch
--
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: What's cooking in git.git (Mar 2013, #07; Tue, 26)

2013-03-27 Thread Junio C Hamano
Jeff King  writes:

> I was kind of surprised to see this still in pu, too. I thought it was
> supposed to cook in next for a while to shake out any interoperability
> bugs (and it was in next previously). Did it get ejected after the
> release and then never put back?

Yes, I've been trying to concentrate on flushing safer and older
ones first to 'master', and I _think_ I am more or less finished
with that as of last night.  Many will come back to 'next' in
today's integration run.

>
> -Peff
>
> PS I notice John Keeping has become quite active these days, and has
>stolen my initials. It makes searching for my topics in "What's
>Cooking" much harder (I read it linearly, but I take special notice
>of the "jk" topics).
--
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: What's cooking in git.git (Mar 2013, #07; Tue, 26)

2013-03-27 Thread Jeff King
On Tue, Mar 26, 2013 at 03:40:00PM -0700, Junio C Hamano wrote:

> [Cooking]
> [...]
> * jk/index-pack-correct-depth-fix (2013-03-20) 1 commit
>  - index-pack: always zero-initialize object_entry list
> 
>  "index-pack --fix-thin" used uninitialize value to compute delta
>  depths of objects it appends to the resulting pack.

Any reason this is still in pu? I'd have expected it to be fairly
uncontroversial and slated for maint.

> * jk/pkt-line-cleanup (2013-03-21) 20 commits
>  - do not use GIT_TRACE_PACKET=3 in tests
>  - remote-curl: always parse incoming refs
>  - remote-curl: move ref-parsing code up in file
>  - remote-curl: pass buffer straight to get_remote_heads
>  - teach get_remote_heads to read from a memory buffer
>  - pkt-line: share buffer/descriptor reading implementation
>  - pkt-line: provide a LARGE_PACKET_MAX static buffer
>  - pkt-line: move LARGE_PACKET_MAX definition from sideband
>  - pkt-line: teach packet_read_line to chomp newlines
>  - pkt-line: provide a generic reading function with options
>  - pkt-line: drop safe_write function
>  - pkt-line: move a misplaced comment
>  - write_or_die: raise SIGPIPE when we get EPIPE
>  - upload-archive: use argv_array to store client arguments
>  - upload-archive: do not copy repo name
>  - send-pack: prefer prefixcmp over memcmp in receive_status
>  - fetch-pack: fix out-of-bounds buffer offset in get_ack
>  - upload-pack: remove packet debugging harness
>  - upload-pack: do not add duplicate objects to shallow list
>  - upload-pack: use get_sha1_hex to parse "shallow" lines
> 
>  Cleans up pkt-line API, implementation and its callers to make them
>  more robust.  Even though I think this change is correct, please
>  report immediately if you find any unintended side effect.
> 
>  Will merge to 'master' in the 3rd batch (Risky).

I was kind of surprised to see this still in pu, too. I thought it was
supposed to cook in next for a while to shake out any interoperability
bugs (and it was in next previously). Did it get ejected after the
release and then never put back?

-Peff

PS I notice John Keeping has become quite active these days, and has
   stolen my initials. It makes searching for my topics in "What's
   Cooking" much harder (I read it linearly, but I take special notice
   of the "jk" topics).
--
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