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. >>> >> >>> >> >>> >> http://thread.gmane.org/gmane.comp.version-control.git/9694/focus=9757 >>> >

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

"H. Peter Anvin" writes: > On February 23, 2016 12:35:12 PM PST, Junio C Hamano > wrote: >>ebied...@xmission.com (Eric W. Biederman) writes: >> >>> Junio C Hamano writes: >>> >>>> It is valuable for a testing organization to say &q

[PATCH] send-email: Add an option to suppress adding a specific email address

email address from being automatically added to a destination the email will be sent to. Signed-off-by: "Eric W. Biederman" --- Documentation/git-send-email.txt | 5 + git-send-email.perl | 20 +++- 2 files changed, 24 insertions(+), 1 deletion(-) diff --git a

[PATCH] send-email: Add an option to suppress adding a specific email address

email address from being automatically added to a destination the email will be sent to. Signed-off-by: "Eric W. Biederman" --- Documentation/git-send-email.txt | 5 + git-send-email.perl | 20 +++- 2 files changed, 24 insertions(+), 1 deletion(-) diff --git a

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

Linus Torvalds <[EMAIL PROTECTED]> writes: > On Thu, 7 Jul 2005, Junio C Hamano wrote: >> >> However it does not automatically mean that the avenue I have >> been pursuing would not work; the server side preparation needs >> to be a bit more careful than what I sent, which unconditionally >> runs

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

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

Linus Torvalds <[EMAIL PROTECTED]> writes: > On Sat, 9 Jul 2005, Eric W. Biederman wrote: >> >> The current intelligent fetch currently has a problem that it cannot >> be used to bootstrap a repository. If you don't have an ancestor >> of what you are fet

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

Linus Torvalds <[EMAIL PROTECTED]> writes: > On Mon, 11 Jul 2005, Eric W. Biederman wrote: >> >> I guess I was expecting to pull from one tree into another unrelated >> tree. Getting a tree with two heads and then be able to merge them >> together. > >

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 coul

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

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

Linus Torvalds <[EMAIL PROTECTED]> writes: > On Mon, 11 Jul 2005, Eric W. Biederman wrote: >> > So if you only get one branch, it will leave the objects that are specific >> > to other branches alone. >> >> Hmm. As I recall reading the code it g

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.

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" &

[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

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

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

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 we

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

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

[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(-) c6f1b65729df142a8968441ca441f6b6

[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

[PATCH 3/6] Add git-var a tool for reading interesting git variables.

+ +git-var - Print the git users identity + + +SYNOPSIS + +git-var [ -l | ] + +DESCRIPTION +--- +Prints a git logical variable. + +-l causes the logical variables to be listed. + +EXAMPLE + +$git-var GIT_AUTHOR_IDENT + +Eric W. Biederman <[EMAIL PROTECTED]> 1121223278

[PATCH 4/6] Update the list of diagnostics for git-commit-tree

With the recent work on setup_ident() there are a few more possible diagnostic messages form git-commit-tree Signed-off-by: Eric W. Biederman <[EMAIL PROTECTED]> --- Documentation/git-commit-tree.txt |4 1 files changed, 4 insertions(+), 0 del

[PATCH 5/6] Update git-tag-script to create the .git/refs/tags if it does not already exist

When testing tags I ran into an interesting problem. git-tag-script dies if .git/refs/tags/ does not exist. And that directory didn't get created when I build my repository, so we need to create it if it doesn't exist. Signed-of-by: Eric W. Biederman <[EMAIL PROTECTED]> ---

[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] Add a RPMBUILD make variable

This allows RPMBUILD to be overridden for people with old versions of rpm or people who want to pass rpmbuild extra options. Signed-off-by: Eric W. Biederman <[EMAIL PROTECTED]> --- Makefile |3 ++- 1 files changed, 2 insertions(+), 1 deletions(-) 50c6a0b3b5d461b81bd5ceb0808206bfa2

[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

[PATCH] Add doc and install-doc targets to the Makefile

This makes it straight forward for people wanting to build and install the git man pages and the rest of the documentation to do so. Signed-off-by: Eric W. Biederman <[EMAIL PROTECTED]> --- Documentation/Makefile | 13 + Makefile |6 ++ 2 files chang

[PATCH] Update the spec file so it can build and install the documentation

If you don't want the documentation simply build with make RPMBUILD="rpmbuild --without docs" Signed-off-by: Eric W. Biederman <[EMAIL PROTECTED]> --- git-core.spec.in | 14 ++ 1 files changed, 10 insertions(+), 4 deletions(-) 18d85dbab2fca214bfb625e65733d5

[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 +++

[PATCH] Complain about sysadmins in the present tense.

Junio C Hamano <[EMAIL PROTECTED]> writes: > [EMAIL PROTECTED] (Eric W. Biederman) writes: > >> Actually I could not see something the system administrator >> had bone being anything but present tense. If you have to type >> 500+ characters just to login, I think

Re: Last mile to 1.0?

Junio C Hamano <[EMAIL PROTECTED]> writes: > I do not know what release plan Linus has in mind, and also > expect things to be quieter next week during OLS and kernel > summit, but I think we are getting really really close. > > Here are the things I think we would want to see before we hit > 1.0:

[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 inse

[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

[PATCH] git-revover-tags-script

k methods. 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 deleti

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 pa

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 wit

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 wit

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 objec

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 s

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

Re: Storing state in $GIT_DIR

Martin Langhoff <[EMAIL PROTECTED]> writes: > Hmmm. That repo is in sync, but there are no guarantees that they will > travel together to a different repo. In fact, the push/pull > infrastructure wants to push/pull one head at a time. > > And if they are not in sync, I have no way of knowing. Hmpf

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

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 an

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

Re: Tags

Daniel Barkalow <[EMAIL PROTECTED]> writes: > On Tue, 5 Jul 2005, Eric W. Biederman wrote: > >> Could you include the person who generated the tag and the time the >> tag was generated in the tag object? >> >> For a tag like "latest" it would help

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 wo

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

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 authenticat