* Re: GIT Packages for Debian Etch
From: Thomas Glanzmann @ 2007-06-18 21:34 UTC (permalink / raw)
To: Pierre Habouzit; +Cc: GIT, LKML
In-Reply-To: <20070618212741.GA5938@artemis.internal.dc7.debconf.org>
Hello Pierre,
> FWIW there is even simpler: I maintain a backport on
> www.backports.org. Which is a semi-official service driven by Debian
> Developers.
good to know, maybe I am going to use backports in the future.
Thomas
^ permalink raw reply
* Re: [PATCH] Add a local implementation of hstrerror for the system which do not have it
From: Brandon Casey @ 2007-06-18 21:34 UTC (permalink / raw)
To: Alex Riesen; +Cc: git, Junio C Hamano, Randal L. Schwartz
In-Reply-To: <4676F8EA.1030305@nrlssc.navy.mil>
Brandon Casey wrote:
> Alex Riesen wrote:
>> The function converts the value of h_errno (last error of name
>> resolver library, see netdb.h). One of systems which supposedly do
>> not have the function is SunOS. POSIX does not mandate its presence.
>
> I saw a comment on another mailing list that hstrerror() is in the
> resolv library.
>
> So adding -lresolv should do it.
>
> A quick compile works for my test program.
Here's a SunOS5.9 man page for hstrerror:
http://bama.ua.edu/cgi-bin/man-cgi?hstrerror+3RESOLV
which shows:
cc [ flag ... ] file ... -lresolv -lsocket -lnsl [ library ... ]
-brandon
^ permalink raw reply
* [PATCH] make dist: include configure script in tarball
From: Matthias Lederhofer @ 2007-06-18 21:30 UTC (permalink / raw)
To: git
Signed-off-by: Matthias Lederhofer <matled@gmx.net>
---
Makefile | 5 +++--
1 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/Makefile b/Makefile
index 0f75955..9b7efcf 100644
--- a/Makefile
+++ b/Makefile
@@ -1009,15 +1009,16 @@ git.spec: git.spec.in
mv $@+ $@
GIT_TARNAME=git-$(GIT_VERSION)
-dist: git.spec git-archive
+dist: git.spec git-archive configure
./git-archive --format=tar \
--prefix=$(GIT_TARNAME)/ HEAD^{tree} > $(GIT_TARNAME).tar
@mkdir -p $(GIT_TARNAME)
- @cp git.spec $(GIT_TARNAME)
+ @cp git.spec configure $(GIT_TARNAME)
@echo $(GIT_VERSION) > $(GIT_TARNAME)/version
@$(MAKE) -C git-gui TARDIR=../$(GIT_TARNAME)/git-gui dist-version
$(TAR) rf $(GIT_TARNAME).tar \
$(GIT_TARNAME)/git.spec \
+ $(GIT_TARNAME)/configure \
$(GIT_TARNAME)/version \
$(GIT_TARNAME)/git-gui/version
@rm -rf $(GIT_TARNAME)
^ permalink raw reply related
* Re: [PATCH] Add a local implementation of hstrerror for the system which do not have it
From: Brandon Casey @ 2007-06-18 21:28 UTC (permalink / raw)
To: Alex Riesen; +Cc: git, Junio C Hamano, Randal L. Schwartz
In-Reply-To: <20070612213129.GD2459@steel.home>
Alex Riesen wrote:
> The function converts the value of h_errno (last error of name
> resolver library, see netdb.h). One of systems which supposedly do
> not have the function is SunOS. POSIX does not mandate its presence.
I saw a comment on another mailing list that hstrerror() is in the
resolv library.
So adding -lresolv should do it.
A quick compile works for my test program.
-brandon
^ permalink raw reply
* Re: GIT Packages for Debian Etch
From: Pierre Habouzit @ 2007-06-18 21:27 UTC (permalink / raw)
To: Thomas Glanzmann, carlo, Linus Torvalds, LKML, Michael Gernoth,
GIT
In-Reply-To: <20070618212524.GC16393@cip.informatik.uni-erlangen.de>
[-- Attachment #1: Type: text/plain, Size: 620 bytes --]
On Mon, Jun 18, 2007 at 11:25:24PM +0200, Thomas Glanzmann wrote:
> Hello,
> a friend of mine always builds the Debian Packages from unstable for
> Debian Etch. I have on all my machines the following line in
> /etc/apt/sources.list:
>
> deb http://rmdir.de/~michael/git/ ./
FWIW there is even simpler: I maintain a backport on
www.backports.org. Which is a semi-official service driven by Debian
Developers.
Cheers,
--
·O· Pierre Habouzit
··O madcoder@debian.org
OOO http://www.madism.org
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* GIT Packages for Debian Etch
From: Thomas Glanzmann @ 2007-06-18 21:25 UTC (permalink / raw)
To: carlo, Linus Torvalds, LKML; +Cc: Michael Gernoth, GIT
Hello,
a friend of mine always builds the Debian Packages from unstable for
Debian Etch. I have on all my machines the following line in
/etc/apt/sources.list:
deb http://rmdir.de/~michael/git/ ./
apt-get update; apt-get dist-upgrade
and you're up2speed.
If you don't trust that packages it is very easy to build them yourself:
wget http://ftp.debian.org/debian/pool/main/g/git-core/git-core_1.5.2.1-1.dsc
wget http://ftp.debian.org/debian/pool/main/g/git-core/git-core_1.5.2.1.orig.tar.gz
wget http://ftp.debian.org/debian/pool/main/g/git-core/git-core_1.5.2.1-1.diff.gz
dpkg-source -x git-core_1.5.2.1-1.dsc
cd git-core-1.5.2.1/
fakeroot debian/rules binary
It runs the whole test suite and only contiues producing debs if they're good
to go. It might be possible that you have to install some build dependencies by
yourself. If some new git version hits unstable you can get the references for
the three files above from:
http://packages.debian.org/git-core
=> unstable
=> scroll to end of page
=> Source Packages
=> Source Package: git-core, Download: [dsc] ...
Thomas
^ permalink raw reply
* Re: how to move with history?
From: Alex Riesen @ 2007-06-18 21:07 UTC (permalink / raw)
To: Oliver Kullmann; +Cc: git
In-Reply-To: <20070618202918.GM3037@cs-wsok.swansea.ac.uk>
Oliver Kullmann, Mon, Jun 18, 2007 22:29:18 +0200:
> > Git does not keep "renaming history". It does not have to, as it keeps
> > how your project looked at each commit (point in history).
>
> For my purposes, that is a bad thing, since I want to get rid off some parts
> of the history (specifically I want to eliminate some files from history),
> as explained in that last paragraph in my e-mail (with the motivation):
>
> Is this possible in git?
Yes. You wont be able to change the history after someone copied it
from you (cloned or fetched), because it's "his" now, but you're free
to do anything with your part (or whole) of the history. Happens all
the time. Look at git-cherry-pick, git-format-patch and git-am (and
the new git-filter-branch, but is more for automated mass-rewriting of
big histories).
> And is it possible to add the history of some file to the history
> of another file (in the above application this would be the renamed
> file) ?
Yes, git-format-patch accept pathnames, and its output can be passed
to git-am, which will apply the changes to this file only. git-am also
accepts -pN, so you can move file up a bit. For more complex path
manipulations you'll have to modify the patches (or git-filter-branch
again).
> Altogether, I want to completely change history: It must look as
> if the old files never has been there (from the git-history that is),
> but as it would have had always the new name.
Yep, no problem, just a bit of scripting. Just make sure no one has
that "old" history: it will be hell to merge with them.
> If this is not possible with Git (this "history surgery"),
no, it is not.
> then I hope that at least the future "git-submodule" will not have
> the files in the history which have been filtered out?
depends on how you write the history for that submodule
> So that in this way at least files can be hidden in (sub-)clones (but
> they cannot be renamed) ?
?
^ permalink raw reply
* Re: how to move with history?
From: Robin Rosenberg @ 2007-06-18 20:43 UTC (permalink / raw)
To: Oliver Kullmann; +Cc: Alex Riesen, git
In-Reply-To: <20070618202918.GM3037@cs-wsok.swansea.ac.uk>
måndag 18 juni 2007 skrev Oliver Kullmann:
> > Git does not keep "renaming history". It does not have to, as it keeps
> > how your project looked at each commit (point in history).
>
> For my purposes, that is a bad thing, since I want to get rid off some parts
> of the history (specifically I want to eliminate some files from history),
> as explained in that last paragraph in my e-mail (with the motivation):
>
> Is this possible in git?
>
> And is it possible to add the history of some file to the history
> of another file (in the above application this would be the renamed
> file) ?
Git does not keep file histories at all. As a consequence it does not track renames
either.
The history in Git is the history of the *whole* tree as a chunk, not a sum of file histories.
It takes snapshots of your project, that's all. Then there are tools to do magic on top of
that (e.g. git-blame).
There are tools to rewrite histories, but then you are violating of
the key principles of git, that history is immutable so git may not be nice to
you after history rewriting. Cogito has a powerful command.
-- robin
^ permalink raw reply
* Re: how to move with history?
From: Frank Lichtenheld @ 2007-06-18 20:36 UTC (permalink / raw)
To: J. Bruce Fields; +Cc: Oliver Kullmann, Alex Riesen, git
In-Reply-To: <20070618203116.GK2334@fieldses.org>
On Mon, Jun 18, 2007 at 04:31:16PM -0400, J. Bruce Fields wrote:
> On Mon, Jun 18, 2007 at 09:29:18PM +0100, Oliver Kullmann wrote:
> So if you want to erase all memory of a path from the git history, then
> you have to rebuild it all. Which is possible--it'd just mean creating
> a new project and writing a script to import every version into the new
> project....
Isn't that what git-filter-branch is for?
Gruesse,
--
Frank Lichtenheld <frank@lichtenheld.de>
www: http://www.djpig.de/
^ permalink raw reply
* Re: how to move with history?
From: J. Bruce Fields @ 2007-06-18 20:31 UTC (permalink / raw)
To: Oliver Kullmann; +Cc: Alex Riesen, git
In-Reply-To: <20070618202918.GM3037@cs-wsok.swansea.ac.uk>
On Mon, Jun 18, 2007 at 09:29:18PM +0100, Oliver Kullmann wrote:
> On Mon, Jun 18, 2007 at 09:49:07PM +0200, Alex Riesen wrote:
> > Git does not keep "renaming history". It does not have to, as it keeps
> > how your project looked at each commit (point in history).
>
> For my purposes, that is a bad thing, since I want to get rid off some parts
> of the history (specifically I want to eliminate some files from history),
> as explained in that last paragraph in my e-mail (with the motivation):
Oh, so even if somebody checks out a previous version of the project,
you don't want them to see that file at the old name any more?
The git history is totally immutable, by design--the SHA1 name of a
commit is taken over the commit, the contents of the entire tree at that
point, and any commit(s) that precede this commit--hence it recursively
summarizes the entire history of the project.
So if you want to erase all memory of a path from the git history, then
you have to rebuild it all. Which is possible--it'd just mean creating
a new project and writing a script to import every version into the new
project....
--b.
^ permalink raw reply
* Re: how to move with history?
From: Oliver Kullmann @ 2007-06-18 20:29 UTC (permalink / raw)
To: Alex Riesen; +Cc: git
In-Reply-To: <20070618194907.GA12445@steel.home>
On Mon, Jun 18, 2007 at 09:49:07PM +0200, Alex Riesen wrote:
> Oliver Kullmann, Mon, Jun 18, 2007 21:16:07 +0200:
> > 2. I issue "git mv file new_file".
> >
> > 3. Then I have to commit the renaming. I can't find anything on how
> > to do this (neither in the git-mv- nor in the git-commit-documentation).
>
> Just git-commit. git-mv is only so you don't have to run git add on
> the new file name and don't need to run "git-commit -a" afterwards.
>
> > So a hack is to use "git commit -a". Apparently this works.
>
> Even a plain "mv file new_file; git add new_file" would have worked.
>
> > 4. Now I have "new_file" in the repository, but without history
> > (except of the renaming operation),
>
> It does. Try "git log file new_file". After committing, that is
>
> > and I have still "file" in this history, but I can no longer get
> > access to the history of "file" via "gitk file" ?
>
> Well, you didn't commit the change yet.
>
> > This looks a bit strange to me (the renamed file has
> > no history, the old file still lurking around, but not
> > easily accessible).
>
I think, there is a bit of a misunderstanding going on, but this doesn't matter,
I believe now that I understand what "git mv" is doing (thanks!).
So that leaves then 2 open question:
> Git does not keep "renaming history". It does not have to, as it keeps
> how your project looked at each commit (point in history).
For my purposes, that is a bad thing, since I want to get rid off some parts
of the history (specifically I want to eliminate some files from history),
as explained in that last paragraph in my e-mail (with the motivation):
Is this possible in git?
And is it possible to add the history of some file to the history
of another file (in the above application this would be the renamed
file) ?
Altogether, I want to completely change history: It must look as
if the old files never has been there (from the git-history that is),
but as it would have had always the new name.
If this is not possible with Git (this "history surgery"), then
I hope that at least the future "git-submodule" will not have
the files in the history which have been filtered out?
So that in this way at least files can be hidden in (sub-)clones (but
they cannot be renamed) ?
> -
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: how to move with history?
From: Alex Riesen @ 2007-06-18 19:49 UTC (permalink / raw)
To: Oliver Kullmann; +Cc: git
In-Reply-To: <20070618191607.GK3037@cs-wsok.swansea.ac.uk>
Oliver Kullmann, Mon, Jun 18, 2007 21:16:07 +0200:
> 2. I issue "git mv file new_file".
>
> 3. Then I have to commit the renaming. I can't find anything on how
> to do this (neither in the git-mv- nor in the git-commit-documentation).
Just git-commit. git-mv is only so you don't have to run git add on
the new file name and don't need to run "git-commit -a" afterwords.
> So a hack is to use "git commit -a". Apparently this works.
Even a plain "mv file new_file; git add new_file" would have worked.
> 4. Now I have "new_file" in the repository, but without history
> (except of the renaming operation),
It does. Try "git log file new_file". After committing, that is
> and I have still "file" in this history, but I can no longer get
> access to the history of "file" via "gitk file" ?
Well, you didn't commit the change yet.
> This looks a bit strange to me (the renamed file has
> no history, the old file still lurking around, but not
> easily accessible).
Git does not keep "renaming history". It does not have to, as it keeps
how your project looked at each commit (point in history).
^ permalink raw reply
* Re: GIT_DIR question
From: Yakov Lerner @ 2007-06-18 19:43 UTC (permalink / raw)
To: Matthias Lederhofer; +Cc: git
In-Reply-To: <20070617215235.GA27753@moooo.ath.cx>
On 6/18/07, Matthias Lederhofer <matled@gmx.net> wrote:
> Yakov Lerner <iler.ml@gmail.com> wrote:
> > I wanted to create cloned repo, but with metaninfo separately from data.
> > I cloned the repo ( git-clone ~/repo ~/x) ,
> > then I moved ~/x/.git to different place (mv ~/x/.git ~/git);
> > then exported GIT_DIR=~/git; then
> > cd ~/x;
> > But now 'git status' says 'fatal: runstatus must be run in a work tree' .
> > Why ?
> >
> > 'ls $GIT_DIR' shows
> > FETCH_HEAD HEAD ORIG_HEAD branches config
> > description hooks index info logs objects refs
> > This is ok, no ?
>
> With current git you have to name the repository directory '.git' to
> use it with a working tree. Some commands work even though the
> repository is named differently, others don't.
>
> In pu is a patch series by me which changes this. First of all the
> core.bare option is used all the time, the directory name of the
> repository does not matter if core.bare is specified. Additionally
> you can specify the working tree through the config option
> core.worktree or the environment variable GIT_WORK_TREE. With this
> you can even work in a subdirectory of the working tree. But this is
> only in pu and it is not decided yet if this will make it into master,
> even though I hope it will. Perhaps more people asking for this helps :)
>
Does your patch allow to use absolute filenames and being cwd
outside of working dir ? I like to use absolute filenames (sometimes.
Most modern VSCes allow absolute pathnames).
Thanks
Yakov
^ permalink raw reply
* how to move with history?
From: Oliver Kullmann @ 2007-06-18 19:16 UTC (permalink / raw)
To: git
Hello,
I try to understand "git mv"; here is
how far I got:
1. Suppose I have "file" (under git control).
2. I issue "git mv file new_file".
3. Then I have to commit the renaming.
I can't find anything on how to do this
(neither in the git-mv- nor in the
git-commit-documentation).
So a hack is to use "git commit -a".
Apparently this works.
4. Now I have "new_file" in the repository, but
without history (except of the renaming operation),
and I have still "file" in this history, but
I can no longer get access to the history of
"file" via "gitk file" ?
This looks a bit strange to me (the renamed file has
no history, the old file still lurking around, but not
easily accessible).
But perhaps this is as it is (since other solutions might be
even stranger under certain circumstances)?
Is it then possible to complete the move, that is, to really
"move" the history of "file" to the history of "new_file", so
that after that except of some moving-information there is
no trace left of "file", while "new_file" has taken over the
old history?
(The motivation is as follows: I want to make the library I've
developed available as a clone, but I have the problem that
there are special files which I do not want to make available.
So I hope that in the future with "git-submodule" I can filter
out the special files, creating a (sub-)repository
without the special files which then can be freely cloned.
Now the special files yet are spread around, and to solve this
I want to introduce a special naming-pattern for the special
files (so that it becomes easy to separate the special files from
the rest). But in order to do so I need the ability to fully
move the special files to their renamed versions, completely
with history (otherwise by browsing the history of the clone
the special files would be revealed).)
I would be glad for any help!
Oliver
^ permalink raw reply
* Re: What's cooking in git.git (topics)
From: Matthias Lederhofer @ 2007-06-18 17:20 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vtztbbnsq.fsf@assigned-by-dhcp.pobox.com>
Junio C Hamano <gitster@pobox.com> wrote:
> * ei/worktree+filter (Wed Jun 6 09:16:56 2007 +0200)
> - filter-branch: always export GIT_DIR if it is set
> * ml/worktree (Fri Jun 8 22:57:55 2007 +0200) 9 commits
> - make git barf when an alias changes environment variables
> - setup_git_directory: fix segfault if repository is found in cwd
> - test GIT_WORK_TREE
> - extend rev-parse test for --is-inside-work-tree
> - Use new semantics of is_bare/inside_git_dir/inside_work_tree
> - introduce GIT_WORK_TREE to specify the work tree
> - test git rev-parse
> - rev-parse: introduce --is-bare-repository
> - rev-parse: document --is-inside-git-dir
>
> Undecided. Some people would want to have a way to have GIT_DIR
> point at somewhere unusual and still want to work from within a
> subdirectory, which is probably a valid thing to support. This
> is not something I would use myself, so I am mostly worried
> about the impact these changes may have on people who do not use
> this feature.
The only problem I know of up to now seems the one which happened with
git-filter-branch: if GIT_DIR is set and GIT_WORK_TREE/core.worktree is
set the specified working tree is used instead of cwd.
So for users not using GIT_WORK_TREE/core.worktree there should be no
problem. There might be problems if someone distributes scripts for
git which expect the old behaviour and the user specified the
worktree. OTOH the fix is to export GIT_WORK_TREE=. which does not
break the script for older versions of git versions and is quite
short (i.e. should not require any restructuring of the script).
^ permalink raw reply
* Re: Stupid quoting...
From: Jeff King @ 2007-06-18 16:19 UTC (permalink / raw)
To: David Kastrup; +Cc: git, Jakub Narebski
In-Reply-To: <86ir9l1ylc.fsf@lola.quinscape.zz>
On Mon, Jun 18, 2007 at 10:00:31AM +0200, David Kastrup wrote:
> > 7-bit email.
>
> I think it can be reasonably safely assumed that people using 8-bit
> characters in file names will not refrain from using them in the files
Not to mention the commit messages.
But more importantly, diffs aren't necessarily going through mail. When
I run 'git-show', this isn't useful to me:
diff --git "a/ni\303\261o" "b/ni\303\261o"
I can only imagine how git-show might look to somebody using all-utf8
filenames (such as Japanese).
-Peff
^ permalink raw reply
* Re: The --no-commit blues
From: Alex Riesen @ 2007-06-18 16:04 UTC (permalink / raw)
To: Brian L. Troutwine; +Cc: git
In-Reply-To: <200706180806.26255.goofyheadedpunk@gmail.com>
On 6/18/07, Brian L. Troutwine <goofyheadedpunk@gmail.com> wrote:
> I've got two branches, one which I commit to quite frequently and another only
> periodically, call them inward and outward. Inward is where I do my work,
> outward tracks an SVN repository. I'd like to merge inward to outward without
> committing the merge so that I may provide a commit message appropriate for
> checking in to the SVN repo.
>
> `git merge --no-commit inward' from branch outward, I thought, should do it.
> Performing a `git status' and a `git log' directly afterward seem to indicate
> that the merge was committed. `git commit' insists the branch is now up to
> date.
Either it was a fast-forward (IOW, the outward had no changes since you
changed inward, and inward is derived from outward), or we have a bug
(which I cannot reproduce).
> Am I going about this the wrong way? What does --no-commit mean, if I am?
exactly what it say: do not commit. Fast-forwards do not commit, just update
your HEAD, index and working directory with the new changed (from inward
in your case).
^ permalink raw reply
* The --no-commit blues
From: Brian L. Troutwine @ 2007-06-18 15:06 UTC (permalink / raw)
To: git
I've got two branches, one which I commit to quite frequently and another only
periodically, call them inward and outward. Inward is where I do my work,
outward tracks an SVN repository. I'd like to merge inward to outward without
committing the merge so that I may provide a commit message appropriate for
checking in to the SVN repo.
`git merge --no-commit inward' from branch outward, I thought, should do it.
Performing a `git status' and a `git log' directly afterward seem to indicate
that the merge was committed. `git commit' insists the branch is now up to
date.
Am I going about this the wrong way? What does --no-commit mean, if I am?
(Also, I asked this on #git earlier. If anyone happens to idle there, pardon
me for re-posting this so quickly. I've got terrible lag this morning, enough
to time out frequently.)
^ permalink raw reply
* git tool to keep a subversion mirror
From: Sergey Yanovich @ 2007-06-18 14:47 UTC (permalink / raw)
To: git, J.Sixt
Johannes Sixt wrote:
> It is extremely difficult to tell whether the patch makes sense or is
> correct, if there is _no_ explanation what it is good for.
I agree 100%. I sent a fore-letter using git-send-email, but all parts got split.
Pasting it manually:
> I am actively using git for my project. Thanks everyone envolved.
>
> However, I got tired of administering own web server and registered my
> project at sourceforge. Unlike repo.or.cz (thanks again for everyone
> envolved), they do not provide git hosting. But a project without a
> source repository is non-sence.
>
> I am not in any way going to use Subversion after I tried git, but I
> need to be able to export to a Subversion repository. I found an
> excellent tool called 'git-svn'. However, the flawed nature of
> Subversion put shackles on normal git usage after you do 'git-svn init'.
>
> Since git is the best scm system, my situation is probably quite common.
> So I am filing these patches.
>
> There is a 'git-svn' command which does want I need, so I created a
> simple wrapper around it. I also found that 'git-svn commit-diff' is
> having a small trouble dealing with root <tree-ish>, which is corrected
> by an attached patch.
^ permalink raw reply
* Re: [PATCH 3/3] Fix large-scale exports by 'git-svndump'
From: Johannes Sixt @ 2007-06-18 13:22 UTC (permalink / raw)
To: git
In-Reply-To: <11821688462083-git-send-email-ynvich@gmail.com>
Sergey Yanovich wrote:
>
> * Split revision list using 'tail' shell command.
>
> * Wrap multiple list generation in an endless cycle with 'while true'.
> Exit from cycle when the current list is empty.
>
> * Improve handling of merges by adding '--no-merges --topo-order'i
> arguments to the list generating command.
Please don't just repeat what can be seen in the patch anyway. Tell us
what this is good for, and which problems it solves.
-- Hannes
^ permalink raw reply
* Re: [PATCH 1/3] Accept root <tree-ish> in 'git-svn commit-diff'
From: Johannes Sixt @ 2007-06-18 13:20 UTC (permalink / raw)
To: git
In-Reply-To: <11821688461828-git-send-email-ynvich@gmail.com>
Sergey Yanovich wrote:
>
> Signed-off-by: Sergey Yanovich <ynvich@gmail.com>
> ---
It is extremely difficult to tell whether the patch makes sense or is
correct, if there is _no_ explanation what it is good for.
-- Hannes
^ permalink raw reply
* Re: [PATCH] mergetool: make Apple's FileMerge available as a merge_tool
From: Theodore Tso @ 2007-06-18 13:18 UTC (permalink / raw)
To: Scott Lamb; +Cc: Steffen Prohaska, Git Mailing List
In-Reply-To: <467652BC.4050900@slamb.org>
On Mon, Jun 18, 2007 at 02:39:08AM -0700, Scott Lamb wrote:
> I propose a simpler test:
>
> if [ -n "$TERM_PROGRAM" ]; then
> echo local
> else
> echo remote
> fi
>
> This environment variable seems to be set by Terminal.app and even two
> alternatives I just tried (iTerm.app and GLterm.app). It's not
> transmitted across ssh unless you stick an AcceptEnv in sshd_config.
Thanks, that's just what I was looking for!
- Ted
^ permalink raw reply
* Re: [PATCH 2/3] 'git-svndump'
From: Charlie Shepherd @ 2007-06-18 12:26 UTC (permalink / raw)
To: Sergey Yanovich; +Cc: git, normalperson, Matthieu.Moy
In-Reply-To: <11821688462290-git-send-email-ynvich@gmail.com>
On 18/06/07, Sergey Yanovich <ynvich@gmail.com> wrote:
> +git-svndump provides a solution when you need to export you source code
your source code
--
-Charlie
^ permalink raw reply
* moving self contained subdirectories from a project to another
From: Luca Barbato @ 2007-06-18 12:24 UTC (permalink / raw)
To: git
Lately I'm trying to move a subdirectory from one project to another,
both tracked in git.
This directory is currently duplicated in two different projects and my
plan was to remove it from those and make a library so it could be
shared between them.
Now, the simple way would be get a scratchpad branch, prune everything
but what I want, push to the library repo, make the projects use it.
There is already a script that automates this task? There are any
pitfalls I'm not considering?
lu
PS: keep me on CC since I'm not subscribed
--
Luca Barbato
Gentoo/linux Gentoo/PPC
http://dev.gentoo.org/~lu_zero
^ permalink raw reply
* [PATCH 2/3] 'git-svndump'
From: Sergey Yanovich @ 2007-06-18 12:14 UTC (permalink / raw)
To: git, normalperson, Matthieu.Moy; +Cc: Sergey Yanovich
In-Reply-To: <4e79874760c3773448d886608d6db7bbda3c97f2.1182168501.git.ynvich@gmail.com>
Signed-off-by: Sergey Yanovich <ynvich@gmail.com>
---
Documentation/git-svndump.txt | 106 +++++++++++++++++++++++++++++++++++++++++
git-svndump-init.sh | 85 +++++++++++++++++++++++++++++++++
git-svndump-sync.sh | 85 +++++++++++++++++++++++++++++++++
3 files changed, 276 insertions(+), 0 deletions(-)
create mode 100644 Documentation/git-svndump.txt
create mode 100755 git-svndump-init.sh
create mode 100755 git-svndump-sync.sh
diff --git a/Documentation/git-svndump.txt b/Documentation/git-svndump.txt
new file mode 100644
index 0000000..9caf02b
--- /dev/null
+++ b/Documentation/git-svndump.txt
@@ -0,0 +1,106 @@
+git-svndump(1)
+==========
+
+NAME
+----
+git-svndump - Exporting from git to a single Subversion branch
+
+SYNOPSIS
+--------
+'git-svndump' <command> [options] [arguments]
+
+DESCRIPTION
+-----------
+git-svndump is essentially a wrapper around 'git-svn commit-diff'. It
+will work only when it is the sole method of committing to the
+Subversion repository.
+
+It is designed to export a linear git branch. However, thanks to the way
+'git' handles source code, 'git-svndump' seems to work in other
+conditions. For example, when branches are switched or merged.
+
+git-svndump provides a solution when you need to export you source code
+in Subversion format (who would need this with git :), but do not want
+to have all the shackles that 'git-svn init' puts on your repository.
+
+COMMANDS
+--------
+--
+
+'init'::
+ Initialize an existing git repository with additional
+ metadata directories for git-svndump. The Subversion URL
+ must be specified as the first non-optional command-line
+ argument. 'git' tree-ish that correspond to the HEAD of
+ that Subversion URL may be specified as the second optional
+ command-line argument.
+
+-f;;
+ git-svndump normally declines to reinitialize the same git
+ repository. With the '-f' option that behavior is overridden.
+
+-A<filename>;;
+--authors-file=<filename>;;
+ The filename is stored, and provided as an argument to 'git-svn'
+ on calls of 'git-svndump sync'.
+
+'sync'::
+ Commit git revisions to the Subversion repository. If a git
+ <tree-ish> is specified as an optional command-line argument,
+ than all commits between the last 'sync' and that <tree-ish> are
+ send. If the argument is omitted, the HEAD of the active branch
+ is used.
+
+-A<filename>;;
+--authors-file=<filename>;;
+ The filename is provided as an argument to 'git-svn'.
+
+--
+
+BASIC EXAMPLE
+--------------
+
+Contributing to a Subversion repository:
+
+------------------------------------------------------------------------
+# Create your git repository, do some work and commit your changes
+# You are working on a computer A (git.foo.org)
+# Prepare your git repository for export (you are in the top dir)
+ git-svndump-init -A .auth http://svn.foo.org/project
+# Commit the whole branch:
+ git-svndump-sync
+# Now you go a different computer B
+# Clone a git repo:
+ git clone git.foo.org:/path/to/project.git
+# Enter the newly cloned directory:
+ cd project
+# Immediately prepare the new repository for export
+ git-svndump-init -A .auth http://svn.foo.org/project HEAD
+# Do some work and commit both locally and to A:
+ git commit ...
+ git push
+# Commit the new work:
+ git-svndump-sync
+# Now you return to the computer A
+# Reinit your repository for export!
+ git-svndump-init -f -A .auth http://svn.foo.org/project HEAD
+------------------------------------------------------------------------
+
+BUGS
+----
+
+The HEAD of the Subversion repository is not tracked. If your
+git-svndump repository goes out-of-sync with the Subversion mirror,
+the latter will most probably be corrupted.
+
+SEE ALSO
+--------
+gitlink:git-svn[1]
+
+Author
+------
+Written by Sergey Yanovich <ynvich@gmail.com>.
+
+Documentation
+-------------
+Written by Sergey Yanovich <ynvich@gmail.com>.
diff --git a/git-svndump-init.sh b/git-svndump-init.sh
new file mode 100755
index 0000000..4cf61b8
--- /dev/null
+++ b/git-svndump-init.sh
@@ -0,0 +1,85 @@
+#!/bin/sh
+
+usage()
+{
+ cat << EOF
+Usage: git-svndump-init [-f] subversion-url [<commit>]
+ subversion-url -- URL of the subversion repository to which you want
+ to dump the current git repository
+ <commit> -- git <commit> that correspond to the latest revision
+ in the subversion repository
+OPTIONS
+ -f
+ do not stop, if the git repository is already initialized.
+EOF
+ exit 1
+}
+
+if test x$GIT_DIR = x ; then
+ if test -d ./.git ; then
+ GIT_DIR=`pwd`/.git
+ fi
+fi
+
+if test ! -d $GIT_DIR ; then
+ usage
+fi
+
+if test x$1 = x ; then
+ usage
+fi
+
+if test x$1 = x-f; then
+ shift
+ rm -rf $GIT_DIR/svndump
+fi
+
+if test -d $GIT_DIR/svndump ; then
+ echo git-svndump-init: error: This git repository is already initialized
+ exit 1
+fi
+
+mkdir $GIT_DIR/svndump
+if test ! -d $GIT_DIR/svndump ; then
+ echo git-svndump-init: error: Failed to create $GIT_DIR/svndump
+ exit 1
+fi
+
+rev=`svn info $1 >$GIT_DIR/svndump/error.log`
+if test $? -ne 0 ; then
+ echo git-svndump-init: error: While quering $1
+ rm -rf $GIT_DIR/svndump
+ exit 1
+fi
+
+rev=`cat $GIT_DIR/svndump/error.log | sed -ne "/Revision/s/.* //p"`
+rm $GIT_DIR/svndump/error.log
+
+if test x$rev = x ; then
+ echo "git-svndump-init: error: Cannot determine the latest revision"
+ echo " at $1"
+ rm -rf $GIT_DIR/svndump
+ exit 1
+fi
+
+if test $rev -eq 0 ; then
+ mkdir -p $GIT_DIR/svndump/import && cd $GIT_DIR/svndump/import &&
+ svn import . $1 -m "Initial import by git-svndump"
+ if test $? -ne 0 ; then
+ echo "git-svndump-init: error: Failed to init $1"
+ rm -rf $GIT_DIR/svndump
+ exit 1
+ fi
+ rmdir $GIT_DIR/svndump/import
+fi
+
+echo "$1" > $GIT_DIR/svndump/url
+
+if test x$2 != x ; then
+ commit=`GIT_DIR=$GIT_DIR git-rev-list --max-count=1 $2`
+ if test $? -ne 0 ; then
+ echo "git-svndump-init: warning: Bad commit $2 ignored"
+ else
+ echo $commit >> $GIT_DIR/svndump/last
+ fi
+fi
diff --git a/git-svndump-sync.sh b/git-svndump-sync.sh
new file mode 100755
index 0000000..e1c04e1
--- /dev/null
+++ b/git-svndump-sync.sh
@@ -0,0 +1,85 @@
+#!/bin/sh
+
+usage()
+{
+ cat << EOF
+Usage: git-svndump-sync [<commit>]
+ <commit> -- git <commit> that correspond to the latest revision
+ to be dumped to the subversion repository
+EOF
+ exit 1
+}
+
+if test x$GIT_DIR = x ; then
+ if test -d ./.git ; then
+ GIT_DIR=`pwd`/.git
+ fi
+fi
+
+if test ! -d $GIT_DIR ; then
+ usage
+fi
+
+if test ! -d $GIT_DIR/svndump ; then
+ echo "git-svndump-sync: error: This git repository is not initialized"
+ echo " Run git-svndump-init first"
+ exit 1
+fi
+
+if test ! -f $GIT_DIR/svndump/url ; then
+ echo "git-svndump-sync: error: Cannot read url"
+ exit 1
+fi
+
+url=`cat $GIT_DIR/svndump/url`
+rev=`svn info $url >$GIT_DIR/svndump/error.log`
+if test $? -ne 0 ; then
+ echo git-svndump-sync: error: While quering $url
+ rm -rf $GIT_DIR/svndump/error.log
+ exit 1
+fi
+
+rev=`cat $GIT_DIR/svndump/error.log | sed -ne "/Revision/s/.* //p"`
+rm $GIT_DIR/svndump/error.log
+
+if test x$rev = x ; then
+ echo "git-svndump-init: error: Cannot determine the latest revision"
+ echo " at $url"
+ exit 1
+fi
+
+if test x$1 = x ; then
+ commit=HEAD
+else
+ commit=`GIT_DIR=$GIT_DIR git-rev-list --max-count=1 $1`
+ if test $? -ne 0 ; then
+ echo "git-svndump-sync: error: Bad commit '$1'"
+ exit 1
+ fi
+fi
+
+start=""
+last=0000000000000000000000000000000000000000
+if test -f $GIT_DIR/svndump/last ; then
+ last=`cat $GIT_DIR/svndump/last`
+ start=^`GIT_DIR=$GIT_DIR git-rev-list --max-count=1 $last`
+ if test $? -ne 0 ; then
+ echo "git-svndump-sync: warning: Ignoring bad commit '$last'"
+ start=""
+ last=0000000000000000000000000000000000000000
+ fi
+fi
+
+list=`GIT_DIR=$GIT_DIR git-rev-list $commit $start`
+
+diffs=""
+for c in $list ; do
+ diffs="$c $diffs"
+done
+
+for c in $diffs ; do
+ GIT_DIR=$GIT_DIR git-svn commit-diff -r$rev $last $c $url
+ echo "$c" > $GIT_DIR/svndump/last
+ last=$c
+ let rev++
+done
--
1.5.2.1
^ permalink raw reply related
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