This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: reject merges on gdb release branches?
- From: Eli Zaretskii <eliz at gnu dot org>
- To: Joel Brobecker <brobecker at adacore dot com>
- Cc: ricard dot wanderlof at axis dot com, gdb-patches at sourceware dot org
- Date: Fri, 24 Jan 2014 10:54:52 +0200
- Subject: Re: reject merges on gdb release branches?
- Authentication-results: sourceware.org; auth=none
- References: <20140122051133 dot GB4762 at adacore dot com> <83r480f2r2 dot fsf at gnu dot org> <20140122161520 dot GF4762 at adacore dot com> <83bnz4ezst dot fsf at gnu dot org> <alpine dot DEB dot 2 dot 00 dot 1401230838060 dot 24884 at lnxricardw dot se dot axis dot com> <83wqhqekpp dot fsf at gnu dot org> <alpine dot DEB dot 2 dot 00 dot 1401240833360 dot 24884 at lnxricardw dot se dot axis dot com> <83ha8tersb dot fsf at gnu dot org> <20140124080703 dot GL4762 at adacore dot com>
- Reply-to: Eli Zaretskii <eliz at gnu dot org>
> Date: Fri, 24 Jan 2014 12:07:03 +0400
> From: Joel Brobecker <brobecker@adacore.com>
> Cc: Ricard Wanderlof <ricard.wanderlof@axis.com>,
> gdb-patches@sourceware.org
>
> I think we cannot expect all our contributors to know git well, and
> for those who don't have a good command of that tool, branch merges
> are more difficult to understand than simple commits.
But this sounds backwards. Merging from a branch is a single git
command, while rebasing requires much more, and requires also
understanding of what rebasing means and does. We are actually
requiring contributors to know more of git, not less.
Also, isn't git popularity enough for us to not be afraid so much?
In any case, if we fear mistakes by git newbies, why not have a Wiki
page that explains the recommended workflow and commands, and point
contributors to that when they get write access.
> Rejecting merges makes sure that the history remains linear.
This is a strange argument: if we want linear history, why did we
switch to git at all? dVCS make very little sense, if we want linear
history. What am I missing?
> I still do not understand what the problem is with rebasing though.
> You said "loss of information". Can you explain a bit more?
The non-linear parts of the development history are deleted. You can
no longer tell which other branches contributed to a particular
commit. For example, if a bug happened because you merged from master
half way through feature development, you can no longer see that
merge. This is an important part of the development history, and is
sometimes invaluable when reflecting on past experience or analyzing
bugs. I don't see why we should force everyone lose it.
In effect, rebasing is tantamount to preparing diffs, then applying
those diffs on the tip of the master branch: you keep all the textual
changes, but lose the DAG of the flow that led to them.
Again, if we don't care at all about all this, why did we switch to
git? It sounds like we want a strictly centralized development, which
means about 99% of power of git (or any dVCS, actually) is left off
limits for us. Is that really the intent?