[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Findutils-patches] [PATCH 1/2] Explain that before reporting a prob
Re: [Findutils-patches] [PATCH 1/2] Explain that before reporting a problem, you should try the current
Sat, 23 Jun 2007 09:37:41 -0600
James Youngman wrote:
> Eric Blake wrote:
> >Say, do you have your git repository published somewhere? Is it worth
> >getting it added to git.sv.gnu.org/gitweb?
> Yes and no. There is a public repo, but it's downstream of CVS.
Being an advocate for git I thought I would mention here that it is
possible to automatically flow changes from CVS commits into Git
commits. A dedicated git branch to match the cvs repository will
avoid having any conflicts. Of course that perpetuates keeping the
cvs as the master. Because of the improved capabilities of Git if
using both then it would be desirable to switch that around as soon as
> 5. There is also a third git repository which is also local here, in
> which I make changes on a private branch. I then format the commits
> and mail them to address@hidden for review. I have a
> script for doing this, so far it seems cumbersome but painless.
> 6. Patches to the findutils-patches mailing list are delivered
> indirectly to individual files in a location convenient to me.
> 7. When positive review comments come in I can apply these patches to
> the CVS repository.
> 8. I can then sync CVS changes into the master branch of my GIT
> repository (see item 5 here). I can periodically rebase my private
> branch against the master.
> This is all unproven and not well bedded in. Items 7 and 8 haven't
> happened yet, having three GIT repositories seems a bit cumbersome,
A nice thing about more than one version control repository is that it
is safer against the accidental 'rm -rf' or disk failure accident.
> not enough is automated, and I am still so new with git that I fear it
> is only a matter of time before I have a nasty accident :(
The fortunate thing about version control is that if there is a
problem there is always a way to fall back to undo the problem. :-)
Therefore much of your fear can be mitigated.
> I'm not ready, yet, for using GIT as the authoritative upstream
> source. At the moment I am essentially using git for managing
> patches. My principal reason is that I'm insifficiently familiar
> with it. More generally though, I am positively inclined about the
> idea of using git.sv.gnu.org.
I think cautious maintainers are a good thing. I like seeing the
careful progress forward.