Re: GNU-style ChangeLog merge driver for Git
Eric Blake wrote: As of git 1.5.4, you can do 'git pull --rebase', to rebase all your local changes on the current branch on top of whatever upstream changes were made in the meantime ... Oops - this put the upstream ChangeLog entries at the top of the file, in front of my entries which I am about to push upstream. I updated the heuristics to take care of this case as well. enforces the following abbreviated ChangeLog style when a single author makes two commits in one day: ... However, the abbreviated style does not currently work with your merge driver, since it treats the entire date-delimited chunk, containing two commits' entries, as a single commit description; and since it does not match any other entry, the merged result then ends up with two copies of the earlier entry: The merge driver should not cause duplication. It should either apply a change that you made, or mark it as a conflict. (Only if you remove the conflict markers without much thought, you will get duplication.) In my experiments, when you augment a ChangeLog entry like you did, either the augmented entry is put in place of the old one (at a position which will not please you), or a conflict is signalled. But it would be nice if your merge driver could recognize that usage. I added an option --split-merged-entry which does just that. To use it, mention it in your $HOME/.gitconfig. It would also be nice if there were a custom diff driver to go alongside the custom merge driver Feel free to implement such a thing. For my part, I don't need it, since I'm accustomed to this slight inaccuracy of diff's output. Bruno
Re: GNU-style ChangeLog merge driver for Git
Bruno Haible bruno at clisp.org writes: Benoit Sigoure explained that what we need to solve this problem is a git merge driver. Here is such a merge driver. It should solve the problem. /* Heuristic to determine whether it's a pull in downstream direction (e.g. pull from a centralized server) or a pull in upstream direction (e.g. git stash apply). For ChangeLog this distinction is important. The difference between an upstream and a downstream repository is that more people are looking at the upstream repository. They want to be informed about changes and expect them to be shown at the top of the ChangeLog. When a user pulls downstream, on the other hand, he has two options: a) He gets the change entries from the central repository also at the top of his ChangeLog, and his own changes come after them. b) He gets the change entries from the central repository after those he has collected for his branch. His own change entries stay at the top of the ChangeLog file. In the case a) he has to reorder the ChangeLog before he can commit. No one does that. So most people want b). In other words, the order of entries in a ChangeLog should represent the order in which they have flown (or will flow) into the *central* repository. But in git this is fundamentally indistinguishable, because when Linus pulls patches from akpm and akpm pulls patches from Linus, it's not clear which of the two is more upstream. Also, when you have many branches in a repository and pull from one to another, git has no way to know which branch is more upstream than the other. The git-tag(1) manual page also says: One important aspect of git is it is distributed, and being distributed largely means there is no inherent upstream or downstream in the system. Therefore anyone who attempts to produce a ChangeLog from the merge history will fail. Here we allow the user to specify the pull direction through an environment variable (GIT_UPSTREAM or GIT_DOWNSTREAM). If these two environment variables are not set, we assume a simple single user usage pattern: He manages local changes through stashes and uses git pull only to pull downstream. How to distinguish these situation? There are several hints: - During a git stash apply, GIT_REFLOG_ACTION is not set. During a git pull, it is set to 'pull'. - During a git stash apply, there is an environment variable of the form GITHEAD_40_hex_digits='Stashed changes'. */ Your heuristics guess wrong in at least one useful scenario. As of git 1.5.4, you can do 'git pull --rebase', to rebase all your local changes on the current branch on top of whatever upstream changes were made in the meantime. So I'm starting to use this new workflow for simple changes (note that I don't need to use the poor UI of 'git stash' with this workflow): $ git branch # I'm working directly on master, with no topic branches * master $ # do some edits, including changelog $ git commit -a -m 'Patch for ...' ... $ git pull --rebase # check for any upstream changes in the meantime First, rewinding head to replay your work on top of it... HEAD is now at e3dce8b... Fix texinfo grammar. Applying Patch for ... error: patch failed: ChangeLog:1 error: ChangeLog: patch does not apply Using index info to reconstruct a base tree... Falling back to patching base and 3-way merge... Auto-merged ChangeLog merging ChangeLog using GNU-style ChangeLog merge driver $ # inspect ChangeLog Oops - this put the upstream ChangeLog entries at the top of the file, in front of my entries which I am about to push upstream. While I could do 'GIT_DOWNSTREAM= git pull --rebase', it would be nicer if you could make your heuristics recognize this mode of operation. One other thing I've noticed. The clcommit script (originally from the cvs- utils project, which is now mostly defunct; but which is still actively distribtuted as part of the libtool project under the name commit) enforces the following abbreviated ChangeLog style when a single author makes two commits in one day: 2008-02-12 Eric Blake [EMAIL PROTECTED] Silence warning in last patch. * lib/quotearg.c (quotearg_buffer_restyled): Add missing const. Quotearg part 4: add tests, fix c-maybe colon quoting. * lib/quotearg.h: Improve documentation. rather than a full-blown: 2008-02-12 Eric Blake [EMAIL PROTECTED] Silence warning in last patch. * lib/quotearg.c (quotearg_buffer_restyled): Add missing const. 2008-02-12 Eric Blake [EMAIL PROTECTED] Quotearg part 4: add tests, fix c-maybe colon quoting. * lib/quotearg.h: Improve documentation. The reason for this policy is that with
Re: GNU-style ChangeLog merge driver for Git
Bruno Haible [EMAIL PROTECTED] wrote: James Youngman wrote: These days, I use a ChangeLog-format change message as my GIT commit message, which solves most of the problem. It's still not that convenient, sadly, because (1) I have not yet taken the time to wrap Emacs' add-change-log-entry so that it creates a new file for use with git commit -F (instead I just cut the change off the head of ChangeLog and write the extract to ..git/cl-desc) Wouldn't a wrapper around git commit do it? I mean, a program 'vc-commit', such that vc-commit foo/bar.c bla/blah.c does the same as git commit -m message foo/bar.c bla/blah.c ChangeLog after having extracted the message from the yet-uncommitted diffs of ChangeLog. Such a program should be usable by command-line users and by Emacs users, right? That's what vc-dwim --commit does (though only from the command line): http://hg.et.redhat.com/hg/emd/applications/vc-dwim?f=97cd8156ef24;file=README;style=raw You can check out the sources with this: hg clone http://hg.et.redhat.com/hg/emd/applications/vc-dwim Note that the package also includes Ralf Wildenhues' vc-chlog program, which generates ChangeLog entries from a working directory with diffs relative to a version control system (any of cvs, hg, git, svn).
Re: GNU-style ChangeLog merge driver for Git
James Youngman wrote: These days, I use a ChangeLog-format change message as my GIT commit message, which solves most of the problem. It's still not that convenient, sadly, because (1) I have not yet taken the time to wrap Emacs' add-change-log-entry so that it creates a new file for use with git commit -F (instead I just cut the change off the head of ChangeLog and write the extract to ..git/cl-desc) Wouldn't a wrapper around git commit do it? I mean, a program 'vc-commit', such that vc-commit foo/bar.c bla/blah.c does the same as git commit -m message foo/bar.c bla/blah.c ChangeLog after having extracted the message from the yet-uncommitted diffs of ChangeLog. Such a program should be usable by command-line users and by Emacs users, right? Bruno
Re: GNU-style ChangeLog merge driver for Git
On Feb 12, 2008 2:41 AM, Micah Cowan [EMAIL PROTECTED] wrote: OTOH, a more difficult problem might be: how do you go about fixing erroneous commit logs? In Subversion and CVS, this can be dealt with if you have appropriate privileges; but in Mercurial at least (and probably Git as well?), the commit log is a part of the changeset; you can't change it without making it a wholly separate changeset. So if it's already been published, it'd be impractical to correct; it'd require some gnarly post-processing, then, to make the corrections. You can use git filter-branch --msg-filter=foo, with appropriate foo. However, the resulting commits will no longer be the ancestors of any changes other people have in their own repository, requiring them probably to do a (non-fast-forward?) fetch and then rebase their changes. All in all it's very awkward, and I'm not sure I fully understand the downsides of having to do it. Then again, there's a different sort of problem that's been irking me somewhat with making ChangeLog entries (whether generated or manual), ever since I started using DRCSses, and that is that the DAG nature of change history in a DRCS doesn't map cleanly to a linear ChangeLog. That is, you can no longer depend, for changes listed A, B, C, D, that all of the changes A, B, and C were present at the time change D was made. This can lead to false impressions about the context of a change entry, or of the history of a particular section of code. This isn't causing me major headaches It does cause me major headaches, particularly when dealing with long sequences of significant but not-yet-merged changes. For example, merging Leslie Polzer's Summer of Code changes for findutils is going to require almost as much work making the ChangeLog work as in merging all of the rest of the code combined. (I know this because I already did a few trial merges). This isn't Leslie's fault at all; he complied with the GNU coding standards; it's the nature of ChangeLog files. However, I have yet to try out the merge-changelog driver. I used to avoid this problem by runing rcs2log (specifically, Emacs's vc-update-change-log command) on the CVS repository for a previous project. However, I found that the username mappings didn't always work as I wished for CVS, and the changelog messages were typically not detailed enough. I found the more disciplined format of ChangeLog an improvement. These days, I use a ChangeLog-format change message as my GIT commit message, which solves most of the problem. It's still not that convenient, sadly, because (1) I have not yet taken the time to wrap Emacs' add-change-log-entry so that it creates a new file for use with git commit -F (instead I just cut the change off the head of ChangeLog and write the extract to .git/cl-desc), and (2) I still need to manually prepend the GIT commit message to ChangeLog when applying changes from GIT to the CVS repository. I'm not sure what I will do in place of (2) when I migrate the public findutils repository from CVS to GIT, though. Maybe just using the merge driver or auto-generating the ChangeLog will be enough. James.
Re: GNU-style ChangeLog merge driver for Git
Ben Pfaff wrote: The web interface is searchable. Type your search string into the box labeled search: and hit Enter. Click on the question mark for a description of the kinds of searches that are available. Indeed! Thanks for pointing this out. This weakens my previous arguments. Bruno
Re: GNU-style ChangeLog merge driver for Git
Bruno Haible [EMAIL PROTECTED] wrote: Jim Meyering wrote yesterday: With the proliferation of topic branches in my work-flow, it is not effective for me to version-control ChangeLog files (too many pointless conflicts). So, for projects that I control, I am transitioning away from that. ... Instead, now, I compose ChangeLog entries solely in git log messages and use the following script to generate a ChangeLog file at make dist time. So, people who now download your development version get the sources without any ChangeLog! If they are looking for the likely reason for the breakage on platform XY or of unit test foo/bar, they cannot look at and search through the version history, except if they have special tools (like gitk) _and_ are familiar with them. You are throwing a proven and helpful GNU practice overboard. This is very bad. That is a fallacious argument. Would-be coreutils developers already have some requirements: they must be able to read README-hacking and install all of the tools it mentions. Expecting them to know how to use git log is no different. While gitk is useful, it's certainly not required to view the logs. However, for those who would like a real ChangeLog file, I may simply add a Makefile rule like the one already in Makefile.am that will generate it upon demand. The real problem is, as you say and as everyone noticed, the pointless conflicts at the top of the ChangeLog file. It's not just that. If I have a patch series and want to reorder or combine change sets, I don't want to have to deal with *any* complications involving ChangeLog conflicts. Also, when I amend a commit to affect an additional file, it's enough to change the commit log: I don't want to take the time to make an identical change to the ChangeLog. This also comes down to avoiding duplication: typically, I would put almost exactly the same text in the commit log as I put in the ChangeLog file, albeit with slightly different formatting. Any time you do that, where the nominally synchronized pieces can be changed independently, they will sometimes get out of sync.
Re: GNU-style ChangeLog merge driver for Git
Mike Frysinger wrote: maintaining ChangeLogs is redundant work, when you're already entering the very same information into the version control system. Please place yourself at the position of the user who builds and runs a program, not the developer. ... how is the user's position relevant ? users will not be using gnulib, developers will. It's not about gnulib's ChangeLog in particular, but more generally about the ChangeLog of packages that install programs. Bruno
Re: GNU-style ChangeLog merge driver for Git
Hello Bruno, A couple of minor nits: * Bruno Haible wrote on Mon, Feb 11, 2008 at 01:15:47AM CET: bin_PROGRAMS = git-merge-changelog git_merge_changelog_LDADD = -L. -lgnu Please make this git_merge_changelog_LDADD = libgnu.a so that automake notices and adds the dependency, so that a parallel build does not fail. /* Installation: $ gnulib-tool --create-testdir --dir=/tmp/testdir123 git-merge-changelog $ cd /tmp/testdir123 $ ./configure $ make $ make install This creates a file $prefix/share/dummy/javaversion.class Surely that 'dummy' is weird, but the file should not be needed at all, no? Cheers, Ralf
Re: GNU-style ChangeLog merge driver for Git
Eric Blake wrote: I wonder if this would be worth pushing upstream for inclusion in git proper. Yes, this should be considered, after a testing phase of - say - two weeks. if a project uses the git-merge-changelog module ... ... Shouldn't this be a noinst target? The git-merge-changelog module is not meant to be used by other projects; rather, it's a program that targets developers as users. It would make sense to distribute it as a package of its own on ftp.gnu.org, or as contrib of the official git. I put it into gnulib only because gnulib already has some git-related tools. Bruno
Re: GNU-style ChangeLog merge driver for Git
Jim Meyering wrote:
However, for those who would like a real ChangeLog file, I may simply
add a Makefile rule like the one already in Makefile.am that will
generate it upon demand.
This would be useful, yes. Or - since the ChangeLog is part of what should
be distributed and not erased by make distclean - it could be already
created by {autogen.sh,bootstrap}.
But wait... *generate* the ChangeLog? Is this possible at all?
- A ChangeLog should have the ChangeLog entries in the order in which they
hit the HEAD branch. But when you are dealing with several branches
and pulling from one branch to another, then can you guarantee the
order of git log is the same as the desired order of entries in
ChangeLog, i.e. the order of appearance of the patches in HEAD?
Recall that git knows nothing about which branch is closer to HEAD.
(I did a simple test with a merge and a rebase. This works fine. But
the more complex cases?)
- When a patch was produced by 2 or 3 people jointly, we list all authors
in the head of the ChangeLog entry. Can git log do this?
If I have a patch series and want to reorder or combine change sets, I
don't want to have to deal with *any* complications involving ChangeLog
conflicts. Also, when I amend a commit to affect an additional file,
it's enough to change the commit log: I don't want to take the time to
make an identical change to the ChangeLog.
This is understandable.
You change your way of working so that it works fine with the given versioning
system. I prefer to modify the versioning system so that it fits the way I
work.
Another point, about searchability: It would be highly useful to be able
to pick a particular ChangeLog entry and say give me the entire patch
belonging to this entry. git annotate ChangeLog would be perfect for
this purpose. But on the web interface, git annotate is unsupported,
and on the command line, git annotate ChangeLog eats up more RAM and
swap space than my machine can offer. (This is maybe why they have
excluded git annotate from the web interface...)
You will certainly say: Of course, don't use git annotate ChangeLog.
Use git log. It's much faster!
Same point here: I don't want to adapt my way of working to git. I want
git to serve me.
Bruno
Re: GNU-style ChangeLog merge driver for Git
Ben Pfaff wrote: The web interface is searchable. Type your search string into the box labeled search: and hit Enter. Click on the question mark for a description of the kinds of searches that are available. Indeed! Thanks for pointing this out. This weakens my previous arguments. No, it doesn't. You cannot do many things in a web browser, for example, you cannot use M-x occur to see how often something was changed, or just to group changes related to a single file. I do not know of a web browser that allows regexp in the search field, which is immensly useful. Then there is narrowing and widening, etc etc. Then there is the question of having to be hooked up to a network if you wish to access this information using a very poor interface.
Re: GNU-style ChangeLog merge driver for Git
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Bruno Haible on 2/11/2008 5:35 AM: | The README and installation instructions are in the source code (for now). First, a big thanks for doing this. Also, I wonder if this would be worth pushing upstream for inclusion in git proper. | | It turns out that we can put the .gitattributes into the repository: if someone | does not have the git-merge-changelog configured, it will have no effect for | him. Is there any way to automate the configuration of the merge-changelog merge engine? In other words, if a project uses the git-merge-changelog module, could gnulib-tool detect whether both a .git directory and the 'git config' tool are present, and if so, double check that 'git config - --get merge.merge-changelog.driver' and so forth are defined correctly? Also, I'm not sure this part of the module specification is wise: Makefile.am: bin_PROGRAMS = git-merge-changelog since that would mean git-merge-changelog is installed alongside every package that uses the module. Shouldn't this be a noinst target? - -- Don't work too hard, make some time for fun as well! Eric Blake [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (Cygwin) Comment: Public key at home.comcast.net/~ericblake/eblake.gpg Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHsEqL84KuGfSFAYARAsL8AKCwZD0zn6k/nktoBGQ1UIE2evAXyACgqfYh J6PH71J1ahOZ1f4aEp/sJto= =7WMO -END PGP SIGNATURE-
Re: GNU-style ChangeLog merge driver for Git
Hello Ralf, A couple of minor nits: * Bruno Haible wrote on Mon, Feb 11, 2008 at 01:15:47AM CET: bin_PROGRAMS = git-merge-changelog git_merge_changelog_LDADD = -L. -lgnu Please make this git_merge_changelog_LDADD = libgnu.a so that automake notices and adds the dependency, so that a parallel build does not fail. Done. Thanks for noticing this. /* Installation: $ gnulib-tool --create-testdir --dir=/tmp/testdir123 git-merge-changelog $ cd /tmp/testdir123 $ ./configure $ make $ make install This creates a file $prefix/share/dummy/javaversion.class Surely that 'dummy' is weird, but the file should not be needed at all, no? I cannot reproduce this. You must have an extraneous dependency to the module 'javacomp' or 'javaversion' somewhere? Bruno 2008-02-11 Bruno Haible [EMAIL PROTECTED] * modules/git-merge-changelog (Makefile.am): Don't use -L and -l for a library in the current directory: it does not work with parallel make. Reported by Ralf Wildenhues [EMAIL PROTECTED]. *** modules/git-merge-changelog.orig2008-02-12 00:09:55.0 +0100 --- modules/git-merge-changelog 2008-02-12 00:08:10.0 +0100 *** *** 24,30 Makefile.am: bin_PROGRAMS = git-merge-changelog ! git_merge_changelog_LDADD = -L. -lgnu Include: --- 24,30 Makefile.am: bin_PROGRAMS = git-merge-changelog ! git_merge_changelog_LDADD = libgnu.a Include:
Re: GNU-style ChangeLog merge driver for Git
Huh. Well, considering that the GNU Coding Guidelines specifically recommend this technique as an alternative to maintaining an actual file, I don't think it's exactly recommended; it's mentioned as an alternative, but in a rather ambiguous way (at least if we're talking about the same thing, in the Change Log Concepts node of standards.texi): Another alternative is to record change log information with a version control system such as RCS or CVS. This can be converted automatically to a `ChangeLog' file using `rcs2log'; Personally, as is somewhat implied here, I think it is highly desirable for there to be actual ChangeLog files in distributions, at least, independent of whether they are created from the vc logs. So I'm glad Jim is still doing that. For background: I believe that rms relies on ChangeLog files in his distributions for legal information. That's why the whole (tiny change) stuff exists, why the rules for who is given as the author are spelled out so precisely (Style of Change Logs), etc. In the vc logs, the person who commits the change might not be the person who wrote the change. What matters legally is who wrote it.
Re: GNU-style ChangeLog merge driver for Git
The web interface for the history is also usable without prerequisite knowledge; but it is not searchable. It is also not accessible to people without access to the big bad internet; or funky GUI tools. maintaining ChangeLogs is redundant work, when you're already entering the very same information into the versipon control system. Please place yourself at the position of the user who builds and runs a program, not the developer. If all packages have different ways of configuring the package, of showing version history, of listing the dependencies, etc. building packages for one's own use is too much of a frustrating experience. This is why a unified 'configure' invocation scheme was needed; this is also why a unified view of the version history is needed. Indeed!
Re: GNU-style ChangeLog merge driver for Git
* Bruno Haible wrote on Tue, Feb 12, 2008 at 12:13:41AM CET: This creates a file $prefix/share/dummy/javaversion.class Surely that 'dummy' is weird, but the file should not be needed at all, no? I cannot reproduce this. You must have an extraneous dependency to the module 'javacomp' or 'javaversion' somewhere? I don't know what I did there, but I cannot reproduce it now. Thanks! Cheers, Ralf
Re: GNU-style ChangeLog merge driver for Git
Micah Cowan wrote: Are you claiming that people who are capable of fetching the sources with git clone will be incapable of git log? Most of them, yes, sure. The git clone command is shown in the homepage http://www.gnu.org/software/gnulib/ and in gnulib's README. Millions of people can use it without prerequisite knowledge. The git log command OTOH is only available to people familiar with git. The web interface for the history is also usable without prerequisite knowledge; but it is not searchable. Whereas the ChangeLog can be used with just a text editor, no knowledge, and is searchable. maintaining ChangeLogs is redundant work, when you're already entering the very same information into the version control system. Please place yourself at the position of the user who builds and runs a program, not the developer. If all packages have different ways of configuring the package, of showing version history, of listing the dependencies, etc. building packages for one's own use is too much of a frustrating experience. This is why a unified 'configure' invocation scheme was needed; this is also why a unified view of the version history is needed. Bruno
GNU-style ChangeLog merge driver for Git (was: Re: [PATCH] New script and module: gitlog-to-changelog)
Jim Meyering wrote yesterday: With the proliferation of topic branches in my work-flow, it is not effective for me to version-control ChangeLog files (too many pointless conflicts). So, for projects that I control, I am transitioning away from that. ... Instead, now, I compose ChangeLog entries solely in git log messages and use the following script to generate a ChangeLog file at make dist time. So, people who now download your development version get the sources without any ChangeLog! If they are looking for the likely reason for the breakage on platform XY or of unit test foo/bar, they cannot look at and search through the version history, except if they have special tools (like gitk) _and_ are familiar with them. You are throwing a proven and helpful GNU practice overboard. This is very bad. The real problem is, as you say and as everyone noticed, the pointless conflicts at the top of the ChangeLog file. Benoit Sigoure explained that what we need to solve this problem is a git merge driver. Here is such a merge driver. It should solve the problem. The README and installation instructions are in the source code (for now). Bruno 2008-02-10 Bruno Haible [EMAIL PROTECTED] New module 'git-merge-changelog'. * modules/git-merge-changelog: New file. * lib/git-merge-changelog.c: New file. = modules/git-merge-changelog === Description: git merge driver for GNU style ChangeLog files Files: lib/git-merge-changelog.c Depends-on: getopt stdbool progname error read-file list array-list linkedhash-list linked-list xalloc xmalloca fstrcmp minmax fwriteerror configure.ac: Makefile.am: bin_PROGRAMS = git-merge-changelog git_merge_changelog_LDADD = -L. -lgnu Include: License: GPL Maintainer: Bruno Haible = lib/git-merge-changelog.c = /* git-merge-changelog - git merge driver for GNU style ChangeLog files. Copyright (C) 2008 Bruno Haible [EMAIL PROTECTED] This program is free software: you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation; either version 2 of the License, or (at your option) any later version. This program is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details. You should have received a copy of the GNU General Public License along with this program. If not, see http://www.gnu.org/licenses/. */ /* README: The default merge driver of 'git' *always* produces conflicts when pulling public modifications into a privately modified ChangeLog file. This is because ChangeLog files are always modified at the top; the default merge driver has no clue how to deal with this. Furthermore the conflicts are presented with more markers than necessary; this is because the default merge driver makes pointless effects to look at the individual line changes inside a ChangeLog entry. This program serves as a 'git' merge driver that avoids these problems. 1. It produces no conflict when ChangeLog entries have been inserted at the top both in the public and in the private modification. It puts the privately added entries above the publicly added entries. 2. It respects the structure of ChangeLog files: entries are not split into lines but kept together. 3. It also handles the case of small modifications of past ChangeLog entries, or of removed ChangeLog entries: they are merged as one would expect it. 4. Conflicts are presented at the top of the file, rather than where they occurred, so that the user will see them immediately. (Unlike for source code written in some programming language, conflict markers that are located several hundreds lines from the top will not cause any syntax error and therefore would be likely to remain unnoticed.) */ /* Installation: $ gnulib-tool --create-testdir --dir=/tmp/testdir123 git-merge-changelog $ cd /tmp/testdir123 $ ./configure $ make $ make install - Add to .git/config of the checkout (or to your $HOME/.gitconfig) the lines [merge cl-merge] name = GNU-style ChangeLog merge driver driver = /usr/local/bin/git-merge-changelog %O %A %B - In every directory that contains a ChangeLog file, add a file '.gitattributes' with this line: ChangeLogmerge=cl-merge (See man 5 gitattributes for more info.) */ /* Calling convention: A merge driver is called with three filename arguments: 1. %O = The common ancestor of %A and %B. 2. %A = The file's contents from the current branch. 3. %B = The file's contents from the other branch; this is the contents being merged
Re: GNU-style ChangeLog merge driver for Git
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Bruno Haible wrote: Jim Meyering wrote yesterday: With the proliferation of topic branches in my work-flow, it is not effective for me to version-control ChangeLog files (too many pointless conflicts). So, for projects that I control, I am transitioning away from that. ... Instead, now, I compose ChangeLog entries solely in git log messages and use the following script to generate a ChangeLog file at make dist time. So, people who now download your development version get the sources without any ChangeLog! If they are looking for the likely reason for the breakage on platform XY or of unit test foo/bar, they cannot look at and search through the version history, except if they have special tools (like gitk) _and_ are familiar with them. You are throwing a proven and helpful GNU practice overboard. This is very bad. Huh. Well, considering that the GNU Coding Guidelines specifically recommend this technique as an alternative to maintaining an actual file, I believe you may be exaggerating a bit. Are you claiming that people who are capable of fetching the sources with git clone will be incapable of git log? Why do you believe that gitk is necessary? Even if it's so, it is common practice (and I believe both coreutils and gnulib bear this out quite well) to expect more of people fetching the development sources (at the very least, possession of recent, or sometimes even ultra-recent, autoconf, automake, etc). In my (admittedly narrow) experience, ever since the advent and widespread use of version control services, the practical usefulness of ChangeLog files have been next to nil compared with the facilities the versioning system itself. I never consult the ChangeLogs when I have access to the repository, with the notable exception of entries that predate the use of an SCM. Even aside from merge problems (for which, thanks for the script, BTW: I may adapt something similar for Wget's Mercurial repos), maintaining ChangeLogs is redundant work, when you're already entering the very same information into the version control system. Wget will probably continue to use checked-in ChangeLog files for some time, partly because we have several different ChangeLog files for various directories, which complicates things more than I want to bother with at this point in time; but we certainly may consider abandoning them in favor of generated entries, in the future, and I certainly don't see reason to fault others for choosing that way. - -- Micah J. Cowan Programmer, musician, typesetting enthusiast, gamer... http://micah.cowan.name/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHr5hz7M8hyUobTrERArAhAJ0UkFtRpIBTFA2H02KhjHWBGP/HlQCfcPuR gFQGRHTc43jP1qkB4PG0oVQ= =UcOA -END PGP SIGNATURE-
Re: GNU-style ChangeLog merge driver for Git
Bruno Haible [EMAIL PROTECTED] writes: The web interface for the history is also usable without prerequisite knowledge; but it is not searchable. The web interface is searchable. Type your search string into the box labeled search: and hit Enter. Click on the question mark for a description of the kinds of searches that are available. -- If a person keeps faithfully busy each hour of the working day, he can count on waking up some morning to find himself one of the competent ones of his generation. --William James
Re: GNU-style ChangeLog merge driver for Git
On Sunday 10 February 2008, Bruno Haible wrote: Micah Cowan wrote: Are you claiming that people who are capable of fetching the sources with git clone will be incapable of git log? Most of them, yes, sure. The git clone command is shown in the homepage http://www.gnu.org/software/gnulib/ and in gnulib's README. Millions of people can use it without prerequisite knowledge. The git log command OTOH is only available to people familiar with git. `git log` is no more foreign than any other scm log. you could even check in a small ChangeLog that merely reads this is generated automatically; please use `git log`. maintaining ChangeLogs is redundant work, when you're already entering the very same information into the version control system. Please place yourself at the position of the user who builds and runs a program, not the developer. If all packages have different ways of configuring the package, of showing version history, of listing the dependencies, etc. building packages for one's own use is too much of a frustrating experience. This is why a unified 'configure' invocation scheme was needed; this is also why a unified view of the version history is needed. how is the user's position relevant ? users will not be using gnulib, developers will. it is unrealistic to think a developer will be unfamiliar with a scm log function but capable of leveraging gnulib. -mike signature.asc Description: This is a digitally signed message part.
Re: GNU-style ChangeLog merge driver for Git
Hello Bruno, * Bruno Haible wrote on Mon, Feb 11, 2008 at 01:15:47AM CET: 2008-02-10 Bruno Haible [EMAIL PROTECTED] New module 'git-merge-changelog'. * modules/git-merge-changelog: New file. * lib/git-merge-changelog.c: New file. *Thank* *you* for this, and to Jim and Benoit for getting this ball rolling! I haven't tested it yet, but I will. Cheers, Ralf
GNU-style ChangeLog merge driver for Git (was: Re: git: avoiding merges, rebasing)
On Oct 9, 2007, at 2:03 PM, Bruno Haible wrote: Hello Benoit, Thanks for working on this. But this merge driver has a few major nits. 1) While my ChangeLog file was locally unmodified but some pulled in commits should modify it, git pull stopped and said: ChangeLog: needs update fatal: Entry 'ChangeLog' not uptodate. Cannot merge. [I cannot swear on this, because I did not do a git status before the git pull, but this is in a directory where I usually have no pending diffs.] I'll check but I'm afraid that Git bails out before actually trying the merge driver. The ChangeLog in question is the one from gnulib (git clone git://git.sv.gnu.org/gnulib). 2) This merge driver did much more than sorting in a merge: it sorted the entire file! In doing so, - It changed the order of ChangeLog entries in a way that does not represent the historical commit order. - For ChangeLog entries with multiple contributors, it shuffled around these extra contributors to other ChangeLog entries. - Near the end of the file, it made a change that I cannot explain. Find attached a context diff of all the bad changes that it did. Yes, it's pretty stupid, I hacked this in a hurry. I'll try to improve it so that it doesn't have these undesired side-effects. In my opinion, a merge driver should not do changes to the file except in the range of lines where the conflict occurred. For a ChangeLog driver, all uncommitted entries should be collected at the top of the file, because 1. ChangeLogs are kept in the order of historical commit in the central repository, 2. other developers always look at the top of the ChangeLog; if a ChangeLog entries is inserted second or third after some already present entries, the danger is too high that the change gets unnoticed. So git-merge-changelog OLD CURRENT OTHERS should IMO do the following: 1) Collect the changes between OLD and HEAD (I don't know if that is CURRENT or OTHERS?), in two categories: - added entries, - changed and removed entries. 2) Back out the added entries, keeping only the changed and removed entries as modifications. 3) Do a normal merge between this and the pulled in remote branch (I don't know if that is OTHERS or CURRENT?). If that merge gives a conflict, bail out. 4) Insert the added entries at the top, in the same order as they were originally (no sorting). Bruno git-merge-changelog-blunder OK I'll try to rework the driver so that it implements this. It will take some time though, I'm quite busy these days. Akim Demaille would also like it to squash the commits added by the merge (the new commits in OTHERS): -MM-DD Author [EMAIL PROTECTED] Merge whatever: -MM-DD Someone Else [EMAIL PROTECTED] Some change. * FileChanged.c: Whatever. -MM-DD Who Cares [EMAIL PROTECTED] Some other change. * OtherFile.c: Do it. I thought this was mandated by the GNU Coding Standards but I checked, it doesn't say anything about merges. Would this sort of strategy be useful to you? Should it be default (or enabled by some --squash option)? Cheers, -- Benoit Sigoure aka Tsuna EPITA Research and Development Laboratory PGP.sig Description: This is a digitally signed message part
Re: GNU-style ChangeLog merge driver for Git
Hello Benoit, Akim Demaille would also like it to squash the commits added by the merge (the new commits in OTHERS): -MM-DD Author [EMAIL PROTECTED] Merge whatever: -MM-DD Someone Else [EMAIL PROTECTED] Some change. * FileChanged.c: Whatever. -MM-DD Who Cares [EMAIL PROTECTED] Some other change. * OtherFile.c: Do it. I thought this was mandated by the GNU Coding Standards but I checked, it doesn't say anything about merges. Would this sort of strategy be useful to you? Should it be default (or enabled by some --squash option)? This merge is occurring in a different situation: The situation where we need ChangeLog merging most often is when a developer has made changes on his own and pulls in the changes from the remote repository (via git stash; git pull; git stash apply). The situation that Akim is describing is that he pulls changes from the repository of Someone Else and Who Cares, and then pushes them into the central repository, under his responsibility. For the first situation, the non-remote ChangeLog entries should be moved to the top, without modification or indentation. For the second situation, three different styles are in use at GNU (because they don't use Signed-off lines): 1) unmodified copying of the ChangeLog entries: -MM-DD Someone Else [EMAIL PROTECTED] Some change. * FileChanged.c: Whatever. -MM-DD Who Cares [EMAIL PROTECTED] Some other change. * OtherFile.c: Do it. 2) copying with lieutenant's email address, like Akim described it: -MM-DD Lieu Tenant [EMAIL PROTECTED] -MM-DD Someone Else [EMAIL PROTECTED] Some change. * FileChanged.c: Whatever. -MM-DD Who Cares [EMAIL PROTECTED] Some other change. * OtherFile.c: Do it. 3) similar, but with indentation of the entire copied-in ChangeLog entries: -MM-DD Lieu Tenant [EMAIL PROTECTED] -MM-DD Someone Else [EMAIL PROTECTED] Some change. * FileChanged.c: Whatever. -MM-DD Who Cares [EMAIL PROTECTED] Some other change. * OtherFile.c: Do it. First of all, your merge driver could try to guess whether we're in the first or second situation (maybe by testing whether the names in the ChangeLog entry match the [user]name from the git config). Then, for the second situation, there can be some flag in the driver or in the git config that describes which of the 3 styles to apply. Bruno
