[git-users] Updating the working set without updating the index?

[Ryan Milligan]

 

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:

   1. 
   
   My working set reflects the changes in the commit
   2. 
   
   The commit is never pushed upstream (at least, as a parent commit of the 
   pushed branch)
   3. 
   
   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 
request? 

 

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.

Re: [git-users] How to remove a project or folder pushed by mistake with original project to master branch???

[Ryan Milligan]

I know this is kind of an old post, but in case anybody comes across this 
answer, you can also use "--force-with-lease" instead of "--force" to do 
the push only if there have been no changes to the upstream history since 
the last time you fetched. This solves the risk Nelson brought up of 
accidentally overwriting other people's changes.

On Tuesday, November 24, 2015 at 4:39:42 AM UTC-8, Moazzam Shahzad wrote:
>
> ok I will do the sameThankyou for helping...
>
> On Tue, Nov 24, 2015 at 5:35 PM, Nelson Efrain A. Cruz  > wrote:
>
>> Hi, in git there is no concept about "rights". I assume you are using 
>> some tool to manage git repos like gitlab or github. Anyway two options 
>> come to my mind right now:
>>
>> Make a new commit erasing the folder that you dont want, with this 
>> approach the folder will be in the history so you can checkout to a commit 
>>  where the folder is present wich is bad if you dont want those files in 
>> the history of the repo.
>>
>> Change your las commit and (force) push it, with this approach you need 
>> to be careful of rewriting history, basically if you are alone in the repo 
>> you are safe if not well you need to be sure that anyone have pulled the 
>> history. For this read [1]
>>
>> 1 - 
>> https://git-scm.com/book/en/v2/Git-Tools-Rewriting-History#Changing-the-Last-Commit
>>
>> El mar., 24 de nov. de 2015 a la(s) 9:03 a. m., Moazzam Shahzad <
>> moazzams...@gmail.com > escribió:
>>
>>> I have master rights on git repository.
>>> How to remove a project or folder pushed by mistake  with original 
>>> project to master branch???
>>>
>>>
>>> -- 
>>> 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+...@googlegroups.com .
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>> -- 
>> You received this message because you are subscribed to a topic in the 
>> Google Groups "Git for human beings" group.
>> To unsubscribe from this topic, visit 
>> https://groups.google.com/d/topic/git-users/413VcP7_cL8/unsubscribe.
>> To unsubscribe from this group and all its topics, send an email to 
>> git-users+...@googlegroups.com .
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>

-- 
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.