Merging commits together into a super-commit

Merging commits together into a super-commit

[Alex Bennee]

Hi,

I really love the fact I can micro-commit changes when I'm developing.
However at some point the combination of changes I have made can be
considered a single body of work. This is especially true when you start
doing things like re-basing on code that has moved around a lot. You
don't want to be correcting a whole bunch of merge failures for every
commit in your current tree.

So far the only was I can see to do this is a:

git-diff master..HEAD > my.patch

And then re-applying your patch in stages, manually doing the commits.

Am I missing something?

I'm thinking something like git-cherrypick taking multiple commits and
create a new super commit on a new tree. i.e.:

git-cherrypick -m "Valgrind fixes" 12345.. 12678.. 565757..

Merging the existing commit comments would be nice too.

-- 
Alex, homepage: http://www.bennee.com/~alex/
All God's children are not beautiful. Most of God's children are, in
fact, barely presentable. -- Fran Lebowitz, "Metropolitan Life"

RE: Merging commits together into a super-commit

[Raimund Bauer]

> Hi,
> 
> I really love the fact I can micro-commit changes when I'm 
> developing. However at some point the combination of changes 
> I have made can be considered a single body of work. This is 
> especially true when you start doing things like re-basing on 
> code that has moved around a lot. You don't want to be 
> correcting a whole bunch of merge failures for every commit 
> in your current tree.
> 
> So far the only was I can see to do this is a:
> 
> git-diff master..HEAD > my.patch
> 
> And then re-applying your patch in stages, manually doing the commits.
> 
> Am I missing something?

git merge --squash ?

-- 
best regards

  Ray

RE: Merging commits together into a super-commit

[Alex Bennee]

On Thu, 2007-05-10 at 13:19 +0200, Raimund Bauer wrote:
> > Hi,
>  <snip> 
> You don't want to be 
> > correcting a whole bunch of merge failures for every commit 
> > in your current tree.
> > 
> > So far the only was I can see to do this is a:
> > 
> > git-diff master..HEAD > my.patch
> > 
> > And then re-applying your patch in stages, manually doing the commits.
> > 
> > Am I missing something?
> 
> git merge --squash ?

Hmm, that would do although it only works on whole trees, you can't
specify a range of commits. So you would have to cherrypick groups of
changes onto other branches and then merge them together with a couple
of --squashes

However thanks for pointing that one out :-)

-- 
Alex, homepage: http://www.bennee.com/~alex/
A pretty woman can do anything; an ugly woman must do everything.

Re: Merging commits together into a super-commit

[Johannes Sixt]

Alex Bennee wrote:
> I really love the fact I can micro-commit changes when I'm developing.
> However at some point the combination of changes I have made can be
> considered a single body of work. This is especially true when you start
> doing things like re-basing on code that has moved around a lot. You
> don't want to be correcting a whole bunch of merge failures for every
> commit in your current tree.
> 
> So far the only was I can see to do this is a:
> 
> git-diff master..HEAD > my.patch
> 
> And then re-applying your patch in stages, manually doing the commits.
> 
> Am I missing something?
> 
> I'm thinking something like git-cherrypick taking multiple commits and
> create a new super commit on a new tree. i.e.:
> 
> git-cherrypick -m "Valgrind fixes" 12345.. 12678.. 565757..
> 
> Merging the existing commit comments would be nice too.

Here we go:

- cherry-pick them before commit

  $ git cherry-pick -n x
  $ git cherry-pick -n y
  $ git cherry-pick -n z
  $ git commit -m "$(for c in x y z; do git show --stat $c; done)" -e

- merge in a single commit

  $ git merge --squash foo

You didn't really think that git couldn't do that, did you? ;)

-- Hannes

RE: Merging commits together into a super-commit

[Johannes Schindelin]

Hi,

On Thu, 10 May 2007, Alex Bennee wrote:

