Yup, it's committers like you and Joel that I'm most worried about simple guidelines for. Those that are deep into Git on this project are likely to do whatever they want anyway. I'm not looking to waste my time fighting them. But for those that don't want to walk those waters, that don't have a religious bent about having the history of every patch in SVN and hundreds of one off branches, let's set up a simple work flow for them that helps keep things sane.
Mark On Mon, Jan 25, 2016 at 2:42 PM Erick Erickson <[email protected]> wrote: > Gotta echo Joel, I just want to get through my first commit here. > Yonik's outline is along the lines of what I'm looking for. For > newcomers (including newcomers to Git like me), this discussion is a > little analogous to someone asking "how do I write to a file in Java" > and having the discussion dive into the pros and cons of the zillion > different things you can do with writing data to some disk somewhere; > options for binary, text, character set, buffered, flushed, fsync'd, > and on and on. Each and every one of the options discussed has a very > good use case, but is hard to absorb all at once. > > The "How to Contribute" page needs to be updated; I'll be happy to > volunteer to create/edit a "Git commit process". I can bring the > newbie's ignorant perspective to bear on it, doing all the dumb things > that newbies do. Trust me on this, I can misinterpret even the > simplest of instructions. > > And do note that it's perfectly OK IMO to have multiple ways of doing > things, so this more along the lines of recommendations than > requirements. I'm not interested in "the one true way". I _am_ > interested in "how do I keep from messing this up completely". > > I'm envisioning a few sections here. > >Your first Git commit > >> steps for method 1 > >>> backporting to 5x > >> steps for method 2 > >>> backporting to 5x > > > Advanced issues > >> advanced issue 1 > >> advanced issue 2 > > Of course we have to reach some consensus on what acceptable "method > for newbies" are, which is much of what this discussion is about. > > Erick > > On Mon, Jan 25, 2016 at 10:07 AM, Shai Erera <[email protected]> wrote: > > I used cherry-pick, as to me it's the most similar thing to the svn merge > > workflow we had. But as Mark said, there are other ways too, and IMO we > > should get to an agreed upon way as a project, and not individuals. > > > > For instance, IIRC, branch_5x now has 2 commits: the first is the one > from > > master, and the second is named 'merge'. Seeing that in 'svn log', IMO, > > doesn't contribute to a better understanding of the history. > > > > Shai > > > > > > On Mon, Jan 25, 2016, 19:56 Mark Miller <[email protected]> wrote: > >> > >> Although, again, before someone gets angry, some groups choose to merge > in > >> this case as well instead. There are lots of legit choices. Projects > tend to > >> come to consensus on how they operate with these things. There is no > >> 'correct' choice, just opinions and what the project coalesces around. > >> > >> > >> - Mark > >> > >> On Mon, Jan 25, 2016 at 12:45 PM Mark Miller <[email protected]> > >> wrote: > >>> > >>> >> The next step is merging to branch_5x > >>> >> How do you recommend I do it? > >>> > >>> Generally, people use 'cherry-pick' for this. > >>> > >>> - Mark > >>> > >>> On Mon, Jan 25, 2016 at 12:39 PM Noble Paul <[email protected]> > wrote: > >>>> > >>>> The most common usecase is > >>>> Do development on trunk(master) > >>>> > >>>> git commit to master > >>>> git push > >>>> > >>>> > >>>> The next step is merging to branch_5x > >>>> How do you recommend I do it? > >>>> > >>>> Another chore we do is on adding new files is > >>>> svn propset svn:eol-style native <file-name> > >>>> > >>>> do we have an equivalent for that in git? > >>>> > >>>> > >>>> On Mon, Jan 25, 2016 at 10:20 PM, Yonik Seeley <[email protected]> > >>>> wrote: > >>>> >> git push origin HEAD:master (this is the equivalent of svn commit) > >>>> >> (b) Is there a less verbose way to do it, > >>>> > > >>>> > I'm no git expert either, but it seems like the simplest example of > >>>> > applying and committing a patch could be much simpler by having good > >>>> > defaults and not using a separate branch. > >>>> > > >>>> > 1) update your repo (note my .gitconfig makes this use rebasing) > >>>> > $ git pull > >>>> > > >>>> > 2) apply patch / changes, run tests, etc > >>>> > > >>>> > 3) commit locally > >>>> > $ git add # add the changed files.. use "git add -u" for adding all > >>>> > modified files > >>>> > $ git commit -m "my commit message" > >>>> > > >>>> > 4) push to remote > >>>> > $ git push > >>>> > > >>>> > -Yonik > >>>> > > >>>> > ------------ my .gitconfig ---------- > >>>> > [user] > >>>> > name = yonik > >>>> > email = [email protected] > >>>> > > >>>> > [color] > >>>> > diff = auto > >>>> > status = auto > >>>> > branch = auto > >>>> > > >>>> > [alias] > >>>> > br = branch > >>>> > co = checkout > >>>> > l = log --pretty=oneline > >>>> > hist = log --pretty=format:\"%h %ad | %s%d [%an]\" --graph > >>>> > --date=short > >>>> > > >>>> > [branch] > >>>> > autosetuprebase = always > >>>> > > >>>> > [push] > >>>> > default = tracking > >>>> > > >>>> > > --------------------------------------------------------------------- > >>>> > To unsubscribe, e-mail: [email protected] > >>>> > For additional commands, e-mail: [email protected] > >>>> > > >>>> > >>>> > >>>> > >>>> -- > >>>> ----------------------------------------------------- > >>>> Noble Paul > >>>> > >>>> --------------------------------------------------------------------- > >>>> To unsubscribe, e-mail: [email protected] > >>>> For additional commands, e-mail: [email protected] > >>>> > >>> -- > >>> - Mark > >>> about.me/markrmiller > >> > >> -- > >> - Mark > >> about.me/markrmiller > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > > -- - Mark about.me/markrmiller
