Re: RFC: i18n: drop KUIT tags in KDE Frameworks 5.0?
On Thu, Mar 22, 2012 at 11:25 AM, Chusslove Illich caslav.i...@gmx.net wrote: Only 0.56% of all messages (1144 out of 200,000) contain any [KUIT tags]. I'm missing one point in this statistic: How big would the percentage be if KUIT was used in every relevant string? I suspect that most translated strings are static captions on widgets and in actions. KUIT is irrelevant here because of its very nature. Greetings Stefan
kdegames looking for a QML-experienced mentor
Hi, on kde-games-devel, we got a lot of interest in a GSoC 2012 idea that's about porting a game to QML/Quick1. We want this on one hand as a template for further QML-based games, but on the other hand, it shall most importantly reveal where we have to adjust libkdegames towards more QML-friendliness. (The ABI breakage of Qt 5.0 is the perfect opportunity for this.) Unfortunately, I will not be able to mentor a project based on this idea. I will be available for co-mentoring to handle libkdegames-specific questions, but we need a mentor who is especially experienced in QML/Quick1, e.g. someone from the Plasma team. Please write to me or kde-games-devel@ if you're interested, and feel free to forward this mail as required. Greetings Stefan
Re: bugzilla situation
On Wed, Feb 22, 2012 at 4:11 PM, David Faure fa...@kde.org wrote: give rights to everyone, and remove rights when someone abuses them. This is also what we do for SVN/GIT, so why don't we do this for bugzilla? Presuming people are innocent upfront, rather than guilty What we do for SVN/Git is to give rights not to everyone, but to everyone who cares to ask. A certain very low barrier may help to keep out people who intend to act in the heat of the moment. Plus new SCM accounts need a supporter. Greetings Stefan
Re: nepomuk restarting
bugs.kde.org? Greetings Stefan
Module layout proposal: Split kdegames-data from kdegames
[CC kde-scm-interest for notification only]
[CC kde-buildsystem for feedback on the proposed build system changes]
[CC kde-packagers for feedback on the implied changes to package layouts]
[@CC: please keep discussion on k-c-d and k-g-d only]
Moin moin,
EXECUTIVE SUMMARY
I propose to move the data files from the kdegames module into a new
kdegames-data module to
1. facilitate the move of the remaining source code to Git (while a
method of storing binary data files in Git efficiently is still being
worked on) and
2. enable developers to fetch and compile the kdegames source without
having to download the data files again.
DETAILED PROPOSAL
kdegames is among the few modules that have not yet switched to Git.
The main concern is that the kdegames source tree contains tons [1] of
binary data files, which Git is known not to handle well. All
discussions about moving to Git (on scm-interest and games-devel) have
just let to bikeshedding about how to handle the binary files with
git. I propose to postpone this specific problem and move on with the
Git transition *now*, especially since the solution I want to propose
has added benefit.
I propose to split a new module kdegames-data from kdegames, meaning that:
1. kdegames-data should be built and installed before kdegames.
2. Any kdegames application will refuse to start when the
corresponding data files have not been installed.
Number 2 is a protective measure because, currently, about all games
won't run correctly or look utterly broken without proper indication
of the problem.
If this proposal is implemented, the kdegames module, that is: the
source code, can move to Git without worrying about the data files.
These can move at any later point in time, when a wise solution has
been worked out by our Git specialists. I'll repeat to get this clear:
I'm not proposing to let the data stay in SVN forever. What I want is
to disentangle the fates of the source code and the data files, for
the benefit of both.
The added benefit of this solution is that distributions will be
encouraged to package data files separately. Because this data (and
esp. its format) changes very seldomly only, developers will not need
to checkout this giant mass of data from our SCM servers, but can
instead use the packages provided by their distribution. The same
holds true for drive-by contributors: They only have to clone a tiny
repo containing the source code of the game which they want to hack
on, without fetching megabytes of data files which they already had
installed.
If this proposal is accepted not later than by the end of next week, I
will be able to implement the following changes before the soft
feature freeze (Thu, October 27):
1. Create the new module in SVN, move data files from the current
kdegames module. The toplevel directory is still divided by
applications, of course.
2. Setup the buildsystem for kdegames-data using
macro_optional_add_subdirectory() as in kdegames, so that data can be
selected for installation on a per-application basis. Each set of
application data will additionally install an empty marker file which
indicates that data is available for this application (something like
${DATA_INSTALL_DIR}/${APP}/hasdata; please suggest better schemes if
there are).
My roadmap also includes the following changes to be implemented
before the hard feature freeze (Thu, November 10):
3. Adjust the buildsystem of kdegames to exclude applications from
compilation when required data files are missing. The exclusion can be
overridden by a documented CMake switch. This is consistent with how
other runtime dependencies of kdegames are handled (see
kdegames/kajongg/CMakeLists.txt).
4. Make all applications abort with a visible warning when data files
are missing.
In both cases, data files are missing is detected by checking for
the existence of the marker files installed by kdegames-data (see
point 2). If a developer for some reason wants to use the application
without the data files, he can do so by touching the marker file
manually.
As has been said before, if there are no objections, I would like to
implement this proposal starting from the end of next week (Sat,
October 22), to make sure that the required changes get into 4.8.
Greetings
Stefan
[1]
$ find -type f -regextype posix-egrep -regex
'.*\.(wav|ogg|svg|svgz|jpg|png)' | xargs du -hsc | grep total
86M total
$ du -hsc (*~(.svn|.git)) | grep total
113M total
The latter uses zsh extended glob: (*~(.svn|.git)) matches everything
except .svn or .git
Re: Module layout proposal: Split kdegames-data from kdegames
On Fri, Oct 14, 2011 at 9:30 PM, Alexander Neundorf neund...@kde.org wrote:
IMO today with usually broadband internet access this shouldn't be much of a
concern (especially if these files change only rarely).
For all games, the data contributes 400 MB of uncompressable history.
(I think that's the number, although it would be nice if someone who
already ran the kdegames svn2git rules could confirm this.)
And no, broadband internet access is not yet ubiquituous. Even here in
Germany, there is a non-negligible percentage of people on less than 1
MBit/s (sometimes much less). Also, broadband internet access is in a
non-negligible number of cases over UMTS and thus limited by volume
plans, so also the raw download volume matters very much in a lot of
cases.
The same
holds true for drive-by contributors: They only have to clone a tiny
repo containing the source code of the game which they want to hack
on, without fetching megabytes of data files which they already had
installed.
Personally I'd say who cares. At least I don't check anymore how big a
checkout will be before doing the checkout.
I vote for splitting the data not because I want to save some
bandwidth. It's because we got numerous complaints with the initial
plan to include the data in the Git repos. Among others, I
specifically remember Aaron caring about drive-by contributors.
I'm not sure I really like this.
The general trend is to split per-application, so there would be e.g. one
repository kolf and one for ksquares.
If data/ goes into one separate repository, this will make it harder once the
sources are split into multiple repositories.
Either each small game would depend on all data files, or each small game
would consist of two packages, one for the data and one for the actual
program.
Or will packager take care of this and create nice packages ?
Yes, the plan is that each game should be split into two packages.
I've consciously included kde-packagers@ for their feedback on this
plan. My humble impression is that package dependency solvers are fast
enough nowadays to handle multiple packages even for small apps.
Each game depends on its data files only. That's why each set of data
(per application) shall create its own marker file.
macro_optional_add_subdirectory ensures that partial SVN checkouts
continue to work for cases where the developer needs a more current
version of his specific data files.
2. Setup the buildsystem for kdegames-data using
macro_optional_add_subdirectory() as in kdegames, so that data can be
selected for installation on a per-application basis. Each set of
application data will additionally install an empty marker file which
indicates that data is available for this application (something like
${DATA_INSTALL_DIR}/${APP}/hasdata; please suggest better schemes if
there are).
Would it be possible to simply check whether the directory exists ?
${DATA_INSTALL_DIR}/${APP}/Data/ or something like this ?
When I checked last time, directories were not cleaned up correctly by
the uninstall target.
Hmm, not sure.
I'd prefer if it would also build when the data files are not present (since
they are not required for building).
It would be possible to build, but it would require a flag. This is
what packagers want to do (since they probably build kdegames-data
separately), but for the random user, I want to make it obvious that
something's wrong by not compiling about everything.
Greetings
Stefan
Re: The future of Power Management - together with Activities
On Sun, Oct 2, 2011 at 7:32 PM, Dario Freddi drf54...@gmail.com wrote: I will conclude the argument by saying that the skepticals can now check out, in kde-workspace, my branch dafre/new- powerdevil, which is implementing everything I said (new applet, new profile handling) except for activities, which hopefully will be coming this week. You can see with your own eyes you can still tweak everything you could tweak before. And the UI finally looks good. Could someone with a build of that please post some screenshots, for those of us how take power management seriously by not letting their computer stay up all night building kde-workspace? I feel that this could help the discussion stay on-topic. Greetings Stefan
Re: The future of Power Management - together with Activities
On Sun, Oct 2, 2011 at 7:58 PM, Dario Freddi drf54...@gmail.com wrote: I still haven't found a you're right after a thousand times I've been explaining the only real saver you can configure is brightness, and this kinda concerns me. You are indeed right. (Funny thing is that brightness is the single point of confusion with power management for me. I sometimes dim the display when in dark rooms, and when the battery goes down and Powerdevil changes from Powersave to Aggressive Powersave, it restores the brightness of the last Aggressive Powersave session and actually brightens my display. Not to say this is something you can do much about.) Greetings Stefan
Re: The future of Power Management - together with Activities
On Sat, Oct 1, 2011 at 7:33 PM, Andras Mantia aman...@kde.org wrote: I can't comment on activities, never used them, nor feel the need to use them. So this sounds more like the power management applet would force me to create and use activites. +1. Actually I'm confused by the concept of activities as a whole: On one hand, there are libraries now for reacting to activity switching. On the other hand, activities are said to include running applications, so apps will be closed when switching to a different activity. That seems contradictory. That makes it difficult for me to see where power profiles come into this game: Does this mean that when I want to switch to a different profile, does this mean that I have to create a new activity when I want to change to a different power profile, which would mean that all running applications would close because they belong to the previous activity? Greetings Stefan
Re: The case for a kdelibs 4.8
Without judging on the other arguments which look very reasonable to me... On Thu, Sep 29, 2011 at 2:01 PM, Kevin Kofler kevin.kof...@chello.at wrote: 2. It will be confusing to our users, and even to some packagers, to have a KDE SC 4.8 on kdelibs 4.7. [...] ...what exactly stops you from advertising kdelibs 4.7.x as version 4.8? (And I mean advertise, so only the user-visible parts, not version numbers in .so files or whatever.) Greetings Stefan
Re: KDE Frameworks Documentation
On Wed, Sep 28, 2011 at 10:26 AM, Myriam Schweingruber myr...@kde.org wrote: Since the API documentation is extracted automatically, I would expect it to be rather up-to-date Yes, but it's not always very extensive. Or to put it differently: API documentation can only be extracted, but not be generated automatically. I've already used several methods from kdelibs which had no documentation at all. Greetings Stefan
Re: Review Request: Change konqueror tabs look and feel
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/102519/#review6262 --- A quick search on b.k.o did not turn anything up, although I for one would immediately open one now that I know there isn't one. (Note that I != submitter.) konqueror/src/konqtabs.cpp http://git.reviewboard.kde.org/r/102519/#comment5504 As far as I can see, there is no provision for making the tabs smaller when there are many of them, like in Firefox and Rekonq. Bellegarde, I think it would be more appropriate to add this functionality to KTabBar, e.g. KTabBar::setUseUniformTabSize(bool), with the default being false for compatibility reasons. I'm a bit disappointed that an important point of the whole uniform tab size model is missing in this and also in the Rekonq implementation. In Firefox and Chrome, when there are many tabs, so the tab size is smaller than the default, and you close some of the tabs, the tab size is not adapted immediately, but only when the cursor leaves the tabbar. This is extremely useful because it allows to close multiple tabs at once by just clicking at the same spot again and again. Speaking of implementation, all you would have to add is calculating and applying an optimal tab size (something like qMin(200, tabBar.size() / tabBar.count())) in the leaveEvent (and when a new tab is added). If you could do that (in KTabBar), that would rock hard. - Stefan On Sept. 2, 2011, 10:51 a.m., Bellegarde Cédric wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/102519/ --- (Updated Sept. 2, 2011, 10:51 a.m.) Review request for KDE Base Apps. Summary --- This patch change konqueror tabs behaviours with fixed size like in firefox, rekonq, ... Tabs size is fixed and text is adapted to this size. Diffs - konqueror/src/konqtabs.cpp d627fad Diff: http://git.reviewboard.kde.org/r/102519/diff Testing --- Screenshots --- Konqueror patched http://git.reviewboard.kde.org/r/102519/s/247/ Thanks, Bellegarde
Re: Re: KImageIO::mimeTypes and SVG/SVGZ Files
On Wed, Aug 31, 2011 at 4:20 PM, Albert Astals Cid aa...@kde.org wrote: But I have a general question: Why is there a Name[lang]= field at all ? The translation for the mime types is already given in the shared-mime-info database. Because it is a .desktop file and .desktop Name fields are translated. I think the question is, why is there a Name field in the desktop file when the shared-mime-info database has that data already? Greetings Stefan
Re: systemd and KDE (was: Re: kdeinit)
On Tue, Aug 23, 2011 at 8:10 AM, Aaron J. Seigo ase...@kde.org wrote: is there a way to get notified from systemd when a unit changes activation or load state? because those would also be useful in the engine, obviously. I don't see such signals, and this can be a real problem. libqsystemd currently implements caching for values because I consider D-Bus calls expensive, but there is nothing that would invalidate cached values. the only thing that might be interesting is to provide a serviceForSource implementation that allows interacting with a unit, if a user is able to do anything useful (such as activate/deactive a unit?). i'm not sure that's possible though; if not then a Service is also unecessary. That's possible, though the default setup of the D-Bus service grants this right only to root. Sounds like a job for PolicyKit. Greetings Stefan
Re: systemd and KDE (was: Re: kdeinit)
On Tue, Aug 23, 2011 at 4:48 PM, Stefan Majewsky stefan.majew...@googlemail.com wrote: I don't see such signals, and this can be a real problem. Looked again, and there is a single change signal, plus a set of properties which are invalidated by this signal. Should be enough to keep the cache sane. Greetings Stefan
Re: Git migration status (Was: Re: Where is kmix hidden?)
On Fri, Aug 19, 2011 at 9:27 PM, John Layt jl...@kde.org wrote: The kde-wallpapers and kdeartwork modules are likely to remain in svn until git handles binary blobs better. Then there is also a lot of stuff still in extragear and playground. This is an issue with kdegames as well: A complete source tree is 112 megabytes, of which about AFAIR 80% is data (SVGZ, audio files, levelsets, etc.). Some months ago, I've proposed on kde-games-devel@ to split a kdegames-data module from kdegames. The discussion ended because we decided not to switch to git before a workflow exists to handle split repositories. (With SuperBuild being available now, this discussion probably needs to be restarted.) What I proposed: 1. Freeze trunk/KDE/kdegames, conserve this state as kdegames-history.git 2. Move all data files from trunk/KDE/kdegames to trunk/KDE/kdegames-data. 3. Move the source code to git.kde.org (as fresh repos, to avoid data blobs in the object db). 4. Optionally patch the games to run without data. This is because the build order of the modules would be: kdegames, then kdegames-data. Greetings Stefan
systemd and KDE (was: Re: kdeinit)
On Sun, Aug 21, 2011 at 4:54 PM, John Layt jl...@kde.org wrote: Ummm, Pulse Audio? It completely broke sound under KDE. It caused a lot of users a lot of pain before Colin come along to fix it for us and for Gnome users too. I don't want to see a repeat of that, so figuring out how to get Lennart to care becomes important. During Desktop Summit, I've jumped on the systemd-KDE-integration bandwagon (which seems to be only me at the moment, or is there any work which I'm not aware of?). As a very first step, there's libqsystemd [1], which I'll try to finish and polish in the next few weeks. This should make it easy to write apps that communicate with systemd. For example, what about a proper Plasma dataengine for systemd units/jobs and an applet that e.g. shows the state of a systemd unit? There's an proof-of-concept dataengine in the repo [1], but the subject is in need of someone who knows his way around Plasma dataengines and friends. The second integration point is the unified interfaces for system configuration that systemd provides. If systemd is present, it should be used to set (possibly also get) the hostname, locale, and system time. Also, KDM should be able to communicate with systemd-logind, which (as outlined by Lennart's talk at DS) seeks to replace ConsoleKit. The third integration point is to use systemd as a session manager, thereby (as already mentioned) possibly replacing big parts of our own startup sequence. Once I can get a current version of systemd to compile on my machine, I will try to look into this, but of course help is appreciated on all fronts. Greetings Stefan [1] git clone kde:libqsystemd
Re: smallish project needed
On Fri, Aug 12, 2011 at 3:58 PM, Mark mark...@gmail.com wrote: Dolphin is going in the QML direction? Yes, I think a Juk rewritten in QML could be a good thing. Well, in that direction.. it's not written in QML or anything.. : http://ppenz.blogspot.com/2011/08/introducing-dolphin-20.html Of course it depends on the application. QML is not yet at the point where writing a desktop file manager using it makes sense (see, for example, tree models). For a media player, though, it can make a lot of sense. Greetings Stefan
Re: KImageCache, KPixmapCache and KSharedDataCache VS QPixmapCache and QCache
On Sat, May 14, 2011 at 10:18 PM, Parker Coates parker.coa...@kdemail.net wrote: Also note that KPixmapCache is now deprecated and that KImageCache is just a thin convenience wrapper around KSharedDataCache. So really, KSharedDataCache is KDE's only current caching system. Michael Pyne, if you're reading this, please try hard to upstream KSharedDataCache. It's a really nice, fast and stable solution. Greetings Stefan
Re: Projects in KDE Review for more than two weeks
On Thu, May 12, 2011 at 10:44 AM, Ben Cooksley bcooks...@kde.org wrote: libtagaro Can be moved back to playground/games for now. Has been postponed to 4.8 cycle (discussion on kde-games-devel). Greetings Stefan
Re: svn - git transition status ?
On Sun, May 8, 2011 at 6:52 PM, todd rme toddrme2...@gmail.com wrote: Weren't there issues with kdeartwork and GIT because of the large number of binary files (like wallpapers)? The same (still unresolved) issues are with kdegames, which has 400 MB of history just for data files (which make up 80% of a 100 MB SVN checkout). Greetings Stefan
Re: [Kde-scm-interest] Re: libtagaro - kdereview [- kdegames]
On Fri, Apr 22, 2011 at 3:39 PM, Torgny Nyblom k...@nyblom.org wrote: +1 a module is a unit and should be treated as such even if the different apps are in different gits. So should I move the code to SVN then? This discussion was on kde-games-devel already, and the mass figured it's quite stupid to move code from Git to SVN while everything's generally moving in the opposite direction. Greetings Stefan
libtagaro - kdereview [- kdegames]
Hi, what is the technical procedure for moving libtagaro.git to kdereview? I think sysadmins need be informed, and hope that those are reading here. Assuming that this goes well: I hereby propose to move libtagaro to the kdegames module after the usual review period. For the time being, because kdegames has not yet moved from SVN, this would create a module that is split between SVN and Git, but a similar situation exists with kdegraphics, so I hope this is not a problem. In any event, scm-interest is CCd if anyone wants to discuss this. Rationale: libtagaro intends to replace libkdegames in the long run. libkdegames was developed long before such important technologies as QGraphicsView, QML and OCS, which define how our games work now or in the near future. Therefore, the scope of the support library that is libkdegames changes rapidly. Currently, libtagaro contains 1. an advanced version of KGameRenderer from libkdegames, which adds some further optimization opportunities and flexibility 2. a simple sound effects API which, if possible, uses OpenAL to reduce playback latency 3. some basic layouting components for QGraphicsView-based games Not much of this is new in the kdegames codebase. Number 2 is already used by Granatier (by means of a static source copy), number 3 is already used by Kolf (in the same way). Number 1 is, as I said, heavily based on KGameRenderer which is already used by about a dozen games. I want to add more components, especially to accommodate the needs of mobile form factors, but doing so will be much easier when I can rely on the games having a hard dependency on it. Previously, I planned to make libtagaro a private library inside the module, but this approach is unpractical while the rest of kdegames is still in SVN, or when kdegames moves to Git with a split repository layout. I therefore plan to install headers publicly, but explicitly state that there is no API/ABI stability guarantee for the time being, i.e. SO versions will likely be bumped often over the course of the next few 4.x releases. I conclude my explanations with a braindump of what needs to be done: * TagaroAudio falls back to Phonon when OpenAL is not available, but the Phonon backend is not yet implemented. (Mathias Kraus of Granatier helps with that.) * No CMake find-script etc. is installed at the moment. AFAIK it would be best to include this with the rest of the kdegames module. Also, it is probably not state-of-the-art to detect libsndfile through pkgconfig. Granatier has a FindSndfile.cmake which I plan to copy. * I have not checked Krazy output for quite a while, though I think it was empty some two months ago. Greetings Stefan
Re: [Kde-games-devel] Re: Move Tagaro code into SVN?
On Wed, Apr 13, 2011 at 11:47 PM, Parker Coates parker.coa...@kdemail.net wrote: If it means adding a new library for distributions to package, I think it has to go through kdereview, even if it does so with a this is not a stable API disclaimer. It's a relatively big change, so I think third parties (packagers, build system folks, translators, etc.) should have the opportunity to point out issues it may cause for them. Let's take this question to k-c-d. Some background for the new readers from my mail which started this thread: Would anybody mind if I moved the Tagaro source tree inside kdegames SVN, in a separate subdirectory? It will explicitly be described as an experimental and private library, with headers being installed only when the undocumented option -DINSTALL_HIGHLY_UNSTABLE_TAGARO_INCLUDES is given to CMake. [...] I know that this proposed procedure bypasses kdereview effectively, but big parts of Tagaro are already source-copied into kdegames somewhere, like TagaroAudio in Granatier and parts of TagaroInterface in Kolf. Also, KGameRenderer from libkdegames shares much with TagaroGraphics, so there is not much new code in there. Besides, I will of course issue a public review via kdereview when the library API is stabilized and goes public. P.S. Everyone is invited to review the code, of course. Look at the current master branch of kde:libtagaro. Greetings Stefan
Re: A Qt replacement for KGlobal::ref and deref
On Wed, Feb 16, 2011 at 5:31 PM, Aaron J. Seigo ase...@kde.org wrote: which begs the question: is KConfig (as ane exmple) platform or app dev? fun conversations to be had and digging to be done :) From my experience, KConfig is actually two things at once: 1. framework for reading and writing INI-like files 2. utility for locating and merging user-specific plus system-wide configuration Only part 2 is platform. Part 1 is already a great thing in itself even if applied to single files. Usages of KConfig for the purpose of defining custom, human-readable file formats include (here in kdegames) KGameTheme description files, Palapeli puzzle metadata, Palapeli collections, Kolf courses, etc.pp. Part 2 is just a bonus for application configuration files, just like KConfigXT which is not useful for custom file formats. So a possible idea could be to refactor the KConfig class into two classes, one for stand-alone config files and one for application configuration in KStandardDirs' config prefix. The latter class would then move into the KDE platform thingy, while the other one does not have any KStandardDirs dependency. (Dunno about other low-level dependencies, though.) Greetings Stefan
Re: git workflow draft
On Wed, Feb 16, 2011 at 10:31 PM, Stephen Kelly steve...@gmail.com wrote: If someone writes 100 commits and pushes them without review then that's a social problem. I was referring to the case when a feature branch gets moved between repositories (e.g. a personal clone and the master repo). Review can only happen when the feature branch is at a publicly visible place. Greetings Stefan
Re: git workflow draft
On Tue, Feb 15, 2011 at 6:51 PM, Aaron J. Seigo ase...@kde.org wrote: Only features / topics that are intended from the state to be merged with master should end up in the main repository, however. More experimental and/or long term efforts (an example presented was the kconfig refactor leading up to 4.0) should start in a personal clone, and when/if the work crosses the border into this is realistically going to be merged with master it can be moved into a branch in the main repository. As far as I'm concerned, the only problem with such branch moves is the potentially epic number of commit notification mails. If so, the email hook should check if the push generates a new branch, and send only one mail then, like 100 commits have been pushed into the new branch foobar; see here for a complete log vs. master and here for the diff. Greetings Stefan
Re: git won't let me delete a branch?
On Sat, Feb 5, 2011 at 9:12 PM, John Tapsell johnf...@gmail.com wrote: The way that it works for the public Qt repository is that no one can create or delete branches. But anyone can clone the repository, and then create/delete branches there as they want. Shouldn't we have something similar? Don't we have this yet? I'm using exactly this approach for my work branches in libtagaro (cf. kde:libtagaro and kde:clones/libtagaro/majewsky/work). The only fear I'm having is that I'll once run into this 100-commits-per-push-operation limit.
Re: Merge or Cherry-Pick?
On Thu, Feb 3, 2011 at 6:21 AM, Dawit A ada...@kde.org wrote: git config --global push.default tracking and use the -t or --track option when creating your branches (branch or checkout -b). This way you can 'git push' (no arguments) in the current tracked branch without accidentally pushing your changes in other branches. I think this is the default. When I do git checkout -b somework origin/somework here, it automatically sets up somework to track origin/somework. Push by default only operates on the tracking branch, i.e. push --all needs to be specified manually. Greetings Stefan
Re: Merge or Cherry-Pick?
On Tue, Feb 1, 2011 at 10:22 PM, Aaron J. Seigo ase...@kde.org wrote: then i learned today to be extra vigilant about doing `git pull --rebase` and not just `git pull` so i don't accidentally throw merge commits in there while preping for a push. Look in man git-config for branch.autosetuprebase. I think this should go into the Git manual after someone has checked this (did not actually try it). Greetings Stefan
Re: Merge or Cherry-Pick?
On Mon, Jan 31, 2011 at 11:34 PM, Arno Rehn kde-de...@arnorehn.de wrote: (Feature branches are a different thing). Am I right that these should be rebased instead of merged?
