* Re: Git benchmark - comparison with Bazaar, Darcs, Git and Mercurial
From: Florian Weimer @ 2007-08-01 20:36 UTC (permalink / raw)
To: git
In-Reply-To: <85vebzrufc.fsf@lola.goethe.zz>
* David Kastrup:
> Couldn't git clone http://host/directory/to/repo tell the proxy that
> it should enter off-line mode and stop updating?
Huh? I don't see how this is relevant to the current thread.
Anyway, I don't think the max-stale cache control mechanism is widely
implemented. If you want effective expiry controls, you need to
implement them on the server side.
^ permalink raw reply
* Re: core.gitproxy and non-git protocols
From: Shawn O. Pearce @ 2007-08-02 5:31 UTC (permalink / raw)
To: David Symonds; +Cc: git
In-Reply-To: <ee77f5c20708012221j4d75ff0dl8fbf16cdaf1401bd@mail.gmail.com>
David Symonds <dsymonds@gmail.com> wrote:
> It'd be great if (a) the documentation could be fixed, or (b) the
> proxy-picking code could be at least extended to ssh:// protocols, and
> preferrably extended to defining custom protocols.
Did you try setting GIT_SSH envvar to point to a script that does
what you need? I do this in one particular case...
--
Shawn.
^ permalink raw reply
* Re: [RFC/PATCH 2/2] gitweb: Add an option to show size of blobs in the tree view
From: Junio C Hamano @ 2007-08-02 5:22 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <200708020158.50343.jnareb@gmail.com>
Jakub Narebski <jnareb@gmail.com> writes:
>>> P.S. I have received no comments on
>>> [RFC/PATCH] gitweb: Enable transparent compression for HTTP output
>>> (trade CPU load for lower bandwidth usage).
>>
>> That's probably nobody was interested in it.
>
> Well, it was also posted in the middle of old thread...
There probably is some of that as well.
Personally, this late in the game, I would be more interested in
resolving the File::Find() stuff, which has been a real issue in
the field, than the compressed transfer one.
^ permalink raw reply
* core.gitproxy and non-git protocols
From: David Symonds @ 2007-08-02 5:21 UTC (permalink / raw)
To: git
Hi,
The part of the git-config documentation that covers core. gitproxy is
incorrect: you can't use the core.gitproxy setting to use a proxy
command for ssh://, nor to create your own faux-protocols. In the
git_connect function (connect.c), it only references git_proxy_connect
(and thus the core.gitproxy setting) if (protocol == PROTO_GIT).
I have a situation where I'd like to push to a remote git repository
on a machine that is a little weird to access, so I need two different
types of ssh'ing to reach it depending on my location. That is easily
scriptable, which is how I did it with SVN (ended up with a
svn+voltron:// protocol), but is not currently possible with git.
It'd be great if (a) the documentation could be fixed, or (b) the
proxy-picking code could be at least extended to ssh:// protocols, and
preferrably extended to defining custom protocols.
Thanks,
Dave.
^ permalink raw reply
* Re: Git User's Survey 2007 - web survey site
From: Martin Langhoff @ 2007-08-02 4:51 UTC (permalink / raw)
To: Paolo Ciarrocchi; +Cc: Jakub Narebski, git
In-Reply-To: <4d8e3fd30707311207q7ec48559n3ff091253085cb47@mail.gmail.com>
> When I wrote the first survey Martin Langhoff help me in getting the
> data into the site.
> Maybe he can help us this time too (Martin CC'ed ;-)
Did I? ;-)
I don't remember what I did -- survey.net is supposed to be quite
self-service. Isn't your survey still there? Anyway, let me know what
I can help with.
martin
^ permalink raw reply
* Re: Git benchmark - comparison with Bazaar, Darcs, Git and Mercurial
From: Allan Wind @ 2007-08-02 4:02 UTC (permalink / raw)
To: Theodore Tso
Cc: Junio C Hamano, Linus Torvalds, Jakub Narebski, Git Mailing List
In-Reply-To: <20070801220350.GD28106@thunk.org>
On 2007-08-01T18:03:50-0400, Theodore Tso wrote:
> Yeah, essentially, with a git-config option (and comand-line option)
> to override the default for those people who are "squeamish" about git
> clone -l. Linus's suggestion of using file:// as a way to indicate
> non-local also makes a lot of sense to me.
I would expect /something and file:///something to behave exactly the
same way (the latter just having bit extra syntax sugar).
/Allan
^ permalink raw reply
* Re: Git benchmark - comparison with Bazaar, Darcs, Git and Mercurial
From: Linus Torvalds @ 2007-08-02 4:13 UTC (permalink / raw)
To: Allan Wind; +Cc: Theodore Tso, Junio C Hamano, Jakub Narebski, Git Mailing List
In-Reply-To: <20070802040201.GI23484@lifeintegrity.com>
On Thu, 2 Aug 2007, Allan Wind wrote:
>
> I would expect /something and file:///something to behave exactly the
> same way (the latter just having bit extra syntax sugar).
I do agree that they should be basically the same, but from an
implementation standpoint it actually makes a lot of sense to separate
them. Also, there's actually a small amount of "logic" in it: the
/something is obviously a "raw filename", while the "file:://something"
clearly is something a lot more abstract.
I don't actually have a very strong opinion, but I do think that "file://"
makes sense regardless (ie the patch I sent out is probably a good idea).
I also strongly dispute that "file://something" is _identical_ to just
"something". There's a huge difference, as anybody who has ever tried to
do
cp file://file-A file-B
will have hopefully found out. They may mean the same thing, but they have
totally different levels of abstraction, so it does actually make some
sense that you end up *cloning* the same thing, but different ways.
Linus
^ permalink raw reply
* Re: [PATCH] git-commit.sh: Permit the --amend message to be given with -m/-c/-C/-F.
From: Junio C Hamano @ 2007-08-02 1:03 UTC (permalink / raw)
To: David Kastrup; +Cc: git
In-Reply-To: <85zm1bq8um.fsf@lola.goethe.zz>
David Kastrup <dak@gnu.org> writes:
> Signed-off-by: David Kastrup <dak@gnu.org>
> ---
> git-commit.sh | 5 ++---
> 1 files changed, 2 insertions(+), 3 deletions(-)
>
> diff --git a/git-commit.sh b/git-commit.sh
> index 4290ae2..d7e7028 100755
> --- a/git-commit.sh
> +++ b/git-commit.sh
> @@ -190,7 +190,6 @@ $1"
> ;;
> --a|--am|--ame|--amen|--amend)
> amend=t
> - log_given=t$log_given
> use_commit=HEAD
> shift
> ;;
> @@ -298,9 +297,9 @@ esac
>
> case "$log_given" in
> tt*)
> - die "Only one of -c/-C/-F/--amend can be used." ;;
> + die "Only one of -c/-C/-F can be used." ;;
> *tm*|*mt*)
> - die "Option -m cannot be combined with -c/-C/-F/--amend." ;;
> + die "Option -m cannot be combined with -c/-C/-F." ;;
> esac
>
> case "$#,$also,$only,$amend" in
Ok, looks obviously correct. Wasn't too painful, was it?
Thanks, will apply.
^ permalink raw reply
* Re: [PATCH] git-sh-setup.sh: make GIT_EDITOR/core.editor/VISUAL/EDITOR accept commands
From: Junio C Hamano @ 2007-08-02 1:00 UTC (permalink / raw)
To: David Kastrup; +Cc: git
In-Reply-To: <85sl72x0x5.fsf@lola.goethe.zz>
David Kastrup <dak@gnu.org> writes:
> Junio C Hamano <gitster@pobox.com> writes:
>
>> Junio C Hamano <gitster@pobox.com> writes:
>>
>>> It is not just "won't apply". What if GIT_DIR had spaces (which
>>> is fine) and single-quotes in it? Wouldn't it percolate down to
>>> $@ because it becomes the leading directory of the temporary
>>> file name? And you quote '"$@"' and eval it, now what happens?
>>
>> Ah, I spoke too fast. It is fine --- the shell that actually is
>> doing the eval then interpolates "$@". Clever.
>
> Since eval folds all its arguments into a single string separated by
> single blanks, actual blanks (which can be multiple or interspersed
> with newlines) must not yet be seen. The string '"$@"' contains no
> blanks and thus gets through unmolested.
Yup. I just misread the code.
Thanks, applied.
^ permalink raw reply
* Re: [PATCH] When generating manpages, delete outdated targets first.
From: Junio C Hamano @ 2007-08-02 0:53 UTC (permalink / raw)
To: David Kastrup; +Cc: git
In-Reply-To: <S1753674AbXHBABb/20070802000131Z+363@vger.kernel.org>
David Kastrup <dak@gnu.org> writes:
> This makes "make doc" work even if you made "sudo make doc" previously
> by mistake. Apparently an oversight: the other targets did this already.
>
> Signed-off-by: David Kastrup <dak@gnu.org>
> ---
> Documentation/Makefile | 1 +
> 1 files changed, 1 insertions(+), 0 deletions(-)
>
> diff --git a/Documentation/Makefile b/Documentation/Makefile
> index 3bc5357..a186843 100644
> --- a/Documentation/Makefile
> +++ b/Documentation/Makefile
> @@ -120,6 +120,7 @@ clean:
> mv $@+ $@
>
> %.1 %.5 %.7 : %.xml
> + $(RM) $@+ $@
> xmlto -m callouts.xsl man $<
>
> %.xml : %.txt
I think "rm" makes sense; the call to xmlto in this Makefile has
been this way from day one, it seems ;-).
The build rule for this target does not use "generate to
temporary $@+ and after that is successful mv to the final $@"
pattern, so we do not have to remove $@+ in this target, though.
Thanks.
^ permalink raw reply
* Re: [RFC/PATCH 2/2] gitweb: Add an option to show size of blobs in the tree view
From: Junio C Hamano @ 2007-08-02 0:47 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <200708020158.50343.jnareb@gmail.com>
Jakub Narebski <jnareb@gmail.com> writes:
> So you think that ";opt=-l" would be required to have 'tree' view with
> blob (file) sizes, and it would be allowed only if
> gitweb_check_feature('ls-tree-size') is true (or something like that).
> Should we return "Permission denied" or simply ignore "-l" extra option
> if it is prohivited by the config?
I would say we should make config show-tree-entry-size (or
whatever name) unconditionally give the object size of the tree
entry, and drop ";opt=-l in URL" support from the code. In
other words, if the site/repo owner wants to show it, it is
shown to everybody, otherwise nothing is shown.
Keeping the URL clean and without needless variations would help
caching; I do not see major advantage of this feature one way or
the other, so if we can keep a tree view of the same object from
the same repository the same by removing one user preference,
that would be better.
^ permalink raw reply
* Re: multiple checked out branches
From: Domenico Andreoli @ 2007-08-02 0:02 UTC (permalink / raw)
To: git
In-Reply-To: <Pine.LNX.4.64.0708012309010.28202@beast.quantumfyre.co.uk>
On Wed, Aug 01, 2007 at 11:19:25PM +0100, Julian Phillips wrote:
>
> The biggest issue with doing this is that you have no protection against
> making changes on the same branch in more than one place - something you
> really don't want to be dealing with. Basically you need to be careful
> about updating refs that you have checkedout in workdirs.
Yes, I figured out this would have been a problem after thinking at it
a bit more. I surely do not want to be careful about acting on the same
branch in two working repositories at the same place.
The actual problem is that switching form a branch to another makes
my autotools fuck and I have to rebuild stuff all the time. My box is
still a faint-hearted single core...
cheers,
Domenico
-----[ Domenico Andreoli, aka cavok
--[ http://www.dandreoli.com/gpgkey.asc
---[ 3A0F 2F80 F79C 678A 8936 4FEE 0677 9033 A20E BC50
^ permalink raw reply
* [PATCH] When generating manpages, delete outdated targets first.
From: David Kastrup @ 2007-08-01 23:48 UTC (permalink / raw)
To: git
This makes "make doc" work even if you made "sudo make doc" previously
by mistake. Apparently an oversight: the other targets did this already.
Signed-off-by: David Kastrup <dak@gnu.org>
---
Documentation/Makefile | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/Documentation/Makefile b/Documentation/Makefile
index 3bc5357..a186843 100644
--- a/Documentation/Makefile
+++ b/Documentation/Makefile
@@ -120,6 +120,7 @@ clean:
mv $@+ $@
%.1 %.5 %.7 : %.xml
+ $(RM) $@+ $@
xmlto -m callouts.xsl man $<
%.xml : %.txt
--
1.5.3.rc2.167.gbef44-dirty
^ permalink raw reply related
* Re: [PATCH] git-sh-setup.sh: make GIT_EDITOR/core.editor/VISUAL/EDITOR accept commands
From: David Kastrup @ 2007-08-01 23:58 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vtzri3kpr.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <gitster@pobox.com> writes:
> Junio C Hamano <gitster@pobox.com> writes:
>
>> It is not just "won't apply". What if GIT_DIR had spaces (which
>> is fine) and single-quotes in it? Wouldn't it percolate down to
>> $@ because it becomes the leading directory of the temporary
>> file name? And you quote '"$@"' and eval it, now what happens?
>
> Ah, I spoke too fast. It is fine --- the shell that actually is
> doing the eval then interpolates "$@". Clever.
Since eval folds all its arguments into a single string separated by
single blanks, actual blanks (which can be multiple or interspersed
with newlines) must not yet be seen. The string '"$@"' contains no
blanks and thus gets through unmolested.
--
David Kastrup, Kriemhildstr. 15, 44793 Bochum
^ permalink raw reply
* Re: [RFC/PATCH 2/2] gitweb: Add an option to show size of blobs in the tree view
From: Jakub Narebski @ 2007-08-01 23:58 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v3az24zo6.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
> Jakub Narebski <jnareb@gmail.com> writes:
>
>> But I agree that this should be protected by the %feature mechanism.
>> Two questions:
>>
>> 1. Should we make '-l' default when turned on? Or make 'showsizes'
>> %feature tristate: off, on, by default on?
>>
>> 2. If it is turned off, should we silently (or not so silently)
>> ignore this option, or return "Permission denied" or perhaps
>> "Invalid extra options parameter"?
>>
>> And how we should name this feature (key in %feature hash)?
>
> I would say we would not do this by default, only with an
> explicit override with gitweb-config.perl. I am not sure what
> the good name would be. "expensive-ls-tree" perhaps?
So you think that ";opt=-l" would be required to have 'tree' view with
blob (file) sizes, and it would be allowed only if
gitweb_check_feature('ls-tree-size') is true (or something like that).
Should we return "Permission denied" or simply ignore "-l" extra option
if it is prohivited by the config?
As to good name: 'showsize'? 'ls-tree-size'? 'ls-tree--long'?
>> P.S. I have received no comments on
>> [RFC/PATCH] gitweb: Enable transparent compression for HTTP output
>> (trade CPU load for lower bandwidth usage).
>
> That's probably nobody was interested in it.
Well, it was also posted in the middle of old thread...
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: [PATCH] git-sh-setup.sh: make GIT_EDITOR/core.editor/VISUAL/EDITOR accept commands
From: David Kastrup @ 2007-08-01 23:55 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vy7gu3kuh.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <gitster@pobox.com> writes:
> David Kastrup <dak@gnu.org> writes:
>
>> David Kastrup <dak@gnu.org> writes:
>>
>>> The previous code only allowed specifying a single executable rather
>>> than a complete command like "emacsclient --alternate-editor vi" in
>>
>> Oops, won't apply cleanly. I found that I had already made a
>> different (trivial) patch previously. Let me try again and fold that
>> patch in manually.
>
> It is not just "won't apply". What if GIT_DIR had spaces (which
> is fine) and single-quotes in it? Wouldn't it percolate down to
> $@ because it becomes the leading directory of the temporary
> file name? And you quote '"$@"' and eval it, now what happens?
The eval removes the outer single quotes and then evaluates the
remaining "$@" which leaves the original argument structure completely
intact: What got passed into git_editor as 3 arguments will remain as
3 arguments, and even multiple embedded spaces in one argument will
get preserved perfectly.
If you don't believe me, throw whatever you want at it.
--
David Kastrup, Kriemhildstr. 15, 44793 Bochum
^ permalink raw reply
* Re: Git benchmark - comparison with Bazaar, Darcs, Git and Mercurial
From: Jakub Narebski @ 2007-08-01 23:51 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Linus Torvalds, Git Mailing List
In-Reply-To: <7vzm1b7i8v.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
> Jakub Narebski <jnareb@gmail.com> writes:
>
> > About clone: there was "pack loose, copy existing packs" idea.
>
> Can you give more details --- I do not recall such an "idea"
> discussed.
The idea was to avoid repacking, and just pack loose, unpacked objects
(and save this pack if possible), then concatenate all packs and send
this concatenated pack as the result. This saves a bit (quite a bit) of
CPU at the cost of additional bandwidth usage if packfiles are not
optimized.
The only result of the discussion was that it would be fairly easy to
send multiple packs concatenated into one pack, without need to add
some multi-pack extension, as there would be required minor changes to
split "concatenated" packfiles.
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: [PATCH] git-sh-setup.sh: make GIT_EDITOR/core.editor/VISUAL/EDITOR accept commands
From: Junio C Hamano @ 2007-08-01 23:21 UTC (permalink / raw)
To: David Kastrup; +Cc: git
In-Reply-To: <7vy7gu3kuh.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <gitster@pobox.com> writes:
> It is not just "won't apply". What if GIT_DIR had spaces (which
> is fine) and single-quotes in it? Wouldn't it percolate down to
> $@ because it becomes the leading directory of the temporary
> file name? And you quote '"$@"' and eval it, now what happens?
Ah, I spoke too fast. It is fine --- the shell that actually is
doing the eval then interpolates "$@". Clever.
^ permalink raw reply
* Re: [PATCH] git-sh-setup.sh: make GIT_EDITOR/core.editor/VISUAL/EDITOR accept commands
From: Junio C Hamano @ 2007-08-01 23:18 UTC (permalink / raw)
To: David Kastrup; +Cc: git
In-Reply-To: <85ejimrjb2.fsf@lola.goethe.zz>
David Kastrup <dak@gnu.org> writes:
> David Kastrup <dak@gnu.org> writes:
>
>> The previous code only allowed specifying a single executable rather
>> than a complete command like "emacsclient --alternate-editor vi" in
>
> Oops, won't apply cleanly. I found that I had already made a
> different (trivial) patch previously. Let me try again and fold that
> patch in manually.
It is not just "won't apply". What if GIT_DIR had spaces (which
is fine) and single-quotes in it? Wouldn't it percolate down to
$@ because it becomes the leading directory of the temporary
file name? And you quote '"$@"' and eval it, now what happens?
^ permalink raw reply
* Re: [RFC/PATCH 2/2] gitweb: Add an option to show size of blobs in the tree view
From: Junio C Hamano @ 2007-08-01 23:12 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <200708011505.02078.jnareb@gmail.com>
Jakub Narebski <jnareb@gmail.com> writes:
> But I agree that this should be protected by the %feature mechanism.
> Two questions:
>
> 1. Should we make '-l' default when turned on? Or make 'showsizes'
> %feature tristate: off, on, by default on?
>
> 2. If it is turned off, should we silently (or not so silently)
> ignore this option, or return "Permission denied" or perhaps
> "Invalid extra options parameter"?
>
> And how we should name this feature (key in %feature hash)?
I would say we would not do this by default, only with an
explicit override with gitweb-config.perl. I am not sure what
the good name would be. "expensive-ls-tree" perhaps?
> P.S. I have received no comments on
> [RFC/PATCH] gitweb: Enable transparent compression for HTTP output
> (trade CPU load for lower bandwidth usage).
That's probably nobody was interested in it.
^ permalink raw reply
* [PATCH] git-sh-setup.sh: make GIT_EDITOR/core.editor/VISUAL/EDITOR accept commands
From: David Kastrup @ 2007-08-01 21:47 UTC (permalink / raw)
To: git
In-Reply-To: <85ejimrjb2.fsf@lola.goethe.zz>
The previous code only allowed specifying a single executable rather
than a complete command like "emacsclient --alternate-editor vi" in
those variables. Since VISUAL/EDITOR appear to be traditionally
passed to a shell for interpretation (as corroborated with "less",
"mail" and "mailx", while the really ancient "more" indeed allows only
an executable name), the shell function git_editor has been amended
appropriately.
"eval" is employed to have quotes and similar interpreted _after_
expansion, so that specifying
EDITOR='"/home/dak/My Commands/notepad.exe"'
can be used for actually using commands with blanks.
Instead of passing just the first argument of git_editor on, we pass
all of them (so that +lineno might be employed at a later point of
time, or so that multiple files may be edited when appropriate).
Strictly speaking, there is a change in behavior: when
git config core.editor
returns a valid but empty string, the fallbacks are still searched.
This is more consistent, and the old code was problematic with regard
to multiple blanks. Putting in additional quotes might have worked,
but quotes inside of command substitution inside of quotes is nasty
enough to not reliably work the same across "Bourne shells".
Signed-off-by: David Kastrup <dak@gnu.org>
---
git-sh-setup.sh | 5 +++--
1 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/git-sh-setup.sh b/git-sh-setup.sh
index c51985e..3c50bc1 100755
--- a/git-sh-setup.sh
+++ b/git-sh-setup.sh
@@ -29,7 +29,8 @@ set_reflog_action() {
}
git_editor() {
- GIT_EDITOR=${GIT_EDITOR:-$(git config core.editor || echo ${VISUAL:-${EDITOR}})}
+ : "${GIT_EDITOR:=$(git config core.editor)}"
+ : "${GIT_EDITOR:=${VISUAL:-${EDITOR}}}"
case "$GIT_EDITOR,$TERM" in
,dumb)
echo >&2 "No editor specified in GIT_EDITOR, core.editor, VISUAL,"
@@ -40,7 +41,7 @@ git_editor() {
exit 1
;;
esac
- "${GIT_EDITOR:-vi}" "$1"
+ eval "${GIT_EDITOR:=vi}" '"$@"'
}
is_bare_repository () {
--
1.5.3.rc2.86.gdc7ba
^ permalink raw reply related
* Re: Git benchmark - comparison with Bazaar, Darcs, Git and Mercurial
From: Brandon Casey @ 2007-08-01 22:49 UTC (permalink / raw)
To: Theodore Tso
Cc: Junio C Hamano, Linus Torvalds, Jakub Narebski, Git Mailing List
In-Reply-To: <20070801220350.GD28106@thunk.org>
Theodore Tso wrote:
> On Wed, Aug 01, 2007 at 03:15:25AM -0700, Junio C Hamano wrote:
>> Perhaps if the destination is local,
>>
>> - if -s is given, just set up alternates, do nothing else;
>
> As I understand it, the main objection with making -s the default is
> surprising result that could happen if you do a git-prune in the base
> repository which causes objects which are borrowed from the base
> repository via .git/objects/info/alternates, right?
-s would be a lot safer to use if repack -a -d (as used by git-gc) was smarter.
-a -d has the nasty side effect of doing what it seems only prune is intended
to do... that is to remove unreferenced objects.
-s usage currently has to be very well thought out, unless you're just using it
for a short-lived temporary branch. If this unintended pruning could be avoided
then an average user could go about their merry business repacking and git-gc'ing
without a care, and only when doing a git-gc --prune would they need to do
something special.
-brandon
^ permalink raw reply
* Re: [PATCH] Fix rebase interactive to allow specifying branch to rebase along with the base
From: Alex Riesen @ 2007-08-01 22:40 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git, Junio C Hamano
In-Reply-To: <Pine.LNX.4.64.0708012336170.14781@racer.site>
Johannes Schindelin, Thu, Aug 02, 2007 00:36:58 +0200:
> On Thu, 2 Aug 2007, Alex Riesen wrote:
> > require_clean_work_tree
> > + mkdir "$DOTEST" || die "Could not create temporary $DOTEST"
>
> Heh. I take that as an ACK from you to my patch? Mine has a test case,
> too ;-)
ACK, indeed 8)
^ permalink raw reply
* Re: multiple checked out branches
From: Johannes Schindelin @ 2007-08-01 22:39 UTC (permalink / raw)
To: Alex Riesen; +Cc: Domenico Andreoli, git
In-Reply-To: <20070801223430.GC2911@steel.home>
Hi,
On Thu, 2 Aug 2007, Alex Riesen wrote:
> Domenico Andreoli, Thu, Aug 02, 2007 00:04:35 +0200:
> >
> > I would like to contemporaneously work with multiple branches out of
> > the same git repository. This does not work out of the box.
> >
> > So I prepare multiple copies of the same repository, every one will have
> > its own checked out branch but I want to share most of their .git subdir.
> >
> > I surely want to share the object db, the local and remote refs.
> > This way it is enough to make a round of fetches/merges/pushes to have
> > all the shared-repositories up to date.
> >
> > I expect to do the trick with some symlinks but I am not an expert of
> > git internals. Which traps are waiting me? Any hint? Thank you.
> >
>
> No traps. Supported. See for "git clone -s" and "git clone -l"
That is not completely what is wanted, AFAIU: "git clone -s" and "git
clone -l" allow for unsynchronised branches. For example, when you
committed to branch "foo" in the cloned repo, branch "foo" in the original
repo will be older until you push.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] Fix rebase interactive to allow specifying branch to rebase along with the base
From: Johannes Schindelin @ 2007-08-01 22:36 UTC (permalink / raw)
To: Alex Riesen; +Cc: git, Junio C Hamano
In-Reply-To: <20070801223241.GB2911@steel.home>
Hi,
On Thu, 2 Aug 2007, Alex Riesen wrote:
> diff --git a/git-rebase--interactive.sh b/git-rebase--interactive.sh
> index 061cd0a..b42dee8 100755
> --- a/git-rebase--interactive.sh
> +++ b/git-rebase--interactive.sh
> @@ -404,6 +404,7 @@ do
> esac
>
> require_clean_work_tree
> + mkdir "$DOTEST" || die "Could not create temporary $DOTEST"
>
> if test ! -z "$2"
> then
> @@ -418,7 +419,6 @@ do
>
> test -z "$ONTO" && ONTO=$UPSTREAM
>
> - mkdir "$DOTEST" || die "Could not create temporary $DOTEST"
> : > "$DOTEST"/interactive || die "Could not mark as interactive"
> git symbolic-ref HEAD > "$DOTEST"/head-name ||
> die "Could not get HEAD"
Heh. I take that as an ACK from you to my patch? Mine has a test case,
too ;-)
Ciao,
Dscho
^ 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