* Re: git blame and cherry-picking
From: Jeff King @ 2008-08-07 18:49 UTC (permalink / raw)
To: Steven Grimm; +Cc: Alex Riesen, git
In-Reply-To: <AA6BDC98-8800-4031-8C8F-A4BD326BEC1E@midwinter.com>
On Thu, Aug 07, 2008 at 11:37:02AM -0700, Steven Grimm wrote:
> No, of course not. But one might want to show the original commit's
> author instead of the name of the person who did the cherry pick. That's
> mostly what I'm looking for here; knowing where the change originally came
> from in terms of the revision graph is occasionally interesting but not
> nearly as important.
OK. I think that is a cherry-pick -n issue, then, as you mention below.
> One could argue that the real issue here is that while "git cherry-pick"
> preserves the original author and doesn't have the misattribution problem,
> "git cherry-pick -n" discards the original commit's attribution (though it
> does keep the commit message). Obviously git doesn't necessarily know
> whether the cherry-picker made substantial changes before committing and
> should truly be considered the author, but one of the use cases for the
> "-n" option is a simple "make sure you don't commit totally broken
> revisions" where there is little to no additional editing of the patch and
> keeping the original author would support that use case better.
I don't think it would be hard to stuff the cherry-picked commit's info
somewhere and to pull it out during git-commit. git-am and git-rebase -i
are already doing something similar. The harder question is what should
be done with multiple "git cherry-pick -n" invocations with different
authors?
I haven't looked closely at the git-sequencer stuff, but I wonder if
some of this will come with it for free. My impression is that the
prototype is built on _top_ of cherry-pick, but that the C version will
not be, and that cherry-pick can then be implemented in terms of the
sequencer.
-Peff
^ permalink raw reply
* [PATCH] Makefile: set SHELL to value of SHELL_PATH
From: Brandon Casey @ 2008-08-07 19:03 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Git Mailing List, Junio C Hamano
In-Reply-To: <alpine.DEB.1.00.0808060208450.9611@pacific.mpi-cbg.de.mpi-cbg.de>
Signed-off-by: Brandon Casey <casey@nrlssc.navy.mil>
---
Johannes Schindelin wrote:
> Hi,
>
> On Tue, 5 Aug 2008, Brandon Casey wrote:
>
>> Otherwise, should we set the SHELL variable to the configured SHELL_PATH
>> at some point in the Makefile?
>
> I think that would make more sense, especially since it would catch
> wrong SHELL_PATH early.
You're right, this makes more sense.
-brandon
Makefile | 2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/Makefile b/Makefile
index 52c67c1..61fc86d 100644
--- a/Makefile
+++ b/Makefile
@@ -1060,6 +1060,8 @@ export TAR INSTALL DESTDIR SHELL_PATH
### Build rules
+SHELL = $(SHELL_PATH)
+
all:: $(ALL_PROGRAMS) $(BUILT_INS) $(OTHER_PROGRAMS) GIT-BUILD-OPTIONS
ifneq (,$X)
$(foreach p,$(patsubst %$X,%,$(filter %$X,$(ALL_PROGRAMS) $(BUILT_INS) git$X)), $(RM) '$p';)
--
1.5.6.2
^ permalink raw reply related
* [PATCH] Makefile: add a target which will abort compilation with ancient shells
From: Brandon Casey @ 2008-08-07 19:06 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Git Mailing List, Junio C Hamano
In-Reply-To: <BUkcoxp99ASidQD8sGQ9PR7w1MT6DXx-6v_djYMHRBKTs_wNXEO3hw@cipher.nrlssc.navy.mil>
This adds a make target which can be used to try to execute certain shell
constructs which are required for compiling and running git.
This patch provides a test for the $() notation for command substition
which is used in the Makefile and extensively in the git scripts.
The make target is named in such a way as to be a hint to the user that
SHELL_PATH should be set to an appropriate shell. If the shell command
fails, the user should receive a message similar to the following:
make: *** [please_set_SHELL_PATH_to_a_more_modern_shell] Error 2
Signed-off-by: Brandon Casey <casey@nrlssc.navy.mil>
---
Johannes Schindelin wrote:
> Maybe we can even have some sanity check that tests if SHELL_PATH groks
> $()?
how about this?
-brandon
Makefile | 8 +++++++-
1 files changed, 7 insertions(+), 1 deletions(-)
diff --git a/Makefile b/Makefile
index 61fc86d..90c5a13 100644
--- a/Makefile
+++ b/Makefile
@@ -1062,7 +1062,7 @@ export TAR INSTALL DESTDIR SHELL_PATH
SHELL = $(SHELL_PATH)
-all:: $(ALL_PROGRAMS) $(BUILT_INS) $(OTHER_PROGRAMS) GIT-BUILD-OPTIONS
+all:: shell_compatibility_test $(ALL_PROGRAMS) $(BUILT_INS) $(OTHER_PROGRAMS) GIT-BUILD-OPTIONS
ifneq (,$X)
$(foreach p,$(patsubst %$X,%,$(filter %$X,$(ALL_PROGRAMS) $(BUILT_INS) git$X)), $(RM) '$p';)
endif
@@ -1075,6 +1075,11 @@ endif
$(QUIET_SUBDIR0)perl $(QUIET_SUBDIR1) PERL_PATH='$(PERL_PATH_SQ)' prefix='$(prefix_SQ)' all
$(QUIET_SUBDIR0)templates $(QUIET_SUBDIR1)
+please_set_SHELL_PATH_to_a_more_modern_shell:
+ @$$(:)
+
+shell_compatibility_test: please_set_SHELL_PATH_to_a_more_modern_shell
+
strip: $(PROGRAMS) git$X
$(STRIP) $(STRIP_OPTS) $(PROGRAMS) git$X
@@ -1457,6 +1462,7 @@ endif
$(RM) GIT-VERSION-FILE GIT-CFLAGS GIT-GUI-VARS GIT-BUILD-OPTIONS
.PHONY: all install clean strip
+.PHONY: shell_compatibility_test please_set_SHELL_PATH_to_a_more_modern_shell
.PHONY: .FORCE-GIT-VERSION-FILE TAGS tags cscope .FORCE-GIT-CFLAGS
.PHONY: .FORCE-GIT-BUILD-OPTIONS
--
1.5.6.2
^ permalink raw reply related
* Re: linearising TopGit forests into patch series (was: [ANNOUNCE] TopGit - A different patch queue manager)
From: Bert Wesarg @ 2008-08-07 19:58 UTC (permalink / raw)
To: martin f krafft; +Cc: Petr Baudis, git, vcs distro packaging discussion list
In-Reply-To: <20080807175623.GA16833@lapse.rw.madduck.net>
Hi,
On Thu, Aug 7, 2008 at 19:56, martin f krafft <madduck@debian.org> wrote:
> Hi Petr and everyone else,
>
> as some of you may know, I am working on http://vcs-pkg.org, and
> Pierre kindly alerted me to your announcement, which looks very
> interesting for what we are trying to do.
>
> Assuming a number of interdependent topic branches, does TopGit
> provide a way for me to linearise/flatten/serialise these branches
> in a one-patch-per-branch fashion, so that I could turn any TopGit
> repository into a quilt series? I am only interested in a one-way
> conversion from TopGit to quilt for now.
Should be doable, I think. At least you can get a topological sorted
list of the TopGit branches (with git show-branch --topo-order <list
of TopGit-branches>). But than it get complicated, because you don't
need the diff from branch-base to branch-head, this would only work
for a single dependent list of topic branches.
At least this is my current point of thinking for this problem.
Regards
Bert
> Thank you,
^ permalink raw reply
* GIT-VERSION-GEN gives "-dirty" when file metadata changed
From: Christian Jaeger @ 2008-08-07 19:35 UTC (permalink / raw)
To: git; +Cc: Gerrit Pape
Hello,
Today I've created custom Debian packages from Git for the first time (yes I know there are Debian packages already, I'm doing it so that I can patch Git and still have the convenience of a package system), using the 1.6.0.rc2 checkout, and using my normal procedure to build debian source packages (running "dpkg-buildpackage -uc -us -b -rfakeroot" as non-root user). The resulting binary reported for --version the string "1.6.0.rc2-dirty"; I wondered why, since I didn't have uncommitted changes neither in the working dir nor in the index. I found that the GIT-VERSION-GEN script would check for a clean working directory by checking that "git diff-index --name-only HEAD --" does not report any files, and since this is now running under the control of the fakeroot process, all files had owner
and group 0, whereas in reality (when I made the checkout) they had a non-root uid/gid. This made diff-index report all files, and hence give the "-dirty" version.
I'll followup this mail with two variants of a patch which runs "git update-index --refresh" before that check, which solves the issue. Patch A just does it always, patch B does it only if the metadata check failed; I've created the latter with the idea in mind that update-index might be too costly in some situation (here it's fast but I don't know about people without much RAM).
Perhaps not many people are building Git with the help of fakeroot, but I don't see why the patch would hurt either, and it seems to me like it's implementing the correct behaviour (metadata changes could also happen should anyone or some build process move or copy the files to another place before building, or similar). I don't know whether the Debian Git package maintainer had another solution, but maybe his packages are simply being built as root without the help of "fakeroot" (cc to him for information).
Christian.
^ permalink raw reply
* [PATCH A] GIT-VERSION-GEN: refresh the index before judging a working dir to be dirty
From: Christian Jaeger @ 2008-08-07 15:16 UTC (permalink / raw)
To: git
In-Reply-To: <sjj6zt28jy9qy7y8@jaeger.mine.nu>
When building under the control of the "fakeroot" tool [*], as is the
case when building a Debian package using "dpkg-buildpackage
-rfakeroot", GIT-VERSION-GEN appended "-dirty" to the version number;
this happens because "git diff-index --name-only HEAD --" would report
all files as changed if they have a non-root owner/group, since they
appear as owned by root under fakeroot, leading to non-empty
output. Refreshing the index first makes the decision based on content
changes only.
[*] http://fakeroot.alioth.debian.org/
Signed-off-by: Christian Jaeger <christian@jaeger.mine.nu>
---
GIT-VERSION-GEN | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/GIT-VERSION-GEN b/GIT-VERSION-GEN
index cb7cd4b..e6ff486 100755
--- a/GIT-VERSION-GEN
+++ b/GIT-VERSION-GEN
@@ -16,6 +16,7 @@ elif test -d .git -o -f .git &&
case "$VN" in
*$LF*) (exit 1) ;;
v[0-9]*)
+ git update-index --refresh
test -z "$(git diff-index --name-only HEAD --)" ||
VN="$VN-dirty" ;;
esac
--
1.6.0.rc2.1.g7e734
^ permalink raw reply related
* [PATCH B] GIT-VERSION-GEN: refresh the index before judging a working dir to be dirty
From: Christian Jaeger @ 2008-08-07 17:59 UTC (permalink / raw)
To: git
In-Reply-To: <sjj6zt28jy9qy7y8@jaeger.mine.nu>
When building under the control of the "fakeroot" tool [*], as is the
case when building a Debian package using "dpkg-buildpackage
-rfakeroot", GIT-VERSION-GEN appended "-dirty" to the version number;
this happens because "git diff-index --name-only HEAD --" would report
all files as changed if they have a non-root owner/group, since they
appear as owned by root under fakeroot, leading to non-empty
output. Refreshing the index first makes the decision based on content
changes only.
[*] http://fakeroot.alioth.debian.org/
Signed-off-by: Christian Jaeger <christian@jaeger.mine.nu>
---
GIT-VERSION-GEN | 6 ++++++
1 files changed, 6 insertions(+), 0 deletions(-)
diff --git a/GIT-VERSION-GEN b/GIT-VERSION-GEN
index cb7cd4b..fb3e2d8 100755
--- a/GIT-VERSION-GEN
+++ b/GIT-VERSION-GEN
@@ -17,6 +17,12 @@ elif test -d .git -o -f .git &&
*$LF*) (exit 1) ;;
v[0-9]*)
test -z "$(git diff-index --name-only HEAD --)" ||
+ {
+ # some metadata of files has changed; what
+ # about the contents?
+ git update-index --refresh
+ test -z "$(git diff-index --name-only HEAD --)"
+ } ||
VN="$VN-dirty" ;;
esac
then
--
1.6.0.rc2.1.g7e734
^ permalink raw reply related
* [TopGit PATCH] tg-create.sh: Support for multiple {to,cc,bcc} options
From: Bert Wesarg @ 2008-08-07 20:31 UTC (permalink / raw)
To: Petr Baudis; +Cc: Bert Wesarg, git
Git config supports multiple values for the same config key, so support it
for these TopGit config options, too.
Signed-off-by: Bert Wesarg <bert.wesarg@googlemail.com>
---
tg-create.sh | 17 ++++++++++++++---
1 files changed, 14 insertions(+), 3 deletions(-)
diff --git a/tg-create.sh b/tg-create.sh
index 6cce7ed..d47959b 100644
--- a/tg-create.sh
+++ b/tg-create.sh
@@ -100,13 +100,24 @@ git checkout -b "$name"
echo "$deps" | sed 's/ /\n/g' >"$root_dir/.topdeps"
git add "$root_dir/.topdeps"
+# Print each config value for a key ($1, without "topgit." prefix)
+# with the given prefix ($2)
+get_multi_config()
+{
+ # escape any / in prefix for sed
+ prefix="$(echo "$2" | sed -e 's/\//\\\\\//g')"
+
+ git config --get-all topgit.$1 2>/dev/null |
+ sed -e "s/^/$prefix /g"
+}
+
author="$(git var GIT_AUTHOR_IDENT)"
author_addr="${author%> *}>"
{
echo "From: $author_addr"
- ! header="$(git config topgit.to)" || echo "To: $header"
- ! header="$(git config topgit.cc)" || echo "Cc: $header"
- ! header="$(git config topgit.bcc)" || echo "Bcc: $header"
+ get_multi_config to "To:"
+ get_multi_config cc "Cc:"
+ get_multi_config bcc "Bcc:"
! subject_prefix="$(git config topgit.subjectprefix)" || subject_prefix="$subject_prefix "
echo "Subject: [${subject_prefix}PATCH] $name"
echo
--
tg: (e311d15..) t/support-for-multiple-to-cc-bcc-options (depends on: master)
^ permalink raw reply related
* On PPC64, the parsing of integers on the commandline is bitshifted.
From: Robin H. Johnson @ 2008-08-07 20:31 UTC (permalink / raw)
To: git, gitster
[-- Attachment #1: Type: text/plain, Size: 1070 bytes --]
In a 64-bit userland, big-endian environment, the parser gets integers
wrong.
# ./test-parse-options --set23 |grep integer
integer: 98784247808
# patch ...
# ./test-parse-options --set23 |grep integer
integer: 23
Full failures from the testcases
-integer: 1729
+integer: 7425998454784
-integer: 13
+integer: 55834574848
-integer: 2
+integer: 8589934592
-integer: 23
+integer: 98784247808
All the values are shifted up 32 bits.
Signed-off-by: Robin H. Johnson <robbat2@gentoo.org>
---
Please CC me in replies, I'm not on git@vger.
Fix against 1.5.6.4:
--- parse-options.c.orig 2008-08-07 14:51:17.000000000 -0500
+++ parse-options.c 2008-08-07 14:51:25.000000000 -0500
@@ -78,7 +78,7 @@
return 0;
case OPTION_SET_INT:
- *(int *)opt->value = unset ? 0 : opt->defval;
+ *(long int *)opt->value = unset ? 0 : opt->defval;
return 0;
case OPTION_SET_PTR:
--
Robin Hugh Johnson
Gentoo Linux Developer & Infra Guy
E-Mail : robbat2@gentoo.org
GnuPG FP : 11AC BA4F 4778 E3F6 E4ED F38E B27B 944E 3488 4E85
[-- Attachment #2: Type: application/pgp-signature, Size: 329 bytes --]
^ permalink raw reply
* Re: On PPC64, the parsing of integers on the commandline is bitshifted.
From: Brandon Casey @ 2008-08-07 21:26 UTC (permalink / raw)
To: Robin H. Johnson; +Cc: git, gitster
In-Reply-To: <20080807203122.GR22707@curie-int.orbis-terrarum.net>
Robin H. Johnson wrote:
> In a 64-bit userland, big-endian environment, the parser gets integers
> wrong.
There is a fix on master. Can you try that out?
Unfortunately, looks like it did not make it into 1.5.6.5
-brandon
^ permalink raw reply
* Re: On PPC64, the parsing of integers on the commandline is bitshifted.
From: Brandon Casey @ 2008-08-07 21:34 UTC (permalink / raw)
To: Robin H. Johnson; +Cc: git, gitster
In-Reply-To: <X68iwLodMeAo1RYVJdU3iyNzAFylpDRpP1jkviJTeiOnoNs5n2qZcg@cipher.nrlssc.navy.mil>
Brandon Casey wrote:
> Robin H. Johnson wrote:
>> In a 64-bit userland, big-endian environment, the parser gets integers
>> wrong.
>
> There is a fix on master. Can you try that out?
> Unfortunately, looks like it did not make it into 1.5.6.5
Also, just so you know, it is test-parse-options.c that is broken, not
the parsing code. So, the rest of git should be using an int with
OPT_INTEGER() and should operate correctly.
-brandon
^ permalink raw reply
* Re: On PPC64, the parsing of integers on the commandline is bitshifted.
From: Junio C Hamano @ 2008-08-07 21:42 UTC (permalink / raw)
To: Brandon Casey; +Cc: Robin H. Johnson, git, gitster
In-Reply-To: <CxVxAoKmEQsrgFdHEvL0sjkgBBIVZ3Zvsl0pPSuDSfH_8xM8NOSGfw@cipher.nrlssc.navy.mil>
Brandon Casey <casey@nrlssc.navy.mil> writes:
> Brandon Casey wrote:
>> Robin H. Johnson wrote:
>>> In a 64-bit userland, big-endian environment, the parser gets integers
>>> wrong.
>>
>> There is a fix on master. Can you try that out?
>> Unfortunately, looks like it did not make it into 1.5.6.5
>
> Also, just so you know, it is test-parse-options.c that is broken, not
> the parsing code. So, the rest of git should be using an int with
> OPT_INTEGER() and should operate correctly.
Yup, that is why it is not on 'maint' --- but somebody should audit the
parse_options() users in the real programs to make sure that there is no
similar breakages, namely, giving a pointer to long to OPT_INTEGER().
^ permalink raw reply
* Re: GIT-VERSION-GEN gives "-dirty" when file metadata changed
From: Junio C Hamano @ 2008-08-07 21:48 UTC (permalink / raw)
To: Christian Jaeger; +Cc: git, Gerrit Pape
In-Reply-To: <sjj6zt28jy9qy7y8@jaeger.mine.nu>
Christian Jaeger <christian@jaeger.mine.nu> writes:
> Today I've created custom Debian packages from Git for the first time (yes I know there are Debian packages already, I'm doing it so that I can patch Git and still have the convenience of a package system),
I personally think that _you_ are responsible for doing the refresh
yourself after becoming root, if you checkout as yourself and then build
as root (or use fakeroot to build as if it is built as root).
By the way "man fakeroot" says...
-u, --unknown-is-real
Use the real ownership of files previously unknown to fakeroot
instead of pretending they are owned by root:root.
which sounds like a sensible thing to do (I would even imagine that would
be a sensible default for fakeroot in general), and I would imagine that
would help.
Not that an extra update-index --refresh would be a huge performance hit,
but I hesitate to take a patch that adds something that should
conceptually be unnecessary.
^ permalink raw reply
* [RFH/PATCH] asciidoc markup fixes
From: Junio C Hamano @ 2008-08-07 23:05 UTC (permalink / raw)
To: git
I see quite a few pages on k.org site, e.g.
http://www.kernel.org/pub/software/scm/git/docs/git-rerere.html
(scroll down to find "After this test merge")
are misformatted to lose teletype text '+' that is followed by a comma,
and turns the following paragraph all typeset in teletype.
This patch seems to fix the issue at the site (meaning, with the
particular vintage of asciidoc and docbook toolchain), without breaking
things with the version I have at my primary development machine, but
wider testing is very much appreciated.
After this patch,
git grep '`+`,' -- Documentation
should report noting.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
diff --git a/Documentation/git-push.txt b/Documentation/git-push.txt
index 050c3dd..89c0c3f 100644
--- a/Documentation/git-push.txt
+++ b/Documentation/git-push.txt
@@ -32,7 +32,7 @@ OPTIONS
<refspec>...::
The canonical format of each <refspec> parameter is
- `+?<src>:<dst>`; that is, an optional plus `+`, followed
+ `+?<src>:<dst>`; that is, an optional plus `{plus}`, followed
by the source ref, followed by a colon `:`, followed by
the destination ref.
+
diff --git a/Documentation/git-rerere.txt b/Documentation/git-rerere.txt
index 89f321b..64715c1 100644
--- a/Documentation/git-rerere.txt
+++ b/Documentation/git-rerere.txt
@@ -90,15 +90,15 @@ One way to do it is to pull master into the topic branch:
The commits marked with `*` touch the same area in the same
file; you need to resolve the conflicts when creating the commit
-marked with `+`. Then you can test the result to make sure your
+marked with `{plus}`. Then you can test the result to make sure your
work-in-progress still works with what is in the latest master.
After this test merge, there are two ways to continue your work
on the topic. The easiest is to build on top of the test merge
-commit `+`, and when your work in the topic branch is finally
+commit `{plus}`, and when your work in the topic branch is finally
ready, pull the topic branch into master, and/or ask the
upstream to pull from you. By that time, however, the master or
-the upstream might have been advanced since the test merge `+`,
+the upstream might have been advanced since the test merge `{plus}`,
in which case the final commit graph would look like this:
------------
diff --git a/Documentation/pull-fetch-param.txt b/Documentation/pull-fetch-param.txt
index 00a8d21..ebdd948 100644
--- a/Documentation/pull-fetch-param.txt
+++ b/Documentation/pull-fetch-param.txt
@@ -6,7 +6,7 @@
<refspec>::
The canonical format of a <refspec> parameter is
- `+?<src>:<dst>`; that is, an optional plus `+`, followed
+ `+?<src>:<dst>`; that is, an optional plus `{plus}`, followed
by the source ref, followed by a colon `:`, followed by
the destination ref.
+
^ permalink raw reply related
* Re: git filter-branch --subdirectory-filter, still a mistery
From: Thomas Rast @ 2008-08-07 23:48 UTC (permalink / raw)
To: Jan Wielemaker; +Cc: git
In-Reply-To: <200808071214.25399.J.Wielemaker@uva.nl>
[-- Attachment #1: Type: text/plain, Size: 1734 bytes --]
Jan Wielemaker wrote:
> Ref 'refs/tags/V5.6.50' was rewritten
> error: Ref refs/tags/V5.6.50 is at 8678b32f71178019c06aefa40e2d3fb9a2e8ef25
> but
> expected 2e8aef64e2fed088720a19ac2ffa2481e5bc7806
> fatal: Cannot lock the ref 'refs/tags/V5.6.50'.
> Could not rewrite refs/tags/V5.6.50
[...]
> Now, if I look in .git/packed-refs [...] and I changed all these to
> `lightweight' tags
This appears to be a bug. I've whipped up a patch that will follow
and should fix the bug. It has nothing to do with packed-refs; the
current filter-branch chokes on annotated tags during
--subdirectory-filter, even though there is support for tag rewriting.
However, to enable tag rewriting, you need to say --tag-name-filter
cat.
> Now it runs to the end. Unfortunagtely the history is completely
> screwed up :-(:
>
> * There are a lot of commits that are not related to the dir
> * Commits start long before the directory came into existence,
> Looks like it just shows the whole project at this place.
For some reason the ancestor detection does not work right. I'm also
following up with an RFH patch that significantly improves the success
rate (in terms of branches and tags successfully mapped to a rewritten
commit) in the case of your repository. I doubt more staring at the
code would yield any more ideas at this hour, so ideas would be
appreciated.
The rest is just the other commits/tags showing a lot of the history.
I don't know of any built-in way to prune the branches and tags that
aren't part of the new master, but
git branch -a --no-merged master
can tell you which branches aren't ancestors of master.
- Thomas
--
Thomas Rast
trast@student.ethz.ch
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* [PATCH] filter-branch: be more helpful when an annotated tag changes
From: Thomas Rast @ 2008-08-07 23:50 UTC (permalink / raw)
To: git; +Cc: Jan Wielemaker, gitster
In-Reply-To: <200808080148.27384.trast@student.ethz.ch>
Previously, git-filter-branch failed if it attempted to update an
annotated tag. Now we ignore this condition if --tag-name-filter is
given, so that we can later rewrite the tag. If no such option was
provided, we warn the user that he might want to run with
--tag-name-filter cat to achieve the intended effect.
Signed-off-by: Thomas Rast <trast@student.ethz.ch>
---
git-filter-branch.sh | 14 +++++++++++---
1 files changed, 11 insertions(+), 3 deletions(-)
diff --git a/git-filter-branch.sh b/git-filter-branch.sh
index 182822a..a324cf0 100755
--- a/git-filter-branch.sh
+++ b/git-filter-branch.sh
@@ -361,9 +361,17 @@ do
;;
$_x40)
echo "Ref '$ref' was rewritten"
- git update-ref -m "filter-branch: rewrite" \
- "$ref" $rewritten $sha1 ||
- die "Could not rewrite $ref"
+ if ! git update-ref -m "filter-branch: rewrite" \
+ "$ref" $rewritten $sha1 2>/dev/null; then
+ if test $(git cat-file -t "$ref") = tag; then
+ if test -z "$filter_tag_name"; then
+ warn "WARNING: You said to rewrite tagged commits, but not the corresponding tag."
+ warn "WARNING: Perhaps use '--tag-name-filter cat' to rewrite the tag."
+ fi
+ else
+ die "Could not rewrite $ref"
+ fi
+ fi
;;
*)
# NEEDSWORK: possibly add -Werror, making this an error
--
1.6.0.rc2.19.g3c9ba
^ permalink raw reply related
* [RFH] filter-branch: ancestor detection weirdness
From: Thomas Rast @ 2008-08-07 23:54 UTC (permalink / raw)
To: git; +Cc: Jan Wielemaker
In-Reply-To: <200808080148.27384.trast@student.ethz.ch>
THIS WILL VERY LIKELY NOT WORK IN ALL CASES.
Use git rev-list -1 -- <subdir> to discover a random ancestor, instead
of more correct boundary detection. Oddly enough, this _increases_
success rate with Jan's repository and --all. May break randomly with
more complicated args.
---
Maybe someone understands what's going on and can fix the underlying
bug...
git-filter-branch.sh | 12 +++---------
1 files changed, 3 insertions(+), 9 deletions(-)
diff --git a/git-filter-branch.sh b/git-filter-branch.sh
index 182822a..52b2bdf 100755
--- a/git-filter-branch.sh
+++ b/git-filter-branch.sh
@@ -325,15 +325,9 @@ while read ref
do
sha1=$(git rev-parse "$ref"^0)
test -f "$workdir"/../map/$sha1 && continue
- # Assign the boundarie(s) in the set of rewritten commits
- # as the replacement commit(s).
- # (This would look a bit nicer if --not --stdin worked.)
- for p in $( (cd "$workdir"/../map; ls | sed "s/^/^/") |
- git rev-list $ref --boundary --stdin |
- sed -n "s/^-//p")
- do
- map $p >> "$workdir"/../map/$sha1
- done
+ # Assign the first commit not pruned as the replacement.
+ candidate=$(git rev-list $ref -1 -- "$filter_subdir")
+ test "$candidate" && map "$candidate" > "$workdir"/../map/$sha1
done < "$tempdir"/heads
# Finally update the refs
--
1.6.0.rc2.19.g3c9ba
^ permalink raw reply related
* Re: [RFH/PATCH] asciidoc markup fixes
From: Gustaf Hendeby @ 2008-08-07 23:26 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v8wv8ifyi.fsf@gitster.siamese.dyndns.org>
[-- Attachment #1: Type: text/plain, Size: 288 bytes --]
Junio C Hamano wrote:
> After this patch,
>
> git grep '`+`,' -- Documentation
>
> should report noting.
>
> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Passes the test with ascidoc 8.2.7, xmlto 0.0.21, DocBooks-utils 0.6.14.
Tested-by: Gustaf Hendeby <hendeby@isy.liu.se>
[-- Attachment #2: hendeby.vcf --]
[-- Type: text/x-vcard, Size: 405 bytes --]
begin:vcard
fn:Gustaf Hendeby
n:Hendeby;Gustaf
org;quoted-printable:Link=C3=B6pings universitet;Department of Electrical Enginering
adr;quoted-printable;quoted-printable:;;;Link=C3=B6ping;;SE-581 83=0D=0A=
;Sweden
email;internet:hendeby@isy.liu.se
title:PhD Student
tel;work:+46 14 28 22 26
tel;cell:+46 730 64 64 89
x-mozilla-html:FALSE
url:http://www.control.isy.liu.se/~hendeby
version:2.1
end:vcard
^ permalink raw reply
* 1.6.0.rc2: Duplicated refs when using git clone --mirror
From: Cesar Eduardo Barros @ 2008-08-08 0:59 UTC (permalink / raw)
To: git
cesarb@delta:/tmp$ PATH=~/opt/git/bin:$PATH git --version
git version 1.6.0.rc2
cesarb@delta:/tmp$ PATH=~/opt/git/bin:$PATH git clone --mirror
git://git.kernel.org/pub/scm/git/git.git
Initialized empty Git repository in /tmp/git.git/
remote: Counting objects: 80828, done.
remote: Compressing objects: 100% (21488/21488), done.
remote: Total 80828 (delta 58880), reused 79522 (delta 57902)
Receiving objects: 100% (80828/80828), 16.84 MiB | 97 KiB/s, done.
Resolving deltas: 100% (58880/58880), done.
cesarb@delta:/tmp$ cd git.git/
cesarb@delta:/tmp/git.git$ PATH=~/opt/git/bin:$PATH git fetch
warning: Duplicated ref: refs/tags/gitgui-0.10.0
warning: Duplicated ref: refs/tags/gitgui-0.10.1
warning: Duplicated ref: refs/tags/gitgui-0.10.2
warning: Duplicated ref: refs/tags/gitgui-0.6.0
warning: Duplicated ref: refs/tags/gitgui-0.6.1
warning: Duplicated ref: refs/tags/gitgui-0.6.2
warning: Duplicated ref: refs/tags/gitgui-0.6.3
warning: Duplicated ref: refs/tags/gitgui-0.6.4
warning: Duplicated ref: refs/tags/gitgui-0.6.5
warning: Duplicated ref: refs/tags/gitgui-0.7.0
warning: Duplicated ref: refs/tags/gitgui-0.7.0-rc1
warning: Duplicated ref: refs/tags/gitgui-0.7.1
warning: Duplicated ref: refs/tags/gitgui-0.7.2
warning: Duplicated ref: refs/tags/gitgui-0.7.3
warning: Duplicated ref: refs/tags/gitgui-0.7.4
warning: Duplicated ref: refs/tags/gitgui-0.7.5
warning: Duplicated ref: refs/tags/gitgui-0.8.0
warning: Duplicated ref: refs/tags/gitgui-0.8.1
warning: Duplicated ref: refs/tags/gitgui-0.8.2
warning: Duplicated ref: refs/tags/gitgui-0.8.3
warning: Duplicated ref: refs/tags/gitgui-0.8.4
warning: Duplicated ref: refs/tags/gitgui-0.9.0
warning: Duplicated ref: refs/tags/gitgui-0.9.1
warning: Duplicated ref: refs/tags/gitgui-0.9.2
warning: Duplicated ref: refs/tags/gitgui-0.9.3
warning: Duplicated ref: refs/tags/junio-gpg-pub
warning: Duplicated ref: refs/tags/v0.99
warning: Duplicated ref: refs/tags/v0.99.9h
warning: Duplicated ref: refs/tags/v0.99.9i
warning: Duplicated ref: refs/tags/v0.99.9j
warning: Duplicated ref: refs/tags/v0.99.9k
warning: Duplicated ref: refs/tags/v0.99.9l
warning: Duplicated ref: refs/tags/v0.99.9m
warning: Duplicated ref: refs/tags/v0.99.9n
warning: Duplicated ref: refs/tags/v1.0.0
warning: Duplicated ref: refs/tags/v1.0.0a
warning: Duplicated ref: refs/tags/v1.0.0b
warning: Duplicated ref: refs/tags/v1.0.10
warning: Duplicated ref: refs/tags/v1.0.11
warning: Duplicated ref: refs/tags/v1.0.12
warning: Duplicated ref: refs/tags/v1.0.13
warning: Duplicated ref: refs/tags/v1.0.3
warning: Duplicated ref: refs/tags/v1.0.4
warning: Duplicated ref: refs/tags/v1.0.5
warning: Duplicated ref: refs/tags/v1.0.6
warning: Duplicated ref: refs/tags/v1.0.7
warning: Duplicated ref: refs/tags/v1.0.8
warning: Duplicated ref: refs/tags/v1.0.9
warning: Duplicated ref: refs/tags/v1.0rc1
warning: Duplicated ref: refs/tags/v1.0rc2
warning: Duplicated ref: refs/tags/v1.0rc3
warning: Duplicated ref: refs/tags/v1.0rc4
warning: Duplicated ref: refs/tags/v1.0rc5
warning: Duplicated ref: refs/tags/v1.0rc6
warning: Duplicated ref: refs/tags/v1.1.0
warning: Duplicated ref: refs/tags/v1.1.1
warning: Duplicated ref: refs/tags/v1.1.2
warning: Duplicated ref: refs/tags/v1.1.3
warning: Duplicated ref: refs/tags/v1.1.4
warning: Duplicated ref: refs/tags/v1.1.5
warning: Duplicated ref: refs/tags/v1.1.6
warning: Duplicated ref: refs/tags/v1.2.0
warning: Duplicated ref: refs/tags/v1.2.1
warning: Duplicated ref: refs/tags/v1.2.2
warning: Duplicated ref: refs/tags/v1.2.3
warning: Duplicated ref: refs/tags/v1.2.4
warning: Duplicated ref: refs/tags/v1.2.5
warning: Duplicated ref: refs/tags/v1.2.6
warning: Duplicated ref: refs/tags/v1.3.0
warning: Duplicated ref: refs/tags/v1.3.0-rc1
warning: Duplicated ref: refs/tags/v1.3.0-rc2
warning: Duplicated ref: refs/tags/v1.3.0-rc3
warning: Duplicated ref: refs/tags/v1.3.0-rc4
warning: Duplicated ref: refs/tags/v1.3.1
warning: Duplicated ref: refs/tags/v1.3.2
warning: Duplicated ref: refs/tags/v1.3.3
warning: Duplicated ref: refs/tags/v1.4.0
warning: Duplicated ref: refs/tags/v1.4.0-rc1
warning: Duplicated ref: refs/tags/v1.4.0-rc2
warning: Duplicated ref: refs/tags/v1.4.1
warning: Duplicated ref: refs/tags/v1.4.1-rc1
warning: Duplicated ref: refs/tags/v1.4.1-rc2
warning: Duplicated ref: refs/tags/v1.4.1.1
warning: Duplicated ref: refs/tags/v1.4.2
warning: Duplicated ref: refs/tags/v1.4.2-rc1
warning: Duplicated ref: refs/tags/v1.4.2-rc2
warning: Duplicated ref: refs/tags/v1.4.2-rc3
warning: Duplicated ref: refs/tags/v1.4.2-rc4
warning: Duplicated ref: refs/tags/v1.4.2.1
warning: Duplicated ref: refs/tags/v1.4.2.2
warning: Duplicated ref: refs/tags/v1.4.2.3
warning: Duplicated ref: refs/tags/v1.4.2.4
warning: Duplicated ref: refs/tags/v1.4.3
warning: Duplicated ref: refs/tags/v1.4.3-rc1
warning: Duplicated ref: refs/tags/v1.4.3-rc2
warning: Duplicated ref: refs/tags/v1.4.3-rc3
warning: Duplicated ref: refs/tags/v1.4.3.1
warning: Duplicated ref: refs/tags/v1.4.3.2
warning: Duplicated ref: refs/tags/v1.4.3.3
warning: Duplicated ref: refs/tags/v1.4.3.4
warning: Duplicated ref: refs/tags/v1.4.3.5
warning: Duplicated ref: refs/tags/v1.4.4
warning: Duplicated ref: refs/tags/v1.4.4-rc1
warning: Duplicated ref: refs/tags/v1.4.4-rc2
warning: Duplicated ref: refs/tags/v1.4.4.1
warning: Duplicated ref: refs/tags/v1.4.4.2
warning: Duplicated ref: refs/tags/v1.4.4.3
warning: Duplicated ref: refs/tags/v1.4.4.4
warning: Duplicated ref: refs/tags/v1.4.4.5
warning: Duplicated ref: refs/tags/v1.5.0
warning: Duplicated ref: refs/tags/v1.5.0-rc0
warning: Duplicated ref: refs/tags/v1.5.0-rc1
warning: Duplicated ref: refs/tags/v1.5.0-rc2
warning: Duplicated ref: refs/tags/v1.5.0-rc3
warning: Duplicated ref: refs/tags/v1.5.0-rc4
warning: Duplicated ref: refs/tags/v1.5.0.1
warning: Duplicated ref: refs/tags/v1.5.0.2
warning: Duplicated ref: refs/tags/v1.5.0.3
warning: Duplicated ref: refs/tags/v1.5.0.4
warning: Duplicated ref: refs/tags/v1.5.0.5
warning: Duplicated ref: refs/tags/v1.5.0.6
warning: Duplicated ref: refs/tags/v1.5.0.7
warning: Duplicated ref: refs/tags/v1.5.1
warning: Duplicated ref: refs/tags/v1.5.1-rc1
warning: Duplicated ref: refs/tags/v1.5.1-rc2
warning: Duplicated ref: refs/tags/v1.5.1-rc3
warning: Duplicated ref: refs/tags/v1.5.1.1
warning: Duplicated ref: refs/tags/v1.5.1.2
warning: Duplicated ref: refs/tags/v1.5.1.3
warning: Duplicated ref: refs/tags/v1.5.1.4
warning: Duplicated ref: refs/tags/v1.5.1.5
warning: Duplicated ref: refs/tags/v1.5.1.6
warning: Duplicated ref: refs/tags/v1.5.2
warning: Duplicated ref: refs/tags/v1.5.2-rc0
warning: Duplicated ref: refs/tags/v1.5.2-rc1
warning: Duplicated ref: refs/tags/v1.5.2-rc2
warning: Duplicated ref: refs/tags/v1.5.2-rc3
warning: Duplicated ref: refs/tags/v1.5.2.1
warning: Duplicated ref: refs/tags/v1.5.2.2
warning: Duplicated ref: refs/tags/v1.5.2.3
warning: Duplicated ref: refs/tags/v1.5.2.4
warning: Duplicated ref: refs/tags/v1.5.2.5
warning: Duplicated ref: refs/tags/v1.5.3
warning: Duplicated ref: refs/tags/v1.5.3-rc0
warning: Duplicated ref: refs/tags/v1.5.3-rc1
warning: Duplicated ref: refs/tags/v1.5.3-rc2
warning: Duplicated ref: refs/tags/v1.5.3-rc3
warning: Duplicated ref: refs/tags/v1.5.3-rc4
warning: Duplicated ref: refs/tags/v1.5.3-rc5
warning: Duplicated ref: refs/tags/v1.5.3-rc6
warning: Duplicated ref: refs/tags/v1.5.3-rc7
warning: Duplicated ref: refs/tags/v1.5.3.1
warning: Duplicated ref: refs/tags/v1.5.3.2
warning: Duplicated ref: refs/tags/v1.5.3.3
warning: Duplicated ref: refs/tags/v1.5.3.4
warning: Duplicated ref: refs/tags/v1.5.3.5
warning: Duplicated ref: refs/tags/v1.5.3.6
warning: Duplicated ref: refs/tags/v1.5.3.7
warning: Duplicated ref: refs/tags/v1.5.3.8
warning: Duplicated ref: refs/tags/v1.5.4
warning: Duplicated ref: refs/tags/v1.5.4-rc0
warning: Duplicated ref: refs/tags/v1.5.4-rc1
warning: Duplicated ref: refs/tags/v1.5.4-rc2
warning: Duplicated ref: refs/tags/v1.5.4-rc3
warning: Duplicated ref: refs/tags/v1.5.4-rc4
warning: Duplicated ref: refs/tags/v1.5.4-rc5
warning: Duplicated ref: refs/tags/v1.5.4.1
warning: Duplicated ref: refs/tags/v1.5.4.2
warning: Duplicated ref: refs/tags/v1.5.4.3
warning: Duplicated ref: refs/tags/v1.5.4.4
warning: Duplicated ref: refs/tags/v1.5.4.5
warning: Duplicated ref: refs/tags/v1.5.4.6
warning: Duplicated ref: refs/tags/v1.5.5
warning: Duplicated ref: refs/tags/v1.5.5-rc0
warning: Duplicated ref: refs/tags/v1.5.5-rc1
warning: Duplicated ref: refs/tags/v1.5.5-rc2
warning: Duplicated ref: refs/tags/v1.5.5-rc3
warning: Duplicated ref: refs/tags/v1.5.5.1
warning: Duplicated ref: refs/tags/v1.5.5.2
warning: Duplicated ref: refs/tags/v1.5.5.3
warning: Duplicated ref: refs/tags/v1.5.5.4
warning: Duplicated ref: refs/tags/v1.5.5.5
warning: Duplicated ref: refs/tags/v1.5.6
warning: Duplicated ref: refs/tags/v1.5.6-rc0
warning: Duplicated ref: refs/tags/v1.5.6-rc1
warning: Duplicated ref: refs/tags/v1.5.6-rc2
warning: Duplicated ref: refs/tags/v1.5.6-rc3
warning: Duplicated ref: refs/tags/v1.5.6.1
warning: Duplicated ref: refs/tags/v1.5.6.2
warning: Duplicated ref: refs/tags/v1.5.6.3
warning: Duplicated ref: refs/tags/v1.5.6.4
warning: Duplicated ref: refs/tags/v1.5.6.5
warning: Duplicated ref: refs/tags/v1.6.0-rc0
warning: Duplicated ref: refs/tags/v1.6.0-rc1
warning: Duplicated ref: refs/tags/v1.6.0-rc2
warning: Duplicated ref: refs/tags/v0.99.9g
cesarb@delta:/tmp/git.git$
There is no file in refs/; the contents of packed-refs are like:
# pack-refs with: peeled
b7d75e49508ac928677f5cb83f490cf40a7c83d3 refs/tags/v1.6.0-rc2
^1fdf6ee6f81b31b299a8039832f45290faa4583a
ad6137f51f5f67e2558849629332c7443ed01108 refs/tags/v1.6.0-rc1
^8e1db3871c767cb17b5e0eeb7bea8d967821a055
4be80e6b423b9ceffab50e120855806712ab3255 refs/tags/v1.6.0-rc0
^93310a40eb022a0e36e7c618921931d8ffc31fd1
07cca3b30ee2b5d060e44e5b18d7c22929c63d1a refs/tags/v1.5.6.5
^781c1834f5419bdf81bb7f3750170ccd6b809174
[...]
33682a5e98adfd8ba4ce0e21363c443bd273eb77 refs/tags/gitgui-0.10.1
^729ffa50f75a025935623bfc58d0932c65f7de2f
d5aef6e4d58cfe1549adef5b436f3ace984e8c86 refs/tags/gitgui-0.10.0
^3d654be48f65545c4d3e35f5d3bbed5489820930
b7d75e49508ac928677f5cb83f490cf40a7c83d3 refs/tags/v1.6.0-rc2
^1fdf6ee6f81b31b299a8039832f45290faa4583a
ad6137f51f5f67e2558849629332c7443ed01108 refs/tags/v1.6.0-rc1
^8e1db3871c767cb17b5e0eeb7bea8d967821a055
4be80e6b423b9ceffab50e120855806712ab3255 refs/tags/v1.6.0-rc0
^93310a40eb022a0e36e7c618921931d8ffc31fd1
07cca3b30ee2b5d060e44e5b18d7c22929c63d1a refs/tags/v1.5.6.5
^781c1834f5419bdf81bb7f3750170ccd6b809174
[...]
33682a5e98adfd8ba4ce0e21363c443bd273eb77 refs/tags/gitgui-0.10.1
^729ffa50f75a025935623bfc58d0932c65f7de2f
d5aef6e4d58cfe1549adef5b436f3ace984e8c86 refs/tags/gitgui-0.10.0
^3d654be48f65545c4d3e35f5d3bbed5489820930
19a1e065c865db403a41af97b2e9e81f1d01dd9e refs/heads/todo
0e60d74cc02f6a0af58a1f99e54509dafc7c8f6a refs/heads/pu
9c632062aee88de890e8b30d8763f83abe1da113 refs/heads/next
1fdf6ee6f81b31b299a8039832f45290faa4583a refs/heads/master
99ad2efc3f7764a1c21e464412af95a8ffe3b5d6 refs/heads/man
781c1834f5419bdf81bb7f3750170ccd6b809174 refs/heads/maint
b53db3ca58a8a65d8de3b9fa048d410757edc38f refs/heads/html
--
Cesar Eduardo Barros
cesarb@cesarb.net
cesar.barros@gmail.com
^ permalink raw reply
* Re: git reset --hard isn't resetting
From: Matt Graham @ 2008-08-08 1:06 UTC (permalink / raw)
To: Avery Pennarun; +Cc: git
In-Reply-To: <32541b130808061102q752076a8ydc02fef4e799491f@mail.gmail.com>
On Wed, Aug 6, 2008 at 2:02 PM, Avery Pennarun <apenwarr@gmail.com> wrote:
> On 8/6/08, Matt Graham <mdg149@gmail.com> wrote:
>> I'm using a git svn tree in Cygwin. I tried doing an svn rebase and
>> got in some weird state with local changes I can't get rid of. It's
>> not an issue w/ the same repository on my linux machine.
>>
>> git reset --hard
>> toggles 4 files between capitalization. The files don't appear to
>> have changed case in svn, but it's a huge repository and not easy to
>> determine with certainty.
>
> Try:
> git log --name-only
> to see which patches change which files. It's a virtual certainty
> that they were renamed in svn at some point.
They weren't "renamed". Further investigation w/ the hated svn tools
showed that the upper case was removed, then many commits later, the
lowercase was added.
> git doesn't handle case-munging filesystems perfectly, and gets into
> the situation you describe. First, you need to figure out whether you
> have files with *both* cases accidentally added to your index (if git
> reset toggles the capitalization, this is almost certainly the case):
>
> git ls-tree HEAD
>
> If you see the same files with different case, that's your problem.
Indeed that was the problem. In fact, l now noticed that my linux
machine has both versions as well. Being case sensitive, it didn't
mind and the problem wasn't obvious.
> Now just 'git rm' the ones with the case you don't want, and commit
> the result. (Do *not* use commit -a!) 'git status' will give you
> some funny messages indicating that files you *didn't* 'git rm' have
> gone away in the filesystem; it's true, of course, but don't worry
> about that. Now 'git reset --hard HEAD' and you should be okay.
This worked fine exactly as you said. I'm curious what will happen when I do
git svn dcommit
These aren't my files and I'm sort of using git svn on the sly. I'd
prefer to not have something weird happen to the svn repository due to
this. Due to the schedule, our tolerance for screwing things up b/c I
want to use git will be low. And my argument that we should have used
git from the outset probably won't help any.
> I'm not really sure what git should do better in this case, although
> the current behaviour is obviously a bit confusing.
Yes, if SVN is going to have both versions, it's understandable that
git wouldn't know what to do. Unfortunately, it looks like SVN only
had one version at a time. So it seems git somehow revived the
uppercase version when the lowercase one was readded through git svn.
This happened on both the cygwin and linux versions, although it only
caused an obvious problem on the cygwin version. I don't know git
well enough to speculate why this happened, but it looks like it's a
real bug that shouldn't have happened in this case.
On cygwin I'm using 1.5.5.1 and the repository only used that version.
On linux, I currently have 1.6.0.rc0.79.gb0320 but the repo may have
been originally cloned w/ earlier versions.
^ permalink raw reply
* GSoC final last meters
From: Johannes Schindelin @ 2008-08-08 1:24 UTC (permalink / raw)
To: git
Cc: Sam Vilain, Joshua Roys, Sverre Rabbelier, David Symonds,
Lea Wiemann, John Hawley, Marek Zawirski, Shawn O. Pearce,
Miklos Vajna, Stephan Beyer, Christian Couder, Daniel Barkalow
Dear GSoC students, dear mentors, dear Git list,
we have all gathered here to participate in the last sprint of the Google
Summer of Code. A lot has happened during all that time. The Git
community has seen "fresh meat", and there may have been a few being
reminded of their first or second steps in Open Source looking back with a
bit of envy.
We saw some of you students prosper from the hands-on discussions with a
few of the brightest minds that Open Source has to offer.
We have seen good work, we have seen excellent work, but also work that
does not fall into these categories, and also work that was not done.
As you might know, the week between the 11th of August and the 18th of
same month is the week when the mentors have to give their evaluations
about their students' work. The mentors are not allowed to base their
evaluations on anything that might come after the deadline, but only on
work completed by that time.
Now, dear students: it is not necessary to have all your work merged into
git.git yet; indeed, the 1.6.0 release cycle is on, and you can hope at
most for 'next', but not 'master'.
However, in order to hope for a good evaluation, it is necessary to have
at least something that comes _close_ to being mergeable.
Dear mentors, now I come to you. Please make sure that you work with your
students during those last days of the project, and help them reach their
goal.
And when it comes to the evaluations, be honest: Google is extremely
generous to provide us with funding for our students, but the students
have to earn it. Every dollar that is spent undeservedly will be a dollar
that is not given to other, more worthy Open Source activities.
To all of you who are neither GSoC students nor GSoC mentors: please help
by reviewing and encouraging.
With those thoughts in mind, I wish us all a fun and frantic last days of
the GSoC project, and I look forward to see you all even after the Summer
has ended.
Ciao,
Dscho
^ permalink raw reply
* [PATCH] clone --mirror: avoid storing repeated tags
From: Johannes Schindelin @ 2008-08-08 2:29 UTC (permalink / raw)
To: Cesar Eduardo Barros; +Cc: git
In-Reply-To: <489B9A8B.9050807@cesarb.net>
With --mirror, clone asks for refs/* already, so it does not need to
ask for ref/tags/*, too.
Noticed by Cesar Eduardo Barros.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---
builtin-clone.c | 3 ++-
t/t5601-clone.sh | 12 ++++++++++++
2 files changed, 14 insertions(+), 1 deletions(-)
diff --git a/builtin-clone.c b/builtin-clone.c
index 8612d59..c0e3086 100644
--- a/builtin-clone.c
+++ b/builtin-clone.c
@@ -330,7 +330,8 @@ static struct ref *write_remote_refs(const struct ref *refs,
struct ref *r;
get_fetch_map(refs, refspec, &tail, 0);
- get_fetch_map(refs, tag_refspec, &tail, 0);
+ if (!option_mirror)
+ get_fetch_map(refs, tag_refspec, &tail, 0);
for (r = local_refs; r; r = r->next)
add_extra_ref(r->peer_ref->name, r->old_sha1, 0);
diff --git a/t/t5601-clone.sh b/t/t5601-clone.sh
index a13b6f9..59c65fe 100755
--- a/t/t5601-clone.sh
+++ b/t/t5601-clone.sh
@@ -95,4 +95,16 @@ test_expect_success 'clone --bare names the local repository <name>.git' '
'
+test_expect_success 'clone --mirror does not repeat tags' '
+
+ (cd src &&
+ git tag some-tag HEAD) &&
+ git clone --mirror src mirror2 &&
+ (cd mirror2 &&
+ git show-ref 2> clone.err > clone.out) &&
+ test_must_fail grep Duplicate mirror2/clone.err &&
+ grep some-tag mirror2/clone.out
+
+'
+
test_done
--
1.6.0.rc1.112.gebbe4
^ permalink raw reply related
* Re: [PATCH] clone --mirror: avoid storing repeated tags
From: Junio C Hamano @ 2008-08-08 4:57 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Cesar Eduardo Barros, git
In-Reply-To: <alpine.DEB.1.00.0808080428520.9611@pacific.mpi-cbg.de.mpi-cbg.de>
Thanks for reporting and a quick fix.
This made me wonder if this relatively new "pack cloned refs" codepath has
funny interaction with --reference which is another user of add_extra_refs(),
but I think it is safe (we clear the real "extra" ones used during the
object transfer before calling write_remote_refs()).
^ permalink raw reply
* Re: [RFH/PATCH] asciidoc markup fixes
From: Junio C Hamano @ 2008-08-08 5:41 UTC (permalink / raw)
To: Gustaf Hendeby; +Cc: git
In-Reply-To: <489B84A9.2090900@isy.liu.se>
Thanks.
^ permalink raw reply
* [PATCH 0/3] Enable parallelized tests
From: Johannes Schindelin @ 2008-08-08 5:59 UTC (permalink / raw)
To: git, gitster
This patch pair enables parallel tests. On a pretty beefy machine,
$ /usr/bin/time make -j50
shows this:
69.33user 92.33system 0:59.26elapsed 272%CPU (0avgtext+0avgdata
0maxresident)k 0inputs+0outputs (0major+33007360minor)pagefaults 0swaps
vs.
$ /usr/bin/time make
showing this:
61.25user 75.10system 3:57.68elapsed 57%CPU (0avgtext+0avgdata
0maxresident)k 0inputs+0outputs (0major+32897071minor)pagefaults 0swaps
Note: the machine was used for other tasks during the test, too.
These results are with SVN/CVS tests enabled. I am pretty sure that the
results would be even more impressive without them (the SVN/CVS tests come
all at the end, and seem to idle the CPU mostly, and the last few seconds
are only spent on 2 tests).
Johannes Schindelin (3):
t9700: remove useless check
tests: Clarify dependencies between tests, 'aggregate-results' and
'clean'
Enable parallel tests
t/Makefile | 15 ++++++++++++---
t/t9700/test.pl | 3 ---
t/test-lib.sh | 11 ++++++++++-
3 files changed, 22 insertions(+), 7 deletions(-)
^ 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