Joel Becker [off-list ref] writes:
No, you're reading me wrong, but I wasn't clear enough either.
At the end of my message, I'm noting that I'm considering smaller
changes here, not huge features.
OK. Consolidating two or more patches into one is something I
have done too, but I never felt need for tool support, so that's
probably why I misunderstood you.
After extracting a sequence of the dirty commits using
git-format-patch, I would say:
for i in 0*.txt; do git-apply --index $i; done
to bring my tree up to date, and then just say "git commit".
Typically when I do this, I have one "significant" commit among
them, usually early in the series, which is followed by smaller
"fix this, fix that, oops fix that too" commits. So I edit the
log message using the log of the significant commit, and add
some missing bits.
I guess another way to do it without even first extracting them
as patches would be:
$ git checkout -b mytopic master
$ work work work, commit commit commit.
$ git checkout master
$ git-read-tree -m -u master mytopic
$ git-commit -c <that-significant-commit-in-mytopic-branch>
If you want a tool support for this workflow, probably the last
two could be somewhat automated. But what would the user input
for that be? You need to tell what tree shape you want the
after-commit tree to be in, and where you would want the bulk of
your commit message to come from.
One possibility.
$ git-squash-pick mytopic
would be something like this:
#!/bin/sh
#
git-read-tree -m -u HEAD "$1"
git log HEAD.."$1" >.tmp-commit
git-commit -F .tmp-commit -e
Your commit-log edit buffer would start with the concatenation
of all the commit logs in that throwaway history, and hopefully
you would mostly need to delete lines and move some parts around
before committing. I do not know how useful this kind of
specialized tool would be, though...
Splitting and merging patches into logical steps is something I
dream of to be automated, but I do not know how (nor even if it
is possible) offhand. Sometimes, when you want truly logical
steps, you would end up needing intermediate steps that never
existed in your true history (i.e. "in the hindsight, my
development should have progressed in these steps.")
On Mon, Oct 31, 2005 at 04:20:51PM -0800, Junio C Hamano wrote:
After extracting a sequence of the dirty commits using
git-format-patch, I would say:
for i in 0*.txt; do git-apply --index $i; done
to bring my tree up to date, and then just say "git commit".
Yeah, but this is a lot of by-hand (as you note below).
Typically when I do this, I have one "significant" commit among
them, usually early in the series, which is followed by smaller
"fix this, fix that, oops fix that too" commits. So I edit the
log message using the log of the significant commit, and add
some missing bits.
When I work, regardless of SCM, I generally have many
checkpoints along the way. It might be a particular subfeature is
complete (and probably deserves a split-out patch of its own when I do
the "clean" merge), but it could also just be "I changed a lot today,
and I'd really like to save that off." So, while somtimes it looks just
like your "significant commit + fixes" model, it might also be "1/4 the
work", "compile fix on other platform, "1/2 the work", "fix", "the rest
of the work", all over the course of two days.
$ git-read-tree -m -u master mytopic
$ git-commit -c <that-significant-commit-in-mytopic-branch>
Replace <that-...> with <overall-concept-of-the-change> and you
have the workflow I'm talking about.
You know, this is a simpler command set than I am using. I've
been using Cogito, because it makes many of the 5-step git operations a
single step, more like some other tools. But I know no way to tell
Cogito to merge all the changes of the branch into the master without
also pulling in the commit history. That's the thing here. Petr, do
you have a way of doing this that I don't know about?
What I mean is, for the "naive" Cogito workflow:
cg-clone repo working
cd working
hack hack hack, commit commit commit
cd mainline
cg-pull working
the cg-pull command merges the changes back, but it also includes the
full commit history. Not what we want. Compare the "identical"
workflow:
cg-clone repo working
cd working
hack hack hack, commit commit commit
cg-diff mainline working > patch
cd mainline
cg-apply < patch
cg-commit
My basic premise is that I shouldn't have to deal with diff/patch as an
external step, especially since git knows more about the tree than
diff/patch do. It's a useless hoop to jump through.
Maybe Cogito contains something like what you describe above, a
way to get all the file changes without actually pulling in the commit
history. I don't care that the read-tree and the commit are separate
stages. I just have to type them.
is possible) offhand. Sometimes, when you want truly logical
steps, you would end up needing intermediate steps that never
existed in your true history (i.e. "in the hindsight, my
development should have progressed in these steps.")
Yes, I always do. But I'm not talking about that sort of large
feature add or whatever. I'm talking about merely doing something on a
small scale, but in a temporary repository.
Joel
--
Life's Little Instruction Book #510
"Count your blessings."
Joel Becker
Principal Software Developer
Oracle
E-mail: joel.becker@oracle.com
Phone: (650) 506-8127
On 11/1/05, Joel Becker [off-list ref] wrote:
quoted
is possible) offhand. Sometimes, when you want truly logical
steps, you would end up needing intermediate steps that never
existed in your true history (i.e. "in the hindsight, my
development should have progressed in these steps.")
Yes, I always do. But I'm not talking about that sort of large
feature add or whatever. I'm talking about merely doing something on a
small scale, but in a temporary repository.
I'm really surprised that Calalin hasn't chimed in. If you are into
rewriting/merging/splitting your patches, StGIT is your friend. Check
out: http://www.procode.org/stgit/
cheers,
martin
On Tue, Nov 01, 2005 at 02:02:43PM +1300, Martin Langhoff wrote:
I'm really surprised that Calalin hasn't chimed in. If you are into
rewriting/merging/splitting your patches, StGIT is your friend. Check
out: http://www.procode.org/stgit/
But I'm not. I don't want patches in the first place. I want
cg-pull but with a flattened history.
Joel
--
"Any man who is under 30, and is not a liberal, has not heart;
and any man who is over 30, and is not a conservative, has no brains."
- Sir Winston Churchill
Joel Becker
Principal Software Developer
Oracle
E-mail: joel.becker@oracle.com
Phone: (650) 506-8127
On Mon, 31 Oct 2005, Joel Becker wrote:
But I'm not. I don't want patches in the first place. I want
cg-pull but with a flattened history.
Well, that you've largely got in "git rebase". But if you wanrt to merge
commits, you'd have to do that logic yourself..
Linus
Dear diary, on Tue, Nov 01, 2005 at 02:29:15AM CET, I got a letter
where Joel Becker [off-list ref] told me that...
On Tue, Nov 01, 2005 at 02:02:43PM +1300, Martin Langhoff wrote:
quoted
I'm really surprised that Calalin hasn't chimed in. If you are into
rewriting/merging/splitting your patches, StGIT is your friend. Check
out: http://www.procode.org/stgit/
But I'm not. I don't want patches in the first place. I want
cg-pull but with a flattened history.
StGIT does not work with patches but with commits. You can manage the
logical changes with StGIT and when it's time, just merge your
StGIT-tracked branch with whatever else. "Patch" here is really just a
different name for logical change / commit.
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
VI has two modes: the one in which it beeps and the one in which
it doesn't.