Hi Volker,
On 2014-12-21, Volker Braun <[email protected]> wrote:
> On Sunday, December 21, 2014 11:41:42 AM UTC+1, Nathann Cohen wrote:
>>
>> Really, I did work with 4+ tickets in linear order. If you add a
>> commit to the first one that's 1+2+3+4=10 merge commits that appears
>> on Sage's tickets. Now do that twice, and look at your branches.
>>
>
> Do not do it, then. Not every commit to the first ticket needs to be
> propagated to every other branch.
In reality, it is needed. Actually that's what is happening to me right
now, and so I'd like to elaborate on it a bit more.
I have a neatly ordered sequence of trac tickets, each implementing a
single thing, thus avoiding patch bombs: One implements sequences of
bounded integers, the next implements quiver paths based on sequences
of bounded integers, the next implements path algebra elements, and I
would really like to finally implement an f5 algorithm for modules over
path algebras. Reasonable approach, I'd say.
The f5 branch is not published yet, hence, here I work with rebase. All
other branches are on trac, and here I work with merge.
What is hampering me is the need to repeatedly resolve conflicts
which---I can't avoid to have that impression!---are nothing but git
artefacts.
Concretely, someone found that a certain boilerplate function for sequences
of bounded integers should better have a different name. I am using that
function in all subsequent tickets, and hence I *do* need to propagate it
to every other branch.
Now, for whatever reason, git is neither able to merge develop into my
work branch nor the other way around. Hence, I do "git mergetool"---and
see merge conflicts that I have worked on before (and yes, I have git
rerere enabled). Unfortunately, because of some totally unrelated
problems (build errors with maxima, which is a program I really don't
need for my work), I *do* need to get recent commits from develop into
my work branch. Otherwise, I cannot compile Sage and thus cannot develop
my own code further.
Just to confirm: Would you say that in both situation described above
(bidirectional conflicts with develop, changed function names), merge
commits are needed?
What I keep finding annoying with git is that the fixes to maxima spkg
and everything else that is in recent commits of the develop branch
become part of my work branch and are considered to be part of *my*
commit history, although they have nothing to do with my work. And
because of the "do-not-change-history" mantra, I now need to take care
about commit history for parts of code that I have never even looked at.
Just to give you an example: I have now successfully merged the latest
commits of #15820 (bounded integer sequences) into #16453 (quiver paths)
and into #17435 (path algebra elements). I had to resolve conflicts in
src/data_structures/bounded_integer_sequences.pyx, which is no suprise
of course---only that I actually had resolved the conflicts before. It
is now all nice, develop does merge cleanly into it.
So. All conflicts and all new code should be confined in
src/sage/data_structures and src/sage/quivers, right? Now, I am rebasing
my private branch for the f5 algorithm. on top of #17435, aiming to at least
temporarily merge the develop branch into the f5 branch after the
rebase.
The f5 branch touches files in src/sage/quivers and src/module_list.py
Would anybody with a sane mind would expect that "git rebase" shows
conflicts in different locations?
In fact, I get this:
> git checkout f5_for_basic_algebras
Zu Branch 'f5_for_basic_algebras' gewechselt
> git rebase t/17435/cythonise_path_algebra_elements
Zunächst wird der Branch zurückgespult, um Ihre Änderungen
darauf neu anzuwenden...
Wende an: Experiment with moving the indexes around and toward the
source tree
Verwende Informationen aus der Staging-Area, um einen Basisverzeichnis
nachzustellen
M src/doc/en/reference/combinat/index.rst
Falle zurück zum Patchen der Basis und des 3-Wege-Merges...
automatischer Merge von src/doc/en/reference/combinat/index.rst
KONFLIKT (Inhalt): Merge-Konflikt in
src/doc/en/reference/combinat/index.rst
automatischer Merge von
src/doc/en/reference/combinat/algebraic_combinatorics.rst
Recorded preimage for 'src/doc/en/reference/combinat/index.rst'
Merge der Änderungen fehlgeschlagen
Anwendung des Patches fehlgeschlagen bei 0001 Experiment with moving
the indexes around and toward the source tree
Die Kopie des fehlgeschlagenen Patches befindet sich in:
/home/king/Sage/git/sage/.git/rebase-apply/patch
##################
WTF?? There is a conflict with some commit that I never ever heard of,
in the file src/doc/en/reference/combinat/index.rst, which is totally
disjoint to my work!!!
I am really tired of these repeated git annoyances. Is there really no
version control system that neatly keeps apart chunks of work, so that
the only reason for merge conflicts occur when two chunks of work touch
the same files? Is git really not able to understand that I haven't
touched src/doc/.../combinat/index.rst and it should just leave it in
whatever state it was?
Best regards,
Simon
--
You received this message because you are subscribed to the Google Groups
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.
