From: Michael Witten <mfwitten@gmail.com>
To: Avery Pennarun <apenwarr@gmail.com>
Cc: Markus Elfring <Markus.Elfring@web.de>,
Junio C Hamano <gitster@pobox.com>,
git@vger.kernel.org
Subject: Re: [PATCH] Clarification for the command "git checkout <branch>"
Date: Thu, 18 Mar 2010 12:19:13 -0500 [thread overview]
Message-ID: <b4087cc51003181019r4408953bxcd5049c9521b8173@mail.gmail.com> (raw)
In-Reply-To: <32541b131003180936x746dad06k386788d3cb6fcdeb@mail.gmail.com>
On Thu, Mar 18, 2010 at 11:36, Avery Pennarun <apenwarr@gmail.com> wrote
> On Thu, Mar 18, 2010 at 6:11 AM, Markus Elfring <Markus.Elfring@web.de> wrote:
>>> You may want retry the command after recording the local changes
>>> (1) in a temporary commit on the current branch,
>>
>> Can commits be consistently marked for intermediate use?
>> Can such "special" commits be easily found later on?
>
> You just make the commit with a 'FIXME' type commit message, then 'git
> commit --amend' to fix it when you come back later.
Something more explicit might be useful in my opinion, as suggested in
this previous post:
http://marc.info/?l=git&m=126768880311121&w=2
> I'm not sure how often WIP commits become
> accidentally published or left in the history,
> but perhaps it would be advantageous to
> provide a means of specifying officially that
> a particular commit is in fact a WIP commit
> such that no other commits can be made on top
> of this WIP commit and it can't be merged with
> other branches or pushed or whatever.
>>> or (2) by using "git stash".
>>
>> Is this storage operation supported per branch?
>> Does a checkout look if any files were stashed away for the specified branch before?
Markus, this was discussed ad nauseum in the other thread:
http://marc.info/?l=git&m=126746296820948&w=2
http://marc.info/?l=git&m=126749413508313&w=2
http://marc.info/?l=git&m=126746730431007&w=2
Are you not reading? Are you not comprehending? Are you trolling?
> stashing isn't really something you'd want to do on a per-branch
> basis. Most of the point is that you stash away your changes, then
> switch to another branch, then restore your stash to your *current*
> working state sometime later.
As you may know, "git checkout" carries local modifications to the new
working tree if there are no conflicts, so no explicit stash usage is
necessary in many cases.
Anyway, I think it would be useful to be able to manage multiple
stashes rather than having to rely on just one global stash. However,
I imagine than explicit Work In Progress (WIP) commits as sketched
above would go a long way in keeping histories and workflows clean and
organized.
next prev parent reply other threads:[~2010-03-18 17:19 UTC|newest]
Thread overview: 56+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-02-01 18:50 Better cooperation between checkouts and stashing Markus Elfring
2010-02-01 20:40 ` Junio C Hamano
2010-02-01 21:57 ` Markus Elfring
2010-02-01 22:44 ` Eugene Sajine
2010-02-02 1:36 ` Petr Baudis
2010-02-02 10:26 ` Markus Elfring
2010-02-02 11:04 ` Petr Baudis
2010-02-09 19:20 ` Markus Elfring
2010-02-09 20:06 ` Junio C Hamano
2010-02-09 21:01 ` Markus Elfring
2010-02-18 17:43 ` Markus Elfring
2010-02-18 20:09 ` Junio C Hamano
2010-02-27 21:33 ` Markus Elfring
2010-02-27 21:51 ` Junio C Hamano
2010-02-28 13:55 ` Markus Elfring
2010-02-28 22:57 ` Michael Witten
2010-03-01 10:50 ` Markus Elfring
2010-03-01 17:02 ` Michael Witten
2010-03-01 17:23 ` Junio C Hamano
2010-03-01 18:14 ` Michael Witten
2010-03-01 18:29 ` Markus Elfring
2010-03-01 19:44 ` Junio C Hamano
2010-03-01 21:20 ` Markus Elfring
2010-03-02 1:41 ` Michael Witten
2010-03-02 9:35 ` Markus Elfring
2010-03-02 17:50 ` Junio C Hamano
2010-03-03 15:55 ` Markus Elfring
2010-03-04 7:46 ` Michael Witten
2010-03-04 19:55 ` Markus Elfring
2010-03-02 9:45 ` Markus Elfring
2010-03-02 18:05 ` Junio C Hamano
2010-03-03 16:00 ` Markus Elfring
2010-03-17 16:35 ` [PATCH] Clarification for the command "git checkout <branch>" Markus Elfring
2010-03-17 16:44 ` Avery Pennarun
2010-03-17 17:00 ` Markus Elfring
2010-03-17 17:58 ` Junio C Hamano
2010-03-17 18:21 ` Markus Elfring
2010-03-17 18:37 ` Junio C Hamano
2010-03-17 18:50 ` Michael Witten
2010-03-17 19:23 ` Junio C Hamano
2010-03-18 10:11 ` Markus Elfring
2010-03-18 16:36 ` Avery Pennarun
2010-03-18 17:19 ` Michael Witten [this message]
2010-03-18 17:33 ` Avery Pennarun
2010-03-19 8:28 ` Markus Elfring
2010-03-19 17:17 ` Avery Pennarun
2010-03-20 6:00 ` Markus Elfring
2010-03-19 8:15 ` Markus Elfring
2010-03-30 15:57 ` Markus Elfring
2010-03-30 22:13 ` Junio C Hamano
2010-03-31 3:58 ` Ramkumar Ramachandra
2010-04-01 4:52 ` Junio C Hamano
2010-04-01 13:09 ` Ramkumar Ramachandra
2010-04-01 6:38 ` Markus Elfring
2010-04-10 13:30 ` Markus Elfring
2010-04-10 22:31 ` Junio C Hamano
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=b4087cc51003181019r4408953bxcd5049c9521b8173@mail.gmail.com \
--to=mfwitten@gmail.com \
--cc=Markus.Elfring@web.de \
--cc=apenwarr@gmail.com \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
/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).