* Re: Git commit won't add an untracked file given on the command line
From: Junio C Hamano @ 2008-11-19 23:07 UTC (permalink / raw)
To: Daniel Barkalow; +Cc: Johannes Schindelin, Mark Burton, git
In-Reply-To: <alpine.LNX.1.00.0811191247560.19665@iabervon.org>
Daniel Barkalow <barkalow@iabervon.org> writes:
> 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.
Ah, I think that it would not be an entirely unreasonable thing to do
(cf. Message-Id: <7vtza4trdp.fsf@gitster.siamese.dyndns.org>).
You can say "git add that/directory" and .gitignore mechanism protects you
from crufts in that/directory, so fearing "git commit that/directory" to
add random junk to the next commit is not a reason to fear it.
But that is a huge behaviour change. For example, I have a handful test
scripts in my t/ directory (all named following the usual t????-*.sh
naming convention) that I do not want to commit. Today, after making
changes to the tracked test scripts, I can rely on "git commit t/" not to
include them in the commit, and I've _learned_ to trust that behaviour.
I'd be surprised if others who have used git for more than a few months
haven't done so as well.
Allowing what Mark wants without any explicit user customization will be a
disaster to the end user experience.
^ permalink raw reply
* Re: [PATCH] Retain multiple -q/-v occurrences in git pull
From: Tuncer Ayaz @ 2008-11-19 23:00 UTC (permalink / raw)
To: Constantine Plotnikov; +Cc: Junio C Hamano, git
In-Reply-To: <4ac8254d0811191458r2a205be3w4a412553edc9b07f@mail.gmail.com>
[re-sent due to propagated wrong Junio address. sorry.]
On Wed, Nov 19, 2008 at 12:46 PM, Constantine Plotnikov
<constantine.plotnikov@gmail.com> wrote:
> On Tue, Nov 18, 2008 at 1:09 AM, Tuncer Ayaz <tuncer.ayaz@gmail.com> wrote:
>> To support counting -q/-v options in git pull retain
>> them by concatenating.
>>
> [rest of message cut]
>
> By the way, there is yet another way to invoke git fetch. It is "git
> remote update". Possibly it should support "-v" and "-q" options for
> consistency as well.
Yes, we could add -q to builtin-remote and also make sure that it
passes the already existing -v and maybe a yet-to-be-added -q to
the fetch command.
I want to be first sure what the overall strategy regarding -q/-v is.
Right now we have some code which uses OPT__VERBOSE/OPT__QUIET
and some new code which uses the newly-added OPT__VERBOSITY.
These are the options I can see:
1) Use the old and new macros and decide in each module which one to use
2) Get rid off OPT__VERBOSE and OPT__QUIET and use OPT__VERBOSITY only
3) Think about new ways to handle all of this. Possibly some new print_* macros?
Any opinions?
^ permalink raw reply
* Re: [PATCH] Retain multiple -q/-v occurrences in git pull
From: Tuncer Ayaz @ 2008-11-19 22:47 UTC (permalink / raw)
To: Constantine Plotnikov; +Cc: git, gitster
In-Reply-To: <85647ef50811190346x11aea0fay3a8a7dfd8ddf6abc@mail.gmail.com>
On Wed, Nov 19, 2008 at 12:46 PM, Constantine Plotnikov
<constantine.plotnikov@gmail.com> wrote:
> On Tue, Nov 18, 2008 at 1:09 AM, Tuncer Ayaz <tuncer.ayaz@gmail.com> wrote:
>> To support counting -q/-v options in git pull retain
>> them by concatenating.
>>
> [rest of message cut]
>
> By the way, there is yet another way to invoke git fetch. It is "git
> remote update". Possibly it should support "-v" and "-q" options for
> consistency as well.
Yes, we could add -q to builtin-remote and also make sure that it
passes the already existing -v and maybe a yet-to-be-added -q to
the fetch command.
I want to be first sure what the overall strategy regarding -q/-v is.
Right now we have some code which uses OPT__VERBOSE/OPT__QUIET
and some new code which uses the newly-added OPT__VERBOSITY.
These are the options I can see:
1) Use the old and new macros and decide in each module which one to use
2) Get rid off OPT__VERBOSE and OPT__QUIET and use OPT__VERBOSITY only
3) Think about new ways to handle all of this. Possibly some new print_* macros?
Any opinions?
^ permalink raw reply
* Re: [git-p4] Can't submit: Something I do in a wrong way.
From: Evgeniy Ivanov @ 2008-11-19 22:16 UTC (permalink / raw)
Cc: git
In-Reply-To: <49247E5D.7070601@gmail.com>
Retried and noticed that if I do:
/dir1/1> git-p4 submit --git-dir=../../git/1/ --origin=master
Then everything works fine. Strange, but docs say:
"This requires a Perforce checkout separate to your git
repository. To submit all changes that are in the current git branch but
not in
the "p4" branch (or "origin" if "p4" doesn't exist) simply call
git-p4 submit
in your git repository."
And my approach is a bit vice versa.
Any suggestions? I can go with it, but I want almost forget about thing
that I have perforce :)
Evgeniy Ivanov wrote:
> Hi list,
> I need a help with git-p4.
>
> There are //1, //2, //3 in perforce's depot, and /dir1 is a client's root.
> So:
> Root: /dir1/
> //1/... //client/1... etc
> I've checkouted //1, //2 and //3.
>
> In /git I did "git clone //1; git clone //2", So I have /git/1, /git/2.
> Now I run in /git/1 "git-p4 submit commitBr" and choose 'y' to sync,
> where comitBr has one more commit than master.
> I get "Path /git/1/... is not under client's root /dir1/". Without
> syncing it says I have opened files, but when I do in /dir1/1 "p4 -a
> revert" I get: "file(s) not opened on this client".
> Looks like "git-p4 rebase" works fine.
>
> Also I tried to keep git in the same dir as perforce workspace: I did 1
> commit and then failed to do anything, because got strange conflicts.
>
>
> P.S. Please don't forget to keep me in CC :)
>
>
--
Cheers, Evgeniy.
Key fingerprint: F316 B5A1 F6D2 054F CD18 B74A 9540 0ABB 1FE5 67A3
^ permalink raw reply
* Re: removing svn remotes
From: Matt Graham @ 2008-11-19 21:26 UTC (permalink / raw)
To: Björn Steinbrink; +Cc: git
In-Reply-To: <20081119083219.GB3538@atjola.homenet>
On Wed, Nov 19, 2008 at 03:32, Björn Steinbrink <B.Steinbrink@gmx.de> wrote:
> On 2008.11.18 20:47:24 -0500, Matt Graham wrote:
>> Hi,
>> I have a svn repo cloned into a git repo. There are several remote
>> refs that are there that I don't care about and don't want to fetch.
>>
>> git svn fetch --fetch-all gets a bunch of stuff from branches I don't want
>> git svn fetch requires I checkout the branches I care about before fetching
>>
>> git svn fetch doesn't accept a branch name
>> git remote rm isn't able to see the svn remotes
>>
>> Is there a way to either:
>> 1) get rid of the svn remotes that I don't want?
>> 2) fetch only the remotes that I do want?
>
> Uhm, are you talking about remote tracking branches (what "git branch
> -r" shows), or svn-remotes (not sure if git-svn can list them, they're
> in .git/config)?
>
> The behaviour you describe doesn't match my experience with git-svn, so
> maybe you could elaborate a bit on the exact problem?
Sorry the question was not clear.
git branch -r -d
did exactly what I need. I guess I just didn't know how to ask for
it. Another happy discovery.
Using git branch -r -d, I was able to delete my svn-remotes.
Now when I run git svn fetch --fetch-all, it appears to fetch only
from the remaining branches that I didn't delete. I hope that
clarifies it.
thank you!
^ permalink raw reply
* [git-p4] Can't submit: Something I do in a wrong way.
From: Evgeniy Ivanov @ 2008-11-19 21:00 UTC (permalink / raw)
To: git
Hi list,
I need a help with git-p4.
There are //1, //2, //3 in perforce's depot, and /dir1 is a client's root.
So:
Root: /dir1/
//1/... //client/1... etc
I've checkouted //1, //2 and //3.
In /git I did "git clone //1; git clone //2", So I have /git/1, /git/2.
Now I run in /git/1 "git-p4 submit commitBr" and choose 'y' to sync,
where comitBr has one more commit than master.
I get "Path /git/1/... is not under client's root /dir1/". Without
syncing it says I have opened files, but when I do in /dir1/1 "p4 -a
revert" I get: "file(s) not opened on this client".
Looks like "git-p4 rebase" works fine.
Also I tried to keep git in the same dir as perforce workspace: I did 1
commit and then failed to do anything, because got strange conflicts.
P.S. Please don't forget to keep me in CC :)
--
Cheers, Evgeniy.
Key fingerprint: F316 B5A1 F6D2 054F CD18 B74A 9540 0ABB 1FE5 67A3
^ permalink raw reply
* 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
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