This is the mail archive of the
archer@sourceware.org
mailing list for the Archer project.
Re: [Archer] Merging lessons
[I was on vacation, so I'm late in this discussion...]
El jue, 15-01-2009 a las 17:38 -0700, Tom Tromey escribiÃ:
> >>>>> "Joel" == Joel Brobecker <brobecker@adacore.com> writes:
>
> >> 3) We need some policy on ChangeLogs.
> >>
> >> I haven't seen a ChangeLog merge yet that went smoothly. Using git
> >> to "attempt" to merge
> >> the files produces a file that is most painful to merge.
>
> Joel> What we do at AdaCore is use our own ChangeLog file (ChangeLog.GNAT
> Joel> FWIW). Similarly, when I work on my own personal branch, I sometimes
> Joel> use my own ChangeLog file called whatever. However, now that I'm using
> Joel> git more and more often, I've found the use of ChangeLogs to simply
> Joel> be redundant and limitative - I just put the ChangeLog entry as my
> Joel> revision history, and git is fast enough to produce a "ChangeLog"
> Joel> on the fly... This worked really well for me while I was trying
> Joel> to contribute the changes for 64bit Windows.
>
> We should pick one of these and go with it.
>
> At the moment I don't think I have a preference. My main concerns are
> that we have decent change logging, and that we reduce the pain of
> merging. Either of these seems to fit the bill.
>
> Someone want to make a proposal?
+1000 for Joel's idea of putting the ChangeLog entry in the commit
message.
I rebase, cherry-pick, reorder and rewrite my commits very often, to
create patches for upstream submission and to organize my work before
pushing to the python branch. Every single time I do that, I have to
solve a conflict in a ChangeLog file. Not having to clean such mess
would definitely make my life simpler.
It's easy enough to collect the relevant changelog entries from the
commit messages when producing a patch for upstream.
--
[]'s
Thiago Jung Bauermann
IBM Linux Technology Center