* Re: Please pull l10n updates for 1.8.2 round 4
From: Junio C Hamano @ 2013-03-07 21:13 UTC (permalink / raw)
To: Jiang Xin; +Cc: Ralf Thielow, Tran Ngoc Quan, Peter Krefting, Git List
In-Reply-To: <CANYiYbEUSc3s1KZ6tyd9Ot68_o2-hxPE=sD8oA0Dgz-_4G8AWA@mail.gmail.com>
Thanks!
^ permalink raw reply
* Re: [PATCH 2/2] bundle: Add colons to list headings in "verify"
From: Junio C Hamano @ 2013-03-07 21:38 UTC (permalink / raw)
To: Lukas Fleischer; +Cc: git, Johannes Schindelin
In-Reply-To: <1362617796-4120-2-git-send-email-git@cryptocrack.de>
Lukas Fleischer <git@cryptocrack.de> writes:
> These slightly improve the reading flow by making it obvious that a list
> follows.
>
> Signed-off-by: Lukas Fleischer <git@cryptocrack.de>
Perhaps.
The earlier message says "contains X ref(s)" while the later one
says "requires this/these X ref(s)". Do we want to make them
consistent, too?
> ---
> bundle.c | 8 ++++----
> 1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/bundle.c b/bundle.c
> index 65db53b..8cd8b4f 100644
> --- a/bundle.c
> +++ b/bundle.c
> @@ -183,8 +183,8 @@ int verify_bundle(struct bundle_header *header, int verbose)
> struct ref_list *r;
>
> r = &header->references;
> - printf_ln(Q_("The bundle contains %d ref",
> - "The bundle contains %d refs",
> + printf_ln(Q_("The bundle contains %d ref:",
> + "The bundle contains %d refs:",
> r->nr),
> r->nr);
> list_refs(r, 0, NULL);
> @@ -192,8 +192,8 @@ int verify_bundle(struct bundle_header *header, int verbose)
> if (!r->nr) {
> printf_ln(_("The bundle records a complete history."));
> } else {
> - printf_ln(Q_("The bundle requires this ref",
> - "The bundle requires these %d refs",
> + printf_ln(Q_("The bundle requires this ref:",
> + "The bundle requires these %d refs:",
> r->nr),
> r->nr);
> list_refs(r, 0, NULL);
^ permalink raw reply
* Re: [PATCH] setup.c: Fix prefix_pathspec from looping pass end of string
From: Junio C Hamano @ 2013-03-07 21:48 UTC (permalink / raw)
To: Andrew Wong; +Cc: git
In-Reply-To: <1362674163-24682-1-git-send-email-andrew.kw.w@gmail.com>
Andrew Wong <andrew.kw.w@gmail.com> writes:
> The previous code was assuming length ends at either `)` or `,`, and was
> not handling the case where strcspn returns length due to end of string.
> So specifying ":(top" as pathspec will cause the loop to go pass the end
> of string.
Thanks.
The parser that goes past the end of the string may be a bug worth
fixing, but is this patch sufficient to diagnose such an input as an
error?
> Signed-off-by: Andrew Wong <andrew.kw.w@gmail.com>
> ---
> setup.c | 6 ++++--
> 1 file changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/setup.c b/setup.c
> index 1dee47e..f4c4e73 100644
> --- a/setup.c
> +++ b/setup.c
> @@ -207,9 +207,11 @@ static const char *prefix_pathspec(const char *prefix, int prefixlen, const char
> *copyfrom && *copyfrom != ')';
> copyfrom = nextat) {
> size_t len = strcspn(copyfrom, ",)");
> - if (copyfrom[len] == ')')
> + if (copyfrom[len] == '\0')
> nextat = copyfrom + len;
> - else
> + else if (copyfrom[len] == ')')
> + nextat = copyfrom + len;
> + else if (copyfrom[len] == ',')
> nextat = copyfrom + len + 1;
> if (!len)
> continue;
^ permalink raw reply
* Re: [gitweb] Removed reference to git.kernel.org
From: Junio C Hamano @ 2013-03-07 21:59 UTC (permalink / raw)
To: Fredrik Gustafsson; +Cc: git
In-Reply-To: <1362619423-17105-1-git-send-email-iveqy@iveqy.com>
Thanks.
^ permalink raw reply
* [feature request] 2) Remove many tags at once and 1) Prune tags on old-branch-before-rebase
From: Eric Chamberland @ 2013-03-07 22:01 UTC (permalink / raw)
To: git@vger.kernel.org
Hi,
============================
Short story:
============================
we are now using *annotated* tags in a way that we would need to manage
(remove) them easily. It would be usefull to have one of the folowing in
"git tag":
1) git tag --delete-tags-to-danglings-and-unnamed-banches
This would be able to remove all tags that refers to commits which are
on branches that are no more referenced by any branch name. This is
happening when you tag something, then "git rebase". Your tag will
still be there on the old-and-before-rebase branch and won't be "pruned"
by any git command... (that I know of...)
Then you will end up to delete all of them "by hand"...
to do so you would like to have:
2) git tag -d "TOKEN*"
This would be able to delete all tags referred by the name.
Ok ok, I can do this like this:
rm .git/refs/tags/TOKEN*
but why have the git users "play" into the .git...?
============================
----------------------------------------
Long story:
----------------------------------------
We started using annotated tags to hold information about the code
"status", ie the results of our regression tests are stored in annotated
tags each time you do a "make test" in the distribution. We can
retrieve the information by "git show" which we aliased to parse the
output, extract the ".html" that we stored in the tag message (about
67kb) and then display the "make test" results as a web page in a
browser... ;-)
We also "resume" the information on the number of "(P)assed" and
"(F)ailed" tests in the tag name to quickly view the overall status of
the code in the local clone. For example, we end up with tags name like
these:
SQA_ericc_ad76kj78_P_155_F_0
as a result of: SQA_${USER}_${SHA}_P_${PASSED}_F_${FAILED}
However, the number of tags increases as you do many "make test" to
validate your developments and see the progressions you do.
Moreover, when you "git fetch" from colleagues, you retrieve their
annotated tags too, which is nice, since you can view the results of the
regression tests they have done, which can contain useful information to
share...
BUT, when your colleagues delete their old tags because they rebased,
you don't have the possibility to "git fetch --prune-tags", so you are
left with all those "old" tags hanging all around and would like to
easily remove them...
Because you know that no more branches are associated with the tip
commit of all those "old-before-rebased-branches", you would like
something like feature request #1 to automagically do the job you do by
hand in feature request #2... ;-)
Ok, we shall not rebase but merge, but this is another long story... ;-)
Hope all this might be useful to other, so if other people start using
tags like this, more will hope to have these features... ;-)
----------------------------------------
thanks,
Eric
^ permalink raw reply
* Re: What I want rebase to do
From: Dale R. Worley @ 2013-03-07 22:06 UTC (permalink / raw)
To: Thomas Rast; +Cc: gitster, git
In-Reply-To: <87r4jra942.fsf@pctrast.inf.ethz.ch>
> From: Thomas Rast <trast@student.ethz.ch>
>
> worley@alum.mit.edu (Dale R. Worley) writes:
> [...snip...]
>
> Isn't that just a very long-winded way of restating what Junio said
> earlier:
>
> > > It was suggested to make it apply the first-parent diff and record
> > > the result, I think. If that were an acceptable approach (I didn't
> > > think about it through myself, though), that would automatically
> > > cover the evil-merge case as well.
Well, I believe what I said was a fleshed-out way of saying what I
*think* Junio said, but...
> You can fake that with something like
>
> git rev-list --first-parent --reverse RANGE_TO_REBASE |
> while read rev; do
> if git rev-parse $rev^2 >/dev/null 2>&1; then
> git cherry-pick -n -m1 $rev
> git rev-parse $rev^2 >.git/MERGE_HEAD
> git commit -C$rev
> else
> git cherry-pick $rev
> fi
> done
This code doesn't do that. I don't want something that rebases a
single thread of the current branch, I want something that rebases
*all* the commits between the head commit and the merge base. Which
is what is illustrated in my message.
> [1] If you don't get the sarcasm: that would amount to reinventing
> large parts of git-rebase.
Yes, that is the point of the exercise.
I've done a proof-of-concept implementation of what I want to see,
calling it git-rebase--merge-safe. But I'm new here and likely that
is a pretty crude solution. I suspect that a real implementation
could be done by inserting this logic into the framework of
git-filter-tree. Following is git-rebase--merge-safe, and the script
I use to test it (and explore rebase problems).
Dale
----------------------------------------------------------------------
git-rebase--merge-safe
#!/bin/bash
. git-sh-setup
prec=4
set -ex
# Ensure the work tree is clean.
require_clean_work_tree "rebase" "Please commit or stash them."
onto_name=$1
onto=$(git rev-parse --verify "${onto_name}^0") ||
die "Does not point to a valid commit: $1"
head_name=$( git symbolic-ref HEAD )
orig_head=$(git rev-parse --verify $head_name) ||
exit 1
echo onto=$onto
echo head_name=$head_name
echo orig_head=$orig_head
# Get the merge base, which is the root of the branch that we are rebasing.
# (For now, ignore the question of whether there is more than one merge base.)
mb=$(git merge-base "$onto" "$orig_head")
echo mb=$mb
# Get the list of commits to rebase, which is everything between $mb and
# $orig_head.
# Note that $mb is not included.
revisions=`git rev-list --reverse --ancestry-path $mb..$orig_head`
echo revisions=$revisions
# Set up the list mapping the commits on the original branch to the commits
# on the branch we are creating.
# Its format is ",old-hash1/new-hash1,old-hash2/new-hash2,...,".
# The initial value maps $mb to $onto.
map=",$mb/$onto,"
# Export these so git commit can see them.
export GIT_AUTHOR_NAME GIT_AUTHOR_EMAIL GIT_AUTHOR_DATE
# Process each commit in forward topological order.
for cmt in $revisions
do
# Examine the commit to extract information we will need to reconstruct it.
# First parent of the commit that has a mapping, i.e., is part of the
# branch (and has thus been rebuilt already.
first_mapped_parent=
# The new commit that was made of $first_mapped_parent.
first_mapped_parent_mapped=
# List of -p options naming the parent commits, or their new commits if they
# are in the branch.
parents=
# Dissect the old commit's data.
# Output the commit data into FD 3.
exec 3< <( git cat-file commit $cmt )
while read keyword rest <&3
do
case $keyword in
tree)
# Ignored
;;
parent)
# See if the parent is mapped, i.e., is in the
# original branch.
if [[ "$map" == *,$rest/* ]]
then
# This parent has been mapped. Get the new commit.
parent_mapped=${map#*,$rest/}
parent_mapped=${parent_mapped%%,*}
if test -z "$first_mapped_parent"
then
first_mapped_parent=$rest
first_mapped_parent_mapped=$parent_mapped
fi
else
# This parent has not been mapped.
parent_mapped=$rest
fi
# $parent_mapped is a parent of the new commit.
parents="$parents -p $parent_mapped"
;;
author)
# Extract the information about the author.
GIT_AUTHOR_NAME="${rest%% <*}"
GIT_AUTHOR_EMAIL="${rest##* <}"
GIT_AUTHOR_EMAIL="${GIT_AUTHOR_EMAIL%%> *}"
GIT_AUTHOR_DATE="${rest##*> }"
;;
committer)
# Ignored: The new commit will have this use's name
# as committer.
;;
'')
# End of fixed fields, remainder is the commit comment.
# Leave contents of FD 3 queued to be read later by
# git commit-tree.
break
;;
*)
# Ignore all other keywords.
;;
esac
done
echo GIT_AUTHOR_NAME="$GIT_AUTHOR_NAME"
echo GIT_AUTHOR_EMAIL="$GIT_AUTHOR_EMAIL"
echo GIT_AUTHOR_DATE="$GIT_AUTHOR_DATE"
echo parents="$parents"
echo first_mapped_parent=$first_mapped_parent
echo first_mapped_parent_mapped=$first_mapped_parent_mapped
test -n "$first_mapped_parent" || exit 1
# Do the three-way merge.
# Empty the tree so git read-tree will merge into it.
git read-tree --empty
git read-tree -m --aggressive \
$first_mapped_parent $cmt $first_mapped_parent_mapped
git merge-index git-merge-one-file -a
# Construct the file tree for the new commit.
tree=$( git write-tree )
# Create the new commit
# Note that FD 3 contains the remainder of the commit description
# from the git cat-file above.
new_commit=$( git commit-tree $tree $parents <&3 )
echo new_commit=$new_commit
# Add the new commit to the map.
map="$map$cmt/$new_commit,"
done
echo Final commit is $new_commit
# Update the branch pointers.
git update-ref ORIG_HEAD $orig_head
git update-ref $head_name $new_commit
# Go to the new head of the branch.
git checkout ${head_name#refs/heads/}
----------------------------------------------------------------------
script.fixed
set -e
# Create a temporary directory and go into it.
DIR=temp.$$
mkdir $DIR
cd $DIR
# Create a Git repository.
git init
# Create a file containing the lines 1 to 10.
seq 1 10 >file
git add file
git commit -m 'Commit A'
# Start the dev branch at commit A.
git branch dev HEAD
# Add lines 1.5, 2.5, and 3.5 in a series of commits on master.
# This sed command adds a line 1.5 before the line 2.
sed --in-place -e '/^2$/i1.5' file
git commit -a -m 'Commit B'
sed --in-place -e '/^3$/i2.5' file
git commit -a -m 'Commit C'
sed --in-place -e '/^4$/i3.5' file
git commit -a -m 'Commit D'
# Show the commit structure of master.
#git log --graph --oneline master
#git log --graph -p master
echo 'On master:'
cat file
# Go to the dev branch and create commits with a non-trivial merge.
git checkout dev
sed --in-place -e '/^5$/i4.5' file
git commit -a -m 'Commit P'
git branch dev1 HEAD
sed --in-place -e '/^6$/i5.5' file
git commit -a -m 'Commit Q'
git checkout dev1
sed --in-place -e '/^7$/i6.5' file
git commit -a -m 'Commit R'
git checkout dev
# Merge commits Q and R, but add the additional line 7.5 (to simulate
# fixes that were needed to resolve the merge).
git merge --no-commit dev1
sed --in-place -e '/^8$/i7.5' file
git commit -a -m 'Commit S'
sed --in-place -e '/^9$/i8.5' file
git commit -a -m 'Commit T'
# Show the commit structure of dev.
#git log --graph --oneline dev
# *** Note that the diffs do not show the line 7.5 added in commit S.
#git log --graph -p dev
echo 'On dev:'
cat file
# Show the branch structure.
git show-branch --sha1-name
git log --all --oneline --graph
# Rebase the dev branch to the tip of master using our hack script.
git checkout dev
git branch -f rebase dev
git checkout rebase
PATH=/usr/libexec/git-core:$PATH
../git-rebase--merge-safe master
# Show the commit structure.
git log --graph --oneline
# *** Note that the line 7.5 added in commit S isn't carried into the new branch.
git log --graph -p
echo 'After rebasing:'
cat file
----------------------------------------------------------------------
[EOF]
^ permalink raw reply
* Re: inotify to minimize stat() calls
From: Torsten Bögershausen @ 2013-03-07 22:16 UTC (permalink / raw)
To: Duy Nguyen
Cc: Junio C Hamano, Ramkumar Ramachandra, Robert Zeh, Git List,
finnag, Torsten Bögershausen
In-Reply-To: <CACsJy8DnvAjQPL4aP_LRC7aqx6OC4M5dMtj-OUot76qET2z08Q@mail.gmail.com>
On 11.02.13 03:56, Duy Nguyen wrote:
> On Mon, Feb 11, 2013 at 3:16 AM, Junio C Hamano <gitster@pobox.com> wrote:
>> The other "lstat()" experiment was a very interesting one, but this
>> is not yet an interesting experiment to see where in the "ignore"
>> codepath we are spending times.
>>
>> We know that we can tell wt_status_collect_untracked() not to bother
>> with the untracked or ignored files with !s->show_untracked_files
>> already, but I think the more interesting question is if we can show
>> the untracked files with less overhead.
>>
>> If we want to show untrackedd files, it is a given that we need to
>> read directories to see what paths there are on the filesystem. Is
>> the opendir/readdir cost dominating in the process? Are we spending
>> a lot of time sifting the result of opendir/readdir via the ignore
>> mechanism? Is reading the "ignore" files costing us much to prime
>> the ignore mechanism?
>>
>> If readdir cost is dominant, then that makes "cache gitignore" a
>> nonsense proposition, I think. If you really want to "cache"
>> something, you need to have somebody (i.e. a daemon) who constantly
>> keeps an eye on the filesystem changes and can respond with the up
>> to date result directly to fill_directory(). I somehow doubt that
>> it is a direction we would want to go in, though.
>
> Yeah, it did not cut out syscall cost, I also cut a lot of user-space
> processing (plus .gitignore content access). From the timings I posted
> earlier,
>
>> unmodified dir.c
>> real 0m0.550s 0m0.287s
>> user 0m0.305s 0m0.201s
>> sys 0m0.240s 0m0.084s
>
> sys time is reduced from 0.24s to 0.08s, so readdir+opendir definitely
> has something to do with it (and perhaps reading .gitignore). But it
> also reduces user time from 0.305 to 0.201s. I don't think avoiding
> readdir+openddir will bring us this gain. It's probably the cost of
> matching .gitignore. I'll try to replace opendir+readdir with a
> no-syscall version. At this point "untracked caching" sounds more
> feasible (and less complex) than ".gitignore cachine".
>
Thanks for Duy for the measurements, and patches.
I took the freedom to convert the patched dir.c into a
"runtime configurable" git status option.
I'm not sure if the following copy-and-paste work applies,
(it is based on Git 1.8.1.3), but the time spend for
"git status --changed-only" is basically half the time of
"git status", similar to what Duy has measured.
I did a test both on a Linux box and Mac OS.
And the speedup is so impressive, that I am tempted to submit a patch simlar
to the following, what do we think about it?
/Torsten
-- >8 --
[PATCH] git status: add option changed-only
git status may be run faster if
- we only check if files are changed which are already known to git.
- we don't check if there are untracked files.
"git status --changed-only" (or the short form "git status -c")
will only check for changed files which are already known to git,
and which are in the index.
The call to read_directory_recursive() is skipped and untracked files
in the working tree are not reported.
Inspired-by: Duy Nguyen <pclouds@gmail.com>
Signed-off-by: Torsten Bögershausen <tboegi@web.de>
---
builtin/commit.c | 2 ++
dir.c | 5 +++--
dir.h | 3 ++-
wt-status.c | 3 +++
wt-status.h | 1 +
5 files changed, 11 insertions(+), 3 deletions(-)
diff --git a/builtin/commit.c b/builtin/commit.c
index d6dd3df..6a5ba11 100644
--- a/builtin/commit.c
+++ b/builtin/commit.c
@@ -1158,6 +1158,8 @@ int cmd_status(int argc, const char **argv, const char *prefix)
unsigned char sha1[20];
static struct option builtin_status_options[] = {
OPT__VERBOSE(&verbose, N_("be verbose")),
+ OPT_BOOLEAN('c', "changed-only", &s.check_changed_only,
+ N_("Ignore untracked files. Check if files known to git are modified")),
OPT_SET_INT('s', "short", &status_format,
N_("show status concisely"), STATUS_FORMAT_SHORT),
OPT_BOOLEAN('b', "branch", &s.show_branch,
diff --git a/dir.c b/dir.c
index a473ca2..555b652 100644
--- a/dir.c
+++ b/dir.c
@@ -1274,8 +1274,9 @@ int read_directory(struct dir_struct *dir, const char *path, int len, const char
return dir->nr;
simplify = create_simplify(pathspec);
- if (!len || treat_leading_path(dir, path, len, simplify))
- read_directory_recursive(dir, path, len, 0, simplify);
+ if ((!(dir->flags & DIR_CHECK_CHANGED_ONLY)) &&
+ (!len || treat_leading_path(dir, path, len, simplify))) o
+ read_directory_recursive(dir, path, len, 0, simplify);
free_simplify(simplify);
qsort(dir->entries, dir->nr, sizeof(struct dir_entry *), cmp_name);
qsort(dir->ignored, dir->ignored_nr, sizeof(struct dir_entry *), cmp_name);
diff --git a/dir.h b/dir.h
index f5c89e3..1a915a7 100644
--- a/dir.h
+++ b/dir.h
@@ -41,7 +41,8 @@ struct dir_struct {
DIR_SHOW_OTHER_DIRECTORIES = 1<<1,
DIR_HIDE_EMPTY_DIRECTORIES = 1<<2,
DIR_NO_GITLINKS = 1<<3,
- DIR_COLLECT_IGNORED = 1<<4
+ DIR_COLLECT_IGNORED = 1<<4,
+ DIR_CHECK_CHANGED_ONLY = 1<<5
} flags;
struct dir_entry **entries;
struct dir_entry **ignored;
diff --git a/wt-status.c b/wt-status.c
index d7cfe8f..b315785 100644
--- a/wt-status.c
+++ b/wt-status.c
@@ -503,6 +503,9 @@ static void wt_status_collect_untracked(struct wt_status *s)
if (s->show_untracked_files != SHOW_ALL_UNTRACKED_FILES)
dir.flags |=
DIR_SHOW_OTHER_DIRECTORIES | DIR_HIDE_EMPTY_DIRECTORIES;
+ if (s->check_changed_only)
+ dir.flags |= DIR_CHECK_CHANGED_ONLY;
+
setup_standard_excludes(&dir);
fill_directory(&dir, s->pathspec);
diff --git a/wt-status.h b/wt-status.h
index 236b41f..7eb0115 100644
--- a/wt-status.h
+++ b/wt-status.h
@@ -47,6 +47,7 @@ struct wt_status {
const char **pathspec;
int verbose;
int amend;
+ int check_changed_only;
enum commit_whence whence;
int nowarn;
int use_color;
--
1.8.2.rc2
^ permalink raw reply related
* Re: [PATCH] setup.c: Fix prefix_pathspec from looping pass end of string
From: Andrew Wong @ 2013-03-07 22:25 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vobeulw4d.fsf@alter.siamese.dyndns.org>
On 3/7/13, Junio C Hamano <gitster@pobox.com> wrote:
> The parser that goes past the end of the string may be a bug worth
> fixing, but is this patch sufficient to diagnose such an input as an
> error?
Yea, the patch should fix the passing end of string too. The parser
was going past end of string because the nextat is set to "copyfrom +
len + 1" for the '\0' case too. Then "+ 1" causes the parser to go
pass end of string. If we handle the '\0' case separately, then the
parser ends properly, and shouldn't be able to go pass the end of
string.
Hm, should I be paranoid and put an "else" clause to call die() as
well? In case there's a scenario where none of the 3 cases is true...
Andrew
^ permalink raw reply
* [BUG] bare repository detection does not work with aliases
From: Mark Lodato @ 2013-03-07 22:47 UTC (permalink / raw)
To: git list
It seems that the fallback bare repository detection in the absence of
core.bare fails for aliases.
$ git init --bare foo
$ cd foo
$ git config alias.s 'status -sb'
$ git s
fatal: This operation must be run in a work tree
$ sed -i -e '/bare =/d' config
$ git s
## Initial commit on master
?? HEAD
?? config
?? description
?? hooks
?? info/
$ git status -sb
fatal: This operation must be run in a work tree
The reason I am using the fallback is to use a single bare repository
with multiple working directories (via git-new-workdir) as suggested
in 8fa0ee3b [1].
[1] https://github.com/git/git/commit/8fa0ee3b50736eb869a3e13375bb041c1bf5aa12
^ permalink raw reply
* [ANNOUNCE] Git v1.8.2-rc3
From: Junio C Hamano @ 2013-03-07 23:13 UTC (permalink / raw)
To: git; +Cc: Linux Kernel
A release candidate Git v1.8.2-rc3 is now available for testing
at the usual places.
The release tarballs are found at:
http://code.google.com/p/git-core/downloads/list
and their SHA-1 checksums are:
3fe30d85cea78a388d61ba79fe3a106fca41cfbe git-1.8.2.rc3.tar.gz
4b378cf6129fa4c9355436b93a698dde2ed4ce7a git-htmldocs-1.8.2.rc3.tar.gz
b18a1f2e70920b5028f1179cc4b362ad78a6f34c git-manpages-1.8.2.rc3.tar.gz
Also the following public repositories all have a copy of the v1.8.2-rc3
tag and the master branch that the tag points at:
url = git://repo.or.cz/alt-git.git
url = https://code.google.com/p/git-core/
url = git://git.sourceforge.jp/gitroot/git-core/git.git
url = git://git-core.git.sourceforge.net/gitroot/git-core/git-core
url = https://github.com/gitster/git
Git v1.8.2 Release Notes (draft)
========================
Backward compatibility notes
----------------------------
In the next major release Git 2.0 (not *this* one), we will change the
behavior of the "git push" command.
When "git push [$there]" does not say what to push, we have used the
traditional "matching" semantics so far (all your branches were sent
to the remote as long as there already are branches of the same name
over there). We will use the "simple" semantics that pushes the
current branch to the branch with the same name, only when the current
branch is set to integrate with that remote branch. There is a user
preference configuration variable "push.default" to change this.
"git push $there tag v1.2.3" used to allow replacing a tag v1.2.3
that already exists in the repository $there, if the rewritten tag
you are pushing points at a commit that is a descendant of a commit
that the old tag v1.2.3 points at. This was found to be error prone
and starting with this release, any attempt to update an existing
ref under refs/tags/ hierarchy will fail, without "--force".
When "git add -u" and "git add -A", that does not specify what paths
to add on the command line, is run from inside a subdirectory, the
scope of the operation has always been limited to the subdirectory.
Many users found this counter-intuitive, given that "git commit -a"
and other commands operate on the entire tree regardless of where you
are. In this release, these commands give warning in such a case and
encourage the user to say "git add -u/-A ." instead when restricting
the scope to the current directory.
At Git 2.0 (not *this* one), we plan to change these commands without
pathspec to operate on the entire tree. Forming a habit to type "."
when you mean to limit the command to the current working directory
will protect you against the planned future change, and that is the
whole point of the new message (there will be no configuration
variable to squelch this warning---it goes against the "habit forming"
objective).
Updates since v1.8.1
--------------------
UI, Workflows & Features
* Initial ports to QNX and z/OS UNIX System Services have started.
* Output from the tests is coloured using "green is okay, yellow is
questionable, red is bad and blue is informative" scheme.
* Mention of "GIT/Git/git" in the documentation have been updated to
be more uniform and consistent. The name of the system and the
concept it embodies is "Git"; the command the users type is "git".
All-caps "GIT" was merely a way to imitate "Git" typeset in small
caps in our ASCII text only documentation and to be avoided.
* The completion script (in contrib/completion) used to let the
default completer to suggest pathnames, which gave too many
irrelevant choices (e.g. "git add" would not want to add an
unmodified path). It learnt to use a more git-aware logic to
enumerate only relevant ones.
* In bare repositories, "git shortlog" and other commands now read
mailmap files from the tip of the history, to help running these
tools in server settings.
* Color specifiers, e.g. "%C(blue)Hello%C(reset)", used in the
"--format=" option of "git log" and friends can be disabled when
the output is not sent to a terminal by prefixing them with
"auto,", e.g. "%C(auto,blue)Hello%C(auto,reset)".
* Scripts can ask Git that wildcard patterns in pathspecs they give do
not have any significance, i.e. take them as literal strings.
* The patterns in .gitignore and .gitattributes files can have **/,
as a pattern that matches 0 or more levels of subdirectory.
E.g. "foo/**/bar" matches "bar" in "foo" itself or in a
subdirectory of "foo".
* When giving arguments without "--" disambiguation, object names
that come earlier on the command line must not be interpretable as
pathspecs and pathspecs that come later on the command line must
not be interpretable as object names. This disambiguation rule has
been tweaked so that ":/" (no other string before or after) is
always interpreted as a pathspec; "git cmd -- :/" is no longer
needed, you can just say "git cmd :/".
* Various "hint" lines Git gives when it asks the user to edit
messages in the editor are commented out with '#' by default. The
core.commentchar configuration variable can be used to customize
this '#' to a different character.
* "git add -u" and "git add -A" without pathspec issues warning to
make users aware that they are only operating on paths inside the
subdirectory they are in. Use ":/" (everything from the top) or
"." (everything from the $cwd) to disambiguate.
* "git blame" (and "git diff") learned the "--no-follow" option.
* "git branch" now rejects some nonsense combinations of command line
arguments (e.g. giving more than one branch name to rename) with
more case-specific error messages.
* "git check-ignore" command to help debugging .gitignore files has
been added.
* "git cherry-pick" can be used to replay a root commit to an unborn
branch.
* "git commit" can be told to use --cleanup=whitespace by setting the
configuration variable commit.cleanup to 'whitespace'.
* "git diff" and other Porcelain commands can be told to use a
non-standard algorithm by setting diff.algorithm configuration
variable.
* "git fetch --mirror" and fetch that uses other forms of refspec
with wildcard used to attempt to update a symbolic ref that match
the wildcard on the receiving end, which made little sense (the
real ref that is pointed at by the symbolic ref would be updated
anyway). Symbolic refs no longer are affected by such a fetch.
* "git format-patch" now detects more cases in which a whole branch
is being exported, and uses the description for the branch, when
asked to write a cover letter for the series.
* "git format-patch" learned "-v $count" option, and prepends a
string "v$count-" to the names of its output files, and also
automatically sets the subject prefix to "PATCH v$count". This
allows patches from rerolled series to be stored under different
names and makes it easier to reuse cover letter messages.
* "git log" and friends can be told with --use-mailmap option to
rewrite the names and email addresses of people using the mailmap
mechanism.
* "git log --cc --graph" now shows the combined diff output with the
ancestry graph.
* "git log --grep=<pattern>" honors i18n.logoutputencoding to look
for the pattern after fixing the log message to the specified
encoding.
* "git mergetool" and "git difftool" learned to list the available
tool backends in a more consistent manner.
* "git mergetool" is aware of TortoiseGitMerge now and uses it over
TortoiseMerge when available.
* "git push" now requires "-f" to update a tag, even if it is a
fast-forward, as tags are meant to be fixed points.
* Error messages from "git push" when it stops to prevent remote refs
from getting overwritten by mistake have been improved to explain
various situations separately.
* "git push" will stop without doing anything if the new "pre-push"
hook exists and exits with a failure.
* When "git rebase" fails to generate patches to be applied (e.g. due
to oom), it failed to detect the failure and instead behaved as if
there were nothing to do. A workaround to use a temporary file has
been applied, but we probably would want to revisit this later, as
it hurts the common case of not failing at all.
* Input and preconditions to "git reset" has been loosened where
appropriate. "git reset $fromtree Makefile" requires $fromtree to
be any tree (it used to require it to be a commit), for example.
"git reset" (without options or parameters) used to error out when
you do not have any commits in your history, but it now gives you
an empty index (to match non-existent commit you are not even on).
* "git status" says what branch is being bisected or rebased when
able, not just "bisecting" or "rebasing".
* "git submodule" started learning a new mode to integrate with the
tip of the remote branch (as opposed to integrating with the commit
recorded in the superproject's gitlink).
* "git upload-pack" which implements the service "ls-remote" and
"fetch" talk to can be told to hide ref hierarchies the server
side internally uses (and that clients have no business learning
about) with transfer.hiderefs configuration.
Foreign Interface
* "git fast-export" has been updated for its use in the context of
the remote helper interface.
* A new remote helper to interact with bzr has been added to contrib/.
* "git p4" got various bugfixes around its branch handling. It is
also made usable with Python 2.4/2.5. In addition, its various
portability issues for Cygwin have been addressed.
* The remote helper to interact with Hg in contrib/ has seen a few
fixes.
Performance, Internal Implementation, etc.
* "git fsck" has been taught to be pickier about entries in tree
objects that should not be there, e.g. ".", ".git", and "..".
* Matching paths with common forms of pathspecs that contain wildcard
characters has been optimized further.
* We stopped paying attention to $GIT_CONFIG environment that points
at a single configuration file from any command other than "git config"
quite a while ago, but "git clone" internally set, exported, and
then unexported the variable during its operation unnecessarily.
* "git reset" internals has been reworked and should be faster in
general. We tried to be careful not to break any behaviour but
there could be corner cases, especially when running the command
from a conflicted state, that we may have missed.
* The implementation of "imap-send" has been updated to reuse xml
quoting code from http-push codepath, and lost a lot of unused
code.
* There is a simple-minded checker for the test scripts in t/
directory to catch most common mistakes (it is not enabled by
default).
* You can build with USE_WILDMATCH=YesPlease to use a replacement
implementation of pattern matching logic used for pathname-like
things, e.g. refnames and paths in the repository. This new
implementation is not expected change the existing behaviour of Git
in this release, except for "git for-each-ref" where you can now
say "refs/**/master" and match with both refs/heads/master and
refs/remotes/origin/master. We plan to use this new implementation
in wider places (e.g. "git ls-files '**/Makefile' may find Makefile
at the top-level, and "git log '**/t*.sh'" may find commits that
touch a shell script whose name begins with "t" at any level) in
future versions of Git, but we are not there yet. By building with
USE_WILDMATCH, using the resulting Git daily and reporting when you
find breakages, you can help us get closer to that goal.
* Some reimplementations of Git do not write all the stat info back
to the index due to their implementation limitations (e.g. jgit).
A configuration option can tell Git to ignore changes to most of
the stat fields and only pay attention to mtime and size, which
these implementations can reliably update. This can be used to
avoid excessive revalidation of contents.
* Some platforms ship with old version of expat where xmlparse.h
needs to be included instead of expat.h; the build procedure has
been taught about this.
* "make clean" on platforms that cannot compute header dependencies
on the fly did not work with implementations of "rm" that do not
like an empty argument list.
Also contains minor documentation updates and code clean-ups.
Fixes since v1.8.1
------------------
Unless otherwise noted, all the fixes since v1.8.1 in the maintenance
track are contained in this release (see release notes to them for
details).
* An element on GIT_CEILING_DIRECTORIES list that does not name the
real path to a directory (i.e. a symbolic link) could have caused
the GIT_DIR discovery logic to escape the ceiling.
* When attempting to read the XDG-style $HOME/.config/git/config and
finding that $HOME/.config/git is a file, we gave a wrong error
message, instead of treating the case as "a custom config file does
not exist there" and moving on.
* The behaviour visible to the end users was confusing, when they
attempt to kill a process spawned in the editor that was in turn
launched by Git with SIGINT (or SIGQUIT), as Git would catch that
signal and die. We ignore these signals now.
(merge 0398fc34 pf/editor-ignore-sigint later to maint).
* A child process that was killed by a signal (e.g. SIGINT) was
reported in an inconsistent way depending on how the process was
spawned by us, with or without a shell in between.
* After failing to create a temporary file using mkstemp(), failing
pathname was not reported correctly on some platforms.
* We used to stuff "user@" and then append what we read from
/etc/mailname to come up with a default e-mail ident, but a bug
lost the "user@" part.
* The attribute mechanism didn't allow limiting attributes to be
applied to only a single directory itself with "path/" like the
exclude mechanism does. The initial implementation of this that
was merged to 'maint' and 1.8.1.2 was with a severe performance
degradations and needs to merge a fix-up topic.
* The smart HTTP clients forgot to verify the content-type that comes
back from the server side to make sure that the request is being
handled properly.
* "git am" did not parse datestamp correctly from Hg generated patch,
when it is run in a locale outside C (or en).
* "git apply" misbehaved when fixing whitespace breakages by removing
excess trailing blank lines.
* "git apply --summary" has been taught to make sure the similarity
value shown in its output is sensible, even when the input had a
bogus value.
* A tar archive created by "git archive" recorded a directory in a
way that made NetBSD's implementation of "tar" sometimes unhappy.
* "git archive" did not record uncompressed size in the header when
streaming a zip archive, which confused some implementations of unzip.
* "git archive" did not parse configuration values in tar.* namespace
correctly.
(merge b3873c3 jk/config-parsing-cleanup later to maint).
* Attempt to "branch --edit-description" an existing branch, while
being on a detached HEAD, errored out.
* "git clean" showed what it was going to do, but sometimes end up
finding that it was not allowed to do so, which resulted in a
confusing output (e.g. after saying that it will remove an
untracked directory, it found an embedded git repository there
which it is not allowed to remove). It now performs the actions
and then reports the outcome more faithfully.
* When "git clone --separate-git-dir=$over_there" is interrupted, it
failed to remove the real location of the $GIT_DIR it created.
This was most visible when interrupting a submodule update.
* "git cvsimport" mishandled timestamps at DST boundary.
* We used to have an arbitrary 32 limit for combined diff input,
resulting in incorrect number of leading colons shown when showing
the "--raw --cc" output.
* "git fetch --depth" was broken in at least three ways. The
resulting history was deeper than specified by one commit, it was
unclear how to wipe the shallowness of the repository with the
command, and documentation was misleading.
(merge cfb70e1 nd/fetch-depth-is-broken later to maint).
* "git log --all -p" that walked refs/notes/textconv/ ref can later
try to use the textconv data incorrectly after it gets freed.
* We forgot to close the file descriptor reading from "gpg" output,
killing "git log --show-signature" on a long history.
* The way "git svn" asked for password using SSH_ASKPASS and
GIT_ASKPASS was not in line with the rest of the system.
* The --graph code fell into infinite loop when asked to do what the
code did not expect.
* http transport was wrong to ask for the username when the
authentication is done by certificate identity.
* "git pack-refs" that ran in parallel to another process that
created new refs had a nasty race.
* Rebasing the history of superproject with change in the submodule
has been broken since v1.7.12.
* After "git add -N" and then writing a tree object out of the
index, the cache-tree data structure got corrupted.
* "git clone" used to allow --bare and --separate-git-dir=$there
options at the same time, which was nonsensical.
* "git rebase --preserve-merges" lost empty merges in recent versions
of Git.
* "git merge --no-edit" computed who were involved in the work done
on the side branch, even though that information is to be discarded
without getting seen in the editor.
* "git merge" started calling prepare-commit-msg hook like "git
commit" does some time ago, but forgot to pay attention to the exit
status of the hook.
* A failure to push due to non-ff while on an unborn branch
dereferenced a NULL pointer when showing an error message.
* When users spell "cc:" in lowercase in the fake "header" in the
trailer part, "git send-email" failed to pick up the addresses from
there. As e-mail headers field names are case insensitive, this
script should follow suit and treat "cc:" and "Cc:" the same way.
* Output from "git status --ignored" showed an unexpected interaction
with "--untracked".
* "gitweb", when sorting by age to show repositories with new
activities first, used to sort repositories with absolutely
nothing in it early, which was not very useful.
* "gitweb"'s code to sanitize control characters before passing it to
"highlight" filter lost known-to-be-safe control characters by
mistake.
* "gitweb" pages served over HTTPS, when configured to show picon or
gravatar, referred to these external resources to be fetched via
HTTP, resulting in mixed contents warning in browsers.
* When a line to be wrapped has a solid run of non space characters
whose length exactly is the wrap width, "git shortlog -w" failed
to add a newline after such a line.
* Command line completion leaked an unnecessary error message while
looking for possible matches with paths in <tree-ish>.
* Command line completion for "tcsh" emitted an unwanted space
after completing a single directory name.
* Command line completion code was inadvertently made incompatible with
older versions of bash by using a newer array notation.
* "git push" was taught to refuse updating the branch that is
currently checked out long time ago, but the user manual was left
stale.
(merge 50995ed wk/man-deny-current-branch-is-default-these-days later to maint).
* Some shells do not behave correctly when IFS is unset; work it
around by explicitly setting it to the default value.
* Some scripted programs written in Python did not get updated when
PYTHON_PATH changed.
(cherry-pick 96a4647fca54031974cd6ad1 later to maint).
* When autoconf is used, any build on a different commit always ran
"config.status --recheck" even when unnecessary.
* A fix was added to the build procedure to work around buggy
versions of ccache broke the auto-generation of dependencies, which
unfortunately is still relevant because some people use ancient
distros.
* The autoconf subsystem passed --mandir down to generated
config.mak.autogen but forgot to do the same for --htmldir.
(merge 55d9bf0 ct/autoconf-htmldir later to maint).
* A change made on v1.8.1.x maintenance track had a nasty regression
to break the build when autoconf is used.
(merge 7f1b697 jn/less-reconfigure later to maint).
* We have been carrying a translated and long-unmaintained copy of an
old version of the tutorial; removed.
* t0050 had tests expecting failures from a bug that was fixed some
time ago.
* t4014, t9502 and t0200 tests had various portability issues that
broke on OpenBSD.
* t9020 and t3600 tests had various portability issues.
* t9200 runs "cvs init" on a directory that already exists, but a
platform can configure this fail for the current user (e.g. you
need to be in the cvsadmin group on NetBSD 6.0).
* t9020 and t9810 had a few non-portable shell script construct.
* Scripts to test bash completion was inherently flaky as it was
affected by whatever random things the user may have on $PATH.
* An element on GIT_CEILING_DIRECTORIES could be a "logical" pathname
that uses a symbolic link to point at somewhere else (e.g. /home/me
that points at /net/host/export/home/me, and the latter directory
is automounted). Earlier when Git saw such a pathname e.g. /home/me
on this environment variable, the "ceiling" mechanism did not take
effect. With this release (the fix has also been merged to the
v1.8.1.x maintenance series), elements on GIT_CEILING_DIRECTORIES
are by default checked for such aliasing coming from symbolic
links. As this needs to actually resolve symbolic links for each
element on the GIT_CEILING_DIRECTORIES, you can disable this
mechanism for some elements by listing them after an empty element
on the GIT_CEILING_DIRECTORIES. e.g. Setting /home/me::/home/him to
GIT_CEILING_DIRECTORIES makes Git resolve symbolic links in
/home/me when checking if the current directory is under /home/me,
but does not do so for /home/him.
(merge 7ec30aa mh/maint-ceil-absolute later to maint).
----------------------------------------------------------------
Changes since v1.8.2-rc2 are as follows:
Fredrik Gustafsson (1):
gitweb/README: remove reference to git.kernel.org
Jiang Xin (2):
l10n: git.pot: v1.8.2 round 4 (1 changed)
l10n: zh_CN.po: translate 1 new message
Junio C Hamano (1):
Git 1.8.2-rc3
Matthieu Moy (1):
git-completion.zsh: define __gitcomp_file compatibility function
Peter Krefting (1):
l10n: Update Swedish translation (2009t0f0u)
Ralf Thielow (4):
l10n: de.po: translate 35 new messages
l10n: de.po: translate 5 new messages
l10n: de.po: correct translation of "bisect" messages
l10n: de.po: translate 1 new message
Tran Ngoc Quan (1):
l10n: vi.po: Update translation (2009t0f0u)
^ permalink raw reply
* [PATCH 0/3] fix git-p4 client root symlink problems
From: Pete Wyckoff @ 2013-03-07 23:19 UTC (permalink / raw)
To: git; +Cc: Miklós Fazekas, John Keeping
In-Reply-To: <20130307091317.GY7738@serenity.lan>
Miklós pointed out in
http://thread.gmane.org/gmane.comp.version-control.git/214915
that when the p4 client root included a symlink, bad things
happen. It is fixable, but inconvenient, to use an absolute path
in one's p4 client. It's not too hard to be smarter about this
in git-p4.
Thanks to Miklós for the patch, and to John for the style
suggestions. I wrote a couple of tests to make sure this part
doesn't break again.
This is maybe a bug introduced by bf1d68f (git-p4: use absolute
directory for PWD env var, 2011-12-09), but that's so long ago
that I don't think this is a candidate for maint.
-- Pete
Miklós Fazekas (1):
git p4: avoid expanding client paths in chdir
Pete Wyckoff (2):
git p4 test: make sure P4CONFIG relative path works
git p4 test: should honor symlink in p4 client root
git-p4.py | 29 ++++++++++++++++++++++-------
t/t9808-git-p4-chdir.sh | 41 +++++++++++++++++++++++++++++++++++++++++
2 files changed, 63 insertions(+), 7 deletions(-)
--
1.8.2.rc2.64.g8335025
^ permalink raw reply
* [PATCH 1/3] git p4 test: make sure P4CONFIG relative path works
From: Pete Wyckoff @ 2013-03-07 23:19 UTC (permalink / raw)
To: git; +Cc: Miklós Fazekas, John Keeping
In-Reply-To: <1362698357-7334-1-git-send-email-pw@padd.com>
This adds a test for the fix in bf1d68f (git-p4: use absolute
directory for PWD env var, 2011-12-09). It is necessary to
set PWD to an absolute path so that p4 can find files referenced
by non-absolute paths, like the value of the P4CONFIG environment
variable.
P4 does not open files directly; it builds a path by prepending
the contents of the PWD environment variable.
Signed-off-by: Pete Wyckoff <pw@padd.com>
---
t/t9808-git-p4-chdir.sh | 14 ++++++++++++++
1 file changed, 14 insertions(+)
diff --git a/t/t9808-git-p4-chdir.sh b/t/t9808-git-p4-chdir.sh
index dc92e60..55c5e36 100755
--- a/t/t9808-git-p4-chdir.sh
+++ b/t/t9808-git-p4-chdir.sh
@@ -42,6 +42,20 @@ test_expect_success 'P4CONFIG and relative dir clone' '
)
'
+# Common setup using .p4config to set P4CLIENT and P4PORT breaks
+# if clone destination is relative. Make sure that chdir() expands
+# the relative path in --dest to absolute.
+test_expect_success 'p4 client root would be relative due to clone --dest' '
+ test_when_finished cleanup_git &&
+ (
+ echo P4PORT=$P4PORT >git/.p4config &&
+ P4CONFIG=.p4config &&
+ export P4CONFIG &&
+ unset P4PORT &&
+ git p4 clone --dest="git" //depot
+ )
+'
+
test_expect_success 'kill p4d' '
kill_p4d
'
--
1.8.2.rc2.64.g8335025
^ permalink raw reply related
* [PATCH 2/3] git p4 test: should honor symlink in p4 client root
From: Pete Wyckoff @ 2013-03-07 23:19 UTC (permalink / raw)
To: git; +Cc: Miklós Fazekas, John Keeping
In-Reply-To: <1362698357-7334-1-git-send-email-pw@padd.com>
This test fails when the p4 client root includes
a symlink. It complains:
Path /vol/bar/projects/foo/... is not under client root /p/foo
and dumps a traceback.
Signed-off-by: Pete Wyckoff <pw@padd.com>
---
t/t9808-git-p4-chdir.sh | 27 +++++++++++++++++++++++++++
1 file changed, 27 insertions(+)
diff --git a/t/t9808-git-p4-chdir.sh b/t/t9808-git-p4-chdir.sh
index 55c5e36..af8bd8a 100755
--- a/t/t9808-git-p4-chdir.sh
+++ b/t/t9808-git-p4-chdir.sh
@@ -56,6 +56,33 @@ test_expect_success 'p4 client root would be relative due to clone --dest' '
)
'
+# When the p4 client Root is a symlink, make sure chdir() does not use
+# getcwd() to convert it to a physical path.
+test_expect_failure 'p4 client root symlink should stay symbolic' '
+ physical="$TRASH_DIRECTORY/physical" &&
+ symbolic="$TRASH_DIRECTORY/symbolic" &&
+ test_when_finished "rm -rf \"$physical\"" &&
+ test_when_finished "rm \"$symbolic\"" &&
+ mkdir -p "$physical" &&
+ ln -s "$physical" "$symbolic" &&
+ test_when_finished cleanup_git &&
+ (
+ P4CLIENT=client-sym &&
+ p4 client -i <<-EOF &&
+ Client: $P4CLIENT
+ Description: $P4CLIENT
+ Root: $symbolic
+ LineEnd: unix
+ View: //depot/... //$P4CLIENT/...
+ EOF
+ git p4 clone --dest="$git" //depot &&
+ cd "$git" &&
+ test_commit file2 &&
+ git config git-p4.skipSubmitEdit true &&
+ git p4 submit
+ )
+'
+
test_expect_success 'kill p4d' '
kill_p4d
'
--
1.8.2.rc2.64.g8335025
^ permalink raw reply related
* [PATCH 3/3] git p4: avoid expanding client paths in chdir
From: Pete Wyckoff @ 2013-03-07 23:19 UTC (permalink / raw)
To: git; +Cc: Miklós Fazekas, John Keeping
In-Reply-To: <1362698357-7334-1-git-send-email-pw@padd.com>
From: Miklós Fazekas <mfazekas@szemafor.com>
The generic chdir() helper sets the PWD environment
variable, as that is what is used by p4 to know its
current working directory. Normally the shell would
do this, but in git-p4, we must do it by hand.
However, when the path contains a symbolic link,
os.getcwd() will return the physical location. If the
p4 client specification includes symlinks, setting PWD
to the physical location causes p4 to think it is not
inside the client workspace. It complains, e.g.
Path /vol/bar/projects/foo/... is not under client root /p/foo
One workaround is to use AltRoots in the p4 client specification,
but it is cleaner to handle it directly in git-p4.
Other uses of chdir still require setting PWD to an
absolute path so p4 features like P4CONFIG work. See
bf1d68f (git-p4: use absolute directory for PWD env
var, 2011-12-09).
[ pw: tweak patch and commit message ]
Thanks-to: John Keeping <john@keeping.me.uk>
Signed-off-by: Pete Wyckoff <pw@padd.com>
---
git-p4.py | 29 ++++++++++++++++++++++-------
t/t9808-git-p4-chdir.sh | 2 +-
2 files changed, 23 insertions(+), 8 deletions(-)
diff --git a/git-p4.py b/git-p4.py
index 647f110..7288c0b 100755
--- a/git-p4.py
+++ b/git-p4.py
@@ -79,12 +79,27 @@ def p4_build_cmd(cmd):
real_cmd += cmd
return real_cmd
-def chdir(dir):
- # P4 uses the PWD environment variable rather than getcwd(). Since we're
- # not using the shell, we have to set it ourselves. This path could
- # be relative, so go there first, then figure out where we ended up.
- os.chdir(dir)
- os.environ['PWD'] = os.getcwd()
+def chdir(path, is_client_path=False):
+ """Do chdir to the given path, and set the PWD environment
+ variable for use by P4. It does not look at getcwd() output.
+ Since we're not using the shell, it is necessary to set the
+ PWD environment variable explicitly.
+
+ Normally, expand the path to force it to be absolute. This
+ addresses the use of relative path names inside P4 settings,
+ e.g. P4CONFIG=.p4config. P4 does not simply open the filename
+ as given; it looks for .p4config using PWD.
+
+ If is_client_path, the path was handed to us directly by p4,
+ and may be a symbolic link. Do not call os.getcwd() in this
+ case, because it will cause p4 to think that PWD is not inside
+ the client path.
+ """
+
+ os.chdir(path)
+ if not is_client_path:
+ path = os.getcwd()
+ os.environ['PWD'] = path
def die(msg):
if verbose:
@@ -1624,7 +1639,7 @@ class P4Submit(Command, P4UserMap):
new_client_dir = True
os.makedirs(self.clientPath)
- chdir(self.clientPath)
+ chdir(self.clientPath, is_client_path=True)
if self.dry_run:
print "Would synchronize p4 checkout in %s" % self.clientPath
else:
diff --git a/t/t9808-git-p4-chdir.sh b/t/t9808-git-p4-chdir.sh
index af8bd8a..09b2cc4 100755
--- a/t/t9808-git-p4-chdir.sh
+++ b/t/t9808-git-p4-chdir.sh
@@ -58,7 +58,7 @@ test_expect_success 'p4 client root would be relative due to clone --dest' '
# When the p4 client Root is a symlink, make sure chdir() does not use
# getcwd() to convert it to a physical path.
-test_expect_failure 'p4 client root symlink should stay symbolic' '
+test_expect_success 'p4 client root symlink should stay symbolic' '
physical="$TRASH_DIRECTORY/physical" &&
symbolic="$TRASH_DIRECTORY/symbolic" &&
test_when_finished "rm -rf \"$physical\"" &&
--
1.8.2.rc2.64.g8335025
^ permalink raw reply related
* Re: [feature request] 2) Remove many tags at once and 1) Prune tags on old-branch-before-rebase
From: Junio C Hamano @ 2013-03-07 23:33 UTC (permalink / raw)
To: Eric Chamberland; +Cc: git@vger.kernel.org
In-Reply-To: <51390E43.60704@giref.ulaval.ca>
Eric Chamberland <Eric.Chamberland@giref.ulaval.ca> writes:
> 1) git tag --delete-tags-to-danglings-and-unnamed-banches
>
> This would be able to remove all tags that refers to commits which are
> on branches that are no more referenced by any branch name. This is
> happening when you tag something, then "git rebase". Your tag will
> still be there on the old-and-before-rebase branch and won't be
> "pruned" by any git command... (that I know of...)
Not interesting for at least two reasons.
Why are "tags" any special? "git branch --delete-merged" may also
be of interest, and for that matter "git update-ref -d" to deal with
any ref in general would be equally valid if such an option were a
good idea.
What you want is a way to compute, given a set of tags (or refs in
general) and a set of branches (or another set of refs in general),
find the ones in the former that none of the latter can reach. With
that, you can drive "git tag -d $(that way)".
In other words, the feature does not belong to "git tag" command.
> 2) git tag -d "TOKEN*"
Again, not interesting. You already have:
git for-each-ref --format='%(refname:short)' refs/tags/TOKEN\* |
xargs -r git tag -d
^ permalink raw reply
* Re: [ANNOUNCE] Git v1.8.2-rc3
From: Javier Domingo @ 2013-03-07 23:40 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git@vger.kernel.org
In-Reply-To: <CALZVapkH-h-B9WG2gu7bjG5YPgCbOfi4Pkt=B_F7rqggmsGPHg@mail.gmail.com>
Thank you a lot! I appreciate very much, the more the "**/" in .gitignore files.
Cheers!
Javier Domingo
^ permalink raw reply
* Re: [PATCH] setup.c: Fix prefix_pathspec from looping pass end of string
From: Junio C Hamano @ 2013-03-07 23:59 UTC (permalink / raw)
To: Andrew Wong; +Cc: git
In-Reply-To: <CADgNjakrBCD2jMNUz95E-7FkyKmNgcQeuz8grDWczb-hM6yHhg@mail.gmail.com>
Andrew Wong <andrew.kw.w@gmail.com> writes:
> On 3/7/13, Junio C Hamano <gitster@pobox.com> wrote:
>> The parser that goes past the end of the string may be a bug worth
>> fixing, but is this patch sufficient to diagnose such an input as an
>> error?
>
> Yea, the patch should fix the passing end of string too. The parser
> was going past end of string because the nextat is set to "copyfrom +
> len + 1" for the '\0' case too. Then "+ 1" causes the parser to go
> pass end of string. If we handle the '\0' case separately, then the
> parser ends properly, and shouldn't be able to go pass the end of
> string.
This did not error out for me, though.
$ cd t && git ls-files ":(top"
^ permalink raw reply
* Re: inotify to minimize stat() calls
From: Junio C Hamano @ 2013-03-08 0:04 UTC (permalink / raw)
To: Torsten Bögershausen
Cc: Duy Nguyen, Ramkumar Ramachandra, Robert Zeh, Git List, finnag
In-Reply-To: <513911B3.7010903@web.de>
Torsten Bögershausen <tboegi@web.de> writes:
> diff --git a/builtin/commit.c b/builtin/commit.c
> index d6dd3df..6a5ba11 100644
> --- a/builtin/commit.c
> +++ b/builtin/commit.c
> @@ -1158,6 +1158,8 @@ int cmd_status(int argc, const char **argv, const char *prefix)
> unsigned char sha1[20];
> static struct option builtin_status_options[] = {
> OPT__VERBOSE(&verbose, N_("be verbose")),
> + OPT_BOOLEAN('c', "changed-only", &s.check_changed_only,
> + N_("Ignore untracked files. Check if files known to git are modified")),
Doesn't this make one wonder why a separate bit and implementation
is necessary to say "I am not interested in untracked files" when
"-uno" option is already there?
^ permalink raw reply
* Re: [PATCH] setup.c: Fix prefix_pathspec from looping pass end of string
From: Andrew Wong @ 2013-03-08 0:25 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vvc92kbho.fsf@alter.siamese.dyndns.org>
On 3/7/13, Junio C Hamano <gitster@pobox.com> wrote:
> This did not error out for me, though.
>
> $ cd t && git ls-files ":(top"
No error message at all? Hm, maybe in your case, the byte after the
end of string happens to be '\0' and the loop ended by chance?
git doesn't crash for me, but it generates this error:
$ git ls-files ":(top"
fatal: Invalid pathspec magic 'LS_COLORS=' in ':(top'
The loop runs for a second time after parsing "top", and copyfrom now
points to the byte after ":(top", which is coming from argv. And in my
distribution/platform, it looks like the envp, the third param of
main(), is packed right after the argv strings, because:
$ env | head -n 1
LS_COLORS=
^ permalink raw reply
* Re: [PATCH] setup.c: Fix prefix_pathspec from looping pass end of string
From: Junio C Hamano @ 2013-03-08 1:51 UTC (permalink / raw)
To: Andrew Wong; +Cc: git
In-Reply-To: <CADgNja=8f+_ORb_WStRz2grr0pYmJ2gZTnCHbOGUb3ogPPd_LQ@mail.gmail.com>
Andrew Wong <andrew.kw.w@gmail.com> writes:
> On 3/7/13, Junio C Hamano <gitster@pobox.com> wrote:
>> This did not error out for me, though.
>>
>> $ cd t && git ls-files ":(top"
>
> No error message at all? Hm, maybe in your case, the byte after the
> end of string happens to be '\0' and the loop ended by chance?
>
> git doesn't crash for me, but it generates this error:
> $ git ls-files ":(top"
> fatal: Invalid pathspec magic 'LS_COLORS=' in ':(top'
What I meant was that I do not get any error _after_ applying your
patch.
It is broken to behave as if "LS_COLORS=..." (which is totally
unrelated string that happens to be laid out next in the memory) is
a part of the pathspec magic specification your ":(top" started.
Your patch makes the code stop doing that.
But it is equally broken to behave as if there is nothing wrong in
the incomplete magic ":(top" that is not closed, isn't it?
^ permalink raw reply
* Re: [PATCH] setup.c: Fix prefix_pathspec from looping pass end of string
From: Andrew Wong @ 2013-03-08 1:58 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vk3pik6aq.fsf@alter.siamese.dyndns.org>
On 03/07/13 20:51, Junio C Hamano wrote:
> But it is equally broken to behave as if there is nothing wrong in
> the incomplete magic ":(top" that is not closed, isn't it?
Ah, yea, I did notice that, but then I saw a few lines below:
if (*copyfrom == ')')
copyfrom++;
which is explicitly making the ")" optional. So I thought maybe that was
the original intention, and left it at that. Though the doc says to end
with ")", so I guess it should error out after all? If that's the case,
I can try to come up with a patch to error it out (through die() ?).
^ permalink raw reply
* Re: [BUG] bare repository detection does not work with aliases
From: Jeff King @ 2013-03-08 5:48 UTC (permalink / raw)
To: Mark Lodato; +Cc: git list
In-Reply-To: <CAHREChhuX82ibNEDQnQUeS9TEeyMFGpuNhyXzt1Pn-Tt2BVOQA@mail.gmail.com>
On Thu, Mar 07, 2013 at 05:47:45PM -0500, Mark Lodato wrote:
> It seems that the fallback bare repository detection in the absence of
> core.bare fails for aliases.
This triggered some deja vu for me, so I went digging. And indeed, this
has been a bug since at least 2008. This patch (which never got applied)
fixed it:
http://thread.gmane.org/gmane.comp.version-control.git/72792
The issue is that we treat:
GIT_DIR=/some/path git ...
as if the current directory is the work tree, unless core.bare is
explicitly set, or unless an explicit work tree is given (via
GIT_WORK_TREE, "git --work-tree", or in the config). This is handy, and
backwards compatible.
Inside setup_git_directory, when we find the directory we put it in
$GIT_DIR for later reference by ourselves or sub-programs (since we are
typically moving to the top of the working tree next, we need to record
the original path, and can't rely on discovery finding the same path
again). But we don't set $GIT_WORK_TREE. So if you don't have core.bare
set, the above rule will kick in for sub-programs, or for aliases (which
will call setup_git_directory again).
The solution is that when we set $GIT_DIR like this, we need to also say
"no, there is no working tree; we are bare". And that's what that patch
does. It's 5 years old now, so not surprisingly, it does not apply
cleanly. The moral equivalent in today's code base would be something
like:
diff --git a/environment.c b/environment.c
index 89d6c70..8edaedd 100644
--- a/environment.c
+++ b/environment.c
@@ -200,7 +200,8 @@ void set_git_work_tree(const char *new_work_tree)
return;
}
git_work_tree_initialized = 1;
- work_tree = xstrdup(real_path(new_work_tree));
+ if (*new_work_tree)
+ work_tree = xstrdup(real_path(new_work_tree));
}
const char *get_git_work_tree(void)
diff --git a/setup.c b/setup.c
index e1cfa48..f0e1251 100644
--- a/setup.c
+++ b/setup.c
@@ -544,7 +544,7 @@ static const char *setup_explicit_git_dir(const char *gitdirenv,
worktree = get_git_work_tree();
/* both get_git_work_tree() and cwd are already normalized */
- if (!strcmp(cwd, worktree)) { /* cwd == worktree */
+ if (!worktree || !strcmp(cwd, worktree)) { /* cwd == worktree */
set_git_dir(gitdirenv);
free(gitfile);
return NULL;
@@ -636,6 +636,8 @@ static const char *setup_bare_git_dir(char *cwd, int offset, int len, int *nongi
}
else
set_git_dir(".");
+
+ setenv(GIT_WORK_TREE_ENVIRONMENT, "", 1);
return NULL;
}
which passes your test. Unfortunately, this patch runs afoul of the same
complaints that prevented the original from being acceptable (weirdness
on Windows with empty environment variables).
Having read the discussion again, I _think_ the more sane thing is to
actually just have a new variable, $GIT_BARE, which overrides any
core.bare config (just as $GIT_WORK_TREE override core.worktree). And
then we set that explicitly when we are in a bare $GIT_DIR, propagating
our auto-detection to sub-processes.
-Peff
^ permalink raw reply related
* Re: [BUG] bare repository detection does not work with aliases
From: Junio C Hamano @ 2013-03-08 6:27 UTC (permalink / raw)
To: Jeff King; +Cc: git
In-Reply-To: <20130308054824.GA24429@sigill.intra.peff.net>
The $GIT_BARE idea sounds very sensible to me.
Jeff King <peff@peff.net> wrote:
>On Thu, Mar 07, 2013 at 05:47:45PM -0500, Mark Lodato wrote:
>
>> It seems that the fallback bare repository detection in the absence
>of
>> core.bare fails for aliases.
>
>This triggered some deja vu for me, so I went digging. And indeed, this
>has been a bug since at least 2008. This patch (which never got
>applied)
>fixed it:
>
> http://thread.gmane.org/gmane.comp.version-control.git/72792
>
>The issue is that we treat:
>
> GIT_DIR=/some/path git ...
>
>as if the current directory is the work tree, unless core.bare is
>explicitly set, or unless an explicit work tree is given (via
>GIT_WORK_TREE, "git --work-tree", or in the config). This is handy,
>and
>backwards compatible.
>
>Inside setup_git_directory, when we find the directory we put it in
>$GIT_DIR for later reference by ourselves or sub-programs (since we are
>typically moving to the top of the working tree next, we need to record
>the original path, and can't rely on discovery finding the same path
>again). But we don't set $GIT_WORK_TREE. So if you don't have core.bare
>set, the above rule will kick in for sub-programs, or for aliases
>(which
>will call setup_git_directory again).
>
>The solution is that when we set $GIT_DIR like this, we need to also
>say
>"no, there is no working tree; we are bare". And that's what that patch
>does. It's 5 years old now, so not surprisingly, it does not apply
>cleanly. The moral equivalent in today's code base would be something
>like:
>
>diff --git a/environment.c b/environment.c
>index 89d6c70..8edaedd 100644
>--- a/environment.c
>+++ b/environment.c
>@@ -200,7 +200,8 @@ void set_git_work_tree(const char *new_work_tree)
> return;
> }
> git_work_tree_initialized = 1;
>- work_tree = xstrdup(real_path(new_work_tree));
>+ if (*new_work_tree)
>+ work_tree = xstrdup(real_path(new_work_tree));
> }
>
> const char *get_git_work_tree(void)
>diff --git a/setup.c b/setup.c
>index e1cfa48..f0e1251 100644
>--- a/setup.c
>+++ b/setup.c
>@@ -544,7 +544,7 @@ static const char *setup_explicit_git_dir(const
>char *gitdirenv,
> worktree = get_git_work_tree();
>
> /* both get_git_work_tree() and cwd are already normalized */
>- if (!strcmp(cwd, worktree)) { /* cwd == worktree */
>+ if (!worktree || !strcmp(cwd, worktree)) { /* cwd == worktree */
> set_git_dir(gitdirenv);
> free(gitfile);
> return NULL;
>@@ -636,6 +636,8 @@ static const char *setup_bare_git_dir(char *cwd,
>int offset, int len, int *nongi
> }
> else
> set_git_dir(".");
>+
>+ setenv(GIT_WORK_TREE_ENVIRONMENT, "", 1);
> return NULL;
> }
>
>
>which passes your test. Unfortunately, this patch runs afoul of the
>same
>complaints that prevented the original from being acceptable (weirdness
>on Windows with empty environment variables).
>
>Having read the discussion again, I _think_ the more sane thing is to
>actually just have a new variable, $GIT_BARE, which overrides any
>core.bare config (just as $GIT_WORK_TREE override core.worktree). And
>then we set that explicitly when we are in a bare $GIT_DIR, propagating
>our auto-detection to sub-processes.
>
>-Peff
>--
>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
--
Pardon terseness, typo and HTML from a tablet.
^ permalink raw reply
* Re: [BUG] bare repository detection does not work with aliases
From: Jeff King @ 2013-03-08 6:37 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <94c531c1-57a0-4464-9f30-3c63f0c1a056@email.android.com>
On Thu, Mar 07, 2013 at 10:27:04PM -0800, Junio C Hamano wrote:
> The $GIT_BARE idea sounds very sensible to me.
Unfortunately, it is not quite as simple as that. I just wrote up the
patch, and it turns out that we are foiled by how core.bare is treated.
If it is true, the repo is definitely bare. If it is false, that is only
a hint for us.
So we cannot just look at is_bare_repository() after setup_git_directory
runs. Because we are not "definitely bare", only "maybe bare", it
returns false. We just happen not to have a work tree. We could do
something like:
if (is_bare_repository_cfg || !work_tree)
setenv("GIT_BARE", "1", 1);
which I think would work, but feels kind of wrong. We are bare in this
instance, but somebody setting GIT_WORK_TREE in a sub-process would
want to become unbare, presumably, but our variable would override them.
Just looking through all of the code paths, I am getting a little
nervous that I would not cover all the bases for such a $GIT_BARE to
work (e.g., doing GIT_BARE=0 would not do I would expect as a user,
because of the historical way we treat core.bare=false).
So rather than introduce something like $GIT_BARE which is going to
bring about all new kinds of corner cases, I think I'd rather just pass
along a $GIT_NO_IMPLICIT_WORK_TREE variable, which is much more direct
for solving this problem, and is less likely to end up having bugs of
its own.
-Peff
^ permalink raw reply
* Re: [PATCH 2/3] git p4 test: should honor symlink in p4 client root
From: Johannes Sixt @ 2013-03-08 6:42 UTC (permalink / raw)
To: Pete Wyckoff; +Cc: git, Miklós Fazekas, John Keeping
In-Reply-To: <1362698357-7334-3-git-send-email-pw@padd.com>
Am 3/8/2013 0:19, schrieb Pete Wyckoff:
> +# When the p4 client Root is a symlink, make sure chdir() does not use
> +# getcwd() to convert it to a physical path.
> +test_expect_failure 'p4 client root symlink should stay symbolic' '
> + physical="$TRASH_DIRECTORY/physical" &&
> + symbolic="$TRASH_DIRECTORY/symbolic" &&
> + test_when_finished "rm -rf \"$physical\"" &&
> + test_when_finished "rm \"$symbolic\"" &&
> + mkdir -p "$physical" &&
> + ln -s "$physical" "$symbolic" &&
This test needs a SYMLINKS prerequisite to future-proof it, in case the
Windows port gains p4 support some time.
> + test_when_finished cleanup_git &&
> + (
> + P4CLIENT=client-sym &&
> + p4 client -i <<-EOF &&
> + Client: $P4CLIENT
> + Description: $P4CLIENT
> + Root: $symbolic
> + LineEnd: unix
> + View: //depot/... //$P4CLIENT/...
> + EOF
> + git p4 clone --dest="$git" //depot &&
> + cd "$git" &&
> + test_commit file2 &&
> + git config git-p4.skipSubmitEdit true &&
> + git p4 submit
> + )
> +'
-- Hannes
^ 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