> On Thu, 2007-05-10 at 13:19 +0200, Raimund Bauer wrote:
> > > Hi,
> >  <snip> 
> > You don't want to be 
> > > correcting a whole bunch of merge failures for every commit 
> > > in your current tree.
> > > 
> > > So far the only was I can see to do this is a:
> > > 
> > > git-diff master..HEAD > my.patch
> > > 
> > > And then re-applying your patch in stages, manually doing the commits.
> > > 
> > > Am I missing something?
> > 
> > git merge --squash ?
> 
> Hmm, that would do although it only works on whole trees, you can't
> specify a range of commits. So you would have to cherrypick groups of
> changes onto other branches and then merge them together with a couple
> of --squashes

Since specifying several commit ranges can always lead to merge conflicts, 
it makes no sense to _not_ accumulate the patches in a separate branch.

Ciao,
Dscho

Re: Merging commits together into a super-commit

[Linus Torvalds]

On Thu, 10 May 2007, Johannes Sixt wrote:
>
> - cherry-pick them before commit
> 
>   $ git cherry-pick -n x
>   $ git cherry-pick -n y
>   $ git cherry-pick -n z

I've done this (actually, mostly with "revert", but cherry-pick and revert 
are literally the same things).

However:

>   $ git commit -m "$(for c in x y z; do git show --stat $c; done)" -e

I'm too lazy to do this part, so I always do it by hand.

> You didn't really think that git couldn't do that, did you? ;)

Clearly git can, but equally clearly it really *would* be pretty nice if 
you could just do

	git cherry-pick x y z

and create one commit and have the message already somewhat done for you 
(and "git revert" doing the same).

So if somebody does that, I'll certainly applaud..

		Linus

Re: Merging commits together into a super-commit

[Carl Worth]

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

On Thu, 10 May 2007 09:01:15 -0700 (PDT), Linus Torvalds wrote:
> Clearly git can, but equally clearly it really *would* be pretty nice if
> you could just do
>
> 	git cherry-pick x y z
>
> and create one commit and have the message already somewhat done for you
> (and "git revert" doing the same).

Perhaps with a --squash option. I've already been wanting a
cherry-pick that accepts a range, but that makes separate commits.

Yes, I know there's some git-rebase thing that will do it, but I can
never remember the right syntax for that without studying the
documentation[*]. What I find myself wanting to type is just:

	git cherry-pick A..B

But there is the whole problem of how to deal with any conflict that
appears during the process.

-Carl

[*] I do use one form of rebase without ever needing to consult the
documentation, but it's in the opposite "direction", if you will, from
the cherry-pick-a-range operation. I use it when I want to rebase a
set of commits from my current branch to some other branch, such as:

	git rebase origin

Not surprisingly, what's common about both of the operations above is
that they are really only accepting a single argument, (a range in one
case, and a branch-name in the other). That's what makes for an
easy-to-use command. Things that require multiple branch names in a
particular order, or extra options, (see "git rebase --onto newbase
upstream branch"), need someone smarter than me to drive them.

Another problem is that using the optional final [<branch>] argument
to git-rebase makes it change the current branch, (which no other
git-rebase operation does), and that's another thing I find very
confusing.

I'm sure the most complex form of git-rebase solves some precise
problem that someone has, (and maybe even gets used regularly). But
it's got enough complications that I just ignore it, (and would
instead really prefer being able to just cherry-pick a whole range).


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

Re: Merging commits together into a super-commit

[J. Bruce Fields]

On Thu, May 10, 2007 at 09:57:10AM -0700, Carl Worth wrote:
> I'm sure the most complex form of git-rebase solves some precise
> problem that someone has, (and maybe even gets used regularly). But
> it's got enough complications that I just ignore it, (and would
> instead really prefer being able to just cherry-pick a whole range).

I use it all the time to fix up old commits with

	git checkout sha1-of-bad-commit
	...edit, test,...
	git commit -a ---amend
	git rebase --onto HEAD sha1-of-bad-commit original-branch

But though it usually does what I want, I'm in total agreement about the
confusing syntax and branch-switching behavior....

--b.

Re: Merging commits together into a super-commit

[Carl Worth]

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

On Thu, 10 May 2007 13:14:57 -0400, "J. Bruce Fields" wrote:
> I use it all the time to fix up old commits with
>
> 	git checkout sha1-of-bad-commit
> 	...edit, test,...
> 	git commit -a ---amend
> 	git rebase --onto HEAD sha1-of-bad-commit original-branch

