threads / discuss / 2150

Re: Pushing a single tag (ref + object)?

Subject: Re: Pushing a single tag (ref + object)?

## tl;dr

4 messages between Oct 19, 2005 and Nov 2, 2005.

replies: 3people: 3as markdown or json

Horst von Brand· Oct 19, 2005, 12:39 UTC · lore

Martin Langhoff <martin.langhoff@gmail.com> wrote:

Show 15 quoted lines

> While we are using a repo which holds all our branches
> (dev/test/prod), locally we have a group of developers that checkout
> one repo-per-branch, working on it with a
> cg-clone/cg-update/cg-commit/cg-push workcycle. So far it's working
> great.
> 
> Now, I am at a loss on how to push a _tag_ object+ref to the repo,
> without doing a git-push --all, which I naturally don't want to do. I
> managed to push the object itself, doing
> 
>     git-push repository tagrefname
> 
> But that ddn't create the ref on the repo. So I had to do
> 
>     scp .git/refs/tags/refname repostory/refs/tags/

I've done:

     git push repository refs/tags/refname

-- 
Dr. Horst H. von Brand                   User #22616 counter.li.org
Departamento de Informatica                     Fono: +56 32 654431
Universidad Tecnica Federico Santa Maria              +56 32 654239
Casilla 110-V, Valparaiso, Chile                Fax:  +56 32 797513

Horst von Brand· Nov 1, 2005, 23:56 UTC · lore

Re: git versus CVS (versus bk)

Martin Langhoff <martin.langhoff@gmail.com> wrote:

[...]

Show 6 quoted lines

> In practice, a new developer will often roll up commits to avoid
> sending a string of shameful patches and corrections on top -- I often
> do that ;-) . Developers with more "mana" will have published repos
> where Junio pulls directly from -- and they get merged with full
> history. Of course -- they don't have brown-paper-bag commits like I
> do...

I bet they have a scratchpad on their laptop (full of brown-paper-bag commits and backtracking) from which they push into a cleaned up repository for public consumption.

-- 
Dr. Horst H. von Brand                   User #22616 counter.li.org
Departamento de Informatica                     Fono: +56 32 654431
Universidad Tecnica Federico Santa Maria              +56 32 654239
Casilla 110-V, Valparaiso, Chile                Fax:  +56 32 797513

Andreas Ericsson· Nov 2, 2005, 08:54 UTC · re: Horst von Brand · lore

Re: git versus CVS (versus bk)

Horst von Brand wrote:

Show 16 quoted lines

> Martin Langhoff <martin.langhoff@gmail.com> wrote:
> 
> [...]
> 
> 
>>In practice, a new developer will often roll up commits to avoid
>>sending a string of shameful patches and corrections on top -- I often
>>do that ;-) . Developers with more "mana" will have published repos
>>where Junio pulls directly from -- and they get merged with full
>>history. Of course -- they don't have brown-paper-bag commits like I
>>do...
> 
> 
> I bet they have a scratchpad on their laptop (full of brown-paper-bag
> commits and backtracking) from which they push into a cleaned up repository
> for public consumption.

I just do a lot of branches.

Incidentally though, is there any way to make a commit completely go away without resetting the files?

It'd be a nice feature even if it can only do it from the top down, unlike git-revert which can do it anywhere in the middle as well.

-- 
Andreas Ericsson                   andreas.ericsson@op5.se
OP5 AB                             www.op5.se
Tel: +46 8-230225                  Fax: +46 8-230231

Junio C Hamano· Nov 2, 2005, 09:26 UTC · re: Andreas Ericsson · lore

Re: git versus CVS (versus bk)

Andreas Ericsson <ae@op5.se> writes:

> Incidentally though, is there any way to make a commit completely go 
> away without resetting the files?

I am not sure if this is what you are looking for, but after I make a commit and find a mistake (either in the checked-in files or commit log message), I do this:

	$ git reset --soft HEAD^
        ... fix the checked-in files, maybe do git-add files that
        ... I forgot to add when I made the last commit.
        $ git commit -a -c ORIG_HEAD ;# edit commit log, too.

Soft reset leaves the working tree files intact and just rewinds the .git/HEAD to whatever commit you specify, and as a side effect stores the original .git/HEAD in .git/ORIG_HEAD. The lowercase -c flag to git-commit is "bring the commit log editor, initialized with the commit log message from that commit".