Re: git-svn: commit author x commit committer issue

[Eric Wong <normalperson@yhbt.net>]

Richard MUSIL <richard.musil@st.com> wrote:
> Eric Wong wrote:
> > Richard MUSIL <richard.musil@st.com> wrote:
> > I also want to avoid creating extra junk on the SVN repository which I
> > don't personally consider very important.  SVK does stuff like that with
> > merges, and only SVK understands the metadata it uses.  I prefer
> > transparency.
> 
> I made some suggestions in this thread about using revision
> (unversioned) property of SVN fot git "metadata". AFAIK using rev. props
> is completely transparent to other SVN clients (in this case those not
> being git-svn), so they could easily ignore them.
> 
> It could be optional on git config property for commit and autodetected
> for clone/pull.
> 
> The scenario I could easily imagine (though it is not something I am
> currently using) is having dev teams using git internally (because its
> much easier for tracking local development) and having SVN repo as a
> "central hub". In such environment, there will be probably one person in
> each team (dev. lead) collecting commits from others and once things are
> set, he will commit all changes to svn. In that particular case, he does
> not have to worry about different sha1s, because they use only one SVN
> (as it was meant to be used). But he could be sad about losing all
> authors info about the people commits. And my personal believe is, this
> is how git-svn may enter svn world on big projects.
> 
> But you are right, it is up to you to decide. It was just an idea ;-).

It'd be easy for git-svn to write metadata to rev-props.  Whether or not
it reads and does anything with them is another issue...  I think Sam
was working on something that allowed it to track merges on the
git-side, but we'd be introducing a third or fourth method of
non-standard merge-tracking into SVN :)

In any case, this behavior should always be optional and off by default.

-- 
Eric Wong