Re: Code Review Systems Was: [gentoo-dev] Git Migration: launch plan & schedule
On Sat, 4 Jul 2015 20:20:23 +0200 Peter Stuge wrote: > It's important that the review flow is well-understood and efficient. This is impossible in our case due to the lack of manpower. We already have a lot of bugs, patches, stabilization requests hanging over there for months and even years. Stabilization request will require at least two developers to participate in each commit. This will double manpower required at least. Such approach can kill the whole project. Code review is good at a limited scope, e.g. for non-developers where we have review anyway. And as was already told in this thread, the best is the enemy of the good. In no way we should delay git migration due to possible git review. Best regards, Andrew Savchenko pgpaeQblTgCEP.pgp Description: PGP signature
Re: [gentoo-dev] Re: Git workflow
On Sun, Jul 5, 2015 at 11:31 AM, Duncan <1i5t5.dun...@cox.net> wrote: > C Bergström posted on Sun, 05 Jul 2015 01:17:41 +0700 as excerpted: > >> I super don't like "merge" workflows. >> 1) "merge commits" are confusing at best and normal tools don't display >> and work with them as you'd always expect > > git log --graph, as others have mentioned. we are not talking about the same thing. I want to see the "diff" - not the graph. svn diff -r 1234 git show show me the "merge" commit in diff format > > Works fine, at the console, is clear enough to follow, and is part of git > itself and commonly used, so is definitely a "normal" tool for those > using git. > > FWIW, to follow kernel developments during the merge window, I'll > actually run git log showing merges-only (generally confined to author > linus, as well, which pretty effectively limits me to only the master > merges). The merge comments give me a summary of what was committed in > that merge, and I can both skip entire merge categories after reading > only the title or merged tree name, where they're not of interest, and > drill down into merges if I find something covered there of particular > interest. > >> 2) merge commits lead to multiple parents, which breaks a clean and >> simple to follow linear history - > > Ugh! Development isn't linear if there's more than one person working on > a shared tree and making commits to their respective local trees to be > pushed later, at once, and making it appear linear is, plainly stated, a > lie. It's not clean and simple. It's a lie, and maintaining a lie > arguably always ends up more complex than simply stating the truth. Your truth and my truth are are clearly not the same thing. You want to preserve (for some reason) the original commit+date+original parent. To me, development is not "done" at that point. It's just getting started. It's not done in my mind until it's ready to be pushed. For something simple it doesn't really matter does it? I do see your point - I just think in the gentoo model it's unlikely to be relevant WHY is the original parent so important? If someone is working in foo/ category of ebuilds and you're working in bar/ - the parent commit is in all probability in a different category. The original parent commit probably has no value.. (who cares!! honest question) > > If you're not using one of the biggest and best features of git, its > ability to accurately and clearly portray parallel development and where > branches actually branched and merged, why are you using git in the first > place? Huh? Git is "nice" because it's distributed. Using rebase doesn't take away any of the benefits to that. Simply because it's used 'most everywhere else and thus people > tend to have some familiarity with it? That's not an invalid reason, of > course, but if you have ten thousand nails to nail, and a nail gun > plugged in and ready, why are you insisting on using a screwdriver to > pound them in, instead? If you're going to use a screwdriver, why not > use screws and a screw gun (svn, I guess, its commits are even > sequentially numbered, which ought to be heaven, by your definition!)? This is a passionate reply, but it's not very accurate. nail gun vs screw driver? (really?) > > To be clear, since the policy states rebase if possible, I'd do it, but > I'd be internally grousing about it every single time, and that's not > very conducive to remaining happy at one's job over a period of any > significant length, absolutely critical if that job's a volunteer job. Happiness is a state of mind - if this conflicts so strongly with a relgious view - sure I could see it being such a burden. Is doing git pull --rebase before you push really so bad? > > (I'd probably deal with it by scripting it to the extent possible and do > my best to forget about the horrible misuse of perfectly good tool > resources, tho I'd be cursing every time I went to use git log and > couldn't use it properly due to all the lying going on.) Again I don't see it as "lying" - (you're still working on stuff until you push.. development isn't done) The ability to do micro or incremental commits instead of the svn's forced wait approach is the benefit here. Hopefully you could share those scripts with others. Making this workflow easier on everyone is a great thing. I've seen people alias this and I think there's ways in git config to do this as well.
[gentoo-dev] Re: Git workflow
C Bergström posted on Sun, 05 Jul 2015 01:17:41 +0700 as excerpted: > I super don't like "merge" workflows. > 1) "merge commits" are confusing at best and normal tools don't display > and work with them as you'd always expect git log --graph, as others have mentioned. Works fine, at the console, is clear enough to follow, and is part of git itself and commonly used, so is definitely a "normal" tool for those using git. FWIW, to follow kernel developments during the merge window, I'll actually run git log showing merges-only (generally confined to author linus, as well, which pretty effectively limits me to only the master merges). The merge comments give me a summary of what was committed in that merge, and I can both skip entire merge categories after reading only the title or merged tree name, where they're not of interest, and drill down into merges if I find something covered there of particular interest. > 2) merge commits lead to multiple parents, which breaks a clean and > simple to follow linear history - Ugh! Development isn't linear if there's more than one person working on a shared tree and making commits to their respective local trees to be pushed later, at once, and making it appear linear is, plainly stated, a lie. It's not clean and simple. It's a lie, and maintaining a lie arguably always ends up more complex than simply stating the truth. If you're not using one of the biggest and best features of git, its ability to accurately and clearly portray parallel development and where branches actually branched and merged, why are you using git in the first place? Simply because it's used 'most everywhere else and thus people tend to have some familiarity with it? That's not an invalid reason, of course, but if you have ten thousand nails to nail, and a nail gun plugged in and ready, why are you insisting on using a screwdriver to pound them in, instead? If you're going to use a screwdriver, why not use screws and a screw gun (svn, I guess, its commits are even sequentially numbered, which ought to be heaven, by your definition!)? To be clear, since the policy states rebase if possible, I'd do it, but I'd be internally grousing about it every single time, and that's not very conducive to remaining happy at one's job over a period of any significant length, absolutely critical if that job's a volunteer job. (I'd probably deal with it by scripting it to the extent possible and do my best to forget about the horrible misuse of perfectly good tool resources, tho I'd be cursing every time I went to use git log and couldn't use it properly due to all the lying going on.) -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman
Re: [gentoo-dev] Git workflow
On Sun, Jul 5, 2015 at 6:54 AM, Peter Stuge wrote:
> C Bergström wrote:
>> 3) Ever tried to make a patch of the *actual* merge commit? Can one of
>> the advocates of merge show me the git command to do that? (Sure you
>> can diff between 2 commits, but the "merge" commit likes to avoid
>> being seen)
>
> If there are no conflicts when merging then the merge commit does not
> contain any changes, so how could there be a patch? Do you actually
> know the Git data model? I wrote it down the other day.
>
> http://peter.stuge.se/git-data-model
You deflect the question so nicely. If there is no merge conflict then
a rebase would be just fine?
You clearly know git very well - much better than I, why not just
answer the question?
>
>
>> 4) I disagree that even a very active repo will have a problem with
>> rebase - Why?
>> a. If devs aren't working in the same area there will be no conflicts
>> b. If
>
> It's not about conflicts.
>
>
>> and a "git pull --rebase" before push will be clean and fast (no
>> problems).
>
> Q: How do you deal with the two commits from other developers that
> were pushed while you were rebasing?
>
> A: You end up having to spin on the remote repo. That's really clumsy.
Pragmatically - the answer to you question is the same as it exists
today. You're scared of something which gentoo devs have been dealing
with and resolving for years. It's not like CVS/SVN handles this
magically better.
>
>
>> 5) More about linear commits and "history" - I need to double check,
>> but I don't think rebase changes the actual commit date (I could be
>> mistaken).
>
> You are mistaken, and should have double checked before you argued.
>
> Arguing without checking makes you look bad.
How? I didn't claim to know and clearly not knowing didn't seem
important (to me). I'm not trying to overstate anything. I'm just
trying to passionately bring this up. I ***wish*** someone with some
guts would actually take charge of this on the gentoo side, have a
vote or make some executive decision which is stronger than this wimpy
policy we have now.
>
>
>> The only advantage to merge is you could see that the commit
>> happened on the "1st" ${DATE-TIME} of the month
>
> That's not correct.
>
>> I can't say I've ever cared to know the date of a commit, but I can
>> say I have cared a lot about knowing which commit came 1st. Rebase,
>> for better or worse, forces something to be 1st and it's clear and
>> easy to see.
>
> A rebase, like a cherry-pick, loses the very information you claim to
> care about; the original parent of the commit.
To clarify - I don't (clearly) give a pooh what the original parent
was. I care much more about a linear history. I rarely can see any
value of the at-to-time of original commit compared to the final
at-push-time commit (what's rebased). The value of linear history
outweighs the arbitrary point you started from. imho a commit and
development is not done until it's ready to be pushed.
>
>
>> If I controlled the gentoo git server, I'd
>
> I think it's a good thing that you don't, since you seem to still
> need to study Git in more detail.
Peter - I'm ashamed of you - don't be a dick. We can keep this civil
without subtle insults. I understand you are one of the people who
feels strongly about this in the opposing way. I wish I could flip
your way of thinking, but git brings out a lot of strong
religious-like views. (immutable)
Re: [gentoo-dev] Git workflow
On Sat, Jul 4, 2015 at 2:36 PM, Peter Stuge wrote: > C Bergström wrote: > >> 2) merge commits lead to multiple parents, which breaks a clean and >> simple to follow linear history > > This is either a bug or a feature depending on whether development > was actually linear. Sometimes it is, but sometimes it isn't. > This is really the crux of it. This debate has been running on IRC and the lists for well over a year now. I think the proposed workflow on the wiki is as good as any I've seen. In six months we'll probably decide to change it, but I couldn't tell you how today. I'd rather see us move to git and work this stuff out vs just debate the topic endlessly on the lists. The existing cvs structure has its own share of pros and cons. The history is a lot cleaner when you look at individual files. On the other hand, when you look at tree-wide commits it is a complete mess. Even with merges it will be a LOT easier to separate out changes with git. -- Rich
Re: [gentoo-dev] Git workflow
C Bergström wrote:
> 1) Rebase doesn't obscure history,
That's plain wrong. Rebasing changes the parent of your commit. That
means that others can no longer see the history of your commit,
specifically its original parent. Sometimes the parent is irrelevant,
sometimes it is critical.
> (Unless you flatten the commit - which makes things easier and then
> yes does "lose" history, but that's a developer choice
Whether flattening is acceptable or not depends on how crappy commits
the developer has committed on the branch. A firm rule is not possible.
> 2) I don't understand your comment about signatures.
So you didn't know about PGP signed commits and now you do.
> 3) Ever tried to make a patch of the *actual* merge commit? Can one of
> the advocates of merge show me the git command to do that? (Sure you
> can diff between 2 commits, but the "merge" commit likes to avoid
> being seen)
If there are no conflicts when merging then the merge commit does not
contain any changes, so how could there be a patch? Do you actually
know the Git data model? I wrote it down the other day.
http://peter.stuge.se/git-data-model
> 4) I disagree that even a very active repo will have a problem with
> rebase - Why?
> a. If devs aren't working in the same area there will be no conflicts
> b. If
It's not about conflicts.
> and a "git pull --rebase" before push will be clean and fast (no
> problems).
Q: How do you deal with the two commits from other developers that
were pushed while you were rebasing?
A: You end up having to spin on the remote repo. That's really clumsy.
> 5) More about linear commits and "history" - I need to double check,
> but I don't think rebase changes the actual commit date (I could be
> mistaken).
You are mistaken, and should have double checked before you argued.
Arguing without checking makes you look bad.
> The only advantage to merge is you could see that the commit
> happened on the "1st" ${DATE-TIME} of the month
That's not correct.
> I can't say I've ever cared to know the date of a commit, but I can
> say I have cared a lot about knowing which commit came 1st. Rebase,
> for better or worse, forces something to be 1st and it's clear and
> easy to see.
A rebase, like a cherry-pick, loses the very information you claim to
care about; the original parent of the commit.
> If I controlled the gentoo git server, I'd
I think it's a good thing that you don't, since you seem to still
need to study Git in more detail.
//Peter
Re: [gentoo-dev] Git workflow
On 07/04/2015 09:23 PM, C Bergström wrote: > On Sun, Jul 5, 2015 at 1:56 AM, hasufell wrote: >> >> Forcing a rebase-only workflow on developers will increase the amount of >> bad commits. Because non-trivial conflicts in rebases are difficult to >> resolve, since you fix conflicts for _every_ commit separately. > > Not true - you have the choice to flatten the commit. This may not be > ideal, but I consider that way more optimal than some > hack-to-make-it-work "merge" commit. > > To be honest and pragmatic - I don't really see tons of conflicts in > the typical gentoo dev workday. > > The people who own ebuilds and eclasses won't be clobbering each > other. That doesn't happen today and why would switching to git > magically make it start? > > With a rebase workflow - you > a. Rebase frequently for long running branches > b. Branch, rebase and push to master > -- > Lastly - IF for whatever reason gentoo wants to switch to a different > VCS for whatever reason - a linear history would absolutely make that > easier (possible). Lets think 10+ years from now.. > > I'm not a git fanboy - I hope one day it's replaced by something > superior (the same thing could be said about almost any piece of > software and given enough time - it's probably true) > So, you've commented on one of my points and proposed to use a workaround for something that a merge can do properly. I'd say that is bikeshedding (to put it diplomatic). Judging from your more recent answer to this thread it seems you haven't even read the current gentoo git workflow proposal. I suggest you do some research first before continuing this discussion.
Re: [gentoo-dev] rfc: Go ebuilds bundling multiple upstream sources
On 07/04/2015 01:33 PM, Zac Medico wrote: > On 07/04/2015 01:24 PM, William Hubbs wrote: >> What am I missing? > > You need to recognize that "build-time for package A" is not the same as > "build-time for package B". When you build go-tools, you can't rely on > the build-time dependencies of go-net being present. Likewise, you can't > rely on the build-time dependencies of consul being present when > consul-template is built. For example, you should be able to build go-net, unistall go-text, and then build go-tools without go-text installed. Likewise, you should be able to build consul, uninstall go-crypto, and then build consul-template without go-crypto installed. -- Thanks, Zac
Re: [gentoo-dev] Git workflow
On Sun, Jul 5, 2015 at 3:33 AM, Alon Bar-Lev wrote: > On 4 July 2015 at 23:28, Alexandre Rostovtsev wrote: >> >> On Sun, 2015-07-05 at 02:16 +0700, C Bergström wrote: >> > 2) I don't understand your comment about signatures. >> >> Gpg commit signatures [1] which are a requirement for any gentoo git >> workflow. Rebasing breaks the author's signature afaict, so the user >> who is doing rebasing needs to re-sign the commit using his own key. >> >> [1] >> https://git-scm.com/book/tr/v2/Git-Tools-Signing-Your-Work#Signing-Commits >> > > Maybe this is the root cause of all issues, and simpler was to remain > with signed manifests. > Just a thought... Not every git feature out there should be actually > be leveraged. > Doing so would enable rebase without loosing data, more secure (than > SHA-1) signatures, using code review tools such as gerrit without an > issue, migration out of git in future and probably more. > Gpg commit signatures - lol... really? (sorry I realize this is a serious comment) -- I'd agree that the point of security failure would probably be better at actually ensuring the content to the users is correct and valid. +1 for gerrit, but I realize that may be overkill
Re: [gentoo-dev] rfc: Go ebuilds bundling multiple upstream sources
On 07/04/2015 01:24 PM, William Hubbs wrote: > On Sat, Jul 04, 2015 at 12:43:37PM -0700, Zac Medico wrote: >> On 07/04/2015 12:32 PM, William Hubbs wrote: >>> On Sat, Jul 04, 2015 at 12:19:28PM -0700, Zac Medico wrote: On 06/30/2015 03:08 PM, William Hubbs wrote: > The source code is where the compatibility between versions of Go is, > not the static objects, so what if, for third-party go packages, we > skip installing the static objects? > > The only down side of this would be that there might be longer rebuilds > if the packages have multiple consumers, but it gets rid of the static > objects. > > What do you think? I'll give real example involving go-tools. The go-tools build requires go-net, which in turn requires go-text. If the go-net *.a files are installed, then it is possible to build go-tools against go-net without having go-text installed. If the go-net *.a files are not installed, then you will have to install go-text before you can build go-tools. It introduces an indirect build-time dependency between go-tools and go-text. >>> >>> Sure, but what I'm proposing is that we do not install any *.a files >>> for Go software that is not part of dev-lang/go. >> >> Exactly the same type of situation can arise for packages that are not >> part of dev-lang/go. For example, if consul's static api.a library is >> not installed, then it will introduce indirect build-time dependencies >> for the consul-template package. > > Hmm, I haven't looked at either consul or consul-template yet, but I'm > thinking that if you use golang-build.eclass to install everything and > make sure GOPATH is set correctly, consul-template will pick up > everything it needs. > > What am I missing? You need to recognize that "build-time for package A" is not the same as "build-time for package B". When you build go-tools, you can't rely on the build-time dependencies of go-net being present. Likewise, you can't rely on the build-time dependencies of consul being present when consul-template is built. -- Thanks, Zac
Re: [gentoo-dev] Git workflow
On 4 July 2015 at 23:28, Alexandre Rostovtsev wrote: > > On Sun, 2015-07-05 at 02:16 +0700, C Bergström wrote: > > 2) I don't understand your comment about signatures. > > Gpg commit signatures [1] which are a requirement for any gentoo git > workflow. Rebasing breaks the author's signature afaict, so the user > who is doing rebasing needs to re-sign the commit using his own key. > > [1] https://git-scm.com/book/tr/v2/Git-Tools-Signing-Your-Work#Signing-Commits > Maybe this is the root cause of all issues, and simpler was to remain with signed manifests. Just a thought... Not every git feature out there should be actually be leveraged. Doing so would enable rebase without loosing data, more secure (than SHA-1) signatures, using code review tools such as gerrit without an issue, migration out of git in future and probably more.
Re: [gentoo-dev] Git workflow
On Sun, 2015-07-05 at 02:16 +0700, C Bergström wrote: > 2) I don't understand your comment about signatures. Gpg commit signatures [1] which are a requirement for any gentoo git workflow. Rebasing breaks the author's signature afaict, so the user who is doing rebasing needs to re-sign the commit using his own key. [1] https://git-scm.com/book/tr/v2/Git-Tools-Signing-Your-Work#Signing-Commits
Re: [gentoo-dev] rfc: Go ebuilds bundling multiple upstream sources
On Sat, Jul 04, 2015 at 12:43:37PM -0700, Zac Medico wrote: > On 07/04/2015 12:32 PM, William Hubbs wrote: > > On Sat, Jul 04, 2015 at 12:19:28PM -0700, Zac Medico wrote: > >> On 06/30/2015 03:08 PM, William Hubbs wrote: > >>> The source code is where the compatibility between versions of Go is, > >>> not the static objects, so what if, for third-party go packages, we > >>> skip installing the static objects? > >>> > >>> The only down side of this would be that there might be longer rebuilds > >>> if the packages have multiple consumers, but it gets rid of the static > >>> objects. > >>> > >>> What do you think? > >> > >> I'll give real example involving go-tools. The go-tools build requires > >> go-net, which in turn requires go-text. If the go-net *.a files are > >> installed, then it is possible to build go-tools against go-net without > >> having go-text installed. If the go-net *.a files are not installed, > >> then you will have to install go-text before you can build go-tools. It > >> introduces an indirect build-time dependency between go-tools and go-text. > > > > Sure, but what I'm proposing is that we do not install any *.a files > > for Go software that is not part of dev-lang/go. > > Exactly the same type of situation can arise for packages that are not > part of dev-lang/go. For example, if consul's static api.a library is > not installed, then it will introduce indirect build-time dependencies > for the consul-template package. Hmm, I haven't looked at either consul or consul-template yet, but I'm thinking that if you use golang-build.eclass to install everything and make sure GOPATH is set correctly, consul-template will pick up everything it needs. What am I missing? William signature.asc Description: Digital signature
Re: [gentoo-dev] rfc: Go ebuilds bundling multiple upstream sources
On 07/04/2015 12:32 PM, William Hubbs wrote: > On Sat, Jul 04, 2015 at 12:19:28PM -0700, Zac Medico wrote: >> On 06/30/2015 03:08 PM, William Hubbs wrote: >>> The source code is where the compatibility between versions of Go is, >>> not the static objects, so what if, for third-party go packages, we >>> skip installing the static objects? >>> >>> The only down side of this would be that there might be longer rebuilds >>> if the packages have multiple consumers, but it gets rid of the static >>> objects. >>> >>> What do you think? >> >> I'll give real example involving go-tools. The go-tools build requires >> go-net, which in turn requires go-text. If the go-net *.a files are >> installed, then it is possible to build go-tools against go-net without >> having go-text installed. If the go-net *.a files are not installed, >> then you will have to install go-text before you can build go-tools. It >> introduces an indirect build-time dependency between go-tools and go-text. > > Sure, but what I'm proposing is that we do not install any *.a files > for Go software that is not part of dev-lang/go. Exactly the same type of situation can arise for packages that are not part of dev-lang/go. For example, if consul's static api.a library is not installed, then it will introduce indirect build-time dependencies for the consul-template package. -- Thanks, Zac
Re: [gentoo-dev] rfc: Go ebuilds bundling multiple upstream sources
On Sat, Jul 04, 2015 at 12:19:28PM -0700, Zac Medico wrote: > On 06/30/2015 03:08 PM, William Hubbs wrote: > > The source code is where the compatibility between versions of Go is, > > not the static objects, so what if, for third-party go packages, we > > skip installing the static objects? > > > > The only down side of this would be that there might be longer rebuilds > > if the packages have multiple consumers, but it gets rid of the static > > objects. > > > > What do you think? > > I'll give real example involving go-tools. The go-tools build requires > go-net, which in turn requires go-text. If the go-net *.a files are > installed, then it is possible to build go-tools against go-net without > having go-text installed. If the go-net *.a files are not installed, > then you will have to install go-text before you can build go-tools. It > introduces an indirect build-time dependency between go-tools and go-text. Sure, but what I'm proposing is that we do not install any *.a files for Go software that is not part of dev-lang/go. William signature.asc Description: Digital signature
Re: [gentoo-dev] Git workflow
On Sun, Jul 5, 2015 at 1:56 AM, hasufell wrote: > On 07/04/2015 08:17 PM, C Bergström wrote: >> I realize that this is subject to lots of different opinions and that >> my input doesn't carry much weight - At least I thought it's a topic >> that should be brought up (again?) >> - >> To start I hate git.. I have used it for years now and the >> multitude of ways that are possible to accomplish nearly the same >> thing are *annoying* at best.. With that rant out of the way on to the >> point.. >> - >> I super don't like "merge" workflows. >> 1) "merge commits" are confusing at best and normal tools don't >> display and work with them as you'd always expect >> >> 2) merge commits lead to multiple parents, which breaks a clean and >> simple to follow linear history >> - >> >> What I personally prefer is a rebase workflow. >> The downsides >> 1) Requires to you rebase before pushing. Which can be slightly more >> work than just a lazy resolution of the conflicting "merge commit" >> (depending on if you flatten your commits) >> >> 2) May not be the most popular git work-flow. >> >> 3) Due to #2 from above - may have detractors and or less people who >> are familiar with it. >> -- >> I'm of the mindset that if you're going to keep something under >> revision - the history should be clear and clean. Linear is the only >> way to fly for that. For those using cvs or svn - that's what they'll >> be familiar with and probably expect to find in a git log. You can >> start with forcing rebase and keep a clean history - if one day it >> proves too problematic you can switch over to "merging" - the other >> way isn't really possible to do cleanly, depending on your tools.. >> >> Thanks for the minute >> > > Forcing a rebase-only workflow on developers will increase the amount of > bad commits. Because non-trivial conflicts in rebases are difficult to > resolve, since you fix conflicts for _every_ commit separately. Not true - you have the choice to flatten the commit. This may not be ideal, but I consider that way more optimal than some hack-to-make-it-work "merge" commit. To be honest and pragmatic - I don't really see tons of conflicts in the typical gentoo dev workday. The people who own ebuilds and eclasses won't be clobbering each other. That doesn't happen today and why would switching to git magically make it start? With a rebase workflow - you a. Rebase frequently for long running branches b. Branch, rebase and push to master -- Lastly - IF for whatever reason gentoo wants to switch to a different VCS for whatever reason - a linear history would absolutely make that easier (possible). Lets think 10+ years from now.. I'm not a git fanboy - I hope one day it's replaced by something superior (the same thing could be said about almost any piece of software and given enough time - it's probably true)
Re: [gentoo-dev] Git workflow
On Sat, Jul 04, 2015 at 02:33:04PM -0400, NP-Hardass wrote: > > > On July 4, 2015 2:17:41 PM EDT, "C Bergström" > wrote: > >I realize that this is subject to lots of different opinions and that > >my input doesn't carry much weight - At least I thought it's a topic > >that should be brought up (again?) > >- > >To start I hate git.. I have used it for years now and the > >multitude of ways that are possible to accomplish nearly the same > >thing are *annoying* at best.. With that rant out of the way on to the > >point.. Just find a workflow that works for you. Git has a lot of power, but you don't have to know everything about it. :-) > >- > >I super don't like "merge" workflows. > > Just a short note, the last time I read the git workflow on the wiki [0], > rebase of one's commit is suggested with fallback to merge if unable to > rebase. Same here, merge workflows are evil. I can't think of a reason you would be unable to rebase other than, "I don't want to resolve the conflicts, so I'm just going to merge". > > >1) "merge commits" are confusing at best and normal tools don't > >display and work with them as you'd always expect > > It's a GUI, but dev-util/meld provides a pretty nice interface for git merges. guis are irrelivant if you can't use them for one reason or another. > > > > >2) merge commits lead to multiple parents, which breaks a clean and > >simple to follow linear history > >- Agreed. > >What I personally prefer is a rebase workflow. > >The downsides > >1) Requires to you rebase before pushing. Which can be slightly more > >work than just a lazy resolution of the conflicting "merge commit" > >(depending on if you flatten your commits) > > > >2) May not be the most popular git work-flow. > > > >3) Due to #2 from above - may have detractors and or less people who > >are familiar with it. > >-- > >I'm of the mindset that if you're going to keep something under > >revision - the history should be clear and clean. Linear is the only > >way to fly for that. For those using cvs or svn - that's what they'll > >be familiar with and probably expect to find in a git log. You can > >start with forcing rebase and keep a clean history - if one day it > >proves too problematic you can switch over to "merging" - the other > >way isn't really possible to do cleanly, depending on your tools.. I firmly agree. Merge commits are very difficult at best to make any sense out of. The master branch of a repo should be kept clear and clean of those. William signature.asc Description: Digital signature
Re: [gentoo-dev] rfc: Go ebuilds bundling multiple upstream sources
On 06/30/2015 03:08 PM, William Hubbs wrote: > The source code is where the compatibility between versions of Go is, > not the static objects, so what if, for third-party go packages, we > skip installing the static objects? > > The only down side of this would be that there might be longer rebuilds > if the packages have multiple consumers, but it gets rid of the static > objects. > > What do you think? I'll give real example involving go-tools. The go-tools build requires go-net, which in turn requires go-text. If the go-net *.a files are installed, then it is possible to build go-tools against go-net without having go-text installed. If the go-net *.a files are not installed, then you will have to install go-text before you can build go-tools. It introduces an indirect build-time dependency between go-tools and go-text. -- Thanks, Zac
Re: [gentoo-dev] Git workflow
On Sun, Jul 5, 2015 at 1:42 AM, Rich Freeman wrote:
> On Sat, Jul 4, 2015 at 2:17 PM, C Bergström wrote:
>>
>> What I personally prefer is a rebase workflow.
>
> The recommendation is to rebase when practical.
>
> Rebasing makes the history look clean, but it sometimes does this by
> obscuring the real history. It also discards original author commits
> with their signatures and rewrites them without signatures (in theory
> it could add new signatures if the person doing the rebase is the
> author).
>
Without having this conversation - then no logical decision or points
will be brought up. Using git isn't magic. There are downsides to
different work-flows and not having some decision or plan on this will
lead to shit and confusion. Leaders should establish rules, guidelines
or some policy before the migration (!!!)
1) Rebase doesn't obscure history, but it may reorder things out of
chronological order. (Unless you flatten the commit - which makes
things easier and then yes does "lose" history, but that's a developer
choice
2) I don't understand your comment about signatures. I have never seen
author tags lost in a rebase. merge will skrew up git blame more than
rebase any day.
3) Ever tried to make a patch of the *actual* merge commit? Can one of
the advocates of merge show me the git command to do that? (Sure you
can diff between 2 commits, but the "merge" commit likes to avoid
being seen)
4) I disagree that even a very active repo will have a problem with
rebase - Why?
a. If devs aren't working in the same area there will be no conflicts
and a "git pull --rebase" before push will be clean and fast (no
problems).
b. If multiple devs have a conflict - then it would be only the 1st
dev to push to have the easy job. The 2nd dev - regardless of merge or
rebase would have to resolve the conflicts. IF the conflicts can be
auto resolved - that would happen with a merge commit or rebase
anyway. Same amount of work - someone would still have to resolve
problems
5) More about linear commits and "history" - I need to double check,
but I don't think rebase changes the actual commit date (I could be
mistaken). The only advantage to merge is you could see that the
commit happened on the "1st" ${DATE-TIME} of the month - wouldn't have
to manually figure out if that commit was before or after another
commit in the graph. I can't say I've ever cared to know the date of a
commit, but I can say I have cared a lot about knowing which commit
came 1st. Rebase, for better or worse, forces something to be 1st and
it's clear and easy to see.
If I controlled the gentoo git server, I'd set it to forbid merge
commits - at least to start. If that poses *real* problems (not just
random crying) then it could always be relaxed.
Re: [gentoo-dev] Git workflow
On 07/04/2015 08:17 PM, C Bergström wrote: > I realize that this is subject to lots of different opinions and that > my input doesn't carry much weight - At least I thought it's a topic > that should be brought up (again?) > - > To start I hate git.. I have used it for years now and the > multitude of ways that are possible to accomplish nearly the same > thing are *annoying* at best.. With that rant out of the way on to the > point.. > - > I super don't like "merge" workflows. > 1) "merge commits" are confusing at best and normal tools don't > display and work with them as you'd always expect > > 2) merge commits lead to multiple parents, which breaks a clean and > simple to follow linear history > - > > What I personally prefer is a rebase workflow. > The downsides > 1) Requires to you rebase before pushing. Which can be slightly more > work than just a lazy resolution of the conflicting "merge commit" > (depending on if you flatten your commits) > > 2) May not be the most popular git work-flow. > > 3) Due to #2 from above - may have detractors and or less people who > are familiar with it. > -- > I'm of the mindset that if you're going to keep something under > revision - the history should be clear and clean. Linear is the only > way to fly for that. For those using cvs or svn - that's what they'll > be familiar with and probably expect to find in a git log. You can > start with forcing rebase and keep a clean history - if one day it > proves too problematic you can switch over to "merging" - the other > way isn't really possible to do cleanly, depending on your tools.. > > Thanks for the minute > Forcing a rebase-only workflow on developers will increase the amount of bad commits. Because non-trivial conflicts in rebases are difficult to resolve, since you fix conflicts for _every_ commit separately. Additionally, it will also mess up user-branches with user gpg signatures and will hide development information that can be useful. It also complicates working on concurrent branches, a lot (mass cherry-picking is bad, rebasing on already pushed commits is bad too). Whether people use merges or rebases is totally orthogonal to the topic of a "clean git history". It only matters _how_ people use both methods. I'd even say it would achieve the opposite of what you want, at least for a project as large as the gentoo tree. If you have a small project with only one master branch and a very strict review policy, then a rebase-only workflow might work. That said, I don't think this discussion is particularly useful. There's no gain and no strong logical reason (except some personal aesthetical preference) to enforce a rebase-only workflow.
Re: [gentoo-dev] Git workflow
On Sat, Jul 4, 2015 at 2:17 PM, C Bergström wrote: > > What I personally prefer is a rebase workflow. The recommendation is to rebase when practical. Rebasing makes the history look clean, but it sometimes does this by obscuring the real history. It also discards original author commits with their signatures and rewrites them without signatures (in theory it could add new signatures if the person doing the rebase is the author). -- Rich
Re: [gentoo-dev] Git workflow
C Bergström wrote: > To start I hate git.. I have used it for years now and the > multitude of ways that are possible to accomplish nearly the same > thing are *annoying* at best.. I'd be interested to hear a couple of examples of what you mean, perhaps in a private mail. Tack på förhand. :) > I super don't like "merge" workflows. I personally also prefer to rebase, but merge also has strong merits. > 1) "merge commits" are confusing at best and normal tools don't > display and work with them as you'd always expect I'm sure you are absolutely right about the tools. I never bother with anything but the command line git client though, and I think it does a good job of dealing with merges. git log --graph > 2) merge commits lead to multiple parents, which breaks a clean and > simple to follow linear history This is either a bug or a feature depending on whether development was actually linear. Sometimes it is, but sometimes it isn't. The benefit of merge commits being so easy is that it allows a correct historical representation of what development happened when, based on what previous commit. > What I personally prefer is a rebase workflow. Yes, I too like rebasing. But if there is high enough activity in a repository it actually becomes impractical. > The downsides > 1) Requires to you rebase before pushing. Which can be slightly more > work than just a lazy resolution of the conflicting "merge commit" > (depending on if you flatten your commits) Please be more aware of what you're doing. Rebase actually comes with pretty large implications, you are changing the base upon which your work applies. Sometimes this is unproblematic. In those cases, git pull --rebase is just more work than git pull. (But there's git config branch.$name.rebase) The thing about requiring rebase is that things in the base may shift without you knowing it. You really have to do a very careful review of what has happened between the old and new base commit, to know for sure that your stack of commits is still correct at all. This can be a very heavy operation and it pretty much must be manual! Sometimes it's really easy to do this manually. The thing is, rebase does incur this extra manual operation, and it is non-negotiable. A history with merges has much richer information about what happened when, and actually makes it easier to figure out difficult problems. > 2) May not be the most popular git work-flow. > 3) Due to #2 from above - may have detractors and or less people > who are familiar with it. I consider it a much more powerful sword, which thus must be wielded much more carefully. > I'm of the mindset that if you're going to keep something under > revision - the history should be clear and clean. I agree that this is ideal, but it's also very easy to think of real world situations where it is just not practical, and would either result in stalling other developers or increasing the local workload before commit/push is possible, neither of which is desirable. I agree that tools can be a big issue. I would not suggest using anything other than the git command line program. //Peter
Re: [gentoo-dev] Git workflow
On July 4, 2015 2:17:41 PM EDT, "C Bergström" wrote: >I realize that this is subject to lots of different opinions and that >my input doesn't carry much weight - At least I thought it's a topic >that should be brought up (again?) >- >To start I hate git.. I have used it for years now and the >multitude of ways that are possible to accomplish nearly the same >thing are *annoying* at best.. With that rant out of the way on to the >point.. >- >I super don't like "merge" workflows. Just a short note, the last time I read the git workflow on the wiki [0], rebase of one's commit is suggested with fallback to merge if unable to rebase. >1) "merge commits" are confusing at best and normal tools don't >display and work with them as you'd always expect It's a GUI, but dev-util/meld provides a pretty nice interface for git merges. > >2) merge commits lead to multiple parents, which breaks a clean and >simple to follow linear history >- > >What I personally prefer is a rebase workflow. >The downsides >1) Requires to you rebase before pushing. Which can be slightly more >work than just a lazy resolution of the conflicting "merge commit" >(depending on if you flatten your commits) > >2) May not be the most popular git work-flow. > >3) Due to #2 from above - may have detractors and or less people who >are familiar with it. >-- >I'm of the mindset that if you're going to keep something under >revision - the history should be clear and clean. Linear is the only >way to fly for that. For those using cvs or svn - that's what they'll >be familiar with and probably expect to find in a git log. You can >start with forcing rebase and keep a clean history - if one day it >proves too problematic you can switch over to "merging" - the other >way isn't really possible to do cleanly, depending on your tools.. > >Thanks for the minute -- NP-Hardass [0] https://wiki.gentoo.org/wiki/Gentoo_git_workflow
Re: Code Review Systems Was: [gentoo-dev] Git Migration: launch plan & schedule
NP-Hardass wrote: > >> or do they typically restrict review to a certain class of users? > > > >Hm, why would that end up happening? I'm not saying it can't, just > >that I don't understand why it would. What do you have in mind? > > Well, it was just proposed earlier in the thread that it could be > used for non-devs (primarily/only), hence two classes of users, > those subjected to review and those not. Ah I understand. Personally I think review is just as important for devs as for non-devs. The big win with a review tool/flow is that it becomes *at all possible* for non-devs to contribute efficiently to the project, and if the review tool is good then giving review is also efficient. Some will always be more equal than others, but.. > An alternative is a situation where all users, developer and non > developer alike require review I feel that this is the only way to achieve the best quality. > with the review requirements different between the two I don't feel that this is as useful for quality. Devs produce crap too. It's important that the review flow is well-understood and efficient. It's important that everyone working is *motivated* to participate in review. I've had plenty of experience with smart people who simply do not want to participate in a review flow and that's all it takes for the review flow to fail. //Peter
[gentoo-dev] Git workflow
I realize that this is subject to lots of different opinions and that my input doesn't carry much weight - At least I thought it's a topic that should be brought up (again?) - To start I hate git.. I have used it for years now and the multitude of ways that are possible to accomplish nearly the same thing are *annoying* at best.. With that rant out of the way on to the point.. - I super don't like "merge" workflows. 1) "merge commits" are confusing at best and normal tools don't display and work with them as you'd always expect 2) merge commits lead to multiple parents, which breaks a clean and simple to follow linear history - What I personally prefer is a rebase workflow. The downsides 1) Requires to you rebase before pushing. Which can be slightly more work than just a lazy resolution of the conflicting "merge commit" (depending on if you flatten your commits) 2) May not be the most popular git work-flow. 3) Due to #2 from above - may have detractors and or less people who are familiar with it. -- I'm of the mindset that if you're going to keep something under revision - the history should be clear and clean. Linear is the only way to fly for that. For those using cvs or svn - that's what they'll be familiar with and probably expect to find in a git log. You can start with forcing rebase and keep a clean history - if one day it proves too problematic you can switch over to "merging" - the other way isn't really possible to do cleanly, depending on your tools.. Thanks for the minute
Re: Code Review Systems Was: [gentoo-dev] Git Migration: launch plan & schedule
On July 4, 2015 1:49:20 PM EDT, Peter Stuge wrote: > >NP-Hardass wrote: >> I am unfamiliar with how other big projects that use code review >> systems. Do they generally make (almost) everyone participate, > >In coreboot, which admittedly isn't such a big project, my impression >is that the introduction of Gerrit has lead to increased >participation. Previously patches and review went across the mailing >list, and many simply filtered the whole list into a folder. > > >> or do they typically restrict review to a certain class of users? > >Hm, why would that end up happening? I'm not saying it can't, just >that I don't understand why it would. What do you have in mind? > > >//Peter Well, it was just proposed earlier in the thread that it could be used for non-devs (primarily/only), hence two classes of users, those subjected to review and those not. An alternative is a situation where all users, developer and non developer alike require review with the review requirements different between the two, e.g. devs need one signoff, non devs need two. Additionally, for certain aspects, a hybrid of those two might be useful. A project or herd accepts direct commits to its packages from its members and has code review for non members (with the number of signoffs dependent on the group/content. -- NP-Hardass
Re: Code Review Systems Was: [gentoo-dev] Git Migration: launch plan & schedule
William Hubbs wrote: > If we do add a code review system, it should be fully accessible from > the command line. Pybugz is almost there for bugzilla; the only thing it > lacks is the ability to reply to specific comments. Gerrit is also almost there, it has an ssh interface which is very usable for most operations, but not so much for writing inline comments within patches, which is a nice feature of Gerrit that I would like to use. At the moment I have to revert to the web interface to do it. NP-Hardass wrote: > I am unfamiliar with how other big projects that use code review > systems. Do they generally make (almost) everyone participate, In coreboot, which admittedly isn't such a big project, my impression is that the introduction of Gerrit has lead to increased participation. Previously patches and review went across the mailing list, and many simply filtered the whole list into a folder. > or do they typically restrict review to a certain class of users? Hm, why would that end up happening? I'm not saying it can't, just that I don't understand why it would. What do you have in mind? //Peter
Re: Code Review Systems Was: [gentoo-dev] Git Migration: launch plan & schedule
I am unfamiliar with how other big projects that use code review systems. Do they generally make (almost) everyone participate, or do they typically restrict review to a certain class of users? -- NP-Hardass On July 4, 2015 4:14:14 AM EDT, "Manuel Rüger" wrote: >On 03.07.2015 22:22, Robin H. Johnson wrote: >> (Breaking the thread, because I believe this topic needs further >> discussion). >> >> On Fri, Jul 03, 2015 at 03:39:31PM +0200, Manuel Rüger wrote: >>> Are there still any plans to use a code review system like gerrit >that >>> will avoid merges, rebases etc. to the tree by just accepting and >>> serializing patches? >> Merges are a fact of life, they will be happening. >> This was included on: >> https://wiki.gentoo.org/wiki/Gentoo_git_workflow >> >> Rebases of already published commits must be avoided. >> >> But beyond that, the general discussion was that a code review system >> was not in the immediate future... >> >> If the merge workflow becomes too problematic due to the high rate of >> change, then we can revisit those systems, to take advantage of their >> auto-merging functionality, but probably only in combination with the >QA >> testsuites. >> > >Using a Code Review System and allowing direct commits are not mutually >exclusive. >If infra has got time to set it up, this could be an option in addition >to direct commits for developers and we could make it obligatory (e.g. >for the first month) for new developers. > >It would also allow proxied maintainers to commit to the tree more >easily, as it will require just an additional ack by the proxy >maintainer. > >Manuel -- NP-Hardass
Re: Code Review Systems Was: [gentoo-dev] Git Migration: launch plan & schedule
On Sat, Jul 04, 2015 at 10:14:14AM +0200, Manuel Rüger wrote: > On 03.07.2015 22:22, Robin H. Johnson wrote: > > (Breaking the thread, because I believe this topic needs further > > discussion). > > > > On Fri, Jul 03, 2015 at 03:39:31PM +0200, Manuel Rüger wrote: > >> Are there still any plans to use a code review system like gerrit that > >> will avoid merges, rebases etc. to the tree by just accepting and > >> serializing patches? > > Merges are a fact of life, they will be happening. > > This was included on: > > https://wiki.gentoo.org/wiki/Gentoo_git_workflow > > > > Rebases of already published commits must be avoided. > > > > But beyond that, the general discussion was that a code review system > > was not in the immediate future... > > > > If the merge workflow becomes too problematic due to the high rate of > > change, then we can revisit those systems, to take advantage of their > > auto-merging functionality, but probably only in combination with the QA > > testsuites. > > > > Using a Code Review System and allowing direct commits are not mutually > exclusive. > If infra has got time to set it up, this could be an option in addition > to direct commits for developers and we could make it obligatory (e.g. > for the first month) for new developers. > > It would also allow proxied maintainers to commit to the tree more > easily, as it will require just an additional ack by the proxy maintainer. If we do add a code review system, it should be fully accessible from the command line. Pybugz is almost there for bugzilla; the only thing it lacks is the ability to reply to specific comments. William signature.asc Description: Digital signature
Re: Code Review Systems Was: [gentoo-dev] Git Migration: launch plan & schedule
On 03.07.2015 22:22, Robin H. Johnson wrote: > (Breaking the thread, because I believe this topic needs further > discussion). > > On Fri, Jul 03, 2015 at 03:39:31PM +0200, Manuel Rüger wrote: >> Are there still any plans to use a code review system like gerrit that >> will avoid merges, rebases etc. to the tree by just accepting and >> serializing patches? > Merges are a fact of life, they will be happening. > This was included on: > https://wiki.gentoo.org/wiki/Gentoo_git_workflow > > Rebases of already published commits must be avoided. > > But beyond that, the general discussion was that a code review system > was not in the immediate future... > > If the merge workflow becomes too problematic due to the high rate of > change, then we can revisit those systems, to take advantage of their > auto-merging functionality, but probably only in combination with the QA > testsuites. > Using a Code Review System and allowing direct commits are not mutually exclusive. If infra has got time to set it up, this could be an option in addition to direct commits for developers and we could make it obligatory (e.g. for the first month) for new developers. It would also allow proxied maintainers to commit to the tree more easily, as it will require just an additional ack by the proxy maintainer. Manuel signature.asc Description: OpenPGP digital signature
