* Re: Untracked working tree files
From: david @ 2008-10-15 20:17 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Andrew Morton, git
In-Reply-To: <alpine.LFD.2.00.0810151247560.3288@nehalem.linux-foundation.org>
On Wed, 15 Oct 2008, Linus Torvalds wrote:
> On Wed, 15 Oct 2008, david@lang.hm wrote:
>>
>> I see it fairly frequently when switching between different branches of a
>> project.
>
> So, at least for any normal switch, assuming file 'a' doesn't exist in the
> other branch, you really should have a few different cases:
>
> - you have a dirty file, and git should say something like
>
> error: You have local changes to 'file'; cannot switch branches.
>
> because it refuses to modify the file to match the other branch (which
> includes removing it) if it doesn't match the index.
>
> So this case shouldn't leave anything behind.
>
> - You have that extra file, but it's not in the index.
>
> If it's in your current HEAD, we should still notice it with something
> like:
>
> error: Untracked working tree file 'tree' would be removed by merge.
>
> because now it's untracked (not in the index), but the switching
> between branches tries to essentially "apply" the difference between
> your current HEAD and the new branch, and finds that the difference
> involves removing a file that git isn't tracking.
one place that I know I've run into it frequently is in an internal
project that I did not properly setup .gitignore and did "git add ." and
"git commit -a" to. that projects repository contains the compiled
binaries and I frequently get these errors when switching trees.
that sounds like the first case.
I've seen discussion of a new sequencer functionality, would it allow me
to define a .gitignore file and re-create the repository as if that file
had existed all along?
David Lang
> See?
>
> HOWEVER.
>
> If you're used to doing "git checkout -f" or "git reset --hard", both of
> those checks are just ignored. After all, you asked for a forced switch.
>
> And at least in the second case, what I think happens is that git won't
> remove the file it doesn't know about, so you'll have a "turd" left
> around.
>
> So yes, you can certainly get these kinds of left-overs, but they really
> should be only happening if you "force" something. Do you do that often?
>
> Linus
>
^ permalink raw reply
* Re: git-scm.com (was Re: Git graph on GitHub)
From: Garry Dolley @ 2008-10-15 20:12 UTC (permalink / raw)
To: PJ Hyett; +Cc: Wincent Colaiuta, git
In-Reply-To: <bab6a2ab0810151136n4f997890qd418277ea8c4aea4@mail.gmail.com>
On Wed, Oct 15, 2008 at 11:36:10AM -0700, PJ Hyett 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.
For the record, I'm a part of the git community and I like GitHub
quite a bit. :)
--
Garry Dolley
ARP Networks, Inc.
http://scie.nti.st
Los Angeles County REACT, Unit 336
WQGK336
^ permalink raw reply
* Re: Untracked working tree files
From: Linus Torvalds @ 2008-10-15 20:08 UTC (permalink / raw)
To: Andrew Morton; +Cc: david, git
In-Reply-To: <20081015124949.b657a8db.akpm@linux-foundation.org>
On Wed, 15 Oct 2008, Andrew Morton wrote:
>
> I treat my git directory as a read-only thing. I only ever modify it
> with git commands.
Ok.
> > (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..)
>
> That's certainly a possibility - I get a lot of merge failures. A real
> lot. And then quite a bit of rebasing goes on, especially in
> linux-next. And then there's all the other stuff which Stephen does on
> top of the underlying trees to get something releasable happening.
Is "git checkout -f" part of the scripting? Or "git reset --hard"?
So what I could imagine is happening is:
- you have a lot of automated merging
- a merge goes south with a data conflict, and since it's all automated,
you just want to throw it away. So you do "git reset --force" to do
that.
- but what "git reset --hard" means is to basically ignore all error
cases, including any unmerged entries that it just basically ignores.
- so it did set the tree back, but the whole point of "--hard" is that it
ignores error cases, and doesn't really touch them.
Now, I don't think we ever really deeply thought about what the error
cases should do when they are ignored. Should the file that is in some
state we don't like be removed? Or should we just ignore the error and
return without removing the file? Generally git tries to avoid touching
things it doesn't understand, but I do think this may explain some pain
for you, and it may not be the right thing in this case.
(And when I say "this case", I don't really know whether you use "git
checkout -f" or "git reset --hard" or something else, so I'm not even
going to say I'm sure exactly _which_ case "this case" actually us :)
Of course, the cheesy way for you to fix this may be to just add a
git clean -dqfx
to directly after whatever point where you decide to reset and revert to
an earlier stage. That just says "force remove all files I don't know
about, including any I might ignore". IOW, "git reset --hard" will
guarantee that all _tracked_ files are reset, but if you worry about some
other crud that could have happened due to a failed merge, that additional
"git clean" may be called for.
Of course, it's going to read the whole directory tree and that's not
really cheap, but especially if you only do this for error cases, it's
probably not going to be any worse. And I'm assuming you're not compiling
in that tree, so you probably don't want to save object files (you can
remove the "x" part, but then you could still at least in theory get a
filename clash with something that is ignored and thus didn't get cleaned
up).
Linus
^ permalink raw reply
* Re: [PATCH] doc: enhance git describe --tags help
From: Uwe Kleine-König @ 2008-10-15 20:05 UTC (permalink / raw)
To: Shawn O. Pearce
Cc: Pierre Habouzit, Erez Zilber, git@vger.kernel.org, open-iscsi,
Junio C Hamano, Andreas Ericsson
In-Reply-To: <20080930222646.GP21310@spearce.org>
Hi Shawn,
On Tue, Sep 30, 2008 at 03:26:46PM -0700, Shawn O. Pearce wrote:
> Its a change in behavior. Today users are getting annotated tags
> back from `git describe --tags` even if lightweight tags are closer.
> Once this code change is in they'll start to get lightweight tags.
>
> Previously `git describe --tags` never gave a lightweight tag if
> there was at least one annotated tag in the history. Now it will
> start to give the lightweight tags. Some users may see that as a
> breakage.
Right, and previously `git describe` didn't differ from `git describe
--tags` in the presence of at least one annotated tag. This is the main
reason for me to believe that this breakage doesn't hurt that much.
> Especially after the 1.6 "dashless" change...
I didn't get why the "dashless" change is relevant here. IMHO this one
is/was harder for the user because it changed every command, and they
had to start using bash completion if they didn't before. This one
should only hurt the users of "git describe --tags", and I assume there
are not that many. Still more as the documentation describes the
behaviour the patch implements.
Best regards
Uwe
^ permalink raw reply
* Re: Untracked working tree files
From: Linus Torvalds @ 2008-10-15 19:56 UTC (permalink / raw)
To: david; +Cc: Andrew Morton, git
In-Reply-To: <alpine.DEB.1.10.0810151240220.7808@asgard.lang.hm>
On Wed, 15 Oct 2008, david@lang.hm wrote:
>
> I see it fairly frequently when switching between different branches of a
> project.
So, at least for any normal switch, assuming file 'a' doesn't exist in the
other branch, you really should have a few different cases:
- you have a dirty file, and git should say something like
error: You have local changes to 'file'; cannot switch branches.
because it refuses to modify the file to match the other branch (which
includes removing it) if it doesn't match the index.
So this case shouldn't leave anything behind.
- You have that extra file, but it's not in the index.
If it's in your current HEAD, we should still notice it with something
like:
error: Untracked working tree file 'tree' would be removed by merge.
because now it's untracked (not in the index), but the switching
between branches tries to essentially "apply" the difference between
your current HEAD and the new branch, and finds that the difference
involves removing a file that git isn't tracking.
See?
HOWEVER.
If you're used to doing "git checkout -f" or "git reset --hard", both of
those checks are just ignored. After all, you asked for a forced switch.
And at least in the second case, what I think happens is that git won't
remove the file it doesn't know about, so you'll have a "turd" left
around.
So yes, you can certainly get these kinds of left-overs, but they really
should be only happening if you "force" something. Do you do that often?
Linus
^ permalink raw reply
* Re: Untracked working tree files
From: Andrew Morton @ 2008-10-15 19:49 UTC (permalink / raw)
To: Linus Torvalds; +Cc: david, git
In-Reply-To: <alpine.LFD.2.00.0810151219120.3288@nehalem.linux-foundation.org>
On Wed, 15 Oct 2008 12:31:40 -0700 (PDT)
Linus Torvalds <torvalds@linux-foundation.org> 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.
I treat my git directory as a read-only thing. I only ever modify it
with git commands.
> 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?
Sorry, no, I haven't seen a pattern.
> (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..)
That's certainly a possibility - I get a lot of merge failures. A real
lot. And then quite a bit of rebasing goes on, especially in
linux-next. And then there's all the other stuff which Stephen does on
top of the underlying trees to get something releasable happening.
^ permalink raw reply
* 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
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