* Re: [gitweb feature request] Release snapshots with vX.X.X tags
From: Junio C Hamano @ 2009-11-08 18:53 UTC (permalink / raw)
To: Bram Neijt; +Cc: Git mailing list
In-Reply-To: <1257680442.14087.78.camel@owl>
Bram Neijt <bneijt@gmail.com> writes:
> I would like to create release snapshots with a git tag like "v0.0.1".
> For proper Debian packaging, a release snapshot of tag "v0.0.1" would
> have to be named "project-0.0.1.tar.gz" and contain a single directory
> with "project-0.0.1/" in the archive.
What the intended audience of this feature? IOW,
- who are going to "click" such a link on gitweb to obtain
project-0.0.1.tar.gz with project-0.0.1/?
- how are they going to use that tarball?
I somehow suspect that they won't be the official Debian distro packagers.
Most likely they actually have a clone of the upstream project (how else
they can stay up to date? In addition they would want to track their own
changes), so it would be more efficient for them to generate such a
tarball from a tag, and more importantly, doing it locally means that they
can they can verify the tag (and the whole history leading to it) before
doing so, instead of relying on somebody else's gitweb.
You could be a mere Debian user who produces a *.deb for his own use out
of such tarball, and in such a case you are a lot less likely be tracking
the project (meaning, reading the history and keeping track of fixed bugs,
new regressions and such) than just getting a snapshot that happens to be
there and building it blindly, and I can understand it would be nicer if
you did not have to unpack, rename and regenerate an archive.
Also, whose gitweb installations are you envisioning to enable this new
feature? Are you going to convince all the gitweb administrators of
projects packaged by Debian (and derivatives) that have gitweb, and what
are the incentive for these upstream projects to do so? I would guess
that most of the upstream projects do not consider Debian as their sole
target distribution, and it would be a tough sell if changing the snapshot
name to suit Debian breaks some other distro's (or human users) needs.
Jakub is polishing Mark's patch to change the snapshot name and contents
hierarchy, but I think it won't satisfy Debian's naming guideline (it will
have v0.0.1, not 0.0.1 in the name). Changing the series's default to
drop 'v' from the beginning of the tagname when the rest of it consists of
all digits and dots would not be a correct solution, as Debian is not the
only system in the world and other people may want different naming rules.
In order to make his series useful for your objective, it probably would
require a bit more customizability, but because I cannot tell whom such a
feature is really trying to help, and what the deployment plans are, I
cannot judge if extra complexity to add such a customizability is worth
it. Also because there will be conflicts in the desired archive format
("Distro X people want this kind of archive, distro Y people want this
different kind"), the choice somehow how to come from whoever is clicking
the link, not from the gitweb administrator, and it probably would mean
the codepath involved would need a lot more careful audit than just a
server only "this gitweb installation would use this format"
configuration.
^ permalink raw reply
* Re: [PATCH] Documentation: avoid tracking intermediate build products
From: Junio C Hamano @ 2009-11-08 19:08 UTC (permalink / raw)
To: Jonathan Nieder; +Cc: Junio C Hamano, git, Chris Johnsen
In-Reply-To: <20091108112009.GA23790@progeny.tock>
Jonathan Nieder <jrnieder@gmail.com> writes:
> Add *.xml+, *.html+, *.texi+, and *.texi++ to .gitignore.
>
> Cc: Chris Johnsen <chris_johnsen@pobox.com>
> Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
> ---
> Some of these files appeared in the "git status" output after an
> interrupted build. I hope I caught them all.
Thanks; I think "*+" would suffice, though.
^ permalink raw reply
* Re: Automatically remote prune
From: Junio C Hamano @ 2009-11-08 19:08 UTC (permalink / raw)
To: Petr Baudis; +Cc: Jay Soffian, Junio C Hamano, John Tapsell, Git List
In-Reply-To: <20091106103100.GG17748@machine.or.cz>
Petr Baudis <pasky@suse.cz> writes:
> On Thu, Nov 05, 2009 at 07:38:39PM -0500, Jay Soffian wrote:
>> On Thu, Nov 5, 2009 at 7:17 PM, Petr Baudis <pasky@suse.cz> wrote:
>> > On Thu, Nov 05, 2009 at 06:09:03PM -0500, Jay Soffian wrote:
>> >> Actually, mirror mode applies to push only. Unless I'm missing
>> >> something obvious.
>> >
>> > Perhaps you are, mirror mode applies to fetch as well...
Sorry, my thinko. We do not do mirrors in fetch.
^ permalink raw reply
* Re: Allowing push --dry-run through fetch url
From: Junio C Hamano @ 2009-11-08 19:23 UTC (permalink / raw)
To: Mike Hommey; +Cc: git
In-Reply-To: <20091106095357.GA13389@glandium.org>
Mike Hommey <mh@glandium.org> writes:
> Usually, when I run git push --dry-run, it's to check that what follows
> (usually the refspec part) does what I want it to do, such as not pushing
> tags I didn't intend to push(*), and stuff like that.
Ahh, that one.
That reminds me of a topic that we discussed but went away without
reaching the conclusion on adding a "confirmation: are you sure this
pushes what you want?" to the command. I had a doubt about the patch back
then which was that it hardcoded a tty interaction and it would be hard to
retrofit it to help GUI frontends (so my suggestion was to use something
like hooks mechanism, perhaps --confirm=this-script and allow it to do its
GUI thing), but thinking about it again, they can always use "expect" to
drive the interaction with the confirmation prompt, so it may not a big
deal after all---we might want to resurrect the topic.
That was an unrelated, independent thought on your comment, but if we did
so, you might not even have to try to use --dry-run on git:// transport.
^ permalink raw reply
* [BUG]
From: Matthieu Moy @ 2009-11-08 20:36 UTC (permalink / raw)
To: git
[-- Attachment #1: Type: text/plain, Size: 2077 bytes --]
Hi,
I'm hitting a bug when git-push-ing to a Linux PPC machine. In
general, pushing works well, but pushing some particular commits
breaks reproducibly with :
fatal: early EOF
error: unpack failed: unpack-objects abnormal exit
To ssh://localhost//home/perms/moy/prive/dest
! [remote rejected] master -> master (n/a (unpacker error))
I've put the guilty files on my website and wrote a reproduction
script:
#!/bin/sh
rm -fr source dest
git init source
git init --bare dest
dest=$PWD/dest
cd source
echo foo > bar.txt
git add .
git commit -m init
git push ssh://localhost/$dest master
wget 'http://www-verimag.imag.fr/~moy/tmp/git-bug/Conception Manual.docx'
wget 'http://www-verimag.imag.fr/~moy/tmp/git-bug/Extreme Programming.doc'
git add .
git commit -m "bug"
git push ssh://localhost/$dest master
The full output is attached (the error message for the last push is
given above). The machine on which I get this (let's call it "A")
says :
$ ssh -Version
OpenSSH_4.3p2, OpenSSL 0.9.8e-fips-rhel5 01 Jul 2008
$ uname -a
Linux A 2.6.18-128.7.1.el5 #1 SMP Wed Aug 19 04:08:13 EDT 2009 ppc64 ppc64 ppc64 GNU/Linux
$ cat /etc/redhat-release
Red Hat Enterprise Linux Server release 5.4 (Tikanga)
(it's a 32-bit distribution although the machine is 64bits)
$ git --version
git version 1.6.5.2
(compiled myself, "make test" passes)
According to my experiments, the problem is on the receiver side. If I
do the same as above, with source/ and dest/ directories on two
different machines, then if source/ in on A and dest/ anywhere else,
it works, and if dest/ is on machine A, I get the same error.
If I push using "file://" instead of "ssh://", then everything works
well.
If instead of push-ing, I go to dest/ and do a fetch, then it works
well too.
Does anyone have any idea on what's going on?
If anyone has a machine similar to mine (ppc64), can he/she run my
reproduction script and tell me if the bug happens?
Thanks a lot,
[-- Attachment #2: git-bug-output.txt --]
[-- Type: text/plain, Size: 4744 bytes --]
Initialized empty Git repository in /perms/moy/prive/source/.git/
Initialized empty Git repository in /perms/moy/prive/dest/
[master (root-commit) e14141d] init
1 files changed, 1 insertions(+), 0 deletions(-)
create mode 100644 bar.txt
Counting objects: 3, done.
Writing objects: 33% (1/3) \rWriting objects: 66% (2/3) \rWriting objects: 100% (3/3) \rWriting objects: 100% (3/3), 209 bytes, done.
Total 3 (delta 0), reused 0 (delta 0)
To ssh://localhost//home/perms/moy/prive/dest
* [new branch] master -> master
--2009-11-08 21:15:27-- http://www-verimag.imag.fr/~moy/tmp/git-bug/Conception%20Manual.docx
Resolving www-verimag.imag.fr... 129.88.43.46
Connecting to www-verimag.imag.fr|129.88.43.46|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 1064912 (1.0M) [application/x-zip]
Saving to: `Conception Manual.docx'
0K .......... .......... .......... .......... .......... 4% 42.9M 0s
50K .......... .......... .......... .......... .......... 9% 38.1M 0s
100K .......... .......... .......... .......... .......... 14% 51.4M 0s
150K .......... .......... .......... .......... .......... 19% 47.1M 0s
200K .......... .......... .......... .......... .......... 24% 54.5M 0s
250K .......... .......... .......... .......... .......... 28% 58.4M 0s
300K .......... .......... .......... .......... .......... 33% 53.5M 0s
350K .......... .......... .......... .......... .......... 38% 64.5M 0s
400K .......... .......... .......... .......... .......... 43% 42.0M 0s
450K .......... .......... .......... .......... .......... 48% 55.7M 0s
500K .......... .......... .......... .......... .......... 52% 61.9M 0s
550K .......... .......... .......... .......... .......... 57% 54.4M 0s
600K .......... .......... .......... .......... .......... 62% 56.3M 0s
650K .......... .......... .......... .......... .......... 67% 58.8M 0s
700K .......... .......... .......... .......... .......... 72% 61.6M 0s
750K .......... .......... .......... .......... .......... 76% 53.5M 0s
800K .......... .......... .......... .......... .......... 81% 44.3M 0s
850K .......... .......... .......... .......... .......... 86% 54.4M 0s
900K .......... .......... .......... .......... .......... 91% 63.9M 0s
950K .......... .......... .......... .......... .......... 96% 75.0M 0s
1000K .......... .......... .......... ......... 100% 89.8M=0.02s
2009-11-08 21:15:27 (54.1 MB/s) - `Conception Manual.docx' saved [1064912/1064912]
--2009-11-08 21:15:27-- http://www-verimag.imag.fr/~moy/tmp/git-bug/Extreme%20Programming.doc
Resolving www-verimag.imag.fr... 129.88.43.46
Connecting to www-verimag.imag.fr|129.88.43.46|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 521216 (509K) [application/msword]
Saving to: `Extreme Programming.doc'
0K .......... .......... .......... .......... .......... 9% 42.7M 0s
50K .......... .......... .......... .......... .......... 19% 38.3M 0s
100K .......... .......... .......... .......... .......... 29% 51.4M 0s
150K .......... .......... .......... .......... .......... 39% 48.9M 0s
200K .......... .......... .......... .......... .......... 49% 51.9M 0s
250K .......... .......... .......... .......... .......... 58% 57.0M 0s
300K .......... .......... .......... .......... .......... 68% 54.6M 0s
350K .......... .......... .......... .......... .......... 78% 56.1M 0s
400K .......... .......... .......... .......... .......... 88% 52.5M 0s
450K .......... .......... .......... .......... .......... 98% 75.4M 0s
500K ......... 100% 17.6M=0.01s
2009-11-08 21:15:27 (52.3 MB/s) - `Extreme Programming.doc' saved [521216/521216]
[master c0fa75f] bug
2 files changed, 0 insertions(+), 0 deletions(-)
create mode 100644 Conception Manual.docx
create mode 100644 Extreme Programming.doc
Counting objects: 5, done.
Delta compression using up to 16 threads.
Compressing objects: 25% (1/4) \rCompressing objects: 50% (2/4) \rCompressing objects: 75% (3/4) \rCompressing objects: 100% (4/4) \rCompressing objects: 100% (4/4), done.
Writing objects: 25% (1/4) \rWriting objects: 50% (2/4) \rWriting objects: 75% (3/4) \rWriting objects: 100% (4/4) \rWriting objects: 100% (4/4), 1.38 MiB, done.
Total 4 (delta 0), reused 0 (delta 0)
fatal: early EOF
error: unpack failed: unpack-objects abnormal exit
To ssh://localhost//home/perms/moy/prive/dest
! [remote rejected] master -> master (n/a (unpacker error))
error: failed to push some refs to 'ssh://localhost//home/perms/moy/prive/dest'
[-- Attachment #3: Type: text/plain, Size: 50 bytes --]
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
^ permalink raw reply
* Re: [RFC/PATCH 1/4] Teach the --all option to 'git fetch'
From: Paolo Bonzini @ 2009-11-08 21:08 UTC (permalink / raw)
To: git
In-Reply-To: <4AF6E7A6.5060209@gmail.com>
On 11/08/2009 04:45 PM, Björn Gustavsson wrote:
> 'git remote' is meant for managing remotes and 'git fetch' is meant
> for actually fetching data from remote repositories. Therefore, it is
> not logical that you must use 'git remote update' to fetch from
> more than one repository at once.
>
> Add the --all option to 'git fetch', to tell it to attempt to fetch
> from all remotes. Also, if --all is not given, the<repository>
> argument is allowed to be the name of a group, to allow fetching
> from all repositories in the group.
>
> Other options except -v and -q are silently ignored.
I'm not sure about the naming of the option. The reason is that while
there is no "git remote push", it makes sense (at least in this case
symmetry) between "git fetch" and "git push". I would love to have a
way to push to multiple remotes, for one thing. :-)
What about having "git fetch --multiple" without arguments do the same
thing as "git fetch --all" (possibly renaming skipFetchAll to
skipFetchDefault)?
Paolo
^ permalink raw reply
* Re: [gitweb feature request] Release snapshots with vX.X.X tags
From: Bram Neijt @ 2009-11-08 21:08 UTC (permalink / raw)
To: Git mailing list
In-Reply-To: <7vbpjcetlp.fsf@alter.siamese.dyndns.org>
I was going to comment inline but I think the general question can be
read as "why would you want this?". For me it's just an extra bit of
automation. It would keep me from having to make release tarballs. I
would just refer all the users to a gitweb snapshot link of the "v..."
tag. Having a release tarball with "projectname-version" with a single
directory called "projectname-version/" in it is just good practice if
you ask me.
Therefore it would benefit any developer like me :D : a spare time
hobbyist who likes to automate as much of the administrative tasks, that
go into running an open source project, as possible.
Greets,
Bram
PS I've found that cgit: http://hjemli.net/git/cgit/
has this feature, so I'm probably going to give that a try and get back
to you if I find any problems with it (the feature that is).
On Sun, 2009-11-08 at 10:53 -0800, Junio C Hamano wrote:
> Bram Neijt <bneijt@gmail.com> writes:
>
> > I would like to create release snapshots with a git tag like "v0.0.1".
> > For proper Debian packaging, a release snapshot of tag "v0.0.1" would
> > have to be named "project-0.0.1.tar.gz" and contain a single directory
> > with "project-0.0.1/" in the archive.
>
> What the intended audience of this feature? IOW,
>
> - who are going to "click" such a link on gitweb to obtain
> project-0.0.1.tar.gz with project-0.0.1/?
>
> - how are they going to use that tarball?
>
> I somehow suspect that they won't be the official Debian distro packagers.
>
> Most likely they actually have a clone of the upstream project (how else
> they can stay up to date? In addition they would want to track their own
> changes), so it would be more efficient for them to generate such a
> tarball from a tag, and more importantly, doing it locally means that they
> can they can verify the tag (and the whole history leading to it) before
> doing so, instead of relying on somebody else's gitweb.
>
> You could be a mere Debian user who produces a *.deb for his own use out
> of such tarball, and in such a case you are a lot less likely be tracking
> the project (meaning, reading the history and keeping track of fixed bugs,
> new regressions and such) than just getting a snapshot that happens to be
> there and building it blindly, and I can understand it would be nicer if
> you did not have to unpack, rename and regenerate an archive.
>
> Also, whose gitweb installations are you envisioning to enable this new
> feature? Are you going to convince all the gitweb administrators of
> projects packaged by Debian (and derivatives) that have gitweb, and what
> are the incentive for these upstream projects to do so? I would guess
> that most of the upstream projects do not consider Debian as their sole
> target distribution, and it would be a tough sell if changing the snapshot
> name to suit Debian breaks some other distro's (or human users) needs.
>
> Jakub is polishing Mark's patch to change the snapshot name and contents
> hierarchy, but I think it won't satisfy Debian's naming guideline (it will
> have v0.0.1, not 0.0.1 in the name). Changing the series's default to
> drop 'v' from the beginning of the tagname when the rest of it consists of
> all digits and dots would not be a correct solution, as Debian is not the
> only system in the world and other people may want different naming rules.
>
> In order to make his series useful for your objective, it probably would
> require a bit more customizability, but because I cannot tell whom such a
> feature is really trying to help, and what the deployment plans are, I
> cannot judge if extra complexity to add such a customizability is worth
> it. Also because there will be conflicts in the desired archive format
> ("Distro X people want this kind of archive, distro Y people want this
> different kind"), the choice somehow how to come from whoever is clicking
> the link, not from the gitweb administrator, and it probably would mean
> the codepath involved would need a lot more careful audit than just a
> server only "this gitweb installation would use this format"
> configuration.
> --
> 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
* Re: [RFC/PATCH 4/4] Re-implement 'git remote update' using 'git fetch'
From: Paolo Bonzini @ 2009-11-08 21:10 UTC (permalink / raw)
To: git
In-Reply-To: <4AF6E865.1030900@gmail.com>
On 11/08/2009 04:48 PM, Björn Gustavsson wrote:
> In order to not duplicate functionality, re-implement 'git remote
> update' in terms of 'git fetch'.
>
> There is one incompatibility: the skipDefaultUpdate configuration
> variable will only be honored if remotes.default is not set (i.e.
> when 'git remote update' will invoke 'git fetch --all', not when
> it will invoke 'git fetch default').
Rather than introducing this incompatibility, I'd rather see 'git remote
update' deprecated (so that the code will one day go away for good) and,
for now, leave duplicated functionality for the incompatible case.
It would be great if the deprecation message for "git remote update"
spewed out commands to convert the old configuration to what is needed
for "git fetch --all" to work in the same way.
Paolo
^ permalink raw reply
* Re: [gitweb feature request] Release snapshots with vX.X.X tags
From: J.H. @ 2009-11-08 21:27 UTC (permalink / raw)
To: Bram Neijt; +Cc: Git mailing list
In-Reply-To: <1257714522.14087.133.camel@owl>
Bram,
This is true, but gitweb, in it's current incarnation, is *SLOW* using
it as a primary distribution means is ludicrous. Regenerating a tarball
on each request will destroy a server, plain and simple. Git/Gitweb
should *NOT* be used in place of doing properly release engineering.
If Debian requires their tarballs to be done up in a certain way, this
is either the problem of the packager, or if you want to be kind create
a makefile target that will generate this and release both when you do a
release:
I.E.
# make release
Generating Normal Tarball: <project>-<version>.tar.gz
Generating Debian Tarball: <project>-<version>.deb.tar.gz
# ls
Makefile <project>-<version>.tar.gz <project>-<version>.deb.tar.gz src/
#
Then take your releases and put them on your release server.
- John 'Warthog9' Hawley
Bram Neijt wrote:
> I was going to comment inline but I think the general question can be
> read as "why would you want this?". For me it's just an extra bit of
> automation. It would keep me from having to make release tarballs. I
> would just refer all the users to a gitweb snapshot link of the "v..."
> tag. Having a release tarball with "projectname-version" with a single
> directory called "projectname-version/" in it is just good practice if
> you ask me.
>
> Therefore it would benefit any developer like me :D : a spare time
> hobbyist who likes to automate as much of the administrative tasks, that
> go into running an open source project, as possible.
>
> Greets,
> Bram
>
> PS I've found that cgit: http://hjemli.net/git/cgit/
> has this feature, so I'm probably going to give that a try and get back
> to you if I find any problems with it (the feature that is).
>
> On Sun, 2009-11-08 at 10:53 -0800, Junio C Hamano wrote:
>> Bram Neijt <bneijt@gmail.com> writes:
>>
>>> I would like to create release snapshots with a git tag like "v0.0.1".
>>> For proper Debian packaging, a release snapshot of tag "v0.0.1" would
>>> have to be named "project-0.0.1.tar.gz" and contain a single directory
>>> with "project-0.0.1/" in the archive.
>> What the intended audience of this feature? IOW,
>>
>> - who are going to "click" such a link on gitweb to obtain
>> project-0.0.1.tar.gz with project-0.0.1/?
>>
>> - how are they going to use that tarball?
>>
>> I somehow suspect that they won't be the official Debian distro packagers.
>>
>> Most likely they actually have a clone of the upstream project (how else
>> they can stay up to date? In addition they would want to track their own
>> changes), so it would be more efficient for them to generate such a
>> tarball from a tag, and more importantly, doing it locally means that they
>> can they can verify the tag (and the whole history leading to it) before
>> doing so, instead of relying on somebody else's gitweb.
>>
>> You could be a mere Debian user who produces a *.deb for his own use out
>> of such tarball, and in such a case you are a lot less likely be tracking
>> the project (meaning, reading the history and keeping track of fixed bugs,
>> new regressions and such) than just getting a snapshot that happens to be
>> there and building it blindly, and I can understand it would be nicer if
>> you did not have to unpack, rename and regenerate an archive.
>>
>> Also, whose gitweb installations are you envisioning to enable this new
>> feature? Are you going to convince all the gitweb administrators of
>> projects packaged by Debian (and derivatives) that have gitweb, and what
>> are the incentive for these upstream projects to do so? I would guess
>> that most of the upstream projects do not consider Debian as their sole
>> target distribution, and it would be a tough sell if changing the snapshot
>> name to suit Debian breaks some other distro's (or human users) needs.
>>
>> Jakub is polishing Mark's patch to change the snapshot name and contents
>> hierarchy, but I think it won't satisfy Debian's naming guideline (it will
>> have v0.0.1, not 0.0.1 in the name). Changing the series's default to
>> drop 'v' from the beginning of the tagname when the rest of it consists of
>> all digits and dots would not be a correct solution, as Debian is not the
>> only system in the world and other people may want different naming rules.
>>
>> In order to make his series useful for your objective, it probably would
>> require a bit more customizability, but because I cannot tell whom such a
>> feature is really trying to help, and what the deployment plans are, I
>> cannot judge if extra complexity to add such a customizability is worth
>> it. Also because there will be conflicts in the desired archive format
>> ("Distro X people want this kind of archive, distro Y people want this
>> different kind"), the choice somehow how to come from whoever is clicking
>> the link, not from the gitweb administrator, and it probably would mean
>> the codepath involved would need a lot more careful audit than just a
>> server only "this gitweb installation would use this format"
>> configuration.
>> --
>> 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
>
>
> --
> 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
* Re: [BUG] unpack-objects abnormal exit when pushing
From: Matthieu Moy @ 2009-11-08 21:28 UTC (permalink / raw)
To: git
In-Reply-To: <vpqeio8eou4.fsf@bauges.imag.fr>
Hi,
Sorry, I forgot to set the subject before sending. The bug report
still holds:
Matthieu Moy <Matthieu.Moy@grenoble-inp.fr> writes:
> Hi,
>
> I'm hitting a bug when git-push-ing to a Linux PPC machine. In
> general, pushing works well, but pushing some particular commits
> breaks reproducibly with :
>
> fatal: early EOF
> error: unpack failed: unpack-objects abnormal exit
> To ssh://localhost//home/perms/moy/prive/dest
> ! [remote rejected] master -> master (n/a (unpacker error))
>
> I've put the guilty files on my website and wrote a reproduction
> script:
>
> #!/bin/sh
>
> rm -fr source dest
> git init source
> git init --bare dest
> dest=$PWD/dest
> cd source
> echo foo > bar.txt
> git add .
> git commit -m init
> git push ssh://localhost/$dest master
> wget 'http://www-verimag.imag.fr/~moy/tmp/git-bug/Conception Manual.docx'
> wget 'http://www-verimag.imag.fr/~moy/tmp/git-bug/Extreme Programming.doc'
> git add .
> git commit -m "bug"
> git push ssh://localhost/$dest master
>
> The full output is attached (the error message for the last push is
> given above). The machine on which I get this (let's call it "A")
> says :
>
> $ ssh -Version
> OpenSSH_4.3p2, OpenSSL 0.9.8e-fips-rhel5 01 Jul 2008
> $ uname -a
> Linux A 2.6.18-128.7.1.el5 #1 SMP Wed Aug 19 04:08:13 EDT 2009 ppc64 ppc64 ppc64 GNU/Linux
> $ cat /etc/redhat-release
> Red Hat Enterprise Linux Server release 5.4 (Tikanga)
> (it's a 32-bit distribution although the machine is 64bits)
> $ git --version
> git version 1.6.5.2
> (compiled myself, "make test" passes)
>
> According to my experiments, the problem is on the receiver side. If I
> do the same as above, with source/ and dest/ directories on two
> different machines, then if source/ in on A and dest/ anywhere else,
> it works, and if dest/ is on machine A, I get the same error.
>
> If I push using "file://" instead of "ssh://", then everything works
> well.
>
> If instead of push-ing, I go to dest/ and do a fetch, then it works
> well too.
>
> Does anyone have any idea on what's going on?
>
> If anyone has a machine similar to mine (ppc64), can he/she run my
> reproduction script and tell me if the bug happens?
>
> Thanks a lot,
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
^ permalink raw reply
* Re: gitk : french translation
From: Nicolas Sebrecht @ 2009-11-08 21:41 UTC (permalink / raw)
To: Emmanuel Trillaud; +Cc: Nicolas Sebrecht, Thomas Moulard, Git Mailing List
In-Reply-To: <9f50533b0911080955l606ea87aw4edd7b0bc926a25f@mail.gmail.com>
The 08/11/09, Emmanuel Trillaud wrote:
> 2009/11/7 Nicolas Sebrecht <nicolas.s.dev@gmx.fr>:
> > [
> > Please, conform to Documentation/SubmittingPatches of the git.git
> > project and send your patches inline to make the work for reviewers
> > easier.
> >
> > Both of your patches lack the Signed-off-by but maybe you don't want
> > them to be merged?
> > ]
> I am aware of this recommendation but this translation is almost 22kb and
> I tought that put it inline wouldn't make the review easier. I will
> submit a patch
> gathering my workand those of the reviewers soon.
Thanks, it will really help. If the patch is very long, you could split
it into more patches for the review purpose, maybe relying on the
semantic fields. Regardless you split it or not, inline patches are the
good way to contribute here.
Side note : you _must_ have the signed-off-by from Thomas if you want to
use his work.
Oh, and please, submit the new version in this thread.
> > I disagree here. Words like "diff", "commit", "patch", etc should be
> > kept as is. Translation of those terms make things harder for the users.
>
> I agree with you when those terms refers to _commands_ names, but the
> main goal of a
> translation is to _translate_ and we have to make the best effort to
> use french word if they _exist_
I don't think so. Here is _why_: the user-frienliness of a translated
software comes from "how hard is it to connect a word with the
underlying concept".
IOW, we want to have good words to refer to the _concepts_. In the
computer science world (and more _specially_ for a SCM), those concepts
are much more well-known with the english terms. Keeping english words
help users to directly understand what it is about, without making the
users have to search for "what the fucking translators are refering to
here?".
> and _are_ appropriate (that's why I'm not sure about translate
> "cherry-pick" by "ceullir").
I don't have strong opinion for this one because :
- the translation is good enough to be directly understood ;
- where "cueillir" (or so) is used, we have the fallback to the english
term between round brackets.
> I prefer to translate "Diff this -> selected" by "Différence entre ça
> et selection"
> because it is what the user do when he make a diff.
Looks ok to me, except that "Diff" is better than "Différence" for the
reason I give above. A "diff" is clearly about a _patch_ where
"différence" may be used to much more concepts. French people don't use
the word "différence" to talk about a diff, they use "diff" as is.
> because it is what the user do when he make a diff. I am also ok to
> translate "merge" by "fusion"
> because it's what "merge" is in french and I don't this we mislead the
> user by using the term
> "fusion".
I don't have a strong opinion on this because both english and french
words are known. That said, I tend to think that the english word is
better here too.
--
Nicolas Sebrecht
^ permalink raw reply
* [PATCH] Add intermediate build products to .gitignore
From: Jonathan Nieder @ 2009-11-08 22:07 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Chris Johnsen
In-Reply-To: <7vvdhkdect.fsf@alter.siamese.dyndns.org>
Temporaries such as configure.ac+ and Documentation/*.xml+
sometimes remain after an interrupted build. Tell git not to
track them.
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
---
Junio C Hamano wrote:
> Jonathan Nieder <jrnieder@gmail.com> writes:
>> Some of these files appeared in the "git status" output after an
>> interrupted build. I hope I caught them all.
>
> Thanks; I think "*+" would suffice, though.
That’s much better. Here’s an updated patch.
.gitignore | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/.gitignore b/.gitignore
index 51a37b1..f0d2e96 100644
--- a/.gitignore
+++ b/.gitignore
@@ -168,6 +168,7 @@ git.spec
*.exe
*.[aos]
*.py[co]
+*+
config.mak
autom4te.cache
config.cache
--
1.6.5.2
^ permalink raw reply related
* Re: [RFC/PATCH 4/4] Re-implement 'git remote update' using 'git fetch'
From: Björn Gustavsson @ 2009-11-08 22:23 UTC (permalink / raw)
To: Paolo Bonzini; +Cc: git, Junio C Hamano
In-Reply-To: <hd7c4k$aul$3@ger.gmane.org>
On Sun, Nov 8, 2009 at 10:10 PM, Paolo Bonzini <bonzini@gnu.org> wrote:
> On 11/08/2009 04:48 PM, Björn Gustavsson wrote:
>> There is one incompatibility: the skipDefaultUpdate configuration
>> variable will only be honored if remotes.default is not set (i.e.
>> when 'git remote update' will invoke 'git fetch --all', not when
>> it will invoke 'git fetch default').
>
> Rather than introducing this incompatibility, I'd rather see 'git remote
> update' deprecated (so that the code will one day go away for good) and, for
> now, leave duplicated functionality for the incompatible case.
I didn't check my facts properly before writing that commit message.
Looking again at the old code in builtin_remote.c (after a long break), and
actually testing the behavior, I see that there is no incompatibility.
Both the old and the new code use skipDefaultUpdate only if remotes.default
is not set. If remotes.default is set, that list of remotes will be used. Only
if remotes.default is not set, will 'git remote update' go through the list
of all remotes and filter away those that have skipDefaultUpdate set to true.
Sorry for the confusion. I will correct the commit message in my re-roll
of the patch.
--
Björn Gustavsson, Erlang/OTP, Ericsson AB
^ permalink raw reply
* Strange behavior (possible bug) using bash command subsitution with "git branch"
From: Kate Ebneter @ 2009-11-08 22:11 UTC (permalink / raw)
To: git
Hi, folks,
I ran into a weird situation while working on a script, which is best
described with a little snippet from my gitosis-admin repository:
$ git branch
* master
$ branch=$(git branch)
$ echo $branch
gitosis.conf keydir master
That is, if you run 'git branch' inside $() or ``, it lists the directories,
too. I can't imagine that this is intended behavior, but perhaps I'm wrong.
I can reproduce this on CentOS, Ubuntu, Solaris, and Mac OS X using git
1.6.2.3, 1.6.3.2, 1.6.3.3, 1.6.4.2, and 1.6.5.2.
(In the end, I figured out a better way to write my script anyway, but this
is just too weird not to ask about.)
Thanks,
Kate Ebneter
Somewhat befuddled build engineer
^ permalink raw reply
* Re: Strange behavior (possible bug) using bash command subsitution with "git branch"
From: Sverre Rabbelier @ 2009-11-08 22:46 UTC (permalink / raw)
To: Kate Ebneter; +Cc: git
In-Reply-To: <C71C822C.22429%kate@ning.com>
Heya
On Sun, Nov 8, 2009 at 23:11, Kate Ebneter <kate@ning.com> wrote:
> That is, if you run 'git branch' inside $() or ``, it lists the directories,
> too. I can't imagine that this is intended behavior, but perhaps I'm wrong.
Try enclosing it in quotes ;).
That is, compare:
$ echo "`git branch`"
with
$ echo `git branch`
The kicker is that there's a * in the output of git branch, which your
shell helpfully substitutes with the contents of your current
directory :).
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* Re: Strange behavior (possible bug) using bash command subsitution with "git branch"
From: Björn Steinbrink @ 2009-11-08 22:49 UTC (permalink / raw)
To: Kate Ebneter; +Cc: git
In-Reply-To: <C71C822C.22429%kate@ning.com>
On 2009.11.08 14:11:56 -0800, Kate Ebneter wrote:
> Hi, folks,
>
> I ran into a weird situation while working on a script, which is best
> described with a little snippet from my gitosis-admin repository:
>
> $ git branch
> * master
^^^
> $ branch=$(git branch)
> $ echo $branch
> gitosis.conf keydir master
Your shell expands the *, thus echo sees all the things in the current
directory. Use 'echo "$branch"' and you'll see what you expected.
Björn
^ permalink raw reply
* Re: Strange behavior (possible bug) using bash command subsitution with "git branch"
From: Kate Ebneter @ 2009-11-08 22:50 UTC (permalink / raw)
To: Sverre Rabbelier; +Cc: git
In-Reply-To: <fabb9a1e0911081446o7793eef1kcbad964c9a73edda@mail.gmail.com>
On 11/8/09 2:46 PM, "Sverre Rabbelier" <srabbelier@gmail.com> wrote:
> Heya
>
> On Sun, Nov 8, 2009 at 23:11, Kate Ebneter <kate@ning.com> wrote:
>> That is, if you run 'git branch' inside $() or ``, it lists the directories,
>> too. I can't imagine that this is intended behavior, but perhaps I'm wrong.
>
> Try enclosing it in quotes ;).
>
> That is, compare:
> $ echo "`git branch`"
> with
> $ echo `git branch`
>
> The kicker is that there's a * in the output of git branch, which your
> shell helpfully substitutes with the contents of your current
> directory :).
*head desk*
You know, I spent hours last night trying to figure that out. So simple.
Duh.
Thanks for pointing that out -- I knew it had to be something simple, but
sometimes you just can't see the forest for the trees! :-)
Thanks again,
Kate Ebneter
^ permalink raw reply
* Re: Strange behavior (possible bug) using bash command subsitution with "git branch"
From: Jeff King @ 2009-11-08 23:03 UTC (permalink / raw)
To: Björn Steinbrink; +Cc: Kate Ebneter, git
In-Reply-To: <20091108224955.GA14095@atjola.homenet>
On Sun, Nov 08, 2009 at 11:49:55PM +0100, Björn Steinbrink wrote:
> > I ran into a weird situation while working on a script, which is best
> > described with a little snippet from my gitosis-admin repository:
> >
> > $ git branch
> > * master
> ^^^
>
> > $ branch=$(git branch)
> > $ echo $branch
> > gitosis.conf keydir master
>
> Your shell expands the *, thus echo sees all the things in the current
> directory. Use 'echo "$branch"' and you'll see what you expected.
And more to the point, this is just one reason why one should use
for-each-ref when scripting (the other is that git-branch's output is
considered porcelain, and is not guaranteed to remain stable). E.g.:
git for-each-ref --format='%(refname:short)' refs/heads/
would produce the output the original poster wanted.
-Peff
^ permalink raw reply
* Re: [PATCH 4/4] format-patch: Add "--no-stat" as a synonym for "-p"
From: Stephen Boyd @ 2009-11-08 23:11 UTC (permalink / raw)
To: Björn Gustavsson; +Cc: git, Junio C Hamano
In-Reply-To: <4AF544DF.6070404@gmail.com>
On Sat, 2009-11-07 at 10:58 +0100, Björn Gustavsson wrote:
> diff --git a/builtin-log.c b/builtin-log.c
> index 9df8dac..968a038 100644
> --- a/builtin-log.c
> +++ b/builtin-log.c
> @@ -925,7 +925,7 @@ int cmd_format_patch(int argc, const char **argv, const char *prefix)
> "show patch format instead of default (patch + stat)"),
> OPT_BOOLEAN(0, "ignore-if-in-upstream", &ignore_if_in_upstream,
> "don't include a patch matching a commit upstream"),
> - OPT_BOOLEAN('p', NULL, &use_patch_format,
> + OPT_BOOLEAN('p', "no-stat", &use_patch_format,
> "show patch format instead of default (patch + stat)"),
> OPT_GROUP("Messaging"),
> { OPTION_CALLBACK, 0, "add-header", NULL, "header",
I think this needs to have the OPT_NO_NEG flag so users can't say
--no-no-stat.
^ permalink raw reply
* Re: gitk : french translation
From: Maximilien Noal @ 2009-11-08 23:11 UTC (permalink / raw)
To: Nicolas Sebrecht; +Cc: Emmanuel Trillaud, Thomas Moulard, Git Mailing List
In-Reply-To: <20091108214130.GA12931@vidovic>
Nicolas Sebrecht wrote :
>>> I disagree here. Words like "diff", "commit", "patch", etc should be
>>> kept as is. Translation of those terms make things harder for the users.
>> I agree with you when those terms refers to _commands_ names, but the
>> main goal of a
>> translation is to _translate_ and we have to make the best effort to
>> use french word if they _exist_
>
> I don't think so. Here is _why_: the user-frienliness of a translated
> software comes from "how hard is it to connect a word with the
> underlying concept".
>
> IOW, we want to have good words to refer to the _concepts_. In the
> computer science world (and more _specially_ for a SCM), those concepts
> are much more well-known with the english terms. Keeping english words
> help users to directly understand what it is about, without making the
> users have to search for "what the fucking translators are refering to
> here?".
Why not put the translation first, then the english word between () ?
At least for English words above that are not used by French devs "as
is" (not like "diff") ?
That way, newbies to SCMs' concepts get the idea, and old SCM users
don't have to translate back.
But if it isn't done _everywhere_ (and not used anywhere for words we
don't want to translate because there's no need or no good translation,
like "diff" for the first case, and "patch" for the second one), it will
make the situation worse.
Just my two cents.
^ permalink raw reply
* Re: gitk : french translation
From: Maximilien Noal @ 2009-11-08 23:15 UTC (permalink / raw)
To: Nicolas Sebrecht; +Cc: Emmanuel Trillaud, Thomas Moulard, Git Mailing List
In-Reply-To: <4AF7502A.9020903@gmail.com>
Maximilien Noal a écrit :
> Nicolas Sebrecht wrote :
>>>> I disagree here. Words like "diff", "commit", "patch", etc should be
>>>> kept as is. Translation of those terms make things harder for the
>>>> users.
>>> I agree with you when those terms refers to _commands_ names, but the
>>> main goal of a
>>> translation is to _translate_ and we have to make the best effort to
>>> use french word if they _exist_
>>
>> I don't think so. Here is _why_: the user-frienliness of a translated
>> software comes from "how hard is it to connect a word with the
>> underlying concept".
>>
>> IOW, we want to have good words to refer to the _concepts_. In the
>> computer science world (and more _specially_ for a SCM), those concepts
>> are much more well-known with the english terms. Keeping english words
>> help users to directly understand what it is about, without making the
>> users have to search for "what the fucking translators are refering to
>> here?".
> Why not put the translation first, then the english word between () ?
> At least for English words above that are not used by French devs "as
> is" (not like "diff") ?
>
> That way, newbies to SCMs' concepts get the idea, and old SCM users
> don't have to translate back.
>
> But if it isn't done _everywhere_ (and not used anywhere for words we
> don't want to translate because there's no need or no good translation,
> like "diff" for the first case, and "patch" for the second one), it will
> make the situation worse.
>
> Just my two cents.
I had in mind a man page when I wrote this, not gitk! Oh well.. Instead
of "French Translated Word (<English Word>)" idea, may be the tooltip
text (the text that pops up on a mouse over a control) can be used when
there is no pixel space left in the UI for the extra (<English Word>) text.
^ permalink raw reply
* Re: Strange behavior (possible bug) using bash command subsitution with "git branch"
From: Kate Ebneter @ 2009-11-08 23:10 UTC (permalink / raw)
To: Jeff King, Björn Steinbrink; +Cc: git
In-Reply-To: <20091108230300.GB17129@coredump.intra.peff.net>
On 11/8/09 3:03 PM, "Jeff King" <peff@peff.net> wrote:
> On Sun, Nov 08, 2009 at 11:49:55PM +0100, Björn Steinbrink wrote:
>
>>> I ran into a weird situation while working on a script, which is best
>>> described with a little snippet from my gitosis-admin repository:
>>>
>>> $ git branch
>>> * master
>> ^^^
>>
>>> $ branch=$(git branch)
>>> $ echo $branch
>>> gitosis.conf keydir master
>>
>> Your shell expands the *, thus echo sees all the things in the current
>> directory. Use 'echo "$branch"' and you'll see what you expected.
>
> And more to the point, this is just one reason why one should use
> for-each-ref when scripting (the other is that git-branch's output is
> considered porcelain, and is not guaranteed to remain stable). E.g.:
>
> git for-each-ref --format='%(refname:short)' refs/heads/
>
> would produce the output the original poster wanted.
Ah, sweet, I did not know about that. I ended up doing something entirely
different (short form: my original idea about what I wanted to do was wrong)
but that's very helpful for the future.
Thanks,
Kate Ebneter (who is gradually learning more and more about git)
^ permalink raw reply
* Re: [RFC/PATCH 4/4] Re-implement 'git remote update' using 'git fetch'
From: Jay Soffian @ 2009-11-09 0:43 UTC (permalink / raw)
To: Björn Gustavsson, Junio C Hamano; +Cc: git
In-Reply-To: <4AF6E865.1030900@gmail.com>
2009/11/8 Björn Gustavsson <bgustavsson@gmail.com>:
> In order to not duplicate functionality, re-implement 'git remote
> update' in terms of 'git fetch'.
Junio, I guess I'll wait for this to hit pu and then rebase my fetch
--prune changes on top of it?
j.
^ permalink raw reply
* Re: [RFC/PATCH 2/4] Teach the --multiple option to 'git fetch'
From: Jay Soffian @ 2009-11-09 0:59 UTC (permalink / raw)
To: Björn Gustavsson; +Cc: git, Junio C Hamano
In-Reply-To: <4AF6E7DE.1020201@gmail.com>
2009/11/8 Björn Gustavsson <bgustavsson@gmail.com>:
> Add the --multiple option to specify that all arguments are either
> groups or remotes. The primary reason for adding this option is
> to allow us to re-implement 'git remote update' using fetch.
Can't this be determined automagically by inspecting the arguments? I
believe there can be two unambiguous usages:
a) git fetch <repository> <refspec>...
b) git fetch <repository>...
If there is more than one argument, either:
a) arguments 2...N must be refpecs (i.e., each must contain a colon)
b) arguments 2...N must NOT be refspecs
"The format of a <refspec> parameter is an optional plus +, followed
by the source ref <src>, followed by a colon :, followed by the
destination ref <dst>."
j.
^ permalink raw reply
* Re: [RFC/PATCH 2/4] Teach the --multiple option to 'git fetch'
From: Jeff King @ 2009-11-09 1:08 UTC (permalink / raw)
To: Jay Soffian; +Cc: Björn Gustavsson, git, Junio C Hamano
In-Reply-To: <76718490911081659u318ea362l29342a9b3d90f03f@mail.gmail.com>
On Sun, Nov 08, 2009 at 07:59:46PM -0500, Jay Soffian wrote:
> 2009/11/8 Björn Gustavsson <bgustavsson@gmail.com>:
> > Add the --multiple option to specify that all arguments are either
> > groups or remotes. The primary reason for adding this option is
> > to allow us to re-implement 'git remote update' using fetch.
>
> Can't this be determined automagically by inspecting the arguments? I
> believe there can be two unambiguous usages:
> [...]
> "The format of a <refspec> parameter is an optional plus +, followed
> by the source ref <src>, followed by a colon :, followed by the
> destination ref <dst>."
Isn't the colon optional, indicating that the ref should be fetched into
FETCH_HEAD? I.e.,
$ git fetch origin pu
From git://git2.kernel.org/pub/scm/git/git
* branch pu -> FETCH_HEAD
?
-Peff
^ 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