Excellent. Thanks for the description.

Fixing up some broken (unpublished) commit in the past is a useful
thing to support[*]. Of course, "commit --amend" takes care of this for
the case where it's the most recent commit. For an older commit, here
is exactly what I'd like to do, (showing that my suggestion of
cherry-pick with a range would cover exactly this scenario):

	git tag tainted		# Could be "git branch tainted" just as well

	git reset --hard bad-commit
	...edit, test...
	git commit --amend
	git cherry-pick bad-commit..tainted

	git tag -d tainted

So, compared to the rebase usage, this does add two commands for
bookkeeping the original state and cleaning it up. But the syntax for
the cherry-pick part is quite a bit simpler than the original rebase
at least.

Also, "reset --hard" isn't actually what I want in this case. I'd like
this recipe to use something that would move the current branch to
some other point, but in a safe way, (that is, not destroy any
uncommitted changes that might exist at the beginning). I don't have
any proposal for what that would be.

-Carl

[*] I've also experimented with using other "non-core git" ways of
addressing this same problem. Here are a couple that I haven't found
satisfactory for this particular use case:

stg - This probably works great if you're using it as a primary
      interface. But trying to use it as a quick one-off when
      generally using core git does not work well at all. Instead of
      the two "git tag" commands in my recipe above, an stg recipe
      would involve a lot of additional bookkeeping with stg init, stg
      uncommit [N times for fixing a commit N steps back in the
      history], stg goto, stg push, etc.

cg-admin-rewritehist - This is a powerful tool, but its interface
      isn't geared toward interactively fixing things up, (instead
      requiring a filter to be executed at all steps). So, while it's
      great for changing history, (as its name suggests), such as
      performing a sed operation on the commit messages, or
      eliminating a file, it doesn't help much with the "fix up one
      broken commit in the past".

      It is worth noting that quite unlike rebase,
      cg-admin-rewritehist can deal quite nicely with history that
      involves branching and merging.


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

Re: Merging commits together into a super-commit

[Petr Baudis]

On Thu, May 10, 2007 at 08:30:37PM CEST, Carl Worth wrote:
> stg - This probably works great if you're using it as a primary
>       interface. But trying to use it as a quick one-off when
>       generally using core git does not work well at all. Instead of
>       the two "git tag" commands in my recipe above, an stg recipe
>       would involve a lot of additional bookkeeping with stg init, stg
>       uncommit [N times for fixing a commit N steps back in the
>       history], stg goto, stg push, etc.

I think you are underestimating stg here. You can stg init just once per
branch (ever), I think. Then,

	stg uncommit -n N
	stg pop -n N-1
	..hack..
	stg refresh
	stg push -a

It seems to be a bit shorter than the sequence you've presented above,
and overally working with volatile commits using StGIT feels much more
natural to me - and I haven't even ever used quilt seriously! (I have
special antipathy to the git reset UI, too.)

Few days ago Santi Bejar has sent me a bundle with some updates to the
Git homepage (thanks again a lot!). Since I didn't want some of the
patches and wanted to tweak others, what I eventually did was pretty
much this: I fast-forwarded my master to his bundle's head, then
uncommitted the patches, popped them all and repeated the sequence

	stg push
	..review..
		stg refresh
		stg commit
	..or..
		stg delete `stg top`

for each patch.

-- 
				Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
Ever try. Ever fail. No matter. // Try again. Fail again. Fail better.
		-- Samuel Beckett

Re: Merging commits together into a super-commit

[J. Bruce Fields]

On Thu, May 10, 2007 at 11:30:37AM -0700, Carl Worth wrote:
> So, compared to the rebase usage, this does add two commands for
> bookkeeping the original state and cleaning it up. But the syntax for
> the cherry-pick part is quite a bit simpler than the original rebase
> at least.

Yeah, something like that would be great.  I think I've seen others
suggest similar syntax before, so it's probably just a question of one
of us who want this finding time to write the patches.

