Re: [git-users] Branches and workflow
On Wed, May 22, 2013 at 08:02:50PM +0100, Roddie wrote: I'm fine with Git and branches when it's simple, but as soon as things get a little complicated, I get baffled and frustrated. For example... I've set up a members' log in system for a website, including a log-in form on the home page. The template for the home page was amended in the process. That's all committed on branch memlogin. That work is on hold because I have to get adverts on the home page, and I've made a new branch - adverts. This was branched from the master branch, so does not include any of the work on memlogin. But I need the revised home page template file because the log-in form affects the position of the adverts. This is just an example. The general point is about how branches are not, in reality, completely independent, and work on one can affect another. What should I do? I have the feeling that I'm missing the point about branches. Everyone raves about them, but they seem to fail as soon as the complexity of the real world kicks in. BTW, I'm familiar with the diagram from nvie.com, but it doesn't answer this problem - its feature branches are completely independent until merged into the develop branch. In my experience the world is not that neat and tidy. I'd appreciate any advice. With the risk of sounding a bit patronising it seems you've forgotten the other side of the coin -- merging. If, and this is a big if, your changes to your work on the home page template file is contained in self-contained patches, then you can merge those changes from 'memlogin' to 'adverts'. If that's not possible you might be facing the risk of having to progressing 'memlogin' to a point where it can be deployed. Merge it into 'master' and then restart 'adverts' from there. I think feature branches are the bee's knees too, but they aren't as easy as in all the examples one reads -- they require some up-front thinking. In particular it's problematic when dependencies between features emerge during development. In essence you then only have two options, finish them in order of dependency, A then B, or don't. If you don't you'll probably end up hacking up certain aspects of B just to make it good enough, then when A is finished you can revisit B. Unfortunately not an answer to What should I do? Because that's really only an answer you, or your project manager, can answer. But hopefully it aids in thinking about the trade-offs of your options. /M -- Magnus Therning OpenPGP: 0xAB4DFBA4 email: mag...@therning.org jabber: mag...@therning.org twitter: magthe http://therning.org/magnus I invented the term Object-Oriented, and I can tell you I did not have C++ in mind. -- Alan Kay pgp9vP1eZei5A.pgp Description: PGP signature
Re: [git-users] Workflow help
On Tue, May 21, 2013 at 04:54:21AM -0700, Tony Quilkey wrote: Hi, I am looking at formulating and then documenting our vcs workflow using Git at work. I have an idea of how I want things to work, but am a little hazy on some of the details. Our basic workflow will be based around: http://nvie.com/posts/a-successful-git-branching-model, with a few exceptions. We would like to create our release-* branches from the last release tag. From there, we would like the ability to cherry pick (or take the complete diff) commits from the develop branch. So, we are after is: 1) Create topic (feature) branches from develop, and merge back into develop when complete. 2) Once it is decided we are packaging a release, make a release-* branch from the previous release tag. 3) Cherry pick/merge/whatever any commits we want from develop into the new release-* until it is complete. 4) Merge the new release-* branch into master and tag it. Repeat as necessary. At the moment I am a little stuck on how exactly we can cherry pick stuff from develop into a release-* branch. I'm not even sure this approach is exactly what we should be doing. Our main concern is that at this stage, there is no guarantee that all commits within develop can be pulled into a release. In regards to how we can achieve the above results any input would be much appreciated. Or if there are any other better options available, I'm all ears. A branching strategy should spring from your needs. Since you are basing it on http://nvie.com/posts/a-successful-git-branching-model/ I'm guessing you work on a product that's released fairly infrequently and you only plan on providing support for the latest released version. Is that right? /M -- Magnus Therning OpenPGP: 0xAB4DFBA4 email: mag...@therning.org jabber: mag...@therning.org twitter: magthe http://therning.org/magnus Most software today is very much like an Egyptian pyramid with millions of bricks piled on top of each other, with no structural integrity, but just done by brute force and thousands of slaves. -- Alan Kay pgpeMSvb5ZZVZ.pgp Description: PGP signature
[git-users] Re: Branches and workflow
Hi, On Wednesday, May 22, 2013 3:02:50 PM UTC-4, Roddie wrote: [...] That work is on hold because I have to get adverts on the home page, and I've made a new branch - adverts. This was branched from the master branch, so does not include any of the work on memlogin. But I need the revised home page template file because the log-in form affects the position of the adverts. You need to split up the `memlogin' branch commits into: A. a bunch of commits that change the size and positioning of the login form B. a bunch of commits that implement the rest of the login form changes Then you merge the `A' commits back into master. Then you branch off `adverts' from master and develop in parallel (because now you're working with the new layout/positioning). The main problem you have is, presumably, the commit(s) on your `memlogin' branch intersperse layout changes with functionality changes. If you are clever with `git rebase -i' you can clean up the commits and make branching work just fine. Of course, please don't rebase if you've already pushed your branches where others can clone/fetch them. Regards, Yawar -- You received this message because you are subscribed to the Google Groups Git for human beings group. To unsubscribe from this group and stop receiving emails from it, send an email to git-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
[git-users] Re: Workflow Advice / Help
Hi, On Tuesday, May 21, 2013 6:39:30 PM UTC-4, Tony Quilkey wrote: [...] 1) Create topic (feature) branches from develop, and merge back into develop when complete. Sounds fine. 2) Once it is decided we are packaging a release, make a release-* branch from the previous release tag. Sounds fine. 3) Cherry pick/merge/whatever any commits we want from develop into the new release-* until it is complete. Avoid cherry-pick. Prefer merge to help git manage history (`That commit has already been applied on this release branch', or `You need to apply commit A first to apply commit B') for you. 4) Merge the new release-* branch into master and tag it. Alarm bells. The purpose of the release-* branch is to never be merged back into master. The flip side of the coin is that you want every commit on master to be good enough to create a new release from. I.e. only merge a commit into master if you would be comfortable with deploying it. Reading this and the rest of your posting (which I've cut out) I feel I should clarify this: on a release-* branch you will be applying bugfixes only. You won't be applying anything new that's done on the develop branch. If you want to apply a bugfix to multiple release-* branches you find their common ancestor (or even better, the old commit that introduced the bug), fix it on top of that, and merge into the release-* and develop branches. If all else fails, of course, you fall back on cherry-pick. Regards, Yawar -- You received this message because you are subscribed to the Google Groups Git for human beings group. To unsubscribe from this group and stop receiving emails from it, send an email to git-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
[git-users] Re: proper meaning of '.' dot in a git command?
Hi Philip, On Thursday, May 16, 2013 6:42:03 PM UTC-4, Philip Oakley wrote: Recently there have been a couple of example commands that have a single dot '.' in the command line. In this case what is its proper meaning, that is, is it expanded by the bash shell, or by git it self, and what would its typical expanded version look like if it is the current dicetory e.g. fully qualified etc. ? I'm afraid none of the replies here have been correct. When used with fetch/push/pull, the dot means `this (the local) repository'. [...] On Sat, May 4, 2013 at 2:51 PM, Jonathan Nieder jrni...@gmail.comjavascript: wrote: Another trick is to use git push: git push . $production_sha1:refs/heads/master This means push this repository's $production_sha1 to this (same) repository's master. This is a shortcut way of saying git checkout master git merge --ff-only $production_sha1 git checkout $production_sha1 Where $production_sha1 can be any branch, tag, or commit ID. Notice the `--ff-only', which forces $production_sha1 to be a descendant of master. Remember that this is how push behaves by default. [...] 'git fetch .' This means fetch all refs from this repo into this repo as remote refs. As you are probably thinking, this doesn't make much sense. So I think the git devs are discussing adding an option here to clarify the use cases: in [PATCH 1/3] fetch: add --allow-local option, Regards, Yawar -- You received this message because you are subscribed to the Google Groups Git for human beings group. To unsubscribe from this group and stop receiving emails from it, send an email to git-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
[git-users] Re: checking out remote branches. problem I haven't read about yet
On Tuesday, May 21, 2013 12:22:01 PM UTC-7, que...@gmail.com wrote: Hi, I am trying to use a repository being served at my work, by me. If I: git ls-remote It shows the branches that I expect, e.g.: ... refs/remotes/floop git branch -a shows: * master remotes/origin/HEAD - origin/master remotes/origin/master git branch -r show: origin/HEAD - origin/master origin/master This produces an error message: git checkout -b noo origin/floop Fatal: Cannot update paths and switch to branch 'noo' at the same time. So, after that I've tried things I've read about but don't understand, like: git remote update git fetch I get the same error message when trying to checkout the branch. git remote add woof https://example.com/arf.git git fetch woof git checkout -b noo woo/floop Produces the same error message. git branch -a now also shows remotes/woof/master and nothing else new. Can you tell what the problem is? Someone on #git gave me a solution. I don't understand it though. The solution was to use a refspec to copy a path from the remote repository. The added remote woof was used. I'm not sure if that is significant or not. git fetch woof +refs/remotes/*:refs/woof/remotes/* The result is that commands now recognize a path starting with woof, e.g.: woof/floop The rest of the error message I was getting was: Did you intend to checkout 'woof/floop' which can not be resolved as commit? Resolved as commit is refers to the type of git object that is called a commit. So, the message means that it doesn't recognize the path woof/floop. -- You received this message because you are subscribed to the Google Groups Git for human beings group. To unsubscribe from this group and stop receiving emails from it, send an email to git-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
