From: Cedric B. <ced...@fr...> - 2013-02-27 12:54:44
|
On Wed, Feb 27, 2013 at 1:05 PM, Shinwoo Kim - Enlightenment Git <no-...@en...> wrote: > kimcinoo pushed a commit to branch master. > > commit 758a84179c6079da04a83cb571a5c262175636c3 > Merge: df32101 4d78961 > Author: Shinwoo Kim <cin...@sa...> > Date: Wed Feb 27 21:05:41 2013 +0900 > > Merge branch 'master' of ssh://git.enlightenment.org/core/elementary It would be better to avoid merge as they hide information in the commit mail. > src/bin/test_entry.c | 9 +++++++++ > src/lib/elm_entry.c | 23 +++++++++++++++++++++-- > src/lib/elm_entry.h | 40 ++++++++++++++++++++++++++++++++++++++++ > src/lib/elm_widget_entry.h | 1 - > 4 files changed, 70 insertions(+), 3 deletions(-) > > -- > > ------------------------------------------------------------------------------ > Everyone hates slow websites. So do we. > Make your web apps faster with AppDynamics > Download AppDynamics Lite for free today: > http://p.sf.net/sfu/appdyn_d2d_feb > -- Cedric BAIL |
From: Tom H. <tom...@sa...> - 2013-02-27 13:01:58
|
On 27/02/13 12:53, Cedric BAIL wrote: > On Wed, Feb 27, 2013 at 1:05 PM, Shinwoo Kim - Enlightenment Git > <no-...@en...> wrote: >> kimcinoo pushed a commit to branch master. >> >> commit 758a84179c6079da04a83cb571a5c262175636c3 >> Merge: df32101 4d78961 >> Author: Shinwoo Kim <cin...@sa...> >> Date: Wed Feb 27 21:05:41 2013 +0900 >> >> Merge branch 'master' of ssh://git.enlightenment.org/core/elementary > > It would be better to avoid merge as they hide information in the commit mail. And in the history... :( Rebase guys, rebase! :) -- Tom. |
From: Rafael A. <ant...@gm...> - 2013-02-27 14:13:35
|
Is it possible to prevent pushes of patches that include a merge commit? Or at least require a push -f? On Wed, Feb 27, 2013 at 10:00 AM, Tom Hacohen <tom...@sa...> wrote: > On 27/02/13 12:53, Cedric BAIL wrote: >> On Wed, Feb 27, 2013 at 1:05 PM, Shinwoo Kim - Enlightenment Git >> <no-...@en...> wrote: >>> kimcinoo pushed a commit to branch master. >>> >>> commit 758a84179c6079da04a83cb571a5c262175636c3 >>> Merge: df32101 4d78961 >>> Author: Shinwoo Kim <cin...@sa...> >>> Date: Wed Feb 27 21:05:41 2013 +0900 >>> >>> Merge branch 'master' of ssh://git.enlightenment.org/core/elementary >> >> It would be better to avoid merge as they hide information in the commit mail. > > And in the history... :( > Rebase guys, rebase! :) > > -- > Tom. > > > ------------------------------------------------------------------------------ > Everyone hates slow websites. So do we. > Make your web apps faster with AppDynamics > Download AppDynamics Lite for free today: > http://p.sf.net/sfu/appdyn_d2d_feb > _______________________________________________ > enlightenment-devel mailing list > enl...@li... > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel -- Rafael Antognolli http://antognolli.org/ |
From: Eduardo L. (Etrunko) <eb...@gm...> - 2013-02-27 14:18:28
|
On Wed, Feb 27, 2013 at 11:13 AM, Rafael Antognolli <ant...@gm...> wrote: > Is it possible to prevent pushes of patches that include a merge > commit? Or at least require a push -f? > Don't do that, as said, sometimes a merge is actually a good idea. But should not be the standard. What we need is to educate people to do the things right, even though it requires applying some penalties in the meantime. > On Wed, Feb 27, 2013 at 10:00 AM, Tom Hacohen <tom...@sa...> wrote: >> On 27/02/13 12:53, Cedric BAIL wrote: >>> On Wed, Feb 27, 2013 at 1:05 PM, Shinwoo Kim - Enlightenment Git >>> <no-...@en...> wrote: >>>> kimcinoo pushed a commit to branch master. >>>> >>>> commit 758a84179c6079da04a83cb571a5c262175636c3 >>>> Merge: df32101 4d78961 >>>> Author: Shinwoo Kim <cin...@sa...> >>>> Date: Wed Feb 27 21:05:41 2013 +0900 >>>> >>>> Merge branch 'master' of ssh://git.enlightenment.org/core/elementary >>> >>> It would be better to avoid merge as they hide information in the commit mail. >> >> And in the history... :( >> Rebase guys, rebase! :) >> >> -- >> Tom. >> >> >> ------------------------------------------------------------------------------ >> Everyone hates slow websites. So do we. >> Make your web apps faster with AppDynamics >> Download AppDynamics Lite for free today: >> http://p.sf.net/sfu/appdyn_d2d_feb >> _______________________________________________ >> enlightenment-devel mailing list >> enl...@li... >> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > > > > -- > Rafael Antognolli > http://antognolli.org/ > > ------------------------------------------------------------------------------ > Everyone hates slow websites. So do we. > Make your web apps faster with AppDynamics > Download AppDynamics Lite for free today: > http://p.sf.net/sfu/appdyn_d2d_feb > _______________________________________________ > enlightenment-devel mailing list > enl...@li... > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel -- Eduardo de Barros Lima ◤✠◢ eb...@gm... |
From: Tom H. <tom...@sa...> - 2013-02-27 14:28:49
|
On 27/02/13 14:13, Rafael Antognolli wrote: > Is it possible to prevent pushes of patches that include a merge > commit? Or at least require a push -f? There is a way, but unfortunately it'll also prevent wanted merges. As Eduardo as said, we should probably just educate people. -- Tom. |
From: Rafael A. <ant...@gm...> - 2013-02-27 14:38:08
|
What about requiring push -f? On Wed, Feb 27, 2013 at 11:29 AM, Tom Hacohen <tom...@sa...> wrote: > On 27/02/13 14:13, Rafael Antognolli wrote: >> >> Is it possible to prevent pushes of patches that include a merge >> commit? Or at least require a push -f? > > > There is a way, but unfortunately it'll also prevent wanted merges. As > Eduardo as said, we should probably just educate people. > > -- > Tom. > -- Rafael Antognolli http://antognolli.org/ |
From: Tom H. <tom...@sa...> - 2013-02-27 14:44:29
|
On 27/02/13 14:38, Rafael Antognolli wrote: > What about requiring push -f? Do you know how to do that? I'd love having that. -- Tom. |
From: Rafael A. <ant...@gm...> - 2013-02-27 15:02:47
|
OK, I don't, but here's another idea: on the update script (or wherever you are doing this), we only allow specific people who are already very familiar with git to do merge commits. Would this be reasonable? On Wed, Feb 27, 2013 at 11:44 AM, Tom Hacohen <tom...@sa...> wrote: > On 27/02/13 14:38, Rafael Antognolli wrote: >> >> What about requiring push -f? > > > Do you know how to do that? I'd love having that. > > -- > Tom. > -- Rafael Antognolli http://antognolli.org/ |
From: Lucas De M. <luc...@pr...> - 2013-03-01 00:48:44
|
On Wed, Feb 27, 2013 at 11:44 AM, Tom Hacohen <tom...@sa...> wrote: > On 27/02/13 14:38, Rafael Antognolli wrote: >> What about requiring push -f? > > Do you know how to do that? I'd love having that. If git >= 1.6 is running on the server, all you need to do is set the configuration: receive.denyNonFastForwards Otherwise you need an update/pre-receive hook checking if "git rev-list $newrev..$oldrev" is empty in order to accept the push. Lucas De Marchi |
From: Tom H. <tom...@sa...> - 2013-02-27 15:05:25
|
On 27/02/13 15:02, Rafael Antognolli wrote: > OK, I don't, but here's another idea: on the update script (or > wherever you are doing this), we only allow specific people who are > already very familiar with git to do merge commits. > > Would this be reasonable? We can easily do that, but is that wanted? -- Tom. |
From: Iván B. <sac...@gm...> - 2013-02-27 15:08:58
|
On Wed, Feb 27, 2013 at 12:05 PM, Tom Hacohen <tom...@sa...> wrote: > On 27/02/13 15:02, Rafael Antognolli wrote: >> OK, I don't, but here's another idea: on the update script (or >> wherever you are doing this), we only allow specific people who are >> already very familiar with git to do merge commits. >> >> Would this be reasonable? > > We can easily do that, but is that wanted? For a while at least? To keep people from blindly pushing merges when not needed? It's much more likely they'll learn if their push fails than reading mails from us saying "oh, hey, it would be nice to avoid merges like that. Please rebase." > > -- > Tom. > > > ------------------------------------------------------------------------------ > Everyone hates slow websites. So do we. > Make your web apps faster with AppDynamics > Download AppDynamics Lite for free today: > http://p.sf.net/sfu/appdyn_d2d_feb > _______________________________________________ > enlightenment-devel mailing list > enl...@li... > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel |
From: Rafael A. <ant...@gm...> - 2013-02-27 15:12:36
|
Yeah, and the policy can be quite simple: give merge permission to whoever asks for it, assuming that they know what they are doing, and revoke that permission if they show to not understand how it works. I don't know if this is too much work though. On Wed, Feb 27, 2013 at 12:08 PM, Iván Briano <sac...@gm...> wrote: > On Wed, Feb 27, 2013 at 12:05 PM, Tom Hacohen <tom...@sa...> wrote: >> On 27/02/13 15:02, Rafael Antognolli wrote: >>> OK, I don't, but here's another idea: on the update script (or >>> wherever you are doing this), we only allow specific people who are >>> already very familiar with git to do merge commits. >>> >>> Would this be reasonable? >> >> We can easily do that, but is that wanted? > > For a while at least? To keep people from blindly pushing merges > when not needed? It's much more likely they'll learn if their push > fails than reading mails from us saying "oh, hey, it would be nice > to avoid merges like that. Please rebase." > >> >> -- >> Tom. >> >> >> ------------------------------------------------------------------------------ >> Everyone hates slow websites. So do we. >> Make your web apps faster with AppDynamics >> Download AppDynamics Lite for free today: >> http://p.sf.net/sfu/appdyn_d2d_feb >> _______________________________________________ >> enlightenment-devel mailing list >> enl...@li... >> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel -- Rafael Antognolli http://antognolli.org/ |
From: Rafael A. <ant...@gm...> - 2013-02-27 15:13:42
|
Ah, and there should be few people needing such permission. For instance, I still can't imagine a situation where I would need it. On Wed, Feb 27, 2013 at 12:12 PM, Rafael Antognolli <ant...@gm...> wrote: > Yeah, and the policy can be quite simple: give merge permission to > whoever asks for it, assuming that they know what they are doing, and > revoke that permission if they show to not understand how it works. > > I don't know if this is too much work though. > > On Wed, Feb 27, 2013 at 12:08 PM, Iván Briano <sac...@gm...> wrote: >> On Wed, Feb 27, 2013 at 12:05 PM, Tom Hacohen <tom...@sa...> wrote: >>> On 27/02/13 15:02, Rafael Antognolli wrote: >>>> OK, I don't, but here's another idea: on the update script (or >>>> wherever you are doing this), we only allow specific people who are >>>> already very familiar with git to do merge commits. >>>> >>>> Would this be reasonable? >>> >>> We can easily do that, but is that wanted? >> >> For a while at least? To keep people from blindly pushing merges >> when not needed? It's much more likely they'll learn if their push >> fails than reading mails from us saying "oh, hey, it would be nice >> to avoid merges like that. Please rebase." >> >>> >>> -- >>> Tom. >>> >>> >>> ------------------------------------------------------------------------------ >>> Everyone hates slow websites. So do we. >>> Make your web apps faster with AppDynamics >>> Download AppDynamics Lite for free today: >>> http://p.sf.net/sfu/appdyn_d2d_feb >>> _______________________________________________ >>> enlightenment-devel mailing list >>> enl...@li... >>> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > > > > -- > Rafael Antognolli > http://antognolli.org/ -- Rafael Antognolli http://antognolli.org/ |
From: Tom H. <tom...@sa...> - 2013-02-27 15:19:07
|
On 27/02/13 15:13, Rafael Antognolli wrote: > Ah, and there should be few people needing such permission. For > instance, I still can't imagine a situation where I would need it. Yeah. Well, the only time you might want to need it is if you'd like to merge your topic branch, but I think rebasing on top of master is better anyway. I don't see a point in merging as well, so... -- Tom. |
From: Kim S. <kim...@gm...> - 2013-02-28 04:20:50
|
omg thanks for messages :) i will do rebase surely. cordially, shinwoo kim. On Thu, Feb 28, 2013 at 12:19 AM, Tom Hacohen <tom...@sa...>wrote: > On 27/02/13 15:13, Rafael Antognolli wrote: > > Ah, and there should be few people needing such permission. For > > instance, I still can't imagine a situation where I would need it. > > Yeah. Well, the only time you might want to need it is if you'd like to > merge your topic branch, but I think rebasing on top of master is better > anyway. I don't see a point in merging as well, so... > > -- > Tom. > > > > ------------------------------------------------------------------------------ > Everyone hates slow websites. So do we. > Make your web apps faster with AppDynamics > Download AppDynamics Lite for free today: > http://p.sf.net/sfu/appdyn_d2d_feb > _______________________________________________ > enlightenment-devel mailing list > enl...@li... > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > |
From: Peter K. <pet...@ax...> - 2013-03-07 08:52:04
|
> -----Original Message----- > From: Tom Hacohen [mailto:tom...@sa...] > Sent: den 27 februari 2013 16:19 > To: Enlightenment developer list > Cc: enl...@li...; Cedric BAIL > Subject: Re: [E-devel] [EGIT] [core/elementary] master 02/02: Merge > branch 'master' of ssh://git.enlightenment.org/core/elementary > > On 27/02/13 15:13, Rafael Antognolli wrote: > > Ah, and there should be few people needing such permission. For > > instance, I still can't imagine a situation where I would need it. > > Yeah. Well, the only time you might want to need it is if you'd like to > merge your topic branch, but I think rebasing on top of master is > better anyway. I don't see a point in merging as well, so... > > -- > Tom. Using rebase simplifies the history, no doubt about that. And for a project where you have multiple people with push access it may be easier for everyone. And if you are used to SVN this is probably easier as well. ;) However, the benefit of using merge to integrate topic branches is that you can tell which commits make up a change. At the company I work for we even require that all topic branches are merged using --no-ff, i.e., there will be an explicit merge even if a fast forward merge would have been possible. That way, if a change (which can be made up of multiple commits) needs to be reverted, we can easily see which commits are involved. Another situation where merging topic branches is more beneficial is if you have to maintain multiple versions of your code at the same time. This is typically done using multiple target branches (master being one of them). If you use rebasing you would have to duplicate your changes for each target branch. Using merge, as long as the topic branch was branched off from a point prior to the starting point of each target branch, you can just merge the topic branch into each target branch where it is appropriate. //Peter |
From: Tom H. <tom...@sa...> - 2013-03-01 22:06:38
|
On 28/02/13 20:35, Lucas De Marchi wrote: > On Wed, Feb 27, 2013 at 11:44 AM, Tom Hacohen <tom...@sa...> wrote: >> On 27/02/13 14:38, Rafael Antognolli wrote: >>> What about requiring push -f? >> >> Do you know how to do that? I'd love having that. > > If git >= 1.6 is running on the server, all you need to do is set the > configuration: > > receive.denyNonFastForwards > > Otherwise you need an update/pre-receive hook checking if "git > rev-list $newrev..$oldrev" is empty in order to accept the push. > The problem with that is that it'll also prevent "normal" (topic branch) merges, won't it? We can control allowing/disallowing merges per user, but that's not what we really want as well (actually, I'm all in favour of banning merges, but that's just me). -- Tom. |
From: Tom H. <tom...@sa...> - 2013-03-07 10:14:29
|
On 07/03/13 08:49, Peter Kjellerstedt wrote: >> -----Original Message----- >> From: Tom Hacohen [mailto:tom...@sa...] >> Sent: den 27 februari 2013 16:19 >> To: Enlightenment developer list >> Cc: enl...@li...; Cedric BAIL >> Subject: Re: [E-devel] [EGIT] [core/elementary] master 02/02: Merge >> branch 'master' of ssh://git.enlightenment.org/core/elementary >> >> On 27/02/13 15:13, Rafael Antognolli wrote: >>> Ah, and there should be few people needing such permission. For >>> instance, I still can't imagine a situation where I would need it. >> >> Yeah. Well, the only time you might want to need it is if you'd like to >> merge your topic branch, but I think rebasing on top of master is >> better anyway. I don't see a point in merging as well, so... >> >> -- >> Tom. > > Using rebase simplifies the history, no doubt about that. And for a > project where you have multiple people with push access it may be > easier for everyone. And if you are used to SVN this is probably > easier as well. ;) > > However, the benefit of using merge to integrate topic branches is > that you can tell which commits make up a change. At the company I > work for we even require that all topic branches are merged using > --no-ff, i.e., there will be an explicit merge even if a fast forward > merge would have been possible. That way, if a change (which can be > made up of multiple commits) needs to be reverted, we can easily see > which commits are involved. > > Another situation where merging topic branches is more beneficial is > if you have to maintain multiple versions of your code at the same > time. This is typically done using multiple target branches (master > being one of them). If you use rebasing you would have to duplicate > your changes for each target branch. Using merge, as long as the > topic branch was branched off from a point prior to the starting > point of each target branch, you can just merge the topic branch > into each target branch where it is appropriate. Yes, I complete agree with your point about the topic branch and --no-ff. Daniel and I actually talked about it the other day and I came to the conclusion I'd like to do something really nice: Rebase a topic branch, and then merge with no-ff. This means that the merge commit will always appear but will always be empty. This will make a bunch of commits package into their own stream while still retaining the benefits of having linear history. However, the whole rebase only policy is just for the meanwhile, until we decide how exactly we would like to do everything. -- Tom. |