* Detached checkout will clobber branch head when using symlink HEAD
From: Matt Draisey @ 2008-10-15 18:24 UTC (permalink / raw)
To: git
The faulty code appears to be this
git 1.6.0.2.526.g5c283
builtin-checkout.c
> 481 static void update_refs_for_switch(struct checkout_opts *opts,
> 500 if (new->path) {
>
> 511 } else if (strcmp(new->name, "HEAD")) {
> 512 update_ref(msg.buf, "HEAD", new->commit->object.sha1, NULL,
> 513 REF_NODEREF, DIE_ON_ERR);
> 514 if (!opts->quiet) {
> 515 if (old->path)
> 516 fprintf(stderr, "Note: moving to \"%s\" which isn't a local branch\nIf you want to create a new branch from this checkout, you may do so\n(now or later) by using -b with the checkout command again. Example:\n git checkout -b <new_branch_name>\n", new->name);
> 517 describe_detached_head("HEAD is now at", new->commit);
> 518 }
> 519 }
If HEAD is a symlink rather than a "ref:" style link this is really bad.
^ permalink raw reply
* Re: [PATCH] Preserve file permissions on git-reflog expire
From: Junio C Hamano @ 2008-10-15 17:54 UTC (permalink / raw)
To: Samuel Lucas Vaz de Mello; +Cc: git, Shawn O. Pearce
In-Reply-To: <48F629C2.70203@datacom.ind.br>
Samuel Lucas Vaz de Mello <samuellucas@datacom.ind.br> writes:
> Preserve file permissions on git-reflog expire to avoid problems with shared repositories and git-gc.
Looong line needs wrapped (I could do this myself if this was the only
issue, but...)
> Signed-off-by: Samuel Lucas Vaz de Mello <samuellucas@datacom.ind.br>
>
> ---
>
> This small patch fixes a bug with shared repositories and git-reflog expire.
> samuel@erdinger:~/myrepo$ git push
> Counting objects: 5, done.
> Compressing objects: 100% (3/3), done.
> Unpacking objects: 100% (3/3), done.
> Writing objects: 100% (3/3), 295 bytes, done.
> Total 3 (delta 2), reused 0 (delta 0)
> error: Unable to append to logs/refs/heads/master: Permission denied
> To /remote/myrepo/
> ! [remote rejected] master -> master (failed to write)
> error: failed to push some refs to '/remote/myrepo/'
Thanks for a reproduction recipe. I think an abbreviated version of this
would deserve to be in the commit log message proper.
> diff --git a/builtin-reflog.c b/builtin-reflog.c
> index 6b3667e..92a0d53 100644
> --- a/builtin-reflog.c
> +++ b/builtin-reflog.c
> @@ -265,6 +265,7 @@ static int expire_reflog(const char *ref, const unsigned char *sha1, int unused,
> struct cmd_reflog_expire_cb *cmd = cb_data;
> struct expire_reflog_cb cb;
> struct ref_lock *lock;
> + struct stat filestat;
> char *log_file, *newlog_path = NULL;
> int status = 0;
>
> @@ -303,6 +304,10 @@ static int expire_reflog(const char *ref, const unsigned char *sha1, int unused,
> status |= error("Couldn't write %s",
> lock->lk->filename);
> unlink(newlog_path);
> + } else if (stat(log_file, &filestat)){
> + status |= error("unable to read permissions of %s", log_file);
Hmmm. Is there a reason you did not use adjust_shared_perm() like all the
other codepaths for creating files under .git/ directory do?
^ permalink raw reply
* [PATCH] Preserve file permissions on git-reflog expire
From: Samuel Lucas Vaz de Mello @ 2008-10-15 17:34 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano, Shawn O. Pearce
Preserve file permissions on git-reflog expire to avoid problems with shared repositories and git-gc.
Signed-off-by: Samuel Lucas Vaz de Mello <samuellucas@datacom.ind.br>
---
This small patch fixes a bug with shared repositories and git-reflog expire.
If you have a shared repository created with git-init --shared, several users can push to it.
Once you run git-gc (which calls git-reflog expire) on the shared repository, the reflogs files are recreated with umask permissions, which defaults to 644 (with no group write). Since then, users receive the following error when trying to push:
samuel@erdinger:~/myrepo$ git push
Counting objects: 5, done.
Compressing objects: 100% (3/3), done.
Unpacking objects: 100% (3/3), done.
Writing objects: 100% (3/3), 295 bytes, done.
Total 3 (delta 2), reused 0 (delta 0)
error: Unable to append to logs/refs/heads/master: Permission denied
To /remote/myrepo/
! [remote rejected] master -> master (failed to write)
error: failed to push some refs to '/remote/myrepo/'
This patch avoid this error preserving the permissions on reflog files.
builtin-reflog.c | 5 +++++
1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/builtin-reflog.c b/builtin-reflog.c
index 6b3667e..92a0d53 100644
--- a/builtin-reflog.c
+++ b/builtin-reflog.c
@@ -265,6 +265,7 @@ static int expire_reflog(const char *ref, const unsigned char *sha1, int unused,
struct cmd_reflog_expire_cb *cmd = cb_data;
struct expire_reflog_cb cb;
struct ref_lock *lock;
+ struct stat filestat;
char *log_file, *newlog_path = NULL;
int status = 0;
@@ -303,6 +304,10 @@ static int expire_reflog(const char *ref, const unsigned char *sha1, int unused,
status |= error("Couldn't write %s",
lock->lk->filename);
unlink(newlog_path);
+ } else if (stat(log_file, &filestat)){
+ status |= error("unable to read permissions of %s", log_file);
+ } else if (chmod(newlog_path, filestat.st_mode)){
+ status |= error("cannot set permissions of %s", newlog_path);
} else if (rename(newlog_path, log_file)) {
status |= error("cannot rename %s to %s",
newlog_path, log_file);
--
1.6.0.2.532.g84ed4c.dirty
^ permalink raw reply related
* Re: [gambit-list] Separating generated files? (Re: Mercurial -> git)
From: Christian Jaeger @ 2008-10-15 17:28 UTC (permalink / raw)
To: Michael J Gruber
Cc: Matthieu Moy, Nguyen Thai Ngoc Duy, Git Mailing List, Marc Feeley,
Gambit List
In-Reply-To: <48F61D77.3080100@drmicha.warpmail.net>
Michael J Gruber wrote:
> I wonder whether a clever use of "excludes" and GIT_DIR would allow
> tracking the different filesets in the same dir, but using different
> repos. I'm just afraid it's a fragile setup, in the sense that it relies
> on config stuff which is not tracked (and thus not reproduced
> automatically on clone).
I expect that using a superproject repository to tie together the two
repositories is good and necessary because it is the link that allows to
specify which commit in the repo of generated files belongs together
with a commit in the repo of source files. So just using two separate
repositories without making them submodules of a superproject does not
seem to be a good idea to me.
Once there is a superproject repository, one could also commit config
files of the submodules into it (I'm not sure what that will buy
though--.gitignore is outside and can committed anyway, at least as long
as not both repositories are overlaid as you suggest).
You're probably right that strictly speaking, there is no need to move
generated files out into a separate directory tree; but I think doing
the move would be worthwhile since it takes away one level of complexity
(you can then access the build/.git repository without the need of
setting GIT_DIR), and because it may be a good idea anyway (for example
it will be easier to grep the sources without getting hits from the
generated files). [Also, the exclude patterns wouldn't be easy, as we
couldn't really just exclude all *.c files from the view of the source
repository, since there are also some hand-crafted ones; the excludes
would need full paths which would have to be kept up to date manually,
unless we wanted to live with the fact that newly created manual .c
files would be added using "git add -f".]
Christian.
^ permalink raw reply
* Re: git-scm.com (was Re: Git graph on GitHub)
From: Petr Baudis @ 2008-10-15 17:25 UTC (permalink / raw)
To: Scott Chacon; +Cc: Wincent Colaiuta, git
In-Reply-To: <d411cc4a0810150921j198fda93j60dae04c4cc9b9d1@mail.gmail.com>
On Wed, Oct 15, 2008 at 09:21:50AM -0700, Scott Chacon wrote:
> Petr and I have previously discussed trying to unify the sites somehow
> and will likely discuss this in more detail at the GitTogether in a
> few weeks.
Yes. I mentioned this on IRC but should really write it on the mailing
list - I'm looking forward for the GitTogether to resolve any remaining
issues anyone has with git-scm.com and make git.or.cz probably
essentially point to git-scm.com. Since the old threads died away long
ago, if anyone - especially who is not attending GitTogether - still
dislikes some things about the git-scm.com site, please follow up here.
> I do wish that there wasn't this 'us vs them' mentality on this list,
> though. I think GitHub is doing some good things for the community,
> and I also think that 'the community' is bigger than this list.
I think this last sentence is where we differ - for (most of?) us the
Git developers, 'the community' pretty much _is_ this list (with the IRC
channel as its casual extension). But I'm very glad to see an
announcement from the GitHub people here and I hope we will see more of
them. Don't worry about the occasional flames, we all get hit by them
sometime. :-) (Um, I personally think *I* get flamed much less than I
would deserve. ;-)
--
Petr "Pasky" Baudis
People who take cold baths never have rheumatism, but they have
cold baths.
^ permalink raw reply
* Re: What's in git.git (Oct 2008, #03; Tue, 14)
From: Mike Ralphson @ 2008-10-15 17:25 UTC (permalink / raw)
To: Brandon Casey
Cc: Junio C Hamano, git, Arjen Laarhoven, Jeff King, Shawn O. Pearce
In-Reply-To: <bsftmRx17krWBpVlulipoJEO1fWsD0hZfF3HOZcajX6GV66RKW8W6A@cipher.nrlssc.navy.mil>
2008/10/15 Brandon Casey <casey@nrlssc.navy.mil>:
> 2) Do we want to stick with compat/regex on
>
> Darwin: Arjen
> FreeBSD: Jeff
> AIX: Mike
>
> now that the builtin funcname patterns have been converted to Extended
> Regular Expressions?
Thanks for the reminder, I'd been meaning to recheck this. It appears
that AIX doesn't require compat/regex now with the eregexes, so:
Tested-as-no-longer-required-by: Mike Ralphson <mike@abacus.co.uk>
Though I've just noticed my test counts don't actually add up...
fixed 1
success 3555
failed 0
broken 1
total 3559
8-)
Mike
^ permalink raw reply
* StGIT 0.14.3: extra space is added before e-mail on export after "stg edit"
From: Andrey Borzenkov @ 2008-10-15 16:25 UTC (permalink / raw)
To: catalin.marinas; +Cc: git
[-- Attachment #1: Type: text/plain, Size: 525 bytes --]
Hi,
Funny problem. I have following export template:
Subject: [PATCH] %(shortdescr)s
From: %(authname)s %(authemail)s
%(longdescr)s
Signed-off-by: %(authname)s %(authemail)s
---
%(diffstat)s
So after "stg new", edit, "stg refres" (and any number of "stg refresh"es)
it exports OK. But once I did "stg edit patch", all subsequent "stg export patch"
will give (assuming author is me@foo.net):
From: My Name < me@foo.net>
...
Signed-off-by: My Name < me@foo.net>
Notice extra space between "<" and e-mail.
TIA
-andrey
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: Separating generated files?
From: Christian Jaeger @ 2008-10-15 16:45 UTC (permalink / raw)
To: Matthieu Moy; +Cc: Gambit List, Git Mailing List
In-Reply-To: <vpqiqrt3mgs.fsf@bauges.imag.fr>
Matthieu Moy wrote:
> I think the first question is: do you (and why) need to use a version
> control system for generated files?
The project in question is a self-hosting compiler which compiles to C
as an intermediary language. Providing the generated C files to users
makes installation easy (it avoids the bootstrapping issue). So it's
more 'severe' of an issue than just one of for example generating
documentation files using a 3rd-party tool.
What may make matters worse, is that there are interdependencies between
a number of hand-written C files and the generated files, so it's not
always possible to use an older compiler version to reproduce the
generated C files for a newer compiler; so if you want to merge newer
compiler sources, you may also need the generated files, at least if you
want that without fuss. So, there is always a need to somehow transmit
the generated files too. I guess that this is easier than code the
system in a way to always allow backwards compatibility (I haven't
worked on the compiler itself yet, so this is a guess and may need
confirmation).
Apart from that, I've found it useful (in another project, writing a
document translator) to keep generated files in a VCS (Git) as well (I
checked them into the *same* repository as the translator source, even
if it felt ugly (for the previously mentioned reasons)), as then when I
changed the translator, I could easily see where it had effect on the
generated output. It can even serve as a debugging help kind of like a
test suite does. This may be the case here, too (again, I'm guessing here).
How are other compiler projects which are bootstrapping via C dealing
with this?
Christian.
^ permalink raw reply
* Re: [gambit-list] Separating generated files? (Re: Mercurial -> git)
From: Michael J Gruber @ 2008-10-15 16:42 UTC (permalink / raw)
To: Matthieu Moy
Cc: Nguyen Thai Ngoc Duy, Christian Jaeger, Git Mailing List,
Marc Feeley, Gambit List
In-Reply-To: <vpqiqrt3mgs.fsf@bauges.imag.fr>
Matthieu Moy venit, vidit, dixit 15.10.2008 17:30:
> "Nguyen Thai Ngoc Duy" <pclouds@gmail.com> writes:
>
>> Hi Christian,
>>
>> The idea of using two separate repositories for source and generated
>> source is interesting. I would like to bring this to git mailing list,
>> they may provide insightul comments for your idea or even other
>> approaches.
>
> I think the first question is: do you (and why) need to use a version
> control system for generated files?
I guess we can take "yes" for granted for the first part ;)
As for the why: In cases like this one it's interesting to compare
(read: diff) the output generated by different versions of the input.
I wonder whether a clever use of "excludes" and GIT_DIR would allow
tracking the different filesets in the same dir, but using different
repos. I'm just afraid it's a fragile setup, in the sense that it relies
on config stuff which is not tracked (and thus not reproduced
automatically on clone).
Michael
^ permalink raw reply
* Re: git-scm.com (was Re: Git graph on GitHub)
From: Scott Chacon @ 2008-10-15 16:21 UTC (permalink / raw)
To: Wincent Colaiuta; +Cc: git
In-Reply-To: <20C9ABEC-52E5-405E-A755-C58A6359D7A9@wincent.com>
Hi,
On Wed, Oct 15, 2008 at 3:34 AM, Wincent Colaiuta <win@wincent.com> wrote:
> El 15/10/2008, a las 12:18, PJ Hyett escribió:
>
>>> One nitpick regarding your git.git mirror: I doubt that people here
>>> ("the community") consider git-scm.com to be "the git homepage". I don't
>>> want to go into the reasons and start a pointless thread, but since
>>> git-scm.com is a fork of git.or.cz pointing to the latter (the root)
>>> should make everyone happy.
There is a slight misperception here. I setup the git mirror at
GitHub as part of my git-scm.com work, they did not do it as some sort
of semi-official mirror. The reason the git.git repo points to
git-scm is because I had plans to use github apis to do some fun stuff
on git-scm, and the mirror is being kept up to date by scripts on the
git-scm server. Also, I figured it was likely that people looking at
the git repo on GitHub rather than on kernel.org would probably be
more interested in the more user-friendly version, yes? That's all,
it's nothing sinister. Petr and I have previously discussed trying to
unify the sites somehow and will likely discuss this in more detail at
the GitTogether in a few weeks.
Also, trust me - none of us want Junio's job. I've talked way too
much with Shawn over the last few weeks to ever covet that position :)
I do wish that there wasn't this 'us vs them' mentality on this list,
though. I think GitHub is doing some good things for the community,
and I also think that 'the community' is bigger than this list. I
propose that we spend our cycles on git stuff, rather than mocking or
trying to exclude each other.
Also, I think we can all agree that Junio is strikingly handsome.
Scott
>>
>> Hi Michael,
>> I'll go ahead and start a pointless thread along with the reasons
>> provided via answers to the 2008 Git Survey[1]:
>
> Coming up in news at 6...
>
> GitHub announces new maintainer for Git
>
> GitHub is proud to announce the replacement of the old Git maintainer with
> the "Git Core Team", comprising PJ Hyett, Scott Chacon, Tom Preston and some
> select personalities from the Ruby on Rails world. You'll be able to track
> all the latest updates to "Git Edge" over at GitHub. The former maintainer,
> Junio C Hamano, is being retired from service because the Git community (see
> git-scm.com) decided he wasn't as good-looking as David Heinemeier Hanson.
> For more information, see the official Git book (book.git-scm.com).
>
> --
> 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
>
^ permalink raw reply
* Re: [gambit-list] Separating generated files? (Re: Mercurial -> git)
From: Matthieu Moy @ 2008-10-15 15:30 UTC (permalink / raw)
To: Nguyen Thai Ngoc Duy
Cc: Christian Jaeger, Git Mailing List, Marc Feeley, Gambit List
In-Reply-To: <fcaeb9bf0810150754s613f2c44pd8341711d9d73f73@mail.gmail.com>
"Nguyen Thai Ngoc Duy" <pclouds@gmail.com> writes:
> Hi Christian,
>
> The idea of using two separate repositories for source and generated
> source is interesting. I would like to bring this to git mailing list,
> they may provide insightul comments for your idea or even other
> approaches.
I think the first question is: do you (and why) need to use a version
control system for generated files?
--
Matthieu
^ permalink raw reply
* Re: What's in git.git (Oct 2008, #03; Tue, 14)
From: Brandon Casey @ 2008-10-15 15:35 UTC (permalink / raw)
To: Junio C Hamano
Cc: git, Arjen Laarhoven, Jeff King, Shawn O. Pearce, Mike Ralphson
In-Reply-To: <7vej2i7rt9.fsf@gitster.siamese.dyndns.org>
Two questions:
1) Should a5a5a048 be in maint?
"xdiff-interface.c: strip newline (and cr) from line before pattern matching"
2) Do we want to stick with compat/regex on
Darwin: Arjen
FreeBSD: Jeff
AIX: Mike
now that the builtin funcname patterns have been converted to Extended
Regular Expressions?
-brandon
^ permalink raw reply
* Re: [BUG] git status doesn't handle submodules properly on OSX
From: Lars Hoss @ 2008-10-15 15:21 UTC (permalink / raw)
To: Richard Bubel; +Cc: Lars Hoss, Pieter de Bie, Jeff King, Git Mailinglist
In-Reply-To: <DE453BEE-6749-4892-BFAA-3B37CFAADD3E@cs.chalmers.se>
Ok, this might be the difference. I am pretty sure my
filesystem is not case-sensitive (default?).
At least "mkdir Foo" fails when "foo" exists.
Yours,
Lars
> Hi,
>
> On Oct 15, 2008, at 16:51 , Lars Hoss wrote:
>
>>> Works for me on Leopard
>>> [...]
>>> Vienna:a pieter$ git --version
>>> git version 1.6.0.2.415.gf9137
>>
>> My git version "1.6.0.2" says:
>>
>> # On branch master
>> [...]
>> git --version
>> git version 1.6.0.2
>>
>> Git was build from macports.
>
>
> works for me too on OS X 10.5.5 with git 1.6.0.2 from MacPorts. As it
> deviates from the default, it might be worth mentioning that the
> filesystem in use here is the case-sensitive version of HFS+.
>
> Best Regards,
> Richard
>
^ permalink raw reply
* Re: [BUG] git status doesn't handle submodules properly on OSX
From: Lars Hoss @ 2008-10-15 15:14 UTC (permalink / raw)
To: Pieter de Bie; +Cc: Lars Hoss, Jeff King, Git Mailinglist
In-Reply-To: <A0A3837E-7F85-4172-A8BA-969BFD46CF48@ai.rug.nl>
> I just tested 1.6.0.2, and had no problems. Perhaps macports is doing
> something odd?
Actually this was my idea first. Thus I build git from the sources the
portfile links to myself. The bug, however, remains.
The link is: http://www.kernel.org/pub/software/scm/git/git-1.6.0.2.tar.bz2.
I've tested this on two machines, both using latest version of Leopard.
And there was another poster on this forum who had the very same issue.
Now the interesting question is what is different between Pieter's system
and mine? And why does 1.5.6 work fine?
As soon as I am at home I will try bisect. I am currently at work behind a
big bad firewall ;)
Yours,
Lars
^ permalink raw reply
* Re: [BUG] git status doesn't handle submodules properly on OSX
From: Richard Bubel @ 2008-10-15 15:01 UTC (permalink / raw)
To: Lars Hoss; +Cc: Pieter de Bie, Jeff King, Git Mailinglist
In-Reply-To: <6ca24750ca8d7bd9e995d023e78e0d71.squirrel@webmail.highteq.net>
Hi,
On Oct 15, 2008, at 16:51 , Lars Hoss wrote:
>> Works for me on Leopard
>> [...]
>> Vienna:a pieter$ git --version
>> git version 1.6.0.2.415.gf9137
>
> My git version "1.6.0.2" says:
>
> # On branch master
> [...]
> git --version
> git version 1.6.0.2
>
> Git was build from macports.
works for me too on OS X 10.5.5 with git 1.6.0.2 from MacPorts. As it
deviates from the default, it might be worth mentioning that the
filesystem in use here is the case-sensitive version of HFS+.
Best Regards,
Richard
^ permalink raw reply
* Re: [BUG] git status doesn't handle submodules properly on OSX
From: Pieter de Bie @ 2008-10-15 14:59 UTC (permalink / raw)
To: Lars Hoss; +Cc: Jeff King, Git Mailinglist
In-Reply-To: <6ca24750ca8d7bd9e995d023e78e0d71.squirrel@webmail.highteq.net>
On 15 okt 2008, at 16:51, Lars Hoss wrote:
> My git version "1.6.0.2" says:
>
> # Untracked files:
> # (use "git add <file>..." to include in what will be committed)
> #
> # lib/
> git --version
> git version 1.6.0.2
I just tested 1.6.0.2, and had no problems. Perhaps macports is doing
something odd?
^ permalink raw reply
* Re: Separating generated files? (Re: Mercurial -> git)
From: Nguyen Thai Ngoc Duy @ 2008-10-15 14:54 UTC (permalink / raw)
To: Christian Jaeger, Git Mailing List; +Cc: Gambit List
In-Reply-To: <48F5D86B.6040501@pflanze.mine.nu>
Hi Christian,
The idea of using two separate repositories for source and generated
source is interesting. I would like to bring this to git mailing list,
they may provide insightul comments for your idea or even other
approaches.
Background for Git people: gambit-c was previously stored in
mercurial. The main source is in gambit-c (a Scheme implementation or
a Lisp dialect). *.scm files generate *.c, which will be compiled by
gcc as usual. Both *.scm and generated *.c are now stored in
mercurial. Gambit-C maintainers have recently decided to move to Git.
On 10/15/08, Christian Jaeger <christian@pflanze.mine.nu> wrote:
> I wonder whether it would be a good idea, and good occasion to realize
> it, to move source files and generated files into separate repositories
> and 'link' those together using the git submodule feature.
>
> Expected advantages:
>
> - no clutter when looking through the history (can possibly be mitigated
> by constraining git log, git diff etc. to the non-generated paths only,
> although I don't think this is possible (cleanly) with the current
> directory structure); the same holds true for using "git format-patch"
> (one wouldn't usually want to include the generated files in diffs sent
> to the mailing list)
>
> - when merging branches, there will usually be no need to deal with
> merge conflicts in the generated files (one would just regenerate them
> instead)
>
> - [especially for files being generated not by Gambit itself (for
> example "configure"),] the files can be regenerated by differing
> [external] software versions without having to deal with those
> superfluous changes in the source repository.
>
> By still committing the generated files--to a different
> submodule--Gambit can still be updated through Git alone, and the
> possible advantage of tracking the generated files to see the effects of
> changes in compiler sources can still be had.
>
> Expected disadvantages:
>
> - all generated files need to reside in a separate directory structure;
> e.g. the file $BASEDIR/lib/_io.c would have to be at a place like
> $BASEDIR/build/lib/_io.c instead, where build/ is the submodule taking
> all generated files; since the "configure" file is expected to reside at
> the toplevel, I guess this would require that "make update" copies it
> from $BASEDIR/build/configure to $BASEDIR/configure (assuming that one
> cannot use a symlink because of portability reasons).
>
> - to commit the generated files, a separate step is necessary ("cd
> $otherrepo; git commit -a", or maybe easier create a "make
> commit_generated" make target?)
>
> - to make this work with the "source" repository residing at the
> toplevel, the Git superproject repository (of which the "source" and
> "build" repositories are submodules) would need to reside in a
> non-standard directory, like $BASEDIR/.gitsuperproject/ instead of the
> usual .git/, and using the GIT_DIR environment variable to access it,
> although this can probably be handled by make targets (i.e. "make
> update" would set GIT_DIR=$BASEDIR/.gitsuperproject when calling "git
> submodule update").
>
> - there may be some cases to flesh out; like, should "make update"
> really call "git submodule update" (which simply sets the submodules to
> the reference given by the superproject, throwing away changes done by
> the user in the submodules (they can be recovered from the git reflog,
> but may still be a surprise)) or should it run "git pull" in each
> submodule instead?
>
> I thought I'd bring this up now because if package maintainers need to
> adapt some things anyway, that may be a good time to do it now. (There's
> even the possibility to split the converted Mercurial repository into
> the source + build parts in retrospect now, which won't be possible
> anymore later on (without changing the sha1 sums of the whole Git
> history with the associated breakage of existing clones), although that
> may not be important.)
>
> I'm willing to help in the effort, although I don't know the build tools
> (autoconf and make) and their use in the setup well, so I would probably
> be quite a bit lost when doing it alone.
>
> Christian.
--
Duy
^ permalink raw reply
* Re: [BUG] git status doesn't handle submodules properly on OSX
From: Lars Hoss @ 2008-10-15 14:51 UTC (permalink / raw)
To: Pieter de Bie; +Cc: Lars Hoss, Jeff King, Git Mailinglist
In-Reply-To: <5D0481A4-D173-4CF8-B855-5E58978210F8@ai.rug.nl>
> Works for me on Leopard
>
> Vienna:a pieter$ git submodule add ~/projects/GitX/ gitx
> Initialized empty Git repository in /Users/pieter/a/gitx/.git/
> Vienna:a pieter$ git st
> # On branch master
> # Changes to be committed:
> # (use "git reset HEAD <file>..." to unstage)
> #
> # new file: .gitmodules
> # new file: gitx
> #
> Vienna:a pieter$ git --version
> git version 1.6.0.2.415.gf9137
My git version "1.6.0.2" says:
# On branch master
# Changes to be committed:
# (use "git reset HEAD <file>..." to unstage)
#
# new file: .gitmodules
# new file: lib
#
# Untracked files:
# (use "git add <file>..." to include in what will be committed)
#
# lib/
git --version
git version 1.6.0.2
Git was build from macports.
Yours,
Lars
^ permalink raw reply
* Re: [BUG] git status doesn't handle submodules properly on OSX
From: Pieter de Bie @ 2008-10-15 14:38 UTC (permalink / raw)
To: Lars Hoss, Jeff King, Git Mailinglist
In-Reply-To: <c60a85c1297be6446ad92a3e7723ddc8.squirrel@webmail.highteq.net>
On 15 okt 2008, at 14:07, Lars Hoss wrote:
> two days ago I posted about an issue:
> http://thread.gmane.org/gmane.comp.version-control.git/98171
>
> After more testing I can confirm it is indeed a bug.
>
> 1.6.0.2 on OSX Leopard doesn't work. After adding a submodule
> the folder of the submodule will always get listed under
> "Untracked files" when calling git status.
>
> 1.5.6, however, works fine. I have not tested trunk yet.
>
> So as a workaround I have to go back to 1.5.6 for now.
Works for me on Leopard
Vienna:a pieter$ git submodule add ~/projects/GitX/ gitx
Initialized empty Git repository in /Users/pieter/a/gitx/.git/
Vienna:a pieter$ git st
# On branch master
# Changes to be committed:
# (use "git reset HEAD <file>..." to unstage)
#
# new file: .gitmodules
# new file: gitx
#
Vienna:a pieter$ git --version
git version 1.6.0.2.415.gf9137
- Pieter
^ permalink raw reply
* Re: [PATCH try 2] t1301-shared-repo.sh: don't let a default ACL interfere with the test
From: Matt McCutchen @ 2008-10-15 14:34 UTC (permalink / raw)
To: Johannes Sixt; +Cc: Junio C Hamano, git
In-Reply-To: <48F589EC.6050307@viscovery.net>
On Wed, 2008-10-15 at 08:13 +0200, Johannes Sixt wrote:
> Junio C Hamano schrieb:
> > Makes me wonder why this is _not_ inside test-lib.sh where it creates the
> > test (trash) directory. That way, you would cover future tests that wants
> > to see a saner/simpler POSIX permission behaviour, wouldn't you?
>
> But that would also paper over unanticipated bad interactions with strange
> ACLs that people might set, wouldn't it? By not placing this into
> test-lib.sh there is a higher chance that such an interaction is revealed,
> and we can react on it (educate users or fix the code).
A default ACL on the working tree does not interfere with git's
operation. If the repository is shared, git will explicitly set the
permissions of every file as configured; otherwise, new files will
simply take their permissions from the default ACL instead of the
creating process's umask. This is exactly the behavior that a user who
sets a default ACL would expect. There is no need to modify
adjust_shared_perm or to warn users not to use default ACLs.
The only problem here is that a default ACL prevents
t1301-shared-repo.sh from testing the interaction between the umask and
the sharedRepository setting, since the test case expects new files to
be created according to the umask it set but the default ACL is
overriding the umask. Removing the trash directory's default ACL is a
perfectly legitimate way for t1301-shared-repo.sh to test what it wants
to test. Another option would be to modify the trash directory's
default ACL instead of modifying the umask.
Other tests will not care whether test-lib.sh clears a default ACL for
them because they are not specifically testing file permissions.
Therefore, I thought it best to leave the default ACL alone so that the
trash directories get the permissions the user has specified in the
default ACL in case he/she cares about sharing the trash directories
with others.
Matt
^ permalink raw reply
* Re: [BUG] git status doesn't handle submodules properly on OSX
From: Lars Hoss @ 2008-10-15 14:30 UTC (permalink / raw)
To: Jeff King; +Cc: Lars Hoss, git
In-Reply-To: <20081015124943.GA10816@sigill.intra.peff.net>
> I wasn't able to reproduce your bug on my Linux box. Can you bisect to
> find the faulty commit?
Yes, you are right. This bug does neither appear on Linux nor on Windows
(mysysgit). So far it seems to be a OSX only bug.
Never used bisect myself before since I am new to git. But will try to do
my best - hehehe :)
Yours,
Lars
^ permalink raw reply
* Re: [PATCH (GITK) v3 0/4] Enhance encoding support.
From: Alexander Gavrilov @ 2008-10-15 13:09 UTC (permalink / raw)
To: Paul Mackerras; +Cc: git, Johannes Sixt
In-Reply-To: <18677.58426.326371.788610@cargo.ozlabs.ibm.com>
On Wed, Oct 15, 2008 at 4:38 PM, Paul Mackerras <paulus@samba.org> wrote:
> Alexander Gavrilov writes:
>
>> Since git apparently cannot work with filenames in non-locale
>> encodings anyway, I did not try to do anything about it apart
>> from fixing some obvious bugs.
>
> What we did before was read filenames and convert them from the system
> encoding (done implicitly by gets) before unquoting filenames that
> were quoted. What we do now with your patch 1/2 is that we read the
> filenames in binary and unquote any quoted filenames before converting
> from the system encoding. So I don't think your patch would have made
> as much difference as it might appear. If there is a reason for
> unquoting before converting from the system encoding rather than
> after, it seems pretty subtle to me and wasn't explained in the patch
> description. An explanation, preferably with examples, would be
> useful.
The reason is that non-ASCII characters may be quoted too, so the
string that we read looks like
"\204\206\204y\204s\204\200\204r\204y\204~\204p.txt". There is no
point decoding it before unquoting.
> Also, you didn't say whether you found the "obvious bugs" by
> inspection or by encountering their effects in actual running (and if
> so, what those effects were). That information is also good to have
> in the patch description.
I actually created a test repository with non-ASCII filenames. If I
remember it correctly, the bugs manifested as strings in the tree view
appearing as if they were decoded using ISO-8859-1 (the result of
decoding before unquoting), or unstaged files being listed quoted as
above.
Now the remaining encoding issues are:
1) Commit messages that are loaded through readcommit are decoded
using the system encoding. It is rare, but it happens. This is a bug.
proc readcommit {id} {
if {[catch {set contents [exec git cat-file commit $id]}]} return
parsecommit $id $contents 0
}
2) Gitk cannot process commits stored in multiple different encodings:
they all are decoded using the current value of i18n.commitencoding.
This seems to be low priority, because most GUI users are better off
using utf-8 for their commits anyway.
Alexander
^ permalink raw reply
* Re: [PATCH v2] describe: Make --tags and --all match lightweight tags more often
From: Santi Béjar @ 2008-10-15 12:54 UTC (permalink / raw)
To: Shawn O. Pearce
Cc: Junio C Hamano, git, Pierre Habouzit, Erez Zilber,
Uwe Kleine-König
In-Reply-To: <20081013143946.GP4856@spearce.org>
> diff --git a/Documentation/git-describe.txt b/Documentation/git-describe.txt
> index c4dbc2a..40e061f 100644
> --- a/Documentation/git-describe.txt
> +++ b/Documentation/git-describe.txt
[...]
> +annotated tags. For more information about creating annoated tags
s/annoated/annotated/
Santi
^ permalink raw reply
* Re: [BUG] git status doesn't handle submodules properly on OSX
From: Jeff King @ 2008-10-15 12:49 UTC (permalink / raw)
To: Lars Hoss; +Cc: git
In-Reply-To: <c60a85c1297be6446ad92a3e7723ddc8.squirrel@webmail.highteq.net>
On Wed, Oct 15, 2008 at 02:07:17PM +0200, Lars Hoss wrote:
> two days ago I posted about an issue:
> http://thread.gmane.org/gmane.comp.version-control.git/98171
>
> After more testing I can confirm it is indeed a bug.
>
> 1.6.0.2 on OSX Leopard doesn't work. After adding a submodule
> the folder of the submodule will always get listed under
> "Untracked files" when calling git status.
>
> 1.5.6, however, works fine. I have not tested trunk yet.
I wasn't able to reproduce your bug on my Linux box. Can you bisect to
find the faulty commit?
-Peff
^ permalink raw reply
* Re: [PATCH (GITK) v3 0/4] Enhance encoding support.
From: Paul Mackerras @ 2008-10-15 12:38 UTC (permalink / raw)
To: Alexander Gavrilov; +Cc: git, Johannes Sixt
In-Reply-To: <1223885554-27718-1-git-send-email-angavrilov@gmail.com>
Alexander Gavrilov writes:
> Since git apparently cannot work with filenames in non-locale
> encodings anyway, I did not try to do anything about it apart
> from fixing some obvious bugs.
What we did before was read filenames and convert them from the system
encoding (done implicitly by gets) before unquoting filenames that
were quoted. What we do now with your patch 1/2 is that we read the
filenames in binary and unquote any quoted filenames before converting
from the system encoding. So I don't think your patch would have made
as much difference as it might appear. If there is a reason for
unquoting before converting from the system encoding rather than
after, it seems pretty subtle to me and wasn't explained in the patch
description. An explanation, preferably with examples, would be
useful.
Also, you didn't say whether you found the "obvious bugs" by
inspection or by encountering their effects in actual running (and if
so, what those effects were). That information is also good to have
in the patch description.
Paul.
^ 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