Hi Sebastien,
Sebastien Chavaux <seb95.scou@gmail.com> writes:
>
> Thank you first of all. So it's not that I don't want to maintain git /
> salsa, it's that I'm not comfortable with it, should do a remedial course
> on it.
>
I also found git hard to start out with. The first thing I noticed that
all documentation seemed to omit was how important it is to set EDITOR
in ~/.bashrc.
Beyond that, here are the three approaches I took:
1. Keep it simple, and use debcommit. With this approach I assume
whole-repository granularity. Note that one pitfall with this method is
that you may need to manually run "git status", "git add ./", and "git
remove list of files". "git add ./" will also add backup-files~, which
is annoying. To be fair, debcommit+git does support more a more
fine-grained staging and committing workflow, but I never really got
comfortable with it. One significant advantage to this approach is that
it encourages objective-driven development. eg: your "* changelog
entry for foo" can be seen as your goal; then you work to accomplish
your goal.
* uscan
* dch -v1.0.1
# Make any change, even as simple as <space> <backspace>, then save
and exit
* debcommit -a
# This "opens a new changelog entry" in git history
[a]* Attempt a build
* If it fails, make changes
* dch
# Document the purpose of your changes, save, and exit
* debcommit -a
... cycle back to [a]
and so on... Eventually "dch -r", commit, and tag.
2. git-buildpackage a bit more difficult, but still fairly easy to use,
and optionally enables a the opposite workflow, where the changelog is
generated from commit messages. When this was my primary approach I
manually ran git commands as necessary.
3. Learn to use Magit to exploit the full power of git staging,
reverting, rebasing, 3-way diffing during conflicts, etc. This is now
my preferred approach, because it enables one to do all the work at
once, then quickly stage specific groups of files and lines from files
(such as changelog) into atomic, self-contained commits. Getting
comfortable with this approach requires getting comfortable with Emacs,
which might not be something you're interested in. For what it's worth,
I was initially skeptical, but after a few months found it totally
worthwhile.
Whatever approach you end up taking, I hope you'll one day have an
empowering "Aha!" moment when you realise that your work wasn't wiped
out by a hasty "git reset --hard committish". eg:
https://stackoverflow.com/questions/5473/how-can-i-undo-git-reset-hard-head1
Beyond this, it's a bit annoying to have to locally delete a release tag
if your mentor asks for revisions; this includes updating the changelog,
committing, rerunning "dch -r", committing, and retagging.
> I will see how to define the same list of architectures as qtwebengine5. I
> watch this and do it after work.
>
This sounds like a good approach to me :-)
Cheers,
Nicholas
Attachment:
signature.asc
Description: PGP signature