[webkit-dev] WebKit Transition to Git

[Adrien Destugues]

> 3. Changelog
> I don’t feel it's a big problem to write ChangeLog file.
> Of course, this is tired thing but I don’t have a strong alternative
> after reading this thread.
> 
> However the current `prepare-Changelog` script does not fit with a
> branch -based workflow on Git, I feel. There is a room to polish on
> this Git migration.
> 
> For example, I’d like to specify a branch as my working set in my
> local machine, instead of commit or staged changes.
> 
> Ordinary, I do these flows but it’s a bit tired…. (if you know more
> good ways, could you tell me!):
> 
> 1. Run `prepare-Changelog`
> 2. Format ChangeLog file and remove duplicated entries added by _steps 1_.
> 3. Fuse new changes into a single patch by `git add . && git commit
> --ammend` or `git commit --fixup HEAD && git rebase master -i
> --autosquash`
> 4. Upload patches by `webkit-patch upload -g HEAD`
> 
> I don’t have an objection that we merge a squashed patch into trunk to
> simplify the history but we would have some chance to improve the script.
> 

The original goal mentionned at the start of the thread was encouraging
more people to contribute to WebKit. From that side, what's important is
trying to retain a patch submission workflow that's standardized. That can
be github/gitlab style pull requests, or Gerrit which is a different one.
There are probably others.

If the workflow for submitting patches requires writing a changelog file,
or other similar custom operations, I think that's more likely to turn
potential contributors away (I can only speak for myself, here, of course).
Even if you automate it with a script, people will have to remember to
use the script. Then it doesn't matter if you use Git or Github or some
other tool under the hood: the patch submission process is a custom one.

Starting from there, the question is more:

Which of these existing workflows is more suitable?

How much can we tweak them (with bots on Github, plugins
on Gerrit, or pre-commit/pre-push hooks on developer machines, for example)
to make them better fit the existing things that will probably be kept?
(I guess Apple internal bugtracker, possibly bugzilla as well, maybe some
parts of the existing build infrastructure and builder machines?).

Can these changes to the workflow be done and documented so that existing
Git (and Github/Gitlab/Gerrit/...) users can handle them easily?

-- 
Adrien.