Re: Triggers status?
Raphael Hertzog writes ("Re: Triggers status?"):
> When there are good reasons, I'm happy to let anyone ignore my
> suggestions. But in this case, given that Ian is just learning git
> usage I believe that most of the things listed are consequences of
> errors / lack of knowledge rather than deliberate choices.
I made a deliberate choice to publish my triggers work as a branch
that could be merged in both directions.
That was necessary to facilitate merging changes from Debian into the
Ubuntu version. It enabled me to make my further substantial changes
for my flex experiment based on code that wasn't going to be radically
revised. It meant I could merge fixes from the trunk into the
triggers branch, and then into the flex branch, or just into the flex
branch if I wanted just to work on that at a particular time, without
undue difficulty. (By undue difficulty I mean without imposing undue
work on a human, for example by generating spurious conflicts on
merging or requiring a particular conflict to be resolved twice.) It
meant that I could publish triggers, and my flex experiment, in a way
that means that other people can edit their own versions and
contribute aappropriate.
I was able to do all of these things straightforwardly and with a
minimum of fuss, once I'd got used to git's slightly odd terminology
and the usual initial kind of minor stumbling block with a new tool.
The only problem seems to me that you are objecting to this mode of
interaction. Can you please explain what is lost by my approach ?
> If this is a deliberate choice, then why not. But I believe this is just
> the result of not having set up the user.name and user.email git
> configuration items...
No, it's due to a bug in the Debian git package, which should have
acquired my email address in the standard way. In that case it would
have used a correct address.
> Well, plain "git rebase" compared to "git merge" only avoids (possibly
> repeated) merge commits. It doesn't change contents of the patches and
> doesn't changes author dates / emails.
AIUI git rebase also prevents repeated merging backwards and forwards
between different branches.
> Many git tools rely on this convention to offer differing short/long view
> of changesets. So I don't like when the first line of the commit log is:
> "dpkg (1.14.5ubuntu16) gutsy; urgency=low"
I agree that this is unhelpful. I can't remember why I didn't use
debcommit at that point but I'm using it nowadays and I'm happy to
continue doing so.
Is there really merit in going back and fixing old commit log entries ?
> Then you're right, it looses history, so it's not required to proceed that
> way. But in many cases, it can ease the review because you'll present your
> change as a coherent serie of patches:
> - logical change 1
> - logical change 2
> - logical change 3
The actual triggers functionality isn't sensibly divisible in this way
and the individual bugfixes which I've made at the same time are too
trivial to care about in this way.
> Sure, patches are perfectly fine.
If I were to supply patches and you were to apply them, my flex branch
would be completely messed up, wouldn't it ? Next time I wanted to do
a merge it would try to apply another copy of the triggers changes.
The whole point of using a drcs is to avoid that kind of thing.
> I wish we could have a quicker review/integration cycle. But submitting a
> git branch in the form that Ian used doesn't help much unless you follow
> the conventions of the team.
I don't understand how presenting it as a git branch can be inferior
to presenting it as a patch.
For the purposes of review, git can tell you exactly what the changes
are. The difference is that if you merge from my branch, my other
branches don't get trashed.
Ian.
Reply to: