* [PATCH 0/3] read-tree cleanups
From: Michael J Gruber @ 2011-09-21 7:48 UTC (permalink / raw)
To: git; +Cc: Joshua Jensen, Junio C Hamano
In-Reply-To: <4E7996AA.4040909@drmicha.warpmail.net>
These are a few cleanups I noticed while checking Joshua's sparse checkout
problem when swithcing branches with a dirty sparse tree.
They are independent of a possible fix.
Michael J Gruber (3):
unpack-trees: print "Aborting" to stderr
git-read-tree.txt: language and typography fixes
git-read-tree.txt: correct sparse-checkout and skip-worktree
description
Documentation/git-read-tree.txt | 48 +++++++++++++++++++-------------------
unpack-trees.c | 2 +-
2 files changed, 25 insertions(+), 25 deletions(-)
--
1.7.7.rc0.469.g9eb94
^ permalink raw reply
* Re: git checkout under 1.7.6 does not properly list untracked files and aborts
From: Michael J Gruber @ 2011-09-21 7:47 UTC (permalink / raw)
To: Joshua Jensen; +Cc: git@vger.kernel.org
In-Reply-To: <4E78DACF.3030200@workspacewhiz.com>
Joshua Jensen venit, vidit, dixit 20.09.2011 20:26:
> ----- Original Message -----
> From: Michael J Gruber
> Date: 9/20/2011 9:10 AM
>> Can you provide a simple test case, such as this one:
>>
>> ---%<---
>> #!/bin/sh
>>
>> rm -Rf utest || exit 1
>> mkdir utest || exit 1
>> cd utest || exit 1
>> git init
>> echo tracked>a
>> git add a
>> git commit -m a a
>> git branch side
>> echo tracked>b
>> git add b
>> git commit -m b
>> cat b
>> git checkout side
>> cat b
>> echo untracked>b
>> cat b
>> git checkout master
>> cat b
>> ---%<---
>>
>> Does this test reproduce your problem on msysgit?
> As listed, your script produces the same results on msysGit.
>
> It appears the issue is related to sparse checkouts:
>
> ---%<---
> #!/bin/sh
>
> rm -Rf utest || exit 1
> mkdir utest || exit 1
> cd utest || exit 1
> git init
> git config core.sparseCheckout true
> echo *>.git/info/sparse-checkout
> echo tracked>a
> git add a
> git commit -m a a
> git branch side
> echo tracked>b
> git add b
> git commit -m b
> cat b
> git checkout side
> cat b
> echo untracked>b
> cat b
> git checkout master
> cat b
> ---%<---
>
> -Josh
Interesting. So, it is related to sparse, it seems, and there is also a
mistake in the documentation (which contradicts itself, btw). With your
script, since all files are requested to be checked out ('*'), none
should have skip-worktree set, and the result should be the same as with
my version. But I get this:
Initialized empty Git repository in /tmp/t/utest/.git/
[master (root-commit) 5929c8b] a
1 files changed, 1 insertions(+), 0 deletions(-)
create mode 100644 a
[master 60ad69e] b
1 files changed, 1 insertions(+), 0 deletions(-)
create mode 100644 b
tracked
Switched to branch 'side'
cat: b: No such file or directory
untracked
untracked
That is probably the same output as for you. The final "git checkout
master" errored out without doing anything and without message. I'll
send a few cleanups now, and do some bisecting and thinking later;
though there are people whose sparse-knowledge is way less sparse than
mine ;)
Michael
^ permalink raw reply
* Re: [PATCH di/fast-import-deltified-tree] Windows: define S_ISUID properly
From: Dmitry Ivankov @ 2011-09-21 7:38 UTC (permalink / raw)
To: git
In-Reply-To: <4E798538.7070106@viscovery.net>
Johannes Sixt <j.sixt <at> viscovery.net> writes:
>
> From: Johannes Sixt <j6t <at> kdbg.org>
>
> 8fb3ad76 (fast-import: prevent producing bad delta) introduced the first
> use of S_ISUID. Since before this commit the value was irrelevant, we had
> only a dummy definition in mingw.h. But beginning with this commit the
> macro must expand to a reasonable value. Make it so.
>
> We do not change S_ISGID from the value 0 because it is used in path.c
> (via FORCE_DIR_SET_GID) to set the mode on directories in a manner that
> is not supported on Windows, and 0 is the right value in this case.
>
> Signed-off-by: Johannes Sixt <j6t <at> kdbg.org>
> ---
> compat/mingw.h | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/compat/mingw.h b/compat/mingw.h
> index 547568b..e2c89d6 100644
> --- a/compat/mingw.h
> +++ b/compat/mingw.h
> @@ -22,7 +22,7 @@ typedef int socklen_t;
> #define S_IWOTH 0
> #define S_IXOTH 0
> #define S_IRWXO (S_IROTH | S_IWOTH | S_IXOTH)
> -#define S_ISUID 0
> +#define S_ISUID 04000
> #define S_ISGID 0
> #define S_ISVTX 0
>
Ow, it's awkward that the issue was discussed in [1] but slipped and nobody
noticed, especially me being a patch sender.
If we choose patch from [1] I'd also change a comment to smth like
/*
* We abuse the 04000 bit on directories to mean "do not delta".
* It is a S_ISUID bit on setuid platforms and an unused bit on
* non-setuid platforms supported in git. In either case git ignores
* the bit, so it's safe to abuse it locally.
*/
[1] http://thread.gmane.org/gmane.comp.version-control.git/179223/focus=179762
^ permalink raw reply
* Re: [PATCH] bisect: fix exiting when checkout failed in bisect_start()
From: Jon Seymour @ 2011-09-21 6:42 UTC (permalink / raw)
To: Christian Couder; +Cc: Junio C Hamano, git, Joel Kaasinen
In-Reply-To: <20110921051725.5255.6756.chriscool@tuxfamily.org>
On Wed, Sep 21, 2011 at 3:17 PM, Christian Couder
<chriscool@tuxfamily.org> wrote:
> Commit 4796e823 ("bisect: introduce --no-checkout support into porcelain." Aug 4 2011)
> made checking out the branch where we started depends on the "checkout" mode. But
> unfortunately it lost the "|| exit" part after the checkout command.
>
> As it makes no sense to continue if the checkout failed and as people have already
> complained that the error message given when we just exit in this case is not clear, see:
>
> http://thread.gmane.org/gmane.comp.version-control.git/180733/
>
> this patch adds a "|| die <hopefully clear message>" part after the checkout command.
>
> Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
> ---
> git-bisect.sh | 3 ++-
> 1 files changed, 2 insertions(+), 1 deletions(-)
>
> diff --git a/git-bisect.sh b/git-bisect.sh
> index e0ca3fb..5fb4291 100755
> --- a/git-bisect.sh
> +++ b/git-bisect.sh
> @@ -129,7 +129,8 @@ bisect_start() {
> start_head=$(cat "$GIT_DIR/BISECT_START")
> if test "z$mode" != "z--no-checkout"
> then
> - git checkout "$start_head" --
> + git checkout "$start_head" -- ||
> + die "$(eval_gettext "Checking out '\$start_head' failed. Try 'git bisect reset <validbranch>'.")"
> fi
> else
> # Get rev from where we start.
> --
> 1.7.7.rc0.72.g4b5ea.dirty
>
>
Thanks. Looks good to me.
Acked-by: Jon Seymour <jon.seymour@gmal.com>
^ permalink raw reply
* [PATCH di/fast-import-deltified-tree] Windows: define S_ISUID properly
From: Johannes Sixt @ 2011-09-21 6:33 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Git Mailing List, msysGit
From: Johannes Sixt <j6t@kdbg.org>
8fb3ad76 (fast-import: prevent producing bad delta) introduced the first
use of S_ISUID. Since before this commit the value was irrelevant, we had
only a dummy definition in mingw.h. But beginning with this commit the
macro must expand to a reasonable value. Make it so.
We do not change S_ISGID from the value 0 because it is used in path.c
(via FORCE_DIR_SET_GID) to set the mode on directories in a manner that
is not supported on Windows, and 0 is the right value in this case.
Signed-off-by: Johannes Sixt <j6t@kdbg.org>
---
compat/mingw.h | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/compat/mingw.h b/compat/mingw.h
index 547568b..e2c89d6 100644
--- a/compat/mingw.h
+++ b/compat/mingw.h
@@ -22,7 +22,7 @@ typedef int socklen_t;
#define S_IWOTH 0
#define S_IXOTH 0
#define S_IRWXO (S_IROTH | S_IWOTH | S_IXOTH)
-#define S_ISUID 0
+#define S_ISUID 04000
#define S_ISGID 0
#define S_ISVTX 0
--
1.7.7.rc2.1135.gf321f
^ permalink raw reply related
* [PATCH v4] Documentation/git-update-index: refer to 'ls-files'
From: Stefan Naewe @ 2011-09-21 6:21 UTC (permalink / raw)
To: gitster, git; +Cc: Stefan Naewe
In-Reply-To: <7vmxdz56xt.fsf@alter.siamese.dyndns.org>
'ls-files' refers to 'update-index' to show how the 'assume unchanged'
bit can be seen. This makes the connection 'bi-directional'.
Signed-off-by: Stefan Naewe <stefan.naewe@gmail.com>
---
As Junio suggested, move the new sentence a little to the place where
setting and unsetting are explained.
Documentation/git-update-index.txt | 7 +++++--
1 files changed, 5 insertions(+), 2 deletions(-)
diff --git a/Documentation/git-update-index.txt b/Documentation/git-update-index.txt
index d393129..d8af8ae 100644
--- a/Documentation/git-update-index.txt
+++ b/Documentation/git-update-index.txt
@@ -264,7 +264,9 @@ tree files, you have to explicitly tell git about it by dropping
"assume unchanged" bit, either before or after you modify them.
In order to set "assume unchanged" bit, use `--assume-unchanged`
-option. To unset, use `--no-assume-unchanged`.
+option. To unset, use `--no-assume-unchanged`. To see which files
+have the "assume unchanged" bit set, use `git ls-files -v`
+(see linkgit:git-ls-files[1]).
The command looks at `core.ignorestat` configuration variable. When
this is true, paths updated with `git update-index paths...` and
@@ -363,7 +365,8 @@ ctime for marking files processed) (see linkgit:git-config[1]).
SEE ALSO
--------
linkgit:git-config[1],
-linkgit:git-add[1]
+linkgit:git-add[1],
+linkgit:git-ls-files[1]
GIT
---
--
1.7.7.rc2
^ permalink raw reply related
* [PATCH] bisect: fix exiting when checkout failed in bisect_start()
From: Christian Couder @ 2011-09-21 5:17 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Joel Kaasinen, Jon Seymour
Commit 4796e823 ("bisect: introduce --no-checkout support into porcelain." Aug 4 2011)
made checking out the branch where we started depends on the "checkout" mode. But
unfortunately it lost the "|| exit" part after the checkout command.
As it makes no sense to continue if the checkout failed and as people have already
complained that the error message given when we just exit in this case is not clear, see:
http://thread.gmane.org/gmane.comp.version-control.git/180733/
this patch adds a "|| die <hopefully clear message>" part after the checkout command.
Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
---
git-bisect.sh | 3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/git-bisect.sh b/git-bisect.sh
index e0ca3fb..5fb4291 100755
--- a/git-bisect.sh
+++ b/git-bisect.sh
@@ -129,7 +129,8 @@ bisect_start() {
start_head=$(cat "$GIT_DIR/BISECT_START")
if test "z$mode" != "z--no-checkout"
then
- git checkout "$start_head" --
+ git checkout "$start_head" -- ||
+ die "$(eval_gettext "Checking out '\$start_head' failed. Try 'git bisect reset <validbranch>'.")"
fi
else
# Get rev from where we start.
--
1.7.7.rc0.72.g4b5ea.dirty
^ permalink raw reply related
* Re: mac osx
From: Kyle Neath @ 2011-09-21 3:40 UTC (permalink / raw)
To: tom smitts; +Cc: git
In-Reply-To: <loom.20110921T002437-246@post.gmane.org>
On Tue, Sep 20, 2011 at 3:40 PM, tom smitts <tomsmitts@ymail.com> wrote:
> Do the git maintainers really think any mac users have
> a clue which git install package to download? You
> put some arcane chipset designation in the package
> name! Why make mac installers at all? Mac users
> know their operating system number, e.g. 10.6.7,
> and that's all. I doubt Windows users know any better.
> And I doubt you can find anywhere on a mac that says
> i386 or whatever the heck the other dumb
> designation is.
Yikes! That's definitely not good. I'll see what we can do about updating
git-scm.com to point to a more reasonable installer for OSX. I haven't clicked
that link in a long time and had no idea it was so confusing.
I've created an issue so we can track it, if you'd like to follow along:
https://github.com/schacon/gitscm/issues/16
Kyle Neath
Director of Design, GitHub
^ permalink raw reply
* Re: [PATCH 2/3] branch: teach --edit-description option
From: Junio C Hamano @ 2011-09-21 2:44 UTC (permalink / raw)
To: Andrew Ardill; +Cc: git, Linus Torvalds
In-Reply-To: <CAH5451nai988=jB8cgFcUaQZWWUyALC-tOSV_jdLX0r_2UfbPw@mail.gmail.com>
Andrew Ardill <andrew.ardill@gmail.com> writes:
> I understand your reasoning here, however is there a way to allow
> setting the branch description in, for example, a script?
As you read in the patch, especially the documentation part, there is not
a way to do that.
I am not interested because it does not directly help my cause of helping
the human communication between the kernel developers who may want to
perform a signed push to their public repository and send their pull
requests with the same message to Linus.
That does _not_ mean I will _reject_ a patch to add such a feature. It
just means writing such a patch myself or reviewing and accepting such a
patch is not very high in my prioritized list at this point in the
evolution of the series. Teaching the use of the information to other
commands such as "format-patch --cover-letter" would have much higher
precedence.
> Additionally I can imagine it would be useful to be able to set the
> branch description from another tool, what is the recommended way of
> doing that? Should tools modify the config directly??
An obvious answer: "do whatever you want". The only rule that the programs
that need to follow is that branch.$name.description has the string to use
to obtain the explanation text.
How they achieve that (perhaps by running "git config") is of secondary
importance.
^ permalink raw reply
* Re: [PATCH 1/5] git-p4 tests: refactor, split out common functions
From: Junio C Hamano @ 2011-09-21 2:35 UTC (permalink / raw)
To: Pete Wyckoff; +Cc: git, Vitor Antunes, Luke Diamand, Chris Li
In-Reply-To: <7vfwjq4o96.fsf@alter.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> Yeah, something like
>
> : start
> p4d &
> echo $! >$pidfile
Obviously I should have written:
: stop
pid=$(cat "$pidfile")
while kill -0 $pid
do
kill $pid
sleep 1
done
Sorry for the noise.
> : stop
> while kill -0 $pidfile
> do
> kill $pidfile
> sleep 1
> done
>
>> Finding an unused port is also a pain.
>
> I think the way t55xx series assign LIB_HTTPD_PORT is an acceptable
> compromise.
^ permalink raw reply
* Re: [PATCH 1/5] git-p4 tests: refactor, split out common functions
From: Junio C Hamano @ 2011-09-21 2:34 UTC (permalink / raw)
To: Pete Wyckoff; +Cc: git, Vitor Antunes, Luke Diamand, Chris Li
In-Reply-To: <20110921012917.GA27256@arf.padd.com>
Pete Wyckoff <pw@padd.com> writes:
> Yes, this is all very shoddy, and I suspect that I don't need the
> initial kill_p4d as long as the other tests fail nicely.
>
> But your point about killing the _wrong_ p4d is good. But p4d
> isn't friendly like other daemons that will drop a pid file for
> help in future cleanup. I can run it without the "-d", in which
> case it does not daemonize. Then I should be able to use shell
> job control to kill off the one I started, hopefully.
Yeah, something like
: start
p4d &
echo $! >$pidfile
: stop
while kill -0 $pidfile
do
kill $pidfile
sleep 1
done
> Finding an unused port is also a pain.
I think the way t55xx series assign LIB_HTTPD_PORT is an acceptable
compromise.
^ permalink raw reply
* 群发软件+买家搜索机+109届广交会买家、海关数据,B2B询盘买家500万
From: 仅10元每天 @ 2011-09-21 2:28 UTC (permalink / raw)
To: girlykoh, gis.beilin, giseleorlandi, gislpl, git, gitech, gitm,
giulia.dellasin
群发软件+109届广交会买家、海关数据、搜索引擎买家,B2B询盘买家共500万,仅10元每天。
群发软件+109届广交会买家、海关数据、搜索引擎买家,B2B询盘买家共500万,仅10元每天。
保证每天都有买家回复。
保证每天都有买家回复。
保证每天都有买家回复。
1、群发软件： 操作简单，功能强大，模仿人工操作模式，到达率高，日发送5万封以上。
2、500万买家资源： 赠送的500万买家资源库，更新 (可以按照您的产品提取出来，更精准开发)。
3、超级海外买家Email搜索机： 内置了600万行业关键词，根据长尾词搜索，结果更精确匹配；每天能搜索1-2万以上买家真实EMAIL，成单率高。
要的抓紧联系QQ: 1339625218 或者立即回复邮箱: 1339625218@qq.com
要的抓紧联系QQ: 1339625218 或者立即回复邮箱: 1339625218@qq.com
要的抓紧联系QQ: 1339625218 或者立即回复邮箱: 1339625218@qq.com
免费赠送:
一共8个包(数据是全行业的，按照行业分好类，并且可以按照关键词查询的)：
1，2011春季109届广交会买家现场询盘数据库新鲜出炉，超级新鲜买家，新鲜数据，容易成单！
2，购买后可以免费更新2011秋季广交会+2012春季广交会买家数据。太超值了。
3，最新全球买家库,共451660条数据。 (最新更新日期 2011-05-16日)
4，2008年,2009年,2010年 春季+秋季广交会买家名录，103 104 105 106 107 108 共六届 共120.6万数据。
5，2010年国际促销协会（PPAI）成员名单 PPAI Members Directory，非常重要的大买家。
6，2010年到香港采购的国外客人名录(香港贸发局提供)，共7.2万数据，超级重要的买家。
7，48.68万条最新买家询盘，购买后每月更新 1-2万条，包括2部分，1，最新的询盘 2，最新的展会买家。免费更新36个月。
8，2009年海关提单数据piers版数据 1千万。
诚信为本，支持支付宝担保交易 (先发货并安装设置群发软件，然后付款) 彻底打消您的 顾虑。
精准数据-成单率极高
精准数据-成单率极高
精准数据-成单率极高
精准数据-成单率极高
精准数据-成单率极高
^ permalink raw reply
* Re: [PATCH 1/5] git-p4 tests: refactor, split out common functions
From: Pete Wyckoff @ 2011-09-21 1:29 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Vitor Antunes, Luke Diamand, Chris Li
In-Reply-To: <7v7h55cyis.fsf@alter.siamese.dyndns.org>
gitster@pobox.com wrote on Sun, 18 Sep 2011 14:48 -0700:
> Pete Wyckoff <pw@padd.com> writes:
>
> > Introduce a library for functions that are common to
> > multiple git-p4 test files.
> >
> > Separate the tests related to detecting p4 branches
> > into their own file, and add a few more.
> >
> > Signed-off-by: Pete Wyckoff <pw@padd.com>
> > ---
> > t/lib-git-p4.sh | 55 ++++++++++++
> > t/t9800-git-p4.sh | 108 ++---------------------
> > t/t9801-git-p4-branch.sh | 221 ++++++++++++++++++++++++++++++++++++++++++++++
> > 3 files changed, 283 insertions(+), 101 deletions(-)
> > create mode 100644 t/lib-git-p4.sh
> > create mode 100755 t/t9801-git-p4-branch.sh
>
> I take that you meant "coding style" by "generic test beauty" in the cover
> letter, so here are some minor nitpicks.
Definitely appreciated.
> > 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
>
> What happens when tests are run in parallel (make -j or prove --jobs) and
> 9800 and 9801 are run at the same time?
Hard... part of the p4d pain below.
> > +export P4PORT=localhost:$P4DPORT
> > +export P4CLIENT=client
> > +
> > +db="$TRASH_DIRECTORY/db"
> > +cli="$TRASH_DIRECTORY/cli"
> > +git="$TRASH_DIRECTORY/git"
> > +
> > +start_p4d()
> > +{
>
> Prevalent style in t/ and scripted part of Git in general is to begin a
> shell function like this, with SP on both sides of () and opening brace
> on the same line.
Thanks, fixed.
> 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" &&
>
> It is unfortunate that you have to use pgrep. I am unfamiliar with p4, but
> do you have any control how p4d is started during this test? If the first
> use of client automagically starts p4d without your control, that would be
> harder to arrange, but the point I am getting at is that if you know when
> you start p4d yourself and that is the only p4d process you use, you
> should be keep its pid in $TRASH_DIRECTORY somewhere and replace these
> with
>
> pid=$(cat "$TRASH_DIRECTORY/p4d_pid") &&
> kill -0 "$pid"
>
> to see if that daemon is still alive.
>
> You call kill_p4d at the very beginning of t9800; what instance of p4d are
> you trying to kill? Who could have started it? For you to be able to kill
> (and nobody sane would be running the test suite as "root", I hope), it
> would be your process, but would it be possible that you are doing some
> other important thing using p4 that is not related to git-p4 development
> or testing at all, perhaps listening to a port different from 10669? Would
> it be necessary to kill that other p4d to run these tests in a predicatable
> and reproducible environment?
>
> I would very much more prefer if at the very beginning you started p4d at
> the port assigned for the test and fail the test if it cannot start for
> whatever reason. Perhaps the reason you cannot start a p4d is because a
> stale p4d instance is hanging around from previous round of test, and if
> that is the case, then that is the bug we need to fix in the _previous_
> test, not something we want to sweep under the rug by killing it during
> this round of test.
Yes, this is all very shoddy, and I suspect that I don't need the
initial kill_p4d as long as the other tests fail nicely.
But your point about killing the _wrong_ p4d is good. But p4d
isn't friendly like other daemons that will drop a pid file for
help in future cleanup. I can run it without the "-d", in which
case it does not daemonize. Then I should be able to use shell
job control to kill off the one I started, hopefully.
Finding an unused port is also a pain. I'll see if p4d produces
parseable error messages that can indicate a taken port.
Otherwise, hardcoding a port per test is a good idea, and will
fix the parallel-run problem. Hopefully no "production" p4d
also happens to be running at the same random port with this
approach.
> > + for i in {1..5} ; do
>
> That {1..5} does not pass POSIX shells, such as /bin/dash.
>
> for i in 1 2 3 4 5
> do
> ...
Ah. Or `seq`, but not sure its existence can be counted on.
Fixed as you suggest for this teensy list.
> > + test_debug "ps wl `echo $pid`" &&
> > + kill $pid 2>/dev/null &&
> > + pgrep -f p4d >/dev/null || break &&
>
> You are saying "all of these things would hold true if we attempt to kill
> it and it still is alive" with the chain of "&&" up to that last pgrep,
> and then with "||", you say "otherwise we do not have to keep sending the
> signal to it anymore". But the extra "&&" after "break" is unneeded and
> misleading.
Yes, that is icky. I'll send this instead, next time (unless I
can fix the p4d issues):
kill $pid 2>/dev/null &&
if pgrep -f p4d >/dev/null ; then
break
fi &&
> > + sleep 0.2
>
> That 0.2 does not look like a non-negative decimal interger like POSIX
> wants to have.
Switched to 1. Optimization of 0.2 isn't important.
> > +test_expect_success 'start p4d' '
> > + kill_p4d || : &&
> > + start_p4d &&
> > + cd "$TRASH_DIRECTORY"
> > '
>
> Don't "chdir" around in the test, and worse yet hide some "cd" in helper
> functions. The seemingly unnecessary "cd $TRASH_DIRECTORY" at the end,
> which may not even happen if start_p4d fails, is because start_p4d has a
> hidden "cd" somewhere (which in turn may or may not run depending on where
> in the && chain you have a failure).
>
> One way to keep the test cleaner is to do the helper functions like the
> following, so that the callers do not have to worry about where they end
> up with:
>
> start_p4d () {
> mkdir -p "$db" "$cli" "$git" &&
> p4d -q -d -r "$db" -p "$P4DPORT" &&
> (
> cd "$cli" &&
> p4 client -i <<-EOF
> ...
> EOF
> )
> }
I see; chdir in a subshell. Will rework these to remove the
silly post-test cd, and put other cds inside shells.
> > test_expect_success 'add p4 files' '
> > cd "$cli" &&
> > echo file1 >file1 &&
> > p4 add file1 &&
> > p4 submit -d "file1" &&
> > ...
> > cd "$TRASH_DIRECTORY"
> > '
>
> The same issue here.
>
> test_expect_success 'add p4 files' '
> (
> cd "$cli" &&
> echo file1 >file1 &&
> ...
> )
> '
Thanks for the useful critique. I'll think through the difficult
issues with p4d, and resubmit the whole series post-release.
-- Pete
^ permalink raw reply
* Re: [PATCH 2/3] branch: teach --edit-description option
From: Andrew Ardill @ 2011-09-21 0:15 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Linus Torvalds
In-Reply-To: <7vty864y24.fsf_-_@alter.siamese.dyndns.org>
On 21 September 2011 09:02, Junio C Hamano <gitster@pobox.com> wrote:
> Using branch.$name.description as the configuration key, give users a
> place to write about what the purpose of the branch is and things like
> that, so that various subsystems, e.g. "push -s", "request-pull", and
> "format-patch --cover-letter", can later be taught to use this
> information.
>
> The "-m" option similar to "commit/tag" is deliberately omitted, as the
> whole point of branch description is about giving descriptive information
> (the name of the branch itself is a better place for information that fits
> on a single-line).
I understand your reasoning here, however is there a way to allow
setting the branch description in, for example, a script?
Additionally I can imagine it would be useful to be able to set the
branch description from another tool, what is the recommended way of
doing that? Should tools modify the config directly??
Regards,
Andrew
^ permalink raw reply
* Re: mac osx
From: Junio C Hamano @ 2011-09-20 23:29 UTC (permalink / raw)
To: tom smitts; +Cc: git
In-Reply-To: <loom.20110921T002437-246@post.gmane.org>
tom smitts <tomsmitts@ymail.com> writes:
> Do the git maintainers really think any mac users have
> a clue which git install package to download?
Not a clue.
> You put some arcane chipset designation in the package
> name! Why make mac installers at all?
No, I don't, I do not make mac installers.
Unfortunately I do not know which one of "Git maintainers" make installers
for Macintosh. Hopefully the guilty-party would respond, or perhaps the
person who make installers do not live on this list, in which case the
complaint needs to be redirected to the person and off of this mailing
list.
Thanks.
^ permalink raw reply
* [PATCH] request-pull: use the branch description
From: Junio C Hamano @ 2011-09-20 23:03 UTC (permalink / raw)
To: git; +Cc: Linus Torvalds
In-Reply-To: <7vy5xi4y3m.fsf@alter.siamese.dyndns.org>
Now we have branch descriptions stored in the repository, we can
use it when preparing the request-pull message.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
git-request-pull.sh | 20 +++++++++++++++++++-
1 files changed, 19 insertions(+), 1 deletions(-)
diff --git a/git-request-pull.sh b/git-request-pull.sh
index 438e7eb..626cf25 100755
--- a/git-request-pull.sh
+++ b/git-request-pull.sh
@@ -35,7 +35,18 @@ do
shift
done
-base=$1 url=$2 head=${3-HEAD} status=0
+base=$1 url=$2 head=${3-HEAD} status=0 branch_name=
+
+headref=$(git symbolic-ref -q "$head")
+if git show-ref -q --verify "$headref"
+then
+ branch_name=${headref#refs/heads/}
+ if test "z$branch_name" = "z$headref" ||
+ ! git config "branch.$branch_name.description" >/dev/null
+ then
+ branch_name=
+ fi
+fi
test -n "$base" && test -n "$url" || usage
baserev=$(git rev-parse --verify "$base"^0) &&
@@ -66,6 +77,13 @@ for you to fetch changes up to %H:
----------------------------------------------------------------' $headrev &&
+if test -n "$branch_name"
+then
+ echo "(from the branch description for $branch local branch)"
+ echo
+ git config "branch.$branch_name.description"
+ echo "----------------------------------------------------------------"
+fi &&
git shortlog ^$baserev $headrev &&
git diff -M --stat --summary $patch $merge_base..$headrev || status=1
--
1.7.7.rc2.4.g5ec82
^ permalink raw reply related
* [PATCH 2/3] branch: teach --edit-description option
From: Junio C Hamano @ 2011-09-20 23:02 UTC (permalink / raw)
To: git; +Cc: Linus Torvalds
In-Reply-To: <7vy5xi4y3m.fsf@alter.siamese.dyndns.org>
Using branch.$name.description as the configuration key, give users a
place to write about what the purpose of the branch is and things like
that, so that various subsystems, e.g. "push -s", "request-pull", and
"format-patch --cover-letter", can later be taught to use this
information.
The "-m" option similar to "commit/tag" is deliberately omitted, as the
whole point of branch description is about giving descriptive information
(the name of the branch itself is a better place for information that fits
on a single-line).
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
Documentation/git-branch.txt | 5 +++
builtin/branch.c | 68 ++++++++++++++++++++++++++++++++++++++++-
2 files changed, 71 insertions(+), 2 deletions(-)
diff --git a/Documentation/git-branch.txt b/Documentation/git-branch.txt
index 79424a5..12bdffc 100644
--- a/Documentation/git-branch.txt
+++ b/Documentation/git-branch.txt
@@ -14,6 +14,7 @@ SYNOPSIS
'git branch' [--set-upstream | --track | --no-track] [-l] [-f] <branchname> [<start-point>]
'git branch' (-m | -M) [<oldbranch>] <newbranch>
'git branch' (-d | -D) [-r] <branchname>...
+'git branch' --edit-description [<branchname>]
DESCRIPTION
-----------
@@ -144,6 +145,10 @@ start-point is either a local or remote-tracking branch.
like '--track' would when creating the branch, except that where
branch points to is not changed.
+--edit-description::
+ Open an editor and edit the text to explain what the branch is
+ for, to be used by various other commands (e.g. `request-pull`).
+
--contains <commit>::
Only list branches which contain the specified commit.
diff --git a/builtin/branch.c b/builtin/branch.c
index f49596f..94319c4 100644
--- a/builtin/branch.c
+++ b/builtin/branch.c
@@ -606,11 +606,61 @@ static int opt_parse_merge_filter(const struct option *opt, const char *arg, int
return 0;
}
+struct branch_desc_cb {
+ const char *config_name;
+ const char *value;
+};
+
+static int read_branch_desc(const char *var, const char *value, void *cb)
+{
+ struct branch_desc_cb *desc = cb;
+ if (strcmp(desc->config_name, var))
+ return 0;
+ free((char *)desc->value);
+ return git_config_string(&desc->value, var, value);
+}
+
+static const char edit_description[] = "BRANCH_DESCRIPTION";
+
+static int edit_branch_description(const char *branch_name)
+{
+ struct branch_desc_cb cb;
+ struct strbuf name = STRBUF_INIT;
+ struct strbuf buf = STRBUF_INIT;
+ FILE *fp;
+
+ strbuf_addf(&name, "branch.%s.description", branch_name);
+ cb.config_name = name.buf;
+ cb.value = NULL;
+ git_config(read_branch_desc, &cb);
+
+ if (cb.value)
+ strbuf_addstr(&buf, cb.value);
+ if (!buf.len || buf.buf[buf.len-1] != '\n')
+ strbuf_addch(&buf, '\n');
+ strbuf_addf(&buf,
+ "# Please edit the description for the branch\n"
+ "# %s\n"
+ "# Lines starting with '#' will be stripped.\n",
+ branch_name);
+ fp = fopen(git_path(edit_description), "w");
+ if (fwrite(buf.buf, 1, buf.len, fp) < buf.len) {
+ strbuf_release(&buf);
+ return error(_("could not write branch description template: %s\n"),
+ strerror(errno));
+ }
+ strbuf_reset(&buf);
+ if (launch_editor(git_path(edit_description), &buf, NULL))
+ return -1;
+ stripspace(&buf, 1);
+ return git_config_set(name.buf, buf.buf);
+}
+
int cmd_branch(int argc, const char **argv, const char *prefix)
{
int delete = 0, rename = 0, force_create = 0;
int verbose = 0, abbrev = -1, detached = 0;
- int reflog = 0;
+ int reflog = 0, edit_description = 0;
enum branch_track track;
int kinds = REF_LOCAL_BRANCH;
struct commit_list *with_commit = NULL;
@@ -648,6 +698,8 @@ int cmd_branch(int argc, const char **argv, const char *prefix)
OPT_BIT('m', NULL, &rename, "move/rename a branch and its reflog", 1),
OPT_BIT('M', NULL, &rename, "move/rename a branch, even if target exists", 2),
OPT_BOOLEAN('l', NULL, &reflog, "create the branch's reflog"),
+ OPT_BOOLEAN(0, "edit-description", &edit_description,
+ "edit the description for the branch"),
OPT__FORCE(&force_create, "force creation (when already exists)"),
{
OPTION_CALLBACK, 0, "no-merged", &merge_filter_ref,
@@ -694,7 +746,19 @@ int cmd_branch(int argc, const char **argv, const char *prefix)
if (delete)
return delete_branches(argc, argv, delete > 1, kinds);
- else if (argc == 0)
+ else if (edit_description) {
+ const char *branch_name;
+ if (detached)
+ die("Cannot give description to detached HEAD");
+ if (!argc)
+ branch_name = head;
+ else if (argc == 1)
+ branch_name = argv[0];
+ else
+ usage_with_options(builtin_branch_usage, options);
+ if (edit_branch_description(branch_name))
+ return 1;
+ } else if (argc == 0)
return print_ref_list(kinds, detached, verbose, abbrev, with_commit);
else if (rename && (argc == 1))
rename_branch(head, argv[0], rename > 1);
--
1.7.7.rc2.4.g5ec82
^ permalink raw reply related
* Re: [PATCH v3] request-pull: state what commit to expect
From: Junio C Hamano @ 2011-09-20 23:01 UTC (permalink / raw)
To: git; +Cc: Linus Torvalds
In-Reply-To: <7viposfgvd.fsf_-_@alter.siamese.dyndns.org>
Here are three patches on top of the latest round of request-pull update.
The first two are to add a new option to "git branch" command so that a
descriptive text that explains what the purpose of the branch is, for use
by other commands. And the last one builds on top of the patch this
message is a response to, to use that information.
And here is the first one, just an unrelated doc clean-up.
-- >8 --
Subject: [PATCH 1/3] branch doc: minor formatting fix
We tend to use typewriter font when writing command flags that are
meant to be typed literally by the user.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
Documentation/git-branch.txt | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/Documentation/git-branch.txt b/Documentation/git-branch.txt
index 507b8d0..79424a5 100644
--- a/Documentation/git-branch.txt
+++ b/Documentation/git-branch.txt
@@ -54,7 +54,7 @@ With a `-d` or `-D` option, `<branchname>` will be deleted. You may
specify more than one branch for deletion. If the branch currently
has a reflog then the reflog will also be deleted.
-Use -r together with -d to delete remote-tracking branches. Note, that it
+Use `-r` together with `-d` to delete remote-tracking branches. Note, that it
only makes sense to delete remote-tracking branches if they no longer exist
in the remote repository or if 'git fetch' was configured not to fetch
them again. See also the 'prune' subcommand of linkgit:git-remote[1] for a
--
1.7.7.rc2.4.g5ec82
^ permalink raw reply related
* Re: mac osx
From: Graham Christensen @ 2011-09-20 22:53 UTC (permalink / raw)
To: tom smitts; +Cc: git
In-Reply-To: <loom.20110921T002437-246@post.gmane.org>
Many people who are using Apple computers choose to use Macports or Homebrew to install their packages, which makes this a moot point. Additionally, XCode 4 provides Git as well.
One thing to consider is that people who truly don't understand what kind of machine they are on, and are incapable of figuring out how to do so, are going to have an extremely difficult time using it.
That isn't to say it shouldn't be addressed, Bazaar, and Mercurial both seem to provide an easy installation medium.
--
Graham Christensen
^ permalink raw reply
* mac osx
From: tom smitts @ 2011-09-20 22:40 UTC (permalink / raw)
To: git
Do the git maintainers really think any mac users have
a clue which git install package to download? You
put some arcane chipset designation in the package
name! Why make mac installers at all? Mac users
know their operating system number, e.g. 10.6.7,
and that's all. I doubt Windows users know any better.
And I doubt you can find anywhere on a mac that says
i386 or whatever the heck the other dumb
designation is.
^ permalink raw reply
* Re: Git wiki down?
From: Sverre Rabbelier @ 2011-09-20 22:39 UTC (permalink / raw)
To: pedroreys, John 'Warthog9' Hawley,
John 'Warthog9' Hawley
Cc: git
In-Reply-To: <1316558166719-6814099.post@n2.nabble.com>
Heya,
On Wed, Sep 21, 2011 at 00:36, pedroreys <pedroreys@gmail.com> wrote:
> Does kernel.org have an ETA for finishing the maintenance?
Probably "when it's done", but if anyone Warthog9 (cc-ed on some
alternate address I found since I suspect the kernel.org mail server
might be down too) would know.
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* Re: Git wiki down?
From: pedroreys @ 2011-09-20 22:36 UTC (permalink / raw)
To: git
In-Reply-To: <20110911141433.4dd8d81e@kuru.homelinux.net>
Hi Carlos,
Does kernel.org have an ETA for finishing the maintenance?
Thanks in advance,
pr
--
View this message in context: http://git.661346.n2.nabble.com/Git-wiki-down-tp6780600p6814099.html
Sent from the git mailing list archive at Nabble.com.
^ permalink raw reply
* Re: [Bug report] git fetch/push fails from sub-directory
From: Frederic Heitzmann @ 2011-09-20 22:25 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v62km6fjl.fsf@alter.siamese.dyndns.org>
Le 20/09/2011 23:59, Junio C Hamano a écrit :
> Frederic Heitzmann<frederic.heitzmann@gmail.com> writes:
>
>> I found a bug in git fetch, with local repositories.
>
>> cd repo2
>> git fetch ../repo1 # OK
>> cd d
>> git fetch ../../repo1 # failed
>
> It has always been like this. You can give a full path to the repository
> from the root, or perhaps define a nickname to refer to the remote (see
> "git remote add") and use it instead.
Is it supposed to be normal ?!
I mean : OK I can use git-remote, but this leads to differents results
for similar usages and similar commands.
Let's compare following cases :
_Case 1:_
|
|_repo1
| |
| \_dir
|
\_repo2
|
\_dir
cd repo2/dir
git fetch ../../repo1 # FAILURE
_Case 2:_
|
|_repo1
|
\_temp
|
\_repo2
cd temp/repo2
git fetch ../../repo1 # SUCCESS
For sure, one can argue that I should better organize my file tree ;-)
--
Fred
^ permalink raw reply
* Re: [Bug report] git fetch/push fails from sub-directory
From: Junio C Hamano @ 2011-09-20 21:59 UTC (permalink / raw)
To: Frederic Heitzmann; +Cc: git
In-Reply-To: <j5b1qa$pki$1@dough.gmane.org>
Frederic Heitzmann <frederic.heitzmann@gmail.com> writes:
> I found a bug in git fetch, with local repositories.
> cd repo2
> git fetch ../repo1 # OK
> cd d
> git fetch ../../repo1 # failed
It has always been like this. You can give a full path to the repository
from the root, or perhaps define a nickname to refer to the remote (see
"git remote add") and use it instead.
^ permalink raw reply
* [Bug report] git fetch/push fails from sub-directory
From: Frederic Heitzmann @ 2011-09-20 21:50 UTC (permalink / raw)
To: git
Hi,
I found a bug in git fetch, with local repositories.
git fetch works fine from the root directory, but it fails when called
from deeper into the file tree of the repository.
git push fails the same way.
The bug is on 1.7.7.rc2 and on master.
mkdir repo1
cd repo1
git init .
mkdir d
touch d/f
git add d/f
git commit -m'initial commit'
cd ..
git clone repo1 repo2
cd repo2
git fetch ../repo1 # OK
cd d
git fetch ../../repo1 # failed
fatal: '../../repo1' does not appear to be a git repository
fatal: The remote end hung up unexpectedly
--
Fred
^ 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