branch versioning

branch versioning

[Nguyen Thai Ngoc Duy]

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

Re: branch versioning

[Matthieu Moy]

Nguyen Thai Ngoc Duy <pclouds@gmail.com> writes:

> 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/

Re: branch versioning

[Ævar Arnfjörð Bjarmason]

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.

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.

Re: branch versioning

[Nguyen Thai Ngoc Duy]

On 10/4/10, Ævar Arnfjörð Bjarmason <avarab@gmail.com> wrote:
> 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 :)

>  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

Re: branch versioning

[Ævar Arnfjörð Bjarmason]

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

Re: branch versioning

[Michael J Gruber]

Nguyen Thai Ngoc Duy venit, vidit, dixit 04.10.2010 15:18:
> 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

Re: branch versioning

[Nguyen Thai Ngoc Duy]

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

Re: branch versioning

[Tomas Carnecky]

On 10/4/10 3:18 PM, Nguyen Thai Ngoc Duy wrote:
> 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