* Re: [user] git-svn and svn cp
From: Benoit Sigoure @ 2007-11-19 14:04 UTC (permalink / raw)
To: Matthieu Moy; +Cc: gerhard.oettl.ml, David Kastrup, Git Mailing List
In-Reply-To: <vpqtzni1h17.fsf@bauges.imag.fr>
[-- Attachment #1: Type: text/plain, Size: 1651 bytes --]
On Nov 19, 2007, at 2:49 PM, Matthieu Moy wrote:
> Benoit Sigoure <tsuna@lrde.epita.fr> writes:
>
>>> Not in the details. Well, I believe the accurate question (to
>>> original
>>> poster) is: does your svn repository use the standard svn layout
>>> (tags/, branches/, trunk/)?
>>
>> I think this is irrelevant to the question he asked.
>
> Well, I'm far enough from being a git-svn expert, but I suppose
> git-svn will special-case the content of tags/ and branches/
> directories, and consider copies there to be tags and branches. I
> don't know whether git-svn does it efficiently, though.
>
> If you use "svn copy" with the meaning "create a tag" with a
> destination other than tags/ directory, then, git-svn can not guess it
> was actually a tag.
No, git-svn only needs to know where to look for branches and tags so
that it can replicate them on the Git side by creating remote
branches. It has nothing to do with the fact that a tag or a branch
happen to be a copy of something else (which isn't necessarily true,
I can perfectly create a tag out of the blue which has its own unique
content, same thing for branches).
The question of Gerhard was thus, why do we need to transfer "so
much" data over the network when we should be able to guess that the
data is already in the Git repo (because git-svn can figure out that
something is a copy of something else -- because SVN records this
information -- and thus save the network from downloading useless
deltas). It's possible that the code can be optimized to handle
this, or so I guess.
--
Benoit Sigoure aka Tsuna
EPITA Research and Development Laboratory
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 186 bytes --]
^ permalink raw reply
* Re: preserving mtime
From: Johannes Schindelin @ 2007-11-19 14:38 UTC (permalink / raw)
To: Wayne Davison; +Cc: Andreas Ericsson, git
In-Reply-To: <20071117182236.GD23659@blorf.net>
Hi,
On Sat, 17 Nov 2007, Wayne Davison wrote:
> On Fri, Nov 16, 2007 at 11:15:34AM +0100, Andreas Ericsson wrote:
> >> is it possible to tell git to preserve the file modification time in
> >> a checked out copy?
>
> > Fabrizio Pollastri wrote:
> > No. Doing so would seriously break build-systems.
>
> I wish that the initial clone would set the modification time to the
> commit time.
Could you stop this discussion, please? This subject comes up every once
in a while, and in the meantime the archives contain more sane
explanations why this would be a bad behaviour of git than I could tell
off of my head.
So no, this is not a sane behaviour.
If you _must_ inist on this behaviour, write your own hook, don't tell
anybody about it, especially not when things break.
Hth,
Dscho
^ permalink raw reply
* Re: Git in a Nutshell guide
From: Jonas Juselius @ 2007-11-19 14:33 UTC (permalink / raw)
To: git
In-Reply-To: <fhs33j$eg9$1@ger.gmane.org>
Jakub Narebski <jnareb <at> gmail.com> writes:
>
> A few comments (from what I checked so far):
>
> 1. It is "man git-checkout" (or "git checkout --help"),
> not "man git checkout"
>
> 2. Instead of using 'verbatim' environment directly to show example CLI
> session it would be I think better to define verbatim-like environment
> for this ('example', 'commands', 'CLI', 'session'); perhaps replacing
> verbatim by lstlisting from the listings/lstlisting package for syntax
> highlighting.
>
First, it seems that it was not entirely clear to everybody that it's possible
to clone the repository:
git clone http://git.jonas.iki.fi/git_guides.git
Thanks for the comments:
1. I did a global subst from the git-command to git
command instead form, and forgot about the man pages ;)
2. You are entirely right of course, but I was a bit lazy. I'll fix it at some
point. lstlistings is a very nice package.
^ permalink raw reply
* [RFC/PATCH] gitweb: Try to sanitize mimetype for 'blob_plain' view
From: Jakub Narebski @ 2007-11-19 14:54 UTC (permalink / raw)
To: git; +Cc: Jakub Narebski
Use 'text/plain' for files which are text and can be viewed in a
browser, and are not among a few 'text/*' mimetypes universally
recognized by web browsers. This means files with 'text/*' which are
not text/html, text/css, text/sgml or text/xml, and files with
'application/x-*' mimetype which are nevertheless text: javascript,
shell, Perl, Tcl, (La)TeX,...
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
---
Tired of my web browser (Mozilla) asking me what I want to do with
shell script, Perl script or LaTeX document when using 'blob_plain'
(raw) view, because of declaration in mimetypes file I have added
mimetype sanitizing to gitweb.
It is an RFC partially because list of mimetypes is a bit
arbitrary. Additionally I guess that the mimetype sanitizing should be
separated into subroutine.
But most of all beause proper solution is to create mimetype file for
use by gitweb.
gitweb/gitweb.perl | 23 ++++++++++++++++++++++-
1 files changed, 22 insertions(+), 1 deletions(-)
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index 491a3f4..1cfe293 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -2366,7 +2366,28 @@ sub blob_mimetype {
if ($filename) {
my $mime = mimetype_guess($filename);
- $mime and return $mime;
+
+ if ($mime) {
+ # try to sanitize mimetype
+
+ # return text/plain on unknown text/* mimetype
+ if ($mime =~ m!^text/! &&
+ $mime !~ m!^text/(?:html|css|sgml|xml)$!) {
+ return 'text/plain' .
+ ($default_text_plain_charset ?
+ '; charset='.$default_text_plain_charset : '');
+ }
+ # return text/plain for known programming languages and like
+ if ($mime =~ m!^application/x-(?:
+ javascript|csshell|shell|csh|perl|
+ sh|shar|tcl|latex|tex|texinfo)!x) {
+ return 'text/plain' .
+ ($default_text_plain_charset ?
+ '; charset='.$default_text_plain_charset : '');
+ }
+ # otherwise return mimetype found in mimetypes file(s)
+ return $mime;
+ }
}
# just in case
--
1.5.3.5
^ permalink raw reply related
* Re: Git in a Nutshell guide
From: Brian Downing @ 2007-11-19 15:02 UTC (permalink / raw)
To: Jonas Juselius; +Cc: git
In-Reply-To: <1195477504.8093.15.camel@localhost>
On Mon, Nov 19, 2007 at 02:05:04PM +0100, Jonas Juselius wrote:
> I have also written a CVS2git transition guide, which outlines one
> possible way of converting from CVS to git.
You write:
> In order to save space you can also enable compression
> $ git config --global core.compression 1
> $ git config --global core.loosecompression 1
I think this contradicts the git-config manpage:
> core.compression
> An integer -1..9, indicating a default compression level. -1 is the
> zlib default. 0 means no compression, and 1..9 are various
> speed/size tradeoffs, 9 being slowest.
> core.loosecompression
> An integer -1..9, indicating the compression level for objects that
> are not in a pack file. -1 is the zlib default. 0 means no
> compression, and 1..9 are various speed/size tradeoffs, 9 being
> slowest. If not set, defaults to core.compression. If that is not
> set, defaults to 0 (best speed).
The default, -1, is the zlib default, which is probably something like 3-6.
Setting these to 1 will probably result in less compression, not more.
-bcd
^ permalink raw reply
* Re: Git in a Nutshell guide
From: Brian Downing @ 2007-11-19 15:03 UTC (permalink / raw)
To: Jonas Juselius; +Cc: git
In-Reply-To: <20071119150209.GF6212@lavos.net>
On Mon, Nov 19, 2007 at 09:02:09AM -0600, Brian Downing wrote:
> The default, -1, is the zlib default, which is probably something like 3-6.
> Setting these to 1 will probably result in less compression, not more.
It's 6:
> Z_DEFAULT_COMPRESSION requests a default compromise between speed and
> compression (currently equivalent to level 6).
-bcd
^ permalink raw reply
* Re: [PATCH 1/2] gitweb: Style all tables using CSS
From: Jakub Narebski @ 2007-11-19 15:08 UTC (permalink / raw)
To: Bernt Hansen; +Cc: git
In-Reply-To: <87d4u671kx.fsf@gollum.intra.norang.ca>
Bernt Hansen wrote:
> Jakub Narebski <jnareb@gmail.com> writes:
>
> > - print "<table cellspacing=\"0\">\n" .
> > + print "<table class=\"projects_list\">\n" .
>
> Should this class be "project_list" instead? I don't see a definition
> of "projects_list" (plural) anywhere.
Now that you mentioned it, I have checked and... we have a bit of
inconsistency in gitweb here. There are $projects_list and
$projects_list_description_width variables (plural),
git_get_projects_list subroutine (also plural), but view is called
'project_list', it is generated by git_project_list subroutine using
git_get_project_list_from_file and git_project_lis_body subroutines.
I am not native English speaker: gitweb mean here "list of projects".
We should probably uniqueify number to either plural or singular, and
not mixed as it is now. But this is a bit of nitpicking/paintshed...
Changing action name from 'project_list' would be hard because of
backward compatibility... _if_ we officially used this action; it is
default action when no project is selected, and all links use this
form.
--
Jakub Narebski
Poland
^ permalink raw reply
* [PATCH] config: correct and clarify core.*compression documentation
From: Brian Downing @ 2007-11-19 15:28 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Jonas Juselius
* core.loosecompression stated that the default was "0 (best speed)",
when in fact 0 is "no compression", and the default is Z_BEST_SPEED,
which is 1.
* Explain that the default of core.compression is -1, zlib default, and
add a quote from zlib.h explaining what that actually means.
---
applies to 'maint'; unfortunately I just noticed 1.5.3.6 went out.
Documentation/config.txt | 5 ++++-
1 files changed, 4 insertions(+), 1 deletions(-)
diff --git a/Documentation/config.txt b/Documentation/config.txt
index 7ee97df..d62a72b 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -226,13 +226,16 @@ core.compression::
An integer -1..9, indicating a default compression level.
-1 is the zlib default. 0 means no compression,
and 1..9 are various speed/size tradeoffs, 9 being slowest.
+ If not set, defaults to -1 (zlib default), which is "a default
+ compromise between speed and compression (currently equivalent
+ to level 6)."
core.loosecompression::
An integer -1..9, indicating the compression level for objects that
are not in a pack file. -1 is the zlib default. 0 means no
compression, and 1..9 are various speed/size tradeoffs, 9 being
slowest. If not set, defaults to core.compression. If that is
- not set, defaults to 0 (best speed).
+ not set, defaults to 1 (best speed).
core.packedGitWindowSize::
Number of bytes of a pack file to map into memory in a
--
1.5.3.5.1824.g5f389
^ permalink raw reply related
* Re: [PATCH 1/2] gitweb: Style all tables using CSS
From: Bernt Hansen @ 2007-11-19 14:27 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <1195478172-17226-2-git-send-email-jnareb@gmail.com>
Jakub Narebski <jnareb@gmail.com> writes:
> - print "<table cellspacing=\"0\">\n" .
> + print "<table class=\"projects_list\">\n" .
Should this class be "project_list" instead? I don't see a definition
of "projects_list" (plural) anywhere.
Bernt
^ permalink raw reply
* Re: Git in a Nutshell guide
From: Nicolas Pitre @ 2007-11-19 15:48 UTC (permalink / raw)
To: Brian Downing; +Cc: Jonas Juselius, git
In-Reply-To: <20071119150209.GF6212@lavos.net>
On Mon, 19 Nov 2007, Brian Downing wrote:
> On Mon, Nov 19, 2007 at 02:05:04PM +0100, Jonas Juselius wrote:
> > I have also written a CVS2git transition guide, which outlines one
> > possible way of converting from CVS to git.
>
> You write:
>
> > In order to save space you can also enable compression
> > $ git config --global core.compression 1
> > $ git config --global core.loosecompression 1
>
> I think this contradicts the git-config manpage:
Also, compression is always enabled by default with the adequate setting
for most usages anyway, so I think it is probably best not to talk about
those settings at all in a nutshell guide.
Nicolas
^ permalink raw reply
* Re: [PATCH] config: correct and clarify core.*compression documentation
From: Nicolas Pitre @ 2007-11-19 15:51 UTC (permalink / raw)
To: Brian Downing; +Cc: Junio C Hamano, git, Jonas Juselius
In-Reply-To: <20071119152853.GH6212@lavos.net>
On Mon, 19 Nov 2007, Brian Downing wrote:
> * core.loosecompression stated that the default was "0 (best speed)",
> when in fact 0 is "no compression", and the default is Z_BEST_SPEED,
> which is 1.
Right.
> * Explain that the default of core.compression is -1, zlib default, and
> add a quote from zlib.h explaining what that actually means.
No, this is wrong. core.compression has no default. It is meaningful
only when an explicit value is configured.
Nicolas
^ permalink raw reply
* Re: Git in a Nutshell guide
From: Jakub Narebski @ 2007-11-19 16:05 UTC (permalink / raw)
To: git
In-Reply-To: <1195477504.8093.15.camel@localhost>
Jonas Juselius wrote:
> The guides, including the LaTeX source, are available via gitweb:
> http://git.jonas.iki.fi/gitweb.cgi?p=git_guides.git;a=summary
By the way, the description of this repository (for gitweb) is
"CVS to git migration guide", the same as for CVS2git.git
(shouldn't it be CVS2git_guide.git?).
> First, it seems that it was not entirely clear to everybody that
> it's possible to clone the repository:
>
> git clone http://git.jonas.iki.fi/git_guides.git
Thanks.
Perhaps you should have make gitweb.cgi with
GITWEB_BASE_URL="http://git.jonas.iki.fi"
then, or configure @git_base_url_list in gitweb_config.perl.
Do I understand correctly that you don't support cloning via git://
protocol?
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: Git in a Nutshell guide
From: Jonas Juselius @ 2007-11-19 16:14 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <fhsc7b$k4g$1@ger.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 896 bytes --]
On Mon, 2007-11-19 at 17:05 +0100, Jakub Narebski wrote:
> By the way, the description of this repository (for gitweb) is
> "CVS to git migration guide", the same as for CVS2git.git
> (shouldn't it be CVS2git_guide.git?).
Well, it's the same repository. When I started out, I only planned to
write the CVS2git manual. Then I wrote the Nutshell guide, and changed
the name of the repo, but I had already given the link to a bunch of
people so I kept the link.
>
> Perhaps you should have make gitweb.cgi with
> GITWEB_BASE_URL="http://git.jonas.iki.fi"
> then, or configure @git_base_url_list in gitweb_config.perl.
>
I'll look into that :)
> Do I understand correctly that you don't support cloning via git://
> protocol?
Yes, that is correct. The machine is behind a number of firewalls, and I
simply cannot be bothered to go through the bureaucracy...
.j.
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH] config: correct and clarify core.*compression documentation
From: Brian Downing @ 2007-11-19 16:23 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: Junio C Hamano, git, Jonas Juselius
In-Reply-To: <alpine.LFD.0.99999.0711191049440.19105@xanadu.home>
On Mon, Nov 19, 2007 at 10:51:31AM -0500, Nicolas Pitre wrote:
> > * Explain that the default of core.compression is -1, zlib default, and
> > add a quote from zlib.h explaining what that actually means.
>
> No, this is wrong. core.compression has no default. It is meaningful
> only when an explicit value is configured.
Would you prefer this?
If not set, packs will be compressed to the zlib default level,
which is "a default compromise between speed and compression
(currently equivalent to level 6)."
I'm trying to make it reassuring as to the fact that, "yes, packs are
compressed plenty, you really don't need to mess with this unless you
want to." As it stands I could see the potential confusion that no
(or poor) compression will occur in packs unless this is set.
-bcd
^ permalink raw reply
* Re: [user] git-svn and svn cp
From: Eric Wong @ 2007-11-19 16:26 UTC (permalink / raw)
To: gerhard.oettl.ml; +Cc: git
In-Reply-To: <47416F68.9070908@ogersoft.at>
gerhard.oettl.ml@ogersoft.at wrote:
> I hope this is the correct mailing list. If not please point me in the
> right direction.
>
>
> I played a little with git (1.5.3.4 / debian) and had the following
> observation:
> Doing a "svn cp" (for example for a tag) results in a large traffic when
> doing a "git-svn fetch" afterwards.
>
> To verify I did:
> git-svn clone -s svn://www.ogersoft.at/ogerlit
> git-svn fetch
> svn cp svn://... svn://... (one file ca 3mb)
> svk checkout (a tcpflow output of about 3k - plaintext commands, I think
> a svn checkout would be the same)
> git-svn fetch (a tcpflow output of 700k - containing a textdelta of
> nearly 700k)
>
>
> So the question remains:
> Does svn-git dont know about lightweight svn copies?
> or can svn-git not handle them correct by now?
> or did I something wrong?
Older versions of the Perl SVN bindings have a broken do_switch()
function, so I fall back to the do_update() function which re-downloads
the whole tree instead..
SVN 1.4.4+ has this fix which allows do_switch() to be used instead of
do_update().
do_switch() will only download the delta between two trees if the parent
is present.
If you don't have easy access to 1.4.4+ packages, I have patched 1.4.3
(x86) packages here for Debian Etch (I haven't built 1.4.4 or 1.4.5 yet):
http://git-svn.yhbt.net/svn/
--
Eric Wong
^ permalink raw reply
* Re: [PATCH] config: correct and clarify core.*compression documentation
From: Nicolas Pitre @ 2007-11-19 16:43 UTC (permalink / raw)
To: Brian Downing; +Cc: Junio C Hamano, git, Jonas Juselius
In-Reply-To: <20071119162307.GI6212@lavos.net>
On Mon, 19 Nov 2007, Brian Downing wrote:
> On Mon, Nov 19, 2007 at 10:51:31AM -0500, Nicolas Pitre wrote:
> > > * Explain that the default of core.compression is -1, zlib default, and
> > > add a quote from zlib.h explaining what that actually means.
> >
> > No, this is wrong. core.compression has no default. It is meaningful
> > only when an explicit value is configured.
>
> Would you prefer this?
>
> If not set, packs will be compressed to the zlib default level,
> which is "a default compromise between speed and compression
> (currently equivalent to level 6)."
This is still rather incorrect. If you want to be thorough, you should
say that this setting provides a global default for pack.compression and
core.loosecompression when those settings are not set. Otherwise
pack.compression and core.loosecompression have a default of their own
when neither is set.
Nicolas
^ permalink raw reply
* Re: Git in a Nutshell guide
From: Lars Hjemli @ 2007-11-19 16:45 UTC (permalink / raw)
To: Jonas Juselius; +Cc: git
In-Reply-To: <1195477504.8093.15.camel@localhost>
On Nov 19, 2007 2:05 PM, Jonas Juselius <jonas.juselius@chem.uit.no> wrote:
> All comments
> and suggestions are welcome!
Very nice introduction, but I have a couple of comments.
In "Specifying revisions" you say that '^' and '~' are equal, but that
is not true. ^ is used to select the first parent of a commit, ^2
selects the second parent of a merge commit (and ^3 selects the third
parent of an octopus merge), while the '~' is used to go back any
number of generations, following the first parents of each commit (~
selects the first parent, ~2 selects the first grand-parent etc).
Also, I think you might scare users away from 'git reset':
git reset resets the branch to a specified state invisibly and
without possibility to go back. Ever. Your call.
That's not true, since any "modern" git has reflogs enabled. If you do
'git reset --hard HEAD^^^' and then realize it was a mistake you can
just 'git reset --hard HEAD@{1}'
--
larsh
^ permalink raw reply
* Re: [PATCH] config: correct and clarify core.*compression documentation
From: Brian Downing @ 2007-11-19 16:46 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: Junio C Hamano, git, Jonas Juselius
In-Reply-To: <alpine.LFD.0.99999.0711191139240.19105@xanadu.home>
On Mon, Nov 19, 2007 at 11:43:56AM -0500, Nicolas Pitre wrote:
> On Mon, 19 Nov 2007, Brian Downing wrote:
> > On Mon, Nov 19, 2007 at 10:51:31AM -0500, Nicolas Pitre wrote:
> > > > * Explain that the default of core.compression is -1, zlib default, and
> > > > add a quote from zlib.h explaining what that actually means.
> > >
> > > No, this is wrong. core.compression has no default. It is meaningful
> > > only when an explicit value is configured.
> >
> > Would you prefer this?
> >
> > If not set, packs will be compressed to the zlib default level,
> > which is "a default compromise between speed and compression
> > (currently equivalent to level 6)."
>
> This is still rather incorrect. If you want to be thorough, you should
> say that this setting provides a global default for pack.compression and
> core.loosecompression when those settings are not set. Otherwise
> pack.compression and core.loosecompression have a default of their own
> when neither is set.
Okay, thanks. (See, I didn't know this either! :) I'll try to work
with that...
-bcd
^ permalink raw reply
* Re: Git in a Nutshell guide
From: Benoit Sigoure @ 2007-11-19 16:49 UTC (permalink / raw)
To: Jonas Juselius; +Cc: Git Mailing List
In-Reply-To: <1195488877.10573.29.camel@localhost>
[-- Attachment #1: Type: text/plain, Size: 2155 bytes --]
On Nov 19, 2007, at 5:14 PM, Jonas Juselius wrote:
> On Mon, 2007-11-19 at 17:05 +0100, Jakub Narebski wrote:
>> Do I understand correctly that you don't support cloning via git://
>> protocol?
>
> Yes, that is correct. The machine is behind a number of firewalls,
> and I
> simply cannot be bothered to go through the bureaucracy...
You can create a repository on repo.or.cz then :)
As it is often the case different people happen to work on similar
things without knowing each other. I started http://repo.or.cz/w/
tutorial.git which is meant to be a big Beamer presentation that
presents Git thoroughly. I wrote some ideas but didn't start to
write the slides. Just in case you want to have a look.
One of the things you said in your guide is that Git is easy to
learn. I think this is wrong. Git is way more complicated than most
other SCMs, especially compared to SVN. Its documentation is far
behind, compared to what other SCMs have. There is no real user
guide and the man pages are incomplete, at best. I know saying this
is a bit harsh, especially to the people out there that are working
and sending patches to improve the documentation, but I think we have
to admit that it's true, even though Git is making progress on this
aspect.
What I hope to achieve, when I'll have time to write my slides, is to
have some sort of equivalent of the wonderful Autotools tutorial
(http://www-src.lip6.fr/homepages/Alexandre.Duret-Lutz/
autotools.html) which is definitely the only thing you need to read
when you want to learn the Autotools (which are also quite
complicated, let's admit it).
Please don't flame me by saying that Git isn't hard to use and
everything. It's the typical reaction of people who know how the
things work. Git is pretty simple to use once you know how it
works. But compared to SVN (for instance) it's hard to learn.
People have to change the way they work to take all the benefits of
Git, and to do this, they have to understand why that new way of
working differently is better for them.
--
Benoit Sigoure aka Tsuna
EPITA Research and Development Laboratory
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 186 bytes --]
^ permalink raw reply
* [PATCH] push: Add "--current", which pushes only the current branch
From: Steffen Prohaska @ 2007-11-19 16:51 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Johannes Schindelin, Steffen Prohaska
In-Reply-To: <3FB7B6E8-FC22-4FDF-BDAD-08312202B29A@zib.de>
Pushing only the current branch to the default remote was awkward
in the past. You needed to remember the default remote and type
"git push $remote $current". A recent commit added support for
"git push $remote HEAD". But still you need to remember and type
the remote.
This commit teaches push a short-cut: "git push --current" now
pushes the current branch to the default remote.
Note, this commit doesn't save you much if you want to push the
current branch to a remote that is not the default: You can now
say either "git push --current foo" or "git push foo HEAD".
Signed-off-by: Steffen Prohaska <prohaska@zib.de>
---
Documentation/git-push.txt | 6 +++++-
builtin-push.c | 14 ++++++++++++--
t/t5516-fetch-push.sh | 25 +++++++++++++++++++++++++
3 files changed, 42 insertions(+), 3 deletions(-)
Eventually, I gave in. I accepted that the default is to push
matching branches. I'll not send further patches that try to
change this. This is the last patch.
The patch applies on top of sp/refspec-match.
Steffen
diff --git a/Documentation/git-push.txt b/Documentation/git-push.txt
index 4a68aab..6ec6078 100644
--- a/Documentation/git-push.txt
+++ b/Documentation/git-push.txt
@@ -9,7 +9,7 @@ git-push - Update remote refs along with associated objects
SYNOPSIS
--------
[verse]
-'git-push' [--all] [--dry-run] [--tags] [--receive-pack=<git-receive-pack>]
+'git-push' [--all] [--current] [--dry-run] [--tags] [--receive-pack=<git-receive-pack>]
[--repo=all] [-f | --force] [-v | --verbose] [<repository> <refspec>...]
DESCRIPTION
@@ -63,6 +63,10 @@ the remote repository.
Instead of naming each ref to push, specifies that all
refs under `$GIT_DIR/refs/heads/` be pushed.
+\--current::
+ Instead of naming each ref to push, specifies that only the
+ current branch is pushed.
+
\--dry-run::
Do everything except actually send the updates.
diff --git a/builtin-push.c b/builtin-push.c
index 54fba0e..c5243ca 100644
--- a/builtin-push.c
+++ b/builtin-push.c
@@ -10,7 +10,7 @@
#include "parse-options.h"
static const char * const push_usage[] = {
- "git-push [--all] [--dry-run] [--tags] [--receive-pack=<git-receive-pack>] [--repo=all] [-f | --force] [-v] [<repository> <refspec>...]",
+ "git-push [--all] [--current] [--dry-run] [--tags] [--receive-pack=<git-receive-pack>] [--repo=all] [-f | --force] [-v] [<repository> <refspec>...]",
NULL,
};
@@ -100,6 +100,7 @@ int cmd_push(int argc, const char **argv, const char *prefix)
{
int flags = 0;
int all = 0;
+ int current = 0;
int dry_run = 0;
int force = 0;
int tags = 0;
@@ -109,6 +110,7 @@ int cmd_push(int argc, const char **argv, const char *prefix)
OPT__VERBOSE(&verbose),
OPT_STRING( 0 , "repo", &repo, "repository", "repository"),
OPT_BOOLEAN( 0 , "all", &all, "push all refs"),
+ OPT_BOOLEAN( 0 , "current", ¤t, "push current branch"),
OPT_BOOLEAN( 0 , "tags", &tags, "push tags"),
OPT_BOOLEAN( 0 , "dry-run", &dry_run, "dry run"),
OPT_BOOLEAN('f', "force", &force, "force updates"),
@@ -135,8 +137,16 @@ int cmd_push(int argc, const char **argv, const char *prefix)
repo = argv[0];
set_refspecs(argv + 1, argc - 1);
}
- if ((flags & TRANSPORT_PUSH_ALL) && refspec)
+ if ((all != 0) + (current != 0) > 1) {
+ fprintf(stderr, "--all and --current are mutual exclusive.\n");
usage_with_options(push_usage, options);
+ }
+ if ((all || current) && refspec)
+ usage_with_options(push_usage, options);
+ if (current) {
+ const char* head[1] = { "HEAD" };
+ set_refspecs(head, 1);
+ }
return do_push(repo, flags);
}
diff --git a/t/t5516-fetch-push.sh b/t/t5516-fetch-push.sh
index fd5f284..11c078a 100755
--- a/t/t5516-fetch-push.sh
+++ b/t/t5516-fetch-push.sh
@@ -100,6 +100,14 @@ test_expect_success 'fetch with wildcard' '
)
'
+test_expect_code 129 'push: --current and --all mutual exclusive' '
+ git push --all --current testrepo
+'
+
+test_expect_code 129 'push: --current and refspec mutual exclusive' '
+ git push --current testrepo master
+'
+
test_expect_success 'push without wildcard' '
mk_empty &&
@@ -271,6 +279,23 @@ test_expect_success 'push with HEAD nonexisting at remote' '
check_push_result $the_commit heads/local
'
+test_expect_success 'push with --current' '
+
+ mk_test heads/master &&
+ git checkout master &&
+ git push --current testrepo &&
+ check_push_result $the_commit heads/master
+
+'
+
+test_expect_success 'push with --current nonexisting at remote' '
+
+ mk_test heads/master &&
+ git checkout local &&
+ git push --current testrepo &&
+ check_push_result $the_commit heads/local
+'
+
test_expect_success 'push with dry-run' '
mk_test heads/master &&
--
1.5.3.5.742.gb61a8b
^ permalink raw reply related
* Re: Git in a Nutshell guide
From: Benoit Sigoure @ 2007-11-19 16:57 UTC (permalink / raw)
To: Lars Hjemli; +Cc: Jonas Juselius, git
In-Reply-To: <8c5c35580711190845s71a4880ek4ab28170d277e0e6@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1876 bytes --]
On Nov 19, 2007, at 5:45 PM, Lars Hjemli wrote:
> On Nov 19, 2007 2:05 PM, Jonas Juselius
> <jonas.juselius@chem.uit.no> wrote:
> Also, I think you might scare users away from 'git reset':
>
> git reset resets the branch to a specified state invisibly and
> without possibility to go back. Ever. Your call.
>
> That's not true, since any "modern" git has reflogs enabled. If you do
> 'git reset --hard HEAD^^^' and then realize it was a mistake you can
> just 'git reset --hard HEAD@{1}'
Yes, I've always been very scared of git-reset until I had a somewhat
better understanding of Git internals. In fact the only danger of
`git reset --hard' is that you loose dirty changes (not yet in the
index) and staged changes (in the index). git-reset will never, ever
delete objects from your repo. Thus, you can perfectly well remember
the current revision sha1 (let's call it `A') and then git reset --
hard HEAD~42 and then git reset --hard A. In between the two Git
commands, it's possible that all the objects of the history from
HEAD~42..A be unreachable. Nothing wrong with this, it just that if
run, say, git gc --prune (note the --prune) you will loose them.
Understanding this is very important because ``error humanum est'',
and people happen to screw up their hard work and they don't realize
that they can go back without even knowing what the hell the reflog
is or how to use it (I personally don't know -- but I'd like to, give
me pointers please :D). For instance, I once rebased a dozen of
commits on a given branch and I realised that I completely screwed my
nice patch series by collapsing changes, introducing changes at the
wrong revision etc. I could start over again by simply doing a git
reset --hard <HEAD_sha1_before_rebase>.
Cheers,
--
Benoit Sigoure aka Tsuna
EPITA Research and Development Laboratory
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 186 bytes --]
^ permalink raw reply
* Re: [PATCH] builtin-commit: fix partial-commit support
From: Kristian Høgsberg @ 2007-11-19 16:47 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <1195381287-26823-4-git-send-email-gitster@pobox.com>
On Sun, 2007-11-18 at 02:21 -0800, Junio C Hamano wrote:
> When making a partial-commit, we need to prepare two index
> files, one to be used to write out the tree to be committed
> (temporary index) and the other to be used as the index file
> after the commit is made.
>
> The temporary index needs to be initialized to HEAD and then all
> the named paths on the command line need to be staged on top of
> the index. For this, running add_files_to_cache() that compares
> what is in the index and the paths given from the command line
> is not enough -- the comparison will miss the paths that the
> user previously ran "git add" to the index since the HEAD
> because the index reset to the HEAD would not know about them.
> The index file needs to get the same modification done when
> preparing the temporary index as described above.
>
> This implementation mimics the behaviour of the scripted
> version of git-commit. It first runs overlay_tree_on_cache(),
> which was stolen from ls-files with the earlier change, to get
> the list of paths that the user can potentially mean, and then
> uses pathspec_match() to find which ones the user meant. This
> list of paths is used to update both the temporary and the real
> index file.
Oh boy, this turns out to be much more involved than what I thought.
Thanks for fixing up this part of builtin-commit.
> Additionally:
>
> - remove the temporary index file .git/next-index-* after
> commit is done or aborted.
Hmm, I see the left-over next-index-* files too, but I though the lock
file would be cleaned up automatically by the atexit handler?
cheers,
Kristian
^ permalink raw reply
* Re: Git in a Nutshell guide
From: Lars Hjemli @ 2007-11-19 17:04 UTC (permalink / raw)
To: Benoit Sigoure; +Cc: Jonas Juselius, git
In-Reply-To: <E983072E-E9FD-499E-A418-B630A275C4F3@lrde.epita.fr>
On Nov 19, 2007 5:57 PM, Benoit Sigoure <tsuna@lrde.epita.fr> wrote:
> Understanding this is very important because ``error humanum est'',
> and people happen to screw up their hard work and they don't realize
> that they can go back without even knowing what the hell the reflog
> is or how to use it (I personally don't know -- but I'd like to, give
> me pointers please :D).
You can simply try 'git reflog', and then 'man git-reflog' ;-)
--
larsh
^ permalink raw reply
* Re: Git in a Nutshell guide
From: Jonas Juselius @ 2007-11-19 16:56 UTC (permalink / raw)
To: Lars Hjemli; +Cc: git
In-Reply-To: <8c5c35580711190845s71a4880ek4ab28170d277e0e6@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1161 bytes --]
On Mon, 2007-11-19 at 17:45 +0100, Lars Hjemli wrote:
>
> Very nice introduction, but I have a couple of comments.
>
Thank you :)
> In "Specifying revisions" you say that '^' and '~' are equal, but that
> is not true. ^ is used to select the first parent of a commit, ^2
> selects the second parent of a merge commit (and ^3 selects the third
> parent of an octopus merge), while the '~' is used to go back any
> number of generations, following the first parents of each commit (~
> selects the first parent, ~2 selects the first grand-parent etc).
>
Thanks for the the clarification. I've never done an octopus, so I
simply ignored the matter. I'll correct the text and add a footnote.
> Also, I think you might scare users away from 'git reset':
>
> git reset resets the branch to a specified state invisibly and
> without possibility to go back. Ever. Your call.
>
> That's not true, since any "modern" git has reflogs enabled. If you do
> 'git reset --hard HEAD^^^' and then realize it was a mistake you can
> just 'git reset --hard HEAD@{1}'
>
This was new to me ;) I'll correct and add a note on reflogs.
.j.
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* [PATCH 1/2] config: correct core.loosecompression documentation
From: Brian Downing @ 2007-11-19 16:58 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Nicolas Pitre, Jonas Juselius, git, Brian Downing
In-Reply-To: <alpine.LFD.0.99999.0711191139240.19105@xanadu.home>
* core.loosecompression stated that the default was "0 (best speed)",
when in fact 0 is "no compression", and the default is Z_BEST_SPEED,
which is 1.
Signed-off-by: Brian Downing <bdowning@lavos.net>
---
Documentation/config.txt | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/Documentation/config.txt b/Documentation/config.txt
index 7ee97df..9565652 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -232,7 +232,7 @@ core.loosecompression::
are not in a pack file. -1 is the zlib default. 0 means no
compression, and 1..9 are various speed/size tradeoffs, 9 being
slowest. If not set, defaults to core.compression. If that is
- not set, defaults to 0 (best speed).
+ not set, defaults to 1 (best speed).
core.packedGitWindowSize::
Number of bytes of a pack file to map into memory in a
--
1.5.3.5.1824.g5f389
^ 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