* Effective difference between git-rebase and git-resolve
From: Marc Singer @ 2006-03-25 3:54 UTC (permalink / raw)
To: git
The process I've been using to keep my patches current with the latest
development is this:
git checkout linus && git pull linus
git checkout work
When I'm ready to merge,
git resolve work linus "Update with head"
git tag basis
This lets me diff against basis even when the linus branch continues
to follow the latest developments.
Today, I wanted to move everything forward. But the resolve failed to
merge some files. In fact, one file was apparently so thorny that
resolve just gave up and left no working file. Bothersome, but I
recovered by moving back to the previous work point.
Then, I found git-rebase which seems to be more what I'd like to use
since it moves my patches along on top of the main development line.
git rebase linus
This time, almost everything merged without a hitch except for the
thorny file from before. I edited the file, removing the conflict
markers, and started a build. But what I found was that some of the
changes I'd made were no longer present. Several files showed no sign
of the patches even though the kernel versions hadn't changed.
So, I have a couple of questions:
1) Am I using rebase correctly?
2) If not, did it leave some of my changes uncommitted and hidden
somewhere? git-ls-files --unmerged shows no sign of them.
3) Do I have to pull all of my patches off, apply them to the head
of the tree, and only use git-rebase to make this work?
4) Should I prefer rebase over resolve?
^ permalink raw reply
* git push refspec URL weirdness
From: Jon Loeliger @ 2006-03-25 3:42 UTC (permalink / raw)
To: git
I wanted to git push some bits to a remote repo
and set up this .git/refs/remotes/publish file:
URL: git+ssh://www.example.com/some/path/repo.git
Push: my-branch:public-branch
So that I could "git push publish".
The ssh on the far side is listening on port 1234
and not the default 22. So I slapped this into my
~/.ssh/config file on the local machine:
Host www.example.com
Port 1234
This worked great for a straight "ssh www.example.com"
connection. However, git still complained that port 22
was refusing connections. It was. Git shouldn't have
been trying to use it.
So Junio suggested taking advantage of the fact that the
default refspec uses git+ssh and use this instead:
URL: www.example.com:/pub/software/linux-2.6-86xx.git
Push: my-branch:public-branch
Which just worked.
So this is either a bug report or google food. :-)
jdl
^ permalink raw reply
* [PATCH] Removed bogus "<snap>" identifier.
From: Jon Loeliger @ 2006-03-25 3:27 UTC (permalink / raw)
To: git
Signed-off-by: Jon Loeliger <jdl@jdl.com>
---
Documentation/git.txt | 4 ----
1 files changed, 0 insertions(+), 4 deletions(-)
c610f57ccfb52441719c5602894139acdd1271ee
diff --git a/Documentation/git.txt b/Documentation/git.txt
index 0c424ff..fe34f50 100644
--- a/Documentation/git.txt
+++ b/Documentation/git.txt
@@ -521,10 +521,6 @@ HEAD::
a valid head 'name'
(i.e. the contents of `$GIT_DIR/refs/heads/<head>`).
-<snap>::
- a valid snapshot 'name'
- (i.e. the contents of `$GIT_DIR/refs/snap/<snap>`).
-
File/Directory Structure
------------------------
--
1.2.4.gdd7be
^ permalink raw reply related
* [PATCH] Clarify and expand some hook documentation.
From: Jon Loeliger @ 2006-03-25 3:21 UTC (permalink / raw)
To: git
Clarify update and post-update hooks.
Made a few references to the hooks documentation.
Signed-off-by: Jon Loeliger <jdl@jdl.com>
---
Documentation/git.txt | 2 +
Documentation/hooks.txt | 49 ++++++++++++++++++++++++++---------
Documentation/repository-layout.txt | 2 +
3 files changed, 41 insertions(+), 12 deletions(-)
83472863b77cde6209ce01211500e2bd9b81ecc7
diff --git a/Documentation/git.txt b/Documentation/git.txt
index de3934d..0c424ff 100644
--- a/Documentation/git.txt
+++ b/Documentation/git.txt
@@ -531,6 +531,8 @@ File/Directory Structure
Please see link:repository-layout.html[repository layout] document.
+Read link:hooks.html[hooks] for more details about each hook.
+
Higher level SCMs may provide and manage additional information in the
`$GIT_DIR`.
diff --git a/Documentation/hooks.txt b/Documentation/hooks.txt
index 4ad1920..3824a95 100644
--- a/Documentation/hooks.txt
+++ b/Documentation/hooks.txt
@@ -97,16 +97,31 @@ send out a commit notification e-mail.
update
------
-This hook is invoked by `git-receive-pack`, which is invoked
-when a `git push` is done against the repository. It takes
-three parameters, name of the ref being updated, old object name
-stored in the ref, and the new objectname to be stored in the
-ref. Exiting with non-zero status from this hook prevents
-`git-receive-pack` from updating the ref.
+This hook is invoked by `git-receive-pack` on the remote repository,
+which is happens when a `git push` is done on a local repository.
+Just before updating the ref on the remote repository, the update hook
+is invoked. It's exit status determins the success or failure of
+the ref update.
+
+The hook executes once for each ref to be updated, and takes
+three parameters:
+ - the name of the ref being updated,
+ - the old object name stored in the ref,
+ - and the new objectname to be stored in the ref.
+
+A zero exit from the update hook allows the ref to be updated.
+Exiting with a non-zero status prevents `git-receive-pack`
+from updating the ref.
-This can be used to prevent 'forced' update on certain refs by
+This hook can be used to prevent 'forced' update on certain refs by
making sure that the object name is a commit object that is a
descendant of the commit object named by the old object name.
+That is, to enforce a "fast forward only" policy.
+
+It could also be used to log the old..new status. However, it
+does not know the entire set of branches, so it would end up
+firing one e-mail per ref when used naively, though.
+
Another use suggested on the mailing list is to use this hook to
implement access control which is finer grained than the one
based on filesystem group.
@@ -115,20 +130,30 @@ The standard output of this hook is sent
want to report something to the git-send-pack on the other end,
you can redirect your output to your stderr.
+
post-update
-----------
-This hook is invoked by `git-receive-pack`, which is invoked
-when a `git push` is done against the repository. It takes
-variable number of parameters; each of which is the name of ref
-that was actually updated.
+This hook is invoked by `git-receive-pack` on the remote repository,
+which is happens when a `git push` is done on a local repository.
+It executes on the remote repository once after all the refs have
+been updated.
+
+It takes a variable number of parameters, each of which is the
+name of ref that was actually updated.
This hook is meant primarily for notification, and cannot affect
the outcome of `git-receive-pack`.
+The post-update hook can tell what are the heads that were pushed,
+but it does not know what their original and updated values are,
+so it is a poor place to do log old..new.
+
The default post-update hook, when enabled, runs
`git-update-server-info` to keep the information used by dumb
-transport up-to-date.
+transports (eg, http) up-to-date. If you are publishing
+a git repository that is accessible via http, you should
+probably enable this hook.
The standard output of this hook is sent to /dev/null; if you
want to report something to the git-send-pack on the other end,
diff --git a/Documentation/repository-layout.txt b/Documentation/repository-layout.txt
index 1f19bf8..98fbe7d 100644
--- a/Documentation/repository-layout.txt
+++ b/Documentation/repository-layout.txt
@@ -89,6 +89,8 @@ hooks::
commands. A handful of sample hooks are installed when
`git init-db` is run, but all of them are disabled by
default. To enable, they need to be made executable.
+ Read link:hooks.html[hooks] for more details about
+ each hook.
index::
The current index file for the repository. It is
--
1.2.4.gdd7be
^ permalink raw reply related
* Re: Fix branch ancestry calculation
From: Chris Shoemaker @ 2006-03-25 1:45 UTC (permalink / raw)
To: Keith Packard
Cc: Linus Torvalds, David Mansfield, David Mansfield,
Git Mailing List
In-Reply-To: <1143218338.6850.68.camel@neko.keithp.com>
On Fri, Mar 24, 2006 at 08:38:58AM -0800, Keith Packard wrote:
> 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.
If that last sentence was a typo then you already know this, but
otherwise you may be disappointed to learn that it's not _always_
possible to discern the correct ancestry tree.
The simplest counter-example is two branches where each adds one file
and no files in common are modified. If A and B both branched off of
HEAD and each adds one file, then they should each only have one file.
But if B branched from A which branched from HEAD, then B should also
have the file that was added to A. (*) However, the information to
distinguish these two cases isn't recorded in CVS.
I seem to have described this example more fully in the notes I took
while writing the patch to cvsps that does the global inferrence
you're describing. You _usually_ can make a very good guess, and the
more files that are modified, the better you can do.
BTW, those notes are still available here:
http://www.codesifter.com/cvsps-notes.txt
If you end up comparing the ancestry tree discovered by your tool and
the tree output by a patched cvsps, I would be very interested in the
results.
-chris
(*) You can distinguish between A->B->head and B->A->head simply by
date.
^ permalink raw reply
* Re: Bug encountered while comitting
From: Matthias Kestenholz @ 2006-03-25 1:15 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vacbfzc3u.fsf@assigned-by-dhcp.cox.net>
* Junio C Hamano (junkio@cox.net) wrote:
> 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.
>
Thanks for your answer; I did not know about this option (I should
probably re-read all the docs).
Anyway, I think git should never corrupt a repository, even if it
does not have the write permissions it needs.
The following commands were sufficient to create a corrupt
repository with git (v1.2.4-1, debian package):
$ git-init-db
$ echo test > file
$ git-update-index --add file ; git commit -m 'message'
repeat (f.e. 10 times):
$ echo test >> file
$ git-update-index file ; git commit -m 'message'
$ sudo chown root .git/objects/*
repeat the modification and commit commands until you get a message
similar to the following:
unable to write sha1 filename .git/objects/90/b33..: Permission denied
fatal: 90b33... is not a valid 'tree' object
unable to write sha1 filename .git/objects/ba/fe4..: Permission denied
error: file: failed to insert into database
fatal: Unable to process file file
etc...
The result of this all is: refs/heads/master might now point to a
non-existant commit object. Every git command now errors out with:
fatal: bad tree object HEAD
and git-log shows no output (probably since it does not find a
commit to begin with)
git-commit should abort as soon as it encounters an error and not
update HEAD.
Thanks,
Matthias
(Note: To find the last valid commit object, I could just scan the
objects directory for the recently modified files and write the sha1
value to refs/heads/master, so I had no data loss.)
--
:wq
^ permalink raw reply
* Re: Bug encountered while comitting
From: Matthias Kestenholz @ 2006-03-25 1:15 UTC (permalink / raw)
To: Andreas Ericsson; +Cc: git
In-Reply-To: <442449E1.5060007@op5.se>
* Andreas Ericsson (ae@op5.se) wrote:
> Matthias Kestenholz wrote:
> >
> >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.
>
I think I did not express myself clearly. The PHP Script executes
git commands which in turn create or modify the mentioned
directories. I do not create them myself by hand.
> >When I tried to commit, I got a message saying "Unable to write sha1
> >filename".
> >
>
> What file were you trying to write?
>
Some file I was updating (in this case, a file holding some wiki
content)
> >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 ?
>
Yes.
>
> >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.
As I (only now) wrote in the other email, I got the
"Permission denied" message, and that was a sufficient hint what was
wrong.
--
:wq
^ permalink raw reply
* Re: Errors GITtifying GCC and Binutils
From: Chris Shoemaker @ 2006-03-25 0:37 UTC (permalink / raw)
To: Jan-Benedict Glaw; +Cc: Linus Torvalds, git
In-Reply-To: <20060324075229.GH31387@lug-owl.de>
On Fri, Mar 24, 2006 at 08:52:29AM +0100, Jan-Benedict Glaw wrote:
> On Thu, 2006-03-23 19:39:44 -0500, Chris Shoemaker <c.shoemaker@cox.net> wrote:
> > On Thu, Mar 23, 2006 at 09:03:06PM +0100, Jan-Benedict Glaw wrote:
> > > On Wed, 2006-03-22 17:28:23 -0800, Linus Torvalds <torvalds@osdl.org> wrote:
> > > It seems there's a patch like
> > > http://www.gelato.unsw.edu.au/archives/git/0602/16278.html is missing?
> > > ...or we need a better cvsps. Shall I add it and try again / try to
> > > continue, or give up on it for now? Though it would be nice to have
> > > these two large and important source trees under GIT control :-)
> >
> > You make want to try the cvsps patch I attached to the email here:
> >
> > http://www.gelato.unsw.edu.au/archives/git/0511/11812.html
>
> [...]
> invalid initial_branch for file bfd/po/BLD-POTFILES.in, probably
> from old cache, run with -x.
I guess that error message wasn't quite as obvious as I intended.
That means you have old cvsps cache state hanging around. You can
either run cvsps with -x or delete the cache file manually. Those are
the files in ~/.cvsps.
Incidentally, I'd recommend doing this in two stages during
trouble-shooting. Run cvsps first and verify that you can produce a
valid ancestry tree. If it's not-quite-right you can even edit the
cvsps output to reparent the incorrect branches. Then run
git-cvsimport after you're satisfied with the ancestry.
-chris
^ 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
* 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: 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
* 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: 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: 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: 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: 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: 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
* 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: 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
* 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: 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: 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: 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: 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: 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
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