* Re: Unapplied patches reminder
From: Junio C Hamano @ 2009-10-18 23:32 UTC (permalink / raw)
To: Carlos R. Mafra, Björn Gustavsson, René Scharfe
Cc: Nanako Shiraishi, git
In-Reply-To: <20091019052030.6117@nanako3.lavabit.com>
Nanako Shiraishi <nanako3@lavabit.com> writes:
> Junio, I saw these patches and thought what they try to do were
> sensible, but I don't them in your tree. I didn't see much discussion
> on most of them, either.
>
> Because I don't read C very well, I may have listed some patches
> here that you may have discarded because the code was no good, and
> if so I apologize for wasting your time, but I thought at least
> some of them should be salvaged.
> ...
> From: "Carlos R. Mafra" <crmafra@aei.mpg.de>
> Subject: [PATCH] Makefile: clean block-sha1/ directory instead of mozilla-sha1/
> Date: Sun, 11 Oct 2009 15:32:19 +0200
>
> 'make clean' should remove the object files from block-sha1/
> instead of the non-existent mozilla-sha1/ directory.
This was lost in the noise, and it is an obviously correct patch.
Thanks for a reminder.
> From: Björn Gustavsson <bgustavsson@gmail.com>
> Subject: [PATCH] push: fix usage: --tags is incompatible with --all and --mirror
> Date: Thu, 15 Oct 2009 18:39:05 +0200
> Message-ID: <4AD75029.1010109@gmail.com>
>
> Correct the usage text to make it clear that --tags cannot
> be combined with --all or --mirror.
Ditto.
> From: René Scharfe <rene.scharfe@lsrfire.ath.cx>
> Subject: [PATCH] describe: load refnames before calling describe()
> Date: Sat, 17 Oct 2009 18:30:48 +0200
> Message-ID: <4AD9F138.3080405@lsrfire.ath.cx>
>
> Get rid of the static variable that was used to prevent loading all
> the refnames multiple times by moving that code out of describe(),
> simply making sure it is only run once that way.
Ditto.
^ permalink raw reply
* Re: Unapplied patches reminder
From: Junio C Hamano @ 2009-10-18 23:32 UTC (permalink / raw)
To: Geoffrey Thomas; +Cc: git, Nanako Shiraishi
In-Reply-To: <20091019052030.6117@nanako3.lavabit.com>
Nanako Shiraishi <nanako3@lavabit.com> writes:
> Junio, I saw these patches and thought what they try to do were
> sensible, but I don't them in your tree. I didn't see much discussion
> on most of them, either.
>
> Because I don't read C very well, I may have listed some patches
> here that you may have discarded because the code was no good, and
> if so I apologize for wasting your time, but I thought at least
> some of them should be salvaged.
> ...
> From: Geoffrey Thomas <geofft@mit.edu>
> Subject: [PATCH] diffcore-order: Default the order file to .git/info/order.
> Date: Sat, 12 Sep 2009 19:49:48 -0400
> Message-ID: <1252799388-16295-1-git-send-email-geofft@mit.edu>
>
> Since order files tend to be useful for all operations in the
> project/repository, add a default location for the order file, so that
> you don't have to specify -O<orderfile> on every diff or similar
> operation.
Except that "$GIT_DIR/info/order" is a bit too generic a name ("eh,
'order'? Order of what?"), I do not think this will hurt, as no existing
repositories would have such a file that would cause any behaviour change
to existing users. The reason I did not queue it was because there wasn't
any discussion on it (not even the filename being too generic) which was
an indication that not many people are interested in such a feature.
That of course can be remedied by interested people speaking out.
^ permalink raw reply
* Re: Unapplied patches reminder
From: Junio C Hamano @ 2009-10-18 23:32 UTC (permalink / raw)
To: Tom G. Christensen; +Cc: Nanako Shiraishi, git
In-Reply-To: <20091019052030.6117@nanako3.lavabit.com>
Nanako Shiraishi <nanako3@lavabit.com> writes:
> Junio, I saw these patches and thought what they try to do were
> sensible, but I don't them in your tree. I didn't see much discussion
> on most of them, either.
>
> Because I don't read C very well, I may have listed some patches
> here that you may have discarded because the code was no good, and
> if so I apologize for wasting your time, but I thought at least
> some of them should be salvaged.
> ...
> From: "Tom G. Christensen" <tgc@statsbiblioteket.dk>
> Subject: [PATCH] NO_PERL_MAKEMAKER should behave more like ExtUtils::MakeMaker
> Date: Tue, 13 Oct 2009 13:14:31 +0200
> Message-ID: <1255432471-14168-1-git-send-email-tgc@statsbiblioteket.dk>
>
> This change makes NO_PERL_MAKEMAKER behave more as ExtUtils::MakeMaker
> by installing the modules into the perl libdir and not $(prefix)/lib.
> It will default to sitelib but will allow the user to choose by setting
> the INSTALLDIRS variable which is also honored by ExtUtils::MakeMaker.
I still have this in my inbox, but I tend to wait for Acks to patches that
touch perl/ area before acting on them, which hasn't happened.
P.S. Originally I somehow mistook this from tchrist (aka thoth) and
blindly applied, but then realized it is a different Tom with slightly
different family name and recategorized the patch to go through the usual
review cycle.
^ permalink raw reply
* Re: Unapplied patches reminder
From: Junio C Hamano @ 2009-10-18 23:32 UTC (permalink / raw)
To: Vietor Liu, Björn Gustavsson; +Cc: Nanako Shiraishi, git
In-Reply-To: <20091019052030.6117@nanako3.lavabit.com>
Nanako Shiraishi <nanako3@lavabit.com> writes:
> Junio, I saw these patches and thought what they try to do were
> sensible, but I don't them in your tree. I didn't see much discussion
> on most of them, either.
>
> Because I don't read C very well, I may have listed some patches
> here that you may have discarded because the code was no good, and
> if so I apologize for wasting your time, but I thought at least
> some of them should be salvaged.
> ...
> From: Vietor Liu <vietor@vxwo.org>
> Subject: [PATCH v4] git-gui: adjust the minimum height of diff pane for
> Date: Fri, 16 Oct 2009 17:41:26 +0800
> Message-Id: <1255686086-3949-1-git-send-email-vietor@vxwo.org>
>
> When the main window is maximized, if the screen height is shorter (e.g.
> Netbook screen 1024x600), both the partial commit pane and the status bar
> are hidden.
I never apply patches to git-gui and gitk myself, but expect to be fed
them via respective area experts.
> From: Björn Gustavsson <bgustavsson@gmail.com>
> Subject: [PATCH] bash: complete more options for 'git rebase'
> Date: Sat, 17 Oct 2009 11:33:38 +0200
> Message-ID: <4AD98F72.1060901@gmail.com>
>
> Complete all long options for 'git rebase' except --no-verify
> (probably used very seldom) and the long options corresponding
> to -v, -q, and -f.
Likewise; I was expecting Shawn to Ack/Nak this one.
^ permalink raw reply
* [PATCH] Document git push -q
From: Miklos Vajna @ 2009-10-18 23:52 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Sebastian Pipping, Jeff King, git
In-Reply-To: <4ADB4AE8.5070007@hartwork.org>
Signed-off-by: Miklos Vajna <vmiklos@frugalware.org>
---
On Sun, Oct 18, 2009 at 07:05:44PM +0200, Sebastian Pipping <webmaster@hartwork.org> wrote:
> If I'm not mistaken --quiet is not documented in the git-push man page.
> This includes release 1.6.5.1.
Here is a patch to document it.
Documentation/git-push.txt | 6 ++++++
1 files changed, 6 insertions(+), 0 deletions(-)
diff --git a/Documentation/git-push.txt b/Documentation/git-push.txt
index ba6a8a2..beb3422 100644
--- a/Documentation/git-push.txt
+++ b/Documentation/git-push.txt
@@ -138,6 +138,12 @@ useful if you write an alias or script around 'git-push'.
--verbose::
Run verbosely.
+-q::
+--quiet::
+ Some transports produce output even without `--verbose` turned
+ on. This provides a way to tell them to be more quiet (whereas
+ simply redirecting might lose error messages).
+
include::urls-remotes.txt[]
OUTPUT
--
1.6.5
^ permalink raw reply related
* [PATCH] git add -e documentation: rephrase note
From: Miklos Vajna @ 2009-10-19 0:09 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jeff King, git
In-Reply-To: <20091014230434.GB29664@coredump.intra.peff.net>
Add a quick overview about what is OK and what is not to cover all
cases.
Signed-off-by: Miklos Vajna <vmiklos@frugalware.org>
Signed-off-by: Jeff King <peff@peff.net>
---
On Wed, Oct 14, 2009 at 07:04:34PM -0400, Jeff King <peff@peff.net> wrote:
> Maybe it makes sense instead to do a quick overview of what is OK and
> what is not (like the list above).
Here it is.
Documentation/git-add.txt | 18 +++++++++++++++---
1 files changed, 15 insertions(+), 3 deletions(-)
diff --git a/Documentation/git-add.txt b/Documentation/git-add.txt
index 45ebf87..1ea074c 100644
--- a/Documentation/git-add.txt
+++ b/Documentation/git-add.txt
@@ -86,9 +86,21 @@ OPTIONS
edit it. After the editor was closed, adjust the hunk headers
and apply the patch to the index.
+
-*NOTE*: Obviously, if you change anything else than the first character
-on lines beginning with a space or a minus, the patch will no longer
-apply.
+The intent of this option is to pick and choose lines of the diff to
+apply, or even to munge the lines. So it is safe to:
++
+* remove lines with a "+" (don't stage the addition)
+* munge any lines with a "+" (stage modified contents)
+* add lines with a "+" (stage an addition)
+* convert lines with a " " to "-" (stage removal)
+* convert lines with a "-" to " " (don't stage removal)
++
+It is a bad idea to:
++
+* delete "-" lines
+* delete " " lines
+* add " " or "-" lines
+* munge the contents of " " or "-" lines
-u::
--update::
--
1.6.5
^ permalink raw reply related
* Re: Creating something like increasing revision numbers
From: Norbert Preining @ 2009-10-19 0:44 UTC (permalink / raw)
To: Daniel Barkalow; +Cc: git
In-Reply-To: <alpine.LNX.2.00.0910181727130.32515@iabervon.org>
Hi all,
thanks everyone for the nice feedback!
On So, 18 Okt 2009, Daniel Barkalow wrote:
> It's possible as long as you don't think of the "version number" as a
> property of the commit, but rather a property that some commits get by
> virtue of having been at some time the commit that's what would be found
> on that particular server at that particular time. Even though the history
Right! That is a good point. In fact I don't care about (local) commits,
but about the pushes to the central server.
> of the *content* is non-linear, the sequence of values stored in
> refs/heads/master on your central server is linear, local, and easy to
> enumerate.
That is exactely what I need.
> Of course, when someone does a bunch of development in parallel with other
> people, does a final merge, and pushes it back to the server, this only
> increases the version by one, and only the final merge actually has a
As it is now with svn, we have to live with that. The point is that we
still would see many different commits pushed to the server, so
git log would show the single items, but the "versioning sequence number"
is only increased by one. That would be *absolutely*perfect* for me!
> because the intermediate commits don't ever get packages created of them
> to need to be compared to other packages.
Right!
Now my follow-up questions:
- how would one access this "sequence" number on the server
- is there a way to determine at which of this "sequence" numbers a specific
file has been changed last?
Thanks a lot and all the best
Norbert
-------------------------------------------------------------------------------
Dr. Norbert Preining Associate Professor
JAIST Japan Advanced Institute of Science and Technology preining@jaist.ac.jp
Vienna University of Technology preining@logic.at
Debian Developer (Debian TeX Task Force) preining@debian.org
gpg DSA: 0x09C5B094 fp: 14DF 2E6C 0307 BE6D AD76 A9C0 D2BF 4AA3 09C5 B094
-------------------------------------------------------------------------------
DULEEK (n.)
Sudden realisation, as you lie in bed waiting for the alarm to go off,
that it should have gone off an hour ago.
--- Douglas Adams, The Meaning of Liff
^ permalink raw reply
* Re: Creating something like increasing revision numbers
From: Norbert Preining @ 2009-10-19 0:48 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Johan Herland, git
In-Reply-To: <7vfx9gnwtw.fsf@alter.siamese.dyndns.org>
On So, 18 Okt 2009, Junio C Hamano wrote:
> #2 Do not give such sequential number locally; the central repository is
> the _only_ place that assigns such a number. '?' stands for
> 'unnumbered'
[...]
> Scheme #2 is a way to get some stablility; give the authority of numbering
> to the central repository and commits that haven't hit the central
> repository are left unnumbered. But that is generally not very useful
> for your purpose of giving incrementing version number for building (the
> developers would want to build for testing before finally committing to
> publish the result to the central place).
That problem we have anyway with subversion, too, because as long as you
do not commit your changes nothing will happen on package rebuild.
So that is not a problem here.
Yes, we want server-sided linear numbers and anything *not* pushed to
the server is unnumbered.
And that is also fine, because packages are built only from the server.
Best wishes
Norbert
-------------------------------------------------------------------------------
Dr. Norbert Preining Associate Professor
JAIST Japan Advanced Institute of Science and Technology preining@jaist.ac.jp
Vienna University of Technology preining@logic.at
Debian Developer (Debian TeX Task Force) preining@debian.org
gpg DSA: 0x09C5B094 fp: 14DF 2E6C 0307 BE6D AD76 A9C0 D2BF 4AA3 09C5 B094
-------------------------------------------------------------------------------
PUDSEY (n.)
The curious-shaped flat wads of dough left on a kitchen table after
someone has been cutting scones out of it.
--- Douglas Adams, The Meaning of Liff
^ permalink raw reply
* Re: Creating something like increasing revision numbers
From: Nicolas Pitre @ 2009-10-19 1:15 UTC (permalink / raw)
To: Johan Herland; +Cc: Norbert Preining, git
In-Reply-To: <200910181923.19511.johan@herland.net>
On Sun, 18 Oct 2009, Johan Herland wrote:
> On Sunday 18 October 2009, Norbert Preining wrote:
> > On So, 18 Okt 2009, Johan Herland wrote:
> > > $ git describe
> > > v1.0.4-14-g2414721
> > >
> > > where the "v1.0.4" part is the last tag that the current state is based
> > > on, the "14" part is the number of commit between that tag and the
> > > current
> >
> > So if we have only one tag (initial) then it would count the number
> > of commits?
>
> Yes. You can create the 'initial' tag with
>
> git rev-list HEAD | tail -n1 | xargs git tag initial
>
> and from then on
>
> git describe --tags --match initial | cut -d'-' -f2
Even simpler, without any tag:
git rev-list HEAD | wc -l
That should roughly give the equivalent of the SVN revision number.
Valid only in one specific repository of course.
Nicolas
^ permalink raw reply
* Re: Creating something like increasing revision numbers
From: Daniel Barkalow @ 2009-10-19 1:16 UTC (permalink / raw)
To: Norbert Preining; +Cc: git
In-Reply-To: <20091019004447.GC11739@gamma.logic.tuwien.ac.at>
On Mon, 19 Oct 2009, Norbert Preining wrote:
> Hi all,
>
> thanks everyone for the nice feedback!
>
> On So, 18 Okt 2009, Daniel Barkalow wrote:
> > It's possible as long as you don't think of the "version number" as a
> > property of the commit, but rather a property that some commits get by
> > virtue of having been at some time the commit that's what would be found
> > on that particular server at that particular time. Even though the history
>
> Right! That is a good point. In fact I don't care about (local) commits,
> but about the pushes to the central server.
>
> > of the *content* is non-linear, the sequence of values stored in
> > refs/heads/master on your central server is linear, local, and easy to
> > enumerate.
>
> That is exactely what I need.
>
> > Of course, when someone does a bunch of development in parallel with other
> > people, does a final merge, and pushes it back to the server, this only
> > increases the version by one, and only the final merge actually has a
>
> As it is now with svn, we have to live with that. The point is that we
> still would see many different commits pushed to the server, so
> git log would show the single items, but the "versioning sequence number"
> is only increased by one. That would be *absolutely*perfect* for me!
>
> > because the intermediate commits don't ever get packages created of them
> > to need to be compared to other packages.
>
> Right!
>
> Now my follow-up questions:
> - how would one access this "sequence" number on the server
There isn't currently anything built in that counts up like that; however,
it shouldn't be too hard to add something, because the reflog gets an
entry at the same times the sequence number would increase. In fact, you
could disable pruning the reflog, and use its length (in lines), except
that would get slow and git doesn't expect you to care about the complete
history there (in fact, you only care about the amount of history past
some point).
> - is there a way to determine at which of this "sequence" numbers a specific
> file has been changed last?
There isn't a built-in way, but you can find the current hash for a
filename with "git ls-tree -r <branch> <filename>", and find the hash as
of N changes ago with "git ls-tree -r <branch>@{<N>} <filename>". You're
looking for the smallest N where they don't match. (And you probably
don't want to be a binary search or the like, because that might miss that
a file was most recently affected by having a change reverted; you'd want
to be sure to report the version that reverted the change, not the version
that introduced the content the later one returned to.
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* Re: Creating something like increasing revision numbers
From: Norbert Preining @ 2009-10-19 1:33 UTC (permalink / raw)
To: Daniel Barkalow; +Cc: git
In-Reply-To: <alpine.LNX.2.00.0910182045580.14365@iabervon.org>
Hi Daniel,
On So, 18 Okt 2009, Daniel Barkalow wrote:
> > - how would one access this "sequence" number on the server
>
> There isn't currently anything built in that counts up like that; however,
> it shouldn't be too hard to add something, because the reflog gets an
> entry at the same times the sequence number would increase. In fact, you
Ok.
> > - is there a way to determine at which of this "sequence" numbers a specific
> > file has been changed last?
>
> There isn't a built-in way, but you can find the current hash for a
> filename with "git ls-tree -r <branch> <filename>", and find the hash as
> of N changes ago with "git ls-tree -r <branch>@{<N>} <filename>". You're
> looking for the smallest N where they don't match. (And you probably
> don't want to be a binary search or the like, because that might miss that
That sounds like we cannot use that, because we have to do that for about
80k files and that on each (at least daily) rebuilt. That is not feasable.
Again thanks for your helpful comments!
Norbert
-------------------------------------------------------------------------------
Dr. Norbert Preining Associate Professor
JAIST Japan Advanced Institute of Science and Technology preining@jaist.ac.jp
Vienna University of Technology preining@logic.at
Debian Developer (Debian TeX Task Force) preining@debian.org
gpg DSA: 0x09C5B094 fp: 14DF 2E6C 0307 BE6D AD76 A9C0 D2BF 4AA3 09C5 B094
-------------------------------------------------------------------------------
BRUMBY
The fake antique plastic seal on a pretentious whisky bottle.
--- Douglas Adams, The Meaning of Liff
^ permalink raw reply
* Re: Creating something like increasing revision numbers
From: Nicolas Pitre @ 2009-10-19 1:34 UTC (permalink / raw)
To: Norbert Preining; +Cc: Daniel Barkalow, git
In-Reply-To: <20091019004447.GC11739@gamma.logic.tuwien.ac.at>
On Mon, 19 Oct 2009, Norbert Preining wrote:
> Now my follow-up questions:
> - how would one access this "sequence" number on the server
you can count how many commits the server has: git rev-list HEAD | wc -l
> - is there a way to determine at which of this "sequence" numbers a specific
> file has been changed last?
You can do: git log <path/filename>. That would give you a list of
commits that touched that file. But to find out which commit "number"
it is you could do:
git rev-list $(git rev-list -1 HEAD <path/file>) | wc -l
Again, that is true for a particular repository only and may give a
different result in another repository with a different state even for
the same commit.
However, given what you want to do is really to stick to the SVN way of
doing things, then why don't you simply stay with SVN? Git works in a
fundamentally different way than SVN, and if you aren't willing/able to
change your workflow away from the SVN way then there is really not much
for you to gain by switching to Git.
Nicolas
^ permalink raw reply
* Re: Creating something like increasing revision numbers
From: Norbert Preining @ 2009-10-19 1:42 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: Daniel Barkalow, git
In-Reply-To: <alpine.LFD.2.00.0910182122100.21739@xanadu.home>
On So, 18 Okt 2009, Nicolas Pitre wrote:
> However, given what you want to do is really to stick to the SVN way of
> doing things, then why don't you simply stay with SVN? Git works in a
I fear so.
> fundamentally different way than SVN, and if you aren't willing/able to
> change your workflow away from the SVN way then there is really not much
> for you to gain by switching to Git.
Well, as I said in the beginning, the metadata handling of svn is a pain
in huge repositories like ours with thousands of subdirectories of subdirs
of subdirs and 80k+ files. That was the reason I thought about git.
But I am coming to the conclusion that I will use git for my other projects,
but not for that one.
Best wishes
Norbert
-------------------------------------------------------------------------------
Dr. Norbert Preining Associate Professor
JAIST Japan Advanced Institute of Science and Technology preining@jaist.ac.jp
Vienna University of Technology preining@logic.at
Debian Developer (Debian TeX Task Force) preining@debian.org
gpg DSA: 0x09C5B094 fp: 14DF 2E6C 0307 BE6D AD76 A9C0 D2BF 4AA3 09C5 B094
-------------------------------------------------------------------------------
GLASSEL (n.)
A seaside pebble which was shiny and interesting when wet, and which
is now a lump of rock, which children nevertheless insist on filing
their suitcases with after the holiday.
--- Douglas Adams, The Meaning of Liff
^ permalink raw reply
* Re: Creating something like increasing revision numbers
From: Daniel Barkalow @ 2009-10-19 2:41 UTC (permalink / raw)
To: Norbert Preining; +Cc: git
In-Reply-To: <20091019013320.GD17397@gamma.logic.tuwien.ac.at>
On Mon, 19 Oct 2009, Norbert Preining wrote:
> Hi Daniel,
>
> On So, 18 Okt 2009, Daniel Barkalow wrote:
> > > - how would one access this "sequence" number on the server
> >
> > There isn't currently anything built in that counts up like that; however,
> > it shouldn't be too hard to add something, because the reflog gets an
> > entry at the same times the sequence number would increase. In fact, you
>
> Ok.
>
> > > - is there a way to determine at which of this "sequence" numbers a specific
> > > file has been changed last?
> >
> > There isn't a built-in way, but you can find the current hash for a
> > filename with "git ls-tree -r <branch> <filename>", and find the hash as
> > of N changes ago with "git ls-tree -r <branch>@{<N>} <filename>". You're
> > looking for the smallest N where they don't match. (And you probably
> > don't want to be a binary search or the like, because that might miss that
>
> That sounds like we cannot use that, because we have to do that for about
> 80k files and that on each (at least daily) rebuilt. That is not feasable.
It's likely to be much more efficient (and maybe sufficiently efficient)
to do them all in a single pass. In fact, it should be easy enough to keep
a cache of the latest numbers for the files, and update that to change the
value for those files that differ between the old commit and the new
commit in the post-update hook.
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* [PATCH] git push: remove incomplete options list from help text
From: Nanako Shiraishi @ 2009-10-19 2:54 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Miklos Vajna, Sebastian Pipping, Jeff King, git
In-Reply-To: <20091018235240.GU6115@genesis.frugalware.org>
'git push -h' shows usage text with incomplete list of options and then
has a separate list of options that are supported. Imitate the way other
commands (I looked at 'git diff' for an example) show their options.
Signed-off-by: しらいし ななこ <nanako3@lavabit.com>
---
Quoting Miklos Vajna <vmiklos@frugalware.org>
> Signed-off-by: Miklos Vajna <vmiklos@frugalware.org>
> ---
>
> On Sun, Oct 18, 2009 at 07:05:44PM +0200, Sebastian Pipping <webmaster@hartwork.org> wrote:
>> If I'm not mistaken --quiet is not documented in the git-push man page.
>> This includes release 1.6.5.1.
>
> Here is a patch to document it.
% git push -h
usage: git push [--all | --mirror] [-n | --dry-run] [--porcelain] [--tags]
[--receive-pack=<git-receive-pack>] [--repo=<repository>] [-f | --force]
[-v] [<repository> <refspec>...]
-q, --quiet be quiet
-v, --verbose be verbose
--repo <repository> repository
--all push all refs
--mirror mirror all refs
--tags push tags
-n, --dry-run dry run
--porcelain machine-readable output
-f, --force force updates
--thin use thin pack
--receive-pack <receive-pack>
receive pack program
--exec <receive-pack>
receive pack program
builtin-push.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/builtin-push.c b/builtin-push.c
index 3cb1ee4..6686b79 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 | --mirror] [-n | --dry-run] [--porcelain] [--tags] [--receive-pack=<git-receive-pack>] [--repo=<repository>] [-f | --force] [-v] [<repository> <refspec>...]",
+ "git push <options> [<repository> <refspec>...]",
NULL,
};
--
1.6.5.rc1.18.g53a9a
--
Nanako Shiraishi
http://ivory.ap.teacup.com/nanako3/
^ permalink raw reply related
* Re: [RFC PATCH v3 10/17] Move WebDAV HTTP push under remote-curl
From: Tay Ray Chuan @ 2009-10-19 2:59 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: git, Daniel Barkalow, Mike Hommey
In-Reply-To: <1255577814-14745-11-git-send-email-spearce@spearce.org>
Hi,
On Thu, Oct 15, 2009 at 11:36 AM, Shawn O. Pearce <spearce@spearce.org> wrote:
> diff --git a/Documentation/git-remote-helpers.txt b/Documentation/git-remote-helpers.txt
> @@ -34,6 +34,10 @@ Commands are given by the caller on the helper's standard input, one per line.
> value of the ref. A space-separated list of attributes follows
> the name; unrecognized attributes are ignored. After the
> complete list, outputs a blank line.
> ++
> +If 'push' is supported this may be called as 'list for-push'
> +to obtain the current refs prior to sending one or more 'push'
> +commands to the helper.
The new paragraph should have the same indentation as 'list'.
It would have been great if you implemented this as a filter, such that
'list <attr>' lists the refs with the specified attribute <attr>,
rather than hardcoding it.
> @@ -59,6 +63,22 @@ suitably updated.
> +When the push is complete, outputs one or more 'ok <dst>' or
> +'error <dst> <why>?' lines to indicate success or failure of
> +each pushed ref. The status report output is terminated by
> +a blank line. The option field <why> may be quoted in a C
> +style string if it contains an LF.
You should mention that this behaviour only occurs when the
--helper-status option is used.
> @@ -106,6 +132,11 @@ OPTIONS
> +'option dry-run' \{'true'|'false'\}:
> + If true, pretend like the operation completed successfully,
> + but don't actually change any repository data. For most
> + helpers this only applies to the 'push', if supported.
> +
The 'like' after 'pretend' can be, like, removed. :)
> diff --git a/http-push.c b/http-push.c
> @@ -1941,9 +1946,14 @@ int main(int argc, char **argv)
>
> if (is_null_sha1(ref->peer_ref->new_sha1)) {
> if (delete_remote_branch(ref->name, 1) == -1) {
> - error("Could not remove %s", ref->name);
> + if (helper_status)
> + printf("error %s cannot remove\n", ref->name);
> + else
> + error("Could not remove %s", ref->name);
> rc = -4;
> }
I think error() calls should be left intact (as indicators to the
user), even when --helper-status is specified. It wouldn't affect
transport-helper.c's parsing of '(ok|error) <ref>' lines, since it
reads stdout only.
In other words, the above would read:
> error("Could not remove %s", ref->name);
> + if (helper_status)
> + printf("error %s cannot remove\n", ref->name);
> rc = -4;
> }
> @@ -1968,12 +1980,15 @@ int main(int argc, char **argv)
> * commits at the remote end and likely
> * we were not up to date to begin with.
> */
> - error("remote '%s' is not an ancestor of\n"
> - "local '%s'.\n"
> - "Maybe you are not up-to-date and "
> - "need to pull first?",
> - ref->name,
> - ref->peer_ref->name);
> + if (helper_status)
> + printf("error %s non-fast forward\n", ref->name);
> + else
> + error("remote '%s' is not an ancestor of\n"
> + "local '%s'.\n"
> + "Maybe you are not up-to-date and "
> + "need to pull first?",
> + ref->name,
> + ref->peer_ref->name);
> rc = -2;
> continue;
> }
Same here.
> @@ -1987,14 +2002,20 @@ int main(int argc, char **argv)
> /* Lock remote branch ref */
> ref_lock = lock_remote(ref->name, LOCK_TIME);
> if (ref_lock == NULL) {
> - fprintf(stderr, "Unable to lock remote branch %s\n",
> - ref->name);
> + if (helper_status)
> + printf("error %s lock error\n", ref->name);
> + else
> + fprintf(stderr, "Unable to lock remote branch %s\n",
> + ref->name);
> rc = 1;
> continue;
> }
Same here.
Two more areas in http-push.c that should have status messages
(generated on top of pu):
(I'm not sure what ref should read when there's no match, but
transport-helper.c should have no problems parsing it with 'null'.)
-->8--
diff --git a/http-push.c b/http-push.c
index 9010ccc..e979feb 100644
--- a/http-push.c
+++ b/http-push.c
@@ -1916,9 +1916,12 @@ int main(int argc, char **argv)
/* Remove a remote branch if -d or -D was specified */
if (delete_branch) {
- if (delete_remote_branch(refspec[0], force_delete) == -1)
+ if (delete_remote_branch(refspec[0], force_delete) == -1) {
fprintf(stderr, "Unable to delete remote branch %s\n",
refspec[0]);
+ if (helper_status)
+ printf("error %s cannot remove\n", refspec[0]);
+ }
goto cleanup;
}
@@ -1930,6 +1933,8 @@ int main(int argc, char **argv)
}
if (!remote_refs) {
fprintf(stderr, "No refs in common and none specified; doing nothing.\n");
+ if (helper_status)
+ printf("error null no match\n");
rc = 0;
goto cleanup;
}
--
Cheers,
Ray Chuan
^ permalink raw reply related
* Re: [PATCH] Add the --submodule option to the diff option family
From: Junio C Hamano @ 2009-10-19 3:02 UTC (permalink / raw)
To: Jens Lehmann; +Cc: Johannes Schindelin, Git Mailing List
In-Reply-To: <4ADA10FC.40708@web.de>
Jens Lehmann <Jens.Lehmann@web.de> writes:
> When you use the option --submodule=left-right-log you can see the submodule
> summaries inlined in the diff, instead of not-quite-helpful SHA-1 pairs.
>
> The format imitates what "git submodule summary" shows.
>
> To do that, <path>/.git/objects/ is added to the alternate object
> databases (if that directory exists).
>
> This option was requested by Jens Lehmann at the GitTogether in Berlin.
>
> Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
> Signed-off-by: Jens Lehmann <Jens.Lehmann@web.de>
> ---
Thanks.
I have four patches queued on js/diff-verbose-submodule topic and I think
this corresponds to the first three, correct?
> diff --git a/Documentation/diff-options.txt b/Documentation/diff-options.txt
> index 9276fae..99cb517 100644
> --- a/Documentation/diff-options.txt
> +++ b/Documentation/diff-options.txt
> @@ -87,6 +87,13 @@ endif::git-format-patch[]
> Show only names and status of changed files. See the description
> of the `--diff-filter` option on what the status letters mean.
>
> +--submodule[=<format>]::
> + Chose the output format for submodule differences. <format> can be one of
> + 'short' and 'left-right-log'. 'short' is the default value for this
> + option and and shows pairs of commit names. 'left-right-log' lists the
> + commits in that commit range like the 'summary' option of
> + linkgit:git-submodule[1] does.
> +
Well, while left-right-log may be logically the most correct name for this
option, I think it is too long to be practical. Because it is not like we
would want to have an option to have full log there when we are showing
"diff", I think it would make sense to making left-right-log the default
when "--submodule" (without format specification) is given, and possibly
give "--submodule=log" as the synonym for this format.
After all, if you do not give --submodule, we will give the traditional
short format, no?
> diff --git a/diff.c b/diff.c
> index c719ce2..8af1ae2 100644
> --- a/diff.c
> +++ b/diff.c
> @@ -2771,6 +2783,10 @@ int diff_opt_parse(struct diff_options *options, const char **av, int ac)
> DIFF_OPT_CLR(options, ALLOW_TEXTCONV);
> else if (!strcmp(arg, "--ignore-submodules"))
> DIFF_OPT_SET(options, IGNORE_SUBMODULES);
> + else if (!prefixcmp(arg, "--submodule=")) {
> + if (!strcmp(arg + 12, "left-right-log"))
> + DIFF_OPT_SET(options, SUBMODULE_LEFT_RIGHT_LOG);
> + }
I do not see --submodule (without "=<format>") supported here as the
documentation claims, but this is the logical place to do so.
> diff --git a/submodule.c b/submodule.c
> new file mode 100644
> index 0000000..206386f
> --- /dev/null
> +++ b/submodule.c
> @@ -0,0 +1,112 @@
> +...
> +void show_submodule_summary(FILE *f, const char *path,
> + unsigned char one[20], unsigned char two[20],
> + const char *del, const char *add, const char *reset)
> +{
> ...
> + fwrite(sb.buf, sb.len, 1, f);
> +
> + if (!message) {
> + while ((commit = get_revision(&rev))) {
> + ...
> + }
> + clear_commit_marks(left, ~0);
> + clear_commit_marks(right, ~0);
> + }
> +}
I thought we had strbuf_release(&sb) here... Where did it go?
^ permalink raw reply
* Re: [PATCH] git push: remove incomplete options list from help text
From: Junio C Hamano @ 2009-10-19 3:13 UTC (permalink / raw)
To: Nanako Shiraishi; +Cc: Miklos Vajna, Sebastian Pipping, Jeff King, git
In-Reply-To: <20091019115412.6117@nanako3.lavabit.com>
Nanako Shiraishi <nanako3@lavabit.com> writes:
> 'git push -h' shows usage text with incomplete list of options and then
> has a separate list of options that are supported. Imitate the way other
> commands (I looked at 'git diff' for an example) show their options.
>
> Signed-off-by: しらいし ななこ <nanako3@lavabit.com>
> ---
> ...
> diff --git a/builtin-push.c b/builtin-push.c
> index 3cb1ee4..6686b79 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 | --mirror] [-n | --dry-run] [--porcelain] [--tags] [--receive-pack=<git-receive-pack>] [--repo=<repository>] [-f | --force] [-v] [<repository> <refspec>...]",
> + "git push <options> [<repository> <refspec>...]",
> NULL,
> };
>
> --
> 1.6.5.rc1.18.g53a9a
Sounds like a sane thing to do, but I am sort of surprised that you are
still on 1.6.5-rc1 ;-)
How does this interact with one of the "unapplied patch" you reminded me
of, namely, this one:
From: Björn Gustavsson <bgustavsson@gmail.com>
Subject: [PATCH] push: fix usage: --tags is incompatible with --all and --mirror
Date: Thu, 15 Oct 2009 18:39:05 +0200
Message-ID: <4AD75029.1010109@gmail.com>
Correct the usage text to make it clear that --tags cannot
be combined with --all or --mirror.
The option description that comes from parse-options may need to be
updated as well, no?
> -q, --quiet be quiet
> -v, --verbose be verbose
> --repo <repository> repository
> --all push all refs
> --mirror mirror all refs
> --tags push tags
> -n, --dry-run dry run
> --porcelain machine-readable output
> -f, --force force updates
> --thin use thin pack
> --receive-pack <receive-pack>
> receive pack program
> --exec <receive-pack>
> receive pack program
^ permalink raw reply
* [PATCH] git push: say that --tag can't be used with --all or --mirror in help text
From: Nanako Shiraishi @ 2009-10-19 3:57 UTC (permalink / raw)
To: Junio C Hamano
Cc: Nanako Shiraishi, Miklos Vajna, Sebastian Pipping, Jeff King, git,
Bjorn Gustavsson
In-Reply-To: <7vpr8kcc00.fsf@alter.siamese.dyndns.org>
This replaces an earlier patch by Björn Gustavsson,
Message-ID: <4AD75029.1010109@gmail.com>
Signed-off-by: しらいし ななこ <nanako3@lavabit.com>
---
builtin-push.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/builtin-push.c b/builtin-push.c
index 6686b79..d7248f2 100644
--- a/builtin-push.c
+++ b/builtin-push.c
@@ -181,7 +181,7 @@ int cmd_push(int argc, const char **argv, const char *prefix)
OPT_BIT( 0 , "all", &flags, "push all refs", TRANSPORT_PUSH_ALL),
OPT_BIT( 0 , "mirror", &flags, "mirror all refs",
(TRANSPORT_PUSH_MIRROR|TRANSPORT_PUSH_FORCE)),
- OPT_BOOLEAN( 0 , "tags", &tags, "push tags"),
+ OPT_BOOLEAN( 0 , "tags", &tags, "push tags (can't be used with --all nor --mirror"),
OPT_BIT('n' , "dry-run", &flags, "dry run", TRANSPORT_PUSH_DRY_RUN),
OPT_BIT( 0, "porcelain", &flags, "machine-readable output", TRANSPORT_PUSH_PORCELAIN),
OPT_BIT('f', "force", &flags, "force updates", TRANSPORT_PUSH_FORCE),
--
1.6.5.rc1.18.g53a9a
--
Nanako Shiraishi
http://ivory.ap.teacup.com/nanako3/
^ permalink raw reply related
* Re: git push should automatically push to remote tracking branch
From: Mohit Aron @ 2009-10-19 3:50 UTC (permalink / raw)
To: Tomas Carnecky; +Cc: git
In-Reply-To: <1B59440B-5929-4AB9-82C7-05188DC4F959@dbservice.com>
Thanks - I suppose this is a new config option. I'm running Git
version 1.6.0.4 (the latest with Ubuntu Jaunty) and that doesn't seem
to have this option.
- Mohit
>
> $ git config push.default tracking
>
> tom
>
>
^ permalink raw reply
* Re: [PATCH] Document git push -q
From: Jeff King @ 2009-10-19 4:01 UTC (permalink / raw)
To: Miklos Vajna; +Cc: Junio C Hamano, Sebastian Pipping, git
In-Reply-To: <20091018235240.GU6115@genesis.frugalware.org>
On Mon, Oct 19, 2009 at 01:52:40AM +0200, Miklos Vajna wrote:
> diff --git a/Documentation/git-push.txt b/Documentation/git-push.txt
> index ba6a8a2..beb3422 100644
> --- a/Documentation/git-push.txt
> +++ b/Documentation/git-push.txt
> @@ -138,6 +138,12 @@ useful if you write an alias or script around 'git-push'.
> --verbose::
> Run verbosely.
>
> +-q::
> +--quiet::
> + Some transports produce output even without `--verbose` turned
> + on. This provides a way to tell them to be more quiet (whereas
> + simply redirecting might lose error messages).
> +
Thanks, though two complaints:
1. This is not just about "some transports". Some of the quieted code
is in transport_push, so hopefully it applies to all transports
once they follow that code path (though we also pass the quiet flag
on to pack-objects, so that part is about "some transports".
2. Maybe it would be more helpful to the user to describe what is
shown and what is not. I think we want to claim to suppress all
non-error output (since that was the intent of the recent patches).
If that is not true for some transport, then we need to fix passing
--quiet to that transport.
...Ah, I see your confusion. You read the log for afdeeb00, but there
were some follow-on patches that impacted others part of push. :)
So maybe this instead:
-- >8 --
Subject: [PATCH] document push's new quiet option
Signed-off-by: Jeff King <peff@peff.net>
---
Documentation/git-push.txt | 5 +++++
1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/Documentation/git-push.txt b/Documentation/git-push.txt
index ba6a8a2..37c8895 100644
--- a/Documentation/git-push.txt
+++ b/Documentation/git-push.txt
@@ -138,6 +138,11 @@ useful if you write an alias or script around 'git-push'.
--verbose::
Run verbosely.
+-q::
+--quiet::
+ Suppress all output, including the listing of updated refs,
+ unless an error occurs.
+
include::urls-remotes.txt[]
OUTPUT
--
1.6.5.1.121.g65c47
^ permalink raw reply related
* Re: [PATCH] git push: remove incomplete options list from help text
From: Jeff King @ 2009-10-19 4:10 UTC (permalink / raw)
To: Nanako Shiraishi; +Cc: Junio C Hamano, Miklos Vajna, Sebastian Pipping, git
In-Reply-To: <20091019115412.6117@nanako3.lavabit.com>
On Mon, Oct 19, 2009 at 11:54:12AM +0900, Nanako Shiraishi wrote:
> static const char * const push_usage[] = {
> - "git push [--all | --mirror] [-n | --dry-run] [--porcelain] [--tags] [--receive-pack=<git-receive-pack>] [--repo=<repository>] [-f | --force] [-v] [<repository> <refspec>...]",
> + "git push <options> [<repository> <refspec>...]",
This is a big improvement, IMO. We should probably standardize on when
to show options, and when to simply say <options>, and make sure every
program does the right thing. I am in favor of a short synopsis followed
by a list (as you do here) for both usage and for manpages. However, I
raised the question a few weeks ago and the response was slightly
negative:
http://thread.gmane.org/gmane.comp.version-control.git/129399/focus=129424
Probably few people read it, as it was buried deep in a thread. But
maybe we should settle on a rule like "short synopsis for usage, long
synopsis for manpage" or whatever people think is best.
Also, minor nit with your patch: should it be "[<options>]"?
-Peff
^ permalink raw reply
* Re: [PATCH] git push: say that --tag can't be used with --all or --mirror in help text
From: Jeff King @ 2009-10-19 4:14 UTC (permalink / raw)
To: Nanako Shiraishi
Cc: Junio C Hamano, Miklos Vajna, Sebastian Pipping, git,
Bjorn Gustavsson
In-Reply-To: <20091019125701.6117@nanako3.lavabit.com>
On Mon, Oct 19, 2009 at 12:57:01PM +0900, Nanako Shiraishi wrote:
> - OPT_BOOLEAN( 0 , "tags", &tags, "push tags"),
> + OPT_BOOLEAN( 0 , "tags", &tags, "push tags (can't be used with --all nor --mirror"),
Grammar nit: I believe it should be "or" and not "nor".
There is an implicit "either", as in "can't be used with either --all or
--mirror". Saying "can't be used with neither --all nor --mirror" would
be a double-negative. The alternative correct single-negation would be
"can be used with neither --all nor --mirror".
-Peff
^ permalink raw reply
* Re: [PATCH] git add -e documentation: rephrase note
From: Jeff King @ 2009-10-19 4:34 UTC (permalink / raw)
To: Miklos Vajna; +Cc: Junio C Hamano, git
In-Reply-To: <20091019000900.GV6115@genesis.frugalware.org>
On Mon, Oct 19, 2009 at 02:09:00AM +0200, Miklos Vajna wrote:
> Add a quick overview about what is OK and what is not to cover all
> cases.
>
> Signed-off-by: Miklos Vajna <vmiklos@frugalware.org>
> Signed-off-by: Jeff King <peff@peff.net>
Please be careful with sign-offs. While your patch text is an adaptation
of what I said, and while it is true that I personally would never say
anything on the list that was not free for use in git, I did not in fact
do such a sign-off, which is what that line is supposed to be
documenting.
In this case, I think you probably just wanted to say "text from Jeff
King" or even "From: Jeff King <peff@peff.net>".
That being said,
Signed-off-by: Jeff King <peff@peff.net>
:)
I still have a few comments, though.
> +The intent of this option is to pick and choose lines of the diff to
> +apply, or even to munge the lines. So it is safe to:
> ++
> +* remove lines with a "+" (don't stage the addition)
> +* munge any lines with a "+" (stage modified contents)
Do we want to use "munge" here? Maybe something a little more specific
like "modify the content of" is more appropriate for documentation.
> +* add lines with a "+" (stage an addition)
> +* convert lines with a " " to "-" (stage removal)
> +* convert lines with a "-" to " " (don't stage removal)
Is " " going to render in an obvious-to-read way? I checked the html
version and the manpage version in my terminal, and they looked OK, but
I would not be surprised if somebody has a font setup that makes it a
little hard to read.
> ++
> +It is a bad idea to:
> ++
Annoyingly, this renders for me as:
· convert lines with a "-" to " " (don’t stage removal)
It is a bad idea to:
· delete "-" lines
(the spacing of which will hopefully not be destroyed in transit). In
other words, the "+" list continuation makes the "it is a bad idea" text
part of the "good idea" list, instead of continuing the definition of
the "-e" option. I think we can fix it with an open block marker. I'll
see what I can do.
-Peff
^ permalink raw reply
* Re: [PATCH] git add -e documentation: rephrase note
From: Jeff King @ 2009-10-19 5:04 UTC (permalink / raw)
To: Miklos Vajna; +Cc: Junio C Hamano, git
In-Reply-To: <20091019043418.GD7170@coredump.intra.peff.net>
On Mon, Oct 19, 2009 at 12:34:18AM -0400, Jeff King wrote:
> I still have a few comments, though.
> [...]
> (the spacing of which will hopefully not be destroyed in transit). In
> other words, the "+" list continuation makes the "it is a bad idea" text
> part of the "good idea" list, instead of continuing the definition of
> the "-e" option. I think we can fix it with an open block marker. I'll
> see what I can do.
Hmph. Here is my attempt. The text is (I hope) more clear, but I am
still having trouble with the formatting. It looks fine in the HTML
version, and if I am reading the XML right, the XML is correct. But
docbook seems to screw up converting the XML to roff, giving this:
· convert removal lines to context lines (don’t stage removal)
Similarly, your patch will likely not apply if you:
· add context or removal lines
Am I missing something, or is it really a docbook bug? Does it render
better for anybody else?
-- >8 --
Subject: [PATCH] docs: give more hints about how "add -e" works
The original text was not very descriptive about what you
can and can't do; let's try to enumerate all cases.
Signed-off-by: Jeff King <peff@peff.net>
---
Documentation/git-add.txt | 22 +++++++++++++++++++---
1 files changed, 19 insertions(+), 3 deletions(-)
diff --git a/Documentation/git-add.txt b/Documentation/git-add.txt
index 45ebf87..b0a8420 100644
--- a/Documentation/git-add.txt
+++ b/Documentation/git-add.txt
@@ -86,9 +86,25 @@ OPTIONS
edit it. After the editor was closed, adjust the hunk headers
and apply the patch to the index.
+
-*NOTE*: Obviously, if you change anything else than the first character
-on lines beginning with a space or a minus, the patch will no longer
-apply.
+The intent of this option is to pick and choose lines of the diff to
+apply, or even to modify the contents of lines to be staged. There are
+three line types in a diff: addition lines (beginning with a plus),
+removal lines (beginning with a minus), and context lines (beginning
+with a space). In general, it should be safe to:
++
+--
+* remove addition lines (don't stage the line)
+* modify the content of any addition lines (stage modified contents)
+* add new addition lines (stage the new line)
+* convert context lines to removal lines (stage removal of line)
+* convert removal lines to context lines (don't stage removal)
+--
++
+Similarly, your patch will likely not apply if you:
++
+* add context or removal lines
+* delete removal or context lines
+* modify the contents of context or removal lines
-u::
--update::
--
1.6.5.1.123.gcaaf
^ 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