Tim Mazid wrote: > > Actually, there's no reason you couldn't just 'git reset HEAD^' once you > realise that the branch isn't ready. If you want to see the changes from > master, you could just merge that into your branch. If you just want to > see the content in master, you could use gitk or gitg, which allows you to > view files at any commit. > > Personally, I merge master into my branches, test and check, and fix, then > merge the branch into master. This sometimes results in a fast-forward, if > you haven't made changes to master. If you don't like that, you can always > use the --no-ff option, though. > I don't think 'git reset HEAD^' would work in my case as that only goes back one commit. I may have made many other changes on the master branch that I want to keep. By merging from master into your branch, like you said, you get a nice graph view that shows what you've brought into your branch from master since you last left off. But doesn't this goes against the idea that branches should be independent, by bringing in changes from master? -- View this message in context: http://n2.nabble.com/Working-on-merged-branches-whilst-seeing-current-master-tp3987667p3994102.html Sent from the git mailing list archive at Nabble.com. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html