Re: git commit messages
On Wed, Apr 22, 2009 at 10:10 PM, Behdad Esfahbod wrote: > Another option I like to document if we can agree on is prefixing the > short-summary with a tag, like for example: > > "[layout] Improve X or Y" > > Others suggested: > > "layout: Improve X or Y" > > I prefer the former as it's visually more pleasing to me AND visually easier > to recognize the tag in git-shortlog output. In git.git they prefer "layout: improve X or Y" (no capital letter). -- Felipe Contreras ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: git commit messages
On Thu, Apr 23, 2009 at 7:09 PM, Shaun McCance wrote: > On Thu, 2009-04-23 at 11:45 +0200, Murray Cumming wrote: >> On Wed, 2009-04-22 at 16:46 +0200, Vincent Untz wrote: >> > Don't use a trailing period either. >> >> I find this really odd and rather arbitrary. I think it's something to >> do with you wanting to use these first lines in bullet-point lists. But >> there's no real grammar consensus about periods at the end of >> bullet-point items. I personally can't stand a sentence without a bullet >> point if it's more than 4 or 5 words. Can we please remove that >> requirement? > > It's not a requirement. It's a suggestion. Individual > maintainers are free to have different suggestions. So > the goal of the overall suggestions is to capture what > most maintainers want. Exactly, it's a guideline. Personally I don't see the point of a full-stop; you already know the summary will be one line, and if for some reason is not complete you'll see "..." -- Felipe Contreras ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: R: git migration - svn:externals
On Thu, Apr 23, 2009 at 2:27 PM, Zeeshan Ali (Khattak) wrote: > On Thu, Apr 23, 2009 at 1:24 PM, Tim-Philipp Müller wrote: >> On Thu, 2009-04-23 at 12:09 +0200, Jaap A. Haitsma wrote: >> >>> I think gst-ffmpeg uses this feature. gst-ffmpeg is in git while it >>> uses ffmpeg which is in svn. >> >> Not really - gst-ffmpeg just runs svn checkout in autogen.sh, and that's >> it. >> >> We use git submodules in GStreamer though (we have a 'common' submodule >> for all other modules), but git submodules are still fairly cumbersome >> to use and I wouldn't recommend them until the git people make them less >> painful to use, at least not for projects where the submodule reference >> needs to be updated frequently. > > This whole idea of sub-modules is just brain-dead so I wouldn't > count on git developers fixing that instead of concentrating on > features of real importance. If you have some code (or even data) that > is needed by more than one of your modules/packages, you either put > that common stuff in another module/package and make other packages > depend on this or you just bite the bullet and don't mind the > redundancy. In some cases you just have to wisely use the combination > of both. I'm involved a bit in git development and I have to say that view is pretty much accurate. 'git submodule' is essentially a big hack and nobody from the main developers is actively working on it. Of course patches are accepted and support is improving, but I wouldn't recommend any major projects to depend on it. -- Felipe Contreras ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Generating .gitignore files
On Mon, Apr 20, 2009 at 4:56 PM, Behdad Esfahbod wrote: > On 04/20/2009 02:34 AM, Steve Frécinaux wrote: >> >> Behdad Esfahbod wrote: >>> >>> The idea is that .gitignore files are autogenerated and are NOT stored >>> in the repository. To use, just copy git.mk into your toplevel, add it >>> to git, run "make -f git.mk" and commit all changes it makes to your >>> tree... >> >> If the generated .gitignore is not meant to be committed into the >> repository, maybe the script should edit .git/info/exclude instead ? > > Why? Other than being harder to generate (since current scheme generates > per-dir .gitignore files) and generally a bad idea to touch the .git dir, > "man gitignore" also suggests that that's the wrong place: > > > "Patterns which are specific to a particular repository but which do not > need to be shared with other related repositories (e.g., auxiliary files > that live inside the repository but are specific to one user´s workflow) > should go into the $GIT_DIR/info/exclude file." Yeap, per-repository (local) include files should go to $GIT_DIR/info/exclude. -- Felipe Contreras ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: R: git migration - svn:externals
On Sat, Apr 25, 2009 at 1:17 PM, Felipe Contreras wrote: > On Thu, Apr 23, 2009 at 2:27 PM, Zeeshan Ali (Khattak) > wrote: >> On Thu, Apr 23, 2009 at 1:24 PM, Tim-Philipp Müller wrote: >>> On Thu, 2009-04-23 at 12:09 +0200, Jaap A. Haitsma wrote: >>> I think gst-ffmpeg uses this feature. gst-ffmpeg is in git while it uses ffmpeg which is in svn. >>> >>> Not really - gst-ffmpeg just runs svn checkout in autogen.sh, and that's >>> it. >>> >>> We use git submodules in GStreamer though (we have a 'common' submodule >>> for all other modules), but git submodules are still fairly cumbersome >>> to use and I wouldn't recommend them until the git people make them less >>> painful to use, at least not for projects where the submodule reference >>> needs to be updated frequently. >> >> This whole idea of sub-modules is just brain-dead so I wouldn't >> count on git developers fixing that instead of concentrating on >> features of real importance. If you have some code (or even data) that >> is needed by more than one of your modules/packages, you either put >> that common stuff in another module/package and make other packages >> depend on this or you just bite the bullet and don't mind the >> redundancy. In some cases you just have to wisely use the combination >> of both. > > I'm involved a bit in git development and I have to say that view is > pretty much accurate. > > 'git submodule' is essentially a big hack and nobody from the main > developers is actively working on it. Of course patches are accepted > and support is improving, but I wouldn't recommend any major projects > to depend on it. There was a suggestion at gnome-i18n to have all translation material in a single repository (such as 'lang-LL', where LL is the a lanugage code), and then have a super-lang module with all those individual submodules. Then, any GNOME module would simply need to have the super-lang module as its submodule, to cater for the l10n needs. http://mail.gnome.org/archives/gnome-i18n/2009-January/msg00201.html In theory it looked good; in practice it was quite error-prone due to the sequence of commands that one currently needs to run with git, in order to activate the submodules. And other usability and maintenance issues. Simos ___ 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 8:26 PM, Tristan Van Berkom wrote: > On Tue, Apr 21, 2009 at 12:19 PM, Zeeshan Ali (Khattak) > 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). Sending patches along with the modified ChangeLog would be a complete nightmare. Essentially they'll never apply cleanly and you would always need to resolve the conflicts. This would also make incredibly difficult powerful tasks such as rebasing. Please generate the ChangeLog on 'make dist'. -- Felipe Contreras ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: On autogenerated ChangeLog
On Thu, Apr 23, 2009 at 9:57 AM, Stefan Kost wrote: > Tristan Van Berkom schrieb: >> 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). >> > A git patch has metadata. That is if you use git format-patch then the > commit messages go into the patch and if you use git apply they will be > applied along with the patch. If it was generated with 'git format-patch', then yes, but AFAIK 'git apply' will not use it, you need 'git am' for that. Also, 'git am' can generate commits out of patch series 'git am *.patch'. -- Felipe Contreras ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: On autogenerated ChangeLog
On Wed, Apr 22, 2009 at 1:35 AM, Sam Thursfield wrote: > Hello! > On Tue, Apr 21, 2009 at 6:36 PM, Cody Russell 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/ That applies only for 'git merge', not for other commands such as 'git am' or 'git rebase'. -- Felipe Contreras ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: git commit messages
On Wed, Apr 22, 2009 at 6:09 PM, Christophe Fergeau wrote: > Hi Vincent, > > 2009/4/22 Vincent Untz >> >> - When committing code on behalf of others use the --author option, e.g. >> git commit -a --author "Joe Coder " and --signoff. >> >> >> >> >> Opinions? > > Not sure about the --signoff part. The committer email/name is already > silently added to the commit by git even when using --author. Moreover, When > reading the "12) Sign your work " section of SubmittingPatches from the > linux kernel source ( > http://lxr.linux.no/linux/Documentation/SubmttingPatches ), it seems to me > that using SignedOffBy is useless if the initial author of the patch didn't > use it : > > "The sign-off is a simple line at the end of the explanation for the patch, > which certifies that you wrote it or otherwise have the right to pass it on > as a open-source patch." (snipped a lot of explanations after this sentence) s-o-b lines are useful if you are following a chain-of-trust model. If you wrote the patch, you add your s-o-b, if you reviewed the patch and think it's ok, then you add your s-o-b too. The commit that goes into the main repo will end up having multiple s-o-b lines and if something goes wrong all the people in the s-o-b are to blame. If you commit a patch without reviewing it fully, then don't add your s-o-b. In a distributed model the s-o-b lines help people to decide whether or not to pick commits from other repositories or a mailing list. The more distributed, the more you need s-o-b lines. In GNOME perhaps the needs doesn't seem too high right now, but think about a patch that was developed collaboratively by 4, or 5 people. A single 'committer' and 'author' field is not enough to represent what really happened. -- Felipe Contreras ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: R: git migration - svn:externals
On Sat, Apr 25, 2009 at 3:28 PM, Simos Xenitellis wrote: > On Sat, Apr 25, 2009 at 1:17 PM, Felipe Contreras > wrote: >> On Thu, Apr 23, 2009 at 2:27 PM, Zeeshan Ali (Khattak) >> wrote: >>> On Thu, Apr 23, 2009 at 1:24 PM, Tim-Philipp Müller wrote: On Thu, 2009-04-23 at 12:09 +0200, Jaap A. Haitsma wrote: > I think gst-ffmpeg uses this feature. gst-ffmpeg is in git while it > uses ffmpeg which is in svn. Not really - gst-ffmpeg just runs svn checkout in autogen.sh, and that's it. We use git submodules in GStreamer though (we have a 'common' submodule for all other modules), but git submodules are still fairly cumbersome to use and I wouldn't recommend them until the git people make them less painful to use, at least not for projects where the submodule reference needs to be updated frequently. >>> >>> This whole idea of sub-modules is just brain-dead so I wouldn't >>> count on git developers fixing that instead of concentrating on >>> features of real importance. If you have some code (or even data) that >>> is needed by more than one of your modules/packages, you either put >>> that common stuff in another module/package and make other packages >>> depend on this or you just bite the bullet and don't mind the >>> redundancy. In some cases you just have to wisely use the combination >>> of both. >> >> I'm involved a bit in git development and I have to say that view is >> pretty much accurate. >> >> 'git submodule' is essentially a big hack and nobody from the main >> developers is actively working on it. Of course patches are accepted >> and support is improving, but I wouldn't recommend any major projects >> to depend on it. > > There was a suggestion at gnome-i18n to have all translation material in > a single repository (such as 'lang-LL', where LL is the a lanugage code), > and then have a super-lang module with all those individual submodules. > Then, any GNOME module would simply need to have the super-lang module as > its submodule, to cater for the l10n needs. > http://mail.gnome.org/archives/gnome-i18n/2009-January/msg00201.html > > In theory it looked good; in practice it was quite error-prone due to > the sequence > of commands that one currently needs to run with git, in order to activate the > submodules. And other usability and maintenance issues. I can imagine. That is a good idea, except that instead of submodules you should use 'git remote' and simply merge the sub-repos. The only difference is that in the sub-repo the files need to be in the same place they are going to be in the super-repo. -- Felipe Contreras ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
mailto: now all of a sudden necessary in DOAP file
Hi, I've just tried to add a doap to netspeed. However pushing failed. --- ERROR: netspeed.doap is not valid: Invalid foaf:mbox property should be a mailto: URL Please see: http://live.gnome.org/MaintainersCorner#maintainers --- error: hooks/pre-receive exited with error code 1 If you go the wiki page there is no mailto: URL just an email address in foaf:mbox property So what's the rule does there have to be a mailto: and the wiki page needs to be updated or is it a bug in the commit script. Jaap ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Correcting a typo on gnome websites
Hi, My understanding is that for updating a gnome website I need to checkout the gnomeweb-wml module. However a clone of this module is about 500MB. Cloning such a repo on a slow internet connection takes quite some time. Isn't there a handier way to do this? Thanks Jaap ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: mailto: now all of a sudden necessary in DOAP file
On Sat, 2009-04-25 at 21:35 +0200, Jaap A. Haitsma wrote: > Hi, > > I've just tried to add a doap to netspeed. However pushing failed. > > --- > ERROR: netspeed.doap is not valid: >Invalid foaf:mbox property should be a mailto: URL > > Please see: >http://live.gnome.org/MaintainersCorner#maintainers > --- > error: hooks/pre-receive exited with error code 1 > > If you go the wiki page there is no mailto: URL just an email address > in foaf:mbox property > > So what's the rule does there have to be a mailto: and the wiki page > needs to be updated or is it a bug in the commit script. Any rdf:resource should always be a URL. An email address is not a URL. The correct thing to do is to use a mailto: URL. The fact that Pulse didn't have mailto: in its templates and that we put bogus info on live.gnome.org just shows that we messed up. Sorry for the confusion. -- Shaun ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: mailto: now all of a sudden necessary in DOAP file
On Sat, 2009-04-25 at 15:46 -0500, Shaun McCance wrote: > Any rdf:resource should always be a URL. An email address > is not a URL. The correct thing to do is to use a mailto: > URL. > > The fact that Pulse didn't have mailto: in its templates > and that we put bogus info on live.gnome.org just shows > that we messed up. > > Sorry for the confusion. Does this mean we should all update our doap files? Ruben -- Ruben Vermeersch (rubenv) http://www.savanne.be/ ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: mailto: now all of a sudden necessary in DOAP file
On Sat, 2009-04-25 at 23:58 +0200, Ruben Vermeersch wrote: > On Sat, 2009-04-25 at 15:46 -0500, Shaun McCance wrote: > > Any rdf:resource should always be a URL. An email address > > is not a URL. The correct thing to do is to use a mailto: > > URL. > > > > The fact that Pulse didn't have mailto: in its templates > > and that we put bogus info on live.gnome.org just shows > > that we messed up. > > > > Sorry for the confusion. > > Does this mean we should all update our doap files? That would be preferable. At the moment it's not breaking anything that I know of. For our internal tools, we can account for this hiccup. But if other parts of the world consume these files, they might not understand it. -- Shaun ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: mailto: now all of a sudden necessary in DOAP file
On Sat, 2009-04-25 at 17:08 -0500, Shaun McCance wrote: > On Sat, 2009-04-25 at 23:58 +0200, Ruben Vermeersch wrote: > > On Sat, 2009-04-25 at 15:46 -0500, Shaun McCance wrote: > > > Any rdf:resource should always be a URL. An email address > > > is not a URL. The correct thing to do is to use a mailto: > > > URL. > > > > > > The fact that Pulse didn't have mailto: in its templates > > > and that we put bogus info on live.gnome.org just shows > > > that we messed up. > > > > > > Sorry for the confusion. > > > > Does this mean we should all update our doap files? > > That would be preferable. At the moment it's not > breaking anything that I know of. For our internal > tools, we can account for this hiccup. But if other > parts of the world consume these files, they might > not understand it. Let's not put hacks in our tools barely a week after they're first introduced, please? Philip > -- > Shaun > > > ___ > desktop-devel-list mailing list > desktop-devel-list@gnome.org > http://mail.gnome.org/mailman/listinfo/desktop-devel-list signature.asc Description: This is a digitally signed message part ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
