FYI: I'm going to give this a whirl w/ MAHOUT-798. Hopefully I won't muck
things up, but bear with me as this is a new workflow for me.
On Sep 18, 2011, at 7:58 AM, Dawid Weiss wrote:
> Yes, these instructions worked for me:
> go to http://wiki.apache.org/general/GitAtApache, then: "Git for
>
I use both Mercurial and git.
The fans you quote are wrong. The major problem with mercurial is that you
can't rewrite history. Keeping a patch separate from a moving base and all
commits after the underlying softwares commits really requires git.
On Sun, Sep 18, 2011 at 11:52 PM, Lance Norskog
I agree with Ted: screwing up your repository (I assume a local clone
of something remote) in svn is much easier than in git, for example by
moving a folder from one place to another. If I can recommend
something, this book is quite nice, especially for beginners ("Basic
Usage" chapter):
http://bo
I have the ability to bollix svn in ways that nobody else fathoms. Some fans
promote Mercurial as "Git without pain".
On Sun, Sep 18, 2011 at 8:09 PM, Ted Dunning wrote:
> On Sun, Sep 18, 2011 at 5:21 PM, Lance Norskog wrote:
>
> > One important caveat: git is a rope factory for hanging yoursel
On Sun, Sep 18, 2011 at 5:21 PM, Lance Norskog wrote:
> One important caveat: git is a rope factory for hanging yourself. It badly
> needs a Chef/Puppet-style "describe the end result" executor. Don't be
> surprised when you have to re-build your whole checkout when something
> unfathomable blows
It's gitk on windows. Also there's a Tortoise git manager for the windows
desktop. And Github has a mac-only local management app.
One important caveat: git is a rope factory for hanging yourself. It badly
needs a Chef/Puppet-style "describe the end result" executor. Don't be
surprised when you ha
As part of that learning curve, make sure you check out gitx (on the mac,
gitg on linux, I don't care what is on windows).
It makes it easier to understand what the branching structure is.
I recommend invoking as gitx --all to show all of the branches right away.
This will highlight the interest
I didn't mean to criticize github -- I use it myself for a number of
projects and I've been extremely happy with their service. I merely
suggested that in terms of the learning curve one may wish to start
with local branches and then slowly progress to adding more remote
sources. I think throwing m
Yes, one doesn't have to use github of course. I do it just to share,
collaborate and let people try and preview what I do with a more timely
detailed history and in more convenient way than an issue patch allows.
Besides, it allows me to have a backup in case my desktop disk goes cuckoo,
and wor
> That is, once you are over the learning curve and have a good workflow! I've
> been doing an SVN patch workflow for a long time now and it has served me
> well. Oh well, time to move on!
I'll put it this way: moving to git is well worth the time spent on
learning. I was a skeptic myself... f
On Sep 18, 2011, at 3:20 PM, Ted Dunning wrote:
> Actually, this is important to say. Speed is one of the huge advantages of
> git over other options.
That is, once you are over the learning curve and have a good workflow! I've
been doing an SVN patch workflow for a long time now and it has s
Actually, this is important to say. Speed is one of the huge advantages of
git over other options.
On Sun, Sep 18, 2011 at 1:13 PM, Dawid Weiss
wrote:
> In case of Lucene you can also work on multiple svn branches and do
> the switching using git... needless to say this is way faster than
> usin
I looked at it -- yes, this is the way to follow. You can save some
complexity by not keeping a github remote (if you work from one place,
a local feature branch is enough, no need to push/pull to github).
In case of Lucene you can also work on multiple svn branches and do
the switching using git.
Dmitriy documented his work-flow which is very similar to this:
http://weatheringthrutechdays.blogspot.com/2011/04/git-github-and-committing-to-asf-svn.html
I use his process almost exactly.
On Sun, Sep 18, 2011 at 5:58 AM, Dawid Weiss
wrote:
> Yes, these instructions worked for me:
> go to htt
Awesome! Thanks.
On Sep 18, 2011, at 7:58 AM, Dawid Weiss wrote:
> Yes, these instructions worked for me:
> go to http://wiki.apache.org/general/GitAtApache, then: "Git for
> Apache committers". The URL for git svn init needs to be:
>
> git svn init --prefix=origin/ --tags=tags --trunk=trunk
>
Yes, these instructions worked for me:
go to http://wiki.apache.org/general/GitAtApache, then: "Git for
Apache committers". The URL for git svn init needs to be:
git svn init --prefix=origin/ --tags=tags --trunk=trunk
--branches=branches https://svn.apache.org/repos/asf/lucene/dev
Should work out
Resurrecting old thread...
I originally just cloned from the ASF Git mirrors. Is there a way to then
associate it with an SVN repos so that I can then push a branch to SVN? I've
got a rather large set of changes across several commits (and don't remember
when I started). My thinking was I wo
I'm the same as Ted -- I have a local repo only and maintain my branches in
there. Don't know about interoperability with other existing git-svn mirrors
like the ones you mentioned, sorry.
Dawid
On Mon, Mar 7, 2011 at 9:01 AM, Ted Dunning wrote:
> I use git svn exclusively any more.
>
> But all
I use git svn exclusively any more.
But all of my git mirrors come from the base that I synchronize using svn.
I haven't try squishing.
I have been maintaining 4-7 local branches this way for some time. Works
like a champ.
On Sun, Mar 6, 2011 at 11:07 PM, Dmitriy Lyubimov wrote:
> in case of
in case of ASF though i found that git svn for some reason checks out
commit history with commit md5 which are different than those
propagated to github (and i guess git.apache.org). So commit from
other branches (merged to git-mirrored trunks) cannot be
merge-squashed to git-svn branch because the
Thanks Dawid.
On Thu, Feb 17, 2011 at 12:14 PM, Dawid Weiss
wrote:
> Works like a charm in my experience, although you should be careful about:
>
> a) merging; best merge local branches with squashing, so that they
> appear as a single patch rather than a commit sequence.
> b) empty folders (reme
Works like a charm in my experience, although you should be careful about:
a) merging; best merge local branches with squashing, so that they
appear as a single patch rather than a commit sequence.
b) empty folders (remember about setting --rmdir if you're removing
something that should remove fol
Any concerns about git-svn as a commit tool?
Thanks
-Dima
23 matches
Mail list logo
