Re: [Nano-devel] polished git repo

[Kamil Dudka]

On Wednesday, February 17, 2016 14:28:47 Mike Frysinger wrote:
> On 17 Feb 2016 20:03, Benno Schulenberg wrote:
> > On Tue, Feb 16, 2016, at 20:21, Mike Frysinger wrote:
> > > 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?

The sooner we stop synchronizing it with svn the better.  I guess many of us 
already maintain a local git repository to access the upstream svn repository.  
Keeping it synchronized is an unpleasant work for no real benefit.

> > (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".)
> 
> i'm pretty sure it can, but it's harder.  instead, i was thinking that
> once we want to move to git, i'd do a one-time rewrite of the history
> and then everyone can switch.

That would be really appreciated!

> > 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),

Loosing the ability to synchronize with svn is not an issue in my view.

> > will it still be possible to easily find the
> > commit in git that corresponds to a certain revision number in svn?

The info is in the commit messages in a machine-readable format, so you
can use 'git log --grep' to look that up.  I believe that by "trimming"
Mike did not mean dropping svn id from commit messages.

> > In other words, is there a command in git that does the equivalent
> > of 'svn diff -c nnnn'?

There is the 'git diff' command you can use to diff anything with anything.

Kamil

> no, that is not easy to do.  not all of the svn commits (rev #s) will
> be in the git repo -- some are garbage like branches/vendor/ and some
> are generated like creating tags/, but git doesn't do that.  so that'd
> leave holes in the # range in the log of trunk (master).
> 
> we could add a svn rev<->git sha1 map, but seems like a lot of work.
> we could try using git-notes so people could get the augmented history
> if they really wanted it.
> -mike