Re: Failure to extra sta...@vger.kernel.org addresses

[Felipe Contreras]

On Tue, Nov 20, 2012 at 8:56 AM, Krzysztof Mazur krzys...@podlesie.net wrote:

 --- a/git-send-email.perl
 +++ b/git-send-email.perl
 @@ -925,8 +925,11 @@ sub quote_subject {
  sub sanitize_address {
 my ($recipient) = @_;

 +   my $local_part_regexp = qr/[^\s@]+/;
 +   my $domain_regexp = qr/[^.\s@]+(?:\.[^.\s@]+)+/;
 +
 # remove garbage after email address
 -   $recipient =~ s/(.*).*$/$1/;
 +   $recipient =~ s/^(.*?$local_part_regexp\@$domain_regexp).*/$1/;

I don't think all that extra complexity is warranted, to me
s/(.*?)(.*)$/$1/ is just fine.

Cheers.

-- 
Felipe Contreras
--
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: Failure to extra sta...@vger.kernel.org addresses

[Andreas Ericsson]

On 11/20/2012 11:28 AM, Felipe Contreras wrote:
 On Tue, Nov 20, 2012 at 8:56 AM, Krzysztof Mazur krzys...@podlesie.net 
 wrote:
 
 --- a/git-send-email.perl
 +++ b/git-send-email.perl
 @@ -925,8 +925,11 @@ sub quote_subject {
   sub sanitize_address {
  my ($recipient) = @_;

 +   my $local_part_regexp = qr/[^\s@]+/;
 +   my $domain_regexp = qr/[^.\s@]+(?:\.[^.\s@]+)+/;
 +
  # remove garbage after email address
 -   $recipient =~ s/(.*).*$/$1/;
 +   $recipient =~ s/^(.*?$local_part_regexp\@$domain_regexp).*/$1/;
 
 I don't think all that extra complexity is warranted, to me
 s/(.*?)(.*)$/$1/ is just fine.
 

It's intentionally left without the at-sign so one can send mail to a
local account as well as remote ones. Very nifty when debugging, and
when one wants to preview outgoing emails.

-- 
Andreas Ericsson   andreas.erics...@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225  Fax: +46 8-230231

Considering the successes of the wars on alcohol, poverty, drugs and
terror, I think we should give some serious thought to declaring war
on peace.
--
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 (Nov 2012, #06; Mon, 19)

[Paul Fox]

junio c hamano wrote:
  [Stalled]
  
  * pf/editor-ignore-sigint (2012-11-11) 5 commits
   - launch_editor: propagate SIGINT from editor to git
   - run-command: do not warn about child death by SIGINT
   - run-command: drop silent_exec_failure arg from wait_or_whine
   - launch_editor: ignore SIGINT while the editor has control
   - launch_editor: refactor to use start/finish_command
  
   Avoid confusing cases where the user hits Ctrl-C while in the editor
   session, not realizing git will receive the signal. Since most editors
   will take over the terminal and will block SIGINT, this is not likely
   to confuse anyone.
  
   Some people raised issues with emacsclient, which are addressed by this
   re-roll. It should probably also handle SIGQUIT, and there were a
   handful of other review comments.
  
   Expecting a re-roll.

i don't have strong feelings on any of the later review comments
(though i guess the check on finish_command()'s return code needed
attention), and wasn't the last submitter, but would certainly like to
see this move forward.

paul
=-
 paul fox, p...@foxharp.boston.ma.us (arlington, ma, where it's 26.1 degrees)
--
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: Failure to extra sta...@vger.kernel.org addresses

[Krzysztof Mazur]

On Tue, Nov 20, 2012 at 11:28:39AM +0100, Felipe Contreras wrote:
 On Tue, Nov 20, 2012 at 8:56 AM, Krzysztof Mazur krzys...@podlesie.net 
 wrote:
 
  --- a/git-send-email.perl
  +++ b/git-send-email.perl
  @@ -925,8 +925,11 @@ sub quote_subject {
   sub sanitize_address {
  my ($recipient) = @_;
 
  +   my $local_part_regexp = qr/[^\s@]+/;
  +   my $domain_regexp = qr/[^.\s@]+(?:\.[^.\s@]+)+/;
  +
  # remove garbage after email address
  -   $recipient =~ s/(.*).*$/$1/;
  +   $recipient =~ s/^(.*?$local_part_regexp\@$domain_regexp).*/$1/;
 
 I don't think all that extra complexity is warranted, to me
 s/(.*?)(.*)$/$1/ is just fine.
 

Yeah, it's a little bit too complex, but s/(.*?)(.*)$/$1/
causes small regression - '' character is no longer allowed
in phrase before email address. Maybe the initial version,
that removes everything after last '' is better? In this case ''
is not allowed in garbage after email.

Krzysiek
--
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: RFC: Making submodules track branches

[W. Trevor King]

On Tue, Nov 20, 2012 at 03:16:35AM -0800, nottrobin wrote:
 Did any of this ever find its way into the submodule core? I'd like
 to have a submodule that tracks a branch.

In progress.  See:

  http://thread.gmane.org/gmane.comp.version-control.git/208254

Cheers,
Trevor

-- 
This email may be signed or encrypted with GnuPG (http://www.gnupg.org).
For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy


signature.asc
Description: OpenPGP digital signature

Re: [PATCH v3 1/3] git-submodule add: Add -r/--record option

[W. Trevor King]

On Mon, Nov 19, 2012 at 09:39:34PM -0800, Junio C Hamano wrote:
 W. Trevor King wk...@tremily.us writes:
 
  On Mon, Nov 19, 2012 at 04:49:09PM -0800, Junio C Hamano wrote:
  W. Trevor King wk...@tremily.us writes:
  ...
   I think it's best to have users craft their own commit messages
   explaining why the branch was updated.  That said, an auto-generated
   hint (a la git merge) would probably be a useful extra feature.
  
  I am not quite sure I agree.  When the project says Use the tip of
  'bar' branch for the submodule 'foo' at the top-level, does an
  individual user who is not working on the submodule 'foo' but merely
  is using it have any clue as to why the submodule's 'foo' branch
  'foo' moved, or does he necessarily even care?
 
  If he doesn't care, why is he updating the submodule gitlink?
 
 He may not be updating the gitlink with git add foo at the
 top-level superproject level.  He is just using that submodule as
 part of the larger whole as he is working on either the top-level or
 some other submodule.  And checkout of 'foo' is necessary in the
 working tree for him to work in the larger context of the project,
 and 'foo' is set to float at the tip of its 'bar' branch.  And that
 checkout results in a commit that is different from the commit the
 gitlink suggests, perhaps because somebody worked in 'foo' submodule
 and advanced the tip of branch 'bar'.

The superproject gitlink should only be updated after

  $ git submodule update --pull

A plain

  $ git submodule update

would still checkout the previously-recorded SHA, not the new upstream
tip.  The uncaring user should skip the --pull, and there will be no
superproject changes to worry about.

 Or are you envisioning that such a check-out will and should show a
 local difference at the submodule 'foo' by leaving the index of the
 top-level superproject unchanged,

A plain git submodule update will, yes.  And this will clobber any
changes that have happened in the submodule directory and its index
(because the user explicitly asked to checkout the
superproject-recorded SHA)

 and the user should refrain from using git commit -a to avoid
 having to describe the changes made on the 'bar' branch in the
 meantime in his top-level commit?

What would git commit -a be picking up?  Nothing in the superproject
has changed?

 That is certainly fine by me (I am no a heavy submodule user to
 begin with), but I am not sure if that is useful and helpful to the
 submodule users.

The benefit is that Ævar's

  $ git submodule foreach 'git checkout $(git config --file 
$toplevel/.gitmodules submodule.$name.branch)  git pull'

becomes

  $ git submodule update --pull

Still an explicit pull, but much easier to remember.

-- 
This email may be signed or encrypted with GnuPG (http://www.gnupg.org).
For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy


signature.asc
Description: OpenPGP digital signature

Re: [PATCH 3/4] pathspec: apply *.c optimization from exclude

[Nguyen Thai Ngoc Duy]

On Tue, Nov 20, 2012 at 4:20 AM, Junio C Hamano gits...@pobox.com wrote:
 $ time git rev-list --quiet HEAD -- '*.c'

 real0m40.770s
 user0m40.290s
 sys 0m0.256s

 With the patch

 $ time ~/w/git/git rev-list --quiet HEAD -- '*.c'

 real0m34.288s
 user0m33.997s
 sys 0m0.205s

 The above command is not supposed to be widely popular.

 Hrm, perhaps.  I use git grep pattern -- \*.c quite a lot, but
 haven't seen use case for \*.c in the context of the log family.

git diff *.c is also helpful (maybe git diff *.[ch] is more often
used). But I suspect I/O dominates in both grep and diff cases. I just
try to make sure matching code won't show up in profile.


 +#define PSF_ONESTAR 1

 Together with the GF_ prefix in the previous, PSF_ prefix needs a
 bit of in-code explanation.  Is it just an RC3L (random combination
 of 3 letters?)

I'm pretty sure PS stands for pathspec. F is probably from
fnmatch. Any suggestions?


 @@ -46,6 +46,12 @@ inline int git_fnmatch(const char *pattern, const char 
 *string,
   pattern += prefix;
   string += prefix;
   }
 + if (flags  GF_ONESTAR) {
 + int pattern_len = strlen(++pattern);
 + int string_len = strlen(string);
 + return strcmp(pattern,
 +   string + string_len - pattern_len);
 + }

 What happens when pattern=foo*oob and string=foob?

 The prefix match before this code determines that the literal prefix
 in the pattern matches with the early part of the string, and makes
 pattern=*oob and string=b.

 When you come to strcmp(), you see that string_len is 1, pattern_len
 is 3, and pattern is oob.  string+string_len-pattern_len = oob,
 one past the beginning of the original string foob.  They match.

 Oops?

Oops indead. I'll need to check exclude code too :(


 return (string_len  pattern_len) ||
 strcmp(pattern, string + string_len - pattern_len);

 perhaps?

Yeah.
-- 
Duy
--
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: [PATCH] tcsh-completion re-using git-completion.bash

[Marc Khouzam]

On Sat, Nov 17, 2012 at 1:01 PM, Felipe Contreras
felipe.contre...@gmail.com wrote:

 I gather that using a wrapper for zsh causes concerns about
 backwards-compatibility.

 I don't see any concerns.

 if [[ -n ${ZSH_VERSION-} ]]; then
   # replace below by zsh completion commands calling `bash
 ${HOME}/.git-completion.bash`

   complete git   'p/*/`bash ${HOME}/.git-completion.bash ${COMMAND_LINE}`/'
   complete gitk 'p/*/`bash ${HOME}/.git-completion.bash ${COMMAND_LINE}`/'

 That doesn't work in zsh. It might be possible to do something
 similar, but it would probably require many more lines.

Hi,

since there doesn't seem to be an agreement that the approach to achieve tcsh
git-completion would be useful for zsh (the other possible shell that could use
it is ksh, but I haven't looked into that), maybe the simplest thing
is to keep the
tcsh solution contained in a tcsh-only script.  This is the latest solution as
proposed here:

[1] http://www.mail-archive.com/git@vger.kernel.org/msg12192.html

For reference, the more general solution was proposed here:
[2] http://www.mail-archive.com/git@vger.kernel.org/msg12122.html

If there is interest in merging [1], please let me know and I'll post another
version which adds a check to make sure that the user properly copied
git-completion.bash to be used by the new git-completion.tcsh.

Thanks for your input.

Marc
--
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: git merge commits are non-deterministic? what changed?

[Ulrich Spörlein]

On Mon, 2012-11-12 at 12:27:31 +0100, Michael J Gruber wrote:
 Ulrich Spörlein venit, vidit, dixit 09.11.2012 19:27:
  On Fri, 2012-11-09 at 11:16:47 -0500, Jeff King wrote:
  On Fri, Nov 09, 2012 at 04:52:48PM +0100, Matthieu Moy wrote:
 
  Ulrich Spörlein u...@spoerlein.net writes:
 
  2. Why the hell is the commit hash dependent on the ordering of the
  parent commits? IMHO it should sort the set of parents before
  calculating the hash ...
 
  What would be the sort key?
 
  Trivially, the hash of the parents itself. So you'd always get
 
  ...
  parent 
  parent 
  parent 
  parent 
 
  That would change the behavior of --first-parent. Or you'd need to
  compute the sha1 of the sorted list, but keep the unsorted one in the
  commit. Possible, but weird ;-).
 
  Right. The reason that merge parents are stored in the order given on
  the command line is not random or because it was not considered. It
  encodes a valuable piece of information: did the user merge foo into
  bar, or did they merge bar into foo?
 
  So I think this discussion is going in the wrong direction; git should
  never sort the parents, because the order is meaningful. The original
  complaint was that a run of svn2git produced different results on two
  different git versions. The important question to me is: did svn2git
  feed the parents to git in the same order?
 
  If it did, and git produced different results, then that is a serious
  bug.
 
  If it did not, then the issue needs to be resolved in svn2git (which
  _may_ want to sort the parents that it feeds to git, but it would depend
  on whether the order it is currently presenting is meaningful).
  
  Yeah, thanks, looks like I have some more work to do. I don't quite get
  how it could come up with a different order, seeing that it is using svn
  as the base.
  
  Will run some more experiments, thanks for the info so far.
 
 There was a change in the order in which git cherry-pick A B C applies
 the commits. It's the only odering affecting change in 1.8.0 that I can
 think of right now.

Just to wrap this up, it was of course a feature of the converter,
that resulted in this unrepeatable behavior. The SVN API makes use of
apr_hashes, which were traversed in arbitrary order, hence SVN commits
spanning multiple git-branches would be handled in a non-deterministic
order, leading to randomly ordered parent objects for later git merge
commits.

It it still debatable, whether a merge commit should have a
list-of-parents or a set-of-parents. Changing it to a set-of-parents
(with a well-defined hash function), would have made this problem go
away.

But this will never be changed, it would break the fundamental git
storage model as it is in place now.

Cheers,
Uli
--
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: [PATCH 3/4] pathspec: apply *.c optimization from exclude

[Junio C Hamano]

Nguyen Thai Ngoc Duy pclo...@gmail.com writes:

 When you come to strcmp(), you see that string_len is 1, pattern_len
 is 3, and pattern is oob.  string+string_len-pattern_len = oob,
 one past the beginning of the original string foob.  They match.

 Oops?

 Oops indead. I'll need to check exclude code too :(

Ok, the one queued on 'pu' has been locally fixed when I sent the
message you are responding to.
--
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: [PATCH 14/13] test-wildmatch: avoid Windows path mangling

[Junio C Hamano]

Johannes Sixt j.s...@viscovery.net writes:

 From: Nguyễn Thái Ngọc Duy pclo...@gmail.com

 The MSYS bash mangles arguments that begin with a forward slash
 when they are passed to test-wildmatch. This causes tests to fail.
 Avoid mangling by prepending XXX, which is removed by
 test-wildmatch before further processing.

 [J6t: reworded commit message]

 Reported-by: Johannes Sixt j...@kdbg.org
 Signed-off-by: Nguyễn Thái Ngọc Duy pclo...@gmail.com
 Signed-off-by: Johannes Sixt j...@kdbg.org
 ---
  Works well, and I'm fine with this work-around.

  -- Hannes

Thanks, but you need to fix your format-patch somehow.

 @@ -187,8 +187,8 @@ match 0 0 '-' '[[-\]]'
  match 1 1 '-adobe-courier-bold-o-normal--12-120-75-75-m-70-iso8859-1' 
 '-*-*-*-*-*-*-12-*-*-*-m-*-*-*'
  match 0 0 '-adobe-courier-bold-o-normal--12-120-75-75-X-70-iso8859-1' 
 '-*-*-*-*-*-*-12-*-*-*-m-*-*-*'
  match 0 0 '-adobe-courier-bold-o-normal--12-120-75-75-/-70-iso8859-1' 
 '-*-*-*-*-*-*-12-*-*-*-m-*-*-*'
 -match 1 1 '/adobe/courier/bold/o/normal//12/120/75/75/m/70/iso8859/1' 
 '/*/*/*/*/*/*/12/*/*/*/m/*/*/*'
 -match 0 0 '/adobe/courier/bold/o/normal//12/120/75/75/X/70/iso8859/1' 
 '/*/*/*/*/*/*/12/*/*/*/m/*/*/*'
 +match 1 1 'XXX/adobe/courier/bold/o/normal//12/120/75/75/m/70/iso8859/1' 
 'XXX/*/*/*/*/*/*/12/*/*/*/m/*/*/*'
 +match 0 0 'XXX/adobe/courier/bold/o/normal//12/120/75/75/X/70/iso8859/1' 
 'XXX/*/*/*/*/*/*/12/*/*/*/m/*/*/*'
  match 1 0 'abcd/abcdefg/abcdefghijk/abcdefghijklmnop.txt' '**/*a*b*g*n*t'
  match 0 0 'abcd/abcdefg/abcdefghijk/abcdefghijklmnop.txtz' '**/*a*b*g*n*t'
  diff --git a/test-wildmatch.c b/test-wildmatch.c

This hunk claims that there are 8 lines in preimage and postimage,
but it is not the case.  It has only 7 lines each.

You also have the first line of the next patch diff --git somehow
indented.  How did this happen?


 index 74c0864..e384c8e 100644
 --- a/test-wildmatch.c
 +++ b/test-wildmatch.c
 @@ -3,6 +3,14 @@
   int main(int argc, char **argv)
  {
 + int i;
 + for (i = 2; i  argc; i++) {
 + if (argv[i][0] == '/')
 + die(Forward slash is not allowed at the beginning of 
 the\n
 + pattern because Windows does not like it. Use 
 `XXX/' instead.);
 + else if (!strncmp(argv[i], XXX/, 4))
 + argv[i] += 3;
 + }
   if (!strcmp(argv[1], wildmatch))
   return !!wildmatch(argv[3], argv[2], 0);
   else if (!strcmp(argv[1], iwildmatch))

And again this claims that the preimage has 6 lines while the
postimage has 14.  Somebody is overcounting, or perhaps you removed
the first pre-context by hand without adjusting the line number?

--
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: [PATCH] git-send-email: don't return undefined value in extract_valid_address()

[Junio C Hamano]

Krzysztof Mazur krzys...@podlesie.net writes:

 In the fallback check, when Email::Valid is not available, the
 extract_valid_address() does not check for success of matching regex,
 and $1, which can be undefined, is always returned. Now if match
 fails an empty string is returned.

That much we can read from the code, but a bigger question is why
would it be a good thing for the callers?  Wouldn't they want to
be able to distinguish a failure from an empty string?

 Signed-off-by: Krzysztof Mazur krzys...@podlesie.net
 ---
 This fixes following warnings:
 Use of uninitialized value in string eq at ./git-send-email.perl line 1017.
 Use of uninitialized value in quotemeta at ./git-send-email.perl line 1017.
 W: unable to extract a valid address from: x a.patch

 when invalid email address was added by --cc-cmd,
 ./git-send-email.perl --dry-run --to a...@podlesie.net --cc-cmd=echo x a.patch

In other words, would we want to *hide* (not fix) the warning?
Shouldn't we be barfing loudly and possibly erroring it out until
the user fixes her --cc-cmd?

  git-send-email.perl | 10 +-
  1 file changed, 5 insertions(+), 5 deletions(-)

 diff --git a/git-send-email.perl b/git-send-email.perl
 index 5a7c29d..045f25f 100755
 --- a/git-send-email.perl
 +++ b/git-send-email.perl
 @@ -831,12 +831,12 @@ sub extract_valid_address {
   $address =~ s/^\s*(.*)\s*$/$1/;
   if ($have_email_valid) {
   return scalar Email::Valid-address($address);
 - } else {
 - # less robust/correct than the monster regexp in Email::Valid,
 - # but still does a 99% job, and one less dependency
 - $address =~ /($local_part_regexp\@$domain_regexp)/;
 - return $1;
   }
 +
 + # less robust/correct than the monster regexp in Email::Valid,
 + # but still does a 99% job, and one less dependency
 + return $1 if $address =~ /($local_part_regexp\@$domain_regexp)/;
 + return ;
  }
  
  # Usually don't need to change anything below here.
--
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: git merge commits are non-deterministic? what changed?

[Junio C Hamano]

Ulrich Spörlein u...@spoerlein.net writes:

 But this will never be changed, it would break the fundamental git
 storage model as it is in place now.

It doesn't just break storage model, but more importantly, it
breaks the semantics.

Imagine that things started breaking after merging your topic branch
'foo' to the integration branch 'master', and how people would
perceive the situation.  Everybody would say your topic 'foo' broke
the build.  Nobody except you would say, even if the tip of your
topic 'foo' alone works perfectly, merging the 'master' to your
topic 'foo' broke that topic.  The topic should have been adjusted
to the updated baseline, that is the 'master' branch before this
merge since your topic 'foo' forked off of it, before or during the
merge.

To express what was merged into what, the order of parents in the
commit is fundamentally a part of what a commit is.
--
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: [PATCH] git-send-email: don't return undefined value in extract_valid_address()

[Krzysztof Mazur]

On Tue, Nov 20, 2012 at 12:27:36PM -0800, Junio C Hamano wrote:
 Krzysztof Mazur krzys...@podlesie.net writes:
 
  In the fallback check, when Email::Valid is not available, the
  extract_valid_address() does not check for success of matching regex,
  and $1, which can be undefined, is always returned. Now if match
  fails an empty string is returned.

Maybe the last line of comment should be changed to:

fails an empty string is returned to indicate failure.

 
 That much we can read from the code, but a bigger question is why
 would it be a good thing for the callers?  Wouldn't they want to
 be able to distinguish a failure from an empty string?

In this case returning empty string does not make sense, so it's
really used to indicate failure.

 
  Signed-off-by: Krzysztof Mazur krzys...@podlesie.net
  ---
  This fixes following warnings:
  Use of uninitialized value in string eq at ./git-send-email.perl line 1017.
  Use of uninitialized value in quotemeta at ./git-send-email.perl line 1017.
  W: unable to extract a valid address from: x a.patch
 
  when invalid email address was added by --cc-cmd,
  ./git-send-email.perl --dry-run --to a...@podlesie.net --cc-cmd=echo x 
  a.patch
 
 In other words, would we want to *hide* (not fix) the warning?
 Shouldn't we be barfing loudly and possibly erroring it out until
 the user fixes her --cc-cmd?
 

Yes, it's just to hide the warning, the error (warning in this case) it's
already correctly generated:

W: unable to extract a valid address from: x a.patch

Maybe we should change it to an error?

Krzysiek
--
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: [PATCH] tcsh-completion re-using git-completion.bash

[Junio C Hamano]

Marc Khouzam marc.khou...@gmail.com writes:

 This one is already merged to 'next'.

 Awesome!  I didn't notice.

 If I want to suggest an improvement (like checking if the bash
 script is available), do I just post a patch here?

Yes, as a follow-up patch (or two).

Thanks.
--
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: Failure to extra sta...@vger.kernel.org addresses

[Krzysztof Mazur]

On Tue, Nov 20, 2012 at 08:58:20PM +0100, Andreas Schwab wrote:
 How about s/(.*?[^]*).*$/$1/?  That will still fail on foo@bar
 foo@bar, but you'll need a full rfc822 parser to handle the general
 case anyway.

That will fail also on something foo@bar.


I think it's good compromise between complexity and correctness.

Felipe, may you check, it again? This time the change is trivial.

Andreas, may I add you in Thanks-to?

Thanks,

Krzysiek

-- 8 --
Subject: [PATCH] git-send-email: remove garbage after email address

In some cases it's very useful to add some additional information
after email in Cc-list, for instance:

Cc: Stable kernel sta...@vger.kernel.org #v3.4 v3.5 v3.6

Currently the git refuses to add such invalid email to Cc-list,
when the Email::Valid perl module is available or just uses whole line
as the email address.

Now in sanitize_address() everything after the email address is
removed, so the resulting line is correct email address and Email::Valid
validates it correctly.

To avoid unnecessary complexity this code assumes that in phrase before
email address 'something' never exists.

Signed-off-by: Krzysztof Mazur krzys...@podlesie.net
---
 git-send-email.perl | 4 
 1 file changed, 4 insertions(+)

diff --git a/git-send-email.perl b/git-send-email.perl
index 5a7c29d..157eabc 100755
--- a/git-send-email.perl
+++ b/git-send-email.perl
@@ -924,6 +924,10 @@ sub quote_subject {
 # use the simplest quoting being able to handle the recipient
 sub sanitize_address {
my ($recipient) = @_;
+
+   # remove garbage after email address
+   $recipient =~ s/(.*?[^]*).*$/$1/;
+
my ($recipient_name, $recipient_addr) = ($recipient =~ 
/^(.*?)\s*(.*)/);
 
if (not $recipient_name) {
-- 
1.8.0.283.gc57d856

--
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: [PATCH] git-send-email: don't return undefined value in extract_valid_address()

[Junio C Hamano]

Krzysztof Mazur krzys...@podlesie.net writes:

 Yes, it's just to hide the warning, the error (warning in this case) it's
 already correctly generated:

 W: unable to extract a valid address from: x a.patch

But it is of no use if the message is sent out without the intended
recipient, no?  It is too late when you notice it.

 Maybe we should change it to an error?

At least, when we are not giving the final sanity check [Y/n]?
prompt, I think the code should error out.
--
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* [PATCH] gitweb: make remote_heads config setting work.

[Junio C Hamano]

Jeff King p...@peff.net writes:

 On Thu, Nov 08, 2012 at 08:40:11PM -0800, Junio C Hamano wrote:

 Looking at the code before this part:
 
  if (my ($hi, $mi, $lo) = ($key =~ /^([^.]*)\.(.*)\.([^.]*)$/)) {
  $key = join(., lc($hi), $mi, lc($lo));
  } else {
  $key = lc($key);
  }
  $key =~ s/^gitweb\.//;
  return if ($key =~ m/\W/);
 
 the new code is munding the $hi and $mi parts, while the mistaken
 configuration this patch is trying to correct is about the $lo part,
 and possibly the $hi part, but never the $mi part.

 Good catch. I think the return in the existing code suffers from the
 same problem: it will bail on non-word characters in the $mi part, but
 that part should allow arbitrary characters.

I am tired of keeping the expecting reroll entries and having to
worry about them, so let's do this

-- 8 --
Subject: [squash] gitweb: make remote_heads config setting work

Only the top-level and bottom-level names are case insensitive and
spelled without _.  Protect future support of subsection names
from name mangling.

Signed-off-by: Junio C Hamano gits...@pobox.com
---
 gitweb/gitweb.perl | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git c/gitweb/gitweb.perl w/gitweb/gitweb.perl
index f2144c8..c421fa4 100755
--- c/gitweb/gitweb.perl
+++ w/gitweb/gitweb.perl
@@ -2697,13 +2697,15 @@ sub git_get_project_config {
# only subsection, if exists, is case sensitive,
# and not lowercased by 'git config -z -l'
if (my ($hi, $mi, $lo) = ($key =~ /^([^.]*)\.(.*)\.([^.]*)$/)) {
+   $lo =~ s/_//g;
$key = join(., lc($hi), $mi, lc($lo));
+   return if ($lo =~ /\W/ || $hi =~ /\W/);
} else {
$key = lc($key);
+   $key =~ s/_//g;
+   return if ($key =~ /\W/);
}
$key =~ s/^gitweb\.//;
-   $key =~ s/_//g;
-   return if ($key =~ m/\W/);
 
# type sanity check
if (defined $type) {
--
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

git-fetch does not work from .git subdirectory

[Timur Tabi]

I was under the impression that git commands which affect repository (as
opposed to the local file system) work from any subdirectory inside the
repository.  For example:

[b04825@efes linux.cq-test]$ git log -1
commit f35d179fde24be5e1675b1df9f7a49b8d95561b2
Author: Timur Tabi ti...@freescale.com
Date:   Wed Oct 31 15:56:20 2012 +0200
...
[b04825@efes linux.cq-test]$ cd .git
[b04825@efes .git]$ git log -1
commit f35d179fde24be5e1675b1df9f7a49b8d95561b2
Author: Timur Tabi ti...@freescale.com
Date:   Wed Oct 31 15:56:20 2012 +0200
...

It appears, however, that git-fetch does not work this way:

[b04825@efes linux.cq-test]$ git fetch upstream master
From ../linux-2.6
 * branchmaster - FETCH_HEAD
[b04825@efes linux.cq-test]$ cd .git
[b04825@efes .git]$ git fetch upstream master
fatal: '../linux-2.6.git' does not appear to be a git repository
fatal: The remote end hung up unexpectedly

This makes it complicated because git hooks run from the .git directory on
normal repositories, but they run from the top-level directory on bare
repositories.  Apparently, you need to be in the top-level directory for
git-fetch to run in any kind of repository.

-- 
Timur Tabi
Linux kernel developer at Freescale

--
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: [PATCH v5 15/15] fast-export: don't handle uninteresting refs

[Junio C Hamano]

Felipe Contreras felipe.contre...@gmail.com writes:

 Of course, transport-helper shouldn't even be specifying the negative
 (^) refs, but that's another story.

Hrm, I am not sure I understand what you mean by this.

How should it be telling the fast-export up to what commit the
receiving end should already have the history for (hence they do not
need to be sent)?  Or are you advocating to re-send the entire
history down to the root commit every time?


--
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: [wishlist] support git flow-like view

[Andrew Ardill]

On 21 November 2012 10:42, Lisandro Damián Nicanor Pérez Meyer
perezme...@gmail.com wrote:

 Hi! I am not suscribed to the list, so please CC-me.

That is the default etiquette on this list :)

 I think this may have been proposed before, but I could not find anything in
 the web, so I better try myself :)

 The idea would be to gitk to show a git flow-like[0] view when it detects
 git flow (or the user ask for it or...)

What does it mean to 'show a git flow-like view'? Show multiple
branches? Place commits on each branch in 'swim-lanes', rather than
moving them around on the horizontal to fit the space available? Some
more detail, or even a mock-up would help a lot here.

 Basiccaly, you can show the main two branches: master and develop. Of course,
 having the possibility to show feature/release/hotfixes branches would be
 ideal.

It is already possible to show multiple branches in gitk at the same
time. You probably have some more specific needs beyond simply showing
the different branches. Maybe you can be more specific?

Regards,

Andrew Ardill
--
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

Topics currently in the Stalled category

[Junio C Hamano]

Here is a list of stalled topics I am having trouble deciding what
to do (the default is to dismiss them around feature freeze).

* fc/fast-export-fixes (2012-11-08) 14 commits

 Renaming of remote-testgit feels to be a mistake.  It probably
 should keep its source in remote-testgit.bash and generate it, and
 moreover, if it wants to rename remote-testgit.py to remote-testpy,
 the new one should be called remote-testbash.  There was one reroll
 after what used to be queued, but nobody seemed to be interested in
 reviewing the series.

 This mostly happened while I was away, and judging from the
 discussion around this topic (and earlier iterations), I do not
 feel comfortable merging this series (or v5 reroll) as-is.

 Help?


* pf/editor-ignore-sigint (2012-11-11) 5 commits

 Avoid confusing cases where the user hits Ctrl-C while in the editor
 session, not realizing git will receive the signal. Since most editors
 will take over the terminal and will block SIGINT, this is not likely
 to confuse anyone.

 Some people raised issues with emacsclient, which are addressed by this
 re-roll. It should probably also handle SIGQUIT, and there were a
 handful of other review comments.

 Anybody interested in moving this forward?
 

* mo/cvs-server-updates (2012-10-16) 10 commits
 - cvsserver Documentation: new cvs ... -r support
 - cvsserver: add t9402 to test branch and tag refs
 - cvsserver: support -r and sticky tags for most operations
 - cvsserver: Add version awareness to argsfromdir
 - cvsserver: generalize getmeta() to recognize commit refs
 - cvsserver: implement req_Sticky and related utilities
 - cvsserver: add misc commit lookup, file meta data, and file listing functions
 - cvsserver: define a tag name character escape mechanism
 - cvsserver: cleanup extra slashes in filename arguments
 - cvsserver: factor out git-log parsing logic

 Needs review by folks interested in cvsserver.


* jn/warn-on-inaccessible-loosen (2012-10-14) 4 commits
 - config: exit on error accessing any config file
 - doc: advertise GIT_CONFIG_NOSYSTEM
 - config: treat user and xdg config permission problems as errors
 - config, gitignore: failure to access with ENOTDIR is ok

 An RFC to deal with a situation where .config/git is a file and we
 notice .config/git/config is not readable due to ENOTDIR, not
 ENOENT; I think a bit more refactored approach to consistently
 address permission errors across config, exclude and attrs may be
 desirable.

 Should we merge this as-is and build on top?  What are the chances
 of potential regressions?


* as/check-ignore (2012-11-08) 14 commits
 - t0007: fix tests on Windows
 - Documentation/check-ignore: we show the deciding match, not the first
 - Add git-check-ignore sub-command
 - dir.c: provide free_directory() for reclaiming dir_struct memory
 - pathspec.c: move reusable code from builtin/add.c
 - dir.c: refactor treat_gitlinks()
 - dir.c: keep track of where patterns came from
 - dir.c: refactor is_path_excluded()
 - dir.c: refactor is_excluded()
 - dir.c: refactor is_excluded_from_list()
 - dir.c: rename excluded() to is_excluded()
 - dir.c: rename excluded_from_list() to is_excluded_from_list()
 - dir.c: rename path_excluded() to is_path_excluded()
 - dir.c: rename cryptic 'which' variable to more consistent name

 Duy helped to reroll this, but it seems that there weren't any
 activity since then during my absense.


* fc/remote-testgit-feature-done (2012-10-29) 1 commit
 - remote-testgit: properly check for errors

 Is this still in Needs review state?  Are people involved in the
 remote interface happy with this change?


* jk/send-email-sender-prompt (2012-11-15) 8 commits
 - send-email: do not prompt for explicit repo ident
 - Git.pm: teach ident to query explicitness
 - var: provide explicit/implicit ident information
 - var: accept multiple variables on the command line
 - ident: keep separate explicit flags for author and committer
 - ident: make user_ident_explicitly_given static
 - t7502: factor out autoident prerequisite
 - test-lib: allow negation of prerequisites

 Avoid annoying sender prompt in git-send-email, but only when it is
 safe to do so.

 Perhaps keep only the first three patches, and replace the rest
 with the one from Felipe that takes a much simpler approach (the
 rationale of that patch needs to be cleaned up first, along the
 lines Jeff outlined, though).  Frozen until that happens.


* nd/unify-appending-of-s-o-b (2012-11-15) 1 commit
 - Unify appending signoff in format-patch, commit and sequencer

 I am not sure if the logic to refrain from adding a sign-off based
 on the existing run of sign-offs is done correctly in this change.


* rc/maint-complete-git-p4 (2012-09-24) 1 commit
  (merged to 'next' on 2012-10-29 at af52cef)
 + Teach git-completion about git p4

 Comment from Pete will need to be addressed in a follow-up patch.


* as/test-tweaks (2012-09-20) 7 commits
 - tests: paint unexpectedly fixed known breakages in bold red
 - tests: test the 

[BUG] git clean does not remove certain directories

[Soren Brinkmann]

Hi,

this use case may be a little awkward but this is the behavior I see:

I have a repository which has a couple of untracked directories which can also
include git repositories. No submodules, though.
I used 'git clean -xdf' on the top level of this repo to remove everything
untracked in it - including the git repositories in sub-directories.

Since using git 1.8.0 the clean operation seems to be 'broken', as output
indicates all those questionable sub directories are removed - just as in prior
git versions - but in fact they remain untouched and are _not_ removed.

I attached a shell script creating a hierarchy to reproduce the issue.
Executing the script creates the git repo 'repo.git' with a couple of tracked
and untracked dirs/files and two more git repositories within the first one.

If you cd into repo.git and execute 'git clean -xdf' I see the following output:
Removing repo2.git/
Removing untracked_dir/

But the directories remain intact when using git 1.8.0.
With git 1.6.3.2 it works as I expected and removes the directories. I'm pretty
sure the 1.7.x versions did the same, but it's no longer installed here.

I can see that this behavior may partially be intended, but the tool output
should match its actions. So, either the directories should be removed, or the
output should state, that they are not removed for what reason whatsoever, IMHO

Thanks,
Soren

#!/bin/sh
mkdir repo.git
cd repo.git
git init
echo foo  tracked_file1
git add tracked_file1
mkdir tracked_dir
echo foo  tracked_dir/tracked_file2
git add tracked_dir/tracked_file2
git commit -m Adding tracked files
mkdir repo2.git
echo foo  repo2.git/tracked_file3
mkdir -p untracked_dir/repo3.git
echo foo  untracked_dir/repo3.git/tracked_file4
cd repo2.git
git init
git add tracked_file3
git commit -m Adding file to subrepo1
cd ../untracked_dir/repo3.git
git init
git add tracked_file4
git commit -m Adding file to subrepo2
cd ../..

Re: [wishlist] support git flow-like view

[Lisandro Damián Nicanor Pérez Meyer]

On Tue 20 Nov 2012 20:56:26 Andrew Ardill escribió:
 On 21 November 2012 10:42, Lisandro Damián Nicanor Pérez Meyer
 
 perezme...@gmail.com wrote:
  Hi! I am not suscribed to the list, so please CC-me.
 
 That is the default etiquette on this list :)

Great :-)
 
  I think this may have been proposed before, but I could not find anything
  in the web, so I better try myself :)
  
  The idea would be to gitk to show a git flow-like[0] view when it
  detects git flow (or the user ask for it or...)
 
 What does it mean to 'show a git flow-like view'? Show multiple
 branches? Place commits on each branch in 'swim-lanes', rather than
 moving them around on the horizontal to fit the space available? Some
 more detail, or even a mock-up would help a lot here.

I think the best mock-up would be:

http://nvie.com/img/2009/12/Screen-shot-2009-12-24-at-11.32.03.png

Yes, I'm referring to swim-lanes like view. Which may be already there and 
I'm miserably failing to see :-/

  Basiccaly, you can show the main two branches: master and develop. Of
  course, having the possibility to show feature/release/hotfixes branches
  would be ideal.
 
 It is already possible to show multiple branches in gitk at the same
 time. You probably have some more specific needs beyond simply showing
 the different branches. Maybe you can be more specific?

Well, two ideas come to my mind:

- detect when using git flow (.git/config contains [gitflow some_branch] 
entries).
- Show swim-lane-like graphs, including branches that may not be present, 
but where there (release branches often are created and merged back, for 
example)

Maybe some of this is already there and/or it's too much trouble to do so, in 
those cases, please accept my apologies :-)

Kinds regards, Lisandro.

-- 
Lisandro Damián Nicanor Pérez Meyer
http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/


signature.asc
Description: This is a digitally signed message part.

Re: [wishlist] support git flow-like view

[Andrew Ardill]

On 21 November 2012 11:13, Lisandro Damián Nicanor Pérez Meyer
perezme...@gmail.com wrote:
 ...
 Well, two ideas come to my mind:

 - detect when using git flow (.git/config contains [gitflow some_branch]
 entries).

I guess this part is just so the next part can be done automatically?

 - Show swim-lane-like graphs, including branches that may not be present,
 but where there (release branches often are created and merged back, for
 example)

I think this could be useful in general, however it might struggle
with already merged branches. I may be mistaken here, however I think
in general there is no way to specify which commits belonged to a
certain branch after they have been merged, as branch information is
not kept in the commit object. There may be some exceptions that make
it feasible at times, but a general solution would be to show any
merged branches as part of the same swim-lane, as per current
behaviour, but to have separate branch heads in different swim-lanes.
This would be a nice feature, and is similar to the behaviour in, for
example, Atlassian's Fisheye repository viewer and the GitHub network
view.

Regards,

Andrew Ardill
--
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: Topics currently in the Stalled category

[Paul Fox]

In-reply-to: 7vobirq0q2.fsf...@alter.siamese.dyndns.org 
(sfid-20121120_190548_379327_D3EE7D14)
References: 7vpq39up0m@alter.siamese.dyndns.org 
7vy5hvq1ey@alter.siamese.dyndns.org 
7vobirq0q2.fsf...@alter.siamese.dyndns.org 
(sfid-20121120_190548_379327_D3EE7D14)
Fcc: outbox


junio c hamano wrote:
  Here is a list of stalled topics I am having trouble deciding what
  to do (the default is to dismiss them around feature freeze).
...
  * pf/editor-ignore-sigint (2012-11-11) 5 commits
  
   Avoid confusing cases where the user hits Ctrl-C while in the editor
   session, not realizing git will receive the signal. Since most editors
   will take over the terminal and will block SIGINT, this is not likely
   to confuse anyone.
  
   Some people raised issues with emacsclient, which are addressed by this
   re-roll. It should probably also handle SIGQUIT, and there were a
   handful of other review comments.
  
   Anybody interested in moving this forward?

i started this, but then jeff took it and ran with it and made it
right.  i think the remaining changes are small -- if jeff would
prefer, i can probably finish it.  (but i won't guarantee not to
mess up the From: lines.  :-)

paul
=-
 paul fox, p...@foxharp.boston.ma.us (arlington, ma, where it's 36.0 degrees)
--
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: [PATCH v5 15/15] fast-export: don't handle uninteresting refs

[Jonathan Nieder]

Junio C Hamano wrote:
 Felipe Contreras felipe.contre...@gmail.com writes:

 Of course, transport-helper shouldn't even be specifying the negative
 (^) refs, but that's another story.

 Hrm, I am not sure I understand what you mean by this.

 How should it be telling the fast-export up to what commit the
 receiving end should already have the history for (hence they do not
 need to be sent)?  Or are you advocating to re-send the entire
 history down to the root commit every time?

I think Felipe has mentioned before that he considers it the remote
helper's responsibility to keep track of what commits have already
been imported, for example using a marks file.

Never mind that others have said that that's not the current interface
(I don't yet see why it would be a good interface after a transition,
but maybe it would be).  Still, hopefully that clarifies the intended
meaning.

Hope that helps,
Jonathan
--
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: [PATCH v5 15/15] fast-export: don't handle uninteresting refs

[Felipe Contreras]

On Wed, Nov 21, 2012 at 5:17 AM, Jonathan Nieder jrnie...@gmail.com wrote:
 Junio C Hamano wrote:
 Felipe Contreras felipe.contre...@gmail.com writes:

 Of course, transport-helper shouldn't even be specifying the negative
 (^) refs, but that's another story.

 Hrm, I am not sure I understand what you mean by this.

 How should it be telling the fast-export up to what commit the
 receiving end should already have the history for (hence they do not
 need to be sent)?  Or are you advocating to re-send the entire
 history down to the root commit every time?

 I think Felipe has mentioned before that he considers it the remote
 helper's responsibility to keep track of what commits have already
 been imported, for example using a marks file.

It's not the remote helper, fast-export does that.

 Never mind that others have said that that's not the current interface
 (I don't yet see why it would be a good interface after a transition,
 but maybe it would be).  Still, hopefully that clarifies the intended
 meaning.

The current interface is broken.

not ok 16 - pulling without marks # TODO known breakage
not ok 17 - pushing without marks # TODO known breakage

See? A remote helper without marks doesn't work.

-- 
Felipe Contreras
--
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: [BUG] git clean does not remove certain directories

[Soren Brinkmann]

 Hi,

 this use case may be a little awkward but this is the behavior I see:

 I have a repository which has a couple of untracked directories which can also
 include git repositories. No submodules, though.
 I used 'git clean -xdf' on the top level of this repo to remove everything
 untracked in it - including the git repositories in sub-directories.

 Since using git 1.8.0 the clean operation seems to be 'broken', as output
 indicates all those questionable sub directories are removed - just as in 
 prior
 git versions - but in fact they remain untouched and are _not_ removed.

 I attached a shell script creating a hierarchy to reproduce the issue.
 Executing the script creates the git repo 'repo.git' with a couple of tracked
 and untracked dirs/files and two more git repositories within the first one.

 If you cd into repo.git and execute 'git clean -xdf' I see the following 
 output:
   Removing repo2.git/
   Removing untracked_dir/

 But the directories remain intact when using git 1.8.0.
 With git 1.6.3.2 it works as I expected and removes the
 directories. I'm pretty
 sure the 1.7.x versions did the same, but it's no longer
 installed here.

As additional data point: With git 1.7.9.5 the 'untracked_dir' is deleted, while
'repo2.git' is kept. Output is the same as always, indicating both were deleted.

So, three different git versions gain three different results...

Soren


This email and any attachments are intended for the sole use of the named 
recipient(s) and contain(s) confidential information that may be proprietary, 
privileged or copyrighted under applicable law. If you are not the intended 
recipient, do not read, copy, or forward this email message or any attachments. 
Delete this email message and any attachments immediately.


--
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: [PATCH v5 15/15] fast-export: don't handle uninteresting refs

[Junio C Hamano]

Jonathan Nieder jrnie...@gmail.com writes:

 Never mind that others have said that that's not the current interface
 (I don't yet see why it would be a good interface after a transition,
 but maybe it would be).  Still, hopefully that clarifies the intended
 meaning.

Care to explain how the current interface is supposed to work, how
fast-export and transport-helper should interact with remote helpers
that adhere to the current interface, and how well/correctly the
current implementation of these pieces work?

What I am trying to get at is to see where the problem lies.  Felipe
sees bugs in the aggregated whole.  Is the root cause of the problems
he sees some breakages in the current interface?  Is the interface
designed right but the problem is that the implementation of the
transport-helper is buggy and driving fast-export incorrectly?  Or is
the implementation of the fast-export buggy and emitting wrong results,
even though the transport-helper is driving fast-export correctly?
Something else?

I see Felipe keeps repeating that there are bugs, and keeps posting
patches to change fast-export, but I haven't seen a concrete No,
the reason why you see these problems is because you are not using
the interface correctly; the currrent interface is fine.  Here is
how you can fix your program from others.

With such a one-sided discussion, I've been having a hard time
convincing myself if Felipe's effort is making the interface better,
or just breaking it even more for existing remote helpers, only to
fit his world model better.

Help?
--
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

To find other pictures of celebrities

[burlet87]

To find other pictures of celebrities, you can also check out weekly tabloid
magazines. You may not be able to afford the exact same
[url=http://www.linksoflondonsweetiebracelets.co.uk/]links of london
bracelets[/url] these people are wearing, but you easily keep up with the
latest styles this way. The latest fashion is always changing so you need to
keep informed on the latest trends if you want to stay current.



--
View this message in context: 
http://git.661346.n2.nabble.com/To-find-other-pictures-of-celebrities-tp7571656.html
Sent from the git mailing list archive at Nabble.com.
--
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

[PATCH 14/13] test-wildmatch: avoid Windows path mangling

[Johannes Sixt]

From: Nguyễn Thái Ngọc Duy pclo...@gmail.com

The MSYS bash mangles arguments that begin with a forward slash
when they are passed to test-wildmatch. This causes tests to fail.
Avoid mangling by prepending XXX, which is removed by
test-wildmatch before further processing.

[J6t: reworded commit message]

Reported-by: Johannes Sixt j...@kdbg.org
Signed-off-by: Nguyễn Thái Ngọc Duy pclo...@gmail.com
Signed-off-by: Johannes Sixt j...@kdbg.org
---
Am 11/20/2012 21:11, schrieb Junio C Hamano:
 Thanks, but you need to fix your format-patch somehow.

No, it was Thunderbird. It ate the blank lines when I said Edit as new
to forward the patch directly from the mailbox.

Sorry for the inconvenience.

 t/t3070-wildmatch.sh | 10 +-
 test-wildmatch.c |  8 
 2 files changed, 13 insertions(+), 5 deletions(-)

diff --git a/t/t3070-wildmatch.sh b/t/t3070-wildmatch.sh
index e6ad6f4..3155eab 100755
--- a/t/t3070-wildmatch.sh
+++ b/t/t3070-wildmatch.sh
@@ -74,7 +74,7 @@ match 0 0 'foo/bar' 'foo[/]bar'
 match 0 0 'foo/bar' 'f[^eiu][^eiu][^eiu][^eiu][^eiu]r'
 match 1 1 'foo-bar' 'f[^eiu][^eiu][^eiu][^eiu][^eiu]r'
 match 1 0 'foo' '**/foo'
-match 1 x '/foo' '**/foo'
+match 1 x 'XXX/foo' '**/foo'
 match 1 0 'bar/baz/foo' '**/foo'
 match 0 0 'bar/baz/foo' '*/foo'
 match 0 0 'foo/bar/baz' '**/bar*'
@@ -95,8 +95,8 @@ match 0 0 ']' '[!]-]'
 match 1 x 'a' '[!]-]'
 match 0 0 '' '\'
 match 0 x '\' '\'
-match 0 x '/\' '*/\'
-match 1 x '/\' '*/\\'
+match 0 x 'XXX/\' '*/\'
+match 1 x 'XXX/\' '*/\\'
 match 1 1 'foo' 'foo'
 match 1 1 '@foo' '@foo'
 match 0 0 'foo' '@foo'
@@ -187,8 +187,8 @@ match 0 0 '-' '[[-\]]'
 match 1 1 '-adobe-courier-bold-o-normal--12-120-75-75-m-70-iso8859-1' 
'-*-*-*-*-*-*-12-*-*-*-m-*-*-*'
 match 0 0 '-adobe-courier-bold-o-normal--12-120-75-75-X-70-iso8859-1' 
'-*-*-*-*-*-*-12-*-*-*-m-*-*-*'
 match 0 0 '-adobe-courier-bold-o-normal--12-120-75-75-/-70-iso8859-1' 
'-*-*-*-*-*-*-12-*-*-*-m-*-*-*'
-match 1 1 '/adobe/courier/bold/o/normal//12/120/75/75/m/70/iso8859/1' 
'/*/*/*/*/*/*/12/*/*/*/m/*/*/*'
-match 0 0 '/adobe/courier/bold/o/normal//12/120/75/75/X/70/iso8859/1' 
'/*/*/*/*/*/*/12/*/*/*/m/*/*/*'
+match 1 1 'XXX/adobe/courier/bold/o/normal//12/120/75/75/m/70/iso8859/1' 
'XXX/*/*/*/*/*/*/12/*/*/*/m/*/*/*'
+match 0 0 'XXX/adobe/courier/bold/o/normal//12/120/75/75/X/70/iso8859/1' 
'XXX/*/*/*/*/*/*/12/*/*/*/m/*/*/*'
 match 1 0 'abcd/abcdefg/abcdefghijk/abcdefghijklmnop.txt' '**/*a*b*g*n*t'
 match 0 0 'abcd/abcdefg/abcdefghijk/abcdefghijklmnop.txtz' '**/*a*b*g*n*t'
 
diff --git a/test-wildmatch.c b/test-wildmatch.c
index 74c0864..e384c8e 100644
--- a/test-wildmatch.c
+++ b/test-wildmatch.c
@@ -3,6 +3,14 @@
 
 int main(int argc, char **argv)
 {
+   int i;
+   for (i = 2; i  argc; i++) {
+   if (argv[i][0] == '/')
+   die(Forward slash is not allowed at the beginning of 
the\n
+   pattern because Windows does not like it. Use 
`XXX/' instead.);
+   else if (!strncmp(argv[i], XXX/, 4))
+   argv[i] += 3;
+   }
if (!strcmp(argv[1], wildmatch))
return !!wildmatch(argv[3], argv[2], 0);
else if (!strcmp(argv[1], iwildmatch))
-- 
1.8.0.1417.gf6038d8
--
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: [wishlist] support git flow-like view

[Johannes Sixt]

Am 11/21/2012 1:13, schrieb Lisandro Damián Nicanor Pérez Meyer:
 I think the best mock-up would be:
 
 http://nvie.com/img/2009/12/Screen-shot-2009-12-24-at-11.32.03.png
 
 Yes, I'm referring to swim-lanes like view. Which may be already there and 
 I'm miserably failing to see :-/
Maybe you are just looking for gitk --date-order --branches?

-- Hannes

--
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: [PATCH v5 15/15] fast-export: don't handle uninteresting refs

[Felipe Contreras]

On Wed, Nov 21, 2012 at 6:08 AM, Junio C Hamano gits...@pobox.com wrote:

 I see Felipe keeps repeating that there are bugs, and keeps posting
 patches to change fast-export, but I haven't seen a concrete No,
 the reason why you see these problems is because you are not using
 the interface correctly; the currrent interface is fine.  Here is
 how you can fix your program from others.

 With such a one-sided discussion, I've been having a hard time
 convincing myself if Felipe's effort is making the interface better,
 or just breaking it even more for existing remote helpers, only to
 fit his world model better.

IIRC you mentioned something about this mailing list being focused on
*technical* merit. I've explained as much as I could, but at the end
of the talk, talk is cheap, the code speaks for itself. I added a new
very very very simple testgit remote helper, so anybody can see what's
going on, and figure out how the interface could be used wrong.

Anybody can modify the bash version of git-remote-testgit and say 'no,
the interface is not broken, here is how you push and pull without
marks'. How hard is it to hack 82 lines of bash code?

But lets assume my testgit is fatally broken, would you, Junio, accept
these patches if I show the same broken behavior with the python
git-remote-testgit?

I'm afraid I have to point out the hard truth; the reason why nobody
is doing that is because a) the interface is truly broken b) if they
try, they most likely would fail, and that would prove they were wrong
in previous discussion, or c) not enough familiarity with the code. I
don't want to point fingers, nor do I intend to offend anybody, but I
cannot find any other explanation of why this patch series, which is
obviously correct (to me), doesn't receive any feedback, even though
in theory, it should be very very very easy to show what's wrong with
the series.

The tests are there, and the remote helper is as simple as it gets.
There's nothing else but fast-export and transport-helper to blame for
the issues. It's that simple.

Cheers.

-- 
Felipe Contreras
--
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

a menagerie of crystal animals

[patteu39]

a menagerie of crystal animals, grinding and abrasive tools, glass reflectors
for the road and rail, nor the production of faucets and knobs for both
doors and cabinetry.[url=http://www.bijouxswarovskiboutique.com/]bijoux
swarovski[/url]is considered by many people to be the finest quality,
full-lead crystal made today.  It contains a minimum of 32%PbO, making the
crystal optically very pure. http://www.bijouxswarovskiboutique.com/  



--
View this message in context: 
http://git.661346.n2.nabble.com/a-menagerie-of-crystal-animals-tp7571661.html
Sent from the git mailing list archive at Nabble.com.
--
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