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-tp3987667...
Sent from the git mailing list archive at Nabble.com.
--

[ message continues ]

If the feature branch is merged to the mainline, it should really mean
that the feature is ready : the feature branch life stop here. This also
means that if you see that this feature was not as ready as you thought,
you have to restart a _new_ feature branch off of the mainline.

That's why there is the "next" branch in the git releases process. This
way, we can test the feature branches without touching master for some

This should not be the case. Modularity in the release process and the
development strategy is not tied to "what I am developing". I'm doing

Yes, feature branches have no reason to live after they are merged to
the mainline.

-- 
Nicolas Sebrecht
--

[ message continues ]

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.

Good luck,
Tim.
-- 
View this message in context: http://n2.nabble.com/Working-on-merged-branches-whilst-seeing-current-master-tp3987667...
Sent from the git mailing list archive at Nabble.com.
--

[ message continues ]

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-tp3987667...
Sent from the git mailing list archive at Nabble.com.
--

[ message continues ]

Yup, you only need to 'git reset HEAD^' on the master branch to undo the
merge. Isn't that what you wanted?

And yeah, I suppose it kind of does. But once again, you can 'git reset
HEAD^'. And since you're merging master INTO the branches, you are keeping
the branches independent, anyway.
-- 
View this message in context: http://n2.nabble.com/Working-on-merged-branches-whilst-seeing-current-master-tp3987667...
Sent from the git mailing list archive at Nabble.com.
--

[ message continues ]

Thanks for the help Nicolas,

That cleared up the issue a lot for me.



Just to clarify. Do you mean that this should not be the case that you get
feature creep in branches or the fact that this happens does interfere with
your release process/development strategy.

Regards,

Richard
-- 
View this message in context: http://n2.nabble.com/Working-on-merged-branches-whilst-seeing-current-master-tp3987667...
Sent from the git mailing list archive at Nabble.com.
--

[ message continues ]

I mean that the independency of the feature branches is mostly relying
on "what do I (as a developer) commit in this branch", which is really
tied to "how to write nice atomic commits" (easily reversible, etc).

This must be applicable whatever the product/software you're working on
and it is applicable for web development too.

-- 
Nicolas Sebrecht
--

[ message continues ]