* "git add sub1/ sub2/" doesn't work as expected when sub1 and sub2 has .git under them
From: Ping Yin @ 2009-01-12 8:36 UTC (permalink / raw)
To: Git Mailing List
Assume directories sub1 and sub2 have .git under them. "git add sub1/"
works as expected (files under sub1/ are added), howerver "git add
sub1/ sub2/" doesn't work as expeced (sub1 and sub2 are added as
submoudle).
$ git --version git version 1.6.0.4.617.g2baf1
# create repo super
$ mkdir super && cd super && git init && git commit --allow-empty -m
"Initial commit"
# create repo super/sub1 with file sub1-file
$ mkdir sub1 && cd sub1 && touch sub1-file
$ git init && git add . && git commit -m "Initial commit" && cd ..
# create repo super/sub2 with file sub2-file
$ mkdir sub2 && cd sub2 && touch sub2-file
$ git init && git add . && git commit -m "Initial commit" && cd ..
# to intend to add files under sub1 and sub2, but submodules are added
$ git add sub1/ sub2/
$ git status
# On branch master
# Changes to be committed:
# (use "git reset HEAD <file>..." to unstage)
#
# new file: sub1
# new file: sub2
#
$ git rm --cached sub1 sub2
# to intend add files under sub1, ok
$ gtad sub1/
$ git status
# On branch master
# Changes to be committed:
# (use "git reset HEAD <file>..." to unstage)
#
# new file: sub1/sub1-file
#
# Untracked files:
# (use "git add <file>..." to include in what will be committed)
#
# sub2/
Ping Yin
^ permalink raw reply
* Re: [RFC PATCH 2/3] Add specification of git-vcs helpers
From: Johannes Sixt @ 2009-01-12 8:13 UTC (permalink / raw)
To: Daniel Barkalow; +Cc: git, Junio C Hamano
In-Reply-To: <alpine.LNX.1.00.0901110334350.19665@iabervon.org>
Daniel Barkalow schrieb:
> +NAME
> +----
> +git-vcs-* - Helper programs for interoperation with foreign systems
> +
> +SYNOPSIS
> +--------
> +'git vcs-<system>' <command> [options] [arguments]
The current rule is that helper programs have double-dash in the name:
git-rebase--interactive, git-web--browse, etc.
-- Hannes
^ permalink raw reply
* Re: Minimum required version of subversion for git-svn?
From: Tom G. Christensen @ 2009-01-12 8:03 UTC (permalink / raw)
To: Eric Wong; +Cc: git@vger.kernel.org
In-Reply-To: <20090112010354.GB23377@yp-box.dyndns.org>
Eric Wong wrote:
> "Tom G. Christensen" <tgc@statsbiblioteket.dk> wrote:
>> Hello,
>>
>> With git 1.6.0.5 I was able to run git-svn with subversion 1.1.4 on
>> RHEL4/i386 but with 1.6.0.6 and 1.6.1 the testsuite now fails in the new
>> test t9104.10:
>
> ...
>
>> With 1.6.1 I also see t9129.10-12 failing with subversion 1.1.4:
>> * FAIL 10: ISO-8859-1 should match UTF-8 in svn
>
> ...
>
>> * failed 3 among 12 test(s)
>> make[2]: Leaving directory `/builddir/build/BUILD/git-1.6.1/t'
>> make[2]: *** [t9129-git-svn-i18n-commitencoding.sh] Error 1
>>
>> I see in git-svn.perl that only SVN::Core 1.1.0 is required. Is it still
>> the intention that git-svn should work with subversion 1.1.x?
>>
>> If you're going to bump the minimum requirement I would ask that you
>> atleast keep 1.3.x as supported. This is the last release of subversion
>> where RHEL3 can satisfy the dependencies out of the box and I've
>> verified that the testsuite will pass with 1.3.2.
>
> It's still my intention that SVN 1.1.x is supported; but I haven't had
> the chance to test those versions in a while.
>
> Can you rerun the tests that failed with "sh -x t91..." ?
>
I've run the tests from 1.6.1 with -v, sh -x and sh -x + -v and dumped
the results at http://jupiterrise.com/tmp
You'll find results from one more test (t9106) which I didn't mention
and which is also giving me problems but only with rhel4/x86_64 and svn
1.1.4. It should be noted that this test has never worked for me with
this config.
-tgc
^ permalink raw reply
* Re: Recent annoying problem with Linus's git repository?
From: Marco Roeland @ 2009-01-12 7:59 UTC (permalink / raw)
To: walt; +Cc: git, rmk
In-Reply-To: <alpine.LNX.2.00.0901111615500.4963@x9.ybpnyarg>
On Sunday January 11th 2009 at 16:42 walt wrote:
> I've been tracking Junio's git.git and Linus's kernel.git for ages,
> and just in the last two weeks or so I've been having a recurring
> problem with the file "arch/arm/mach-integrator/clock.h" from Linus.
>
> Any time I check out an old kernel version (e.g. during a bisect)
> and then do a "checkout master" when I'm done fiddling, git thinks
> my repository is "dirty".
>
> This is the reason for my impurity:
>
> # git status
> # On branch master
> # Changed but not updated:
> # (use "git add/rm <file>..." to update what will be committed)
> # (use "git checkout -- <file>..." to discard changes in working directory)
> #
> # deleted: arch/arm/mach-integrator/clock.h
>
> It's always that same damned clock.h that remains in my working
> directory after doing the "checkout master" but it shouldn't be
> there -- it has indeed been deleted from branch master.
>
> When I then do a "git reset --hard" I Am Purified! and no longer
> considered dirty. But why should that extra reset step be needed?
>
> Only that one file is involved in this recurring annoyance. Can
> anyone figure out why, or at least reproduce the problem?
It is because commit d72fbdf01fc77628c0b837d0dd2fd564fa26ede6 "[ARM]
integrator: convert to clkdev and lookup clocks by device name" didn't
really _delete_ file arch/arm/mach-integrator/clock.h but only made it
empty. So the file still exists in the repository, but with size 0.
Cleanup scripts within the kernel build environment however always
consider empty files leftover products from the build and so delete
them.
That's why you get this result, after cleaning up.
The file should probably just be really deleted. Adding Russell to the
Cc. ;-)
At the moment (git describe gives v2.6.29-rc1-1-gae04d14) this is the
only "empty" file in the kernel repository. We've had these cases
before.
--
Marco Roeland
^ permalink raw reply
* [PATCH] git-am: add --directory=<dir> option
From: Junio C Hamano @ 2009-01-12 6:33 UTC (permalink / raw)
To: git; +Cc: Simon 'corecode' Schubert, Kevin Ballard
Thanks to a200337 (git-am: propagate -C<n>, -p<n> options as well,
2008-12-04) and commits around it, "git am" is equipped to correctly
propagate the command line flags such as -C/-p/-whitespace across a patch
failure and restart.
It is trivial to support --directory option now, resurrecting previous
attempts by Kevin and Simon.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
"What's cooking" has listed kb/am-directory in "Stalled" category for too
long a time and I dropped it entirely. This resurrects the feature.
git-am.sh | 17 +++++++++++++----
t/t4252-am-options.sh | 8 ++++++++
2 files changed, 21 insertions(+), 4 deletions(-)
diff --git c/git-am.sh w/git-am.sh
index 4b157fe..7e6329b 100755
--- c/git-am.sh
+++ w/git-am.sh
@@ -16,6 +16,7 @@ s,signoff add a Signed-off-by line to the commit message
u,utf8 recode into utf8 (default)
k,keep pass -k flag to git-mailinfo
whitespace= pass it through git-apply
+directory= pass it through git-apply
C= pass it through git-apply
p= pass it through git-apply
resolvemsg= override error message when patch failure occurs
@@ -33,6 +34,14 @@ cd_to_toplevel
git var GIT_COMMITTER_IDENT >/dev/null ||
die "You need to set your committer info first"
+sq () {
+ for sqarg
+ do
+ printf "%s" "$sqarg" |
+ sed -e 's/'\''/'\''\'\'''\''/g' -e 's/.*/ '\''&'\''/'
+ done
+}
+
stop_here () {
echo "$1" >"$dotest/next"
exit 1
@@ -155,10 +164,10 @@ do
;;
--resolvemsg)
shift; resolvemsg=$1 ;;
- --whitespace)
- git_apply_opt="$git_apply_opt $1=$2"; shift ;;
+ --whitespace|--directory)
+ git_apply_opt="$git_apply_opt $(sq "$1=$2")"; shift ;;
-C|-p)
- git_apply_opt="$git_apply_opt $1$2"; shift ;;
+ git_apply_opt="$git_apply_opt $(sq "$1$2")"; shift ;;
--)
shift; break ;;
*)
@@ -459,7 +468,7 @@ do
case "$resolved" in
'')
- git apply $git_apply_opt --index "$dotest/patch"
+ eval 'git apply '"$git_apply_opt"' --index "$dotest/patch"'
apply_status=$?
;;
t)
diff --git c/t/t4252-am-options.sh w/t/t4252-am-options.sh
index 3ab9e8e..e91a6da 100755
--- c/t/t4252-am-options.sh
+++ w/t/t4252-am-options.sh
@@ -50,4 +50,12 @@ test_expect_success 'interrupted am -C1 -p2' '
grep "^Three$" file-2
'
+test_expect_success 'interrupted am --directory="frotz nitfol"' '
+ rm -rf .git/rebase-apply &&
+ git reset --hard initial &&
+ test_must_fail git am --directory="frotz nitfol" "$tm"/am-test-5-? &&
+ git am --skip &&
+ grep One "frotz nitfol/file-5"
+'
+
test_done
^ permalink raw reply related
* Re: [RFC PATCH 4/3] Add example git-vcs-p4
From: Junio C Hamano @ 2009-01-12 6:29 UTC (permalink / raw)
To: Daniel Barkalow; +Cc: git
In-Reply-To: <alpine.LNX.1.00.0901120026290.19665@iabervon.org>
Daniel Barkalow <barkalow@iabervon.org> writes:
>> vcs-p4.c:504: warning: ISO C90 forbids mixed declarations and code
>> make: *** [vcs-p4.o] Error 1
>
> I haven't been over the 4/3 stuff for coding style yet. But how do you get
> these warnings?
I thought I have mentioned this already, but...
I compile with (at least) these:
-Wno-pointer-to-int-cast
-Wold-style-definition
-Wdeclaration-after-statement
explicitly specified.
I also run kernel's checkpatch.pl script (but ignoring "more than 80-col
is too long" rule) from time to time.
I consider these are good ways to check style-discipline.
^ permalink raw reply
* Re: [PATCH 0/4] refactor the --color-words to make it more hackable
From: Thomas Rast @ 2009-01-12 6:25 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <alpine.DEB.1.00.0901112351050.3586@pacific.mpi-cbg.de>
[-- Attachment #1: Type: text/plain, Size: 1530 bytes --]
Johannes Schindelin wrote:
> On Sun, 11 Jan 2009, Thomas Rast wrote:
> > However, the final result segfaults and/or prints garbage (on
> > apparently every commit except very small changes) when using the regex
> > '\S+', which IMHO should give exactly the same result as not using a
> > regex at all.
>
> No, it should not. The correct regex is '^\S+'.
>
> As it happens, your regex matches _anything_ + non-whitespace.
It definitely doesn't(*).
Given ' word rest', '^\S+' would not match at all, and '\S+' would
match 'word'. No space there. However, at a cursory glance your
patch seems to ignore the rm_so member of match[0], so it'll never
know the difference.
While it might arguably make sense to enforce that only isspace()
characters are whitespace and !isspace() is at least part of _some_
(possibly one-character) word, I do not think it is a good idea to
require the anchoring of the user. If we need it, we must anchor the
match ourselves.
> Unfortunately, this includes a newline which utterly confuses the
> diff,
I do agree that matching a newline as part of a word is bad because we
need it for its diff separator semantics. Consider passing
REG_NEWLINE to regcomp() to reduce the risk of matching newlines via
things like [^\[:space:]].
(*) Well, modulo Junio's objection in the other thread that \S is
actually a PCRE extension. Substitute [^[:space:]] if your local
flavour doesn't understand it.
--
Thomas Rast
trast@{inf,student}.ethz.ch
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: [RFC PATCH 3/3] Support fetching from foreign VCSes
From: Daniel Barkalow @ 2009-01-12 5:48 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vfxjpmhow.fsf@gitster.siamese.dyndns.org>
On Sun, 11 Jan 2009, Junio C Hamano wrote:
> Daniel Barkalow <barkalow@iabervon.org> writes:
>
> > This supports a useful subset of the usual fetch logic, mostly in the
> > config file.
> >
> > Signed-off-by: Daniel Barkalow <barkalow@iabervon.org>
>
> I like the direction this series is going. In the longer term, it would
> be nice if we can have git-svn and git-cvsimport replaced with something
> like this.
That was my goal, although the only foreign system I currently use is
Perforce.
> Is the current foreign vcs interface sufficiently rich to support git as a
> foreign scm by using fast-import and fast-export?
I think so, although it would be pretty strange, since it would generally
have a whole lot of local data (a complete clone of any remote
repository).
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* Re: [RFC PATCH 4/3] Add example git-vcs-p4
From: Daniel Barkalow @ 2009-01-12 5:41 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vy6xhl1i7.fsf@gitster.siamese.dyndns.org>
On Sun, 11 Jan 2009, Junio C Hamano wrote:
> Hmm...
>
> CC vcs-p4.o
> cc1: warnings being treated as errors
> vcs-p4.c: In function 'output_data':
> vcs-p4.c:253: warning: format '%d' expects type 'int', but argument 2 has type 'size_t'
> vcs-p4.c: In function 'p4_where':
> vcs-p4.c:291: warning: ISO C90 forbids mixed declarations and code
> vcs-p4.c: In function 'p4_submit':
> vcs-p4.c:363: warning: ISO C90 forbids mixed declarations and code
> vcs-p4.c: In function 'p4_print':
> vcs-p4.c:433: warning: format '%d' expects type 'int', but argument 2 has type 'size_t'
> vcs-p4.c: In function 'p4_change':
> vcs-p4.c:453: warning: ISO C90 forbids mixed declarations and code
> vcs-p4.c: In function 'p4_filelog':
> vcs-p4.c:504: warning: ISO C90 forbids mixed declarations and code
> make: *** [vcs-p4.o] Error 1
I haven't been over the 4/3 stuff for coding style yet. But how do you get
these warnings? My gcc 4.1.2 doesn't seem to want to complain about
non-C90 usage except in strict C90 mode, where it gets more upset about
"inline" all over the place.
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* Re: [PATCH] git-svn: add --authors-file test
From: Junio C Hamano @ 2009-01-12 5:40 UTC (permalink / raw)
To: Eric Wong; +Cc: git
In-Reply-To: <20090111234406.GA22763@yp-box.dyndns.org>
Eric Wong <normalperson@yhbt.net> writes:
> I'm not sure how often this functionality is used, but in case
> it's not, having an extra test here will help catch breakage
> sooner.
>
> Signed-off-by: Eric Wong <normalperson@yhbt.net>
> ---
>
> This was posted over a year ago and forgotten about. Updated and
> cleaned up a bit to work with the new test suite.
Thanks.
^ permalink raw reply
* Re: [PATCH] Cleanup of unused symcache variable inside diff-lib.c
From: Junio C Hamano @ 2009-01-12 5:39 UTC (permalink / raw)
To: Kjetil Barvik; +Cc: git
In-Reply-To: <1231699002-5316-1-git-send-email-barvik@broadpark.no>
Kjetil Barvik <barvik@broadpark.no> writes:
> diff --git a/diff-lib.c b/diff-lib.c
> index ae96c64ca209f4df9008198e8a04b160bed618c7..e6d1d2b34147a13aadb5019e0c8336ef5f56ee39 100644
> --- a/diff-lib.c
> +++ b/diff-lib.c
> ...
> @@ -344,8 +334,7 @@ static void do_oneway_diff(struct unpack_trees_options *o,
> struct cache_entry *idx,
> struct cache_entry *tree)
> {
> - struct oneway_unpack_data *cbdata = o->unpack_data;
> - struct rev_info *revs = cbdata->revs;
> + struct rev_info *revs = o->unpack_data;;
Thanks; I'll clean-up the extra semicolon and apply.
^ permalink raw reply
* Re: git-svn: File was not found in commit
From: Eric Wong @ 2009-01-12 5:14 UTC (permalink / raw)
To: Morgan Christiansson; +Cc: git
In-Reply-To: <20090112023211.GA21462@dcvr.yhbt.net>
Eric Wong <normalperson@yhbt.net> wrote:
> Morgan Christiansson <git@mog.se> wrote:
> > The "Ignoring path" message appears to be coming from git which is
> > refusing to commit the .git directory. Which leads to git-svn being
> > unaware of the files being ignored and giving an error when it can't
> > find them.
>
> > I'm personally fine with these files being ignored by git, but git-svn
> > needs to be aware that they are not added to the repository.
>
> Hi Morgan,
> Can you try the following rough patch and see it it fixes things
> for you? Thanks!
Actually, I think this patch is broken (my quickly put together test
case was insufficient)...
> From 559f4b673592f364e9773f2ba65caf09b138521b Mon Sep 17 00:00:00 2001
> From: Eric Wong <normalperson@yhbt.net>
> Date: Sun, 11 Jan 2009 18:23:38 -0800
> Subject: [PATCH/RFC] git-svn: avoid importing nested repos
>
> Some SVN repositories contain .git repositories within them
> (hopefully accidentally checked in). Since git refuses to
> check in ".git" repositories, this can be a problem when
> fetching updates from SVN.
>
> This seems to repull the entire blob from SVN everytime a user
> changes something inside the ".git" directory on the SVN side,
> but hopefully this will be a rare case and the SVN users will
> correct the error quickly.
>
> The test could probably be expanded to be more thorough...
>
> Signed-off-by: Eric Wong <normalperson@yhbt.net>
^ permalink raw reply
* Re: current git kernel has strange problems during bisect
From: Christian Couder @ 2009-01-12 5:03 UTC (permalink / raw)
To: Christian Borntraeger
Cc: Pierre Habouzit, Alexey Zaytsev, Sam Ravnborg, Linus Torvalds,
Johannes Schindelin, git, Linux Kernel Mailing List
In-Reply-To: <200901120551.56791.chriscool@tuxfamily.org>
I wrote:
>
> Anyway it looks to me that this kind of problem could be avoided if one
> could "replace" some commits only when bisecting. In this case what could
> be done is that one could "replace" the commit where btrfs is merged with
> one commit that cuts off the btrfs history.
By the way, it possible right now to cut off the btrfs history in one's own
repository using a graft. One don't need to wait for me to finish the
replace stuff I am slowly working on. But on the other hand it will have
all the restrictions of the current graft mechanism.
Regards,
Christian.
^ permalink raw reply
* Re: current git kernel has strange problems during bisect
From: Christian Couder @ 2009-01-12 4:51 UTC (permalink / raw)
To: Pierre Habouzit
Cc: Alexey Zaytsev, Sam Ravnborg, Linus Torvalds,
Christian Borntraeger, Johannes Schindelin, git,
Linux Kernel Mailing List
In-Reply-To: <20090111230240.GA27489@artemis.corp>
Le lundi 12 janvier 2009, Pierre Habouzit a écrit :
> On Sun, Jan 11, 2009 at 07:47:18PM +0000, Alexey Zaytsev wrote:
> > On Sun, Jan 11, 2009 at 22:42, Sam Ravnborg <sam@ravnborg.org> wrote:
> > >> For bisect, it's indeed somewhat annoying, and we could have perhaps
> > >> done some things a bit differently, but it's about the closest you
> > >> can get to "real history" without making the first btrfs merge-point
> > >> a _total_ disaster.
> > >>
> > >> For bisect purposes, if you know you're not chasing down a btrfs
> > >> issue, you can do
> > >>
> > >> git bisect good 34353029534a08e41cfb8be647d734b9ce9ebff8
> > >>
> > >> where that commit 34353029 is the last one which has _just_ the
> > >> btrfs files. The next commit is when it does "Merge Btrfs into
> > >> fs/btrfs", and that one has the whole kernel tree again.
> > >
> > > The cost of moving this piece of history from one git tree to another
> > > git tree is that we make it harder to debug the kernel for the
> > > advanced user that knows how to do bisect.
> >
> > And wasn't is trivial to avoid? Just exporting the commits as
> > patches and importing them into the kernel tree would preserve
> > the history, and not break bisection.
>
> And would have brought a whole history of totally irrelevant stuff that
> never exited for real, with probably a lot of non-compiling sub-steps
> which would be even worse.
>
> No, the two possible choices were to squash the whole stuff at once, or
> do what has been done IMNSHO. People have to grok how to take shortcuts
> with git-bisect. I know that git-bisect puts people on the brainless
> course of actions where they git-bisect; configure; compile; boot; test;
> mark as good/bad and retry. And that's what I sometimes don't like with
> it. Because people trust git-bisect too much and forget how to think
> right.
Well "git bisect" can be more usefull if it can be fully automated (with git
bisect run) because then you can make the computer do all the boring work.
So I think putting people on the "brainless course of actions" can often be
a good thing.
Anyway it looks to me that this kind of problem could be avoided if one
could "replace" some commits only when bisecting. In this case what could
be done is that one could "replace" the commit where btrfs is merged with
one commit that cuts off the btrfs history. If the merge commit is only
replaced when bisecting, then you get the best of both worlds:
_ when you bisect, you don't see the btrfs history that breaks the kernel
build,
_ when you don't bisect, you see the full real history.
Of course if the bisection process finds out that the "replaced" commit is
the culprit, then you need to understand what this means...
Regards,
Christian.
^ permalink raw reply
* Re: [PATCH/RFC v6 1/3] lstat_cache(): more cache effective symlink/directory detection
From: Junio C Hamano @ 2009-01-12 4:05 UTC (permalink / raw)
To: Kjetil Barvik; +Cc: git, René Scharfe, Linus Torvalds
In-Reply-To: <1231680542-17315-2-git-send-email-barvik@broadpark.no>
Kjetil Barvik <barvik@broadpark.no> writes:
> -static inline void set_pathname(int len, const char *name, struct pathname *match)
> +static inline void reset_lstat_cache(void)
> {
> - if (len < PATH_MAX) {
> - match->len = len;
> - memcpy(match->path, name, len);
> - match->path[len] = 0;
> - }
> + cache.path[0] = '\0';
> + cache.len = 0;
> + cache.flags = 0;
> }
I see you made this internal to the caching code, but I suspect in the
long run there needs to be a way for callers that use the caching
mechanism to check and then create new paths in the work tree to
invalidate the cached code (namely, builtin-apply.c::write_out_results()
and entry.c::checkout_entry() codepaths).
I'll queue this round to 'pu' anyway, though.
Thanks.
^ permalink raw reply
* Re: What's cooking in git.git (Jan 2009, #02; Sun, 11)
From: Junio C Hamano @ 2009-01-12 4:03 UTC (permalink / raw)
To: Marcel Koeppen; +Cc: git
In-Reply-To: <A40F4753-A81B-43FD-B1A5-B28B627F8BBD@marzelpan.de>
Marcel Koeppen <lists@marzelpan.de> writes:
> Hi,
>
> Am 11.01.2009 um 10:51 schrieb Junio C Hamano:
>
>> ----------------------------------------------------------------
>> [Will merge to "master" soon]
>
>> * mc/cd-p-pwd (Tue Dec 30 07:10:24 2008 -0800) 1 commit
>> + git-sh-setup: Fix scripts whose PWD is a symlink to a work-dir on
>> OS X
>
> I think this belongs into maint - without it the testsuite fails on OSX.
One step at a time.
I did fork the topic at v1.6.1 so that after it proves itself in next and
then in master it can go to maint.
^ permalink raw reply
* Re: [PATCH] Documentation/git-push.txt: minor: compress one option
From: Junio C Hamano @ 2009-01-12 3:59 UTC (permalink / raw)
To: jidanni; +Cc: git
In-Reply-To: <1231729554-10513-1-git-send-email-jidanni@jidanni.org>
Thanks, queued.
This unfortunately missed tonight's integration window and won't appear
until I start next round of integration tomorrow evening.
^ permalink raw reply
* "git diff --stat" doesn't show added empty file
From: Ping Yin @ 2009-01-12 3:36 UTC (permalink / raw)
To: Git Mailing List
$ git --version
git version 1.6.1.9.g97c34
$ mkdir test && cd test && git init && git commit --allow-empty -m
"Initial commit"
$ touch .gitignore && git add .gitignore && git commit -m "Add empty .gitignore"
$ git diff --stat HEAD^..
0 files changed, 0 insertions(+), 0 deletions(-)
May be the following is better?
.gitignore | 0 +
1 files changed, 0 insertions(+), 0 deletions(-)
Ping Yin
^ permalink raw reply
* Re: [RFC/PATCH 1/3] tree.c: add support for traversal of submodules
From: Junio C Hamano @ 2009-01-12 3:15 UTC (permalink / raw)
To: Lars Hjemli; +Cc: git
In-Reply-To: <1231717555-10559-2-git-send-email-hjemli@gmail.com>
Lars Hjemli <hjemli@gmail.com> writes:
> If the commit referenced by a gitlink is available in the (possibly
> alternate) object database, read_tree_recursive() is now able to descend
> into the tree of the linked commit if the flag 'traverse_gitlinks' is
> turned on.
>
> Signed-off-by: Lars Hjemli <hjemli@gmail.com>
> ---
> tree.c | 20 +++++++++++++++++---
> tree.h | 1 +
> 2 files changed, 18 insertions(+), 3 deletions(-)
>
> diff --git a/tree.c b/tree.c
> index 03e782a..1468e10 100644
> --- a/tree.c
> +++ b/tree.c
> @@ -7,6 +7,7 @@
> #include "tree-walk.h"
>
> const char *tree_type = "tree";
> +int traverse_gitlinks = 0;
I think we tend to put these global settings that will affect everybody in
environment.c. You do not have to initialize variable to zero; BSS will
take care of it.
When the user explicitly asks you to traverse into submodules and the
necessary commit is not available in a submodule, the code goes on without
complaining. I am not saying it is bad, but I wonder if we would want to
distinguish these three cases:
(1) the submodule is initialized and the necessary commit is there.
(2) the submodule is initialized, but the necessary commit is missing.
(3) the submodule is not even initialized (aka "the user is not
interested in it"); there is only an empty directory.
I think it is perfectly fine not to say anything for (3) but I am unsure
about the second case.
^ permalink raw reply
* [PATCH] Documentation/git-push.txt: minor: compress one option
From: jidanni @ 2009-01-12 3:05 UTC (permalink / raw)
To: git; +Cc: gitster
Signed-off-by: jidanni <jidanni@jidanni.org>
---
Documentation/git-push.txt | 4 +---
1 files changed, 1 insertions(+), 3 deletions(-)
diff --git a/Documentation/git-push.txt b/Documentation/git-push.txt
index 6150b1b..3321966 100644
--- a/Documentation/git-push.txt
+++ b/Documentation/git-push.txt
@@ -86,14 +86,12 @@ nor in any Push line of the corresponding remotes file---see below).
line.
--receive-pack=<git-receive-pack>::
+--exec=<git-receive-pack>::
Path to the 'git-receive-pack' program on the remote
end. Sometimes useful when pushing to a remote
repository over ssh, and you do not have the program in
a directory on the default $PATH.
---exec=<git-receive-pack>::
- Same as \--receive-pack=<git-receive-pack>.
-
-f::
--force::
Usually, the command refuses to update a remote ref that is
--
1.6.0.6
^ permalink raw reply related
* Re: [BUG/RFH] gitweb: Trouble with ref markers being hyperlinks because of illegally nested links
From: Giuseppe Bilotta @ 2009-01-12 2:59 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <200901120215.13668.jnareb@gmail.com>
On Sun, Jan 11, 2009 at 8:15 PM, Jakub Narebski <jnareb@gmail.com> wrote:
> Commit 4afbaef by Giuseppe Bilotta (gitweb: ref markers link to named
> shortlogs) turned ref markers for tags and heads into links to
> appropriate views for the ref name.
>
> Unfortunately the code didn't take into account the fact that nesting
> links (A elements) is illegal in (X)HTML:
>
> 12.2.2 Nested links are illegal
>
> Links and anchors defined by the A element must not be nested;
> an A element must not contain any other A elements.
>
> (from http://www.w3.org/TR/html401/struct/links.html#h-12.2.2), and that
> some browsers (e.g. Mozilla 1.17.2 I still use) in the very strict
> conformance mode (application/xhtml+xml mimetype and XML + XHTML DTD)
> _enforce_ this requirement by moving inner link immediately outside the
> end of outer link, i.e. for the HTML source looking like the following
> <a ...> some text <a ...>v1.5.1</a></a>
> rendered HTML (which you can see using "View Selection Source") is
> instead
> <a ...> some text </a><a ...>v1.5.1</a>
> And of course SPAN elements which wraps inner link (inner A element) is
> _not_ moved.
>
>
> This is quite easy to fix for hyperlinked ref markers in 'shortlog' and
> 'history' views: just close the "title" hyperlink before printing
> $extra, i.e. ref markers. I have even made a patch doing that. Then
> instead of incorrect
> _Merge branch into maint_ [] _maint_
> where _aaa_ means that 'aaa' is hyperlink, and [xxx] is a fer marker,
> we will have correct:
> _Merge branch into maint_ [_maint_]
> See that we have two separate and not nested links...
I've seen from the list that you already have patches ready to fix at
least this problem. I think we might start from having these patches
in while we think of the best way to fix the biggest issue:
> What is more complicated is the issue of ref marker from
> git_print_header_div e.g. in 'commit'/'commitdiff' view, and in 'log'
> view. There link is made into block element using "display: block;"
> CSS rule (div.title, a.title), so that you can click _anywhere_ on the
> header block. This breaks layout even worse, making hyperlinked ref
> marker text appear *below* header div:
>
> -----------------------------------------------------------
> |_Merge branch into maint_ [] |
> -----------------------------------------------------------
> _maint_
>
> To preserve current layout and behavior it would be needed to do some
> deep HTML + CSS positioning hackery, perhaps with additional link block
> without any text... But I don't know exactly how to do this; all [few]
> experiments I did failed.
>
> I see possible the following alternate solutions:
> * Ignore this issue (e.g. if it does not affect modern browsers)
That would be my current choice until we find a better solution.
> * Revert 4afbaef (we lose feature, but how often used is it?)
> * Always use quirks mode, or check browser and use quirks mode if it
> would break layout
> * Use extra divs and links and CSS positioning to make layout which
> looks like current one, and behaves as current one, but is more
> complicated.
I'm asking on #html, hopefully I'll get some interesting idea to try for this.
--
Giuseppe "Oblomov" Bilotta
^ permalink raw reply
* grammar patches not best use of talent
From: jidanni @ 2009-01-12 2:51 UTC (permalink / raw)
To: git
In-Reply-To: <7vprito32u.fsf@gitster.siamese.dyndns.org>
I've decided to back out of my plan to patch grammar.
$ perl -nwle '/\w+\s+handful.*/i&& print $&' Documentation/*|sort -uf
a handful commits on top of that,
A handful documentation fixes.
A handful documentation updates.
a handful example hooks are copied in the
a handful fixes to run it
a handful of examples:
A handful of sample hooks are installed when
a handful pack-objects changes to help you cope better
a handful small fixes to gitweb.
a handful the real changes in non-zero
first handful of characters, show the full
only handful hexdigits prefix.
only handful hexdigits prefix. Non default number of
only handful hexdigits prefix. This is
At first some of the above lines irritated me, but who am I to say
that English must be said like my mom says it, and is never allowed to
evolve further. Nope, I'll stick to correcting 2+2=3 type things.
^ permalink raw reply
* Re: git-svn: File was not found in commit
From: Eric Wong @ 2009-01-12 2:32 UTC (permalink / raw)
To: Morgan Christiansson; +Cc: git
In-Reply-To: <496A890C.8080208@mog.se>
Morgan Christiansson <git@mog.se> wrote:
> The "Ignoring path" message appears to be coming from git which is
> refusing to commit the .git directory. Which leads to git-svn being
> unaware of the files being ignored and giving an error when it can't
> find them.
> I'm personally fine with these files being ignored by git, but git-svn
> needs to be aware that they are not added to the repository.
Hi Morgan,
Can you try the following rough patch and see it it fixes things
for you? Thanks!
>From 559f4b673592f364e9773f2ba65caf09b138521b Mon Sep 17 00:00:00 2001
From: Eric Wong <normalperson@yhbt.net>
Date: Sun, 11 Jan 2009 18:23:38 -0800
Subject: [PATCH/RFC] git-svn: avoid importing nested repos
Some SVN repositories contain .git repositories within them
(hopefully accidentally checked in). Since git refuses to
check in ".git" repositories, this can be a problem when
fetching updates from SVN.
This seems to repull the entire blob from SVN everytime a user
changes something inside the ".git" directory on the SVN side,
but hopefully this will be a rare case and the SVN users will
correct the error quickly.
The test could probably be expanded to be more thorough...
Signed-off-by: Eric Wong <normalperson@yhbt.net>
---
git-svn.perl | 8 +++++
t/t9133-git-svn-nested-git-repo.sh | 61 ++++++++++++++++++++++++++++++++++++
2 files changed, 69 insertions(+), 0 deletions(-)
create mode 100755 t/t9133-git-svn-nested-git-repo.sh
diff --git a/git-svn.perl b/git-svn.perl
index b0e3d7c..d34d967 100755
--- a/git-svn.perl
+++ b/git-svn.perl
@@ -3379,6 +3379,13 @@ sub apply_textdelta {
# (but $base does not,) so dup() it for reading in close_file
open my $dup, '<&', $fh or croak $!;
my $base = $::_repository->temp_acquire('git_blob');
+
+ # skip any .git directories that may have gone into SVN
+ # since update-index refuses to add anything under ".git"
+ if ($fb->{path} =~ m{(?:^|/)\.git(?:/|$)}) {
+ goto apply;
+ }
+
if ($fb->{blob}) {
my ($base_is_link, $size);
@@ -3412,6 +3419,7 @@ sub apply_textdelta {
}
}
seek $base, 0, 0 or croak $!;
+apply:
$fb->{fh} = $fh;
$fb->{base} = $base;
[ SVN::TxDelta::apply($base, $dup, undef, $fb->{path}, $fb->{pool}) ];
diff --git a/t/t9133-git-svn-nested-git-repo.sh b/t/t9133-git-svn-nested-git-repo.sh
new file mode 100755
index 0000000..85402f4
--- /dev/null
+++ b/t/t9133-git-svn-nested-git-repo.sh
@@ -0,0 +1,61 @@
+#!/bin/sh
+#
+# Copyright (c) 2009 Eric Wong
+#
+
+test_description='git svn property tests'
+. ./lib-git-svn.sh
+
+test_expect_success 'setup repo with a git repo inside it' '
+ svn co "$svnrepo" s &&
+ (
+ cd s &&
+ git init &&
+ test -f .git/HEAD &&
+ echo a > a &&
+ svn add .git a &&
+ test a = "`sed -ne 1p < a`" &&
+ svn commit -m "create a nested git repo"
+ )
+'
+
+test_expect_success 'clone an SVN repo containing a git repo' '
+ git svn clone "$svnrepo" g
+'
+
+test_expect_success 'SVN-side change outside of .git' '
+ (
+ cd s &&
+ echo b >> a &&
+ svn commit -m "SVN-side change outside of .git"
+ )
+'
+
+test_expect_success 'update git svn-cloned repo' '
+ (
+ cd g &&
+ git svn rebase &&
+ test a = "`sed -ne 1p < a`" &&
+ test b = "`sed -ne 2p < a`"
+ )
+'
+test_expect_success 'SVN-side change inside of .git' '
+ (
+ cd s &&
+ git add a &&
+ git commit -m "add a inside an SVN repo" &&
+ svn add .git &&
+ svn commit -m "SVN-side change inside of .git"
+ )
+'
+
+test_expect_success 'update git svn-cloned repo' '
+ (
+ cd g &&
+ git svn rebase &&
+ grep ^b a &&
+ git log --raw -r
+ )
+'
+
+test_done
--
Eric Wong
^ permalink raw reply related
* Re: [RFC PATCH 4/3] Add example git-vcs-p4
From: Junio C Hamano @ 2009-01-12 2:08 UTC (permalink / raw)
To: Daniel Barkalow; +Cc: git
In-Reply-To: <alpine.LNX.1.00.0901110336380.19665@iabervon.org>
Hmm...
CC vcs-p4.o
cc1: warnings being treated as errors
vcs-p4.c: In function 'output_data':
vcs-p4.c:253: warning: format '%d' expects type 'int', but argument 2 has type 'size_t'
vcs-p4.c: In function 'p4_where':
vcs-p4.c:291: warning: ISO C90 forbids mixed declarations and code
vcs-p4.c: In function 'p4_submit':
vcs-p4.c:363: warning: ISO C90 forbids mixed declarations and code
vcs-p4.c: In function 'p4_print':
vcs-p4.c:433: warning: format '%d' expects type 'int', but argument 2 has type 'size_t'
vcs-p4.c: In function 'p4_change':
vcs-p4.c:453: warning: ISO C90 forbids mixed declarations and code
vcs-p4.c: In function 'p4_filelog':
vcs-p4.c:504: warning: ISO C90 forbids mixed declarations and code
make: *** [vcs-p4.o] Error 1
^ permalink raw reply
* Re: [RFC/PATCH 0/3] Enable in-process submodule traversal
From: Junio C Hamano @ 2009-01-12 2:07 UTC (permalink / raw)
To: Lars Hjemli; +Cc: git
In-Reply-To: <1231717555-10559-1-git-send-email-hjemli@gmail.com>
Sounds interesting except 1/3 didn't seem to reach the list...
^ 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