* Re: Tags not transferred with git pull?
From: Erik Mouw @ 2005-11-04 16:05 UTC (permalink / raw)
To: git
In-Reply-To: <20051104155914.GA9567@ferdyx.org>
On Fri, Nov 04, 2005 at 04:59:14PM +0100, Fernando J. Pereda wrote:
> On Fri, Nov 04, 2005 at 04:53:14PM +0100, Erik Mouw wrote:
> | Is it OK that the latest git (0.99.9c) doesn't get the tags
> | (refs/tags/*) when doing a git pull? It's getting a bit of a nuisance
> | to do a separate rsync to get them right.
>
> As Linus explained in a message earlier, a git fetch --tags will do it.
Ah, right. I got the impression that the latest git was supposed to do
that automatically with a git pull.
Erik
--
+-- Erik Mouw -- www.harddisk-recovery.com -- +31 70 370 12 90 --
| Lab address: Delftechpark 26, 2628 XH, Delft, The Netherlands
^ permalink raw reply
* Fixing Commit And Author
From: Darrin Thompson @ 2005-11-04 16:38 UTC (permalink / raw)
To: git
I've got a small project in git where I made a dumb error. All my
commits have author/committer information like this:
Author: Darrin Thompson <darrint@dhcp-1-211.(none)> 2005-10-20 16:50:38
Committer: Darrin Thompson <darrint@dhcp-1-211.(none)> 2005-10-20
16:50:38
Tags: svn-5099
I'd like to replace the commits (yes, I know that means all of them)
with new ones with corrected email addresses and also manage to migrate
my tags. A push in the right direction would be appreciated.
Next I'd like to do the same with the kernel sources... :-)
--
Darrin
^ permalink raw reply
* Re: [PATCH] v2: proxy-command support for git://
From: Junio C Hamano @ 2005-11-04 16:50 UTC (permalink / raw)
To: Paul Collins; +Cc: git
In-Reply-To: <871x1wbgvn.fsf_-_@briny.internal.ondioline.org>
Paul Collins <paul@briny.ondioline.org> writes:
> Regarding internal vs. external hosts, the proxy command can simply
> run netcat locally to internal hosts, so perhaps that is sufficient.
I was hoping this to become a bit more generalized mechanism
than that; for example using outgoing plug over HTTP Connect or
telnet proxy using tn-gw-nav.
^ permalink raw reply
* Re: binary safe?
From: David Brown @ 2005-11-04 16:54 UTC (permalink / raw)
To: git
In-Reply-To: <46a038f90511031500p3d6ed433s6efe3f5a5e60bcf8@mail.gmail.com>
On Fri, Nov 04, 2005 at 12:00:54PM +1300, Martin Langhoff wrote:
> Yes it works, and cvsimport -k will do the right thing for you.
Unless it has changed from 0.99.9b, 'cvsimport -k' will very much scramble
some binary files. '-k' passes the '-kk' option which causes CVS to strip
the keywords down. It needs to pass -ko through if you want it to be able
to handle binary files.
However, since CVS (RCS really) can remember the state of this flag, it
does work to 'cvs admin -ko filename' beforehand, and then do the
cvsimport without the '-k' option.
Dave
^ permalink raw reply
* Re: CFLAGS usage
From: David Brown @ 2005-11-04 16:59 UTC (permalink / raw)
To: Morten Welinder; +Cc: GIT Mailing List
In-Reply-To: <118833cc0511040721w7f3990fbw631feaa6a4bda936@mail.gmail.com>
On Fri, Nov 04, 2005 at 10:21:55AM -0500, Morten Welinder wrote:
> Various stuff is being added to CFLAGS, but CFLAGS is not being used
> after being composed in CFLAGS_ALL.
> CFLAGS = -g -O2 -Wall
> ALL_CFLAGS = $(CFLAGS) $(PLATFORM_DEFINES) $(DEFINES)
> CFLAGS += -I$(CURLDIR)/include
Make expands variable lazily, so the ALL_CFLAGS expansion only happens at
the point of use, where all of the CFLAGS definitions have been made.
Dave
^ permalink raw reply
* Re: Now What?
From: Daniel Barkalow @ 2005-11-04 17:06 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vll05bd1w.fsf@assigned-by-dhcp.cox.net>
On Thu, 3 Nov 2005, Junio C Hamano wrote:
> Daniel Barkalow <barkalow@iabervon.org> writes:
>
> > On Thu, 3 Nov 2005, Junio C Hamano wrote:
> >
> >> "Peter Eriksen" <s022018@student.dtu.dk> writes:
> >>
> >> > ~/git/git-core]cat .git/remotes/origin
> >> > URL: git://git.kernel.org/pub/scm/git/git.git
> >> > Pull: master:origin
> >> >
> >> > ~/git/git-core]git-checkout maint
> >> > ~/git/git-core]git pull
> >>
> >> You are merging my master into your "maint", probably a copy of
> >> my (previous) maint.
> >
> > I think the situation is that he really wanted to update master, but
> > forgot that he was on the maint branch.
>
> I wonder if it would make sense to have something in .git/remotes/
> file that says "run merge only when I am on frotz branch", like
> this:
>
> ~/git/git-core]cat .git/remotes/origin
> URL: git://git.kernel.org/pub/scm/git/git.git
> Pull: master:origin
> Fetch-Only-Unless: master
>
> ~/git/git-core]git-checkout maint
> ~/git/git-core]git pull
> warning: not merging because you are not on 'master' branch.
>
> This would make the above "git pull" behave identical to "git
> fetch", and the user can then do:
>
> $ git checkout master
> $ git pull . origin
>
> Useful? Useless?
People probably want to merge master into their personal work branches,
though; I think it would be better to have it list branches into which it
shouldn't be merged. I think the pair of "maint" and "master" are special,
in that they get different fixes for the same problems, and so they'll
merge badly or to a wrong result.
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* Re: Fixing Commit And Author
From: Linus Torvalds @ 2005-11-04 17:30 UTC (permalink / raw)
To: Darrin Thompson; +Cc: git
In-Reply-To: <1131122325.5446.14.camel@localhost.localdomain>
On Fri, 4 Nov 2005, Darrin Thompson wrote:
> I've got a small project in git where I made a dumb error. All my
> commits have author/committer information like this:
>
> Author: Darrin Thompson <darrint@dhcp-1-211.(none)> 2005-10-20 16:50:38
> Committer: Darrin Thompson <darrint@dhcp-1-211.(none)> 2005-10-20
> 16:50:38
> Tags: svn-5099
>
> I'd like to replace the commits (yes, I know that means all of them)
> with new ones with corrected email addresses and also manage to migrate
> my tags. A push in the right direction would be appreciated.
There's a program in the git sources called "git-convert-objects.c".
It basically knows how to walk the git object chains, and rewrite each
object according to a few rules.
The rules currently do _not_ include changing the author/committer info,
but it does know how to parse the really old-style dates, for example,
which are on those same lines, so adding some code there to also re-write
the author/committer name and email wouldn't be impossible.
The code isn't necessarily all that easy to understand, and usage-wise you
also have to convert each head separately (you tell it which branch head
you want to convert, it trawls every reachable object from that head, and
will create the new objects and return the new head value).
What I'm trying to say is that it might not be _pleasant_, but it's
certainly something you can automate and do in a timely manner (ie a small
project will take just a few seconds - or minutes - to convert).
> Next I'd like to do the same with the kernel sources... :-)
The same program will work, but it will take some time.
Actually, as long as you only rewrite commits, it should even be
reasonably efficient. It's when you start rewriting every single object
(like I did when I switched the compression scheme around) that it gets
_really_ expensive, and a project like the kernel would take a long long
time.
Hint to the wise: don't do the conversion on the only copy of the
repository you have. It's always worked for me, but hey, maybe I'm just
lucky and never write buggy conversion software.
Linus
^ permalink raw reply
* Re: [PATCH] Cogito: Support for implicit remote branches in cloned repositories
From: Junio C Hamano @ 2005-11-04 17:43 UTC (permalink / raw)
To: Josef Weidendorfer; +Cc: git
In-Reply-To: <200511041701.48881.Josef.Weidendorfer@gmx.de>
Josef Weidendorfer <Josef.Weidendorfer@gmx.de> writes:
> ... One difference of cloning with GIT vs. with
> Cogito is that Git always clones all remote branches. This can
> be limiting if you want to work with multiple repositories,
> but allows you to immediatly work with all the branches.
Three points, and two footnotes.
. After a git clone, you can still fetch from non-origin
repository; you can also set up .git/remotes/somewhere-else if
you pull from the non-origin repository regularly, so it is
not really "limiting". It is just being slightly less
convenient, in that setting up for the origin is done for you
by clone [*1*] while you have to arrange for non-origin
repository yourself afterwards.
. The namespace under refs/heads is and always will be an issue.
It is a local matter and how remote branches are named should
not dictate what local branch names you can use in your
repository, but that essentially is what happens after
git-clone to users who do not rename those branches from the
initial cloning.
I once considered to give an option to clone to map the origin
heads to .git/refs/heads/origin/{master,maint,pu,...}. In
hindsight that might have been cleaner. Instead I just followed
what Cogito already established, and mapped remote "master" to
"origin".
. The namespace under refs/tags theoretically also has the same
issue, but I suspect it would not matter too much in practice.
The tags people fetches from remote tend to be release-point
tags (e.g. v2.6.14) whose names implicitly follow an obvious
(to humans) naming convention; when you name your temporary
anchor points using lightweight tags, you can easily avoid
name clashes with those "for other people" tags [*2*].
[Footnotes]
*1* Actually, even the setting up for the origin is done only
halfway -- it only arranges 'git fetch/pull' to fetch from the
master branch, and other branches are not tracked unless you
explicitly arrange them to be. This is somewhat deliberate; the
refs/ namespace management is a local matter and you do not
necessarily want to keep tracking all the branches from origin.
*2* This becomes somewhat problematic when the tool
automatically follows/fetches tags, and that is why git-core
barebone Porcelainish requires an explicit 'git fetch --tags'.
^ permalink raw reply
* Re: CFLAGS usage
From: Junio C Hamano @ 2005-11-04 17:45 UTC (permalink / raw)
To: Morten Welinder; +Cc: git
In-Reply-To: <118833cc0511040721w7f3990fbw631feaa6a4bda936@mail.gmail.com>
Morten Welinder <mwelinder@gmail.com> writes:
> Various stuff is being added to CFLAGS, but CFLAGS is not being used
> after being composed in CFLAGS_ALL.
True.
We should move ALL_CFLAGS definition at the very end; is
anything else needed?
^ permalink raw reply
* Re: CFLAGS usage
From: David Brown @ 2005-11-04 18:23 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Morten Welinder, git
In-Reply-To: <7voe50wblp.fsf@assigned-by-dhcp.cox.net>
On Fri, Nov 04, 2005 at 09:45:38AM -0800, Junio C Hamano wrote:
> Morten Welinder <mwelinder@gmail.com> writes:
>
> > Various stuff is being added to CFLAGS, but CFLAGS is not being used
> > after being composed in CFLAGS_ALL.
>
> True.
>
> We should move ALL_CFLAGS definition at the very end; is
> anything else needed?
Although it will work fine just as it is (it may be misleading, though).
Lazy evaluation in make is important, it allows such things as having
different CFLAGS that for different source files.
foo.o: CFLAGS += -fspecial-option
And the additional CFLAGS will only apply to the compilation of foo.
Since the ALL_CFLAGS is expanded lazily, it gets expanded for each target,
and the rule above causes CFLAGS to have extra values only on that target.
Dave
^ permalink raw reply
* Re: [PATCH] Cogito: Support for implicit remote branches in cloned repositories
From: Josef Weidendorfer @ 2005-11-04 18:38 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vvez8wbpz.fsf@assigned-by-dhcp.cox.net>
On Friday 04 November 2005 18:43, Junio C Hamano wrote:
> Josef Weidendorfer <Josef.Weidendorfer@gmx.de> writes:
>
> > ... One difference of cloning with GIT vs. with
> > Cogito is that Git always clones all remote branches. This can
> > be limiting if you want to work with multiple repositories,
> > but allows you to immediatly work with all the branches.
>
> Three points, and two footnotes.
>
> . After a git clone, you can still fetch from non-origin
> repository; you can also set up .git/remotes/somewhere-else if
> you pull from the non-origin repository regularly, so it is
> not really "limiting".
With "limiting" I only meant the fact that all the refs/heads names are
copied over, thus polluting your local namespace. Additionally, it can
be some transfer burden to copy all the objects instead only the objects
needed for one head.
Cogito does not have an issue with pollution of refs/heads namespace
as it only clones one head to the special "origin" head [*1*].
But as I said, the Git way can be more convenient. I think that the
proposed "implicit remote branches" are a way between: make it convenient
for Cogito users to fast access branches from the origin repository, but
pollute the name space only "a little".
[*1*] Still, it would be nice to specify the name of the branch tracking
the origin repository via on option in cg-clone (defaulting to "origin"),
and to also be able to specify the head which is branched off and you
are put on after cloning (defaulting to "master"); but I do not think
there is much use to such flexibility.
> It is just being slightly less
> convenient, in that setting up for the origin is done for you
> by clone [*1*] while you have to arrange for non-origin
> repository yourself afterwards.
I do not think there is much difference in editing files under
.git/remotes, or using cg-branch-add.
> . The namespace under refs/heads is and always will be an issue.
> It is a local matter and how remote branches are named should
> not dictate what local branch names you can use in your
> repository, but that essentially is what happens after
> git-clone to users who do not rename those branches from the
> initial cloning.
Yes, and that is nice about Cogito.
> I once considered to give an option to clone to map the origin
> heads to .git/refs/heads/origin/{master,maint,pu,...}. In
> hindsight that might have been cleaner. Instead I just followed
> what Cogito already established, and mapped remote "master" to
> "origin".
That is a nice idea. What is the exact compatiblity problem with Cogito
here? Either a repository is cloned with Git or with Cogito, and
afterwards, both should be able to cope with any naming scheme.
Both Git and Cogito do setup local "master" for local work after cloning.
To still be able to track a remote "master", this is mapped to local
"origin". Am I right here?
What happens if the remote side itself has an "origin" head?
> [Footnotes]
>
> *1* Actually, even the setting up for the origin is done only
> halfway -- it only arranges 'git fetch/pull' to fetch from the
> master branch, and other branches are not tracked unless you
> explicitly arrange them to be. This is somewhat deliberate; the
> refs/ namespace management is a local matter and you do not
> necessarily want to keep tracking all the branches from origin.
Yes. I do not see any problem here with explicitly specifying a
head you want to track in "git fetch origin <head>". Still, I would
not call this syntax 'porcelainish'.
But we have Cogito for this.
> *2* This becomes somewhat problematic when the tool
> automatically follows/fetches tags, and that is why git-core
> barebone Porcelainish requires an explicit 'git fetch --tags'.
Ah, ok.
Josef
^ permalink raw reply
* Re: CFLAGS usage
From: Junio C Hamano @ 2005-11-04 18:47 UTC (permalink / raw)
To: David Brown; +Cc: Morten Welinder, git
In-Reply-To: <20051104182342.GA27711@old.davidb.org>
David Brown <git@davidb.org> writes:
> And the additional CFLAGS will only apply to the compilation of foo.
> Since the ALL_CFLAGS is expanded lazily, it gets expanded for each target,
> and the rule above causes CFLAGS to have extra values only on that target.
Lazy expansion is true, but the reason we did ALL_CFLAGS was to
make CFLAGS overridable from the command line.
I suspect that this would currently fail to add -I/some/where/include
on the compilation command line:
make CFLAGS='-Os -g' CURLDIR=/some/where
while CURL_LIBCURL is set correctly on the linkage command line.
^ permalink raw reply
* Re: [PATCH] v2: proxy-command support for git://
From: Junio C Hamano @ 2005-11-04 18:57 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v1x1wz7ae.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> writes:
> Paul Collins <paul@briny.ondioline.org> writes:
>
>> Regarding internal vs. external hosts, the proxy command can simply
>> run netcat locally to internal hosts, so perhaps that is sufficient.
>
> I was hoping this to become a bit more generalized mechanism
> than that; for example using outgoing plug over HTTP Connect or
> telnet proxy using tn-gw-nav.
I realize the above does not really convey my real objection.
Your "ssh to the proxy/firewall host and run netcat to the
destination" would not work for me to reach the internal hosts
at all (while it would work for external ones), because my
firewall does not know names of our internal hosts (the same for
using tn-gw-nav to cross http or telnet proxy).
^ permalink raw reply
* Re: Three-way merge with the index as one way
From: Junio C Hamano @ 2005-11-04 19:05 UTC (permalink / raw)
To: Petr Baudis; +Cc: Zack Brown, git
In-Reply-To: <20051103003423.GH1431@pasky.or.cz>
Petr Baudis <pasky@suse.cz> writes:
> I wanted to make tree_timewarp do three-way merge, but didn't figure a
> good way to do it. First, what do I want - a two-way merge between two
> trees, which will however respect (not die on) local changes in the
> working tree.
I remember that we used to have --emu23 flag to read-tree. It
was yanked out when we did multi-merge-base conversion, because
nobody was using it, but I wonder if that is close to what you
are looking for.
$ git whatchanged -S--emu23 read-tree.c
tells me that 32192e6622d78347448cfc0572827d6e64e0de28 commit
completed it and ee6566e8d70da682ac4926dd8a67ac821b2c1743 commit
removed it.
^ permalink raw reply
* Re: Tags not transferred with git pull?
From: Junio C Hamano @ 2005-11-04 19:26 UTC (permalink / raw)
To: Erik Mouw; +Cc: git
In-Reply-To: <20051104160503.GC23790@harddisk-recovery.com>
Erik Mouw <erik@harddisk-recovery.com> writes:
> Ah, right. I got the impression that the latest git was supposed to do
> that automatically with a git pull.
Sorry for the confusion. The barebone Porcelainish shipped with
git-core does not fetch and store tags unconditionally under the
same name as the remote has without being told; you need to
explicitly tell it to 'git fetch --tags'.
What was added recently was a low level support for Cogito to
implement the automatic tracking. This is supposed to (I do not
offhand know if the Cogito side has been updated to do so
already) work a bit differently. Instead of grabbing all tags
and all objects reachable from them, as you fetch commits from
the remote, the automatic tracking fetches tags that point at
them. What this means is that the tags on the remote branch you
are tracking would be fetched automatically but tags on a remote
branch you are not interested in are not.
^ permalink raw reply
* Re: RFC: GIT networked storage
From: Jeff Garzik @ 2005-11-04 20:40 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vd5lg22gm.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
> Jeff Garzik <jgarzik@pobox.com> writes:
>
>
>>How easy is it to add a new storage backend to git?
>
>
> Almost everything is contained within sha1_file.c.
>
> Object creation side is simple -- everybody who creates an
> object (e.g update-index registering blobs, write-tree writing
> the toplevel and intermediate level trees, commit-tree building
> a commit object, unpack-objects exploding a pack) goes through
> write_sha1_file(), which checks if the object is already
> available using has_sha1_file() and creates a new object in the
> local .git/objects/?? directory. I am assuming that you are not
> planning to create objects in a remote peer from within the git
> code path, and instead to have background process that replicate
> them over the network to peer repositories, so you probably do
> not have to touch this side.
>
> Extending inspection and reading from existing objects for your
> networked storage may be somewhat messy, but starting points
> are:
[...]
Thanks. It looks pretty straightforward to add a new storage backend,
grepping on the symbols you listed.
Jeff
^ permalink raw reply
* [ANNOUNCE qgit-0.97]
From: Marco Costalba @ 2005-11-04 20:42 UTC (permalink / raw)
To: git
qgit, a git GUI viewer.
With qgit you will be able to browse revisions history, view patch content and changed
files, graphically following different development branches.
FEATURES
- View revisions, diffs, files history, files annotation, archive tree.
- Commit changes visually cherry picking modified files.
- Apply or format patch series from selected commits, drag and
drop commits between two instances of qgit.
- qgit implements a GUI for the most common StGIT commands like push/pop
and apply/format patches. You can also create new patches or refresh
current top one using the same semantics of git commit, i.e. cherry picking
single modified files.
NEW IN THIS RELEASE
This release is build around the wonderful new "--dense" option of git-rev-list,
i.e. git-rev-list can now filter revs according to a file list.
Because of this, makes now sense to show the archive tree and let the user to select
files and/or directory (treeview supports multi-selection) to filter on the main view
on the fly (by a new toolbar toggle button).
Also file history retrieving is now based on --dense option, so to let annotations be
more consistent with "legacy" file history. Because of this, annotation window gains a
graph column on file history, independent from main view, and updatable trough tree
browsing.
Under the hood improvements to event handling and external process launching complete
the picture.
DOWNLOAD
Download from sourceforge project page:
http://prdownloads.sourceforge.net/qgit/qgit-0.97.tar.bz2?download
There is also a git archive with the latest stuff
QGit repository (GIT): http://digilander.libero.it/mcostalba/qgit.git
You can use 'cg-clone http://digilander.libero.it/mcostalba/qgit.git'
to create and populate a local qgit directory.
Finally, there is a version built against Qt 3.3:
http://digilander.libero.it/mcostalba/qgit
INSTALLATION
You need scons and qt-mt developer libs, version 3.3.4 or better, already installed.
qgit is NOT compatible with Qt4.
On some platforms (Debian) you should set QTDIR before to compile.
- unpack tar file
- make
- make install
qgit will be installed in $HOME/bin
CHANGELOG
- added tree view on archive files/directories, double clicking on a file opens
file annotation window.
- took advantage of git-rev-list "--dense" option to retrieve file history.
- added a file history graph in annotation viewer.
- took advantage of --dense option to compress revision list to show only selected
files/directories in tree view. Tree view supports multi-selection.
- rewritten external processes launching to be more stable and fast.
- rewritten event handling to be much more clean and easy to follow. This also
fixes some subtle bugs.
Marco
__________________________________
Yahoo! Mail - PC Magazine Editors' Choice 2005
http://mail.yahoo.com
^ permalink raw reply
* Re: [PATCH] Cogito: Support for implicit remote branches in cloned repositories
From: Petr Baudis @ 2005-11-04 21:08 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Josef Weidendorfer, git
In-Reply-To: <7vvez8wbpz.fsf@assigned-by-dhcp.cox.net>
Dear diary, on Fri, Nov 04, 2005 at 06:43:04PM CET, I got a letter
where Junio C Hamano <junkio@cox.net> told me that...
> I once considered to give an option to clone to map the origin
> heads to .git/refs/heads/origin/{master,maint,pu,...}. In
> hindsight that might have been cleaner. Instead I just followed
> what Cogito already established, and mapped remote "master" to
> "origin".
Well, that obviously works only when you resign on the workflow where
pull means fetch + merge, since your local master would conflict with
the remote master, therefore having nowhere to store the remote master.
> . The namespace under refs/tags theoretically also has the same
> issue, but I suspect it would not matter too much in practice.
> The tags people fetches from remote tend to be release-point
> tags (e.g. v2.6.14) whose names implicitly follow an obvious
> (to humans) naming convention; when you name your temporary
> anchor points using lightweight tags, you can easily avoid
> name clashes with those "for other people" tags [*2*].
I still believe we need the notion of private tags which shouldn't be
cloned.
Hmm. Wait.
All right. git-update-server-info ignores hidden refs, but referencing a
hidden ref works all right (unsurprisingly). So let's just codify that
private tags which shan't be fetched (unless requested explicitly) start
with a dot (/^\./) and we are all set...?
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
VI has two modes: the one in which it beeps and the one in which
it doesn't.
^ permalink raw reply
* Re: [PATCH] v2: proxy-command support for git://
From: Paul Collins @ 2005-11-04 21:06 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v7jbow8ae.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> writes:
> Junio C Hamano <junkio@cox.net> writes:
>
>> Paul Collins <paul@briny.ondioline.org> writes:
>>
>>> Regarding internal vs. external hosts, the proxy command can simply
>>> run netcat locally to internal hosts, so perhaps that is sufficient.
>>
>> I was hoping this to become a bit more generalized mechanism
>> than that; for example using outgoing plug over HTTP Connect or
>> telnet proxy using tn-gw-nav.
"Run a program and talk to it via stdin/stdout" is as general as it
gets, isn't it? ssh+netcat is just what I happen to use.
> I realize the above does not really convey my real objection.
>
> Your "ssh to the proxy/firewall host and run netcat to the
> destination" would not work for me to reach the internal hosts
> at all (while it would work for external ones), because my
> firewall does not know names of our internal hosts (the same for
> using tn-gw-nav to cross http or telnet proxy).
It doesn't have to be unconditional. For example, one could have:
if on_blargco_network; then
# internal
case "$1" in
*.blargco.com)
exec nc "$1" "$2"
;;
*)
exec ssh bastion.blargco.com nc "$1" "$2"
;;
esac
else
# external
case "$1" in
*.blargco.com)
exec ssh bastion.blargco.com nc "$1" "$2"
;;
*)
exec ssh bastion nc "$1" "$2"
;;
esac
fi
But perhaps I do not really understand your objection.
--
Dag vijandelijk luchtschip de huismeester is dood
^ permalink raw reply
* Re: binary safe?
From: Martin Langhoff @ 2005-11-04 21:22 UTC (permalink / raw)
To: David Brown; +Cc: git
In-Reply-To: <20051104165419.GA12145@old.davidb.org>
On 11/5/05, David Brown <git@davidb.org> wrote:
> On Fri, Nov 04, 2005 at 12:00:54PM +1300, Martin Langhoff wrote:
>
> > Yes it works, and cvsimport -k will do the right thing for you.
>
> Unless it has changed from 0.99.9b, 'cvsimport -k' will very much scramble
> some binary files. '-k' passes the '-kk' option which causes CVS to strip
> the keywords down. It needs to pass -ko through if you want it to be able
> to handle binary files.
There is a misunderstanding here. We don't pass '-kk' to the cvs
utility -- we pass it at the protocol level. Strangely enough, when
passing ko we were getting broken files, and when passing kk we got
all the files correctly. I explored and tested this quite a bit when I
added the flag, and explicitly tested it with files that _would_ get
broken with cvs update -kk.
To recap: my main test repository has a lot of binary files, files
that do get broken if I do a cvs checkout with -kk. git-cvsimport gets
them right with its -k parameter. Don't ask me why, though: the cvs
protocol is really messy, and I suspect that part of the -kk option is
being 'implemented' on the client side.
(That being said, if you have a case where git-cvsimport is doing the
wrong thing, let me know!)
> However, since CVS (RCS really) can remember the state of this flag, it
> does work to 'cvs admin -ko filename' beforehand, and then do the
> cvsimport without the '-k' option.
Yes, but a repo you don't control, where people are using keywords,
means thatyou need to do -kk to kill the keywords or your imported
files are going to have a horrid amount of noise in them.
cheers,
martin
^ permalink raw reply
* Re: binary safe?
From: David Brown @ 2005-11-04 21:27 UTC (permalink / raw)
To: Martin Langhoff; +Cc: git
In-Reply-To: <46a038f90511041322x1d9f7a50ndafe724c2e8d368b@mail.gmail.com>
On Sat, Nov 05, 2005 at 10:22:29AM +1300, Martin Langhoff wrote:
> (That being said, if you have a case where git-cvsimport is doing the
> wrong thing, let me know!)
>
> > However, since CVS (RCS really) can remember the state of this flag, it
> > does work to 'cvs admin -ko filename' beforehand, and then do the
> > cvsimport without the '-k' option.
>
> Yes, but a repo you don't control, where people are using keywords,
> means thatyou need to do -kk to kill the keywords or your imported
> files are going to have a horrid amount of noise in them.
Yes, the unpleasantness of CVS.
However, I was unable to do a proper git-cvsimport of the SourceForge 'vim'
archive, with '-k'. By not giving it '-k' and using cvs admin '-ko' on the
appropriate files, I was able to get the correct results.
May be the interpretation of the option depends on the particular server
being used?
I can investigate later which particular file is causing the problem.
Dave
^ permalink raw reply
* Re: Fixing Commit And Author
From: Darrin Thompson @ 2005-11-04 21:35 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0511040924400.27915@g5.osdl.org>
On Fri, 2005-11-04 at 09:30 -0800, Linus Torvalds wrote:
> The rules currently do _not_ include changing the author/committer info,
> but it does know how to parse the really old-style dates, for example,
> which are on those same lines, so adding some code there to also re-write
> the author/committer name and email wouldn't be impossible.
>
> The code isn't necessarily all that easy to understand,
I can follow it mostly. If the commits were being read and built from
scratch with strbuf's I'd be willing to give it a try. :-)
I was able to hack together a really stupid python script that worked
fine (I think) for my less demanding case.
import sys
import os
name = "Darrin Thompson"
mail = "email@address"
os.environ['GIT_AUTHOR_NAME'] = name
os.environ['GIT_AUTHOR_EMAIL'] = mail
os.environ['GIT_COMMITTER_NAME'] = name
os.environ['GIT_COMMITTER_EMAIL'] = mail
commits = os.popen('git-rev-list HEAD | tac')
def parse_commit(commit):
tree = '///'
parents = []
lines = os.popen('git-cat-file commit %s' % commit)
for line in lines:
if not line.strip():
break
key, value = line.strip().split(None, 1)
if key == 'tree':
tree = value
elif key == 'parent':
parents.append(value)
elif key == 'author' or key == 'committer':
parts = value.split()
seconds, tz = parts[-2:]
date = ' '.join([seconds, tz])
message = ''.join(lines)
return tree, parents, message, date
tag_map = {}
tags = os.popen('git-rev-parse --symbolic --all | grep ^refs/tags/')
for line in tags:
filename = line.strip()
tag_name = filename.split('/')[-1]
tag_commit = os.popen('git-rev-parse %s' % tag_name).read().strip()
tag_list = tag_map.setdefault(tag_commit, [])
tag_list.append(tag_name)
commit_map = {}
for line in commits:
commit = line.strip()
tree, bio_parents, message, date = parse_commit(commit)
real_parents = [ commit_map[p] for p in bio_parents ]
parents_args = ' '.join([ '-p %s' % p for p in real_parents ])
os.environ['GIT_COMMITTER_DATE'] = date
os.environ['GIT_AUTHOR_DATE'] = date
write_handle, read_handle \
= os.popen2('git-commit-tree %s %s' % (tree, parents_args), 'w')
write_handle.write(message)
write_handle.close()
new_commit = read_handle.read().strip()
commit_map[commit] = new_commit
for tag_name in tag_map.get(commit, []):
os.system('git-tag -f %s %s' % (tag_name, new_commit))
read_handle.close()
print new_commit
--
Darrin
^ permalink raw reply
* Re: [PATCH] v2: proxy-command support for git://
From: Junio C Hamano @ 2005-11-04 21:42 UTC (permalink / raw)
To: Paul Collins; +Cc: git
In-Reply-To: <87ll049l8a.fsf@briny.internal.ondioline.org>
Paul Collins <paul@briny.ondioline.org> writes:
> But perhaps I do not really understand your objection.
No, I think you are getting it right.
I just wanted to avoid using the proxy script for some hosts,
depending on where you are going. Obviously you can teach the
proxy script to do passthru for some hosts like you did in your
message. The only difference is where the configuration is
specified. I wanted it to be in the git configuration file
(i.e. using different proxy script or no script, depending on
the host). Your example has that configuration wired in the
single script that is always called regardless of the
destination, and the script itself switches how it proxies,
depending on where it is going, perhaps using its own
configuration file or hardcoding.
^ permalink raw reply
* Re: [PATCH] Cogito: Support for implicit remote branches in cloned repositories
From: Junio C Hamano @ 2005-11-04 21:50 UTC (permalink / raw)
To: Petr Baudis; +Cc: Josef Weidendorfer, git
In-Reply-To: <20051104210820.GM1431@pasky.or.cz>
Petr Baudis <pasky@suse.cz> writes:
> I still believe we need the notion of private tags which shouldn't be
> cloned.
I agree with you violently. I just do not know what is the
right convention to tell which is private and which is not.
Fetching used to be a different matter, because we did not do
'git-fetch --tags' for a reason: you do not have any business
with my tags unless I tell you about them. But now we tell
others about what tags we have, so...
> All right. git-update-server-info ignores hidden refs, but referencing a
> hidden ref works all right (unsurprisingly). So let's just codify that
> private tags which shan't be fetched (unless requested explicitly) start
> with a dot (/^\./) and we are all set...?
Except that I suspect refs.c::check_ref_format() will barf on it
instead of ignoring it, and obviously you would want it to do
two different things depending on what kind of operation you are
doing. You for example would want to change git-branch or
git-tag not to refuse creating such "private" tag. You would
still want git-upload-pack to show it to the other end, for
better common commit computation purposes, especially if the tag
is of lightweight kind, but would want git-clone to ignore
them. It should be doable but we first need a plan.
^ permalink raw reply
* Re: [PATCH] v2: proxy-command support for git://
From: Paul Collins @ 2005-11-04 22:04 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v3bmct7i3.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> writes:
> Paul Collins <paul@briny.ondioline.org> writes:
>
>> But perhaps I do not really understand your objection.
>
> No, I think you are getting it right.
>
> I just wanted to avoid using the proxy script for some hosts,
> depending on where you are going. Obviously you can teach the
> proxy script to do passthru for some hosts like you did in your
> message. The only difference is where the configuration is
> specified. I wanted it to be in the git configuration file
> (i.e. using different proxy script or no script, depending on
> the host). Your example has that configuration wired in the
> single script that is always called regardless of the
> destination, and the script itself switches how it proxies,
> depending on where it is going, perhaps using its own
> configuration file or hardcoding.
I had some ideas along those lines, but I didn't like any of them.
* Extend the proxy-command "protocol" with a third argument, an
action. For example if 'query $host $port' returns successfully,
then git should run it with arguments 'connect $host $port',
otherwise use git_tcp_connect().
* Add a Proxy-Command field to the files in .git/remotes, e.g.:
URL: git://git.kernel.org/pub/scm/git/git.git/
Pull: master:origin
Proxy-command: my-git-proxy-command
* If the git config syntax is extended to allow dots in section or
key names:
[proxy]
git.kernel.org = "ssh-to-bastion-proxy-command"
git.blargco.com = "blargco-proxy-command"
or perhaps
[git.kernel.org]
proxycommand = "ssh-to-bastion-proxy-command"
[git.blargco.com]
proxycommand = "blargco-proxy-command"
--
Dag vijandelijk luchtschip de huismeester is dood
^ 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;
as well as URLs for NNTP newsgroup(s).