* Recommended steps for a "subsystem maintainer" ?
From: Gary Yang @ 2008-11-19 20:47 UTC (permalink / raw)
To: git
Hi,
The doc,http://www.kernel.org/pub/software/scm/git/docs/gitcore-tutorial.html at "Working with Others" recommended steps for a "subsystem maintainer".
See below. But, I do not understand the step 3. Copy over the packed files from "project lead" public repository to your public repository.
The step 1 used git-clone. That means, I got the code including histories as well. Why do I need step 3 to get the packed files?
If I really need the packed files, how do I get it? As an example, I need to get the packed files for http://git.denx.de/?p=u-boot.git;a=summary .
How can I get the files something like, pack-d5ef1966072c86ef5108ac57525b802581de5d21.idx and pack-d5ef1966072c86ef5108ac57525b802581de5d21.pack ?
The snapshot dose not have the packed files. They are all text files.
A recommended work cycle for a "subsystem maintainer" who works on that project and has an own "public repository" goes like this:
1. Prepare your work repository, by git-clone the public repository of the "project lead". The URL used for the initial cloning
is stored in the remote.origin.url configuration variable.
2. Prepare a public repository accessible to others, just like the "project lead" person does.
3. Copy over the packed files from "project lead" public repository to your public repository, unless the "project lead" repository lives on the same machine as yours. In the latter case, you can use objects/info/alternates file to point at the repository you are borrowing from.
4. Push into the public repository from your primary repository. Run git-repack, and possibly git-prune if the transport used for pulling from your repository supports packed repositories.
5. Keep working in your primary repository. Your changes include modifications of your own, patches you receive via e-mails, and merges resulting from pulling the "public" repositories of your "project lead" and possibly your "sub-subsystem maintainers".
You can repack this private repository whenever you feel like.
6. Push your changes to your public repository, and ask your "project lead" and possibly your "sub-subsystem maintainers" to pull from it.
7. Every once in a while, git-repack the public repository. Go back to step 5. and continue working.
Thank you,
Gary
^ permalink raw reply
* Re: New converstion tool: svn2git.py
From: Neil Schemenauer @ 2008-11-19 20:40 UTC (permalink / raw)
To: Kevin Menard; +Cc: git
In-Reply-To: <7e3605160811191139t34c5de7q1912475f778386e8@mail.gmail.com>
On Wed, Nov 19, 2008 at 02:39:26PM -0500, Kevin Menard wrote:
> You may want to look at this Ruby implementation for more ideas:
>
> http://github.com/nirvdrum/svn2git/
>
Hi Kevin,
Thanks for the link. I see that git-svn does most of the heavy
lifting and now I see that it does try to intelligently handle
branches and tags by looking for a suitable parent commit. I will
have to look closer at what it's doing. Maybe it is sufficient for
my task.
Regards,
Neil
^ permalink raw reply
* Re: git workshop in Sweden/Denmark
From: Christian Couder @ 2008-11-19 20:35 UTC (permalink / raw)
To: nadim khemir; +Cc: git
In-Reply-To: <200811191858.21990.nadim@khemir.net>
Le mercredi 19 novembre 2008, nadim khemir a écrit :
> Hi,
>
> Lund.pm and Data-foreningen are trying to organize a 'git' workshop.
Nice!
> The workshop will consist of a presentation in the morning followed by a
> lunch in a local restaurant and a workshop after lunch.
>
> We already have a location where the workshop will take place. Most
> probably a Saturday to allow as many people as possible to join us. The
> location is in Malmö the biggest town in the south of Sweden and only
> 30mn by train from Copenhagen capital of Danmark. We, of course, welcome
> people from other places too.
Great, but some people may have exhausted their git available time with
GitTogether'08 (see below).
> We are already working on securing one or two speakers that will
> enlighten us.
>
> I would like the git community to help us with:
>
> - has a git workshop already been organized?
> is there material that we could get?
> any conference organization existing (something like YAPC)?
There was GitTogether'08 one month ago, see:
http://git.or.cz/gitwiki/GitTogether
Some material is available from the "Speakers" section of the page.
Other material may be available from the wiki (perhaps
http://git.or.cz/gitwiki/GitLinks).
But there is no conference organization.
Regards,
Christian.
^ permalink raw reply
* Re: [PATCH 3/3] builtin-branch: use strbuf in rename_branch()
From: Lars Hjemli @ 2008-11-19 19:48 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Junio C Hamano, Miklos Vajna, git
In-Reply-To: <alpine.DEB.1.00.0811190209470.30769@pacific.mpi-cbg.de>
On Wed, Nov 19, 2008 at 02:11, Johannes Schindelin
<Johannes.Schindelin@gmx.de> wrote:
> Hi,
>
> On Tue, 18 Nov 2008, Junio C Hamano wrote:
>
>> Miklos Vajna <vmiklos@frugalware.org> writes:
>>
>> > - snprintf(logmsg, sizeof(logmsg), "Branch: renamed %s to %s",
>> > - oldref, newref);
>> > + strbuf_addf(&logmsg, "Branch: renamed %s to %s",
>> > + oldref.buf, newref.buf);
>>
>> I am wondering why nobody has complained until now, but shouldn't this
>> be oldname and newname?
>
> I think that was the intention. Lars?
Some background: the message was first generated internally (in
c976d415) by refs.c:rename_ref() and thus it made sense to use the
full refname. Sometime later (in 678d0f4c), rename_ref() was modified
to get the message as an argument from
builtin_branch.c:rename_branch() but the format of the message was
kept (almost) identical.
Personally, I think it's nice if the reflog contains the full refname.
--
larsh
^ permalink raw reply
* Re: New converstion tool: svn2git.py
From: Kevin Menard @ 2008-11-19 19:39 UTC (permalink / raw)
To: Neil Schemenauer; +Cc: git
In-Reply-To: <20081119191320.GA20870@arctrix.com>
Hi Neil,
You may want to look at this Ruby implementation for more ideas:
http://github.com/nirvdrum/svn2git/
I forked it from a project originally by James Coglan, but should be
able to answer most questions about it.
--
Kevin
On Wed, Nov 19, 2008 at 2:13 PM, Neil Schemenauer <nas@arctrix.com> wrote:
> Hi,
>
> I'm working on a tool to do conversions from SVN to git using a SVN
> dump. It's in early development but perhaps some people would be
> interested in it:
>
> http://python.ca/nas/python/svn2git.py
>
> I would like to improve it so that it intelligently converts SVN
> branches and tags into git branches (when possible). The basic idea
> is to map SVN paths into git branches, e.g. trunk -> master,
> branches/foo -> branch-foo, tags/bar -> tags-bar. Next, specific
> SVN dump actions like:
>
> Node-path: branches/foo
> Node-kind: dir
> Node-action: add
> Node-copyfrom-rev: 3
> Node-copyfrom-path: trunk
>
> need to be detected and the commit needs to performed with the
> correct parent. One complication is that SVN can create a branch or
> tag from anywhere, for example, the action
>
> Node-path: tags/bar
> Node-kind: dir
> Node-action: add
> Node-copyfrom-rev: 3
> Node-copyfrom-path: trunk/subdir
>
> would create tags/bar based on revision 3 of trunk/subdir. There
> doesn't seem to be a good way to convert that into git. I was
> thinking that the tags-bar branch in that case would have no parent.
> Would git still efficently pack that or would you end up with extra
> blobs?
>
> Neil
> --
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply
* New converstion tool: svn2git.py
From: Neil Schemenauer @ 2008-11-19 19:13 UTC (permalink / raw)
To: git
Hi,
I'm working on a tool to do conversions from SVN to git using a SVN
dump. It's in early development but perhaps some people would be
interested in it:
http://python.ca/nas/python/svn2git.py
I would like to improve it so that it intelligently converts SVN
branches and tags into git branches (when possible). The basic idea
is to map SVN paths into git branches, e.g. trunk -> master,
branches/foo -> branch-foo, tags/bar -> tags-bar. Next, specific
SVN dump actions like:
Node-path: branches/foo
Node-kind: dir
Node-action: add
Node-copyfrom-rev: 3
Node-copyfrom-path: trunk
need to be detected and the commit needs to performed with the
correct parent. One complication is that SVN can create a branch or
tag from anywhere, for example, the action
Node-path: tags/bar
Node-kind: dir
Node-action: add
Node-copyfrom-rev: 3
Node-copyfrom-path: trunk/subdir
would create tags/bar based on revision 3 of trunk/subdir. There
doesn't seem to be a good way to convert that into git. I was
thinking that the tags-bar branch in that case would have no parent.
Would git still efficently pack that or would you end up with extra
blobs?
Neil
^ permalink raw reply
* fatal: did you run git update-server-info on the server? mv post-update.sample post-update
From: Gary Yang @ 2008-11-19 18:59 UTC (permalink / raw)
To: git
The doc, http://www.kernel.org/pub/software/scm/git/docs/gitcore-tutorial.html, at the the section, "Working with Others" says that
mv post-update.sample post-update under the $GIT_DIR/hooks directory for the public repository. I did that. The file permission is executable.
ls -alF /pub/git/u-boot.git/hooks/post-update
-rwxr-xr-x 1 garyyang6 engr 189 Nov 18 15:54 /pub/git/u-boot.git/hooks/post-update*
But, I got error, "did you run git update-server-info on the server" when I tried to "git pull". Any idea why I got this error?
I did not run post-update at public repository manually. Do I need to run it for the very first time?
At my private repository, I did:
git pull http://git01.my.com /pub/git/u-boot.git HEAD
fatal: http://git01.my.com/info/refs not found: did you run git update-server-info on the server?
Thank you,
Gary
^ permalink raw reply
* Re: [TopGit PATCH] Check for help invocation before setup
From: Petr Baudis @ 2008-11-19 18:39 UTC (permalink / raw)
To: martin f krafft; +Cc: git
In-Reply-To: <20081119183234.GA19781@piper.oerlikon.madduck.net>
On Wed, Nov 19, 2008 at 07:32:34PM +0100, martin f krafft wrote:
> also sprach Petr Baudis <pasky@suse.cz> [2008.11.19.1924 +0100]:
> > > +args_saved="$@"
> > > +while [ -n "$1" ]; do
> > > + case "$1" in
> > > + help|--help|-h)
> > > + shift
> > > + do_help "$1"
> > > + exit 1;;
> > > + esac
> > > + shift
> > > +done
> > > +set -- $args_saved
> > > +unset args_saved
> > >
> > > ## Initial setup
> >
> > Huh, why do you actually need $args_saved at all? :-) This is bound to
> > do horrible things with space-containing arguments etc., I think. You
> > don't need to do the outer shift and then drop $args_saved altogether,
> > no?
>
> I figured I need to restore $@ for others to consume, e.g. when you
> check for -r later.
>
> The challenge is to identify help|--help|-h anywhere on the command
> line. Thus, you need to iterate, or do some weird matching against
> $*.
>
> When you iterate in a for loop, it's not easy to get at the next
> argument, except if you use a state machine. I wanted to avoid that.
Oh, oops - I missed the loop, I should get some lunch. ;-)
Thus, something like this?
check_help() { while [ -n "$1" ]; do ...; shift; done }
check_help "$@"
--
Petr "Pasky" Baudis
People who take cold baths never have rheumatism, but they have
cold baths.
^ permalink raw reply
* Re: [TopGit PATCH] Check for help invocation before setup
From: martin f krafft @ 2008-11-19 18:32 UTC (permalink / raw)
To: Petr Baudis; +Cc: git
In-Reply-To: <20081119182436.GB10544@machine.or.cz>
[-- Attachment #1: Type: text/plain, Size: 1606 bytes --]
also sprach Petr Baudis <pasky@suse.cz> [2008.11.19.1924 +0100]:
> > +args_saved="$@"
> > +while [ -n "$1" ]; do
> > + case "$1" in
> > + help|--help|-h)
> > + shift
> > + do_help "$1"
> > + exit 1;;
> > + esac
> > + shift
> > +done
> > +set -- $args_saved
> > +unset args_saved
> >
> > ## Initial setup
>
> Huh, why do you actually need $args_saved at all? :-) This is bound to
> do horrible things with space-containing arguments etc., I think. You
> don't need to do the outer shift and then drop $args_saved altogether,
> no?
I figured I need to restore $@ for others to consume, e.g. when you
check for -r later.
The challenge is to identify help|--help|-h anywhere on the command
line. Thus, you need to iterate, or do some weird matching against
$*.
When you iterate in a for loop, it's not easy to get at the next
argument, except if you use a state machine. I wanted to avoid that.
But you are right, I am wreaking havoc with space-containing
arguments. I will have to go back and rework this.
I take it you agree with the general principle though?
--
.''`. martin f. krafft <madduck@debian.org>
: :' : proud Debian developer, author, administrator, and user
`. `'` http://people.debian.org/~madduck - http://debiansystem.info
`- Debian - when you have better things to do than fixing systems
"it is easier to be a lover than a husband for the simple reason
that it is more difficult to be witty every day
than to say pretty things from time to time."
-- honoré de balzac
[-- Attachment #2: Digital signature (see http://martin-krafft.net/gpg/) --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: [TopGit PATCH] Check for help invocation before setup
From: Petr Baudis @ 2008-11-19 18:24 UTC (permalink / raw)
To: martin f. krafft; +Cc: git
In-Reply-To: <1227110623-4474-2-git-send-email-madduck@debian.org>
On Wed, Nov 19, 2008 at 05:03:40PM +0100, martin f. krafft wrote:
> diff --git a/tg.sh b/tg.sh
> index 2961106..40c4ab7 100644
> --- a/tg.sh
> +++ b/tg.sh
> @@ -235,6 +235,20 @@ do_help()
> fi
> }
>
> +## Startup
> +
> +args_saved="$@"
> +while [ -n "$1" ]; do
> + case "$1" in
> + help|--help|-h)
> + shift
> + do_help "$1"
> + exit 1;;
> + esac
> + shift
> +done
> +set -- $args_saved
> +unset args_saved
>
> ## Initial setup
Huh, why do you actually need $args_saved at all? :-) This is bound to
do horrible things with space-containing arguments etc., I think. You
don't need to do the outer shift and then drop $args_saved altogether,
no?
--
Petr "Pasky" Baudis
People who take cold baths never have rheumatism, but they have
cold baths.
^ permalink raw reply
* Cygwin error?
From: nadim khemir @ 2008-11-19 17:57 UTC (permalink / raw)
To: git
Hi, Given:
$ git pull
remote: Counting objects: 46, done.
...
Updating b80286d..a543dae
error: Untracked working tree file 'xxx.txt' would be overwritten by merge.
This is due to a rename of xxx.txt to Xxx.txt. I understand that this is due
to files being just case preserving on Cycwin/Win32.
The only I found was to remove the xxx.txt localy and do a pull. The
interresting thing is that Xxx.txt is no present in my file system. I can
check it out from HEAD though.
What did I missunderstood and do wrong?
Cheers, Nadim.
^ permalink raw reply
* Git.pm
From: nadim khemir @ 2008-11-19 17:56 UTC (permalink / raw)
To: git
Hi, I'm new on this mailing list and quite new to git too. I named on irc that
I develop mainly in Perl (http://search.cpan.org/~nkh/) when I do open
source. I heard that Git.pm needed some love and I can take over its
maintenance if there are things that need to be done.
I need to know:
- what needs to be done
- who was doing maintenanace before
- how do you want to release it (perl modules are best placed on CPAN
(too))
- what (and who) is depending on Git.pm
- what would be expected of me
As you may have seen in another mail, the Perl community is getting
interrested in git.
Cheers, Nadim.
^ permalink raw reply
* git workshop in Sweden/Denmark
From: nadim khemir @ 2008-11-19 17:58 UTC (permalink / raw)
To: git
Hi,
Lund.pm and Data-foreningen are trying to organize a 'git' workshop.
The workshop will consist of a presentation in the morning followed by a lunch
in a local restaurant and a workshop after lunch.
We already have a location where the workshop will take place. Most probably
a Saturday to allow as many people as possible to join us. The location is in
Malmö the biggest town in the south of Sweden and only 30mn by train from
Copenhagen capital of Danmark. We, of course, welcome people from other places
too.
We are already working on securing one or two speakers that will enlighten us.
I would like the git community to help us with:
- has a git workshop already been organized?
is there material that we could get?
any conference organization existing (something like YAPC)?
- what's the interrest? I'm sure I can get 30 ppl to join but if there is
interrest we can organize something bigger.
- Can you be :
- a speaker
- a sponsor
- If you come, what would you like to learn, discuss?
Cheers, Nadim.
PS: there's a lot of interrest for git in the Perl community right now and
rumors has it that Perl itself is going over to git. Next year YAPC in
Portugal would be a great opportunity to present git in depth to perl
developers. If someone is interrested, please let me know.
^ permalink raw reply
* Re: Git commit won't add an untracked file given on the command line
From: Daniel Barkalow @ 2008-11-19 18:01 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Johannes Schindelin, Mark Burton, git
In-Reply-To: <7vd4grsveo.fsf@gitster.siamese.dyndns.org>
On Wed, 19 Nov 2008, Junio C Hamano wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>
> > On Wed, 19 Nov 2008, Mark Burton wrote:
> >
> >> Having said that, I still like the concept of being able to add named
> >> files without touching the index.
> >
> > That's just impossible. You cannot create a tree object, let alone a
> > commit object, without touching the index (AKA staging area).
>
> I do not think Mark really _means_ "not in the index".
>
> The wish is more like "I want to let git know that I am interested in this
> path, but I'm not ready to say what exact content I want for that path in
> the next commit, not just yet".
>
> I do not think that is an unreasonable wish. On the other hand, it is
> unreasonable for anybody to insist that we satisfy the wish without
> touching the index. The index is the most natural place to do that.
I don't think that's what Mark wants, in this case. He's looking for the
ability to have "git commit" act on a temporary index created by adding to
the parent commit explicitly named files which aren't in the non-temporary
index. That is, Mark doesn't want to touch *the* index, which is fine; git
can commit with *an* index.
> We have a half (probably a quarter) of what we need for that implemented
> already, by the way.
I've looked into what you're suggesting on occasion; the main issue is
getting the various index users to avoid getting confused. I was stumped
by the diff code, which was confusing the "intent to add something" token
with its "compare against the work tree" token. I'd say, it's half
implemented, but testing is a major unstarted undertaking.
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* Re: "secret key not available". "unable to sign the tag".
From: Gary Yang @ 2008-11-19 16:54 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Jeff King, Git Mailing List
In-Reply-To: <alpine.LFD.2.00.0811190740200.18283@nehalem.linux-foundation.org>
The command, "git tag -u garyyang6@yahoo.com tag-name" works! Thank you!
Below is the output of "gpg -k". I have no idea why I have three keys.
gpg -k
gpg: WARNING: using insecure memory!
gpg: please see http://www.gnupg.org/faq.html for more information
/home/garyyang6/.gnupg/pubring.gpg
----------------------------------
pub 1024D/A3F6A45E 2008-11-14 Gary Yang (For git.) <garyyang6@yahoo.com>
sub 1024g/58AE6B3C 2008-11-14
pub 1024D/EE763A89 2008-11-14 Gary Yang (PGP for git.) <garyyang6@yahoo.com>
sub 1024g/AECCA323 2008-11-14
pub 1024D/5015631E 2008-11-18 Gary Yang (For git) <garyyang6@yahoo.com>
--- On Wed, 11/19/08, Linus Torvalds <torvalds@linux-foundation.org> wrote:
> From: Linus Torvalds <torvalds@linux-foundation.org>
> Subject: Re: "secret key not available". "unable to sign the tag".
> To: "Gary Yang" <garyyang6@yahoo.com>
> Cc: "Jeff King" <peff@peff.net>, "Git Mailing List" <git@vger.kernel.org>
> Date: Wednesday, November 19, 2008, 7:42 AM
> On Tue, 18 Nov 2008, Gary Yang wrote:
> >
> > The gpg works. But, git tag dose not work. Any idea?
>
> Does
>
> git tag -u garyyang6@yahoo.com tag-name
>
> work (ie when you use an explicitly given key to tag with)?
>
> And if not, please do list the output of "gpg -K"
> if that doesn't work.
>
> Linus
> --
> To unsubscribe from this list: send the line
> "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at
> http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH] compat/mingw.c: Teach mingw_rename() to replace read-only files
From: Johannes Sixt @ 2008-11-19 16:25 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: Alex Riesen, Junio C Hamano, Git Mailing List
In-Reply-To: <49242821.50604@viscovery.net>
From: Johannes Sixt <j6t@kdbg.org>
On POSIX, rename() can replace files that are not writable. On Windows,
however, read-only files cannot be replaced without additional efforts:
We have to make the destination writable first.
Since the situations where the destination is read-only are rare, we do not
make the destination writable on every invocation, but only if the first
try to rename a file failed with an "access denied" error.
Signed-off-by: Johannes Sixt <j6t@kdbg.org>
---
Johannes Sixt schrieb:
> Nicolas Pitre schrieb:
>> On Wed, 19 Nov 2008, Johannes Sixt wrote:
>>> The unusual case is where you do this:
>>>
>>> $ git rev-list -10 HEAD | git pack-objects foobar
>>>
>>> twice in a row: In this case the second invocation fails on Windows
>>> because the destination pack file already exists *and* is open. But not
>>> even git-repack does this even if it is called twice. OTOH, the test case
>>> *does* exactly this.
>> OK.... Well, despite my earlier assertion, I think the above should be a
>> valid operation.
Would you please clarify which operation you exactly mean? As is written
above, or with .git/objects/pack/foobar instead like in the test case?
>> I'm looking at it now. I'm therefore revoking my earlier ACK as well
>> (better keep that test case alive).
>
> Hold on a moment: When I tested the above sequence, I was fooled by a flaw
> in mingw_rename() (it doesn't replace read-only files). With that fixed...
Here is this fix.
-- Hannes
compat/mingw.c | 15 ++++++++++++---
1 files changed, 12 insertions(+), 3 deletions(-)
diff --git a/compat/mingw.c b/compat/mingw.c
index b534a8a..3dbe6a7 100644
--- a/compat/mingw.c
+++ b/compat/mingw.c
@@ -819,6 +819,8 @@ int mingw_connect(int sockfd, struct sockaddr *sa, size_t sz)
#undef rename
int mingw_rename(const char *pold, const char *pnew)
{
+ DWORD attrs;
+
/*
* Try native rename() first to get errno right.
* It is based on MoveFile(), which cannot overwrite existing files.
@@ -830,12 +832,19 @@ int mingw_rename(const char *pold, const char *pnew)
if (MoveFileEx(pold, pnew, MOVEFILE_REPLACE_EXISTING))
return 0;
/* TODO: translate more errors */
- if (GetLastError() == ERROR_ACCESS_DENIED) {
- DWORD attrs = GetFileAttributes(pnew);
- if (attrs != INVALID_FILE_ATTRIBUTES && (attrs & FILE_ATTRIBUTE_DIRECTORY)) {
+ if (GetLastError() == ERROR_ACCESS_DENIED &&
+ (attrs = GetFileAttributes(pnew)) != INVALID_FILE_ATTRIBUTES) {
+ if (attrs & FILE_ATTRIBUTE_DIRECTORY) {
errno = EISDIR;
return -1;
}
+ if ((attrs & FILE_ATTRIBUTE_READONLY) &&
+ SetFileAttributes(pnew, attrs & ~FILE_ATTRIBUTE_READONLY)) {
+ if (MoveFileEx(pold, pnew, MOVEFILE_REPLACE_EXISTING))
+ return 0;
+ /* revert file attributes on failure */
+ SetFileAttributes(pnew, attrs);
+ }
}
errno = EACCES;
return -1;
--
1.6.0.4.1694.g07ac
^ permalink raw reply related
* Re: git and mtime
From: Christian MICHON @ 2008-11-19 16:18 UTC (permalink / raw)
To: Roger Leigh; +Cc: git
In-Reply-To: <20081119113752.GA13611@ravenclaw.codelibre.net>
On Wed, Nov 19, 2008 at 12:37 PM, Roger Leigh <rleigh@codelibre.net> wrote:
> Would it be possible for git to store the mtime of files in the tree?
>
> This would make it possible to do this type of work in git, since it's
> currently a bit random as to whether it works or not. This only
> started when I upgraded to an amd64 architecture from powerpc32,
> I guess it's maybe using high-resolution timestamps.
>
beside the obvious answer it comes back often as a request, it is
possible in theory to create a shell script which, for each file
present in the sandbox in the current branch, would find the mtime of
the last commit on that file (quite an expensive operation) and apply
it.
I had a need for this once, then lost interest since using git as it
is is so much better than trying to mimic behaviour of old scm tools
and makefiles.
You should store mostly content of source files. You should do a make
in your first cloned repo at least once before committing anything to
the repo. That's what I did and I saved days...
--
Christian
--
http://detaolb.sourceforge.net/, a linux distribution for Qemu with Git inside !
^ permalink raw reply
* [TopGit PATCH] Check for help invocation before setup
From: martin f. krafft @ 2008-11-19 16:03 UTC (permalink / raw)
To: git; +Cc: martin f. krafft
In-Reply-To: <1227110623-4474-1-git-send-email-madduck@debian.org>
The user ought to be able to call `tg help` from anywhere in the
filesystem, not just Git repositories, so the help parsing has to happen
before the calls to git git binary.
Debian bug: #501982
Signed-off-by: martin f. krafft <madduck@debian.org>
---
tg.sh | 17 ++++++++++++++---
1 files changed, 14 insertions(+), 3 deletions(-)
diff --git a/tg.sh b/tg.sh
index 2961106..40c4ab7 100644
--- a/tg.sh
+++ b/tg.sh
@@ -235,6 +235,20 @@ do_help()
fi
}
+## Startup
+
+args_saved="$@"
+while [ -n "$1" ]; do
+ case "$1" in
+ help|--help|-h)
+ shift
+ do_help "$1"
+ exit 1;;
+ esac
+ shift
+done
+set -- $args_saved
+unset args_saved
## Initial setup
@@ -268,9 +282,6 @@ cmd="$1"
shift
case "$cmd" in
-help|--help|-h)
- do_help "$1"
- exit 1;;
--hooks-path)
# Internal command
echo "@hooksdir@";;
--
1.6.0.2
^ permalink raw reply related
* [TopGit PATCH] Check for cmddir earlier
From: martin f. krafft @ 2008-11-19 16:03 UTC (permalink / raw)
To: git; +Cc: martin f. krafft
In-Reply-To: <1227110623-4474-3-git-send-email-madduck@debian.org>
Without cmddir, tg is basically useless, even do_help() needs it, so
check it first and die hard if not found
Signed-off-by: martin f. krafft <madduck@debian.org>
---
tg.sh | 6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/tg.sh b/tg.sh
index ea22544..f3d1323 100644
--- a/tg.sh
+++ b/tg.sh
@@ -237,6 +237,9 @@ do_help()
## Startup
+[ -d "@cmddir@" ] ||
+ die "No command directory: '@cmddir@'"
+
args_saved="$@"
while [ -n "$1" ]; do
case "$1" in
@@ -263,9 +266,6 @@ tg="tg"
setup_ours
setup_hook "pre-commit"
-[ -d "@cmddir@" ] ||
- die "No command directory: '@cmddir@'"
-
## Dispatch
# We were sourced from another script for our utility functions;
--
1.6.0.2
^ permalink raw reply related
* [TopGit PATCH] Print help output when no command is given
From: martin f. krafft @ 2008-11-19 16:03 UTC (permalink / raw)
To: git; +Cc: martin f. krafft
In-Reply-To: <1227110623-4474-4-git-send-email-madduck@debian.org>
As much as I love your message (although you really ought not be
throwing around ducks!), this is more user-friendly.
Signed-off-by: martin f. krafft <madduck@debian.org>
---
tg.sh | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/tg.sh b/tg.sh
index f3d1323..e0d62e7 100644
--- a/tg.sh
+++ b/tg.sh
@@ -278,7 +278,7 @@ if [ "$1" = "-r" ]; then
fi
cmd="$1"
-[ -n "$cmd" ] || die "He took a duck in the face at two hundred and fifty knots"
+[ -n "$cmd" ] || { do_help; exit 1; }
shift
case "$cmd" in
--
1.6.0.2
^ permalink raw reply related
* [TopGit PATCH] Change tg help exit code to 0
From: martin f. krafft @ 2008-11-19 16:03 UTC (permalink / raw)
To: git; +Cc: martin f. krafft
In-Reply-To: <1227110623-4474-2-git-send-email-madduck@debian.org>
Printing --help is not an error, but a successful operation, if the help
output could be printed.
Signed-off-by: martin f. krafft <madduck@debian.org>
---
tg.sh | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/tg.sh b/tg.sh
index 40c4ab7..ea22544 100644
--- a/tg.sh
+++ b/tg.sh
@@ -243,7 +243,7 @@ while [ -n "$1" ]; do
help|--help|-h)
shift
do_help "$1"
- exit 1;;
+ exit 0;;
esac
shift
done
--
1.6.0.2
^ permalink raw reply related
* [TopGit] Improve help output
From: martin f. krafft @ 2008-11-19 16:03 UTC (permalink / raw)
To: git
The following patches improve the help output by TopGit. They are
not all related, but they conflict.
I would just push them to the master branch, but I don't want to
risk my chances of Petr getting angry with his new release
assistant...
^ permalink raw reply
* Re: "secret key not available". "unable to sign the tag".
From: Linus Torvalds @ 2008-11-19 15:42 UTC (permalink / raw)
To: Gary Yang; +Cc: Jeff King, Git Mailing List
In-Reply-To: <31942.12221.qm@web37902.mail.mud.yahoo.com>
On Tue, 18 Nov 2008, Gary Yang wrote:
>
> The gpg works. But, git tag dose not work. Any idea?
Does
git tag -u garyyang6@yahoo.com tag-name
work (ie when you use an explicitly given key to tag with)?
And if not, please do list the output of "gpg -K" if that doesn't work.
Linus
^ permalink raw reply
* Re: git and mtime
From: Matthieu Moy @ 2008-11-19 14:54 UTC (permalink / raw)
To: Arafangion; +Cc: Roger Leigh, git
In-Reply-To: <1227098252.11370.8.camel@therock.nsw.bigpond.net.au>
Arafangion <thestar@fussycoder.id.au> writes:
> You should probably fix your build script,
ccache should help:
http://ccache.samba.org/
--
Matthieu
^ permalink raw reply
* Re: [PATCH] Fix handle leak in builtin-pack-objects
From: Johannes Sixt @ 2008-11-19 14:52 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: Alex Riesen, Junio C Hamano, Git Mailing List
In-Reply-To: <alpine.LFD.2.00.0811190940480.27509@xanadu.home>
Nicolas Pitre schrieb:
> On Wed, 19 Nov 2008, Johannes Sixt wrote:
>> The unusual case is where you do this:
>>
>> $ git rev-list -10 HEAD | git pack-objects foobar
>>
>> twice in a row: In this case the second invocation fails on Windows
>> because the destination pack file already exists *and* is open. But not
>> even git-repack does this even if it is called twice. OTOH, the test case
>> *does* exactly this.
>
> OK.... Well, despite my earlier assertion, I think the above should be a
> valid operation.
>
> I'm looking at it now. I'm therefore revoking my earlier ACK as well
> (better keep that test case alive).
Hold on a moment: When I tested the above sequence, I was fooled by a flaw
in mingw_rename() (it doesn't replace read-only files). With that fixed,
it works as expected in repeated invocations (note that foobar is outside
the .git/objects/pack directory).
If I use .git/objects/pack/foobar instead, then I get the failures on
Windows, and I won't argue that this should be "fixed". ;)
-- Hannes
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox