Re: [Nano-devel] polished git repo

[Benno Schulenberg]

On Tue, Feb 16, 2016, at 20:21, Mike Frysinger wrote:
> On 16 Feb 2016 11:59, Kamil Dudka wrote:
> > On Tuesday 16 February 2016 04:48:20 Mike Frysinger wrote:
> > > the only two outstanding issues:
> > >  - the converted git does not do include keyword expansion (e.g. $ID:$),
> > >    so many of the files will not diff exactly to the tarballs.  git does
> > >    not make this easy, so i think it's fine to leave as-is.
> > >  - the git messages all have the svn metadata in them.  e.g. the log has:
> > >    git-svn-id: svn://svn.savannah.gnu.org/nano/trunk/address@hidden
> > > 35c25a1d-7b9e-4130-9fde-d3aeb78583b8 i think it's OK to leave these in.
> > 
> > Both of them are expected and harmless IMO.
> 
> sorry, i should have clarified a bit.  what i meant was we should agree
> that this is what we want.  they're both standard/common in the svn->git
> world and i don't mind them.  but some people really like to have diff
> behavior,

If those were the only differences, it might be worth to make
them go away.  But there are other differences too: on a newer
system all the Makefile.in-s are different, and all the PO files
too (adding a Language: field to the header, and a c-format tag
to one of the messages), and some of the texi stuff and generated
html too.  So... let it be.

(Using your repo, I've regenerated a 2.2.6 tarball.  What I noticed
most was that it is 40 kilobytes bigger than the original one --
mostly because of the Makefiles, the PO files, and the texinfo.texi.)


> and it is possible to attain that with some scripts to rewrite
> the history.  for keyword expansion, it's a bit non-trivial, but for the
> svn metadata in the commit message, it's easy to trim.

But when you remove that svn metadata, can git still synchronize
with svn?  (Some months ago I've tried twice a git over svn checkout
with --no-metadata, and it's useless: when the checkout is complete
you can't 'git svn rebase' any more: "Unable to determine upstream
SVN information from working tree history".)

If trimming that git-svn-id from the commit message is possible
without losing the ability to rebase your repo (for as long as we
are still using svn), will it still be possible to easily find the
commit in git that corresponds to a certain revision number in svn?
In other words, is there a command in git that does the equivalent
of 'svn diff -c nnnn'?

Benno

-- 
http://www.fastmail.com - The way an email service should be