[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [gits] best practice question



Yep, sounds like it to me. You could even keep your workshop branch after the merge so you still have a copy of the workshop paper, and then keep the main document in master.

Josh Kunz

On 11/14/14 12:13 AM, josh wrote:
Yep, sounds like it to me. You could even keep your workshop branch
after the merge so you still have a copy of the workshop paper, and then
keep the main document in master.

Josh Kunz

On 11/14/14 12:09 AM, Suresh Venkatasubramanian wrote:
ah thanks. of course it is entirely possible that we will merge much of
the workshop document (which won’t be published) into the main document
eventually. But then I guess that I don’t need to cherry pick, since
everything will eventually get merged back in ?

On Nov 14, 2014, at 12:06 AM, Josh Kunz <josh@flux.utah.edu
<mailto:josh@flux.utah.edu>> wrote:

In general, I find that having a branch that I don't intend to merge
back into master can be tedious. In most projects I've seen, there
will be one git repo for the project, a stable "master" branch, and
then one or more branches for unstable/experimental features. Some
especially large projects will even have entirely different repos for
components. Some examples: https://git.kernel.org/cgit/
http://git.musicpd.org/ https://github.com/git/git/branches/all

If I find myself wanting to have a separate branch that I don't intend
to merge back into master, I'll either split that piece off into a new
repository entirely, or I'll just add a new directory to the main
project repo. In your case, I'd do the latter because: A) You want to
share content between the documents, B) The documents are closely
related to each other, and C) The shared content will likely not be
useful in other projects.

Just to give an example of a time when I would split something into a
separate repo: If I had a small library (of code or data) that I was
using in a project that would be useful in other projects, I would put
that content into a separate repository and then use git's `submodule`
feature to include that repository's contents into the original
repository.

Hope that helps,
Josh Kunz

On 11/13/14 10:54 PM, Suresh Venkatasubramanian wrote:
so I’m using git for a paper I’m writing. I recently branched off a
version for a document we’re preparing for a workshop: the main
document
(in prep for a conference later on) is still in the master branch.

But I’m constantly encountering things that should be in both branches
(like relevant papers, bib entries, and common notes). so far I’ve been
cherry picking updates as necessary, but that’s a little painful.

Is there a ‘best practice’ for how to do this properly ? or should I
just not have created a branch

--
Suresh Venkatasubramanian Web: http://www.cs.utah.edu/~suresh/
Blog: http://geomblog.blogspot.com/
Associate Professor,
School of Computing, University of Utah

Why is it that buying a thought costs a penny, but freely given
thoughts
are two cents ? -- Heard on the internet.


--
Suresh Venkatasubramanian Web: http://www.cs.utah.edu/~suresh/
Blog: http://geomblog.blogspot.com/
Associate Professor,
School of Computing, University of Utah

Why is it that buying a thought costs a penny, but freely given thoughts
are two cents ? -- Heard on the internet.