I too have no idea where this "history limit" comes into play. I work on and have repos spaning 50-100 developers working on dozens of thousands of branches over two dozen repos with almost 8 years of history. Some people rebase, but most people don't.
It is extremely easy to have a clean history due to the fact we enforce the "[COMPONENT] Description" commit message (and can use a git hook to make sure it looks this way). It is then trivial to write a script that only looks for those commits. Heck you can even auto-squash/rebase anything that doesn't match. That being said, that type of "dirty history" only happens if you heavily work with branches. That's not how reactos developers work -- we don't open PRs and separate branches for every checkin. These ALL sound like manufactured problems or poor/strange use of git. On Thu, Feb 16, 2017 at 12:02 AM David Quintana (gigaherz) < gigah...@gmail.com> wrote: > If git has an upper limit on history, it's the first time I hear about it, > and it would be an issue I was simply not aware of. So far as I was aware, > git just keeps a parent hash on each commit, and the GC just deletes > commits without any reference. In fact, we use Git at my current job, and > the history goes back many years, and it seems perfectly capable of > tracking it. And no, we don't rebase or squash, ever. We are not allowed to > do any operation that changes commit history. So it's quite a mess of merge > commits, but even then it's manageable. > > I disagree on needing a single person responsible for merges. The the PR > workflow we have at my current job is that the developer submits a PR for > review, and adds to the PR two other developers, who have to approve the > changes or request fixes. Once it's approved, the original developer can > click the merge button themselves. For external PRs done by contributors, > then one of the reviewers is the responsible for clicking the merge button. > > And even if you do choose to require a commit-master, with the way > github's merge button works, you can choose to have a merge commit, or to > squash & rebase implicitly, and the history ends up with one single commit > attributed to all the developers that were involved in the merge. As an > example, I have a hobby writing Minecraft mods, and they use Forge to work: > https://github.com/MinecraftForge/MinecraftForge/commits/1.11.x -- you'll > see many "<someone> commited with LexManos". That's because there's an > author, and a commiter, in the git info. > > I do agree, git history can get messy, and ugly, and hard to track -- if > you abuse merge commits. I, unlike Alex, am a fan of manual rebases, and > leaving a clean history before you submit the changes for review. But I > understand that constantly rewriting history means you end up with a > fabricated history at the end. So the policy choices should probably either > be no merges at all, or no rebasing at all. But that's where "git blame" > comes in. With a proper tool, you can see exactly who changed a file, and > when, and you can use it to track back the history of that file, or that > specific line of code. > > > > On 16 February 2017 at 03:45, Zachary Gorden <drakekaizer...@gmail.com> > wrote: > > I've used both git and svn in work environments. If all you do is git pull > and git push, you end up with lots of noise in the commit log with git > tracking every single merge because you don't rebase. Combined with the > fact that git has an upper limit on how much history it can track and the > solution literally being to purge history, I'm not exactly sure why all of > you are so enthused about it. Unless the team wants to adopt having a > single person being responsible for all commits going into the canonical > master repo to avoid all of the problems with how git tracks history, the > commit log is going to be next to useless for actual tracking of history. > If you don't care about the commit history, then sure, go ahead, but I > personally would like to be able to easily track changes back cleanly. We > get that basically for free with svn right now. With git, the usage > patterns that those of you pushing for git are promoting actively works > against keeping a clean history. > > On Wed, Feb 15, 2017 at 7:32 PM, Alex Ionescu <ion...@videotron.ca> wrote: > > Sure, I didn't count git add because you can do it with git commit -a. > git status/log are the same as the svn equivalents. just like git > diff/svn diff. I was mainly referring to regular workflow. > > In fact, I think outside of stash (which is an optional, but awesome, > feature) fetch and rebase (which I refuse to learn), all commands map > 1:1 with svn. That's why I don't get this whole "it takes way more > commands/steps in git". > > git commit -a -m "[BOOTLIB] Fix yet another bug]" > git push > > Done. > > Best regards, > Alex Ionescu > > > On Wed, Feb 15, 2017 at 3:48 PM, David Quintana (gigaherz) > <gigah...@gmail.com> wrote: > > My command set is a bit more extended: > > > > git clone -- similar to svn checkout into a new folder > > git checkout -- for changing the current branch > > git pull -- effectively the same as "svn update", xcept it gets the > entire > > change history, not just the latest commit data > > git push [--force] -- for sending changes into the repository > > git fetch -- downloads stuff but doesn't apply it to the checkout copy > > git merge -- can be used to merge the remote data (in which case it's > like > > svn update), or to merge from another branch > > git branch > > git add > > git commit > > git stash save/pop -- can be used to temporarily undo some changes, and > be > > able to recover them afterward > > git status, git log, ... -- for getting info about the state of the > > repository and the uncommited changes > > ... and more I that I use less often > > > > I do agree that it is a bit annoying that git has so much trouble pulling > > with local changes, and that is the one area where svn just simply works > > better. In every other aspect, I have come to like the "git way" more. > > > > That said, I avoid commandline git as much as possible. I prefer to use > > TortoiseGit (in Windows, at home), or SourceTree (at work, where I use a > > mac, and SourceTree is probably the least shitty frontend for git). > > > > I like to say, that for someone who knows Subversion, learning git > starts by > > realizing that all the usual svn concepts, apply to git, just NOT with > the > > remote repository. The svn-like commands work with the local repository > > clone, and then it has a separate command set for interacting with > remotes. > > Of course it's not a 1:1 match, but it's a good starting point. If you > are > > able to "catch" that, then learning how to work with git becomes a LOT > > easier. > > > > > > > > On 16 February 2017 at 00:31, Alex Ionescu <ion...@videotron.ca> wrote: > >> > >> On Wed, Feb 15, 2017 at 9:01 AM, Zachary Gorden > >> <drakekaizer...@gmail.com> wrote: > >> > Why is there a need for anything beyond "git commit" or "git push" or > >> > "git > >> > pull" to do anything? > >> > >> Good question. I've never used any other git command other than those > >> (except git checkout). Oh, that's lie, I've also used "git branch", > >> just like on svn, to create a branch. > >> > >> Sounds like you've never actually used git? I've never rebased in my > >> life, and I don't know what other commands even exist. > >> > >> Best regards, > >> Alex Ionescu > >> > >> _______________________________________________ > >> Ros-dev mailing list > >> Ros-dev@reactos.org > >> http://www.reactos.org/mailman/listinfo/ros-dev > > > > > > > > _______________________________________________ > > Ros-dev mailing list > > Ros-dev@reactos.org > > http://www.reactos.org/mailman/listinfo/ros-dev > > > > _______________________________________________ > Ros-dev mailing list > Ros-dev@reactos.org > http://www.reactos.org/mailman/listinfo/ros-dev > > > _______________________________________________ > Ros-dev mailing list > Ros-dev@reactos.org > http://www.reactos.org/mailman/listinfo/ros-dev > > _______________________________________________ > Ros-dev mailing list > Ros-dev@reactos.org > http://www.reactos.org/mailman/listinfo/ros-dev > -- Best regards, Alex Ionescu
_______________________________________________ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
