Re: [gnome-flashback] New branch 'gnome-applets'
- From: Philipp Kaluza <floss ghostroute eu>
- To: Mailing list for the Gnome Flashback project <gnome-flashback-list gnome org>
- Subject: Re: [gnome-flashback] New branch 'gnome-applets'
- Date: Tue, 27 May 2014 13:09:18 +0200
Hi Alberts,
Am 27.05.2014 08:45, schrieb Alberts Muktupāvels:
I don't get what exactly is wrong with my branch...
You just added a "code drop" in two commits, instead of taking advantage
of the rich history data that we have.
My branch log:
https://git.gnome.org/browse/gnome-panel/log/?h=gnome-applets
(-4666/+689381)
Your branch log:
https://git.gnome.org/browse/gnome-panel/log/?h=features/merge-gnome-applets
(-2/+722195)
1. In both cases there are no history for applets.
You are mistaken. Check with "gitk --all" or "git blame"
2. What was point of copying HACKING, NEWS, autogen.sh other files too?
They were in gnome-applet's master branch, and moved down to applets/ by
the git subtree merge. Can be merged probably, or left in the subdir,
depending on each file.
3. Why would I do exactly same work again?
You wouldn't, we just need to rebase your work. I assumed you'd be
willing to do that yourself, because you know which files you edited, so
nothing gets lost. But never mind, Lanoxx did it already.
[...]
If someone need history of gnome-applets than he could go to
https://git.gnome.org/browse/gnome-applets/ and get it.
No, that is not a solution, because any automated tools (and most
visitors) will not know to look there, or how the two histories are
related exactly. A merge commit makes that clear.
_If_ we commit to carrying all the applets in gnome panel - and I feel
that discussion needs to happen here in more detail, when we have
something to look at - we'll need the history.
My branch contains extra work so it compiles and are in working state
where yours are just simply everything copied into applets dir.
Exactly. I didn't program anything here (why would I redo your work ?),
I showed you the way on how to prepare such a merge feature branch
correctly, so we can even consider it.
P.S. What is NAK?
"Not ACKnowledged", i.e. "I am not OK with the state of this patch /
branch".
Like I just wrote to Lanoxx:
I pushed features/tmp/merge-gnome-applets-rebase as an example /
teachable moment branch.
[...]
but it's still not in a shape I would
would like to have in the permanent history, as some files are still
copied instead of moved.
I will ask Alberts to split d758665 up in a better way.
So, using features/tmp/merge-gnome-applets-rebase as a base (which does
not have the line ending changes your branch had, but which would be
completely inappropriate in a merge branch), could you try to split up
your work into more sensible / reviewable patches ? I would at least
like to see:
* one patch doing only the build fixups (Makefile.am, configure.ac),
with a /proper commit message/ that explains any path changes (like
linking libpanel-applet in-tree now)
* one patch doing the documenting files (like AUTHORS), with /proper
commit message/
* one patch moving the manpages, and integrating into build system
* one patch doing the merge of the po files, and removing the ones under
applets/po/.
For starters, look at "git rebase -i" (specifically the SPLITTING
COMMITS section in the git-rebase man page).
git checkout features/merge-gnome-applets
git rebase -i features/tmp/merge-gnome-applets-rebase
should get you started then.
Cheers
Philipp
--
Philipp Kaluza
Ghostroute IT Consulting
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]