* Re: git binary directory?
From: Junio C Hamano @ 2005-11-06 2:49 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Git Mailing List
In-Reply-To: <Pine.LNX.4.64.0511051247330.3316@g5.osdl.org>
Linus Torvalds <torvalds@osdl.org> writes:
> Now, I happen to think that 2500+ files in /usr/bin is a bit much (ever
> try to use the horrid gnome executable finder on it when you want to
> convince firefox to use xpdf instead of that broken crap called "evince"?
> Takes absolutely ages and is horrible).
>
> And git made it about 4% worse all on its own.
My pragmatic half agrees with what you said. /usr/bin should
not contain things that are never used by the end user -- things
like git-sh-setup, git-fmt-merge-msg, and git-merge-recursive
should not be there. Not having things like git-show-branch and
git-update-index in /usr/bin is a regression because it needs an
extra fork to call them through 'git' wrapper, but I could live
with that.
My purist half, however, says that it is a wrong solution to the
problem. If having many files in /usr/bin hurts performance,
you should be using a filesystem that handles large directory
better. Modern shells already know how to hash command names
found in $PATH. It is just your gnome executable finder that is
lacking the knowledge of which binaries are appropriate for what
mimetype; perhaps your distribution could help by having a way
for each package to register programs that handle particular
mimetypes well with the system-wide database.
And my lazy remainder (yes, I add up to more then one ;-))
cheers on my purist side.
But common sense prevails at the end of the day. I would not
fight a battle I know I would not be able to win. So what
should we do about this problem? And when?
Since we do not have enough clout to have /usr/bin/git/ and ask
the users to put that in their PATH like X11 does, we need to
teach some of our commands that use other git commands to
prepend /usr/lib/git/ (or /usr/libexec/git) on their PATH while
they run. Although many of the Porcelainish commands include
git-sh-setup, git-sh-setup itself is a prime candidate to be
kicked out of /usr/bin, which means essentially everything needs
to have that PATH trick.
This also is a bit inconvenient for our in-source-tree tests.
We need to be testing what we just built and are about to
install, not what is already installed, so every script needs to
start with something like this:
#!/bin/sh
: ${GIT_BIN_DIR=@@GIT_BIN_DIR@@}
PATH="$GIT_BIN_DIR:$PATH"
git-sh-setup || die "not a git repository"
...
and our test will run with GIT_BIN_DIR set to `pwd`/../../ (they
run in t/trash and what we just built are found at the toplevel
of the source). Also we need to do the same for binaries if they
fork/exec other git commands.
Commands like upload-pack and receive-pack are directly executed
from the ssh connection, and we need to arrange for them to be
found on the PATH of users' non-login shells. This does not
necessarily mean these commands need to stay in /usr/bin, but if
we move them outside standard PATH, we would need to teach
.bash_profile vs .bashrc workaround to all users, which I think
is the yuckiest part of all of the above.
^ permalink raw reply
* Re: git binary directory?
From: Linus Torvalds @ 2005-11-06 0:27 UTC (permalink / raw)
To: Git Mailing List, Junio C Hamano
In-Reply-To: <Pine.LNX.4.64.0511051535220.3316@g5.osdl.org>
On Sat, 5 Nov 2005, Linus Torvalds wrote:
>
> This is a guaranteed BUGGY thing to make the git RPM do something like
> that.
>
> [ ... ]
>
> WARNING! I just realized that "gitk" also ends up in that /usr/lib/git..
> directory, and this isn't visible. My bad. I'm a retard.
This fixes the gitk thing, by installing it (along with git) in the
regular $prefix/bin directory (ie default /usr/bin for the RPM).
I'm still a retard, and it's _probably_ still buggy, but at least it is no
longer GUARANTEED to be buggy.
Linus
---
diff --git a/Makefile b/Makefile
index 6c01dc2..6ec9dd2 100644
--- a/Makefile
+++ b/Makefile
@@ -59,6 +59,7 @@ ALL_CFLAGS = $(CFLAGS) $(PLATFORM_DEFINE
prefix = $(HOME)
bindir = $(prefix)/bin
+gitdir = $(bindir)
template_dir = $(prefix)/share/git-core/templates/
GIT_PYTHON_DIR = $(prefix)/share/git-core/python
# DESTDIR=
@@ -86,7 +87,7 @@ SCRIPT_SH = \
git-prune.sh git-pull.sh git-push.sh git-rebase.sh \
git-repack.sh git-request-pull.sh git-reset.sh \
git-resolve.sh git-revert.sh git-sh-setup.sh git-status.sh \
- git-tag.sh git-verify-tag.sh git-whatchanged.sh git.sh \
+ git-tag.sh git-verify-tag.sh git-whatchanged.sh \
git-applymbox.sh git-applypatch.sh git-am.sh \
git-merge.sh git-merge-stupid.sh git-merge-octopus.sh \
git-merge-resolve.sh git-merge-ours.sh git-grep.sh
@@ -310,12 +311,12 @@ DEFINES += -DSHA1_HEADER=$(call shellquo
SCRIPTS = $(patsubst %.sh,%,$(SCRIPT_SH)) \
$(patsubst %.perl,%,$(SCRIPT_PERL)) \
$(patsubst %.py,%,$(SCRIPT_PYTHON)) \
- gitk git-cherry-pick
+ git-cherry-pick
export prefix TAR INSTALL DESTDIR SHELL_PATH template_dir
### Build rules
-all: $(PROGRAMS) $(SCRIPTS)
+all: git gitk $(PROGRAMS) $(SCRIPTS)
all:
$(MAKE) -C templates
@@ -323,6 +324,7 @@ all:
git: git.sh Makefile
rm -f $@+ $@
sed -e '1s|#!.*/sh|#!$(call shq,$(SHELL_PATH))|' \
+ -e 's:@@GITDIR@@:$(gitdir):g' \
-e 's/@@GIT_VERSION@@/$(GIT_VERSION)/g' \
-e 's/@@X@@/$(X)/g' \
$(GIT_LIST_TWEAK) <$@.sh >$@+
@@ -410,9 +412,11 @@ check:
### Installation rules
-install: $(PROGRAMS) $(SCRIPTS)
+install: git gitk $(PROGRAMS) $(SCRIPTS)
$(INSTALL) -d -m755 $(call shellquote,$(DESTDIR)$(bindir))
- $(INSTALL) $(PROGRAMS) $(SCRIPTS) $(call shellquote,$(DESTDIR)$(bindir))
+ $(INSTALL) git gitk $(call shellquote,$(DESTDIR)$(bindir))
+ $(INSTALL) -d -m755 $(call shellquote,$(DESTDIR)$(gitdir))
+ $(INSTALL) $(PROGRAMS) $(SCRIPTS) $(call shellquote,$(DESTDIR)$(gitdir))
$(MAKE) -C templates install
$(INSTALL) -d -m755 $(call shellquote,$(DESTDIR)$(GIT_PYTHON_DIR))
$(INSTALL) $(PYMODULES) $(call shellquote,$(DESTDIR)$(GIT_PYTHON_DIR))
@@ -450,7 +454,7 @@ deb: dist
clean:
rm -f *.o mozilla-sha1/*.o ppc/*.o compat/*.o $(PROGRAMS) $(LIB_FILE)
- rm -f $(filter-out gitk,$(SCRIPTS))
+ rm -f $(SCRIPTS)
rm -f git-core.spec *.pyc *.pyo
rm -rf $(GIT_TARNAME)
rm -f $(GIT_TARNAME).tar.gz git-core_$(GIT_VERSION)-*.tar.gz
diff --git a/git-core.spec.in b/git-core.spec.in
index 5240dd2..0d0ddf3 100644
--- a/git-core.spec.in
+++ b/git-core.spec.in
@@ -19,17 +19,19 @@ distributed source code management syste
rudimentary tools that can be used as a SCM, but you should look
elsewhere for tools for ordinary humans layered on top of this.
+%define gitdir %{_libdir}/git-@@VERSION@@
+
%prep
%setup -q
%build
make %{_smp_mflags} CFLAGS="$RPM_OPT_FLAGS" WITH_OWN_SUBPROCESS_PY=YesPlease \
- prefix=%{_prefix} all %{!?_without_docs: doc}
+ gitdir=%{gitdir} prefix=%{_prefix} all %{!?_without_docs: doc}
%install
rm -rf $RPM_BUILD_ROOT
make %{_smp_mflags} DESTDIR=$RPM_BUILD_ROOT WITH_OWN_SUBPROCESS_PY=YesPlease \
- prefix=%{_prefix} mandir=%{_mandir} \
+ gitdir=%{gitdir} prefix=%{_prefix} mandir=%{_mandir} \
install %{!?_without_docs: install-doc}
%clean
@@ -38,6 +40,7 @@ rm -rf $RPM_BUILD_ROOT
%files
%defattr(-,root,root)
%{_bindir}/*
+%{gitdir}/*
%{_datadir}/git-core/
%doc README COPYING Documentation/*.txt
%{!?_without_docs: %doc Documentation/*.html }
diff --git a/git.sh b/git.sh
index 94940ae..9ba1608 100755
--- a/git.sh
+++ b/git.sh
@@ -1,7 +1,8 @@
#!/bin/sh
cmd=
-path=$(dirname "$0")
+path="@@GITDIR@@"
+export PATH="$path:$PATH"
case "$#" in
0) ;;
*) cmd="$1"
^ permalink raw reply related
* Re: git binary directory?
From: Linus Torvalds @ 2005-11-05 23:52 UTC (permalink / raw)
To: Git Mailing List, Junio C Hamano
In-Reply-To: <Pine.LNX.4.64.0511051247330.3316@g5.osdl.org>
On Sat, 5 Nov 2005, Linus Torvalds wrote:
>
> So I'd really suggest that while the "git-<tab><tab>" thing is perhaps
> useful, we'd actually be better off with an /usr/lib/git directory where
> we put the git executables by default. And just put "git" into /usr/bin.
This is a guaranteed BUGGY thing to make the git RPM do something like
that.
It adds a "gitdir" parameter to "make install", which defaults to the same
as "bindir" if you don't specify it.
It installs only "git" in "bindir", and all other git programs in
"gitdir".
It then makes the "git" script use "gitdir" for searching for the
installed git scripts and programs, and forces PATH to have "gitdir" at
the head while executing the sub-script (so that when the scripts do
"git-diff-tree" etc, they'll always use the proper gitdir version).
The RPM specfile is taught to make "gitdir" be "${_libdir}/git-@@VERSION"
This means that if I got everything right, the RPM will build with
/usr/bin/git
/usr/lib/git-0.99.9.GIT/git-add
/usr/lib/git-0.99.9.GIT/git-am
/usr/lib/git-0.99.9.GIT/git-apply
..
/usr/share/doc/git-core-0.99.9.GIT
/usr/share/doc/git-core-0.99.9.GIT/COPYING
..
/usr/share/git-core
/usr/share/git-core/python
..
/usr/share/git-core/templates
/usr/share/git-core/templates/branches
..
/usr/share/man/man1/git-add.1.gz
/usr/share/man/man1/git-am.1.gz
..
where the new thing is that "/usr/lib/git-0.99.9.GIT/" usage.
I've tested building the rpm, and that part works. I haven't actually
tested the end result, though.
Oh, and I have not a clue in hell about how Debian works. In fact, I don't
have a real clue how RPM files work either, this was done by doing some
pattern matching on the existing git-core.spec.in file. Somebody who knows
better really should fix it.
WARNING! I just realized that "gitk" also ends up in that /usr/lib/git..
directory, and this isn't visible. My bad. I'm a retard.
Comments?
What do people think about this? Any daring souls willing to test this?
(Btw: word of caution on something that confused me at first: you have to
_commit_ this diff in order for "make rpm" to work, since "make rpm" uses
"git-tar-tree" to create the rpm file, not the current directory contents,
heh ;)
Linus
---
diff --git a/Makefile b/Makefile
index 6c01dc2..8df8b50 100644
--- a/Makefile
+++ b/Makefile
@@ -59,6 +59,7 @@ ALL_CFLAGS = $(CFLAGS) $(PLATFORM_DEFINE
prefix = $(HOME)
bindir = $(prefix)/bin
+gitdir = $(bindir)
template_dir = $(prefix)/share/git-core/templates/
GIT_PYTHON_DIR = $(prefix)/share/git-core/python
# DESTDIR=
@@ -86,7 +87,7 @@ SCRIPT_SH = \
git-prune.sh git-pull.sh git-push.sh git-rebase.sh \
git-repack.sh git-request-pull.sh git-reset.sh \
git-resolve.sh git-revert.sh git-sh-setup.sh git-status.sh \
- git-tag.sh git-verify-tag.sh git-whatchanged.sh git.sh \
+ git-tag.sh git-verify-tag.sh git-whatchanged.sh \
git-applymbox.sh git-applypatch.sh git-am.sh \
git-merge.sh git-merge-stupid.sh git-merge-octopus.sh \
git-merge-resolve.sh git-merge-ours.sh git-grep.sh
@@ -315,7 +316,7 @@ SCRIPTS = $(patsubst %.sh,%,$(SCRIPT_SH)
export prefix TAR INSTALL DESTDIR SHELL_PATH template_dir
### Build rules
-all: $(PROGRAMS) $(SCRIPTS)
+all: git $(PROGRAMS) $(SCRIPTS)
all:
$(MAKE) -C templates
@@ -323,6 +324,7 @@ all:
git: git.sh Makefile
rm -f $@+ $@
sed -e '1s|#!.*/sh|#!$(call shq,$(SHELL_PATH))|' \
+ -e 's:@@GITDIR@@:$(gitdir):g' \
-e 's/@@GIT_VERSION@@/$(GIT_VERSION)/g' \
-e 's/@@X@@/$(X)/g' \
$(GIT_LIST_TWEAK) <$@.sh >$@+
@@ -410,9 +412,11 @@ check:
### Installation rules
-install: $(PROGRAMS) $(SCRIPTS)
+install: git $(PROGRAMS) $(SCRIPTS)
$(INSTALL) -d -m755 $(call shellquote,$(DESTDIR)$(bindir))
- $(INSTALL) $(PROGRAMS) $(SCRIPTS) $(call shellquote,$(DESTDIR)$(bindir))
+ $(INSTALL) git $(call shellquote,$(DESTDIR)$(bindir))
+ $(INSTALL) -d -m755 $(call shellquote,$(DESTDIR)$(gitdir))
+ $(INSTALL) $(PROGRAMS) $(SCRIPTS) $(call shellquote,$(DESTDIR)$(gitdir))
$(MAKE) -C templates install
$(INSTALL) -d -m755 $(call shellquote,$(DESTDIR)$(GIT_PYTHON_DIR))
$(INSTALL) $(PYMODULES) $(call shellquote,$(DESTDIR)$(GIT_PYTHON_DIR))
diff --git a/git-core.spec.in b/git-core.spec.in
index 5240dd2..0d0ddf3 100644
--- a/git-core.spec.in
+++ b/git-core.spec.in
@@ -19,17 +19,19 @@ distributed source code management syste
rudimentary tools that can be used as a SCM, but you should look
elsewhere for tools for ordinary humans layered on top of this.
+%define gitdir %{_libdir}/git-@@VERSION@@
+
%prep
%setup -q
%build
make %{_smp_mflags} CFLAGS="$RPM_OPT_FLAGS" WITH_OWN_SUBPROCESS_PY=YesPlease \
- prefix=%{_prefix} all %{!?_without_docs: doc}
+ gitdir=%{gitdir} prefix=%{_prefix} all %{!?_without_docs: doc}
%install
rm -rf $RPM_BUILD_ROOT
make %{_smp_mflags} DESTDIR=$RPM_BUILD_ROOT WITH_OWN_SUBPROCESS_PY=YesPlease \
- prefix=%{_prefix} mandir=%{_mandir} \
+ gitdir=%{gitdir} prefix=%{_prefix} mandir=%{_mandir} \
install %{!?_without_docs: install-doc}
%clean
@@ -38,6 +40,7 @@ rm -rf $RPM_BUILD_ROOT
%files
%defattr(-,root,root)
%{_bindir}/*
+%{gitdir}/*
%{_datadir}/git-core/
%doc README COPYING Documentation/*.txt
%{!?_without_docs: %doc Documentation/*.html }
diff --git a/git.sh b/git.sh
index 94940ae..9ba1608 100755
--- a/git.sh
+++ b/git.sh
@@ -1,7 +1,8 @@
#!/bin/sh
cmd=
-path=$(dirname "$0")
+path="@@GITDIR@@"
+export PATH="$path:$PATH"
case "$#" in
0) ;;
*) cmd="$1"
^ permalink raw reply related
* Re: git binary directory?
From: Yaacov Akiba Slama @ 2005-11-05 21:43 UTC (permalink / raw)
To: git
In-Reply-To: <436D2269.6090605@slamail.org>
Linus Torvalds wrote:
> So I'd really suggest that while the "git-<tab><tab>" thing is perhaps
> useful, we'd actually be better off with an /usr/lib/git directory
> where we put the git executables by default. And just put "git" into
> /usr/bin.
>
> That way, people who _want_ to use "git-<tab><tab>" can just add the
> git binary directory to their path and directly access all of them.
> And others can just use the plain "git" interface.
>
> That would mean that I'd have to learn to use "git whatchanged" and
> "git diff-tree" instead of "git-whatchanged" and "git-diff-tree", but
> hey, it's why we have that "git" script in the first place.
>
> What do people think?
I agree with you. I have 3268 entries in /usr/bin and git commands
account for 3.3% of this number which is a lot.
In addition custom tab completion can be quite easily added to bash and zsh.
If you indeed put only git in /usr/bin, a good idea would be perhaps to
implement (svn does that for instance) : "git help" to have a simple
list of command (this is almost already there), and "git help
<command>" which can give the same result as "man git-<command>" because
it's not clear from "man git" that one needs to see the man pages of the
commands listed in "Porcelain-ish command".
--yas
^ permalink raw reply
* git binary directory?
From: Linus Torvalds @ 2005-11-05 21:02 UTC (permalink / raw)
To: Git Mailing List, Junio C Hamano
Just for fun, I did "git-<tab><tab>" a moment ago, and it asked me
Display all 171 possibilities? (y or n)
which was a bit scary. Now, part of that was because I hadn't cleaned up
the old git names, so I removed everything, and did a clean "make install"
with the current git tree. At which point the question became
Display all 105 possibilities? (y or n)
and pressing "y" shows a really nice list of programs.
Now, this is actually very convenient, and since I tend to install things
in my own ~/bin directory, it's all good. What's a hundred files more or
less?
However, doing a "ls /usr/bin/ | wc" shows that on my laptop /usr/bin is
already 2583 files, and git is actually part of the problem there (hey,
it's got the git RPM installed - it's not my main machine)..
Now, I happen to think that 2500+ files in /usr/bin is a bit much (ever
try to use the horrid gnome executable finder on it when you want to
convince firefox to use xpdf instead of that broken crap called "evince"?
Takes absolutely ages and is horrible).
And git made it about 4% worse all on its own.
So I'd really suggest that while the "git-<tab><tab>" thing is perhaps
useful, we'd actually be better off with an /usr/lib/git directory where
we put the git executables by default. And just put "git" into /usr/bin.
That way, people who _want_ to use "git-<tab><tab>" can just add the git
binary directory to their path and directly access all of them. And others
can just use the plain "git" interface.
That would mean that I'd have to learn to use "git whatchanged" and "git
diff-tree" instead of "git-whatchanged" and "git-diff-tree", but hey, it's
why we have that "git" script in the first place.
What do people think?
Linus
^ permalink raw reply
* Re: hgmq vs. StGIT
From: Catalin Marinas @ 2005-11-05 20:23 UTC (permalink / raw)
To: Chris Mason
Cc: Chuck Lever, Petr Baudis, Theodore Ts'o, Joel Becker,
Junio C Hamano, git
In-Reply-To: <20051102154108.GM26847@watt.suse.com>
Sorry for the delay in replying.
On 02/11/05, Chris Mason <mason@suse.com> wrote:
> I think we're talking past each other a little, partially because
> I'm not sure exactly what features you want from revision control on the
> patches.
That's unclear for me too :-). I would like to have a way of checking
the changes to individual patches, just to be able to go back if some
changes broke it. It's also useful to have some kind of revision
control for the whole stack, but this can be achieved with tags at the
moment. What I usually do is export the series when I'm happy with it
and keep that directory safe. I could add revision control for the
directory containing the exported series but this would be somehow
outside StGIT.
> But, my suggestion is to remember that once you add some sort of
> revision control, people are going to want all of the features they are
> used to with git/hg/their favorite SCM. You'll probably get better
> results if you patch git to your needs then if you try to reimplement
> things all over again.
That's true. I think that people who want a full revision control of
the patches should rather use separate branches instead of stacked
patches. It's indeed more convenient to be able to add or remove
features with push/pop but providing yet another SCM layer on top of
these would make the tool hard to understand (and maybe make Quilt
fans run away from it).
The current StGIT features are enough for my needs but I'll
accept/implement new features based on others' requirements.
BTW, the latest StGIT snapshot has support for a 'patches' command
which shows the patches modifying a file or set of files (that's
because I needed this feature recently).
--
Catalin
^ permalink raw reply
* [PATCH] gitk: moving all three panes if clicking on an arrow.
From: Stefan-W. Hahn @ 2005-11-05 19:55 UTC (permalink / raw)
To: git
[PATCH] gitk: moving all three panes if clicking on an arrow.
Signed-off-by: Stefan-W. Hahn <stefan.hahn@s-hahn.de>
---
gitk | 4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
applies-to: ef3876e50bb5e91a6fb40d4e59df2178c6f40237
078ef4fa295368b5337ad797b27372bbaa19d7fc
diff --git a/gitk b/gitk
index a9d37d9..616a3e2 100755
--- a/gitk
+++ b/gitk
@@ -3178,7 +3178,7 @@ proc clickisonarrow {id y} {
}
proc arrowjump {id dirn y} {
- global mainline sidelines canv
+ global mainline sidelines canv canv2 canv3
set yt {}
if {$dirn eq "down"} {
@@ -3216,6 +3216,8 @@ proc arrowjump {id dirn y} {
set yfrac 0
}
$canv yview moveto $yfrac
+ $canv2 yview moveto $yfrac
+ $canv3 yview moveto $yfrac
}
proc lineclick {x y id isnew} {
---
0.99.8.GIT
--
Stefan-W. Hahn It is easy to make things.
/ mailto:stefan.hahn@s-hahn.de / It is hard to make things simple.
^ permalink raw reply related
* [PATCH] Separate RPMS for programs with non-standard dependencies
From: Jim Radford @ 2005-11-05 19:38 UTC (permalink / raw)
To: git
Separate RPMS for programs with non-standard dependencies
Signed-off-by: Jim Radford <radford@blackbean.org>
diff --git a/git-core.spec.in b/git-core.spec.in
index 5240dd2..26846d0 100644
--- a/git-core.spec.in
+++ b/git-core.spec.in
@@ -19,32 +19,70 @@ distributed source code management syste
rudimentary tools that can be used as a SCM, but you should look
elsewhere for tools for ordinary humans layered on top of this.
+%package svn
+Summary: Git tools for importing Subversion repositories.
+Group: Development/Tools
+Requires: subversion
+%description svn
+Git tools for importing Subversion repositories.
+
+%package cvs
+Summary: Git tools for importing CVS repositories.
+Group: Development/Tools
+Requires: cvs
+%description cvs
+Git tools for importing CVS repositories.
+
+%package email
+Summary: Git tools for sending email.
+Group: Development/Tools
+%description email
+Git tools for sending email.
+
%prep
%setup -q
%build
-make %{_smp_mflags} CFLAGS="$RPM_OPT_FLAGS" WITH_OWN_SUBPROCESS_PY=YesPlease \
+make %{_smp_mflags} CFLAGS="$RPM_OPT_FLAGS" WITH_OWN_SUBPROCESS_PY=YesPlease WITH_SEND_EMAIL=1 \
prefix=%{_prefix} all %{!?_without_docs: doc}
%install
rm -rf $RPM_BUILD_ROOT
-make %{_smp_mflags} DESTDIR=$RPM_BUILD_ROOT WITH_OWN_SUBPROCESS_PY=YesPlease \
+make %{_smp_mflags} DESTDIR=$RPM_BUILD_ROOT WITH_OWN_SUBPROCESS_PY=YesPlease WITH_SEND_EMAIL=1 \
prefix=%{_prefix} mandir=%{_mandir} \
install %{!?_without_docs: install-doc}
+(find $RPM_BUILD_ROOT%{_bindir} -type f | grep -vE "svn|cvs|email" | sed -e s@^$RPM_BUILD_ROOT@@) > bin-man-files
+%if %{!?_without_docs:1}0
+(find $RPM_BUILD_ROOT%{_mandir} -type f | grep -vE "svn|cvs|email" | sed -e s@^$RPM_BUILD_ROOT@@ -e 's/$/*/' ) >> bin-man-files
+%endif
+
%clean
rm -rf $RPM_BUILD_ROOT
-%files
+%files svn
+%{_bindir}/*svn*
+%{!?_without_docs: %{_mandir}/man1/*svn*.1*}
+
+%files cvs
+%{_bindir}/*cvs*
+%{!?_without_docs: %{_mandir}/man1/*cvs*.1*}
+
+%files email
+%{_bindir}/*email*
+%{!?_without_docs: %{_mandir}/man1/*email*.1*}
+
+%files -f bin-man-files
%defattr(-,root,root)
-%{_bindir}/*
%{_datadir}/git-core/
%doc README COPYING Documentation/*.txt
%{!?_without_docs: %doc Documentation/*.html }
-%{!?_without_docs: %{_mandir}/man1/*.1*}
-%{!?_without_docs: %{_mandir}/man7/*.7*}
%changelog
+* Tue Sep 27 2005 Jim Radford <radford@blackbean.org>
+- Move programs with non-standard dependencies (svn, cvs, email)
+ into separate packages
+
* Tue Sep 27 2005 H. Peter Anvin <hpa@zytor.com>
- parallelize build
- COPTS -> CFLAGS
^ permalink raw reply related
* Re: [GIT PATCH] SCSI updates for 2.6.14
From: Linus Torvalds @ 2005-11-05 19:32 UTC (permalink / raw)
To: James Bottomley; +Cc: Junio C Hamano, Git Mailing List
In-Reply-To: <1131216913.3614.15.camel@mulgrave>
On Sat, 5 Nov 2005, James Bottomley wrote:
>
> On Sat, 2005-11-05 at 10:42 -0800, Linus Torvalds wrote:
> > James: what's your umask on master? Maybe you've set it to 0077, from the
> > default 0002?
>
> I set it to 0022 ... could that be the problem?
No, 0022 should still be perfectly fine, and should result in drwxr-xr-x,
not your strange things.
Looking at things, I can't imagine it being anything else than a cpio bug
(or misfeature - I don't know where cpio _could_ get the permissions for
the intermediate directories from). But that implies that the system git
shouldn't have mattered, and if you used "git clone -l" with your old git
it should have done exactly the same thing.
Junio: I just confirmed this. Do a
git clone -l src dst
with any git, and you'll end up with
...
drwx------ 2 torvalds torvalds 4096 Nov 5 11:22 de
drwx------ 2 torvalds torvalds 4096 Nov 5 11:22 df
drwx------ 2 torvalds torvalds 4096 Nov 5 11:22 e0
...
drwx------ 2 torvalds torvalds 4096 Nov 5 11:22 ff
drwxrwxr-x 2 torvalds torvalds 4096 Nov 5 11:22 info
drwxrwxr-x 2 torvalds torvalds 4096 Nov 5 11:22 pack
regardless of umask.
Happens with both cpio 2.5 and 2.6.
I _think_ it's this:
...
find objects -type f -print |
cpio -puamd$l "$D/.git/" || exit 1
...
and I suspect that if you remove the "-type f" it will just work (because
it will get the directory permissions from the source). But cpio is black
magic to me (very un-unixy feel to it, I'd guess it comes from some odd
other pre-unix OS).
Linus
^ permalink raw reply
* Re: [PATCH] Added a few examples to git-pull man page.
From: Josef Weidendorfer @ 2005-11-05 19:37 UTC (permalink / raw)
To: git
In-Reply-To: <7vk6fno36c.fsf@assigned-by-dhcp.cox.net>
On Saturday 05 November 2005 10:27, Junio C Hamano wrote:
> Maybe something like this (I know my wording is quite bad and I
> would appreciate rephrasing it better very much) would be more
> explicit and appropriate?
>
> If you intend to do development derived from a remote
> branch B, have a `Pull:` line to track it, like this:
>
> Pull: B:remote-B
>
> and have a separate branch my-B to do your development
> on top of it. The latter is created by 'git branch my-B
> remote-B' (or its equivalent, 'git checkout -b my-B
> remote-B'), and that is the branch you make your own
> commits. Run 'git fetch' to keep track of the progress
> of the remote side, and when you see the tracked remote
> branch has something new, merge it into your development
> branch with 'git pull . remote-B', while you are on my-B
> branch.
It would be good to explicitly mention that exactly this is
already setup for you after cloning: you are prepared to do
local development based on the remote "master", with
- remote head "B" = remote head "master"
- local head "remote-B" = local head "origin"
- local head "my-B" = local head "master"
Hmm. I just looked up the manual page of "git-clone", but it
does not mention this. It also should say that all remote heads
are cloned to local heads with the same name, with one exception:
remote "master" matches local "origin".
This feels really inconsistent. Junio, I think your proposal of
tracking remote "B" with local "origin/B" is a lot better. It
allows to name a local development branch for any remote "B" by
the same local name "B".
We could make heads starting with "origin/" special: Never let
"git commit" update such a head, but give out a warning instead,
that this head should not be changed locally, as it is used for
tracking a remote head. This warning could suggest to do "git branch"
before committing.
This special handling (of "origin/") should not be hardcoded, but
configurable, perhaps in .git/remotes:
URL: remote-URL
Prefix: origin/
Josef
^ permalink raw reply
* Re: GIT 0.99.9c
From: Santi Béjar @ 2005-11-05 14:00 UTC (permalink / raw)
To: git
In-Reply-To: <7vwtjp2h59.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> writes:
> And I would appreciate somebody who actually uses svnimport to Ack on
> Yaacov's svnimport fix.
Let's try to make a good report :)
Situation:
an svn repo created with cvs2svn, and used with svk so it has
the property svk:merge to say explicity the extra parents of a commit.
svn log -r 1:2 -v file:///repo/susy/
------------------------------------------------------------------------
r1 | (no author) | 2003-10-29 16:49:04 +0100 (Wed, 29 Oct 2003) | 1 line
Changed paths:
A /branches
A /tags
A /trunk
New repository initialized by cvs2svn.
------------------------------------------------------------------------
r2 | guasch | 2003-10-29 16:49:04 +0100 (Wed, 29 Oct 2003) | 2 lines
Changed paths:
A /trunk/includes
A /trunk/includes/gamma_gg.F
Initial revision
------------------------------------------------------------------------
git-svnimport orig:
bela $ git-svnimport -v file:///repo/susy/
1: Unrecognized path: /branches
1: Unrecognized path: /tags
Tree ID 4b825dc642cb6eb9a060e54bf8d69288fbee4904
Committing initial tree 4b825dc642cb6eb9a060e54bf8d69288fbee4904
Committed change 1:/ 2003-10-29 15:49:04)
Commit ID caff0f3ee5bc540a264f615b000fcbd7b355586a
Writing to refs/heads/origin
DONE: 1 origin caff0f3ee5bc540a264f615b000fcbd7b355586a
... 2 /trunk/includes ...
Name does not refer to a filesystem file: Attempted to get textual contents of a *non*-file node at /home/santi/usr/bin/git-svnimport line 115
bela $ git-cat-file tree 4b825dc642cb6eb9a060e54bf8d69288fbee4904
bela $
and the same error for the commit r2 with "-s 2". I suppose that it
tries to chechkout the includes dir.
git-svnimport new:
I've used the one in the message
"[PATCH] Several fixes to import mono's svn tree"
bela $ git-svnimport -v file:///repo/susy/
Tree ID 4b825dc642cb6eb9a060e54bf8d69288fbee4904
Committing initial tree 4b825dc642cb6eb9a060e54bf8d69288fbee4904
Committed change 1:/ 2003-10-29 15:49:04)
Commit ID caff0f3ee5bc540a264f615b000fcbd7b355586a
Writing to refs/heads/origin
DONE: 1 origin caff0f3ee5bc540a264f615b000fcbd7b355586a
... 2 /trunk/includes/gamma_gg.F ...
Tree ID b7ea8a91831deea3a6015a17f8843be4833255bc
Merge parent branch: caff0f3ee5bc540a264f615b000fcbd7b355586a
Committed change 2:/ 2003-10-29 15:49:04)
Commit ID 6dc8146789badce6368705f9317e7f65f4526f6b
Writing to refs/heads/origin
DONE: 2 origin 6dc8146789badce6368705f9317e7f65f4526f6b
[...]
DONE: 154 SinCosAlpha 657abeb912a00d6fad9fcd4436490d81b4002bcb
Switching from 657abeb912a00d6fad9fcd4436490d81b4002bcb to 760501ff6986134eaf0ee34484af1e38e7f8b8b0 (/)
perl: /home/devel/release/subversion-1.2.3dfsg1/subversion/libsvn_subr/path.c:115: svn_path_join: Assertion `is_canonical (component, clen)' failed.
Aborted
So it worked till the revision 154. But the revision 155 is:
bela $ svn log -r 155 file:///repo/susy/
------------------------------------------------------------------------
r155 | guasch | 2005-02-25 11:19:38 +0100 (Fri, 25 Feb 2005) | 14 lines
Changed paths:
M /
M /trunk
M /trunk/includes/pp.f
A /trunk/includes/subh.F
r157@jgi: guasch | 2005-02-25 11:19:23 +0100
r156@jgi: guasch | 2005-02-25 11:17:06 +0100
Create local branch of SVN mirror
*** Merge branch SinCosAlpha. Revisions 152:154
bela $ svn diff -r 154:155 file:///repo/susy/
[...]
Property changes on: trunk
___________________________________________________________________
Name: svk:merge
+ e2421932-edf0-0310-b7cb-9d7cda74567f:/local/branches/SinCosAlpha:156
Property changes on: .
___________________________________________________________________
Name: svk:merge
+ e2421932-edf0-0310-b7cb-9d7cda74567f:/local:157
bela $
This is the first revision that changes the properties of / and
/trunk, and it does not handle this situation.
A usefull thing would be if it could use this information to create a
merge commit. So it could check if this information is from the
repository we are importing, and fallback to the heuristic one if it
fails. (In the case above the "e242..." UUID is from another svn
repository).
If I do it by hand, the I get the following:
156: Unrecognized path: /Xsecfile
157: Unrecognized path: /Xsecfile/bo_Hqqp/hqqpinterface_sqcd_maximize_SSB_bsg_runningmass_prod.F
157: Unrecognized path: /Xsecfile/includes/pphtt.f
157: Unrecognized path: /Xsecfile/includes/dsig_htt.F
158: Unrecognized path: /Xsecfile/includes/dsig_htt.F
perl: /home/devel/release/subversion-1.2.3dfsg1/subversion/libsvn_subr/path.c:115: svn_path_join: Assertion `is_canonical (component, clen)' failed.
Aborted
The r159 changes the properties of /trunk too. The other thing is that
finds an "Unrecognized path" (that is logical), but I have not find any
way to tell "OK, it's my fault, but treat this as branch Xsecfile".
Hope it's usefull.
Santi
^ permalink raw reply
* Package split: Debian.
From: Junio C Hamano @ 2005-11-05 11:19 UTC (permalink / raw)
To: git
In-Reply-To: <7vpsplcr7l.fsf@assigned-by-dhcp.cox.net>
This is still WIP (I forgot to split out tla and doc) but I'd
appreciate it if somebody can help me on the RPM side. An RPM
novice without a test install environment like myself is pretty
much useless for the job X-<.
Not that I am a Debian expert, but at least I do have a chrooted
sarge partition that I can test install and trash.
-- >8 -- cut here -- >8 --
As discussed on the list, split the foreign SCM interoperability
packages from the git-core binary package.
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
Makefile | 4 ++--
debian/changelog | 7 +++++++
debian/control | 25 ++++++++++++++++++++++++-
debian/git-cvs.files | 2 ++
debian/git-email.files | 2 ++
debian/git-svn.files | 2 ++
debian/rules | 5 ++++-
7 files changed, 43 insertions(+), 4 deletions(-)
create mode 100644 debian/git-cvs.files
create mode 100644 debian/git-email.files
create mode 100644 debian/git-svn.files
applies-to: 861aaf77ef8cff205f4d8721ce24f3c25d180ca8
0017ffa572ce837d0a73d69014a0f4820b2b80b5
diff --git a/Makefile b/Makefile
index 6064672..76d33b4 100644
--- a/Makefile
+++ b/Makefile
@@ -450,8 +450,8 @@ clean:
rm -f git-core.spec *.pyc *.pyo
rm -rf $(GIT_TARNAME)
rm -f $(GIT_TARNAME).tar.gz git-core_$(GIT_VERSION)-*.tar.gz
- rm -f git-core_$(GIT_VERSION)-*.deb git-core_$(GIT_VERSION)-*.dsc
- rm -f git-tk_$(GIT_VERSION)-*.deb
+ rm -f git-core_$(GIT_VERSION)-*.dsc
+ rm -f git-*_$(GIT_VERSION)-*.deb
$(MAKE) -C Documentation/ clean
$(MAKE) -C templates clean
$(MAKE) -C t/ clean
diff --git a/debian/changelog b/debian/changelog
index 5fd31b7..17a4a24 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,10 @@
+git-core (0.99.9-1) unstable; urgency=low
+
+ * Split the git-core binary package into core and foreign SCM
+ interoperability modules.
+
+ -- Junio C Hamano <junkio@cox.net> Sat, 29 Oct 2005 14:34:30 -0700
+
git-core (0.99.9-0) unstable; urgency=low
* GIT 0.99.9
diff --git a/debian/control b/debian/control
index 1f45f93..2c1d295 100644
--- a/debian/control
+++ b/debian/control
@@ -8,7 +8,7 @@ Standards-Version: 3.6.1
Package: git-core
Architecture: any
Depends: ${shlibs:Depends}, ${perl:Depends}, ${misc:Depends}, rcs
-Recommends: rsync, curl, ssh, libmail-sendmail-perl, libemail-valid-perl, libsvn-core-perl (>= 1.2.1), python (>= 2.4.0), less
+Recommends: rsync, curl, ssh, python (>= 2.4.0), less
Suggests: cogito, patch
Conflicts: git, cogito (<< 0.13)
Description: The git content addressable filesystem
@@ -24,3 +24,26 @@ Depends: ${shlibs:Depends}, ${misc:Depen
Description: The git content addressable filesystem, GUI add-on
This package contains 'gitk', the git revision tree visualizer.
+Package: git-svn
+Architecture: all
+Depends: ${shlibs:Depends}, ${misc:Depends}, ${perl:Depends}, git-core, libsvn-core-perl (>= 1.2.1)
+Suggests: subversion
+Description: The git content addressable filesystem, SVN interoperability
+ This package contains 'git-svnimport', to import development history from
+ SVN repositories.
+
+Package: git-cvs
+Architecture: all
+Depends: ${shlibs:Depends}, ${misc:Depends}, ${perl:Depends}, git-core
+Suggests: cvs
+Description: The git content addressable filesystem, CVS interoperability
+ This package contains 'git-cvsimport', to import development history from
+ CVS repositories.
+
+Package: git-email
+Architecture: all
+Depends: ${shlibs:Depends}, ${misc:Depends}, git-core, libmail-sendmail-perl, libemail-valid-perl
+Description: The git content addressable filesystem, e-mail add-on
+ This package contains 'git-send-email', to send a series of patch e-mails.
+
+
diff --git a/debian/git-cvs.files b/debian/git-cvs.files
new file mode 100644
index 0000000..8bf5090
--- /dev/null
+++ b/debian/git-cvs.files
@@ -0,0 +1,2 @@
+/usr/bin/git-cvsimport
+/usr/share/doc/git-core/git-cvsimport.*
diff --git a/debian/git-email.files b/debian/git-email.files
new file mode 100644
index 0000000..236754c
--- /dev/null
+++ b/debian/git-email.files
@@ -0,0 +1,2 @@
+/usr/bin/git-send-email
+/usr/share/doc/git-core/git-send-email.*
diff --git a/debian/git-svn.files b/debian/git-svn.files
new file mode 100644
index 0000000..317b12a
--- /dev/null
+++ b/debian/git-svn.files
@@ -0,0 +1,2 @@
+/usr/bin/git-svnimport
+/usr/share/doc/git-core/git-svnimport.*
diff --git a/debian/rules b/debian/rules
index 568d430..cf33cdf 100755
--- a/debian/rules
+++ b/debian/rules
@@ -41,7 +41,7 @@ MAN_DESTDIR := $(DESTDIR)/$(MANDIR)
build: debian/build-stamp
debian/build-stamp:
dh_testdir
- $(MAKE) prefix=$(PREFIX) PYTHON_PATH=/usr/bin/python2.4 all doc test
+ $(MAKE) prefix=$(PREFIX) PYTHON_PATH=/usr/bin/python2.4 all test doc
touch debian/build-stamp
debian-clean:
@@ -65,7 +65,10 @@ install: build
mkdir -p $(DOC_DESTDIR)
find $(DOC) '(' -name '*.txt' -o -name '*.html' ')' -exec install {} $(DOC_DESTDIR) ';'
+ dh_movefiles -p git-cvs
+ dh_movefiles -p git-svn
dh_movefiles -p git-tk
+ dh_movefiles -p git-email
dh_movefiles -p git-core
find debian/tmp -type d -o -print | sed -e 's/^/? /'
---
0.99.9.GIT
^ permalink raw reply related
* Re: [PATCH] Added a few examples to git-pull man page.
From: Junio C Hamano @ 2005-11-05 9:27 UTC (permalink / raw)
To: Jon Loeliger; +Cc: git
In-Reply-To: <E1EYDua-00017o-9d@jdl.com>
Thanks for the documentation updates. I have one
trouble about this part:
You never do your own development on branches that appear
on the right hand side of a <refspec> colon on `Pull:` lines;
they are to be updated by `git-fetch`. The corollary is that
a local branch should be introduced and named on a <refspec>
right-hand-side if you intend to do development derived from
that branch.
This leads to the common `Pull: master:origin` mapping of a
remote `master` branch to a local `origin` branch, which
is then merged to a local development branch, again typically
named `master`.
I am a bit confused by the "corollary". What happens if you
have the following:
Pull: master:origin
Pull: +pu:pu
Pull: maint:maint
and you say:
git-pull remote
when you are on your master branch is:
1. master, pu and maint from remote are copied to origin, pu,
and maint in the local repository (you already know this);
2. the updated origin is merged into the local master (you
alerady know this too).
If somebody intends to do development derived from say 'maint',
one way to do so would be something like this:
git checkout -b my-maint maint
.. work work work, commit commit commit
.. "git-format-patch maint..my-maint" to send patches
.. off, or send a pull request to upstream.
git fetch remote ;# to update origin, pu, and maint.
git pull . maint ;# merge maint changes into my-maint.
That is, my-maint branch is used for your own development, and
from time to time you fetch remote heads (using remotes/remote
shorthands, the fetch would update origin, pu and maint) to keep
track of the progress of the upstream. And you merge upstream
'maint' into your development line 'my-maint', when you find
that the upstream have something new in 'maint'.
And because of the rule "you never do your own development on RHS
branch":
git checkout maint
.. work work work, commit commit commit
git pull remote ;# oops
this is discouraged. 'git pull remote' would try to overwrite
the local 'maint' with the remote 'maint', and it would find
that the head would not fast-forward (obviously, since we did
our own work that the remote side does not know about). But
when I read the "corollary" the first time, it appeared to me
that we are suggesting the above.
Maybe something like this (I know my wording is quite bad and I
would appreciate rephrasing it better very much) would be more
explicit and appropriate?
If you intend to do development derived from a remote
branch B, have a `Pull:` line to track it, like this:
Pull: B:remote-B
and have a separate branch my-B to do your development
on top of it. The latter is created by 'git branch my-B
remote-B' (or its equivalent, 'git checkout -b my-B
remote-B'), and that is the branch you make your own
commits. Run 'git fetch' to keep track of the progress
of the remote side, and when you see the tracked remote
branch has something new, merge it into your development
branch with 'git pull . remote-B', while you are on my-B
branch.
^ permalink raw reply
* [PATCH] Simplify CFLAGS/DEFINES in Makefile
From: Junio C Hamano @ 2005-11-05 7:57 UTC (permalink / raw)
To: git; +Cc: David Brown, Morten Welinder
In-Reply-To: <7vek5ww8q5.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> writes:
> David Brown <git@davidb.org> writes:
>
>> And the additional CFLAGS will only apply to the compilation of foo.
>> Since the ALL_CFLAGS is expanded lazily, it gets expanded for each target,
>> and the rule above causes CFLAGS to have extra values only on that target.
>
> Lazy expansion is true, but the reason we did ALL_CFLAGS was to
> make CFLAGS overridable from the command line.
>
> I suspect that this would currently fail to add -I/some/where/include
> on the compilation command line:
>
> make CFLAGS='-Os -g' CURLDIR=/some/where
>
> while CURL_LIBCURL is set correctly on the linkage command line.
So here is a proposed fix. Likes, dislikes, "you are a idiot
and you do not understand make"s?
-jc
-- >8 -- cut here -- >8 --
I think the original intention was to make CFLAGS overridable
from the make command line, but somehow we ended up accumulating
conditional makefile sections that wrongly appends values to
CFLAGs. These assignments do not work when the user actually
override them from the make command line!
DEFINES are handled the same way; it was seemingly overridable,
but the makefile sections had assignments, which meant
overriding it from the command line broke things.
This simplifies things by limiting the internal futzing to
ALL_CFLAGS, and by removing DEFINES altogether. Overriding
CFLAGS from the command line should start working with this
change.
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
Makefile | 32 ++++++++++++++------------------
1 files changed, 14 insertions(+), 18 deletions(-)
applies-to: ef3876e50bb5e91a6fb40d4e59df2178c6f40237
3502cee71d7c0d1a0c9d792f9d185886e91d5d26
diff --git a/Makefile b/Makefile
index 6c01dc2..6064672 100644
--- a/Makefile
+++ b/Makefile
@@ -37,25 +37,21 @@
# 1461501637330902918203684832716283019655932542976 hashes do not give you
# sufficient guarantee that no collisions between objects will ever happen.
-# DEFINES += -DCOLLISION_CHECK
-
# Define USE_NSEC below if you want git to care about sub-second file mtimes
# and ctimes. Note that you need recent glibc (at least 2.2.4) for this, and
# it will BREAK YOUR LOCAL DIFFS! show-diff and anything using it will likely
# randomly break unless your underlying filesystem supports those sub-second
# times (my ext3 doesn't).
-# DEFINES += -DUSE_NSEC
-
# Define USE_STDEV below if you want git to care about the underlying device
# change being considered an inode change from the update-cache perspective.
-# DEFINES += -DUSE_STDEV
-
GIT_VERSION = 0.99.9.GIT
+# CFLAGS is for the users to override from the command line.
+
CFLAGS = -g -O2 -Wall
-ALL_CFLAGS = $(CFLAGS) $(PLATFORM_DEFINES) $(DEFINES)
+ALL_CFLAGS = $(CFLAGS)
prefix = $(HOME)
bindir = $(prefix)/bin
@@ -194,19 +190,19 @@ ifeq ($(uname_S),SunOS)
NO_STRCASESTR = YesPlease
INSTALL = ginstall
TAR = gtar
- PLATFORM_DEFINES += -D__EXTENSIONS__
+ ALL_CFLAGS += -D__EXTENSIONS__
endif
ifeq ($(uname_O),Cygwin)
NO_STRCASESTR = YesPlease
NEEDS_LIBICONV = YesPlease
NO_IPV6 = YesPlease
X = .exe
- PLATFORM_DEFINES += -DUSE_SYMLINK_HEAD=0
+ ALL_CFLAGS += -DUSE_SYMLINK_HEAD=0
endif
ifeq ($(uname_S),OpenBSD)
NO_STRCASESTR = YesPlease
NEEDS_LIBICONV = YesPlease
- PLATFORM_DEFINES += -I/usr/local/include -L/usr/local/lib
+ ALL_CFLAGS += -I/usr/local/include -L/usr/local/lib
endif
ifneq (,$(findstring arm,$(uname_M)))
ARM_SHA1 = YesPlease
@@ -217,7 +213,7 @@ endif
ifndef NO_CURL
ifdef CURLDIR
# This is still problematic -- gcc does not want -R.
- CFLAGS += -I$(CURLDIR)/include
+ ALL_CFLAGS += -I$(CURLDIR)/include
CURL_LIBCURL = -L$(CURLDIR)/lib -R$(CURLDIR)/lib -lcurl
else
CURL_LIBCURL = -lcurl
@@ -240,13 +236,13 @@ ifndef NO_OPENSSL
OPENSSL_LIBSSL = -lssl
ifdef OPENSSLDIR
# Again this may be problematic -- gcc does not always want -R.
- CFLAGS += -I$(OPENSSLDIR)/include
+ ALL_CFLAGS += -I$(OPENSSLDIR)/include
OPENSSL_LINK = -L$(OPENSSLDIR)/lib -R$(OPENSSLDIR)/lib
else
OPENSSL_LINK =
endif
else
- DEFINES += -DNO_OPENSSL
+ ALL_CFLAGS += -DNO_OPENSSL
MOZILLA_SHA1 = 1
OPENSSL_LIBSSL =
endif
@@ -258,7 +254,7 @@ endif
ifdef NEEDS_LIBICONV
ifdef ICONVDIR
# Again this may be problematic -- gcc does not always want -R.
- CFLAGS += -I$(ICONVDIR)/include
+ ALL_CFLAGS += -I$(ICONVDIR)/include
ICONV_LINK = -L$(ICONVDIR)/lib -R$(ICONVDIR)/lib
else
ICONV_LINK =
@@ -276,15 +272,15 @@ ifdef NEEDS_NSL
SIMPLE_LIB += -lnsl
endif
ifdef NO_STRCASESTR
- DEFINES += -Dstrcasestr=gitstrcasestr -DNO_STRCASESTR=1
+ ALL_CFLAGS += -Dstrcasestr=gitstrcasestr -DNO_STRCASESTR=1
LIB_OBJS += compat/strcasestr.o
endif
ifdef NO_MMAP
- DEFINES += -Dmmap=gitfakemmap -Dmunmap=gitfakemunmap -DNO_MMAP
+ ALL_CFLAGS += -Dmmap=gitfakemmap -Dmunmap=gitfakemunmap -DNO_MMAP
LIB_OBJS += compat/mmap.o
endif
ifdef NO_IPV6
- DEFINES += -DNO_IPV6 -Dsockaddr_storage=sockaddr_in
+ ALL_CFLAGS += -DNO_IPV6 -Dsockaddr_storage=sockaddr_in
endif
ifdef PPC_SHA1
@@ -305,7 +301,7 @@ endif
endif
endif
-DEFINES += -DSHA1_HEADER=$(call shellquote,$(SHA1_HEADER))
+ALL_CFLAGS += -DSHA1_HEADER=$(call shellquote,$(SHA1_HEADER))
SCRIPTS = $(patsubst %.sh,%,$(SCRIPT_SH)) \
$(patsubst %.perl,%,$(SCRIPT_PERL)) \
---
0.99.9.GIT
^ permalink raw reply related
* [PATCH] Added a few examples to git-pull man page.
From: Jon Loeliger @ 2005-11-05 2:36 UTC (permalink / raw)
To: git
Added a few examples to git-pull man page.
Clarified and added notes for pull/push refspecs.
Converted to back-ticks for literal text examples.
Signed-off-by: Jon Loeliger <jdl@freescale.com>
---
Hmmm. Are back-ticks the standard for literal text examples?
Documentation/git-pull.txt | 55 ++++++++++++++++++++++++++--
Documentation/pull-fetch-param.txt | 72 +++++++++++++++++++++++++-----------
2 files changed, 101 insertions(+), 26 deletions(-)
applies-to: a469bc3e7efcb96db78bbffcdabcbea01bead34d
ca90ebc23d3e6fb73bc7da3e3d893adab8456722
diff --git a/Documentation/git-pull.txt b/Documentation/git-pull.txt
index cef4c0a..8f37d53 100644
--- a/Documentation/git-pull.txt
+++ b/Documentation/git-pull.txt
@@ -19,7 +19,7 @@ When only one ref is downloaded, runs 'g
into the local HEAD. Otherwise uses 'git octopus' to merge them
into the local HEAD.
-Note that you can use '.' (current directory) as the
+Note that you can use `.` (current directory) as the
<repository> to pull from the local repository -- this is useful
when merging local branches into the current branch.
@@ -29,8 +29,57 @@ include::pull-fetch-param.txt[]
-a, \--append::
Append ref names and object names of fetched refs to the
- existing contents of $GIT_DIR/FETCH_HEAD. Without this
- option old data in $GIT_DIR/FETCH_HEAD will be overwritten.
+ existing contents of `$GIT_DIR/FETCH_HEAD`. Without this
+ option old data in `$GIT_DIR/FETCH_HEAD` will be overwritten.
+
+Examples
+--------
+Command line pull of multiple branches from one repository::
++
+------------------------------------------------
+$ cat .git/remotes/origin
+URL: rsync://rsync.kernel.org/pub/scm/git/git.git
+Pull: master:origin
+
+$ git checkout master
+$ git fetch origin master:origin +pu:pu maint:maint
+$ git pull . origin
+------------------------------------------------
++
+Here, a typical `$GIT_DIR/remotes/origin` file from a
+`git-clone` operation is used in combination with
+command line options to `git-fetch` to first update
+multiple branches of the local repository and then
+to merge the remote `origin` branch into the local
+`master` branch. The local `pu` branch is updated
+even if it does not result in a fast forward update.
+Here, the pull can obtain its objects from the local
+repository using `.`, as the previous `git-fetch` is
+known to have already obtained and made available
+all the necessary objects.
+
+
+Pull of multiple branches from one repository using `$GIT_DIR/remotes` file::
++
+------------------------------------------------
+$ cat .git/remotes/origin
+URL: rsync://rsync.kernel.org/pub/scm/git/git.git
+Pull: master:origin
+Pull: +pu:pu
+Pull: maint:maint
+
+$ git checkout master
+$ git pull origin
+------------------------------------------------
++
+Here, a typical `$GIT_DIR/remotes/origin` file from a
+`git-clone` operation has been hand-modified to include
+the branch-mapping of additional remote and local
+heads directly. A single `git-pull` operation while
+in the `master` branch will fetch multiple heads and
+merge the remote `origin` head into the current,
+local `master` branch.
+
Author
------
diff --git a/Documentation/pull-fetch-param.txt b/Documentation/pull-fetch-param.txt
index e8db9d7..2a71318 100644
--- a/Documentation/pull-fetch-param.txt
+++ b/Documentation/pull-fetch-param.txt
@@ -1,7 +1,8 @@
<repository>::
- The "remote" repository to pull from. One of the
- following notations can be used to name the repository
- to pull from:
+ The "remote" repository that is the source of a fetch
+ or pull operation, or the destination of a push operation.
+ One of the following notations can be used
+ to name the remote repository:
+
===============================================================
- Rsync URL: rsync://remote.machine/path/to/repo.git/
@@ -12,7 +13,7 @@
===============================================================
+
In addition to the above, as a short-hand, the name of a
-file in $GIT_DIR/remotes directory can be given; the
+file in `$GIT_DIR/remotes` directory can be given; the
named file should be in the following format:
+
URL: one of the above URL format
@@ -21,57 +22,82 @@ named file should be in the following fo
+
When such a short-hand is specified in place of
<repository> without <refspec> parameters on the command
-line, <refspec>... specified on Push lines or Pull lines
-are used for "git push" and "git fetch/pull",
-respectively.
+line, <refspec>... specified on `Push:` lines or `Pull:`
+lines are used for `git-push` and `git-fetch`/`git-pull`,
+respectively. Multiple `Push:` and and `Pull:` lines may
+be specified for additional branch mappings.
+
-The name of a file in $GIT_DIR/branches directory can be
+The name of a file in `$GIT_DIR/branches` directory can be
specified as an older notation short-hand; the named
file should contain a single line, a URL in one of the
-above formats, optionally followed by a hash '#' and the
+above formats, optionally followed by a hash `#` and the
name of remote head (URL fragment notation).
-$GIT_DIR/branches/<remote> file that stores a <url>
+`$GIT_DIR/branches/<remote>` file that stores a <url>
without the fragment is equivalent to have this in the
-corresponding file in the $GIT_DIR/remotes/ directory
+corresponding file in the `$GIT_DIR/remotes/` directory.
+
URL: <url>
Pull: refs/heads/master:<remote>
+
-while having <url>#<head> is equivalent to
+while having `<url>#<head>` is equivalent to
+
URL: <url>
Pull: refs/heads/<head>:<remote>
<refspec>::
The canonical format of a <refspec> parameter is
- '+?<src>:<dst>'; that is, an optional plus '+', followed
- by the source ref, followed by a colon ':', followed by
+ `+?<src>:<dst>`; that is, an optional plus `+`, followed
+ by the source ref, followed by a colon `:`, followed by
the destination ref.
+
-When used in "git push", the <src> side can be an
+When used in `git-push`, the <src> side can be an
arbitrary "SHA1 expression" that can be used as an
-argument to "git-cat-file -t". E.g. "master~4" (push
+argument to `git-cat-file -t`. E.g. `master~4` (push
four parents before the current master head).
+
-For "git push", the local ref that matches <src> is used
+For `git-push`, the local ref that matches <src> is used
to fast forward the remote ref that matches <dst>. If
-the optional plus '+' is used, the remote ref is updated
+the optional plus `+` is used, the remote ref is updated
even if it does not result in a fast forward update.
+
-For "git fetch/pull", the remote ref that matches <src>
+For `git-fetch` and `git-pull`, the remote ref that matches <src>
is fetched, and if <dst> is not empty string, the local
ref that matches it is fast forwarded using <src>.
-Again, if the optional plus '+' is used, the local ref
+Again, if the optional plus `+` is used, the local ref
is updated even if it does not result in a fast forward
update.
+
+[NOTE]
+If the remote branch from which you want to pull is
+modified in non-linear ways such as being rewound and
+rebased frequently, then a pull will attempt a merge with
+an older version of itself, likely conflict, and fail.
+It is under these conditions that you would want to use
+the `+` sign to indicate non-fast-forward updates will
+be needed. There is currently no easy way to determine
+or declare that a branch will be made available in a
+repository with this behavior; the pulling user simply
+must know this is the expected usage pattern for a branch.
++
+[NOTE]
+You never do your own development on branches that appear
+on the right hand side of a <refspec> colon on `Pull:` lines;
+they are to be updated by `git-fetch`. The corollary is that
+a local branch should be introduced and named on a <refspec>
+right-hand-side if you intend to do development derived from
+that branch.
+This leads to the common `Pull: master:origin` mapping of a
+remote `master` branch to a local `origin` branch, which
+is then merged to a local development branch, again typically
+named `master`.
++
Some short-cut notations are also supported.
+
-* For backward compatibility, "tag" is almost ignored;
+* For backward compatibility, `tag` is almost ignored;
it just makes the following parameter <tag> to mean a
- refspec "refs/tags/<tag>:refs/tags/<tag>".
+ refspec `refs/tags/<tag>:refs/tags/<tag>`.
* A parameter <ref> without a colon is equivalent to
- <ref>: when pulling/fetching, and <ref>:<ref> when
+ <ref>: when pulling/fetching, and <ref>`:`<ref> when
pushing. That is, do not store it locally if
fetching, and update the same name if pushing.
---
0.99.9.GIT
^ permalink raw reply related
* Re: Trying to Update All Heads of a Repository
From: Junio C Hamano @ 2005-11-05 2:07 UTC (permalink / raw)
To: Daniel Barkalow; +Cc: Jon Loeliger, git
In-Reply-To: <Pine.LNX.4.64.0511041745480.25300@iabervon.org>
Daniel Barkalow <barkalow@iabervon.org> writes:
> Shouldn't approximately this be what git-clone sets up for you? If it's
> getting those heads initially, it should keep the information for future
> use. The only thing it wouldn't know would be the "+" on pu.
Yes, and I am actually thinking along the lines of:
URL: git://git.kernel.org/pub/scm/git/git.git
Pull: master:origin/master
Pull: +pu:origin/pu
Pull: maint:origin/maint
to further prevent the puller's namespace being cluttered. This
has an added benefit that it gives a convention that
"remotes/origin" file describes the "refs/heads/origin"
hierarchy. In the past, somebody complained that branches/*
files are configuration per local branch, but remotes/* files
are not.
> On the "pu" issue, maybe "pu" shouldn't be a branch, but should be
> something different, like a tag. I think, actually, that a tag would
> describe "pu" pretty well: no development happens on its line; rather,
> development happens elsewhere (topic branches), and a merge of some of
> them is then released as being interesting.
Hmph. That is a thought.
Another thing that bothers me somewhat about git.git/ repository
is the todo branch. The "todo" branch does not have any common
commit from the mainline and it is deliberately so --- I'd want
to maintain a unified TODO list even after we go 1.0, at that
time I plan to have master that continues post 1.0 development,
maint which corresponds the current maint (i.e. maintenance for
post 1.0 releases) and maint1.0 which is for backporting
important fixes to frozen 1.0. I could maintain separate
TODO-for-post-1.0 and TODO-for-1.0-maint, but that is rather a
waste --- items on the two list both end up requirign attention
and time from the same brain. Also merging "todo" into master
and maint1.0 the way "gitk" project was merged into git.git
would not make much sense, because that merge is pretty much
one-way street.
The first thing I clone from git.git/ repository is almost
always "rm -f .git/refs/heads/todo", because it clutters
git-show-branch output otherwise ;-). In fact, it comes from
totally separate repository on my private end, and just happens
to be pushed into the same git.git/ repository (partly because I
do not have any other repository there at kernel.org; i.e.
/pub/scm/git/ is not writable by me).
^ permalink raw reply
* Re: Trying to Update All Heads of a Repository
From: Daniel Barkalow @ 2005-11-04 23:47 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jon Loeliger, git
In-Reply-To: <7vy8453zhu.fsf@assigned-by-dhcp.cox.net>
On Thu, 3 Nov 2005, Junio C Hamano wrote:
> Jon Loeliger <jdl@freescale.com> writes:
>
> > First, I have this, because it came with a git-clone:
> >
> > % cat .git/remotes/origin
> > URL: rsync://rsync.kernel.org/pub/scm/git/git.git
> > Pull: master:origin
> >
> > I don't know how to say "Grab all the updates for
> > all the heads for which I have heads in my .git/refs".
>
> My "guinea pig" repository has this in $GIT_DIR/remotes/origin:
>
> URL: git://git.kernel.org/pub/scm/git/git.git
> Pull: master:origin
> Pull: +pu:pu
> Pull: maint:maint
Shouldn't approximately this be what git-clone sets up for you? If it's
getting those heads initially, it should keep the information for future
use. The only thing it wouldn't know would be the "+" on pu.
On the "pu" issue, maybe "pu" shouldn't be a branch, but should be
something different, like a tag. I think, actually, that a tag would
describe "pu" pretty well: no development happens on its line; rather,
development happens elsewhere (topic branches), and a merge of some of
them is then released as being interesting. What is interesting as "pu"
today isn't necessarily related to yesterday or tomorrow. Then you
wouldn't exactly be rebasing things all the time, but you'd instead be
marking different and unrelated commits in the same way at different
times. (Probably need to do more to handle the case where a tag ref
changes and define the semantics properly)
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* [PATCH 4/4] Refresh the remote lock if it is about to expire
From: Nick Hengeveld @ 2005-11-04 22:22 UTC (permalink / raw)
To: git
Refresh the remote lock if it is about to expire
Signed-off-by: Nick Hengeveld <nickh@reactrix.com>
---
http-push.c | 106 ++++++++++++++++++++++++++++++++++++++++++++---------------
1 files changed, 79 insertions(+), 27 deletions(-)
applies-to: 678d5afb150b94bf4a516f852cd41f6920e8642b
197abe5895bea9924c8f01398d9fc73ec013cbd5
diff --git a/http-push.c b/http-push.c
index 85cd595..c10067c 100644
--- a/http-push.c
+++ b/http-push.c
@@ -40,6 +40,9 @@ static const char http_push_usage[] =
#define PROPFIND_REQUEST "<?xml version=\"1.0\" encoding=\"utf-8\" ?>\n<D:propfind xmlns:D=\"DAV:\">\n<D:prop xmlns:R=\"%s\">\n<D:supportedlock/>\n</D:prop>\n</D:propfind>"
#define LOCK_REQUEST "<?xml version=\"1.0\" encoding=\"utf-8\" ?>\n<D:lockinfo xmlns:D=\"DAV:\">\n<D:lockscope><D:exclusive/></D:lockscope>\n<D:locktype><D:write/></D:locktype>\n<D:owner>\n<D:href>mailto:%s</D:href>\n</D:owner>\n</D:lockinfo>"
+#define LOCK_TIME 600
+#define LOCK_REFRESH 30
+
static int active_requests = 0;
static int data_received;
static int pushing = 0;
@@ -143,10 +146,12 @@ struct active_lock
int ctx_timeout;
int ctx_locktoken;
int ctx_locktoken_href;
+ char *url;
char *owner;
+ char *token;
time_t start_time;
long timeout;
- char *token;
+ int refreshing;
};
struct lockprop
@@ -580,11 +585,65 @@ static void start_move(struct transfer_r
}
}
+int refresh_lock(struct active_lock *lock)
+{
+ struct active_request_slot *slot;
+ char *if_header;
+ char timeout_header[25];
+ struct curl_slist *dav_headers = NULL;
+ int rc = 0;
+
+ lock->refreshing = 1;
+
+ if_header = xmalloc(strlen(lock->token) + 25);
+ sprintf(if_header, "If: (<opaquelocktoken:%s>)", lock->token);
+ sprintf(timeout_header, "Timeout: Second-%ld", lock->timeout);
+ dav_headers = curl_slist_append(dav_headers, if_header);
+ dav_headers = curl_slist_append(dav_headers, timeout_header);
+
+ slot = get_active_slot();
+ curl_easy_setopt(slot->curl, CURLOPT_HTTPGET, 1);
+ curl_easy_setopt(slot->curl, CURLOPT_WRITEFUNCTION, fwrite_null);
+ curl_easy_setopt(slot->curl, CURLOPT_URL, lock->url);
+ curl_easy_setopt(slot->curl, CURLOPT_CUSTOMREQUEST, DAV_LOCK);
+ curl_easy_setopt(slot->curl, CURLOPT_HTTPHEADER, dav_headers);
+
+ if (start_active_slot(slot)) {
+ run_active_slot(slot);
+ if (slot->curl_result != CURLE_OK) {
+ fprintf(stderr, "Got HTTP error %ld\n", slot->http_code);
+ } else {
+ lock->start_time = time(NULL);
+ rc = 1;
+ }
+ }
+
+ lock->refreshing = 0;
+ curl_slist_free_all(dav_headers);
+ free(if_header);
+
+ return rc;
+}
+
static void finish_request(struct transfer_request *request)
{
+ time_t current_time = time(NULL);
+ int time_remaining;
+
request->curl_result = request->slot->curl_result;
request->http_code = request->slot->http_code;
request->slot = NULL;
+
+ /* Refresh the lock if it is close to timing out */
+ time_remaining = request->lock->start_time + request->lock->timeout
+ - current_time;
+ if (time_remaining < LOCK_REFRESH && !request->lock->refreshing) {
+ if (!refresh_lock(request->lock)) {
+ fprintf(stderr, "Unable to refresh remote lock\n");
+ aborted = 1;
+ }
+ }
+
if (request->headers != NULL)
curl_slist_free_all(request->headers);
if (request->state == RUN_HEAD) {
@@ -1114,7 +1173,7 @@ end_lockprop_element(void *userData, con
}
}
-struct active_lock *lock_remote(char *file, int timeout)
+struct active_lock *lock_remote(char *file, long timeout)
{
struct active_request_slot *slot;
struct buffer out_buffer;
@@ -1175,8 +1234,9 @@ struct active_lock *lock_remote(char *fi
new_lock->owner = NULL;
new_lock->token = NULL;
new_lock->timeout = -1;
+ new_lock->refreshing = 0;
- sprintf(timeout_header, "Timeout: Second-%d", timeout);
+ sprintf(timeout_header, "Timeout: Second-%ld", timeout);
dav_headers = curl_slist_append(dav_headers, timeout_header);
dav_headers = curl_slist_append(dav_headers, "Content-Type: text/xml");
@@ -1211,7 +1271,6 @@ struct active_lock *lock_remote(char *fi
return NULL;
}
- free(url);
free(out_data);
XML_SetUserData(parser, new_lock);
@@ -1223,6 +1282,7 @@ struct active_lock *lock_remote(char *fi
if (result != XML_STATUS_OK) {
fprintf(stderr, "%s", XML_ErrorString(
XML_GetErrorCode(parser)));
+ free(url);
free(new_lock);
return NULL;
}
@@ -1232,18 +1292,19 @@ struct active_lock *lock_remote(char *fi
free(new_lock->token);
if (new_lock->owner != NULL)
free(new_lock->owner);
+ free(url);
free(new_lock);
return NULL;
}
+ new_lock->url = url;
new_lock->start_time = time(NULL);
return new_lock;
}
-int unlock_remote(char *file, struct active_lock *lock)
+int unlock_remote(struct active_lock *lock)
{
struct active_request_slot *slot;
- char *url;
char *lock_token_header;
struct curl_slist *dav_headers = NULL;
int rc = 0;
@@ -1251,13 +1312,11 @@ int unlock_remote(char *file, struct act
lock_token_header = xmalloc(strlen(lock->token) + 31);
sprintf(lock_token_header, "Lock-Token: <opaquelocktoken:%s>",
lock->token);
- url = xmalloc(strlen(remote->url) + strlen(file) + 1);
- sprintf(url, "%s%s", remote->url, file);
dav_headers = curl_slist_append(dav_headers, lock_token_header);
slot = get_active_slot();
curl_easy_setopt(slot->curl, CURLOPT_WRITEFUNCTION, fwrite_null);
- curl_easy_setopt(slot->curl, CURLOPT_URL, url);
+ curl_easy_setopt(slot->curl, CURLOPT_URL, lock->url);
curl_easy_setopt(slot->curl, CURLOPT_CUSTOMREQUEST, DAV_UNLOCK);
curl_easy_setopt(slot->curl, CURLOPT_HTTPHEADER, dav_headers);
@@ -1274,7 +1333,12 @@ int unlock_remote(char *file, struct act
curl_slist_free_all(dav_headers);
free(lock_token_header);
- free(url);
+
+ if (lock->owner != NULL)
+ free(lock->owner);
+ free(lock->url);
+ free(lock->token);
+ free(lock);
return rc;
}
@@ -1423,20 +1487,15 @@ void get_delta(unsigned char *sha1, stru
}
}
-int update_remote(char *remote_path, unsigned char *sha1,
- struct active_lock *lock)
+int update_remote(unsigned char *sha1, struct active_lock *lock)
{
struct active_request_slot *slot;
- char *url;
char *out_data;
char *if_header;
struct buffer out_buffer;
struct curl_slist *dav_headers = NULL;
int i;
- url = xmalloc(strlen(remote->url) + strlen(remote_path) + 1);
- sprintf(url, "%s%s", remote->url, remote_path);
-
if_header = xmalloc(strlen(lock->token) + 25);
sprintf(if_header, "If: (<opaquelocktoken:%s>)", lock->token);
dav_headers = curl_slist_append(dav_headers, if_header);
@@ -1460,13 +1519,12 @@ int update_remote(char *remote_path, uns
curl_easy_setopt(slot->curl, CURLOPT_HTTPHEADER, dav_headers);
curl_easy_setopt(slot->curl, CURLOPT_UPLOAD, 1);
curl_easy_setopt(slot->curl, CURLOPT_PUT, 1);
- curl_easy_setopt(slot->curl, CURLOPT_URL, url);
+ curl_easy_setopt(slot->curl, CURLOPT_URL, lock->url);
if (start_active_slot(slot)) {
run_active_slot(slot);
free(out_data);
free(if_header);
- free(url);
if (slot->curl_result != CURLE_OK) {
fprintf(stderr,
"PUT error: curl result=%d, HTTP code=%ld\n",
@@ -1477,7 +1535,6 @@ int update_remote(char *remote_path, uns
} else {
free(out_data);
free(if_header);
- free(url);
fprintf(stderr, "Unable to start PUT request\n");
return 0;
}
@@ -1629,7 +1686,7 @@ int main(int argc, char **argv)
free(remote_path);
remote_path = xmalloc(strlen(remote_ref) + 12);
sprintf(remote_path, "refs/heads/%s", remote_ref);
- remote_lock = lock_remote(remote_path, 3600);
+ remote_lock = lock_remote(remote_path, LOCK_TIME);
if (remote_lock == NULL) {
fprintf(stderr, "Unable to lock remote branch %s\n",
remote_ref);
@@ -1701,8 +1758,7 @@ int main(int argc, char **argv)
/* Update the remote branch if all went well */
if (do_remote_update) {
- if (!aborted && update_remote(remote_path,
- local_sha1,
+ if (!aborted && update_remote(local_sha1,
remote_lock)) {
fprintf(stderr, "%s remote branch %s\n",
new_branch ? "Created" : "Updated",
@@ -1718,12 +1774,8 @@ int main(int argc, char **argv)
}
unlock:
- unlock_remote(remote_path, remote_lock);
+ unlock_remote(remote_lock);
free(remote_path);
- if (remote_lock->owner != NULL)
- free(remote_lock->owner);
- free(remote_lock->token);
- free(remote_lock);
}
cleanup:
---
0.99.9.GIT
^ permalink raw reply related
* [PATCH 3/4] Improve lock handling
From: Nick Hengeveld @ 2005-11-04 22:22 UTC (permalink / raw)
To: git
Improve lock handling: parse the server response for the timeout, owner,
and lock token
Signed-off-by: Nick Hengeveld <nickh@reactrix.com>
---
http-push.c | 201 +++++++++++++++++++++++++++++++++++++++++++----------------
1 files changed, 147 insertions(+), 54 deletions(-)
applies-to: 99366e40c96e3fd0436287c601697f3166e8cf36
1b26b4528dc9e14f2be5d57154022249206fcc6f
diff --git a/http-push.c b/http-push.c
index 6a241aa..85cd595 100644
--- a/http-push.c
+++ b/http-push.c
@@ -55,7 +55,6 @@ static CURL *curl_default;
static struct curl_slist *no_pragma_header;
static struct curl_slist *default_headers;
static char curl_errorstr[CURL_ERROR_SIZE];
-static char *lock_token = NULL;
static int push_verbosely = 0;
static int push_all = 0;
@@ -92,7 +91,7 @@ struct transfer_request
unsigned char sha1[20];
char *url;
char *dest;
- char *lock_token;
+ struct active_lock *lock;
struct curl_slist *headers;
struct buffer buffer;
char filename[PATH_MAX];
@@ -136,6 +135,20 @@ static char *ssl_cainfo = NULL;
static long curl_low_speed_limit = -1;
static long curl_low_speed_time = -1;
+struct active_lock
+{
+ int ctx_activelock;
+ int ctx_owner;
+ int ctx_owner_href;
+ int ctx_timeout;
+ int ctx_locktoken;
+ int ctx_locktoken_href;
+ char *owner;
+ time_t start_time;
+ long timeout;
+ char *token;
+};
+
struct lockprop
{
int supported_lock;
@@ -509,7 +522,7 @@ static void start_put(struct transfer_re
if (request->url != NULL)
free(request->url);
request->url = xmalloc(strlen(remote->url) +
- strlen(request->lock_token) + 51);
+ strlen(request->lock->token) + 51);
strcpy(request->url, remote->url);
posn = request->url + strlen(remote->url);
strcpy(posn, "objects/");
@@ -522,7 +535,7 @@ static void start_put(struct transfer_re
sprintf(request->dest, "Destination: %s", request->url);
posn += 38;
*(posn++) = '.';
- strcpy(posn, request->lock_token);
+ strcpy(posn, request->lock->token);
slot = get_active_slot();
curl_easy_setopt(slot->curl, CURLOPT_INFILE, &request->buffer);
@@ -724,7 +737,7 @@ void process_waiting_requests(void)
}
}
-void add_request(unsigned char *sha1, char *lock_token)
+void add_request(unsigned char *sha1, struct active_lock *lock)
{
struct transfer_request *request = request_queue_head;
struct packed_git *target;
@@ -741,7 +754,7 @@ void add_request(unsigned char *sha1, ch
request = xmalloc(sizeof(*request));
memcpy(request->sha1, sha1, 20);
request->url = NULL;
- request->lock_token = lock_token;
+ request->lock = lock;
request->headers = NULL;
request->state = NEED_CHECK;
request->next = request_queue_head;
@@ -999,6 +1012,68 @@ int fetch_ref(char *ref, unsigned char *
}
static void
+start_activelock_element(void *userData, const char *name, const char **atts)
+{
+ struct active_lock *lock = (struct active_lock *)userData;
+
+ if (lock->ctx_activelock && !strcmp(name, "D:timeout"))
+ lock->ctx_timeout = 1;
+ else if (lock->ctx_owner && strstr(name, "href"))
+ lock->ctx_owner_href = 1;
+ else if (lock->ctx_activelock && strstr(name, "owner"))
+ lock->ctx_owner = 1;
+ else if (lock->ctx_locktoken && !strcmp(name, "D:href"))
+ lock->ctx_locktoken_href = 1;
+ else if (lock->ctx_activelock && !strcmp(name, "D:locktoken"))
+ lock->ctx_locktoken = 1;
+ else if (!strcmp(name, "D:activelock"))
+ lock->ctx_activelock = 1;
+}
+
+static void
+end_activelock_element(void *userData, const char *name)
+{
+ struct active_lock *lock = (struct active_lock *)userData;
+
+ if (lock->ctx_timeout && !strcmp(name, "D:timeout")) {
+ lock->ctx_timeout = 0;
+ } else if (lock->ctx_owner_href && strstr(name, "href")) {
+ lock->ctx_owner_href = 0;
+ } else if (lock->ctx_owner && strstr(name, "owner")) {
+ lock->ctx_owner = 0;
+ } else if (lock->ctx_locktoken_href && !strcmp(name, "D:href")) {
+ lock->ctx_locktoken_href = 0;
+ } else if (lock->ctx_locktoken && !strcmp(name, "D:locktoken")) {
+ lock->ctx_locktoken = 0;
+ } else if (lock->ctx_activelock && !strcmp(name, "D:activelock")) {
+ lock->ctx_activelock = 0;
+ }
+}
+
+static void
+activelock_cdata(void *userData, const XML_Char *s, int len)
+{
+ struct active_lock *lock = (struct active_lock *)userData;
+ char *this = malloc(len+1);
+ strncpy(this, s, len);
+
+ if (lock->ctx_owner_href) {
+ lock->owner = malloc(len+1);
+ strcpy(lock->owner, this);
+ } else if (lock->ctx_locktoken_href) {
+ if (!strncmp(this, "opaquelocktoken:", 16)) {
+ lock->token = malloc(len-15);
+ strcpy(lock->token, this+16);
+ }
+ } else if (lock->ctx_timeout) {
+ if (!strncmp(this, "Second-", 7))
+ lock->timeout = strtol(this+7, NULL, 10);
+ }
+
+ free(this);
+}
+
+static void
start_lockprop_element(void *userData, const char *name, const char **atts)
{
struct lockprop *prop = (struct lockprop *)userData;
@@ -1039,40 +1114,21 @@ end_lockprop_element(void *userData, con
}
}
-size_t process_lock_header( void *ptr, size_t size, size_t nmemb, void *stream)
-{
- size_t header_size = size*nmemb;
- char *start;
- char *end;
-
- if (!strncmp(ptr, "Lock-Token: <opaquelocktoken:", 29)) {
- start = ptr + 29;
- for (end = ptr + header_size;
- *(end - 1) == '\r' || *(end - 1) == '\n' || *(end - 1) == '>';
- end--) {}
- if (end > start) {
- lock_token = xmalloc(end - start + 1);
- memcpy(lock_token, start, end - start);
- lock_token[end - start] = 0;
- }
- }
-
- return header_size;
-}
-
-char *lock_remote(char *file, int timeout)
+struct active_lock *lock_remote(char *file, int timeout)
{
struct active_request_slot *slot;
struct buffer out_buffer;
+ struct buffer in_buffer;
char *out_data;
+ char *in_data;
char *url;
char *ep;
char timeout_header[25];
+ struct active_lock *new_lock;
+ XML_Parser parser = XML_ParserCreate(NULL);
+ enum XML_Status result;
struct curl_slist *dav_headers = NULL;
- if (lock_token != NULL)
- free(lock_token);
-
url = xmalloc(strlen(remote->url) + strlen(file) + 1);
sprintf(url, "%s%s", remote->url, file);
@@ -1110,6 +1166,16 @@ char *lock_remote(char *file, int timeou
out_buffer.posn = 0;
out_buffer.buffer = out_data;
+ in_buffer.size = 4096;
+ in_data = xmalloc(in_buffer.size);
+ in_buffer.posn = 0;
+ in_buffer.buffer = in_data;
+
+ new_lock = xmalloc(sizeof(*new_lock));
+ new_lock->owner = NULL;
+ new_lock->token = NULL;
+ new_lock->timeout = -1;
+
sprintf(timeout_header, "Timeout: Second-%d", timeout);
dav_headers = curl_slist_append(dav_headers, timeout_header);
dav_headers = curl_slist_append(dav_headers, "Content-Type: text/xml");
@@ -1118,9 +1184,9 @@ char *lock_remote(char *file, int timeou
curl_easy_setopt(slot->curl, CURLOPT_INFILE, &out_buffer);
curl_easy_setopt(slot->curl, CURLOPT_INFILESIZE, out_buffer.size);
curl_easy_setopt(slot->curl, CURLOPT_READFUNCTION, fread_buffer);
- curl_easy_setopt(slot->curl, CURLOPT_WRITEFUNCTION, fwrite_null);
- curl_easy_setopt(slot->curl, CURLOPT_HEADERFUNCTION,
- process_lock_header);
+ curl_easy_setopt(slot->curl, CURLOPT_FILE, &in_buffer);
+ curl_easy_setopt(slot->curl, CURLOPT_WRITEFUNCTION,
+ fwrite_buffer_dynamic);
curl_easy_setopt(slot->curl, CURLOPT_URL, url);
curl_easy_setopt(slot->curl, CURLOPT_UPLOAD, 1);
curl_easy_setopt(slot->curl, CURLOPT_CUSTOMREQUEST, DAV_LOCK);
@@ -1130,13 +1196,17 @@ char *lock_remote(char *file, int timeou
run_active_slot(slot);
if (slot->curl_result != CURLE_OK) {
fprintf(stderr, "Got HTTP error %ld\n", slot->http_code);
+ free(new_lock);
free(url);
free(out_data);
+ free(in_data);
return NULL;
}
} else {
+ free(new_lock);
free(url);
free(out_data);
+ free(in_data);
fprintf(stderr, "Unable to start request\n");
return NULL;
}
@@ -1144,10 +1214,33 @@ char *lock_remote(char *file, int timeou
free(url);
free(out_data);
- return strdup(lock_token);
+ XML_SetUserData(parser, new_lock);
+ XML_SetElementHandler(parser, start_activelock_element,
+ end_activelock_element);
+ XML_SetCharacterDataHandler(parser, activelock_cdata);
+ result = XML_Parse(parser, in_buffer.buffer, in_buffer.posn, 1);
+ free(in_data);
+ if (result != XML_STATUS_OK) {
+ fprintf(stderr, "%s", XML_ErrorString(
+ XML_GetErrorCode(parser)));
+ free(new_lock);
+ return NULL;
+ }
+
+ if (new_lock->token == NULL || new_lock->timeout <= 0) {
+ if (new_lock->token != NULL)
+ free(new_lock->token);
+ if (new_lock->owner != NULL)
+ free(new_lock->owner);
+ free(new_lock);
+ return NULL;
+ }
+
+ new_lock->start_time = time(NULL);
+ return new_lock;
}
-int unlock_remote(char *file, char *lock_token)
+int unlock_remote(char *file, struct active_lock *lock)
{
struct active_request_slot *slot;
char *url;
@@ -1155,14 +1248,9 @@ int unlock_remote(char *file, char *lock
struct curl_slist *dav_headers = NULL;
int rc = 0;
- if (lock_token == NULL) {
- fprintf(stderr, "Unable to unlock, no lock token");
- return 0;
- }
-
- lock_token_header = xmalloc(strlen(lock_token) + 31);
+ lock_token_header = xmalloc(strlen(lock->token) + 31);
sprintf(lock_token_header, "Lock-Token: <opaquelocktoken:%s>",
- lock_token);
+ lock->token);
url = xmalloc(strlen(remote->url) + strlen(file) + 1);
sprintf(url, "%s%s", remote->url, file);
dav_headers = curl_slist_append(dav_headers, lock_token_header);
@@ -1278,7 +1366,8 @@ int is_ancestor(unsigned char *sha1, str
return 0;
}
-void get_delta(unsigned char *sha1, struct object *obj, char *lock_token)
+void get_delta(unsigned char *sha1, struct object *obj,
+ struct active_lock *lock)
{
struct commit *commit;
struct commit_list *parents;
@@ -1294,7 +1383,7 @@ void get_delta(unsigned char *sha1, stru
if (obj->type == commit_type) {
if (push_verbosely)
fprintf(stderr, "walk %s\n", sha1_to_hex(obj->sha1));
- add_request(obj->sha1, lock_token);
+ add_request(obj->sha1, lock);
commit = (struct commit *)obj;
if (parse_commit(commit)) {
fprintf(stderr, "Error parsing commit %s\n",
@@ -1307,12 +1396,12 @@ void get_delta(unsigned char *sha1, stru
if (sha1 == NULL ||
memcmp(sha1, parents->item->object.sha1, 20))
get_delta(sha1, &parents->item->object,
- lock_token);
- get_delta(sha1, &commit->tree->object, lock_token);
+ lock);
+ get_delta(sha1, &commit->tree->object, lock);
} else if (obj->type == tree_type) {
if (push_verbosely)
fprintf(stderr, "walk %s\n", sha1_to_hex(obj->sha1));
- add_request(obj->sha1, lock_token);
+ add_request(obj->sha1, lock);
tree = (struct tree *)obj;
if (parse_tree(tree)) {
fprintf(stderr, "Error parsing tree %s\n",
@@ -1324,17 +1413,18 @@ void get_delta(unsigned char *sha1, stru
tree->entries = NULL;
while (entry) {
struct tree_entry_list *next = entry->next;
- get_delta(sha1, entry->item.any, lock_token);
+ get_delta(sha1, entry->item.any, lock);
free(entry->name);
free(entry);
entry = next;
}
} else if (obj->type == blob_type || obj->type == tag_type) {
- add_request(obj->sha1, lock_token);
+ add_request(obj->sha1, lock);
}
}
-int update_remote(char *remote_path, unsigned char *sha1, char *lock_token)
+int update_remote(char *remote_path, unsigned char *sha1,
+ struct active_lock *lock)
{
struct active_request_slot *slot;
char *url;
@@ -1347,8 +1437,8 @@ int update_remote(char *remote_path, uns
url = xmalloc(strlen(remote->url) + strlen(remote_path) + 1);
sprintf(url, "%s%s", remote->url, remote_path);
- if_header = xmalloc(strlen(lock_token) + 25);
- sprintf(if_header, "If: (<opaquelocktoken:%s>)", lock_token);
+ if_header = xmalloc(strlen(lock->token) + 25);
+ sprintf(if_header, "If: (<opaquelocktoken:%s>)", lock->token);
dav_headers = curl_slist_append(dav_headers, if_header);
out_buffer.size = 41;
@@ -1411,7 +1501,7 @@ int main(int argc, char **argv)
struct object *local_object = NULL;
char *remote_ref = NULL;
unsigned char remote_sha1[20];
- char *remote_lock = NULL;
+ struct active_lock *remote_lock;
char *remote_path = NULL;
char *low_speed_limit;
char *low_speed_time;
@@ -1630,6 +1720,9 @@ int main(int argc, char **argv)
unlock:
unlock_remote(remote_path, remote_lock);
free(remote_path);
+ if (remote_lock->owner != NULL)
+ free(remote_lock->owner);
+ free(remote_lock->token);
free(remote_lock);
}
---
0.99.9.GIT
^ permalink raw reply related
* [PATCH 2/4] Support remote references with slashes in their names
From: Nick Hengeveld @ 2005-11-04 22:22 UTC (permalink / raw)
To: git
Support remote references with slashes in their names
Signed-off-by: Nick Hengeveld <nickh@reactrix.com>
---
http-push.c | 42 +++++++++++++++++++++++++++++++++++++++---
1 files changed, 39 insertions(+), 3 deletions(-)
applies-to: 54e1d462248523bfac7d7c4b42e3b1ce1270fbd9
33cd543dfe656dce9c5722e4fe6af22fa5a80e7e
diff --git a/http-push.c b/http-push.c
index 134d405..6a241aa 100644
--- a/http-push.c
+++ b/http-push.c
@@ -1066,12 +1066,44 @@ char *lock_remote(char *file, int timeou
struct buffer out_buffer;
char *out_data;
char *url;
+ char *ep;
char timeout_header[25];
struct curl_slist *dav_headers = NULL;
if (lock_token != NULL)
free(lock_token);
+ url = xmalloc(strlen(remote->url) + strlen(file) + 1);
+ sprintf(url, "%s%s", remote->url, file);
+
+ /* Make sure leading directories exist for the remote ref */
+ ep = strchr(url + strlen(remote->url) + 11, '/');
+ while (ep) {
+ *ep = 0;
+ slot = get_active_slot();
+ curl_easy_setopt(slot->curl, CURLOPT_HTTPGET, 1);
+ curl_easy_setopt(slot->curl, CURLOPT_URL, url);
+ curl_easy_setopt(slot->curl, CURLOPT_CUSTOMREQUEST, DAV_MKCOL);
+ curl_easy_setopt(slot->curl, CURLOPT_WRITEFUNCTION, fwrite_null);
+ if (start_active_slot(slot)) {
+ run_active_slot(slot);
+ if (slot->curl_result != CURLE_OK &&
+ slot->http_code != 405) {
+ fprintf(stderr,
+ "Unable to create branch path %s\n",
+ url);
+ free(url);
+ return NULL;
+ }
+ } else {
+ fprintf(stderr, "Unable to start request\n");
+ free(url);
+ return NULL;
+ }
+ *ep = '/';
+ ep = strchr(ep + 1, '/');
+ }
+
out_buffer.size = strlen(LOCK_REQUEST) + strlen(git_default_email) - 2;
out_data = xmalloc(out_buffer.size + 1);
snprintf(out_data, out_buffer.size + 1, LOCK_REQUEST, git_default_email);
@@ -1079,8 +1111,6 @@ char *lock_remote(char *file, int timeou
out_buffer.buffer = out_data;
sprintf(timeout_header, "Timeout: Second-%d", timeout);
- url = xmalloc(strlen(remote->url) + strlen(file) + 1);
- sprintf(url, "%s%s", remote->url, file);
dav_headers = curl_slist_append(dav_headers, timeout_header);
dav_headers = curl_slist_append(dav_headers, "Content-Type: text/xml");
@@ -1098,16 +1128,22 @@ char *lock_remote(char *file, int timeou
if (start_active_slot(slot)) {
run_active_slot(slot);
- free(out_data);
if (slot->curl_result != CURLE_OK) {
fprintf(stderr, "Got HTTP error %ld\n", slot->http_code);
+ free(url);
+ free(out_data);
return NULL;
}
} else {
+ free(url);
free(out_data);
fprintf(stderr, "Unable to start request\n");
+ return NULL;
}
+ free(url);
+ free(out_data);
+
return strdup(lock_token);
}
---
0.99.9.GIT
^ permalink raw reply related
* [PATCH 1/4] Verify remote packs, speed up pending request queue
From: Nick Hengeveld @ 2005-11-04 22:22 UTC (permalink / raw)
To: git
Verify that remote packs exist before using the pack index, add requests to
the beginning of the queue to locate pending requests faster.
Signed-off-by: Nick Hengeveld <nickh@reactrix.com>
---
http-push.c | 37 +++++++++++++++++++++----------------
1 files changed, 21 insertions(+), 16 deletions(-)
applies-to: aaaf3e5d771c5de11e2c4da6677f51c7e07f7a50
216264d37339c149efa8c2eb03dbf03f2812d5d1
diff --git a/http-push.c b/http-push.c
index e85f1c1..134d405 100644
--- a/http-push.c
+++ b/http-push.c
@@ -727,7 +727,6 @@ void process_waiting_requests(void)
void add_request(unsigned char *sha1, char *lock_token)
{
struct transfer_request *request = request_queue_head;
- struct transfer_request *tail;
struct packed_git *target;
while (request != NULL && memcmp(request->sha1, sha1, 20))
@@ -745,17 +744,8 @@ void add_request(unsigned char *sha1, ch
request->lock_token = lock_token;
request->headers = NULL;
request->state = NEED_CHECK;
- request->next = NULL;
-
- if (request_queue_head == NULL) {
- request_queue_head = request;
- } else {
- tail = request_queue_head;
- while (tail->next != NULL) {
- tail = tail->next;
- }
- tail->next = request;
- }
+ request->next = request_queue_head;
+ request_queue_head = request;
#ifdef USE_CURL_MULTI
process_request_queue();
process_curl_messages();
@@ -775,13 +765,29 @@ static int fetch_index(unsigned char *sh
FILE *indexfile;
struct active_request_slot *slot;
+ /* Don't use the index if the pack isn't there */
+ url = xmalloc(strlen(remote->url) + 65);
+ sprintf(url, "%s/objects/pack/pack-%s.pack", remote->url, hex);
+ slot = get_active_slot();
+ curl_easy_setopt(slot->curl, CURLOPT_URL, url);
+ curl_easy_setopt(slot->curl, CURLOPT_NOBODY, 1);
+ if (start_active_slot(slot)) {
+ run_active_slot(slot);
+ if (slot->curl_result != CURLE_OK) {
+ free(url);
+ return error("Unable to verify pack %s is available",
+ hex);
+ }
+ } else {
+ return error("Unable to start request");
+ }
+
if (has_pack_index(sha1))
return 0;
if (push_verbosely)
fprintf(stderr, "Getting index for pack %s\n", hex);
- url = xmalloc(strlen(remote->url) + 64);
sprintf(url, "%s/objects/pack/pack-%s.idx", remote->url, hex);
filename = sha1_pack_index_name(sha1);
@@ -792,6 +798,8 @@ static int fetch_index(unsigned char *sh
filename);
slot = get_active_slot();
+ curl_easy_setopt(slot->curl, CURLOPT_NOBODY, 0);
+ curl_easy_setopt(slot->curl, CURLOPT_HTTPGET, 1);
curl_easy_setopt(slot->curl, CURLOPT_FILE, indexfile);
curl_easy_setopt(slot->curl, CURLOPT_WRITEFUNCTION, fwrite);
curl_easy_setopt(slot->curl, CURLOPT_URL, url);
@@ -833,8 +841,6 @@ static int fetch_index(unsigned char *sh
static int setup_index(unsigned char *sha1)
{
struct packed_git *new_pack;
- if (has_pack_file(sha1))
- return 0; // don't list this as something we can get
if (fetch_index(sha1))
return -1;
@@ -1610,7 +1616,6 @@ int main(int argc, char **argv)
while (request != NULL) {
next_request = request->next;
release_request(request);
- free(request);
request = next_request;
}
---
0.99.9.GIT
^ permalink raw reply related
* [PATCH 0/4] git-http-push improvements
From: Nick Hengeveld @ 2005-11-04 22:22 UTC (permalink / raw)
To: git
This series of patches makes HTTP/DAV pushes more stable. Locks are
handled much better and are refreshed if they are about to expire, and
remote refs with '/' in their names are supported.
Items still on my todo list:
- Process the server's lock refresh timeout response (currently it
assumes that the original lock timeout will continue to work.)
- Verify remote commit object if branches are the same (currently
it does no verification if the refs point to the same object.)
- Clean up temp filenames after failed PUTs (no need to leave them
there since you can't resume.)
- Either send compressed objects directly rather than uncompressing and
recompressing them before sending; or since we have an uncompressed
copy, also verify the SHA1 before sending since the remote doesn't
verify (and/or consider read after write verification.)
- Use a pack to send under what circumstances? Perhaps allow
min-pack-size and max-pack-size (more objects == less impact on failed
transfer, more transfer overhead.)
- Attempt recovery if the remote ref PUT fails?
- Test against other DAV servers (I've currently tested it using only
Apache.)
--
For a successful technology, reality must take precedence over public
relations, for nature cannot be fooled.
^ permalink raw reply
* Re: [PATCH] v2: proxy-command support for git://
From: Linus Torvalds @ 2005-11-04 22:15 UTC (permalink / raw)
To: Paul Collins; +Cc: Junio C Hamano, git
In-Reply-To: <87hdas9ijp.fsf@briny.internal.ondioline.org>
On Fri, 4 Nov 2005, Paul Collins wrote:
>
> * If the git config syntax is extended to allow dots in section or
> key names:
>
> [proxy]
> git.kernel.org = "ssh-to-bastion-proxy-command"
> git.blargco.com = "blargco-proxy-command"
I would suggest
[proxy]
command = "ssh-to-bastion-proxy-command" for git.kernel.org
and then it's easy enough to just parse the value "proxy.command" with
code like
host = value;
cmd = strstr(value, " for ");
if (!cmd)
return -1;
*cmd = 0;
cmd += 5;
which would do the right thing..
The thing is, it's not just ".". I could well imagine that you'd have
[proxy]
command="ssh" for "ssh://kernel.org/"
command="proxy-command" for kernel.org
command="myprotocol-command" for "my://"
which would actually allow you to literally add your own protocol names
(it would see that the target starts with "my://", and decide that it
shoul drun the "myprotocol-command" for the proxy).
I'd rather allow free-form strings for the values than for the key names.
If we allow free-form key-names, then random text files suddenly often
become valid (but strange) config files.
Right now the non-free-form key names are the strongest syntax checker of
the whole protocol.
Linus
^ permalink raw reply
* Re: [PATCH] Cogito: Support for implicit remote branches in cloned repositories
From: Linus Torvalds @ 2005-11-04 22:07 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Petr Baudis, Josef Weidendorfer, git
In-Reply-To: <7voe50rskh.fsf@assigned-by-dhcp.cox.net>
On Fri, 4 Nov 2005, Junio C Hamano wrote:
>
> I agree with you violently. I just do not know what is the
> right convention to tell which is private and which is not.
I don't like the dot idea, but it certainly _would_ make sense to have a
local prefix.
We could even make it a _totally_ different namespace:
.git/refs/local/heads
.git/refs/local/tags
which means that even if you call a local head the same thing as a global
one, both can still exist.
Then, make "origin" always be a local head.
That avoids the issue of the remote repo _also_ having an "origin" branch.
Locally, the "local" heads would always take precedence, with this trivial
patch making sure of that..
If you want to access a global tag or head, you can always do so by using
the full path ("refs/tags/tagname" is the global one, but "tags/tagname"
or "tagname" would be the local one if one exists).
Linus
---
diff --git a/sha1_name.c b/sha1_name.c
index be1755a..5daaa11 100644
--- a/sha1_name.c
+++ b/sha1_name.c
@@ -231,6 +231,8 @@ static int get_sha1_basic(const char *st
static const char *prefix[] = {
"",
"refs",
+ "refs/local/tags",
+ "refs/local/heads",
"refs/tags",
"refs/heads",
NULL
^ permalink raw reply related
* Re: [PATCH] v2: proxy-command support for git://
From: Paul Collins @ 2005-11-04 22:04 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v3bmct7i3.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> writes:
> Paul Collins <paul@briny.ondioline.org> writes:
>
>> But perhaps I do not really understand your objection.
>
> No, I think you are getting it right.
>
> I just wanted to avoid using the proxy script for some hosts,
> depending on where you are going. Obviously you can teach the
> proxy script to do passthru for some hosts like you did in your
> message. The only difference is where the configuration is
> specified. I wanted it to be in the git configuration file
> (i.e. using different proxy script or no script, depending on
> the host). Your example has that configuration wired in the
> single script that is always called regardless of the
> destination, and the script itself switches how it proxies,
> depending on where it is going, perhaps using its own
> configuration file or hardcoding.
I had some ideas along those lines, but I didn't like any of them.
* Extend the proxy-command "protocol" with a third argument, an
action. For example if 'query $host $port' returns successfully,
then git should run it with arguments 'connect $host $port',
otherwise use git_tcp_connect().
* Add a Proxy-Command field to the files in .git/remotes, e.g.:
URL: git://git.kernel.org/pub/scm/git/git.git/
Pull: master:origin
Proxy-command: my-git-proxy-command
* If the git config syntax is extended to allow dots in section or
key names:
[proxy]
git.kernel.org = "ssh-to-bastion-proxy-command"
git.blargco.com = "blargco-proxy-command"
or perhaps
[git.kernel.org]
proxycommand = "ssh-to-bastion-proxy-command"
[git.blargco.com]
proxycommand = "blargco-proxy-command"
--
Dag vijandelijk luchtschip de huismeester is dood
^ 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