* Importing from CVS issues
From: Alex Bennee @ 2005-08-16 10:41 UTC (permalink / raw)
To: git
Hi,
We've been having issues with CVS for some time and I thought I'd give
git a spin. To do some like-for-like tests I'm having a go at importing
our cvs repository into git so I can do some benchmarks on things like
branch creation as well as play around with the visualisation tools.
Obviously the CVS repo is non-trivial as we have many branches (one per
change developed). I've been trying to import script but it seems to
falling over. For starters cvsps is spitting out lots of messages along
the lines of:
WARNING: revision 1.3.2.1 of file scripts/xmltools/t/runtests.pl on
unnamed branch
Before the import script finally dies with:
WARNING: revision 1.3.2.1 of file
scripts/xmltools/t/data/gzip/DO-NOT-BACKUP on unnamed branch
DONE; creating master branch
cp: cannot stat `/export/test/cvstogit/.git/refs/heads/origin': No such
file or directory
usage: git-read-tree (<sha> | -m [-u] <sha1> [<sha2> [<sha3>]])
Is this a just a case of the cvsps not giving output the script can deal
with? Any suggestions on how I can proceed with diagnosing what went
wrong?
--
Alex, homepage: http://www.bennee.com/~alex/
Barometer, n.: An ingenious instrument which indicates what kind of
weather we are having. -- Ambrose Bierce, "The Devil's Dictionary"
^ permalink raw reply
* Re: [PATCH] Add merge detection to git-cvsimport
From: Sven Verdoolaege @ 2005-08-16 11:07 UTC (permalink / raw)
To: Martin Langhoff; +Cc: git
In-Reply-To: <20050816103527.F420A33010C@ng.eduforge.org>
On Tue, Aug 16, 2005 at 10:35:27PM +1200, Martin Langhoff wrote:
> +
> +sub get_headref($$) {
If you want to check whether a ref is valid, then
it is better to use git-rev-parse...
> + my $name = shift;
> + my $git_dir = shift;
> + my $sha;
> +
> + if (open(C,"$git_dir/refs/heads/$name")) {
> + chomp($sha = <C>);
> + close(C);
> + length($sha) == 40
> + or die "Cannot get head id for $name ($sha): $!\n";
... but if you're just going to die, then why not simply
let git-commit-tree do the test ?
> + if ($mparent eq 'HEAD') { $mparent = 'origin'};
Please don't hardcode 'origin' here.
skimo
^ permalink raw reply
* Re: Importing from CVS issues
From: Martin Langhoff @ 2005-08-16 11:26 UTC (permalink / raw)
To: Alex Bennee; +Cc: git
In-Reply-To: <1124188894.7444.9.camel@okra.transitives.com>
I haven't seen this problem myself. There are some recent patches
Junio merged that handle some oddities better. Give the 'pu' branch a
go if you can.
I take it that the repo is not public. I'd like to try and reproduce
the problem. Can you get it to happen with a public repository?
For debugging, I'd say proofread the cvsps output, see ~/.cvsps/#repo
. that could give you hints as to the 'nameless' branches. Why is
origin missing is a different problem.
Ah! Important: if you're adding debugging statements by hand, bear in
mind that part of the code is executed in a forked child process, and
prints there will mess things up.
cheers,
martin
^ permalink raw reply
* Re: [PATCH] Add -k kill keyword expansion option to git-cvsimport
From: Martin Langhoff @ 2005-08-16 11:29 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vll32viy5.fsf@assigned-by-dhcp.cox.net>
On 8/16/05, Junio C Hamano <junkio@cox.net> wrote:
> However, the -kk change one is a corrupted patch and does not
> apply. Your MUA ate leading whitespaces, perhaps.
I stupidly did a forward. Rebased to your current pu branch and sent.
From now on I'll be sending straight from cmdline.
> I have already slurped in other two patches to cvsimport in the
> proposed updates branch, so could you kindly proofread them (I
> am no expert on cvs networking protocol issues)
Proofread. I don't claim to have understood 100% but it made sense.
Most importantly, it imported several repos perfectly.
cheers,
martin
^ permalink raw reply
* Re: Importing from CVS issues
From: David Kågedal @ 2005-08-16 12:16 UTC (permalink / raw)
To: git
In-Reply-To: <1124188894.7444.9.camel@okra.transitives.com>
Alex Bennee <kernel-hacker@bennee.com> writes:
> Before the import script finally dies with:
>
> WARNING: revision 1.3.2.1 of file
> scripts/xmltools/t/data/gzip/DO-NOT-BACKUP on unnamed branch
> DONE; creating master branch
> cp: cannot stat `/export/test/cvstogit/.git/refs/heads/origin': No such
> file or directory
Was this done with an empty destination dir? I've seen similar things
happen in a dir where an interrupted cvs import was done previously,
and the 'origin' branch was never created.
--
David Kågedal
^ permalink raw reply
* Re: Importing from CVS issues
From: Alex Bennee @ 2005-08-16 13:48 UTC (permalink / raw)
To: git
In-Reply-To: <u5toe7y2i28.fsf@fidgit.hq.vtech>
On Tue, 2005-08-16 at 14:16 +0200, David Kågedal wrote:
> Alex Bennee <kernel-hacker@bennee.com> writes:
>
> > Before the import script finally dies with:
> >
> > WARNING: revision 1.3.2.1 of file
> > scripts/xmltools/t/data/gzip/DO-NOT-BACKUP on unnamed branch
> > DONE; creating master branch
> > cp: cannot stat `/export/test/cvstogit/.git/refs/heads/origin': No such
> > file or directory
>
> Was this done with an empty destination dir? I've seen similar things
> happen in a dir where an interrupted cvs import was done previously,
> and the 'origin' branch was never created.
Yes, in fact I let the script create the new destination dir. So I don't
think its an issue with stale data from a previous attempt being left
around.
>
--
Alex Bennee - alexjb@transitive.com
"The world is beating a path to our door" -- Bruce Perens, (Open
Sources, 1999 O'Reilly and Associates)
^ permalink raw reply
* Submitting patches w/ Thunderbird [was: Re: [PATCH] Add SubmittingPatches]
From: A Large Angry SCM @ 2005-08-16 15:22 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Junio C Hamano, git
In-Reply-To: <Pine.LNX.4.63.0508160335420.1574@wgmdd8.biozentrum.uni-wuerzburg.de>
Johannes Schindelin wrote:
> Hi,
>
> On Mon, 15 Aug 2005, Junio C Hamano wrote:
>
>>Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>>
>>>Maybe we should enhance git-applymbox to detect whitespace corruption in
>>>particular, and output the User-Agent header (or if that does not
>>>exist, the Message-ID header; thanks, pine) on error.
>
> Alternatively, SubmittingPatches could include a big fat CAVEAT, and a
> note that the submitter might want to send a single SP to herself, save
> the received mail and check that all is well, prior to sending the first
> patch. I mean, well, erm, it is sort of, uh, annoying, to send out a
> corrupt patch *speaksofyourstruly*.
Here are some hints on how to successfully submit patches inline using
Thunderbird.
This recipe appears to work with the current [*1*] Thunderbird from Suse.
The following Thunderbird extensions are needed:
AboutConfig 0.5
http://aboutconfig.mozdev.org/
External Editor 0.5.4
http://extensionroom.mozdev.org/more-info/exteditor
1) Prepare the patch as a text file using your method of choice.
2) Before opening a compose window, use Edit->Account Settings to
uncheck the "Compose messages in HTML format" setting in the
"Composition & Addressing" panel of the account to be used to send the
patch. [*2*]
3) In the main Thunderbird window, _before_ you open the compose window
for the patch, use Tools->about:config to set the following to the
indicated values:
mailnews.send_plaintext_flowed => false
mailnews.wraplength => 999
4) Open a compose window and click the external editor icon.
5) In the external editor window, read in the patch file and exit the
editor normally.
6) Back in the compose window: Add whatever other text you wish to the
message, complete the addressing and subject fields, and press send.
7) Optionally, undo the about:config/account settings changes made in
steps 2 & 3.
[Footnotes]
*1* Version 1.0 (20041207) from the MozillaThunderbird-1.0-5 rpm of Suse
9.3 professional updates.
*2* It may be possible to do this with about:config and the following
settings but I haven't tried, yet.
mail.html_compose => false
mail.identity.default.compose_html => false
mail.identity.id?.compose_html => false
^ permalink raw reply
* Re: Git 1.0 Synopis (Draft v4)
From: Johannes Schindelin @ 2005-08-16 15:31 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Daniel Barkalow, Ryan Anderson, git
In-Reply-To: <7vy872fiin.fsf@assigned-by-dhcp.cox.net>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 1072 bytes --]
Hi,
On Tue, 16 Aug 2005, Junio C Hamano wrote:
> - Are all the files in Documentation/ reachable from git(7)
> or otherwise made into a standalone document using asciidoc
> by the Makefile? I haven't looked into documentation
> generation myself (I use only the text files as they are);
> help to update the Makefile by somebody handy with asciidoc
> suite is greatly appreciated here.
>
> Volunteers?
The attached script reveals:
git-unpack-objects.txt is not reachable from git.txt
git-cvsimport-script.txt is not reachable from git.txt
git-send-email-script.txt is not reachable from git.txt
git-rename-script.txt is not reachable from git.txt
tutorial.txt is not reachable from git.txt
git-show-index.txt is not reachable from git.txt
cvs-migration.txt is not reachable from git.txt
diffcore.txt is not reachable from git.txt
git-ls-remote-script.txt is not reachable from git.txt
git-apply.txt is not reachable from git.txt
git-diff-stages.txt is not reachable from git.txt
pack-protocol.txt is not reachable from git.txt
Ciao,
Dscho
[-- Attachment #2: Type: APPLICATION/x-perl, Size: 1215 bytes --]
^ permalink raw reply
* Re: Git 1.0 Synopis (Draft v4)
From: Daniel Barkalow @ 2005-08-16 15:39 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Ryan Anderson, git
In-Reply-To: <7vy872fiin.fsf@assigned-by-dhcp.cox.net>
On Tue, 16 Aug 2005, Junio C Hamano wrote:
> Daniel Barkalow <barkalow@iabervon.org> writes:
>
> > It might be worth putting the list of things left to do before 1.0 in the
> > tree (since they clearly covary), and it would be useful to know what
> > you're thinking of as preventing the release at any particular stage.
>
> Yeah, yeah. Call me lazy.
>
> Excerpts from my "last mile to 1.0", my Itchlist, and pieces from
> random other messages since then.
>
> - Documentation. [I really need help here --- among ~7000 lines
> there, I've written around 2500 lines, David Greaves another
> 2500, and Linus 1400. And it is not very easy to proofread
> what you wrote yourself.]
I'm not sure how done this can actually get before some sort of feature
freeze; the best ways to do things keeps changing as more convenient ways
are added. Once the new stuff is diverted to post-1.0, I'd be interested
in going through it.
> - git prune and git fsck-cache; think about their interactions
> with an object database that borrows from another. This
> includes the case where .git/objects itself is symlinked to
> somewhere else (i.e. running "git prune" that somewhere else
> without consulting this repository would lose objects), and
> alternates pointing at somewhere else (i.e. ditto).
It should be fine, but only if .git/refs is symlinked to the matching
place; this gives you the same repository with multiple working trees.
Having refs/ and objects/ directories that aren't always together would be
much less safe.
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* Re: Git 1.0 Synopis (Draft v4)
From: Daniel Barkalow @ 2005-08-16 15:47 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Junio C Hamano, Ryan Anderson, git
In-Reply-To: <Pine.LNX.4.63.0508161730120.11105@wgmdd8.biozentrum.uni-wuerzburg.de>
On Tue, 16 Aug 2005, Johannes Schindelin wrote:
> Hi,
>
> On Tue, 16 Aug 2005, Junio C Hamano wrote:
>
> > - Are all the files in Documentation/ reachable from git(7)
> > or otherwise made into a standalone document using asciidoc
> > by the Makefile? I haven't looked into documentation
> > generation myself (I use only the text files as they are);
> > help to update the Makefile by somebody handy with asciidoc
> > suite is greatly appreciated here.
> >
> > Volunteers?
>
> The attached script reveals:
>
> git-unpack-objects.txt is not reachable from git.txt
> git-cvsimport-script.txt is not reachable from git.txt
> git-send-email-script.txt is not reachable from git.txt
> git-rename-script.txt is not reachable from git.txt
> tutorial.txt is not reachable from git.txt
> git-show-index.txt is not reachable from git.txt
> cvs-migration.txt is not reachable from git.txt
> diffcore.txt is not reachable from git.txt
> git-ls-remote-script.txt is not reachable from git.txt
> git-apply.txt is not reachable from git.txt
> git-diff-stages.txt is not reachable from git.txt
> pack-protocol.txt is not reachable from git.txt
The ones that don't start with git probably don't belong in the same set;
perhaps there should be a "technical" (or something similar but shorter)
subdirectory for developer documentation instead of user documentation?
(And tutorial and cvs-migration can move to howto)
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* Re: Making note, in the repository, of push/pull relationships
From: Carl Baldwin @ 2005-08-16 16:03 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Carl Baldwin, git
In-Reply-To: <Pine.LNX.4.63.0508160044490.25894@wgmdd8.biozentrum.uni-wuerzburg.de>
On Tue, Aug 16, 2005 at 12:49:33AM +0200, Johannes Schindelin wrote:
> Hi,
>
> On Mon, 15 Aug 2005, Carl Baldwin wrote:
>
> > Somewhere in the thread something was mentioned about maintaining
> > <local branch>:<remote branch> pairs in the git repository when pushes
> > and pulls are performed. I think the argument was actually against
> > keeping this information and ultimately against allowing pushes to a
> > branch of a different name.
>
> I think the loudest voice was mine :-)
>
> Actually, I was not against *keeping* the information, but against
> *pulling* in such strange ways. If "cross-pulling" is allowed, I am all
> for keeping track of that.
So, just a question. What, exactly, is meant by 'cross-pulling'?
> In the meantime, I did not think about the issue at all :-) However, as is
> often the case in an open discussion, I think I was wrong after all. There
> may be cases you want that, and in the end, nobody forces me to use that
> feature.
>
> Anyway, Junio decided to enhance the fetch mechanism to support the
> cross-pulling (and also multi-pulling).
>
> Ciao,
> Dscho
>
--
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Carl Baldwin Systems VLSI Laboratory
Hewlett Packard Company
MS 88 work: 970 898-1523
3404 E. Harmony Rd. work: Carl.N.Baldwin@hp.com
Fort Collins, CO 80525 home: Carl@ecBaldwin.net
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
^ permalink raw reply
* Re: Importing from CVS issues
From: Alex Bennee @ 2005-08-16 16:09 UTC (permalink / raw)
To: Martin Langhoff; +Cc: git
In-Reply-To: <46a038f90508160426450eff12@mail.gmail.com>
On Tue, 2005-08-16 at 23:26 +1200, Martin Langhoff wrote:
> I haven't seen this problem myself. There are some recent patches
> Junio merged that handle some oddities better. Give the 'pu' branch a
> go if you can.
I'll look at that in a bit. I already picked up a few of the patches
mentioned on the list.
> I take it that the repo is not public. I'd like to try and reproduce
> the problem. Can you get it to happen with a public repository?
I'm afraid not. However I think I've found a problem when I tried
running cvsps on its own to generate the patchset. It seems that
REV_STR_MAX (cvsps-2.1/cvsps_types.h) wasn't big enough to contain some
of our version strings.
This will be a feature of our development process which means all
changes are based of branches, some of which branch multiple times and
live for a long time before code is merged into the mainline. I don't
know if any open source projects use CVS in such a way.
My import seems to be getting a lot further now. I now just need to
clean out the corrupted files that are breaking cvs log.
--
Alex, homepage: http://www.bennee.com/~alex/
New systems generate new problems.
^ permalink raw reply
* Re: Making note, in the repository, of push/pull relationships
From: Carl Baldwin @ 2005-08-16 17:11 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Carl Baldwin, git
In-Reply-To: <7vzmrispi4.fsf@assigned-by-dhcp.cox.net>
On Mon, Aug 15, 2005 at 05:18:43PM -0700, Junio C Hamano wrote:
> If you are referring to what I said about the user having some
> control over both ends hence it should be possible to arrange to
> use the same name on both ends to reduce mental burden, Pasky
> and others convinced me otherwise during later discussions, and
> the current core knows how to do renaming pushes.
I wasn't referring to any particular post just a general idea that came
up in the thread. I wanted a starting point to present my thoughts. :-)
> $ cat .git/remotes/ko
> URL: master.kernel.org:/pub/scm/git/git.git/
> Push: master pu rc
> Pull: master:ko-master pu:ko-pu rc:ko-rc
This is very close to what I was getting at. It records each branch
involved and wether the relationship is push or pull (or possibly both).
If I may, let me give an example of something I think could serve the
purpose a little more simply and generically.
Let's say I start with the following:
% ls .git/refs/heads
master
mylocalbranch
myremotebranch
ko-master
% cat .git/branches/ko-master
master.kernel.org:/pub/scm/git/git.git
I would add something like this: (I didn't put much thought into the
actual directory and file names, forgive me. ;-)
% cat .git/branches/relationships
pull:ko-master:master
pull:master:mylocalbranch # The next two document my flow locally
pull:mylocalbranch:master
push:master:myremotebranch # I push my master to a remote that I control
_OR_
% ls .git/relationships/*
pull:ko-master:master
pull:master:mylocalbranch
pull:mylocalbranch:master
push:master:myremotebranch
I think this is flexible and could easily support the workflow that you
present below. You could do the following as a convenience in using
fetch in addition to what I suggest above.
% cat .git/remotes/ko
push: master:ko-master pu:ko-pu rc:ko-rc
pull: ko-master:master ko-pu:pu ko-rc:rc
I might argue that this is now a job for a porcelain script or
something.
With the addition of the simple relationships file a complete graph of
your workflow could derived. There is no assumption on what the
workflow is nor if the branches are local or remote. This work flow can
be arbitrarily simple or complex but further complexity can and should
be handled in the porcelains.
> The expected workflow with the above example "remotes" file is
> for me to be able to do this:
>
> (1) fetch from master.kernel.org (that is the source of the
> mirroring for everybody to see on {www,rsync}.kernel.org)
> before starting my day. The current "git fetch" does not
> do this, but make it:
>
> $ git fetch ko
This is still doable. As is this...
> (2) after doing work in my private repository, push to
> master.kernel.org with:
>
> $ git push ko
>
> Note that I am _not_ expecting for "git push/pull/fetch"
> commands to dynamically update .git/remotes/ file whenever it
So, with the way I suggest splitting up refspecs and 'relationships' I
_would_ suggest dynamically adding to (but not deleting from) the
relationships file. But, I agree with you about the refspec. I think
this should be 100% supplied by the user or porcelain.
Adding relationships dynamically will be a good way to document whatever
flow is being used. Also, the savy user can periodically check the file
(or a porcelain with a pretty interface could do something intelligent
with it) to see how his work flow has evolved. He can also
delete relationships that are no longer needed if he is a clean-freak
like me ;-)
I really think there is some good common ground here. Let's keep going
with this. I actually have an idea brewing up for a porcelain to handle
work-flow in a tightly-knit corporate type development environment.
Hey, I've enjoyed the discussion. I hope to make a valuable
contribution to git. I think it has incredible potential.
Cheers,
Carl
> would not push usual "master pu rc" but create a new "testing"
> branch there, starting at the commit which is the head commit of
> the local "pu" branch. This is a one-shot override, so next
> time around, "git push ko" will do the usual three heads that is
> recorded in the .git/remotes/ko file.
>
>
--
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Carl Baldwin Systems VLSI Laboratory
Hewlett Packard Company
MS 88 work: 970 898-1523
3404 E. Harmony Rd. work: Carl.N.Baldwin@hp.com
Fort Collins, CO 80525 home: Carl@ecBaldwin.net
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
^ permalink raw reply
* Re: [PATCH] Add git-branches-script
From: Kalle Valo @ 2005-08-16 17:53 UTC (permalink / raw)
To: Amos Waterland; +Cc: junkio, git
In-Reply-To: <20050815204430.GA77829@rossby.metr.ou.edu>
Amos Waterland <apw@rossby.metr.ou.edu> writes:
> For people whose workflow involves switching back and forth between a
> lot of branches, it can be really helpful to be able to quickly tell
> which branch you are on and which ones are available. This patch
> introduces a small script that when invoked as `git branches' prints a
> list of available branches with a star in front of the one you are on:
>
> $ cd linux-2.6/
> $ git checkout -b ppc64-cleanups
> $ git checkout -b ppc64-new-devel
> $ git checkout -b ppc64-all-merge
> $ git branches
> master
> * ppc64-all-merge
> ppc64-cleanups
> ppc64-new-devel
I would prefer to using some git command compared to 'ls -l
.git/refs/heads/'. In my opinion there is a need for this command and
it should be included.
But my immediate concern was that there is already 'git branch'
command and 'git branches' is too similar. I think they should be
merged. I have a patch coming up.
--
Kalle Valo
^ permalink raw reply
* [PATCH] Change git-branch to list branches
From: Kalle Valo @ 2005-08-16 17:58 UTC (permalink / raw)
To: Amos Waterland; +Cc: junkio, git
In-Reply-To: <87hddplqdu.fsf@litku.valo.iki.fi>
If no argument provided to `git branch`, show available branches and
mark current branch with star.
This is based on patch written by Amos Waterland <apw@rossby.metr.ou.edu>.
Signed-off-by: Kalle Valo <Kalle.Valo@iki.fi>
---
git-branch-script | 8 +++++++-
1 files changed, 7 insertions(+), 1 deletions(-)
38aca3bb4ad4e6b0e10e295a87a9f5ce37ff5be4
diff --git a/git-branch-script b/git-branch-script
--- a/git-branch-script
+++ b/git-branch-script
@@ -11,7 +11,13 @@ case "$2" in
esac
rev=$(git-rev-parse --revs-only --verify "$head") || exit
-[ -z "$branchname" ] && die "git branch: I want a branch name"
+if [ -z "$branchname" ]; then
+ current=$(basename $(readlink $GIT_DIR/HEAD))
+ cd $GIT_DIR/refs/heads &&
+ ls | sed -e "s/^/ /" -e "s/ $current/* $current/"
+ exit
+fi
+
[ -e "$GIT_DIR/refs/heads/$branchname" ] && die "$branchname already exists"
echo $rev > "$GIT_DIR/refs/heads/$branchname"
^ permalink raw reply
* [PATCH] Make tools use DESTDIR as well (otherwise rpm build is broken)
From: Chris Wright @ 2005-08-16 18:28 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
Please pull from:
rsync.kernel.org://pub/scm/linux/kernel/git/chrisw/git
This will give you the following trivial fix for the rpm build, where
tools was still using dest not DESTDIR.
thanks,
-chris
--
diff-tree 5eaaed02111510ff00b288a99ec3d203d5d1761f (from d9ac9df41c8c1c3a2f5b0fb1bcc0546dc1bafba2)
tree 636f8c808fd80fb886c5c8b96e854d7d9dea8591
parent d9ac9df41c8c1c3a2f5b0fb1bcc0546dc1bafba2
author Chris Wright <chrisw@osdl.org> 1124215389 -0700
committer Chris Wright <chrisw@osdl.org> 1124215389 -0700
Make tools use DESTDIR as well (otherwise rpm build is broken).
Signed-off-by: Chris Wright <chrisw@osdl.org>
diff --git a/tools/Makefile b/tools/Makefile
--- a/tools/Makefile
+++ b/tools/Makefile
@@ -18,7 +18,7 @@ git-%: %.c
all: $(PROGRAMS)
install: $(PROGRAMS) $(SCRIPTS)
- $(INSTALL) -m755 -d $(dest)$(bindir)
+ $(INSTALL) -m755 -d $(DESTDIR)$(bindir)
$(INSTALL) $(PROGRAMS) $(SCRIPTS) $(DESTDIR)$(bindir)
clean:
^ permalink raw reply
* Re: [PATCH] Make tools use DESTDIR as well (otherwise rpm build is broken)
From: Junio C Hamano @ 2005-08-16 18:59 UTC (permalink / raw)
To: Chris Wright; +Cc: git
In-Reply-To: <20050816182802.GH8041@shell0.pdx.osdl.net>
My bug. Thanks.
^ permalink raw reply
* Re: [PATCH] Alternate object pool mechanism updates.
From: Linus Torvalds @ 2005-08-16 19:07 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Petr Baudis, git
In-Reply-To: <7vr7cw7ypt.fsf@assigned-by-dhcp.cox.net>
On Sun, 14 Aug 2005, Junio C Hamano wrote:
> Linus Torvalds <torvalds@osdl.org> writes:
>
> > I think this is great - especially for places like kernel.org, where a lot
> > of repos end up being related to each other, yet independent.
>
> Yes. There is one shortcoming in the current git-clone -s in
> the proposed updates branch. If the parent repository has
> alternates on its own, that information should be copied to the
> cloned one as well (e.g. Jeff has alternates pointing at you,
> and I clone from Jeff with -s flag --- I should list not just
> Jeff but also you to borrow from in my alternates file).
Btw, looking at the code, it strikes me that using ":" to separate the
alternate object directories in the file is rather strange.
Maybe allow a different format for the file? Or at least allow '\n' as an
alternate separator (but it would be nice to allow comments too).
Finally, I have to say that that "info" directory is confusing. Namely,
there's two of them - the "git info" and the "object info" directories are
totally different directories - maybe logical, but to me it smells like
"info" is here a code-name for "misc files that don't make sense anywhere
else".
Anyway, I don't think "alternates" is necessarily sensible as a "object"
information. Sure, it's about alternate objects, but the thing is, object
directories can be shared across many projects, but "alternates" to me
makes more sense as a per-project thing.
What this all is leading up to is that I think we'd be better off with a
totally new "git config" file, in ".git/config", and we'd have all the
startup configuration there. Including things like alternate object
directories, perhaps standard preferences for that particular repo, and
things like the "grafts" thing.
Wouldn't that be nice?
Linus
^ permalink raw reply
* Re: [PATCH] Alternate object pool mechanism updates.
From: Daniel Barkalow @ 2005-08-16 19:45 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Junio C Hamano, Petr Baudis, git
In-Reply-To: <Pine.LNX.4.58.0508161156430.3553@g5.osdl.org>
On Tue, 16 Aug 2005, Linus Torvalds wrote:
> Finally, I have to say that that "info" directory is confusing. Namely,
> there's two of them - the "git info" and the "object info" directories are
> totally different directories - maybe logical, but to me it smells like
> "info" is here a code-name for "misc files that don't make sense anywhere
> else".
>
> What this all is leading up to is that I think we'd be better off with a
> totally new "git config" file, in ".git/config", and we'd have all the
> startup configuration there. Including things like alternate object
> directories, perhaps standard preferences for that particular repo, and
> things like the "grafts" thing.
>
> Wouldn't that be nice?
I'd originally proposed the .git/info directory because I keep multiple
working trees for the same repository, by having symlinks for .git/objects
and .git/refs, and I could also get other per-repository things to be
shared properly without knowing exactly what they are if they're in a
subdirectory of .git that could be a symlink. This would mean that a
".git/config" would be per-working-tree, like .git/index or .git/HEAD, not
pre-repository like ".git/info/config". Of course, the core didn't have
any thing to go in .git/info at the time, so it didn't really get tacked
down.
(I find it convenient to have mainline and my latest work both checked out
for reference while I'm generating a series of commits for a patch set,
and I don't want three different repositories which could be out of sync;
this also keeps the repository safely out of pwd, since I have the actual
repositories as ~/git/{project}.git/)
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* Re: Git 1.0 Synopis (Draft v4)
From: Horst von Brand @ 2005-08-16 19:41 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Daniel Barkalow, Ryan Anderson, git
In-Reply-To: <7vy872fiin.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> wrote:
[...]
> - Oh, another itch I did not list in the previous message. Is
> anybody interested in doing an Emacs VC back-end for GIT?
And teach make(1) about checking out files from git... or just create a
co(1) command for git.
--
Dr. Horst H. von Brand User #22616 counter.li.org
Departamento de Informatica Fono: +56 32 654431
Universidad Tecnica Federico Santa Maria +56 32 654239
Casilla 110-V, Valparaiso, Chile Fax: +56 32 797513
^ permalink raw reply
* [RFC] Patches exchange is bad?
From: Marco Costalba @ 2005-08-16 20:01 UTC (permalink / raw)
To: git
Hi,
I would like to ask the list about something I'am thinking about,
and I'am not sure it's a good idea.
Suppose a possible scenario involves using a couple of git archives, one
for releases and stable code, say MAIN, and one for experimental stuff
or new development, say HEAD.
Suppose there is stuff in HEAD you don't want merged in MAIN, more,
you need to update MAIN with only a subset of patches in HEAD, peraphs
in different order. Or simply, you are not interested to see the history
of the HEAD tree when looking MAIN. All this points could keep you
from merging.
I have mocked up a very simple and very stupid 'drag and drop' function.
Basically you drag some selected revs in another instance of qgit, open on
a different archive.
What happpens in the background is that git-format-patch-script is feeded
with the selected revs and a bunch of temporary patch files are created,
then git-applymbox (re)creates the corresponding commits in the destination
archive.
It is just a very thin layer above the two git scripts, the only extra work
is the cleaning up of some info that git-format-patch-script automatically adds,
so that the new commits look like the originals (i.e. same header and description).
I've built-up this thing mainly because I found it useful for me, but I have
some concerns that this is the correct way to go, the way git it's meant to be used.
If there is some interest for this I can push something on SF, after a due polishing,
but if it is deeply broken I prefer discard and eventually switch to a more consistent
workflow.
What do you think?
Marco
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
^ permalink raw reply
* Re: [PATCH] Alternate object pool mechanism updates.
From: Junio C Hamano @ 2005-08-16 20:38 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Petr Baudis, git
In-Reply-To: <Pine.LNX.4.58.0508161156430.3553@g5.osdl.org>
Linus Torvalds <torvalds@osdl.org> writes:
> Btw, looking at the code, it strikes me that using ":" to separate the
> alternate object directories in the file is rather strange.
Yes, I admit it one was done in a quick and dirty way. Patches
welcome [*1*] ;-)
> Anyway, I don't think "alternates" is necessarily sensible as a "object"
> information. Sure, it's about alternate objects, but the thing is, object
> directories can be shared across many projects, but "alternates" to me
> makes more sense as a per-project thing.
Well, I have to think about this a bit more, but I have to say
there were some thinking behind the way things are right now.
$GIT_DIR/info describes properties of the repository. That's
why refs, graft and rev-cache go there.
$GIT_OBJECT_DIRECTORY/info describes the properties of the
object pool (I am inventing words as I speak, but an object pool
is a directory that can be combined with other object pools to
make an object database). So object/info/packs talks about the
packs in it, but not about packs it borrows from its alternates.
The alternates file in question talks about what other object
pools you need to consult to obtain the objects it refers to but
it lacks itself. If two repositories share a particular object
pool as its .git/objects directory, by symlinking .git/objects
or by using GIT_OBJECT_DIRECTORY environment, it does not matter
from which repository you look at this object pool. The set of
objects it refers to but lacks itself, and from which other
pools these objects can be obtained, do not depend on from which
repository you are looking at it. While I agree with everything
you said about "maybe logical but confusing", I have to disagree
with you about this one.
> What this all is leading up to is that I think we'd be better off with a
> totally new "git config" file, in ".git/config", and we'd have all the
> startup configuration there.
I think what _is_ lacking is an easy way to have per repository
configuration that can be shared among "opt-in" developers. The
graft file naturally falls into this category, and probably the
Porcelain standard .git/info/exclude file as well. Although we
ended up doing .git/hooks, it is a per repository thing and
logically it _could_ be moved to .git/info/hooks [*2*]. And
that might also be a nice thing to share among "opt-in"
developers.
[Footnote]
*1* Sorry I could not resist --- I always wanted to say this.
*2* I do not think we _should_ move it under .git/info, though.
^ permalink raw reply
* Re: [RFC] Patches exchange is bad?
From: Johannes Schindelin @ 2005-08-16 20:39 UTC (permalink / raw)
To: Marco Costalba; +Cc: git
In-Reply-To: <20050816200132.88287.qmail@web26304.mail.ukl.yahoo.com>
Hi,
On Tue, 16 Aug 2005, Marco Costalba wrote:
> Suppose a possible scenario involves using a couple of git archives, one
> for releases and stable code, say MAIN, and one for experimental stuff
> or new development, say HEAD.
>
> Suppose there is stuff in HEAD you don't want merged in MAIN, more,
> you need to update MAIN with only a subset of patches in HEAD, peraphs
> in different order. Or simply, you are not interested to see the history
> of the HEAD tree when looking MAIN. All this points could keep you
> from merging.
This looks like a good description of cherry picking. See StGIT (and to a
certain extent, git-cherry) for that.
Ciao,
Dscho
^ permalink raw reply
* Re: Git 1.0 Synopis (Draft v4)
From: Johannes Schindelin @ 2005-08-16 20:41 UTC (permalink / raw)
To: Horst von Brand; +Cc: Junio C Hamano, Daniel Barkalow, Ryan Anderson, git
In-Reply-To: <200508161941.j7GJfpI3023107@laptop11.inf.utfsm.cl>
Hi,
On Tue, 16 Aug 2005, Horst von Brand wrote:
> And teach make(1) about checking out files from git... or just create a
> co(1) command for git.
How about "git-checkout-script", optionally with the "-f" flag to ignore
changes since the last checkout/checkin?
Ciao,
Dscho
^ permalink raw reply
* Re: Making note, in the repository, of push/pull relationships
From: Johannes Schindelin @ 2005-08-16 20:45 UTC (permalink / raw)
To: Carl Baldwin; +Cc: git
In-Reply-To: <20050816160327.GA20016@hpsvcnb.fc.hp.com>
Hi,
On Tue, 16 Aug 2005, Carl Baldwin wrote:
> So, just a question. What, exactly, is meant by 'cross-pulling'?
When I say "cross-pulling" I mean that a branch is pulled from a remote
repository, where the named head is called "a", but that reference is
pulled into the local branch whose head is "b".
Example:
--snip--
> git-ls-remote-script junio
abe0582207c72ec848e78707577c61a98f5c633d refs/heads/master
c506e5687b9257c6182950f245d58cf839abfae4 refs/heads/pu
1f40c7c24d999675df818f9d7824937a964f9f40 refs/heads/rc
0918385dbd9656cab0d1d81ba7453d49bbc16250 refs/tags/junio-gpg-pub
d6602ec5194c87b0fc87103ca4d67251c76f233a refs/tags/v0.99
f25a265a342aed6041ab0cc484224d9ca54b6f41 refs/tags/v0.99.1
c5db5456ae3b0873fc659c19fafdde22313cc441 refs/tags/v0.99.2
7ceca275d047c90c0c7d5afb13ab97efdf51bd6e refs/tags/v0.99.3
b3e9704ecdf48869f635f0aa99ddfb513f885aff refs/tags/v0.99.4
> git-pull-script junio pu:temporary-proposed-updates
[...]
> echo .git/refs/heads/temporary-proposed-updates
c506e5687b9257c6182950f245d58cf839abfae4
--snap--
So, the remote branch "pu" gets cross-pulled to the local branch
"temporary-proposed-updates", i.e. to a local branch of a different name.
Ciao,
Dscho
^ 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