On 05/17/2013 06:10 PM, Eugene Sajine wrote:
> MIchael, sorry for dup - didn't press reply all for the first one.
>
>>
>> So what are you going to do, use cvsimport whenever you cannot *prove*
>> that it is wrong? You sure have low standards for your software.
>
> 1. You are making assumptions a
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 ++--
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-c
Before introducing interactive git-clean, refactor git-clean operations
into two phases:
* hold cleaning items in del_list,
* and remove them in a separate loop at the end.
We will introduce interactive git-clean between the two phases. The
interactive git-clean will show what would be done and
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
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 retur
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, press
Add test cases for git-clean--interactive.
Signed-off-by: Jiang Xin
---
t/t7301-clean-interactive.sh | 439 +++
1 file changed, 439 insertions(+)
create mode 100755 t/t7301-clean-interactive.sh
diff --git a/t/t7301-clean-interactive.sh b/t/t7301-clean-in
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
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 +++---
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 +--
Since there is an enhanced version of relative_path() in path.c,
remove duplicate counterpart path_relative() in quote.c.
Signed-off-by: Jiang Xin
---
quote.c | 55 ++-
1 file changed, 2 insertions(+), 53 deletions(-)
diff --git a/quote.c b/qu
After substitute path_relative() in quote.c with relative_path() from
path.c, parameters (such as len and prefix_len) are obsolete in function
write_name_quoted_relative(). Remove unused parameters from
write_name_quoted_relative() and related functions.
Signed-off-by: Jiang Xin
---
builtin/ls-f
After substitute path_relative() in quote.c with relative_path() from
path.c, parameters (such as len and prefix_len) are obsolete in function
quote_path_relative(). Remove unused parameters and change the order of
parameters for quote_path_relative() function.
Signed-off-by: Jiang Xin
---
built
Original design of relative_path() is simple, just strip the prefix
(*base) from the absolute path (*abs). In most cases, we need a real
relative path, such as: ../foo, ../../bar. That's why there is another
reimplementation (path_relative()) in quote.c.
Refactor relative_path() in path.c to retur
Add subcommand "relative_path" in test-path-utils, and add test cases
in t0060.
Signed-off-by: Jiang Xin
---
t/t0060-path-utils.sh | 26 ++
test-path-utils.c | 25 +
2 files changed, 51 insertions(+)
diff --git a/t/t0060-path-utils.sh b/t/t006
I feel change the order of patch 01/15 and patch 02/15 is better.
I.E. Add test cases for relative_path first, then refactor
relative_path and fix the test cases.
Also fix wrong indent in t/7301.
Differences with gitster/jx/clean-interactive:
diff --git a/Documentation/git-clean.txt b/Documentat
On Fri, May 17, 2013 at 9:51 PM, David Aguilar wrote:
> On Fri, May 17, 2013 at 7:12 PM, Junio C Hamano wrote:
>> Felipe Contreras writes:
>>
>>> These remote helpers use 'env python', not PYTHON_PATH, so that's where
>>> we should check for the extensions. Otherwise, if 'python' is not
>>> PYTH
On Fri, May 17, 2013 at 7:12 PM, Junio C Hamano wrote:
> Felipe Contreras writes:
>
>> These remote helpers use 'env python', not PYTHON_PATH, so that's where
>> we should check for the extensions. Otherwise, if 'python' is not
>> PYTHON_PATH (e.g. /usr/bin/python: Makefile's default), there will
When the user has an upstream branch configured to track a remote
tracking branch:
% git checkout --set-upstream-to github/master
Doing a 'git fetch' without any arguments would try to fetch 'github',
because it's configured as current branch's remote
(branch..remote).
However, if we do someth
Felipe Contreras writes:
> These remote helpers use 'env python', not PYTHON_PATH, so that's where
> we should check for the extensions. Otherwise, if 'python' is not
> PYTHON_PATH (e.g. /usr/bin/python: Makefile's default), there will be a
> mismatch between the python libraries actually accessi
Eric Sunshine writes:
> From: David Aguilar
>
> As of Mac OS X 10.7, Apple deprecated all OpenSSL functions due to
> OpenSSL ABI instability. Silence the warnings by using Apple's
> CommonCrypto HMAC replacement functions.
>
> [es: reworded commit message; eliminated abuse of
> COMMON_DIGEST_FO
As I already said, I think calling this as pickaxe-regex is wrong
("invalid regex" is fine, though). More on this in the review for
[2/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.ke
Ramkumar Ramachandra writes:
> diff --git a/Documentation/diff-options.txt b/Documentation/diff-options.txt
> index 104579d..b61a666 100644
> --- a/Documentation/diff-options.txt
> +++ b/Documentation/diff-options.txt
> @@ -383,14 +383,35 @@ ifndef::git-format-patch[]
> that matches other c
On Fri, May 17, 2013 at 10:57 AM, Junio C Hamano wrote:
> Eric Sunshine writes:
>
>> On Fri, May 17, 2013 at 12:53 PM, Junio C Hamano wrote:
>>> David Aguilar writes:
>>>
Do you have advice on how we should proceed? :sigh: sorry for wasting
so much maintainer time on this series alre
From: David Aguilar
As of Mac OS X 10.7, Apple deprecated all OpenSSL functions due to
OpenSSL ABI instability. Silence the warnings by using Apple's
CommonCrypto HMAC replacement functions.
[es: reworded commit message; eliminated abuse of
COMMON_DIGEST_FOR_OPENSSL by checking NO_APPLE_COMMON_
From: David Aguilar
As of Mac OS X 10.7, Apple deprecated all OpenSSL functions due to
OpenSSL ABI instability, thus leading to build warnings. As a
replacement, Apple encourages developers to migrate to its own (stable)
CommonCrypto facility.
Introduce boilerplate which controls whether Apple'
From: David Aguilar
As of Mac OS X 10.7, Apple deprecated all OpenSSL functions due to
OpenSSL ABI instability, thus leading to build diagnostics such as:
warning: 'SHA1_Init' is deprecated
(declared at /usr/include/openssl/sha.h:121)
Silence the warnings by using Apple's Common
This is a re-roll of David Aguilar's patch series which eliminates some
of the OpenSSL deprecation warnings on Mac OS X.
Patch 1 is new. It extracts the CommonCrypto-related Makefile
boilerplate, from his SHA-1-related patch, into a distinct introductory
patch which can then be referenced by subse
A release candidate Git v1.8.3-rc3 is now available for testing
at the usual places.
I originally said this cycle will have only up to -rc2 and we were
supposed to have the final release today, but we needed to apply
last minute fixes patch to breakages in a few areas this week, so we
will be dela
Am 17.05.2013 19:02, schrieb Thomas Rast:
> At this point the splitting has already happened in the caller when it
> does the (refactored)
>
> + if match_pattern_list $this_test.$test_count $GIT_SKIP_TESTS
>
> So $@ and "$@" is actually the same thing.
Not in general: If you omit the double-
These remote helpers use 'env python', not PYTHON_PATH, so that's where
we should check for the extensions. Otherwise, if 'python' is not
PYTHON_PATH (e.g. /usr/bin/python: Makefile's default), there will be a
mismatch between the python libraries actually accessible to the remote
helpers.
Suggest
Let's specify a merge tool, otherwise mercurial might open one and hang
our tests waiting for user input.
Signed-off-by: Felipe Contreras
---
contrib/remote-helpers/test-hg-hg-git.sh | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/contrib/remote-helpers/test-hg-hg-git.
Hi,
I've setup a project in Travis CI for continuous integration with very good
results, however, I had to apply a couple of fixes.
I'm not sure if this is v1.8.3 material, but here they are.
https://travis-ci.org/felipec/git/builds/7262886
Felipe Contreras (2):
remote-helpers: tests: use pyt
Only consider the first parent commit when walking the commit history. This
is useful if you only wish to match tags on your branch after a merge.
Signed-off-by: Mike Crowe
---
Documentation/git-describe.txt |9 -
builtin/describe.c |5 +
t/t6120-describe.sh
Greetings Git Developers,
I just used git-remote-hg to convert a small hg repository.
It worked perfectly.
Thanks, and happy hacking,
Samuel
--
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://vge
On Fri, May 17, 2013 at 2:51 PM, Junio C Hamano wrote:
> Kevin Bracey writes:
>
>> On 15/05/2013 23:34, Felipe Contreras wrote:
>>> I think I'm using 'upstream' for something it was not intended to,
>>> and
>>> I think the current 'upstream' behavior should be split into
>>> 'upstream' and 'bas
On Fri, May 17, 2013 at 2:20 PM, Kevin Bracey wrote:
> On 15/05/2013 23:34, Felipe Contreras wrote:
>>
>> I think I'm using 'upstream' for something it was not intended to, and
>> I think the current 'upstream' behavior should be split into
>> 'upstream' and 'base'.
>>
> I found myself thinking
Kevin Bracey writes:
> On 15/05/2013 23:34, Felipe Contreras wrote:
>> I think I'm using 'upstream' for something it was not intended to,
>> and
>> I think the current 'upstream' behavior should be split into
>> 'upstream' and 'base'.
>>
> I found myself thinking the same thing. It's really con
On 15/05/2013 23:34, Felipe Contreras wrote:
I think I'm using 'upstream' for something it was not intended to, and
I think the current 'upstream' behavior should be split into
'upstream' and 'base'.
I found myself thinking the same thing. It's really convenient being
able to set your topic
John Keeping writes:
> It can't ever happen because we only call this if the mode is non-zero
> in which case the SHA-1 is only null if there are unstaged changes.
>
> However, I think this revised version is much clearer.
Yes, that makes the intention crystal clear. I like it.
>
> git-diffto
Felipe Contreras writes:
> On Fri, May 17, 2013 at 1:01 PM, Junio C Hamano wrote:
>> Felipe Contreras writes:
>>
>>> On Fri, May 17, 2013 at 12:10 PM, Felipe Contreras
>>> wrote:
Up to v2.0.
>>
>> Is that "down to v2.0"?
Is that 'down to v2.0'?
>>
Signed-off-by: Felipe Con
Felipe Contreras writes:
> This is irrelevant, it's an implementation detail of 'git pull'. *THE
> USER* is not running 'git fetch .'
To those who fear running "git pull", the following has worked as a
quick way to "preview" what they would be getting.
git fetch
git log ..FETCH_
Commit 02c5631 (difftool --dir-diff: symlink all files matching the
working tree, 2013-03-14) does not handle the case where a file that is
being compared does not exist in the working tree. Fix this by checking
for existence explicitly before running git-hash-object.
Reported-by: Kevin Bracey
S
On Fri, May 17, 2013 at 1:01 PM, Junio C Hamano wrote:
> Felipe Contreras writes:
>
>> On Fri, May 17, 2013 at 12:10 PM, Felipe Contreras
>> wrote:
>>> Up to v2.0.
>
> Is that "down to v2.0"?
>
>>>
>>> Signed-off-by: Felipe Contreras
>>> ---
>>> contrib/remote-helpers/git-remote-bzr | 6 --
John Keeping writes:
> Commit 02c5631 (difftool --dir-diff: symlink all files matching the
> working tree, 2013-03-14) does not handle the case where a file that is
> being compared does not exist in the working tree. Fix this by checking
> for existence explicitly before running git-hash-object
Hi, i am using git to push my code from eclipse to heroku , but
recently iam getting error like::
master:master rejected:non fast forward
and i am not able to resolve it .I tried a git pull but that says -
conflicts shud be resolved before git pull can be implemented.I can;t
find the solution P
Felipe Contreras writes:
> On Fri, May 17, 2013 at 12:10 PM, Felipe Contreras
> wrote:
>> Up to v2.0.
Is that "down to v2.0"?
>>
>> Signed-off-by: Felipe Contreras
>> ---
>> contrib/remote-helpers/git-remote-bzr | 6 --
>> 1 file changed, 4 insertions(+), 2 deletions(-)
>
> We want this
Felipe Contreras writes:
> On Fri, May 17, 2013 at 12:09 PM, Junio C Hamano wrote:
>> Felipe Contreras writes:
>>
>>> On Fri, May 17, 2013 at 5:02 AM, Sandor Bodo-Merle
>>> wrote:
>>>
apparently this breaks my existing clone of the bugzilla repository, where
i
have branches cl
Eric Sunshine writes:
> On Fri, May 17, 2013 at 12:53 PM, Junio C Hamano wrote:
>> David Aguilar writes:
>>
>>> Do you have advice on how we should proceed? :sigh: sorry for wasting
>>> so much maintainer time on this series already. If you need any
>>> resends or anything please let me know.
Ramkumar Ramachandra writes:
> Junio C Hamano wrote:
>
>> Side note: I do not think "fork" rings bell to the end
>> users. Who is forking from what? I am guessing you are
>> trying to make a short form of "the branch in my public
>> pepository I push this branch
On Fri, May 17, 2013 at 4:21 AM, David Aguilar wrote:
> On Thu, May 16, 2013 at 11:18 PM, Eric Sunshine
> wrote:
>> On Wed, May 15, 2013 at 1:56 PM, Torsten Bögershausen wrote:
>>> On 2013-05-15 09.11, David Aguilar wrote:
+ ifndef NO_APPLE_COMMON_CRYPTO
+ APPLE_COMMON
Commit 02c5631 (difftool --dir-diff: symlink all files matching the
working tree, 2013-03-14) does not handle the case where a file that is
being compared does not exist in the working tree. Fix this by checking
for existence explicitly before running git-hash-object.
Reported-by: Kevin Bracey
S
On Fri, May 17, 2013 at 12:53 PM, Junio C Hamano wrote:
> David Aguilar writes:
>
>> Do you have advice on how we should proceed? :sigh: sorry for wasting
>> so much maintainer time on this series already. If you need any
>> resends or anything please let me know. This time I'll wait for a
>>
On Fri, May 17, 2013 at 12:10 PM, Felipe Contreras
wrote:
> Up to v2.0.
>
> Signed-off-by: Felipe Contreras
> ---
> contrib/remote-helpers/git-remote-bzr | 6 --
> 1 file changed, 4 insertions(+), 2 deletions(-)
We want this for v1.8.3, otherwise it wouldn't work in older versions of bzr.
Junio C Hamano wrote:
> Doesn't Duy's more recent work on the pretty-format front introduce
> alignment operators?
Oh, awesome. I know where to steal that from now ;)
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More major
Thomas Rast writes:
> At this point the splitting has already happened in the caller when it
> does the (refactored)
>
> + if match_pattern_list $this_test.$test_count $GIT_SKIP_TESTS
>
> So $@ and "$@" is actually the same thing.
Ah, then it is perfect. Thanks.
--
To unsubscribe from this
Ramkumar Ramachandra writes:
> I just have one major doubt: in the above output, how do I align all
> the upstream branches to the same column? How can I achieve it with
> pretty-formats? Something like %*d? But * is already taken to mean
> deref in for-each-ref's --format.
Doesn't Duy's
On Fri, May 17, 2013 at 9:53 AM, Junio C Hamano wrote:
> David Aguilar writes:
>
>> Do you have advice on how we should proceed? :sigh: sorry for wasting
>> so much maintainer time on this series already. If you need any
>> resends or anything please let me know. This time I'll wait for a
>> s
On Fri, May 17, 2013 at 12:14 PM, Matthieu Moy
wrote:
> Felipe Contreras writes:
>
>> On Fri, May 17, 2013 at 11:56 AM, Matthieu Moy
>> wrote:
>>> Felipe Contreras writes:
>>>
THERE IS NO STYLE BREAKAGE.
>>>
>>> Repeating something, and even making it all caps does not make it true.
>>
>>
Felipe Contreras writes:
> On Fri, May 17, 2013 at 11:56 AM, Matthieu Moy
> wrote:
>> Felipe Contreras writes:
>>
>>> THERE IS NO STYLE BREAKAGE.
>>
>> Repeating something, and even making it all caps does not make it true.
>
> Tell that to Junio. He is also repeating the same.
Junio explained
Up to v2.0.
Signed-off-by: Felipe Contreras
---
contrib/remote-helpers/git-remote-bzr | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/contrib/remote-helpers/git-remote-bzr
b/contrib/remote-helpers/git-remote-bzr
index ad42317..51b4a29 100755
--- a/contrib/remote-helper
On Fri, May 17, 2013 at 12:09 PM, Junio C Hamano wrote:
> Felipe Contreras writes:
>
>> On Fri, May 17, 2013 at 5:02 AM, Sandor Bodo-Merle
>> wrote:
>>
>>> apparently this breaks my existing clone of the bugzilla repository, where i
>>> have branches cloned with versions of remote-bzr prior 1.8
Felipe Contreras writes:
> On Fri, May 17, 2013 at 5:02 AM, Sandor Bodo-Merle
> wrote:
>
>> apparently this breaks my existing clone of the bugzilla repository, where i
>> have branches cloned with versions of remote-bzr prior 1.8.2 and after. The
>> erro iget is:
>>
>> Fetching origin
>> Trace
On Fri, May 17, 2013 at 11:56 AM, Matthieu Moy
wrote:
> Felipe Contreras writes:
>
>> THERE IS NO STYLE BREAKAGE.
>
> Repeating something, and even making it all caps does not make it true.
Tell that to Junio. He is also repeating the same.
I actually provided *evidence*. Did you miss it?
> Yo
Junio C Hamano writes:
> Thomas Rast writes:
>
>> Johannes Sixt writes:
>>
>>> Am 5/16/2013 22:50, schrieb Thomas Rast:
+match_pattern_list () {
+ arg="$1"
+ shift
+ test -z "$*" && return 1
+ for pat in $@
>>>
>>> You should have double-quotes around $@ here, but t
Junio C Hamano wrote:
> Please clarify the semantics of @{f}. Does it conceptually refer to
> where the current branch is going to be pushed to (i.e. a pair of
> (, ))? Will we have a remote tracking branch for it
> to record what we pushed there the last time? I am guessing that
> your answers
Ramkumar Ramachandra writes:
> So that we can extend it with ZSH-colors in a later patch.
>
> Signed-off-by: Ramkumar Ramachandra
> ---
> contrib/completion/git-prompt.sh | 79
> ++--
> 1 file changed, 43 insertions(+), 36 deletions(-)
>
> diff --git a/contr
Felipe Contreras writes:
> THERE IS NO STYLE BREAKAGE.
Repeating something, and even making it all caps does not make it true.
You are wasting your time and everybody else's in this thread and many
others. You seem to reject the very concept of code review. The Git
community likes very much cod
David Aguilar writes:
> Do you have advice on how we should proceed? :sigh: sorry for wasting
> so much maintainer time on this series already. If you need any
> resends or anything please let me know. This time I'll wait for a
> strong opinion before firing off patches.
>
> My opinion: yeah,
Thomas Rast writes:
> Johannes Sixt writes:
>
>> Am 5/16/2013 22:50, schrieb Thomas Rast:
>>> +match_pattern_list () {
>>> + arg="$1"
>>> + shift
>>> + test -z "$*" && return 1
>>> + for pat in $@
>>
>> You should have double-quotes around $@ here, but then you can just as
>> well abbrev
Ramkumar Ramachandra writes:
> Which is the exact argument I presented on the other thread. However,
> Felipe has a point: we shouldn't cripple @{f} (I think "fork" is a
> good name for it) in the name of generality.
Please clarify the semantics of @{f}. Does it conceptually refer to
where the
On Fri, May 17, 2013 at 11:22 AM, Junio C Hamano wrote:
> Felipe Contreras writes:
>
>> *You* are telling my that; it's *your* opinion and nothing else. It's
>
> I saw a review comment that points out that the continuation lines
> do not align, and you refused to say "ah, thanks for spotting" and
Felipe Contreras writes:
> *You* are telling my that; it's *your* opinion and nothing else. It's
I saw a review comment that points out that the continuation lines
do not align, and you refused to say "ah, thanks for spotting" and
reroll [*1*], so even I do not want to do so in general, I had to
MIchael, sorry for dup - didn't press reply all for the first one.
>
> So what are you going to do, use cvsimport whenever you cannot *prove*
> that it is wrong? You sure have low standards for your software.
1. You are making assumptions and conclusions that have no grounds.
I asked for help un
On 05/17/2013 03:34 PM, Andreas Krey wrote:
> On Fri, 17 May 2013 15:14:58 +, Michael Haggerty wrote:
> ...
>> We both know that the CVS history omits important data, and that the
>> history is mutable, etc. So there are lots of hypothetical histories
>> that do not contradict CVS. But some t
On Fri, May 17, 2013 at 04:03:29PM +0100, John Keeping wrote:
> On Fri, May 17, 2013 at 03:24:26PM +0100, Mike Crowe wrote:
> > Only consider the first parent commit when walking the commit history. This
> > is useful if you only wish to match tags on your branch after a merge.
>
> For consistency
On Fri, May 17, 2013 at 03:24:26PM +0100, Mike Crowe wrote:
> Only consider the first parent commit when walking the commit history. This
> is useful if you only wish to match tags on your branch after a merge.
For consistency with "git log" should this be called "--first-parent"?
In "git log" --
Only consider the first parent commit when walking the commit history. This
is useful if you only wish to match tags on your branch after a merge.
Signed-off-by: Mike Crowe
---
Documentation/git-describe.txt | 9 -
builtin/describe.c | 5 +
t/t6120-describe.sh
You can now do something like
$ git for-each-ref --format='%C(red)%(refname:short)%C(reset)
%C(blue)%(upstream:diff)%C(reset)' --count 5 --sort='-committerdate'
refs/heads
To get output that's much more customizable 'git branch' output. Future
patches will attempt unify the semantics of 'git bra
On Fri, 17 May 2013 15:14:58 +, Michael Haggerty wrote:
...
> We both know that the CVS history omits important data, and that the
> history is mutable, etc. So there are lots of hypothetical histories
> that do not contradict CVS. But some things are recorded unambiguously
> in the CVS histo
On Fri, May 17, 2013 at 9:34 AM, Andreas Krey wrote:
> On Fri, 17 May 2013 15:14:58 +, Michael Haggerty wrote:
> ...
>> We both know that the CVS history omits important data, and that the
>> history is mutable, etc. So there are lots of hypothetical histories
>> that do not contradict CVS.
On 05/17/2013 01:50 PM, Martin Langhoff wrote:
> On Fri, May 17, 2013 at 5:10 AM, Michael Haggerty
> wrote:
>> For one-time imports, the fix is to use a tool that is not broken, like
>> cvs2git.
>
> As one of the earlier maintainers of cvsimport, I do believe that
> cvs2git is less broken, for o
On Fri, May 17, 2013 at 4:00 AM, Thomas Rast wrote:
> Phil Hord writes:
>
>> On Thu, May 16, 2013 at 4:50 PM, Thomas Rast wrote:
>>> This is not really meant for external use, but allows the next commit
>>> to neatly distinguish between sub-tests and the main run.
>>
>> Maybe we do not care abou
Junio C Hamano wrote:
> Actually, I suspect that you shouldn't even need to do that
> pros-and-cons analysis, because the 'single' thing should cover as a
> natural extension of the existing infrastructure. You should only
> need to have something like this:
Which is the exact argument I presente
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 err
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)
Inpu
[1/2] is unchangd, but [2/2] has some major changes: thanks to inputs
from Junio and Phil. The inter-diff for [2/2] follows.
diff --git a/Documentation/diff-options.txt b/Documentation/diff-options.txt
index 765abc5..b61a666 100644
--- a/Documentation/diff-options.txt
+++ b/Documentation/diff-opt
On Fri, May 17, 2013 at 5:10 AM, Michael Haggerty wrote:
> For one-time imports, the fix is to use a tool that is not broken, like
> cvs2git.
As one of the earlier maintainers of cvsimport, I do believe that
cvs2git is less broken, for one-shot imports, than cvsimport. Users
looking for a one-sho
From: Sandor Bodo-Merle
Signed-off-by: Felipe Contreras
---
contrib/remote-helpers/git-remote-bzr | 2 ++
1 file changed, 2 insertions(+)
diff --git a/contrib/remote-helpers/git-remote-bzr
b/contrib/remote-helpers/git-remote-bzr
index ad42317..8ecee67 100755
--- a/contrib/remote-helpers/git-r
On Fri, May 17, 2013 at 5:02 AM, Sandor Bodo-Merle wrote:
> apparently this breaks my existing clone of the bugzilla repository, where i
> have branches cloned with versions of remote-bzr prior 1.8.2 and after. The
> erro iget is:
>
> Fetching origin
> Traceback (most recent call last):
> File
On Fri, May 17, 2013 at 11:10:03AM +0200, Michael Haggerty wrote:
> On 05/15/2013 08:03 PM, Eugene Sajine wrote:
> > My primary goal was to understand better what are the real problems
> > that we might have with the way we use git cvsimport, so I was not
> > asking about the guarantee of the cvsim
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-c
Add test cases for git-clean--interactive.
Signed-off-by: Jiang Xin
---
t/t7301-clean-interactive.sh | 439 +++
1 file changed, 439 insertions(+)
create mode 100755 t/t7301-clean-interactive.sh
diff --git a/t/t7301-clean-interactive.sh b/t/t7301-clean-in
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, press
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 +--
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
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
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 retur
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 +++---
1 - 100 of 116 matches
Mail list logo
