Re: "git grep --no-index" doesn't do what it says on the tin?

[Antoine Pelisse]

On Wed, May 15, 2013 at 7:32 AM, Nazri Ramliy  wrote:
> Hi,
>
> From "git help grep":
>
>   --no-index
>Search files in the current directory that is not managed by Git.
>
>--untracked
>In addition to searching in the tracked files in the working tree,
>search also in untracked files.

The difference is in the "not managed by Git". Inside a repository,
they will do the same thing. But only the first can work outside a
repository.

Cheers,
Antoine
--
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: [PATCHv2 03/10] refs.c: Refactor code for mapping between shorthand names and full refnames

[Michael Haggerty]

On 05/14/2013 04:24 PM, Johan Herland wrote:
> On Mon, May 13, 2013 at 10:34 PM, Junio C Hamano  wrote:
>> Junio C Hamano  writes:
>>> Johan Herland  writes:
 Obviously, I named it '%1' since it expands into the _first_ component
 of the (slash-separated) shorthand.
>>>
>>> OK, I can buy something like
>>>
>>>   %*
>>> refs/%*
>>> refs/heads/%*
>>> ...
>>> refs/remotes/%*/HEAD
>>> refs/remotes/%1/%2
>>> refs/peers/%1/heads/%2
>>>
>>> that is, for a pattern that has %*, we feed the end-user string as a
>>> whole, and for a pattern that has %1 thru %N, we find an appropriate
>>> way to chop the end-user string into N pieces (e.g. nick/name would
>>> be split into %1 = nick, %2 = name, while foo/bar/baz might have two
>>> possibilities, <%1, %2> =  or ).  The
>>> earlier ones on the above list can even be written with their %*
>>> substituted with %1 if we go that route.
>>
>> Just to make sure.
>>
>> Please do not let "two possibilities" stop you.  As I said in the
>> nearby thread, I do not necessarily insist that we must try all N
>> possibilities.  "We find an appropriate way" could be just "we
>> always chop at the first slash, and %1 is what comes before it, %2
>> is what comes after it".
>>
>> That will close the possibility for us to use %1 thru %N (N is
>> limited to 2), but it still is "We have %1 and we have %2, both fall
>> into the same 'path components, numbered from left to right'
>> category", and justifies the use of %1 ("one", not "el").
>>
>> So still no objection to %1 from me.
> 
> I think I like "refs/peers/%1/heads/%*" better than
> "refs/peers/%1/heads/%2", since the latter sort of makes me wonder
> whether the 3rd, 4th, etc. components would be discarded. That said,
> having %* mean "the rest of the shorthand" means that we must adjust
> the expansion of %* for every preceding %N, which prevents us from
> simplifying the code by using strbuf_expand_dict_cb() with a static
> dictionary [1].
> 
> I am not sure why we would want "refs/remotes/%1/%2" instead of
> "refs/remote/%*". Maybe I've been staring at this for too long, but I
> find the latter shorter and more descriptive and the "%1/%2" notation
> needlessly cumbersome, especially if it's also supposed to match
> "foo/bar/baz"

"refs/remotes/%1/%2" (or "refs/remotes/%1/%*") might be a nice way to
imply that the rule should only be attempted if the input has at least
two components, whereas something like "refs/heads/%*" would be applied
even for inputs with no slashes.

Michael

-- 
Michael Haggerty
mhag...@alum.mit.edu
http://softwareswirl.blogspot.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

Re: is this a bug of git-diff?

[Antoine Pelisse]

On Wed, May 15, 2013 at 8:23 AM, eric liou  wrote:
> The output of git-diff is different from my expectation.
> It may skip some lines of context.

git-diff is using a default of 3 lines of context above and below the changes.
In your example, there is only two lines of context below the change,
so only two lines are displayed.
Above the change, three lines are displayed, as expected. That's why
the blank line and leading slash line are not displayed.
You can change the number of context lines by invoking git-diff with -U.

Hope that helps,
Antoine
--
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: Fwd: git cvsimport implications

[Michael Haggerty]

On 05/15/2013 12:19 AM, Junio C Hamano wrote:
> Eugene Sajine  writes:
> 
>> What if there are a lot of branches in the CVS repo? Is it guaranteed
>> to be broken after import?
> 
> Even though CVS repository can record branches in individual ,v
> files, reconstructing per branch history and where the branch
> happened in each "changeset" cannot be determined with any
> certainty.  The best you can get is a heuristic result.
> 
> I do not think anybody can give such a guarantee.  The best you can
> do is to convert it and validate if the result matches what you
> think has happened in the CVS history.

Junio, you are correct that there is no 100% reliable way of inferring
the changesets that were made in CVS.  CVS doesn't record which file
revisions were committed at the same time, unambiguous branch points,
etc.  The best a tool can do is use heuristics.

But it *is* possible for a conversion tool to make some more elementary
guarantees regarding aspects of the history that are recorded
unambiguously in CVS, for example:

* That if you check the tip of same branch out of CVS and out of Git,
you get the same contents.

* That CVS file revisions are committed to Git in the correct order
relative to each other; e.g., that the changes made in CVS revision
1.4.2.2 in a particular file precede those made in revision 1.4.2.3 of
the same file.

git-cvsimport fails to ensure even this minimal level of correctness.
Such errors are demonstrated in its own test suite.

cvs2git, on the other hand, gets the basics 100% correct (if you find a
discrepancy, please file a bug!), in addition to having great heuristics
for inferring the details of the history.

There is no reason ever to use git-cvsimport for one-time conversions
from CVS to Git.  The only reason ever to use it is if you absolutely
require an incremental bridge between CVS and Git, and even then please
use it with great caution.

Michael
the cvs2svn/cvs2git maintainer

-- 
Michael Haggerty
mhag...@alum.mit.edu
http://softwareswirl.blogspot.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

is this a bug of git-diff?

[eric liou]

The output of git-diff is different from my expectation.
It may skip some lines of context.
For the case of the diff result attached here, a blank line and a line
with a leading slash is skipped.

Please check out the attached files for details.

Thanks.


ab.patch
Description: Binary data
int a = 1;

/*
 * 1
 * 2
 * 3
 * added
 */
 int a = 1;

/*
 * 1
 * 2
 * 3
 */
 

Re: Problems with Windows, Was: What's cooking in git.git (May 2013, #01; Fri, 3)

[Tay Ray Chuan]

On Wed, May 15, 2013 at 3:37 AM, Torsten Bögershausen  wrote:
> Second,
> I was able to do some testing.
> The hanging is not 100% reproducable, and I had one hanging in Git 1.8.1
>
> Turning the screen saver off in Win XP helps that the machine reacts,
> and using process explorer showed that the hanging is happening
> in test cases doing "git fetch" (or git pull) from a local repository.
> What I can see is one git-fetch.exe together with git-upload-pack.exe

I also managed to run into the intermittent hanging of git-fetch when
running t5510. What I do is keep running the test till it stalls:

  while [ $? -eq 0 ]; do date; ./t5510-fetch.sh -i -v; done

Almost always the git-fetch output looks like this:

  remote: Counting objects: 7, done.
  remote: Compressing objects: 100% (5/5), done.
  remote: Total 6 (delta 1), reused 0 (delta 0)

However my task manager indicates that git-upload-pack or whatever
that runs on the remote side is absent, only git-fetch is waiting - 0
I/O, 0 cswitches, nilda. I tried getting a gdb backtrace but I get ???
nonsense, despite having compiled git with `-g -O0`. I also noticed
there were a couple of threads. This is my gdb session:

$ gdb --pid=7936
GNU gdb (GDB) 7.6.50.20130508-cvs (cygwin-special)
...
Attaching to process 7936
[New Thread 7936.0x1c7c]
[New Thread 7936.0x6b8]
[New Thread 7936.0xd20]
[New Thread 7936.0x1cf8]
[New Thread 7936.0x1b24]
Reading symbols from /cygdrive/f/files/coding/git/git.exe...done.
(gdb) info thread
  Id   Target Id Frame
* 5Thread 7936.0x1b24 0x77c5000d in ntdll!DbgBreakPoint ()
   from /cygdrive/c/Windows/SysWOW64/ntdll.dll
  4Thread 7936.0x1cf8 0x77c5f8b1 in ntdll!ZwWaitForSingleObject ()
   from /cygdrive/c/Windows/SysWOW64/ntdll.dll
  3Thread 7936.0xd20 0x77c5f91d in ntdll!ZwWriteFile ()
   from /cygdrive/c/Windows/SysWOW64/ntdll.dll
  2Thread 7936.0x6b8 0x77c5f8b1 in ntdll!ZwWaitForSingleObject ()
   from /cygdrive/c/Windows/SysWOW64/ntdll.dll
  1Thread 7936.0x1c7c 0x77c5f8b1 in ntdll!ZwWaitForSingleObject ()
   from /cygdrive/c/Windows/SysWOW64/ntdll.dll
(gdb) bt
#0  0x77c5000d in ntdll!DbgBreakPoint () from
/cygdrive/c/Windows/SysWOW64/ntdll.dll
#1  0x77cdf896 in ntdll!DbgUiRemoteBreakin () from
/cygdrive/c/Windows/SysWOW64/ntdll.dll
#2  0x775c5cca in ?? ()
#3  0x in ?? ()
(gdb) thread 4
[Switching to thread 4 (Thread 7936.0x1cf8)]
#0  0x77c5f8b1 in ntdll!ZwWaitForSingleObject () from
/cygdrive/c/Windows/SysWOW64/ntdll.dll
(gdb) bt
#0  0x77c5f8b1 in ntdll!ZwWaitForSingleObject () from
/cygdrive/c/Windows/SysWOW64/ntdll.dll
#1  0x77c5f8b1 in ntdll!ZwWaitForSingleObject () from
/cygdrive/c/Windows/SysWOW64/ntdll.dll
#2  0x7573149d in WaitForSingleObjectEx () from
/cygdrive/c/Windows/syswow64/KERNELBASE.dll
#3  0x0148 in ?? ()
#4  0x in ?? ()
(gdb) thread 3
[Switching to thread 3 (Thread 7936.0xd20)]
#0  0x77c5f91d in ntdll!ZwWriteFile () from
/cygdrive/c/Windows/SysWOW64/ntdll.dll
(gdb) bt
#0  0x77c5f91d in ntdll!ZwWriteFile () from
/cygdrive/c/Windows/SysWOW64/ntdll.dll
#1  0x77c5f91d in ntdll!ZwWriteFile () from
/cygdrive/c/Windows/SysWOW64/ntdll.dll
#2  0x7572dec1 in WriteFile () from /cygdrive/c/Windows/syswow64/KERNELBASE.dll
#3  0x009c in ?? ()
#4  0x in ?? ()
(gdb) thread 2
[Switching to thread 2 (Thread 7936.0x6b8)]
#0  0x77c5f8b1 in ntdll!ZwWaitForSingleObject () from
/cygdrive/c/Windows/SysWOW64/ntdll.dll
(gdb) bt
#0  0x77c5f8b1 in ntdll!ZwWaitForSingleObject () from
/cygdrive/c/Windows/SysWOW64/ntdll.dll
#1  0x77c5f8b1 in ntdll!ZwWaitForSingleObject () from
/cygdrive/c/Windows/SysWOW64/ntdll.dll
#2  0x7573149d in WaitForSingleObjectEx () from
/cygdrive/c/Windows/syswow64/KERNELBASE.dll
#3  0x001c in ?? ()
#4  0x in ?? ()
(gdb) thread 1
[Switching to thread 1 (Thread 7936.0x1c7c)]
#0  0x77c5f8b1 in ntdll!ZwWaitForSingleObject () from
/cygdrive/c/Windows/SysWOW64/ntdll.dll
(gdb) bt
#0  0x77c5f8b1 in ntdll!ZwWaitForSingleObject () from
/cygdrive/c/Windows/SysWOW64/ntdll.dll
#1  0x77c5f8b1 in ntdll!ZwWaitForSingleObject () from
/cygdrive/c/Windows/SysWOW64/ntdll.dll
#2  0x7573149d in WaitForSingleObjectEx () from
/cygdrive/c/Windows/syswow64/KERNELBASE.dll
#3  0x0034 in ?? ()
#4  0x in ?? ()

--
Cheers,
Ray Chuan
--
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 grep --no-index" doesn't do what it says on the tin?

[Nazri Ramliy]

Hi,

>From "git help grep":

  --no-index
   Search files in the current directory that is not managed by Git.

   --untracked
   In addition to searching in the tracked files in the working tree,
   search also in untracked files.

>From the description above I would think that "git grep --no-index"
and "git grep --untracked" would behave differently, but it seems like
their behavior is the same:

$ cd ~/src/git
$ echo superman >> git.c
$ echo superman >> foo.txt
$ git grep --no-index superman
foo.txt:1:superman
git.c:588:superman
$ git grep --untracked superman
foo.txt:1:superman
git.c:588:superman

I would expect the following behavior for "git grep --no-index":

$ git grep --no-index superman
foo.txt:1:superman
$

That is, it won't search inside files that are managed by git.

nazri
--
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: Segmentation fault with latest git (070c57df)

[sam]

Hmmm nabble embed didn't provide much value there :)

http://pastebin.com/RC8mUPF3



--
View this message in context: 
http://git.661346.n2.nabble.com/Segmentation-fault-with-latest-git-070c57df-tp7576614p7585907.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

Re: Segmentation fault with latest git (070c57df)

[sam]

Hi,

Has there been any further progress on this. I just encountered a SEGV with
a git apply. This is the latest git version running on Ubuntu 13.04

cat /etc/lsb-release 
DISTRIB_ID=Ubuntu
DISTRIB_RELEASE=13.04
DISTRIB_CODENAME=raring
DISTRIB_DESCRIPTION="Ubuntu 13.04"

uname -a
Linux sam-mac 3.8.0-20-generic #31-Ubuntu SMP Mon May 6 17:03:32 UTC 2013
x86_64 x86_64 x86_64 GNU/Linux

git --version
git version 1.8.2.2


samueldoyle@sam-MacBookPro:~/Projects/VMware/perforce_repos/esx50u3ps$ sudo
gdb /usr/bin/git core
GNU gdb (GDB) 7.5.91.20130417-cvs-ubuntu
Copyright (C) 2013 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later

This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
For bug reporting instructions, please see:
...
Reading symbols from /usr/bin/git...(no debugging symbols found)...done.
[New LWP 28634]

warning: Can't read pathname for load map: Input/output error.
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".

