* Re: [RFD] what should "git push remote.host:path" do?
From: Nick Hengeveld @ 2006-01-12 16:31 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vslrtq05h.fsf@assigned-by-dhcp.cox.net>
On Thu, Jan 12, 2006 at 01:13:30AM -0800, Junio C Hamano wrote:
> BTW, Nick, what does http-push do with "git push http://foo"
> without refspecs?
It won't push anything unless refspecs are specified. If there are
none, it will still verify remote DAV locking is available and then
exit quietly.
--
For a successful technology, reality must take precedence over public
relations, for nature cannot be fooled.
^ permalink raw reply
* Re: git pull on Linux/ACPI release tree
From: Catalin Marinas @ 2006-01-12 16:10 UTC (permalink / raw)
To: Greg KH
Cc: Adrian Bunk, Linus Torvalds, Brown, Len, David S. Miller,
linux-acpi-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, akpm-3NddpPZAyC0,
git-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20060112013706.GA3339-U8xfFu+wG4EAvxtiuMwx3w@public.gmane.org>
Greg KH <greg-U8xfFu+wG4EAvxtiuMwx3w@public.gmane.org> wrote:
> On Tue, Jan 10, 2006 at 09:19:09PM +0100, Adrian Bunk wrote:
>>
>> I am using the workaround of carrying the patches in a mail folder,
>> applying them in a batch, and not pulling from your tree between
>> applying a batch of patches and you pulling from my tree.
>
> Ick, I'd strongly recommend using quilt for this. It works great for
> just this kind of workflow.
Or StGIT :-). Similar workflow (and similar commands) but better
integrated with GIT and better at dealing with conflicts since it uses
a three-way merge when pushing patches rather than applying them with
"patch".
--
Catalin
-
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: git pull on Linux/ACPI release tree
From: Greg KH @ 2006-01-12 1:37 UTC (permalink / raw)
To: Adrian Bunk
Cc: Linus Torvalds, Brown, Len, David S. Miller, linux-acpi,
linux-kernel, akpm, git
In-Reply-To: <20060110201909.GB3911@stusta.de>
On Tue, Jan 10, 2006 at 09:19:09PM +0100, Adrian Bunk wrote:
>
> I am using the workaround of carrying the patches in a mail folder,
> applying them in a batch, and not pulling from your tree between
> applying a batch of patches and you pulling from my tree.
Ick, I'd strongly recommend using quilt for this. It works great for
just this kind of workflow.
thanks,
greg k-h
^ permalink raw reply
* Re: Linus repository at git.kernel.org???
From: Linus Torvalds @ 2006-01-12 15:58 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Coywolf Qi Hunt, git
In-Reply-To: <7vr77dud41.fsf@assigned-by-dhcp.cox.net>
On Wed, 11 Jan 2006, Junio C Hamano wrote:
> Coywolf Qi Hunt <coywolf@gmail.com> writes:
>
> > gemini:~/linux/linux-2.6> git-pull
> > fatal: unexpected EOF
> > Fetch failure: git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
>
> The failure does not seem to happen on all repositories, but
> just is with Linus repository, so I doubt "git update" on either
> your end or kernel.org public machines have anything to do with
> this. And Linus repository from gitweb is also missing.
The mirroring was delayed for a while, but seems to be ok now.
I repacked my archive (exactly because mirroring was so slow) and while
the result was always a valid archive on the master site, if you pulled
when mirroring was starting to delete the unpacked objects but had not yet
mirrored the new pack, you'd get something like the above - git-daemon
would exit because of a "missing" object).
I think it should be ok now (at least it seems to have mirrored out things
over-night, and gitweb now matches my local head again).
Linus
^ permalink raw reply
* Re: git-commit: allow From: line to be entered in commit message
From: sean @ 2006-01-12 15:21 UTC (permalink / raw)
To: git
In-Reply-To: <BAYC1-PASMTP117A18814EAAFACFE0F31DAE270@CEZ.ICE>
On Thu, 12 Jan 2006 09:37:00 -0500
sean <seanlkml@sympatico.ca> wrote:
> Mostly just for comment to see if there is any support
> for this feature....
Sorry. Slightly better version of the patch below:
---
Use the author name and email information given as the
first line of the commit message in the form of:
From: name <email>
as the author's name and email address in the resulting
commit object. This makes committing foreign patches
a little less cumbersome to handle for some workflows.
diff --git a/git-commit.sh b/git-commit.sh
index 193feeb..163e2d7 100755
--- a/git-commit.sh
+++ b/git-commit.sh
@@ -219,14 +219,19 @@ t)
fi
esac
-grep -v '^#' < "$GIT_DIR"/COMMIT_EDITMSG |
-git-stripspace > "$GIT_DIR"/COMMIT_MSG
+grep -v '^#' < "$GIT_DIR"/COMMIT_EDITMSG | git-stripspace |
+sed -e '1s/^[ \t]*from:.*//I' | git-stripspace > "$GIT_DIR"/COMMIT_MSG
if cnt=`grep -v -i '^Signed-off-by' "$GIT_DIR"/COMMIT_MSG |
git-stripspace |
wc -l` &&
test 0 -lt $cnt
then
+ FROM=$(sed -ne '/^#/d;/^[ \t]*$/d;s/from:[ \t]*\(.*\)/\1/Ip;q' "$GIT_DIR"/COMMIT_EDITMSG)
+ if test -n "$FROM"; then
+ export GIT_AUTHOR_NAME=$(echo "$FROM" | sed -e 's/[ \t]*<.*//')
+ export GIT_AUTHOR_EMAIL=$(echo "$FROM" | sed -e 's/.*<\(.*\)>.*/\1/')
+ fi
tree=$(git-write-tree) &&
commit=$(cat "$GIT_DIR"/COMMIT_MSG | git-commit-tree $tree $PARENTS) &&
git-update-ref HEAD $commit $current &&
^ permalink raw reply related
* Re: [PATCH] stgit: fix clone
From: Chuck Lever @ 2006-01-12 14:51 UTC (permalink / raw)
To: Catalin Marinas; +Cc: Pavel Roskin, git
In-Reply-To: <b0943d9e0601120354u73489c74j@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1134 bytes --]
Catalin Marinas wrote:
> On 11/01/06, Chuck Lever <cel@citi.umich.edu> wrote:
>
>>Chuck Lever wrote:
>>
>>>seems to me the "git clone" script should create an environment where
>>>"git-rev-parse --git-dir" ought to work correctly.
>>
>>stgit/main.py does a special stack.Series('master') just for the clone
>>command. it really shouldn't do this -- the crt_series.init() in the
>>clone command ought to be fixed to do this properly.
>
>
> If the stack.Series() doesn't get a parameter, it will try to get the
> default branch using 'git-symbolic-ref HEAD'. Any command run outside
> a tree (and which doesn't have the -h option) would fail. The clone
> command is the only one allowed to run outside a tree and that's why I
> passed a default branch name. This is to avoid the creation of another
> stack.Series() object later when the git tree was cloned.
>
> See the attached patch for a different fix and let me know if there
> are any issues with it. I should probably release 0.8.1 with the fixed
> bugs.
looked at the patch. that's what i had in mind. the extra exception
processing in Series.__init__ is a nice touch.
[-- Attachment #2: cel.vcf --]
[-- Type: text/x-vcard, Size: 451 bytes --]
begin:vcard
fn:Chuck Lever
n:Lever;Charles
org:Network Appliance, Incorporated;Open Source NFS Client Development
adr:535 West William Street, Suite 3100;;Center for Information Technology Integration;Ann Arbor;MI;48103-4943;USA
email;internet:cel@citi.umich.edu
title:Member of Technical Staff
tel;work:+1 734 763-4415
tel;fax:+1 734 763 4434
tel;home:+1 734 668-1089
x-mozilla-html:FALSE
url:http://troy.citi.umich.edu/u/cel/
version:2.1
end:vcard
^ permalink raw reply
* git-commit: allow From: line to be entered in commit message
From: sean @ 2006-01-12 14:37 UTC (permalink / raw)
To: git
Mostly just for comment to see if there is any support
for this feature....
Sean
---
Use the author name and email information given as the
first line of the commit message in the form of:
From: name <email>
as the author's name and email address in the resulting
commit object. This makes committing foreign patches
a little less cumbersome to handle for some workflows.
diff --git a/git-commit.sh b/git-commit.sh
index 193feeb..6004cd4 100755
--- a/git-commit.sh
+++ b/git-commit.sh
@@ -219,7 +219,7 @@ t)
fi
esac
-grep -v '^#' < "$GIT_DIR"/COMMIT_EDITMSG |
+grep -v '^#' < "$GIT_DIR"/COMMIT_EDITMSG | sed -e '1s/^[ \t]*from:.*//I' |
git-stripspace > "$GIT_DIR"/COMMIT_MSG
if cnt=`grep -v -i '^Signed-off-by' "$GIT_DIR"/COMMIT_MSG |
@@ -227,6 +227,13 @@ if cnt=`grep -v -i '^Signed-off-by' "$GI
wc -l` &&
test 0 -lt $cnt
then
+ FROM=$(grep -v '^#' < "$GIT_DIR"/COMMIT_EDITMSG | sed -ne '1s/from:[ \t]*\(.*\)/\1/Ip;q')
+ NAME=$(echo "$FROM" | sed -e 's/<.*//;s/[ \t]*$//')
+ EMAIL=$(echo "$FROM" | sed -e 's/.*<\(.*\)>.*/\1/')
+ if test -n "$FROM"; then
+ export GIT_AUTHOR_NAME="$NAME"
+ export GIT_AUTHOR_EMAIL="$EMAIL"
+ fi
tree=$(git-write-tree) &&
commit=$(cat "$GIT_DIR"/COMMIT_MSG | git-commit-tree $tree $PARENTS) &&
git-update-ref HEAD $commit $current &&
^ permalink raw reply related
* Re: git binary size...
From: Andreas Ericsson @ 2006-01-12 13:49 UTC (permalink / raw)
To: Git Mailing List
In-Reply-To: <2cd57c900601120215pdb5da27l@mail.gmail.com>
Coywolf Qi Hunt wrote:
> 2006/1/12, Linus Torvalds <torvalds@osdl.org>:
>
>>
>>On Wed, 11 Jan 2006, Andreas Ericsson wrote:
>>
>>>strip:
>>> strip $(PROGRAMS)
>>>
>>>install: strip
>>
>>Well, that ends up shaving some more from the binaries, but at a much
>>bigger cost than just removing "-g".
>>
>>With stripped binaries, you can't really do _anything_. You get a
>>core-file, and you're screwed.
>
>
> Are you sure?
>
> gemini:~> file `which mke2fs`
> /sbin/mke2fs: ELF 32-bit LSB executable, Intel 80386, version 1
> (SYSV), for GNU/Linux 2.2.0, dynamically linked (uses shared libs),
> stripped
>
> gemini:~> file /lib/libext2fs.so.2.4
> /lib/libext2fs.so.2.4: ELF 32-bit LSB shared object, Intel 80386,
> version 1 (SYSV), stripped
>
> (gdb) bt
> #0 0xb7f16445 in ext2fs_mark_generic_bitmap () from /lib/libext2fs.so.2
> #1 0xb7f110ed in ext2fs_reserve_super_and_bgd () from /lib/libext2fs.so.2
> #2 0xb7f18353 in ext2fs_initialize () from /lib/libext2fs.so.2
> #3 0x0804b461 in ?? ()
> #4 0xbf84b9ad in ?? ()
> #5 0x00000000 in ?? ()
>
> So with stripped binary, I still get the backtrace to locate the buggy
> function. IMO, Debian packages are build with -g.
>
No, you don't. The last three stack-frames resolve to no symbol.
Libraries always contain symbol names. You wouldn't be able to use them
if they didn't, because the dynamic linker uses those symbols to look up
the address of the function to call.
>
> To make git not tight to Linux, but cross platform, consider autoconf.
>
git is already fairly portable without the autoconf hackery. It's easy
enough to move some of the conditional stuff out of the Makefile without
autoconf, but it would still require GNU Make, so there's no real point
in doing so.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: RFC: Subprojects
From: Daniel Barkalow @ 2006-01-12 13:38 UTC (permalink / raw)
To: Martin Langhoff; +Cc: Alexander Litvinov, Simon Richter, git
In-Reply-To: <46a038f90601112046u13d7075dsc2108111e2462152@mail.gmail.com>
On Thu, 12 Jan 2006, Martin Langhoff wrote:
> What about using nested checkouts? They work great with git as-is,
> just add an .gitignore file.
>
> As Linus points out, there are many good reasons why a top-level
> commit should _not_ commit the nested subproject. And once you are
> observing that rule, what's left then? git status and git diff <HEAD>
> can show an aggregate of top-level and nested subprojects, but that's
> ease-of-use -- not something only.
>
> What is your show stopper?
The core structural thing (which I'm not sure CVS handles) is having each
commit of the outer project specify the commit of the inner project that
it contains in some way. This would be good with CVS, but is vital with
git, because there's no way of estimating it when you don't have a linear
history. (With CVS, you could say that the inner project version for a
given outer project version should be the version that was current when
the outer project was committed. But that isn't well-defined for git.) If
you try to debug anything involving the history, you'd have problems with
choosing versions of the two projects that don't actually match.
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* Re: git binary size...
From: Coywolf Qi Hunt @ 2006-01-12 10:15 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Andreas Ericsson, Junio C Hamano, Git Mailing List
In-Reply-To: <Pine.LNX.4.64.0601111134560.5073@g5.osdl.org>
2006/1/12, Linus Torvalds <torvalds@osdl.org>:
>
>
> On Wed, 11 Jan 2006, Andreas Ericsson wrote:
> >
> > strip:
> > strip $(PROGRAMS)
> >
> > install: strip
>
> Well, that ends up shaving some more from the binaries, but at a much
> bigger cost than just removing "-g".
>
> With stripped binaries, you can't really do _anything_. You get a
> core-file, and you're screwed.
Are you sure?
gemini:~> file `which mke2fs`
/sbin/mke2fs: ELF 32-bit LSB executable, Intel 80386, version 1
(SYSV), for GNU/Linux 2.2.0, dynamically linked (uses shared libs),
stripped
gemini:~> file /lib/libext2fs.so.2
/lib/libext2fs.so.2: symbolic link to `libext2fs.so.2.4'
gemini:~> file /lib/libext2fs.so.2.4
/lib/libext2fs.so.2.4: ELF 32-bit LSB shared object, Intel 80386,
version 1 (SYSV), stripped
In gdb:
No symbol table is loaded. Use the "file" command.
(gdb) bt
#0 0xb7f16445 in ext2fs_mark_generic_bitmap () from /lib/libext2fs.so.2
#1 0xb7f110ed in ext2fs_reserve_super_and_bgd () from /lib/libext2fs.so.2
#2 0xb7f18353 in ext2fs_initialize () from /lib/libext2fs.so.2
#3 0x0804b461 in ?? ()
#4 0xbf84b9ad in ?? ()
#5 0x00000000 in ?? ()
So with stripped binary, I still get the backtrace to locate the buggy
function. IMO, Debian packages are build with -g.
So I suggest to let git go with `-g and striped' like all other packages do.
And if we use gnu autoconf, which provides site config ability, we
could easily get (1) "-g, striped" for distros, (2) "not striped" for
Linus and (3) "-g3, -O0, no striped" for some git developers.
To make git not tight to Linux, but cross platform, consider autoconf.
>
> With non-stripped binaries you can at least see the function the SIGSEGV
> happened in, and you usually even get a half-way decent backtrace etc.
>
False, see above.
> Linus
If I missed something in Debian, correct me.
--
Coywolf Qi Hunt
^ permalink raw reply
* Re: [PATCH] stgit: fix clone
From: Catalin Marinas @ 2006-01-12 11:54 UTC (permalink / raw)
To: cel; +Cc: Pavel Roskin, git
In-Reply-To: <43C58AF3.10606@citi.umich.edu>
[-- Attachment #1: Type: text/plain, Size: 994 bytes --]
On 11/01/06, Chuck Lever <cel@citi.umich.edu> wrote:
> Chuck Lever wrote:
> > seems to me the "git clone" script should create an environment where
> > "git-rev-parse --git-dir" ought to work correctly.
>
> stgit/main.py does a special stack.Series('master') just for the clone
> command. it really shouldn't do this -- the crt_series.init() in the
> clone command ought to be fixed to do this properly.
If the stack.Series() doesn't get a parameter, it will try to get the
default branch using 'git-symbolic-ref HEAD'. Any command run outside
a tree (and which doesn't have the -h option) would fail. The clone
command is the only one allowed to run outside a tree and that's why I
passed a default branch name. This is to avoid the creation of another
stack.Series() object later when the git tree was cloned.
See the attached patch for a different fix and let me know if there
are any issues with it. I should probably release 0.8.1 with the fixed
bugs.
--
Catalin
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: clone-fix.diff --]
[-- Type: text/x-patch; name="clone-fix.diff", Size: 4168 bytes --]
Fix the clone command failure
From: Catalin Marinas <catalin.marinas@gmail.com>
The clone command fails because there is no GIT tree available, which is
wrong. The patch fixes the Series.__init__() function and also creates a
new Series object in clone.py once a GIT tree was initialised.
Signed-off-by: Catalin Marinas <catalin.marinas@gmail.com>
---
stgit/commands/clone.py | 2 +-
stgit/main.py | 18 ++++++++----------
stgit/stack.py | 30 ++++++++++++++++--------------
3 files changed, 25 insertions(+), 25 deletions(-)
diff --git a/stgit/commands/clone.py b/stgit/commands/clone.py
index f4e3f6b..9ad76a6 100644
--- a/stgit/commands/clone.py
+++ b/stgit/commands/clone.py
@@ -51,6 +51,6 @@ def func(parser, options, args):
os.chdir(local_dir)
git.checkout(tree_id = 'HEAD')
- crt_series.init()
+ stack.Series().init()
print 'done'
diff --git a/stgit/main.py b/stgit/main.py
index b84d91d..2336a43 100644
--- a/stgit/main.py
+++ b/stgit/main.py
@@ -150,16 +150,14 @@ def main():
option_list = command.options)
options, args = parser.parse_args()
try:
- # 'clone' doesn't expect an already initialised GIT tree
- if cmd == 'clone':
- stgit.commands.common.crt_series = stack.Series('master')
- elif hasattr(options, 'branch') and options.branch:
- stgit.commands.common.crt_series = stack.Series(options.branch)
- else:
- stgit.commands.common.crt_series = stack.Series()
- # the line below is a simple way to avoid an exception when
- # stgit is run outside an initialised tree
- setattr(command, 'crt_series', stgit.commands.common.crt_series)
+ # 'clone' doesn't expect an already initialised GIT tree. A Series
+ # object will be created after the GIT tree is cloned
+ if cmd != 'clone':
+ if hasattr(options, 'branch') and options.branch:
+ command.crt_series = stack.Series(options.branch)
+ else:
+ command.crt_series = stack.Series()
+ stgit.commands.common.crt_series = command.crt_series
command.func(parser, options, args)
except (IOError, CmdException, stack.StackException, git.GitException), \
diff --git a/stgit/stack.py b/stgit/stack.py
index 8b7c296..c2adeb9 100644
--- a/stgit/stack.py
+++ b/stgit/stack.py
@@ -257,21 +257,23 @@ class Series:
def __init__(self, name = None):
"""Takes a series name as the parameter.
"""
- if name:
- self.__name = name
- else:
- self.__name = git.get_head_file()
-
- if self.__name:
+ try:
+ if name:
+ self.__name = name
+ else:
+ self.__name = git.get_head_file()
base_dir = git.get_base_dir()
- self.__patch_dir = os.path.join(base_dir, 'patches',
- self.__name)
- self.__base_file = os.path.join(base_dir, 'refs', 'bases',
- self.__name)
- self.__applied_file = os.path.join(self.__patch_dir, 'applied')
- self.__unapplied_file = os.path.join(self.__patch_dir, 'unapplied')
- self.__current_file = os.path.join(self.__patch_dir, 'current')
- self.__descr_file = os.path.join(self.__patch_dir, 'description')
+ except git.GitException, ex:
+ raise StackException, 'GIT tree not initialised: %s' % ex
+
+ self.__patch_dir = os.path.join(base_dir, 'patches',
+ self.__name)
+ self.__base_file = os.path.join(base_dir, 'refs', 'bases',
+ self.__name)
+ self.__applied_file = os.path.join(self.__patch_dir, 'applied')
+ self.__unapplied_file = os.path.join(self.__patch_dir, 'unapplied')
+ self.__current_file = os.path.join(self.__patch_dir, 'current')
+ self.__descr_file = os.path.join(self.__patch_dir, 'description')
def get_branch(self):
"""Return the branch name for the Series object
^ permalink raw reply related
* Re: reverting back both working copy and commits
From: Bahadir Balban @ 2006-01-12 10:40 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vslrutv2h.fsf@assigned-by-dhcp.cox.net>
On 1/11/06, Junio C Hamano <junkio@cox.net> wrote:
> Eh? That should not happen.
>
> Could you elaborate?
> What "git reset --hard" would leave behind are files in the
> working tree that you had when you made the wrongly done commit,
> which were *not* known to git (i.e. you forgot to "git add"
> before committing). Since they are not known to git, "reset --hard"
> does not touch them.
Sorry, it's my mistake, I later realised the working tree had been
updated correctly.
Thanks,
Bahadir
^ permalink raw reply
* Re: [RFD] what should "git push remote.host:path" do?
From: Sean @ 2006-01-12 10:18 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Nick Hengeveld
In-Reply-To: <7vslrtq05h.fsf@assigned-by-dhcp.cox.net>
On Thu, January 12, 2006 4:13 am, Junio C Hamano said:
> The underlying "git send-pack remote.host:path" pushes all the
> matching refs that both local and remote has, and "git push"
> blindly inherits this property.
[snip]
> Unlike pull that can happen pretty much promiscuously, people
> will push into the same set of a limited number of remote
> repositories repeatedly over the life of the project, so it is
> reasonable to assume they would want to keep a $GIT_DIR/remotes/
> entry for those repositories to save typing. Then always
> requiring one or more refspecs for push is not too much to ask
> for.
>
> Opinions?
What about assuming a refspec of "current-branch:current-branch" ?
That is, if the branch name that is currently checked out locally
also exists upstream, push into it (only if fast forward).
This should allow multiple branches to be updated locally, and pushed
upstream selectively. If you force all push-refspecs to be listed
in a remotes file, they'll all be updated every time you push and
you'd lose the ability to push just one branch upstream without
resorting to multiple $GIT_DIR/remotes/ entries.
Sean
^ permalink raw reply
* Re: killing a branch
From: linux @ 2006-01-12 9:57 UTC (permalink / raw)
To: git
Note that "git prune" could be sped up ENORMOUSLY if git-fsck-cache
could be taught to (optionally) not open, uncompress, hash, and
verify any blob objects. Just assume that they're okay.
I had a look at the code briefly, but it was a little bit hairier (a
more invasive change) than I felt like dealing with.
^ permalink raw reply
* [RFD] what should "git push remote.host:path" do?
From: Junio C Hamano @ 2006-01-12 9:13 UTC (permalink / raw)
To: git; +Cc: Nick Hengeveld
The underlying "git send-pack remote.host:path" pushes all the
matching refs that both local and remote has, and "git push"
blindly inherits this property.
This is bad. A typical cloned repository (e.g. a subsystem
maintainer repository cloned from Linus repository) has at least
two branches, "master" to keep the subsystem and "origin" that
records tip of Linus "master" when the repository was cloned.
If this is the public repository, then subsystem developers
would clone from this one, and then cloned ones have "master"
and "origin". When developers use this public subsystem
repository as a shared repository, "git push subsys:path" would
try to push the matching refs, "master" and "origin".
One workaround is to delete "origin" branch from the public
repository, because having "origin" there is meaningless.
Nobody is supposed to pull directly into it from Linus after
cloning; rather, changes in upstream would trickle in by a
developer who cloned from this subsystem repository and then
pulled from Linus into his repository and then pushed his merge
result into this public repository.
Nevertheless, exposing the default behaviour of "git send-pack"
to "git push" was probably a mistake. I'd propose to require at
least one refspec to be specified, either on the command line or
via $GIT_DIR/remotes mechanism. So my answer to the "Subject: "
line question is "Barf".
Unlike pull that can happen pretty much promiscuously, people
will push into the same set of a limited number of remote
repositories repeatedly over the life of the project, so it is
reasonable to assume they would want to keep a $GIT_DIR/remotes/
entry for those repositories to save typing. Then always
requiring one or more refspecs for push is not too much to ask
for.
Opinions?
BTW, Nick, what does http-push do with "git push http://foo"
without refspecs?
^ permalink raw reply
* Re: RFC: Subprojects
From: Alex Riesen @ 2006-01-12 8:58 UTC (permalink / raw)
To: Alexander Litvinov; +Cc: Martin Langhoff, Simon Richter, git
In-Reply-To: <200601121436.52827.lan@ac-sw.com>
On 1/12/06, Alexander Litvinov <lan@ac-sw.com> wrote:
> > > 1. I need to have ability to make tags, branches thru all subprojects.
> >
> > I suspect that this is a bad idea -- for the same reason as committing
> > to a subproject is a bad idea. The subprojects most likely have their
> > own external repositories -- and lifecycles of their own. The same
> > headname/branchname won't do.
>
> This is one main idea of supporing subprojects. Everything else I already can
> do. I want to be able to make tag over composite project and be able to fetch
> tagged files later. The same with branches.
>
> I cleary understand if I made tag/branch on subproject outside my composite
> project I will not be able to work with it - this is ok.
>
> But tag/branches on whole composite project is "the must".
The Linus' proposal of gitlink will probably help you here: gitlink will be
tagged as well, so you just have to teach git-checkout about checking
out subprojects.
^ permalink raw reply
* [PATCH] Show non-naked git repositories in subdirectories as well.
From: Junio C Hamano @ 2006-01-12 8:55 UTC (permalink / raw)
To: Kay Sievers; +Cc: git
This allows $projects_list to name a directory under which a
non-naked git project trees can hang.
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
* The development of this patch was done using the experimental
"git checkout" I posted in thread:
http://thread.gmane.org/gmane.comp.version-control.git/14375
With the same workflow as I described there, I added this
feature by working in the test branch, and then did this:
$ git checkout -b projects master
which automerged the changes in the test branch over to a new
branch, based on Kay's upstream (thereby removing the effect
of my other changes I had in the test branch). All I had to
do after that was to make a commit, and I am reasonably happy
to see the checkout change is working nicely.
gitweb.cgi | 20 +++++++++++---------
1 files changed, 11 insertions(+), 9 deletions(-)
c302bfde91563778155084d13453b1c2bdc771d8
diff --git a/gitweb.cgi b/gitweb.cgi
index 986d7da..ed52ed0 100755
--- a/gitweb.cgi
+++ b/gitweb.cgi
@@ -14,6 +14,7 @@ use CGI::Util qw(unescape);
use CGI::Carp qw(fatalsToBrowser);
use Encode;
use Fcntl ':mode';
+use File::Find qw(find);
binmode STDOUT, ':utf8';
my $cgi = new CGI;
@@ -794,17 +795,18 @@ sub git_read_projects {
if (-d $projects_list) {
# search in directory
- my $dir = $projects_list;
- opendir my $dh, $dir or return undef;
- while (my $dir = readdir($dh)) {
- if (-e "$projectroot/$dir/HEAD") {
- my $pr = {
- path => $dir,
+ my $pl = quotemeta($projects_list);
+ find(sub {
+ if (/\.git$/ && -d _ &&
+ (-l "$File::Find::name/HEAD" || -f _) &&
+ $File::Find::name =~ /^$pl\/(.*)/) {
+ push @list, {
+ path => "$1"
};
- push @list, $pr
+ $File::Find::prune = 1;
}
- }
- closedir($dh);
+ }, $projects_list);
+
} elsif (-f $projects_list) {
# read from file(url-encoded):
# 'git%2Fgit.git Linus+Torvalds'
--
1.1.1-g8a769
^ permalink raw reply related
* Re: RFC: Subprojects
From: Alexander Litvinov @ 2006-01-12 8:36 UTC (permalink / raw)
To: Martin Langhoff; +Cc: Simon Richter, git
In-Reply-To: <46a038f90601112139l2f2bde5bx15102a1afcf4ec25@mail.gmail.com>
> > 1. I need to have ability to make tags, branches thru all subprojects.
>
> I suspect that this is a bad idea -- for the same reason as committing
> to a subproject is a bad idea. The subprojects most likely have their
> own external repositories -- and lifecycles of their own. The same
> headname/branchname won't do.
This is one main idea of supporing subprojects. Everything else I already can
do. I want to be able to make tag over composite project and be able to fetch
tagged files later. The same with branches.
I cleary understand if I made tag/branch on subproject outside my composite
project I will not be able to work with it - this is ok.
But tag/branches on whole composite project is "the must".
I hope it is possible to teach git (or may be something else) to scan all
subprojects and fetch common tags/branches and work with them.
^ permalink raw reply
* [PATCH] checkout: automerge local changes while switching branches.
From: Junio C Hamano @ 2006-01-12 7:33 UTC (permalink / raw)
To: Alex Riesen
Cc: Brown, Len, Luck, Tony, Martin Langhoff, David S. Miller,
Linus Torvalds, git
In-Reply-To: <81b0412b0601100731p46ec276btfe04382a9e53bd5c@mail.gmail.com>
When switching branches from A to B, if the working tree has a
local modification at paths that are different between A and B,
we refused the operation saying "cannot merge." This attempts
to do an automerge for such paths.
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
Alex Riesen <raa.lkml-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> writes:
> On 1/9/06, Junio C Hamano <junkio-j9pdmedNgrk@public.gmane.org> wrote:
>> 2. Fix "git checkout <branch>" so that it does a reasonable thing
>> even when a dirty path is different in current HEAD and
>> destination branch. Then I could:
>>
>> $ git checkout symref ;# this would not work in the current git
>> # it would die like this:
>> # $ git checkout symref
>> # fatal: Entry 'gitweb.cgi' not uptodate. Cannot merge.
>
> That is actually very interesting. I already wished sometimes to be
> able to switch branches with a dirty working directory (and usually
> ended up with git diff+checkout+apply).
> Even if it results in a merge and conflict markers in files it looks
> like a very practical idea!
This is still experimental and probably has rough edges, but I
actually tested it once and it worked fine ;-).
git-checkout.sh | 24 +++++++++++++++++++++++-
1 files changed, 23 insertions(+), 1 deletions(-)
7929db987a9aac1d0370b64a8a00ffa13e6bab82
diff --git a/git-checkout.sh b/git-checkout.sh
index 3bbd111..1b2db91 100755
--- a/git-checkout.sh
+++ b/git-checkout.sh
@@ -121,7 +121,29 @@ then
git-checkout-index -q -f -u -a
else
git-update-index --refresh >/dev/null
- git-read-tree -m -u $old $new
+ git-read-tree -m -u $old $new || (
+ echo >&2 -n "Try automerge [y/N]? "
+ read yesno
+ case "$yesno" in [yY]*) ;; *) exit 1 ;; esac
+
+ # NEEDSWORK: We may want to reset the index from the $new for
+ # these paths after the automerge happens, but it is not done
+ # yet. Probably we need to leave unmerged ones alone, and
+ # yank the object name & mode from $new for cleanly merged
+ # paths and stuff them in the index.
+
+ names=`git diff-files --name-only`
+ echo "$names" | git update-index --remove --stdin
+
+ work=`git write-tree` &&
+ git read-tree -m -u $old $work $new || exit
+ if result=`git write-tree 2>/dev/null`
+ then
+ echo >&2 "Trivially automerged." ;# can this even happen?
+ exit 0
+ fi
+ git merge-index -o git-merge-one-file -a
+ )
fi
#
--
1.1.1-g8ecb
^ permalink raw reply related
* Linus repository at git.kernel.org???
From: Junio C Hamano @ 2006-01-12 7:19 UTC (permalink / raw)
To: Coywolf Qi Hunt; +Cc: git, torvalds
In-Reply-To: <2cd57c900601112153t2d85895bg@mail.gmail.com>
Coywolf Qi Hunt <coywolf@gmail.com> writes:
> gemini:~/linux/linux-2.6> git-pull
> fatal: unexpected EOF
> Fetch failure: git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
The failure does not seem to happen on all repositories, but
just is with Linus repository, so I doubt "git update" on either
your end or kernel.org public machines have anything to do with
this. And Linus repository from gitweb is also missing.
I do not have more access to the mirrored public machines than
you have. I can try snooping the traffic from git-peek-remote
to git://git.kernel.org/ but cannot examine the filesystem over
there, so I cannot tell you more than this: I looked at Linus
repository on the mirror source machine and did not see anything
obviously wrong with it. It seemed to have updated around 3-4
hours ago.
^ permalink raw reply
* Re: RFC: Subprojects
From: Anand Kumria @ 2006-01-12 7:20 UTC (permalink / raw)
To: git
In-Reply-To: <200601121125.33696.lan@ac-sw.com>
On Thu, 12 Jan 2006 11:25:33 +0600, Alexander Litvinov wrote:
> On Thursday 12 January 2006 10:46, Martin Langhoff wrote:
>> > I really miss this feature. This is the last stopper for moving from CVS
>> > to git for out project.
>>
>> What about using nested checkouts? They work great with git as-is,
>> just add an .gitignore file.
>>
>> As Linus points out, there are many good reasons why a top-level
>> commit should _not_ commit the nested subproject. And once you are
>> observing that rule, what's left then? git status and git diff <HEAD>
>> can show an aggregate of top-level and nested subprojects, but that's
>> ease-of-use -- not something only.
>>
>> What is your show stopper?
>
> I would agree to make separate commits for each sub project.
>
> 1. I need to have ability to make tags, branches thru all subprojects.
> 2. Update (pull) sould update each subproject, it is hard to update them by
> hands.
> 3. The need of some sort of checkout script (can be solved by storing this
> script in base project, but it would be much nicer allow git fetch all
> subprojects)
>
> Nothing else I can imagine.
It sounds like you want 'config-manager',
http://packages.debian.org/unstable/devel/config-manager, it doesn't
support git (yet) but I can't imagine it is hard to add that support in.
Cheers,
Anand
^ permalink raw reply
* git-pull fails after git upgrade
From: Coywolf Qi Hunt @ 2006-01-12 5:53 UTC (permalink / raw)
To: git
Hello,
gemini:~/linux/linux-2.6> git --version
git version 1.0.8
gemini:~/linux/linux-2.6> git-pull
fatal: unexpected EOF
Fetch failure: git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
What am I missing? thanks
--
Coywolf Qi Hunt
^ permalink raw reply
* Re: RFC: Subprojects
From: Martin Langhoff @ 2006-01-12 5:39 UTC (permalink / raw)
To: Alexander Litvinov; +Cc: Simon Richter, git
In-Reply-To: <200601121125.33696.lan@ac-sw.com>
On 1/12/06, Alexander Litvinov <lan@ac-sw.com> wrote:
> > What is your show stopper?
>
> I would agree to make separate commits for each sub project.
>
> 1. I need to have ability to make tags, branches thru all subprojects.
I suspect that this is a bad idea -- for the same reason as committing
to a subproject is a bad idea. The subprojects most likely have their
own external repositories -- and lifecycles of their own. The same
headname/branchname won't do.
> 2. Update (pull) sould update each subproject, it is hard to update them by
> hands.
A simple shellscript can help you here.
> 3. The need of some sort of checkout script (can be solved by storing this
> script in base project, but it would be much nicer allow git fetch all
> subprojects)
As you say, a bootstrapping shellscript can sort this out.
Sounds quite doable ;-)
(have to warn you though -- git is quite addictive. there's no going back...)
cheers,
martin
^ permalink raw reply
* Re: [PATCH] (Updated) Exec git programs without using PATH.
From: H. Peter Anvin @ 2006-01-12 5:38 UTC (permalink / raw)
To: Andreas Ericsson; +Cc: git
In-Reply-To: <43C59EC6.6070905@op5.se>
Andreas Ericsson wrote:
>
> Not being entirely knowledgeable on what spawn() actually does and how
> its semantics differ from fork() and exec*() style API's (Google was
> depressingly unhelpful and wikipedia dredged up froglings...), I've got
> a decent "clone-lots-of-processes-and-multiplex-between-them" kind of
> library lying around. Would it be of any use?
>
> From the prototypes I've seen on spawn it doesn't seem to be much more
> than a fork() + execve(), either closing or dup2'ing all the
> file-descriptors, so I don't understand why that couldn't be implemented
> for git. Some pointers, anyone?
>
RTFM(posix_spawn)...
-hpa
^ permalink raw reply
* Re: RFC: Subprojects
From: Alexander Litvinov @ 2006-01-12 5:25 UTC (permalink / raw)
To: Martin Langhoff; +Cc: Simon Richter, git
In-Reply-To: <46a038f90601112046u13d7075dsc2108111e2462152@mail.gmail.com>
On Thursday 12 January 2006 10:46, Martin Langhoff wrote:
> > I really miss this feature. This is the last stopper for moving from CVS
> > to git for out project.
>
> What about using nested checkouts? They work great with git as-is,
> just add an .gitignore file.
>
> As Linus points out, there are many good reasons why a top-level
> commit should _not_ commit the nested subproject. And once you are
> observing that rule, what's left then? git status and git diff <HEAD>
> can show an aggregate of top-level and nested subprojects, but that's
> ease-of-use -- not something only.
>
> What is your show stopper?
I would agree to make separate commits for each sub project.
1. I need to have ability to make tags, branches thru all subprojects.
2. Update (pull) sould update each subproject, it is hard to update them by
hands.
3. The need of some sort of checkout script (can be solved by storing this
script in base project, but it would be much nicer allow git fetch all
subprojects)
Nothing else I can imagine.
^ 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