Hi again gits, I think my current query is somewhat related to my previous issue of "Preserving branches after merging on ancestor" that you help me with last time (many thanks). I use branches for features. I have a branch and I merged it into my master branch as I thought it was finished. But it turns out I wasn't and so I need to work on it again. I have made some more changes (branches and merges) on master. So what I should do is checkout that branch, work on it committing along the way and then merge it again onto my master branch. However I though I am working on a feature branch I want to be also working from the master branch as reference. Yes I know I probably should not be working like this. My branches should be wholly independent. But I doing web development not kernel development so there is much less modularity and branches/features have a tendency to creep into one another. If you want to get and idea of my workflow see my thread last week "Preserving branches after merging on ancestor". So how do I work again on a branch that has been preiously merged whilst "seeing" the current changes on the master or another branch? Is this a bad idea first of all. Should I change my workflow instead? If I do try to do this I guess I got several ways. I think I could pull(?) or merge the changes so far from the master branch into the feature branch. But this seems like an uneccesary duplication. Or should I just create a new branch? But if I do this there is no link between the old and new branch. Richard -- View this message in context: http://n2.nabble.com/Working-on-merged-branches-whilst-seeing-current-master-tp3987667p3987667.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