warning: no loadable sections found in added symbol-file system-supplied DSO
at 0x7fff94d1a000
Core was generated by `git apply --verbose --check --ignore-whitespace
--directory=/home/sam/P'.
Program terminated with signal 11, Segmentation fault.
#0  __strlen_sse2 () at ../sysdeps/x86_64/multiarch/../strlen.S:31
31  ../sysdeps/x86_64/multiarch/../strlen.S: No such file or directory.
(gdb) bt 10
#0  __strlen_sse2 () at ../sysdeps/x86_64/multiarch/../strlen.S:31
#1  0x7f06ba7c28c6 in __GI___strdup (s=0x0) at strdup.c:41
#2  0x004f4449 in ?? ()
#3  0x0040eab0 in ?? ()
#4  0x0040f6f5 in ?? ()
#5  0x00405a88 in ?? ()
#6  0x00404ee2 in ?? ()
#7  0x7f06ba75aea5 in __libc_start_main (main=0x404e30, argc=7,
ubp_av=0x7fff94c3bd08, init=, fini=, 
rtld_fini=, stack_end=0x7fff94c3bcf8) at libc-start.c:260
#8  0x00405329 in ?? ()


A quick search turned up this post that appears to provide the cause:
http://stackoverflow.com/questions/3608931/why-is-this-program-segfaulting



--
View this message in context: 
http://git.661346.n2.nabble.com/Segmentation-fault-with-latest-git-070c57df-tp7576614p7585906.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

Re: [PATCH] git-svn: introduce --parents parameter for commands branch and tag

[Eric Wong]

Tobias Schulte  wrote:
> This parameter is equivalent to the parameter --parents on svn cp commands
> and is useful for non-standard repository layouts.

This looks useful.  A few minor cosmetic issues.

> +++ b/Documentation/git-svn.txt
> @@ -298,6 +298,11 @@ where  is the name of the SVN repository as 
> specified by the -R option to
>   git config --get-all svn-remote..commiturl
>  +
>  
> +--parents;;
> + Create parent folders. This parameter is equivalent to the parameter 
> + --parents on svn cp commands and is useful for non-standard repository 
> + layouts.

Trailing whitespace.

> +sub mk_parent_dirs {
> + my $ctx = shift;
> + my $parent = shift;

I prefer declaring multiple variables from arguments as:

my ($ctx, $parent) = @_;

> + $parent =~ s/\/[^\/]*$//;

You can avoid leaning toothpick syndrome (escaping '/') by specifying
alternate delimiters:

$parent =~ s{/[^/]*$}{};

ref: perlop(1)

> + if (!eval{$ctx->ls($parent, 'HEAD', 0)}) {
> + mk_parent_dirs($ctx, $parent);
> + print "Creating parent folder ${parent} ...\n";
> + $ctx->mkdir($parent)
> + unless $_dry_run;

The newline is confusing, I prefer:

$ctx->mkdir($parent) unless $_dry_run;

Howeve :

if (!$_dry_run) {
$ctx->mkdir($parent);
}

May be preferred, too (especially for the non-Perl-fluent)

> +++ b/t/t9167-git-svn-cmd-branch-subproject.sh

> +test_expect_success 'initialize svnrepo' '
> +mkdir import &&
> +(
> +(cd import &&
> +mkdir -p trunk/project branches tags &&
> +(cd trunk/project &&
> +echo foo > foo
> +) &&

Tabs for all indentation, and indent consistently for subshells:

mkdir import &&
(
cd import &&
mkdir .. &&
(
cd .. &&
..
)
)

We use subshells + cd like this so it's easier to read/maintain.

Thanks again, looking forward to applying v2.
--
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 resend 0/2] git-svn: improve documentation of multiple fetch lines

[Eric Wong]

Jonathan Nieder  wrote:
> I last sent these patches as an RFC a year and a half or so ago[1].
> Nathan seemed to like them and they still seem valid, so thought
> I'd resubmit. :)

Thanks, both applied.  Sorry for forgetting :x
--
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 v9 1/9] git-clean: refactor git-clean into two phases

[Jiang Xin]

2013/5/15 Junio C Hamano :
>> @@ -242,11 +287,6 @@ int cmd_clean(int argc, const char **argv, const char 
>> *prefix)
>>   continue; /* Yup, this one exists unmerged */
>>   }
>>
>> - /*
>> -  * we might have removed this as part of earlier
>> -  * recursive directory removal, so lstat() here could
>> -  * fail with ENOENT.
>> -  */
>>   if (lstat(ent->name, &st))
>>   continue;
>
> I am guessing that the reason why you removed the comment is because
> during this phase there is no way we "might have removed".  But if
> that is the case, does it still make sense to run lstat() and ignore
> errors from the call?
>

Run lstat() here is necessary, because we need to check whether
ent->name points to a file or a directory. If ent points to a directory,
only add to del_list when user provides '-x' option to git-clean.

if (S_ISDIR(st.st_mode)) {
if (remove_directories || (matches ==
MATCHED_EXACTLY)) {
rel = path_relative(ent->name, prefix);
string_list_append(&del_list, rel);
}
} ...


When start to do cleaning, there is a duplicate lstat() call, and the removed
comments above are moved here.

/*
 * we might have removed this as part of earlier
 * recursive directory removal, so lstat() here could
 * fail with ENOENT.
 */
if (lstat(abs_path.buf, &st))
continue;

if (S_ISDIR(st.st_mode)) {
if (remove_dirs(&abs_path, prefix, rm_flags,
dry_run, quiet, &gone))
errors++;
if (gone && !quiet) {
qname =
quote_path_relative(item->string, -1, &buf, NULL);
printf(dry_run ? _(msg_would_remove) :
_(msg_remove), qname);
}
}

But I am not clear how "earlier recursive directory removal" could
make lstat() failure here. If it is not the case, maybe we can test a
directory by ent->name (ends with '/' or '\\' ?).

-- 
Jiang Xin
--
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/PATCH] branch: show me the hot branches

[Duy Nguyen]

On Tue, May 14, 2013 at 3:02 AM, Ramkumar Ramachandra
 wrote:
> Uses commit->date to sort displayed refs.
>
> Signed-off-by: Ramkumar Ramachandra 
> ---
>  Just had this idea and wrote it down in five minutes.  The
>  implementation is only meant to be indicative.
>
>  Isn't this awesome?

I tried a more generic approach a while ago.

http://thread.gmane.org/gmane.comp.version-control.git/188705
--
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 v3 08/10] remote-hg: update bookmarks when pulling

[Felipe Contreras]

On Tue, May 14, 2013 at 6:32 PM, Junio C Hamano  wrote:
> Felipe Contreras  writes:
>
>> ... After all, this is in the contrib area,
>> so if there's a time for a possible future maintainer of a core part
>> of git to make mistakes, it would be now.
>
> That sounds reasonable.
>
> Incidentally, before I had to stop working in order to respond to
> your endless arguments, I already queued the 8 patches to 'master'
> (also remote-bzr one is in below that).

Cool. But FTR, the "endless arguments" come from both sides.

> I had no time checking other topics in flight nor merging the result
> up to 'next' and 'pu' yet, and it will take a while for the result
> to be published, but we'll see these in 1.8.3.

Well, the priority is 1.8.3.

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: [RFC/PATCH] branch: show me the hot branches

[Junio C Hamano]

Phil Hord  writes:

> I imagine it with --date-order and whatnot.

Perhaps modeled after this one.

git for-each-ref \
--format='%(refname:short) %(subject)'
--sort='-committerdate' refs/heads/

--
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 v3 08/10] remote-hg: update bookmarks when pulling

[Junio C Hamano]

Felipe Contreras  writes:

> ... After all, this is in the contrib area,
> so if there's a time for a possible future maintainer of a core part
> of git to make mistakes, it would be now.

That sounds reasonable.

Incidentally, before I had to stop working in order to respond to
your endless arguments, I already queued the 8 patches to 'master'
(also remote-bzr one is in below that).

I had no time checking other topics in flight nor merging the result
up to 'next' and 'pu' yet, and it will take a while for the result
to be published, but we'll see these in 1.8.3.
--
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 v9 0/9] interactive git-clean

[Junio C Hamano]

Except for one nit in 1/9, the series seems to be nicely done.
--
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 v9 1/9] git-clean: refactor git-clean into two phases

[Junio C Hamano]

Jiang Xin  writes:

> +/*
> + * Give path as relative to prefix.
> + *
> + * This function is a combination of path_relative (in quote.c) and
> + * relative_path (in path.c)
> + */
> +static const char *path_relative(const char *in, const char *prefix)
> +{
> +...

Hmph.  Is it possible to reuse the public one (in path.c) here and
in quote.c, perhaps after enhancing it a bit to serve needs of the
callers of two existing ones and the new callers of this one?

> @@ -242,11 +287,6 @@ int cmd_clean(int argc, const char **argv, const char 
> *prefix)
>   continue; /* Yup, this one exists unmerged */
>   }
>  
> - /*
> -  * we might have removed this as part of earlier
> -  * recursive directory removal, so lstat() here could
> -  * fail with ENOENT.
> -  */
>   if (lstat(ent->name, &st))
>   continue;

I am guessing that the reason why you removed the comment is because
during this phase there is no way we "might have removed".  But if
that is the case, does it still make sense to run lstat() and ignore
errors from the call?

--
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/PATCH] branch: show me the hot branches

[Phil Hord]

On Mon, May 13, 2013 at 4:02 PM, Ramkumar Ramachandra
 wrote:
> Uses commit->date to sort displayed refs.
>
> Signed-off-by: Ramkumar Ramachandra 
> ---

I dig it.

I imagine it with --date-order and whatnot.  But I might like it even
better if it were reverse-sorted.  Maybe it needs -rt for that. ;-)

Phil
--
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 v3 08/10] remote-hg: update bookmarks when pulling

[Felipe Contreras]

On Tue, May 14, 2013 at 5:49 PM, Junio C Hamano  wrote:
> Felipe Contreras  writes:
>
>> The reason for the "only regression" period is to avoid more
>> regressions. If you show me how any of the fixes I sent in this series
>> could potentially cause a regression,
>
> I already said that "You can see these patches are so trivially
> correct" is not a valid argument.

You can say so, it doesn't make it so.

> The original patches would also
> have been looked correct when they were sent to the list.

No, they didn't look correct, and I made it clear when I sent the
patches to be *tested*.

> Things
> take time and actual use by the users to mature.

Some things, not all things. That's a hasty generalization fallacy.

>>> You cannot be both.  Which is it?
>>
>> I marked the patch that fix a regression as such, I marked the patches
>> that are obvious fixes with no possibility of regressions as such, and
>> I marked the trivial cleanups with no possibility of regressions as
>> such.
>
> I think you mean 6/10 by "the patch that fix a regression", but if
> that is the case, please send only the regression fix that cleanly
> apply to the tip of 'master', without any other dependencies, with a
> proper description of what breaks and how it fixes.

I did that for v2, but you didn't merge that.

> We know you can do better than "certain" and "might".
>
>> In certain situations we might end up pushing garbage revisions (e.g. in
>> a rebase), and the patches to deal with that haven't been merged yet.
>>
>> So let's disable forced pushes by default.

I have done more than enough. I'm not going to write tests for this,
and I'm not going to find out for sure. There is a *potential* that
there's a regression, and that's reason enough to apply this patch as
it is.

I have done way more than my fair share already. I'm 98% certain that
this patch series as it is would not introduce a regression for
v1.8.3, and that's good enough for me. If anybody has any problem with
that, they can pick this series and do whatever they want with them.

If I'm supposed to be the owner of contrib/remote-helpers, it
certainly doesn't feel that way. If I am the owner, but you are
worried, why don't you let me make the decision, and if something
blows in v1.8.3, you can tell me; "see? you are not ready to have the
full maintainership of this". After all, this is in the contrib area,
so if there's a time for a possible future maintainer of a core part
of git to make mistakes, it would be now. But of course, this would
*not* happen, because the patches are obviously correct and I stand by
that claim.

As things currently stand, v1.8.3 *might* introduce a regression.

-- 
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: [PATCH v3 08/10] remote-hg: update bookmarks when pulling

[Junio C Hamano]

Felipe Contreras  writes:

> The reason for the "only regression" period is to avoid more
> regressions. If you show me how any of the fixes I sent in this series
> could potentially cause a regression,

I already said that "You can see these patches are so trivially
correct" is not a valid argument. The original patches would also
have been looked correct when they were sent to the list. Things
take time and actual use by the users to mature.

>> You cannot be both.  Which is it?
>
> I marked the patch that fix a regression as such, I marked the patches
> that are obvious fixes with no possibility of regressions as such, and
> I marked the trivial cleanups with no possibility of regressions as
> such.

I think you mean 6/10 by "the patch that fix a regression", but if
that is the case, please send only the regression fix that cleanly
apply to the tip of 'master', without any other dependencies, with a
proper description of what breaks and how it fixes.

We know you can do better than "certain" and "might".

> In certain situations we might end up pushing garbage revisions (e.g. in
> a rebase), and the patches to deal with that haven't been merged yet.
> 
> So let's disable forced pushes by default.

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: [PATCH] remote-bzr: update old organization

[Felipe Contreras]

On Tue, May 14, 2013 at 5:33 PM, Junio C Hamano  wrote:
> Felipe Contreras  writes:
>
>> On Tue, May 14, 2013 at 5:14 PM, Junio C Hamano  wrote:
>>> Junio C Hamano  writes:
>>>
 Felipe Contreras  writes:

> And the clone would happen either way, with or without this patch,
> because 'hg/origin/master' doesn't exist, the only purpose 'hg/origin'
> serves is to block the new feature.

 That is the answer I was trying to extract out of you (I take the hg
 is a typo for bzr in the above, though).
>>>
>>> Just to double check, I understand that the justification for
>>> removal is this:
>>>
>>>  If a clone exists with the old organization (v1.8.2) it will prevent 
>>> the
>>>  new shared repository organization from working, so let's remove this
>>> -repository, which is not used any more.
>>> +repository. It is not used by 1.8.3, and did not host any useful
>>> +information in the code in 1.8.2.
>>
>> That is not true. It did host useful information in 1.8.2, if we apply
>> this and the user tries to pull with remote-bzr from 1.8.2, it would
>> need to be cloned again.
>
> So the answer to my original question:
>
> So we nuke that and have them clone from scratch?

No, as I already explained the "cloning from scratch" is already
happening with or without this patch.

All this change does is remove a repository that is not used any more
in order to allow a feature that was already introduced, and that's
exactly what the commit message says. It doesn't cause any other
change.

-- 
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: [msysGit] Re: Problems with Windows, Was: What's cooking in git.git (May 2013, #01; Fri, 3)

[Philip Oakley]

sorry about the MUA mangling - reply at end.
- Original Message - 
From: "Torsten Bögershausen" 

To: "Ramsay Jones" 
Cc: "Torsten Bögershausen" ; "Junio C Hamano"
; ; ;
"Jonathan Nieder" ; ; "msysGit"

Sent: Tuesday, May 14, 2013 8:37 PM
Subject: [msysGit] Re: Problems with Windows, Was: What's cooking in
git.git (May 2013, #01; Fri, 3)


On 2013-05-09 19.18, Ramsay Jones wrote:

Torsten Bögershausen wrote:

On 2013-05-04 01.14, Junio C Hamano wrote:


 Cygwin portability; both were reviewed by Jonathan, and the tip one
 seems to want a bit further explanation.  Needs positive report
 from Cygwin 1.7 users who have been on 1.7 to make sure it does not
 regress for them.


I was trying to verify that cygwin 1.7 is still Ok, but got puzzled.

Running the test suite under cygwin doesn't seem to work any more
(?):

Scenario 1:
The PC is running alone, and goes into the screen saver.
Pressing CTRL-ALT-DEL didn't get any effect.

Scenario 2:
The PC didn't react any more, when the test suite was run in
background.
In 3 or 4 cases the PC needed to be reboot hardly.

Using the commits before and after this change makes the test suite
hang
as well at some point, then it hangs somewhere at TC 3000--4000.

Scenario 4:
The I disabled the screensaver, upgdated cygwin,
 and went back to an older commit:
The latest run from commit 52d63e70, April 28,
hangs in TC 5500, ok 26 clone shallow object count.

I can see 2 times
git.exe pull --depth 4 ..A

Scenario 5:
The run of today 1.8.3-rc1, hangs in t5510,
some git.exe are running fetch. (or pull)


It seems as if some process/exes are not terminated
in the way it should be.

I will try on a different machine,
comments are wellcome


Hmm, I'm a little puzzled, but not shocked. ;-)

Somebody, I forget who, had already tested Jonathan's patch
on cygwin 1.7 successfully and my follow up patch should be
a no-op on cygwin 1.7; so I'm puzzled! (The high risk should
have been on cygwin 1.5).

I'm not shocked because running the test-suite on cygwin has
been a bit of a magical mystery tour for quite some time.

In about 2007, I could not run the test-suite for about six
to nine months; it would randomly wedge my laptop solid - I had
to pull the power-cord out in order to re-boot. (I suspect that
commit 9cb18f56fde may have cured that particular problem, but
don't quote me on that - I didn't investigate at the time.)

I have noticed that running the tests with 'prove' is more likely
to prove successful, so my config.mak looks like:

$ cat config.mak
NO_SVN_TESTS=1
GIT_TEST_OPTS=--no-color
NO_GETTEXT=1
DEFAULT_TEST_TARGET=prove
GIT_PROVE_OPTS='--timer'
$

I currently run the tests like so:

$ time $(GIT_SKIP_TESTS='t0061.3 t0070.3 t4130 t9010 t9300' make
test \
>test-outp13 2>&1)

real172m25.311s
user132m15.133s
sys 66m43.122s
$

The t0061.3 and t0070.3 failures don't require much discussion. The
t4130
failure is an intermittent "racy git" issue that has been on my TODO
list
for several years. t9300 also fails intermittently. However, t9010
fails
every time for me, hanging the test suite (although ^C interrupts it
just
fine).

I have a "fix" for t9010 that looks like:

diff --git a/t/t9010-svn-fe.sh b/t/t9010-svn-fe.sh
index b7eed24..4d01e3b 100755
--- a/t/t9010-svn-fe.sh
+++ b/t/t9010-svn-fe.sh
@@ -22,10 +22,9 @@ try_dump () {
maybe_fail_fi=${3:+test_$3} &&

{
-   $maybe_fail_svnfe test-svn-fe "$input" >stream
3backflow &&
-   wait $!
+   $maybe_fail_svnfe test-svn-fe "$input" 3backflow
 }

 properties () {

but I have not tested this patch enough to be happy to submit it (I
have
some suspicions that it would still fail intermittently, just like
t9300).

Also, commit 7bc0911d ("test-lib: Fix say_color () not to interpret
\a\b\c
in the message", 11-10-2012) caused several random test failures.
(don't ask
me why). So, before each test run, I have to apply the following:

diff --git a/t/test-lib.sh b/t/test-lib.sh
index f50f834..ed32b7f 100644
--- a/t/test-lib.sh
+++ b/t/test-lib.sh
@@ -230,7 +230,7 @@ else
say_color() {
test -z "$1" && test -n "$quiet" && return
shift
-   printf "%s\n" "$*"
+   echo -E "$*"
}
 fi

which effectively reverts that commit.

So, as I said, a "magical mystery tour". :-D

ATB,
Ramsay Jones



First of all,
the patch we are talking about does not any regrssions at my side.

Second,
I was able to do some testing.
The hanging is not 100% reproducable, and I had one hanging in Git 1.8.1

Turning the screen saver off in Win XP helps that the machine reacts,
and using process explorer showed that the hanging is happening
in test cases doing "git fetch" (or git pull) from a local repository.
What I can see is one git-fetch.exe together with git-upload-pack.exe


From my understanding is

Re: [PATCH v3 08/10] remote-hg: update bookmarks when pulling

[Felipe Contreras]

On Tue, May 14, 2013 at 5:25 PM, Junio C Hamano  wrote:
> Felipe Contreras  writes:
>
>> On Tue, May 14, 2013 at 4:59 PM, Junio C Hamano  wrote:
>>> Felipe Contreras  writes:
>>>
 Without this fix, the user would never ever see new bookmarks, only the 
 ones
 that (s)he initially cloned.
>>>
>>> Now, think again and realize how long it took you (the original
>>> author) to discover issues and come up with these fixes and
>>> explanation since the series was merged before -rc0.
>>
>> This issue has *always* been there, it's not a regression.
>
> Then why are you rushing it?  -rc is a "regression-fix-only" period.

I'm not rushing this patch, I'm rushing the regression fix. I added
the cleanup patches because they help the fix, and I added this patch
because it's obviously good.

>> Define "ready". It's probably more "ready" than any other bridge
>> tool out there.
>
> Anything that needs "oh, we need to push these ten patches to avoid
> regressions at the last minute" is not mature enough to be relied
> upon by end users for everyday use.  That is what I meant.

Only a single patch is needed to fix the regression and I sent that
patch standalone in v2 of this series, but you didn't pick it, so I
sent the cleanups as well.

> But now you are saying these are not regression fixes, in which case
> they have to wait because the users have known about the limitations
> that existed for a long time and learned to live with them.  That is
> a sign of mature (not "not ready") software.

No, they don't have to wait. And we don't have to mindlessly apply
guidelines as dogma.

The reason for the "only regression" period is to avoid more
regressions. If you show me how any of the fixes I sent in this series
could potentially cause a regression, I would agree with you, even if
remote, the possibility would be there, therefore the patch wouldn't
be material for 1.8.3.

But the fact of the matter is that the possibility is not there, we
are not decreasing the possibility of regressions, we are simply
removing a feature users could enjoy for no gain at all.

> You cannot be both.  Which is it?

I marked the patch that fix a regression as such, I marked the patches
that are obvious fixes with no possibility of regressions as such, and
I marked the trivial cleanups with no possibility of regressions as
such.

-- 
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: [PATCH] remote-bzr: update old organization

[Junio C Hamano]

Felipe Contreras  writes:

> On Tue, May 14, 2013 at 5:14 PM, Junio C Hamano  wrote:
>> Junio C Hamano  writes:
>>
>>> Felipe Contreras  writes:
>>>
 And the clone would happen either way, with or without this patch,
 because 'hg/origin/master' doesn't exist, the only purpose 'hg/origin'
 serves is to block the new feature.
>>>
>>> That is the answer I was trying to extract out of you (I take the hg
>>> is a typo for bzr in the above, though).
>>
>> Just to double check, I understand that the justification for
>> removal is this:
>>
>>  If a clone exists with the old organization (v1.8.2) it will prevent the
>>  new shared repository organization from working, so let's remove this
>> -repository, which is not used any more.
>> +repository. It is not used by 1.8.3, and did not host any useful
>> +information in the code in 1.8.2.
>
> That is not true. It did host useful information in 1.8.2, if we apply
> this and the user tries to pull with remote-bzr from 1.8.2, it would
> need to be cloned again.

So the answer to my original question:

So we nuke that and have them clone from scratch?

is now "Yes, unfortunately, but it happens automatically inside
remote-bzr and the users won't have to do anything extra"?

That is the kind of honest description I wanted to see.
--
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 v3 08/10] remote-hg: update bookmarks when pulling

[Junio C Hamano]

Felipe Contreras  writes:

> On Tue, May 14, 2013 at 4:59 PM, Junio C Hamano  wrote:
>> Felipe Contreras  writes:
>>
>>> Without this fix, the user would never ever see new bookmarks, only the ones
>>> that (s)he initially cloned.
>>
>> Now, think again and realize how long it took you (the original
>> author) to discover issues and come up with these fixes and
>> explanation since the series was merged before -rc0.
>
> This issue has *always* been there, it's not a regression.

Then why are you rushing it?  -rc is a "regression-fix-only" period.

> Define "ready". It's probably more "ready" than any other bridge
> tool out there.

Anything that needs "oh, we need to push these ten patches to avoid
regressions at the last minute" is not mature enough to be relied
upon by end users for everyday use.  That is what I meant.

But now you are saying these are not regression fixes, in which case
they have to wait because the users have known about the limitations
that existed for a long time and learned to live with them.  That is
a sign of mature (not "not ready") software.

You cannot be both.  Which is it?


--
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: Fwd: git cvsimport implications

[Junio C Hamano]

Eugene Sajine  writes:

> What if there are a lot of branches in the CVS repo? Is it guaranteed
> to be broken after import?

Even though CVS repository can record branches in individual ,v
files, reconstructing per branch history and where the branch
happened in each "changeset" cannot be determined with any
certainty.  The best you can get is a heuristic result.

I do not think anybody can give such a guarantee.  The best you can
do is to convert it and validate if the result matches what you
think has happened in the CVS history.
--
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 1/4] t5510: start tracking-ref tests from a known state

[Eric Sunshine]

On Sat, May 11, 2013 at 12:14 PM, Jeff King  wrote:
> We have three sequential tests for for whether tracking refs

s/for for/for/
[or]
s/for for/for checking/

> are updated by various fetches and pulls; the first two
> should not update the ref, and the third should. Each test
> depends on the state left by the test before.
>
> This is fragile (a failing early test will confuse later
> tests), and means we cannot add more "should update" tests
> after the third one.
>
> Let's instead save the initial state before these tests, and
> then reset to a known state before running each test.
>
> Signed-off-by: Jeff King 
--
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] remote-bzr: update old organization

[Felipe Contreras]

On Tue, May 14, 2013 at 5:14 PM, Junio C Hamano  wrote:
> Junio C Hamano  writes:
>
>> Felipe Contreras  writes:
>>
>>> And the clone would happen either way, with or without this patch,
>>> because 'hg/origin/master' doesn't exist, the only purpose 'hg/origin'
>>> serves is to block the new feature.
>>
>> That is the answer I was trying to extract out of you (I take the hg
>> is a typo for bzr in the above, though).
>
> Just to double check, I understand that the justification for
> removal is this:
>
>  If a clone exists with the old organization (v1.8.2) it will prevent the
>  new shared repository organization from working, so let's remove this
> -repository, which is not used any more.
> +repository. It is not used by 1.8.3, and did not host any useful
> +information in the code in 1.8.2.

That is not true. It did host useful information in 1.8.2, if we apply
this and the user tries to pull with remote-bzr from 1.8.2, it would
need to be cloned again.

-- 
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: [PATCH v3 08/10] remote-hg: update bookmarks when pulling

[Felipe Contreras]

On Tue, May 14, 2013 at 4:59 PM, Junio C Hamano  wrote:
> Felipe Contreras  writes:
>
>> Without this fix, the user would never ever see new bookmarks, only the ones
>> that (s)he initially cloned.
>
> Now, think again and realize how long it took you (the original
> author) to discover issues and come up with these fixes and
> explanation since the series was merged before -rc0.

This issue has *always* been there, it's not a regression.

> Are we giving the users enough time to discover and complain issues
> that these 10 patches may introduce before the final release?

Yes, because the time needed is *zero*.

> "You
> can see these patches are so trivially correct" is not a valid
> argument. The original patches would also have been looked correct
> when they were sent to the list. Things take time and actual use by
> the users to mature.

There was no original patches that introduced this regression, because
it's not a regression.

When I say these are trivially correct, I mean it; the regressions you
talk about were on patches that were marked as *not* trivially
correct, and potentially dangerous.

> Having said that, the impression I am getting is that whatever we
> pushed out in 1.8.2 and 1.8.3-rc0 was far from ready for real use,
> and with your explanations (by the way, I found that many of them
> deserve to be in the log message), the end result of applying these
> patches, up to 8/10, will still not be as it is very likely that you
> and users will discover issues at a similar rate, but at least it
> will be much closer to be ready than they currently are.

Define "ready". It's probably more "ready" than any other bridge tool out there.

> In other words, it still seems to be in "something is better than
> nothing, newer is better than older" stage before stabilization.

remote-hg is already stable, this patch has nothing to do with
stabilization, neither do any of the 47 patches I sent to the list.

> And that is to be expected for a contrib/ material; nothing for us
> to be ashamed of.  So I changed my mind.  As long as it is clearly
> marked as "still experimental, possibly with rough edges", I think
> it is better to ship 1.8.3 with these 8 patches than without.
>
> I am unhappy with 3/10, though.  It is spreading existing mistake by
> adding another configuration variable with dash in its name, which
> goes against the recommended practice, and making it more cumbersome
> to eventually fix them, because we would need to break end user's
> configuration.

It's not adding any configuration; remote-hg.track-branches is already
present, even in v1.8.2.

> Things like 1/10 and 2/10 that can be characterized as:
>
>> This is a trivial cleanup, cannot cause regressions.
>
> may probably be a good clean-up to build the next development cycle
> on top, but are not at all urgent for it to deserve to be included
> in the upcoming release.  But it seems that 3-8 textually depend on
> at least 2, so I'll queue the first eight for 1.8.3 and exclude the
> rest for now.  If these are identical to the early part of the
> 47-patch series (I didn't check; they are for the next cycle), it
> would make the next cycle shorter by 8 patches.

Indeed, they are exactly the same as the first 10 patches of the
47-patch series.

I think this makes sense.

-- 
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: [PATCH] remote-bzr: update old organization

[Junio C Hamano]

Junio C Hamano  writes:

> Felipe Contreras  writes:
>
>> And the clone would happen either way, with or without this patch,
>> because 'hg/origin/master' doesn't exist, the only purpose 'hg/origin'
>> serves is to block the new feature.
>
> That is the answer I was trying to extract out of you (I take the hg
> is a typo for bzr in the above, though).

Just to double check, I understand that the justification for
removal is this:

 If a clone exists with the old organization (v1.8.2) it will prevent the
 new shared repository organization from working, so let's remove this
-repository, which is not used any more.
+repository. It is not used by 1.8.3, and did not host any useful
+information in the code in 1.8.2.


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

Fwd: git cvsimport implications

[Eugene Sajine]

Hi,

We are using git cvsimport heavily but mostly the projects are not
using branches that much. We are also migrating our repos only once,
so there is  no commits to CVS repo and no incremental imports allowed
after the migration. we have migrated more than a thousand projects
already.

we use the simplest way (from the CVS checkout folder)

$ git cvsimport -C /path/to/new/git/repo

Just recently it was brought to my attention that we can have problems
with that tool. So my question is if anybody could advise which
scenarios are safe to use this tool for, and what is not recommended?

What if there are a lot of branches in the CVS repo? Is it guaranteed
to be broken after import?

Do i understand correctly that it might put some files into a branch,
that were not originally in this branch in CVS? In which cases it
might happen (i'm sorry i didn't quite get the "issues" in the man
pages for cvsimport)?

Thanks,
Eugene
--
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] remote-bzr: update old organization

[Junio C Hamano]

Felipe Contreras  writes:

> And the clone would happen either way, with or without this patch,
> because 'hg/origin/master' doesn't exist, the only purpose 'hg/origin'
> serves is to block the new feature.

That is the answer I was trying to extract out of you (I take the hg
is a typo for bzr in the above, though).
--
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 v3 08/10] remote-hg: update bookmarks when pulling

[Junio C Hamano]

Felipe Contreras  writes:

> Without this fix, the user would never ever see new bookmarks, only the ones
> that (s)he initially cloned.

Now, think again and realize how long it took you (the original
author) to discover issues and come up with these fixes and
explanation since the series was merged before -rc0.

Are we giving the users enough time to discover and complain issues
that these 10 patches may introduce before the final release?  "You
can see these patches are so trivially correct" is not a valid
argument. The original patches would also have been looked correct
when they were sent to the list. Things take time and actual use by
the users to mature.

Having said that, the impression I am getting is that whatever we
pushed out in 1.8.2 and 1.8.3-rc0 was far from ready for real use,
and with your explanations (by the way, I found that many of them
deserve to be in the log message), the end result of applying these
patches, up to 8/10, will still not be as it is very likely that you
and users will discover issues at a similar rate, but at least it
will be much closer to be ready than they currently are.

In other words, it still seems to be in "something is better than
nothing, newer is better than older" stage before stabilization.

And that is to be expected for a contrib/ material; nothing for us
to be ashamed of.  So I changed my mind.  As long as it is clearly
marked as "still experimental, possibly with rough edges", I think
it is better to ship 1.8.3 with these 8 patches than without.

I am unhappy with 3/10, though.  It is spreading existing mistake by
adding another configuration variable with dash in its name, which
goes against the recommended practice, and making it more cumbersome
to eventually fix them, because we would need to break end user's
configuration.

Things like 1/10 and 2/10 that can be characterized as:

> This is a trivial cleanup, cannot cause regressions.

may probably be a good clean-up to build the next development cycle
on top, but are not at all urgent for it to deserve to be included
in the upcoming release.  But it seems that 3-8 textually depend on
at least 2, so I'll queue the first eight for 1.8.3 and exclude the
rest for now.  If these are identical to the early part of the
47-patch series (I didn't check; they are for the next cycle), it
would make the next cycle shorter by 8 patches.

--
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 v3 09/10] remote-hg: test: be a little more quiet

[Felipe Contreras]

On Tue, May 14, 2013 at 4:40 PM, Junio C Hamano  wrote:
> Felipe Contreras  writes:
>
>> No-brainer; improve one test.
>
> In general, unless we are taking the output from commands to a file
> and grepping in it, we prefer not to have --quiet (unless you are
> testing the --quiet feature of the command, of course).  Running the
> tests without "-v" option will not show them and when running with
> "-v" to debug the tests, the extra output will help to figure out
> which step failed.

Yeah, but I spent a long time looking at the output of these tests and
grew tired of all the irrelevant noise. In fact, I'm even tempted to
set push.default because of that annoying message all over them. Maybe
the --quiet for the push shouldn't be there, but the --quiet for
checkout definitely. Either way, I don't see much value in changing
this patch at this point.

-- 
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: [PATCH v3 09/10] remote-hg: test: be a little more quiet

[Junio C Hamano]

Felipe Contreras  writes:

> No-brainer; improve one test.

In general, unless we are taking the output from commands to a file
and grepping in it, we prefer not to have --quiet (unless you are
testing the --quiet feature of the command, of course).  Running the
tests without "-v" option will not show them and when running with
"-v" to debug the tests, the extra output will help to figure out
which step failed.

> Felipe Contreras wrote:
>> Signed-off-by: Felipe Contreras 
>> ---
>>  contrib/remote-helpers/test-hg.sh | 4 ++--
>>  1 file changed, 2 insertions(+), 2 deletions(-)
>> 
>> diff --git a/contrib/remote-helpers/test-hg.sh 
>> b/contrib/remote-helpers/test-hg.sh
>> index 8de2aa7..f8d1f9e 100755
>> --- a/contrib/remote-helpers/test-hg.sh
>> +++ b/contrib/remote-helpers/test-hg.sh
>> @@ -109,10 +109,10 @@ test_expect_success 'update bookmark' '
>>(
>>git clone "hg::$PWD/hgrepo" gitrepo &&
>>cd gitrepo &&
>> -  git checkout devel &&
>> +  git checkout --quiet devel &&
>>echo devel > content &&
>>git commit -a -m devel &&
>> -  git push
>> +  git push --quiet
>>) &&
>>  
>>hg -R hgrepo bookmarks | egrep "devel[ ]+3:"
>> -- 
>> 1.8.3.rc1.579.g184e698
--
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] remote-bzr: update old organization

[Felipe Contreras]

On Tue, May 14, 2013 at 4:18 PM, Junio C Hamano  wrote:
> Felipe Contreras  writes:
>
>> I forgot to mention the main objective of the shared repo feature:
>>
>> + first/
>> * first/second/foo
>> * first/third/foo
>> * first/fourth/foo
>> * first/fifth/foo
>> * first/sixth/foo
>>
>> Since in bazaar branches are repositories, we want to make it possible
>> for remote-bzr users to create a single remote per branch as easily as
>> possible (without having to duplicate huge clones).
>>
>> But as I said, without this patch, they wouldn't be able to use that
>> feature if they cloned with v1.8.2.
>
> So we nuke that and have them clone from scratch?  I am not saying
> that is bad.  I just want us to be honest about the implications
> when including it in the ReleaseNotes.

The user won't have to do a thing, it happens behind the curtain.

And the clone would happen either way, with or without this patch,
because 'hg/origin/master' doesn't exist, the only purpose 'hg/origin'
serves is to block the new feature.

-- 
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: [PATCH] remote-bzr: update old organization

[Junio C Hamano]

Felipe Contreras  writes:

> I forgot to mention the main objective of the shared repo feature:
>
> + first/
> * first/second/foo
> * first/third/foo
> * first/fourth/foo
> * first/fifth/foo
> * first/sixth/foo
>
> Since in bazaar branches are repositories, we want to make it possible
> for remote-bzr users to create a single remote per branch as easily as
> possible (without having to duplicate huge clones).
>
> But as I said, without this patch, they wouldn't be able to use that
> feature if they cloned with v1.8.2.

So we nuke that and have them clone from scratch?  I am not saying
that is bad.  I just want us to be honest about the implications
when including it in the ReleaseNotes.
--
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] diffcore-pickaxe doc: document -S and -G properly

[Phil Hord]

On Tue, May 14, 2013 at 2:57 PM, Ramkumar Ramachandra
 wrote:
> Junio C Hamano wrote:
>> I do not use zsh but with bash+readline the old tradition lnext can
>> be used (see "stty -a" output and it typically is set to ^V), i.e.
>> \C-v followed by \C-i should give you a literal HT.
>
> Just looked it up: zsh has quoted-insert (^V) after which I can TAB.
> Still doesn't solve my problem though: I don't type out structs; I
> paste them the X clipboard (Emacs).  And that doesn't work either on
> bash or zsh.
>
> What can we do to improve the interface?

Don't use tabs in your code?

P
--
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 16/47] remote-hg: load all extensions

[Eric Sunshine]

On Tue, May 14, 2013 at 12:36 AM, Felipe Contreras
 wrote:
> The user might have then configured differently, plus, all of them will

Did you mean s/then/them/ ?

> be loaded anyway later on.
>
> Signed-off-by: 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: [PATCH 33/47] remote-hg: add test for new bookmark special

[Eric Sunshine]

On Tue, May 14, 2013 at 12:36 AM, Felipe Contreras
 wrote:
> From the point of view of Mercurial, this creates a new branch head, and
> requires a forced push.
>
> Ideally, whoever, we would want it to work just like in git; new

Did you mean s/whoever/however/ ?

> branches can be pushed without problems.
>
> Signed-off-by: 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: [PATCH] remote-bzr: update old organization

[Felipe Contreras]

On Tue, May 14, 2013 at 3:50 PM, Felipe Contreras
 wrote:
> On Tue, May 14, 2013 at 3:36 PM, Junio C Hamano  wrote:
>> Felipe Contreras  writes:
>>
>>> On Tue, May 14, 2013 at 12:30 PM, Junio C Hamano  wrote:
 Felipe Contreras  writes:

> If a clone exists with the old organization (v1.8.2) it will prevent the
> new shared repository organization from working, so let's remove this
> repository, which is not used any more.
>
> Signed-off-by: Felipe Contreras 
> ---

 What happens with and without this patch to an existing user from
 1.8.2 days, when she does what?
>>>
>>> I already explained it would prevent the new shared repository
>>> organization from working, so the old organization would be used; the
>>> repositories won't be shared.
>>>
 A sample answer (to show the level of descriptiveness, not the
 content, I am epecting) might go something like "Because the
 organization is different, it will barf whenever she tries to
 incrementally update from the other side. By removing the old one
 1.8.3 contrib/ does not understand, at least we can unstuck her; she
 ends up reimporting the whole history, though."
>>>
>>> Bazaar won't barf, the repositories will be duplicated, so the shared
>>> feature won't work.
>>
>> But by removing the old incarnation, you are getting rid of the copy
>> for which the shared feature will not work, so with patch, "won't
>> work" is no longer an issue.  Is the user making a trade-off by
>> using Git with this patch?  What is she losing by removal, if
>> anything?
>
> No. The way repositories work in bazaar is tricky:
>
> Suppose you have a directory like this:
>
> +* first/second/foo
> +* first/second/bar
>
> Both the branch and the repository are on the same directory (hence
> +*). We have two branches, and two independent repositories.
>
> And then you have a shared repo:
>
> + first/
> * first/second/foo
> * first/second/bar
>
> Now we have a single repository shared between two branches.
>
> But:
>
> + first/
> +* first/second
> +* first/second/foo
> +* first/second/bar
>
> If there's another repository in-between, neither 'foo' nor 'bar' can
> reach 'first', so they are stuck with the repository in 'second',
> which is not a shared repository, so they must create their own
> repositories, but even if they could use 'second', there still would
> be a problem:
>
> + first/
> +* first/second
> +* first/second/foo
> +* first/second/bar
> +* first/third
> +* first/third/foo
> +* first/third/bar
>
> We want 'second' and 'third' to share to object tree, but we can't.
>
> This patch would remove the old repository ('second' and 'third') so
> we have exactly what we want:
>
> + first/
> * first/second/foo
> * first/second/bar
> * first/third/foo
> * first/third/bar
>
> A single bzr repository shared by all the branches and all the repos.
>
> In reality it probably wouldn't be a big deal, because in v1.8.2 users
> couldn't clone true bzr repos, but there are some bazaar repos with a
> single branch they could clone, and there would be a single duplicated
> repo, like this:
>
> + first/
> +* first/second/foo
> +* first/third/foo

I forgot to mention the main objective of the shared repo feature:

+ first/
* first/second/foo
* first/third/foo
* first/fourth/foo
* first/fifth/foo
* first/sixth/foo

Since in bazaar branches are repositories, we want to make it possible
for remote-bzr users to create a single remote per branch as easily as
possible (without having to duplicate huge clones).

But as I said, without this patch, they wouldn't be able to use that
feature if they cloned with v1.8.2.

-- 
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: [PATCH] remote-bzr: update old organization

[Felipe Contreras]

On Tue, May 14, 2013 at 3:36 PM, Junio C Hamano  wrote:
> Felipe Contreras  writes:
>
>> On Tue, May 14, 2013 at 12:30 PM, Junio C Hamano  wrote:
>>> Felipe Contreras  writes:
>>>
 If a clone exists with the old organization (v1.8.2) it will prevent the
 new shared repository organization from working, so let's remove this
 repository, which is not used any more.

 Signed-off-by: Felipe Contreras 
 ---
>>>
>>> What happens with and without this patch to an existing user from
>>> 1.8.2 days, when she does what?
>>
>> I already explained it would prevent the new shared repository
>> organization from working, so the old organization would be used; the
>> repositories won't be shared.
>>
>>> A sample answer (to show the level of descriptiveness, not the
>>> content, I am epecting) might go something like "Because the
>>> organization is different, it will barf whenever she tries to
>>> incrementally update from the other side. By removing the old one
>>> 1.8.3 contrib/ does not understand, at least we can unstuck her; she
>>> ends up reimporting the whole history, though."
>>
>> Bazaar won't barf, the repositories will be duplicated, so the shared
>> feature won't work.
>
> But by removing the old incarnation, you are getting rid of the copy
> for which the shared feature will not work, so with patch, "won't
> work" is no longer an issue.  Is the user making a trade-off by
> using Git with this patch?  What is she losing by removal, if
> anything?

No. The way repositories work in bazaar is tricky:

Suppose you have a directory like this:

+* first/second/foo
+* first/second/bar

Both the branch and the repository are on the same directory (hence
+*). We have two branches, and two independent repositories.

And then you have a shared repo:

+ first/
* first/second/foo
* first/second/bar

Now we have a single repository shared between two branches.

But:

+ first/
+* first/second
+* first/second/foo
+* first/second/bar

If there's another repository in-between, neither 'foo' nor 'bar' can
reach 'first', so they are stuck with the repository in 'second',
which is not a shared repository, so they must create their own
repositories, but even if they could use 'second', there still would
be a problem:

+ first/
+* first/second
+* first/second/foo
+* first/second/bar
+* first/third
+* first/third/foo
+* first/third/bar

We want 'second' and 'third' to share to object tree, but we can't.

This patch would remove the old repository ('second' and 'third') so
we have exactly what we want:

+ first/
* first/second/foo
* first/second/bar
* first/third/foo
* first/third/bar

A single bzr repository shared by all the branches and all the repos.

In reality it probably wouldn't be a big deal, because in v1.8.2 users
couldn't clone true bzr repos, but there are some bazaar repos with a
single branch they could clone, and there would be a single duplicated
repo, like this:

+ first/
+* first/second/foo
+* first/third/foo

-- 
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: [PATCH] remote-bzr: update old organization

[Junio C Hamano]

Felipe Contreras  writes:

> On Tue, May 14, 2013 at 12:30 PM, Junio C Hamano  wrote:
>> Felipe Contreras  writes:
>>
>>> If a clone exists with the old organization (v1.8.2) it will prevent the
>>> new shared repository organization from working, so let's remove this
>>> repository, which is not used any more.
>>>
>>> Signed-off-by: Felipe Contreras 
>>> ---
>>
>> What happens with and without this patch to an existing user from
>> 1.8.2 days, when she does what?
>
> I already explained it would prevent the new shared repository
> organization from working, so the old organization would be used; the
> repositories won't be shared.
>
>> A sample answer (to show the level of descriptiveness, not the
>> content, I am epecting) might go something like "Because the
>> organization is different, it will barf whenever she tries to
>> incrementally update from the other side. By removing the old one
>> 1.8.3 contrib/ does not understand, at least we can unstuck her; she
>> ends up reimporting the whole history, though."
>
> Bazaar won't barf, the repositories will be duplicated, so the shared
> feature won't work.

But by removing the old incarnation, you are getting rid of the copy
for which the shared feature will not work, so with patch, "won't
work" is no longer an issue.  Is the user making a trade-off by
using Git with this patch?  What is she losing by removal, if
anything?
--
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 v3 10/10] remote-hg: trivial reorganization

[Felipe Contreras]

Another no-brainer; simply shuffling some code.

Felipe Contreras wrote:
> We only need to get the remote dict once.
> 
> Signed-off-by: Felipe Contreras 
> ---
>  contrib/remote-helpers/git-remote-hg | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/contrib/remote-helpers/git-remote-hg 
> b/contrib/remote-helpers/git-remote-hg
> index dc276af..96bed8d 100755
> --- a/contrib/remote-helpers/git-remote-hg
> +++ b/contrib/remote-helpers/git-remote-hg
> @@ -860,6 +860,7 @@ def do_export(parser):
>  
>  if peer:
>  parser.repo.push(peer, force=force_push, newbranch=True)
> +remote_bmarks = peer.listkeys('bookmarks')
>  
>  # handle bookmarks
>  for bmark, node in p_bmarks:
> @@ -886,8 +887,7 @@ def do_export(parser):
>  continue
>  
>  if peer:
> -rb = peer.listkeys('bookmarks')
> -old = rb.get(bmark, '')
> +old = remote_bmarks.get(bmark, '')
>  if not peer.pushkey('bookmarks', bmark, old, new):
>  print "error %s" % ref
>  continue
> -- 
> 1.8.3.rc1.579.g184e698

-- 
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: [PATCH v3 09/10] remote-hg: test: be a little more quiet

[Felipe Contreras]

No-brainer; improve one test.

Felipe Contreras wrote:
> Signed-off-by: Felipe Contreras 
> ---
>  contrib/remote-helpers/test-hg.sh | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/contrib/remote-helpers/test-hg.sh 
> b/contrib/remote-helpers/test-hg.sh
> index 8de2aa7..f8d1f9e 100755
> --- a/contrib/remote-helpers/test-hg.sh
> +++ b/contrib/remote-helpers/test-hg.sh
> @@ -109,10 +109,10 @@ test_expect_success 'update bookmark' '
>(
>git clone "hg::$PWD/hgrepo" gitrepo &&
>cd gitrepo &&
> -  git checkout devel &&
> +  git checkout --quiet devel &&
>echo devel > content &&
>git commit -a -m devel &&
> -  git push
> +  git push --quiet
>) &&
>  
>hg -R hgrepo bookmarks | egrep "devel[  ]+3:"
> -- 
> 1.8.3.rc1.579.g184e698



-- 
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: [PATCH v3 08/10] remote-hg: update bookmarks when pulling

[Felipe Contreras]

Without this fix, the user would never ever see new bookmarks, only the ones
that (s)he initially cloned.

Felipe Contreras wrote:
> Signed-off-by: Felipe Contreras 
> ---
>  contrib/remote-helpers/git-remote-hg | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/contrib/remote-helpers/git-remote-hg 
> b/contrib/remote-helpers/git-remote-hg
> index beb864b..dc276af 100755
> --- a/contrib/remote-helpers/git-remote-hg
> +++ b/contrib/remote-helpers/git-remote-hg
> @@ -363,6 +363,9 @@ def get_repo(url, alias):
>  die('Repository error')
>  repo.pull(peer, heads=None, force=True)
>  
> +rb = peer.listkeys('bookmarks')
> +bookmarks.updatefromremote(myui, repo, rb, url)
> +
>  return repo
>  
>  def rev_to_mark(rev):
> -- 
> 1.8.3.rc1.579.g184e698



-- 
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: [PATCH v3 07/10] remote-hg: don't push fake 'master' bookmark

[Felipe Contreras]

We obviously don't want to push our fake 'master' bookmark to the remote. This
is an obvious good change.

Felipe Contreras wrote:
> We skip it locally, but not for the remote, so let's do so.
> 
> Signed-off-by: Felipe Contreras 
> ---
>  contrib/remote-helpers/git-remote-hg | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/contrib/remote-helpers/git-remote-hg 
> b/contrib/remote-helpers/git-remote-hg
> index 53412dd..beb864b 100755
> --- a/contrib/remote-helpers/git-remote-hg
> +++ b/contrib/remote-helpers/git-remote-hg
> @@ -873,7 +873,8 @@ def do_export(parser):
>  
>  if bmark == 'master' and 'master' not in parser.repo._bookmarks:
>  # fake bookmark
> -pass
> +print "ok %s" % ref
> +continue
>  elif bookmarks.pushbookmark(parser.repo, bmark, old, new):
>  # updated locally
>  pass
> -- 
> 1.8.3.rc1.579.g184e698

-- 
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: [PATCH v3 06/10] remote-hg: disable forced push by default

[Felipe Contreras]

And here is the important fix. We are essentially reverting back to the old
v1.8.2 behavior, to minimize the possibility of regressions, but in a way the
user can configure.

The cleanups before made it so this patch eas easy and simple.

And the fix before this makes it so the new default force_push=False still is
able to push new branches, so we don't disable other v1.8.3 features.

Felipe Contreras wrote:
> In certain situations we might end up pushing garbage revisions (e.g. in
> a rebase), and the patches to deal with that haven't been merged yet.
> 
> So let's disable forced pushes by default.
> 
> Signed-off-by: Felipe Contreras 
> ---
>  contrib/remote-helpers/git-remote-hg | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/contrib/remote-helpers/git-remote-hg 
> b/contrib/remote-helpers/git-remote-hg
> index 3cf9b4c..53412dd 100755
> --- a/contrib/remote-helpers/git-remote-hg
> +++ b/contrib/remote-helpers/git-remote-hg
> @@ -914,7 +914,7 @@ def main(args):
>  
>  hg_git_compat = get_config_bool('remote-hg.hg-git-compat')
>  track_branches = get_config_bool('remote-hg.track-branches', True)
> -force_push = get_config_bool('remote-hg.force-push', True)
> +force_push = get_config_bool('remote-hg.force-push')
>  
>  if hg_git_compat:
>  mode = 'hg'
> -- 
> 1.8.3.rc1.579.g184e698



-- 
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: [PATCH v3 05/10] remote-hg: fix new branch creation

[Felipe Contreras]

This is the first fix, but it's obvious this is what we want: if a user creates
a new branch with git:

 % git checkout -b branches/devel

And then pushes this branch

 % git push origin branches/devel

(which is the way to push new mercurial branches)

We obviously want to create a branch, but the command would fail, and the fix
is simple: tell the push that we might create new branches.

This only matters when foce_push=False.

Can't possibly introduce regressions, unless you think of the ability to push
new branches as a regression.

Felipe Contreras wrote:
> When force_push is disabled, we need to turn the argument to True.
> 
> Signed-off-by: Felipe Contreras 
> ---
>  contrib/remote-helpers/git-remote-hg | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/contrib/remote-helpers/git-remote-hg 
> b/contrib/remote-helpers/git-remote-hg
> index 4a5c72f..3cf9b4c 100755
> --- a/contrib/remote-helpers/git-remote-hg
> +++ b/contrib/remote-helpers/git-remote-hg
> @@ -856,7 +856,7 @@ def do_export(parser):
>  continue
>  
>  if peer:
> -parser.repo.push(peer, force=force_push)
> +parser.repo.push(peer, force=force_push, newbranch=True)
>  
>  # handle bookmarks
>  for bmark, node in p_bmarks:
> -- 
> 1.8.3.rc1.579.g184e698



-- 
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: [PATCH v3 04/10] remote-hg: add new get_config_bool() helper

[Felipe Contreras]

This is simply refactoring code, functionally they are the same.

Felipe Contreras wrote:
> No functional changes.
> 
> Signed-off-by: Felipe Contreras 
> ---
>  contrib/remote-helpers/git-remote-hg | 24 +---
>  1 file changed, 13 insertions(+), 11 deletions(-)
> 
> diff --git a/contrib/remote-helpers/git-remote-hg 
> b/contrib/remote-helpers/git-remote-hg
> index de3a96e..4a5c72f 100755
> --- a/contrib/remote-helpers/git-remote-hg
> +++ b/contrib/remote-helpers/git-remote-hg
> @@ -87,6 +87,15 @@ def get_config(config):
>  output, _ = process.communicate()
>  return output
>  
> +def get_config_bool(config, default=False):
> +value = get_config(config).rstrip('\n')
> +if value == "true":
> +return True
> +elif value == "false":
> +return False
> +else:
> +return default
> +
>  class Marks:
>  
>  def __init__(self, path):
> @@ -327,7 +336,7 @@ def get_repo(url, alias):
>  myui.setconfig('ui', 'interactive', 'off')
>  myui.fout = sys.stderr
>  
> -if get_config('remote-hg.insecure') == 'true\n':
> +if get_config_bool('remote-hg.insecure'):
>  myui.setconfig('web', 'cacerts', '')
>  
>  try:
> @@ -903,16 +912,9 @@ def main(args):
>  url = args[2]
>  peer = None
>  
> -hg_git_compat = False
> -track_branches = True
> -force_push = True
> -
> -if get_config('remote-hg.hg-git-compat') == 'true\n':
> -hg_git_compat = True
> -if get_config('remote-hg.track-branches') == 'false\n':
> -track_branches = False
> -if get_config('remote-hg.force-push') == 'false\n':
> -force_push = False
> +hg_git_compat = get_config_bool('remote-hg.hg-git-compat')
> +track_branches = get_config_bool('remote-hg.track-branches', True)
> +force_push = get_config_bool('remote-hg.force-push', True)
>  
>  if hg_git_compat:
>  mode = 'hg'
> -- 
> 1.8.3.rc1.579.g184e698



-- 
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: [PATCH v3 03/10] remote-hg: enable track-branches in hg-git mode

[Felipe Contreras]

No regression here either, we simply give more power to the user.

Felipe Contreras wrote:
> The user can turn this off.
> 
> Signed-off-by: Felipe Contreras 
> ---
>  contrib/remote-helpers/git-remote-hg | 1 -
>  contrib/remote-helpers/test-hg-hg-git.sh | 1 +
>  2 files changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/contrib/remote-helpers/git-remote-hg 
> b/contrib/remote-helpers/git-remote-hg
> index 9d6940b..de3a96e 100755
> --- a/contrib/remote-helpers/git-remote-hg
> +++ b/contrib/remote-helpers/git-remote-hg
> @@ -909,7 +909,6 @@ def main(args):
>  
>  if get_config('remote-hg.hg-git-compat') == 'true\n':
>  hg_git_compat = True
> -track_branches = False
>  if get_config('remote-hg.track-branches') == 'false\n':
>  track_branches = False
>  if get_config('remote-hg.force-push') == 'false\n':
> diff --git a/contrib/remote-helpers/test-hg-hg-git.sh 
> b/contrib/remote-helpers/test-hg-hg-git.sh
> index 0c36573..7f579c8 100755
> --- a/contrib/remote-helpers/test-hg-hg-git.sh
> +++ b/contrib/remote-helpers/test-hg-hg-git.sh
> @@ -102,6 +102,7 @@ setup () {
>   ) >> "$HOME"/.hgrc &&
>   git config --global receive.denycurrentbranch warn
>   git config --global remote-hg.hg-git-compat true
> + git config --global remote-hg.track-branches false
>  
>   HGEDITOR=/usr/bin/true
>  
> -- 
> 1.8.3.rc1.579.g184e698

-- 
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: [PATCH v3 02/10] remote-hg: get rid of unused exception checks

[Felipe Contreras]

This is removing an exception check and since that exception is thrown by
check_output() but not Popen(), this doesn't change anything.

Felipe Contreras wrote:
> We are not calling check_output() anymore.
> 
> Signed-off-by: Felipe Contreras 
> ---
>  contrib/remote-helpers/git-remote-hg | 24 +---
>  1 file changed, 9 insertions(+), 15 deletions(-)
> 
> diff --git a/contrib/remote-helpers/git-remote-hg 
> b/contrib/remote-helpers/git-remote-hg
> index d33c7ba..9d6940b 100755
> --- a/contrib/remote-helpers/git-remote-hg
> +++ b/contrib/remote-helpers/git-remote-hg
> @@ -327,11 +327,8 @@ def get_repo(url, alias):
>  myui.setconfig('ui', 'interactive', 'off')
>  myui.fout = sys.stderr
>  
> -try:
> -if get_config('remote-hg.insecure') == 'true\n':
> -myui.setconfig('web', 'cacerts', '')
> -except subprocess.CalledProcessError:
> -pass
> +if get_config('remote-hg.insecure') == 'true\n':
> +myui.setconfig('web', 'cacerts', '')
>  
>  try:
>  mod = extensions.load(myui, 'hgext.schemes', None)
> @@ -910,16 +907,13 @@ def main(args):
>  track_branches = True
>  force_push = True
>  
> -try:
> -if get_config('remote-hg.hg-git-compat') == 'true\n':
> -hg_git_compat = True
> -track_branches = False
> -if get_config('remote-hg.track-branches') == 'false\n':
> -track_branches = False
> -if get_config('remote-hg.force-push') == 'false\n':
> -force_push = False
> -except subprocess.CalledProcessError:
> -pass
> +if get_config('remote-hg.hg-git-compat') == 'true\n':
> +hg_git_compat = True
> +track_branches = False
> +if get_config('remote-hg.track-branches') == 'false\n':
> +track_branches = False
> +if get_config('remote-hg.force-push') == 'false\n':
> +force_push = False
>  
>  if hg_git_compat:
>  mode = 'hg'
> -- 
> 1.8.3.rc1.579.g184e698

-- 
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: [PATCH v3 01/10] remote-hg: trivial cleanups

[Felipe Contreras]

This is a trivial cleanup, cannot cause regressions.

Felipe Contreras wrote:
> Signed-off-by: Felipe Contreras 
> ---
>  contrib/remote-helpers/git-remote-hg | 2 +-
>  contrib/remote-helpers/test-hg-hg-git.sh | 2 --
>  2 files changed, 1 insertion(+), 3 deletions(-)
> 
> diff --git a/contrib/remote-helpers/git-remote-hg 
> b/contrib/remote-helpers/git-remote-hg
> index 96ad30d..d33c7ba 100755
> --- a/contrib/remote-helpers/git-remote-hg
> +++ b/contrib/remote-helpers/git-remote-hg
> @@ -538,7 +538,7 @@ def list_head(repo, cur):
>  g_head = (head, node)
>  
>  def do_list(parser):
> -global branches, bmarks, mode, track_branches
> +global branches, bmarks, track_branches
>  
>  repo = parser.repo
>  for bmark, node in bookmarks.listbookmarks(repo).iteritems():
> diff --git a/contrib/remote-helpers/test-hg-hg-git.sh 
> b/contrib/remote-helpers/test-hg-hg-git.sh
> index 8440341..0c36573 100755
> --- a/contrib/remote-helpers/test-hg-hg-git.sh
> +++ b/contrib/remote-helpers/test-hg-hg-git.sh
> @@ -455,8 +455,6 @@ test_expect_success 'hg author' '
>   git_log gitrepo-$x > git-log-$x
>   done &&
>  
> - test_cmp git-log-hg git-log-git &&
> -
>   test_cmp hg-log-hg hg-log-git &&
>   test_cmp git-log-hg git-log-git
>  '
> -- 
> 1.8.3.rc1.579.g184e698



-- 
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: [PATCH v3 00/10] remote-hg: fixes and cleanups

[Felipe Contreras]

On Tue, May 14, 2013 at 1:59 PM, Junio C Hamano  wrote:
> Felipe Contreras  writes:
>
>> On Mon, May 13, 2013 at 8:08 PM, Junio C Hamano  wrote:
>>
>>> Folks interested in working remote-hg, please try it out, so that we
>>> can have a polished one soon after 1.8.3 ships (I am not saying this
>>> round is not polished---I haven't even looked at the patches).
>>>
>>> And others, please spend time on testing the 1.8.3-rc2 to make sure
>>> what we are going to ship is free of embarrassing regressions.
>>
>> If we want folks to test something, it should be the patches I
>> prepared for 'next' which I just sent.
>
> Yeah, but that is for the release _after_ 1.8.3; I'd rather see
> folks help to make sure we have a solid 1.8.3 relaese.

That's the intention of the ten patches I sent for 1.8.3. But you said
you are not going to put them in 'master', but in 'next', so I sent
the ones I think should go into next.

So now you have the patches that I think should go into 'master' (10),
and the ones for 'next' (47, including the previous unmerged 10).

-- 
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: [PATCH] remote-bzr: update old organization

[Felipe Contreras]

On Tue, May 14, 2013 at 12:30 PM, Junio C Hamano  wrote:
> Felipe Contreras  writes:
>
>> If a clone exists with the old organization (v1.8.2) it will prevent the
>> new shared repository organization from working, so let's remove this
>> repository, which is not used any more.
>>
>> Signed-off-by: Felipe Contreras 
>> ---
>
> What happens with and without this patch to an existing user from
> 1.8.2 days, when she does what?

I already explained it would prevent the new shared repository
organization from working, so the old organization would be used; the
repositories won't be shared.

> A sample answer (to show the level of descriptiveness, not the
> content, I am epecting) might go something like "Because the
> organization is different, it will barf whenever she tries to
> incrementally update from the other side. By removing the old one
> 1.8.3 contrib/ does not understand, at least we can unstuck her; she
> ends up reimporting the whole history, though."

Bazaar won't barf, the repositories will be duplicated, so the shared
feature won'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: [PATCH] diffcore-pickaxe doc: document -S and -G properly

[Ramkumar Ramachandra]

Junio C Hamano wrote:
> When a commit moves a file wholesale without affecting the block of
> code you are interested in, you know that whole block came from the
> file in the old tree at pre-rename location without looking at
> anywhere else.  That is why renamed but pickaxe-uninteresting
> filepairs are dropped.
>
> When a commit moves (some lines of) the block of code you are
> interested in from one file to another, it may have been a single
> instance moving to another place, but it may well have been multiple
> copies consolidated into one (the new copy, pickaxe digging from
> future to past may see "disappearing").  That is a significant event
> worth digging into further by first stopping there and then
> inspecting the whole change with --pickaxe-all to see what changes
> that are similar to the change in question exist in the other parts
> (notice the multiple) of the tree.

Makes sense.  I wasn't looking at it from a macro perspective.

Yeah, I constantly re-read 217 and your follow-up.
--
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 v3 00/10] remote-hg: fixes and cleanups

[Felipe Contreras]

On Tue, May 14, 2013 at 1:21 PM, Junio C Hamano  wrote:
> Felipe Contreras  writes:
>
>> On Mon, May 13, 2013 at 8:08 PM, Junio C Hamano  wrote:
>>> And others, please spend time on testing the 1.8.3-rc2 to make sure
>>> what we are going to ship is free of embarrassing regressions.
>>
>> The whole purpose of this series is to avoid regressions, that's why I
>> sent them for 1.8.3.
>
> We agreed to make an exception to let remote-bzr updates go in even
> after v1.8.3-rc1, because it is too young and you can afford to
> check that the updated code will give only gains to its userbase
> that matters without hurting them by checking with Emacs and other
> projects.
>
> I do not recall us doing a similar exception for remote-hg.  Did we?

The exception was for massive changes, theses are not massive changes,
they are no-brainer fixes that would possibly fix regressions.

> If we didn't, then a 10-patch series at this point in the cycle is
> way too late for me to be comfortable taking.

Well, don't blame me if users hit regressions then.

> We merged the 21-patch remote-hg series from you on Apr 21st, a week
> before -rc0, and it has been 3 weeks.  Back then you thought it made
> things better without regression, and I expected that loose ends
> could be fixed by -rc1 with enough time to cook them in 'next'
> (meaning tying such loose ends would be just the matter of a couple
> of trivial patches at most).  But now you are saying they regress
> things and need 6 (in 'next') + 10 + 47 patches to fix on top, in
> order not to hurt existing users?
>
> What is going on?

No, I sent *four* patches for 'master', which I eventually increased
to ten, because the increased ones are all simple cleanups.

And the fixes are obvious and can't possibly introduce regressions,
specially since the important change re-introduces the same behavior
we had in v1.8.2.

The 47 patches I sent are for 'next', and are clearly marked as so. I
included the same 10 fixes I sent for 'master', because they never
landed on master.

> People make mistakes and the initial submission being buggy is *not*
> a problem per-se, but what quality assurance do the 10-patch and/or
> the follow up 47-patch series have over these 21 patches to assure
> us that they do not introduce more problems, when we are this close
> to the final, way less than the 3 weeks we had?

Read the patches and you would see.

> The best we could do to avoid regressions (if there are reported
> ones) is to revert specific changes that cause the regression that
> are already in v1.8.3-rc2.  Which one(s) should we be reverting, and
> do you have a regression report that says the commit(s) in question
> breaks things for a specific project, and reverting it(them) makes
> things work again?

I am going to go one by one to show you the patches make sense for 'master'.

-- 
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: [PATCH] diffcore-pickaxe doc: document -S and -G properly

[Junio C Hamano]

Ramkumar Ramachandra  writes:

> What I was trying to say is that it's an accidental feature

There is nothing accidental about it.  It was a very conscious
design decision.

When a commit moves a file wholesale without affecting the block of
code you are interested in, you know that whole block came from the
file in the old tree at pre-rename location without looking at
anywhere else.  That is why renamed but pickaxe-uninteresting
filepairs are dropped.

When a commit moves (some lines of) the block of code you are
interested in from one file to another, it may have been a single
instance moving to another place, but it may well have been multiple
copies consolidated into one (the new copy, pickaxe digging from
future to past may see "disappearing").  That is a significant event
worth digging into further by first stopping there and then
inspecting the whole change with --pickaxe-all to see what changes
that are similar to the change in question exist in the other parts
(notice the multiple) of the tree.

If you do not understand it, then you really should re-read
$gmane/217 and then its explanation I wrote 4 years ago (both of
which I already gave you URLs to in this thread).

--
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: make git ignore the timestamp embedded in PDFs

[Johannes Sixt]

Am 14.05.2013 15:17, schrieb Andreas Leha:
> Hi all,
> 
> how can I make git ignore the time stamp(s) in a PDF.  Two PDFs that
> differ only in these time stamps should be considered identical.
> ...
> What I tried is a filter:
> ,[ ~/.gitconfig ]
> | [filter "pdfresetdate"]
> | clean = pdfresetdate
> `
> 
> This 'works' as far as the committed pdf indeed has the date reset to my
> default value.
> 
> However, when I re-checkout the files, they are marked modified by git.

