* 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
* Re: Bug encountered while comitting
From: Andreas Ericsson @ 2006-03-24 19:34 UTC (permalink / raw)
To: Matthias Kestenholz; +Cc: git
In-Reply-To: <20060324183951.GA23193@spinlock.ch>
Matthias Kestenholz wrote:
> 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
Ouch... You're not really supposed to do that. The proper thing to do is
to do things in the working tree and commit them to git later.
> 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.
>
Unless you're using the git tools (or things hooking in to the git core
C functions somehow), don't touch the .git directory.
(this merits an exclamation marks, so brace yourselves) !
> When I tried to commit, I got a message saying "Unable to write sha1
> filename".
>
What file were you trying to write?
> 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.
>
Did you use git tools to update .git/refs/heads/master ?
> The expected behavior would have been an error message telling me I
> had insufficient write privileges and surely no repository
> corruption.
>
Didn't you get the strerror(3) message from that? If so, I'd consider it
a bug.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: History rewriting swiss army knife
From: Junio C Hamano @ 2006-03-24 22:47 UTC (permalink / raw)
To: Petr Baudis; +Cc: git
In-Reply-To: <20060324140831.GY18185@pasky.or.cz>
Petr Baudis <pasky@suse.cz> writes:
> 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.
Hmph. The above description sounds like you are not allowing
the user's custom script to drop existing parent (or graft a new
one) while rewriting. I have not looked at how you are
interfacing with user's custom script, but I sort-of expected
you to throw a commit at it from older to newer (i.e. topo-order
in reverse), along with the names of already re-written commit
objects that are parents of taht commit, and have it build a
rewritten commit and report its object name back to you.
But it sounds like a useful tool in certain situations -- I
sounded mildly negative last night, but after you gave an
example of cleaning up a half-botched import, I changed my mind.
^ permalink raw reply
* Question about git-ls-files
From: Radoslaw Szkodzinski @ 2006-03-24 22:49 UTC (permalink / raw)
To: git
[-- Attachment #1: Type: text/plain, Size: 870 bytes --]
git-ls-files is a very useful command to list various types of files.
However, it has some weird behaviour.
Let's say someone removed the file and not updated the index yet.
I want to get status for all files in the directory, so I launch git-ls-files
-t -m -d -o, and I get:
R removed-file
C removed-file
? something-else
(it looks even better if I call it w/o -t)
If the file is removed, then marking it as changed is redundant.
A removed file cannot be unchanged.
This behaviour makes for slow parsing, because to get the changed files which
still exist one has to at least skip items (or uniquify the list). This
shouldn't be needed.
Removed files should of course still be listed as changed if there's no -d
parameter.
--
GPG Key id: 0xD1F10BA2
Fingerprint: 96E2 304A B9C4 949A 10A0 9105 9543 0453 D1F1 0BA2
AstralStorm
[-- Attachment #2: Type: application/pgp-signature, Size: 191 bytes --]
^ permalink raw reply
* Re: Bug encountered while comitting
From: Junio C Hamano @ 2006-03-24 22:55 UTC (permalink / raw)
To: Matthias Kestenholz; +Cc: git
In-Reply-To: <20060324183951.GA23193@spinlock.ch>
Matthias Kestenholz <lists@irregular.ch> writes:
> 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.
core.sharedrepository perhaps?
While it probably is not a good idea to have you in www-data, it
appears that is essentially you will end up doing, because PHP
scripts that may _create_ new directories better not to have
privilege to give newly created directories away to you (busting
your quota), so they will be owned by www-data.www-data and for
you to be able to write into it you either need to be www-data
user or in www-data group, with core.sharedrepostiory set.
^ 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