threads / discuss / 25336

branch versioning

Subject: branch versioning

## tl;dr

8 messages between Oct 4, 2010 and Oct 4, 2010.

replies: 7people: 5as markdown or json

Nguyen Thai Ngoc Duy· Oct 4, 2010, 13:18 UTC · lore
Hi,

How do you guys manage versions of a topic branch? I usually end up saving format-patch series somewhere or forget all old versions. Although I really want to keep old versions around. reflog to me is polluted with every kind of branch updates. And it's local information. It can't be transferred to another repo (or can it?)

On the same subject, I have quite a few old topic branches that I rarely touch. I don't want to remove them. I just want to hide them away from "git branch". I've been thinking of "attic/" namespace that "git branch" by default will not show. Just wondering if other people face the same problem..

-- 
Duy
Matthieu Moy· Oct 4, 2010, 13:25 UTC · re: Nguyen Thai Ngoc Duy · lore

Re: branch versioning

Nguyen Thai Ngoc Duy <pclouds@gmail.com> writes:
Show 7 quoted lines
> Hi,
>
> How do you guys manage versions of a topic branch? I usually end up
> saving format-patch series somewhere or forget all old versions.
> Although I really want to keep old versions around. reflog to me   is
> polluted with every kind of branch updates. And it's local
> information. It can't be transferred to another repo (or can it?)

I don't have strong needs in branch-versionning, so usually, the reflog is OK for me. When I need to save something, I set a tag on the current version of the branch before continuing (that's somehow manual versionning: the tag isn't versionned, so if I actually need history, I'll set several tags like refs/tags/sent-to-list-as-v1 refs/tags/before-starting-rebase, ...).

But other tools like stgit, topgit & friends may help to manage that in a cleaner way.

-- 
Matthieu Moy
http://www-verimag.imag.fr/~moy/
Ævar Arnfjörð Bjarmason· Oct 4, 2010, 13:29 UTC · re: Nguyen Thai Ngoc Duy · lore

Re: branch versioning

On Mon, Oct 4, 2010 at 13:18, Nguyen Thai Ngoc Duy <pclouds@gmail.com> wrote:
Show 5 quoted lines
> How do you guys manage versions of a topic branch? I usually end up
> saving format-patch series somewhere or forget all old versions.
> Although I really want to keep old versions around. reflog to me   is
> polluted with every kind of branch updates. And it's local
> information. It can't be transferred to another repo (or can it?)

I usually have foo, foo-v2, foo-v3 which eventually gets reset back to foo once I'm sure nobody cares about the initial one or foo-v2. It's very chaotic.

So my git.git on GitHub is up to 123 branches, and I don't even want to know what my personal git.git is at. I also save my outgoing format-patch E-Mails, but would probably do less of that if there was support for attaching the comments after the diffstat in a git-note or something.

Nguyen Thai Ngoc Duy· Oct 4, 2010, 13:50 UTC · re: Ævar Arnfjörð Bjarmason · lore

Re: branch versioning

On 10/4/10, Ævar Arnfjörð Bjarmason <avarab@gmail.com> wrote:
Show 11 quoted lines
> On Mon, Oct 4, 2010 at 13:18, Nguyen Thai Ngoc Duy <pclouds@gmail.com> wrote:
>  > How do you guys manage versions of a topic branch? I usually end up
>  > saving format-patch series somewhere or forget all old versions.
>  > Although I really want to keep old versions around. reflog to me   is
>  > polluted with every kind of branch updates. And it's local
>  > information. It can't be transferred to another repo (or can it?)
>
>
> I usually have foo, foo-v2, foo-v3 which eventually gets reset back to
>  foo once I'm sure nobody cares about the initial one or foo-v2. It's
>  very chaotic.

You remind me of my ~100 patch rebase/refactor on busybox-w32. I had up to master.7 :)

Show 5 quoted lines
>  So my git.git on GitHub is up to 123 branches, and I don't even want
>  to know what my personal git.git is at. I also save my outgoing
>  format-patch E-Mails, but would probably do less of that if there was
>  support for attaching the comments after the diffstat in a git-note or
>  something.

OK. Thanks for the information. I'll try my best to stay away from your repo :-D. Seriously, how can you select a branch out of those 123 branches? Does git-branch support regex matching or.. (looked up git-branch.txt, no it does not)

-- 
Duy
Ævar Arnfjörð Bjarmason· Oct 4, 2010, 14:16 UTC · re: Nguyen Thai Ngoc Duy · lore

Re: branch versioning

On Mon, Oct 4, 2010 at 13:50, Nguyen Thai Ngoc Duy <pclouds@gmail.com> wrote:
> OK. Thanks for the information. I'll try my best to stay away from
> your repo :-D. Seriously, how can you select a branch out of those 123
> branches? Does git-branch support regex matching or.. (looked up
> git-branch.txt, no it does not)

I usually only have 1-4 branches active at any one point, so it doesn't get too bad.

I also have a special tag in my E-Mail folder for patches that Junio hasn't picked up yet or those that I need to work on. It's currently at around 200 patches :)

I mostly select branches with Emacs's magit which has a fuzzy regex based selector. "git branch -a | grep ..." also works.

It also helps to use long descriptive branch names, e.g.:
  run-partial-expensive-git-notes-test-everywhere
  run-partial-expensive-git-notes-test-everywhere-v2
Michael J Gruber· Oct 4, 2010, 13:44 UTC · re: Nguyen Thai Ngoc Duy · lore

Re: branch versioning

