This is the mail archive of the cygwin-apps mailing list for the Cygwin project.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
Other format: | [Raw text] |
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
Attachment:
pgpQFeaMW4qZb.pgp
Description: PGP signature
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |