* Re: Untracked working tree files
From: Junio C Hamano @ 2008-10-15 22:06 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Andrew Morton, david, Git Mailing List
In-Reply-To: <alpine.LFD.2.00.0810151311210.3288@nehalem.linux-foundation.org>
Linus Torvalds <torvalds@linux-foundation.org> writes:
> On Wed, 15 Oct 2008, Linus Torvalds wrote:
>>
> It's quite possible that we should remove unmerged entries. Except that's
> not how our internal 'read_cache_unmerged()' function works. It really
> just ignores them, and throws them on the floor. We _could_ try to just
> turn them into a (since) stage-0 entry.
>
> Junio?
I'd agree that dropping unmerged entries to stage-0 when we can would make
sense. An conflicted existing path would get an stage-0 entry in the
index, which is compared with the switched-to HEAD (which could be the
same as the current one when "git reset --hard" is run without a rev), we
notice that they are different and the index entry and the work tree path
is overwritten by the version from the switched-to HEAD. For a new path
that a failed merge tried to bring in, we notice that the switched-to HEAD
does not have that path and happily remove it from the index and from the
work tree. All will go a lot smoother than the current code.
I am not sure what should happen when we can't drop the unmerged entry
down to stage-0 due to D/F conflicts, though. IIRC, read-tree proper
would not touch the work tree in such a case, but merge-recursive creates
our and their versions with funny suffixes, which will not be known to the
index and will be left in the working tree.
^ permalink raw reply
* Re: Super module pointing to submodule branch instead of a specific commit?
From: Avery Pennarun @ 2008-10-15 21:57 UTC (permalink / raw)
To: skillzero; +Cc: git
In-Reply-To: <2729632a0810151416l3a16f6d6x4e32e457d26496bc@mail.gmail.com>
On Wed, Oct 15, 2008 at 5:16 PM, <skillzero@gmail.com> wrote:
> Is there a way to have a super module point to a branch of a submodule
> instead of a specific commit ID?
In some sense, this is too simple to be supported by git-submodule.
You might want to try the "ext" tool instead:
http://nopugs.com/2008/09/06/ext-tutorial
Have fun,
Avery
^ permalink raw reply
* Re: BUG: git rev-list segfaults
From: Nanako Shiraishi @ 2008-10-15 21:22 UTC (permalink / raw)
To: Stephan Springl; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0810152034040.7572@rosenkohl.springl.homeip.net>
Stephan Springl <springl-git@bfw-online.de> writes:
> git rev-list segfaults when crossing a merge commit when given
> --bisect-vars and --first-parent.
This is an old news, isn't it?
http://thread.gmane.org/gmane.comp.version-control.git/93416/focus=93420
--
Nanako Shiraishi
http://ivory.ap.teacup.com/nanako3/
^ permalink raw reply
* Re: [PATCH] Fix mkpath abuse in dwim_ref/sha1_name.c
From: Junio C Hamano @ 2008-10-15 21:22 UTC (permalink / raw)
To: Alex Riesen; +Cc: Git Mailing List, Shawn O. Pearce
In-Reply-To: <20081015062039.GA3775@blimp.localdomain>
Alex Riesen <raa.lkml@gmail.com> writes:
> Junio C Hamano, Wed, Oct 15, 2008 01:17:52 +0200:
>> "Alex Riesen" <raa.lkml@gmail.com> writes:
>> >
>> > Otherwise the function sometimes fail to resolve obviously correct refnames,
>> > because the string data pointed to by "ref" argument were reused.
>> >
>> But your patch instead rewrites the computation of str2 by bypassing the
>> call to "another_function_that_uses_get_pathname()" and duplicating its
>> logic, which I do not think is a viable approach in the longer term.
>
> There is not enough logic to bypass there. It's just a dumb sprintf!
But didn't you lose call to cleanup_path()?
^ permalink raw reply
* Re: builtin conversion between tabs and spaces
From: Stefan Karpinski @ 2008-10-15 21:18 UTC (permalink / raw)
To: Jonathan del Strother; +Cc: Alex Riesen, Git Mailing List, Johannes Sixt
In-Reply-To: <57518fd10810151402p4ea3283anf4b3d175c4e82425@mail.gmail.com>
>> if you consistently use spaces, then tabs_to_spaces will
>> always give you back your original version; if you consistently use
>> tabs, then spaces_to_tabs will give you back your original version. If
>> you use some crazy mix of the two, you cannot reconstruct your
>> original without remembering where there were tabs versus spaces,
>
> Just IMO, a crazy mix of tabs and spaces is the only _sane_ thing to
> do. Using tabs for the initial indentation, plus spaces for alignment
> of function arguments / comments / whatever, is the only way of
> getting a layout that will both look right regardless of the tab size,
> and allow a viewer to alter the indentation size.
That's not what I would call a "crazy" mix of tabs and spaces, but
rather a *sane* mix of tabs and spaces. That can consistently be
reproduced, and is in fact what the spaces_to_tabs function included
above produces. The sane consistent formats as I see it are:
1) use spaces for everything
2) use tabs for indentation, spaces for everything else
3) use tabs for indentation and alignment
If you know the tab size, you can reproduce any of these from the
others, except that #3 is a little tricky since there's places where
the tab/space issue can be ambiguous. I actually think that keeping
the repo version with tab-based indentation is a very sane thing to
do. However, I'd still like to be able to edit the files using soft
tabs, largely because any program that doesn't know what my tab size
should be applies its own interpretation and makes the code look
terrible (think terminal output for diff, cat, less, etc.)
On the other hand, a *crazy* mix of tabs and spaces is where some
indentation is done with spaces while other indentation is done with
tabs. Even crazier is a single line where the indentation is a mixture
of tabs and spaces. I think that just about everyone can agree that
this is not only crazy, but evil and is the kind of thing one really
wants to avoid in a code base. Unfortunately, when developers disagree
on their standard settings, it's very, very hard to avoid precisely
this kind of mess. My idea is to enable git to prevent this sort of
insanity if configured to do so.
^ permalink raw reply
* Super module pointing to submodule branch instead of a specific commit?
From: skillzero @ 2008-10-15 21:16 UTC (permalink / raw)
To: git
Is there a way to have a super module point to a branch of a submodule
instead of a specific commit ID? I have a repository of common code
I'd like to use with a several different projects (each project has a
repository of its own). I want those super repositories to reference
the "stable" branch of this shared repository so that whenever they
pull one of these super modules, they get any changes made to stable
branch of the shared repository. When creating a tag of the super
module, I still want it to tag based on the commit ID of the submodule
(like I think it does today).
>From what I can tell, I seem to have to commit to the submodule then
commit the new commit ID of the submodule to every super module it is
a member of. That's somewhat tedious, but the larger problem is that
not all everyone with commit access to the submodule will has access
to all the super modules (they may not even know they exist).
^ permalink raw reply
* Re: git-scm.com (was Re: Git graph on GitHub)
From: Aaron Cohen @ 2008-10-15 21:04 UTC (permalink / raw)
To: Garry Dolley; +Cc: PJ Hyett, Wincent Colaiuta, git
In-Reply-To: <20081015201230.GA9534@garry-x300.arpnetworks.com>
On Wed, Oct 15, 2008 at 4:12 PM, Garry Dolley <gdolley@arpnetworks.com> wrote:
> 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. :)
>
For the record, I'm not part of either community and find things to
dislike about both of them.
git.or.cz: I personally prefer its plain style, but it has way too
much information on the front page (why is so much download
information on that page rather than hidden behind the "download" link
that currently just goes to an ftp directory?)
git-scm.com: Much better organized, but suffers from web 2.0
shininess. Also, every time I look at it my eyes have to read
EVERYTHING to figure out what ANYTHING is. For instance, why is there
that random column of "projects using git" that seems to only exist to
distract me from the important stuff?
^ permalink raw reply
* Re: builtin conversion between tabs and spaces
From: Jonathan del Strother @ 2008-10-15 21:02 UTC (permalink / raw)
To: Stefan Karpinski; +Cc: Alex Riesen, Git Mailing List
In-Reply-To: <d4bc1a2a0810151352s6c963e32jc4f492a7c84841dc@mail.gmail.com>
On Wed, Oct 15, 2008 at 9:52 PM, Stefan Karpinski
<stefan.karpinski@gmail.com> wrote:
> if you consistently use spaces, then tabs_to_spaces will
> always give you back your original version; if you consistently use
> tabs, then spaces_to_tabs will give you back your original version. If
> you use some crazy mix of the two, you cannot reconstruct your
> original without remembering where there were tabs versus spaces,
Just IMO, a crazy mix of tabs and spaces is the only _sane_ thing to
do. Using tabs for the initial indentation, plus spaces for alignment
of function arguments / comments / whatever, is the only way of
getting a layout that will both look right regardless of the tab size,
and allow a viewer to alter the indentation size.
^ permalink raw reply
* Re: builtin conversion between tabs and spaces
From: Stefan Karpinski @ 2008-10-15 20:55 UTC (permalink / raw)
To: Johannes Sixt; +Cc: Git Mailing List
In-Reply-To: <48F58D1C.2040208@viscovery.net>
>> This led me to wonder if it wouldn't make sense to have this
>> conversion ability built into git.
>
> This wouldn't help your case a lot. It is still at the discretion of each
> individual repository owner to enable the conversion. (You didn't mean to
> make this conversion mandatory, did you?)
This would all be completely discretionary, of course. I just thought
that the issue was complicated enough and the problem of mixed spaces
and tabs in source code ubiquitous enough that it might be worth
"solving" correctly in git itself.
> BTW, you don't need to change git code to achieve this. It's sufficient to
> install a suitable "clean" filter:
>
> echo "*.c filter=c-code" > .git/info/attributes
> git config filter.c-code.clean tabs2spaces
>
> where tabs2spaces is your utility that does the conversion.
That was the first thing I did—in ruby first, then in C. The ruby
version is *way* too slow to use on any number of files—and the
typical use case is that most of your files are source code and so
will have this applied to them. On the other hand, the ruby script (or
perl or whatever) is portable, so I can send it to my Windows-based
developers and have them use it too.
But the speed issue is pretty crucial, so I rewrote the thing as an
external C program, which is obviously much faster. But it's still
noticably slower than native git checkout though. Worse still, now the
filter script isn't portable, so I have to cross-compile it and give
every developer the version that works on their platform and make sure
that they have their path setup correctly, etc.
Having the conversion built into git would
1) have native git checkout speed (I've tried it and it's not
noticable slower than normal git checkouts);
2) be naturally portable to anywhere git works.
Now, if I thought this was a thing that would only benefit me, I would
never bring it up. However, it seems like something that a lot of
projects might want to use to ensure standard spacing in their source
files. Moreover, since developers feel strongly about using tabs or
spaces, it would be beneficial for individuals too. I think there's
enough complex issues that solving it once-and-for-all might be worth
a shot.
^ permalink raw reply
* Re: builtin conversion between tabs and spaces
From: Stefan Karpinski @ 2008-10-15 20:52 UTC (permalink / raw)
To: Alex Riesen; +Cc: Git Mailing List
In-Reply-To: <20081015062539.GB3775@blimp.localdomain>
> Is your conversion two-way? IOW, is it possible to convert the
> converted file and get the original? (Because all the existing
> conversions are reversible)
Yes and no. The CRLF conversion isn't always invertable—it is so long
as your use of CRLF/LF is consistent. The tab/space conversion is
similar: if you consistently use spaces, then tabs_to_spaces will
always give you back your original version; if you consistently use
tabs, then spaces_to_tabs will give you back your original version. If
you use some crazy mix of the two, you cannot reconstruct your
original without remembering where there were tabs versus spaces,
which information either filter destroys. But that's the same as the
CRLF conversion. You could enable a warning when worktree file has an
inconsistent mixture of tabs and spaces, like there is for
inconsistent CRLF files.
On Tue, Oct 14, 2008 at 11:25 PM, Alex Riesen <raa.lkml@gmail.com> wrote:
> Stefan Karpinski, Wed, Oct 15, 2008 03:44:10 +0200:
>> I find myself really wanting to enforce standards in the use of spaces
>> versus tabs. I deal with some unruly programmers who refuse to set
>> their editors to use soft tabs, but I *hate* tabs in the repo. And of
>> course others feel equally strongly about keeping only tabs in the
>> repo (e.g. the git repo).
>>
>> This led me to wonder if it wouldn't make sense to have this
>> conversion ability built into git. The following patch implements this
>> functionality. It still needs work—it's not meant to be final, just to
>> give an idea—but I just wanted to see if people on the git list
>> thought this sort of thing would be worthwhile at all.
>
> Is your conversion two-way? IOW, is it possible to convert the
> converted file and get the original? (Because all the existing
> conversions are reversible)
>
^ permalink raw reply
* Re: What's in git.git (Oct 2008, #03; Tue, 14)
From: Shawn O. Pearce @ 2008-10-15 20:36 UTC (permalink / raw)
To: Junio C Hamano
Cc: Brandon Casey, git, Arjen Laarhoven, Jeff King, Mike Ralphson
In-Reply-To: <7vhc7dr4f8.fsf@gitster.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> wrote:
> "Shawn O. Pearce" <spearce@spearce.org> writes:
>
> >> If we can add a test case to demonstrate the existing breakage, I think we
> >> can (and should) cherry-pick it to 'maint'.
> >
> > Yes, it probably should have gone to maint. No, it didn't go there.
> > Temporary lapse in maintainer judgement.
>
> That is Ok. I do the same all the time (and I try to rewind and rebuild
> when I spot it before pushing the results out, but I am not always
> successful).
Oh, trust me, I had many times where I had to rebuild everything
for that day's push because I forgot about a patch that should
be in maint. At least your Meta/RB and Meta/PU scripts make it
somewhat painless, that and Git's ability to just hard reset a
branch back to what I last published. ;-)
I just utterly failed to do it that morning. Or at least failed
to do it for this change.
> I just wanted to see if there was any particular reason not to have this
> on 'maint'.
Nope.
--
Shawn.
^ permalink raw reply
* Re: BUG: git rev-list segfaults
From: Avery Pennarun @ 2008-10-15 20:32 UTC (permalink / raw)
To: Stephan Springl; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0810152034040.7572@rosenkohl.springl.homeip.net>
On Wed, Oct 15, 2008 at 3:00 PM, Stephan Springl
<springl-git@bfw-online.de> wrote:
> git rev-list segfaults when crossing a merge commit when given --bisect-vars
> and --first-parent. This is on branches master, next, and pu from
> git://git.kernel.org/pub/scm/git/git.git right now.
See this thread:
http://kerneltrap.org/mailarchive/git/2008/8/23/3050004
Unfortunately I worked around the crash in the scripts I was working
on, and I have since been sidetracked, so I haven't been able to test
Junio's fix. It's still on my ever-growing to-do list. If you try it
and it works for you, please let him know.
Thanks,
Avery
^ permalink raw reply
* Re: Untracked working tree files
From: Andrew Morton @ 2008-10-15 20:30 UTC (permalink / raw)
To: Linus Torvalds; +Cc: david, git, gitster
In-Reply-To: <alpine.LFD.2.00.0810151311210.3288@nehalem.linux-foundation.org>
On Wed, 15 Oct 2008 13:23:50 -0700 (PDT)
Linus Torvalds <torvalds@linux-foundation.org> wrote:
>
>
> On Wed, 15 Oct 2008, Linus Torvalds wrote:
> >
> > - a merge goes south with a data conflict, and since it's all automated,
> > you just want to throw it away.
>
> Actually, with your filename, I suspect the conflict would be not a real
> file content, but more of a "delete" conflicting with a modification to
> that file. IOW, I'm guessing that the thing you hit with
> arch/x86/kernel/apic.c was that some branch you pulled:
>
> - created that file
>
> - deleted arch/x86/kernel/apic_[32|64].c
>
> - the old file got marked as a rename source for the new apic.c and
> there was a data conflict when trying to apply the changes.
>
> as a result, your working tree would have that "apic.c" file in it, but
> with conflict markers, and marked as unmerged.
That sounds likely. I suspect things were especially bad today because
I accidentally pulled four-week-old linux-next, which had over 500
rejects in it.
^ permalink raw reply
* Re: What's in git.git (Oct 2008, #03; Tue, 14)
From: Junio C Hamano @ 2008-10-15 20:26 UTC (permalink / raw)
To: Shawn O. Pearce
Cc: Brandon Casey, git, Arjen Laarhoven, Jeff King, Mike Ralphson
In-Reply-To: <20081015202032.GD28802@spearce.org>
"Shawn O. Pearce" <spearce@spearce.org> writes:
>> If we can add a test case to demonstrate the existing breakage, I think we
>> can (and should) cherry-pick it to 'maint'.
>
> Yes, it probably should have gone to maint. No, it didn't go there.
> Temporary lapse in maintainer judgement.
That is Ok. I do the same all the time (and I try to rewind and rebuild
when I spot it before pushing the results out, but I am not always
successful).
I just wanted to see if there was any particular reason not to have this
on 'maint'.
Thanks.
^ permalink raw reply
* Re: Untracked working tree files
From: Linus Torvalds @ 2008-10-15 20:23 UTC (permalink / raw)
To: Andrew Morton; +Cc: david, Git Mailing List, Junio C Hamano
In-Reply-To: <alpine.LFD.2.00.0810151256410.3288@nehalem.linux-foundation.org>
On Wed, 15 Oct 2008, Linus Torvalds wrote:
>
> - a merge goes south with a data conflict, and since it's all automated,
> you just want to throw it away.
Actually, with your filename, I suspect the conflict would be not a real
file content, but more of a "delete" conflicting with a modification to
that file. IOW, I'm guessing that the thing you hit with
arch/x86/kernel/apic.c was that some branch you pulled:
- created that file
- deleted arch/x86/kernel/apic_[32|64].c
- the old file got marked as a rename source for the new apic.c and
there was a data conflict when trying to apply the changes.
as a result, your working tree would have that "apic.c" file in it, but
with conflict markers, and marked as unmerged.
When you then do "git reset --hard", it will just ignore unmerged entries,
and since the original tree (and the destination tree) match, and neither
of them contain apic.c either, git will totally ignore that file and not
even try to remove it (since it wasn't there originally).
> So you do "git reset --force" to do that.
It's "--hard", not "--force". Yeah, the git reset flags are insane. As is
the default action, for that matter. It's one of the earliest interfaces,
and it's stupid and reflects git internal implementations rather than what
we ended up learning about using git later. Oh, well.
But 'git checkout -f' (which is nicer from a user interface standpoint)
has the exact same logic and I think shares all the implementation. I
think they both end up just calling "git read-tree --reset -u".
It's quite possible that we should remove unmerged entries. Except that's
not how our internal 'read_cache_unmerged()' function works. It really
just ignores them, and throws them on the floor. We _could_ try to just
turn them into a (since) stage-0 entry.
Junio?
Linus
^ permalink raw reply
* Re: Untracked working tree files
From: Andrew Morton @ 2008-10-15 20:23 UTC (permalink / raw)
To: Linus Torvalds; +Cc: david, git
In-Reply-To: <alpine.LFD.2.00.0810151256410.3288@nehalem.linux-foundation.org>
On Wed, 15 Oct 2008 13:08:36 -0700 (PDT)
Linus Torvalds <torvalds@linux-foundation.org> wrote:
>
>
> 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"?
well, this script has been hacked on so many times I'm not sure what
it does any more.
Presently the main generate-a-diff function is
doit()
{
tree=$1
upstream=$2
cd $GIT_TREE
git checkout "$upstream"
git reset --hard "$upstream"
git fetch "$tree" || exit 1
git merge --no-commit 'test merge' HEAD FETCH_HEAD > /dev/null
{
git_header "$tree"
git log --no-merges ORIG_HEAD..FETCH_HEAD
git diff --patch-with-stat ORIG_HEAD
} >$PULL/$tree.patch
{
echo DESC
echo $tree.patch
echo EDESC
git_header "$tree"
git log --no-merges ORIG_HEAD..FETCH_HEAD
} >$PULL/$tree.txt
git reset --hard "$upstream"
}
usually invoked as
doit origin v2.6.27
doit origin linux-next
etc.
the above seemed fairly busted, so I'm now using
git checkout -f "$upstream"
git reset --hard "$upstream"
git fetch "$tree" || exit 1
which seems a bit more sensible. Perhaps I should do the reset before
the checkout, dunno.
That function has been through sooooooo many revisions and each time
some scenario get fixed (more like "improved"), some other scenario
gets busted (more like "worsened"). The above sorta mostly works,
although it presently generates thirty-odd rejects against
git://git.kernel.org/pub/scm/linux/kernel/git/x86/linux-2.6-tip.git#auto-latest,
which is way above my fix-it-manually threshold. linux-next is still
dead because it's taking Stephen over two days to fix the mess he's
been fed so I'm madly rebasing everything on mainline over here.
> 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.
didn't know about --force.
> - 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.
Yeah, there's no easy solution here, and I suspect the real solution is
"read programmer's mind". Providing a reliable override (like -f) is a
sensible solution.
> (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.
OK, I'll try git clean -dqfx if it blows up again.
> 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).
^ permalink raw reply
* BUG: git rev-list segfaults
From: Stephan Springl @ 2008-10-15 19:00 UTC (permalink / raw)
To: git
[-- Attachment #1: Type: TEXT/PLAIN, Size: 1321 bytes --]
Hi,
git rev-list segfaults when crossing a merge commit when given
--bisect-vars and --first-parent. This is on branches master, next, and
pu from git://git.kernel.org/pub/scm/git/git.git right now.
Reproduce it using git's git repository like this:
git rev-list --bisect-vars --first-parent \
80bfd76af7ac817d4a4b9b7d54485..67faaaba8338cf59c212ce5239eeb
Without either --first-parent or --bisect-vars it works.
Thank you for your work on git. When we introduced CVS in our development
some ten years ago, after a few weeks we could not imagine how we could
have got any work done without it. When we started using git, we found
this former step was tiny compared to the increase in productivity we
experienced switching from CVS to git.
Regards
Stephan
--
Stephan Springl BFW Werner Völk GmbH
Energiemesstechnik & Service
Drosselgasse 5
D-82166 Gräfelfing
Germany
Geschäftsführer: Georg F. Völk
HRB 44779 Amtsgericht München
USt.-ID: DE129301566
^ permalink raw reply
* Re: What's in git.git (Oct 2008, #03; Tue, 14)
From: Shawn O. Pearce @ 2008-10-15 20:20 UTC (permalink / raw)
To: Junio C Hamano
Cc: Brandon Casey, git, Arjen Laarhoven, Jeff King, Mike Ralphson
In-Reply-To: <7vljwpr6lr.fsf@gitster.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> wrote:
> 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.
My fault. I didn't have a reason for putting it on master.
My reason really boiled down to "I can't decide where this goes,
oops, got distracted by something, git checkout master, git am,
move on...".
Yes, it probably should have gone to maint. No, it didn't go there.
Temporary lapse in maintainer judgement.
> If we can add a test case to demonstrate the existing breakage, I think we
> can (and should) cherry-pick it to 'maint'.
Probably. Sorry for the cherry-pick being required here.
--
Shawn.
^ permalink raw reply
* 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
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