Git development
 help / color / mirror / Atom feed
From: Jan Hudec <bulb@ucw.cz>
To: "Shawn O. Pearce" <spearce@spearce.org>
Cc: Brian Scott Dobrovodsky <brian@pontech.com>, git@vger.kernel.org
Subject: Re: Data Integrity & un-Commited Branches
Date: Sat, 15 Sep 2007 09:38:45 +0200	[thread overview]
Message-ID: <20070915073845.GB3782@efreet.light.src> (raw)
In-Reply-To: <20070915025129.GY3099@spearce.org>

[-- Attachment #1: Type: text/plain, Size: 1299 bytes --]

On Fri, Sep 14, 2007 at 22:51:29 -0400, Shawn O. Pearce wrote:
> It isn't unreasonable to want Git to save uncommitted work for the
> current branch and then you switch to another, ending up with a
> clean working directory when you finally get there.  Today we have
> git-stash to help you with this, but I'm thinking maybe we want to
> connect git-checkout with it?

I think it would be reasonable if it just forced you to decide about it. That
is reading the documentation, checkout only switches branches if the merge of
each modified file is trivial and only does 3-way merge if it got -m option.

It might be reasonable to requre that option for all cases, where there are
local changes and the branches don't point to the same commit and without it,
checkout should say something like:

  Cannot switch branches, because the tree is modified. You can apply the
  modifications to the target branch by using -m option, or commit them
  before switching branches (you can undo or amend that commit later if it's
  not finished yet).

The case with branches pointing to the same commit is for checkout -b,
reverting that command if you do it too early/by mistake/wanted branch
instead and for doing it with branch + checkout.

-- 
						 Jan 'Bulb' Hudec <bulb@ucw.cz>

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

  parent reply	other threads:[~2007-09-15  7:38 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <2a8a071a0709140028o472bcr8c82bd88e37cc4e9@mail.gmail.com>
     [not found] ` <2a8a071a0709140036l5db62c0fl5af01f75f35610ba@mail.gmail.com>
     [not found]   ` <7vk5qtd3le.fsf@gitster.siamese.dyndns.org>
2007-09-15  0:40     ` Data Integrity & un-Commited Branches Brian Scott Dobrovodsky
2007-09-15  2:51       ` Shawn O. Pearce
2007-09-15  6:24         ` Brian Scott Dobrovodsky
2007-09-15  6:32           ` Shawn O. Pearce
2007-09-15  6:37           ` Junio C Hamano
2007-09-15  7:14             ` Brian Scott Dobrovodsky
2007-09-15  7:38         ` Jan Hudec [this message]
2007-09-15  7:51           ` Shawn O. Pearce
2007-09-15 13:11             ` Nikodemus Siivola
2007-09-15 13:59               ` David Kastrup
2007-09-15 17:14                 ` Nikodemus Siivola
2007-09-15 17:33                   ` David Kastrup

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=20070915073845.GB3782@efreet.light.src \
    --to=bulb@ucw.cz \
    --cc=brian@pontech.com \
    --cc=git@vger.kernel.org \
    --cc=spearce@spearce.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