* Re: [ANNOUNCE] git-svn - bidirection operations between svn and git
From: Eric Wong @ 2006-02-16 19:25 UTC (permalink / raw)
To: Eduardo Pereira Habkost; +Cc: git list
In-Reply-To: <20060216134248.GC4271@duckman.conectiva>
Eduardo Pereira Habkost <ehabkost@mandriva.com> wrote:
> On Wed, Feb 15, 2006 at 11:38:26PM -0800, Eric Wong wrote:
> > Hello, I've written a simple tool for interoperating between git and
> > svn. I wrote this so I could use git to work on projects where other
> > developers use Subversion. I really hate using svn, but some projects I
> > work on require it, and svk isn't nearly as fast nor simple as git.
>
> Great, I was doing some testing with git-svnimport for this, but I missed
> a tool to automatically commit to svn what I have in my GIT tree.
>
> >
> > git-svn does not replace git-svnimport, git-svnimport handles branches
> > and tags automatically, but is too inflexible about repository layouts
> > to be useful for a good number of projects I follow, and of course
> > git-svnimport can't commit to Subversion repositories :)
>
> I am already using git-svnimport to keep a "mirror" of some subversion
> repositories, here (automatically udpated on crontab). Do you plan to
> allow "integration" with repositories that are just clones of
> git-svnimport'ed repositories?
It's possible, just not very obvious at the moment. git-svn was written
as quickly as possible without regard to svnimport compatibility since I
had some repos that didn't work with svnimport to begin with.
The 'ADDITIONAL FETCH ARGUMENTS' part of the manpage is worth reading
for you. Basically, you can define equalities
"(svn revision number)=(git commit)" as arguments to git-svn fetch to
add parents for all the revisions it imports.
If I were you, I'd only want git-svn to care about partial history,
since you already have the rest of it from git-svnimport. You can do
this:
svn_revno=<last svn revision number you imported from git-svnimport>
git_commit=<equivalent commit sha1 name of svn_revno above>
git-svn fetch --revision $svn_revno:HEAD $svn_revno=$git_commit
> I plan to keep using git-svnimport and the standard git tools to work
> using the "svn mirror on git" as the main repository, but I plan to use
> "git-svn commit" to commit to the SVN repositories. I want this "commit
> tool" to not affect the current repository in any way, just like git-push:
> only send the commits to the remote repository and don't change anything
> in the local repository.
> However, it seems that "git-svn commit" does some tasks assuming we
> are on a "git-svn aware" repository (e.g. the "resyncing" just after
> the commit). Would you accept patches to allow using "git-svn commit"
> to commit changes from any GIT repository (i.e. not "svn-git aware"
> repositories) to any SVN repository, just like "git-push" would work
> for a GIT repository?
>
> However, I am not sure if the easier way would be changing git-svn to
> do this for me or writing a different script just for this task.
You should be 95% there just by exporting the svn_checkout_tree()
function to the command-line. Perhaps automating reading of the
$svn_rev variable can be in order.
--
Eric Wong
^ permalink raw reply
* Re: [PATCH] Fix for rpm creation
From: Petr Baudis @ 2006-02-16 16:09 UTC (permalink / raw)
To: Josef Weidendorfer; +Cc: git
In-Reply-To: <200602161659.39173.Josef.Weidendorfer@gmx.de>
Dear diary, on Thu, Feb 16, 2006 at 04:59:39PM CET, I got a letter
where Josef Weidendorfer <Josef.Weidendorfer@gmx.de> said that...
> So perhaps it would be good to hint the user to cg-seek in this
> error message?
That's a good idea. I added a hint there and a paragraph to cg-switch
documentation.
Thanks,
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
Of the 3 great composers Mozart tells us what it's like to be human,
Beethoven tells us what it's like to be Beethoven and Bach tells us
what it's like to be the universe. -- Douglas Adams
^ permalink raw reply
* Re: [PATCH] Fix for rpm creation
From: Josef Weidendorfer @ 2006-02-16 15:59 UTC (permalink / raw)
To: Petr Baudis; +Cc: git
In-Reply-To: <20060216154320.GT31278@pasky.or.cz>
On Thursday 16 February 2006 16:43, Petr Baudis wrote:
> > Another thing:
> > "cg-switch origin" currently refuses to switch to the branch.
> > Wouldn't it be better to handle this like "cg-seek origin"?
>
> Well, it depends on what you expect this to actually do. If you really
> want to just seek to whichever is the current origin commit, that's very
> different from what cg-switch does - you want cg-seek and cg-switch
> doing the same thing when it does something totally different from the
> user POV otherwise would be very confusing.
I just used it to check if you already fixed this issue yourself.
I known I should have used cg-seek, but I thought cg-switch should
allow me to do the same - I did not need to remember where I come
from.
So perhaps it would be good to hint the user to cg-seek in this
error message?
Josef
^ permalink raw reply
* Re: [PATCH] Fix for rpm creation
From: Petr Baudis @ 2006-02-16 15:43 UTC (permalink / raw)
To: Josef Weidendorfer; +Cc: git
In-Reply-To: <200602161633.44399.Josef.Weidendorfer@gmx.de>
Dear diary, on Thu, Feb 16, 2006 at 04:33:44PM CET, I got a letter
where Josef Weidendorfer <Josef.Weidendorfer@gmx.de> said that...
>
> Signed-off-by: Josef Weidendorfer <Josef.Weidendorfer@gmx.de>
>
> ---
> This fixes "make rpm", which currently gives at the very end:
> ...
> Checking for unpackaged file(s): /usr/lib/rpm/check-files /var/tmp/cogito-0.17rc2.GIT-1-root-weidendo
> error: Installed (but unpackaged) file(s) found:
> /usr/share/cogito/default-exclude
Thanks, applied.
> Another thing:
> "cg-switch origin" currently refuses to switch to the branch.
> Wouldn't it be better to handle this like "cg-seek origin"?
Well, it depends on what you expect this to actually do. If you really
want to just seek to whichever is the current origin commit, that's very
different from what cg-switch does - you want cg-seek and cg-switch
doing the same thing when it does something totally different from the
user POV otherwise would be very confusing.
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
Of the 3 great composers Mozart tells us what it's like to be human,
Beethoven tells us what it's like to be Beethoven and Bach tells us
what it's like to be the universe. -- Douglas Adams
^ permalink raw reply
* [PATCH] Fix for rpm creation
From: Josef Weidendorfer @ 2006-02-16 15:33 UTC (permalink / raw)
To: Petr Baudis; +Cc: git
In-Reply-To: <20060216135100.GR31278@pasky.or.cz>
Signed-off-by: Josef Weidendorfer <Josef.Weidendorfer@gmx.de>
---
This fixes "make rpm", which currently gives at the very end:
...
Checking for unpackaged file(s): /usr/lib/rpm/check-files /var/tmp/cogito-0.17rc2.GIT-1-root-weidendo
error: Installed (but unpackaged) file(s) found:
/usr/share/cogito/default-exclude
Another thing:
"cg-switch origin" currently refuses to switch to the branch.
Wouldn't it be better to handle this like "cg-seek origin"?
Josef
cogito.spec.in | 2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
e483d914813413b43fd1d067ebc50d4a86c93df1
diff --git a/cogito.spec.in b/cogito.spec.in
index 1fb3b7b..50c4172 100644
--- a/cogito.spec.in
+++ b/cogito.spec.in
@@ -38,6 +38,8 @@ rm -rf $RPM_BUILD_ROOT
%{_bindir}/*
%dir %{_libdir}/cogito
%{_libdir}/cogito/*
+%dir %{_datadir}/cogito
+%{_datadir}/cogito/*
%{_mandir}/man*/*
%doc README COPYING Documentation/tutorial-script
--
1.2.0.g719b
^ permalink raw reply related
* Re: git faq : draft and rfc
From: Petr Baudis @ 2006-02-16 15:18 UTC (permalink / raw)
To: Thomas Riboulet; +Cc: git
In-Reply-To: <22e91bb0602151636r2e70e60cpa5038f4b6caccc9c@mail.gmail.com>
Dear diary, on Thu, Feb 16, 2006 at 01:36:20AM CET, I got a letter
where Thomas Riboulet <riboulet@gmail.com> said that...
> . Git commit is dying telling me "fatal : empty ident <user@myhost>
> not allowed", what's wrong ?
> Make sure your Full Name is not empty in chsh or the 5th field of your
> user line in /etc/passwd isn't empty. If you @myhost is empty make sure
> your hostname is correctly set.
Please also mention GIT_AUTHOR_NAME; chsh may be frequently unavailable.
> . What's the difference between fetch and pull ?
> Fetch : download objects and a head from another repository.
> Pull : pull and merge from another repository.
> See man git-fetch and git-pull for more.
This could do with a little more elaboration as well. Nice inspiration
might be <Pine.LNX.4.64.0602140845080.3691@g5.osdl.org>.
> . Can I tell git to ignore files ?
> Yes. Put the files path in the repository in the .git/info/exclude file.
Or .gitignore in the tree itself. .git/info/exclude is only for your
particular checkout while .gitignore is what matters for all and
everyone's checkouts of the project.
> . What can I use to setup a public repository ?
> A ssh server, an http server, or the git-daemon.
> See the tutorial for more details.
Well this is about how to make it available, not how to use it.
The repository should be set up by cg-admin-setuprepo or git-init-db
--shared and normally does not have a working tree attached. You can
fetch from such a repository either over:
* the GIT protocol (you need to run git-daemon)
* SSH (you can set up a git-use-only account using git-shell)
* rsync (has important disadvantages but it is currently the
fastest way to do the initial checkout)
* or the HTTP protocol (any reasonable webhosting will do, but
you need to run git-update-server-info after each repository
update; if you used cg-admin-setuprepo to set it up, this
will be done automatically, otherwise you may enable it in
the post-update hook - see .git/hooks/post-update).
You can push to such a repository over:
* SSH
* HTTP DAV (you will need to specially configure your HTTP
server for this)
Obviously, you can also fetch/push from/to a repository locally if it
is available in the local filesystem structure.
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
Of the 3 great composers Mozart tells us what it's like to be human,
Beethoven tells us what it's like to be Beethoven and Bach tells us
what it's like to be the universe. -- Douglas Adams
^ permalink raw reply
* Re: git faq : draft and rfc
From: Johannes Schindelin @ 2006-02-16 15:00 UTC (permalink / raw)
To: Bertrand Jacquin; +Cc: Martin Langhoff, Thomas Riboulet, git
In-Reply-To: <4fb292fa0602160538s3f6d3c2av45dd907837b01f90@mail.gmail.com>
Hi,
On Thu, 16 Feb 2006, Bertrand Jacquin wrote:
> How old linus bk repos have been import to git ?
Using the CVS gateway, via git-cvsimport.
Hth,
Dscho
^ permalink raw reply
* Re: git faq : draft and rfc
From: Jon Loeliger @ 2006-02-16 14:32 UTC (permalink / raw)
To: git
> I'll try to add questions from the archives of this ml, I'm also open
> to any suggestions.
This is sort of the "missing" paragraph from the "git-checkout"
man page. It's there now, but in the "-m" option.
jdl
Q. Why won't git let me change to a different branch
using "git checkout <branch>" or "git checkout -b <branch>"?
Instead it just says:
fatal: Entry 'foo.c' not uptodate. Cannot merge.
A. You have changes to files in your working directory that
will be overwritten, removed or otherwise lost if the checkout
and change to the new branch were to proceed. To fix this
you may either check your changes in, create a patch of your
changes and revert your files, or use the "-m" flag like this:
git checkout -m -b my-branch
^ permalink raw reply
* [ANNOUNCE] Cogito-0.17rc2
From: Petr Baudis @ 2006-02-16 13:51 UTC (permalink / raw)
To: git
Hello,
here comes Cogito version 0.17rc1, the human-friendly version control
UI for Linus' GIT tool. Share and enjoy at:
http://www.kernel.org/pub/software/scm/cogito/
Few bugfixes and actually few minor features compared to 0.17rc1.
You're encouraged to upgrade if you are using 0.17rc2. I am receiving
less bugreports than what I have expected, which either means there are
no bugs (hah!) or that noone cares about the rcs (more likely). So if
there will be no bugreports in two or three days, I'll make this the
final 0.17.
The notable new stuff includes:
* cg-clean -d fix (do not clean the contents of untracked directories)
* cg-log -d renamed to cg-log -D, please fix your scripts and retrain
your fingers if you actually use it regularily
* cg-commit -M to load the commit message from a file
* cg-commit -f will commit even if you are seeked
* Fix repeated cg-seek <commit> invocations
* Fix pushing to symlinked repositories (it was racy before and would
not deal appropriately with permissions)
* Random documentation improvements
$ cg-log --summary -r cogito-0.17rc1..
Jonas Fonseca:
cg-commit: use -- to delimit paths args to git-diff-index for --review
cg-status: pretty-print heads using printf
Add warn function which can beep; use it to generalise warnings
Pavel Roskin:
[PATCH 1/2] cg-clean shouldn't clean untracked directories without -d
[PATCH 2/2] Workaround git < 1.2.0 ignoring .gitignore in parent directories
Petr Baudis:
0.17rc1.GIT
Doc clarification.
Do not list cg-object-id in helper commands
Fix shortdesc.
Rename cg-log -d to cg-log -D
Network together the cg-switch,cg-seek,cg-admin-uncommit docs
Refuse to uncommit merges, redirect the user to cg-switch
Simplify the editor testing code
Warn about seeking to a branch head
cg-commit -M to take the commit message from a file
cg-commit -f will override cg-seek's blocking
Hint cg-switch -n to save the volatile commit
Automatically determine cg-status headname column width
Fix cg-seek re-seeking
Remove the obsolete umask mention
Fix pushing to symlinked repositories
cogito-0.17rc2
P.S.: See us at #git @ FreeNode!
Happy hacking,
--
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: git faq : draft and rfc
From: Bertrand Jacquin @ 2006-02-16 13:38 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Martin Langhoff, Thomas Riboulet, git
In-Reply-To: <Pine.LNX.4.63.0602161421320.18016@wbgn013.biozentrum.uni-wuerzburg.de>
How old linus bk repos have been import to git ?
On 2/16/06, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> Hi,
>
> On Thu, 16 Feb 2006, Martin Langhoff wrote:
>
> > + Can I import from others? Maybe -- check if tailor.py can do it.
>
> + What is tailor.py? http://www.darcs.net/DarcsWiki/Tailor.
>
> Hth,
> Dscho
>
> -
> 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
>
--
Beber
#e.fr@freenode
^ permalink raw reply
* Re: [ANNOUNCE] git-svn - bidirection operations between svn and git
From: Eduardo Pereira Habkost @ 2006-02-16 13:42 UTC (permalink / raw)
To: Eric Wong; +Cc: git list
In-Reply-To: <20060216073826.GA12055@hand.yhbt.net>
[-- Attachment #1: Type: text/plain, Size: 2676 bytes --]
On Wed, Feb 15, 2006 at 11:38:26PM -0800, Eric Wong wrote:
> Hello, I've written a simple tool for interoperating between git and
> svn. I wrote this so I could use git to work on projects where other
> developers use Subversion. I really hate using svn, but some projects I
> work on require it, and svk isn't nearly as fast nor simple as git.
Great, I was doing some testing with git-svnimport for this, but I missed
a tool to automatically commit to svn what I have in my GIT tree.
>
> git-svn does not replace git-svnimport, git-svnimport handles branches
> and tags automatically, but is too inflexible about repository layouts
> to be useful for a good number of projects I follow, and of course
> git-svnimport can't commit to Subversion repositories :)
I am already using git-svnimport to keep a "mirror" of some subversion
repositories, here (automatically udpated on crontab). Do you plan to
allow "integration" with repositories that are just clones of
git-svnimport'ed repositories?
I plan to keep using git-svnimport and the standard git tools to work
using the "svn mirror on git" as the main repository, but I plan to use
"git-svn commit" to commit to the SVN repositories. I want this "commit
tool" to not affect the current repository in any way, just like git-push:
only send the commits to the remote repository and don't change anything
in the local repository.
However, it seems that "git-svn commit" does some tasks assuming we
are on a "git-svn aware" repository (e.g. the "resyncing" just after
the commit). Would you accept patches to allow using "git-svn commit"
to commit changes from any GIT repository (i.e. not "svn-git aware"
repositories) to any SVN repository, just like "git-push" would work
for a GIT repository?
However, I am not sure if the easier way would be changing git-svn to
do this for me or writing a different script just for this task.
>
> git-svn only cares about a single branch/trunk in SVN[1], but you can
> use as many branches in git as you want. This makes it much easier to
> use and allows it to handle just about any repository layout, not just
> those recommended in the SVN book/developers.
>
> Although importing changesets from SVN is mostly a linear affair,
> committing to SVN is the opposite. You may commit git tree objects in
> any order you want. It simply clobbers the existing svn tree as
> 'git-checkout -f' would, but tags file renames/copies carefully so users
> on the SVN side can see them. You can even do some wacky things with
> patch reordering.
Good, this is what I expect to be able to do when commiting to svn.
--
Eduardo
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: git faq : draft and rfc
From: Johannes Schindelin @ 2006-02-16 13:22 UTC (permalink / raw)
To: Martin Langhoff; +Cc: Thomas Riboulet, git
In-Reply-To: <46a038f90602152004i30c67a56i24dd9dfd41c0e873@mail.gmail.com>
Hi,
On Thu, 16 Feb 2006, Martin Langhoff wrote:
> + Can I import from others? Maybe -- check if tailor.py can do it.
+ What is tailor.py? http://www.darcs.net/DarcsWiki/Tailor.
Hth,
Dscho
^ permalink raw reply
* Re: [ANNOUNCE] Cogito-0.17rc1
From: Petr Baudis @ 2006-02-16 13:02 UTC (permalink / raw)
To: git
In-Reply-To: <20060216102059.17009.qmail@8b7ebad5023b2c.315fe32.mid.smarden.org>
Dear diary, on Thu, Feb 16, 2006 at 11:20:59AM CET, I got a letter
where Gerrit Pape <pape@smarden.org> said that...
> On Sun, Feb 12, 2006 at 06:11:54PM +0100, Petr Baudis wrote:
> > I'm announcing the release of Cogito version 0.17rc1, the human-friendly
> > version control UI for Linus' GIT tool. Share and enjoy at:
> >
> > http://www.kernel.org/pub/software/scm/cogito/
>
> Hi, the selftests for cg-seek fail for me on Debian/unstable:
Yes, I've noticed that afterwards as well - I can't tell how that
slipped through, I could swear that I ran the testsuite before the
release... :/
It's fixed in 0.17rc2. Thanks for the report,
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
Of the 3 great composers Mozart tells us what it's like to be human,
Beethoven tells us what it's like to be Beethoven and Bach tells us
what it's like to be the universe. -- Douglas Adams
^ permalink raw reply
* Re: [ANNOUNCE] git-svn - bidirection operations between svn and git
From: Aneesh Kumar @ 2006-02-16 12:01 UTC (permalink / raw)
To: Petr Baudis, scott; +Cc: Junio C Hamano, git
In-Reply-To: <20060216115707.GP31278@pasky.or.cz>
On 2/16/06, Petr Baudis <pasky@suse.cz> wrote:
> Dear diary, on Thu, Feb 16, 2006 at 12:20:01PM CET, I got a letter
> where Aneesh Kumar <aneesh.kumar@gmail.com> said that...
> > Scott James code was motivation to start the project. But if you
> > compare the two code lot of changes are done. Infact only thing that
> > remain now is how i draw using the cairo which is also modified a bit.
> >
> > This is the COPYING file that scott had in bzrk project.
> >
> > http://people.ubuntu.com/~scott/bzr/bzrk/COPYING
> >
> > But gitview is quiet different from bzrk. I just wanted to add it to
> > the code that i started with bzrk code.
>
> IANAL but AFAIK even if the code is quite different by now, if you
> _started_ with bzrk code the copyright of the original author is still
> lurking inside your code - it's basically a continuous series of
> directly derived works.
>
> OTOH, what am I not getting? The bzrk's license seems to be GPLv2, our
> license seems to be GPLv2, ...
>
>
Correct. That way i guess we can add the code the way i sent. In any
case i am marking this mail to scott. So if he has anything to add he
can let us know
-aneesh
^ permalink raw reply
* Re: [ANNOUNCE] git-svn - bidirection operations between svn and git
From: Petr Baudis @ 2006-02-16 11:57 UTC (permalink / raw)
To: Aneesh Kumar; +Cc: Junio C Hamano, git
In-Reply-To: <cc723f590602160320p7d551c58q96f6882c97e8422b@mail.gmail.com>
Dear diary, on Thu, Feb 16, 2006 at 12:20:01PM CET, I got a letter
where Aneesh Kumar <aneesh.kumar@gmail.com> said that...
> Scott James code was motivation to start the project. But if you
> compare the two code lot of changes are done. Infact only thing that
> remain now is how i draw using the cairo which is also modified a bit.
>
> This is the COPYING file that scott had in bzrk project.
>
> http://people.ubuntu.com/~scott/bzr/bzrk/COPYING
>
> But gitview is quiet different from bzrk. I just wanted to add it to
> the code that i started with bzrk code.
IANAL but AFAIK even if the code is quite different by now, if you
_started_ with bzrk code the copyright of the original author is still
lurking inside your code - it's basically a continuous series of
directly derived works.
OTOH, what am I not getting? The bzrk's license seems to be GPLv2, our
license seems to be GPLv2, ...
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
Of the 3 great composers Mozart tells us what it's like to be human,
Beethoven tells us what it's like to be Beethoven and Bach tells us
what it's like to be the universe. -- Douglas Adams
^ permalink raw reply
* Re: [ANNOUNCE] git-svn - bidirection operations between svn and git
From: Aneesh Kumar @ 2006-02-16 11:20 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vmzgrbqy0.fsf@assigned-by-dhcp.cox.net>
On 2/16/06, Junio C Hamano <junkio@cox.net> wrote:
> Aneesh Kumar <aneesh.kumar@gmail.com> writes:
>
> > It would be fine with me if you just drop the script to
> > contrib/gitview directory.
>
> OK. One final question. Actually, two. Is the original author
> Scott James Remnant OK with adding the script to a GPLv2
> project? Also do you want your HP affiliation appear in the
> author field or your gmail address?
>
>
>
Scott James code was motivation to start the project. But if you
compare the two code lot of changes are done. Infact only thing that
remain now is how i draw using the cairo which is also modified a bit.
This is the COPYING file that scott had in bzrk project.
http://people.ubuntu.com/~scott/bzr/bzrk/COPYING
But gitview is quiet different from bzrk. I just wanted to add it to
the code that i started with bzrk code.
Regarding HP affiliation i guess it should remain. In short you can
add the file as I send you
-aneesh
^ permalink raw reply
* Re: [ANNOUNCE] pg - A patch porcelain for GIT
From: Catalin Marinas @ 2006-02-16 11:10 UTC (permalink / raw)
To: Junio C Hamano
Cc: Fernando J. Pereda, Shawn Pearce, J. Bruce Fields, Sam Vilain,
Petr Baudis, Chuck Lever, Karl Hasselström, git
In-Reply-To: <7v64nfbmo6.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> wrote:
> "Fernando J. Pereda" <ferdy@ferdyx.org> writes:
>
>> That's because you told mutt you are subscribed to that list, so mutt
>> won't add you to Mail-Followup-To:, so you don't get duplicates. If you
>> don't tell mutt you are subscribed to the list, It will add your own
>> addres there.
>>
>> I think it is a nice feature, although it seems to annoy Junio :)
>
> Rightfully so.
>
> Last I heard that was a feature mutt people regret. Go back to
> the mail archive for details -- you robbed me 30 seconds so I
> won't do a research for you this time as I usually do ;-).
For Gnus users:
(setq message-use-mail-followup-to nil)
--
Catalin
^ permalink raw reply
* Re: [ANNOUNCE] pg - A patch porcelain for GIT
From: Junio C Hamano @ 2006-02-16 10:52 UTC (permalink / raw)
To: Fernando J. Pereda
Cc: Shawn Pearce, J. Bruce Fields, Sam Vilain, Petr Baudis,
Chuck Lever, Karl Hasselström, git
In-Reply-To: <20060216104224.GA29192@ferdyx.org>
"Fernando J. Pereda" <ferdy@ferdyx.org> writes:
> That's because you told mutt you are subscribed to that list, so mutt
> won't add you to Mail-Followup-To:, so you don't get duplicates. If you
> don't tell mutt you are subscribed to the list, It will add your own
> addres there.
>
> I think it is a nice feature, although it seems to annoy Junio :)
Rightfully so.
Last I heard that was a feature mutt people regret. Go back to
the mail archive for details -- you robbed me 30 seconds so I
won't do a research for you this time as I usually do ;-).
The "feature" is to allow you be lazy and not filter on your own
end and force everybody who wants to respond to you to fix up
the addressee header. In other words, it is not a "feature" for
people who receives your mail at all.
^ permalink raw reply
* Re: [ANNOUNCE] pg - A patch porcelain for GIT
From: Fernando J. Pereda @ 2006-02-16 10:42 UTC (permalink / raw)
To: Catalin Marinas
Cc: Junio C Hamano, Shawn Pearce, J. Bruce Fields, Sam Vilain,
Petr Baudis, Chuck Lever, Karl Hasselström, git
In-Reply-To: <b0943d9e0602160233i68fe5879y@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 945 bytes --]
On Thu, Feb 16, 2006 at 10:33:12AM +0000, Catalin Marinas wrote:
> On 16/02/06, Junio C Hamano <junkio@cox.net> wrote:
> > By the way, please do *not* do this:
> >
> > Mail-Followup-To: "J. Bruce Fields" <bfields@fieldses.org>,
> > Sam Vilain <sam@vilain.net>, Petr Baudis <pasky@suse.cz>,...
> > ...
>
> I think that's a "feature" of mutt that I couldn't understand. Every
> time I got this header and looked at the mail client, it was... mutt
> :-).
That's because you told mutt you are subscribed to that list, so mutt
won't add you to Mail-Followup-To:, so you don't get duplicates. If you
don't tell mutt you are subscribed to the list, It will add your own
addres there.
I think it is a nice feature, although it seems to annoy Junio :)
Cheers,
Ferdy
--
Fernando J. Pereda Garcimartín
Gentoo Developer (Alpha,net-mail,mutt,git)
20BB BDC3 761A 4781 E6ED ED0B 0A48 5B0C 60BD 28D4
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [ANNOUNCE] pg - A patch porcelain for GIT
From: Catalin Marinas @ 2006-02-16 10:33 UTC (permalink / raw)
To: Junio C Hamano
Cc: Shawn Pearce, J. Bruce Fields, Sam Vilain, Petr Baudis,
Chuck Lever, Karl Hasselström, git
In-Reply-To: <7vbqx7bnz7.fsf@assigned-by-dhcp.cox.net>
On 16/02/06, Junio C Hamano <junkio@cox.net> wrote:
> By the way, please do *not* do this:
>
> Mail-Followup-To: "J. Bruce Fields" <bfields@fieldses.org>,
> Sam Vilain <sam@vilain.net>, Petr Baudis <pasky@suse.cz>,...
> ...
I think that's a "feature" of mutt that I couldn't understand. Every
time I got this header and looked at the mail client, it was... mutt
:-).
--
Catalin
^ permalink raw reply
* Re: [ANNOUNCE] pg - A patch porcelain for GIT
From: Junio C Hamano @ 2006-02-16 10:24 UTC (permalink / raw)
To: Shawn Pearce
Cc: J. Bruce Fields, Sam Vilain, Petr Baudis, Chuck Lever,
Karl Hasselström, Catalin Marinas, git
In-Reply-To: <20060215065411.GB26632@spearce.org>
Shawn Pearce <spearce@spearce.org> writes:
> I think I'm almost there with pg. One of my next tasks is the
> patch log ripping code. This is really only complicated because GIT
> won't let me store the base of a 3 way merge as part of a commit;
> all I can store is the set of parents. If I had the base in the
> commit (and specifically marked as such so I can tell it from the
> end points) then I could easily walk through the log to extract all
> commits relevant to a patch and seek forward and backward over it.
I think I know what you are talking about. Maybe you might be
interested to take a look at TO script in my todo branch [*1*]?
Also there is a sample hook script templates/hooks--pre-rebase
that uses the same idea used in the said script. These are what
I use to manage the "next" branch (an aggregation of topic
branches being cooked).
By the way, please do *not* do this:
Mail-Followup-To: "J. Bruce Fields" <bfields@fieldses.org>,
Sam Vilain <sam@vilain.net>, Petr Baudis <pasky@suse.cz>,...
...
I wanted to reply to *you*, but by having the header you robbed
about 30 seconds from me, forcing me to edit the "To:"
addressee.
[Footnote]
*1* todo branch does not have *any* ancestry relationship with
my primary branches, so please do not try to merge it in your
primary repository (unless you know what you are doing). Make a
clone into a separate directory and running "git checkout todo"
there is the cleanest way to peek into it.
^ permalink raw reply
* Re: [ANNOUNCE] Cogito-0.17rc1
From: Gerrit Pape @ 2006-02-16 10:20 UTC (permalink / raw)
To: git
In-Reply-To: <20060212171154.GW31278@pasky.or.cz>
On Sun, Feb 12, 2006 at 06:11:54PM +0100, Petr Baudis wrote:
> I'm announcing the release of Cogito version 0.17rc1, the human-friendly
> version control UI for Linus' GIT tool. Share and enjoy at:
>
> http://www.kernel.org/pub/software/scm/cogito/
Hi, the selftests for cg-seek fail for me on Debian/unstable:
$ wget -q -O- http://www.kernel.org/pub/software/scm/cogito/cogito-0.17rc1.tar.gz |tar xzpf -
$ cd cogito-0.17rc1
$ make
Generating cg-version...
$ make test
[...]
*** t9300-seek.sh ***
* ok 1: initialize repo
Adding file different
* ok 2: record second commit
* ok 3: seeking to the first commit
* ok 4: we should have .git/head-name == master
* ok 5: current branch should be cg-seek-point
* ok 6: current commit should be commit1
* ok 7: newfile should be gone
* ok 8: different should be v1
* ok 9: identical should be identical
* FAIL 10: seeking to the second commit
cg-seek ab3fddb2498b5378c1eb91f341c0f9cfbc15944f
* ok 11: we should not unseeked properly
* FAIL 12: current commit should be commit2
[ 422409bf18cdcf9214cd9fcc34a2cace15ce5aff =
ab3fddb2498b5378c1eb91f341c0f9cfbc15944f ]
* ok 13: seeking to the last (well, still second) commit
* ok 14: we should be unseeked properly
* ok 15: current commit should be commit2
* ok 16: newdir/newfile should be back
* ok 17: different should be v2
* ok 18: identical should be identical
* ok 19: local change to identical (non-conflicting)
* ok 20: local change to newdir/newfile (conflicting)
* ok 21: seeking to the first commit
* ok 22: current commit should be commit1
* ok 23: different should be v1
* ok 24: identical should be nonconflicting
* ok 25: unseeking
* ok 26: we should be unseeked properly
* ok 27: current commit should be commit2
* failed 2 among 27 test(s)
This seems to be a workaround:
--- t/.t9300-seek.sh 2006-02-16 10:13:31.000000000 +0000
+++ t/t9300-seek.sh 2006-02-16 10:14:00.000000000 +0000
@@ -45,7 +45,7 @@
"[ $(cat identical) = identical ]"
test_expect_success 'seeking to the second commit' \
- "cg-seek $commit2"
+ "cg-seek && cg-seek $commit2"
test_expect_success 'we should not unseeked properly' \
"([ -e .git/head-name ] &&
[ $(basename $(git-symbolic-ref HEAD)) = cg-seek-point ])"
Regards, Gerrit.
^ permalink raw reply
* Re: [ANNOUNCE] git-svn - bidirection operations between svn and git
From: Junio C Hamano @ 2006-02-16 9:20 UTC (permalink / raw)
To: Aneesh Kumar; +Cc: git
In-Reply-To: <cc723f590602160030n498b18edla328f7c64d44c04a@mail.gmail.com>
Aneesh Kumar <aneesh.kumar@gmail.com> writes:
> It would be fine with me if you just drop the script to
> contrib/gitview directory.
OK. One final question. Actually, two. Is the original author
Scott James Remnant OK with adding the script to a GPLv2
project? Also do you want your HP affiliation appear in the
author field or your gmail address?
^ permalink raw reply
* Re: [PATCH] pack-objects: reuse data from existing pack.
From: Junio C Hamano @ 2006-02-16 9:13 UTC (permalink / raw)
To: Andreas Ericsson; +Cc: git
In-Reply-To: <43F438AA.1040508@op5.se>
Andreas Ericsson <ae@op5.se> writes:
> Whoa! Columbus and the egg. Strange noone saw it before. It's so
> obvious when you shove it under the nose like that. :)
I wished the pack format were not so dense as we have today. It
is very expensive to obtain the uncompressed size of a deltified
object. For this reason, a delta newly created (either from a
non-delta in an existing pack or from a loose object) by the
experimental algorithm is never made against an object that is
in deltified form in a pack. Also it incurs nontrivial cost to
obtain the size of the in-pack representation of an object
(either deltified or not). But the inefficiency in the
resulting pack due to these factors may not matter in practice.
I just packed v2.6.16-rc3 object list (184141 objects) using the
current and the experimental, just for fun. Tonight's one runs
just under 1 minutes on my Duron 750 (with slow disks I should
add). This was done in a repository that has about 1500 loose
objects and a single mega pack; reuse rate of packed data by the
experimental algorithm is about 99%. I am hoping the one from
the "master" would come back before I finish writing this
message ;-).
There are subtleties.
For example, in a typical project, files tend to grow rather
than shrink on average, and older ones tend to be in packs. If
you do packing the traditional way, the largest one (which is
typically the latest) is kept as non-delta, and all the smaller
ones will be incremental delta from that, no matter how your
packs and loose objects are organized.
Usually, you have the latest objects as loose objects in your
repository to be packed (either you push from it, or somebody
else pulls from you). In other words, as you develop after your
last repack, you would accumulate loose objects, and they are
the ones that typically matter the most.
Let's say you have been changing the same file in every commit
(1..N), then you fully packed and then created another commit
(revision N+1) that touches the file. The experimental
reuse-packer would:
- notice blobs from revision 1..(N-1) are deltified,
relative to the rev one greater than each of them.
these would be reused.
- notice blob from revision N is in the pack but not
deltified.
- notice blob from revision N+1 is loose.
Then emit the bigger one between N or N+1 as non-delta, the
other one as delta. 1..(N-1) are output as delta. If it
happens to choose N as plain, it does not have to uncompress and
recompress so the pack process would go very fast, but you would
end up always having to apply a delta to bring rev N to N+1 on
top of the non-delta N to get to the latest blob in rev N+1, and
you typically would want to access rev N+1 blob more often.
In other words, the experimental reuse-packer would create a
suboptimal pack in such a case. Not a big deal, though.
We may want an option to disable the optimization for
weekly/monthly repacking. git-daemon (or whatever runs
pack-objects via upload-pack) should use the default with the
optimization, since this is so obviously faster.
> Now that pack-creation went from bizarrely expensive to insanely cheap
> (well, comparable to "tar czf" anyways), what's BCP for packing a
> public repository? Always one mega-pack and never worry, or should one
> still use incremental and sometimes overlapping pack-files?
I would say an optimum single mega-pack would work the best, but
"repack -a -d" to create the mega-pack _with_ the optimization
may have performance impact for users of resulting packs.
Oh, the traditional one finally came back after 11 minutes.
^ permalink raw reply
* Re: [ANNOUNCE] git-svn - bidirection operations between svn and git
From: Eric Wong @ 2006-02-16 8:48 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v4q2zg2an.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> wrote:
> Eric Wong <normalperson@yhbt.net> writes:
>
> > @ Junio: Is there room for this in the git distribution alongside
> > git-svnimport?
>
> Surely. Things that superficially do similar things are not
> necessarily mutually exclusive, if that is what you are worried
> about. There is not much incumbent advantage for tools that
> support a narrowly defined specific task (e.g. interfacing with
> foreign SCM X) on the periphery, while I would perhaps feel more
> hesitant to support 47 different variants of git-commit ;-).
<snip>
> Even having some experimental tools that are only starting to do
> useful things might be useful, if we had it in the git.git
> repository. For one thing, it would give more exposure to them
> and help improve things.
Good to know. I fully agree on this point.
> How about first adding a contrib/ directory and see how it goes?
Sure thing. Don't worry about development history, there's hardly any
as it was all done pretty quickly. Being able to draw from my
experiences with svn-arch-mirror, arch-svn-merge (this one sucked), and
git-archimport helped greatly; as did the very simple and flexible
nature of git.
--
Eric Wong
^ 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