Re: Tags

Linus Torvalds [EMAIL PROTECTED] writes: (And you might also change tag contents occasionally. One reason might be a bug and you decide to re-tag something else. But a more common reason might be because you want to have tags like latest that don't actually update with development, but they

Re: Tags

Linus Torvalds [EMAIL PROTECTED] writes: On Tue, 5 Jul 2005, Eric W. Biederman wrote: True but if you can you will get multiple tags with the same suggested name. So you need so way to find the one you care about. I do agree that it would make sense to have a tagger field with the same

Re: [ANNOUNCE] Cogito-0.12

Linus Torvalds [EMAIL PROTECTED] writes: That said, I really think the dumb protocols are useless anyway. No other system supports pure static object pulling anyway, and as far as I'm concerned, I want rsync to kind of work (but it won't be optimal, since re-packing will delete all the old

Re: [ANNOUNCE] Cogito-0.12

Linus Torvalds [EMAIL PROTECTED] writes: On Thu, 7 Jul 2005, Eric W. Biederman wrote: For optimizing network bandwidth that sounds like the way to go. For adhoc development I don't know. For a central sever you still need an authenticated way to push content, which makes it another

Re: Trial git RPM's..

Linus Torvalds [EMAIL PROTECTED] writes: Ok, I tagged a v0.99 thing, and pushed it out. I've also made trial RPM's of it: src, ppc64 and x86. They're build on whatever random machines I had, and on the ppc64 I chose to do it on my FC4 machine that has newer libraries than my YDL one. The

Re: Trial git RPM's..

Linus Torvalds [EMAIL PROTECTED] writes: On Mon, 11 Jul 2005, Eric W. Biederman wrote: A couple of pieces. The dist target has assumes git-tar-tree is in the path. Making it so you have to have git installed to build the rpm. Yes. Maybe we could relax that requirement by using ./git-tar

Re: Trial git RPM's..

Linus Torvalds [EMAIL PROTECTED] writes: On Mon, 11 Jul 2005, Eric W. Biederman wrote: Are you still up for a patch that records who and when made a tag? I sent one but it seems to have been lost. I'd really actually prefer for the code to be shared with the commit code, so that the user

Re: Trial git RPM's..

Linus Torvalds [EMAIL PROTECTED] writes: On Mon, 11 Jul 2005, Eric W. Biederman wrote: Actually I was looking at doing a git-ident thing that will just compute who git thinks you are. And then git-commit-tree can just popen it to share code. That looks like how the logic has been

Re: [PATCH] rev-list: add --full-objects flag.

Linus Torvalds [EMAIL PROTECTED] writes: On Mon, 11 Jul 2005, Eric W. Biederman wrote: The question: Does git-upload-pack which gets it's list of objects with git-rev-list --objects needed1 needed2 needed3 ^has1 ^has2 ^has3 get any history beyond the top of tree of each branch. As I

[PATCH] tagger id

This patch adds a command git-id for use on the command line to see what git will set your id too, and for use in scripts (git-tag-script) so they can get your git id. The common code for computing the git-id is moved to ident.c Fix parse_date to not mind being passed a constant date to parse.

Re: [PATCH] tagger id

[EMAIL PROTECTED] (Eric W. Biederman) writes: This patch adds a command git-id for use on the command line to see what git will set your id too, and for use in scripts (git-tag-script) so they can get your git id. The common code for computing the git-id is moved to ident.c Fix parse_date

Re: [PATCH] tagger id

Junio C Hamano [EMAIL PROTECTED] writes: [EMAIL PROTECTED] (Eric W. Biederman) writes: Should this default to git_author_ident or git_committer_ident? I'm not really certain how we expect to use the different flavors. The only in-tree user after your patch is applied is the tagger stuff

Re: Trial git RPM's..

Chris Wright [EMAIL PROTECTED] writes: * Linus Torvalds ([EMAIL PROTECTED]) wrote: And it does not pass my torture test of building rpm's on debian, but that is not a huge problem. Ok, why is debian problematic? Is there some missing dependency or something? I really haven't ever done

Re: Trial git RPM's..

Linus Torvalds [EMAIL PROTECTED] writes: Ahh. Dang, I should have remembered this. We should call the rpm git-core-0.99, not just git-0.99. Chris, I assume this is just changing the name in the spec-file from git to git-core? The name of the tarball needs to be updated as well. Eric - To

Re: [PATCH] tagger id

Linus Torvalds [EMAIL PROTECTED] writes: Eric, I ended up coding the ident stuff a bit differently, and I didn't do done the tag/git-id part yet. Can you check out my latest commit (pushed out, but it will probably take a few minutes to mirror out), and do the final tag stuff based on

Re: [PATCH] tagger id

Junio C Hamano [EMAIL PROTECTED] writes: I am afraid I do not follow you. I was confused. My big problem was that we don't really have an in tree user, and there wasn't a good explanation anywhere. So it was hard to track this down. I'm going to lobby for a script to import patches from

Re: [PATCH] tagger id

Junio C Hamano [EMAIL PROTECTED] writes: Eric W. Biederman ebiederm at xmission.com writes: Part of the request was to put all of this information together in a common place. And note that it is actually: tagger=$GIT_COMMITTER_NAME $GIT_COMMITTER_EMAIL $GIT_COMMITTER_DATE Where the date

[PATCH 1/6] Move git_author_info and git_commiter_info to ident.c

Moving these functions allows all of the logic for figuring out what these values are to be shared between programs. --- cache.h |2 ++ commit-tree.c | 10 -- ident.c | 10 ++ 3 files changed, 12 insertions(+), 10 deletions(-)

[PATCH 2/6] ident.c: Disambiguate the error messages in setup_ident

If your user name is too long it is your sysadmin who hates you not your parents! Signed-off-by: Eric W. Biederman [EMAIL PROTECTED] --- ident.c |4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) 935f88376b79fc19df6dff85ba57ed94f06d79f0 diff --git a/ident.c b/ident.c --- a/ident.c

[PATCH 6/6] Update tags to record who made them

And finally what all of this has been leading up to. The 2 line code change to record who made a tag, and the 8 line code change to check that we recorded the tag. Gosh the error checking is always so much bigger than the code :) --- git-tag-script |3 ++- mktag.c| 10 --

[PATCH] Use gzip -f when building the git-core tarball

This allows rebuilding the tarball when it is already present without having to answer annoying questions from gzip Signed-off-by: Eric W. Biederman [EMAIL PROTECTED] --- Makefile |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) d7c4e5ae707a6ad3028c48d800d568c554cc10af diff --git

[PATCH] Initial support for building a debian package (.deb)

It's not any harder to include debian package support than to include a spec file so here is the setup to build the equivalent debian package. Signed-off-by: Eric W. Biederman [EMAIL PROTECTED] --- debian/changelog |5 +++ debian/control | 17 ++ debian

[PATCH] Cleanup: git-verify-tag-script

- Use git-verify-parse to allow sha1 tags references - When the tag does not verify set an appropriate exit status - Use git-sh-setup-script to verify the .git directory Signed-off-by: Eric W. Biederman [EMAIL PROTECTED] --- git-verify-tag-script |7 +++ 1 files changed, 3 insertions

[PATCH] Install git-verify-tag-script

Signed-off-by: Eric W. Biederman [EMAIL PROTECTED] --- Makefile |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) b4ef59fcedf0855519fc23b58f9ec0c80e78221c diff --git a/Makefile b/Makefile --- a/Makefile +++ b/Makefile @@ -36,7 +36,7 @@ SCRIPTS=git git-apply-patch-script git-m

[PATCH] git-revover-tags-script

. But since we aren't quite going at full speed on those yet we should be good. Signed-off-by: Eric W. Biederman [EMAIL PROTECTED] --- Makefile|3 ++- git-recover-tags-script | 27 +++ 2 files changed, 29 insertions(+), 1 deletions(-) create mode 100755

Re: [PATCH] git-revover-tags-script

Junio C Hamano [EMAIL PROTECTED] writes: [EMAIL PROTECTED] (Eric W. Biederman) writes: First pass at a script to dig through .git/objects and find dangling tags. It likely has a lot of weird limitations, I don't know if it will work with packs, and the policy it implments is pretty stupid

Re: [PATCH] git-revover-tags-script

Junio C Hamano [EMAIL PROTECTED] writes: [EMAIL PROTECTED] (Eric W. Biederman) writes: What we care about are the tag objects, those are the only kind that are verifiable and usable remotely. Now that I know we do not pull tags currently with any of the optimized transports, I would

Re: [PATCH] git-revover-tags-script

Junio C Hamano [EMAIL PROTECTED] writes: [EMAIL PROTECTED] (Eric W. Biederman) writes: What we care about are the tag objects, those are the only kind that are verifiable and usable remotely. Now that I know we do not pull tags currently with any of the optimized transports, I would

Re: [PATCH] git-revover-tags-script

Junio C Hamano [EMAIL PROTECTED] writes: [EMAIL PROTECTED] (Eric W. Biederman) writes: Actually looking a little deeper unless I have misread the code git-fetch-pack at least will only ask for commit objects so git fetch will never return a tag object. I thought so but then I tried

git-format-patch-script bug?

I haven't had a chance to investigate this much yet but I have ran into a peculiar problem. I was trying to help someone track down a bug that occurred between linux-2.6.12 and linux-2.6.13-rc1. Since it was very much an unknown where the problem was introduced I decided to run git format-patch

Re: git-format-patch-script bug?

Junio C Hamano [EMAIL PROTECTED] writes: [EMAIL PROTECTED] (Eric W. Biederman) writes: I was trying to help someone track down a bug that occurred between linux-2.6.12 and linux-2.6.13-rc1. Since it was very much an unknown where the problem was introduced I decided to run git format-patch

Re: Storing state in $GIT_DIR

Martin Langhoff [EMAIL PROTECTED] writes: On 8/26/05, Eric W. Biederman [EMAIL PROTECTED] wrote: Thinking about it going from arch to git should be just a matter of checking sha1 hashes, possibly back to the beginning of the arch tree. Yup, though actually replaying the tree to compute

Re: [ANNOUNCE] GIT 0.99.5

Junio C Hamano [EMAIL PROTECTED] writes: Documentation - A nit but possibly an important for 1.0 there are quite a few git commands that don't have man pages or whose man pages are currently very poor. Getting the code sane and stable of course comes first but if people can't

Re: Merges without bases

Junio C Hamano [EMAIL PROTECTED] writes: Daniel Barkalow [EMAIL PROTECTED] writes: I'd still like to revive my idea of having projects overlaid on each other, where the commits in the project that absorbed the other project say, essentially, also include this other commit, but any changes to

Re: [RFC/PATCH 1/1] format-patch: add an option to record base tree info

Fengguag Wu, Xiaolong Ye, have you attempted to use the truncated sha1 of the file the patch applies to? Git already places a file sha1 at the top of a patch. See the index line? > diff --git a/fs/namespace.c b/fs/namespace.c > index eccd925c6e82..3c3f8172c734 100644 > --- a/fs/namespace.c >

Re: [RFC/PATCH 1/1] format-patch: add an option to record base tree info

Junio C Hamano writes: > Fengguang Wu writes: > >>> >> I have a mixed feeling about this one, primarily because this was >>> >> already tried quite early in the life of "format-patch" command. >>> >> >>> >> >>> >>

Re: [RFC/PATCH 1/1] format-patch: add an option to record base tree info

"H. Peter Anvin" <h...@zytor.com> writes: > On February 23, 2016 12:35:12 PM PST, Junio C Hamano <gits...@pobox.com> > wrote: >>ebied...@xmission.com (Eric W. Biederman) writes: >> >>> Junio C Hamano <gits...@pobox.com> writes: >>>