* Re: [RFC/PATCH] remote: add new sync command
From: Felipe Contreras @ 2011-11-08 17:31 UTC (permalink / raw)
To: Jeff King; +Cc: git
In-Reply-To: <20111107210134.GA7380@sigill.intra.peff.net>
On Mon, Nov 7, 2011 at 11:01 PM, Jeff King <peff@peff.net> wrote:
> On Mon, Nov 07, 2011 at 10:51:10PM +0200, Felipe Contreras wrote:
>
>> > What I don't understand is why it is not:
>> >
>> > git push --mirror <URL|remote>
>>
>> Because that pushes *everything*.
>
> Ahh, I think I see. It is doing --mirror, but only on a reduced refspec?
>
> In that case, is there a reason that:
>
> git push --prune <URL|remote> refs/heads/*
>
> would not do what you want (note that "--prune" does not exist, but I
> think it should).
I guess that should work.
>> > That's what I don't understand from your proposal. Your command is just
>> > pushing something to the remote, right? Why isn't "push" the command,
>> > and your sync options become options to push?
>>
>> How exactly? --sync-prune, --sync-new, --sync-all? But actually, I was
>> thinking on adding an option to sync the other way around; to get all
>> the remote branches and have them locally.
>
> If I understand correctly, you have three modes:
>
> 1. update remote refs with local values, prune anything remote that we
> don't have locally (--sync-prune)
>
> 2. update remote refs with local values, including pushing anything
> new that we don't have locally (--sync-new)
Anything new that we don't have *remotely*.
> 3. push new and prune (i.e., 1 and 2 together)
Yeap.
> If we had "git push --prune" as above, those would be:
>
> 1. git push --prune <remote> :
>
> I.e., use the "matching" refspec to not push new things, but turn
> on pruning.
I guess so, but ":" seems a bit obscure.
> 2. git push <remote> refs/heads/*
>
> Turn off pruning, but use an explicit refspec, not just "matching",
> which will push all local branches.
Isn't refs/heads/* the same as --all? BTW. I think --all is confusing,
should be --branches, or something.
> 3. git push --prune <remote> refs/heads/*
>
> Turn on both features.
Maybe 'git push' options should be reorganized (for 1.8.0):
--all -> --branches
--tags (same)
--mirror -> --all
--update = :
--prune (new)
In the meantime, we could add --update and --prune, which would not conflict.
>> Well, I usually have quite a lot of branches in my local repositories,
>> like a dozen of so. And I like to back them up in some remote
>> repository, however, not all the branches all the time. git push
>> --mirror not only pushes branches, but also tags (and I don't want
>> that), and even other refs. Does that clarifies things?
>
> That makes sense. But I think it fits in with git's current UI to do
> this via a combination of push options and refspecs. Even if we want to
> wrap it in some "git remote" command for convenience, I think what
> you're asking should be implemented as part of "git push".
Perhaps. I will give that a try, let's see how the code ends up.
But then, maybe similar options should be added to 'git fetch' to do
the same in the opposite direction, and that's where things get a bit
ugly:
--all -> rename to --all-remotes?
--prune -> rename to --prune-tracking?
--prune-local (new; prune local branches that don't exist on the remote)
--all (new; similar to 'git push --all' [--mirror])
--tags (same)
--update (new; similar to 'git push --update')
--branches (new; similar to 'git push --branches')
Somehow I fell there should be a 'sync' command somewhere to
differentiate these options from normal 'git fetch/push' commands.
Cheers.
--
Felipe Contreras
^ permalink raw reply
* Re: Checkout first version of each file?
From: Junio C Hamano @ 2011-11-08 17:44 UTC (permalink / raw)
To: Dario Rodriguez; +Cc: Git Mailing List
In-Reply-To: <CABLeVKF5P_sWwNX+OR_FX4+SPCN+SovZ2QuMmGGvJ-EskK7=YQ@mail.gmail.com>
Dario Rodriguez <soft.d4rio@gmail.com> writes:
> So, how can I checkout the first version of each file? (I know that
> GIT tracks contents and not files, but the fact is that I need to keep
> track on files, it's the real thing I work with)
In general "the first version of a file" is an undefined concept if your
history has merges of parallel development, but in a narrow special case
of linear history, you should be able to do something like this:
$ git log --format='# %h %s' --diff-filter=A --raw --abbrev=40
which would give you something like
# 8d19b44 Git 1.7.7.2
:000000 100644 0000000... e6bbef2... A Documentation/RelNotes/1.7.7.2.txt
# 0f77dea mingw: move poll out of sys-folder
:000000 100644 0000000... 708a6c9... A compat/win32/poll.c
:000000 100644 0000000... b7aa59d... A compat/win32/poll.h
# 8f41c07 read-cache.c: fix index memory allocation
:000000 100755 0000000... bca359d... A t/t7511-status-index.sh
...
so that you know what blobs to check out to which path. E.g.
$ mkdir -p compat/win32; git cat-file blob 708a6c9... >compat/win32/poll.c
^ permalink raw reply
* Re: [RFC/PATCH] remote: add new sync command
From: Junio C Hamano @ 2011-11-08 17:49 UTC (permalink / raw)
To: Felipe Contreras; +Cc: Jeff King, git
In-Reply-To: <CAMP44s0vsQ5sfx8arrRDo+-g9Zff_MmCz5t+yghwCMx_pL4Xzg@mail.gmail.com>
Felipe Contreras <felipe.contreras@gmail.com> writes:
> On Mon, Nov 7, 2011 at 11:25 PM, Junio C Hamano <gitster@pobox.com> wrote:
>> Jeff King <peff@peff.net> writes:
>>
>>> That makes sense. But I think it fits in with git's current UI to do
>>> this via a combination of push options and refspecs. Even if we want to
>>> wrap it in some "git remote" command for convenience, I think what
>>> you're asking should be implemented as part of "git push".
>>
>> Yeah, I think it makes sense to give --prune to "push" just like "fetch"
>> already has. These two are the primary (and in the ideal world, only)
>> operations that talk to the outside world. "remote add -f" might have been
>> a tempting "convenience" feature, but I personally think it probably was a
>> mistake for the exact reason that letting anything but "push" and "fetch"
>> talk to the outside world just invites more confusion. There does not have
>> to be 47 different ways to do the same thing.
>
> What about 'git remote update'?
If you asked, I would have to say that is probably a worse mistake in the
hindsight. I am guessing that back them "remote" command might have been a
tool meant only for the read-only customers and the verb "update" may have
made sense as "update me from the upstream", but these days "remote" also
helps the aspect of pushing things out (e.g. "set-url --push"), so "update"
that does not specify the direction is totally an inappropriate verb.
You _could_ argue that adding subcommands and options related to pushing
to "git remote" was a mistake. I don't care too much which side you would
choose to blame, but taken as the whole, in the current set of options,
subcommands and what "git remote" command does, "update" is a complete
misnomer.
^ permalink raw reply
* Re: [RFC/PATCH] remote: add new sync command
From: Felipe Contreras @ 2011-11-08 17:59 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jeff King, git
In-Reply-To: <7vvcquy05c.fsf@alter.siamese.dyndns.org>
On Tue, Nov 8, 2011 at 7:49 PM, Junio C Hamano <gitster@pobox.com> wrote:
> Felipe Contreras <felipe.contreras@gmail.com> writes:
>
>> On Mon, Nov 7, 2011 at 11:25 PM, Junio C Hamano <gitster@pobox.com> wrote:
>>> Jeff King <peff@peff.net> writes:
>>>
>>>> That makes sense. But I think it fits in with git's current UI to do
>>>> this via a combination of push options and refspecs. Even if we want to
>>>> wrap it in some "git remote" command for convenience, I think what
>>>> you're asking should be implemented as part of "git push".
>>>
>>> Yeah, I think it makes sense to give --prune to "push" just like "fetch"
>>> already has. These two are the primary (and in the ideal world, only)
>>> operations that talk to the outside world. "remote add -f" might have been
>>> a tempting "convenience" feature, but I personally think it probably was a
>>> mistake for the exact reason that letting anything but "push" and "fetch"
>>> talk to the outside world just invites more confusion. There does not have
>>> to be 47 different ways to do the same thing.
>>
>> What about 'git remote update'?
>
> If you asked, I would have to say that is probably a worse mistake in the
> hindsight. I am guessing that back them "remote" command might have been a
> tool meant only for the read-only customers and the verb "update" may have
> made sense as "update me from the upstream", but these days "remote" also
> helps the aspect of pushing things out (e.g. "set-url --push"), so "update"
> that does not specify the direction is totally an inappropriate verb.
>
> You _could_ argue that adding subcommands and options related to pushing
> to "git remote" was a mistake. I don't care too much which side you would
> choose to blame, but taken as the whole, in the current set of options,
> subcommands and what "git remote" command does, "update" is a complete
> misnomer.
Perhaps these 'git remote' commands should be removed in 1.8 then.
--
Felipe Contreras
^ permalink raw reply
* Re: [RFC/PATCH] remote: add new sync command
From: Jeff King @ 2011-11-08 18:14 UTC (permalink / raw)
To: Felipe Contreras; +Cc: git
In-Reply-To: <CAMP44s089xbEo4VT8rqgS=BJMUu=qsb8Hm5z8bTR2akU8-5QhA@mail.gmail.com>
On Tue, Nov 08, 2011 at 07:31:09PM +0200, Felipe Contreras wrote:
> > 2. update remote refs with local values, including pushing anything
> > new that we don't have locally (--sync-new)
>
> Anything new that we don't have *remotely*.
Sorry, yeah.
> > 1. git push --prune <remote> :
> >
> > I.e., use the "matching" refspec to not push new things, but turn
> > on pruning.
>
> I guess so, but ":" seems a bit obscure.
Yeah, it is. It's also the default, so you could just do:
git push --prune <remote>
Although some people have argued for changing the default in future
versions. I don't know what the status of that is.
> > 2. git push <remote> refs/heads/*
> >
> > Turn off pruning, but use an explicit refspec, not just "matching",
> > which will push all local branches.
>
> Isn't refs/heads/* the same as --all? BTW. I think --all is confusing,
> should be --branches, or something.
Doesn't --all mean all refs, including tags and branches? I thought that
was the thing you were avoiding. We could add syntactic sugar to make
--branches mean "refs/heads/*". But I do worry that pseudo-options like
that just end up creating more confusion (I seem to recall there being a
lot of confusion about "--tags", which is more or less the same thing).
-Peff
^ permalink raw reply
* Re: Checkout first version of each file?
From: Andreas Schwab @ 2011-11-08 18:15 UTC (permalink / raw)
To: Fredrik Gustafsson; +Cc: Dario Rodriguez, Git Mailing List
In-Reply-To: <20111108150007.GA5261@kolya>
Fredrik Gustafsson <iveqy@iveqy.com> writes:
> #!/bin/sh
> git reset --hard HEAD
> for f in `find`
git ls-files
> do
> commit=`git log $f | grep commit | tail -1`
git rev-list HEAD -- $f | tail -1
> git checkout $commit $f
> done
Andreas.
--
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
^ permalink raw reply
* Update install-doc-quick (Re* What's cooking in git.git (Nov 2011, #02; Sun, 6))
From: Junio C Hamano @ 2011-11-08 18:17 UTC (permalink / raw)
To: Stefan Näwe; +Cc: git@vger.kernel.org
In-Reply-To: <7v8vnqzitb.fsf@alter.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> Stefan Näwe <stefan.naewe@atlas-elektronik.com> writes:
>
>> This breaks the 'quick-install-{doc,html,man}' make targets, btw.
>
> Thanks. As the "push into kernel.org auto-rebuilds these branches"
> infrastructure is no longer available, I think we should remove these
> targets and description of them in the INSTALL file in the meantime.
>
> Anybody care to do a big removal patch?
Alternatively, we could keep it alive if people really want it, like this.
Stefan, care to apply it on top of 'maint' and try it out?
Documentation/Makefile | 23 +++++++++++++++-----
Documentation/install-doc-quick.sh | 40 +++++++++++++++++++++--------------
INSTALL | 29 ++-----------------------
3 files changed, 44 insertions(+), 48 deletions(-)
diff --git a/Documentation/Makefile b/Documentation/Makefile
index 6346a75..5a340fd 100644
--- a/Documentation/Makefile
+++ b/Documentation/Makefile
@@ -46,8 +46,8 @@ MANPAGE_XSL = manpage-normal.xsl
XMLTO_EXTRA =
INSTALL?=install
RM ?= rm -f
-DOC_REF = origin/man
-HTML_REF = origin/html
+MAN_REPO = ../../git-manpages
+HTML_REPO = ../../git-htmldocs
infodir?=$(prefix)/share/info
MAKEINFO=makeinfo
@@ -327,12 +327,23 @@ $(patsubst %.txt,%.html,$(wildcard howto/*.txt)): %.html : %.txt
install-webdoc : html
'$(SHELL_PATH_SQ)' ./install-webdoc.sh $(WEBDOC_DEST)
+# You must have a clone of git-htmldocs and git-manpages repositories
+# next to the git repository itself for the following to work.
+
quick-install: quick-install-man
-quick-install-man:
- '$(SHELL_PATH_SQ)' ./install-doc-quick.sh $(DOC_REF) $(DESTDIR)$(mandir)
+require-manrepo::
+ @if test ! -d $(MAN_REPO); \
+ then echo "git-manpages repository must exist at $(MAN_REPO)"; exit 1; fi
+
+quick-install-man: require-manrepo
+ '$(SHELL_PATH_SQ)' ./install-doc-quick.sh $(MAN_REPO) $(DESTDIR)$(mandir)
+
+require-htmlrepo::
+ @if test ! -d $(HTML_REPO); \
+ then echo "git-htmldocs repository must exist at $(HTML_REPO)"; exit 1; fi
-quick-install-html:
- '$(SHELL_PATH_SQ)' ./install-doc-quick.sh $(HTML_REF) $(DESTDIR)$(htmldir)
+quick-install-html: require-htmlrepo
+ '$(SHELL_PATH_SQ)' ./install-doc-quick.sh $(HTML_REPO) $(DESTDIR)$(htmldir)
.PHONY: FORCE
diff --git a/Documentation/install-doc-quick.sh b/Documentation/install-doc-quick.sh
index 35f4408..bbf0a21 100755
--- a/Documentation/install-doc-quick.sh
+++ b/Documentation/install-doc-quick.sh
@@ -1,29 +1,37 @@
#!/bin/sh
-# This requires a branch named in $head
-# (usually 'man' or 'html', provided by the git.git repository)
-set -e
-head="$1"
-mandir="$2"
-SUBDIRECTORY_OK=t
-USAGE='<refname> <target directory>'
-. "$(git --exec-path)"/git-sh-setup
-cd_to_toplevel
+# This requires git-manpages and/or git-htmldocs repositories
-test -z "$mandir" && usage
-if ! git rev-parse --verify "$head^0" >/dev/null; then
- echo >&2 "head: $head does not exist in the current repository"
- usage
+repository=${1?repository}
+destdir=${2?destination}
+
+head=master GIT_DIR=
+for d in "$repository/.git" "$repository"
+do
+ if GIT_DIR="$d" git rev-parse refs/heads/master >/dev/null 2>&1
+ then
+ GIT_DIR="$d"
+ export GIT_DIR
+ break
+ fi
+done
+
+if test -z "$GIT_DIR"
+then
+ echo >&2 "Neither $repository nor $repository/.git is a repository"
+ exit 1
fi
-GIT_INDEX_FILE=`pwd`/.quick-doc.index
-export GIT_INDEX_FILE
+GIT_WORK_TREE=$(pwd)
+GIT_INDEX_FILE=$(pwd)/.quick-doc.$$
+export GIT_INDEX_FILE GIT_WORK_TREE
rm -f "$GIT_INDEX_FILE"
trap 'rm -f "$GIT_INDEX_FILE"' 0
git read-tree $head
git checkout-index -a -f --prefix="$mandir"/
-if test -n "$GZ"; then
+if test -n "$GZ"
+then
git ls-tree -r --name-only $head |
xargs printf "$mandir/%s\n" |
xargs gzip -f
diff --git a/INSTALL b/INSTALL
index bbb9d4d..bf0d97e 100644
--- a/INSTALL
+++ b/INSTALL
@@ -139,34 +139,11 @@ Issues of note:
uses some compatibility wrappers to work on AsciiDoc 8. If you have
AsciiDoc 7, try "make ASCIIDOC7=YesPlease".
- Alternatively, pre-formatted documentation is available in
- "html" and "man" branches of the git repository itself. For
- example, you could:
-
- $ mkdir manual && cd manual
- $ git init
- $ git fetch-pack git://git.kernel.org/pub/scm/git/git.git man html |
- while read a b
- do
- echo $a >.git/$b
- done
- $ cp .git/refs/heads/man .git/refs/heads/master
- $ git checkout
-
- to checkout the pre-built man pages. Also in this repository:
-
- $ git checkout html
-
- would instead give you a copy of what you see at:
-
- http://www.kernel.org/pub/software/scm/git/docs/
-
There are also "make quick-install-doc", "make quick-install-man"
and "make quick-install-html" which install preformatted man pages
- and html documentation.
- This does not require asciidoc/xmlto, but it only works from within
- a cloned checkout of git.git with these two extra branches, and will
- not work for the maintainer for obvious chicken-and-egg reasons.
+ and html documentation. To use these build targets, you need to
+ clone two separate git-htmldocs and git-manpages repositories next
+ to the clone of git itself.
It has been reported that docbook-xsl version 1.72 and 1.73 are
buggy; 1.72 misformats manual pages for callouts, and 1.73 needs
^ permalink raw reply related
* Re: Checkout first version of each file?
From: Dario Rodriguez @ 2011-11-08 18:49 UTC (permalink / raw)
To: Andreas Schwab; +Cc: Fredrik Gustafsson, Git Mailing List
In-Reply-To: <m239dypjkd.fsf@igel.home>
On Tue, Nov 8, 2011 at 3:15 PM, Andreas Schwab <schwab@linux-m68k.org> wrote:
> Fredrik Gustafsson <iveqy@iveqy.com> writes:
>
>> #!/bin/sh
>> git reset --hard HEAD
>> for f in `find`
> git ls-files
>> do
>> commit=`git log $f | grep commit | tail -1`
> git rev-list HEAD -- $f | tail -1
>> git checkout $commit $f
>> done
>
> Andreas.
>
> --
> Andreas Schwab, schwab@linux-m68k.org
> GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
> "And now for something completely different."
>
Thank you again guys,
Junio, as part of the options applicable to diff-* commands, git-log
can take '--name-only' as argument. As the functionality of git log is
to show commit logs (the user way) I wonder if we have some similar,
parallel way to show a list of blobs. I mean, maybe the user (as in my
case) doesn't want the list of files, but the list of blobs, and the
raw format is not a clean, friendly output.
I can just: 'git log --oneline --name-only --diff-filter=A', but i
cannot list blobs for each commit the same simple way.
Just a suggestion, I think a little script fits better for me now.
Thank you,
Dario
^ permalink raw reply
* Re: [fyi] patches used by git distributors
From: Junio C Hamano @ 2011-11-08 20:41 UTC (permalink / raw)
To: Jonathan Nieder; +Cc: git
In-Reply-To: <20111108090251.GB17954@elie.hsd1.il.comcast.net>
Jonathan Nieder <jrnieder@gmail.com> writes:
Note that I didn't check any of the patches that are not linked in
references section.
> Gerrit Pape (1):
> bug#506445: hooks/post-receive-email: set encoding to utf-8 [2]
>
> Jonathan Nieder (12):
> remove shebang line from shell libraries [3]
If this is about git-sh-setup, I think it is probably a good idea to
upstream it.
> pre-rebase hook: capture documentation in a <<here document [4]
I do not mind this but if you are to do so you should remove the "exit 0"
before that block.
> transport: expose git_tcp_connect and friends in new tcp.h [5]
> daemon: make host resolution into a separate function [5]
> daemon: move locate_host to tcp.c [5]
> tcp: unify ipv4 and ipv6 code paths [5]
> daemon: check for errors retrieving IP address [5]
> tcp: make dns_resolve return an error code [5]
> transport: optionally honor DNS SRV records [5]
> srv: make errors less quiet [5]
It seems that this received almost no interest from anybody. I suspect
that the reason was because the cover letter was poorly written that
people did not realize the need for it.
> Makefile: add a knob to turn off hardlinks within same directory [6]
I think the real fix for this issue should be either made in btrfs or even
better "tar x", instead of forcing everybody who consumes a tarball to use
symlink or copies. That is, work-around should be made when a _particular_
recipient wants to extract a tarball that stores hardlinks to the same
inode than the filesystem the recipient _happens_ to be trying to extract
it on, not before.
^ permalink raw reply
* Re: [fyi] patches used by git distributors
From: Junio C Hamano @ 2011-11-08 20:45 UTC (permalink / raw)
To: Jonathan Nieder; +Cc: git
In-Reply-To: <7vmxc6xs73.fsf@alter.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
-ECANNOTPARSE, sorry.
... That is, work-around should be made when a _particular_
recipient wants to extract a tarball that stores more hardlinks to the same
inode than the filesystem the recipient _happens_ to be trying to extract
it on supports.
^ permalink raw reply
* git svn rebase bug
From: Matt Arsenault @ 2011-11-08 20:50 UTC (permalink / raw)
To: git
There seems to be a bug using git svn rebase with strategies
git version 1.7.7.2
$ git svn rebase --strategy=theirs
First, rewinding head to replay your work on top of it...
/usr/lib/git-core/git-rebase--merge: line 69: git-merge-theirs: command not found
Unknown exit code (127) from command: git-merge-theirs deabad54a6d5ce3ab3f655e06b9c24eadbba6f6c^ -- HEAD deabad54a6d5ce3ab3f655e06b9c24eadbba6f6c
rebase --strategy=theirs refs/remotes/git-svn: command returned error: 1
^ permalink raw reply
* Re: git-apply that handles rejects like merge conflicts
From: Ori Avtalion @ 2011-11-08 20:50 UTC (permalink / raw)
To: Jeff King; +Cc: Junio C Hamano, git
In-Reply-To: <20111108054643.GC29643@sigill.intra.peff.net>
On 11/08/2011 07:46 AM, Jeff King wrote:
> On Mon, Nov 07, 2011 at 03:45:48PM -0800, Junio C Hamano wrote:
> But I think there are two questions:
>
[ snip ]
>
> I'm actually not sure which one Ori was asking about.
>
I'm actually interested in both :)
Here's a copy of the description of my problem from another reply:
> I'm dealing with two codebases that have branched in the past, before
> any VCS was used, and now I'm tracking both separately with git. I'm
> trying to apply changes from one to the other with format-patch and
> git-am/apply.
In answer to your first question
> 1. Should am's 3-way fallback be made more easily available to users
> of regular "apply"?
git-am is never part of this workflow as I'm trying to move patches
between separate repositories with no shared root.
<rant>
And, personally, I don't think git-am is named correctly as the only
use-case I have for it is applying+committing single patches produced by
format-patch and sent as individual files over some medium which isn't
mboxes (I'm not that old-school). I never understood why git-apply can't
do the commit and I have to instead use a tool with 'mail' in its name
(Let's ignore the historical reasons) -- Shouldn't git-am be an
mbox-reading wrapper around some more basic patch-applying tool?
</rant>
>> 2. Short of doing a 3-way merge, are there better ways to represent
>> failed hunks in the patch target itself, rather than saving ".rej"
>> files?
I really want this as .rej files feel very un-git-like. However, after
understanding the problems raised in this thread, I'm a bit more
realistic :)
-Ori
^ permalink raw reply
* Re: Update install-doc-quick (Re* What's cooking in git.git (Nov 2011, #02; Sun, 6))
From: Stefan Naewe @ 2011-11-08 20:59 UTC (permalink / raw)
To: git
In-Reply-To: <7vr51ixyuz.fsf_-_@alter.siamese.dyndns.org>
Junio C Hamano <gitster <at> pobox.com> writes:
>
> Junio C Hamano <gitster <at> pobox.com> writes:
>
> > Stefan Näwe <stefan.naewe <at> atlas-elektronik.com> writes:
> >
> >> This breaks the 'quick-install-{doc,html,man}' make targets, btw.
> >
> > Thanks. As the "push into kernel.org auto-rebuilds these branches"
> > infrastructure is no longer available, I think we should remove these
> > targets and description of them in the INSTALL file in the meantime.
> >
> > Anybody care to do a big removal patch?
>
> Alternatively, we could keep it alive if people really want it, like this.
Yes!
> Stefan, care to apply it on top of 'maint' and try it out?
(That was a little harder than I thought, because the patch got garbled
when I added '/raw' to the URL in gmane. Had to use a news reader to
get an 'applyable' version).
>
> git read-tree $head
> git checkout-index -a -f --prefix="$mandir"/
-git checkout-index -a -f --prefix="$mandir"/
+git checkout-index -a -f --prefix="$destdir"/
> -if test -n "$GZ"; then
> +if test -n "$GZ"
> +then
> git ls-tree -r --name-only $head |
> xargs printf "$mandir/%s\n" |
- xargs printf "$mandir/%s\n" |
+ xargs printf "$destdir/%s\n" |
Works for me.
Thanks,
Stefan
^ permalink raw reply
* Re: git-apply that handles rejects like merge conflicts
From: Jeff King @ 2011-11-08 21:00 UTC (permalink / raw)
To: Ori Avtalion; +Cc: Junio C Hamano, git
In-Reply-To: <4EB9962B.8060809@avtalion.name>
On Tue, Nov 08, 2011 at 10:50:51PM +0200, Ori Avtalion wrote:
> In answer to your first question
> > 1. Should am's 3-way fallback be made more easily available to users
> > of regular "apply"?
>
> git-am is never part of this workflow as I'm trying to move patches
> between separate repositories with no shared root.
Isn't git-am the right tool for that? You format-patch out your commits
in one repo, and then apply them in the other. No shared history is
required; just the ability of the patches to actually be applied.
It _helps_ if you have the common base objects (the actual files, not
the commits), since the git diffs carry the pre- and post-image file
sha1s, which is what allows us to do a real 3-way merge. In that case,
it is just a matter of making the objects from the first repo available
to git during the moment you are applying in the second repo. You could
do it by fetching the history of the first into a side-branch of the
second, or even just by sharing object databases via the "alternates"
mechanism.
> <rant>
> And, personally, I don't think git-am is named correctly as the only
> use-case I have for it is applying+committing single patches produced by
> format-patch and sent as individual files over some medium which isn't
> mboxes (I'm not that old-school). I never understood why git-apply can't
> do the commit and I have to instead use a tool with 'mail' in its name
> (Let's ignore the historical reasons) -- Shouldn't git-am be an
> mbox-reading wrapper around some more basic patch-applying tool?
> </rant>
git-am _is_ an mbox-reading wrapper around some more basic
patch-applying tool. That tool is "git apply". I think what you are
missing is that a single patch (or multiple patches) produced by
format-patch _is_ an mbox. There is nothing wrong with:
cd repo1 &&
git format-patch -1 --stdout >../my.patch &&
cd ../repo2 &&
git am ../my.patch
There is no standard for representing commit metadata in the diff
format. So git had to invent its own. It used rfc822 messages and
mailboxes because it was simple and convenient, it mapped to what some
people were already doing, and it means we don't need a separate tool
for applying local commits versus ones that were emailed.
So the "m" is really for mbox, which happens to be git's format for
storing one or more commits, including metadata. If you just forget that
it's associated with mail, then I think you will be happy. :)
-Peff
^ permalink raw reply
* Re: git log --quiet bug?
From: Jeff King @ 2011-11-08 21:29 UTC (permalink / raw)
To: Prasad Deshpande; +Cc: Junio C Hamano, git@vger.kernel.org
In-Reply-To: <1320762978.3614.YahooMailNeo@web84005.mail.mud.yahoo.com>
On Tue, Nov 08, 2011 at 06:36:18AM -0800, Prasad Deshpande wrote:
> I am seeing a bug with git log --quiet. It doesn't seem to be quiet
> :-). Also I have seen cases where the exit status returned is not
> correct i.e. its 0 even if there is some output (although I cant seem
> to reproduce that problem at present).
I think the description of "--quiet" in the git-log manpage is
accidentally inherited by including the diff options. In "git diff", it
stops output and makes the exit code useful for determining whether
there were changes. But what does the exit code even mean in the context
of "git log"?
It does look like there is code in "git log" to handle --quiet, and
convert it to "no diff output" (i.e., like "-s"). But it doesn't seem to
do anything. If I manually specify a format like "git log -p --quiet", I
still get output. And if I don't say "-p", then I wouldn't get diff
output anyway. It does seem to have an impact on other log variants that
have output by default (e.g., "git whatchanged --quiet" won't show the
usual raw diffs).
I think we should probably just excise it from the git-log manpage, like
this:
-- >8 --
Subject: [PATCH] docs: don't mention --quiet or --exit-code in git-log(1)
These are diff-options, but they don't actually make sense
in the context of log.
Signed-off-by: Jeff King <peff@peff.net>
---
Documentation/diff-options.txt | 2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/Documentation/diff-options.txt b/Documentation/diff-options.txt
index 08b581f..9f7cba2 100644
--- a/Documentation/diff-options.txt
+++ b/Documentation/diff-options.txt
@@ -412,15 +412,17 @@ endif::git-format-patch[]
--function-context::
Show whole surrounding functions of changes.
ifndef::git-format-patch[]
+ifndef::git-log[]
--exit-code::
Make the program exit with codes similar to diff(1).
That is, it exits with 1 if there were differences and
0 means no differences.
--quiet::
Disable all output of the program. Implies `--exit-code`.
+endif::git-log[]
endif::git-format-patch[]
--ext-diff::
Allow an external diff helper to be executed. If you set an
--
1.7.7.2.7.g9f96f
^ permalink raw reply related
* Re: Update install-doc-quick (Re* What's cooking in git.git (Nov 2011, #02; Sun, 6))
From: Junio C Hamano @ 2011-11-08 21:34 UTC (permalink / raw)
To: Stefan Naewe; +Cc: git
In-Reply-To: <loom.20111108T215341-107@post.gmane.org>
Thanks.
-- >8 --
Subject: [PATCH] docs: Update install-doc-quick
The preformatted documentation pages live in their own repositories
these days. Adjust the installation procedure to the updated layout.
Tested-by: Stefan Naewe <stefan.naewe@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
Documentation/Makefile | 23 ++++++++++++++-----
Documentation/install-doc-quick.sh | 44 +++++++++++++++++++++--------------
INSTALL | 29 ++---------------------
3 files changed, 46 insertions(+), 50 deletions(-)
diff --git a/Documentation/Makefile b/Documentation/Makefile
index 6346a75..5a340fd 100644
--- a/Documentation/Makefile
+++ b/Documentation/Makefile
@@ -46,8 +46,8 @@ MANPAGE_XSL = manpage-normal.xsl
XMLTO_EXTRA =
INSTALL?=install
RM ?= rm -f
-DOC_REF = origin/man
-HTML_REF = origin/html
+MAN_REPO = ../../git-manpages
+HTML_REPO = ../../git-htmldocs
infodir?=$(prefix)/share/info
MAKEINFO=makeinfo
@@ -327,12 +327,23 @@ $(patsubst %.txt,%.html,$(wildcard howto/*.txt)): %.html : %.txt
install-webdoc : html
'$(SHELL_PATH_SQ)' ./install-webdoc.sh $(WEBDOC_DEST)
+# You must have a clone of git-htmldocs and git-manpages repositories
+# next to the git repository itself for the following to work.
+
quick-install: quick-install-man
-quick-install-man:
- '$(SHELL_PATH_SQ)' ./install-doc-quick.sh $(DOC_REF) $(DESTDIR)$(mandir)
+require-manrepo::
+ @if test ! -d $(MAN_REPO); \
+ then echo "git-manpages repository must exist at $(MAN_REPO)"; exit 1; fi
+
+quick-install-man: require-manrepo
+ '$(SHELL_PATH_SQ)' ./install-doc-quick.sh $(MAN_REPO) $(DESTDIR)$(mandir)
+
+require-htmlrepo::
+ @if test ! -d $(HTML_REPO); \
+ then echo "git-htmldocs repository must exist at $(HTML_REPO)"; exit 1; fi
-quick-install-html:
- '$(SHELL_PATH_SQ)' ./install-doc-quick.sh $(HTML_REF) $(DESTDIR)$(htmldir)
+quick-install-html: require-htmlrepo
+ '$(SHELL_PATH_SQ)' ./install-doc-quick.sh $(HTML_REPO) $(DESTDIR)$(htmldir)
.PHONY: FORCE
diff --git a/Documentation/install-doc-quick.sh b/Documentation/install-doc-quick.sh
index 35f4408..327f69b 100755
--- a/Documentation/install-doc-quick.sh
+++ b/Documentation/install-doc-quick.sh
@@ -1,31 +1,39 @@
#!/bin/sh
-# This requires a branch named in $head
-# (usually 'man' or 'html', provided by the git.git repository)
-set -e
-head="$1"
-mandir="$2"
-SUBDIRECTORY_OK=t
-USAGE='<refname> <target directory>'
-. "$(git --exec-path)"/git-sh-setup
-cd_to_toplevel
+# This requires git-manpages and/or git-htmldocs repositories
-test -z "$mandir" && usage
-if ! git rev-parse --verify "$head^0" >/dev/null; then
- echo >&2 "head: $head does not exist in the current repository"
- usage
+repository=${1?repository}
+destdir=${2?destination}
+
+head=master GIT_DIR=
+for d in "$repository/.git" "$repository"
+do
+ if GIT_DIR="$d" git rev-parse refs/heads/master >/dev/null 2>&1
+ then
+ GIT_DIR="$d"
+ export GIT_DIR
+ break
+ fi
+done
+
+if test -z "$GIT_DIR"
+then
+ echo >&2 "Neither $repository nor $repository/.git is a repository"
+ exit 1
fi
-GIT_INDEX_FILE=`pwd`/.quick-doc.index
-export GIT_INDEX_FILE
+GIT_WORK_TREE=$(pwd)
+GIT_INDEX_FILE=$(pwd)/.quick-doc.$$
+export GIT_INDEX_FILE GIT_WORK_TREE
rm -f "$GIT_INDEX_FILE"
trap 'rm -f "$GIT_INDEX_FILE"' 0
git read-tree $head
-git checkout-index -a -f --prefix="$mandir"/
+git checkout-index -a -f --prefix="$destdir"/
-if test -n "$GZ"; then
+if test -n "$GZ"
+then
git ls-tree -r --name-only $head |
- xargs printf "$mandir/%s\n" |
+ xargs printf "$destdir/%s\n" |
xargs gzip -f
fi
rm -f "$GIT_INDEX_FILE"
diff --git a/INSTALL b/INSTALL
index bbb9d4d..bf0d97e 100644
--- a/INSTALL
+++ b/INSTALL
@@ -139,34 +139,11 @@ Issues of note:
uses some compatibility wrappers to work on AsciiDoc 8. If you have
AsciiDoc 7, try "make ASCIIDOC7=YesPlease".
- Alternatively, pre-formatted documentation is available in
- "html" and "man" branches of the git repository itself. For
- example, you could:
-
- $ mkdir manual && cd manual
- $ git init
- $ git fetch-pack git://git.kernel.org/pub/scm/git/git.git man html |
- while read a b
- do
- echo $a >.git/$b
- done
- $ cp .git/refs/heads/man .git/refs/heads/master
- $ git checkout
-
- to checkout the pre-built man pages. Also in this repository:
-
- $ git checkout html
-
- would instead give you a copy of what you see at:
-
- http://www.kernel.org/pub/software/scm/git/docs/
-
There are also "make quick-install-doc", "make quick-install-man"
and "make quick-install-html" which install preformatted man pages
- and html documentation.
- This does not require asciidoc/xmlto, but it only works from within
- a cloned checkout of git.git with these two extra branches, and will
- not work for the maintainer for obvious chicken-and-egg reasons.
+ and html documentation. To use these build targets, you need to
+ clone two separate git-htmldocs and git-manpages repositories next
+ to the clone of git itself.
It has been reported that docbook-xsl version 1.72 and 1.73 are
buggy; 1.72 misformats manual pages for callouts, and 1.73 needs
--
1.7.8.rc1.82.g90e080
^ permalink raw reply related
* Re: git log --quiet bug?
From: Junio C Hamano @ 2011-11-08 21:37 UTC (permalink / raw)
To: Jeff King; +Cc: Prasad Deshpande, git@vger.kernel.org
In-Reply-To: <20111108212930.GA18529@sigill.intra.peff.net>
Thanks, the patch makes sense to me.
^ permalink raw reply
* Re: [PATCH v2 00/12] Pulling signed/annotated tags
From: Junio C Hamano @ 2011-11-08 21:45 UTC (permalink / raw)
To: git; +Cc: Linus Torvalds
In-Reply-To: <7vobwnyy2m.fsf@alter.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> Here is what I had in mind....
And then I changed my mind again. Using a single SP indent for multi-line
header fields make things easy to view.
| tree 20009beb1d5d0494347db5afbe80b364563dd511
| parent 8457d13895251ebf2f839ee6f74dd0087fb56334
| parent 6486ca6d77eaf4109b26b70da0b3a0158868e22f
| author Junio C Hamano <gitster@pobox.com> 1320781099 -0800
| committer Junio C Hamano <gitster@pobox.com> 1320781099 -0800
| mergetag object 6486ca6d77eaf4109b26b70da0b3a0158868e22f
| type commit
| tag test-tag
| tagger Junio C Hamano <gitster@pobox.com> 1320471226 -0700
|
| test merge
| -----BEGIN PGP SIGNATURE-----
| Version: GnuPG v1.4.10 (GNU/Linux)
|
| iQIcBAABAgAGBQJOtMq7AAoJELC16IaWr+bLL30P/iEhPR+gkOpF09EshWZy7Vbu
| ...
| =eJX/
| -----END PGP SIGNATURE-----
|
| Merge tag 'test-tag' of ../git into HEAD
|
| test merge
I am redoing the "signed-commit" series to also use this format.
The way I made the tag available to commit_tree() turned out to be a bit
too clever, by the way, and it would cause problems down the road when
these things need to be amended. Embedded "gpgsig" in a commit is about
the commit itself, and should not be carried over, but "mergetag" is about
the parent and should not be lost only because you wanted to fix a type
in your merge log message. I'll be redoing that part in the series and
hopefully the finished result would be ready for review after 1.7.8 final.
^ permalink raw reply
* Re: Benchmarks regarding git's gc
From: Jeff King @ 2011-11-08 21:58 UTC (permalink / raw)
To: Brandon Casey; +Cc: Felipe Contreras, git
In-Reply-To: <CA+sFfMdax6UYsi2ojGWQT_TdPSMPGMGRZA3jz+VaENmbs4buzQ@mail.gmail.com>
On Tue, Nov 08, 2011 at 10:40:15AM -0600, Brandon Casey wrote:
> On Tue, Nov 8, 2011 at 5:34 AM, Felipe Contreras
> <felipe.contreras@gmail.com> wrote:
> > Has anybody seen these?
> > http://draketo.de/proj/hg-vs-git-server/test-results.html#results
> >
> > Seems like a potential area of improvement.
>
> I think this is a case of designing the problem space so that your
> intended winner wins and your intended loser loses.
Sort of. It is a real problem space, and mercurial does have some
advantage in that area.
His problem definition is that of a git-backed server database that is
under constant load creating new commits. So imagine wikipedia backed by
git.
Mercurial's strategy (as I understand it) is to always calculate and
store deltas as new commits are created. Git's strategy is to store full
objects, and then worry about deltification later. So of course git is
going to do more work, and especially more I/O.
Git's strategy is fine for the workload for which it was designed:
people making commits in burst, and occasionally doing book-keeping to
make things smaller.
But for a constant-commit workflow, the burstiness is annoying, and the
amount of I/O can be cumbersome. We realized this long ago when
importing old histories into git. And that's why fast-import was born:
it does at least a minimal level of delta and puts everything into a
single packfile, instead of writing out loose objects.
If you were writing commits at some fast constant rate into your
repository, then you'd probably want to do the same thing. And it would
be fairly easy to do on top of git's object model. At best, it's just a
specialized commit command (like fast-import), and at worst it's
probably a more incremental object store.
So he may have a point that mercurial might perform better for some
metrics than git in the current state. But I think a lot of that is
because nobody has bothered putting git into this situation and done the
tweaks needed to make it fast. You can argue that git sucks because it
needs tweaking, of course, but if I were picking between the two systems
to implement something like this, I'd consider picking git and doing the
tweaks (of course, I'm far from unbiased).
-Peff
^ permalink raw reply
* git-svn: t9155 fails against subversion 1.7.0
From: Frans Klaver @ 2011-11-08 22:09 UTC (permalink / raw)
To: git@vger.kernel.org
For kicks I decided to run the tests and noticed that on master
t9155-git-svn-fetch-deleted-tag fails against svn 1.7.0. We hit an
assertion in subversion's dirent_uri.c, stating that we don't provide a
canonical url. I haven't tested against other subversion versions. I dare
assume that this issue doesn't arise on earlier versions. It probably
won't affect a lot of users right now, but it will in the future.
Here's some verbose test output:
expecting success:
git svn init --stdlayout "$svnrepo" git_project &&
cd git_project &&
git svn fetch &&
git diff --exit-code mybranch:trunk/subdir/file tags/mytag:file &&
git diff --exit-code master:subdir/file tags/mytag^:file
Initialized empty Git repository in /home/frans/devsw/git/t/trash
directory.t9155-git-svn-fetch-deleted-tag/git_project/.git/
svn: E235000: In file 'subversion/libsvn_subr/dirent_uri.c' line 2291:
assertion failed (svn_uri_is_canonical(url, pool))
error: git-svn died of signal 6
not ok - 2 fetch deleted tags from same revision with checksum error
I've been trying to debug and got down to:
Git::SVN::Ra::new(/home/frans/devsw/git/git-svn:5496):
5496: my $self = SVN::Ra->new(url => escape_url($url), auth => $baton,
5497: config => $config,
5498: pool => SVN::Pool->new,
5499: auth_provider_callbacks => $callbacks);
...
SVN::Ra::new(/usr/lib/perl5/vendor_perl/5.12.4/i686-linux/SVN/Ra.pm:529):
529: $self->{session} = SVN::_Ra::svn_ra_open($self->{url}, $callback,
$self->{config} || {}, $pool);
DB<3> p $self->{url}
file:///home/frans/devsw/git/t/trash
directory.t9155-git-svn-fetch-deleted-tag/svnrepo
The url looks like that throughout the stack (as far as I've seen), so if
it is wrong, it is probably wrong at top-level. Hope someone with a bit
more experience knows how to deal with this.
Thanks,
Frans
^ permalink raw reply
* Re: git log --quiet bug?
From: Jeff King @ 2011-11-08 23:20 UTC (permalink / raw)
To: Prasad Deshpande; +Cc: Junio C Hamano, git@vger.kernel.org
In-Reply-To: <1320791465.67359.YahooMailNeo@web84006.mail.mud.yahoo.com>
On Tue, Nov 08, 2011 at 02:31:05PM -0800, Prasad Deshpande wrote:
> Thanks for your response. I was actually trying to write a script to
> determine if a workspace has commits which haven't been pushed to the
> repository.
> For this I was using the following in a bash script:
>
> ..
> git log origin..HEAD --quiet
> if [ $? -ne 0 ]
> then
> echo
>
> echo "git log shows files committed but not pushed.. ABORTING"
> echo
> echo "************* `pwd` ***************"
> git log origin..HEAD --color --graph --stat
> exit 1
> fi
>
> What is the recommended way to do this?
Try:
test -z "$(git rev-list -1 origin..HEAD)" &&
echo nothing that needs pushing
You can also use --count to get the exact number, but if you just care
whether there is something or nothing, using "-1" lets git stop the
graph traversal immediately.
-Peff
^ permalink raw reply
* Re: git log --quiet bug?
From: Junio C Hamano @ 2011-11-09 0:04 UTC (permalink / raw)
To: Jeff King; +Cc: Prasad Deshpande, Junio C Hamano, git@vger.kernel.org
In-Reply-To: <20111108232043.GA21957@sigill.intra.peff.net>
Jeff King <peff@peff.net> writes:
> Try:
>
> test -z "$(git rev-list -1 origin..HEAD)" &&
> echo nothing that needs pushing
>
> You can also use --count to get the exact number, but if you just care
> whether there is something or nothing, using "-1" lets git stop the
> graph traversal immediately.
Doesn't some variant of "branch -v" show the ahead/behind information for
all branches?
^ permalink raw reply
* RFH: unexpected reflog behavior with --since=
From: Eric Raible @ 2011-11-09 0:22 UTC (permalink / raw)
To: git@vger.kernel.org
I'm trying to leverage the reflog to speed up our $dayjob build procedure
(it's complicated), and found unexpected behavior when limiting reflog
output with --since.
git init reflog-test
cd reflog-test
touch a && git add a && git commit -m'add a'
sleep 1
touch b && git add b && git commit -m'add b'
# add_b will be the time that b was added (email ends with '>')
add_b=$(tail -1 .git/logs/HEAD | perl -e "print( <> =~ m/> (\S+)/ )")
# It's reported correctly here:
git log -g --oneline --since=$add_b
# But after a reset no history isn't shown.
git reset --hard HEAD^
git log -g --oneline --since=$add_b
Is this a bug? Of course everything is reported when --since isn't used,
but not so when limited with --since.
1.7.7.1.msysgit.0
Thanks - Eric
^ permalink raw reply
* Re: [PATCH v0] fast-import: Add drop command
From: Vitor Antunes @ 2011-11-09 0:24 UTC (permalink / raw)
To: Sverre Rabbelier; +Cc: Dmitry Ivankov, Jonathan Nieder, git, David Barr
In-Reply-To: <CAGdFq_hSnywznK=3JgWBVigGZmS0ry_WHuuDww5tvPrcsPd7cQ@mail.gmail.com>
Hi Sverre,
Sorry for the late reply.
On Thu, Oct 27, 2011 at 3:36 PM, Sverre Rabbelier <srabbelier@gmail.com> wrote:
> Ok, so the problem is that fast-import notices that a tree that was
> written out as part of a checkpoint is later removed and doesn't like
> that? Shouldn't we just teach the check about trees deleted by the
> drop command?
That was exactly my intention when I used release_tree_entry(). But I
guess I'm doing it wrong, because without the delete_ref() part this
does not work (just noticed there's a missing semicolon there...
sorry). Any advices/guidance, please? :)
--
Vitor Antunes
^ permalink raw reply
* Re: [PATCH v0] fast-import: Add drop command
From: Sverre Rabbelier @ 2011-11-09 0:27 UTC (permalink / raw)
To: Vitor Antunes; +Cc: Dmitry Ivankov, Jonathan Nieder, git, David Barr
In-Reply-To: <CAOpHH-X3bgJpRpiJMy-iDDpaFbUy8yZK+GFEwVB2vGHd-GpUiw@mail.gmail.com>
Heya,
On Wed, Nov 9, 2011 at 01:24, Vitor Antunes <vitor.hda@gmail.com> wrote:
> On Thu, Oct 27, 2011 at 3:36 PM, Sverre Rabbelier <srabbelier@gmail.com> wrote:
>> Ok, so the problem is that fast-import notices that a tree that was
>> written out as part of a checkpoint is later removed and doesn't like
>> that? Shouldn't we just teach the check about trees deleted by the
>> drop command?
>
> That was exactly my intention when I used release_tree_entry(). But I
> guess I'm doing it wrong, because without the delete_ref() part this
> does not work (just noticed there's a missing semicolon there...
> sorry). Any advices/guidance, please? :)
ENODATA. What do you mean with "does not work"? Can you run it through
gdb and see what's going on?
--
Cheers,
Sverre Rabbelier
^ 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