Felipe Contreras wrote:
This is what Linux's checkpatch throws:
Perhaps it's time to include checkpatch.pl in our tree and update our
CodingGuidelines?
--
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
Phil Hord phil.h...@gmail.com writes:
On Thu, May 16, 2013 at 4:50 PM, Thomas Rast tr...@inf.ethz.ch 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 about standards for this library or
Johannes Sixt j.s...@viscovery.net 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 abbreviate to
for pat
and
On Thu, May 16, 2013 at 11:18 PM, Eric Sunshine sunsh...@sunshineco.com wrote:
On Wed, May 15, 2013 at 1:56 PM, Torsten Bögershausen tbo...@web.de wrote:
On 2013-05-15 09.11, David Aguilar wrote:
+ ifndef NO_APPLE_COMMON_CRYPTO
+ APPLE_COMMON_CRYPTO = YesPlease
+ endif
One minor change, in accordance with Junio's review. In part 1, I
use:
local z=${GIT_PS1_STATESEPARATOR- }
Instead of the convoluted:
local z=
if [ -n ${GIT_PS1_STATESEPARATOR+set} ]; then
z=${GIT_PS1_STATESEPARATOR}
fi
Everything else is the same. I've rebased it on top of the
So that we can extend it with ZSH-colors in a later patch.
Signed-off-by: Ramkumar Ramachandra artag...@gmail.com
---
contrib/completion/git-prompt.sh | 79 ++--
1 file changed, 43 insertions(+), 36 deletions(-)
diff --git a/contrib/completion/git-prompt.sh
Add colors suitable for use in the ZSH prompt. Having learnt that the
ZSH equivalent of PROMPT_COMMAND is precmd (), you can now use
GIT_PS1_SHOWCOLORHINTS with ZSH.
Signed-off-by: Ramkumar Ramachandra artag...@gmail.com
---
contrib/completion/git-prompt.sh | 40
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 cvsimport to import things
correctly, but if there is a guarantee the import
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
Add subcommand relative_path in test-path-utils, and add test cases
in t0060.
Signed-off-by: Jiang Xin worldhello@gmail.com
---
t/t0060-path-utils.sh | 23 +++
test-path-utils.c | 24
2 files changed, 47 insertions(+)
diff --git
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 worldhello@gmail.com
---
quote.c | 55 ++-
1 file changed, 2 insertions(+), 53 deletions(-)
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
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
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
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 worldhello@gmail.com
---
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 worldhello@gmail.com
Comments-by: Matthieu Moy matthieu@imag.fr
---
Documentation/config.txt | 4
builtin/clean.c |
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
Show header, help, error messages, and prompt in colors for interactive
git-clean. Re-use config variables, such as color.interactive and
color.interactive.slot for command `git-add--interactive`.
Signed-off-by: Jiang Xin worldhello@gmail.com
Comments-by: Matthieu Moy matthieu@imag.fr
---
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,
Add new section Interactive mode for documentation of interactive
git-clean.
Signed-off-by: Jiang Xin worldhello@gmail.com
Helped-by: Eric Sunshine sunsh...@sunshineco.com
---
Documentation/git-clean.txt | 65 +++--
1 file changed, 63 insertions(+), 2
Add test cases for git-clean--interactive.
Signed-off-by: Jiang Xin worldhello@gmail.com
---
t/t7301-clean-interactive.sh | 439 +++
1 file changed, 439 insertions(+)
create mode 100755 t/t7301-clean-interactive.sh
diff --git
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 cvsimport
On Fri, May 17, 2013 at 5:02 AM, Sandor Bodo-Merle sbodome...@gmail.com 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
From: Sandor Bodo-Merle sbodome...@gmail.com
Signed-off-by: Felipe Contreras felipe.contre...@gmail.com
---
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
On Fri, May 17, 2013 at 5:10 AM, Michael Haggerty mhag...@alum.mit.edu 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
[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
+++
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
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 -Gregexp that greps in the patch text)
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 presented
On Fri, May 17, 2013 at 4:00 AM, Thomas Rast tr...@inf.ethz.ch wrote:
Phil Hord phil.h...@gmail.com writes:
On Thu, May 16, 2013 at 4:50 PM, Thomas Rast tr...@inf.ethz.ch wrote:
This is not really meant for external use, but allows the next commit
to neatly distinguish between sub-tests and
On 05/17/2013 01:50 PM, Martin Langhoff wrote:
On Fri, May 17, 2013 at 5:10 AM, Michael Haggerty mhag...@alum.mit.edu
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
On Fri, May 17, 2013 at 9:34 AM, Andreas Krey a.k...@gmx.de 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
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 history,
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
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 m...@mcrowe.com
---
Documentation/git-describe.txt | 9 -
builtin/describe.c | 5 +
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
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 with
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 things
On Fri, May 17, 2013 at 11:22 AM, Junio C Hamano gits...@pobox.com wrote:
Felipe Contreras felipe.contre...@gmail.com 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
Ramkumar Ramachandra artag...@gmail.com 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
Thomas Rast tr...@inf.ethz.ch writes:
Johannes Sixt j.s...@viscovery.net 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
David Aguilar dav...@gmail.com 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
Felipe Contreras felipe.contre...@gmail.com 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
Ramkumar Ramachandra artag...@gmail.com writes:
So that we can extend it with ZSH-colors in a later patch.
Signed-off-by: Ramkumar Ramachandra artag...@gmail.com
---
contrib/completion/git-prompt.sh | 79
++--
1 file changed, 43 insertions(+), 36
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
(remote, ref))? Will we have a remote tracking branch for it
to record what we pushed there the last time? I am guessing that
your
On Fri, May 17, 2013 at 11:56 AM, Matthieu Moy
matthieu@grenoble-inp.fr wrote:
Felipe Contreras felipe.contre...@gmail.com 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
Felipe Contreras felipe.contre...@gmail.com writes:
On Fri, May 17, 2013 at 5:02 AM, Sandor Bodo-Merle sbodome...@gmail.com
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
Felipe Contreras felipe.contre...@gmail.com writes:
On Fri, May 17, 2013 at 11:56 AM, Matthieu Moy
matthieu@grenoble-inp.fr wrote:
Felipe Contreras felipe.contre...@gmail.com writes:
THERE IS NO STYLE BREAKAGE.
Repeating something, and even making it all caps does not make it true.
On Fri, May 17, 2013 at 12:14 PM, Matthieu Moy
matthieu@grenoble-inp.fr wrote:
Felipe Contreras felipe.contre...@gmail.com writes:
On Fri, May 17, 2013 at 11:56 AM, Matthieu Moy
matthieu@grenoble-inp.fr wrote:
Felipe Contreras felipe.contre...@gmail.com writes:
THERE IS NO STYLE
On Fri, May 17, 2013 at 9:53 AM, Junio C Hamano gits...@pobox.com wrote:
David Aguilar dav...@gmail.com 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
Ramkumar Ramachandra artag...@gmail.com 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.
Thomas Rast tr...@inf.ethz.ch 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
On Fri, May 17, 2013 at 12:10 PM, Felipe Contreras
felipe.contre...@gmail.com wrote:
Up to v2.0.
Signed-off-by: Felipe Contreras felipe.contre...@gmail.com
---
contrib/remote-helpers/git-remote-bzr | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
We want this for v1.8.3,
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
On Fri, May 17, 2013 at 4:21 AM, David Aguilar dav...@gmail.com wrote:
On Thu, May 16, 2013 at 11:18 PM, Eric Sunshine sunsh...@sunshineco.com
wrote:
On Wed, May 15, 2013 at 1:56 PM, Torsten Bögershausen tbo...@web.de wrote:
On 2013-05-15 09.11, David Aguilar wrote:
+ ifndef
Felipe Contreras felipe.contre...@gmail.com writes:
On Fri, May 17, 2013 at 12:09 PM, Junio C Hamano gits...@pobox.com wrote:
Felipe Contreras felipe.contre...@gmail.com writes:
On Fri, May 17, 2013 at 5:02 AM, Sandor Bodo-Merle sbodome...@gmail.com
wrote:
apparently this breaks my
Felipe Contreras felipe.contre...@gmail.com writes:
On Fri, May 17, 2013 at 12:10 PM, Felipe Contreras
felipe.contre...@gmail.com wrote:
Up to v2.0.
Is that down to v2.0?
Signed-off-by: Felipe Contreras felipe.contre...@gmail.com
---
contrib/remote-helpers/git-remote-bzr | 6 --
1
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
On Fri, May 17, 2013 at 1:01 PM, Junio C Hamano gits...@pobox.com wrote:
Felipe Contreras felipe.contre...@gmail.com writes:
On Fri, May 17, 2013 at 12:10 PM, Felipe Contreras
felipe.contre...@gmail.com wrote:
Up to v2.0.
Is that down to v2.0?
Signed-off-by: Felipe Contreras
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
Felipe Contreras felipe.contre...@gmail.com 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
Felipe Contreras felipe.contre...@gmail.com writes:
On Fri, May 17, 2013 at 1:01 PM, Junio C Hamano gits...@pobox.com wrote:
Felipe Contreras felipe.contre...@gmail.com writes:
On Fri, May 17, 2013 at 12:10 PM, Felipe Contreras
felipe.contre...@gmail.com wrote:
Up to v2.0.
Is that down to
John Keeping j...@keeping.me.uk 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.
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
Kevin Bracey ke...@bracey.fi 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
On Fri, May 17, 2013 at 2:20 PM, Kevin Bracey ke...@bracey.fi 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
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
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.
Let's specify a merge tool, otherwise mercurial might open one and hang
our tests waiting for user input.
Signed-off-by: Felipe Contreras felipe.contre...@gmail.com
---
contrib/remote-helpers/test-hg-hg-git.sh | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git
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-quotes,
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
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
From: David Aguilar dav...@gmail.com
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
From: David Aguilar dav...@gmail.com
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
From: David Aguilar dav...@gmail.com
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
On Fri, May 17, 2013 at 10:57 AM, Junio C Hamano gits...@pobox.com wrote:
Eric Sunshine sunsh...@sunshineco.com writes:
On Fri, May 17, 2013 at 12:53 PM, Junio C Hamano gits...@pobox.com wrote:
David Aguilar dav...@gmail.com writes:
Do you have advice on how we should proceed? :sigh: sorry
Ramkumar Ramachandra artag...@gmail.com 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
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
Eric Sunshine sunsh...@sunshineco.com writes:
From: David Aguilar dav...@gmail.com
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;
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.current.remote).
However, if we
On Fri, May 17, 2013 at 7:12 PM, Junio C Hamano gits...@pobox.com wrote:
Felipe Contreras felipe.contre...@gmail.com 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.
On Fri, May 17, 2013 at 9:51 PM, David Aguilar dav...@gmail.com wrote:
On Fri, May 17, 2013 at 7:12 PM, Junio C Hamano gits...@pobox.com wrote:
Felipe Contreras felipe.contre...@gmail.com writes:
These remote helpers use 'env python', not PYTHON_PATH, so that's where
we should check for the
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
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
Add subcommand relative_path in test-path-utils, and add test cases
in t0060.
Signed-off-by: Jiang Xin worldhello@gmail.com
---
t/t0060-path-utils.sh | 26 ++
test-path-utils.c | 25 +
2 files changed, 51 insertions(+)
diff --git
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
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 worldhello@gmail.com
---
quote.c | 55 ++-
1 file changed, 2 insertions(+), 53 deletions(-)
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
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 worldhello@gmail.com
Comments-by: Matthieu Moy matthieu@imag.fr
---
Documentation/config.txt | 4
builtin/clean.c |
Show header, help, error messages, and prompt in colors for interactive
git-clean. Re-use config variables, such as color.interactive and
color.interactive.slot for command `git-add--interactive`.
Signed-off-by: Jiang Xin worldhello@gmail.com
Comments-by: Matthieu Moy matthieu@imag.fr
---
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
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,
Add test cases for git-clean--interactive.
Signed-off-by: Jiang Xin worldhello@gmail.com
---
t/t7301-clean-interactive.sh | 439 +++
1 file changed, 439 insertions(+)
create mode 100755 t/t7301-clean-interactive.sh
diff --git
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
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 worldhello@gmail.com
---
builtin/clean.c | 36
1 file changed,
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
Add new section Interactive mode for documentation of interactive
git-clean.
Signed-off-by: Jiang Xin worldhello@gmail.com
Helped-by: Eric Sunshine sunsh...@sunshineco.com
---
Documentation/git-clean.txt | 65 +++--
1 file changed, 63 insertions(+), 2
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 worldhello@gmail.com
---
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 and
100 matches
Mail list logo
