* [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
* Re: [PATCH v3 1/2] pretty: Add failing tests: user format ignores i18n.logOutputEncoding setting
From: Alexey Shumkin @ 2011-09-20 20:46 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vaa9z6n9p.fsf@alter.siamese.dyndns.org>
> Alexey Shumkin <zapped@mail.ru> writes:
>
> > diff --git a/t/t4041-diff-submodule-option.sh
> > b/t/t4041-diff-submodule-option.sh ...
> > @@ -48,28 +53,25 @@ head2=$(add_file sm1 foo3)
> >
> > test_expect_success 'modified submodule(forward)' "
>
> As this is [PATCH 1/2], doesn't this patch make this test fail,
> calling for test_expect_failure here (and then later in 2/2 to be
> flipped back to test_expect_success)?
I did not know how is right.
AFAIK, XP way tells to write failing tests and then
patch/fix the code to pass them.
Here, As I understand now all tests must be successful
The difference is in expectation of failure or success.
Ok. I got it and I will reroll the patches.
>
> > git diff-index -p --submodule=log HEAD >actual &&
> > - cat >expected <<-EOF &&
> > -Submodule sm1 $head1..$head2:
> > - > Add foo3
> > -EOF
> > + printf \"Submodule sm1 $head1..$head2:\n\
> > + > Add foo3 ($added foo3)\n\
> > +\" > expected &&
> > test_cmp expected actual
> > "
>
> Hmmm... why printf? Is it worth to force reviewers wonder what would
> happen if any of these $variables happened to have "%" in them? Are
> you benefiting from any printf features that you cannot achieve with
> the original cat?
This is a remained from v1 patch code. It is not required now.
I'll fix it. Thanks.
> This hunk and others throughout your patch that change cat with here
> doc into printf seem to make the tests less legible, at least to me.
>
> Perhaps like this instead, if the "flushed left" of the original
> looked ugly to your eyes?
No, the reason was not in "flushed left". And, BTW, this code generates
expected output that has predefined format...
>
> @@ -49,27 +54,25 @@ head2=$(add_file sm1 foo3)
> test_expect_success 'modified submodule(forward)' "
> git diff-index -p --submodule=log HEAD >actual &&
> cat >expected <<-EOF &&
> -Submodule sm1 $head1..$head2:
> - > Add foo3
> -EOF
> + Submodule sm1 $head1..$head2:
> + > Add foo3 ($added foo3)
> + EOF
> test_cmp expected actual
> "
>
--
С уважением, Алексей Шумкин
Программист компании 1С-Рарус
E-mail: ashu@rarus.ru
ICQ: 118001447
Jabber (GoogleTalk): ashu@rarus.ru
Skype: crezoff
^ permalink raw reply
* Re: git-rebase skips automatically no more needed commits
From: Martin von Zweigbergk @ 2011-09-20 20:45 UTC (permalink / raw)
To: Junio C Hamano
Cc: Martin von Zweigbergk, Francis Moreau, Michael J Gruber, git,
Ramkumar Ramachandra
In-Reply-To: <alpine.DEB.2.00.1109151956040.12564@debian>
On Thu, 15 Sep 2011, Martin von Zweigbergk wrote:
[CC'ing Ramkunar regarding the footnote]
> [...] With your
> patch, we would also get the patch body from the commit. The only
> thing remaining after that is the commit log message, correct?
It turns out the commit log message have been taken from the commit
for ages. Sorry about not checking the code first.
I have started implementing the changes to git-am.sh now. I have made
it not use mailinfo when in $rebasing mode, as you suggested. So now
git-am works even if only a list of
From $sha1 Mon Sep 17 00:00:00 2001
lines are fed to it. Since only the $sha1 is needed, we should
probably make --rebasing imply a patch-format is just a simple list of
revisions. Since the --rebasing flag is only for internal use, this
should be safe when it comes to backwards compatibility. [1]
Now the question is how to generate such lines, without the overhead
of a full format-patch call. We still want the --ignore-if-in-upstream
functionality, so we can not use plain rev-list. We also want it to
work with --root, so we can not use git-cherry. Finally, we can not
use 'git rev-list --cherry-pick --right-only' since it seems to be
inherently for symmetric ranges and therefore does not support
git-cherry's <limit> parameter.
If I'm not mistaken, we would have to teach some new option to some
command, but which one?
It doesn't feel right to teach format-patch a --commit-name-only,
simply because it would then no longer be a patch.
It's probably easiest to teach git-cherry a --root flag. Does that
sound like the right solution to people? I think it makes sense for
such an option to exist.
More involved would be to teach rev-list --cherry-pick also for
asymmetric ranges. I would imagine that "--cherry-pick $branch --not
$newbase $oldbase" could be defined as "all commits in $branch that
are not patch-equivalent to any commits in $newbase or $oldbase". Just
s/patch-equivalent/identical/ and you have the regular definition of
the rev-list, right? There is of course no need to actually calculate
the patch-id for any commits are not in "$branch --not $newbase
$oldbase" (identical => patch-equivalent).
I would go for teaching git-cherry --root, unless the "rev-list
--cherry-pick for asymmetric ranges" option would be useful
elsewhere. Either way, teaching git-cherry --root would not be a bad
thing, I think.
Martin
[1] Long term, would it make sense to teach 'git cherry-pick' a '-2'
option instead of using the '-3' option to 'git am'? (Where 'git
cherry-pick -2' would try "apply && write-tree && commit-tree"
before falling back to merging.)
^ permalink raw reply
* Re: [PATCH/RFCv4 1/4] Documentation: Preparation for gitweb manpages
From: Jakub Narebski @ 2011-09-20 20:33 UTC (permalink / raw)
To: Jonathan Nieder; +Cc: git, Drew Northup
In-Reply-To: <20110920201953.GA11464@elie>
Jonathan Nieder wrote:
> Jakub Narebski wrote:
>
> > I hope that this version is more clear:
>
> Yep, it doesn't leave me confused any more. Thanks, this looks good
> (and sorry for my carelessness in reading the patch before).
No, your concern was valid.
It's better to be more explicit.
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: Worktree vs. working copy
From: Carlos Martín Nieto @ 2011-09-20 20:25 UTC (permalink / raw)
To: Junio C Hamano
Cc: Ramkumar Ramachandra, git, Nguyễn Thái Ngọc Duy,
Michael Haggerty
In-Reply-To: <7vhb476ned.fsf@alter.siamese.dyndns.org>
[-- Attachment #1: Type: text/plain, Size: 5104 bytes --]
On Tue, 2011-09-20 at 12:10 -0700, Junio C Hamano wrote:
> Ramkumar Ramachandra <artagnon@gmail.com> writes:
>
> > Hi Carlos,
> >
> > Carlos Martín Nieto writes:
> >> [...]
> >> $ git grep 'worktree' | wc -l
> >> 412
> >> $ git grep 'working copy' | grep -v ^git-cvsserver | wc -l
> >> 32
> >> [...]
> >
> > You might like to refer to a related discussion [1].
> >
> > [1]: http://thread.gmane.org/gmane.comp.version-control.git/159287/focus=160083
>
> Sorry, I do not see "working tree" discussion there. The discussion on
> that quoted thread was about remote-tracking branches, no?
>
> Historically, we used to say "working tree" and "worktree" more or less
> interchangeably, and over time we tried to update the documentation to use
> "working tree" consistently, even though the latter is still seen in
> places like "GIT_WORK_TREE" environment variable (which will _not_
> change).
>
> But as far as I recall, we have never referred to the working tree
> controlled by a git repository as "working copy".
The config man page has three mentions, diff-lib.c has one,
merge-recursive.c three and perl/Git.pm nine.
This patch covers the documentation and C code. I'll move the perl code
over if you want, but I'm not sure how well maintained or relevant that
part of the codebase is.
--- 8< ---
Subject: [PATCH] Remove 'working copy' from the documentation and C code
The git term is 'working tree', so replace the most public references
to 'working copy'.
Signed-off-by: Carlos Martín Nieto <cmn@elego.de>
---
Documentation/config.txt | 6 +++---
Documentation/git-svn.txt | 2 +-
diff-lib.c | 2 +-
merge-recursive.c | 2 +-
4 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/Documentation/config.txt b/Documentation/config.txt
index 6b93777..c3f22f3 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -147,7 +147,7 @@ advice.*::
core.fileMode::
If false, the executable bit differences between the index and
- the working copy are ignored; useful on broken filesystems like FAT.
+ the working tree are ignored; useful on broken filesystems like FAT.
See linkgit:git-update-index[1].
+
The default is true, except linkgit:git-clone[1] or linkgit:git-init[1]
@@ -179,7 +179,7 @@ is created.
core.trustctime::
If false, the ctime differences between the index and the
- working copy are ignored; useful when the inode change time
+ working tree are ignored; useful when the inode change time
is regularly modified by something outside Git (file system
crawlers and some backup systems).
See linkgit:git-update-index[1]. True by default.
@@ -292,7 +292,7 @@ core.ignoreStat::
If true, commands which modify both the working tree and the index
will mark the updated paths with the "assume unchanged" bit in the
index. These marked files are then assumed to stay unchanged in the
- working copy, until you mark them otherwise manually - Git will not
+ working tree, until you mark them otherwise manually - Git will not
detect the file changes by lstat() calls. This is useful on systems
where those are very slow, such as Microsoft Windows.
See linkgit:git-update-index[1].
diff --git a/Documentation/git-svn.txt b/Documentation/git-svn.txt
index 713e523..4ba6f61 100644
--- a/Documentation/git-svn.txt
+++ b/Documentation/git-svn.txt
@@ -297,7 +297,7 @@ Any other arguments are passed directly to 'git log'
Show what revision and author last modified each line of a file. The
output of this mode is format-compatible with the output of
`svn blame' by default. Like the SVN blame command,
- local uncommitted changes in the working copy are ignored;
+ local uncommitted changes in the working tree are ignored;
the version of the file in the HEAD revision is annotated. Unknown
arguments are passed directly to 'git blame'.
+
diff --git a/diff-lib.c b/diff-lib.c
index 9c29293..c7d33d7 100644
--- a/diff-lib.c
+++ b/diff-lib.c
@@ -289,7 +289,7 @@ static void show_new_file(struct rev_info *revs,
/*
* New file in the index: it might actually be different in
- * the working copy.
+ * the working tree.
*/
if (get_stat_data(new, &sha1, &mode, cached, match_missing,
&dirty_submodule, &revs->diffopt) < 0)
diff --git a/merge-recursive.c b/merge-recursive.c
index db9ba19..0c9f77e 100644
--- a/merge-recursive.c
+++ b/merge-recursive.c
@@ -337,7 +337,7 @@ static void make_room_for_directories_of_df_conflicts(struct merge_options *o,
struct string_list *entries)
{
/* If there are D/F conflicts, and the paths currently exist
- * in the working copy as a file, we want to remove them to
+ * in the working tree as a file, we want to remove them to
* make room for the corresponding directory. Such paths will
* later be processed in process_df_entry() at the end. If
* the corresponding directory ends up being removed by the
--
1.7.5.2.354.g349bf
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 490 bytes --]
^ permalink raw reply related
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