* Re: missing git features (was: Re: Errors GITtifying GCC and Binutils)
From: Carl Worth @ 2006-03-24 16:44 UTC (permalink / raw)
To: Andreas Ericsson; +Cc: git
In-Reply-To: <4423ED16.9080504@op5.se>
[-- Attachment #1: Type: text/plain, Size: 859 bytes --]
On Fri, 24 Mar 2006 13:59:02 +0100, Andreas Ericsson wrote:
> See how Junio does with next and pu and recommend your users to do the
> same. There's no way of pulling a rebased branch, because the rebasing
> destroys ancestry information, meaning the original commits other people
> have cease to exist in your repository.
But the "other people" still have those commits, so it should be
rather straightforward for a tool to also perform a rebase for them
when doing this kind of "rebased pull". I think there's just a single
arc of data missing showing where a rebased commit object came from.
So this sounds solvable, and it is something I would very much enjoy
having, (call me funny, but I prefer to rebase and avoid a merge
commit when looking at independent lines of development for which
logically there shouldn't be any "merge" required).
-Carl
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH] cogito: Avoid slowness when timewarping large trees.
From: Shawn Pearce @ 2006-03-24 16:43 UTC (permalink / raw)
To: Jeff King; +Cc: Junio C Hamano, git
In-Reply-To: <20060324112246.GA5220@coredump.intra.peff.net>
Jeff King <peff@peff.net> wrote:
> On Fri, Mar 24, 2006 at 03:01:35AM -0800, Junio C Hamano wrote:
>
> > > git-read-tree --reset "$base"
> > Exactly. That's what I meant. Thanks.
>
> Hmm. That doesn't actually work, though. If I have a history like this:
>
> $ cg-init -m "initial"
> $ cg-tag initial
> $ echo contents >file
> $ cg-add file
> $ cg-commit -m "added file"
>
> and I try this:
> $ echo changes >file
> $ git-read-tree --reset master
> $ git-read-tree -m -u master initial
>
> I get this:
> fatal: Entry 'file' not uptodate. Cannot merge.
>
> If I do an update-index before the second read-tree, then I simply get:
> fatal: Entry 'file' would be overwritten by merge. Cannot merge.
>
> Is there something I'm missing, or is a 'git reset --hard' really what
> we want here (in that case, the fact that git reset changes the HEAD
> might be a problem)?
This is sort of what I'm doing in pg-reset-tree, which is kind
of like 'git-reset --hard' but I think it is faster when $force
is unset:
# Remove files left over from merge conflicts and files which are
# somehow modified. If this makes a directory empty it may have
# been a new directory so delete that too.
#
(git-ls-files -z \
--others \
--ignored \
--exclude='*#1' \
--exclude='*#2' \
--exclude='*#3' \
--exclude='*.rej'
git-diff-index --name-only -z HEAD
) | perl -n0e 'chomp; unlink; 1 while (s,/[^/]*$,, && rmdir)'
# Rebuild the index and working directory. We'll only checkout the
# files which don't exist. This resets the modified files we deleted
# just above; remaining files will have their stat information updated
# in the index.
#
git-read-tree --reset HEAD &&
git-checkout-index --index --all $force \
|| die "Can't reset index and working directory."
# Now that the working directory is clean we can safely merge it to
# to our target tree, $new_base.
#
git-read-tree -m -u HEAD $new_base
The $force in git-checkout-index may or may not be set to
'--force'; its usually not set as its not usually necessary.
Unfortunately I've got a case where I'm mounting a directory
exported by SAMBA onto a Windows 2000 system and if I don't include
--force during git-checkout-index it doesn't work right about 1/3
of the time. (It appears to be bad stat information coming from
Cygwin/Windows/SAMBA/Solaris.)
You can't skip the git-checkout-index step (I've tried) as the
ls-files/diff-index above causes the modified files (in your test
above 'changes') to disappear from the working directory and the
read-tree may not bring it back.
Now that I think about it isn't this sort of where you were before
in cg-seek?
--
Shawn.
^ permalink raw reply
* Re: Fix branch ancestry calculation
From: Keith Packard @ 2006-03-24 16:38 UTC (permalink / raw)
To: Linus Torvalds; +Cc: keithp, David Mansfield, David Mansfield, Git Mailing List
In-Reply-To: <Pine.LNX.4.64.0603240739360.26286@g5.osdl.org>
[-- Attachment #1: Type: text/plain, Size: 2593 bytes --]
On Fri, 2006-03-24 at 07:46 -0800, Linus Torvalds wrote:
>
> On Fri, 24 Mar 2006, David Mansfield wrote:
> >
> > Anyway, I'd like to nail down some of the other nagging ancestry/branch point
> > problems if possible.
>
> What I considered doing was to just ignore the branch ancestry that cvsps
> gives us, and instead use whatever branch that is closest (ie generates
> the minimal diff). That's really wrong too (the data just _has_ to be in
> CVS somehow), but I just don't know how CVS handles branches, and it's how
> we'd have to do merges if we were to ever support them (since afaik, the
> merge-back information simply doesn't exists in CVS).
cvsps is more of a problem than cvs itself. Per-file branch information
is readily available in the ,v files; each version has a list of
branches from that version, and there are even tags marking the names of
them. One issue that I've discovered is when files have differing branch
structure in the same repository. That happens when a branch is created
while files are checked out on different branches. I'm not quite sure
what to do in this case; I've been trying several approaches and none
seem optimal. One remaining plan is to just attach such branches by
date, but that assumes that the first commit along a branch occurs
shortly after the branch is created (which isn't required).
Of course, this branch information is only created when a change is made
to the file along said branch, so most of the repository will lack
precise branch information for each branch. When you create a child
branch, the files with no commits in the parent branch will never get
branch information, so the child branch will be numbered as if it were a
branch off of the grandparent. Globally, it is possible to reconstruct
the entire branch structure.
> Suddenly it was a perfectly reasonable system: the fact that you can only
> merge once (between working tree and repo) is perfectly reasonable when
> there is only one branch and checking in requires you to have updated
> first. All the things I really hated about CVS just go away if you don't
> do any branches at all.
If you look at how deltas are stored in the file you get an even
stronger argument -- CVS has always advertised that it stores deltas
'backwards' so that the current version is first in the file. That's
true for the trunk, but for every other branch, you have to seek back
from the tip of the trunk to the branch point and then walk forwards to
the desired version along the branch.
--
keith.packard@intel.com
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 191 bytes --]
^ permalink raw reply
* Cogito asciidoc failure
From: Randal L. Schwartz @ 2006-03-24 16:17 UTC (permalink / raw)
To: git
asciidoc -b xhtml11 -d manpage -f asciidoc.conf cg-admin-rewritehist.1.txt
ERROR: cg-admin-rewritehist.1.txt: line 54: title not allowed in list item continuation
make[1]: *** [cg-admin-rewritehist.1.html] Error 1
make: *** [doc] Error 2
--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<merlyn@stonehenge.com> <URL:http://www.stonehenge.com/merlyn/>
Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.
See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!
^ permalink raw reply
* Re: Fix branch ancestry calculation
From: Linus Torvalds @ 2006-03-24 15:46 UTC (permalink / raw)
To: David Mansfield; +Cc: David Mansfield, Git Mailing List
In-Reply-To: <44240619.20103@dm.cobite.com>
On Fri, 24 Mar 2006, David Mansfield wrote:
>
> Anyway, I'd like to nail down some of the other nagging ancestry/branch point
> problems if possible.
What I considered doing was to just ignore the branch ancestry that cvsps
gives us, and instead use whatever branch that is closest (ie generates
the minimal diff). That's really wrong too (the data just _has_ to be in
CVS somehow), but I just don't know how CVS handles branches, and it's how
we'd have to do merges if we were to ever support them (since afaik, the
merge-back information simply doesn't exists in CVS).
I actually went back to read some of the original CVS papers, and realized
that CVS _without_ branches actually makes perfect sense.
Suddenly it was a perfectly reasonable system: the fact that you can only
merge once (between working tree and repo) is perfectly reasonable when
there is only one branch and checking in requires you to have updated
first. All the things I really hated about CVS just go away if you don't
do any branches at all.
Of course, it's a much less powerful thing without branches, but what I'm
getting at is that the whole branch support seems to have been a total
crock added later on top of something that was never designed for it, and
where the data-structures aren't even set up for it.
Live and learn. (Of course, maybe I'm wrong, and the thing doesn't make
sense even without branches).
Linus
^ permalink raw reply
* Re: Errors GITtifying GCC and Binutils
From: Johannes Schindelin @ 2006-03-24 15:12 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vslp84u43.fsf@assigned-by-dhcp.cox.net>
Hi,
On Thu, 23 Mar 2006, Junio C Hamano wrote:
> Shawn Pearce <spearce@spearce.org> writes:
>
> > I'm not trying to bash Windows users. I'm just saying that there's
> > definately a large user base for SCMs such as CVS who just want
> > to check in the latest version of a file they have to maintain.
> > Many of these people are afraid of a command prompt. Asking them
> > to install Cygwin just to check in a file is a difficult challenge.
>
> Export your git repository via git-cvsserver and have them use
> TortoiseCVS. Such "maintain the tip and that is the only thing
> what interest me" people do not even need to know the backend is
> git.
Now if I could only find a way to tell TortoiseCVS which CVS_SERVER to
use...
Ciao,
Dscho
^ permalink raw reply
* Re: Fix branch ancestry calculation
From: David Mansfield @ 2006-03-24 14:45 UTC (permalink / raw)
To: Linus Torvalds; +Cc: David Mansfield, Git Mailing List
In-Reply-To: <Pine.LNX.4.64.0603221723230.9196@g5.osdl.org>
Linus Torvalds wrote:
> Some branches don't get any ancestors at all, because their ancestor gets
> a "dotcount" value of 0, and are thus not considered any better than not
> having any ancestor. That's obviously wrong. Even a zero-dot-count
> ancestor is better than having none at all.
>
> This fixes the issue by making not having an ancestor branch have a
> goodness value of -1, avoiding the problem (because even a zero dot-count
> will be considered better).
>
> Alternatively, the special-case for the "1.1.1.1" revision should be
> removed (or made to imply a dot-count of 1).
>
Thanks for this. I'll look at bundling this and some miscellaneous
other stuff this weekend (pray to gods for rain so I can stay in all
weekend ;-).
Anyway, I'd like to nail down some of the other nagging ancestry/branch
point problems if possible.
David
^ permalink raw reply
* Re: [RFC] Make dot-counting ignore ".1" at the end
From: David Mansfield @ 2006-03-24 14:40 UTC (permalink / raw)
To: Linus Torvalds; +Cc: David Mansfield, Git Mailing List
In-Reply-To: <Pine.LNX.4.64.0603221746300.26286@g5.osdl.org>
Linus Torvalds wrote:
> I'm not 100% sure this is appropriate, but in general, I think "<rev>" and
> "<rev>.1" should be considered the same thing, no? Which implies that
> "1.1" and "1.1.1.1" are all the same thing, and collapse to just "1", ie a
> zero dot-count. They are all the same version, after all, no?
Hmmm. I'm not sure about this. Given x.y.z.q... the 'odd' nodes
(starting from x = position 1) represent branches, not revisions, and
don't refer to actual concrete objects (just tags if you will) in the
cvs world.
So if <rev> is something like x.y then x.y.z would refer to the 'z' branch.
Furthermore, 'z' better be an even value 2 4 6 etc. because those are
the only branch id's cvs will create. The odd values are for 'imported
source' branches.
The reason 1.1.1.1 exists is some lame-ass crap that CVS delivers to any
developer who imports his/her initial source code.
It creates 1.1 as a placeholder, and I think in this special case it has
the same contents. It also creates a .1 'import branch' then puts the
imported revision onto that 'import' branch.
In a normal situation, you have rev = x.y
You branch, it 'registers' a branch x.y.z where z in {2,4,6...} (and
uses a special 'magic branch' syntax x.y.0.z in the symbolic tags
section).
Only when you commit your first change does it create x.y.z.1.
So we have:
x.y != x.y.z.1 for sure, in the general case.
Also x.y.z will never be x.y.1 for a user created branch because z must
be even number (except for import branches), in any case x.y.z is never
an actual file revision. Now, it COULD be the fact there there needs to
be special handling for x.y.z where z == 1 because that is an import
branch and something devilish is happening there.
I honestly don't know...
David
^ permalink raw reply
* History rewriting swiss army knife
From: Petr Baudis @ 2006-03-24 14:08 UTC (permalink / raw)
To: git
Hi,
it is not very frequent, but sometimes you really want to rewrite your
history - you need to get rid of a copyright violation or a file with
confidential information slipped through, or who knows what other good
reason you might have. As long as you are aware of the implications of
all the tree/commit ids getting different, why not.
It's never been so easy before - I've written cg-admin-rewritehist,
which will execute your filters for each commit (which can rewrite the
tree contents, just the tree itself through the index, committer/author
information and commit message) while the script will obviously preserve
all the other information like merges, author/committer information etc.
The script will place the rewritten history on a newly created branch.
If you are interested, you can also look at the script at
http://kernel.org/git/?p=cogito/cogito.git;a=blob;f=cg-admin-rewritehist
but it has few Cogito dependencies.
Have fun,
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
Right now I am having amnesia and deja-vu at the same time. I think
I have forgotten this before.
^ permalink raw reply
* Re: [BUG] make test (t3600-rm.sh) fails
From: Petr Baudis @ 2006-03-24 13:51 UTC (permalink / raw)
To: Panagiotis Issaris; +Cc: Junio C Hamano, git
In-Reply-To: <4423E06E.9090004@issaris.org>
Dear diary, on Fri, Mar 24, 2006 at 01:05:02PM CET, I got a letter
where Panagiotis Issaris <takis@issaris.org> said that...
> diff --git a/t/t3600-rm.sh b/t/t3600-rm.sh
> index d1947e1..52a1e99 100755
> --- a/t/t3600-rm.sh
> +++ b/t/t3600-rm.sh
> @@ -56,6 +56,7 @@ test "$test_tabs" = y && test_expect_suc
> "git-rm -f 'space embedded' 'tab embedded' 'newline
> embedded'"
>
> +if test `whoami` != "root"; then
Root is not the only condition when this will not fail, it can happen
on broken filesystems as well, specifically AFS. (Avoid avoid avoid that
horrid thing!)
So, perhaps rather
> if test "$test_tabs" = y; then
> chmod u-w .
+ touch xyzzy || \
> test_expect_failure \
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
Right now I am having amnesia and deja-vu at the same time. I think
I have forgotten this before.
^ permalink raw reply
* Re: missing git features (was: Re: Errors GITtifying GCC and Binutils)
From: Andreas Ericsson @ 2006-03-24 12:59 UTC (permalink / raw)
To: git
In-Reply-To: <20060324123238.GA3070@linux-mips.org>
Ralf Baechle wrote:
>
> For my various hacking projects and archiving needs git has done me alot
> of good and it's pretty close to the answer to the question for life,
> universe and everything. But a few rough areas (I'm currently using git
> 1.2.4 btw.) remain:
>
> o During the debugging phase before a new kernel release I put anything
> that isn't appropriate for the master branch on a queue branch which
> I am rebasing frequently to ensure things will work right in the
> "patch bombing" phase before the next -rc1 when I'm sending everything
> on the queue branch upstream.
> The problem: users pull such a branch, create their own branch starting
> somewhere on my queue branch. So eventually when they pull again
> after I rebased the branch things blow up spectactularly. This needs a
> simple solution.
See how Junio does with next and pu and recommend your users to do the
same. There's no way of pulling a rebased branch, because the rebasing
destroys ancestry information, meaning the original commits other people
have cease to exist in your repository.
> o git rebase had no reasonable handling of conflicts last I ran into a
> rebase conflict.
"git rerere" might be of service here. Other than that, it's merging
that goes, unless we come up with a way of patching the delta on the fly
when such things are encountered. Unfortunately that is beyond me, but
perhaps there are other takers on the list. It would indeed be very nice
to have.
> o If a file is modified in a user's tree and a non-conflicting patch is
> being pull users seem to expect the old CVS behaviour which is trying
> to merge into the checked out tree, worst case adding conflict markers.
> Git just refuses the operation.
A pull (fetch + merge) requires a pristine index. If the user has done
"git update-index" on the files, but not committed the merge *should*
fail every time. If they have changes in the working tree but not in the
index, the fetch should work, but the final phase (checking out the
updated head) should fail, since the working tree has un-committed changes.
> o I had people piling up over 2GB in their $GIT_DIR/objects/pack/
> directory because they were using the rsync method for updating.
This most likely happens because you're doing too large packs. You can
do incremental packing, or ask users to switch to using the git://
protocol, which is much faster for incremental updates.
> o Git is a dramatically more powerful and for most operations better
> performing SCM than CVS - but CVS is what people know, it's easy to
> learn and handling special cases like conflicts is sort of obvious
> because CVS expects the user to cleanup the mess and does not try to
> compete with the users in that.
git doesn't compete with the user either, but it doesn't touch the
working tree unless the merge succeeds, which is sane imo but surprising
for CVS users where the action is done in the working tree and the
result is put under rcs control.
> o A Git for Dummies book would be helpful.
The tutorial is fairly complete.
http://www.kernel.org/pub/software/scm/git/docs/tutorial.html
> o When users have problems with git I found it useful to explain them
> how git internally works so they get a better understanding of what
> actually is going on. Dominic Sweetman which is an excellent
> technical writer has made a similar experience and started writing
> a bit about git in the wiki at http://www.linux-mips.org/wiki/WhatIsGit
> May somebody wants to extend this?
> (Dominic unfortunately is currently deeply burried in writing the
> 2nd issue of See MIPS Run, so can't really contribute ...)
>
Good to know. Unfortunately I don't know git internals half as well as I
would like. I can sometimes answer questions, but starting from scratch
and explain it is beyond me.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: Errors GITtifying GCC and Binutils
From: Ralf Baechle @ 2006-03-24 12:44 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Jan-Benedict Glaw, git
In-Reply-To: <Pine.LNX.4.64.0603221517210.26286@g5.osdl.org>
On Wed, Mar 22, 2006 at 03:39:00PM -0800, Linus Torvalds wrote:
> it's "PatchSet 104" (well, for me it is, I have a hacked cvsps, so it
> might not be that for you), which creates the "gdb-4_18-branch", but it
> appears that cvsps hasn't actually figured out any "Ancestor branch" for
> that commit.
>
> What a crock.
>
> Anyway, it's clearly a cvsps bug (mentioning a new branch without the
> _source_ of that branch). Equally clearly, "git cvsimport" is being an ass
> about then failing so totally on it.
>
> I'll try to take a look at why cvsps does that.
Last I converted CVS trees to git found that about half of the branches
were branching off from the wrong commit of the parent branch. At that
time I decieded to just move the branch using a quick script instead of
diving into cvsps.
Ralf
^ permalink raw reply
* Re: Errors GITtifying GCC and Binutils
From: Ralf Baechle @ 2006-03-24 12:32 UTC (permalink / raw)
To: Linus Torvalds; +Cc: sean, keithp, hpa, jbglaw, git
In-Reply-To: <Pine.LNX.4.64.0603231134160.26286@g5.osdl.org>
On Thu, Mar 23, 2006 at 12:38:33PM -0800, Linus Torvalds wrote:
> > lol, that sounds like a really good plan. Perhaps as a two pronged effort
> > its worth changing the notion that git is primarily "plumbing". Adding
> > some of the nice features of cogito and other "porcelains" into the core
> > git might go a ways toward converting the few naysayers we don't kill.
>
> Actually, as far as I can tell, git already has a hell of a lot more
> porcelain than pretty much any non-IDE type traditional SCM. Certainly
> more than CVS.
>
> Yeah, I'm not counting things like Eclipse etc. I'm talking about "plain
> SCM" environments, ie just basic SVN or CVS. What are we missing in that
> department? (The only thing I can think of is a diff colorizer, which some
> prople seem to really want).
I'd like sunglasses with that diff colouriser, please ;-)
For my various hacking projects and archiving needs git has done me alot
of good and it's pretty close to the answer to the question for life,
universe and everything. But a few rough areas (I'm currently using git
1.2.4 btw.) remain:
o During the debugging phase before a new kernel release I put anything
that isn't appropriate for the master branch on a queue branch which
I am rebasing frequently to ensure things will work right in the
"patch bombing" phase before the next -rc1 when I'm sending everything
on the queue branch upstream.
The problem: users pull such a branch, create their own branch starting
somewhere on my queue branch. So eventually when they pull again
after I rebased the branch things blow up spectactularly. This needs a
simple solution.
o git rebase had no reasonable handling of conflicts last I ran into a
rebase conflict.
o If a file is modified in a user's tree and a non-conflicting patch is
being pull users seem to expect the old CVS behaviour which is trying
to merge into the checked out tree, worst case adding conflict markers.
Git just refuses the operation.
o I had people piling up over 2GB in their $GIT_DIR/objects/pack/
directory because they were using the rsync method for updating.
o Git is a dramatically more powerful and for most operations better
performing SCM than CVS - but CVS is what people know, it's easy to
learn and handling special cases like conflicts is sort of obvious
because CVS expects the user to cleanup the mess and does not try to
compete with the users in that.
o A Git for Dummies book would be helpful.
o When users have problems with git I found it useful to explain them
how git internally works so they get a better understanding of what
actually is going on. Dominic Sweetman which is an excellent
technical writer has made a similar experience and started writing
a bit about git in the wiki at http://www.linux-mips.org/wiki/WhatIsGit
May somebody wants to extend this?
(Dominic unfortunately is currently deeply burried in writing the
2nd issue of See MIPS Run, so can't really contribute ...)
Ralf
^ permalink raw reply
* Re: [BUG] make test (t3600-rm.sh) fails
From: Panagiotis Issaris @ 2006-03-24 12:05 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vy7z0yuav.fsf@assigned-by-dhcp.cox.net>
Hi,
Junio C Hamano wrote:
>...
>But that does not mean fakeroot is buggy. Fakeroot is doing
>what it is designed to do.
>
>That does not mean running our tests under fakeroot is stupidity
>on your part. We do not advertise that the tests should not be
>run as root.
>
>The test is buggy -- it tries to make sure the command fails
>when underlying rm fails, but is not aware that "chmod u-w ."
>is not a good way to make ./foo undeletable if you run it as
>root. At least it should skip those two tests if it is run by
>root.
>
>
Something like this?
diff --git a/t/t3600-rm.sh b/t/t3600-rm.sh
index d1947e1..52a1e99 100755
--- a/t/t3600-rm.sh
+++ b/t/t3600-rm.sh
@@ -56,6 +56,7 @@ test "$test_tabs" = y && test_expect_suc
"git-rm -f 'space embedded' 'tab embedded' 'newline
embedded'"
+if test `whoami` != "root"; then
if test "$test_tabs" = y; then
chmod u-w .
test_expect_failure \
@@ -63,6 +64,7 @@ test_expect_failure \
'git-rm -f baz'
chmod u+w .
fi
+fi
test_expect_success \
'When the rm in "git-rm -f" fails, it should not remove the file from the index' \
^ permalink raw reply related
* Re: Errors GITtifying GCC and Binutils
From: Andreas Ericsson @ 2006-03-24 11:29 UTC (permalink / raw)
To: git
In-Reply-To: <slrne27kv8.cp6.mdw@metalzone.distorted.org.uk>
Mark Wooding wrote:
> Shawn Pearce <spearce@spearce.org> wrote:
>
>
>>But your definately right; once the blame/annotate war settles out
>>GIT will have pretty much everything one might need - except a good
>>distributed bug/issue tracking type system. :-)
>
>
> There ought to be such a thing. And I hope it gets called `bugger'.
>
I'm working (slowly) on integrating it with Mantis (www.mantisbt.org),
which we use at work. It shouldn't be difficult to reuse that code with
Bugzilla and other similar trackers.
The recognition thing is done in the update-script, looking for a hash
followed by a number (the bug-id) and then sending that commit to
another program, so it's simply a matter of including the bug-id,
prefixed with a hash, and the bug-topic somewhere in the commit message,
which is a fairly good practice anyways.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: [PATCH] cogito: Avoid slowness when timewarping large trees.
From: Jeff King @ 2006-03-24 11:22 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v3bh814z4.fsf@assigned-by-dhcp.cox.net>
On Fri, Mar 24, 2006 at 03:01:35AM -0800, Junio C Hamano wrote:
> > git-read-tree --reset "$base"
> Exactly. That's what I meant. Thanks.
Hmm. That doesn't actually work, though. If I have a history like this:
$ cg-init -m "initial"
$ cg-tag initial
$ echo contents >file
$ cg-add file
$ cg-commit -m "added file"
and I try this:
$ echo changes >file
$ git-read-tree --reset master
$ git-read-tree -m -u master initial
I get this:
fatal: Entry 'file' not uptodate. Cannot merge.
If I do an update-index before the second read-tree, then I simply get:
fatal: Entry 'file' would be overwritten by merge. Cannot merge.
Is there something I'm missing, or is a 'git reset --hard' really what
we want here (in that case, the fact that git reset changes the HEAD
might be a problem)?
-Peff
^ permalink raw reply
* Re: Errors GITtifying GCC and Binutils
From: Mark Wooding @ 2006-03-24 11:11 UTC (permalink / raw)
To: git
In-Reply-To: <20060323204825.GE30176@spearce.org>
Shawn Pearce <spearce@spearce.org> wrote:
> But your definately right; once the blame/annotate war settles out
> GIT will have pretty much everything one might need - except a good
> distributed bug/issue tracking type system. :-)
There ought to be such a thing. And I hope it gets called `bugger'.
-- [mdw]
^ permalink raw reply
* Re: [BUG] make test (t3600-rm.sh) fails
From: Junio C Hamano @ 2006-03-24 11:08 UTC (permalink / raw)
To: takis; +Cc: git
In-Reply-To: <df33fe7c0603240245o516095b5m@mail.gmail.com>
Takis <panagiotis.issaris@gmail.com> writes:
> I am running it as fakeroot, as part of the "dpkg-buildpackage
> -rfakeroot -uc -us -b"
> command for building Debian packages. Would this be the problem (the fakeroot)?
That is what is causing this, yes.
$ mkdir /var/tmp/junk && cd /var/tmp/junk
$ chmod u+w .
$ fakeroot sh -c 'date >foo; chmod u-w .; rm foo; ls -l foo'
$ chmod u+w .
$ sh -c 'date >foo; chmod u-w .; rm foo; ls -l foo'
The one under fakeroot happily ignores the directory being
unwritable because it mimics to be root.
But that does not mean fakeroot is buggy. Fakeroot is doing
what it is designed to do.
That does not mean running our tests under fakeroot is stupidity
on your part. We do not advertise that the tests should not be
run as root.
The test is buggy -- it tries to make sure the command fails
when underlying rm fails, but is not aware that "chmod u-w ."
is not a good way to make ./foo undeletable if you run it as
root. At least it should skip those two tests if it is run by
root.
^ permalink raw reply
* Re: [PATCH] cogito: Avoid slowness when timewarping large trees.
From: Junio C Hamano @ 2006-03-24 11:01 UTC (permalink / raw)
To: Jeff King; +Cc: git
In-Reply-To: <20060324105543.GA2543@coredump.intra.peff.net>
Jeff King <peff@peff.net> writes:
> ... Should the first read-tree actually
> be:
> git-read-tree --reset "$base"
Exactly. That's what I meant. Thanks.
Originally I wrote "git reset" there, but this being Cogito I
thought Pasky preferred to use the true Plumbing and I botched
it X-<.
^ permalink raw reply
* Re: [PATCH] cogito: Avoid slowness when timewarping large trees.
From: Jeff King @ 2006-03-24 10:55 UTC (permalink / raw)
To: git
In-Reply-To: <7vd5gc16u2.fsf@assigned-by-dhcp.cox.net>
On Fri, Mar 24, 2006 at 02:21:25AM -0800, Junio C Hamano wrote:
> Metainformation fields are internally separated with SP and a
> TAB comes before pathname; you can just say:
>
> sed -ne 's/^:[^ ]* D //p'
That is much cleaner (I stupidly just converted the original regex
verbatim).
> a SP). You might also want to consider "xargs rm -f --", BTW.
Oops, you're right. In particular, rm complains when there are no
deletions.
> However, I wonder why it does not do this instead:
>
> ... stash away the local changes
> git-read-tree -m "$base" ;# reset the index to $base
>
> # switch to $branch -- removing gone files as well
> git-read-tree -m -u "$base" "$branch"
>
> Then you can also lose diff-tree and checkout-index there.
This doesn't deal very well with local changes. The second read-tree
complains about a not uptodate entry during the merge. Since we've
already stashed the local changes as a diff, we should be able to simply
ignore them during the read-tree. Should the first read-tree actually
be:
git-read-tree --reset "$base"
?
-Peff
^ permalink raw reply
* Re: [BUG] make test (t3600-rm.sh) fails
From: Takis @ 2006-03-24 10:45 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v7j6k16g2.fsf@assigned-by-dhcp.cox.net>
Hi,
2006/3/24, Junio C Hamano <junkio@cox.net>:
> Panagiotis Issaris <takis@issaris.org> writes:
>
> > * FAIL 9: Test that "git-rm -f" fails if its rm fails
> > git-rm -f baz
> >...
> > My system:
> > Ubuntu 5.10 aka Breezy
> > Linux issaris 2.6.15.060103 #1 Tue Jan 3 14:27:55 CET 2006 i686 GNU/Linux
>
> I wonder what your system shows if you run:
>
> $ cd t && sh -x t3600-rm.sh -i -v
Here's the output:
takis@issaris:/usr/local/src/git$ cd t && sh -x t3600-rm.sh -i -v
...
* ok 8: Test that "git-rm -f" succeeds with embedded space, tab, or
newline characters.
+ test y = y
+ chmod u-w .
+ test_expect_failure 'Test that "git-rm -f" fails if its rm fails'
'git-rm -f baz'
+ test 2 = 2
+ say 'expecting failure: git-rm -f baz'
+ echo '* expecting failure: git-rm -f baz'
* expecting failure: git-rm -f baz
+ test_run_ 'git-rm -f baz'
+ eval 'git-rm -f baz'
++ git-rm -f baz
rm: cannot remove `baz': Permission denied
+ eval_ret=0
+ return 0
+ '[' 0 = 0 -a 0 '!=' 0 ']'
+ test_failure_ 'Test that "git-rm -f" fails if its rm fails' 'git-rm -f baz'
++ expr 8 + 1
+ test_count=9
++ expr 0 + 1
+ test_failure=1
+ say 'FAIL 9: Test that "git-rm -f" fails if its rm fails'
+ echo '* FAIL 9: Test that "git-rm -f" fails if its rm fails'
* FAIL 9: Test that "git-rm -f" fails if its rm fails
+ shift
+ echo 'git-rm -f baz'
+ sed -e 's/^/ /'
git-rm -f baz
+ test t = ''
+ trap - exit
+ exit 1
> The test #9 makes the test directory unwritable before trying to
> unlink a file there, and git-rm runs rm without -f which should
> make it fail. So either your "chmod u-w ." is broken, you are
> running it as root and defeating "chmod u-w .", or you have a
> broken rm that does not report failure with its exit status.
I am running it as fakeroot, as part of the "dpkg-buildpackage
-rfakeroot -uc -us -b"
command for building Debian packages. Would this be the problem (the fakeroot)?
With friendly regards,
Takis
^ permalink raw reply
* Re: [BUG] make test (t3600-rm.sh) fails
From: Junio C Hamano @ 2006-03-24 10:29 UTC (permalink / raw)
To: Panagiotis Issaris; +Cc: git
In-Reply-To: <4423C681.3000302@issaris.org>
Panagiotis Issaris <takis@issaris.org> writes:
> * FAIL 9: Test that "git-rm -f" fails if its rm fails
> git-rm -f baz
>...
> My system:
> Ubuntu 5.10 aka Breezy
> Linux issaris 2.6.15.060103 #1 Tue Jan 3 14:27:55 CET 2006 i686 GNU/Linux
I wonder what your system shows if you run:
$ cd t && sh -x t3600-rm.sh -i -v
The test #9 makes the test directory unwritable before trying to
unlink a file there, and git-rm runs rm without -f which should
make it fail. So either your "chmod u-w ." is broken, you are
running it as root and defeating "chmod u-w .", or you have a
broken rm that does not report failure with its exit status.
The relevant part on my machine looks like this:
$ cd t
$ sh -x t3600-rm.sh -i -v
...
* ok 8: Test that "git-rm -f" succeeds with embedded space, tab, or newline characters.
+ test y = y
+ chmod u-w .
+ test_expect_failure 'Test that "git-rm -f" fails if its rm fails' 'git-rm -f baz'
+ test 2 = 2
+ say 'expecting failure: git-rm -f baz'
+ echo '* expecting failure: git-rm -f baz'
* expecting failure: git-rm -f baz
+ test_run_ 'git-rm -f baz'
+ eval 'git-rm -f baz'
++ git-rm -f baz
rm: cannot remove `baz': Permission denied
+ eval_ret=123
+ return 0
+ '[' 0 = 0 -a 123 '!=' 0 ']'
+ test_ok_ 'Test that "git-rm -f" fails if its rm fails'
++ expr 8 + 1
+ test_count=9
+ say ' ok 9: Test that "git-rm -f" fails if its rm fails'
+ echo '* ok 9: Test that "git-rm -f" fails if its rm fails'
* ok 9: Test that "git-rm -f" fails if its rm fails
...
^ permalink raw reply
* Re: [PATCH] cogito: Avoid slowness when timewarping large trees.
From: Junio C Hamano @ 2006-03-24 10:21 UTC (permalink / raw)
To: Jeff King; +Cc: git
In-Reply-To: <20060324084423.GA30213@coredump.intra.peff.net>
Jeff King <peff@peff.net> writes:
> tree_timewarp was calling read, egrep, and rm in an O(N) loop where N is
> the number of changed files between two trees. This caused a bottleneck
> when seeking/switching/merging between trees with many changed files.
>...
> ---
>
> cg-Xlib | 9 +++------
> 1 files changed, 3 insertions(+), 6 deletions(-)
>
> a9a160c0bd63973c53ba3aa74650728135d23ac7
> diff --git a/cg-Xlib b/cg-Xlib
> index a2f28cf..ceddeeb 100644
> --- a/cg-Xlib
> +++ b/cg-Xlib
> @@ -345,12 +345,9 @@ tree_timewarp()
>
> # Kill gone files
> git-diff-tree -r "$base" "$branch" |
> ...
> + # match ":100755 000000 14d43b1abf... 000000000... D"
> + sed -ne 's/^:\([^ ][^ ]* \)\{4\}D\t//p' |
> + xargs rm --
> git-checkout-index -u -f -a
Metainformation fields are internally separated with SP and a
TAB comes before pathname; you can just say:
sed -ne 's/^:[^ ]* D //p'
there (whitespace inside [] and after D are TAB; one before D is
a SP). You might also want to consider "xargs rm -f --", BTW.
However, I wonder why it does not do this instead:
... stash away the local changes
git-read-tree -m "$base" ;# reset the index to $base
# switch to $branch -- removing gone files as well
git-read-tree -m -u "$base" "$branch"
Then you can also lose diff-tree and checkout-index there.
^ permalink raw reply
* [BUG] make test (t3600-rm.sh) fails
From: Panagiotis Issaris @ 2006-03-24 10:14 UTC (permalink / raw)
To: git
Hi,
Just a small report that "make test" fails on my system on the current
git git tree:
...
* passed all 3 test(s)
*** t3600-rm.sh ***
Committing initial tree e5c556e46aae6124ff4a2a466c95004e92d9a2e4
* ok 1: Pre-check that foo exists and is in index before git-rm foo
* ok 2: Test that git-rm foo succeeds
* ok 3: Post-check that foo exists but is not in index after git-rm foo
* ok 4: Pre-check that bar exists and is in index before "git-rm -f bar"
* ok 5: Test that "git-rm -f bar" succeeds
* ok 6: Post-check that bar does not exist and is not in index after
"git-rm -f bar"
* ok 7: Test that "git-rm -- -q" succeeds (remove a file that looks
like an option)
* ok 8: Test that "git-rm -f" succeeds with embedded space, tab, or
newline characters.
* FAIL 9: Test that "git-rm -f" fails if its rm fails
git-rm -f baz
* ok 10: When the rm in "git-rm -f" fails, it should not remove the
file from the index
* failed 1 among 10 test(s)
make[2]: *** [t3600-rm.sh] Error 1
make[2]: Leaving directory `/usr/local/src/git/t'
make[1]: *** [test] Error 2
make[1]: Leaving directory `/usr/local/src/git'
make: *** [build-arch-stamp] Error 2
My system:
Ubuntu 5.10 aka Breezy
Linux issaris 2.6.15.060103 #1 Tue Jan 3 14:27:55 CET 2006 i686 GNU/Linux
model name : Intel(R) Pentium(R) 4 CPU 3.20GHz
With friendly regards,
Takis
^ permalink raw reply
* [PATCH] cogito: Avoid slowness when timewarping large trees.
From: Jeff King @ 2006-03-24 8:44 UTC (permalink / raw)
To: git
tree_timewarp was calling read, egrep, and rm in an O(N) loop where N is
the number of changed files between two trees. This caused a bottleneck
when seeking/switching/merging between trees with many changed files.
On the historical linux tree, the time to cg-seek from the head to the
initial commit (a change of 19099 files) dropped from 2m35s to 21s.
---
cg-Xlib | 9 +++------
1 files changed, 3 insertions(+), 6 deletions(-)
a9a160c0bd63973c53ba3aa74650728135d23ac7
diff --git a/cg-Xlib b/cg-Xlib
index a2f28cf..ceddeeb 100644
--- a/cg-Xlib
+++ b/cg-Xlib
@@ -345,12 +345,9 @@ tree_timewarp()
# Kill gone files
git-diff-tree -r "$base" "$branch" |
- while IFS=$'\t' read header file; do
- # match ":100755 000000 14d43b1abf... 000000000... D"
- if echo "$header" | egrep "^:([^ ][^ ]* ){4}D" >/dev/null; then
- rm -- "$file"
- fi
- done
+ # match ":100755 000000 14d43b1abf... 000000000... D"
+ sed -ne 's/^:\([^ ][^ ]* \)\{4\}D\t//p' |
+ xargs rm --
git-checkout-index -u -f -a
# FIXME: Can produce bogus "contains only garbage" messages.
--
1.2.4
^ permalink raw reply related
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