gvfs branched for gnome-2-26
I've branched gvfs for gnome 2.26, further developement on master is for gnome 2.28. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Nautilus branched for gnome-2-26
Nautilus has been branched, stable development is on gnome-2-26 branch, master is for 2.28 development. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Applets? [was Re: Planning for GNOME 3.0]
Le lundi 20 avril 2009 à 16:10 -0700, Dylan McCall a écrit : I do have a guess what could be done. Firstly, abolish applets as things which must be run differently from other applications; the user should not Ever see the word applet again. Enhance running applications and how they connect with application launchers and their windows; one of the things GNOME Shell seems to be doing. Maybe one way about this is to build on that part of the window manager where it's up to The User whether he wants to minimize a window, shade it or put it beside another on the right side of the screen. How about window management hotspots, such as a panel and a sidebar, each with unique properties for how they treat windows? The user places a window in one of those and, depending on whether it supports some fancy extensions, it becomes a docked window like any file in the panel or the desktop (eg: a window icon that when clicked opens into a full window again). Super awesomeness could extend that so the docked window gains desklety / applety functionality when supported. Basically, kill the distinction and leave it up to the user to say what he wants a window to do rather than have them making unpredictable guesses, and have the window - or whatever other object - do what it can to meet the user's commands. While I agree your proposal would be a great enhancement for most applications that abuse of the notification area (e.g. music players), I don't think that could fully replace applets. Applets like timerapplet or sticky notes are different from standard applications in the sense that you don't work with them as a full task, but only keep them in the background to be easily accessible, while you actually use them for a very short period. The point with them is that the ratio (time running)/(time use) is very low compared with e.g. a text processor. Thus, you need them not to take too much space on the screen, not even, as you suggested, stacked in a corner by the window manager. I'd argue that the best place to put them is on a separate layer à la dashboard (Apple), or directly on the desktop. This layer could be accessed with a button in the top panel, somewhere or in the overlay. Many widgets of this kind exist, see Screenlets, Superkaramba, or Google gadgets, or Plasmoids. A simple way of reintroducing applets in a correct way would be to support e.g. Screenlets in an overlay: replacements for Tomboy already exist in that framework, which is AFAIK compatible with other widget formats. At least, that's really how I consider we could get rid of the clutter on the main screen, which is distracting us with icons we don't need to be always visible. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Applets? [was Re: Planning for GNOME 3.0]
Hi, possible solution, the golden one imho, could be to create new API for applets, while redefining term applet. Applet could be equivalent to widgets in macos x, or plasmoids (horrible naming) in kde. Small self contained applications rendered either with gtk+ or some htmlview with javascript (gecko or webkit), without window decoration, etc. We could either lookup or create specification and API for these. New API should stay language neutral, C, python, ruby, javascript, ... For existing applets, there will be one written in new API, providing room for these yet to rewritten applets. They can decide to transform into icon in notification area, or transform to new applet platform, or do nothing :) (the bad case) For users, there could be the option to either display these new applets as floating windows, or they can be docked in sidebar. There also could be an algorithm for laying out applets while in sidebar: wider applets in vertical list, rectangular/portrait in line, dragdrop sorting. Some examples: * Banshee/Rhytmbox/... - they could display small player controls and line with now playing artist/title * Deskbar - should be reused and rewritten as primary search field for gnome-shell, no reason to reinvent the wheel here, or use tracker or gnome-do to query for items * Volume+DateTime+user session could merge into one applet or move into notification area * ...I can imagine many other applets to expand beyond it's current (very restricting) panel-like container On Mon, Apr 20, 2009 at 09:13, Johannes Schmid j...@jsschmid.de wrote: Hi! (I'm talking about Empathy, Pidgin, RhythmBox, and Banshee here. And probably quite a lot more.) Well, these are part of the notification area - they will mostly remain the way they are (so I think the RhythmBox and Banshee icons are completely useless). I think the point of applets is that they should be more than just an icon, because the icon case is already quite well covered. Regards, Johannes ___ gnome-shell-list mailing list gnome-shell-l...@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-shell-list -- Best regards, Dušan Maliarik // cell: +420 722 810 140 ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Applets? [was Re: Planning for GNOME 3.0]
Milan Bouchet-Valat wrote: While I agree your proposal would be a great enhancement for most applications that abuse of the notification area (e.g. music players), I don't think that could fully replace applets. Applets like timerapplet or sticky notes are different from standard applications in the sense that you don't work with them as a full task, but only keep them in the background to be easily accessible, while you actually use them for a very short period. The point with them is that the ratio (time running)/(time use) is very low compared with e.g. a text processor. Thus, you need them not to take too much space on the screen, not even, as you suggested, stacked in a corner by the window manager. I'd argue that the best place to put them is on a separate layer à la dashboard (Apple), or directly on the desktop. This layer could be accessed with a button in the top panel, somewhere or in the overlay. Many widgets of this kind exist, see Screenlets, Superkaramba, or Google gadgets, or Plasmoids. A simple way of reintroducing applets in a correct way would be to support e.g. Screenlets in an overlay: replacements for Tomboy already exist in that framework, which is AFAIK compatible with other widget formats. At least, that's really how I consider we could get rid of the clutter on the main screen, which is distracting us with icons we don't need to be always visible. I like the proposed solution that the panel launchers would somehow become a dock. e.g. for Tomboy or Hamster Applet, you have the icon launcher. If you click on it, the app is opened. If you click on it again, it's closed. That could be achieved with single-instance applications (libunique), for example (when you try to launch it again, the instance is closed). For many cases, I can imagine such a workflow would be fine. It wouldn't solve all of them though, for example you don't want system-monitor to be a launcher, but rather to see the system activity IRL. Another benefit of this is that a) your applet doesn't need to be started up on login, and b) you don't have it running everytime. Of course, you need it to be quick to start up. But if it doesn't for such small applications, it's a big fail IMHO. Best regards, Emilio signature.asc Description: OpenPGP digital signature ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Vino and Vinagre branched for 2.26
Branch names are gnome-2-26. Development will happen in master. Cheers, -- Jonh Wendell www.bani.com.br ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Bumping required version of DeviceKit-power to 007
On Tue, 2009-04-21 at 03:58 +0200, Vincent Untz wrote: Sounds good. Please update the wiki page and the jhbuild moduleset to make this official :-) Done, thanks! Richard. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: BillReminder waiting for git conversion
On Tue, Apr 21, 2009 at 8:26 AM, Og Maciel ogmac...@gnome.org wrote: I was wondering if someone could give me some feedback on how to get my BillReminder project converted to git. I was told there was a snag during the first import attempt... As most of the GNOME modules seem to have been converted, could someone take a look at it for me? Also, the special case repository of seahorse-plugins hasn't been converted yet. Cheers, Adam ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Vino and Vinagre branched for 2.26
2009/4/21 Jonh Wendell jwend...@gnome.org: Branch names are gnome-2-26. Development will happen in master. Are there any plans for an RDP Gtk+ widget during this cycle? Cheers, -- Jonh Wendell www.bani.com.br ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list -- Un saludo, Alberto Ruiz ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Vino and Vinagre branched for 2.26
Em Ter, 2009-04-21 às 13:40 +0100, Alberto Ruiz escreveu: 2009/4/21 Jonh Wendell jwend...@gnome.org: Branch names are gnome-2-26. Development will happen in master. Are there any plans for an RDP Gtk+ widget during this cycle? YEP!!! My friend Jorge Pereira (CC'ed) is working on porting rdesktop to a gtk+ widget just like gtk-vnc is. I'm working on turning the vinagre internal structure into a generic one. Currently it works only with VNC. Hopefully it will be done for 2.28 :) Cheers, -- Jonh Wendell http://www.bani.com.br ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Vino and Vinagre branched for 2.26
Hi Jonh, Am Dienstag, den 21.04.2009, 09:50 -0300 schrieb Jonh Wendell: My friend Jorge Pereira (CC'ed) is working on porting rdesktop to a gtk+ widget just like gtk-vnc is. Hopefully it will be done for 2.28 :) please add this to http://live.gnome.org/RoadMap . andre -- mailto:ak...@gmx.net | failed http://www.iomc.de/ | http://blogs.gnome.org/aklapper ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Applets? [was Re: Planning for GNOME 3.0]
I've found that I really like the plasmoid approach from KDE4. Most of those things fit the description of infrequently needed for short periods of time, or crack. From my point of view (a user), I mainly want to be able to get to applets quickly. With the current small format of applets on the panel, getting any significant amount of info requires that I actually mouse-over or click many of them to see what's going on. Since I'm already context-switching my mind from what I was doing to whatever I'm about to do with the applet, I don't particularly mind if my current application disappears temporarily while I work with the applet. With that in mind... What if we create a new class of window for applets with these characteristics: - Does not appear in the Window list - Does not appear in the alt-tab switcher - No window borders (they will draw their own content somehow) - The Window Manager will have a certain key event that will bring all of these class of windows to the foreground until that button is pressed again (or each applet could register its own) - These windows (or maybe their children?) can be configured to be on top of all windows permanently, maybe with a lowered opacity (so you can always see f.e. your CPU usage on the system monitor applet) - The windows can be positioned anywhere on the screen - Ability to toggle temporary visibility in order to inform of events (next song playing, network disconnected, etc.) (maybe a good way to do notifications in the future?) - Would be nice if each app could have a collapsed state to further minimize screen usage (for people with smaller screens) The goals of this design would be: - Quick access to any of these applications when you need them; already running, just a keypress to activate them / bring to foreground - Can display more information because they have a larger display area - Can be written into any applicable spec so other environments could implement these - No specific framework required to these applications, just create a certain type of window - No language constraints; anything that can make a graphical app can make one of these - Any app could have a minimize as applet state (media players would like this) which shows just the basic info about them in a small footprint I personally think that the current state of applets is a little limiting. I like the panel well enough, but I feel like applets could be displaying more information about their state if they just had a little more screen real estate to play with. Since many people have very large screens now, why not work on letting the applets take up more of it? - Martin On Tue, Apr 21, 2009 at 8:10 AM, Emilio Pozuelo Monfort po...@ubuntu.com wrote: Milan Bouchet-Valat wrote: While I agree your proposal would be a great enhancement for most applications that abuse of the notification area (e.g. music players), I don't think that could fully replace applets. Applets like timerapplet or sticky notes are different from standard applications in the sense that you don't work with them as a full task, but only keep them in the background to be easily accessible, while you actually use them for a very short period. The point with them is that the ratio (time running)/(time use) is very low compared with e.g. a text processor. Thus, you need them not to take too much space on the screen, not even, as you suggested, stacked in a corner by the window manager. I'd argue that the best place to put them is on a separate layer à la dashboard (Apple), or directly on the desktop. This layer could be accessed with a button in the top panel, somewhere or in the overlay. Many widgets of this kind exist, see Screenlets, Superkaramba, or Google gadgets, or Plasmoids. A simple way of reintroducing applets in a correct way would be to support e.g. Screenlets in an overlay: replacements for Tomboy already exist in that framework, which is AFAIK compatible with other widget formats. At least, that's really how I consider we could get rid of the clutter on the main screen, which is distracting us with icons we don't need to be always visible. I like the proposed solution that the panel launchers would somehow become a dock. e.g. for Tomboy or Hamster Applet, you have the icon launcher. If you click on it, the app is opened. If you click on it again, it's closed. That could be achieved with single-instance applications (libunique), for example (when you try to launch it again, the instance is closed). For many cases, I can imagine such a workflow would be fine. It wouldn't solve all of them though, for example you don't want system-monitor to be a launcher, but rather to see the system activity IRL. Another benefit of this is that a) your applet doesn't need to be started up on login, and b) you don't have it running everytime. Of course, you need it to be quick to start up. But if it doesn't for such small applications, it's a big fail IMHO. Best
gnome-session saving X autostarting apps
Hi, folks. There's a bug in vino which talks about vino service restarting in a loop, due to it being saved in the session AND being part of auto-started applications. http://bugzilla.gnome.org/show_bug.cgi?id=579355 My guess is that it's not a vino bug, but a gnome-session one, as it affects all auto-started programs. What do you guys (specially gnome-session devs) think? Thanks, -- Jonh Wendell http://www.bani.com.br ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Vino and Vinagre branched for 2.26
You can take a look at: http://grdc.sourceforge.net It is a good application El mar, 21-04-2009 a las 15:17 +0200, Andre Klapper escribió: Hi Jonh, Am Dienstag, den 21.04.2009, 09:50 -0300 schrieb Jonh Wendell: My friend Jorge Pereira (CC'ed) is working on porting rdesktop to a gtk+ widget just like gtk-vnc is. Hopefully it will be done for 2.28 :) please add this to http://live.gnome.org/RoadMap . andre Pulse para ir al sitio web Jesús Barbero Rodríguez Departamento de Análisis y Programación - Desarrollo tecnológico Zoco Gran Santander, 1ª Planta ■ 39011 Peñacastillo ■ Santander ■ ESPAÑA Tel.: +34 902 233 323 ■ Fax: +34 902 234 280 AVISO LEGAL: Este mensaje contiene información destinada exclusivamente al usuario de destino, pudiendo contener información confidencial o protegida legalmente. Si, por un error de envío o transmisión, ha recibido este mensaje y usted no es el destinatario del mismo, por favor, notifique de este hecho al remitente y no use, informe, distribuya, imprima, copie o difunda este mensaje bajo ningún medio . Cualquier opinión en él contenida, es exclusiva de su autor y no representa necesariamente la opinión de Quiter Servicios Informáticos, S.L. LEGAL WARNING: This e-mail and any attachment, contain information intended solely for the addressee and may contain confidential information or legally protected data. If you are not the intended recipient, please notify the sender and do not use, disclose, distribute, copy, print or rely on this e-mail under any circumstances. The views and opinions expressed are the authorŽs own and do not necessarily reflect those of Quiter Servicios Informáticos, S.L. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: On autogenerated ChangeLog
On Mon, Apr 20, 2009 at 10:20 PM, Cody Russell brats...@gnome.org wrote: [] Yeah, but the thing that sucks about versioned ChangeLogs is merging/rebasing your code. Typically you always leave writing a ChangeLog last for this reason, but it just makes so much more sense to be able to write your entry when you do your commit. If you're posting a branch for review or something, people can read your commit logs as well as the code.. but if you post patches for review, you probably don't post the ChangeLog with it because it'll get clobbered when you have to merge it into the tree. You always post ChangeLogs diffs with large patches, large patches generally come to the maintainer in the form of a patch, with a single changelog entry, the maintainer reviewing a branch doesnt want to see the revision history of what happened on the branch, or why you reverted that peice of code thats not actually in the patch (and never made it into the baseline/trunk). Now if I can demand that a patch submitter provide the base minimum: - A patch that applies to trunk - A rich ChangeLog entry that describes what happens in the change Then why would I waste my time flipping through individual commit logs ? Cheers, -Tristan ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: On autogenerated ChangeLog
On Tue, Apr 21, 2009 at 6:51 PM, Tristan Van Berkom t...@gnome.org wrote: On Mon, Apr 20, 2009 at 10:20 PM, Cody Russell brats...@gnome.org wrote: [] Yeah, but the thing that sucks about versioned ChangeLogs is merging/rebasing your code. Typically you always leave writing a ChangeLog last for this reason, but it just makes so much more sense to be able to write your entry when you do your commit. If you're posting a branch for review or something, people can read your commit logs as well as the code.. but if you post patches for review, you probably don't post the ChangeLog with it because it'll get clobbered when you have to merge it into the tree. You always post ChangeLogs diffs with large patches, large patches generally come to the maintainer in the form of a patch, with a single changelog entry, the maintainer reviewing a branch doesnt want to see the revision history of what happened on the branch, or why you reverted that peice of code thats not actually in the patch (and never made it into the baseline/trunk). Now if I can demand that a patch submitter provide the base minimum: - A patch that applies to trunk - A rich ChangeLog entry that describes what happens in the change Then why would I waste my time flipping through individual commit logs ? Dude, we have moved to git and you are still talking of versioned ChangeLog and favoring large patches? -- Regards, Zeeshan Ali (Khattak) FSF member#5124 ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: On autogenerated ChangeLog
On Tue, Apr 21, 2009 at 12:19 PM, Zeeshan Ali (Khattak) zee...@gmail.com wrote: [...] Dude, we have moved to git and you are still talking of versioned ChangeLog and favoring large patches? With a tool like git, you should be at least able to generate a single reviewable patch, large or small, and thats reviewable, yes. Versioned ChangeLog is a matter of trust, Id personally rather take care of it and revision it by hand, I didnt ask other people to do so, this is what I will do though (also, merging changes in a ChangeLog cannot be difficlult, definitly not more difficult than merging sources). Cheers, -Tristan ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: On autogenerated ChangeLog
On Tue, 2009-04-21 at 13:26 -0400, Tristan Van Berkom wrote: Versioned ChangeLog is a matter of trust, Id personally rather take care of it and revision it by hand, I didnt ask other people to do so, this is what I will do though (also, merging changes in a ChangeLog cannot be difficlult, definitly not more difficult than merging sources). No, but the point is that if you edit some code and someone else has made changes to some code elsewhere in the repo, and you merge their work into yours.. then maybe you have to fix some conflicts, but maybe not. If you have already added ChangeLog entries and someone else commits something before you commit then you have to resolve conflicts in your ChangeLog 100% of the time. If it's not a big deal to you, cool. I was just pointing out that this is something sucky about dealing with ChangeLog files that exist in your repo instead of being generated by your VCS. / Cody ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: On autogenerated ChangeLog
On Mon, 2009-04-20 at 09:01 -0500, Jonathon Jongsma wrote: Same thing with the dates. The old ChangeLog only had dates, not time, so there is imho no loss in just using dates in the autogenerated file. I agree with alex. The changelog should be easily readable. big strings of +++-- make it harder to scan. If we want that detailed level of information, we can always extract it from git on demand anyway. If anybody eventually thinks they have a decent way to generate ChangeLogs then please do add it here so we can have some consistency: http://live.gnome.org/Git/ChangeLog I'm interested to see the result, though I'm frankly resigned to the entropy increase. I personally have never seen a generated ChangeLog that was anywhere near as useful as a separate ChangeLog, regardless of what other tools are available to do commits archeology, so my projects will not change that practice just because of a VCS change. No, I'm not interested in discussing it. -- Murray Cumming murr...@murrayc.com www.murrayc.com www.openismus.com ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: On autogenerated ChangeLog
On Tue, Apr 21, 2009 at 4:23 PM, Zeeshan Ali (Khattak) zee...@gmail.com wrote: [...] Reminds me of my friend who insists that evolution is nothing more than hoax and when I try to educate him, he doesn't want to discuss it. :) There are simply two facts to be kept in mind here: 1. All information in the ChangeLog is redundant. 2. Maintaining a ChangeLog only and only realizes otherwise inexistent conflicts. It is as simple as that. Sure, on the other hand projects with ChangeLogs that are hand-tended to are, in my personal experience richer than logs of arbitrary commits, if only by the simple virtue of forcing you to spend time caring for it. Anyway, lets see what some experiments yield ;-) Cheers, -Tristan ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: On autogenerated ChangeLog
Tristan Van Berkom wrote: Sure, on the other hand projects with ChangeLogs that are hand-tended to are, in my personal experience richer than logs of arbitrary commits, if only by the simple virtue of forcing you to spend time caring for it. I use ChangeLogs a lot. My preference for hand-made ChangeLogs is that the author involuntarily tends to order things by priority. The fact that he bumped the solib version is much more important than that he cleaned up whitespace, fixed an include flag that breaks on some obscure platform, etc. The latter of examples of the kind of entries frequently seen in auto-generated logs. As Murray says, increased entropy. I'll take a weak wine to a high-powered beer any day. --Pat ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: On autogenerated ChangeLog
On Tue, Apr 21, 2009 at 3:32 PM, Tristan Van Berkom t...@gnome.org wrote: Sure, on the other hand projects with ChangeLogs that are hand-tended to are, in my personal experience richer than logs of arbitrary commits, if only by the simple virtue of forcing you to spend time caring for it. Anyway, lets see what some experiments yield ;-) Anyone submitting patches to our module without a proper commit log message will likely have their patch gently rejected until it's fixed. That certainly is the case with the vast majority of FOSS projects out there using git. See git format-patch. Likewise, at some point, translators making a commit log message that reads Updated a file. will have their commit reverted with an explanation in the commit log as to why it was reverted. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: On autogenerated ChangeLog
On 04/21/2009 10:23 PM, Zeeshan Ali (Khattak) wrote: 1. All information in the ChangeLog is redundant. 2. Maintaining a ChangeLog only and only realizes otherwise inexistent conflicts. Agreed. You could do what we've been doing in a project of mine: Auto-generating the changelogs on release, and publishing a hand-picked friendly changelog too. In fact, you probably should have a file which would be updated as developers churn along (distributing the effort over time), where each big notable feature/bugfix/etc. is recorded as a line in the file whenever it officially lands. When you make a release, create a tag in git (using git tag -a of course). When you diff the file between tags (this can be done easily if you have a release branch which always points at the most current release) and extract only the new lines, you have a changelog of well-written, user-friendly features — perfect for posting to your project's website, sending out to a mailing list, etc. Then, for those who want a more traditional here's-everything changelog, just generate a changelog based on your git commit messages. This should also be done also automatically on release. The nice thing about a process like this is that it minimizes the effort needed (since it's all done automatically using git, at release time) and should make everyone happy. Garrett ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: On autogenerated ChangeLog
Hello! On Tue, Apr 21, 2009 at 6:36 PM, Cody Russell brats...@gnome.org wrote: No, but the point is that if you edit some code and someone else has made changes to some code elsewhere in the repo, and you merge their work into yours.. then maybe you have to fix some conflicts, but maybe not. If you have already added ChangeLog entries and someone else commits something before you commit then you have to resolve conflicts in your ChangeLog 100% of the time. This problem was solved by Bruno Haible, who presents a git merge driver designed specifically for ChangeLog files, in a thread similar to this one: http://www.mail-archive.com/bug-gnu...@gnu.org/msg09183.html It's summed more succinctly in this blog post: http://i-nz.net/2009/03/19/git-automatic-smart-changelog-merging/ Sam ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: How to remove remote branch with git?
On Mon, Apr 20, 2009 at 10:54 PM, Vincent Untz vu...@gnome.org wrote: Added to http://live.gnome.org/Git/FAQ As per the information above: git push origin :tags/billreminder-0.3.2 --- You are trying to delete the tag 'billreminder-0.3.2'. http://live.gnome.org/Git/Help/TagUpdates --- To ssh://ogmac...@git.gnome.org/git/billreminder ! [remote rejected] billreminder-0.3.2 (pre-receive hook declined) error: hooks/pre-receive exited with error code 1 error: failed to push some refs to 'ssh://ogmac...@git.gnome.org/git/billreminder' Am I doing something wrong? Thanks in advance. -- Og B. Maciel omac...@foresightlinux.org ogmac...@gnome.org ogmac...@ubuntu.com GPG Keys: D5CFC202 http://www.ogmaciel.com (en_US) http://blog.ogmaciel.com (pt_BR) ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Applets? [was Re: Planning for GNOME 3.0]
Just to throw my hat into the ring, I thought I'd link to some previous discussion on applets. http://davyd.livejournal.com/118545.html http://mail.gnome.org/archives/desktop-devel-list/2004-September/msg00241.html http://mail.gnome.org/archives/desktop-devel-list/2004-September/msg00384.html -- Davyd Madeley http://www.davyd.id.au/ 08B0 341A 0B9B 08BB 2118 C060 2EDD BB4F 5191 6CDA ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: How to remove remote branch with git?
On 04/21/2009 07:30 PM, Og Maciel wrote: On Mon, Apr 20, 2009 at 10:54 PM, Vincent Untzvu...@gnome.org wrote: Added to http://live.gnome.org/Git/FAQ As per the information above: git push origin :tags/billreminder-0.3.2 --- You are trying to delete the tag 'billreminder-0.3.2'. http://live.gnome.org/Git/Help/TagUpdates --- To ssh://ogmac...@git.gnome.org/git/billreminder ! [remote rejected] billreminder-0.3.2 (pre-receive hook declined) error: hooks/pre-receive exited with error code 1 error: failed to push some refs to 'ssh://ogmac...@git.gnome.org/git/billreminder' Am I doing something wrong? Thanks in advance. That's actually what I expected. I added some detail to this page: http://live.gnome.org/Git/Help/TagUpdates Please find owen or krh in #git to sort things out as special cases. Someone please update Git/FAQ :). Cheers, behdad ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