I'm using cleaned files every now and then, but not on Linux. I have
never observed this behavior recently.

If you 'git add' the file, does it keep its modified state? Does 'git
diff' tell a difference?

-- 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] diffcore-pickaxe doc: document -S and -G properly

[Ramkumar Ramachandra]

Junio C Hamano wrote:
> I think what makes this paragraph unnecessarily hard to read is the
> "While rename works".
>
> With that, you are implying "if you rename a file as a whole without
> changing the block of text you identify with the -S parameter, then
> such a change is not interesting as far as pickaxe is concerned".
> while that statement is logically correct, normal people are not
> that generous to read that much between your lines.

Yes, I'm exactly implying that.  But I don't want to lose meaning: in
the previous sentence, I talk about filepairs.  I want to point out
that rename detection working at the filepair level is a perfectly
normal thing.

> I think that is one of the reasons why "If you moved a string from
> file A to file B, log -S will flag that change as worth inspecting"
> does not seem to logically follow and made Phil find your
> description confusing.

Sure, we can elaborate a bit more.

> Finding such a change indeed is a feature [*1*]; we need to flag
> such a change as worth inspecting to find where the code came from
> in order to dig deeper, so at least this "cannot omit" should be
> "does not omit".

What I was trying to say is that it's an accidental feature: the
reason this "feature" exists is because diffcore is tied to filepairs
(and rename detection works at the filepair level).  You may argue
that there's nothing wrong with this design, but consider what happens
if you rebase on top of a big code move: it's completely broken.  If
git were a true content tracker, and file boundaries really did not
matter, isn't this feature actually a deficiency?

