Keep index?
-u?
(reads manual)
...
(reads git-clean)
...
Definitely do NOT want -u :-).

Git stash gives me the same issue, unless there is something I don't know 
about. In order to do the test, the checked out working copy needs to NOT have 
spare/untested chunks in it. 

In other words, I have (roughly) 2 sets of 9 changes. One set is "optional" -- 
things will work better if I can get them to work, but they are not necessary. 
The other set is "must get to work", and I've confirmed that at least two of 
them (one found, now hunting the second) is bad.

My understanding (is this correct?) is that after "git stash --keep-index", I 
have a file that is a copy of what is in the index, ready to commit -- and the 
commit, if it works, records success. 

What I am currently doing:
> 
> git checkout broken-all chest_content.cfg    # Get the broken file with 
> everything
>                                             # This is the command I did not 
> know how to do
>                                             # Warning: it starts with the 
> whole file in index
> git gui                           # Visually commit the lines for one segment 
> at a time
>                                  # First uncommit the whole file, then add 
> just one segment
> git checkout -- chest_content.cfg # and throw away the other changes
> ## test test test                 # See if it works or breaks
> 
> Repeat those last 4 lines until it breaks; then, back out one commit.

What I understand you are recommending

git checkout broken-all chest_content.cfg    # Get the broken file with 
everything

Loop target:
git gui                                      # edit; have one new chunk in the 
index, the rest as uncommitted chunks.

# File has everything, including uncertain stuff not yet tested.
# Index has new lines to test. Make file match index
git stash --keep-index

# test test test
git commit -m "one more down, N more to go"  # assuming it worked

git stash pop                                # Restore all the things not yet 
tested


Is that correct?
... If so, it solves the next problem -- how to continue after finding and 
fixing one set of patches, and still hunting down the next one (which ... 
failed miserably for me last night :-).

On 2015-05-10, at 12:03 AM, Gergely Polonkai <gerg...@polonkai.eu> wrote:

> Hello,
> 
> how about using stash?
> 
> git add -p (or use git gui) to add some lines you want to check, but don't 
> commit
> git stash --keep-index
> 
> do your tests. If everything is fine, make a commit
> 
> git stash pop
> start over
> 
> when you are finished, you will have several commits, so you may want to 
> squash them with git rebase -i
> 
> Also, be aware that stash puts every modified file away, but not untracked 
> files (use -u for that), so if you have modified files other than that 
> config, you should commit them first.
> 
> Best,
> Gergely
> 
> On 10 May 2015 02:18, "Michael" <keybou...@gmail.com> wrote:
> 
> On 2015-05-09, at 2:59 PM, Michael <keybou...@gmail.com> wrote:
> 
> > So here's something that I'd like to do, and I'm wondering if Git is the 
> > right tool for this.
> >
> > I have a program's config file, that is broken up into a large number of 
> > sections. One of them is causing a problem. All of them have been modified.
> >
> > ...
> >
> > What comes to mind as a good way to do this:
> > 1. Commit the version that has too many (including the problem section) 
> > edits made to it, to one branch.
> > 2. Start a new branch (off the parent, not that over-edited commit), and 
> > start that with a plain config file.
> > 3. Repeat loop:
> > a. Check out a copy from the branch in #1.
> > b. Commit one chunk into the branch in #2.
> > c. Reset the file to the version just checked in
> > d. Test
> >
> > 4. As long as that works, each loop will test, and commit, one more section 
> > of edits.
> >
> > The problem? I don't have any idea how to check out a copy of file X from 
> > branch OverEdit into branch Testing.
> >
> > Is there a better way to do this with git? Is git the wrong tool?
> 
> Ok, I think I have a way to do this. I now want to know, is this the best 
> way, is there a better way, are there hidden gotchas with this?
> 
> git checkout -b Chest             # Start with a new branch
> git add chest_content.cfg         # Put the base, unaltered config file in
> git commit -m "base config file"  # and save it
> 
> git checkout -b broken-all        # Now, another branch for the broken set of 
> changes
> cp ../Loot/chest_content.cfg .    # Put the broken file in place
> git commit .                      # Save the broken file into git
> git checkout Chest                # Back to the working branch
> 
> git checkout broken-all chest_content.cfg    # Get the broken file with 
> everything
>                                              # This is the command I did not 
> know how to do
>                                              # Warning: it starts with the 
> whole file in index
> git gui                           # Visually commit the lines for one segment 
> at a time
>                                   # First uncommit the whole file, then add 
> just one segment
> git checkout -- chest_content.cfg # and throw away the other changes
> ## test test test                 # See if it works or breaks
> 
> Repeat those last 4 lines until it breaks; then, back out one commit.
> 
> 
> >
> > ---
> > Entertaining minecraft videos
> > http://YouTube.com/keybounce
> >
> 
> ---
> Entertaining minecraft videos
> http://YouTube.com/keybounce
> 
> --
> 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.
> 
> -- 
> 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.

---
Entertaining minecraft videos
http://YouTube.com/keybounce

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