Junio C Hamano writes:
> In addition to your topic, it may be a good idea to notice this at
> the Porcelain level (e.g. "checkout -b" and "branch", but not at the
> "update-ref" level) and warn or even die if a Porcelain tries to
> create a branch with such a name.
But if we're going there and d
Junio C Hamano writes:
> * tr/test-v-and-v-subtest-only (2013-05-16) 6 commits
> - test-lib: support running tests under valgrind in parallel
> - test-lib: allow prefixing a custom string before "ok N" etc.
> - test-lib: valgrind for only tests matching a pattern
> - test-lib: verbose mode fo
[+CC: Matthieu Moy]
Mathieu Liénard--Mayor wrote:
> -Cleaner error message when "git rm" fails with multiple files
Should be fairly straightforward to implement. Just collect the
errors and print them out at once.
> -Add configuration options for some commonly used command-line options
I'd rea
From: "Junio C Hamano"
Sent: Monday, May 20, 2013 11:22 PM
"Philip Oakley" writes:
So we can have a branch whose remote is '.'
_and_ a remote whose URL is '.'
Yes, and they are two separate concepts.
Thank you of the confirmation.
"git fetch" while on "mywork" branch with this:
[bra
On Mon, May 20, 2013 at 03:36:58PM -0700, Junio C Hamano wrote:
> Dmitry Marakasov writes:
>
> > Use /bin/sh interpreter instead of /bin/bash for contrib/git-subtree:
> > it's required for systems which don't use bash by default (for example,
> > FreeBSD), while there seem to be no bashisms in th
On Tue, May 21, 2013 at 10:59:17AM +1000, Quilkey, Tony wrote:
> I am looking at formulating and then documenting our vcs workflow
> using Git at work. I have an idea of how I want things to work, but am
> a little hazy on some of the details.
>
> Our basic workflow will be based around:
> http://
Hi,
Seeing other patches on the list, I decided that I should do something
for 1.8.3 as well (as opposed to constantly writing new features). So
here's my contribution.
The first error message has annoyed me endlessly, and I took this
opportunity to fix it. Interested people can sprinkle in som
Currently, when no (valid) upstream is configured for a branch, we get
an error like:
$ git show @{u}
error: No upstream configured for branch 'upstream-error'
error: No upstream configured for branch 'upstream-error'
fatal: ambiguous argument '@{u}': unknown revision or path not in the wo
Currently, when we try to resolve @{} or @{} when the reflog
for the current branch doesn't go back far enough, we get errors like:
$ git show @{1}
fatal: Log for '' only has 7 entries.
$ git show @{1.days.ago}
warning: Log for '' only goes back to Tue, 21 May 2013 14:14:45 +0530.
Junio C Hamano writes:
> * mm/color-auto-default (2013-05-15) 2 commits
> - make color.ui default to 'auto'
> - config: refactor management of color.ui's default value
>
> Flip the default for color.ui to 'auto', which is what many
> tutorials recommend new users to do.
>
> I think this is r
On Friday, May 17, 2013 at 14:02 EDT,
ASHISH VERMA wrote:
> 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
On Monday, May 20, 2013 at 20:59 EDT,
"Quilkey, Tony" wrote:
> I am looking at formulating and then documenting our vcs workflow
> using Git at work. I have an idea of how I want things to work, but am
> a little hazy on some of the details.
>
> Our basic workflow will be based around:
> ht
On 2013-05-21 02:59, Quilkey, Tony wrote:
Hi,
I am looking at formulating and then documenting our vcs workflow
using Git at work. I have an idea of how I want things to work, but am
a little hazy on some of the details.
Our basic workflow will be based around:
http://nvie.com/posts/a-successfu
Thomas Rast writes:
> Junio C Hamano writes:
>
>> In addition to your topic, it may be a good idea to notice this at
>> the Porcelain level (e.g. "checkout -b" and "branch", but not at the
>> "update-ref" level) and warn or even die if a Porcelain tries to
>> create a branch with such a name.
>
Johan Herland writes:
> On Tue, May 21, 2013 at 2:15 AM, Junio C Hamano wrote:
>> * jh/shorten-refname (2013-05-07) 4 commits
>> - t1514: refname shortening is done after dereferencing symbolic refs
>> - shorten_unambiguous_ref(): Fix shortening refs/remotes/origin/HEAD to
>> origin
>> - t15
Thomas Rast writes:
> Junio C Hamano writes:
>
>> * tr/test-v-and-v-subtest-only (2013-05-16) 6 commits
>> - test-lib: support running tests under valgrind in parallel
>> - test-lib: allow prefixing a custom string before "ok N" etc.
>> - test-lib: valgrind for only tests matching a pattern
>
Matthieu Moy writes:
> Junio C Hamano writes:
>
>> * mm/color-auto-default (2013-05-15) 2 commits
>> - make color.ui default to 'auto'
>> - config: refactor management of color.ui's default value
>>
>> Flip the default for color.ui to 'auto', which is what many
>> tutorials recommend new use
"Philip Oakley" writes:
> From: "Junio C Hamano"
> Sent: Monday, May 20, 2013 11:22 PM
>> "Philip Oakley" writes:
>>
>>> So we can have a branch whose remote is '.'
>>> _and_ a remote whose URL is '.'
>>
>> Yes, and they are two separate concepts.
> Thank you of the confirmation.
>
>>
>> "git f
Felipe Contreras writes:
> On Mon, May 20, 2013 at 7:33 PM, Felipe Contreras
> wrote:
>> zsh completion wrapper doesn't reimplement __gitcompadd(). Although it
>> should be trivial to do that, let's use __gitcomp_nl() which achieves
>> exactly the same thing, specially since the suffix ($4) has
Felipe Contreras writes:
> Otherwise with certain remote helpers (the ones that support 'export'),
> the users will be pushing to the wrong branch:
>
> git push topic:master
>
> Will push the topic branch, as if the user typed:
>
> git push topic
>
> Signed-off-by: Felipe Contreras
> ---
>
>
Ramkumar Ramachandra writes:
> [+CC: Matthieu Moy]
>
> Mathieu Liénard--Mayor wrote:
>> -Cleaner error message when "git rm" fails with multiple files
>
> Should be fairly straightforward to implement. Just collect the
> errors and print them out at once.
>
>> -Add configuration options for some
Ramkumar Ramachandra writes:
> Seeing other patches on the list, I decided that I should do something
> for 1.8.3 as well
Fixes to something that are broken the same way between 'master' and
older release versions are the same as enhancements (which you can
view as "fix to lack of feature"). Th
Ramkumar Ramachandra writes:
> Currently, when no (valid) upstream is configured for a branch, we get
> an error like:
>
> $ git show @{u}
> error: No upstream configured for branch 'upstream-error'
> error: No upstream configured for branch 'upstream-error'
> fatal: ambiguous argument '@
Ramkumar Ramachandra writes:
> Currently, when we try to resolve @{} or @{} when the reflog
> for the current branch doesn't go back far enough, we get errors like:
>
> $ git show @{1}
> fatal: Log for '' only has 7 entries.
>
> $ git show @{1.days.ago}
> warning: Log for '' only
Felipe Contreras writes:
> Certain remote-helpers (the ones with 'export') would try to push
> regardless.
>
> Obviously this is not what the user wants.
>
> Also, add a check for the 'dry-run' option, so remote-helpers can
> implement it.
This sounds like a good thing to do. Perhaps the refspe
Will apply for 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
Nguyễn Thái Ngọc Duy writes:
> This series introduces:
>
> - %(current), which either shows "*" if the ref is pointed by HEAD
>or a space. Junio called it %(headness). I don't like that.
>I don't like %(current) either but we have to start somewhere.
>Name suggestion? %(marker)??
"
Michael Haggerty writes:
> Instead of accepting an array and using exactly two elements from the
> array, take two single (struct object_array_entry *) arguments.
>
> Signed-off-by: Michael Haggerty
> ---
> builtin/diff.c | 18 +-
> 1 file changed, 9 insertions(+), 9 deletions(-
Michael Haggerty writes:
> Change cmd_diff() to use a (struct object_array) for holding the trees
> that it accumulates, rather than rolling its own equivalent.
>
A significant detail missing here is that this lifts the hardcoded
100 tree limit in combined diff but that does not matter in
practi
Michael Haggerty writes:
> Signed-off-by: Michael Haggerty
> ---
> revision.c | 20 ++--
> revision.h | 32 +---
> 2 files changed, 35 insertions(+), 17 deletions(-)
Looks obviously good for *.c file, but I am on the fence for *.h
one, as the reason
Michael Haggerty writes:
> The condition under which gc_boundary() is called was previously
>
> if (alloc <= nr)
>
> . But by construction, nr can never exceed alloc, so the check looks
> unnecessarily mysterious. In fact, the purpose of the check is to try
> to avoid a realloc() call by sh
Michael Haggerty writes:
> There is no logical reason for this test to be here. At the caller we
> might be able to figure out its meaning.
>
> Signed-off-by: Michael Haggerty
> ---
I do not think this change is justified, *unless* the caller later
in the series gains a better heuristics than
Junio C Hamano wrote:
> Fixes to something that are broken the same way between 'master' and
> older release versions are the same as enhancements (which you can
> view as "fix to lack of feature"). They are not regression fixes
> and not for 1.8.3 at this point in the cycle, deep into -rc.
If we
On 21/05/2013 19:52, Junio C Hamano wrote:
Ramkumar Ramachandra writes:
The empty string '' looks ugly and inconsistent with the output of
@{}. Replace it with the string 'current branch'.
Wouldn't that be '*the* current branch'?
More importantly, doesn't "real_ref" have the name of the bra
Junio C Hamano wrote:
> Does a failure in interpret-branch-name that issue these error
> messages always followed by die() in the caller? I know you looked
> at the cases you noticed as an end-user (like the above "git show @{u}"
> example), but if some codepaths did this:
>
> if (interpre
Ramkumar Ramachandra writes:
> So, is it
> because that version was too long ago that we don't consider it a
> regression (do we backport fixes)?
The "regression fixes" pre-release -rc period is for is to make sure
to avoid unwanted/unintended behaviour changes between releases.
People have _al
Ramkumar Ramachandra writes:
> Junio C Hamano wrote:
>> Does a failure in interpret-branch-name that issue these error
>> messages always followed by die() in the caller? I know you looked
>> at the cases you noticed as an end-user (like the above "git show @{u}"
>> example), but if some codepat
Junio C Hamano wrote:
> So did you or did you not audit the codepath?
No; I was explaining why I didn't in the first place. Going through it now.
--
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://
Ramkumar Ramachandra writes:
> Junio C Hamano wrote:
>> So did you or did you not audit the codepath?
>
> No; I was explaining why I didn't in the first place. Going through it now.
I did not mean "You must do so or we should discard the patch". I
just wanted to make sure the log messages say
Junio C Hamano wrote:
> More importantly, doesn't "real_ref" have the name of the branch?
>
> Suppose the user said "git show @{1}" instead of "git show
> master@{1}" while on 'master'.
My stupidity, sorry.
> It could be argued that it may look nicer to say "your current
> branch does not
Junio C Hamano wrote:
> People have _already_ seen and lived with these issues in released
> versions. Changing it may or may not be getting it back to the
> state to that of an even older release, but at that point the
> differences do not matter. It is a "fix", too late for the kind of
> regres
There's still a lot to think about.
[3/3] is the big itch: [1/2] and [2/2] are just setup patches.
Ramkumar Ramachandra (3):
push: factor out the detached HEAD error message
push: fail early with detached HEAD and current
push: don't push the volatile HEAD with current
builtin/push.c | 20
With push.default set to upstream or simple, and a detached HEAD, git
push prints the following error:
$ git push
fatal: You are not currently on a branch.
To push the history leading to the current (detached HEAD)
state now, use
git push ram HEAD:
This error is not unique to upstrea
Setting push.default to current adds the refspec "HEAD" for the
transport layer to handle. If "HEAD" doesn't resolve to a branch (and
since no refspec rhs is specified), the push fails after some time with
a cryptic error message:
$ git push
error: unable to push to unqualified destination: H
Since a push does not lock the "HEAD" ref, there is no guarantee that it
will remain the same for the entire operation of the push. Practically,
this means that with push.default set to current:
# on branch push-current-head
$ git push
# on another terminal
$ git checkout master
# retur
Johan Herland writes:
> On Mon, May 20, 2013 at 6:37 PM, Junio C Hamano wrote:
> ...
>> That "backing out" can be made more intelligently than just dying
>> with "compare and swap failed--please retry" message, e.g. you at
>> that point notice what you started with, what the other party did
>> w
Ramkumar Ramachandra writes:
> There's still a lot to think about.
Is there? I do not think "volatile" is particularly a good
description for this, but showing what is pushed as a concrete
branch name feels like a good improvement to me, at least in
principle.
I haven't picked them up, and I w
On 2013-05-21 00.52, Junio C Hamano wrote:
> Thanks, will replace da/darwin with this round.
(May be late response, not sure if this is the right email thread.
I eventually managed to compile under 10.6, what we have on pu)
One minor nit, or 2:
imap-send.c: In function ‘cram’:
imap-send.c:913: war
Ramkumar Ramachandra wrote:
> Junio C Hamano wrote:
>> So did you or did you not audit the codepath?
>
> No; I was explaining why I didn't in the first place. Going through it now.
So, this is what I have:
interpret_branch_name -> interpret_branch_name (recursion)
-> get_sh
Torsten Bögershausen wrote:
> One minor nit, or 2:
> imap-send.c: In function ‘cram’:
> imap-send.c:913: warning: statement with no effect
>
> This fixes it:
>
> diff --git a/imap-send.c b/imap-send.c
> index 8ea180f..11577c9 100644
> --- a/imap-send.c
> +++ b/imap-send.c
> @@ -35,7 +35,7 @@ typed
Junio C Hamano wrote:
> Is there? I do not think "volatile" is particularly a good
> description for this, but showing what is pushed as a concrete
> branch name feels like a good improvement to me, at least in
> principle.
Okay. I used "volatile", because push does not lock HEAD when the
operat
Ramkumar Ramachandra writes:
> We're at 1.8.3; isn't it a little early to be thinking of 2.0? Is it
> conflicting with jc/push-2.0-default-to-simple in pu? I should
> re-send after this topic graduates to master in 2.0?
I implicitly asked you not to ask as I do not even have to worry
about con
Ramkumar Ramachandra writes:
> Ramkumar Ramachandra wrote:
>> Junio C Hamano wrote:
>>> So did you or did you not audit the codepath?
>>
>> No; I was explaining why I didn't in the first place. Going through it now.
>
> So, this is what I have:
>
> interpret_branch_name -> interpret_branch_name
Junio C Hamano wrote:
>> interpret_branch_name -> interpret_branch_name (recursion)
>> -> get_sha1_basic -> get_sha1 [context] (end-user data)
>> -> substitute_branch_name -> dwim (end-user data)
>> -> strbuf_branchname (callers pass a
Ramkumar Ramachandra writes:
> Junio C Hamano wrote:
>> Is there? I do not think "volatile" is particularly a good
>> description for this, but showing what is pushed as a concrete
>> branch name feels like a good improvement to me, at least in
>> principle.
>
> Okay. I used "volatile", because
Ramkumar Ramachandra writes:
> "@{u}". What am I missing?
You draw the arrow the other way around, that is what made the text
confusing.
--
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
Jiang Xin writes:
> diff --git a/test-path-utils.c b/test-path-utils.c
> index 0092cb..18267 100644
> --- a/test-path-utils.c
> +++ b/test-path-utils.c
> @@ -1,6 +1,19 @@
> #include "cache.h"
> #include "string-list.h"
>
> +#define PARSE_ARGV_STRING(var, input) do { \
> + if (!strcmp(inpu
Currently the __git_ps1 git prompt gives the following error with a
repository converted by git-svn, when used with zsh:
__git_ps1_show_upstream:19: bad pattern: svn_remote[
This was introduced by 6d158cba (bash completion: Support "divergence
from upstream" messages in __git_ps1), whe
Junio C Hamano wrote:
> In general, when a command is working in your repository with a
> working tree, we do not make any such promise that it keeps
> operationg normally when you pull the rug under its feet from
> another terminal ("git checkout maint" running at the same time "git
> pull" would
On Tue, May 21, 2013 at 11:32 AM, Junio C Hamano wrote:
> Felipe Contreras writes:
>> I won't
>> bother rationalizing if this makes sense for 'master'
>
> As this is a change to an old code/behaviour that was with us with
> many released versions, it hardly is for 'master' during -rc period.
Pr
On Tue, May 21, 2013 at 11:55 AM, Junio C Hamano wrote:
> Felipe Contreras writes:
>
>> Certain remote-helpers (the ones with 'export') would try to push
>> regardless.
>>
>> Obviously this is not what the user wants.
>>
>> Also, add a check for the 'dry-run' option, so remote-helpers can
>> impl
On Tue, May 21, 2013 at 11:23 AM, Junio C Hamano wrote:
> "Philip Oakley" writes:
>> On Sat, May 4, 2013 at 2:51 PM, Jonathan Nieder
>> wrote:
>>> Another trick is to use "git push":
>>> git push . $production_sha1:refs/heads/master
>
> It all falls out naturally from the "Git is distri
Hello,
I'm building a library to manipulate git repositories (interacting
directly with the filesystem).
Currently, we're trying to parse commit objects. After decompressing
the contents of a commit object file we got the following output:
commit 191
author Francisco Sokol 1369140112 -0300
comm
On Tue, May 21, 2013 at 4:21 PM, Chico Sokol wrote:
> Hello,
>
> I'm building a library to manipulate git repositories (interacting
> directly with the filesystem).
>
> Currently, we're trying to parse commit objects. After decompressing
> the contents of a commit object file we got the following
On Tue, May 21, 2013 at 5:21 PM, Chico Sokol wrote:
> Hello,
>
> I'm building a library to manipulate git repositories (interacting
> directly with the filesystem).
>
> Currently, we're trying to parse commit objects. After decompressing
> the contents of a commit object file we got the following
Ok, we discovered that the commit object actually contains the tree
object's sha1, by reading its contents with python zlib library.
So the bug must be with our java code (we're building a java lib).
Is there any non-standard issue in git's zlib compression? We're
decompressing its contents with
Chico Sokol writes:
> Hello,
>
> I'm building a library to manipulate git repositories (interacting
> directly with the filesystem).
>
> Currently, we're trying to parse commit objects. After decompressing
> the contents of a commit object file we got the following output:
Who wrote this commit
Chico Sokol writes:
> Ok, we discovered that the commit object actually contains the tree
> object's sha1, by reading its contents with python zlib library.
>
> So the bug must be with our java code (we're building a java lib).
Why aren't you using jgit?
--
To unsubscribe from this list: send th
From: "Felipe Contreras"
Sent: Tuesday, May 21, 2013 10:21 PM
On Tue, May 21, 2013 at 11:23 AM, Junio C Hamano
wrote:
"Philip Oakley" writes:
On Sat, May 4, 2013 at 2:51 PM, Jonathan Nieder
wrote:
Another trick is to use "git push":
git push . $production_sha1:refs/heads/master
It was git who created that object.
We're trying to build a improved java library focused in our needs
(jgit has a really confusing api focused in solving egit needs). But
we're about to get into their code to discover how to decompress git
objects.
--
Chico Sokol
On Tue, May 21, 2013 at 7:22
On Tue, May 21, 2013 at 12:19 PM, Torsten Bögershausen wrote:
> On 2013-05-21 00.52, Junio C Hamano wrote:
>> Thanks, will replace da/darwin with this round.
> (May be late response, not sure if this is the right email thread.
> I eventually managed to compile under 10.6, what we have on pu)
>
> O
Hi,
On Tue, May 21, 2013 at 10:54:27PM +0200, Thomas Gummerer wrote:
> Currently the __git_ps1 git prompt gives the following error with a
> repository converted by git-svn, when used with zsh:
>
> __git_ps1_show_upstream:19: bad pattern: svn_remote[
>
> This was introduced by 6d158cba
On Tue, May 21, 2013 at 5:33 PM, Philip Oakley wrote:
> From: "Felipe Contreras"
> Sent: Tuesday, May 21, 2013 10:21 PM
>
>> On Tue, May 21, 2013 at 11:23 AM, Junio C Hamano
>> wrote:
>>>
>>> "Philip Oakley" writes:
>>
>>
On Sat, May 4, 2013 at 2:51 PM, Jonathan Nieder
wrote:
>
>
On Tue, May 21, 2013 at 5:41 PM, SZEDER Gábor wrote:
> On Tue, May 21, 2013 at 10:54:27PM +0200, Thomas Gummerer wrote:
>> Currently the __git_ps1 git prompt gives the following error with a
>> repository converted by git-svn, when used with zsh:
>>
>> __git_ps1_show_upstream:19: bad pat
Felipe Contreras writes:
> I still haven't received a response: which makes more sense?
>
> a)
>
> % git checkout svn-ext
> % git fetch
> From .
>* branchmaster -> FETCH_HEAD
> # oops
> % git fetch git-svn
> % git log ..FETCH_HEAD
>
Here are the topics that have been cooking. Commits prefixed with
'-' are only in 'pu' (proposed updates) while commits prefixed with
'+' are in 'next'.
The final version of 1.8.3 is expected to be tagged late this week.
I have kept many late topics outside 'next' during the -rc period
primarily
Chico Sokol wrote:
> We're trying to build a improved java library focused in our needs
> (jgit has a really confusing api focused in solving egit needs).
JGit is also open to contributions, including contributions that
add less confusing API calls. :) See
http://wiki.eclipse.org/JGit/User_Gui
On Tue, May 21, 2013 at 06:04:35PM -0500, Felipe Contreras wrote:
> On Tue, May 21, 2013 at 5:41 PM, SZEDER Gábor wrote:
>
> > On Tue, May 21, 2013 at 10:54:27PM +0200, Thomas Gummerer wrote:
> >> Currently the __git_ps1 git prompt gives the following error with a
> >> repository converted by git
On Tue, May 21, 2013 at 6:36 PM, SZEDER Gábor wrote:
> On Tue, May 21, 2013 at 06:04:35PM -0500, Felipe Contreras wrote:
>> On Tue, May 21, 2013 at 5:41 PM, SZEDER Gábor wrote:
>>
>> > On Tue, May 21, 2013 at 10:54:27PM +0200, Thomas Gummerer wrote:
>> >> Currently the __git_ps1 git prompt gives
On Tue, May 21, 2013 at 07:03:09PM -0500, Felipe Contreras wrote:
> On Tue, May 21, 2013 at 6:36 PM, SZEDER Gábor wrote:
> > On Tue, May 21, 2013 at 06:04:35PM -0500, Felipe Contreras wrote:
> >> On Tue, May 21, 2013 at 5:41 PM, SZEDER Gábor wrote:
> >>
> >> > On Tue, May 21, 2013 at 10:54:27PM +
On Tue, May 21, 2013 at 6:24 PM, Junio C Hamano wrote:
> Felipe Contreras writes:
>
>> I still haven't received a response: which makes more sense?
>>
>> a)
>>
>> % git checkout svn-ext
>> % git fetch
>> From .
>>* branchmaster -> FETCH_HEAD
>> # oo
On Tue, May 21, 2013 at 7:20 PM, SZEDER Gábor wrote:
> On Tue, May 21, 2013 at 07:03:09PM -0500, Felipe Contreras wrote:
>> On Tue, May 21, 2013 at 6:36 PM, SZEDER Gábor wrote:
>> > On Tue, May 21, 2013 at 06:04:35PM -0500, Felipe Contreras wrote:
>> >> On Tue, May 21, 2013 at 5:41 PM, SZEDER Gáb
On Tue, May 21, 2013 at 07:29:38PM -0500, Felipe Contreras wrote:
> On Tue, May 21, 2013 at 7:20 PM, SZEDER Gábor wrote:
> > On Tue, May 21, 2013 at 07:03:09PM -0500, Felipe Contreras wrote:
> >> On Tue, May 21, 2013 at 6:36 PM, SZEDER Gábor wrote:
> >> > On Tue, May 21, 2013 at 06:04:35PM -0500,
Felipe Contreras writes:
> On Tue, May 21, 2013 at 11:55 AM, Junio C Hamano wrote:
>
>> This sounds like a good thing to do. Perhaps the refspec mapping
>> can be handled the same way as a backend feature so that you do not
>> have to unconditionally disable it in the other patch.
>
> With my p
Felipe Contreras writes:
> On Tue, May 21, 2013 at 6:24 PM, Junio C Hamano wrote:
>> Felipe Contreras writes:
>>
>>> I still haven't received a response: which makes more sense?
>>>
>>> a)
>>>
>>> % git checkout svn-ext
>>> % git fetch
>>> From .
>>>* branch
2013/5/22 Junio C Hamano :
> Jiang Xin writes:
>
>> diff --git a/test-path-utils.c b/test-path-utils.c
>> index 0092cb..18267 100644
>> --- a/test-path-utils.c
>> +++ b/test-path-utils.c
>> @@ -1,6 +1,19 @@
>> #include "cache.h"
>> #include "string-list.h"
>>
>> +#define PARSE_ARGV_STRING(var, i
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
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
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
Signed-off-by: Junio C Hamano
---
quote.c | 55 ++-
1 file changed, 2 insertions(+), 53 deletion
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
Signed-off
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
Signed-off-by: Junio C Hamano
---
Documentati
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
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
Signed-off-by: Junio C Hamano
---
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
Signed-off-by: Junio C Hamano
---
Documentatio
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, press
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 new section "Interactive mode" for documentation of interactive
git-clean.
Signed-off-by: Jiang Xin
Helped-by: Eric Sunshine
Signed-off-by: Junio C Hamano
---
Documentation/git-clean.txt | 65 +++--
1 file changed, 63 insertions(+), 2 deletions(-)
d
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
Signed-off-by: Junio C Hamano
---
builtin/clean.c | 36
1 file
Add test cases for git-clean--interactive.
Signed-off-by: Jiang Xin
Signed-off-by: Junio C Hamano
---
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-in
1 - 100 of 113 matches
Mail list logo