* Re: Untracked working tree files
From: david @ 2008-10-15 19:42 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Andrew Morton, git
In-Reply-To: <alpine.LFD.2.00.0810151219120.3288@nehalem.linux-foundation.org>
On Wed, 15 Oct 2008, Linus Torvalds wrote:
> On Wed, 15 Oct 2008, david@lang.hm wrote:
>>
>> the fact that git will happily leave modified things in the working directory
>> appears to be very helpful for some developers, but it's also a big land mine
>> for others.
>
> Hmm. It doesn't actually do that normally. If you switch between trees,
> git will (or _should_) remove the old files that it knows about. If you
> get a lot of left-over turds, there's something wrong.
>
> It could be a git bug, of course. That said, especially considering the
> source of this, I wonder if it's just that Andrew ends up using all those
> non-git scripts on top of a git tree, and then that can result in git
> *not* knowing about a certain file, and then when switching between trees
> (with either git checkout or with git reset), the data that was created
> with non-git tools gets left behind and now git will be afraid to
> overwrite it.
>
> So yes, there are ways to force it (both "git checkout -f" and "git reset
> --hard" having already been mentioned), but the need for that - especially
> if it's common - is a bit discouraging.
>
> Especially since it's still possible that it's some particular mode of git
> usage that leaves those things around. Andrew - have you any clue what it
> is that triggers the behavior?
I see it fairly frequently when switching between different branches of a
project.
I also see it when I try applying a patch to a tree, then want to get up
to date with that tree (in this case it really is different)
It could be that git is looking to see if the file is the same as the old
tree had it before checking out the new tree. if it isn't for any reason
it sounds the alert.
David Lang
> (By the filename, I realize it's a file that doesn't exist in one tree or
> the other, and which doesn't get removed at some point. But have you had
> merge failures, for example? Is it perhaps a file that was created during
> a non-clean merge, and then got left behind due to the merge being
> aborted? It would be interesting to know what led up to this..)
>
> Linus
>
^ permalink raw reply
* Re: What's in git.git (Oct 2008, #03; Tue, 14)
From: Junio C Hamano @ 2008-10-15 19:38 UTC (permalink / raw)
To: Brandon Casey
Cc: git, Arjen Laarhoven, Jeff King, Shawn O. Pearce, Mike Ralphson
In-Reply-To: <bsftmRx17krWBpVlulipoJEO1fWsD0hZfF3HOZcajX6GV66RKW8W6A@cipher.nrlssc.navy.mil>
Brandon Casey <casey@nrlssc.navy.mil> writes:
> Two questions:
>
> 1) Should a5a5a048 be in maint?
> "xdiff-interface.c: strip newline (and cr) from line before pattern matching"
I would have forked a maint-fix topic to prepare a merge of this fix to
both 'maint' and 'master' but apparently this was applied directly on
'master'. I may be missing a valid reason why Shawn did it this way.
If we can add a test case to demonstrate the existing breakage, I think we
can (and should) cherry-pick it to 'maint'.
> 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?
Mike already said AIX does not need to, and I expect others would say
their native regexp library can grok ERE just fine. Let's wait for others
to confirm and then remove the compat/regex thing.
^ permalink raw reply
* Re: Untracked working tree files
From: Nicolas Pitre @ 2008-10-15 19:34 UTC (permalink / raw)
To: Andrew Morton; +Cc: david, git
In-Reply-To: <alpine.LFD.2.00.0810151531140.26244@xanadu.home>
On Wed, 15 Oct 2008, Nicolas Pitre wrote:
> On Wed, 15 Oct 2008, Andrew Morton wrote:
>
> > I do
> >
> > git-reset --hard HEAD
> > git-reset --hard linux-next
> > git-checkout linux-next
> >
> > and get
> >
> > error: Untracked working tree file 'Next/SHA1s' would be overwritten by merge.
> > y
> >
> > grr.
>
> What about simply:
>
> git-checkout -f linux-next
Never mind -- you apparently did that already with success.
Nicolas
^ permalink raw reply
* Re: Untracked working tree files
From: Nicolas Pitre @ 2008-10-15 19:32 UTC (permalink / raw)
To: Andrew Morton; +Cc: david, git
In-Reply-To: <20081015122621.a9674d75.akpm@linux-foundation.org>
On Wed, 15 Oct 2008, Andrew Morton wrote:
> I do
>
> git-reset --hard HEAD
> git-reset --hard linux-next
> git-checkout linux-next
>
> and get
>
> error: Untracked working tree file 'Next/SHA1s' would be overwritten by merge.
> y
>
> grr.
What about simply:
git-checkout -f linux-next
Nicolas
^ permalink raw reply
* Re: Untracked working tree files
From: Linus Torvalds @ 2008-10-15 19:31 UTC (permalink / raw)
To: david; +Cc: Andrew Morton, git
In-Reply-To: <alpine.DEB.1.10.0810151211580.7808@asgard.lang.hm>
On Wed, 15 Oct 2008, david@lang.hm wrote:
>
> the fact that git will happily leave modified things in the working directory
> appears to be very helpful for some developers, but it's also a big land mine
> for others.
Hmm. It doesn't actually do that normally. If you switch between trees,
git will (or _should_) remove the old files that it knows about. If you
get a lot of left-over turds, there's something wrong.
It could be a git bug, of course. That said, especially considering the
source of this, I wonder if it's just that Andrew ends up using all those
non-git scripts on top of a git tree, and then that can result in git
*not* knowing about a certain file, and then when switching between trees
(with either git checkout or with git reset), the data that was created
with non-git tools gets left behind and now git will be afraid to
overwrite it.
So yes, there are ways to force it (both "git checkout -f" and "git reset
--hard" having already been mentioned), but the need for that - especially
if it's common - is a bit discouraging.
Especially since it's still possible that it's some particular mode of git
usage that leaves those things around. Andrew - have you any clue what it
is that triggers the behavior?
(By the filename, I realize it's a file that doesn't exist in one tree or
the other, and which doesn't get removed at some point. But have you had
merge failures, for example? Is it perhaps a file that was created during
a non-clean merge, and then got left behind due to the merge being
aborted? It would be interesting to know what led up to this..)
Linus
^ permalink raw reply
* Re: Usability of git stash
From: Brandon Casey @ 2008-10-15 19:31 UTC (permalink / raw)
To: Anders Melchiorsen; +Cc: git
In-Reply-To: <87wsg9acfv.fsf@cup.kalibalik.dk>
Anders Melchiorsen wrote:
> When trying to recover from that scenario, I do "git stash apply" as
> recommended by the "git stash" output. Now I still lost my index
> state, all changes are unstaged.
See the documentation, apply has a '--index' option.
-brandon
^ permalink raw reply
* Re: Untracked working tree files
From: Andrew Morton @ 2008-10-15 19:26 UTC (permalink / raw)
To: david; +Cc: git
In-Reply-To: <alpine.DEB.1.10.0810151211580.7808@asgard.lang.hm>
On Wed, 15 Oct 2008 12:14:34 -0700 (PDT)
david@lang.hm wrote:
> On Wed, 15 Oct 2008, david@lang.hm wrote:
>
> > On Wed, 15 Oct 2008, Andrew Morton wrote:
> >
> >> Date: Wed, 15 Oct 2008 11:56:54 -0700
> >> From: Andrew Morton <akpm@linux-foundation.org>
> >> To: git@vger.kernel.org
> >> Subject: Untracked working tree files
> >>
> >> I often get this (running git 1.5.6.rc0 presently):
> >>
> >> y:/usr/src/git26> git-checkout linux-next
> >> error: Untracked working tree file 'arch/x86/kernel/apic.c' would be
> >> overwritten by merge.
> >>
> >> which screws things up. I fix it by removing the offending file, which
> >> gets irritating because git bails out after the first such instance, so
> >> I need to rerun git-checkout once per file (there are sometimes tens of
> >> them).
> >
> > what I do when I run into this is "git reset --hard HEAD" which makes all
> > files in the working directory match HEAD, and then I can do the other
> > checkout.
I do
git-reset --hard HEAD
git-reset --hard linux-next
git-checkout linux-next
and get
error: Untracked working tree file 'Next/SHA1s' would be overwritten by merge.
y
grr.
> I think you can also do git checkout -f head to force the checkout to
> overwrite all files
yup, that fixed it. whee, thanks.
> the fact that git will happily leave modified things in the working
> directory appears to be very helpful for some developers, but it's also a
> big land mine for others.
>
> is there a way to disable this?
>
> David Lang
^ permalink raw reply
* Re: git-scm.com
From: Teemu Likonen @ 2008-10-15 19:26 UTC (permalink / raw)
To: PJ Hyett; +Cc: Wincent Colaiuta, git
In-Reply-To: <bab6a2ab0810151136n4f997890qd418277ea8c4aea4@mail.gmail.com>
PJ Hyett [2008-10-15 11:36 -0700]:
> For the record, Scott wasn't a GitHub employee when he wrote
> git-scm.com, nor was he paid to produce it. Turns out people don't
> always have ulterior motives, he just wanted to make a better git
> homepage.
I'm not sure what community I'm part of but I think git-scm.com is much
better homepage. I also think that the new user book[1] is better than
the one in kernel.org. So thanks for contributing to git users.
-------------
1. http://book.git-scm.com/
^ permalink raw reply
* Usability of git stash
From: Anders Melchiorsen @ 2008-10-15 19:24 UTC (permalink / raw)
To: git
I find the UI of git stash quite unfortunate.
First, I would prefer list to be the default action, so that typing
"git stash" in the hope of getting some help would not make me lose my
local changes.
When trying to recover from that scenario, I do "git stash apply" as
recommended by the "git stash" output. Now I still lost my index
state, all changes are unstaged.
The "git command subcommand" syntax seems different from other git
commands. For example, you do not delete a branch with "git branch
delete".
The default naming of stashes makes it hard to remember what I was
actually working on. Forcing me to give it a description (like branch
and commit do) would probably have saved me some time overall.
And finally, a "git stash clear" has quite far-reaching consequences.
Most other mistakes are easy to recover from, but not this one.
I offer these observations just for discussion. It has not been
possible for me to think of any backwards compatible improvements,
other than staying away from "git stash".
Cheers,
Anders.
^ permalink raw reply
* Re: Untracked working tree files
From: Andrew Morton @ 2008-10-15 19:24 UTC (permalink / raw)
To: david; +Cc: git
In-Reply-To: <alpine.DEB.1.10.0810151211580.7808@asgard.lang.hm>
On Wed, 15 Oct 2008 12:14:34 -0700 (PDT)
david@lang.hm wrote:
> On Wed, 15 Oct 2008, david@lang.hm wrote:
>
> > On Wed, 15 Oct 2008, Andrew Morton wrote:
> >
> >> Date: Wed, 15 Oct 2008 11:56:54 -0700
> >> From: Andrew Morton <akpm@linux-foundation.org>
> >> To: git@vger.kernel.org
> >> Subject: Untracked working tree files
> >>
> >> I often get this (running git 1.5.6.rc0 presently):
> >>
> >> y:/usr/src/git26> git-checkout linux-next
> >> error: Untracked working tree file 'arch/x86/kernel/apic.c' would be
> >> overwritten by merge.
> >>
> >> which screws things up. I fix it by removing the offending file, which
> >> gets irritating because git bails out after the first such instance, so
> >> I need to rerun git-checkout once per file (there are sometimes tens of
> >> them).
> >
> > what I do when I run into this is "git reset --hard HEAD" which makes all
> > files in the working directory match HEAD, and then I can do the other
> > checkout.
I was using this but it seems it wasn't in the right place in the script.
> I think you can also do git checkout -f head to force the checkout to
> overwrite all files
OK, I'll try that.
> the fact that git will happily leave modified things in the working
> directory appears to be very helpful for some developers, but it's also a
> big land mine for others.
These files weren't modified. By me, at least. git might have
"modified" them, but it has all the info necessary to know that the
file has no uncommitted changes.
> is there a way to disable this?
>
> David Lang
^ permalink raw reply
* Re: git-scm.com (was Re: Git graph on GitHub)
From: Jakub Narebski @ 2008-10-15 19:20 UTC (permalink / raw)
To: PJ Hyett; +Cc: Wincent Colaiuta, git
In-Reply-To: <bab6a2ab0810151136n4f997890qd418277ea8c4aea4@mail.gmail.com>
"PJ Hyett" <pjhyett@gmail.com> writes:
[> Wincent Colaiuta wrote:]
The above attribution was missing, BTW...
> > 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).
>
> In case there was any confusion, this is why we almost never bother
> posting to the list, because no matter what the topic, it always turns
> into why the git community hates GitHub.
Errr... for me it looks like somebodys irony detection is not working...
On the other hand it is why Scott E Fahlman invented emoticons :-)
--
Jakub Narebski
Poland
ShadeHawk on #git
^ permalink raw reply
* git-svnimport.perl bug when copy source path has a revision
From: Karl Chen @ 2008-10-15 19:11 UTC (permalink / raw)
To: Git mailing list
This looks like a bug in git-svnimport.perl. If a tag (or
branch?) is created retroactively, git-svnimport doesn't respect
the copy source revision.
To reproduce:
svnadmin create somerepo; export R=file://$PWD/somerepo
svn co $R wc && cd wc
mkdir trunk tags && svn add trunk tags && svn commit -m "" # rev 1
cd trunk
echo a > a
echo b > b
echo c > c
svn add a && svn commit -m "commit a" # rev 2
svn add b && svn commit -m "commit b" # rev 3
# Copy from revision 2 instead of HEAD:
svn cp -m "tag rev 2" $R/trunk@2 $R/tags/mytag # rev 4
svn add c && svn commit -m "commit c" # rev 5
svn ls $R/tags/mytag
# Lists only 'a'
mkdir /tmp/gitrepo && cd /tmp/gitrepo
perl /usr/share/doc/git-core/contrib/examples/git-svnimport.perl $R
git log mytag
# 'mytag' includes "commit b"; it was created as if it were tagged
# at r3; the "@2" was ignored.
^ permalink raw reply
* Re: Untracked working tree files
From: david @ 2008-10-15 19:14 UTC (permalink / raw)
To: Andrew Morton; +Cc: git
In-Reply-To: <alpine.DEB.1.10.0810151208100.7808@asgard.lang.hm>
On Wed, 15 Oct 2008, david@lang.hm wrote:
> On Wed, 15 Oct 2008, Andrew Morton wrote:
>
>> Date: Wed, 15 Oct 2008 11:56:54 -0700
>> From: Andrew Morton <akpm@linux-foundation.org>
>> To: git@vger.kernel.org
>> Subject: Untracked working tree files
>>
>> I often get this (running git 1.5.6.rc0 presently):
>>
>> y:/usr/src/git26> git-checkout linux-next
>> error: Untracked working tree file 'arch/x86/kernel/apic.c' would be
>> overwritten by merge.
>>
>> which screws things up. I fix it by removing the offending file, which
>> gets irritating because git bails out after the first such instance, so
>> I need to rerun git-checkout once per file (there are sometimes tens of
>> them).
>
> what I do when I run into this is "git reset --hard HEAD" which makes all
> files in the working directory match HEAD, and then I can do the other
> checkout.
I think you can also do git checkout -f head to force the checkout to
overwrite all files
the fact that git will happily leave modified things in the working
directory appears to be very helpful for some developers, but it's also a
big land mine for others.
is there a way to disable this?
David Lang
^ permalink raw reply
* Re: Untracked working tree files
From: david @ 2008-10-15 19:09 UTC (permalink / raw)
To: Andrew Morton; +Cc: git
In-Reply-To: <20081015115654.fb34438f.akpm@linux-foundation.org>
On Wed, 15 Oct 2008, Andrew Morton wrote:
> Date: Wed, 15 Oct 2008 11:56:54 -0700
> From: Andrew Morton <akpm@linux-foundation.org>
> To: git@vger.kernel.org
> Subject: Untracked working tree files
>
> I often get this (running git 1.5.6.rc0 presently):
>
> y:/usr/src/git26> git-checkout linux-next
> error: Untracked working tree file 'arch/x86/kernel/apic.c' would be overwritten by merge.
>
> which screws things up. I fix it by removing the offending file, which
> gets irritating because git bails out after the first such instance, so
> I need to rerun git-checkout once per file (there are sometimes tens of them).
what I do when I run into this is "git reset --hard HEAD" which makes all
files in the working directory match HEAD, and then I can do the other
checkout.
David Lang
> Should this be happening? I don't know what causes it, really. All
> I've been doing in that directory is running `git-checkout' against
> various maintainers' trees. 95% of the time this works OK but
> eventually git seems to get all confused and the above happens.
>
> Is there some way in which I can work around this with a single command
> rather than having to run git-checkout once per offending file? I
> suppose a good old `rm -rf *' would do it...
>
> Thanks.
> --
> 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: git-scm.com (was Re: Git graph on GitHub)
From: Jonathan del Strother @ 2008-10-15 19:02 UTC (permalink / raw)
To: PJ Hyett; +Cc: Wincent Colaiuta, git
In-Reply-To: <bab6a2ab0810151136n4f997890qd418277ea8c4aea4@mail.gmail.com>
On Wed, Oct 15, 2008 at 7:36 PM, PJ Hyett <pjhyett@gmail.com> wrote:
>> 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).
>
> In case there was any confusion, this is why we almost never bother
> posting to the list, because no matter what the topic, it always turns
> into why the git community hates GitHub.
Really? I thought it was usually just about how Wincent hates GitHub.
FWIW, I think github is pretty good, and git-scm.com is great.
^ permalink raw reply
* Untracked working tree files
From: Andrew Morton @ 2008-10-15 18:56 UTC (permalink / raw)
To: git
I often get this (running git 1.5.6.rc0 presently):
y:/usr/src/git26> git-checkout linux-next
error: Untracked working tree file 'arch/x86/kernel/apic.c' would be overwritten by merge.
which screws things up. I fix it by removing the offending file, which
gets irritating because git bails out after the first such instance, so
I need to rerun git-checkout once per file (there are sometimes tens of them).
Should this be happening? I don't know what causes it, really. All
I've been doing in that directory is running `git-checkout' against
various maintainers' trees. 95% of the time this works OK but
eventually git seems to get all confused and the above happens.
Is there some way in which I can work around this with a single command
rather than having to run git-checkout once per offending file? I
suppose a good old `rm -rf *' would do it...
Thanks.
^ permalink raw reply
* --diff-filter=T does not list x changes
From: Anders Melchiorsen @ 2008-10-15 18:42 UTC (permalink / raw)
To: git
>From documentation, I would expect --diff-filter to list changes in
the execute bit, but it does not. I hear on #git that this is
intended, though I still do not know how to filter on the execute bit.
Is it impossible?
Testcase:
mkdir t && cd t && git init
touch a && git add -A && git commit -m1
chmod +x a && git add -A && git commit -m2
git log --diff-filter=T # <--- shows nothing
rm -f a && ln -s b a && git add -A && git commit -m3
git log --diff-filter=T
Anders
^ permalink raw reply
* Re: git-scm.com (was Re: Git graph on GitHub)
From: PJ Hyett @ 2008-10-15 18:36 UTC (permalink / raw)
To: Wincent Colaiuta; +Cc: git
In-Reply-To: <20C9ABEC-52E5-405E-A755-C58A6359D7A9@wincent.com>
> 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).
In case there was any confusion, this is why we almost never bother
posting to the list, because no matter what the topic, it always turns
into why the git community hates GitHub.
I really don't understand the disdain for a company that's made git
accessible to a much wider audience in less than a year. I kinda
thought we'd all be on the same team.
For the record, Scott wasn't a GitHub employee when he wrote
git-scm.com, nor was he paid to produce it. Turns out people don't
always have ulterior motives, he just wanted to make a better git
homepage.
-PJ
^ permalink raw reply
* 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
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