tags:

views:

65

answers:

3

Hi,

I don't know how to bring my problem on the point so I try to explain it a bit ;-)

When working with git on my local maschine I usually commit a lot. For this I use topic branches. Then I merge such a topic branch into a branch called develop which will be pushed to a remote repo.

I always merge with --no-ff so their is always a commit for my whole topic.

Now I'd like to only push this commit with a specified description what I did on the whole in this branch.

I would prefer this because you can look at the commit history on the server and see directly what happend and don't need to read every single commit.

And for my local work I would have the full history if I want to reset my branch or something similar.

I don't know if their is a way to do this in git but it would be very useful for me so I give it a try to ask you ;-)

Best regards, Sebastian

+1  A: 

From what you are describing, it looks like all you need to do is to push only your devel branch, and not push your topic branches.

  • your devel branch will contain that one commit (created on the merge with topic branch) which summarize what has been done.
    That commit will be pushed on the remote.
    The trick is, it should not be linked to your topic branch (or its history is also published).
    a git merge --squash would be useful to produced that single commit.
  • your topic branches remain unpublished (not pushed) and contain the all detailed history.
    You can enforce that, for instance, by a hook on the remote side, to refuse any branch you don't want being pushed on your (remote) repo.

As Daniel Yankowsky mentions in the comment, a git merge --squash works, but "lost the change lineage".
The is why you could setup 2 'devel' branches.

      t--t--t--t (topic)
     /
 x--x (devel)
 \
  p--p (devel_pub)
  • one for merging purposes (the classic 'devel' branch)
  • one for publishing purpose ('devel_pub'), where you perform a merge --squash)
                  (topic)
                    |
     x--x--t--t--t--t--d (devel)
     \
      p--p--T (devel_pub, with T being "git merge --squash topic")
VonC
Aren't all parent commits also pushed? Thus, pushing a merge commit will also push both sides of the merge?
Daniel Yankowsky
But when using:$ git checkout develop$ git merge --no-ff topicdevelop has the complete history I've got in topic.
Sebastian Bechtel
@Daniel: good point. I have amended my answer to avoid linking the history of devel with a topic branch being merged.
VonC
@Sebastien: true, that is why I suggest (in the new revision of my answer) a '`git merge --squashed`'.
VonC
It seems like that would handle his situation, though I would think that it would be difficult to continue working with a branch that has been --squashed into another branch. If I'm not mistaken, you've completely lost the change lineage, so a later merge would not realize that the commits have already been partially merged.
Daniel Yankowsky
@Daniel: true, the rebase --squashed is more appropriate for topic branches in end of life status. But a possible solution would be *two* '`devel`' branches: one where you merge (classic) but don't push (because it has the all history), and a '`devel_published`' branch where you do the "merge --squashed".
VonC
@VonC: The option is `--squash`, not `--squashed`.
Jefromi
@Jefromi: fixed.
VonC
+1  A: 

I don't know of any way to do what you are describing, and I suspect that it is working against git's design. It sounds like you want to summarize a whole set of commits. What if you merge with the --no-commit option, and edit the merge commit message to summarize your branch's changes?

Daniel Yankowsky
A: 

It sounds like you may want to use git rebase to rewrite your local history before pushing.

Why don't you want it on the remote side, anyway? It doesn't seem like it would matter very much. Just set the remote end to show only one branch that has your merge commits.

Daenyth