Ofcourse, the user doesn't need to know all this, and "does not omit"
is a good suggestion.
--
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] diffcore-pickaxe doc: document -S and -G properly

[Junio C Hamano]

Jonathan Nieder  writes:

> Ramkumar Ramachandra wrote:
>
>> Should we mention in the -S documentation that temporary shell script
>> is the way to get multi-line input?
>
> No, because for almost everyone it isn't.
>
> An example in the EXAMPLES section including an aside that you might
> have to hit ^V to enter a tab could be useful, though.

Or document it as "for scripter's use", which it 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: Problems with Windows, Was: What's cooking in git.git (May 2013, #01; Fri, 3)

[Torsten Bögershausen]

On 2013-05-09 19.18, Ramsay Jones wrote:
> Torsten Bögershausen wrote:
>> On 2013-05-04 01.14, Junio C Hamano wrote:
>>>
>>>  Cygwin portability; both were reviewed by Jonathan, and the tip one
>>>  seems to want a bit further explanation.  Needs positive report
>>>  from Cygwin 1.7 users who have been on 1.7 to make sure it does not
>>>  regress for them.
>>
>> I was trying to verify that cygwin 1.7 is still Ok, but got puzzled.
>>
>> Running the test suite under cygwin doesn't seem to work any more (?):
>>
>> Scenario 1:
>> The PC is running alone, and goes into the screen saver.
>> Pressing CTRL-ALT-DEL didn't get any effect.
>>
>> Scenario 2:
>> The PC didn't react any more, when the test suite was run in background.
>> In 3 or 4 cases the PC needed to be reboot hardly.
>>
>> Using the commits before and after this change makes the test suite hang 
>> as well at some point, then it hangs somewhere at TC 3000--4000.
>>
>> Scenario 4:
>> The I disabled the screensaver, upgdated cygwin,
>>  and went back to an older commit:
>> The latest run from commit 52d63e70, April 28,
>> hangs in TC 5500, ok 26 clone shallow object count.
>>
>> I can see 2 times 
>> git.exe pull --depth 4 ..A 
>>
>> Scenario 5:
>> The run of today 1.8.3-rc1, hangs in t5510,
>> some git.exe are running fetch. (or pull)
>>
>>
>> It seems as if some process/exes are not terminated
>> in the way it should be.
>>
>> I will try on a different machine,
>> comments are wellcome
> 
> Hmm, I'm a little puzzled, but not shocked. ;-)
> 
> Somebody, I forget who, had already tested Jonathan's patch
> on cygwin 1.7 successfully and my follow up patch should be
> a no-op on cygwin 1.7; so I'm puzzled! (The high risk should
> have been on cygwin 1.5).
> 
> I'm not shocked because running the test-suite on cygwin has
> been a bit of a magical mystery tour for quite some time.
> 
> In about 2007, I could not run the test-suite for about six
> to nine months; it would randomly wedge my laptop solid - I had
> to pull the power-cord out in order to re-boot. (I suspect that
> commit 9cb18f56fde may have cured that particular problem, but
> don't quote me on that - I didn't investigate at the time.)
> 
> I have noticed that running the tests with 'prove' is more likely
> to prove successful, so my config.mak looks like:
> 
> $ cat config.mak
> NO_SVN_TESTS=1
> GIT_TEST_OPTS=--no-color
> NO_GETTEXT=1
> DEFAULT_TEST_TARGET=prove
> GIT_PROVE_OPTS='--timer'
> $
> 
> I currently run the tests like so:
> 
> $ time $(GIT_SKIP_TESTS='t0061.3 t0070.3 t4130 t9010 t9300' make test \
> >test-outp13 2>&1)
> 
> real172m25.311s
> user132m15.133s
> sys 66m43.122s
> $
> 
> The t0061.3 and t0070.3 failures don't require much discussion. The t4130
> failure is an intermittent "racy git" issue that has been on my TODO list
> for several years. t9300 also fails intermittently. However, t9010 fails
> every time for me, hanging the test suite (although ^C interrupts it just
> fine).
> 
> I have a "fix" for t9010 that looks like:
> 
> diff --git a/t/t9010-svn-fe.sh b/t/t9010-svn-fe.sh
> index b7eed24..4d01e3b 100755
> --- a/t/t9010-svn-fe.sh
> +++ b/t/t9010-svn-fe.sh
> @@ -22,10 +22,9 @@ try_dump () {
> maybe_fail_fi=${3:+test_$3} &&
> 
> {
> -   $maybe_fail_svnfe test-svn-fe "$input" >stream 3 &
> -   } &&
> -   $maybe_fail_fi git fast-import --cat-blob-fd=3 backflow 
> &&
> -   wait $!
> +   $maybe_fail_svnfe test-svn-fe "$input" 3 +   } |
> +   $maybe_fail_fi git fast-import --cat-blob-fd=3 3>backflow
>  }
> 
>  properties () {
> 
> but I have not tested this patch enough to be happy to submit it (I have
> some suspicions that it would still fail intermittently, just like t9300).
> 
> Also, commit 7bc0911d ("test-lib: Fix say_color () not to interpret \a\b\c
> in the message", 11-10-2012) caused several random test failures. (don't ask
> me why). So, before each test run, I have to apply the following:
> 
> diff --git a/t/test-lib.sh b/t/test-lib.sh
> index f50f834..ed32b7f 100644
> --- a/t/test-lib.sh
> +++ b/t/test-lib.sh
> @@ -230,7 +230,7 @@ else
> say_color() {
> test -z "$1" && test -n "$quiet" && return
> shift
> -   printf "%s\n" "$*"
> +   echo -E "$*"
> }
>  fi
> 
> which effectively reverts that commit.
> 
> So, as I said, a "magical mystery tour". :-D
> 
> ATB,
> Ramsay Jones
> 
> 
First of all,
the patch we are talking about does not any regrssions at my side.

Second,
I was able to do some testing.
The hanging is not 100% reproducable, and I had one hanging in Git 1.8.1

Turning the screen saver off in Win XP helps that the machine reacts,
and using process explorer showed that the hanging is happening
in test cases doing "git fetch" (or git pull) from 

Re: [PATCH] diffcore-pickaxe doc: document -S and -G properly

[Junio C Hamano]

Ramkumar Ramachandra  writes:

> Junio C Hamano wrote:
>> I do not use zsh but with bash+readline the old tradition lnext can
>> be used (see "stty -a" output and it typically is set to ^V), i.e.
>> \C-v followed by \C-i should give you a literal HT.
>
> Just looked it up: zsh has quoted-insert (^V) after which I can TAB.
> Still doesn't solve my problem though: I don't type out structs; I
> paste them the X clipboard (Emacs).  And that doesn't work either on
> bash or zsh.
>
> What can we do to improve the interface?

Heh, I seem to have just found a volunteer to finish the Linus's
dream by following up on http://gitster.livejournal.com/35628.html
(see section #5; I do not do GUI, neither Linus, so this has been a
four-year old dream).
--
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] diffcore-pickaxe doc: document -S and -G properly

