* [PATCH] git-remote rename should match whole string when renaming remote ref directory
From: Benny Halevy @ 2011-09-26 13:53 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Benny Halevy
From: Benny Halevy <bhalevy@tonian.com>
Otherwise, with two remotes: test, test-2
git remote rename test test-
ends up with:
.git/refs/remotes/test-
.git/refs/remotes/test--2
Signed-off-by: Benny Halevy <bhalevy@tonian.com>
---
By the way, I also see the old names as empty directories in .git/refs/remotes
not sure if that's a bug or a feature... :)
Benny
builtin/remote.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/builtin/remote.c b/builtin/remote.c
index f2a9c26..5443e71 100644
--- a/builtin/remote.c
+++ b/builtin/remote.c
@@ -571,7 +571,7 @@ static int read_remote_branches(const char *refname,
const char *symref;
strbuf_addf(&buf, "refs/remotes/%s", rename->old);
- if (!prefixcmp(refname, buf.buf)) {
+ if (!strcmp(refname, buf.buf)) {
item = string_list_append(rename->remote_branches, xstrdup(refname));
symref = resolve_ref(refname, orig_sha1, 1, &flag);
if (flag & REF_ISSYMREF)
--
1.7.7.rc3.dirty
^ permalink raw reply related
* Re: subversion-perl missing
From: Georg-Johann Lay @ 2011-09-26 13:41 UTC (permalink / raw)
To: Michael J Gruber; +Cc: git
In-Reply-To: <4E807829.7050609@drmicha.warpmail.net>
Michael J Gruber schrieb:
> Georg-Johann Lay venit, vidit, dixit 26.09.2011 13:48:
>> Hi, I just downloaded git and built from source, version is
>>
>> git version 1.7.6.4
>>
>> I am particularly interested in git-svn, but running it I get complaints
>>
>> Initialized empty Git repository in /local/Downloads/v4.5.x/.git/
>> Can't locate SVN/Core.pm in @INC (@INC contains:
>> /usr/local/lib/perl5/site_perl/5.10.0/i586-linux-thread-multi
>> /usr/local/lib/perl5/site_perl/5.10.0
>> /usr/lib/perl5/5.10.0/i586-linux-thread-multi /usr/lib/perl5/5.10.0
>> /usr/lib/perl5/site_perl/5.10.0/i586-linux-thread-multi
>> /usr/lib/perl5/site_perl/5.10.0
>> /usr/lib/perl5/vendor_perl/5.10.0/i586-linux-thread-multi
>> /usr/lib/perl5/vendor_perl/5.10.0 /usr/lib/perl5/vendor_perl .) at
>> /usr/local/libexec/git-core/git-svn line 42
>>
>> I found out that a module like subversion-perl is missing, but installing it
>> via OpenSuse 1.11 would downgrade my SVN installation, so I skipped that.
>
> So, where did you get your svn from? If you compiled it yourself, you
> should rebuild it with the perl bindings. Make sure you note where you
> install this to - you may have to adjust your PERL5LIB.
Hi Michael
svn identifies itself as
> svn --version
svn, version 1.6.2 (r37639)
compiled Jun 19 2009, 12:21:15
Copyright (C) 2000-2009 CollabNet.
Subversion is open source software, see http://subversion.tigris.org/
This product includes software developed by CollabNet (http://www.Collab.Net/).
The following repository access (RA) modules are available:
* ra_neon : Module for accessing a repository via WebDAV protocol using Neon.
- handles 'http' scheme
- handles 'https' scheme
* ra_svn : Module for accessing a repository using the svn network protocol.
- with Cyrus SASL authentication
- handles 'svn' scheme
* ra_local : Module for accessing a repository on local disk.
- handles 'file' scheme
and its installed in
> which svn
/usr/bin/svn
> echo $PERL5LIB
<empty>
so looks like plain vanilla installation/build.
Is "perl bindings" the "subversion-perl" package (which likes to downgrade my
svn upon installing in yast)?
Is it a part of SVN (couln't find it there) or of perl?
> perl --version says:
This is perl, v5.10.0 built for i586-linux-thread-multi
Copyright 1987-2007, Larry Wall
...
>> Thus, being no admin and no perl guy, I am stuck now and am asking here for
>> some kind help, being very well aware that it's not a git issue but just about
>> getting some prerequisite for git.
>>
>> Where do I have to go to get the svn+perl stuff? Couldn't locate anything like
>> that in subversion.tigris.org, so that I am stuck and need some hints on how to
>> proceed.
>>
>> Many thanks,
>>
>> Johann
^ permalink raw reply
* Re: subversion-perl missing
From: Michael J Gruber @ 2011-09-26 13:03 UTC (permalink / raw)
To: Georg-Johann Lay; +Cc: git
In-Reply-To: <4E8066AB.7000208@gjlay.de>
Georg-Johann Lay venit, vidit, dixit 26.09.2011 13:48:
> Hi, I just downloaded git and built from source, version is
>
> git version 1.7.6.4
>
> I am particularly interested in git-svn, but running it I get complaints
>
> Initialized empty Git repository in /local/Downloads/v4.5.x/.git/
> Can't locate SVN/Core.pm in @INC (@INC contains:
> /usr/local/lib/perl5/site_perl/5.10.0/i586-linux-thread-multi
> /usr/local/lib/perl5/site_perl/5.10.0
> /usr/lib/perl5/5.10.0/i586-linux-thread-multi /usr/lib/perl5/5.10.0
> /usr/lib/perl5/site_perl/5.10.0/i586-linux-thread-multi
> /usr/lib/perl5/site_perl/5.10.0
> /usr/lib/perl5/vendor_perl/5.10.0/i586-linux-thread-multi
> /usr/lib/perl5/vendor_perl/5.10.0 /usr/lib/perl5/vendor_perl .) at
> /usr/local/libexec/git-core/git-svn line 42
>
> I found out that a module like subversion-perl is missing, but installing it
> via OpenSuse 1.11 would downgrade my SVN installation, so I skipped that.
So, where did you get your svn from? If you compiled it yourself, you
should rebuild it with the perl bindings. Make sure you note where you
install this to - you may have to adjust your PERL5LIB.
> Thus, being no admin and no perl guy, I am stuck now and am asking here for
> some kind help, being very well aware that it's not a git issue but just about
> getting some prerequisite for git.
>
> Where do I have to go to get the svn+perl stuff? Couldn't locate anything like
> that in subversion.tigris.org, so that I am stuck and need some hints on how to
> proceed.
>
> Many thanks,
>
> Johann
^ permalink raw reply
* [PATCH 2/2] templates/hooks--*: don't refer to contrib hooks
From: Gerrit Pape @ 2011-09-26 12:59 UTC (permalink / raw)
To: Junio C Hamano, git
Simplify the sample post-receive hook to not refer to some location of a
contrib hook that might be installed in different locations on different
systems. Instead simply provide a sample file that does nothing just as
the post-commit sample hook.
Signed-off-by: Gerrit Pape <pape@smarden.org>
---
templates/hooks--post-receive.sample | 12 ++----------
1 files changed, 2 insertions(+), 10 deletions(-)
diff --git a/templates/hooks--post-receive.sample b/templates/hooks--post-receive.sample
index 7a83e17..5b1771f 100755
--- a/templates/hooks--post-receive.sample
+++ b/templates/hooks--post-receive.sample
@@ -2,14 +2,6 @@
#
# An example hook script for the "post-receive" event.
#
-# The "post-receive" script is run after receive-pack has accepted a pack
-# and the repository has been updated. It is passed arguments in through
-# stdin in the form
-# <oldrev> <newrev> <refname>
-# For example:
-# aa453216d1b3e49e7f6f98441fa56946ddcd6a20 68f7abf4e6f922807889f52bc043ecd31b79f814 refs/heads/master
-#
-# see contrib/hooks/ for a sample, or uncomment the next line and
-# rename the file to "post-receive".
+# To enable this hook, rename this file to "post-receive".
-#. /usr/share/doc/git-core/contrib/hooks/post-receive-email
+: Nothing
--
1.7.6.3
^ permalink raw reply related
* [PATCH 1/2] contrib/hooks: adapt comment about Debian install location for contrib hooks
From: Gerrit Pape @ 2011-09-26 12:58 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vr53b578t.fsf@alter.siamese.dyndns.org>
Placing the contrib hooks into /usr/share/doc/ wasn't a good idea in the
first place. According to the Debian policy they should be located in
/usr/share/git-core/, so let's put them there.
Thanks to Bill Allombert for reporting this through
http://bugs.debian.org/640949
Signed-off-by: Gerrit Pape <pape@smarden.org>
---
On Tue, Sep 20, 2011 at 12:44:18PM -0700, Junio C Hamano wrote:
> > --- a/contrib/hooks/post-receive-email
> > +++ b/contrib/hooks/post-receive-email
> > @@ -11,11 +11,11 @@
> > # will have put this somewhere standard. You should make this
> > script
> > # executable then link to it in the repository you would like to
> > use it in.
> > # For example, on debian the hook is stored in
> > -# /usr/share/doc/git-core/contrib/hooks/post-receive-email:
> > +# /usr/share/git-core/contrib/hooks/post-receive-email:
> > #
> > # chmod a+x post-receive-email
> > # cd /path/to/your/repository.git
> > -# ln -sf /usr/share/doc/git-core/contrib/hooks/post-receive-email
> > hooks/post-receive
> > +# ln -sf /usr/share/git-core/contrib/hooks/post-receive-email
> > hooks/post-receive
>
> This one I do not have any problem with; the leading text makes it
> very
> clear that this is an example that is specific to Debian and that is
> good enough to signal readers that they may have to look elsewhere if
> they
> are on a different distribution.
>
Ok, thanks. I stripped this patch to just touch this file.
Regards, Gerrit.
contrib/hooks/post-receive-email | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/contrib/hooks/post-receive-email b/contrib/hooks/post-receive-email
index fa6d41a..ba077c1 100755
--- a/contrib/hooks/post-receive-email
+++ b/contrib/hooks/post-receive-email
@@ -11,11 +11,11 @@
# will have put this somewhere standard. You should make this script
# executable then link to it in the repository you would like to use it in.
# For example, on debian the hook is stored in
-# /usr/share/doc/git-core/contrib/hooks/post-receive-email:
+# /usr/share/git-core/contrib/hooks/post-receive-email:
#
# chmod a+x post-receive-email
# cd /path/to/your/repository.git
-# ln -sf /usr/share/doc/git-core/contrib/hooks/post-receive-email hooks/post-receive
+# ln -sf /usr/share/git-core/contrib/hooks/post-receive-email hooks/post-receive
#
# This hook script assumes it is enabled on the central repository of a
# project, with all users pushing only to it and not between each other. It
--
1.7.6.3
^ permalink raw reply related
* Re: [ANNOUNCE] Git 1.7.7.rc3
From: Ævar Arnfjörð Bjarmason @ 2011-09-26 12:47 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Linux Kernel
In-Reply-To: <7vhb42su6f.fsf@alter.siamese.dyndns.org>
On Sat, Sep 24, 2011 at 01:41, Junio C Hamano <gitster@pobox.com> wrote:
> Also the following public repositories all have a copy of the v1.7.7-rc3
> tag and the master branch that the tag points at:
The 1.7.7-rc* series still doesn't compile on older Red Hat machines
because 4c1be38b4a236403a329187acb70591a7fd92150 hasn't been included
in it.
Could you please include that in the final 1.7.7? It would be a PITA
to have to work around that.
^ permalink raw reply
* Re: Git is not scalable with too many refs/*
From: Christian Couder @ 2011-09-26 12:41 UTC (permalink / raw)
To: Martin Fick; +Cc: git, Christian Couder
In-Reply-To: <201109251443.28243.mfick@codeaurora.org>
On Sun, Sep 25, 2011 at 10:43 PM, Martin Fick <mfick@codeaurora.org> wrote:
> A coworker of mine pointed out to me that a simple
>
> git checkout
>
> can also take rather long periods of time > 3 mins when run
> on a repo with ~100K refs.
Are all these refs packed?
> While this is not massive like the other problem I reported,
> it still seems like it is more than one would expect. So, I
> tried an older version of git, and to my surprise/delight,
> it was much faster (.2s). So, I bisected this issue also,
> and it seems that the "offending" commit is
> 680955702990c1d4bfb3c6feed6ae9c6cb5c3c07:
>
> commit 680955702990c1d4bfb3c6feed6ae9c6cb5c3c07
> Author: Christian Couder <chriscool@tuxfamily.org>
> Date: Fri Jan 23 10:06:53 2009 +0100
>
> replace_object: add mechanism to replace objects found
> in "refs/replace/"
[...]
> Now, I suspect this commit is desirable, but I was hoping
> that perhaps a look at it might inspire someone to find an
> obvious problem with it.
I don't think there is an obvious problem with it, but it would be
nice if you could dig a bit deeper.
The first thing that could take a lot of time is the call to
for_each_replace_ref() in this function:
+static void prepare_replace_object(void)
+{
+ static int replace_object_prepared;
+
+ if (replace_object_prepared)
+ return;
+
+ for_each_replace_ref(register_replace_ref, NULL);
+ replace_object_prepared = 1;
+}
Another thing is calling replace_object_pos() repeatedly in
lookup_replace_object().
Thanks,
Christian.
^ permalink raw reply
* Re: config-file includes
From: Jeff King @ 2011-09-26 12:36 UTC (permalink / raw)
To: Nguyen Thai Ngoc Duy
Cc: git, Michael Haggerty, Jay Soffian, Junio C Hamano,
Jakub Narebski
In-Reply-To: <CACsJy8BAVRAct=sxTpZ+b-ft1OjbY9oZG6uEXrcsTXw3CXnwSg@mail.gmail.com>
On Mon, Sep 26, 2011 at 08:45:58PM +1000, Nguyen Thai Ngoc Duy wrote:
> > You could extend this to look in refs, with something like:
> >
> > [include]
> > ref = meta:config
> >
> > which would resolve meta:config to a blob and examine it (i.e., it would
> > look at refs/heads/meta).
>
> I had something similar [1], although I disregarded worktree content
> completely.
Thanks, I had totally missed that thread.
Maybe it wasn't clear from my proposal, but I intend to disregard the
worktree entirely, too. The include.path was about including stuff from
the local filesystem, not necessarily your worktree.
> One thing about this meta thing is fsck/prune must dig in
> config file in order not to accidentally remove something config file
> refers to.
It is only a connectivity problem if you put a raw sha1 in the config.
It seems much more sensible to me to use a real ref. That solves the
fsck issue, and it makes it easier to manipulate the contents using git.
> Another thing is, what if I want to exclude certain part of the included config?
git show origin/meta:config ;# review upstream
git checkout meta origin/meta
$EDITOR config
git commit -a -m 'tweak my config based on upstream'
git config include.ref meta:config
[weeks later]
git fetch ;# oh, new config from upstream
git log -p origin/meta@{1}...origin/meta ;# looks good to me
git checkout meta
git merge origin/meta
Junio raised a good point in the thread you referenced: why is this any
better than the project just shipping a "./setup-config" script that you
run (and re-run when there is an update). Two things I can think of:
1. Carrying it in the project tree (as opposed to a separate ref) is
annoying. It bloats your project tree, and any changes you make
get tangled up in the changes you're making to the project itself.
To me, they're logically separate entities.
You can still keep a separate "meta" ref that has the setup-config
script in it, though. That wouldn't need git support at all.
But...
2. Using a script to deploy the config makes it annoying to track
changes. If I make local tweaks to what upstream suggests for the
config, I would want those tracked by git. And when upstream makes
a change, I want to do a 3-way merge. So either my script must be
clever in deploying, or I must never touch the deployed .git/config
file, and instead edit the setup-config script. Even then, how does
it handle changes in .git/config that happen naturally (e.g.,
branch config written by git).
If we had even a mechanism to include regular files, you could do
something like:
# make our local tweaked version of config
git checkout meta
$EDITOR config
git commit -a -m 'tweak config based on upstream'
# now deploy it
cp config .git/tracked-config
# and reference it
git config include.path tracked-config
# Weeks later, update and redeploy. Don't touch tracked-config in
# the meantime, as your changes will be overwritten (or copy it
# back after checkout, commit changes, then pull)
git checkout meta
git pull
cp config .git/tracked-config
which is really quite similar to the "include.ref" I showed earlier,
except you can skip the annoying "deploy" step. Which is a minor
convenience if you are actually keeping your own local config branch,
and a slightly larger one if you want to do the dangerous "just look at
origin/meta for config" thing.
> > [1] I want conditional inclusion because sometimes the rules for config
> > entries changes from version to version. For example, I have
> > pager.diff set to a script in my ~/.gitconfig. But older versions of
> > git don't understand non-boolean values and barf. I'd really like to
> > do something like:
> >
> > [include-ifdef "has-pager-scripts"]
> > path = ~/.gitconfig-pager
> >
> > where "has-pager-scripts" would be a magic flag compiled into git
> > versions that understand that config.
>
> But how far would you go with conditional expressions?
I agree it could become hairy in the general case. That's why I called
it "include-ifdef" and not "include-if". That would serve my use case. I
have no desire to support
[include-if "2 + 2 >= 4"]
-Peff
^ permalink raw reply
* subversion-perl missing
From: Georg-Johann Lay @ 2011-09-26 11:48 UTC (permalink / raw)
To: git
Hi, I just downloaded git and built from source, version is
git version 1.7.6.4
I am particularly interested in git-svn, but running it I get complaints
Initialized empty Git repository in /local/Downloads/v4.5.x/.git/
Can't locate SVN/Core.pm in @INC (@INC contains:
/usr/local/lib/perl5/site_perl/5.10.0/i586-linux-thread-multi
/usr/local/lib/perl5/site_perl/5.10.0
/usr/lib/perl5/5.10.0/i586-linux-thread-multi /usr/lib/perl5/5.10.0
/usr/lib/perl5/site_perl/5.10.0/i586-linux-thread-multi
/usr/lib/perl5/site_perl/5.10.0
/usr/lib/perl5/vendor_perl/5.10.0/i586-linux-thread-multi
/usr/lib/perl5/vendor_perl/5.10.0 /usr/lib/perl5/vendor_perl .) at
/usr/local/libexec/git-core/git-svn line 42
I found out that a module like subversion-perl is missing, but installing it
via OpenSuse 1.11 would downgrade my SVN installation, so I skipped that.
Thus, being no admin and no perl guy, I am stuck now and am asking here for
some kind help, being very well aware that it's not a git issue but just about
getting some prerequisite for git.
Where do I have to go to get the svn+perl stuff? Couldn't locate anything like
that in subversion.tigris.org, so that I am stuck and need some hints on how to
proceed.
Many thanks,
Johann
^ permalink raw reply
* Re: How to use git attributes to configure server-side checks?
From: Jeff King @ 2011-09-26 11:05 UTC (permalink / raw)
To: Michael Haggerty
Cc: Jay Soffian, Junio C Hamano, git discussion list, Jakub Narebski
In-Reply-To: <4E7DB916.6010606@alum.mit.edu>
On Sat, Sep 24, 2011 at 01:03:50PM +0200, Michael Haggerty wrote:
> > But once you've verified that the config looks OK and turned this option
> > on, how do you protect yourself from malicious config entering the repo
> > through a fetch?
>
> For most software projects, the user does
>
> git pull
> make
>
> daily. There is nothing that a nasty .gitconfig can do that can't be
> done more easily by a nasty Makefile (or anything else in the build
> process). The moment I pull from Junio's repository and run a build
> without having personally done a full code review first, I've given
> Junio complete pownership of my account. For projects in which I invest
> such trust, "core.useTreeConfig=true" would be a convenience that does
> not appreciably increase my risk.
True. I think it would be nice for their to be a less risky option, too,
though. Which was part of the motivation in my earlier proposal for
specifying a ref that contains config. Then you can ignore it, track
your own local config which is derived from upstream, or do the easy but
dangerous thing of just using the remote tracking ref directly.
> There are obviously config options that should not be versioned. These
> should not be stored in the tree. (Perhaps they should be stored in
> another branch, as you suggested.) But there's no need to prevent
> people from versioning *any* config options just because they shouldn't
> version *all* of them.
Do you have an example of a config option whose old value should be
respected when looking at an old version? In general, the split between
attributes and config was meant to split what is tied to a specific
version, and what should apply to all versions. We may not have followed
that in all cases, but if so, the right solution may actually be
migrating the functionality into .gitattributes.
> While we are on the topic of config settings, I have often thought that
> it would be nice for git's default settings to be set via a
> well-commented config file, installed along with git, rather than via
> values compiled into the code. This file and Documentation/config.txt
> could be generated from a single source file as part of the build
> process.
I think that can be a nice piece of documentation, but there may be some
complications. I seem to recall that there may be one or two options
whose builtin values cannot be replicated via config (i.e., the "unset"
state means something). But I may be misremembering.
However, I'm not sure what you mean by "rather than via values compiled
into the code". Would you somehow generate code that sets the default
according to your master file? Would git fail to start if the file is
missing? Or if a specific config option is missing? How would you track
that?
-Peff
^ permalink raw reply
* Re: config-file includes
From: Nguyen Thai Ngoc Duy @ 2011-09-26 10:45 UTC (permalink / raw)
To: Jeff King
Cc: git, Michael Haggerty, Jay Soffian, Junio C Hamano,
Jakub Narebski
In-Reply-To: <20110923195829.GA27677@sigill.intra.peff.net>
On Sat, Sep 24, 2011 at 5:58 AM, Jeff King <peff@peff.net> wrote:
> Here's one solution I've given a little thought to. Comments welcome.
>
> I've sometimes wanted an "include" mechanism in git config files.
> Partially to just keep things tidier, partially to avoid
> cutting-and-pasting between some repo-specific config, and partially
> because I'd like a conditional inclusion mechanism[1]. I was thinking of
> something that would be syntactically compatible but semantically
> meaningless in current versions of git, like:
>
> [include]
> path = /some/file
> path = /some/other/file
> path = ~/some/file/in/your/homedir
>
> You could extend this to look in refs, with something like:
>
> [include]
> ref = meta:config
>
> which would resolve meta:config to a blob and examine it (i.e., it would
> look at refs/heads/meta).
I had something similar [1], although I disregarded worktree content
completely. One thing about this meta thing is fsck/prune must dig in
config file in order not to accidentally remove something config file
refers to.
Another thing is, what if I want to exclude certain part of the included config?
[1] http://thread.gmane.org/gmane.comp.version-control.git/163285/focus=163288
> [1] I want conditional inclusion because sometimes the rules for config
> entries changes from version to version. For example, I have
> pager.diff set to a script in my ~/.gitconfig. But older versions of
> git don't understand non-boolean values and barf. I'd really like to
> do something like:
>
> [include-ifdef "has-pager-scripts"]
> path = ~/.gitconfig-pager
>
> where "has-pager-scripts" would be a magic flag compiled into git
> versions that understand that config.
But how far would you go with conditional expressions?
--
Duy
^ permalink raw reply
* Re: Test message to Git mailing list
From: Alexey Shumkin @ 2011-09-26 10:21 UTC (permalink / raw)
To: Shumkin Alexey; +Cc: git@vger.kernel.org
In-Reply-To: <CAEFUfsHK20GivxtJpZZnFRfiTM9TZDtbrJs==U-woV=o7gniYQ@mail.gmail.com>
Replied from claws-mail
> Test message body
>
> P.S. previous messages from this account did not delivered
^ permalink raw reply
* Test message to Git mailing list
From: Alexey Shumkin @ 2011-09-26 10:16 UTC (permalink / raw)
To: git @ vger . kernel . org; +Cc: Shumkin Alexey, zapped
From: Shumkin Alexey <Alex.Crezoff@gmail.com>
Test message body
P.S. previous messages from this account did not delivered
^ permalink raw reply
* Test message to Git mailing list
From: Shumkin Alexey @ 2011-09-26 10:08 UTC (permalink / raw)
To: git@vger.kernel.org; +Cc: zapped
Test message body
P.S. previous messages from this account did not delivered
^ permalink raw reply
* Re: git-rebase skips automatically no more needed commits
From: Thomas Rast @ 2011-09-26 9:10 UTC (permalink / raw)
To: Martin von Zweigbergk
Cc: Ramkumar Ramachandra, Junio C Hamano, Francis Moreau,
Michael J Gruber, git
In-Reply-To: <alpine.DEB.2.00.1109242148570.24369@debian>
Martin von Zweigbergk wrote:
>
> If I understand correctly, [rebase --root] was introduced to solve
> exactly the same reason problem that made Francis start this thread
> -- to avoid re-applying patches that are already in $onto.
Not quite; I wrote it because at the time, there was no way to
transplant git history onto a git-svn "make empty subdir" commit for
later dcommitting. So the main point was really
> After my patches (that are not yet ready) that calculate revisions as
> "git cherry $onto $orig_head $upstream", I don't think there should be
> any need for the --root flag. The only place the flag is checked now
> (in my current work tree, that is) is when deciding how to interpret
> the remaining arguments. Although I have not tried (temporarily)
> rewriting all the test cases from
>
> git rebase --root --onto upstream branch
>
> to
>
> git rebase upstream branch
>
> , I think it should work. What do you think, Thomas?
I still think it would be natural for a user to want a way to say "all
the way back to the root commit". At least for me the "full" rebase
invocation is
git rebase --onto onto base branch
In that mindset it comes natural to replace 'base' with --root if you
want to go all the way.
Maybe I don't trust rebase enough to do what I want ;-)
> I saw that
> "--root" is also passed to the hook. Should that value be passed to
> the hook also when the old base is not explicitly a root (by "rebase
> --root"), but only implicitly so (by an $onto that is disjoint from
> $branch)?
I think I did it that way because if you use --root, the base/upstream
argument is missing, and the hook needs to know that.
If the user specifies an upstream that is disjoint from the branch
itself, the hook gets the upstream argument and can presumably work it
out from there. So you could perhaps save the hook some trouble if
you *know* that it's a disjoint rebase, but I wouldn't spend too much
time on that.
--
Thomas Rast
trast@{inf,student}.ethz.ch
^ permalink raw reply
* Re: Could someone give me a copy of git internal api document?
From: Tay Ray Chuan @ 2011-09-26 8:42 UTC (permalink / raw)
To: Michael Schubert; +Cc: 徐迪, Git 邮件列表
In-Reply-To: <4E802872.2010906@elegosoft.com>
2011/9/26 Michael Schubert <mschub@elegosoft.com>:
> On 09/26/2011 09:11 AM, 徐迪 wrote:
>> I am reading code of git recently, and i want to know some internal
>> api in git, so i googled "git internal api", and result is
>> http://www.kernel.org/pub/software/scm/git/docs/v1.6.5.9/technical/api-index.html
>> but kernel.org was down for maintenance, and i have no idea when it
>> will recover, could someone give me a mirror url or post me a copy of
>> it?
>
> If you got the code, you should have Documentation/technical in your
> source tree.?
If you prefer the generated HTML output:
https://git-core.googlecode.com/git-history/html/technical/api-index.html
--
Cheers,
Ray Chuan
^ permalink raw reply
* Re: git svn clone issues with buddypress subversion repository
From: Michael J Gruber @ 2011-09-26 8:13 UTC (permalink / raw)
To: Anand Kumria; +Cc: git
In-Reply-To: <CAM1C4G=o_Q5scdv=Jk3ou-3OjnZiukZV3nz0NJR7CTaKLbB2jw@mail.gmail.com>
Anand Kumria venit, vidit, dixit 24.09.2011 18:50:
> Hi,
>
> I'm trying:
>
> % git svn clone -s http://svn.buddypress.org/trunk/ buddypress
Please try
git svn clone -s http://svn.buddypress.org/ buddypress
By saying "-s", you make git-svn look in trunk, branches and tags
subdirs of the URL that you specify, i.e. trunk/trunk etc. with your
command line.
Or, omit "-s" if you want the trunk branch only.
> Initialized empty Git repository in
> /home/anand/Projects/wordpress/buddypress/.git/
> Using higher level of URL: http://svn.buddypress.org/trunk =>
> http://svn.buddypress.org
>
> % git --version
> git version 1.7.0.4
>
> And at the end, git svn appears to successfull complete but nothing
> has occurred. I'm successfully using 'git svn' against other
> repositories with no problem, just wondering if anyone else has come
> across this.
>
> % find buddypress
> buddypress
> buddypress/.git
> [omitted]
> buddypress/.git/svn
> buddypress/.git/svn/refs
> buddypress/.git/svn/refs/remotes
> buddypress/.git/svn/refs/remotes/git-svn
> buddypress/.git/svn/refs/remotes/trunk
> buddypress/.git/svn/refs/remotes/trunk/.rev_map.cdf35c40-ae34-48e0-9cc9-0c9da1808c22
> buddypress/.git/svn/.metadata
>
> % cat buddypress/.git/svn/.metadata
> ; This file is used internally by git-svn
> ; You should not have to edit it
> [svn-remote "svn"]
> reposRoot = http://svn.buddypress.org
> uuid = cdf35c40-ae34-48e0-9cc9-0c9da1808c22
> branches-maxRev = 5188
> tags-maxRev = 5188
Contents of .git/config would be more helpful in general. We don't need
it in this case, but looking at it might have given you the clue
(trunk/trunk).
Michael
^ permalink raw reply
* Re: Could someone give me a copy of git internal api document?
From: Michael Schubert @ 2011-09-26 7:23 UTC (permalink / raw)
To: 徐迪; +Cc: Git 邮件列表
In-Reply-To: <CAMocUqREFHdqFGR9c_3hFJy6KxUaXLnaY9R+4K04mL42-KY-Kg@mail.gmail.com>
On 09/26/2011 09:11 AM, 徐迪 wrote:
> I am reading code of git recently, and i want to know some internal
> api in git, so i googled "git internal api", and result is
> http://www.kernel.org/pub/software/scm/git/docs/v1.6.5.9/technical/api-index.html
> but kernel.org was down for maintenance, and i have no idea when it
> will recover, could someone give me a mirror url or post me a copy of
> it?
If you got the code, you should have Documentation/technical in your
source tree.?
Alternate repository source:
http://repo.or.cz/w/alt-git.git
Documentation/technical on GitHub:
https://github.com/gitster/git/tree/master/Documentation/technical
^ permalink raw reply
* Could someone give me a copy of git internal api document?
From: 徐迪 @ 2011-09-26 7:11 UTC (permalink / raw)
To: Git 邮件列表
I am reading code of git recently, and i want to know some internal
api in git, so i googled "git internal api", and result is
http://www.kernel.org/pub/software/scm/git/docs/v1.6.5.9/technical/api-index.html
but kernel.org was down for maintenance, and i have no idea when it
will recover, could someone give me a mirror url or post me a copy of
it?
^ permalink raw reply
* Re: How to use git attributes to configure server-side checks?
From: Michael Haggerty @ 2011-09-26 4:28 UTC (permalink / raw)
To: Junio C Hamano
Cc: Jeff King, Jay Soffian, git discussion list, Jakub Narebski
In-Reply-To: <7vwrcwq70k.fsf@alter.siamese.dyndns.org>
On 09/26/2011 06:09 AM, Junio C Hamano wrote:
> Michael Haggerty <mhagger@alum.mit.edu> writes:
>
>> On 09/24/2011 08:15 AM, Jeff King wrote:
>> For most software projects, the user does
>>
>> git pull
>> make
>>
>> daily. There is nothing that a nasty .gitconfig can do that can't be
>> done more easily by a nasty Makefile (or anything else in the build
>> process). The moment I pull from Junio's repository and run a build
>> without having personally done a full code review first, I've given
>> Junio complete pownership of my account.
>
> I suspect that argument is somewhat leaky.
>
> Will I be the _only_ one you will be pulling from? What if I were not so
> careful and relay a contaminated in-tree configuration file (which I would
> never use myself) to trusting downstream users like you?
I'm not saying that trusting in-tree configuration files makes sense for
everybody, and in the open-source world one must be very careful about
doing so. But I think that among closely-cooperating groups (e.g.,
personal projects, many projects in industry) (1) we don't pull from
outside the group and (2) we are forced to trust each other pretty
completely anyway. So I think that there are many sane use-cases for
giving users the opportunity to "bless" an in-tree config.
Michael
--
Michael Haggerty
mhagger@alum.mit.edu
http://softwareswirl.blogspot.com/
^ permalink raw reply
* Re: How to use git attributes to configure server-side checks?
From: Junio C Hamano @ 2011-09-26 4:09 UTC (permalink / raw)
To: Michael Haggerty
Cc: Jeff King, Jay Soffian, git discussion list, Jakub Narebski
In-Reply-To: <4E7DB916.6010606@alum.mit.edu>
Michael Haggerty <mhagger@alum.mit.edu> writes:
> On 09/24/2011 08:15 AM, Jeff King wrote:
> For most software projects, the user does
>
> git pull
> make
>
> daily. There is nothing that a nasty .gitconfig can do that can't be
> done more easily by a nasty Makefile (or anything else in the build
> process). The moment I pull from Junio's repository and run a build
> without having personally done a full code review first, I've given
> Junio complete pownership of my account.
I suspect that argument is somewhat leaky.
Will I be the _only_ one you will be pulling from? What if I were not so
careful and relay a contaminated in-tree configuration file (which I would
never use myself) to trusting downstream users like you?
>> I'm not sure it makes sense to have it in the tree at all. For
>> attributes it makes sense, because you are annotating a path at a
>> _specific_ revision. But config is often much more meta- than that.
>> Take textconv for an example. The gitattributes say "foo.pdf should use
>> the 'pdf' diff driver". That makes sense to go in a revision. But the
>> config will say "pdf files can be converted to text using
>> /usr/bin/pdftotext". That is not something that is tied to the revision
>> at all, and should exist outside of any revision. I.e., whether I am
>> doing a "git show" on the HEAD, or on some ancient commit, I would want
>> to use the same value, not whatever tool I used to convert PDFs years
>> ago.
I agree 100% with Peff on this point. What pdfviewer is configured to be
used for my repository is tied closely to what I happen to have installed
on my box that I use that repository on. This is not by accident but by
design why attributes only specify what _kind_ of payload is in the path,
and leave it up to the config to say _how_ to handle each kind of payload
on the box).
^ permalink raw reply
* Re: More Beginning Git Questions
From: tactical @ 2011-09-26 1:42 UTC (permalink / raw)
To: git
In-Reply-To: <CAH5451nk9FnqwhEe0SWxDc3TnLiTLnFgD6zB3jDehFZn6=qWvw@mail.gmail.com>
Andrew Ardill wrote:
> As any commits you make in a detached state are in the reflog until
> they expire (by default 30 days I think?) you have more than enough
> time to decide if you want to keep the work - which you can do very
> easily by assigning it a name. If the default time is not long enough,
> simply extend it in your config
> git config gc.reflogExpire = 10000 years <- syntax might not be correct
Thanks for your post, but, again, my point is that Git does not support
anonymous branching as part of a normal workflow. Having X days until
detonation is hardly part of a normal workflow (even if X can be changed,
as you suggest).
Anyway, this thread's really going off topic, so I'll try not to reply
again.
^ permalink raw reply
* Re: More Beginning Git Questions
From: Andrew Ardill @ 2011-09-26 1:34 UTC (permalink / raw)
To: tactical; +Cc: git
In-Reply-To: <1aec7c1qq0n56.sxybjnsj6ngr$.dlg@40tude.net>
On 26 September 2011 10:56, tactical <a5158017@nepwk.com> wrote:
> Konstantin Khomoutov wrote:
>
>>>>> From what I read, detached heads are subject to garbage collection.
>>>>
>>>> No, HEAD is protected against garbage collecting. To be sure you
>>>> should name a branch when switching branches, though reflog would
>>>> protect you for 30 days (by default) even if you don't do that.
>>>
>>> So Git doesn't really support anonymous branching as part of a normal
>>> workflow.
>>
>> I perceive a certain logical fallacy here: you cannot switch between
>> anything anonymous because to switch, you should somehow identify
>> something to switch to--a name in whatever sense we put into this word.
>
> In Mercurial, you can just update to a particular changeset (and you
> identify that changeset by repository-local revision number or globally
> unique ID) and then commit again. The point is that there's no need to
> give a label to a head in Mercurial (although you can if you want to, using
> Mercurial bookmarks, which are basically the same as what Git uses).
>
> Here's an example of anonymous branching:
>
> c:\test>hg init
>
> c:\test>echo test>foo
>
> c:\test>hg commit --addremove -m initial
> adding foo
>
> c:\test>echo first>>foo
>
> c:\test>hg commit -m first
>
> c:\test>hg log
> changeset: 1:3e895ec28d6c
> tag: tip
> user: tactical
> date: Mon Sep 26 01:39:46 2011 +0100
> summary: first
>
> changeset: 0:b51644bb3450
> user: tactical
> date: Mon Sep 26 01:39:40 2011 +0100
> summary: initial
>
> c:\test>hg update 0
> 1 files updated, 0 files merged, 0 files removed, 0 files unresolved
>
> c:\test>echo second>>foo
>
> c:\test>hg commit -m second
> created new head
>
> c:\test>hg glog
> @ changeset: 2:35c82a7e7de1
> | tag: tip
> | parent: 0:b51644bb3450
> | user: tactical
> | date: Mon Sep 26 01:40:10 2011 +0100
> | summary: second
> |
> | o changeset: 1:3e895ec28d6c
> |/ user: tactical
> | date: Mon Sep 26 01:39:46 2011 +0100
> | summary: first
> |
> o changeset: 0:b51644bb3450
> user: tactical
> date: Mon Sep 26 01:39:40 2011 +0100
> summary: initial
>
> I now have two anonymous branches, and these will never be garbage
> collected. I can easily update to either branch with "hg update 1" or "hg
> update 2" (or "hg update 0" again, if i want to create yet another
> anonymous branch).
>
>> As I understand, by switching between branches in Mercurial you mean
>> switching between directories with clones;
>
> No. Clones are a different topic.
>
>> As to branches, they do have names in Git but they are very loosely
>> coupled with their names: tag a tip of some branch (to still have a
>> handle on that tip commit) then delete that branch--there will be no
>> traces of that branch's name left, the branch's name is not encoded in
>> its history in any way.
>
> Git branch names are basically the same as Mercurial bookmarks. The
> difference is that in Mercurial you don't *have* to use bookmarks.
>
>> The branch names is just a way to not mess with
>> SHA-1 names of commits (and to have references to those commits to keep
>> them out of consideration for garbage collection).
>> Hence the idea to demand support for anonymous branches in Git's model
>> is just unfounded.
>
> I think it's simply a weakness of Git. There are zero problems with
> anonymous branching in Mercurial, and it's a very powerful and simple
> system.
>
I am no expert on this, however git can (of course) do 'anonymous
branching' just as simply as mercurial, with one caveat; for most
intents and purposes (as far as I have seen/heard discussed) git and
mercurial are homomorphic, and in the situations they are not git is
the more general system.
The flow that you are using for anonymous branching in mercurial is
easily reproducible in git, using detached heads. Checkout a revision
(note: not a ref)
git checkout HEAD@{1}
hack + commit. Repeat as often as you like. Your concern is that these
will (eventually) be garbage collected. Again, I am not an expert in
this so please correct me if I have this incorrect, but the man page
for gc says:
git-gc tries very hard to be safe about the garbage it collects. In
particular, it will keep not only objects referenced by your current
set of branches and tags, but also objects referenced by the index,
remote tracking branches, refs saved by git-filter-branch in
refs/original/, or reflogs (which may references commits in branches
that were later amended or rewound).
As any commits you make in a detached state are in the reflog until
they expire (by default 30 days I think?) you have more than enough
time to decide if you want to keep the work - which you can do very
easily by assigning it a name. If the default time is not long enough,
simply extend it in your config
git config gc.reflogExpire = 10000 years <- syntax might not be correct
The reason this is not true by default is that _most_ people don't
work exclusively in anonymous branches, and it is far nicer
performance wise to have git clean up for you.
So you don't *have* to use branches in git - they just make it much
easier to get around. They cost practically nothing to use, so I don't
really understand why you wouldn't want to for anything other than
just a quick throwaway test or scratch idea.
I hope that clears it up a little.
Andrew
^ permalink raw reply
* Re: More Beginning Git Questions
From: tactical @ 2011-09-26 0:56 UTC (permalink / raw)
To: git
In-Reply-To: <20110926003447.GG10955@localhost.localdomain>
Konstantin Khomoutov wrote:
>>>> From what I read, detached heads are subject to garbage collection.
>>>
>>> No, HEAD is protected against garbage collecting. To be sure you
>>> should name a branch when switching branches, though reflog would
>>> protect you for 30 days (by default) even if you don't do that.
>>
>> So Git doesn't really support anonymous branching as part of a normal
>> workflow.
>
> I perceive a certain logical fallacy here: you cannot switch between
> anything anonymous because to switch, you should somehow identify
> something to switch to--a name in whatever sense we put into this word.
In Mercurial, you can just update to a particular changeset (and you
identify that changeset by repository-local revision number or globally
unique ID) and then commit again. The point is that there's no need to
give a label to a head in Mercurial (although you can if you want to, using
Mercurial bookmarks, which are basically the same as what Git uses).
Here's an example of anonymous branching:
c:\test>hg init
c:\test>echo test>foo
c:\test>hg commit --addremove -m initial
adding foo
c:\test>echo first>>foo
c:\test>hg commit -m first
c:\test>hg log
changeset: 1:3e895ec28d6c
tag: tip
user: tactical
date: Mon Sep 26 01:39:46 2011 +0100
summary: first
changeset: 0:b51644bb3450
user: tactical
date: Mon Sep 26 01:39:40 2011 +0100
summary: initial
c:\test>hg update 0
1 files updated, 0 files merged, 0 files removed, 0 files unresolved
c:\test>echo second>>foo
c:\test>hg commit -m second
created new head
c:\test>hg glog
@ changeset: 2:35c82a7e7de1
| tag: tip
| parent: 0:b51644bb3450
| user: tactical
| date: Mon Sep 26 01:40:10 2011 +0100
| summary: second
|
| o changeset: 1:3e895ec28d6c
|/ user: tactical
| date: Mon Sep 26 01:39:46 2011 +0100
| summary: first
|
o changeset: 0:b51644bb3450
user: tactical
date: Mon Sep 26 01:39:40 2011 +0100
summary: initial
I now have two anonymous branches, and these will never be garbage
collected. I can easily update to either branch with "hg update 1" or "hg
update 2" (or "hg update 0" again, if i want to create yet another
anonymous branch).
> As I understand, by switching between branches in Mercurial you mean
> switching between directories with clones;
No. Clones are a different topic.
> As to branches, they do have names in Git but they are very loosely
> coupled with their names: tag a tip of some branch (to still have a
> handle on that tip commit) then delete that branch--there will be no
> traces of that branch's name left, the branch's name is not encoded in
> its history in any way.
Git branch names are basically the same as Mercurial bookmarks. The
difference is that in Mercurial you don't *have* to use bookmarks.
> The branch names is just a way to not mess with
> SHA-1 names of commits (and to have references to those commits to keep
> them out of consideration for garbage collection).
> Hence the idea to demand support for anonymous branches in Git's model
> is just unfounded.
I think it's simply a weakness of Git. There are zero problems with
anonymous branching in Mercurial, and it's a very powerful and simple
system.
^ permalink raw reply
* Re: More Beginning Git Questions
From: Konstantin Khomoutov @ 2011-09-26 0:34 UTC (permalink / raw)
To: tactical; +Cc: git
In-Reply-To: <1ttmqsxtaj98i$.hv6s5shjeugr.dlg@40tude.net>
On Sun, Sep 25, 2011 at 10:07:24PM +0100, tactical wrote:
[...]
> > I think you can use detached HEAD for that, at least when working on
> > one issue at a time (you have to name branch when switching to some
> > other work).
>
> But in Mercurial I can switch between anonymous branches as much as I like
> without anything ever being deleted.
>
> >> From what I read, detached heads are subject to garbage collection.
> >
> > No, HEAD is protected against garbage collecting. To be sure you
> > should name a branch when switching branches, though reflog would
> > protect you for 30 days (by default) even if you don't do that.
>
> So Git doesn't really support anonymous branching as part of a normal
> workflow.
I perceive a certain logical fallacy here: you cannot switch between
anything anonymous because to switch, you should somehow identify
something to switch to--a name in whatever sense we put into this word.
As I understand, by switching between branches in Mercurial you mean
switching between directories with clones; if so, you had had to name
those directories when they were created.
As to branches, they do have names in Git but they are very loosely
coupled with their names: tag a tip of some branch (to still have a
handle on that tip commit) then delete that branch--there will be no
traces of that branch's name left, the branch's name is not encoded in
its history in any way. The branch names is just a way to not mess with
SHA-1 names of commits (and to have references to those commits to keep
them out of consideration for garbage collection).
Hence the idea to demand support for anonymous branches in Git's model
is just unfounded.
^ 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