* Re: Git SVN Rebranching Issue
From: Eric Wong @ 2008-11-06 9:39 UTC (permalink / raw)
To: Avery Pennarun; +Cc: Dmitry Potapov, Matt Kern, git
In-Reply-To: <32541b130811041640x18e3bbfewa639df356ff7561e@mail.gmail.com>
Avery Pennarun <apenwarr@gmail.com> wrote:
> On Tue, Nov 4, 2008 at 7:33 PM, Eric Wong <normalperson@yhbt.net> wrote:
> > Dmitry Potapov <dpotapov@gmail.com> wrote:
> >> On Tue, Nov 04, 2008 at 12:41:11AM -0800, Eric Wong wrote:
> >> >
> >> > Short answer: you can use grafts to remove parents.
> >>
> >> Using grafts requires some cautious, especially when it is used to make
> >> some commits unreachable, because git gc can remove unreachable commits.
> >> Also, a repository with grafts cannot be cloned. So using grafts looks
> >> like more as workaround rather a real solution.
> >
> > I don't think extra history is harmful at all, so the grafts could even
> > be temporary. AFAIK, the extra history is only an aesthetic issue in
> > visualizers (and I actually like to see it myself).
>
> But it's *lying* history in this case; it doesn't reflect what really
> happened in svn *or* in real life. I'd say lying history is most
> often harmful. "git blame" and "git log" will lie in this case, for
> example.
Maybe, but I don't find having a choice to follow _either_:
a) copy history (the REAL history)
b) the name history (faked)
I've had to deal with repositories that recycled branch names for a
while now and it hasn't been an issue for me nor anybody else
using git svn on them.
git log --first-parent exists for following copy history, too.
> >> Would it not be better to save the old branch using "@SVN-NUMBER" as
> >> suffix? Thus, those do not need the old branch can easily delete it.
> >
> > That would require renaming _existing_ branches to their "@SVN-NUMBER"
> > name; which would break mechanisms for tracking branches based on
> > refname.
>
> Well, you wouldn't have to rename the existing branch. You would
> simply create the new @SVN-NUMBER branch when it became clear that
> that commit is no longer reachable from the undecorated branch ref.
> Isn't that why the @SVN-NUMBER branches are needed in the first place?
Making @SVN-NUMBER branches for new/latest branches is even more
confusing. That would mean the user would have to remember the
@SVN-NUMBER every time they wanted to do operations with the
recycled branch.
The current use of @SVN-NUMBER in branches are only used when following
parents (when repositories are rearranged). In retrospect, it's
probably possible to for git-svn to not make them user-visible (I seem
to recall they made development/debugging/testing easier in the past,
though).
> As for tracking branches based on refname, it seems like the current
> behaviour of pretending to merge histories together wouldn't work too
> well anyway. For someone pulling from the messed-up branch, they
> really *will* need to rewind and re-pull, since that's exactly what
> happened in svn. I don't think git has any chance of doing this
> automatically just because of a new commit with two parents.
"git svn rebase" and "git log ..$RECYCLED" both work. non-FF/non-squash
pulls won't, of course.
> Disclaimer: I haven't run into any of this myself since I don't
> recycle branch names in svn :)
Lucky you :)
--
Eric Wong
^ permalink raw reply
* Re: [PATCH v2] git-svn: proper detection of bare repositories
From: Eric Wong @ 2008-11-06 9:45 UTC (permalink / raw)
To: Deskin Miller; +Cc: git, gitster
In-Reply-To: <20081106050739.GA7713@euler>
Deskin Miller <deskinm@umich.edu> wrote:
> On Tue, Nov 04, 2008 at 12:30:15AM -0800, Eric Wong wrote:
> > How about using git_cmd_try instead?
> >
> > The Error.pm try/catch stuff makes me a bit uncomfortable. I realize
> > it's (unfortunately) in Git.pm; but I'd rather keep it confined there so
> > we can more easily remove it later if someone were inclined.
>
> Yeah, major thinko; I read the Git(3pm) manpage, looked at git_cmd_try, and for
> some reason thought that it wasn't what I want. But it's exactly what I want.
Thanks, acked and pushed out to git://git.bogomips.org/git-svn.git
--
Eric Wong
^ permalink raw reply
* Re: multiple-commit cherry-pick?
From: Björn Steinbrink @ 2008-11-06 9:51 UTC (permalink / raw)
To: Deskin Miller; +Cc: Miles Bader, git
In-Reply-To: <20081106032437.GA27237@euler>
On 2008.11.05 22:24:37 -0500, Deskin Miller wrote:
> On Thu, Nov 06, 2008 at 11:45:27AM +0900, Miles Bader wrote:
> > Is there any easy way to cherry pick a _range_ of commits from some other
> > branch to the current branch, instead of just one?
> >
> > I thought maybe git-rebase could be coerced to do this somehow, but I
> > couldn't figure a way.
>
> Rebase is exactly what you want. Given something like this:
>
> o--o--o--A--B--C--o--o--X
> \
> o--o--D
>
> where you want A, B, C to go on top of D:
>
> $ git checkout -b newbranch C
> $ git rebase --onto D ^A
That should be A^ ;-)
> newbranch will have <...> --D--A--B--C
... and then you can merge newbranch into the existing branch that
references D, fast-forwarding the branch. And then newbranch can be
deleted.
If you don't want to use a temporary branch, you can also do (while on
the branch onto which you want to cherry-pick):
git reset --hard C
git rebase --onto ORIG_HEAD A^
Which should get you the same result, without using a temporary branch.
Björn
^ permalink raw reply
* Re: How to rebase for git svn?
From: Eric Wong @ 2008-11-06 9:55 UTC (permalink / raw)
To: Yang Zhang; +Cc: git
In-Reply-To: <4911EF4C.8030703@gmail.com>
Yang Zhang <yanghatespam@gmail.com> wrote:
> Hi, I made a git svn repository from an svn repository. Then I cloned
> the git repository, committed some changes to the clone, and pulled back
> to the original repository. However, now the original repository gives
> me conflicts whenever I run git svn rebase. I believe this is because
> git pull treats the other repository's commits as a branch and merges
> them back instead of rebasing them and maintaining the type of linear
> history that is good for playing with svn. Any hints as to how to fix
> this? I think the solution is to undo the merge that resulted from the
> pull, but I don't know how to do this.
>
> I wrote a simple script reproducing exactly what's going on (along with
> a transcript of its output). I tried to make it as simple as possible,
> but it can probably be simplified even more to reproduce the problem:
>
> http://assorted.svn.sourceforge.net/viewvc/assorted/sandbox/trunk/src/git/gitsvn.bash?revision=1057&view=markup
>
> Thanks in advance for any help!
Hi,
Try passing --rebase or --squash with "git pull" to keep history linear
for SVN.
--
Eric Wong
^ permalink raw reply
* Re: How to rebase for git svn?
From: Sverre Rabbelier @ 2008-11-06 10:15 UTC (permalink / raw)
To: Eric Wong; +Cc: Yang Zhang, git
In-Reply-To: <20081106095500.GA9587@untitled>
On Thu, Nov 6, 2008 at 10:55, Eric Wong <normalperson@yhbt.net> wrote:
> Yang Zhang <yanghatespam@gmail.com> wrote:
>> Thanks in advance for any help!
>
> Try passing --rebase or --squash with "git pull" to keep history linear
> for SVN.
Consider doing the following:
git config alias.repull "pull --rebase"
And then using 'git repull' instead of 'git pull'.
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* StGit: stgit mail configuration options
From: David Kågedal @ 2008-11-06 10:21 UTC (permalink / raw)
To: Catalin Marinas; +Cc: Git Mailing List
The "stg mail" command uses a couple of configuration options that are
completely undocumented, and don't fit well together.
"stgit.autobcc" seems to give a default value for the --bcc option.
"stgit.mail.prefix seems to give a default value for the --prefix
option.
Shouldn't these both be stgit.* or stgit.mail.*? And shouldn't they be
documented? Or maybe removed?
And I propse that the autobcc option should be a boolean which means
that user.email should be used.
--
David Kågedal
^ permalink raw reply
* Re: How to rebase for git svn?
From: Björn Steinbrink @ 2008-11-06 10:24 UTC (permalink / raw)
To: sverre; +Cc: Eric Wong, Yang Zhang, git
In-Reply-To: <bd6139dc0811060215j1ad7ee0ahd0b568283da06cb@mail.gmail.com>
On 2008.11.06 11:15:21 +0100, Sverre Rabbelier wrote:
> On Thu, Nov 6, 2008 at 10:55, Eric Wong <normalperson@yhbt.net> wrote:
> > Yang Zhang <yanghatespam@gmail.com> wrote:
> >> Thanks in advance for any help!
> >
> > Try passing --rebase or --squash with "git pull" to keep history linear
> > for SVN.
>
> Consider doing the following:
> git config alias.repull "pull --rebase"
> And then using 'git repull' instead of 'git pull'.
Or set branch.<name>.rebase in your config and just use "git pull" ;-)
Setting branch.autosetuprebase might also be useful in that case.
You should be careful to make sure that the other side does not lag
behind WRT svn, though. Otherwise, you end up rebasing commits that
corresponds to svn revisions. Bad.
Björn
^ 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
* 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
* 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: 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: 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: 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: 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: 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: 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
* 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: 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
* 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: 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
* 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: 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: [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: [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 (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
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