[Jonathan Nieder]

Ramkumar Ramachandra wrote:

> Should we mention in the -S documentation that temporary shell script
> is the way to get multi-line input?

No, because for almost everyone it isn't.

An example in the EXAMPLES section including an aside that you might
have to hit ^V to enter a tab could be useful, though.
--
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] diffcore-pickaxe doc: document -S and -G properly

[Ramkumar Ramachandra]

Jonathan Nieder wrote:
> Write a better shell?

Shell, editor.  Both are very hard problems, and the successful
projects last many years (emacs, zsh are over 20 years old).

> Teach "git gui blame" to blame on arbitrary
> regions instead of single lines?

Or in my case: get magit to do log -S.

Should we mention in the -S documentation that temporary shell script
is the way to get multi-line input?
--
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] diffcore-pickaxe doc: document -S and -G properly

[Phil Hord]

On Tue, May 14, 2013 at 2:44 PM, Ramkumar Ramachandra
 wrote:
> Phil Hord wrote:
>> References to git-log seem out of place to me here in git-diffcore.  I
>> know it's only an example, but it seems that Git normally describes
>> these 'reference selectors' more generically.  The generic description
>> may be more confusing to new users, but this patch is not the place to
>> consider whether it should change.
>
> It's not for new users at all.  The most useful application of -S and
> -G is in log.  The translation from a log -G to a diffcore -G is not
> obvious at all, and warrants an explanation.
>
> Oh, and for the user.  No user is going to type out `man gitdiffcore`
> out of the blue: she's most probably led there from log, and we're
> connecting the dots for her.

She may have been led here by some other help topic, too.  Maybe the
git log examples belong in the git-log documentation.

>> While the switches are called -S and -G, I do not think it is helpful
>> to name the two pickaxe options as "the S kind" and "the G kind".
>
> How do you describe something precisely without loss of meaning?  You
> stop abstracting unnecessarily.  Read the sources: you will literally
> see DIFF_PICKAXE_KIND_G there.

S and G are abstractions.

DIFF_PICKAXE_KIND_G is an implementer's distinction.

I agree this is a tricky subject.  When writing technical
documentation you must be precise and clear.  It is easy to forget
both.  It is common to forget to be either clear or precise.  It is
very difficult to be both clear and precise.

So, my suggestion is to use some meaningful names for the action of -S
and -G.  Relating these names to -S and -G in a clear way is likely to
be difficult.

>>> +
>>> +The S kind detects filepairs whose "result" side and "origin" side
>>> +have different number of occurrences of specified string.  While
>>> +rename detection works as usual, 'git log -S' cannot omit commits
>>
>> The "cannot omit" feels like a confusing double-negative.  How about
>> "includes" instead?
>
> Intended.  Omission is expected.

This is precision at the expense of clarity.  Omission is not expected
for the user who wants to ask this question:  "Where is that commit
that added 'foo'?"  To Git she wants to ask "Show me the commit that
added or removed 'foo'."  You and I both know that Git does this in
reverse.  Git translates this question into "Show all the commits, but
hide the ones which do not add or remove 'foo'."

And so we say Git 'cannot omit' commits


>
>> Is it worth mentioning that something in the documentation is "worth
>> mentioning"?
>
> You don't have to nitpick style.  We can allow this much creative
> freedom in documentation.

I think I do.  The concepts in here are complicated enough without
loading the language with excess verbiage.  I am chronically afflicted
with this disease where I am always adding extra decorations to my
sentences.  I work hard to combat that, especially when dealing with
technical writings.  This makes it easy for me to recognize in other
technical writing.

I didn't look closely, but these unnecessary introductory clause
appeared to be the only change in this paragraph.  I do not think it
adds anything, which is why I mentioned it.

I could have been more clear and less flippant about it, though.  I'm
sorry if my manner was offensive. This is another chronic problem I
seem to have.


>>> +in effect, diffcore-pickaxe leaves only such filepairs that touch the
>>> +specified string in its output.  When in effect, diffcore-pickaxe
>>> +leaves all filepairs intact if there is such a filepair, or makes the
>>> +output empty otherwise.  The latter behavior is designed to make
>>> +reviewing of the changes in the context of the whole changeset easier.
>>
>> I find this description (from the original code, not from this commit)
>> somewhat confusing.  It is written from the implementer's POV.
>
> I explained the entire -S and -G thing in terms of filepairs (and yes,
> that's implementation detail).  Why would I want to explain this in
> any other terms?

Clarity.

What is a 'filepair' when I am getting a short-log?  Internally there
was a diff, and the diff involves pairs of files.  But it's a tedious
detail to the user which might send her off needlessly trying to
understand the meaning of the term.

But you are right; gitdiffcore.txt is about precision and
implementation.  The goal is to address the technical user who is
trying to understand these operations in general, not just for log.
'filepairs' is a useful concept to lean on.

The clearer description probably belongs in git-log.

>> Does
>> this seem clearer to you?
>> [...]
>
> From diff-options.txt (the more end-user side):
>
> When -S or -G finds a change, show all the changes in that changeset,
> not just the files that contain the change in .
>
> Not clear enough?

Yes, it was clear enough to me in git-log.  Perhaps it is not worth
mentioning here.

Phil
--
To unsubscribe from this list: send the line "unsubscribe git

Re: [PATCH] diffcore-pickaxe doc: document -S and -G properly

[Junio C Hamano]

Ramkumar Ramachandra  writes:

>>> +The S kind detects filepairs whose "result" side and "origin" side
>>> +have different number of occurrences of specified string.  While
>>> +rename detection works as usual, 'git log -S' cannot omit commits
>>
>> The "cannot omit" feels like a confusing double-negative.  How about
>> "includes" instead?
>
> Intended.  Omission is expected.

I think what makes this paragraph unnecessarily hard to read is the
"While rename works".

With that, you are implying "if you rename a file as a whole without
changing the block of text you identify with the -S parameter, then
such a change is not interesting as far as pickaxe is concerned".
while that statement is logically correct, normal people are not
that generous to read that much between your lines.

I think that is one of the reasons why "If you moved a string from
file A to file B, log -S will flag that change as worth inspecting"
does not seem to logically follow and made Phil find your
description confusing.

Finding such a change indeed is a feature [*1*]; we need to flag
such a change as worth inspecting to find where the code came from
in order to dig deeper, so at least this "cannot omit" should be
"does not omit".


[Footnote]

*1* I suspect that your confusion may stem from not understanding
what pickaxe was invented for. It is _not_ about finding the
final answer, but is about stopping at a commit that is worth
investigating further.  

It may help to read
http://article.gmane.org/gmane.comp.version-control.git/217 and
then its follow-up http://gitster.livejournal.com/35628.html


--
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] diffcore-pickaxe doc: document -S and -G properly

[Jonathan Nieder]

Ramkumar Ramachandra wrote:

> What can we do to improve the interface?

Write a better shell?  Teach "git gui blame" to blame on arbitrary
regions instead of single lines?  I'm not sure what you're asking,
mostly because I'm not sure who "we" 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 v3 00/10] remote-hg: fixes and cleanups

[Junio C Hamano]

Felipe Contreras  writes:

> On Mon, May 13, 2013 at 8:08 PM, Junio C Hamano  wrote:
>
>> Folks interested in working remote-hg, please try it out, so that we
>> can have a polished one soon after 1.8.3 ships (I am not saying this
>> round is not polished---I haven't even looked at the patches).
>>
>> And others, please spend time on testing the 1.8.3-rc2 to make sure
>> what we are going to ship is free of embarrassing regressions.
>
> If we want folks to test something, it should be the patches I
> prepared for 'next' which I just sent.

Yeah, but that is for the release _after_ 1.8.3; I'd rather see
folks help to make sure we have a solid 1.8.3 relaese.
--
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] diffcore-pickaxe doc: document -S and -G properly

[Ramkumar Ramachandra]

Junio C Hamano wrote:
> I do not use zsh but with bash+readline the old tradition lnext can
> be used (see "stty -a" output and it typically is set to ^V), i.e.
> \C-v followed by \C-i should give you a literal HT.

Just looked it up: zsh has quoted-insert (^V) after which I can TAB.
Still doesn't solve my problem though: I don't type out structs; I
paste them the X clipboard (Emacs).  And that doesn't work either on
bash or zsh.

What can we do to improve the interface?
--
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] diffcore-pickaxe doc: document -S and -G properly

[Junio C Hamano]

Phil Hord  writes:

> Normally the pickaxe options limit the diff output to those files which
> contained the changes being searched; that is, those files which
> had modifications including the search string.  With the --pickaxe-all
> option, the diff of the entire commit will be shown including files
> which did not have modifications including the search string.  This
> is designed to make it easier to review the changes in the context
> of the whole commit.

I find this very readable, even though "diff output" might be
somewhat misleading (it is not "output for the end user", but is
"passing to the next stage in the pipeline").

--
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] diffcore-pickaxe doc: document -S and -G properly

[Junio C Hamano]

Ramkumar Ramachandra  writes:

> Junio C Hamano wrote:
>> Any time you say "This means that", "More precisely", etc. please
>> check if you can rewrite it to lose everything before them (i.e. a
>> vague sentence that needs to be clarified may not have to be there
>> at all).
>
> Right.  I thought both are necessary in this case: the first sentence
> gives easy information to a first-timer.  For someone who has played
> with it a bit, and wants to know more: the second line.
>
>>> ++
>>> +It is often useful when you're looking for an exact string (like a
>>> +function prototype), and want to know the history of that string since
>>> +it first came into being.
>>
>> I think you should remind that the most useful case (and indeed the
>> intended one) is for "an exact string" to be a multi-line "block of
>> text".  People often get a (wrong) impression from the word "string"
>> that it is meant to be used with a single-liner.
>
> Yes, I've been meaning to discuss that.  I've been having some trouble
> with multi-line strings: zsh doesn't insert a TAB in the next line.
> The workaround I have is to write a shell script and execute that.
> How do you do it?

I do not use zsh but with bash+readline the old tradition lnext can
be used (see "stty -a" output and it typically is set to ^V), i.e.
\C-v followed by \C-i should give you a literal HT.

--
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] diffcore-pickaxe doc: document -S and -G properly

[Ramkumar Ramachandra]

Phil Hord wrote:
> References to git-log seem out of place to me here in git-diffcore.  I
> know it's only an example, but it seems that Git normally describes
> these 'reference selectors' more generically.  The generic description
> may be more confusing to new users, but this patch is not the place to
> consider whether it should change.

It's not for new users at all.  The most useful application of -S and
-G is in log.  The translation from a log -G to a diffcore -G is not
obvious at all, and warrants an explanation.

Oh, and for the user.  No user is going to type out `man gitdiffcore`
out of the blue: she's most probably led there from log, and we're
connecting the dots for her.

> While the switches are called -S and -G, I do not think it is helpful
> to name the two pickaxe options as "the S kind" and "the G kind".

How do you describe something precisely without loss of meaning?  You
stop abstracting unnecessarily.  Read the sources: you will literally
see DIFF_PICKAXE_KIND_G there.

>> +
>> +The S kind detects filepairs whose "result" side and "origin" side
>> +have different number of occurrences of specified string.  While
>> +rename detection works as usual, 'git log -S' cannot omit commits
>
> The "cannot omit" feels like a confusing double-negative.  How about
> "includes" instead?

Intended.  Omission is expected.

> Is it worth mentioning that something in the documentation is "worth
> mentioning"?

You don't have to nitpick style.  We can allow this much creative
freedom in documentation.

>> +in effect, diffcore-pickaxe leaves only such filepairs that touch the
>> +specified string in its output.  When in effect, diffcore-pickaxe
>> +leaves all filepairs intact if there is such a filepair, or makes the
>> +output empty otherwise.  The latter behavior is designed to make
>> +reviewing of the changes in the context of the whole changeset easier.
>
> I find this description (from the original code, not from this commit)
> somewhat confusing.  It is written from the implementer's POV.

I explained the entire -S and -G thing in terms of filepairs (and yes,
that's implementation detail).  Why would I want to explain this in
any other terms?

> Does
> this seem clearer to you?
> [...]

>From diff-options.txt (the more end-user side):

When -S or -G finds a change, show all the changes in that changeset,
not just the files that contain the change in .

Not clear enough?
--
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 v3 00/10] remote-hg: fixes and cleanups

[Junio C Hamano]

Junio C Hamano  writes:

> ...  But now you are saying they regress
> things and need 6 (in 'next') + 10 + 47 patches to fix on top, in
> order not to hurt existing users?
>
> What is going on?

Ahh, OK, I miscounted.  The 10 were supposed to replace 6 and then 47
in turn are supposed to replace the whole thing, while these are
still *not* in 'next'.

OK, will replace fc/remote-hg that is currently on 'pu' with the
latest (v4 */47).
--
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 v3 00/10] remote-hg: fixes and cleanups

[Junio C Hamano]

Felipe Contreras  writes:

> On Mon, May 13, 2013 at 8:08 PM, Junio C Hamano  wrote:
>> And others, please spend time on testing the 1.8.3-rc2 to make sure
>> what we are going to ship is free of embarrassing regressions.
>
> The whole purpose of this series is to avoid regressions, that's why I
> sent them for 1.8.3.

We agreed to make an exception to let remote-bzr updates go in even
after v1.8.3-rc1, because it is too young and you can afford to
check that the updated code will give only gains to its userbase
that matters without hurting them by checking with Emacs and other
projects.

I do not recall us doing a similar exception for remote-hg.  Did we?

If we didn't, then a 10-patch series at this point in the cycle is
way too late for me to be comfortable taking.

We merged the 21-patch remote-hg series from you on Apr 21st, a week
before -rc0, and it has been 3 weeks.  Back then you thought it made
things better without regression, and I expected that loose ends
could be fixed by -rc1 with enough time to cook them in 'next'
(meaning tying such loose ends would be just the matter of a couple
of trivial patches at most).  But now you are saying they regress
things and need 6 (in 'next') + 10 + 47 patches to fix on top, in
order not to hurt existing users?