> Also, "reset --hard" isn't actually what I want in this case. I'd like
> this recipe to use something that would move the current branch to
> some other point, but in a safe way, (that is, not destroy any
> uncommitted changes that might exist at the beginning). I don't have
> any proposal for what that would be.

The tag creation and cleanup could get to be annoying too.  You could
scrounge through the reflog instead of using a temporary tag, but
depending on the amount of --amend'ing and cherry-picking you do the
reflog entry may end up in a different place each time, so it's probably
hard to make this automatic.

> stg - This probably works great if you're using it as a primary
>       interface. But trying to use it as a quick one-off when
>       generally using core git does not work well at all. Instead of
>       the two "git tag" commands in my recipe above, an stg recipe
>       would involve a lot of additional bookkeeping with stg init, stg
>       uncommit [N times for fixing a commit N steps back in the
>       history], stg goto, stg push, etc.

I also didn't like having to come up with another name for each
patch--I'd rather just run git-log or gitk and cut-n-paste the sha1.

For kernel work I started out working with multiple (sym- or
hard-linked) trees, then used akpm's patch scripts, then stgit.  I think
I'm happiest just using plain git.

The one thing I've never been good at is keeping the history of the
patch series itself.

--b.

Re: Merging commits together into a super-commit

[Petr Baudis]

On Thu, May 10, 2007 at 09:22:12PM CEST, J. Bruce Fields wrote:
> On Thu, May 10, 2007 at 11:30:37AM -0700, Carl Worth wrote:
> > stg - This probably works great if you're using it as a primary
> >       interface. But trying to use it as a quick one-off when
> >       generally using core git does not work well at all. Instead of
> >       the two "git tag" commands in my recipe above, an stg recipe
> >       would involve a lot of additional bookkeeping with stg init, stg
> >       uncommit [N times for fixing a commit N steps back in the
> >       history], stg goto, stg push, etc.
> 
> I also didn't like having to come up with another name for each
> patch--I'd rather just run git-log or gitk and cut-n-paste the sha1.

Actually, you don't have to - if you don't specify the patch names,
stgit will make them up itself using the subject of the commit message
as a base.

And by the way, I absolutely love that - when viewing the stack, it's
very useful to see what commits you still have to go etc. - stg series
is concise yet fully descriptive. I'm pondering about whether something
like this couldn't be incorporated into other git UIs somehow as well.

-- 
				Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
Ever try. Ever fail. No matter. // Try again. Fail again. Fail better.
		-- Samuel Beckett

Re: Merging commits together into a super-commit

[Carl Worth]

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

On Thu, 10 May 2007 21:21:06 +0200, Petr Baudis wrote:
> I think you are underestimating stg here.

Yes, maybe I didn't learn to use it well enough.

> You can stg init just once per branch (ever), I think.

I don't have details now, but I know I ran into some difficulty when
leaving the extra stg state around. It seems that it added stuff that
resulted in some reference of mine becoming ambiguous, ("refspec <foo>
matches more than one" perhaps?). What I do remember is that I couldn't
get one of my standard git push commands to work until I deleted all
of .git/refs/bases and .git/refs/patches and then things started to
work again.

> 	stg uncommit -n N
> 	stg pop -n N-1
> 	..hack..
> 	stg refresh
> 	stg push -a
>
> It seems to be a bit shorter than the sequence you've presented above,
> and overally working with volatile commits using StGIT feels much more
> natural to me - and I haven't even ever used quilt seriously! (I have
> special antipathy to the git reset UI, too.)

The -n option is something I hadn't noticed, and that helps, (except
that what I've got to start with is a git revision name, not a
number).

But there are still some places where an experienced git user runs
into some awkward situations trying to use stg. For example, "stg
refresh" is basically always doing the equivalent of "commit -a" so
there's annoyingly no way to refresh only some of the modified state
into the commit.

Also, if I want to edit a commit message while under the influence of
stg, how do I do that? If I do "git commit --amend" will I seriously
confuse stg, (I'm guessing I would, but I don't know).

It's that kind of uncertainty that makes me uncomfortable to mix git
and stg. And personally, I couldn't get excited about using it alone,
(for example, in addition to the commit message with headline, stg
makes me invent yet _another_ name for every commit---yuck). Not to
mention I'm already quite comfortable with git alone, and all the
flexibility it provides.

Plus, all the stuff that stg provides to allow it to be used
standalone ends up just being noise to the git user that just wants to
do some stack-based manipulation of an unpublished branch, for
example.

So, I'd really like to see something more integrated into git itself
that provides some of the missing functionality.

-Carl

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

Re: Merging commits together into a super-commit

[J. Bruce Fields]

On Thu, May 10, 2007 at 09:47:42PM +0200, Petr Baudis wrote:
> Actually, you don't have to - if you don't specify the patch names,
> stgit will make them up itself using the subject of the commit message
> as a base.

You still have to on new patches, right?

> And by the way, I absolutely love that - when viewing the stack, it's
> very useful to see what commits you still have to go etc. - stg series
> is concise yet fully descriptive.

Sure.

I mainly find myself using gitk origin.. for that now.  My main problem
there is just that it's slow.  (And File->Update) seems possibly even
slower than just killing and restarting it.--b.

Re: Merging commits together into a super-commit

[Robin Rosenberg]

torsdag 10 maj 2007 skrev Carl Worth:
> But there are still some places where an experienced git user runs
> into some awkward situations trying to use stg. For example, "stg
> refresh" is basically always doing the equivalent of "commit -a" so
> there's annoyingly no way to refresh only some of the modified state
> into the commit.

List the files to refresh and you get what you want.

	stg refresh file1 file2...

> Also, if I want to edit a commit message while under the influence of
> stg, how do I do that? If I do "git commit --amend" will I seriously
> confuse stg, (I'm guessing I would, but I don't know).

	stg refresh -e

[...]
> Plus, all the stuff that stg provides to allow it to be used
> standalone ends up just being noise to the git user that just wants to
> do some stack-based manipulation of an unpublished branch, for
> example.
>
> So, I'd really like to see something more integrated into git itself
> that provides some of the missing functionality.

I agree mixing stgit and git is not really comfy until you learn it and still
I mess things up somtimes. Also rebase seems quite a bit faster than stgit, but I
have not intuitive understanding for rebase so I get scared everytime. Having
a gui that lets me mark commits and "drag" them to the new location would
be nice.

-- robin

Re: Merging commits together into a super-commit

[linux]

Er... why is everyone making this so complex?

git checkout trunk	# Switch to "trunk"
git checkout branch .	# Overwrite with "branch", but stay on "trunk"
git commit

Now branch is the same tree object as "branch", but without the history.

Of course, you could be even nastier and di a direct

git-commit-tree branch^{tree} -p HEAD < commit_message

But that's not really necessary.


Starting from the branch, using the high-level commands is a bit awkward,
but it's easy enough to:

git-update-ref HEAD trunk
git-commit

Re: Merging commits together into a super-commit

[Alex Riesen]

On 10 May 2007 17:55:15 -0400, linux@horizon.com <linux@horizon.com> wrote:
> Er... why is everyone making this so complex?
>
> git checkout trunk      # Switch to "trunk"
> git checkout branch .   # Overwrite with "branch", but stay on "trunk"
> git commit
>
> Now branch is the same tree object as "branch", but without the history.
>
> Of course, you could be even nastier and di a direct
>
> git-commit-tree branch^{tree} -p HEAD < commit_message
>

And it is not enough. Authorship information is lost. And you
have to be damn sure the "branch" starts directly at HEAD,
otherwise everything HEAD..branch is lost. It is complex
if you want it right.

Merging commits together into a super-commit

[Eugine Kosenko]

2007/5/11, Alex Riesen <raa.lkml@gmail.com>:
> And it is not enough. Authorship information is lost.

If one dare to make such super-commit, he would be the author of the
whole couple of changes.

> And you have to be damn sure the "branch" starts directly at HEAD,
> otherwise everything HEAD..branch is lost. It is complex
> if you want it right.

I used to make git-rebase to add extra commits after this.

Re: Merging commits together into a super-commit

[Yann Dirson]

On Thu, May 10, 2007 at 12:48:05PM -0700, Carl Worth wrote:
> On Thu, 10 May 2007 21:21:06 +0200, Petr Baudis wrote:
> > I think you are underestimating stg here.
> 
> Yes, maybe I didn't learn to use it well enough.
> 
> > You can stg init just once per branch (ever), I think.
> 
> I don't have details now, but I know I ran into some difficulty when
> leaving the extra stg state around.

I really think we should have a "stg uninit" command.  Note that
currently "stg branch --delete" on master will just do that instead of
really deleting the branch, but that is a known bug (#8732 on gna).

> It seems that it added stuff that
> resulted in some reference of mine becoming ambiguous, ("refspec <foo>
> matches more than one" perhaps?). What I do remember is that I couldn't
> get one of my standard git push commands to work until I deleted all
> of .git/refs/bases and .git/refs/patches and then things started to
> work again.

I remember quite some time ago that cg-push exhibited this behaviour.
However, nowadays I frequently push stgit stacks with git-push without
a problem.

> > 	stg uncommit -n N
> > 	stg pop -n N-1
> > 	..hack..
> > 	stg refresh
> > 	stg push -a
> >
> > It seems to be a bit shorter than the sequence you've presented above,
> > and overally working with volatile commits using StGIT feels much more
> > natural to me - and I haven't even ever used quilt seriously! (I have
> > special antipathy to the git reset UI, too.)
> 
> The -n option is something I hadn't noticed, and that helps, (except
> that what I've got to start with is a git revision name, not a
> number).

While "uncommit to named commit" that Karl implemented helps here, and
that "stg goto <patchname>" may be a viable alternative to "pop -n",
you may also want to try:

	stg uncommit -t <commit>
	..hack..
	stg refresh -p <patchname>

There are still some rough edges with "refresh -p", though[*], but
when it works I love this comfort :)

Best regards,
-- 
Yann.

[*] most notably, it does not work yet if any patch above the one you
want to modify changes the same file)

Re: Merging commits together into a super-commit

[Jan Hudec]

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

On Fri, May 11, 2007 at 15:41:45 +0300, Eugine Kosenko wrote:
> 2007/5/11, Alex Riesen <raa.lkml@gmail.com>:
> >And it is not enough. Authorship information is lost.
> 
> If one dare to make such super-commit, he would be the author of the
> whole couple of changes.

No, he would not. He would be committer, but the change would still be based
on the work of the original authors and therefore would have to be attributed
to them (and especially they would still remain copyright holders).

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

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

Re: Merging commits together into a super-commit

[Jakub Narebski]

Yann Dirson wrote:

> On Thu, May 10, 2007 at 12:48:05PM -0700, Carl Worth wrote:
>> On Thu, 10 May 2007 21:21:06 +0200, Petr Baudis wrote:
>> > I think you are underestimating stg here.
>> 
>> Yes, maybe I didn't learn to use it well enough.
>> 
>> > You can stg init just once per branch (ever), I think.
>> 
>> I don't have details now, but I know I ran into some difficulty when
>> leaving the extra stg state around.
> 
> I really think we should have a "stg uninit" command.  Note that
> currently "stg branch --delete" on master will just do that instead of
> really deleting the branch, but that is a known bug (#8732 on gna).

It would be also nice to have command to remove applied patches.
Sometimes I'd muck up StGIT stack by rebasing in git. Applied patches
are in repository, but I'm interested in preserving unapplied ones.

-- 
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git

Re: Merging commits together into a super-commit

[Karl Hasselström]

On 2007-05-12 13:34:30 +0200, Yann Dirson wrote:

> I really think we should have a "stg uninit" command. Note that
> currently "stg branch --delete" on master will just do that instead
> of really deleting the branch, but that is a known bug (#8732 on
> gna).

What we should do is delete all stgit metadata when the last patch
goes away.

And we shouldn't have "stg init", either. Initing should be done
automatically when needed.

-- 
Karl Hasselström, kha@treskal.com
      www.treskal.com/kalle

Re: Merging commits together into a super-commit

[Yann Dirson]

On Sat, May 12, 2007 at 04:02:28PM +0200, Karl Hasselström wrote:
> On 2007-05-12 13:34:30 +0200, Yann Dirson wrote:
> 
> > I really think we should have a "stg uninit" command. Note that
> > currently "stg branch --delete" on master will just do that instead
> > of really deleting the branch, but that is a known bug (#8732 on
> > gna).
> 
> What we should do is delete all stgit metadata when the last patch
> goes away.

This supposes there is no valuable branch-level metadata.  Currently
we have the description - something which could arguably be moved to
the git level as well.  Otherwise that sounds reasonable to me.

> And we shouldn't have "stg init", either. Initing should be done
> automatically when needed.

Good idea as well, that would make stg more accessible to the average
plain-git user.

Best regards,
-- 
Yann.

Re: Merging commits together into a super-commit

[Karl Hasselström]

On 2007-05-12 16:41:45 +0200, Yann Dirson wrote:

> On Sat, May 12, 2007 at 04:02:28PM +0200, Karl Hasselström wrote:
>
> > What we should do is delete all stgit metadata when the last patch
> > goes away.
>
> This supposes there is no valuable branch-level metadata. Currently
> we have the description - something which could arguably be moved to
> the git level as well. Otherwise that sounds reasonable to me.

I left the branch description out of the discussion on purpose, since
it's not that interesting -- if there is a description, we can simply
delete everything except that. And I wholeheartedly agree that the
branch description doesn't belong in stgit; it's orthogonal to the
business of managing a patch stack.

> > And we shouldn't have "stg init", either. Initing should be done
> > automatically when needed.
>
> Good idea as well, that would make stg more accessible to the
> average plain-git user.

Yes, that's my secret evil master plan.

-- 
Karl Hasselström, kha@treskal.com
      www.treskal.com/kalle

Re: Merging commits together into a super-commit

[Junio C Hamano]

Yann Dirson <ydirson@altern.org> writes:

> On Sat, May 12, 2007 at 04:02:28PM +0200, Karl Hasselström wrote:
>> ...
>> What we should do is delete all stgit metadata when the last patch
>> goes away.
>
> This supposes there is no valuable branch-level metadata.  Currently
> we have the description - something which could arguably be moved to
> the git level as well.  Otherwise that sounds reasonable to me.

Will it be something like

	[branch "master"]
        	description = "My primary development line"

if so I think that is a reasonable thing to do, from git-core's
point of view.  Obviously, gitk, tig, gitweb and friends can use
this, too.

Are there other per-branch information StGIT wants to keep on an
active branch that might benefit the core as well?

>> And we shouldn't have "stg init", either. Initing should be done
>> automatically when needed.
>
> Good idea as well, that would make stg more accessible to the average
> plain-git user.

Yes, I wished for this often myself.

Re: Merging commits together into a super-commit

[Karl Hasselström]

On 2007-05-12 12:27:49 -0700, Junio C Hamano wrote:

> Yann Dirson <ydirson@altern.org> writes:
>
> > This supposes there is no valuable branch-level metadata.
> > Currently we have the description - something which could arguably
> > be moved to the git level as well. Otherwise that sounds
> > reasonable to me.
>
> Will it be something like
>
>       [branch "master"]
>               description = "My primary development line"

Yes, exactly. It's just a simple per-branch description string, just
like in your suggestion.

> if so I think that is a reasonable thing to do, from git-core's
> point of view. Obviously, gitk, tig, gitweb and friends can use
> this, too.

Absolutely.

> Are there other per-branch information StGIT wants to keep on an
> active branch that might benefit the core as well?

No, I'm pretty sure there isn't.

-- 
Karl Hasselström, kha@treskal.com
      www.treskal.com/kalle

Re: Merging commits together into a super-commit

[Yann Dirson]

On Sat, May 12, 2007 at 12:27:49PM -0700, Junio C Hamano wrote:
> Are there other per-branch information StGIT wants to keep on an
> active branch that might benefit the core as well?

Maybe the "protected" attribute, to forbid commands to touch to the
stack ?  Not sure, however, since the semantics would probably be a
bit different in git (eg. just forbid update-ref) and in StGIT (also
protects unapplied patches).

Best regards,
-- 
Yann