* Re: [VOTE] git versus mercurial (for DragonflyBSD)
From: Isaac Jurado @ 2008-11-06 17:41 UTC (permalink / raw)
To: Marcin Kasperski; +Cc: mercurial, git
In-Reply-To: <878wrwom88.fsf@softax.com.pl>
On Thu, Nov 6, 2008 at 5:25 PM, Marcin Kasperski
<Marcin.Kasperski@softax.com.pl> wrote:
>
> Are really programming languages that important?
Considering the success of some of them, having the worst possible
syntax and semantics, I believe it does not matter much.
> Main showstoppers in this area are not the programming languages, but
> lack of documentation, miserable APIs, or lack of process. Or ... the
> fact that the tool is so good that it does not really need extensions.
I couldn't agree more. Sorry for such a useless reply, but I felt some
emotion reading "common sense".
Cheers.
--
Isaac Jurado Peinado
http://www.krenel.net
"The noblest pleasure is the joy of understanding"
Leonardo da Vinci
^ permalink raw reply
* [PATCH] Added test case for mirror to not push stash refs
From: david @ 2008-11-06 17:39 UTC (permalink / raw)
To: git; +Cc: David Bryson
In-Reply-To: <20081028212327.GA25358@sigill.intra.peff.net>
From: David Bryson <david@statichacks.org>
This test case checks to make sure mirror does not push stashed refs
---
t/t5517-push-mirror.sh | 10 ++++++++++
1 files changed, 10 insertions(+), 0 deletions(-)
diff --git a/t/t5517-push-mirror.sh b/t/t5517-push-mirror.sh
index ea49ded..bb263cd 100755
--- a/t/t5517-push-mirror.sh
+++ b/t/t5517-push-mirror.sh
@@ -123,6 +123,16 @@ test_expect_success 'push mirror adds, updates and removes branches together' '
'
+test_expect_success 'push mirror does not push stash refs' '
+
+ mk_repo_pair &&
+ (
+ cd master &&
+ echo foo >foo && git add foo && git commit -m 'foo' &&
+ echo bar >foo && git stash save 'WIP' &&
+ git push --mirror up
+ )
+'
# TAG tests
test_expect_success 'push mirror creates new tags' '
--
1.6.0.1
^ permalink raw reply related
* Re: [PATCH (MINGW) Resend] Windows: Make OpenSSH properly detect tty detachment.
From: Johannes Sixt @ 2008-11-06 17:21 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Alexander Gavrilov, git
In-Reply-To: <7vvdv0iyl2.fsf@gitster.siamese.dyndns.org>
Junio C Hamano schrieb:
> Do people build and test MinGW port out of my 'next'? If so, I'll queue
> this on its own topic branch and have it go through the usual "cook then
> graduate" cycle. Otherwise, I'll apply this directly on top of 'master'.
My own build is on top of your 'master', and I've cooked this patch to
death there already, so I don't think it needs another cycle. ;)
-- Hannes
^ permalink raw reply
* Re: Issue updating files during a checkout from a remote push
From: Steve Walker @ 2008-11-06 17:17 UTC (permalink / raw)
To: git
In-Reply-To: <334B3AB1-125A-4163-BEBC-9A73C4F569B5@idibu.com>
Sorry to keep answering my own questions directly after posting...
I just tried with a 'git commit -f' and the files updated.
Can anyone tell me if this is good practice? I would have thought a
normal commit would update from index to head - isnt always forcing it
creating potentially bad merges?
Kind regards, Steve.
On Nov 6, 2008, at 6:04 PM, Steve Walker wrote:
> Hi there,
>
> Hoping someone could point me in the right direction here.
>
> The overall issue is that with files that have been pushed into our
> repo on our server, when we then check out into local working copy
> the new files appear, but the updated files dont update even though
> the output suggests it has. The flow I'm doing:
>
> 1. The file I'm testing an update to is this:
>
> -rw-r--r-- 1 root www-data 0 2008-11-06 16:13 steve-git-
> test3.txt
>
> 2. On my local box I change file, add it, commit, then push it from
> my local box to our server repo:
>
> StevePoota:public_html steve$ vi steve-git-test3.txt
> StevePoota:public_html steve$ git add steve-git-test3.txt
> StevePoota:public_html steve$ git commit
> Created commit e29b724: testing only
> 1 files changed, 1 insertions(+), 0 deletions(-)
> StevePoota:public_html steve$ git push ssh://idibu.com/home/beta_idibu/public_html
> master:master
> Counting objects: 5, done.
> Compressing objects: 100% (2/2), done.
> Writing objects: 100% (3/3), 272 bytes, done.
> Total 3 (delta 1), reused 0 (delta 0)
> To ssh://idibu.com/home/beta_idibu/public_html
> a28332a..e29b724 master -> master
>
> 3. It all looks good, on my server if i do a 'git log' I can see in
> the latest update:
>
> oneworld:/home/beta_idibu/public_html# git log
> commit e29b7246beab458d6a7b53cb245a5596adc8c198
> Author: Steve <steve@StevePoota.local>
> Date: Thu Nov 6 17:55:21 2008 +0100
>
> testing only
>
> 4. So I check out:
>
> oneworld:/home/beta_idibu/public_html# git checkout master
> M .gitignore
> M steve-git-test.txt
> M steve-git-test2.txt
> M steve-git-test3.txt
> Already on branch "master"
> oneworld:/home/beta_idibu/public_html#
>
> and its telling me that file has been modified
>
> but checking my file it hasnt changed by date stamp, and looking
> insie the file my changes arent there :((
>
> -rw-r--r-- 1 root www-data 0 2008-11-06 16:13 steve-git-
> test3.txt
>
> I'm stumped. I tried 777'ing that file temporarily in case git
> couldnt write to that file on checkout. What is strange is that when
> I add new files to the system it works - for example this file I'm
> testing no was originally added to the server via an external push.
>
> If anyone could give me some help I'd be very grateful.
>
> Kind regards, Steve.
>
> --
> 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
www.idibu.co.uk
steve@idibu.com
Sales: +44 (0)800 311 2750
Support: +44 (0)870 626 4268
Fax: +44 (0)8701 417 136
Mobile: +34 661 785 387
www.linkedin.com/in/stevejwalker
^ permalink raw reply
* Issue updating files during a checkout from a remote push
From: Steve Walker @ 2008-11-06 17:04 UTC (permalink / raw)
To: git
Hi there,
Hoping someone could point me in the right direction here.
The overall issue is that with files that have been pushed into our
repo on our server, when we then check out into local working copy the
new files appear, but the updated files dont update even though the
output suggests it has. The flow I'm doing:
1. The file I'm testing an update to is this:
-rw-r--r-- 1 root www-data 0 2008-11-06 16:13 steve-git-
test3.txt
2. On my local box I change file, add it, commit, then push it from my
local box to our server repo:
StevePoota:public_html steve$ vi steve-git-test3.txt
StevePoota:public_html steve$ git add steve-git-test3.txt
StevePoota:public_html steve$ git commit
Created commit e29b724: testing only
1 files changed, 1 insertions(+), 0 deletions(-)
StevePoota:public_html steve$ git push ssh://idibu.com/home/beta_idibu/public_html
master:master
Counting objects: 5, done.
Compressing objects: 100% (2/2), done.
Writing objects: 100% (3/3), 272 bytes, done.
Total 3 (delta 1), reused 0 (delta 0)
To ssh://idibu.com/home/beta_idibu/public_html
a28332a..e29b724 master -> master
3. It all looks good, on my server if i do a 'git log' I can see in
the latest update:
oneworld:/home/beta_idibu/public_html# git log
commit e29b7246beab458d6a7b53cb245a5596adc8c198
Author: Steve <steve@StevePoota.local>
Date: Thu Nov 6 17:55:21 2008 +0100
testing only
4. So I check out:
oneworld:/home/beta_idibu/public_html# git checkout master
M .gitignore
M steve-git-test.txt
M steve-git-test2.txt
M steve-git-test3.txt
Already on branch "master"
oneworld:/home/beta_idibu/public_html#
and its telling me that file has been modified
but checking my file it hasnt changed by date stamp, and looking insie
the file my changes arent there :((
-rw-r--r-- 1 root www-data 0 2008-11-06 16:13 steve-git-
test3.txt
I'm stumped. I tried 777'ing that file temporarily in case git couldnt
write to that file on checkout. What is strange is that when I add new
files to the system it works - for example this file I'm testing no
was originally added to the server via an external push.
If anyone could give me some help I'd be very grateful.
Kind regards, Steve.
^ permalink raw reply
* Re: [PATCH/RFC v3] git add -i: Answer questions with a single keypress
From: Junio C Hamano @ 2008-11-06 17:06 UTC (permalink / raw)
To: Suraj N. Kurapati; +Cc: Jeff King, git
In-Reply-To: <200811060815.16797.sunaku@gmail.com>
"Suraj N. Kurapati" <sunaku@gmail.com> writes:
> On Thursday 06 November 2008 00:42:36 Jeff King wrote:
>> On Wed, Nov 05, 2008 at 09:59:25AM -0800, Suraj N. Kurapati wrote:
>> > Allows the user to answer 'Stage this hunk' questions with a
>> > single keypress, just like in Darcs. Previously, the user was
>> > forced to press the Return key after every choice they made.
>> > This quickly becomes tiring, burdensome work for the fingers.
>>
>> I think this is a reasonable goal, but I have a few questions/concerns.
>>
>> - There are three versions of your patch, but nobody has commented.
>> Clearly we can see what changed, but it is not clear what advantage
>> one patch has over the other. Care to elaborate?
>
> v1 and v2 make the mistake of setting raw mode, which prevent the user from
> pressing Control-C to exit the program. v3 fixes this by using cbreak mode.
When I was reading the last round I noticed the above change myself, but
it is customary to write this kind of "patch changelog" under --- line in
your patch around here. That way you can save everybody's time.
Thanks. And thanks, Jeff, for being a good reviewer.
^ permalink raw reply
* Re: [PATCH] Added test case for mirror to not push stash refs
From: Junio C Hamano @ 2008-11-06 16:58 UTC (permalink / raw)
To: sverre; +Cc: david, git
In-Reply-To: <bd6139dc0811060034q14e47232n5f00471e5420efbb@mail.gmail.com>
"Sverre Rabbelier" <alturin@gmail.com> writes:
>> + git push --mirror up
>> + )
>> +'
>
> I don't quite get how this works, I don't see a test here anywhere to
> actually test that the stash refs were not pushed?
I agree that this test should check the receiving end.
The patch is relying on the fact that the receiving end would reject the
push if the sending end tries to push refs/$foo where $foo does not have
any slash.
^ permalink raw reply
* Re: [PATCH (MINGW) Resend] Windows: Make OpenSSH properly detect tty detachment.
From: Junio C Hamano @ 2008-11-06 16:55 UTC (permalink / raw)
To: Johannes Sixt; +Cc: Alexander Gavrilov, git
In-Reply-To: <49129E47.4080209@viscovery.net>
Johannes Sixt <j.sixt@viscovery.net> writes:
> The latest "What's cooking in git.git" report still doesn't mention this
> patch. The reason might be ...
Sorry, my mistake.
>> Signed-off-by: Alexander Gavrilov <angavrilov@gmail.com>
>> Acked-by: Johannes Sixt <johannes.sixt@telecom.at>
>> ---
>>
>> This patch appears to have been overlooked,
Indeed. It was lost in the noise because it was marked MinGW and I failed
to see your Ack.
Do people build and test MinGW port out of my 'next'? If so, I'll queue
this on its own topic branch and have it go through the usual "cook then
graduate" cycle. Otherwise, I'll apply this directly on top of 'master'.
Thanks.
^ permalink raw reply
* Re: [VOTE] git versus mercurial (for DragonflyBSD)
From: Marcin Kasperski @ 2008-11-06 16:25 UTC (permalink / raw)
To: mercurial; +Cc: git
In-Reply-To: <20081028193841.GA23637@neumann>
>> > How many perl gurus have skipped writing
>> > stuff for hg because it's a "python-or-bust" thing?
>>
>> How many Python people decided to write an extension for hg, because it can
>> very nicely be accessed via Python?
>
> And wouldn't they contribute at all, if there would be hg bindings for
> other programming languages, would they?
Are really programming languages that important? If I find a tool
which is useful and has features I need, and while using it I find
some drawback, and I am able to find how could I work on it, I can
pick up enough of the language it is written in. I am not a "guru"
if I can't.
Main showstoppers in this area are not the programming languages, but
lack of documentation, miserable APIs, or lack of process. Or ... the
fact that the tool is so good that it does not really need extensions.
--
----------------------------------------------------------------------
| Marcin Kasperski | If we are to be successful, we must still have
| http://mekk.waw.pl | the courage to put our faith in people as
| | opposed to a process. (Booch,Martin,Newkirk)
----------------------------------------------------------------------
^ permalink raw reply
* Re: [PATCH/RFC v3] git add -i: Answer questions with a single keypress
From: Suraj N. Kurapati @ 2008-11-06 16:15 UTC (permalink / raw)
To: Jeff King; +Cc: git
In-Reply-To: <20081106084230.GA4407@sigill.intra.peff.net>
On Thursday 06 November 2008 00:42:36 Jeff King wrote:
> On Wed, Nov 05, 2008 at 09:59:25AM -0800, Suraj N. Kurapati wrote:
> > Allows the user to answer 'Stage this hunk' questions with a
> > single keypress, just like in Darcs. Previously, the user was
> > forced to press the Return key after every choice they made.
> > This quickly becomes tiring, burdensome work for the fingers.
>
> I think this is a reasonable goal, but I have a few questions/concerns.
>
> - There are three versions of your patch, but nobody has commented.
> Clearly we can see what changed, but it is not clear what advantage
> one patch has over the other. Care to elaborate?
v1 and v2 make the mistake of setting raw mode, which prevent the user from
pressing Control-C to exit the program. v3 fixes this by using cbreak mode.
> - Term::ReadKey, while common, is not part of base perl. So I think
> using it needs to be conditional, and on systems without it we can
> degrade to the current behavior.
The git-svn.perl script also uses Term::ReadKey. Since it is already in the
git source repository, I thought it was okay to use Term::ReadKey.
> - There's no facility in your patch for restoring the terminal if we
> break out of the loop in an unexpected way (e.g., via the user
> hitting ^C).
Good point. I'll try to address this in a v4 patch.
> - This only enhances one particular input, the patch loop. It is
> probably worth being consistent and allowing these behavior for other
> menus (though the numeric inputs are a bit trickier).
Understood.
^ permalink raw reply
* Re: Bug: "git-svn fetch" segfaults on unknown user
From: Jens Seidel @ 2008-11-06 15:48 UTC (permalink / raw)
To: git
In-Reply-To: <237967ef0811060643g1037b8dbuf3660dfa8e3ff625@mail.gmail.com>
On Thu, Nov 06, 2008 at 03:43:18PM +0100, Mikael Magnusson wrote:
> 2008/11/6 Jens Seidel <jensseidel@users.sf.net>:
> > I noticed the following bug in git-svn version 1.6.0.3 (svn 1.5.5):
> >
> > "git-svn fetch" segfaults if I provide an incomplete svn.authorsfile config
> > file setting with account<-->email mappings. This happens if an unknown user
> > account is found in the Subversion log.
I should really provide more information:
I imported my Subversion repository in the past succesfully from my server
(svn+ssh protocol). Since I'm new to git (and still confused by the large
amount of git tools) I decided to start on a svnsync'ed copy of my repository
(file protocol) to avoid any harm. I added also some new config settings
including svn.authorsfile and fetching revisions started to fail. The last
output was:
r38 = 4dca32e3d82a32206fd11545d4f270e118f51f12 (trunk@166)
M myproject/file
Revision 39 contained the unknown user account so I suspected the error
is related to an incomplete authors file.
I used following versions of Subversion:
Client: 1.5.5
Server: 1.5.3
After adding the missing account to the authors file it fetched all revisions,
called the garbage collector and stilled crashed with a core dump. Last
output:
Checked out HEAD:
file:///home/jens/Subversion-Repository.synced/myproject/trunk r1700
Abgebrochen (core dumped)
This happened also after I removed the svn.authorsfile config setting.
My current settings:
[user]
name = Jens Seidel
email = jensseidel@users.sf.net
[color]
diff = auto
branch = auto
interactive = auto
[svn]
findcopiesharder = true
rmdir = true
"gdb -c core" is useless, it just mentions the error occured in
"perl git-svn fetch" and there is no stacktrace (don't know how to
debug perl).
I removed now both [svn] options and it failed again. So it seems a problem
with file:// access while svn+ssh:// works well.
> Are you sure this isn't the regular svn 1.5.x crash? Ie, does
> compiling subversion with --disable-runtime-module-search fix it?
Huch? I follow the Subversion developer list and I'm not not aware of
such a problem. Will try it now ...
PS: Compared to previous releases of git the import is at least 10 times
faster. Good job!
Jens
^ permalink raw reply
* Re: Setting Up a GIT Repository Mirror
From: Santi Béjar @ 2008-11-06 15:33 UTC (permalink / raw)
To: Yaser Raja; +Cc: git
In-Reply-To: <e97d51700811060708y5deb9e9ek4a36c012726b3a63@mail.gmail.com>
On Thu, Nov 6, 2008 at 4:08 PM, Yaser Raja <yrraja@gmail.com> wrote:
> Hi
[...]
> I came to know about --mirror option of git-clone and used it to make
> a bare repository replica of the MainRep. Now i am not sure how to
> keep it in sync with the MainRep.
$ git fetch
as it is bare you cannot merge, so you cannot pull.
HTH,
Santi
^ permalink raw reply
* Re: More help needed on merging unrelated repos
From: Karl Hasselström @ 2008-11-06 15:28 UTC (permalink / raw)
To: Christian MICHON; +Cc: Andreas Ericsson, Git Mailing List
In-Reply-To: <46d6db660811060413q7f4e2437maa6d87a27b8704b@mail.gmail.com>
On 2008-11-06 13:13:42 +0100, Christian MICHON wrote:
> nice suggestion Karl! it took a while to understand all the
> consequences and workflow. On top of your suggestion, I had to
> remove the refs/original/refs/heads/master and the grafts file.
I've never tried to use git-filter-branch, so I was deliberately
vague. I was hoping you would be the enterprising type who would
figure out the details anyway ... ;-)
> It worked well: quite a spell, but an efficient one. Kudo++
Well, that's Git for you. Once you get the (really simple) underlying
data model you know what _can_ be done, even if it's not always
obvious _how_ to do it.
--
Karl Hasselström, kha@treskal.com
www.treskal.com/kalle
^ permalink raw reply
* Setting Up a GIT Repository Mirror
From: Yaser Raja @ 2008-11-06 15:08 UTC (permalink / raw)
To: git
In-Reply-To: <e97d51700811060706t40433bb9k7a3704429f244164@mail.gmail.com>
Hi
I have a main repository placed at a remote location and i want to
have a read-only mirror of this repository available locally. The
users/automated processes will use this local mirror to get the latest
code.
Can anyone guide me how to implement this? I did make a basic setup as
follows but it has some issues:
1. Create a clone (MirrorRep) of the remote git repository (MainRep)
on a local machine using "git-clone" command
git-clone ssh://<user>@<remote machine addr> MyMirror
2. Use "git-pull" to keep this repository (MirrorRep) in sync with the
main repository. I added entry in /etc/crontab to invoke "git-pull"
after every 10 minutes to update this repository.
3. Launch "git-daemon" so that local users can access and clone from
this Mirror Repository.
git-daemon --export-all --verbose --base-path=<base path to
MyMirror directory>
After this the users can easily clone from the local repository and
work with it. The problem is that the branches that were present in
MainRep are not visible in the clones made using MirrorRep. When
MirrorRep was created all the branches of MainRep became remote
branches for MirrorRep. And when users make a clone from MirrorRep
none of the remote branches are transfered over.
I came to know about --mirror option of git-clone and used it to make
a bare repository replica of the MainRep. Now i am not sure how to
keep it in sync with the MainRep.
Thanks
Yaser
^ permalink raw reply
* Re: Bug: "git-svn fetch" segfaults on unknown user
From: Mikael Magnusson @ 2008-11-06 14:43 UTC (permalink / raw)
To: Jens Seidel; +Cc: git
In-Reply-To: <20081106143826.GA26900@merkur.sol.de>
2008/11/6 Jens Seidel <jensseidel@users.sf.net>:
> Hi,
>
> I noticed the following bug in git-svn version 1.6.0.3 (svn 1.5.5):
>
> "git-svn fetch" segfaults if I provide an incomplete svn.authorsfile config
> file setting with account<-->email mappings. This happens if an unknown user
> account is found in the Subversion log.
>
> If I do not provide svn.authorsfile at all, it doesn't crash.
Are you sure this isn't the regular svn 1.5.x crash? Ie, does
compiling subversion with --disable-runtime-module-search fix it?
--
Mikael Magnusson
^ permalink raw reply
* Bug: "git-svn fetch" segfaults on unknown user
From: Jens Seidel @ 2008-11-06 14:38 UTC (permalink / raw)
To: git
Hi,
I noticed the following bug in git-svn version 1.6.0.3 (svn 1.5.5):
"git-svn fetch" segfaults if I provide an incomplete svn.authorsfile config
file setting with account<-->email mappings. This happens if an unknown user
account is found in the Subversion log.
If I do not provide svn.authorsfile at all, it doesn't crash.
Jens
^ permalink raw reply
* Re: What's cooking in git.git (Nov 2008, #02; Wed, 05)
From: Miklos Vajna @ 2008-11-06 14:29 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v1vxplku2.fsf@gitster.siamese.dyndns.org>
[-- Attachment #1: Type: text/plain, Size: 344 bytes --]
On Wed, Nov 05, 2008 at 05:11:33PM -0800, Junio C Hamano <gitster@pobox.com> wrote:
> * mv/remote-rename (Mon Nov 3 19:26:18 2008 +0100) 1 commit
> . Implement git remote rename
I plan to send a second patch on top of this to support migration from
.git/branches and .git/remotes, but probably I can do so only next week
due to lack of time.
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: Fetch via http and proxy which requires authentication
From: Dilip M @ 2008-11-06 13:29 UTC (permalink / raw)
To: Paolo Ciarrocchi; +Cc: Git Mailing List
In-Reply-To: <4d8e3fd30811040313x44290557yecfedb2fbc8cad0b@mail.gmail.com>
On Tue, Nov 4, 2008 at 4:43 PM, <paolo.ciarrocchi@gmail.com> wrote:
> Works for me: $ git version git version 1.6.0.2.1172.ga5ed0
>
> I set in the Environment Variables panel:
>
> Variable Value http_proxy http://ip_of_my_proxy
Okay it solved now. Problem was old version of GIT. libcurl library
problem.
Upgrade the OS ,which in turn upgraded the libs...
Working fine for me too..
--
Dilip
^ permalink raw reply
* Re: cvs2git
From: Michael Haggerty @ 2008-11-06 12:42 UTC (permalink / raw)
To: Francis Galiegue; +Cc: cvs2svn developers, Git Mailing List
In-Reply-To: <200811052319.04879.fg@one2team.net>
Francis Galiegue wrote:
> I don't like to reinvent the wheel and you have gone a lot further than I did
> wrt cvs2git, with the added advantage that you work on a physical CVS tree
> and you know a LOT more about CVS than I do. And I do, indeed, have physical
> access to "my" CVS tree.
Even for the few people who don't have physical access to their CVS
tree, there is a solution [1]. I don't think this is a significant
issue, and indeed we've had very few complaints about this over the years.
> I wish that cvs2svn[2git] gets things as right as possible, and am willing to
> help in any way possible.
The first step is to send in bug reports (including sample repositories)
for anything you think can be improved. It is very easy to produce a
test case from even a proprietary repository [2].
> Have you ever had a look at git-cvsimport already? Not my code, it relies on
> cvsps, which is flawed, that's a given fact. But it builds a state-of-the-art
> git repository.
How do you define "state-of-the-art"? Granted, the resulting git
repository is simpler than the one created by cvs2git, but that is
because *it is typically wrong*. The tool produces simple output
because it assumes away so much of the true complexity that can be
recorded in a CVS history.
I am not interested in a known-to-be-incorrect conversion, no matter how
pretty it looks in gitk.
git-cvsimport is *broken*, and the only way to fix it is to give it (and
its output) all of the complexity of cvs2svn/cvs2git. I know that for a
fact because cvs2svn used to be based on simpler algorithms (though even
then not as naive as those used by cvsps!) and we were constantly trying
to patch up this or that edge case in a futile struggle against a system
that was fundamentally broken. The switch to the current
topological-based changeset creation fixed all such bugs at once.
If you try to build a robust and correct tool on cvsps, you are doomed
to failure because (1) cvsps can crash complex CVS repositories and (2)
cvsps doesn't even *try* to supply all information correctly, e.g.
regarding the true contents of tags and branches [3].
> By now, I have achieved the first part of my project (correctly parsing the
> cvsps cache file), next step I'll "lighten" the git-cvsimport source (bug for
> bug compatibility to start with).
Please believe me, because I have years of suffering behind me:
1. cvsps is broken and not useful for this purpose
2. "parsing the cvsps cache file" is an absolutely minuscule part of
writing a CVS -> anything converter. You think you're making good
progress, but you have no idea of what you are getting into. Read [4]
and really think about whether you want to reimplement a comparable set
of features from scratch. And remember that many of these features are
not optional bells and whistles; they are *needed for correctness*.
> One thing is that this program uses bare git commands, not the fast-import
> way.
This will absolutely kill performance for a large repository. There is
a discussion of this issue in our mailing list archives and probably
also on the git mailing list.
> Hence my first question: if I lighten git-cvsimport code, will that help
> you for cvs2git?
If I polish up my roller skates, will that help you fix your car? ;-)
Michael
[1] http://cvs2svn.tigris.org/faq.html#repoaccess
[2] http://cvs2svn.tigris.org/faq.html#testcase
[3] http://selenic.com/pipermail/mercurial-devel/2008-February/004975.html
[4] http://cvs2svn.tigris.org/features.html
^ permalink raw reply
* Re: multiple-commit cherry-pick?
From: Björn Steinbrink @ 2008-11-06 12:26 UTC (permalink / raw)
To: Miles Bader; +Cc: Deskin Miller, git
In-Reply-To: <buozlkd6oh1.fsf@dhapc248.dev.necel.com>
On 2008.11.06 21:14:18 +0900, Miles Bader wrote:
> Björn Steinbrink <B.Steinbrink@gmx.de> writes:
> > git reset --hard C
> > git rebase --onto ORIG_HEAD A^
>
> Is that safe...? Doesn't git-rebase also set ORIG_HEAD?
One of the first things rebase does is validating and resolving its
arguments. And that's happening before any actions that would touch
ORIG_HEAD. Though I'm not sure if it's always been like that.
Björn
^ permalink raw reply
* Re: Need help for migration from CVS to git in one go (ie, FORGETTING CVS history)
From: Francis Galiegue @ 2008-11-06 12:13 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <m3zlkdeelm.fsf@localhost.localdomain>
Le Thursday 06 November 2008 04:08:16 Jakub Narebski, vous avez écrit :
Hello,
[...]
> >
> > * 52 CVS modules, fine; but then this can become one and 52
> > subdirectories in them and still act as separate modules from
> > the build system point of view (which I have implemented, so
> > I can change it);
>
> I think that those CVS modules should become separate repositories,
> perhaps joined together using submodules. This is one of more
> difficult things during conversion.
>
> Note that in Git commits are always whole tree (whole project)
> commits.
>
Honestly, I'm not fond of this approach. The problem with submodules as far as
I'm concerned is that documentation is "not really there", and (unless the
README of egit is _really_ outdated) that there's no support in egit.
I know about commits affecting the whole tree, and even branches and tags, and
that's more of an advantage to my eyes, for two reasons:
* 99+% of queries currently done on the CVS tree (with Bonsai) cover all
modules; only rarely is a single module concerned, and in this case you just
fill in the appropriate field in the search page anyway;
* creating a branch is one command and that's it. It may also be one command
with submodules, but again, the documentation makes me uncomfortable; with
CVS, well... You get the picture.
What's more, I don't think we have the requirement of making specific
per-module tags. Not as far as this has been discussed so far, anyway, and
not as far as the history shows.
> > * second: even though this may be a "non problem", we use Bonsai,
> > which has the ability to see what was commited by whom, given a time
> > interval (from d1 to d2): the base gitweb allows to search by
> > commiter, which is good, but it has no date boundaries: do tools
> > exist for git that can do this? If not, that wouldn't be a big deal,
> > however...
>
> First, there are more web interfaces than gitweb, see
> http://git.or.cz/gitweb/InterfacesFrontendsAndTools
>
Yep, I've yet to try those... There are quite a few!
> Second, you can do this from command line, using combination of commit
> limiting a..b and a...b, or --since=<date> or --after=<date> and
> --before=<date>, commit message searching --author, --committer, and
> --grep, and path limiting "git log -- <pathspec>".
>
Well, a Web-based search engine is kind of a requirement. I'm the only one to
do command line... Thanks for the hints, though!
> Third, it would be not that hard to add more advanced search support
> to gitweb; this is even one of planned features.
>
Which brings back to the subject of submodules, since as I said above, we
generally search on the entire tree, and per-module searches are rare.
> > * third: also Bonsai-related; Bonsai can link to Bugzilla by
> > matching (wild guess) /\b(?:#?)(\d+)\b/ and transforming this into
> > http://your.bugzilla.fqdn.here/show_bug.cgi?id=$1. Does gitweb have
> > this built-in? (haven't looked yet) Is this planned, or has it been
> > discussed and been considered not worth the hassle?
>
> This is (under name of 'committags') in gitweb TODO; gitweb-xmms2
> support this IIRC or supported this (for Mantis and not Bugzilla
> though...)
Interesting... I'll have a look at it.
Thanks for the answers!
--
fge
^ permalink raw reply
* Re: multiple-commit cherry-pick?
From: Miles Bader @ 2008-11-06 12:14 UTC (permalink / raw)
To: Björn Steinbrink; +Cc: Deskin Miller, git
In-Reply-To: <20081106095122.GA2656@atjola.homenet>
Björn Steinbrink <B.Steinbrink@gmx.de> writes:
> git reset --hard C
> git rebase --onto ORIG_HEAD A^
Is that safe...? Doesn't git-rebase also set ORIG_HEAD?
-Miles
--
Twice, adv. Once too often.
^ permalink raw reply
* Re: More help needed on merging unrelated repos
From: Christian MICHON @ 2008-11-06 12:13 UTC (permalink / raw)
To: Karl Hasselström; +Cc: Andreas Ericsson, Git Mailing List
In-Reply-To: <20081106083751.GA10359@diana.vm.bytemark.co.uk>
On Thu, Nov 6, 2008 at 9:37 AM, Karl Hasselström <kha@treskal.com> wrote:
> On 2008-11-04 23:30:56 +0100, Christian MICHON wrote:
>
>> note the merge can work, but it's still done in 2 steps. :(
>> thanks for suggesting this.
>
> If it had worked, you'd have gotten just one merge commit. What you
> want to do is entirely possible, but it seems the high-level commands
> were not designed with your use-case in mind.
>
> Another thing you could try is to merge the two branches separately,
> getting a history like this:
>
> p1----\
> \
> p2---A--B
> /
> p3--
>
> And then use grafts to convince git that B has parents p1, p2, and p3
> (instead of its actual parents p1 and A). (Grep for "graft" in the
> Documentation directory.)
>
> And then use git-filter-branch to rewrite history so that the grafted
> history becomes the real history.
>
> --
> Karl Hasselström, kha@treskal.com
> www.treskal.com/kalle
>
nice suggestion Karl! it took a while to understand all the
consequences and workflow.
On top of your suggestion, I had to remove the
refs/original/refs/heads/master and the grafts file.
It worked well: quite a spell, but an efficient one. Kudo++
--
Christian
--
http://detaolb.sourceforge.net/, a linux distribution for Qemu with Git inside !
^ permalink raw reply
* Re: Question: 'git pull' hangs on local machine
From: Steve Walker @ 2008-11-06 11:34 UTC (permalink / raw)
To: git
In-Reply-To: <C520D4F3-1B6B-4049-911E-F1D82209A7B4@idibu.com>
All,
Please now ignore this - have tried it on a different connection and
its now worked :)
Kind regards, Steve.
On Nov 5, 2008, at 10:49 PM, Steve Walker wrote:
> Hi there,
>
> We have git on our server - I can pull between repo's no problem on
> the server. I've also cloned a repo on my local box to dev on. The
> clone has worked perfectly.
>
> The problem occurs when I try to do a 'git pull' to update my local
> repo with updates we've made on the server, i see this:
>
> StevePoota:public_html steve$ git pull
> remote: Counting objects: 89, done.
> remote: Compressing objects: 100% (63/63), done.
> Unpacking objects: 35% (24/67)
>
> It hangs on the unpacking objects stage. I tried pulling from
> different repo, but got the same issue.
>
> I've done some test updates on the server repo's in case they were
> corrupt but they seem to be ok...
>
> Has anyone got any ideas how to fix this?
>
> Kind regards, Steve
>
>
>
> --
> 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
www.idibu.co.uk
steve@idibu.com
Sales: +44 (0)800 311 2750
Support: +44 (0)870 626 4268
Fax: +44 (0)8701 417 136
Mobile: +34 661 785 387
www.linkedin.com/in/stevejwalker
^ permalink raw reply
* [StGit PATCH] stgit.el: Try to make the point stay on the coalesced patch.
From: David Kågedal @ 2008-11-06 10:27 UTC (permalink / raw)
To: kha, catalin.marinas; +Cc: git
It might not be spot on if all the coalesced patches were unapplied.
---
This fixes a small annoyance with the 'c' command.
contrib/stgit.el | 12 +++++++++++-
1 files changed, 11 insertions(+), 1 deletions(-)
diff --git a/contrib/stgit.el b/contrib/stgit.el
index d0f19c3..971ecd1 100644
--- a/contrib/stgit.el
+++ b/contrib/stgit.el
@@ -193,6 +193,9 @@ Commands:
(let ((patchsym (intern patch)))
(setq stgit-marked-patches (delq patchsym stgit-marked-patches))))
+(defun stgit-clear-marks ()
+ (setq stgit-marked-patches '()))
+
(defun stgit-marked-patches ()
"Return the names of the marked patches."
(mapcar 'symbol-name stgit-marked-patches))
@@ -406,8 +409,15 @@ With numeric prefix argument, pop that many patches."
(write-region (point-min) (point-max) file)
(stgit-capture-output nil
(apply 'stgit-run "coalesce" "-f" file stgit-patches))
+ (stgit-clear-marks)
(with-current-buffer log-edit-parent-buffer
- (stgit-refresh))))
+ ;; Go to first marked patch and stay there
+ (goto-char (point-min))
+ (re-search-forward (concat "^[>+-]\\*") nil t)
+ (move-to-column goal-column)
+ (let ((pos (point)))
+ (stgit-refresh)
+ (goto-char pos)))))
(defun stgit-help ()
"Display help for the StGit mode."
^ 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