What is going on?

People make mistakes and the initial submission being buggy is *not*
a problem per-se, but what quality assurance do the 10-patch and/or
the follow up 47-patch series have over these 21 patches to assure
us that they do not introduce more problems, when we are this close
to the final, way less than the 3 weeks we had?

The best we could do to avoid regressions (if there are reported
ones) is to revert specific changes that cause the regression that
are already in v1.8.3-rc2.  Which one(s) should we be reverting, and
do you have a regression report that says the commit(s) in question
breaks things for a specific project, and reverting it(them) makes
things work again?
--
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] diffcore-pickaxe doc: document -S and -G properly

[Ramkumar Ramachandra]

Junio C Hamano wrote:
> Any time you say "This means that", "More precisely", etc. please
> check if you can rewrite it to lose everything before them (i.e. a
> vague sentence that needs to be clarified may not have to be there
> at all).

Right.  I thought both are necessary in this case: the first sentence
gives easy information to a first-timer.  For someone who has played
with it a bit, and wants to know more: the second line.

>> ++
>> +It is often useful when you're looking for an exact string (like a
>> +function prototype), and want to know the history of that string since
>> +it first came into being.
>
> I think you should remind that the most useful case (and indeed the
> intended one) is for "an exact string" to be a multi-line "block of
> text".  People often get a (wrong) impression from the word "string"
> that it is meant to be used with a single-liner.

Yes, I've been meaning to discuss that.  I've been having some trouble
with multi-line strings: zsh doesn't insert a TAB in the next line.
The workaround I have is to write a shell script and execute that.
How do you do it?
--
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] diffcore-pickaxe: make error messages more consistent

[Ramkumar Ramachandra]

Junio C Hamano wrote:
> I am debating myself if it is truly easier to explain for users that
> "-G" is a different variant of pickaxe.

Hm, I think it is the correct approach because readers of diffcore are
probably going to look at the source: it's not exactly an end-user
manpage.  I've not explained it as G king versus S kind in the
diff-options documentation.

Or are you just talking about the error message?  That's simple:
--pickaxe-regex is what triggers this off, and we've made it clear
that it applies to both commands (-G implicitly; see doc).
--
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: AW: English/German terminology, git.git's de.po, and pro-git

[Ralf Thielow]

Hi all,

I tried to merge these different glossaries together (based on git de.po)
as a new wiki page [1]. You can see the diff against the current git de.po
glossary at [2]. I've also created a branch in my repository which only contains
the wiki page as a text file. This allows comments on each line of a commit,
which perhaps can be used for discussions (see [3]) and/or pull-requests?!
If we really want to use one glossary, I'm also happy with other solutions or
repositories.

The new wiki page is in WIP state and it turns out that there aren't so many
changes to the current one as I expected. I want to give a few comments on
the most important changes:

- tree = Baum
+ tree = Baum, Baum-Objekt, "Tree"-Objekt

"Baum" is already fine. Depending on the message context we could use
"Baum-Objekt", but not necessarily.

- submodule = Unterprojekt
+ submodule = Submodul (suggested by JL) (before it was "Unterprojekt")

I'm fine with that.

- ancestor = Vorfahre
+ ancestor = Vorfahre, Vorgänger, Vorgänger-Commit

"Vorgänger" sounds a bit better for me.

- repository = Projektarchiv
- bare repository = bloßes Projektarchiv
+ repository = Projektarchiv, (or just Repository?)
+ bare repository = bloßes Projektarchiv (-||-), (reines, pures Repository)

I'm not sure about using "Repository". I think "Projektarchiv" is
actually good enough.

- committer = Eintragender
- tagger = Markierer
+ committer = Eintragender (or Committer, Commit-Ersteller)
+ tagger = Markierer (or Tagger, Tag-Ersteller)
...[each usage of commit and tag]...

This goes to the question if we should translate "Commit" and "Tag".
I think we shouldn't since everyone who uses/learn Git or come from
other SCMs know what it means.

+ revision = Revision (use Commit instead (see dfb4410 (glossary: a
revision is just a commit))

So just "Commit".

+ branch = Zweig (or Branch)

I think "Zweig" is already fine.

+ stage/index (noun) = Bereitstellung (Staging-Area, Index)
+ stage/index (verb) = stagen, für einen Commit vormerken, zur Staging
Area hinzufügen, dem Index hinzufügen
+ unstage (verb) = unstagen, aus Staging Area entfernen/nehmen, aus
Index entfernen/nehmen

I think we should replace "Bereitstellung" and "bereitstellen". "für
einen/den Commit vormerken" is
nice when "stage" is used as a verb. When "stage" is used as a noun,
we have to decide between
"Index" and "Staging Area" (and "Cache"?) I'd prefer "Index".

+ merge = Zusammenführung (Merge)

We currently translate the noun of "merge" as "Zusammenführung" and
the verb as "zusammenführen".
I'd change it so "der Merge" and "mergen".

The diff in [2] shows a couple of more changes but they're all based
on the things I've mentioned here.

[1]
https://github.com/ralfth/git-po-de/wiki/Glossary-new-WIP
[2]
https://github.com/ralfth/git-po-de/wiki/_compare/25baaa323929949283a0b920c1ef66dc16288d0b...12f08b8973bd4b7ea55779f6eb5ad3a86bac13d8
[3]
https://github.com/ralfth/git-po-de/commit/28852f8ea33ac6a9dbf7e3b17dfa00ddd4e7ecb5

Thanks,
Ralf

2013/5/13 Jan Engelhardt :
>
> On Monday 2013-05-13 20:57, Ralph Haußmann wrote:
>>
>>There is a glossary for the pro-git book (see [2]) but it is not up-to-date
>>and it is also mixed. Therefor I would like to avoid using this glossary.
>>I like the idea of a shared wiki (git de.po and pro-git).
>>I suggest a single page as overview and single pages for
>>complicated terms. Maybe we can use our GitHub wiki (see also [3]).
>>
>>[2] https://github.com/progit/progit/blob/master/de/NOTES
>>[3] https://github.com/progit-de/progit/wiki/Glossar
>
> This is how I envision a good glossary
>
> http://inai.de/files/git-glossary.txt
>
> Maybe the "Benevolent Dictator" model might be better suited
> instead of a wiki? (Think of the edit wars.)
--
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: [PATCHv2 03/10] refs.c: Refactor code for mapping between shorthand names and full refnames

[Junio C Hamano]

Johan Herland  writes:

> I think I like "refs/peers/%1/heads/%*" better than
> "refs/peers/%1/heads/%2", since the latter sort of makes me wonder
> whether the 3rd, 4th, etc. components would be discarded.

Makes sense.

> I am not sure why we would want "refs/remotes/%1/%2" instead of
> "refs/remote/%*".

The former way makes it easier to see what "refs/peers/%1/heads/%2"
means, I think, but otherwise aren't they equivalent?  I do not see
a strong reason to favor one over the other.

> remote-tracking branch "baz" from remote "foo/bar", but we might say
> that's ok, because (a) multi-level remote names are so rare, and (b)
> the simple workaround of explicitly saying
> "refs/peers/foo/bar/heads/baz" would always be available in any case.

Sounds sensible.

And if you limit things that way, "%1" again starts to make sense,
as you are representing "the first path component" with it.

--
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] diffcore-pickaxe doc: document -S and -G properly

[Phil Hord]

On Tue, May 14, 2013 at 1:44 PM, Phil Hord  wrote:
> On Tue, May 14, 2013 at 10:12 AM, Ramkumar Ramachandra
>  wrote:
>>
>>  -S::
>> -   Look for differences that introduce or remove an instance of
>> -   . Note that this is different than the string simply
>> -   appearing in diff output; see the 'pickaxe' entry in
>> -   linkgit:gitdiffcore[7] for more details.
>> +   Look for commits where the specified string was added or
>> +   removed.  More precisely, find commits that change the number
>> +   of occurrences of the specified string.
>> ++
>> +It is often useful when you're looking for an exact string (like a
>> +function prototype), and want to know the history of that string since
>> +it first came into being.
>>
>>  -G::
>
> It looks like you have deleted the -S and -G references here.  Am I
> reading this right?

Doy!  Yes, I was reading it wrong.  Sorry for the noise there.

Phil
--
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] diffcore-pickaxe: make error messages more consistent

[Junio C Hamano]

Ramkumar Ramachandra  writes:

> Currently, diffcore-pickaxe reports two distinct errors for the same
> user error:
>
> $ git log --pickaxe-regex -S'\1'
> fatal: invalid pickaxe regex: Invalid back reference
>
> $ git log -G'\1' # --pickaxe-regex is implied
> fatal: invalid log-grep regex: Invalid back reference
>
> Since the error has nothing to do with "log-grep", change the -G error
> message to match the -S error message.
>
> Signed-off-by: Ramkumar Ramachandra 
> ---
>  Sorry I couldn't do more.  diffcore-pickaxe.c isn't at all easy to
>  hack on, because there are so few tests guarding it.
>
>  diffcore-pickaxe.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/diffcore-pickaxe.c b/diffcore-pickaxe.c
> index 63722f8..d69a7a2 100644
> --- a/diffcore-pickaxe.c
> +++ b/diffcore-pickaxe.c
> @@ -122,7 +122,7 @@ static void diffcore_pickaxe_grep(struct diff_options *o)
>   char errbuf[1024];
>   regerror(err, ®ex, errbuf, 1024);
>   regfree(®ex);
> - die("invalid log-grep regex: %s", errbuf);
> + die("invalid pickaxe regex: %s", errbuf);
>   }
>  
>   pickaxe(&diff_queued_diff, o, ®ex, NULL, diff_grep);

I am debating myself if it is truly easier to explain for users that
"-G" is a different variant of pickaxe.

It happens to be implemented in the same source file as pickaxe, but
they do logically quite different things.  -G does not even have a
reason to pay attention to --pickaxe-regexp (it is "grep in the log
-p").

I suspect that it might avoid unnecessary confusion to explain them
as totally separate operations, and not labelling this error with
"pickaxe regex".  I dunno.

--
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] diffcore-pickaxe doc: document -S and -G properly

[Phil Hord]

On Tue, May 14, 2013 at 10:12 AM, Ramkumar Ramachandra
 wrote:
> The documentation of -S and -G is very sketchy.  Completely rewrite the
> sections in Documentation/diff-options.txt and
> Documentation/gitdiffcore.txt.
>
> References:
> 52e9578 ([PATCH] Introducing software archaeologist's tool "pickaxe".)
> f506b8e (git log/diff: add -G that greps in the patch text)
>
> Signed-off-by: Ramkumar Ramachandra 
> ---
>  I spent some time reading the code and history to figure out what -S
>  and -G really do.  I hope I've done justice.
>
>  Documentation/diff-options.txt | 35 +++---
>  Documentation/gitdiffcore.txt  | 43 
> +++---
>  2 files changed, 52 insertions(+), 26 deletions(-)
>
> diff --git a/Documentation/diff-options.txt b/Documentation/diff-options.txt
> index 104579d..765abc5 100644
> --- a/Documentation/diff-options.txt
> +++ b/Documentation/diff-options.txt
> @@ -383,14 +383,35 @@ ifndef::git-format-patch[]
> that matches other criteria, nothing is selected.
>
>  -S::
> -   Look for differences that introduce or remove an instance of
> -   . Note that this is different than the string simply
> -   appearing in diff output; see the 'pickaxe' entry in
> -   linkgit:gitdiffcore[7] for more details.
> +   Look for commits where the specified string was added or
> +   removed.  More precisely, find commits that change the number
> +   of occurrences of the specified string.
> ++
> +It is often useful when you're looking for an exact string (like a
> +function prototype), and want to know the history of that string since
> +it first came into being.
>
>  -G::

It looks like you have deleted the -S and -G references here.  Am I
reading this right?

> -   Look for differences whose added or removed line matches
> -   the given .
> +   Grep through the patch text of commits for added/removed lines
> +   that match .  `--pickaxe-regex` is implied in this
> +   mode.
> ++
> +To illustrate the difference between `-S --pickaxe-regex` and
> +`-G`, consider a commit with the following diff in the same
> +file:
> ++
> +
> ++return !regexec(regexp, two->ptr, 1, ®match, 0);
> +...
> +-hit = !regexec(regexp, mf2.ptr, 1, ®match, 0);
> +
> ++
> +While `git log -G"regexec\(regexp"` will show this commit, `git log
> +-S"regexec\(regexp" --pickaxe-regex` will not (because the number of
> +occurrences of that string didn't change).

References to git-log seem out of place to me here in git-diffcore.  I
know it's only an example, but it seems that Git normally describes
these 'reference selectors' more generically.  The generic description
may be more confusing to new users, but this patch is not the place to
consider whether it should change.

> ++
> +See the 'pickaxe' entry in linkgit:gitdiffcore[7] for more
> +information.
>
>  --pickaxe-all::
> When `-S` or `-G` finds a change, show all the changes in that
> @@ -399,7 +420,7 @@ ifndef::git-format-patch[]
>
>  --pickaxe-regex::
> Make the  not a plain string but an extended POSIX
> -   regex to match.
> +   regex to match.  Implied when using `-G`.
>  endif::git-format-patch[]
>
>  -O::
> diff --git a/Documentation/gitdiffcore.txt b/Documentation/gitdiffcore.txt
> index 568d757..39b9c51 100644
> --- a/Documentation/gitdiffcore.txt
> +++ b/Documentation/gitdiffcore.txt
> @@ -222,25 +222,30 @@ version prefixed with '+'.
>  diffcore-pickaxe: For Detecting Addition/Deletion of Specified String
>  -
>
> -This transformation is used to find filepairs that represent
> -changes that touch a specified string, and is controlled by the
> --S option and the `--pickaxe-all` option to the 'git diff-*'
> -commands.
> -
> -When diffcore-pickaxe is in use, it checks if there are
> -filepairs whose "result" side and whose "origin" side have
> -different number of specified string.  Such a filepair represents
> -"the string appeared in this changeset".  It also checks for the
> -opposite case that loses the specified string.
> -
> -When `--pickaxe-all` is not in effect, diffcore-pickaxe leaves
> -only such filepairs that touch the specified string in its
> -output.  When `--pickaxe-all` is used, diffcore-pickaxe leaves all
> -filepairs intact if there is such a filepair, or makes the
> -output empty otherwise.  The latter behaviour is designed to
> -make reviewing of the changes in the context of the whole
> -changeset easier.
> -
> +There are two kinds of pickaxe: the S kind (corresponding to 'git log
> +-S') and the G kind (corresponding to 'git log -G').

While the switches are called -S and -G, I do not think it is helpful
to name the two pickaxe options as "the S kind" and "the G kind".

> +
> +The S kind detects filepairs whose "result" side and "origin" side
> +have different number of occurrences of specified string.  While
> +rename detection works as usua

Re: [PATCH] diffcore-pickaxe doc: document -S and -G properly

[Junio C Hamano]

Ramkumar Ramachandra  writes:

>  -S::
> - Look for differences that introduce or remove an instance of
> - . Note that this is different than the string simply
> - appearing in diff output; see the 'pickaxe' entry in
> - linkgit:gitdiffcore[7] for more details.
> + Look for commits where the specified string was added or
> + removed.  More precisely, find commits that change the number
> + of occurrences of the specified string.

Any time you say "This means that", "More precisely", etc. please
check if you can rewrite it to lose everything before them (i.e. a
vague sentence that needs to be clarified may not have to be there
at all).

> ++
> +It is often useful when you're looking for an exact string (like a
> +function prototype), and want to know the history of that string since
> +it first came into being.

I think you should remind that the most useful case (and indeed the
intended one) is for "an exact string" to be a multi-line "block of
text".  People often get a (wrong) impression from the word "string"
that it is meant to be used with a single-liner.
--
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] remote-bzr: update old organization

[Junio C Hamano]

Felipe Contreras  writes:

> If a clone exists with the old organization (v1.8.2) it will prevent the
> new shared repository organization from working, so let's remove this
> repository, which is not used any more.
>
> Signed-off-by: Felipe Contreras 
> ---

What happens with and without this patch to an existing user from
1.8.2 days, when she does what?

A sample answer (to show the level of descriptiveness, not the
content, I am epecting) might go something like "Because the
organization is different, it will barf whenever she tries to
incrementally update from the other side. By removing the old one
1.8.3 contrib/ does not understand, at least we can unstuck her; she
ends up reimporting the whole history, though."

Trying to see if this is a 1.8.3 "fast-track" material.

>  contrib/remote-helpers/git-remote-bzr | 7 +++
>  1 file changed, 7 insertions(+)
>
> diff --git a/contrib/remote-helpers/git-remote-bzr 
> b/contrib/remote-helpers/git-remote-bzr
> index 3e452af..b295dd4 100755
> --- a/contrib/remote-helpers/git-remote-bzr
> +++ b/contrib/remote-helpers/git-remote-bzr
> @@ -830,6 +830,13 @@ def get_repo(url, alias):
>  clone_path = os.path.join(dirname, 'clone')
>  if not os.path.exists(clone_path):
>  os.mkdir(clone_path)
> +else:
> +# check and remove old organization
> +try:
> +bdir = bzrlib.bzrdir.BzrDir.open(clone_path)
> +bdir.destroy_repository()
> +except bzrlib.errors.NotBranchError:
> +pass
>  
>  try:
>  repo = origin.open_repository()
--
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: [PATCHv2 03/10] refs.c: Refactor code for mapping between shorthand names and full refnames

[Johan Herland]

On Mon, May 13, 2013 at 10:34 PM, Junio C Hamano  wrote:
> Junio C Hamano  writes:
>> Johan Herland  writes:
>>> Obviously, I named it '%1' since it expands into the _first_ component
>>> of the (slash-separated) shorthand.
>>
>> OK, I can buy something like
>>
>>   %*
>> refs/%*
>> refs/heads/%*
>> ...
>> refs/remotes/%*/HEAD
>> refs/remotes/%1/%2
>> refs/peers/%1/heads/%2
>>
>> that is, for a pattern that has %*, we feed the end-user string as a
>> whole, and for a pattern that has %1 thru %N, we find an appropriate
>> way to chop the end-user string into N pieces (e.g. nick/name would
>> be split into %1 = nick, %2 = name, while foo/bar/baz might have two
>> possibilities, <%1, %2> =  or ).  The
>> earlier ones on the above list can even be written with their %*
>> substituted with %1 if we go that route.
>
> Just to make sure.
>
> Please do not let "two possibilities" stop you.  As I said in the
> nearby thread, I do not necessarily insist that we must try all N
> possibilities.  "We find an appropriate way" could be just "we
> always chop at the first slash, and %1 is what comes before it, %2
> is what comes after it".
>
> That will close the possibility for us to use %1 thru %N (N is
> limited to 2), but it still is "We have %1 and we have %2, both fall
> into the same 'path components, numbered from left to right'
> category", and justifies the use of %1 ("one", not "el").
>
> So still no objection to %1 from me.

I think I like "refs/peers/%1/heads/%*" better than
"refs/peers/%1/heads/%2", since the latter sort of makes me wonder
whether the 3rd, 4th, etc. components would be discarded. That said,
having %* mean "the rest of the shorthand" means that we must adjust
the expansion of %* for every preceding %N, which prevents us from
simplifying the code by using strbuf_expand_dict_cb() with a static
dictionary [1].

I am not sure why we would want "refs/remotes/%1/%2" instead of
"refs/remote/%*". Maybe I've been staring at this for too long, but I
find the latter shorter and more descriptive and the "%1/%2" notation
needlessly cumbersome, especially if it's also supposed to match
"foo/bar/baz"

When it comes to multi-level remote names, I guess I could drop the
patch that disallows them, and still just have "%1" only map to the
first component (i.e. "foo/bar/baz" would always be interpreted as %1
= "foo", and never %1 = "foo/bar"). This would mean that the
"foo/bar/baz" shorthand notation would simply not work against
remote-tracking branch "baz" from remote "foo/bar", but we might say
that's ok, because (a) multi-level remote names are so rare, and (b)
the simple workaround of explicitly saying
"refs/peers/foo/bar/heads/baz" would always be available in any case.


...Johan


[1]: Maybe we could use '%N+' to mean "everything starting from
component #N"? Then we could construct the following dictionary the
shorthand "foo/bar/baz":

  "*" -> "foo/bar/baz"
  "1" -> "foo"
  "1+" -> "foo/bar/baz"
  "2" -> "bar"
  "2+" -> "bar/baz"
etc.

But I really think this is overkill. Avoiding having to write our own
expansion helper is not _that_ important.

-- 
Johan Herland, 
www.herland.net
--
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] diffcore-pickaxe: make error messages more consistent

[Ramkumar Ramachandra]

Currently, diffcore-pickaxe reports two distinct errors for the same
user error:

$ git log --pickaxe-regex -S'\1'
fatal: invalid pickaxe regex: Invalid back reference

