[setup] Makefile.am patches

Corinna Vinschen corinna-cygwin@cygwin.com
Wed Feb 18 15:44:00 GMT 2015


On Feb 16 11:31, Corinna Vinschen wrote:
> On Feb 16 10:52, Achim Gratz wrote:
> > Corinna Vinschen writes:
> > > I saw some .gitattributes file mentioning exactly this ChangeLog merging
> > > in the binutils-gdb repo and copied it over so it's part of our repo as
> > > well.
> > 
> > That deals with the problem of merging log files.  If you do keep a
> > manual log just about any merge would create a conflict since you're
> > always editing the same part of the file.
> > 
> > > I don't know exactly where to go from there.  The comment claims the
> > > user has to install the git-merge-changelog package and per the comment
> > > "this is the tricky part!".  Why that's the tricky part beats me.  The
> > > git-merge-changelog package is part of the Fedora distro.
> > 
> > It is also in openSUSE, but other than that you'd have to install it by
> > hand.
> > 
> > > So, is that really all there is?  Installing git-merge-changelog,
> > > adding
> > >
> > >   [merge "merge-changelog"]
> > > 	  name = GNU-style ChangeLog merge driver
> > > 	  driver = git-merge-changelog %O %A %B
> > >
> > > to my .gitconfig and shoot?  So ultimately the user has to make the choice
> > > whether generating ChangeLogs automatically or manually, right?
> > 
> > Yes, you now have a merge driver for ChangeLog files and Git can use it
> > instead of the simple merge it would use otherwise.
> > 
> > >> For starters it only needs to trace back to the latest tag and not
> > >> through all commits and the tags give you an easy way to refer to
> > >> exactly the commit some release has been made from.
> > >
> > > Ok, I trust you tested it?  Please check in (with ChangeLog ;))
> > 
> > This is Git, so if you want to give it a spin, please add this as an
> > additional remote: http://repo.or.cz/w/cygwin-setup/local.git, then pull
> > from my "local" branch.
> 
> I inspected your code and played around with git-tag and git-describe
> so it's ok.

While tagging for the next release, I noticed this:

  $ git describe
  release_2.869-14-g10cac83

  $ git describe --match release_\* --abbrev=6 HEAD
  release_2.869-14-g10cac8

See the missing 3?  Shouldn't that be --abbrev=7 in the Makefile?

Next problem is this.  I just generated the annotation tag
"release_2.870".  Now what?  Do I have to push?  Or how do I get this
into the repo on sware?  git status tells me

  On branch master
  Your branch is up-to-date with 'origin/master'.
  nothing to commit, working directory clean

Git is puzzeling...


Thanks,
Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 cygwin AT cygwin DOT com
Red Hat
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://cygwin.com/pipermail/cygwin-apps/attachments/20150218/23d7465c/attachment.sig>


More information about the Cygwin-apps mailing list