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
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 email@example.com
To unsubscribe from this group, send email to
For more options, visit this group at