* 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: 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: 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: [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
* 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: [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
* 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: 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: 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
* 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: 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
* 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: 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: Fw: [PATCH 31/49] PCI: PCI/Cardbus cards hidden, needs pci=assign-busses to fix
From: Ryan Anderson @ 2006-03-24 17:23 UTC (permalink / raw)
To: Junio C Hamano; +Cc: greg, git, Andrew Morton
In-Reply-To: <7v3bh837cs.fsf@assigned-by-dhcp.cox.net>
On Thu, Mar 23, 2006 at 06:27:15PM -0800, Junio C Hamano wrote:
> [PATCH] send-email: Identify author at the top when sending e-mail
>
> git-send-email was not checking if the sender is the same as the
> patch author. Follow the "From: at the beginning" convention to
> propagate the patch author correctly.
This looks fine.
My initial thought here was that it might be even simpler to just always
put the From: line in the body, with the patch author's name there, but
this is a bit cleaner, so ACK.
--
Ryan Anderson
sometimes Pug Majere
^ permalink raw reply
* Re: Cloning from sites with 404 overridden
From: Mark Wooding @ 2006-03-24 17:29 UTC (permalink / raw)
To: git
In-Reply-To: <442152E0.4020604@op5.se>
Andreas Ericsson <ae@op5.se> wrote:
>> I'm not sure what the best "object that's not supposed to be there" is.
>
> .git/objects/00/hoping-for-a-404-or-webadmin-should-fix
If .git/objects/00/00000000000000000000000000000000000000 exists, the
repository has big problems already.
(Aside: `C-u 38 0' doesn't work because Emacs hears `C-u 380' and waits
for a key. `M-: (insert-char ?0 38) RET' does the right thing, but is
ugly. Any better suggestions?)
-- [mdw]
^ permalink raw reply
* Re: Cloning from sites with 404 overridden
From: Junio C Hamano @ 2006-03-24 17:52 UTC (permalink / raw)
To: Mark Wooding; +Cc: git
In-Reply-To: <slrne28b3a.cp6.mdw@metalzone.distorted.org.uk>
Mark Wooding <mdw@distorted.org.uk> writes:
> (Aside: `C-u 38 0' doesn't work because Emacs hears `C-u 380' and waits
> for a key. `M-: (insert-char ?0 38) RET' does the right thing, but is
> ugly. Any better suggestions?)
C-u 38 C-u 0
^ permalink raw reply
* Re: Cloning from sites with 404 overridden
From: Linus Torvalds @ 2006-03-24 17:53 UTC (permalink / raw)
To: Mark Wooding; +Cc: git
In-Reply-To: <slrne28b3a.cp6.mdw@metalzone.distorted.org.uk>
On Fri, 24 Mar 2006, Mark Wooding wrote:
>
> (Aside: `C-u 38 0' doesn't work because Emacs hears `C-u 380' and waits
> for a key. `M-: (insert-char ?0 38) RET' does the right thing, but is
> ugly. Any better suggestions?)
I don't do GNU emacs, but the way to do it in some other editors that do
repeats somewhat similarly is to do the action that starts with a number
as a macro, and do that macro 37 more times.
On uemacs: ^X '(' '0' ^X ')' ESC '3' '7' ^X 'E'
(Of course, the easier way is to just do '0' LEFT ^K to put the 0 in the
buffer, and than ESC '3' '8' ^Y to yank it 38 times, but the macro trick
is generic, even if it's a few more keystrokes).
Linus "teaching people the one true editor" Torvalds
^ permalink raw reply
* Re: Cloning from sites with 404 overridden
From: Morten Welinder @ 2006-03-24 18:16 UTC (permalink / raw)
To: Mark Wooding; +Cc: git
In-Reply-To: <slrne28b3a.cp6.mdw@metalzone.distorted.org.uk>
> (Aside: `C-u 38 0' doesn't work because Emacs hears `C-u 380' and waits
> for a key. `M-: (insert-char ?0 38) RET' does the right thing, but is
> ugly. Any better suggestions?)
There's a million ways to skin that cat.
ESC 38 C-q 60 RET
[Octal 060 == '0']
M.
^ permalink raw reply
* Re: Errors GITtifying GCC and Binutils
From: Jan-Benedict Glaw @ 2006-03-24 18:25 UTC (permalink / raw)
To: git
In-Reply-To: <20060322133337.GU20746@lug-owl.de>
[-- Attachment #1: Type: text/plain, Size: 4040 bytes --]
On Wed, 2006-03-22 14:33:37 +0100, Jan-Benedict Glaw <jbglaw@lug-owl.de> wrote:
Since it seems nobody looked at the GCC import run (which means to use
the svnimport), I ran it again, under strace control:
> GCC
> ~~~
> $ /home/jbglaw/bin/git svnimport -C gcc -v svn://gcc.gnu.org/svn/gcc
> Committed change 3936:/ 1993-03-31 05:44:03)
> Commit ID ceff85145f8671fb2a9d826a761cedc2a507bd1e
> Writing to refs/heads/origin
> DONE: 3936 origin ceff85145f8671fb2a9d826a761cedc2a507bd1e
> ... 3937 trunk/gcc/final.c ...
> Can't fork at /home/jbglaw/bin/git-svnimport line 379.
... 4279 trunk/gcc/config/i386/xm-sco.h ...
This time it broke at a different revision, so I guess it's not a SVN
or git / git-svnimport problem, but rather a problem of my Perl
installation or the kernel itself?
Tree ID 5b04fbc98f8dc9d50506b6dbc8f31567eea2e225
Committed change 4279:/ 1993-04-29 21:13:46)
Merge parent branch: eeb742d8ffd78d58f05d0b9c80bb55e1dc25ad13
Commit ID e85129f5e8af0b93a41d5bf294f17a9c9bf9fa21
Writing to refs/heads/origin
DONE: 4279 origin e85129f5e8af0b93a41d5bf294f17a9c9bf9fa21
... 4280 trunk/gcc/config/mips/mips.h ...
Tree ID 3feb45ec3ee93e8a6d75b8ce552281e0ed2d7215
Committed change 4280:/ 1993-04-30 00:53:35)
Merge parent branch: e85129f5e8af0b93a41d5bf294f17a9c9bf9fa21
Commit ID 34b473ffc0e05419c50be848d5349592b7c48ee3
Writing to refs/heads/origin
DONE: 4280 origin 34b473ffc0e05419c50be848d5349592b7c48ee3
readline() on closed filehandle H at /home/jbglaw/bin/git-svnimport line 562.
4281: cannot find commit 'origin'!
readline() on closed filehandle H at /home/jbglaw/bin/git-svnimport line 562.
4282: cannot find commit 'origin'!
readline() on closed filehandle H at /home/jbglaw/bin/git-svnimport line 562.
4283: cannot find commit 'origin'!
readline() on closed filehandle H at /home/jbglaw/bin/git-svnimport line 562.
4284: cannot find commit 'origin'!
readline() on closed filehandle H at /home/jbglaw/bin/git-svnimport line 562.
4285: cannot find commit 'origin'!
... 4286 trunk/gcc/fixincludes ...
Can't fork at /home/jbglaw/bin/git-svnimport line 379.
strace of this:
read(3, "rintf decl"..., 4096) = 2896
write(6, "superfluou"..., 4096) = 4096
read(3, "$file ${LI"..., 4096) = 1448
read(3, "m -f ${LIB"..., 4096) = 1448
read(3, "LIB}/machi"..., 4096) = 1448
write(6, " 2>/dev/nu"..., 4096) = 4096
read(3, "memory\\.h"..., 4096) = 2896
read(3, "h>\") > ${"..., 4096) = 1448
write(6, "&& [ ! -r "..., 4096) = 4096
read(3, " char *__n"..., 4096) = 3438
write(6, "claim to h"..., 4096) = 4096
write(6, "ymbolic no"..., 446) = 446
close(6) = 0
pipe([6, 7]) = 0
clone(child_stack=0,
flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD,
child_tidptr=0xb7ddf708) = -1 ENOMEM (Cannot allocate memory)
close(6) = 0
close(7) = 0
write(2, "Can\'t for"..., 55) = 55
close(4) = 0
close(3) = 0
What are possible reasons for clone() to fail with -ENOMEN? I have to
admit that the box _is_ loaded a bit all the time:
jbglaw@bixie:~/vax/git-conversion$ uptime
19:23:58 up 136 days, 7:46, 20 users, load average: 4.45, 4.25, 3.05
jbglaw@bixie:~/vax/git-conversion$ free
total used free shared buffers cached
Mem: 507308 501760 5548 0 2184 16900
-/+ buffers/cache: 482676 24632
Swap: 2441872 1295512 1146360
MfG, JBG
--
Jan-Benedict Glaw jbglaw@lug-owl.de . +49-172-7608481 _ O _
"Eine Freie Meinung in einem Freien Kopf | Gegen Zensur | Gegen Krieg _ _ O
für einen Freien Staat voll Freier Bürger" | im Internet! | im Irak! O O O
ret = do_actions((curr | FREE_SPEECH) & ~(NEW_COPYRIGHT_LAW | DRM | TCPA));
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Bug encountered while comitting
From: Matthias Kestenholz @ 2006-03-24 18:39 UTC (permalink / raw)
To: git
Hello list,
I don't know if this is the right place to report a bug, but I'll
just try and see what comes back.
I am trying to build a Wiki [1] using PHP, a hacked version of Markdown,
and git for content tracking. I use the git core plumbing to do the
history work.
The PHP script created directories under .git/objects which were
only writable by www-data. There were other directories which were
owned by user mk and group www-data, and they were group writable.
So, I had write access to only a part of the .git directory.
When I tried to commit, I got a message saying "Unable to write sha1
filename".
The result was, that only part of the commit was recorded and that I
experienced repository corruption. refs/heads/master pointed to a
non-existant object.
The expected behavior would have been an error message telling me I
had insufficient write privileges and surely no repository
corruption.
Thanks,
Matthias
[1]: http://spinlock.ch/cgi-bin/gitweb.pl?p=swisdk2/bugs.git;a=tree
(See Wiki_ctrl.php for source)
--
:wq
^ permalink raw reply
* Re: Cloning from sites with 404 overridden
From: Andreas Ericsson @ 2006-03-24 18:40 UTC (permalink / raw)
To: Mark Wooding; +Cc: git
In-Reply-To: <slrne28b3a.cp6.mdw@metalzone.distorted.org.uk>
Mark Wooding wrote:
> Andreas Ericsson <ae@op5.se> wrote:
>
>
>>>I'm not sure what the best "object that's not supposed to be there" is.
>>
>>.git/objects/00/hoping-for-a-404-or-webadmin-should-fix
>
>
> If .git/objects/00/00000000000000000000000000000000000000 exists, the
> repository has big problems already.
>
Indeed. I'm off sobriety again, it being friday and all, but I'm
assuming there are more than 18 zeroes there, yes? The "feature" of the
above line is that it will fit in any buffer that already exists, and
will match any third argument to send(2) that already exists.
> (Aside: `C-u 38 0' doesn't work because Emacs hears `C-u 380' and waits
> for a key. `M-: (insert-char ?0 38) RET' does the right thing, but is
> ugly. Any better suggestions?)
>
This I happily don't understand at all. I'm also happy ignorant of what
it has to do with the issue at hand.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: missing git features
From: Andreas Ericsson @ 2006-03-24 18:55 UTC (permalink / raw)
To: Carl Worth; +Cc: git
In-Reply-To: <871wwrztaz.wl%cworth@cworth.org>
Carl Worth wrote:
> 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".
Yes they do, but you don't, so their tip won't match yours, meaning
their git will try a merge, which will fail since lots of commits are
already applied. Perhaps it would be possible to try the blobs against
each other, if anyone's interested.
> 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).
>
For the cases where no merge is required you could rebase several
branches on top of one and simply publish that one. If that's the case,
git would need the ability to know what branches are exported and which
arne't, which should be a lot simpler than implementing a rebased-merge
strategy.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: Cogito asciidoc failure
From: Petr Baudis @ 2006-03-24 19:02 UTC (permalink / raw)
To: Randal L. Schwartz; +Cc: git
In-Reply-To: <86u09n4y1k.fsf@blue.stonehenge.com>
Dear diary, on Fri, Mar 24, 2006 at 05:17:43PM CET, I got a letter
where "Randal L. Schwartz" <merlyn@stonehenge.com> said that...
>
> 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
Oh. Thanks, fixed.
--
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: Errors GITtifying GCC and Binutils
From: Andreas Ericsson @ 2006-03-24 19:10 UTC (permalink / raw)
To: Jan-Benedict Glaw; +Cc: git
In-Reply-To: <20060324182504.GI31387@lug-owl.de>
Jan-Benedict Glaw wrote:
> On Wed, 2006-03-22 14:33:37 +0100, Jan-Benedict Glaw <jbglaw@lug-owl.de> wrote:
>
> Since it seems nobody looked at the GCC import run (which means to use
> the svnimport), I ran it again, under strace control:
>
If you send me a bzipped tar-ball of the repo you're trying to import,
preferrably with all the patches to cvsps you've tried, I'll see what I
can do over the weekend.
--
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: Santi Béjar @ 2006-03-24 19:35 UTC (permalink / raw)
To: Jan-Benedict Glaw; +Cc: git
In-Reply-To: <20060324182504.GI31387@lug-owl.de>
Jan-Benedict Glaw <jbglaw@lug-owl.de> writes:
> On Wed, 2006-03-22 14:33:37 +0100, Jan-Benedict Glaw <jbglaw@lug-owl.de> wrote:
>
> Since it seems nobody looked at the GCC import run (which means to use
> the svnimport), I ran it again, under strace control:
>
>> GCC
>> ~~~
>> $ /home/jbglaw/bin/git svnimport -C gcc -v svn://gcc.gnu.org/svn/gcc
>
>> Committed change 3936:/ 1993-03-31 05:44:03)
>> Commit ID ceff85145f8671fb2a9d826a761cedc2a507bd1e
>> Writing to refs/heads/origin
>> DONE: 3936 origin ceff85145f8671fb2a9d826a761cedc2a507bd1e
>> ... 3937 trunk/gcc/final.c ...
>> Can't fork at /home/jbglaw/bin/git-svnimport line 379.
>
I have the same (?) problem with one of my svn repository. It worked
before (I've redone the import with the -r flag), so I bisected it.
The problematic commit seems to be:
diff-tree 4802426... (from 525c0d7...)
Author: Karl Hasselström <kha@treskal.com>
Date: Sun Feb 26 06:11:27 2006 +0100
svnimport: Convert executable flag
Convert the svn:executable property to file mode 755 when converting
an SVN repository to GIT.
Signed-off-by: Karl Hasselström <kha@treskal.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
:100755 100755 ee2940f... 6603b96... M git-svnimport.perl
I think it has a memory leak, it used up to 140m of memory.
$ git reset --hard 4802426^
$ time ../git-svnimport.perl file:///path/
Use of uninitialized value in string eq at ../git-svnimport.perl line 463.
Use of uninitialized value in substitution (s///) at ../git-svnimport.perl line 466.
real 0m55.801s
user 0m30.578s
sys 0m23.084s
$ git reset --hard 4802426
$ time ../git-svnimport.perl file:///path/
Use of uninitialized value in string eq at ../git-svnimport.perl line 463.
Use of uninitialized value in substitution (s///) at ../git-svnimport.perl line 466.
Can't fork at /home/santi/usr/src/scm/git/git-svnimport.perl line 331.
real 6m2.163s
user 0m20.332s
sys 0m50.180s
and it didn't finished. Hope it helps.
Santi
^ 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