git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Neal Kreitzinger" <neal@rsss.com>
To: git@vger.kernel.org
Subject: Re: Problems switching branches
Date: Wed, 24 Nov 2010 16:33:04 -0600	[thread overview]
Message-ID: <ick3tr$j5l$1@dough.gmane.org> (raw)
In-Reply-To: 4CD3A5D9.6070802@seznam.cz


"Maaartin-1" <grajcar1@seznam.cz> wrote in message 
news:4CD3A5D9.6070802@seznam.cz...
> On 10-11-04 15:39, Nguyen Thai Ngoc Duy wrote:
>> On Thu, Nov 4, 2010 at 7:23 AM, Maaartin <grajcar1@seznam.cz> wrote:
>>> Maaartin <grajcar1 <at> seznam.cz> writes:
>>>
>>>>
>>>> I sometimes run in a problem similar to
>>>> http://kerneltrap.org/mailarchive/git/2008/10/15/3667644/thread
>>>> There are some ignored files which I want neither track nor throw away; 
>>>> I'm
>>> just
>>>> happy to have them and keep them out of version control.
>>>>
>>>> Unfortunately, there weren't ignored in the old branch. I'd be quite 
>>>> happy
>>> with
>>>> non-destructive switching like "checkout everything what doesn't 
>>>> overwrite an
>>>> untracked file", so I would end in the old branch with a dirty working 
>>>> tree.
>>> Is
>>>> it possible?
>>>
>>> No answer?
>>
>> Which means nobody is interested in. Well, not really.
>>
>> I also get irritated by a similar situation, where the untracked files
>> have the same content as the to-be-checked-out files. I have been
>> tempted (but never got around) to make git compare the in-index
>> content and the untracked file, if it's the same, no need to abort the
>> checkout process.
>
> I was asked to provide a working example of the happening, but I haven't
> managed to reproduce it yet. However, it's not very rare (it just never
> happen when I need it).
>
>> But your approach may be better. Yes, I think it's possible. Any
>> suggestion for checkout's new argument? --no-overwrite-untracked seems
>> too long.
>
> I would go even further: a switch called "ignorant" or "lenient"
> allowing to always switch branches in a non-destructible way. All files
> normally causing abort would be left unmodified, so you could do
> git checkout --ignorant forth; git checkout back
> and would (assuming you started in branch "back") land in the original
> state without loosing anything. Of course, this means, that the ignorant
> checkout doesn't lead you into a clean state, but that's why I'd like to
> use a switch instead of making it the default. :)
>
> I may be talking non-sense as I'm quite inexperienced user, however I'd
> love an easier way for switching branches. Quite often, I'd like to put
> a modified file onto a different branch. This sounds probably strange,
> but my work is really quite chaotic in this respect at the moment and
> I'd like to organize it better by using a couple of (quite similar)
> branches (with a lifespan of a few days at most).
>

You could use git-stash in combination with git-clean.  Let's say BranchA 
has FileA (untracked), and BranchB has FileA (tracked):
git branch = BranchA
git stash = this will store your dirty working tree in a commit 
behind-the-scenes, and store your index in a commit behind-the-scenes, and 
then run a git-reset --hard behind the scenes.
git status = is FileA still 'untracked'?
    if so, git clean -f to remove it.  don't worry, its in your stash you 
just made.
git clean -f
git checkout BranchB
now you have FileA from BranchB
git checkout BranchA
git stash apply, (use git stash apply --index if you want the index back 
also)
now you have BranchA and its untracked FileA

Using the stash and clean will also keep various untracked files from 
different lines-of-development from accumulating in your worktree.  "Keep 
track" of your untracked files by stashing them away and cleaning them up, 
so to speak.  This is actually pretty straightforwarad and easy once you get 
used to it, IMHO.

v/r,
Neal 

      parent reply	other threads:[~2010-11-24 22:34 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-11-03  2:37 Problems switching branches Maaartin
2010-11-04  0:23 ` Maaartin
2010-11-04 14:39   ` Nguyen Thai Ngoc Duy
2010-11-05  6:36     ` Maaartin-1
2010-11-05  8:41       ` Nguyen Thai Ngoc Duy
2010-11-24 22:33       ` Neal Kreitzinger [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='ick3tr$j5l$1@dough.gmane.org' \
    --to=neal@rsss.com \
    --cc=git@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).