From: Richard Lee <richard@webdezign.co.uk>
To: git@vger.kernel.org
Subject: Preserving branches after merging on ancestor
Date: Thu, 5 Nov 2009 10:30:24 -0800 (PST) [thread overview]
Message-ID: <26217077.post@talk.nabble.com> (raw)
Hello gits,
I've been using various version control systems for several years now before
coming to git two months ago. So far I've been just doing linear commits
without any branches on my source code so that I end up with a linear
history. This makes it very hard to see where you started and stopped
working on something on the git graph.
So I tried using branches for features today. Most of the time I'm the only
person working on a project. So when I've finished working on a feature
branch and ready to merge it back into the master branch, the master head IS
the common ancestor of the two branches. As shown below
* b6d75f1 [feature] stuff on feature branch
* 43dba08 stuff on feature branch
* ab7efdd [master] init
When I merge the graph looks likes this:
* b6d75f1 [master] [feature] stuff on feature branch
* 43dba08 stuff on feature branch
* ab7efdd init
Now I lose the start point of where I satrted on the feature branch. And if
I decided to reuse the name of the branch 'feature' to work on it again by
resetting it to somewhere else, I loose to finish point. (Should I be using
git-reset like this?)
One way of getting round this problem is to use empty commits on the master
branch, as shown below.
* 6fc04b5 Merge branch 'feature2'
|\
| * 07a117b stuff on feature2
* | 52f5ba1 Empty commit
|/
* 5deaa93 Merge branch 'feature1'
|\
| * b163b17 stuff on feature1
| * 53bb820 stuff on feature1
| * c9ef14c stuff on feature1
* | 34227a3 Empty commit
|/
* e88d332 Init
But is this correct? It seems rather hackish to create empty commits on the
master branch just to historically preserve commits on a seperate branch.
Should I be using feature branches in git like this or another way? For
example more informative commit messages.
I cannot imagine using this empty commits fix in other VCS if they don't
allow empty commits like svn or hg.
Cheers,
Richard
--
View this message in context: http://old.nabble.com/Preserving-branches-after-merging-on-ancestor-tp26217077p26217077.html
Sent from the git mailing list archive at Nabble.com.
next reply other threads:[~2009-11-05 18:30 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-11-05 18:30 Richard Lee [this message]
2009-11-05 18:38 ` Preserving branches after merging on ancestor Eric Raible
2009-11-05 22:30 ` Jonathan Nieder
2009-11-05 23:28 ` Björn Steinbrink
2009-11-06 1:09 ` Jonathan Nieder
2009-11-06 2:10 ` Björn Steinbrink
2009-11-06 5:03 ` Jonathan Nieder
2009-11-06 15:21 ` rhlee
2009-11-06 22:52 ` Jonathan Nieder
2009-11-07 3:41 ` Dilip M
2009-11-07 13:31 ` Björn Steinbrink
2009-11-07 13:28 ` Björn Steinbrink
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=26217077.post@talk.nabble.com \
--to=richard@webdezign.co.uk \
--cc=git@vger.kernel.org \
/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