$ git log -G'\1' # --pickaxe-regex is implied
fatal: invalid log-grep regex: Invalid back reference

Since the error has nothing to do with "log-grep", change the -G error
message to match the -S error message.

Signed-off-by: Ramkumar Ramachandra 
---
 Sorry I couldn't do more.  diffcore-pickaxe.c isn't at all easy to
 hack on, because there are so few tests guarding it.

 diffcore-pickaxe.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/diffcore-pickaxe.c b/diffcore-pickaxe.c
index 63722f8..d69a7a2 100644
--- a/diffcore-pickaxe.c
+++ b/diffcore-pickaxe.c
@@ -122,7 +122,7 @@ static void diffcore_pickaxe_grep(struct diff_options *o)
char errbuf[1024];
regerror(err, ®ex, errbuf, 1024);
regfree(®ex);
-   die("invalid log-grep regex: %s", errbuf);
+   die("invalid pickaxe regex: %s", errbuf);
}
 
pickaxe(&diff_queued_diff, o, ®ex, NULL, diff_grep);
-- 
1.8.3.rc1.61.g2cacfff

--
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] diffcore-pickaxe doc: document -S and -G properly

[Ramkumar Ramachandra]

The documentation of -S and -G is very sketchy.  Completely rewrite the
sections in Documentation/diff-options.txt and
Documentation/gitdiffcore.txt.

References:
52e9578 ([PATCH] Introducing software archaeologist's tool "pickaxe".)
f506b8e (git log/diff: add -G that greps in the patch text)

Signed-off-by: Ramkumar Ramachandra 
---
 I spent some time reading the code and history to figure out what -S
 and -G really do.  I hope I've done justice.

 Documentation/diff-options.txt | 35 +++---
 Documentation/gitdiffcore.txt  | 43 +++---
 2 files changed, 52 insertions(+), 26 deletions(-)

diff --git a/Documentation/diff-options.txt b/Documentation/diff-options.txt
index 104579d..765abc5 100644
--- a/Documentation/diff-options.txt
+++ b/Documentation/diff-options.txt
@@ -383,14 +383,35 @@ ifndef::git-format-patch[]
that matches other criteria, nothing is selected.
 
 -S::
-   Look for differences that introduce or remove an instance of
-   . Note that this is different than the string simply
-   appearing in diff output; see the 'pickaxe' entry in
-   linkgit:gitdiffcore[7] for more details.
+   Look for commits where the specified string was added or
+   removed.  More precisely, find commits that change the number
+   of occurrences of the specified string.
++
+It is often useful when you're looking for an exact string (like a
+function prototype), and want to know the history of that string since
+it first came into being.
 
 -G::
