* [PATCHv3 0/5] patterns for branch list
From: Michael J Gruber @ 2011-08-28 14:54 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano, Jeff King
In-Reply-To: <cover.1314367414.git.git@drmicha.warpmail.net>
v3 has reworded commit messages for 2,3,4 and tests for combinations
of branch options in 4, as suggested.
No code changes (besides the additional tests in 4).
Michael J Gruber (5):
t6040: test branch -vv
git-tag: introduce long forms for the options
git-branch: introduce missing long forms for the options
branch: introduce --list option
branch: allow pattern arguments
Documentation/git-branch.txt | 20 +++++++++++++++--
Documentation/git-tag.txt | 8 +++++++
builtin/branch.c | 46 +++++++++++++++++++++++++++++++----------
builtin/tag.c | 16 +++++++-------
t/t3200-branch.sh | 32 +++++++++++++++++++++++++++++
t/t3203-branch-output.sh | 24 +++++++++++++++++++++
t/t6040-tracking-info.sh | 16 ++++++++++++++
7 files changed, 140 insertions(+), 22 deletions(-)
--
1.7.6.845.gc3c05
^ permalink raw reply
* Re: Overriding ~/.gitconfig using GIT_CONFIG
From: David Aguilar @ 2011-08-28 13:05 UTC (permalink / raw)
To: Richard Purdie
Cc: Junio C Hamano, Daniel Barkalow,
Nguy� n Thái Ngọc Duy, GIT Mailing-list
In-Reply-To: <1313181853.14274.535.camel@rex>
On Fri, Aug 12, 2011 at 09:44:13PM +0100, Richard Purdie wrote:
> My problem isn't that I want to specify a specific .gitconfig file, I
> just need it to ignore the one in $HOME. I'm happy for the .git/config
> file to be used, in fact I need it to be.
If you're writing a tool then it should restrict itself to
git's plumbing commands. You should be able to do just about
anything without needing to worry about differences in
configuraiton. Git commands almost always provide a way to
override configuration through the use of flags.
The plumbing commands are listed in the main git manpage.
See "Low-level commands (plumbing)" here:
http://www.kernel.org/pub/software/scm/git/docs/
What is the specific problem solved by overriding the
configuration? It may be possible to solve it without needing
to get too complicated.
Have fun,
--
David
^ permalink raw reply
* Re: Re* git clean --exclude broken?
From: Pete Wyckoff @ 2011-08-28 12:31 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Todd Rinaldo
In-Reply-To: <7v62li9hk5.fsf@alter.siamese.dyndns.org>
gitster@pobox.com wrote on Sat, 27 Aug 2011 23:27 -0700:
> Pete Wyckoff <pw@padd.com> writes:
>
> >> diff --git a/Documentation/git-clean.txt b/Documentation/git-clean.txt
> >> index 974e04e..a7a18e3 100644
> >> --- a/Documentation/git-clean.txt
> >> +++ b/Documentation/git-clean.txt
> >> @@ -47,9 +47,9 @@ OPTIONS
> >>
> >> -e <pattern>::
> >> --exclude=<pattern>::
> >> - Specify special exceptions to not be cleaned. Each <pattern> is
> >> - the same form as in $GIT_DIR/info/excludes and this option can be
> >> - given multiple times.
> >> + In addition to what are found in .gitignore (per directory) and
> >> + $GIT_DIR/info/exclude, also consider these patterns to be in the
> >> + set of the ignore rules in effect.
> >>
> >> -x::
> >> Don't use the ignore rules. This allows removing all untracked
> >> diff --git a/builtin/clean.c b/builtin/clean.c
> >> index 75697f7..3782718 100644
> >> --- a/builtin/clean.c
> >> +++ b/builtin/clean.c
> >> @@ -76,6 +76,8 @@ int cmd_clean(int argc, const char **argv, const char *prefix)
> >>
> >> if (ignored && ignored_only)
> >> die(_("-x and -X cannot be used together"));
> >> + if (ignored && exclude_list.nr)
> >> + die(_("adding exclude with -e and ignoring it with -x is crazy"));
> >
> > This breaks one of my use cases for git clean.
>
> The description of '-x' needs to be also updated to reflect what it does.
>
> How about this on top?
>
> Documentation/git-clean.txt | 4 +++-
> builtin/clean.c | 2 --
> 2 files changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/Documentation/git-clean.txt b/Documentation/git-clean.txt
> index b49674f..79fb984 100644
> --- a/Documentation/git-clean.txt
> +++ b/Documentation/git-clean.txt
> @@ -52,7 +52,9 @@ OPTIONS
> set of the ignore rules in effect.
>
> -x::
> - Don't use the ignore rules. This allows removing all untracked
> + Don't use the standard ignore rules read from .gitignore (per
> + directory) and $GIT_DIR/info/exclude, but do still use the ignore
> + rules given with `-e` options. This allows removing all untracked
> files, including build products. This can be used (possibly in
> conjunction with 'git reset') to create a pristine
> working directory to test a clean build.
> diff --git a/builtin/clean.c b/builtin/clean.c
> index 7fcbf87..0c7b3d0 100644
> --- a/builtin/clean.c
> +++ b/builtin/clean.c
> @@ -76,8 +76,6 @@ int cmd_clean(int argc, const char **argv, const char *prefix)
>
> if (ignored && ignored_only)
> die(_("-x and -X cannot be used together"));
> - if (ignored && exclude_list.nr)
> - die(_("adding exclude with -e and ignoring it with -x is crazy"));
>
> if (!show_only && !force) {
> if (config_set)
>
This works, thanks. It is a confusing set of options, but we
need them all. I couldn't think of a better way to describe
how they interact.
-- Pete
^ permalink raw reply
* Re: [PATCH v2] Makefile: Improve compiler header dependency check
From: Fredrik Kuivinen @ 2011-08-28 11:47 UTC (permalink / raw)
To: David Aguilar; +Cc: Junio C Hamano, Jonathan Nieder, git
In-Reply-To: <1314478844-55379-1-git-send-email-davvid@gmail.com>
On Sat, Aug 27, 2011 at 23:00, David Aguilar <davvid@gmail.com> wrote:
> Make the check use the same flags as the invocation to avoid
> false positives when user-configured compiler flags contain
> incompatible options.
[...]
> I'm not sure if "sh -c" is necessary but I did notice that other
> parts of the Makefile use $(SHELL_PATH). The check was adjusted
> to use that as well.
I'm not sure either. I just used what I saw at other places in the Makefile.
[patch snipped]
Looks good to me. Thanks!
- Fredrik
^ permalink raw reply
* Re: [PATCH v2 5/5] Use kwset in grep
From: Fredrik Kuivinen @ 2011-08-28 11:31 UTC (permalink / raw)
To: Paolo Bonzini; +Cc: git, dpotapov, Junio C Hamano
In-Reply-To: <4E51F998.50801@gnu.org>
On Mon, Aug 22, 2011 at 08:39, Paolo Bonzini <bonzini@gnu.org> wrote:
> On 08/21/2011 12:42 AM, Fredrik Kuivinen wrote:
>>
>> + if (opt->regflags& REG_ICASE || p->ignore_case) {
>> + static char trans[256];
>> + int i;
>> + for (i = 0; i< 256; i++)
>> + trans[i] = tolower(i);
>> + p->kws = kwsalloc(trans);
>> + } else {
>> + p->kws = kwsalloc(NULL);
>> + }
>
> Of course, this makes absolutely no sense for MB_CUR_MAX > 1. It's worth
> mentioning that grep instead uses a loop with mbrtowc/towlower/wcrtomb.
> This in turn will remove the need for the complex kwset code. :)
Good catch. At least it is not a regression from the current behavior,
neither our own strcasestr in compat/ nor strcasestr in glibc can
handle MB_CUR_MAX > 1. My original idea was to make use of kwset also
for the case when more than one fixed string is given to git-grep, but
I didn't find a nice way to refactor the code to make that possible.
> The "mbtolower" code" dates to after the license change, but I wrote it and
> I give permission to use it under GPLv2. See commits 70e23616 and 30af8050
> in the GNU grep repository.
>
> Should still be good enough for most uses, so I'll give my
>
> Acked-by: Paolo Bonzini <bonzini@gnu.org>
Thanks.
- Fredrik
^ permalink raw reply
* branch practice in my project
From: Lynn Lin @ 2011-08-28 9:23 UTC (permalink / raw)
To: git
Hi git experts,
currently our project use git to manage source code,we only have
master branch to support development and release.However when we goes
into regression phase,code freeze will be runnning on master branch
and it will hold lots of patch in developers.
I want to use a new branch strategy to resolve code freeeze issue
master branch ----1----2----3-----4-----5-----6-----7------8--->
| |
release 3‘----4’---5‘ 7'----8'
our release sprint cycle is 3 weeks per sprint. when we start a new
sprint,we can create a release branch and get the data back to master
branch after the sprint is over
how to get the data back to master branch? I suggest we can merge
release branch back, and others are afraid that merge conflict will be
a big deal for us so they suggest we can double commit into master and
release branch
what's your thoughts? Could you give me some suggestions?
Thanks in advance
Lynn
^ permalink raw reply
* extracting original git commits from "git svn" repository?
From: Anthony Foiani @ 2011-08-28 8:13 UTC (permalink / raw)
To: git
About two years ago, I started an SVN repo for a private project.
After a few months, I started using "git svn" for day-to-day updating
(to take advantage of offline commits, etc). git-svn has been
fantastic, but since it doesn't maintain AuthorDate (or, if it does, I
don't know how to ask it to do so), I'd like to migrate that SVN repo
to a git repo.
Is there any straightforward way to recover the "original" git commits
(spread out across two different workstations), so I can reinstate the
proper AuthorDate information?
Does this request even make sense?
I can have all the original data in one place, and I've got plenty of
CPU and RAM to throw at the problem:
server.svn/...
workstation1.git/...
workstation2.git/...
I'm hoping that it can be done with sufficient trawling through the
reflog, but I thought I'd ask before trying to do the conversion
myself.
Thanks in advance,
Tony
^ permalink raw reply
* [PATCH] t3005: do not assume a particular order of stdout and stderr of git-ls-files
From: Johannes Sixt @ 2011-08-28 7:34 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
There is no guarantee that stderr is flushed before stdout when both
channels are redirected to a file. Check the channels using independent
files.
Signed-off-by: Johannes Sixt <j6t@kdbg.org>
---
t/t3005-ls-files-relative.sh | 22 ++++++++++++----------
1 files changed, 12 insertions(+), 10 deletions(-)
diff --git a/t/t3005-ls-files-relative.sh b/t/t3005-ls-files-relative.sh
index a2b63e2..3778694 100755
--- a/t/t3005-ls-files-relative.sh
+++ b/t/t3005-ls-files-relative.sh
@@ -45,11 +45,12 @@ test_expect_success 'ls-files -c' '
for f in ../y*
do
echo "error: pathspec $sq$f$sq did not match any file(s) known to git."
- done >expect &&
- echo "Did you forget to ${sq}git add${sq}?" >>expect &&
- ls ../x* >>expect &&
- test_must_fail git ls-files -c --error-unmatch ../[xy]* >actual 2>&1 &&
- test_cmp expect actual
+ done >expect.err &&
+ echo "Did you forget to ${sq}git add${sq}?" >>expect.err &&
+ ls ../x* >expect.out &&
+ test_must_fail git ls-files -c --error-unmatch ../[xy]* >actual.out 2>actual.err &&
+ test_cmp expect.out actual.out &&
+ test_cmp expect.err actual.err
)
'
@@ -59,11 +60,12 @@ test_expect_success 'ls-files -o' '
for f in ../x*
do
echo "error: pathspec $sq$f$sq did not match any file(s) known to git."
- done >expect &&
- echo "Did you forget to ${sq}git add${sq}?" >>expect &&
- ls ../y* >>expect &&
- test_must_fail git ls-files -o --error-unmatch ../[xy]* >actual 2>&1 &&
- test_cmp expect actual
+ done >expect.err &&
+ echo "Did you forget to ${sq}git add${sq}?" >>expect.err &&
+ ls ../y* >expect.out &&
+ test_must_fail git ls-files -o --error-unmatch ../[xy]* >actual.out 2>actual.err &&
+ test_cmp expect.out actual.out &&
+ test_cmp expect.err actual.err
)
'
--
1.7.7.rc0.92.g0cd2b
^ permalink raw reply related
* Re: [PATCH] checkout: be quiet if not on isatty()
From: martin f krafft @ 2011-08-28 6:28 UTC (permalink / raw)
To: Junio C Hamano, Steffen Daode Nurpmeso, Steffen Daode Nurpmeso,
Tay Ray Chuan, git
In-Reply-To: <7vaaau9hso.fsf@alter.siamese.dyndns.org>
[-- Attachment #1: Type: text/plain, Size: 691 bytes --]
also sprach Junio C Hamano <gitster@pobox.com> [2011.08.28.0822 +0200]:
> In general, the progress output should not be given unless the
> output is sent to a tty (i.e. an interactive session).
Just as a note — around Unix, it's generally "output should not be
given unless there was an unexpected condition, or --verbose was
passed. If a tool did successfully what it was asked to do, it
should just be quiet about it."
--
martin | http://madduck.net/ | http://two.sentenc.es/
/.ing an issue is like asking an infinite number of monkeys for advice
-- in #debian-devel
spamtraps: madduck.bogus@madduck.net
[-- Attachment #2: Digital signature (see http://martin-krafft.net/gpg/sig-policy/999bbcc4/current) --]
[-- Type: application/pgp-signature, Size: 1124 bytes --]
^ permalink raw reply
* Re: Idea: "git format-patch" should get more information out of git
From: Junio C Hamano @ 2011-08-28 6:34 UTC (permalink / raw)
To: Michael Haggerty; +Cc: git, Jeff King, Johan Herland, Jonathan Nieder
In-Reply-To: <7vippiaduw.fsf@alter.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> Michael Haggerty <mhagger@alum.mit.edu> writes:
>
>> 4. There is no place to store the "additional information" (the part
>> that comes in patch emails between the "---" and the diffstat) while
>> working on the patch series;...
>
> I thought there was a RFC floating around to do this using notes and also
> teach it to "commit -e" a few months ago? I vaguelly recall that Peff and
> one of the J's were involved, so I am CC'ing them.
Also, when I prepare a commit to be sent with an additional piece of
information, I often write "---" and the additional message after my
S-o-b: line while preparing the commit log message. Unlike format-patch
that strips that off, commit keeps it, which is handy.
^ permalink raw reply
* Re: Re* git clean --exclude broken?
From: Junio C Hamano @ 2011-08-28 6:27 UTC (permalink / raw)
To: Pete Wyckoff; +Cc: git, Todd Rinaldo
In-Reply-To: <20110827235458.GA8124@arf.padd.com>
Pete Wyckoff <pw@padd.com> writes:
>> diff --git a/Documentation/git-clean.txt b/Documentation/git-clean.txt
>> index 974e04e..a7a18e3 100644
>> --- a/Documentation/git-clean.txt
>> +++ b/Documentation/git-clean.txt
>> @@ -47,9 +47,9 @@ OPTIONS
>>
>> -e <pattern>::
>> --exclude=<pattern>::
>> - Specify special exceptions to not be cleaned. Each <pattern> is
>> - the same form as in $GIT_DIR/info/excludes and this option can be
>> - given multiple times.
>> + In addition to what are found in .gitignore (per directory) and
>> + $GIT_DIR/info/exclude, also consider these patterns to be in the
>> + set of the ignore rules in effect.
>>
>> -x::
>> Don't use the ignore rules. This allows removing all untracked
>> diff --git a/builtin/clean.c b/builtin/clean.c
>> index 75697f7..3782718 100644
>> --- a/builtin/clean.c
>> +++ b/builtin/clean.c
>> @@ -76,6 +76,8 @@ int cmd_clean(int argc, const char **argv, const char *prefix)
>>
>> if (ignored && ignored_only)
>> die(_("-x and -X cannot be used together"));
>> + if (ignored && exclude_list.nr)
>> + die(_("adding exclude with -e and ignoring it with -x is crazy"));
>
> This breaks one of my use cases for git clean.
The description of '-x' needs to be also updated to reflect what it does.
How about this on top?
Documentation/git-clean.txt | 4 +++-
builtin/clean.c | 2 --
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/Documentation/git-clean.txt b/Documentation/git-clean.txt
index b49674f..79fb984 100644
--- a/Documentation/git-clean.txt
+++ b/Documentation/git-clean.txt
@@ -52,7 +52,9 @@ OPTIONS
set of the ignore rules in effect.
-x::
- Don't use the ignore rules. This allows removing all untracked
+ Don't use the standard ignore rules read from .gitignore (per
+ directory) and $GIT_DIR/info/exclude, but do still use the ignore
+ rules given with `-e` options. This allows removing all untracked
files, including build products. This can be used (possibly in
conjunction with 'git reset') to create a pristine
working directory to test a clean build.
diff --git a/builtin/clean.c b/builtin/clean.c
index 7fcbf87..0c7b3d0 100644
--- a/builtin/clean.c
+++ b/builtin/clean.c
@@ -76,8 +76,6 @@ int cmd_clean(int argc, const char **argv, const char *prefix)
if (ignored && ignored_only)
die(_("-x and -X cannot be used together"));
- if (ignored && exclude_list.nr)
- die(_("adding exclude with -e and ignoring it with -x is crazy"));
if (!show_only && !force) {
if (config_set)
^ permalink raw reply related
* Re: [PATCH] checkout: be quiet if not on isatty()
From: Junio C Hamano @ 2011-08-28 6:22 UTC (permalink / raw)
To: Steffen Daode Nurpmeso; +Cc: Steffen Daode Nurpmeso, Tay Ray Chuan, git
In-Reply-To: <c70a246a601bec0ce973b177bf5553d3fee47014.1314472512.git.sdaoden@gmail.com>
Steffen Daode Nurpmeso <sdaoden@googlemail.com> writes:
> Signed-off-by: Steffen Daode Nurpmeso <sdaoden@gmail.com>
Justification is necessary why this is a good change.
Perhaps you meant something like this:
In general, the progress output should not be given unless the
output is sent to a tty (i.e. an interactive session).
But this patch may be squelching the output a bit too much. The opts.quiet
field is used not just to set verbose_update in the unpack_trees_options
used in reset_tree() and merge_working_tree(), but also used to report the
local changes at the end of merge_working_tree(), report tracking
information, and report where the detached HEAD is at, among other things.
Independently, it might make sense to squelch advice messages in a
non-interactive session, but I think that should probably be done by
flipping advice_* variables in advice.c, I think.
> ---
> builtin/checkout.c | 1 +
> 1 files changed, 1 insertions(+), 0 deletions(-)
>
> diff --git a/builtin/checkout.c b/builtin/checkout.c
> index 4eaedff..6fb6d48 100644
> --- a/builtin/checkout.c
> +++ b/builtin/checkout.c
> @@ -958,6 +958,7 @@ int cmd_checkout(int argc, const char **argv, const char *prefix)
> gitmodules_config();
> git_config(git_checkout_config, &opts);
>
> + opts.quiet = !isatty(2);
> opts.track = BRANCH_TRACK_UNSPECIFIED;
>
> argc = parse_options(argc, argv, prefix, options, checkout_usage,
^ permalink raw reply
* Re: Idea: "git format-patch" should get more information out of git
From: Michael Haggerty @ 2011-08-28 6:21 UTC (permalink / raw)
To: Michael J Gruber
Cc: Junio C Hamano, git, Jeff King, Johan Herland, Jonathan Nieder
In-Reply-To: <4E595521.7080208@drmicha.warpmail.net>
On 08/27/2011 10:35 PM, Michael J Gruber wrote:
> My current setup is:
>
> A. I put the additional per commit info in notes. "git format-patch
> --notes" takes it from there and adds it where it belongs.
>
> B. I put series title and cover letter text into a ref note. "git branch
> --notes" displays them as a branch note, and "git format-patch --cover
> --notes" fills in the cover letter for me.
Very cool. I will check this out.
Michael
--
Michael Haggerty
mhagger@alum.mit.edu
http://softwareswirl.blogspot.com/
^ permalink raw reply
* t0300-credentials: poll failed: invalid argument
From: Brian Gernhardt @ 2011-08-28 4:40 UTC (permalink / raw)
To: Git List
The only usage of poll I see in the credentials system is:
credentials-cache--daemon.c
177: if (poll(&pfd, 1, 1000 * wakeup) < 0) {
My guess is that (1000 * wakeup) is more than INT_MAX and is becoming negative as the man page for poll seems to indicate that it will fail if timeout < -1.
Does anyone familiar with the credentials daemon want to try to figure out a reasonable fix?
~~ Brian
^ permalink raw reply
* [PATCH] t5540-http-test: shorten grep pattern
From: Brian Gernhardt @ 2011-08-28 4:42 UTC (permalink / raw)
To: Git List; +Cc: Junio C Hamano
On OS X, the grep pattern
"\"OP .*/objects/$x2/X38_X40 HTTP/[.0-9]*\" 20[0-9] "
is far too long ($x38 and $x40 represent 38 and 40 copies of
[0-9a-f]). In order to still be able to match this, use the sed
invocation to replace what we're looking for a token.
Signed-off-by: Brian Gernhardt <brian@gernhardtsoftware.com>
---
t/t5540-http-push.sh | 5 +++--
1 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/t/t5540-http-push.sh b/t/t5540-http-push.sh
index a266ca5..5bf287d 100755
--- a/t/t5540-http-push.sh
+++ b/t/t5540-http-push.sh
@@ -132,8 +132,9 @@ x38="$x5$x5$x5$x5$x5$x5$x5$x1$x1$x1"
x40="$x38$x2"
test_expect_success 'PUT and MOVE sends object to URLs with SHA-1 hash suffix' '
- sed -e "s/PUT /OP /" -e "s/MOVE /OP /" "$HTTPD_ROOT_PATH"/access.log |
- grep -e "\"OP .*/objects/$x2/${x38}_$x40 HTTP/[.0-9]*\" 20[0-9] "
+ sed -e "s/PUT /OP /" -e "s/MOVE /OP /" -e "s/$x40/X40/" -e "s/$x38/X38/"\
+ "$HTTPD_ROOT_PATH"/access.log |
+ grep -e "\"OP .*/objects/$x2/X38_X40 HTTP/[.0-9]*\" 20[0-9] "
'
--
1.7.6.671.g4d09b
^ permalink raw reply related
* Re: obstack fails to compile on OS X 10.7
From: Brian Gernhardt @ 2011-08-28 3:57 UTC (permalink / raw)
To: David Aguilar; +Cc: Git List, Fredrik Kuivinen
In-Reply-To: <20110827101418.GA8074@gmail.com>
On Aug 27, 2011, at 6:14 AM, David Aguilar wrote:
> This fixes it for me, but we might want to rearrange the
> #includes a bit. I think this needs more work.. including
> compat/obstack.h from kwset.c seems wrong.
> Should we just include obstack.h in git-compat-util instead?
If obstack.h is only used in kwset, I don't see a problem with it.
> -- 8< --
> Subject: [RFC PATCH] obstack: Fix portability issues
This patch does solve my compile problem. Now to track down test failures (unrelated to this issue, I'm very sure).
~~ B
^ permalink raw reply
* Re: Re* git clean --exclude broken?
From: Pete Wyckoff @ 2011-08-27 23:54 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Todd Rinaldo
In-Reply-To: <7vpqjtl4yi.fsf_-_@alter.siamese.dyndns.org>
gitster@pobox.com wrote on Thu, 25 Aug 2011 11:29 -0700:
> Junio C Hamano <gitster@pobox.com> writes:
>
> > The documentation and the implementation of "git clean" is quite confused.
> > ...
>
> So here is a patch to fix the confusion.
>
> It does not add a new "--except=C" I alluded to, but at least it should
> be the right first step to make the document clearly describe what the
> existing option does.
>
> -- >8 --
> Subject: [PATCH] Documentation: clarify "git clean -e <pattern>"
>
> The current explanation of -e can be misread as allowing the user to say
>
> I know 'git clean -XYZ' (substitute -XYZ with any option and/or
> parameter) will remove paths A, B, and C, and I want them all removed
> except for paths matching this pattern by adding '-e C' to the same
> command line, i.e. 'git clean -e C -XYZ'.
>
> But that is not what this option does. It augments the set of ignore rules
> from the command line, just like the same "-e <pattern>" argument does
> with the "ls-files" command (the user could probably pass "-e \!C" to tell
> the command to clean everything the command would normally remove, except
> for C).
>
> It also fixes small style nit in the parameter to add_exclude() call. The
> current code only works because EXC_CMDL happens to be defined as 0.
>
> Signed-off-by: Junio C Hamano <gitster@pobox.com>
> ---
> Documentation/git-clean.txt | 6 +++---
> builtin/clean.c | 5 ++++-
> 2 files changed, 7 insertions(+), 4 deletions(-)
>
> diff --git a/Documentation/git-clean.txt b/Documentation/git-clean.txt
> index 974e04e..a7a18e3 100644
> --- a/Documentation/git-clean.txt
> +++ b/Documentation/git-clean.txt
> @@ -47,9 +47,9 @@ OPTIONS
>
> -e <pattern>::
> --exclude=<pattern>::
> - Specify special exceptions to not be cleaned. Each <pattern> is
> - the same form as in $GIT_DIR/info/excludes and this option can be
> - given multiple times.
> + In addition to what are found in .gitignore (per directory) and
> + $GIT_DIR/info/exclude, also consider these patterns to be in the
> + set of the ignore rules in effect.
>
> -x::
> Don't use the ignore rules. This allows removing all untracked
> diff --git a/builtin/clean.c b/builtin/clean.c
> index 75697f7..3782718 100644
> --- a/builtin/clean.c
> +++ b/builtin/clean.c
> @@ -76,6 +76,8 @@ int cmd_clean(int argc, const char **argv, const char *prefix)
>
> if (ignored && ignored_only)
> die(_("-x and -X cannot be used together"));
> + if (ignored && exclude_list.nr)
> + die(_("adding exclude with -e and ignoring it with -x is crazy"));
This breaks one of my use cases for git clean.
We have "precious" files that are listed in .gitignore so that
they don't show up in "git status" output. They're not part of
the repository, but special per-user per-workspace configuration
settings that are required to build the code.
There's plenty of other stuff in .gitignore that should be
deleted. So we invoke:
git clean -dqfx -e .magic_file -e "Magic*"
It's been discussed on the list a couple of times that a separate
category for files that I want to ignore, but do not want to
have cleaned, would fill this gap.
-- Pete
> if (!show_only && !force) {
> if (config_set)
> @@ -98,7 +100,8 @@ int cmd_clean(int argc, const char **argv, const char *prefix)
> setup_standard_excludes(&dir);
>
> for (i = 0; i < exclude_list.nr; i++)
> - add_exclude(exclude_list.items[i].string, "", 0, dir.exclude_list);
> + add_exclude(exclude_list.items[i].string, "", 0,
> + &dir.exclude_list[EXC_CMDL]);
>
> pathspec = get_pathspec(prefix, argv);
>
> --
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply
* Re: [PATCH/RFC 2/2] git-p4: Add complex test case for branch import
From: Pete Wyckoff @ 2011-08-27 23:32 UTC (permalink / raw)
To: Vitor Antunes; +Cc: git, Tor Arvid Lund
In-Reply-To: <CAOpHH-Uv=zK9JoL+ooA9eEHg2XyX=k92hL1QZ_WNZwgvpnNj0g@mail.gmail.com>
vitor.hda@gmail.com wrote on Wed, 24 Aug 2011 22:23 +0100:
> On Wed, Aug 24, 2011 at 11:46 AM, Vitor Antunes <vitor.hda@gmail.com> wrote:
> > 1. When doing a "checkpoint" it would make sense to have some kind of
> > feedback loop to know when fast-import completes it. In fact, I've
> > just looked at fast-import man page and the "progress" command seems
> > to do exactly that! Myabe we should crease a specific function for
> > "checkpoint" that would call also "progress" instead of calling
> > os.sleep().
>
> # Force a checkpoint in fast-import and wait for it to finish
> def checkpoint(self):
> self.gitStream.write("checkpoint\n\n")
> self.gitStream.write("progress checkpoint\n\n")
> out = self.gitOutput.readline()
> if self.verbose:
> print "checkpoint finished: " + out
>
> This seems to work! :)
That's brilliant. And not even hacky. :)
> > 2. In order to avoid needing to use "--force" it would be nice to have
> > some form of "drop" command in fast-import that would allows us to
> > actively drop an older commit after calling "reset" (this could even
> > be an option of "reset"). This way fast-import would not find
> > dangling commits in the end of the import. Maybe there's already
> > some sort of command to achieve this in fast-import...? We could
> > probably ask to one of its maintainers.
>
> Just missing point 2 now.
How about this. Create the commit onto a fake branch name,
something involving the changeid would be okay. Remember this
so we can delete it later. For a parent, you can use anything,
so the top of the parent branch would be okay. Checkpoint.
Use rev-parse like you do. But go from the most recent commit on
back, hoping that the branch was created recently. I suspect
this is the case for those using "git-p4 sync" with
detect-branches to discover new ones periodically.
For each ref, diff-tree like you do. When it is found, generate
the commit again, with its real branch name and parent now.
When it exits, remember to delete the temp branches. Would be
nice to do this even on error exit, but that's harder. Maybe
the fake branch name should be something like
"refs/git-p4-temp/change-30214" instead of refs/heads/... to
indicate they are special. GC will commit the commits
eventually.
The other thought I had was to use "blob" with a mark name on
each file. Use --export-marks=... Checkpoint. Read the blob
ids corresponding to files on the branch. Then iterate back the
revs and do "git ls-tree -r ref^{tree}". Compare its blobs to
the new ones until a matching commit is found. Finally assemble
the blobs into a commit; no need to write them again. This seems
harder.
Here's a commit that refactors the tests and adds a bunch more
branch tests. They all pass with your checkpoint/progress fix,
and still using --force.
-- Pete
---------------------8<---------------
From f1e11b78cbb74fd4347df5fff64a373c3e449f68 Mon Sep 17 00:00:00 2001
From: Pete Wyckoff <pw@padd.com>
Date: Mon, 22 Aug 2011 22:20:33 -0400
Subject: [PATCH] git-p4 tests: refactor and add branch tests
Separate the tests related to detecting p4 branches
into their own file, and add a few more.
Introduce a library for functions that are common to
both git-p4 test files.
Signed-off-by: Pete Wyckoff <pw@padd.com>
---
t/lib-git-p4.sh | 55 ++++++++
t/t9800-git-p4.sh | 182 +-------------------------
t/t9801-git-p4-branch.sh | 326 ++++++++++++++++++++++++++++++++++++++++++++++
3 files changed, 388 insertions(+), 175 deletions(-)
create mode 100644 t/lib-git-p4.sh
create mode 100755 t/t9801-git-p4-branch.sh
diff --git a/t/lib-git-p4.sh b/t/lib-git-p4.sh
new file mode 100644
index 0000000..dbc1499
--- /dev/null
+++ b/t/lib-git-p4.sh
@@ -0,0 +1,55 @@
+#
+# Library code for git-p4 tests
+#
+
+. ./test-lib.sh
+
+( p4 -h && p4d -h ) >/dev/null 2>&1 || {
+ skip_all='skipping git-p4 tests; no p4 or p4d'
+ test_done
+}
+
+GITP4=$GIT_BUILD_DIR/contrib/fast-import/git-p4
+P4DPORT=10669
+
+export P4PORT=localhost:$P4DPORT
+export P4CLIENT=client
+
+db="$TRASH_DIRECTORY/db"
+cli="$TRASH_DIRECTORY/cli"
+git="$TRASH_DIRECTORY/git"
+
+start_p4d()
+{
+ mkdir -p "$db" &&
+ p4d -q -d -r "$db" -p $P4DPORT &&
+ mkdir -p "$cli" &&
+ mkdir -p "$git" &&
+ cd "$cli" &&
+ p4 client -i <<-EOF
+ Client: client
+ Description: client
+ Root: $cli
+ View: //depot/... //client/...
+ EOF
+}
+
+kill_p4d()
+{
+ pid=`pgrep -f p4d` &&
+ test -n "$pid" &&
+ for i in {1..5} ; do
+ test_debug "ps wl `echo $pid`" &&
+ kill $pid 2>/dev/null &&
+ pgrep -f p4d >/dev/null || break &&
+ sleep 0.2
+ done &&
+ rm -rf "$db" &&
+ rm -rf "$cli"
+}
+
+cleanup_git() {
+ cd "$TRASH_DIRECTORY" &&
+ rm -rf "$git" &&
+ mkdir "$git"
+}
diff --git a/t/t9800-git-p4.sh b/t/t9800-git-p4.sh
index cf3a70e..684aa53 100755
--- a/t/t9800-git-p4.sh
+++ b/t/t9800-git-p4.sh
@@ -2,40 +2,16 @@
test_description='git-p4 tests'
-. ./test-lib.sh
+. ./lib-git-p4.sh
-( p4 -h && p4d -h ) >/dev/null 2>&1 || {
- skip_all='skipping git-p4 tests; no p4 or p4d'
- test_done
-}
-
-GITP4=$GIT_BUILD_DIR/contrib/fast-import/git-p4
-P4DPORT=10669
-
-export P4PORT=localhost:$P4DPORT
-
-db="$TRASH_DIRECTORY/db"
-cli="$TRASH_DIRECTORY/cli"
-git="$TRASH_DIRECTORY/git"
-
-test_debug 'echo p4d -q -d -r "$db" -p $P4DPORT'
-test_expect_success setup '
- mkdir -p "$db" &&
- p4d -q -d -r "$db" -p $P4DPORT &&
- mkdir -p "$cli" &&
- mkdir -p "$git" &&
- export P4PORT=localhost:$P4DPORT
+test_expect_success 'start p4d' '
+ kill_p4d || : &&
+ start_p4d &&
+ cd "$TRASH_DIRECTORY"
'
test_expect_success 'add p4 files' '
cd "$cli" &&
- p4 client -i <<-EOF &&
- Client: client
- Description: client
- Root: $cli
- View: //depot/... //client/...
- EOF
- export P4CLIENT=client &&
echo file1 >file1 &&
p4 add file1 &&
p4 submit -d "file1" &&
@@ -45,12 +21,6 @@ test_expect_success 'add p4 files' '
cd "$TRASH_DIRECTORY"
'
-cleanup_git() {
- cd "$TRASH_DIRECTORY" &&
- rm -rf "$git" &&
- mkdir "$git"
-}
-
test_expect_success 'basic git-p4 clone' '
"$GITP4" clone --dest="$git" //depot &&
test_when_finished cleanup_git &&
@@ -404,146 +374,8 @@ test_expect_success 'detect copies' '
p4 filelog //depot/file13 | grep -q "branch from //depot/file"
'
-# Create a simple branch structure in P4 depot to check if it is correctly
-# cloned.
-test_expect_success 'add simple p4 branches' '
- cd "$cli" &&
- mkdir branch1 &&
- cd branch1 &&
- echo file1 >file1 &&
- echo file2 >file2 &&
- p4 add file1 file2 &&
- p4 submit -d "branch1" &&
- p4 integrate //depot/branch1/... //depot/branch2/... &&
- p4 submit -d "branch2" &&
- echo file3 >file3 &&
- p4 add file3 &&
- p4 submit -d "add file3 in branch1" &&
- p4 open file2 &&
- echo update >>file2 &&
- p4 submit -d "update file2 in branch1" &&
- p4 integrate //depot/branch1/... //depot/branch3/... &&
- p4 submit -d "branch3" &&
- cd "$TRASH_DIRECTORY"
-'
-
-# Configure branches through git-config and clone them.
-# All files are tested to make sure branches were cloned correctly.
-# Finally, make an update to branch1 on P4 side to check if it is imported
-# correctly by git-p4.
-test_expect_success 'git-p4 clone simple branches' '
- test_when_finished cleanup_git &&
- test_create_repo "$git" &&
- cd "$git" &&
- git config git-p4.branchList branch1:branch2 &&
- git config --add git-p4.branchList branch1:branch3 &&
- "$GITP4" clone --dest=. --detect-branches //depot@all &&
- git log --all --graph --decorate --stat &&
- git reset --hard p4/depot/branch1 &&
- test -f file1 &&
- test -f file2 &&
- test -f file3 &&
- grep -q update file2 &&
- git reset --hard p4/depot/branch2 &&
- test -f file1 &&
- test -f file2 &&
- test ! -f file3 &&
- ! grep -q update file2 &&
- git reset --hard p4/depot/branch3 &&
- test -f file1 &&
- test -f file2 &&
- test -f file3 &&
- grep -q update file2 &&
- cd "$cli" &&
- cd branch1 &&
- p4 edit file2 &&
- echo file2_ >>file2 &&
- p4 submit -d "update file2 in branch3" &&
- cd "$git" &&
- git reset --hard p4/depot/branch1 &&
- "$GITP4" rebase &&
- grep -q file2_ file2
-'
-
-# Create a complex branch structure in P4 depot to check if they are correctly
-# cloned. The branches are created from older changelists to check if git-p4 is
-# able to correctly detect them.
-# The final expected structure is:
-# `branch1
-# | `- file1
-# | `- file2 (updated)
-# | `- file3
-# `branch2
-# | `- file1
-# | `- file2
-# `branch3
-# | `- file1
-# | `- file2 (updated)
-# | `- file3
-# `branch4
-# | `- file1
-# | `- file2
-# `branch5
-# `- file1
-# `- file2
-# `- file3
-test_expect_success 'add p4 complex branches' '
- cd "$cli" &&
- changelist=$(p4 changes -m1 //depot/... | cut -d" " -f2) &&
- changelist=$((changelist - 5)) &&
- p4 integrate //depot/branch1/...@$changelist //depot/branch4/... &&
- p4 submit -d "branch4" &&
- changelist=$((changelist + 2)) &&
- p4 integrate //depot/branch1/...@$changelist //depot/branch5/... &&
- p4 submit -d "branch5" &&
- cd "$TRASH_DIRECTORY"
-'
-
-# Configure branches through git-config and clone them. git-p4 will only be able
-# to clone the original structure if it is able to detect the origin changelist
-# of each branch.
-test_expect_success 'git-p4 clone complex branches' '
- test_when_finished cleanup_git &&
- test_create_repo "$git" &&
- cd "$git" &&
- git config git-p4.branchList branch1:branch2 &&
- git config --add git-p4.branchList branch1:branch3 &&
- git config --add git-p4.branchList branch1:branch4 &&
- git config --add git-p4.branchList branch1:branch5 &&
- "$GITP4" clone --dest=. --detect-branches //depot@all &&
- git log --all --graph --decorate --stat &&
- git reset --hard p4/depot/branch1 &&
- test -f file1 &&
- test -f file2 &&
- test -f file3 &&
- grep -q update file2 &&
- git reset --hard p4/depot/branch2 &&
- test -f file1 &&
- test -f file2 &&
- test ! -f file3 &&
- ! grep -q update file2 &&
- git reset --hard p4/depot/branch3 &&
- test -f file1 &&
- test -f file2 &&
- test -f file3 &&
- grep -q update file2 &&
- git reset --hard p4/depot/branch4 &&
- test -f file1 &&
- test -f file2 &&
- test ! -f file3 &&
- ! grep -q update file2 &&
- git reset --hard p4/depot/branch5 &&
- test -f file1 &&
- test -f file2 &&
- test -f file3 &&
- ! grep -q update file2
-'
-
-test_expect_success 'shutdown' '
- pid=`pgrep -f p4d` &&
- test -n "$pid" &&
- test_debug "ps wl `echo $pid`" &&
- kill $pid
+test_expect_success 'kill p4d' '
+ kill_p4d
'
test_done
diff --git a/t/t9801-git-p4-branch.sh b/t/t9801-git-p4-branch.sh
new file mode 100755
index 0000000..c71d1a5
--- /dev/null
+++ b/t/t9801-git-p4-branch.sh
@@ -0,0 +1,326 @@
+#!/bin/sh
+
+test_description='git-p4 p4 branching tests'
+
+. ./lib-git-p4.sh
+
+test_expect_success 'start p4d' '
+ kill_p4d || : &&
+ start_p4d &&
+ cd "$TRASH_DIRECTORY"
+'
+
+#
+# 1: //depot/main/f1
+# 2: //depot/main/f2
+# 3: integrate //depot/main/... -> //depot/branch1/...
+# 4: //depot/main/f4
+# 5: //depot/branch1/f5
+# .: named branch branch2
+# 6: integrate -b branch2
+# 7: //depot/branch2/f7
+# 8: //depot/main/f8
+#
+test_expect_success 'basic p4 branches' '
+ cd "$cli" &&
+ mkdir -p main &&
+
+ echo f1 >main/f1 &&
+ p4 add main/f1 &&
+ p4 submit -d "main/f1" &&
+
+ echo f2 >main/f2 &&
+ p4 add main/f2 &&
+ p4 submit -d "main/f2" &&
+
+ p4 integrate //depot/main/... //depot/branch1/... &&
+ p4 submit -d "integrate main to branch1" &&
+
+ echo f4 >main/f4 &&
+ p4 add main/f4 &&
+ p4 submit -d "main/f4" &&
+
+ echo f5 >branch1/f5 &&
+ p4 add branch1/f5 &&
+ p4 submit -d "branch1/f5" &&
+
+ p4 branch -i <<-EOF &&
+ Branch: branch2
+ View: //depot/main/... //depot/branch2/...
+ EOF
+
+ p4 integrate -b branch2 &&
+ p4 submit -d "integrate main to branch2" &&
+
+ echo f7 >branch2/f7 &&
+ p4 add branch2/f7 &&
+ p4 submit -d "branch2/f7" &&
+
+ echo f8 >main/f8 &&
+ p4 add main/f8 &&
+ p4 submit -d "main/f8" &&
+
+ cd "$TRASH_DIRECTORY"
+'
+
+test_expect_success 'import main, no branch detection' '
+ test_when_finished cleanup_git &&
+ "$GITP4" clone --dest="$git" //depot/main@all &&
+ cd "$git" &&
+ git log --oneline --graph --decorate --all &&
+ git rev-list master >wc &&
+ test_line_count = 4 wc
+'
+
+test_expect_success 'import branch1, no branch detection' '
+ test_when_finished cleanup_git &&
+ "$GITP4" clone --dest="$git" //depot/branch1@all &&
+ cd "$git" &&
+ git log --oneline --graph --decorate --all &&
+ git rev-list master >wc &&
+ test_line_count = 2 wc
+'
+
+test_expect_success 'import branch2, no branch detection' '
+ test_when_finished cleanup_git &&
+ "$GITP4" clone --dest="$git" //depot/branch2@all &&
+ cd "$git" &&
+ git log --oneline --graph --decorate --all &&
+ git rev-list master >wc &&
+ test_line_count = 2 wc
+'
+
+test_expect_success 'import depot, no branch detection' '
+ test_when_finished cleanup_git &&
+ "$GITP4" clone --dest="$git" //depot@all &&
+ cd "$git" &&
+ git log --oneline --graph --decorate --all &&
+ git rev-list master >wc &&
+ test_line_count = 8 wc
+'
+
+test_expect_success 'import depot, branch detection' '
+ test_when_finished cleanup_git &&
+ "$GITP4" clone --dest="$git" --detect-branches //depot@all &&
+ cd "$git" &&
+
+ git log --oneline --graph --decorate --all &&
+
+ # 4 main commits
+ git rev-list master >wc &&
+ test_line_count = 4 wc &&
+
+ # 3 main, 1 integrate, 1 on branch2
+ git rev-list p4/depot/branch2 >wc &&
+ test_line_count = 5 wc &&
+
+ # no branch1, since no p4 branch created for it
+ test_must_fail git show-ref p4/depot/branch1
+'
+
+test_expect_success 'import depot, branch detection, branchList branch definition' '
+ test_when_finished cleanup_git &&
+ test_create_repo "$git" &&
+ cd "$git" &&
+ git config git-p4.branchList main:branch1 &&
+ "$GITP4" clone --dest=. --detect-branches //depot@all &&
+
+ git log --oneline --graph --decorate --all &&
+
+ # 4 main commits
+ git rev-list master >wc &&
+ test_line_count = 4 wc &&
+
+ # 3 main, 1 integrate, 1 on branch2
+ git rev-list p4/depot/branch2 >wc &&
+ test_line_count = 5 wc &&
+
+ # 2 main, 1 integrate, 1 on branch1
+ git rev-list p4/depot/branch1 >wc &&
+ test_line_count = 4 wc
+'
+
+test_expect_success 'branch from non-head should find parent' '
+ cd "$cli" &&
+ p4 integrate //depot/main/...@1 //depot/branch3/... &&
+ p4 submit -d "integrate main@1 to branch3" &&
+
+ test_when_finished cleanup_git &&
+ test_create_repo "$git" &&
+ cd "$git" &&
+
+ git config git-p4.branchList main:branch1 &&
+ git config git-p4.branchList main:branch3 &&
+ "$GITP4" clone --dest=. --detect-branches //depot@all &&
+
+ git log --oneline --graph --decorate --all &&
+
+ branch3_parent=$(git rev-parse p4/depot/branch3^) &&
+ change1=$(git rev-parse :/"change = 1") &&
+ echo test $branch3_parent = $change1 &&
+ test $branch3_parent = $change1
+'
+
+test_expect_success 'restart p4d' '
+ kill_p4d &&
+ start_p4d &&
+ cd "$TRASH_DIRECTORY"
+'
+
+#
+# 1: //depot/branch1/file1
+# //depot/branch1/file2
+# 2: integrate //depot/branch1/... -> //depot/branch2/...
+# 3: //depot/branch1/file3
+# 4: //depot/branch1/file2 (edit)
+# 5: integrate //depot/branch1/... -> //depot/branch3/...
+#
+## Create a simple branch structure in P4 depot.
+test_expect_success 'add simple p4 branches' '
+ cd "$cli" &&
+ mkdir branch1 &&
+ cd branch1 &&
+ echo file1 >file1 &&
+ echo file2 >file2 &&
+ p4 add file1 file2 &&
+ p4 submit -d "branch1" &&
+ p4 integrate //depot/branch1/... //depot/branch2/... &&
+ p4 submit -d "branch2" &&
+ echo file3 >file3 &&
+ p4 add file3 &&
+ p4 submit -d "add file3 in branch1" &&
+ p4 open file2 &&
+ echo update >>file2 &&
+ p4 submit -d "update file2 in branch1" &&
+ p4 integrate //depot/branch1/... //depot/branch3/... &&
+ p4 submit -d "branch3" &&
+ cd "$TRASH_DIRECTORY"
+'
+
+# Configure branches through git-config and clone them.
+# All files are tested to make sure branches were cloned correctly.
+# Finally, make an update to branch1 on P4 side to check if it is imported
+# correctly by git-p4.
+test_expect_success 'git-p4 clone simple branches' '
+ test_when_finished cleanup_git &&
+ test_create_repo "$git" &&
+ cd "$git" &&
+ git config git-p4.branchList branch1:branch2 &&
+ git config --add git-p4.branchList branch1:branch3 &&
+ "$GITP4" clone --dest=. --detect-branches //depot@all &&
+ git log --all --graph --decorate --stat &&
+ git reset --hard p4/depot/branch1 &&
+ test -f file1 &&
+ test -f file2 &&
+ test -f file3 &&
+ grep -q update file2 &&
+ git reset --hard p4/depot/branch2 &&
+ test -f file1 &&
+ test -f file2 &&
+ test ! -f file3 &&
+ test_must_fail grep -q update file2 &&
+ git reset --hard p4/depot/branch3 &&
+ test -f file1 &&
+ test -f file2 &&
+ test -f file3 &&
+ grep -q update file2 &&
+ cd "$cli" &&
+ cd branch1 &&
+ p4 edit file2 &&
+ echo file2_ >>file2 &&
+ p4 submit -d "update file2 in branch3" &&
+ cd "$git" &&
+ git reset --hard p4/depot/branch1 &&
+ "$GITP4" rebase &&
+ grep -q file2_ file2
+'
+
+# Create a complex branch structure in P4 depot to check if they are correctly
+# cloned. The branches are created from older changelists to check if git-p4 is
+# able to correctly detect them.
+#
+# The final expected structure is:
+# `branch1
+# | `- file1
+# | `- file2 (updated)
+# | `- file3
+# `branch2
+# | `- file1
+# | `- file2
+# `branch3
+# | `- file1
+# | `- file2 (updated)
+# | `- file3
+# `branch4
+# | `- file1
+# | `- file2
+# `branch5
+# `- file1
+# `- file2
+# `- file3
+#
+# Changes 1..6 from previous tests, plus two new ones:
+# 1: //depot/branch1/file1
+# //depot/branch1/file2
+# 2: integrate //depot/branch1/... -> //depot/branch2/...
+# 3: //depot/branch1/file3
+# 4: //depot/branch1/file2 (edit)
+# 5: integrate //depot/branch1/... -> //depot/branch3/...
+# 6: //depot/branch3/file2 (edit, from previous test)
+# 7: integrate //depot/branch1/...@1 -> //depot/branch4/...
+# 8: integrate //depot/branch1/...@3 -> //depot/branch5/...
+#
+test_expect_success 'add p4 complex branches' '
+ cd "$cli" &&
+ p4 integrate //depot/branch1/...@1 //depot/branch4/... &&
+ p4 submit -d "branch4 from branch1@1" &&
+ p4 integrate //depot/branch1/...@3 //depot/branch5/... &&
+ p4 submit -d "branch5 from branch1@3" &&
+ cd "$TRASH_DIRECTORY"
+'
+
+# Configure branches through git-config and clone them. git-p4 will only be
+# able to clone the original structure if it is able to detect the origin
+# changelist of each branch.
+test_expect_success 'git-p4 clone complex branches' '
+ test_when_finished cleanup_git &&
+ test_create_repo "$git" &&
+ cd "$git" &&
+ git config git-p4.branchList branch1:branch2 &&
+ git config --add git-p4.branchList branch1:branch3 &&
+ git config --add git-p4.branchList branch1:branch4 &&
+ git config --add git-p4.branchList branch1:branch5 &&
+ "$GITP4" clone --dest=. --detect-branches //depot@all &&
+ git log --all --graph --decorate --stat &&
+ git reset --hard p4/depot/branch1 &&
+ test -f file1 &&
+ test -f file2 &&
+ test -f file3 &&
+ grep -q update file2 &&
+ git reset --hard p4/depot/branch2 &&
+ test -f file1 &&
+ test -f file2 &&
+ test ! -f file3 &&
+ test_must_fail grep -q update file2 &&
+ git reset --hard p4/depot/branch3 &&
+ test -f file1 &&
+ test -f file2 &&
+ test -f file3 &&
+ grep -q update file2 &&
+ git reset --hard p4/depot/branch4 &&
+ test -f file1 &&
+ test -f file2 &&
+ test ! -f file3 &&
+ test_must_fail grep -q update file2 &&
+ git reset --hard p4/depot/branch5 &&
+ test -f file1 &&
+ test -f file2 &&
+ test -f file3 &&
+ test_must_fail grep -q update file2
+'
+
+test_expect_success 'kill p4d' '
+ kill_p4d
+'
+
+test_done
--
1.7.5.4
^ permalink raw reply related
* Re: Files that cannot be added to the index
From: seanh @ 2011-08-27 21:44 UTC (permalink / raw)
To: git
In-Reply-To: <20110827153536.GA291@sooty-2.local>
On Sat, Aug 27, 2011 at 05:35:36PM +0200, seanh wrote:
> On Fri, Aug 26, 2011 at 04:12:33PM -0500, Shaun Ruffell wrote:
> > Not sure if this is your problem exactly but awhile back I ran into
> > something similar to what you describe and tracked it down to the
> > fact that my filesystem was case insensitive. i.e.
>
> My filesystem (HFS+ on OSX Lion) is case-insensitive, yeah. I bet you're
> right, because in one repo the modified file shows up in `git status` as
> LOG.txt but in the output from `ls` it is called `Log.txt`. It's the
> same in the other repo that has the problem, the case of the filename
> that is having the problem is different in `git status` and `ls`.
>
> Perhaps the problem might have been introduced by moving the repo from a
> case-sensitive to an insensitive filesystem? Or by originally starting
> the repo on a sensitive fs and then using git clone to clone it onto an
> insensitive one. Or, maybe at some point I committed a change to the
> case of the filename and that introduced a problem on case-insenstive
> filesystems.
>
> Did you find a way around the problem? I guess that the repo does not
> really have any uncommitted changes, so I just want to convince `git
> status` and `git diff` of this.
I think I fixed it like this:
git config core.ignorecase false
then backup the LOG.txt file and:
git rm Text/Log.txt
git rm Text/LOG.txt
git commit
then copy the LOG.txt file back again and add and commit it. Seems to be
okay now.
^ permalink raw reply
* Re: [PATCH] Makefile: Improve compiler header dependency check
From: David Aguilar @ 2011-08-27 21:19 UTC (permalink / raw)
To: Jonathan Nieder; +Cc: Junio C Hamano, Fredrik Kuivinen, git
In-Reply-To: <20110827162645.GA10476@elie.gateway.2wire.net>
On Sat, Aug 27, 2011 at 11:26:54AM -0500, Jonathan Nieder wrote:
> David Aguilar wrote:
>
> > I fired up git's next branch on a mac laptop where I
> > have a config.mak that builds universal git binaries:
> >
> > CFLAGS = -arch i386 -arch x86_64
> >
> > This configuration broke when 111ee18c31f9bac9436426399355facc79238566
> > was merged into next.
>
> Good catch; thanks. This information would be useful for the commit
> message.
>
> > gcc cannot generate header dependencies when
> > multiple -arch statements are used
>
> Sounds like a bug. Any idea why it behaves that way? What error message
> does it write?
>
> If it is a bug, it might be worth reporting this to the gcc devs while
> at it.
This has been the behavior for as long as I can remember.
I don't think it's a bug. I included the error message
in the commit message for [PATCH v2]:
gcc-4.2: -E, -S, -save-temps and -M options are
not allowed with multiple -arch flags
I don't think it's a gcc bug. This is just another one of
those annoying mac-isms. When building against multiple archs
gcc will include a different set of headers for each arch
which is likely why the gcc devs do not support it.
I sent a v2 version of the patch that uses $(SHELL_PATH)
and omits $(EXTRA_CPPFLAGS).
I think the ideal situation would be for the dependency
check to emit headers required across all architectures
but that's not how it works. Perhaps there are some
internal architectural limitations in gcc that prevent
it from being done that way.
My experience has been that most projects DTRT when CFLAGS
is configured this way. It's always one or two that require
intrusive Makefile or libtool hacks to make them build
universal and those are no fun ;-)
BTW after applying this patch I immediately ran into the
compat/obstack.[ch] portability problem that I responded
to in another thread. I was finally able to make git
build with the patch that I included inline there but
I think it still needs work. I'll keep an eye on that
thread so that we can get a final patch for it.
I also noticed that a few of our compat/ files have
gcc/autoconf-isms such as:
#ifdef HAVE_CONFIG_H
#include "config.h"
#endif
Should I clean these up? They seem unnecessary.
--
David
^ permalink raw reply
* [PATCH v2] Makefile: Improve compiler header dependency check
From: David Aguilar @ 2011-08-27 21:00 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jonathan Nieder, Fredrik Kuivinen, git
In-Reply-To: <20110827162645.GA10476@elie.gateway.2wire.net>
Make the check use the same flags as the invocation to avoid
false positives when user-configured compiler flags contain
incompatible options.
For example, it is possible to build universal git binaries on
OS X with the following snippet in config.mak:
CFLAGS = -arch i386 -arch x86_64
111ee18c31f9bac9436426399355facc79238566 breaks this setup and
results in the following error message:
gcc-4.2: -E, -S, -save-temps and -M options are
not allowed with multiple -arch flags
Include ALL_CFLAGS so that this and other conditions are caught.
Use SHELL_PATH instead of assuming that "sh" is a sane shell.
Signed-off-by: David Aguilar <davvid@gmail.com>
---
I'm not sure if "sh -c" is necessary but I did notice that other
parts of the Makefile use $(SHELL_PATH). The check was adjusted
to use that as well.
Makefile | 5 +++--
1 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/Makefile b/Makefile
index aa67142..9446a4e 100644
--- a/Makefile
+++ b/Makefile
@@ -1250,8 +1250,9 @@ COMPUTE_HEADER_DEPENDENCIES =
USE_COMPUTED_HEADER_DEPENDENCIES =
else
ifndef COMPUTE_HEADER_DEPENDENCIES
-dep_check = $(shell sh -c \
- '$(CC) -c -MF /dev/null -MMD -MP -x c /dev/null -o /dev/null 2>&1; \
+dep_check = $(shell $(SHELL_PATH) -c \
+ '$(CC) -c -MF /dev/null -MMD -MP -x c /dev/null -o /dev/null \
+ $(ALL_CFLAGS) 2>&1; \
echo $$?')
ifeq ($(dep_check),0)
COMPUTE_HEADER_DEPENDENCIES=YesPlease
--
1.7.7.rc0.308.gc820
^ permalink raw reply related
* Re: Idea: "git format-patch" should get more information out of git
From: Michael J Gruber @ 2011-08-27 20:35 UTC (permalink / raw)
To: Junio C Hamano
Cc: Michael Haggerty, git, Jeff King, Johan Herland, Jonathan Nieder
In-Reply-To: <7vippiaduw.fsf@alter.siamese.dyndns.org>
Junio C Hamano venit, vidit, dixit 27.08.2011 20:46:
> Michael Haggerty <mhagger@alum.mit.edu> writes:
>
>> 1. The extra information typed into the email series is not archived in
>> the git repository, and therefore the emails have to be kept around.
>
> The convention is to have information that is not meant to be kept around
> after '---', so...
>
>> 2. If it is discovered between "git format-patch" and "git send-email"
>> that one of the patches needs a tweak, then the email series has to be
>> generated anew and all of the hand-edits need to be redone.
>
> I actually often work this backwards. Tweak the patch files, apply them to
> commit that they are meant to be applied, retest and then finally send.
> There is no "generating anew" involved.
>
>> 4. There is no place to store the "additional information" (the part
>> that comes in patch emails between the "---" and the diffstat) while
>> working on the patch series;...
>
> I thought there was a RFC floating around to do this using notes and also
> teach it to "commit -e" a few months ago? I vaguelly recall that Peff and
> one of the J's were involved, so I am CC'ing them.
Don't forget the MJ ;)
My current setup is:
A. I put the additional per commit info in notes. "git format-patch
--notes" takes it from there and adds it where it belongs.
B. I put series title and cover letter text into a ref note. "git branch
--notes" displays them as a branch note, and "git format-patch --cover
--notes" fills in the cover letter for me.
A patch for A has been on the list, but Junio didn't like the additional
"---" which I had for technical reasons, and I haven't had time to
revisit that patch yet. (The code would have to store a flag about notes
having been inserted or not.) Nobody has complained about the patches
I've created with that form, though ;)
The stuff for B is part of my "ref notes" stuff which I haven't
submitted so far. I've been using it for quite a while now, but am still
unsure about some design aspects.
A is simply my branch "format-patch-notes".
B uses these:
vob/virtual-objects
vob/refrev-hash
vob/branch-notes
vob/format-patch-branch-note
(Merge in this order. Last one is the most immature.)
Note that I rebase frequently these days because of overlapping work in
these areas.
I think Jeff had an interesting patch allowing to edit the note along
side (OK: at the bottom of) the commit message.
Cheers,
Michael
Oh, repo, yes... Any of these:
git://github.com/gitigit/git.git
git://gitorious.org/~mjg/git/mjg.git
git://repo.or.cz/git/mjg.git
^ permalink raw reply
* [PATCH] Add a credential-helper for KDE
From: Lukas Sandström @ 2011-08-27 19:54 UTC (permalink / raw)
To: Git Mailing List; +Cc: Lukas Sandström, Jeff King
This Python script plugs into the credentials API
of Git to ask the user for passwords with a nice
KDE password dialog.
The password is saved in the KWallet.
Signed-off-by: Lukas Sandström <luksan@gmail.com>
---
Here is a credentials-helper for KDE. You need to have PyKDE installed to use it.
See Documentation/gitcredentials.txt for more info.
.../git-kde-credentials-helper.py | 122 ++++++++++++++++++++
1 files changed, 122 insertions(+), 0 deletions(-)
create mode 100755 contrib/kde-credetials-helper/git-kde-credentials-helper.py
diff --git a/contrib/kde-credetials-helper/git-kde-credentials-helper.py b/contrib/kde-credetials-helper/git-kde-credentials-helper.py
new file mode 100755
index 0000000..8d3be4d
--- /dev/null
+++ b/contrib/kde-credetials-helper/git-kde-credentials-helper.py
@@ -0,0 +1,122 @@
+#!/usr/bin/env python
+# encoding=utf-8
+#
+# Copyright 2011, Lukas Sandström
+#
+# Licensed under the GPL version 2.
+
+import sys, commands
+from PyQt4.QtCore import QString
+from PyKDE4.kdecore import i18n, ki18n, KAboutData, KCmdLineArgs, KCmdLineOptions
+from PyKDE4.kdeui import KApplication, KWallet, KPasswordDialog
+
+appName = "git-kde-credentials-helper"
+catalog = ""
+programName = ki18n ("Git KDE credentials helper")
+version = "0.1"
+description = ki18n ("Credentials storage helper for Git")
+license = KAboutData.License_GPL_V2
+copyright = ki18n ("(c) 2011 Lukas Sandström")
+text = ki18n ("none")
+homePage = "http://www.git-scm.com"
+bugEmail = "luksan@gmail.com"
+
+aboutData = KAboutData (appName, catalog, programName, version, description,
+ license, copyright, text, homePage, bugEmail)
+
+class CredentialHelper(KApplication):
+ def __init__(self, token, username = None, desc = None, reject = False):
+ super(CredentialHelper, self).__init__()
+ self.password = None
+ self.username = username
+ self.save_password = False
+ self.token = token
+ self.desc = desc
+
+ if not self.token:
+ return
+
+ self.open_wallet()
+
+ if reject:
+ self.wallet.removeEntry(QString(token))
+ return
+
+ if not self.check_wallet():
+ self.ask_password_dialog()
+
+ if self.save_password:
+ self.store_password()
+
+ self.output_credentials()
+
+ def output_credentials(self):
+ if self.username:
+ print "username=" + self.username
+ if self.password:
+ print "password=" + self.password
+
+ def store_password(self):
+ self.wallet.writeMap(QString(self.token),
+ {QString("username") : QString(self.username),
+ QString("password") : QString(self.password)})
+
+ def open_wallet(self):
+ self.wallet = KWallet.Wallet.openWallet(
+ KWallet.Wallet.LocalWallet(), 0, KWallet.Wallet.Synchronous)
+ if not self.wallet.isOpen():
+ return None
+ if not self.wallet.hasFolder("GitCredentials"):
+ self.wallet.createFolder("GitCredentials")
+ self.wallet.setFolder("GitCredentials")
+
+ def check_wallet(self):
+ (res, data) = self.wallet.readMap(self.token)
+ if res != 0:
+ return None
+ try:
+ self.username = data[QString("username")]
+ self.password = data[QString("password")]
+ except KeyError:
+ return None
+ return self.username and self.password
+
+ def ask_password_dialog(self):
+ dlg = KPasswordDialog(None,
+ KPasswordDialog.KPasswordDialogFlag(
+ KPasswordDialog.ShowKeepPassword |
+ KPasswordDialog.ShowUsernameLine))
+ if self.desc:
+ desc = self.desc
+ else:
+ desc = self.token
+ dlg.setPrompt(i18n("Please enter username and password for %s" % (desc)))
+ dlg.setUsername(self.username)
+ dlg.setKeepPassword(True)
+ if not dlg.exec_():
+ return
+ self.username = dlg.username()
+ self.password = dlg.password()
+ self.save_password = dlg.keepPassword()
+
+def main():
+ KCmdLineArgs.init(sys.argv, aboutData)
+
+ options = KCmdLineOptions()
+ options.add("unique <token>", ki18n("Unique token identifying the credential"))
+ options.add("description <desc>", ki18n("Human readable description of the credential"))
+ options.add("username <username>", ki18n("Requested username"))
+ options.add("reject", ki18n("Purge credential"))
+
+ KCmdLineArgs.addCmdLineOptions(options)
+ args = KCmdLineArgs.parsedArgs();
+
+ username = args.getOption("username")
+ token = args.getOption("unique")
+ desc = args.getOption("description")
+ reject = args.isSet("reject")
+
+ app = CredentialHelper(token, username, desc, reject)
+
+if __name__ == "__main__":
+ main()
--
1.7.6.1
^ permalink raw reply related
* [PATCH] checkout: be quiet if not on isatty()
From: Steffen Daode Nurpmeso @ 2011-08-27 19:45 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Steffen Daode Nurpmeso, Tay Ray Chuan, git
In-Reply-To: <cover.1314472512.git.sdaoden@gmail.com>
Signed-off-by: Steffen Daode Nurpmeso <sdaoden@gmail.com>
---
builtin/checkout.c | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/builtin/checkout.c b/builtin/checkout.c
index 4eaedff..6fb6d48 100644
--- a/builtin/checkout.c
+++ b/builtin/checkout.c
@@ -958,6 +958,7 @@ int cmd_checkout(int argc, const char **argv, const char *prefix)
gitmodules_config();
git_config(git_checkout_config, &opts);
+ opts.quiet = !isatty(2);
opts.track = BRANCH_TRACK_UNSPECIFIED;
argc = parse_options(argc, argv, prefix, options, checkout_usage,
--
1.7.6.537.ga80e5.dirty
^ permalink raw reply related
* [PATCH] checkout: be quiet if not on isatty()
From: Steffen Daode Nurpmeso @ 2011-08-27 19:45 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Steffen Daode Nurpmeso, Tay Ray Chuan, git
In-Reply-To: <7vwrg5u7oz.fsf@alter.siamese.dyndns.org>
(Original subject was:
Re: [PATCH] progress: use \r as EOL only if isatty(stderr) is true)
@ Junio C Hamano <gitster@pobox.com> wrote (2011-06-28 20:33+0200):
> [..]
> I thought that we try to disable the progress pretty much
> everywhere when we are not talking to a tty[..]
Today i got this by accident:
================================================================
openbsd-src.git-null: performing reduce
Checking out files: 17% (11410/65508) ^MChecking out files:
18% (11792/65508) ^M [..]
This is the output of my dumb arena-manager, which i append after
the first scissor for reference. (Maybe someone finds it useful.
It's a dumb sh(1) thing, i don't do shell scripting that often.)
I haven't actually tried it yet, but setting .quiet for
unpack_trees may stop this output. (Compilation succeeds,
though.) I still and *truly* have no idea of the git(1)
internals, so i may oversee .. just *any* thinkable side-effect.
Hope this helps a bit.
(Actual patch as response. Have a nice weekend.)
--Steffen
Ciao, sdaoden(*)(gmail.com)
ASCII ribbon campaign ( ) More nuclear fission plants
against HTML e-mail X can serve more coloured
and proprietary attachments / \ and sounding animations
-- >8 --
#!/bin/bash
# NOTE: this acts according to extensions, e.g.:
# docutils.svn-git-null: git svn
# groff.cvs-git-null : git cvsimport
# openbsd-src.git-null : git
# vim.hg-null : Mercurial
# If a '-null' is in the suffix one may use 'reduce' and 'expand'
# modes; for git(1) these modes require an empty NULL branch:
# $ git co --orphan NULL && git rm -rf '*' &&
# echo DEFAULT-BRANCH >NULL && git add NULL && git ci -m NULL
# Mercurial has builtin support for 'null'. (Nice for backups.)
# Top dir where everything happens
ARENA="$HOME/arena/code.extern.repos"
##
GIT=git
HG=hg
SVN=svn
CVS='cvs -fz 9 update -ACRPd'
ESTAT=0
LOGFILE=lastlog.txt
CVSROOT=/nonexistent
CURR=/nonexistent
log() {
echo "$*"
echo "$*" >> $LOGFILE
}
logerr() {
echo >&2 "ERROR: $*"
echo "ERROR: $*" >> $LOGFILE
ESTAT=1
}
SEP='================================================================'
intro() {
log ''
log $SEP
log $1
}
final() {
local es=$?
if test $es -eq 0; then
log "... ok: $1"
else
logerr "$1"
ESTAT=$es
fi
log $SEP
log ''
}
if test "$BASH" = x""; then
echo >&2 "This script needs the GNU bash shell interpreter"
exit 1
fi
cd $ARENA || {
echo >&2 "Failed to chdir to $ARENA"
exit 1
}
rm -rf $LOGFILE || {
echo >&2 "Failed to remove stale $LOGFILE"
exit 1
}
MODE="$1"
shift
PARAMS="$@"
set -u
test $# -ne 0 || PARAMS=$(echo *.*)
# Perform basename cleanup and move over to $params[]
log "$0: script startup, mode $MODE"
declare -a params
for rd in $PARAMS; do
rd=$(echo "$rd" | sed -Ee 's/(.+)\/+$/\1/' -e 's/.*\/([^/]+)$/\1/')
params[${#params[*]}]="$rd"
done
GITDID=
case "$MODE" in
reduce|expand)
if test "$MODE" == 'reduce'; then
git_branch='NULL'
hg_branch='null'
else
git_branch=
hg_branch=''
fi
for rd in ${params[@]}; do
if test "$rd" == "${rd/null/}"; then
log "[$rd: $MODE does not apply]"
continue
fi
intro "$rd: performing $MODE"
set -o pipefail
( cd "$rd" || exit 1
if test "$rd" != "${rd/git-null}"; then
# On branch NULL file NULL contains master branch's name
if test -z "$git_branch"; then
if test -f NULL; then
git_branch=$(<NULL)
else
echo >&2 "No file NULL in $rd"
git_branch=master
fi
fi
$GIT checkout $git_branch
else
$HG up $hg_branch
fi
exit $?
) 2>&1 | tee -a "$LOGFILE"
final "$rd"
set +o pipefail
done
;;
update)
for rd in ${params[@]}; do
intro "$rd: performing $MODE"
set -o pipefail
( cd "$rd" || exit 1
if test "$rd" != "${rd/.git}"; then
#$GIT pull -v --ff-only --stat --prune
$GIT fetch --verbose --prune
GITDID=1
elif test "$rd" != "${rd/.svn-git}"; then
$GIT svn rebase
GITDID=1
elif test "$rd" != "${rd/.cvs-git}"; then
ldir='.git/.cvsps'
tar xjf "$ldir.tbz" || {
echo >&2 "$rd: bail: tar xjf $ldir.tbz"
exit 1
}
hdir="$HOME/.cvsps"
test -d "$hdir" || mkdir "$hdir" || {
echo >&2 "$rd: failed to create $hdir directory"
exit 2
}
root="$ldir/CVSROOT"
repo="$ldir/MODULE"
cache=$(<$ldir/CVSPS_FILE)
mv -f "$ldir/cvs-revisions" .git/
mv -f "$ldir/$cache" "$hdir/$cache"
$GIT cvsimport -aR -r origin -p '-u,--cvs-direct' \
-d $(<$root) $(<$repo)
es=$?
GITDID=1
mv -f .git/cvs-revisions "$ldir/"
mv -f "$hdir/$cache" "$ldir/$cache"
tar cjf "$ldir.tbz" "$ldir" || {
echo >&2 "$rd: bail: tar cjf $ldir.tbz $ldir"
exit 3
}
rm -rf $ldir
exit $es
elif test "$rd" != "${rd/.hg}"; then
$HG -v pull #-u
elif test "$rd" != "${rd/.svn}"; then
$SVN update
elif test "$rd" != "${rd/.cvs}"; then
$CVS
else
echo "Unknown revision-control-system: $rd"
exit 1
fi
) 2>&1 | tee -a "$LOGFILE"
final "$rd"
set +o pipefail
done
;;
fullgc|gc)
gct=
test "$MODE" == fullgc && gct=--aggressive
for rd in ${params[@]}; do
intro "$rd: performing $MODE"
set -o pipefail
( cd "$rd" || exit 1
test "$rd" != "${rd/.git}" && git gc $gct
) 2>&1 | tee -a "$LOGFILE"
final "$rd"
set +o pipefail
done
;;
*)
echo 'USAGE: manager reduce|expand|update|gc|fullgc LIST-OF-DIRECTORIES'
exit 1
;;
esac
test x"$GITDID" != x && log 'git(1) fetched data - do arena-manager [full]gc ..'
test $ESTAT -ne 0 && log 'Errors occurred!'
exit $ESTAT
# vim:set fenc=utf-8 filetype=sh syntax=sh ts=4 sts=4 sw=4 et tw=79:
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox