* Groups of commits
@ 2010-04-28 1:59 John Tapsell
2010-04-28 2:14 ` Jeff King
2010-04-28 2:15 ` Michael Poole
0 siblings, 2 replies; 6+ messages in thread
From: John Tapsell @ 2010-04-28 1:59 UTC (permalink / raw)
To: Git List
Hi all,
In my work place, we have a lot of strict rules to get something
committed. The code has to pass against a large test suite, it has to
be tested on different hardware, and so on.
The problem is that it forces everyone to have one single large
commit for a week's work. All the intermediate stages get squashed
and that history forever lost.
It would be nice to have a commit in the repository, treated as a
single commit for all purposes, but then be able to split it into
multiple commits if necessary.
Any ideas?
John
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Groups of commits
2010-04-28 1:59 Groups of commits John Tapsell
@ 2010-04-28 2:14 ` Jeff King
2010-04-28 2:15 ` Michael Poole
1 sibling, 0 replies; 6+ messages in thread
From: Jeff King @ 2010-04-28 2:14 UTC (permalink / raw)
To: John Tapsell; +Cc: Git List
On Wed, Apr 28, 2010 at 10:59:44AM +0900, John Tapsell wrote:
> In my work place, we have a lot of strict rules to get something
> committed. The code has to pass against a large test suite, it has to
> be tested on different hardware, and so on.
>
> The problem is that it forces everyone to have one single large
> commit for a week's work. All the intermediate stages get squashed
> and that history forever lost.
Redefine "committed" to be "merged to the mainline branch" (or
"committed to the mainline branch" if you need to keep the nomenclature
to please pointy-haired people). Have everybody work on their own branch
each week (or better yet, a branch per topic).
When they would make their single big commit, instead "git merge
--no-ff" from the topic branch into mainline. Do your tests on the
result. If it fails, kick back an error (or whatever you do now). If it
works, then add that merge commit to mainline.
If you want to see the "big commits", follow "log --first-parent" of the
mainline branch. These commits will all pass the test suite. If you want
to see the whole history, then use regular history browsing. Commits on
side-branches do not necessarily pass the test suite.
> It would be nice to have a commit in the repository, treated as a
> single commit for all purposes, but then be able to split it into
> multiple commits if necessary.
My suggestion above is not exactly what you asked for. It treats the
history as multiple commits most of the time, but using --first-parent
you can ask for just the big commits.
-Peff
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Groups of commits
2010-04-28 1:59 Groups of commits John Tapsell
2010-04-28 2:14 ` Jeff King
@ 2010-04-28 2:15 ` Michael Poole
2010-04-28 5:25 ` Tay Ray Chuan
1 sibling, 1 reply; 6+ messages in thread
From: Michael Poole @ 2010-04-28 2:15 UTC (permalink / raw)
To: John Tapsell; +Cc: Git List
John Tapsell writes:
> Hi all,
>
> In my work place, we have a lot of strict rules to get something
> committed. The code has to pass against a large test suite, it has to
> be tested on different hardware, and so on.
>
> The problem is that it forces everyone to have one single large
> commit for a week's work. All the intermediate stages get squashed
> and that history forever lost.
>
> It would be nice to have a commit in the repository, treated as a
> single commit for all purposes, but then be able to split it into
> multiple commits if necessary.
>
> Any ideas?
Isn't that what topic branches are for? When development is done on a
short-lived branch (hopefully one with a descriptive name), the only
commit that needs to go through that process is the merge onto the
integration branch.
Michael Poole
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Groups of commits
2010-04-28 2:15 ` Michael Poole
@ 2010-04-28 5:25 ` Tay Ray Chuan
2010-04-28 8:05 ` Alex Riesen
0 siblings, 1 reply; 6+ messages in thread
From: Tay Ray Chuan @ 2010-04-28 5:25 UTC (permalink / raw)
To: Michael Poole; +Cc: John Tapsell, Jeff King, Git List
On Wed, Apr 28, 2010 at 10:15 AM, Michael Poole <mdpoole@troilus.org> wrote:
> John Tapsell writes:
>
>> Hi all,
>>
>> In my work place, we have a lot of strict rules to get something
>> committed. The code has to pass against a large test suite, it has to
>> be tested on different hardware, and so on.
>>
>> The problem is that it forces everyone to have one single large
>> commit for a week's work. All the intermediate stages get squashed
>> and that history forever lost.
>>
>> It would be nice to have a commit in the repository, treated as a
>> single commit for all purposes, but then be able to split it into
>> multiple commits if necessary.
>>
>> Any ideas?
>
> Isn't that what topic branches are for? When development is done on a
> short-lived branch (hopefully one with a descriptive name), the only
> commit that needs to go through that process is the merge onto the
> integration branch.
Just to add to the "merge in topic branches" idea - if you find that
the commits are trivially fast-forwardable, you can still add a short
note/cover letter with
git merge --no-ff -m "Added in foo's work" <branch/commit>
--
Cheers,
Ray Chuan
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Groups of commits
2010-04-28 5:25 ` Tay Ray Chuan
@ 2010-04-28 8:05 ` Alex Riesen
2010-04-28 12:46 ` Avery Pennarun
0 siblings, 1 reply; 6+ messages in thread
From: Alex Riesen @ 2010-04-28 8:05 UTC (permalink / raw)
To: Tay Ray Chuan; +Cc: Michael Poole, John Tapsell, Jeff King, Git List
On Wed, Apr 28, 2010 at 07:25, Tay Ray Chuan <rctay89@gmail.com> wrote:
> Just to add to the "merge in topic branches" idea - if you find that
> the commits are trivially fast-forwardable, you can still add a short
> note/cover letter with
>
> git merge --no-ff -m "Added in foo's work" <branch/commit>
>
Except that is not a "short note" anymore, but a full-fledged merge
commit. You forced it with "--no-ff".
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Groups of commits
2010-04-28 8:05 ` Alex Riesen
@ 2010-04-28 12:46 ` Avery Pennarun
0 siblings, 0 replies; 6+ messages in thread
From: Avery Pennarun @ 2010-04-28 12:46 UTC (permalink / raw)
To: Alex Riesen
Cc: Tay Ray Chuan, Michael Poole, John Tapsell, Jeff King, Git List
On Wed, Apr 28, 2010 at 4:05 AM, Alex Riesen <raa.lkml@gmail.com> wrote:
> On Wed, Apr 28, 2010 at 07:25, Tay Ray Chuan <rctay89@gmail.com> wrote:
>> Just to add to the "merge in topic branches" idea - if you find that
>> the commits are trivially fast-forwardable, you can still add a short
>> note/cover letter with
>>
>> git merge --no-ff -m "Added in foo's work" <branch/commit>
>
> Except that is not a "short note" anymore, but a full-fledged merge
> commit. You forced it with "--no-ff".
I think it's safe to say that a commit *is* just a "short note" about
a tree, who made it, the reason (message), and who its parents were.
Have fun,
Avery
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2010-04-28 12:46 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2010-04-28 1:59 Groups of commits John Tapsell
2010-04-28 2:14 ` Jeff King
2010-04-28 2:15 ` Michael Poole
2010-04-28 5:25 ` Tay Ray Chuan
2010-04-28 8:05 ` Alex Riesen
2010-04-28 12:46 ` Avery Pennarun
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).