-   Look for differences whose added or removed line matches
-   the given .
+   Grep through the patch text of commits for added/removed lines
+   that match .  `--pickaxe-regex` is implied in this
+   mode.
++
+To illustrate the difference between `-S --pickaxe-regex` and
+`-G`, consider a commit with the following diff in the same
+file:
++
+
++return !regexec(regexp, two->ptr, 1, ®match, 0);
+...
+-hit = !regexec(regexp, mf2.ptr, 1, ®match, 0);
+
++
+While `git log -G"regexec\(regexp"` will show this commit, `git log
+-S"regexec\(regexp" --pickaxe-regex` will not (because the number of
+occurrences of that string didn't change).
++
+See the 'pickaxe' entry in linkgit:gitdiffcore[7] for more
+information.
 
 --pickaxe-all::
When `-S` or `-G` finds a change, show all the changes in that
@@ -399,7 +420,7 @@ ifndef::git-format-patch[]
 
 --pickaxe-regex::
Make the  not a plain string but an extended POSIX
-   regex to match.
+   regex to match.  Implied when using `-G`.
 endif::git-format-patch[]
 
 -O::
diff --git a/Documentation/gitdiffcore.txt b/Documentation/gitdiffcore.txt
index 568d757..39b9c51 100644
--- a/Documentation/gitdiffcore.txt
+++ b/Documentation/gitdiffcore.txt
@@ -222,25 +222,30 @@ version prefixed with '+'.
 diffcore-pickaxe: For Detecting Addition/Deletion of Specified String
 -
 
-This transformation is used to find filepairs that represent
-changes that touch a specified string, and is controlled by the
--S option and the `--pickaxe-all` option to the 'git diff-*'
-commands.
-
-When diffcore-pickaxe is in use, it checks if there are
-filepairs whose "result" side and whose "origin" side have
-different number of specified string.  Such a filepair represents
-"the string appeared in this changeset".  It also checks for the
-opposite case that loses the specified string.
-
-When `--pickaxe-all` is not in effect, diffcore-pickaxe leaves
-only such filepairs that touch the specified string in its
-output.  When `--pickaxe-all` is used, diffcore-pickaxe leaves all
-filepairs intact if there is such a filepair, or makes the
-output empty otherwise.  The latter behaviour is designed to
-make reviewing of the changes in the context of the whole
-changeset easier.
-
+There are two kinds of pickaxe: the S kind (corresponding to 'git log
+-S') and the G kind (corresponding to 'git log -G').
+
+The S kind detects filepairs whose "result" side and "origin" side
+have different number of occurrences of specified string.  While
+rename detection works as usual, 'git log -S' cannot omit commits
+where a the small string being looked for is moved verbatim from one
+file to another (since the number of occurrences of that string
+changed in each of those two filepairs). The implementation
+essentially runs a count, and is significantly cheaper than the G
+kind.
+
+The G kind detects filepairs whose patch text has an added or a
+deleted line that matches the given regexp.  This means that it can
+detect in-file (or what rename-detection considers the same file)
+moves.  The implementation of 'git log -G' runs diff twice and greps,
+and this can be quite expensive.
+
+A diffcore-pickaxe option worth mentioning: `--pickaxe-all`.  When not
+in effect, diffcore-pickaxe leaves only such filepairs that touch the
+specified string in its output.  When in effec

make git ignore the timestamp embedded in PDFs

[Andreas Leha]

Hi all,

how can I make git ignore the time stamp(s) in a PDF.  Two PDFs that
differ only in these time stamps should be considered identical.

Here is an example:
,
| > pdfinfo some.pdf
| Title:  R Graphics Output
| Creator:R
| Producer:   R 2.15.1
| CreationDate:   Thu Jan 24 13:43:31 2013 <==  these entries
| ModDate:Thu Jan 24 13:43:31 2013 <==  should be ignored
| Tagged: no
| Pages:  1
| Encrypted:  no
| Page size:  504 x 504 pts
| File size:  54138 bytes
| Optimized:  no
| PDF version:1.4
`


What I tried is a filter:
,[ ~/.gitconfig ]
| [filter "pdfresetdate"]
| clean = pdfresetdate
`

With this filter script:
,[ pdfresetdate ]
| #!/bin/bash
|
| FILEASARG=true
| if [ "$#" == 0 ]; then
| FILEASARG=false
| fi
|
| if $FILEASARG ; then
| FILENAME="$1"
| else
| FILENAME=`mktemp`
| cat /dev/stdin > "${FILENAME}"
| fi
|
| TMPFILE=`mktemp`
| TMPFILE2=`mktemp`
|
| ## dump the pdf metadata to a file and replace the dates
| pdftk "$FILENAME" dump_data | sed -e '{N;s/Date\nInfoValue: 
D:.*/Date\nInfoValue: D:19790101072619/}' > "$TMPFILE"
|
| ## update the pdf metadata
| pdftk "$FILENAME" update_info "$TMPFILE" output "$TMPFILE2"
|
| ## overwrite the original pdf
| mv -f "$TMPFILE2" "$FILENAME"
|
| ## clean up
| rm -f "$TMPFILE"
| rm -f "$TMPFILE2"
| if [ -n $FILEASARG ] ; then
| cat "$FILENAME"
| fi
`


This 'works' as far as the committed pdf indeed has the date reset to my
default value.

However, when I re-checkout the files, they are marked modified by git.

So, my question is:  How can I make git *completely* ignore the embedded
date in the PDF?

Many thanks in advance for any help!

Regards,
Andreas


PS:
I had posted this question (without much success) here:
http://stackoverflow.com/questions/16058187/make-git-ignore-the-date-in-pdf-files
and with no answer on the git-users mailing list:
https://groups.google.com/forum/#!topic/git-users/KqtecNa3cOc

--
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 v3] checkout: add --ignore-skip-worktree-bits in sparse checkout mode

[Duy Nguyen]

On Tue, May 14, 2013 at 4:27 PM, Müller  Kirill
 wrote:
> Thank you, this looks nice. What needs to be done that this will
> eventually reach the git in my favorite distribution? Which version of
> Git will this be?

It'll be in the upcoming 1.8.3.
--
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 v3] checkout: add --ignore-skip-worktree-bits in sparse checkout mode

[Müller Kirill]

Thank you, this looks nice. What needs to be done that this will
eventually reach the git in my favorite distribution? Which version of
Git will this be?


Cheers

Kirill


On Sat, 2013-04-13 at 09:12 +1000, Nguyễn Thái Ngọc Duy wrote:
> "git checkout -- " is usually used to restore all modified
> files in . In sparse checkout mode, this command is overloaded
> with another meaning: to add back all files in  that are
> excluded by sparse patterns.
> 
> As the former makes more sense for day-to-day use. Switch it to the
> default and the latter enabled with --ignore-skip-worktree-bits.

Re: [PATCH 0/4] Coverage support revisited

[Thomas Rast]

Jens Lehmann  writes:

> Am 13.05.2013 23:27, schrieb Thomas Rast:
>> Jens asked me at git-merge if coverage support was still available.
>> Turns out it is, but there were some weirdnesses.  So this should fix
>> them.  It is relly slow as you still have to run the tests one by
>> one; despite claims in the wild that it is multiprocess- safe but
>> thread-unsafe, I am in fact observing the opposite behavior pretty
>> clearly.  (As before, it switches to sequential tests automatically,
>> so you have to edit the Makefile if you want to try with parallel
>> tests.)
>
> Thx! That might explain why the coverage run I tried today didn't
> work (I saw bogus test failures).

Indeed it does.  I should have mentioned it in the cover letter; it's
fixed by this series but if you set DEFAULT_TEST_TARGET=prove like
everyone else, it ignored the (existing) force-to-sequential rule.

>> unpack-trees.c: verify_clean_submodule
>
> This is the one I was after. While discussing my recursive update
> code with Peff on Saturday we wondered if that function would ever
> be called. I'll check if the tests are missing some relevant cases,
> if that function can be removed or some refactoring is necessary.
>
> Hmm, while function coverage is already extremely useful me thinks
> lcov support would be really nice. We'd have line and branch coverage,
> which help me a lot in finding dead code and missing tests at $DAYJOB
> ... will look into that when I have the recursive update ready.

Actually if you run it, it generates submodule.c.gcov as an intermediate
step to the uncovered-functions list.  Of course you can also use any
other tool that can read gcov; the results are cleaned before the run,
not after, so they will remain in place.

Originally I hacked together an uncovered-functions list because that
list was so long that looking at things in even more detail seemed
extremely pointless.

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

[PATCH v9 5/9] git-clean: use a git-add-interactive compatible UI

[Jiang Xin]

Rewrite menu using a new method `list_and_choose`, which is borrowed
from `git-add--interactive.perl`. We will use this framework to add
new actions for interactive git-clean later.

Please NOTE:

 * Method `list_and_choose` return an array of integers, and
 * it is up to you to free the allocated memory of the array.
 * The array ends with EOF.
 * If user pressed CTRL-D (i.e. EOF), no selection returned.

Signed-off-by: Jiang Xin 
---
 builtin/clean.c | 449 
 1 file changed, 420 insertions(+), 29 deletions(-)

diff --git a/builtin/clean.c b/builtin/clean.c
index 5c781..7930f 100644
--- a/builtin/clean.c
+++ b/builtin/clean.c
@@ -50,6 +50,36 @@ enum color_clean {
CLEAN_COLOR_ERROR = 5,
 };
 
+#define MENU_OPTS_SINGLETON01
+#define MENU_OPTS_IMMEDIATE02
+#define MENU_OPTS_LIST_ONLY04
+
+struct menu_opts {
+   const char *header;
+   const char *prompt;
+   int flags;
+};
+
+#define MENU_RETURN_NO_LOOP10
+
+struct menu_item {
+   char hotkey;
+   char *title;
+   int selected;
+   int (*fn)();
+};
+
+enum menu_stuff_type {
+   MENU_STUFF_TYPE_STRING_LIST = 1,
+   MENU_STUFF_TYPE_MENU_ITEM
+};
+
+struct menu_stuff {
+   enum menu_stuff_type type;
+   int nr;
+   void *stuff;
+};
+
 static int parse_clean_color_slot(const char *var)
 {
if (!strcasecmp(var, "reset"))
@@ -282,54 +312,415 @@ static void pretty_print_dels(void)
copts.indent = "  ";
copts.padding = 2;
print_columns(&list, colopts, &copts);
-   putchar('\n');
strbuf_release(&buf);
string_list_clear(&list, 0);
 }
 
-static void interactive_main_loop(void)
+static void pretty_print_menus(struct string_list *menu_list)
+{
+   unsigned int local_colopts = 0;
+   struct column_options copts;
+
+   local_colopts = COL_ENABLED | COL_ROW;
+   memset(&copts, 0, sizeof(copts));
+   copts.indent = "  ";
+   copts.padding = 2;
+   print_columns(menu_list, local_colopts, &copts);
+}
+
+static void prompt_help_cmd(int singleton)
+{
+   clean_print_color(CLEAN_COLOR_HELP);
+   printf_ln(singleton ?
+ _("Prompt help:\n"
+   "1  - select a numbered item\n"
+   "foo- select item based on unique prefix\n"
+   "   - (empty) select nothing") :
+ _("Prompt help:\n"
+   "1  - select a single item\n"
+   "3-5- select a range of items\n"
+   "2-3,6-9- select multiple ranges\n"
+   "foo- select item based on unique prefix\n"
+   "-...   - unselect specified items\n"
+   "*  - choose all items\n"
+   "   - (empty) finish selecting"));
+   clean_print_color(CLEAN_COLOR_RESET);
+}
+
+/*
+ * display menu stuff with number prefix and hotkey highlight
+ */
+static void print_highlight_menu_stuff(struct menu_stuff *stuff, int **chosen)
+{
+   struct string_list menu_list = STRING_LIST_INIT_DUP;
+   struct strbuf menu = STRBUF_INIT;
+   int i;
+
+   if (MENU_STUFF_TYPE_MENU_ITEM == stuff->type) {
+   struct menu_item *item;
+
+   item = (struct menu_item *)stuff->stuff;
+   for (i = 0; i < stuff->nr; i++, item++) {
+   char *p;
+   int highlighted = 0;
+
+   p = item->title;
+   if ((*chosen)[i] < 0)
+   (*chosen)[i] = item->selected ? 1 : 0;
+   strbuf_addf(&menu, "%s%2d: ", (*chosen)[i] ? "*" : " ", 
i+1);
+   for (; *p; p++) {
+   if (!highlighted && *p == item->hotkey) {
+   strbuf_addstr(&menu, 
clean_get_color(CLEAN_COLOR_PROMPT));
+   strbuf_addch(&menu, *p);
+   strbuf_addstr(&menu, 
clean_get_color(CLEAN_COLOR_RESET));
+   highlighted = 1;
+   } else {
+   strbuf_addch(&menu, *p);
+   }
+   }
+   string_list_append(&menu_list, menu.buf);
+   strbuf_reset(&menu);
+   }
+   } else if (MENU_STUFF_TYPE_STRING_LIST == stuff->type) {
+   struct string_list_item *item;
+   struct strbuf buf = STRBUF_INIT;
+   i = 0;
+
+   for_each_string_list_item(item, (struct string_list 
*)stuff->stuff) {
+   if ((*chosen)[i] < 0)
+   (*chosen)[i] = 0;
+   strbuf_addf(&menu, "%s%2d: %s", (*chosen)[i] ? "*" : " 
", ++i, item->string);
+  

[PATCH v9 7/9] git-clean: add select by numbers interactive action

[Jiang Xin]

Draw a multiple choice menu using `list_and_choose` to select items
to be deleted by numbers.

User can input:

 *  1,5-7 : select 1,5,6,7 items to be deleted
 *  * : select all items to be deleted
 *  -*: unselect all, nothing will be deleted
 *: (empty) finish selecting, and return back to main menu

Signed-off-by: Jiang Xin 
---
 builtin/clean.c | 39 +++
 1 file changed, 39 insertions(+)

diff --git a/builtin/clean.c b/builtin/clean.c
index 80cf1..74fc9 100644
--- a/builtin/clean.c
+++ b/builtin/clean.c
@@ -715,6 +715,43 @@ static int filter_by_patterns_cmd(void)
return 0;
 }
 
+static int select_by_numbers_cmd(void)
+{
+   struct menu_opts menu_opts;
+   struct menu_stuff menu_stuff;
+   struct string_list_item *items;
+   int *chosen;
+   int i, j;
+
+   menu_opts.header = NULL;
+   menu_opts.prompt = N_("Select items to delete");
+   menu_opts.flags = 0;
+
+   menu_stuff.type = MENU_STUFF_TYPE_STRING_LIST;
+   menu_stuff.stuff = &del_list;
+   menu_stuff.nr = del_list.nr;
+
+   chosen = list_and_choose(&menu_opts, &menu_stuff);
+   items = del_list.items;
+   for(i = 0, j = 0; i < del_list.nr; i++) {
+   if (i < chosen[j]) {
+   *(items[i].string) = '\0';
+   } else if (i == chosen[j]) {
+   /* delete selected item */
+   j++;
+   continue;
+   } else {
+   /* end of chosen (chosen[j] == EOF), won't delete */
+   *(items[i].string) = '\0';
+   }
+   }
+
+   string_list_remove_empty_items(&del_list, 0);
+
+   free(chosen);
+   return 0;
+}
+
 static int quit_cmd(void)
 {
string_list_clear(&del_list, 0);
@@ -728,6 +765,7 @@ static int help_cmd(void)
printf_ln(_(
"clean   - start cleaning\n"
"filter by pattern   - exclude items from deletion\n"
+   "select by numbers   - select items to be deleted by 
numbers\n"
"quit- stop cleaning\n"
"help- this screen\n"
"?   - help for prompt selection"
@@ -744,6 +782,7 @@ static void interactive_main_loop(void)
struct menu_item menus[] = {
{'c', "clean",  0, clean_cmd},
{'f', "filter by pattern",  0, 
filter_by_patterns_cmd},
+   {'s', "select by numbers",  0, 
select_by_numbers_cmd},
{'q', "quit",   0, quit_cmd},
{'h', "help",   0, help_cmd},
};
-- 
1.8.3.rc1.404.gb9fcf3e

--
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 v9 8/9] git-clean: add ask each interactive action

[Jiang Xin]

Add a new action for interactive git-clean: ask each. It's just like
the "rm -i" command, that the user must confirm one by one for each
file or directory to be cleaned.

Signed-off-by: Jiang Xin 
---
 builtin/clean.c | 36 
 1 file changed, 36 insertions(+)

diff --git a/builtin/clean.c b/builtin/clean.c
index 74fc9..fc68b 100644
--- a/builtin/clean.c
+++ b/builtin/clean.c
@@ -752,6 +752,40 @@ static int select_by_numbers_cmd(void)
return 0;
 }
 
+static int ask_each_cmd(void)
+{
+   struct strbuf confirm = STRBUF_INIT;
+   struct strbuf buf = STRBUF_INIT;
+   struct string_list_item *item;
+   const char *qname;
+   int changed = 0, eof = 0;
+
+   for_each_string_list_item(item, &del_list) {
+   /* Ctrl-D should stop removing files */
+   if (!eof) {
+   qname = quote_path_relative(item->string, -1, &buf, 
NULL);
+   printf(_("remove %s? "), qname);
+   if (strbuf_getline(&confirm, stdin, '\n') != EOF) {
+   strbuf_trim(&confirm);
+   } else {
+   putchar('\n');
+   eof = 1;
+   }
+   }
+   if (!confirm.len || !strncasecmp(confirm.buf, "no", 
confirm.len)) {
+   *item->string = '\0';
+   changed++;
+   }
+   }
+
+   if (changed)
+   string_list_remove_empty_items(&del_list, 0);
+
+   strbuf_release(&buf);
+   strbuf_release(&confirm);
+   return MENU_RETURN_NO_LOOP;
+}
+
 static int quit_cmd(void)
 {
string_list_clear(&del_list, 0);
@@ -766,6 +800,7 @@ static int help_cmd(void)
"clean   - start cleaning\n"
"filter by pattern   - exclude items from deletion\n"
"select by numbers   - select items to be deleted by 
numbers\n"
+   "ask each- confirm each deletion (like \"rm 
-i\")\n"
"quit- stop cleaning\n"
"help- this screen\n"
"?   - help for prompt selection"
@@ -783,6 +818,7 @@ static void interactive_main_loop(void)
{'c', "clean",  0, clean_cmd},
{'f', "filter by pattern",  0, 
filter_by_patterns_cmd},
{'s', "select by numbers",  0, 
select_by_numbers_cmd},
+   {'a', "ask each",   0, ask_each_cmd},
{'q', "quit",   0, quit_cmd},
{'h', "help",   0, help_cmd},
};
-- 
1.8.3.rc1.404.gb9fcf3e

--
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 v9 9/9] git-clean: add documentation for interactive git-clean

[Jiang Xin]

Add new section "Interactive mode" for documentation of interactive
git-clean.

Signed-off-by: Jiang Xin 
Helped-by: Eric Sunshine 
---
 Documentation/git-clean.txt | 65 +++--
 1 file changed, 63 insertions(+), 2 deletions(-)

diff --git a/Documentation/git-clean.txt b/Documentation/git-clean.txt
index 186e34..5bf76 100644
--- a/Documentation/git-clean.txt
+++ b/Documentation/git-clean.txt
@@ -39,8 +39,8 @@ OPTIONS
 
 -i::
 --interactive::
-   Show what would be done and the user must confirm before actually
-   cleaning.
+   Show what would be done and clean files interactively. See
+   ``Interactive mode'' for details.
 
 -n::
 --dry-run::
@@ -69,6 +69,67 @@ OPTIONS
Remove only files ignored by Git.  This may be useful to rebuild
everything from scratch, but keep manually created files.
 
+Interactive mode
+
+When the command enters the interactive mode, it shows the
+files and directories to be cleaned, and goes into its
+interactive command loop.
+
+The command loop shows the list of subcommands available, and
+gives a prompt "What now> ".  In general, when the prompt ends
+with a single '>', you can pick only one of the choices given
+and type return, like this:
+
+
+*** Commands ***
+1: clean2: filter by pattern3: select by numbers
+4: ask each 5: quit 6: help
+What now> 1
+
+
+You also could say `c` or `clean` above as long as the choice is unique.
+
+The main command loop has 6 subcommands.
+
+clean::
+
+   Start cleaning files and directories, and then quit.
+
+filter by pattern::
+
+   This shows the files and directories to be deleted and issues an
+   "Input ignore patterns>>" prompt. You can input space-seperated
+   patterns to exclude files and directories from deletion.
+   E.g. "*.c *.h" will excludes files end with ".c" and ".h" from
+   deletion. When you are satisfied with the filtered result, press
+   ENTER (empty) back to the main menu.
+
+select by numbers::
+
+   This shows the files and directories to be deleted and issues an
+   "Select items to delete>>" prompt. When the prompt ends with double
+   '>>' like this, you can make more than one selection, concatenated
+   with whitespace or comma.  Also you can say ranges.  E.g. "2-5 7,9"
+   to choose 2,3,4,5,7,9 from the list.  If the second number in a
+   range is omitted, all remaining patches are taken.  E.g. "7-" to
+   choose 7,8,9 from the list.  You can say '*' to choose everything.
+   Also when you are satisfied with the filtered result, press ENTER
+   (empty) back to the main menu.
+
+ask each::
+
+  This will start to clean, and you must confirm one by one in order
+  to delete items. Please note that this action is not as efficient
+  as the above two actions.
+
+quit::
+
+  This lets you quit without do cleaning.
+
+help::
+
+  Show brief usage of interactive git-clean.
+
 SEE ALSO
 
 linkgit:gitignore[5]
-- 
1.8.3.rc1.404.gb9fcf3e

--
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 v9 4/9] git-clean: add colors to interactive git-clean

[Jiang Xin]

Show header, help, error messages, and prompt in colors for interactive
git-clean. Re-use config variables, such as "color.interactive" and
"color.interactive." for command `git-add--interactive`.

Signed-off-by: Jiang Xin 
Comments-by: Matthieu Moy 
---
 Documentation/config.txt | 17 +--
 builtin/clean.c  | 73 +++-
 2 files changed, 81 insertions(+), 9 deletions(-)

diff --git a/Documentation/config.txt b/Documentation/config.txt
index e031b..83613 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -876,16 +876,17 @@ The values of these variables may be specified as in 
color.branch..
 
 color.interactive::
When set to `always`, always use colors for interactive prompts
-   and displays (such as those used by "git-add --interactive").
-   When false (or `never`), never.  When set to `true` or `auto`, use
-   colors only when the output is to the terminal. Defaults to false.
+   and displays (such as those used by "git-add --interactive" and
+   "git-clean --interactive"). When false (or `never`), never.
+   When set to `true` or `auto`, use colors only when the output is
+   to the terminal. Defaults to false.
 
 color.interactive.::
-   Use customized color for 'git add --interactive'
-   output. `` may be `prompt`, `header`, `help` or `error`, for
-   four distinct types of normal output from interactive
-   commands.  The values of these variables may be specified as
-   in color.branch..
+   Use customized color for 'git add --interactive' and 'git clean
+   --interactive' output. `` may be `prompt`, `header`, `help`
+   or `error`, for four distinct types of normal output from
+   interactive commands.  The values of these variables may be
+   specified as in color.branch..
 
 color.pager::
A boolean to enable/disable colored output when the pager is in
diff --git a/builtin/clean.c b/builtin/clean.c
index d7c68..5c781 100644
--- a/builtin/clean.c
+++ b/builtin/clean.c
@@ -14,6 +14,7 @@
 #include "string-list.h"
 #include "quote.h"
 #include "column.h"
+#include "color.h"
 
 static int force = -1; /* unset */
 static int interactive;
@@ -31,16 +32,82 @@ static const char *msg_skip_git_dir = N_("Skipping 
repository %s\n");
 static const char *msg_would_skip_git_dir = N_("Would skip repository %s\n");
 static const char *msg_warn_remove_failed = N_("failed to remove %s");
 
+static int clean_use_color = -1;
+static char clean_colors[][COLOR_MAXLEN] = {
+   GIT_COLOR_RESET,
+   GIT_COLOR_NORMAL,   /* PLAIN */
+   GIT_COLOR_BOLD_BLUE,/* PROMPT */
+   GIT_COLOR_BOLD, /* HEADER */
+   GIT_COLOR_BOLD_RED, /* HELP */
+   GIT_COLOR_BOLD_RED, /* ERROR */
+};
+enum color_clean {
+   CLEAN_COLOR_RESET = 0,
+   CLEAN_COLOR_PLAIN = 1,
+   CLEAN_COLOR_PROMPT = 2,
+   CLEAN_COLOR_HEADER = 3,
+   CLEAN_COLOR_HELP = 4,
+   CLEAN_COLOR_ERROR = 5,
+};
+
+static int parse_clean_color_slot(const char *var)
+{
+   if (!strcasecmp(var, "reset"))
+   return CLEAN_COLOR_RESET;
+   if (!strcasecmp(var, "plain"))
+   return CLEAN_COLOR_PLAIN;
+   if (!strcasecmp(var, "prompt"))
+   return CLEAN_COLOR_PROMPT;
+   if (!strcasecmp(var, "header"))
+   return CLEAN_COLOR_HEADER;
+   if (!strcasecmp(var, "help"))
+   return CLEAN_COLOR_HELP;
+   if (!strcasecmp(var, "error"))
+   return CLEAN_COLOR_ERROR;
+   return -1;
+}
+
 static int git_clean_config(const char *var, const char *value, void *cb)
 {
if (!prefixcmp(var, "column."))
return git_column_config(var, value, "clean", &colopts);
 
+   /* honors the color.interactive* config variables which also
+  applied in git-add--interactive and git-stash */
+   if (!strcmp(var, "color.interactive")) {
+   clean_use_color = git_config_colorbool(var, value);
+   return 0;
+   }
+   if (!prefixcmp(var, "color.interactive.")) {
+   int slot = parse_clean_color_slot(var +
+ strlen("color.interactive."));
+   if (slot < 0)
+   return 0;
+   if (!value)
+   return config_error_nonbool(var);
+   color_parse(value, var, clean_colors[slot]);
+   return 0;
+   }
+
if (!strcmp(var, "clean.requireforce")) {
force = !git_config_bool(var, value);
return 0;
}
-   return git_default_config(var, value, cb);
+
+   /* inspect the color.ui config variable and others */
+   return git_color_default_config(var, value, cb);
+}
+
+static const char *clean_get_color(enum color_clean ix)
+{
+   if (want_color(clean_use_color))
+   return clean_colors[ix];
+   return "";
+}
+
+static 

[PATCH v9 6/9] git-clean: add filter by pattern interactive action

[Jiang Xin]

Add a new action for interactive git-clean: filter by pattern. When the
user chooses this action, user can input space-separated patterns (the
same syntax as gitignore), and each clean candidate that matches with
one of the patterns will be excluded from cleaning. When the user feels
it's OK, presses ENTER and back to the confirmation dialog.

Signed-off-by: Jiang Xin 
Suggested-by: Junio C Hamano 
---
 builtin/clean.c | 68 +
 1 file changed, 68 insertions(+)

diff --git a/builtin/clean.c b/builtin/clean.c
index 7930f..80cf1 100644
--- a/builtin/clean.c
+++ b/builtin/clean.c
@@ -649,6 +649,72 @@ static int clean_cmd(void)
return MENU_RETURN_NO_LOOP;
 }
 
+static int filter_by_patterns_cmd(void)
+{
+   struct dir_struct dir;
+   struct strbuf confirm = STRBUF_INIT;
+   struct strbuf **ignore_list;
+   struct string_list_item *item;
+   struct exclude_list *el;
+   int changed = -1, i;
+
+   for (;;) {
+   if (!del_list.nr)
+   break;
+
+   if (changed)
+   pretty_print_dels();
+
+   clean_print_color(CLEAN_COLOR_PROMPT);
+   printf(_("Input ignore patterns>> "));
+   clean_print_color(CLEAN_COLOR_RESET);
+   if (strbuf_getline(&confirm, stdin, '\n') != EOF)
+   strbuf_trim(&confirm);
+   else
+   putchar('\n');
+
+   /* quit filter_by_pattern mode if press ENTER or Ctrl-D */
+   if (!confirm.len)
+   break;
+
+   memset(&dir, 0, sizeof(dir));
+   el = add_exclude_list(&dir, EXC_CMDL, "manual exclude");
+   ignore_list = strbuf_split_max(&confirm, ' ', 0);
+
+   for (i = 0; ignore_list[i]; i++) {
+   strbuf_trim(ignore_list[i]);
+   if (!ignore_list[i]->len)
+   continue;
+
+   add_exclude(ignore_list[i]->buf, "", 0, el, -(i+1));
+   }
+
+   changed = 0;
+   for_each_string_list_item(item, &del_list) {
+   int dtype = DT_UNKNOWN;
+
+   if (is_excluded(&dir, item->string, &dtype)) {
+   *item->string = '\0';
+   changed++;
+   }
+   }
+
+   if (changed) {
+   string_list_remove_empty_items(&del_list, 0);
+   } else {
+   clean_print_color(CLEAN_COLOR_ERROR);
+   printf_ln(_("WARNING: Cannot find items matched by: 
%s"), confirm.buf);
+   clean_print_color(CLEAN_COLOR_RESET);
+   }
+
+   strbuf_list_free(ignore_list);
+   clear_directory(&dir);
+   }
+
+   strbuf_release(&confirm);
+   return 0;
+}
+
 static int quit_cmd(void)
 {
string_list_clear(&del_list, 0);
@@ -661,6 +727,7 @@ static int help_cmd(void)
clean_print_color(CLEAN_COLOR_HELP);
printf_ln(_(
"clean   - start cleaning\n"
+   "filter by pattern   - exclude items from deletion\n"
"quit- stop cleaning\n"
"help- this screen\n"
"?   - help for prompt selection"
@@ -676,6 +743,7 @@ static void interactive_main_loop(void)
struct menu_stuff menu_stuff;
struct menu_item menus[] = {
{'c', "clean",  0, clean_cmd},
+   {'f', "filter by pattern",  0, 
filter_by_patterns_cmd},
{'q', "quit",   0, quit_cmd},
{'h', "help",   0, help_cmd},
};
-- 
1.8.3.rc1.404.gb9fcf3e

--
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 v9 2/9] git-clean: add support for -i/--interactive

[Jiang Xin]

Show what would be done and the user must confirm before actually
cleaning.

Would remove ...
Would remove ...
Would remove ...

Remove [y/n]?

Press "y" to start cleaning, and press "n" if you want to abort.

Signed-off-by: Jiang Xin 
---
 Documentation/git-clean.txt | 10 ++--
 builtin/clean.c | 61 +
 2 files changed, 64 insertions(+), 7 deletions(-)

diff --git a/Documentation/git-clean.txt b/Documentation/git-clean.txt
index bdc3a..186e34 100644
--- a/Documentation/git-clean.txt
+++ b/Documentation/git-clean.txt
@@ -8,7 +8,7 @@ git-clean - Remove untracked files from the working tree
 SYNOPSIS
 
 [verse]
-'git clean' [-d] [-f] [-n] [-q] [-e ] [-x | -X] [--] ...
+'git clean' [-d] [-f] [-i] [-n] [-q] [-e ] [-x | -X] [--] ...
 
 DESCRIPTION
 ---
@@ -34,7 +34,13 @@ OPTIONS
 -f::
 --force::
If the Git configuration variable clean.requireForce is not set
-   to false, 'git clean' will refuse to run unless given -f or -n.
+   to false, 'git clean' will refuse to run unless given -f, -n or
+   -i.
+
+-i::
+--interactive::
+   Show what would be done and the user must confirm before actually
+   cleaning.
 
 -n::
 --dry-run::
diff --git a/builtin/clean.c b/builtin/clean.c
index ccd4..127463 100644
--- a/builtin/clean.c
+++ b/builtin/clean.c
@@ -15,10 +15,11 @@
 #include "quote.h"
 
 static int force = -1; /* unset */
+static int interactive;
 static struct string_list del_list = STRING_LIST_INIT_DUP;
 
 static const char *const builtin_clean_usage[] = {
-   N_("git clean [-d] [-f] [-n] [-q] [-e ] [-x | -X] [--] 
..."),
+   N_("git clean [-d] [-f] [-i] [-n] [-q] [-e ] [-x | -X] [--] 
..."),
NULL
 };
 
@@ -185,6 +186,50 @@ static const char *path_relative(const char *in, const 
char *prefix)
return buf;
 }
 
+static void interactive_main_loop(void)
+{
+   struct strbuf confirm = STRBUF_INIT;
+   struct strbuf buf = STRBUF_INIT;
+   struct string_list_item *item;
+   const char *qname;
+
+   while (del_list.nr) {
+   putchar('\n');
+   for_each_string_list_item(item, &del_list) {
+   qname = quote_path_relative(item->string, -1, &buf, 
NULL);
+   printf(_(msg_would_remove), qname);
+   }
+   putchar('\n');
+
+   printf(_("Remove [y/n]? "));
+   if (strbuf_getline(&confirm, stdin, '\n') != EOF) {
+   strbuf_trim(&confirm);
+   } else {
+   /* Ctrl-D is the same as "quit" */
+   string_list_clear(&del_list, 0);
+   putchar('\n');
+   printf_ln("Bye.");
+   break;
+   }
+
+   if (confirm.len) {
+   if (!strncasecmp(confirm.buf, "yes", confirm.len)) {
+   break;
+   } else if (!strncasecmp(confirm.buf, "no", confirm.len) 
||
+  !strncasecmp(confirm.buf, "quit", 
confirm.len)) {
+   string_list_clear(&del_list, 0);
+   printf_ln("Bye.");
+   break;
+   } else {
+   continue;
+   }
+   }
+   }
+
+   strbuf_release(&buf);
+   strbuf_release(&confirm);
+}
+
 int cmd_clean(int argc, const char **argv, const char *prefix)
 {
int i, res;
@@ -204,6 +249,7 @@ int cmd_clean(int argc, const char **argv, const char 
*prefix)
OPT__QUIET(&quiet, N_("do not print names of files removed")),
OPT__DRY_RUN(&dry_run, N_("dry run")),
OPT__FORCE(&force, N_("force")),
+   OPT_BOOL('i', "interactive", &interactive, N_("interactive 
cleaning")),
OPT_BOOLEAN('d', NULL, &remove_directories,
N_("remove whole directories")),
{ OPTION_CALLBACK, 'e', "exclude", &exclude_list, N_("pattern"),
@@ -230,12 +276,16 @@ int cmd_clean(int argc, const char **argv, const char 
*prefix)
if (ignored && ignored_only)
die(_("-x and -X cannot be used together"));
 
-   if (!dry_run && !force) {
+   if (interactive) {
+   if (!isatty(0) || !isatty(1))
+   die(_("interactive clean can not run without a valid 
tty; "
+ "refusing to clean"));
+   } else if (!dry_run && !force) {
if (config_set)
-   die(_("clean.requireForce set to true and neither -n 
nor -f given; "
+   die(_("clean.requireForce set to true and neither -i, 
-n nor -f given; "
  "refusing to clean"));
else
-   die(_("clean.requireForce defaults to true and ne

[PATCH v9 3/9] git-clean: show items of del_list in columns

[Jiang Xin]

When there are lots of items to be cleaned, it is hard to see them all
in one screen. Show them in columns will solve this problem.

Signed-off-by: Jiang Xin 
Comments-by: Matthieu Moy 
---
 Documentation/config.txt |  4 
 builtin/clean.c  | 49 +++-
 2 files changed, 44 insertions(+), 9 deletions(-)

diff --git a/Documentation/config.txt b/Documentation/config.txt
index 6e53f..e031b 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -955,6 +955,10 @@ column.branch::
Specify whether to output branch listing in `git branch` in columns.
See `column.ui` for details.
 
+column.clean::
+   Specify the layout when list items in `git clean -i`, which always
+   shows files and directories in columns. See `column.ui` for details.
+
 column.status::
Specify whether to output untracked files in `git status` in columns.
See `column.ui` for details.
diff --git a/builtin/clean.c b/builtin/clean.c
index 127463..d7c68 100644
--- a/builtin/clean.c
+++ b/builtin/clean.c
@@ -13,10 +13,12 @@
 #include "refs.h"
 #include "string-list.h"
 #include "quote.h"
+#include "column.h"
 
 static int force = -1; /* unset */
 static int interactive;
 static struct string_list del_list = STRING_LIST_INIT_DUP;
+static unsigned int colopts;
 
 static const char *const builtin_clean_usage[] = {
N_("git clean [-d] [-f] [-i] [-n] [-q] [-e ] [-x | -X] [--] 
..."),
@@ -31,8 +33,13 @@ static const char *msg_warn_remove_failed = N_("failed to 
remove %s");
 
 static int git_clean_config(const char *var, const char *value, void *cb)
 {
-   if (!strcmp(var, "clean.requireforce"))
+   if (!prefixcmp(var, "column."))
+   return git_column_config(var, value, "clean", &colopts);
+
+   if (!strcmp(var, "clean.requireforce")) {
force = !git_config_bool(var, value);
+   return 0;
+   }
return git_default_config(var, value, cb);
 }
 
@@ -186,21 +193,46 @@ static const char *path_relative(const char *in, const 
char *prefix)
return buf;
 }
 
-static void interactive_main_loop(void)
+static void pretty_print_dels(void)
 {
-   struct strbuf confirm = STRBUF_INIT;
-   struct strbuf buf = STRBUF_INIT;
+   struct string_list list = STRING_LIST_INIT_DUP;
struct string_list_item *item;
+   struct strbuf buf = STRBUF_INIT;
const char *qname;
+   struct column_options copts;
+
+   for_each_string_list_item(item, &del_list) {
+   qname = quote_path_relative(item->string, -1, &buf, NULL);
+   string_list_append(&list, qname);
+   }
+
+   /*
+* always enable column display, we only consult column.*
+* about layout strategy and stuff
+*/
+   colopts = (colopts & ~COL_ENABLE_MASK) | COL_ENABLED;
+   memset(&copts, 0, sizeof(copts));
+   copts.indent = "  ";
+   copts.padding = 2;
+   print_columns(&list, colopts, &copts);
+   putchar('\n');
+   strbuf_release(&buf);
+   string_list_clear(&list, 0);
+}
+
+static void interactive_main_loop(void)
+{
+   struct strbuf confirm = STRBUF_INIT;
 
while (del_list.nr) {
putchar('\n');
-   for_each_string_list_item(item, &del_list) {
-   qname = quote_path_relative(item->string, -1, &buf, 
NULL);
-   printf(_(msg_would_remove), qname);
-   }
+   printf_ln(Q_("Would remove the following item:",
+"Would remove the following items:",
+del_list.nr));
putchar('\n');
 
+   pretty_print_dels();
+
printf(_("Remove [y/n]? "));
if (strbuf_getline(&confirm, stdin, '\n') != EOF) {
strbuf_trim(&confirm);
@@ -226,7 +258,6 @@ static void interactive_main_loop(void)
}
}
 
-   strbuf_release(&buf);
strbuf_release(&confirm);
 }
 
-- 
1.8.3.rc1.404.gb9fcf3e

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