From: "David Jeske" <jeske@willowmail.com>
To: "Robert Anderson" <rwa000@gmail.com>
Cc: "Jakub Narebski" <jnareb@gmail.com>,
"Stephen Sinclair" <radarsat1@gmail.com>,
"Git Mailing List" <git@vger.kernel.org>
Subject: Re: An alternate model for preparing partial commits
Date: Sat, 28 Jun 2008 19:12:35 -0000 [thread overview]
Message-ID: <willow-jeske-01l83mS5FEDjCcUW> (raw)
In-Reply-To: <9af502e50806281125v5459f7deuc14256044b3e726@mail.gmail.com>
-- Robert Anderson wrote:
> If I come back to a branch on which there are several
> commits which have not been pushed yet, how do I know which are
> "temporary" and which are "for real" commits? I cannot. It is
> impossible. The information is not there.
This comment resonates with me Robert. Because git's concept of a workspace
is a "non-tracking branch", git doesn't automate having "temporary" and "for
real" commits intermixed in the workspace, or having more than one "named set
of temporary commits".
Imagine if we use git's mechanisms to setup a "p4 change" style workflow. In
that workflow, we can have multiple outstanding named changes in the same
working-files. This seems simple and reasonable to me, I use it quite a bit in
p4. My most common use of it is to prevent myself from accidentally publishing
a set of edited files that are supposed to remain local as I'm iterating (I
throw them in a "don't submit this yet" pending change).
If we dynamically compose a "workspace" out of 2 temporary "changes" it might
look like this:
: /---PQ workspace/1
: |<- Q / change/feature1
: |<---- P change/feature2
: |
: --A<--B master
You're working in workspace 1, and you could pretty easily make the equivilant
of "git commit -c change/feature2". That would say, "hey, commit this change,
and then merge it down to "change/feature2 branch" as R'.
: /---PQ---R workspace/1
: |<- Q / / change/feature1
: |<---- P<---R' change/feature2
: |
: --A<--B master
This seems doable, and git's mechanisms would make it pretty easy (though it
feels dangerous to me).
You can then merge either change onto the master when it's done. Your little
wrapper could give you a "workspace rebase" which could destroy the workspace,
rebase all the features, and recompose the workspace. If you want to rebase one
of the changes onto the master, again, your wrapper destroys the workspace,
rebases and pushes the change, rebases the rest of the changes, and recreates
your workspace.
All of that "destroying the workspace" is required because rebase is a change
operation which does not contain merge-history. In the setup above, your
"change/*" branches are effectively "published to your workspace", so if you
rebase either of them, you're technically rebasing something that's published,
and "workspace" will be in a world of hurt. Therefore, one solution is to
destroy the workspace, making the rebase a valid operation, then recompose it.
Personally, I'd like to see rebase made to have merge history, using some kind
of "soft-dag-link" that would cause it to work for anyone who had those
changes, while not causing the history to show or hold onto those parents.
next prev parent reply other threads:[~2008-06-28 19:18 UTC|newest]
Thread overview: 61+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <willow-jeske-01l7H4tHFEDjCgPV-01l7H4sOFEDjCbyi>
2008-06-27 6:50 ` An alternate model for preparing partial commits Robert Anderson
2008-06-27 7:10 ` Björn Steinbrink
2008-06-27 14:37 ` [PATCH/RFC] stash: introduce 'stash save --keep-index' option SZEDER Gábor
2008-06-27 18:26 ` Junio C Hamano
2008-06-27 16:54 ` An alternate model for preparing partial commits Robert Anderson
2008-06-27 17:27 ` Björn Steinbrink
2008-06-27 17:34 ` Robert Anderson
2008-06-27 8:35 ` Johannes Sixt
2008-06-27 17:01 ` Robert Anderson
2008-06-27 8:50 ` Petr Baudis
2008-06-27 17:02 ` Robert Anderson
2008-06-27 13:33 ` Johannes Schindelin
2008-06-27 13:49 ` Miklos Vajna
2008-06-27 17:14 ` Robert Anderson
2008-06-27 17:45 ` Johannes Schindelin
2008-06-27 17:49 ` Robert Anderson
[not found] ` <alpine.DEB.1.00.0806271854120.9925@racer>
2008-06-27 18:07 ` Robert Anderson
2008-06-27 18:20 ` Dana How
2008-06-27 20:31 ` Stephen Sinclair
2008-06-27 20:45 ` David Jeske
2008-06-27 20:45 ` David Jeske
2008-06-28 17:23 ` Wincent Colaiuta
2008-06-28 2:14 ` Dmitry Potapov
2008-06-28 2:57 ` Robert Anderson
2008-06-28 4:03 ` Dmitry Potapov
[not found] ` <9af502e50806272320p23f01e8eo4a67c5f6f4476098@mail.gmail.com>
2008-06-28 6:31 ` Fwd: " Robert Anderson
2008-06-28 12:38 ` Dmitry Potapov
[not found] ` <20080628123522.GL5737@dpotapov.dyndns.org>
2008-06-28 15:53 ` Robert Anderson
2008-06-28 16:52 ` Dmitry Potapov
2008-06-27 18:15 ` Junio C Hamano
2008-06-27 18:43 ` Robert Anderson
2008-06-28 5:03 ` Jeff King
2008-06-28 7:03 ` Robert Anderson
2008-06-28 8:53 ` Jeff King
2008-06-28 21:53 ` Junio C Hamano
2008-06-28 14:51 ` Johannes Schindelin
2008-07-08 4:58 ` Jeff King
2008-06-27 20:29 ` David Jeske
2008-06-27 20:29 ` David Jeske
2008-06-27 20:47 ` Jakub Narebski
2008-06-27 20:51 ` David Jeske
2008-06-27 20:51 ` David Jeske
[not found] ` <-8386235276716376372@unknownmsgid>
2008-06-27 22:55 ` Robert Anderson
2008-06-27 23:14 ` Junio C Hamano
2008-06-28 0:08 ` Robert Anderson
2008-06-28 2:57 ` Dmitry Potapov
2008-06-28 3:31 ` Robert Anderson
2008-06-28 14:34 ` Stephen Sinclair
2008-06-28 16:00 ` Robert Anderson
2008-06-28 16:30 ` Robert Anderson
2008-06-28 17:12 ` Jakub Narebski
2008-06-28 18:25 ` Robert Anderson
2008-06-28 19:12 ` David Jeske
2008-06-28 19:12 ` David Jeske [this message]
2008-06-28 19:13 ` Stephen Sinclair
2008-06-28 0:22 ` David Jeske
2008-06-28 0:22 ` David Jeske
2008-06-28 1:17 Theodore Tso
2008-06-28 1:56 ` Miklos Vajna
-- strict thread matches above, loose matches on Subject: below --
2008-06-28 1:23 Theodore Tso
2008-06-28 9:30 Stephen R. van den Berg
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=willow-jeske-01l83mS5FEDjCcUW \
--to=jeske@willowmail.com \
--cc=git@vger.kernel.org \
--cc=jnareb@gmail.com \
--cc=radarsat1@gmail.com \
--cc=rwa000@gmail.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