On Sep 24, 9:01 am, Jeenu <jee...@gmail.com> wrote:

> I mainly use git at work for tracking my own stuff, with no intent of
> collaboration. I usually have huge directories to track, and when I
> start out, I do so with very minimal stuff which I think would
> suffice. Later, while I proceed through different branches, I realize
> that I'm going to change something that's not tracked yet; and that
> I've to track in my future branches.
> I could start tracking that to my current branch, and all the branches
> that I create. But I wish I was added upstream so that's trackable on
> all my existing branches. So is there a way to achieve that? I know of
> filter-branch, and that it's going to be expensive on both time and
> disk, but not quite sure of how to use it in this case. Are there any
> better alternatives?

You could commit the necessary change on one branch then switch to
every other branch in turn and `git cherry-pick` that change from the
original branch.
This won't place the change "down the tree" of commits, of course, but
this approach is non-destructive in the sense it doesn't imply history

If, on the other hand, you're OK with history rewriting (for instance,
you don't publish your branches), you supposedly can do this:
1) Commit the change on one branch;
2) Do rebasing of this branch so that the committed change appears
after some specific commit in the branch history (supposedly it should
be some commit earlier than the common ancestor of all the branches
interested in the change you just made).
3) Rebase the rest of the branches on top of that new commit
containing the change.
I suppose this approach should be a bit less cumbersome than git-
You received this message because you are subscribed to the Google Groups "Git 
for human beings" group.
To post to this group, send email to git-users@googlegroups.com
To unsubscribe from this group, send email to 
For more options, visit this group at 

Reply via email to