Hello all, I’m not really sure how to quickly sum up the scenario I’m 
trying to achieve here, so this is going to run a little bit long.

Basically, I’ve run into several situations where I want to be able to 
create a commit such that:

   My working set reflects the changes in the commit
   The commit is never pushed upstream (at least, as a parent commit of the 
   pushed branch)
   The commit is easy to apply and remove
There are several reasons I want to do this. For example, I have a 
repository (which I’ll call R) with a submodule (which I’ll call A) which, 
itself, contains another submodule (which I’ll call B). Furthermore, A is a 
GitHub fork of another repository, which I’ll call A’. Developers working 
on R are expected to commit regularly to A, periodically creating pull 
requests in A’ to bring their changes over to the original repository 
(which is then shared with other vendors). The issue here is that I would 
like to also have a B’, of which B would be a fork, so that A’ submodules 
B’, and A submodules B. The problem is that if the A’ submodule points to 
B’ and we change the A submodule to B, then either any check-in made to A 
and pushed to A’ would change the submodule, or we would have to rely on a 
manual merge process to make sure it doesn’t accidentally get overwritten. 
What I want is some sort of gesture that can be performed to update that 
submodule to point to something else, but guarantee that the change will 
never be pushed up to the origin. If that gesture can be checked in such 
that users will simply have it without having to do anything local to make 
it work, so much the better


Another scenario I run into frequently is the need to keep a list of 
patches I occasionally want to merge into my working set without actually 
publishing them. For example, I keep a local branch for one of my projects 
(which I call hacks/failnetwork) that introduces an error into the network 
code so that all network calls will fail with a predictable error, for 
troubleshooting the error handling. Right now, when I want to apply it, I 
create a branch off my feature branch called something like 
“somefeature-failnetwork” and merge in the hacks/failnetwork branch, then 
make sure to checkout “somefeature” again before committing. However, what 
I really want to be able to do is to merge hacks/failnetwork into my 
working set, commit normally with the knowledge that I won’t accidentally 
check in a change that breaks all network calls, then roll the diagnostic 
change back.


The way I’ve been thinking about it is that I basically want to be able to 
checkout “octopus” branches with multiple tips, one of which is the “main” 
tip. Commits would only update the “main” tip, merges and rebases would 
only merge and rebase the “main” tip, but the others would always be merged 
into the working set, without being reflected in the index. Whenever the 
working set is added to the index, it would first undo the changes in any 
extra tips, with merge conflicts that would need to be resolved at add time 
if anything goes wrong with applying the reverse patch. I’m thinking of the 
general flow as something like this:


[master] > git checkout -b somefeature

Switched to a new branch 'somefeature'


[somefeature]> git branch --import hacks/failnetwork

Imported branch hacks/failnetwork


        modified:   source/code/network.xml


[somefeature, hacks/failnetwork] // do work, edit files, etc…

[somefeature, hacks/failnetwork +0 ~2 +0] git commit -m “Fixed some really 
big problems”



[somefeature, hacks/failnetwork] > git branch --remove hacks/failnetwork

Removed branch hacks/failnetwork


[somefeature] >


So the question is, does something exist that can do something like this 
already? If not, do the gurus think this would be a good fit for a feature 


Thanks for reading this far!


                -- Ryan Milligan

You received this message because you are subscribed to the Google Groups "Git 
for human beings" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to git-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to