How to track history of personal changes in a repository?

Hi,

I'm looking for a way to track history of personal changes in a repository. I'd like to protect against accidentally pushing the changes to a remote branch. I imagine this working a little like `git ignore`, and a little like a separate branch. It might be like a personal sub-branch that is ignored by `git push`. Or it might be like a history of the work tree that runs parallel to the reflog and to the history of any given branch.

Does something like this exist in Git or a complementary tool?

I found `git update-index --skip-worktree`. I imagine it might be relevant in some kind of workflow where I can maintain a personal-worktree branch.

Does any of you have a personal workflow that addresses similar concerns?

Thanks.

On Thu, Aug 29, 2019 at 7:34 AM Matthew McClure <matt@continuousdelta.com> wrote:

Perhaps put all the changes in a specific branch and run:
  git config branch.${personalBranchName}.pushRemote
Do.Not.Push.Changes.From.This.Branch
?  (And make sure that push.default is not set to 'matching'.)

On Thu, Aug 29, 2019 at 1:04 PM Elijah Newren <newren@gmail.com> wrote:

I imagine putting all the changes on a specific branch might be part of a solution. I'm looking for ways to keep the changes in the work tree as well, even as I switch among other branches I'm working on.

-- Matthew McClure Continuous Delta https://www.continuousdelta.com/

On Thu, Aug 29, 2019 at 10:58 AM Matthew McClure <matt@continuousdelta.com> wrote:

Well, here's some ideas...

If you want personal changes kept in the worktree and aren't worried about versioning them:

* If the changes are new files that are not tracked, just .gitignore them.
* If the changes are to files that are tracked, AND you aren't making
changes to those same files that do need to be committed and pushed,
use the assume-unchanged bit (see git-update-index(1)).
* If the changes are to files that are tracked and you need to make
other changes to those same files, the best you've probably got is "be
careful while using 'git add -p' to only select the bits that should
be staged".

If you want to keep the personal changes in the worktree AND are worried about version control:

* You could just make sure that any personal changes are made in
separate commits of their own and put a special string (e.g. "DO NOT
PUSH") in the commit message.  Add a pre-push hook (see githooks) that
checks for this string in any of the commits to be pushed and denies
the push if it is found.  At that point, you'd just rebase to move the
"DO NOT PUSH" to be the last commits in the series, and always make
sure when pushing that you specify a commit older than the current tip
of your branch to push (i.e. using refspecs; see the git-push manpage)
* If you don't like the githook route and if the personal changes are
all in different filenames than exist in other branches, and you're
willing to do a little low-level hackery...then you could put all
these changes in a different branch as mentioned previously, and use
some low-level commands to "checkout" the files from both branches
simultaneously.  The basic way it'd work is that the real branch would
have a .gitignore for all files in your personal changes (whereas the
personal changes branch would have no .gitignore because files have to
be independent; things will just be uglier when you're on that
branch).  You'd use 'git symbolic-ref HEAD $OTHER_BRANCH && git reset'
to swap branches on the fly so you can commit different types of
changes.

Hope that helps, Elijah

Hi Elijah, Matt

On 30/08/2019 16:21, Elijah Newren wrote:

Not sure I parsed that well but...

The `assume-unchanged bit` is commonly miss-construed as a promise by Git that it will ignore changes to the file.

That is incorrect. The bit is a promise by the _user_ that they won't change the file, so that, in general Git stops checking for updates to the file. However it will check for updates sometimes, leading to unexpected effects if the user has the wrong mental model, thinking that Git would ignore their changes...

Philip

On Sat, Aug 31, 2019 at 09:32 Philip Oakley <philipoakley@iee.email> wrote:

Maybe `--skip-worktree` would be more appropriate.