+1 I strongly agree.
Commit id title is inconvenient.
2013. 2. 18. 오후 1:04에 "Daniel Juyung Seo" <seojuyung2@...>님이 작성:
> And it'll be great if the title includes the first line of commit message.
> That should be way more useful.
> Thanks.
>
> Daniel Juyung Seo (SeoZ)
>
> On Mon, Feb 18, 2013 at 10:14 AM, ChunEon Park <hermet@...> wrote:
>
> > By the way, Daniel,
> >
> > Could it possible to make git mail title messages to be more meaningful?
> >
> > i.e) [core/efl] xxxmaster updated.
> f27ff2fbf31a01c2f8d98e773bed6cc4298749bd
> > -> [core/efl/evas] xxxmaster updated.
> > f27ff2fbf31a01c2f8d98e773bed6cc4298749bd
> >
> > If the title shows any detailed core lib name that was changed, it would
> > be better to know what is changed in abstractly.
> >
> > -Regards, Hermet-
> >
> > -----Original Message-----
> > From: "David Seikel"<onefang@...>
> > To: <enlightenment-devel@...>;
> > Cc:
> > Sent: 2013-02-16 (토) 16:19:58
> > Subject: Re: [E-devel] SVN->Git Migration (was: (no subject))
> >
> > On Sat, 16 Feb 2013 15:42:46 +0900 Jérôme Pinot <ngc891>@gmail.com>
> > wrote:
> >
> > > On 02/16/13 15:58, David Seikel wrote:
> > > > On Fri, 15 Feb 2013 11:56:06 -0200 Rafael Antognolli
> > > > <antognolli>@gmail.com> wrote:
> > > >
> > > > > Hi David,
> > > > >
> > > > > On Thu, Feb 14, 2013 at 9:12 AM, David Seikel <onefang>@gmail.com>
> > > > > wrote:
> > > > > > On Thu, 14 Feb 2013 08:53:22 -0200 Bruno Dilly
> > > > > > <bdilly>@profusion.mobi> wrote:
> > > > > >
> > > > > >> On Wed, Feb 13, 2013 at 8:42 AM, Daniel Willmann
> > > > > >> <d.willmann>@samsung.com> wrote:
> > > > > >> > On 13/02/13 00:36, Bruno Dilly wrote:
> > > > > >> >> On Mon, Feb 11, 2013 at 2:07 PM, Daniel Willmann
> > > > > >> >> <d.willmann>@samsung.com> wrote:
> > > > > >> >>>
> > > > > >> >>> Topic branches:
> > > > > >> >>> * In each repository every developer with commit access
> > > > > >> >>> will be able to push/update branches in their own namespace
> > > > > >> >>> (devs/<name>/*). These branches will allow non-fastforward
> > > > > >> >>> updates and no one should expect these to be stable.
> > > > > >> >>> * This is a testing ground for developers where new
> > > > > >> >>> features can be developed, debugged and shared with fellow
> > > > > >> >>> developers. Ideally any new feature would live in its own
> > > > > >> >>> branch until it matures and is merged into master.
> > > > > >> >>
> > > > > >> >> Hey Daniel,
> > > > > >> >>
> > > > > >> >> It's a nice proposal, but what about master branch
> > > > > >> >> permissions ? Every developer would be allowed to push
> > > > > >> >> stuff on there (with a flow similar to svn) ? Or we'll try
> > > > > >> >> to establish some kind of policy about it (maintainers,
> > > > > >> >> review, etc) ?
> > > > > >> >
> > > > > >> > As others have already pointed out there seems to be
> > > > > >> > consensus that we don't have enough manpower to work with an
> > > > > >> > integrator workflow (whether or not that's true I don't
> > > > > >> > know).
> > > > > >>
> > > > > >> ok, I got it.
> > > > > >>
> > > > > >> >
> > > > > >> > What I want to achieve with the topic branches is that
> > > > > >> > whoever wants to can maintain an integrator-like workflow.
> > > > > >> > You develop your feature in a topic branch, then post a
> > > > > >> > request for review/review and test yourself and if
> > > > > >> > everything looks good you can merge into master.
> > > > > >> >
> > > > > >> > Speaking of merging...is there any preference on merge vs.
> > > > > >> > rebase?
> > > > > >> >
> > > > > >> > Lots of small merges can really pollute your history and I
> > > > > >> > don't really like them. For larger topic branches I think
> > > > > >> > merging makes sense.
> > > > > >>
> > > > > >> I agree with Tom here.
> > > > > >> I'm always trying to keep a linear history, focusing on rebases
> > > > > >> instead of merges.
> > > > > >> We've used this approach on Profusion projects for years and it
> > > > > >> worked fine so far.
> > > > > >>
> > > > > >> Maybe it will give you a little bit more work, you'll have to
> > > > > >> fix conflicts in the commits it happens instead of only once
> > > > > >> in a final merge commit, but it will be nicer to review or look
> > > > > >> for issues later, imo.
> > > > > >>
> > > > > >> Using the merge approach, in a project with so many commiters
> > > > > >> could lead us to a very confuse history.
> > > > > >
> > > > > > If the history is confused, then that's what it should show. I
> > > > > > really don't like the idea of rewriting history just to make it
> > > > > > easier for some people. Sometimes you just need to track down
> > > > > > what actually happened, not the convenient lie we tell
> > > > > > ourselves is what happened.
> > > > >
> > > > > I don't think those that a rebased branch history is a lie. Each
> > > > > commit will still have the original commit date (if the author
> > > > > did not change it). You can use that to know when the feature
> > > > > started to be developed.
> > > >
> > > > It is a lie, it's changing the history to say it was all done one
> > > > after the other, when in fact a major feature of distributed
> > > > development was used to branch then merge. It was not done in a
> > > > linear fashion, thus making it be linear after the fact is not
> > > > representing the truth. Sure SOME parts of the commit history are
> > > > still the truth, but not all.
> > > >
> > > > > OK, you lose a way to track the parent commit for that feature
> > > > > branch, but on the other hand you earn something important here:
> > > > > the knowledge that the commits from that feature branch will
> > > > > apply correctly on top of the current state of the tree, without
> > > > > a magic merge commit fixing stuff later since some things on the
> > > > > tree are not exactly as they seem to be in the diff from this
> > > > > commit. The changes that appear in the diff from a given commit
> > > > > are exactly what that commit is doing.
> > > >
> > > > That's what I'm saying, loosing information to make things more
> > > > convenient. I'd prefer to err on the side of not loosing
> > > > information. But then again, I'm a hoarder. B-)
> > > >
> > > > > I know that this is not a poll, but I particularly prefer rebased
> > > > > branches/commits too.
> > >
> > > LWN has a neat article about the git rebase thing:
> > > http://lwn.net/Articles/328436/
> > >
> > > "Thou Shalt Not Rebase Trees With History Visible To Others"
> >
> > I was easily able to come up with many "rebase is evil" things with a
> > web search engine, and it turned up a few "rebase is not evil" things as
> > well.
> >
> > --
> > A big old stinking pile of genius that no one wants
> > coz there are too many silver coated monkeys in the world.
> >
> >
> >
> ------------------------------------------------------------------------------
> > The Go Parallel Website, sponsored by Intel - in partnership with
> Geeknet,
> > is your hub for all things parallel software development, from weekly
> > thought
> > leadership blogs to news, videos, case studies, tutorials, tech docs,
> > whitepapers, evaluation guides, and opinion stories. Check out the most
> > recent posts - join the conversation now.
> > http://goparallel.sourceforge.net/
> > _______________________________________________
> > enlightenment-devel mailing list
> > enlightenment-devel@...
> > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
> >
> >
> >
> ------------------------------------------------------------------------------
> > The Go Parallel Website, sponsored by Intel - in partnership with
> Geeknet,
> > is your hub for all things parallel software development, from weekly
> > thought
> > leadership blogs to news, videos, case studies, tutorials, tech docs,
> > whitepapers, evaluation guides, and opinion stories. Check out the most
> > recent posts - join the conversation now.
> > http://goparallel.sourceforge.net/
> > _______________________________________________
> > enlightenment-devel mailing list
> > enlightenment-devel@...
> > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
> >
>
> ------------------------------------------------------------------------------
> The Go Parallel Website, sponsored by Intel - in partnership with Geeknet,
> is your hub for all things parallel software development, from weekly
> thought
> leadership blogs to news, videos, case studies, tutorials, tech docs,
> whitepapers, evaluation guides, and opinion stories. Check out the most
> recent posts - join the conversation now.
> http://goparallel.sourceforge.net/
> _______________________________________________
> enlightenment-devel mailing list
> enlightenment-devel@...
> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
>
|