Nguyen Thai Ngoc Duy venit, vidit, dixit 04.10.2010 15:18:
Show 13 quoted lines
> Hi,
> 
> How do you guys manage versions of a topic branch? I usually end up
> saving format-patch series somewhere or forget all old versions.
> Although I really want to keep old versions around. reflog to me   is
> polluted with every kind of branch updates. And it's local
> information. It can't be transferred to another repo (or can it?)
> 
> On the same subject, I have quite a few old topic branches that I
> rarely touch. I don't want to remove them. I just want to hide them
> away from "git branch". I've been thinking of "attic/" namespace that
> "git branch" by default will not show. Just wondering if other people
> face the same problem..

Same problem, without a perfect solution. I have a branch mjg/foo for a topic in flight. If I need to submit v2, I tag the old tip mjg/foo-v1 and rebase -i, etc. Once a patch gets accepted, I do:

- Merge the git.git commit with the applied patch to mjg/foo (with a
message like "Applied as commit deadbeef on next). The merge diff shows
the differences between my patch and the actual commit on git.git.
- Tag the tip as mjg/applied/foo.
- Delete the branch.
- Delete the branch on my repos if it has been pushed out already (this
point sucks).

That way my branch namespace is reasonably clean, and the graph view on github, e.g., is somewhat meaningful. My tag name space is a bit crowded...

I also keep the commit notes (post ---) in a note ;)
Michael
Nguyen Thai Ngoc Duy· Oct 4, 2010, 14:10 UTC · re: Michael J Gruber · lore

Re: branch versioning

On Mon, Oct 04, 2010 at 03:44:24PM +0200, Michael J Gruber wrote:
> That way my branch namespace is reasonably clean, and the graph view on
> github, e.g., is somewhat meaningful. My tag name space is a bit crowded...

This might help you. I don't know. I think the idea is good, but you may need a negative pattern, or multiple patterns... Just a starting point.

If I git-branch supported pattern matching and negative pattern, then my "attic/" hidden namespace would be solved. Hmm..

>From 461bd140c71fc242470c08523bc7becefb9aa2cf Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Nguy=E1=BB=85n=20Th=C3=A1i=20Ng=E1=BB=8Dc=20Duy?= <pclouds@gmail.com>
Date: Mon, 4 Oct 2010 21:05:54 +0700
Subject: [PATCH] tag: add core.taglist to let user customize "git tag -l"
Be default "git tag" alone (or "git tag -l") will list all tags.
Let user specify how they want to list in this case via core.taglist
---
 Documentation/git-tag.txt |    3 ++-
 builtin/tag.c             |    7 ++++++-
 2 files changed, 8 insertions(+), 2 deletions(-)
diff --git a/Documentation/git-tag.txt b/Documentation/git-tag.txt
index 31c78a8..770d1d8 100644
--- a/Documentation/git-tag.txt
+++ b/Documentation/git-tag.txt
@@ -69,7 +69,8 @@ OPTIONS
 
 -l <pattern>::
 	List tags with names that match the given pattern (or all if no pattern is given).
-	Typing "git tag" without arguments, also lists all tags.
+	Typing "git tag" without arguments, also lists all tags matched
+	by core.taglist ('*' if undefined)
 
 --contains <commit>::
 	Only list tags which contain the specified commit.
diff --git a/builtin/tag.c b/builtin/tag.c
index d311491..33620f6 100644
--- a/builtin/tag.c
+++ b/builtin/tag.c
@@ -22,6 +22,7 @@ static const char * const git_tag_usage[] = {
 };
 
 static char signingkey[1000];
+static const char *default_pattern = "*";
 
 struct tag_filter {
 	const char *pattern;
@@ -96,7 +97,7 @@ static int list_tags(const char *pattern, int lines,
 	struct tag_filter filter;
 
 	if (pattern == NULL)
-		pattern = "*";
+		pattern = default_pattern;
 
 	filter.pattern = pattern;
 	filter.lines = lines;
@@ -234,6 +235,10 @@ static int git_tag_config(const char *var, const char *value, void *cb)
 		set_signingkey(value);
 		return 0;
 	}
+	if (!strcmp(var, "core.taglist")) {
+		git_config_string(&default_pattern, var, value);
+		return 0;
+	}
 
 	return git_default_config(var, value, cb);
 }
-- 
1.7.0.2.445.gcbdb3
-- 
Duy
Tomas Carnecky· Oct 4, 2010, 14:33 UTC · re: Nguyen Thai Ngoc Duy · lore

Re: branch versioning

On 10/4/10 3:18 PM, Nguyen Thai Ngoc Duy wrote:
Show 13 quoted lines
> Hi,
> 
> How do you guys manage versions of a topic branch? I usually end up
> saving format-patch series somewhere or forget all old versions.
> Although I really want to keep old versions around. reflog to me   is
> polluted with every kind of branch updates. And it's local
> information. It can't be transferred to another repo (or can it?)
> 
> On the same subject, I have quite a few old topic branches that I
> rarely touch. I don't want to remove them. I just want to hide them
> away from "git branch". I've been thinking of "attic/" namespace that
> "git branch" by default will not show. Just wondering if other people
> face the same problem..

There was a blog post from someone suggesting how to extend rebase to track the old and new commits so the old ones don't get lost (sadly I can't find the blog post anymore). The idea was to add the old commit as the second parent to the newly rebased commits. This way you can track the evolution of commits across multiple iterations. You could do the same with topic branches: after you create the new version of the topic branch, add the old topic branch as the second parent of the new branch head (use merge -s ours to discard changes made by the old topic branch). And to submit the commits in a topic branch for review you'd use --first-parent.

tom

← back to recent threads