* bash_completion outside repo
From: james bardin @ 2009-09-10 15:13 UTC (permalink / raw)
To: git
Hi,
I'm making a git rpm for our site, and I'm getting an error with
bash_completion on RHEL/CentOS 5.
When outside a repo, any completion causes git to spit out
fatal: error processing config file(s)
This is 1.6.4.2 using the contrib bash completion file
Thanks
-jim
^ permalink raw reply
* Re: [PATCH] Introduce <branch>@{tracked} as shortcut to the tracked branch
From: Jeff King @ 2009-09-10 14:26 UTC (permalink / raw)
To: Johannes Schindelin
Cc: Junio C Hamano, Björn Steinbrink, Michael J Gruber,
Pete Wyckoff, git
In-Reply-To: <20090910141618.GB4942@coredump.intra.peff.net>
On Thu, Sep 10, 2009 at 10:16:18AM -0400, Jeff King wrote:
> And we may want to add a test for HEAD, as well.
>
> Also, I seem to be able to stimulate a segfault on a detached HEAD, but
> I haven't investigated it yet.
Found it. We should probably squash this in:
diff --git a/sha1_name.c b/sha1_name.c
index a886846..ef4ec11 100644
--- a/sha1_name.c
+++ b/sha1_name.c
@@ -276,7 +276,7 @@ static char *substitute_branch_name(const char **string, int *len)
struct branch *tracking = branch_get(*ref ? ref : NULL);
free(ref);
- if (tracking->merge && tracking->merge[0]->dst) {
+ if (tracking && tracking->merge && tracking->merge[0]->dst) {
*string = xstrdup(tracking->merge[0]->dst);
*len = strlen(*string);
return (char *)*string;
diff --git a/t/t1506-rev-parse-tracked.sh b/t/t1506-rev-parse-tracked.sh
index 89193e1..2be5b75 100755
--- a/t/t1506-rev-parse-tracked.sh
+++ b/t/t1506-rev-parse-tracked.sh
@@ -61,4 +61,15 @@ test_expect_success '<branch>@{t}@{1} resolves correctly' '
test 5 = $(commit_subject my-side@{t}@{1})
'
+test_expect_success 'HEAD@{t} dereferences HEAD' '
+ (cd clone && git checkout master) &&
+ test refs/remotes/origin/master = "$(full_name HEAD@{t})"
+'
+
+test_expect_success 'HEAD@{t} and @{t} on detached HEAD fail' '
+ (cd clone && git checkout master^0) &&
+ test_must_fail full_name @{t} &&
+ test_must_fail full_name HEAD@{t}
+'
+
test_done
^ permalink raw reply related
* Re: [PATCH] Introduce <branch>@{tracked} as shortcut to the tracked branch
From: Michael J Gruber @ 2009-09-10 14:17 UTC (permalink / raw)
To: Johannes Schindelin
Cc: Johan Herland, git, Junio C Hamano, Jeff King,
Björn Steinbrink, Pete Wyckoff
In-Reply-To: <alpine.DEB.1.00.0909101534440.8306@pacific.mpi-cbg.de>
Johannes Schindelin venit, vidit, dixit 10.09.2009 15:35:
> Hi,
>
> On Thu, 10 Sep 2009, Johan Herland wrote:
>
>> I think I vote for the second option, renaming 'git branch --track'
>> to 'git branch --upstream', and s/@{tracked}/@{upstream}/.
>
> That does not make any sense, as that --track is to be understood as a
> verb. How do you "upstream a branch"?
Well, that brunch also got its granma wrong tho his speeling is right ;)
Seriously: In
git branch --track branch1 branch2
who tracks whom if you read "--track" as a verb?
So, "--track" can only be understood as an attribute to the main (first)
argument, saying it's tracking something. Just as --upstream could be
read as an attribute meaning "has an upstream".
(Note also how different this is from how -b works for checkout, -b
actually taking an argument: git checkout -b branch1 branch2)
Cheers,
Michael
^ permalink raw reply
* Re: [PATCH] Introduce <branch>@{tracked} as shortcut to the tracked branch
From: Jeff King @ 2009-09-10 14:16 UTC (permalink / raw)
To: Johannes Schindelin
Cc: Junio C Hamano, Björn Steinbrink, Michael J Gruber,
Pete Wyckoff, git
In-Reply-To: <alpine.DEB.1.00.0909101135590.8306@pacific.mpi-cbg.de>
On Thu, Sep 10, 2009 at 11:36:42AM +0200, Johannes Schindelin wrote:
> diff --git a/Documentation/git-rev-parse.txt b/Documentation/git-rev-parse.txt
> index 82045a2..09a2145 100644
> --- a/Documentation/git-rev-parse.txt
> +++ b/Documentation/git-rev-parse.txt
> @@ -231,6 +231,10 @@ when you run 'git-merge'.
> * The special construct '@\{-<n>\}' means the <n>th branch checked out
> before the current one.
>
> +* The suffix '@{tracked}' to a ref (short form 'blabla@{t}') refers to
> + the branch tracked by that ref. If no ref was specified, it means the
> + branch tracked by the current branch.
> +
It looks like the code dereferences symbolic refs when doing the lookup
(so HEAD@{t} will find the upstream of the current branch), which I
think is the best thing to do. However, that does make it behave
slightly differently than HEAD@{2.minutes.ago}, so it may be worth
adding a sentence to this paragraph like:
If the ref is a symbolic ref, it is dereferenced before searching
for the upstream ref.
And we may want to add a test for HEAD, as well.
Also, I seem to be able to stimulate a segfault on a detached HEAD, but
I haven't investigated it yet.
-Peff
^ permalink raw reply
* [PATCH v3 3/3] INSTALL: Describe dependency knobs from Makefile
From: Brian Gernhardt @ 2009-09-10 14:12 UTC (permalink / raw)
To: Git List; +Cc: Junio C Hamano
In-Reply-To: <7vpra0hcd3.fsf@alter.siamese.dyndns.org>
We said that some of our dependencies were optional, but didn't say
how to turn them off. Add information for that and mention where to
save the options close to the top of the file.
Also, standardize on both using quotes for the names of the dependencies
and tabs for indentation of the list.
Signed-off-by: Brian Gernhardt <brian@gernhardtsoftware.com>
---
Junio C Hamano <gitster@pobox.com> wrote:
> I did not like calling "make variables" "options", and also it was unclear
> what good these "options" are for. How about...
Sounds good. Would have sent this out yesterday, but I ran out of tuits.
INSTALL | 38 ++++++++++++++++++++++++--------------
1 files changed, 24 insertions(+), 14 deletions(-)
diff --git a/INSTALL b/INSTALL
index 7ab2580..69c97b2 100644
--- a/INSTALL
+++ b/INSTALL
@@ -13,6 +13,10 @@ that uses $prefix, the built results have some paths encoded,
which are derived from $prefix, so "make all; make prefix=/usr
install" would not work.
+There are many options that can be configured in the makefile using either
+command line defines or a config.mak file. These options are documented at
+the beginning of the Makefile.
+
Alternatively you can use autoconf generated ./configure script to
set up install paths (via config.mak.autogen), so you can write instead
@@ -48,7 +52,9 @@ Issues of note:
export GIT_EXEC_PATH PATH GITPERLLIB
- Git is reasonably self-sufficient, but does depend on a few external
- programs and libraries:
+ programs and libraries. Git can be used without most of them by adding
+ the approriate "NO_<LIBRARY>=YesPlease" to the make command line or
+ config.mak file.
- "zlib", the compression library. Git won't build without it.
@@ -59,25 +65,29 @@ Issues of note:
- "Perl" is needed to use some of the features (e.g. preparing a
partial commit using "git add -i/-p", interacting with svn
- repositories with "git svn").
+ repositories with "git svn"). If you can live without these, use
+ NO_PERL.
- - "openssl". Unless you specify otherwise, you'll get the SHA1
- library from here.
+ - "openssl" library is used by git-imap-send to use IMAP over SSL.
+ If you don't need it, use NO_OPENSSL.
- If you don't have openssl, you can use one of the SHA1 libraries
- that come with git (git includes one inspired by Mozilla's and a
- PowerPC optimized one too - see the Makefile).
+ By default, git uses OpenSSL for SHA1 but it will use it's own
+ library (inspired by Mozilla's) with either NO_OPENSSL or
+ BLK_SHA1. Also included is a version optimized for PowerPC
+ (PPC_SHA1).
- - libcurl library; git-http-fetch and git-fetch use them. You
+ - "libcurl" library is used by git-http-fetch and git-fetch. You
might also want the "curl" executable for debugging purposes.
- If you do not use http transfer, you are probably OK if you
- do not have them.
+ If you do not use http:// or https:// repositories, you do not
+ have to have them (use NO_CURL).
- - expat library; git-http-push uses it for remote lock
- management over DAV. Similar to "curl" above, this is optional.
+ - "expat" library; git-http-push uses it for remote lock
+ management over DAV. Similar to "curl" above, this is optional
+ (with NO_EXPAT).
- - "wish", the Tcl/Tk windowing shell is used in gitk to show the
- history graphically, and in git-gui.
+ - "wish", the Tcl/Tk windowing shell is used in gitk to show the
+ history graphically, and in git-gui. If you don't want gitk or
+ git-gui, you can use NO_TCLTK.
- Some platform specific issues are dealt with Makefile rules,
but depending on your specific installation, you may not
--
1.6.4.2.420.g30ecf
^ permalink raw reply related
* Re: [PATCHv5 00/14] git notes
From: Geert Bosch @ 2009-09-10 14:12 UTC (permalink / raw)
To: Michael J Gruber
Cc: Johan Herland, gitster, git, Johannes.Schindelin, trast, tavestbo,
chriscool, spearce
In-Reply-To: <4AA9089D.3000507@drmicha.warpmail.net>
On Sep 10, 2009, at 10:09, Michael J Gruber wrote:
> It's not separate, that's the point. They're stored as objects in
> trees,
> just like anything else. The discussion about the structure is about
> how
> to organize the tree structure, not actual subdirectories under .git/.
Arghh, sorry for the noise.
-Geert
^ permalink raw reply
* Re: [PATCHv5 00/14] git notes
From: Michael J Gruber @ 2009-09-10 14:09 UTC (permalink / raw)
To: Geert Bosch
Cc: Johan Herland, gitster, git, Johannes.Schindelin, trast, tavestbo,
chriscool, spearce
In-Reply-To: <8445CEA3-AC5D-4A38-9C73-B4E14BD4864C@adacore.com>
Geert Bosch venit, vidit, dixit 10.09.2009 16:00:
> On Sep 7, 2009, at 22:26, Johan Herland wrote:
...
>
> Hi Johan,
>
> I've been following this series with some interest, and am curious
> why notes need to be stored in a separate data structure from regular
> objects. Note that I'm not questioning the design (and certainly would
It's not separate, that's the point. They're stored as objects in trees,
just like anything else. The discussion about the structure is about how
to organize the tree structure, not actual subdirectories under .git/.
> not want to, this late in the process), rather I'd like to learn
> about the reasons.
>
> I've wondered about this as well in the context of refs, reflog and
> git config. In a completely unified model, every change to the
> repository (except for the index, pack indices and working directory)
> would be a commit of the .git/ directory (again excluding indices).
> One of the advantages (besides allowing configuration management
> of the repository itself in addition to its contents) would be that
> no locking is ever required.
...and one of the disadvantages that you're not in control of your
config any more, if you pull from upstream. config and reflog are
something inherently private and local. The reflog does not even make
sense other than in a local (per repo) context.
For the config, one may think up a solution where parts of config are
shared (by storing them as objects and referencing them) and git asks
you before changing anything on pull/fetch. In a sense git submodule
does that already.
Cheers,
Michael
^ permalink raw reply
* Re: [PATCHv5 00/14] git notes
From: Geert Bosch @ 2009-09-10 14:00 UTC (permalink / raw)
To: Johan Herland
Cc: gitster, git, Johannes.Schindelin, trast, tavestbo, git,
chriscool, spearce
In-Reply-To: <1252376822-6138-1-git-send-email-johan@herland.net>
On Sep 7, 2009, at 22:26, Johan Herland wrote:
> Yet another iteration of the 'git notes' feature. Rebased on top of
> 'next':
> - Patches 1-9 are unchanged from (patches 1-7, 11-12 of) the last
> iteration.
> - Patch 10 teaches the notes code to free its data structures on
> request.
> - Patch 11 introduces the 16-tree notes lookup code that handles
> SHA1-based
> fanout schemes. This is pretty much unchanged from patch 8 in the
> previous
> iteration.
> - Patch 12 adds selftests that verify correct parsing of notes trees
> with
> various SHA1-based fanouts.
> - Patch 13 introduces a flexible parser for a variety of date-based
> and
> SHA1-based fanout schemes. This is the interesting part, as far as
> this
> iteration is concerned.
> - Patch 14 adds selftests that verify correct parsing of notes trees
> with
> various date-based fanouts.
>
> Note that the series does not yet include code for _writing_ notes
> into a
> suitably structured notes tree. That will be done in a later
> iteration.
>
> I have some performance numbers that I will send in a separate email.
Hi Johan,
I've been following this series with some interest, and am curious
why notes need to be stored in a separate data structure from regular
objects. Note that I'm not questioning the design (and certainly would
not want to, this late in the process), rather I'd like to learn
about the reasons.
I've wondered about this as well in the context of refs, reflog and
git config. In a completely unified model, every change to the
repository (except for the index, pack indices and working directory)
would be a commit of the .git/ directory (again excluding indices).
One of the advantages (besides allowing configuration management
of the repository itself in addition to its contents) would be that
no locking is ever required.
This would be just an implementation detail without necessarily
affecting the user interface other than direct inspection/modification
of the .git directory, which is a similar to the move to packed refs.
Again, I'm not proposing to change anything, just wondering about
design rationale.
-Geert
^ permalink raw reply
* Re: [PATCH] Introduce <branch>@{tracked} as shortcut to the tracked branch
From: Johannes Schindelin @ 2009-09-10 13:35 UTC (permalink / raw)
To: Johan Herland
Cc: git, Michael J Gruber, Junio C Hamano, Jeff King,
Björn Steinbrink, Pete Wyckoff
In-Reply-To: <200909101429.30190.johan@herland.net>
Hi,
On Thu, 10 Sep 2009, Johan Herland wrote:
> I think I vote for the second option, renaming 'git branch --track'
> to 'git branch --upstream', and s/@{tracked}/@{upstream}/.
That does not make any sense, as that --track is to be understood as a
verb. How do you "upstream a branch"?
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] Introduce <branch>@{tracked} as shortcut to the tracked branch
From: Johan Herland @ 2009-09-10 12:29 UTC (permalink / raw)
To: git
Cc: Michael J Gruber, Johannes Schindelin, Junio C Hamano, Jeff King,
Björn Steinbrink, Pete Wyckoff
In-Reply-To: <4AA8DC23.6050500@drmicha.warpmail.net>
On Thursday 10 September 2009, Michael J Gruber wrote:
> Johan Herland venit, vidit, dixit 10.09.2009 12:18:
> > On Thursday 10 September 2009, Michael J Gruber wrote:
> >> Johannes Schindelin venit, vidit, dixit 10.09.2009 11:36:
> >>> Often, it is quite interesting to inspect the branch tracked by a
> >>> given branch. This patch introduces a nice notation to get at
> >>> the tracked branch: '<branch>@{tracked}' can be used to access
> >>> that tracked branch.
> >>>
> >>> A special shortcut '@{tracked}' refers to the branch tracked by
> >>> the current branch.
> >>
> >> Sorry, I didn't know the name of the long form was up for
> >> discussion. But it should certainly coincide with the key which
> >> for-each-ref uses, shouldn't it? I don't care whether tracked or
> >> upstream, but for-each-ref's "upstream" has set the precedent.
> >
> > ...and 'git branch --track' set an even earlier precedent...
>
> an unfortunate one, yes. It brings us back to an old discussion. The
> consensus was what's in the glossary:
[snip]
> Maybe this is a good time to either
>
> - change the definition of "tracking branch" (to one having an
> upstream which is in refs/remotes/; and call "remote upbranch" what's
> in refs/remotes/) or
> - rename the option and output of git checkout -b/git branch --track.
>
> Accordingly, either tracked or something else (such as upstream)
> would be appropriate for the for-each-ref key and the ref specifier.
Sure, as someone else already stated, I don't care too much what it's
named, as long as the naming is consistent across all of git. We do
have an unforunate name clash between remote-tracking branches (i.e.
branches under refs/remotes/) and 'tracking' branches (i.e. 'git
branch --track') [1], and I believe 1.7.0 would be a nice opportunity
to clean this up.
I think I vote for the second option, renaming 'git branch --track'
to 'git branch --upstream', and s/@{tracked}/@{upstream}/.
Have fun! :)
...Johan
[1]: And also tracked and untracked files, although I believe that is
unambiguous in most cases.
--
Johan Herland, <johan@herland.net>
www.herland.net
^ permalink raw reply
* Re: [PATCH] Introduce <branch>@{tracked} as shortcut to the tracked branch
From: Jeff King @ 2009-09-10 11:11 UTC (permalink / raw)
To: Johan Herland
Cc: git, Michael J Gruber, Johannes Schindelin, Junio C Hamano,
Björn Steinbrink, Pete Wyckoff
In-Reply-To: <200909101218.06789.johan@herland.net>
On Thu, Sep 10, 2009 at 12:18:06PM +0200, Johan Herland wrote:
> > > A special shortcut '@{tracked}' refers to the branch tracked by the
> > > current branch.
> >
> > Sorry, I didn't know the name of the long form was up for discussion.
> > But it should certainly coincide with the key which for-each-ref
> > uses, shouldn't it? I don't care whether tracked or upstream, but
> > for-each-ref's "upstream" has set the precedent.
>
> ...and 'git branch --track' set an even earlier precedent...
FWIW, that came about from this discussion:
http://article.gmane.org/gmane.comp.version-control.git/115765
-Peff
^ permalink raw reply
* Re: [PATCH] Introduce <branch>@{tracked} as shortcut to the tracked branch
From: Michael J Gruber @ 2009-09-10 10:59 UTC (permalink / raw)
To: Johan Herland
Cc: git, Michael J Gruber, Johannes Schindelin, Junio C Hamano,
Jeff King, Björn Steinbrink, Pete Wyckoff
In-Reply-To: <200909101218.06789.johan@herland.net>
Johan Herland venit, vidit, dixit 10.09.2009 12:18:
> On Thursday 10 September 2009, Michael J Gruber wrote:
>> Johannes Schindelin venit, vidit, dixit 10.09.2009 11:36:
>>> Often, it is quite interesting to inspect the branch tracked by a
>>> given branch. This patch introduces a nice notation to get at the
>>> tracked branch: '<branch>@{tracked}' can be used to access that
>>> tracked branch.
>>>
>>> A special shortcut '@{tracked}' refers to the branch tracked by the
>>> current branch.
>>
>> Sorry, I didn't know the name of the long form was up for discussion.
>> But it should certainly coincide with the key which for-each-ref
>> uses, shouldn't it? I don't care whether tracked or upstream, but
>> for-each-ref's "upstream" has set the precedent.
>
> ...and 'git branch --track' set an even earlier precedent...
an unfortunate one, yes. It brings us back to an old discussion. The
consensus was what's in the glossary:
tracking branch
A regular git branch that is used to follow changes from
another repository. A tracking branch should
not contain direct modifications or have local commits made
to it. A tracking branch can usually be
identified as the right-hand-side ref in a Pull: refspec.
I.e., a tracking branch is something under refs/remotes/ (usually; I'll
use that simplification).
If I checkout -b myworkonit refs/remotes/origin/theirstuff then
myworkonit *does not track* origin/theirstuff according to the glossary
(but git checkout says so, unfortunately, and the option is named
likewise); rather, it has origin/theirstuff as its upstream.
In fact, refs/remotes/origin/theirstuff tracks whatever the name is on
the left hand side of the correspondig fetch refspec.
Maybe this is a good time to either
- change the definition of "tracking branch" (to one having an upstream
which is in refs/remotes/; and call "remote upbranch" what's in
refs/remotes/) or
- rename the option and output of git checkout -b/git branch --track.
Accordingly, either tracked or something else (such as upstream) would
be appropriate for the for-each-ref key and the ref specifier.
Cheers,
Michael
^ permalink raw reply
* Re: [PATCH] Introduce <branch>@{tracked} as shortcut to the tracked branch
From: Johan Herland @ 2009-09-10 10:18 UTC (permalink / raw)
To: git
Cc: Michael J Gruber, Johannes Schindelin, Junio C Hamano, Jeff King,
Björn Steinbrink, Pete Wyckoff
In-Reply-To: <4AA8CA88.9060802@drmicha.warpmail.net>
On Thursday 10 September 2009, Michael J Gruber wrote:
> Johannes Schindelin venit, vidit, dixit 10.09.2009 11:36:
> > Often, it is quite interesting to inspect the branch tracked by a
> > given branch. This patch introduces a nice notation to get at the
> > tracked branch: '<branch>@{tracked}' can be used to access that
> > tracked branch.
> >
> > A special shortcut '@{tracked}' refers to the branch tracked by the
> > current branch.
>
> Sorry, I didn't know the name of the long form was up for discussion.
> But it should certainly coincide with the key which for-each-ref
> uses, shouldn't it? I don't care whether tracked or upstream, but
> for-each-ref's "upstream" has set the precedent.
...and 'git branch --track' set an even earlier precedent...
...Johan
--
Johan Herland, <johan@herland.net>
www.herland.net
^ permalink raw reply
* Re: [PATCH] Introduce <branch>@{tracked} as shortcut to the tracked branch
From: Johannes Schindelin @ 2009-09-10 10:14 UTC (permalink / raw)
To: Michael J Gruber
Cc: Junio C Hamano, Jeff King, Björn Steinbrink, Pete Wyckoff,
git
In-Reply-To: <4AA8CA88.9060802@drmicha.warpmail.net>
Hi,
On Thu, 10 Sep 2009, Michael J Gruber wrote:
> Johannes Schindelin venit, vidit, dixit 10.09.2009 11:36:
> >
> > Often, it is quite interesting to inspect the branch tracked by a given
> > branch. This patch introduces a nice notation to get at the tracked
> > branch: '<branch>@{tracked}' can be used to access that tracked branch.
> >
> > A special shortcut '@{tracked}' refers to the branch tracked by the
> > current branch.
>
> Sorry, I didn't know the name of the long form was up for discussion.
> But it should certainly coincide with the key which for-each-ref uses,
> shouldn't it? I don't care whether tracked or upstream, but
> for-each-ref's "upstream" has set the precedent.
You're right.
sed -i -e 's/@{tracked}/@{upstream}/g' -e 's/@{t}/@{u}/g' $PATCH
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] Introduce <branch>@{tracked} as shortcut to the tracked branch
From: Michael J Gruber @ 2009-09-10 9:44 UTC (permalink / raw)
To: Johannes Schindelin
Cc: Junio C Hamano, Jeff King, Björn Steinbrink, Pete Wyckoff,
git
In-Reply-To: <alpine.DEB.1.00.0909101135590.8306@pacific.mpi-cbg.de>
Johannes Schindelin venit, vidit, dixit 10.09.2009 11:36:
>
> Often, it is quite interesting to inspect the branch tracked by a given
> branch. This patch introduces a nice notation to get at the tracked
> branch: '<branch>@{tracked}' can be used to access that tracked branch.
>
> A special shortcut '@{tracked}' refers to the branch tracked by the
> current branch.
Sorry, I didn't know the name of the long form was up for discussion.
But it should certainly coincide with the key which for-each-ref uses,
shouldn't it? I don't care whether tracked or upstream, but
for-each-ref's "upstream" has set the precedent.
>
> Suggested by Pasky.
>
> The syntax was suggested by Junio.
>
> Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
> ---
>
> I decided that I like @{tracked} better than @{upstream} (which
> reads to me more like the upstream _repository_), but hey, I made
> the code flexible enough to change that at a whim.
>
> Documentation/git-rev-parse.txt | 4 ++
> sha1_name.c | 37 ++++++++++++++++++++--
> t/t1506-rev-parse-tracked.sh | 64 +++++++++++++++++++++++++++++++++++++++
> 3 files changed, 102 insertions(+), 3 deletions(-)
> create mode 100755 t/t1506-rev-parse-tracked.sh
>
> diff --git a/Documentation/git-rev-parse.txt b/Documentation/git-rev-parse.txt
> index 82045a2..09a2145 100644
> --- a/Documentation/git-rev-parse.txt
> +++ b/Documentation/git-rev-parse.txt
> @@ -231,6 +231,10 @@ when you run 'git-merge'.
> * The special construct '@\{-<n>\}' means the <n>th branch checked out
> before the current one.
>
> +* The suffix '@{tracked}' to a ref (short form 'blabla@{t}') refers to
> + the branch tracked by that ref. If no ref was specified, it means the
> + branch tracked by the current branch.
> +
> * A suffix '{caret}' to a revision parameter means the first parent of
> that commit object. '{caret}<n>' means the <n>th parent (i.e.
> 'rev{caret}'
> diff --git a/sha1_name.c b/sha1_name.c
> index 44bb62d..a886846 100644
> --- a/sha1_name.c
> +++ b/sha1_name.c
> @@ -5,6 +5,7 @@
> #include "blob.h"
> #include "tree-walk.h"
> #include "refs.h"
> +#include "remote.h"
>
> static int find_short_object_filename(int len, const char *name, unsigned char *sha1)
> {
> @@ -238,9 +239,24 @@ static int ambiguous_path(const char *path, int len)
> return slash;
> }
>
> +static inline int tracked_suffix(const char *string, int len)
> +{
> + const char *suffix[] = { "@{tracked}", "@{t}" };
> + int i;
> +
> + for (i = 0; i < ARRAY_SIZE(suffix); i++) {
> + int suffix_len = strlen(suffix[i]);
> + if (len >= suffix_len && !memcmp(string + len - suffix_len,
> + suffix[i], suffix_len))
> + return suffix_len;
> + }
> + return 0;
> +}
> +
> /*
> * *string and *len will only be substituted, and *string returned (for
> - * later free()ing) if the string passed in is of the form @{-<n>}.
> + * later free()ing) if the string passed in is of the form @{-<n>} or
> + * of the form <branch>@{tracked}.
> */
> static char *substitute_branch_name(const char **string, int *len)
> {
> @@ -254,6 +270,19 @@ static char *substitute_branch_name(const char **string, int *len)
> return (char *)*string;
> }
>
> + ret = tracked_suffix(*string, *len);
> + if (ret) {
> + char *ref = xstrndup(*string, *len - ret);
> + struct branch *tracking = branch_get(*ref ? ref : NULL);
> +
> + free(ref);
> + if (tracking->merge && tracking->merge[0]->dst) {
> + *string = xstrdup(tracking->merge[0]->dst);
> + *len = strlen(*string);
> + return (char *)*string;
> + }
> + }
> +
> return NULL;
> }
>
> @@ -340,8 +369,10 @@ static int get_sha1_basic(const char *str, int len, unsigned char *sha1)
> if (len && str[len-1] == '}') {
> for (at = len-2; at >= 0; at--) {
> if (str[at] == '@' && str[at+1] == '{') {
> - reflog_len = (len-1) - (at+2);
> - len = at;
> + if (!tracked_suffix(str + at, len - at)) {
> + reflog_len = (len-1) - (at+2);
> + len = at;
> + }
> break;
> }
> }
> diff --git a/t/t1506-rev-parse-tracked.sh b/t/t1506-rev-parse-tracked.sh
> new file mode 100755
> index 0000000..89193e1
> --- /dev/null
> +++ b/t/t1506-rev-parse-tracked.sh
> @@ -0,0 +1,64 @@
> +#!/bin/sh
> +
> +test_description='test <branch>@{tracked} syntax'
> +
> +. ./test-lib.sh
> +
> +
> +test_expect_success 'setup' '
> +
> + test_commit 1 &&
> + git checkout -b side &&
> + test_commit 2 &&
> + git checkout master &&
> + git clone . clone &&
> + test_commit 3 &&
> + (cd clone &&
> + test_commit 4 &&
> + git branch --track my-side origin/side)
> +
> +'
> +
> +full_name () {
> + (cd clone &&
> + git rev-parse --symbolic-full-name "$@")
> +}
> +
> +commit_subject () {
> + (cd clone &&
> + git show -s --pretty=format:%s "$@")
> +}
> +
> +test_expect_success '@{tracked} resolves to correct full name' '
> + test refs/remotes/origin/master = "$(full_name @{tracked})"
> +'
> +
> +test_expect_success '@{t} resolves to correct full name' '
> + test refs/remotes/origin/master = "$(full_name @{t})"
> +'
> +
> +test_expect_success 'my-side@{tracked} resolves to correct full name' '
> + test refs/remotes/origin/side = "$(full_name my-side@{t})"
> +'
> +
> +test_expect_success 'my-side@{t} resolves to correct commit' '
> + git checkout side &&
> + test_commit 5 &&
> + (cd clone && git fetch) &&
> + test 2 = "$(commit_subject my-side)" &&
> + test 5 = "$(commit_subject my-side@{t})"
> +'
> +
> +test_expect_success 'not-tracking@{t} fails' '
> + test_must_fail full_name non-tracking@{t} &&
> + (cd clone && git checkout --no-track -b non-tracking) &&
> + test_must_fail full_name non-tracking@{t}
> +'
> +
> +test_expect_success '<branch>@{t}@{1} resolves correctly' '
> + test_commit 6 &&
> + (cd clone && git fetch) &&
> + test 5 = $(commit_subject my-side@{t}@{1})
> +'
> +
> +test_done
^ permalink raw reply
* [PATCH] Introduce <branch>@{tracked} as shortcut to the tracked branch
From: Johannes Schindelin @ 2009-09-10 9:36 UTC (permalink / raw)
To: Junio C Hamano
Cc: Jeff King, Björn Steinbrink, Michael J Gruber, Pete Wyckoff,
git
In-Reply-To: <alpine.DEB.1.00.0909100941330.8306@pacific.mpi-cbg.de>
Often, it is quite interesting to inspect the branch tracked by a given
branch. This patch introduces a nice notation to get at the tracked
branch: '<branch>@{tracked}' can be used to access that tracked branch.
A special shortcut '@{tracked}' refers to the branch tracked by the
current branch.
Suggested by Pasky.
The syntax was suggested by Junio.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---
I decided that I like @{tracked} better than @{upstream} (which
reads to me more like the upstream _repository_), but hey, I made
the code flexible enough to change that at a whim.
Documentation/git-rev-parse.txt | 4 ++
sha1_name.c | 37 ++++++++++++++++++++--
t/t1506-rev-parse-tracked.sh | 64 +++++++++++++++++++++++++++++++++++++++
3 files changed, 102 insertions(+), 3 deletions(-)
create mode 100755 t/t1506-rev-parse-tracked.sh
diff --git a/Documentation/git-rev-parse.txt b/Documentation/git-rev-parse.txt
index 82045a2..09a2145 100644
--- a/Documentation/git-rev-parse.txt
+++ b/Documentation/git-rev-parse.txt
@@ -231,6 +231,10 @@ when you run 'git-merge'.
* The special construct '@\{-<n>\}' means the <n>th branch checked out
before the current one.
+* The suffix '@{tracked}' to a ref (short form 'blabla@{t}') refers to
+ the branch tracked by that ref. If no ref was specified, it means the
+ branch tracked by the current branch.
+
* A suffix '{caret}' to a revision parameter means the first parent of
that commit object. '{caret}<n>' means the <n>th parent (i.e.
'rev{caret}'
diff --git a/sha1_name.c b/sha1_name.c
index 44bb62d..a886846 100644
--- a/sha1_name.c
+++ b/sha1_name.c
@@ -5,6 +5,7 @@
#include "blob.h"
#include "tree-walk.h"
#include "refs.h"
+#include "remote.h"
static int find_short_object_filename(int len, const char *name, unsigned char *sha1)
{
@@ -238,9 +239,24 @@ static int ambiguous_path(const char *path, int len)
return slash;
}
+static inline int tracked_suffix(const char *string, int len)
+{
+ const char *suffix[] = { "@{tracked}", "@{t}" };
+ int i;
+
+ for (i = 0; i < ARRAY_SIZE(suffix); i++) {
+ int suffix_len = strlen(suffix[i]);
+ if (len >= suffix_len && !memcmp(string + len - suffix_len,
+ suffix[i], suffix_len))
+ return suffix_len;
+ }
+ return 0;
+}
+
/*
* *string and *len will only be substituted, and *string returned (for
- * later free()ing) if the string passed in is of the form @{-<n>}.
+ * later free()ing) if the string passed in is of the form @{-<n>} or
+ * of the form <branch>@{tracked}.
*/
static char *substitute_branch_name(const char **string, int *len)
{
@@ -254,6 +270,19 @@ static char *substitute_branch_name(const char **string, int *len)
return (char *)*string;
}
+ ret = tracked_suffix(*string, *len);
+ if (ret) {
+ char *ref = xstrndup(*string, *len - ret);
+ struct branch *tracking = branch_get(*ref ? ref : NULL);
+
+ free(ref);
+ if (tracking->merge && tracking->merge[0]->dst) {
+ *string = xstrdup(tracking->merge[0]->dst);
+ *len = strlen(*string);
+ return (char *)*string;
+ }
+ }
+
return NULL;
}
@@ -340,8 +369,10 @@ static int get_sha1_basic(const char *str, int len, unsigned char *sha1)
if (len && str[len-1] == '}') {
for (at = len-2; at >= 0; at--) {
if (str[at] == '@' && str[at+1] == '{') {
- reflog_len = (len-1) - (at+2);
- len = at;
+ if (!tracked_suffix(str + at, len - at)) {
+ reflog_len = (len-1) - (at+2);
+ len = at;
+ }
break;
}
}
diff --git a/t/t1506-rev-parse-tracked.sh b/t/t1506-rev-parse-tracked.sh
new file mode 100755
index 0000000..89193e1
--- /dev/null
+++ b/t/t1506-rev-parse-tracked.sh
@@ -0,0 +1,64 @@
+#!/bin/sh
+
+test_description='test <branch>@{tracked} syntax'
+
+. ./test-lib.sh
+
+
+test_expect_success 'setup' '
+
+ test_commit 1 &&
+ git checkout -b side &&
+ test_commit 2 &&
+ git checkout master &&
+ git clone . clone &&
+ test_commit 3 &&
+ (cd clone &&
+ test_commit 4 &&
+ git branch --track my-side origin/side)
+
+'
+
+full_name () {
+ (cd clone &&
+ git rev-parse --symbolic-full-name "$@")
+}
+
+commit_subject () {
+ (cd clone &&
+ git show -s --pretty=format:%s "$@")
+}
+
+test_expect_success '@{tracked} resolves to correct full name' '
+ test refs/remotes/origin/master = "$(full_name @{tracked})"
+'
+
+test_expect_success '@{t} resolves to correct full name' '
+ test refs/remotes/origin/master = "$(full_name @{t})"
+'
+
+test_expect_success 'my-side@{tracked} resolves to correct full name' '
+ test refs/remotes/origin/side = "$(full_name my-side@{t})"
+'
+
+test_expect_success 'my-side@{t} resolves to correct commit' '
+ git checkout side &&
+ test_commit 5 &&
+ (cd clone && git fetch) &&
+ test 2 = "$(commit_subject my-side)" &&
+ test 5 = "$(commit_subject my-side@{t})"
+'
+
+test_expect_success 'not-tracking@{t} fails' '
+ test_must_fail full_name non-tracking@{t} &&
+ (cd clone && git checkout --no-track -b non-tracking) &&
+ test_must_fail full_name non-tracking@{t}
+'
+
+test_expect_success '<branch>@{t}@{1} resolves correctly' '
+ test_commit 6 &&
+ (cd clone && git fetch) &&
+ test 5 = $(commit_subject my-side@{t}@{1})
+'
+
+test_done
--
1.6.4.313.g3d9e3
^ permalink raw reply related
* Re: [PATCHv5 00/14] git notes
From: Johan Herland @ 2009-09-10 9:25 UTC (permalink / raw)
To: Johannes Schindelin
Cc: git, Junio C Hamano, trast, tavestbo, git, chriscool, spearce
In-Reply-To: <200909081436.30761.johan@herland.net>
On Tuesday 08 September 2009, Johan Herland wrote:
> On Tuesday 08 September 2009, Johannes Schindelin wrote:
> > On Tue, 8 Sep 2009, Johan Herland wrote:
> > > Algorithm / Notes tree git log -n10 (x100) git log --all
> > > ------------------------------------------------------------
> > > next / no-notes 4.77s 63.84s
> > >
> > > before / no-notes 4.78s 63.90s
> > > before / no-fanout 56.85s 65.69s
> > >
> > > 16tree / no-notes 4.77s 64.18s
> > > 16tree / no-fanout 30.35s 65.39s
> > > 16tree / 2_38 5.57s 65.42s
> > > 16tree / 2_2_36 5.19s 65.76s
> > >
> > > flexible / no-notes 4.78s 63.91s
> > > flexible / no-fanout 30.34s 65.57s
> > > flexible / 2_38 5.57s 65.46s
> > > flexible / 2_2_36 5.18s 65.72s
> > > flexible / ym 5.13s 65.66s
> > > flexible / ym_2_38 5.08s 65.63s
> > > flexible / ymd 5.30s 65.45s
> > > flexible / ymd_2_38 5.29s 65.90s
> > > flexible / y_m 5.11s 65.72s
> > > flexible / y_m_2_38 5.08s 65.67s
> > > flexible / y_m_d 5.06s 65.50s
> > > flexible / y_m_d_2_38 5.07s 65.79s
[snip]
> > - I'd love to see performance numbers for less than 157118 notes.
> > Don't get me wrong, it is good to see the worst-case scenario in
> > terms of notes/commits ratio. But it will hardly be the common case,
> > and I very much would like to optimize for the common case.
> >
> > So, I'd appreciate if you could do the tests with something like
> > 500 notes, randomly spread over the commits (rationale: my original
> > understanding was that the notes could amend commit messages, and
> > that is much more likely to be done with relatively old commits that
> > you cannot change anymore).
>
> Ok. I will try to test that.
Here are the results of the 500-notes-in-kernel-repo test:
Algorithm / Notes tree git log -n10 (x100) git log --all
next / no-notes 4.83s 64.78s
before / no-notes 4.84s 64.76s
before / no-fanout 4.98s 64.89s
16tree / no-notes 4.84s 64.61s
16tree / no-fanout 4.92s 64.68s
16tree / 2_38 4.85s 64.45s
16tree / 2_2_36 4.85s 64.63s
flexible / no-notes 4.84s 64.82s
flexible / no-fanout 4.91s 65.01s
flexible / 2_38 4.85s 64.93s
flexible / 2_2_36 4.85s 64.63s
flexible / ym 4.83s 64.63s
flexible / ym_2_38 4.86s 64.72s
flexible / ymd 4.91s 64.74s
flexible / ymd_2_38 4.91s 64.56s
flexible / y_m 4.86s 64.76s
flexible / y_m_2_38 4.86s 64.71s
flexible / y_m_d 4.86s 64.73s
flexible / y_m_d_2_38 4.84s 64.50s
I don't like the noise level in the second column ('git log --all'). Then
again, I don't find that column very interesting (it's mostly there to
verify that we don't have any abysmal worst-case behaviours in the notes
code).
The first column is fairly nice and tidy, though. At a first glance it shows
pretty much the same results as the 157000-notes table previously posted.
Obviously the abysmal performance of no-fanout is gone (500 notes in a
single tree object is not _that_ bad), although a 2/38-fanout is still a
better choice for 500 notes (but 2/2/36 does not provide any additional
improvement).
>From this we can start to guess that the threshold for moving from no fanout
to 2/38 is somewhere below 500 notes, while the theshold for moving from
2/38 to 2/2/36 is between 500 and ~157000 notes (probably much closer to
157000 than to 500; I wouldn't be surprised if ~256 entries per level turns
out to be good a threshold).
The date-based fanout performs on par with the SHA1-based fanout, although
it's hard to say anything conclusively when the numbers are as close as
this. However, the ymd and ymd_2_38 fanout probably show signs of too much
overhead (too many levels) at only 500 notes. This is not surprising.
My gut feeling tells me that moving from 'no-fanout' to either '2_38' or
'ym' is a good idea at ~256 notes. Then, if we went with '2_38', we'd have
to switch to '2_2_36' at ~64K notes (i.e. when each /38 level reaches ~256
notes) However, it seems that with 'ym', we could stick with it for much
longer before having to consider switching to a different fanout alternative
(probably 'ym_2_38' or 'y_m_d').
Have fun! :)
...Johan
--
Johan Herland, <johan@herland.net>
www.herland.net
^ permalink raw reply
* Re: obnoxious CLI complaints
From: Jakub Narebski @ 2009-09-10 9:16 UTC (permalink / raw)
To: Brendan Miller; +Cc: git
In-Reply-To: <ef38762f0909091709t7336d86dkd2f175e5b3a6a3f@mail.gmail.com>
On Thu, 10 Sep 2009, Brendan Miller wrote:
> On Wed, Sep 9, 2009 at 2:54 PM, Jakub Narebski <jnareb@gmail.com> wrote:
>> Brendan Miller <catphive@catphive.net> writes:
>> First question: which git version do you use?
>
> It sounds like a bunch of things have been fixed in yet to be released
> versions. That's great.
Both "git init --bare" and cloning empty repository are in _released_
versions.
>>> This is what I want to do 90% of the time, so it should just have the
>>> proper defaults, and not make me look at the man page every time I
>>> want to use it.
>>
>> You learn those idioms.
>
> I guess. Is that a good thing? Is the goal of interface design to make
> it difficult so I need to learn a lot of things, or easy so I can
> remain blissfully ignorant but still do what I want?
There are at least two issues:
1. What you want to do 90% of time might be not what other people want
to do 90% of time.
2. Some thing are due to git philosophy (like e.g. "git commit -a").
As to git-archive example: first, git-archive _has_ default format, and
it is tar. Second, compression is better left to separate program, but
I guess we can follow GNU tar example and add equivalents of -Z/-z/-j
and --use-compress-program options when using --output=<file>. Third,
when using e.g. tar you have to specify files to compress, so I don't
know why you complain that git-archive requires equivalent, HEAD in your
example.
>>> 6. Where is the bug tracker? If people users can't find the bug
>>> tracker, they can't report issues, and obnoxious bugs go unfixed, or
>>> people have to whine on the mailing list. There should be a nice big
>>> link on the front page of git-scm.com. A bug tracker is really the
>>> only way for the vast majority of a community that use a tool can give
>>> feedback on the problems the tool has.
>>
>> Do you offer to maintain and manage such bug tracker? I mean here
>> taking care of duplicated bugs, tracking which bugs are resolved and
>> which are not, checking if bug is reproductible, etc. Do you?
>> Unmaintained bugtracker is worse than useless.
>>
>> Using mailing list for bug reports and for patches is time-honored
>> workflow, which works rather well for smaller projects such as Git.
>> Note that git mailing list is free for all; you don't need to
>> subscribe to send, and you can watch it via many archives and gateways
>> (like GMane).
>
> Bug trackers are a hassle, believe me, I know... but I think they
> contribute to the overall quality of the product if used effectively.
> Mailing lists seem like a good way to forget about bugs after people
> have given up on getting developers to fix them.
This is a good way to separate important from unimportant bug reports
and feature requests ;-)
>>> 7. Man pages: It's nice we have them, but we shouldn't need them to do
>>> basic stuff. I rarely had to look at the man pages using svn, but
>>> every single time I use git I have to dig into these things. Frankly,
>>> I have better things to do than RTFM.
>>
>> Learn. If you learn the philosophy behind git design, you would have
>> much easier understanding and remembering git.
>
> I think what you mean by philosophy is the underlying data structures,
> which are discussed in the manual (how many apps do you have that do
> that!). I have read that. However, that one needs to understand
> underlying data structure is just one more hurdle to understanding
> git.
No, I didn't mean understanding underlying data structures, but
understanding philosophy: graph of revisions; tracking contents; refs
as pointers to graph of revisions; the trifecta of working area,
the index and repository, etc.
> If I use GCC, do I need to know that it has a recursive descent
> parser? That it is implemented with a garbage collector? No. I just
> need to know that I give it C, and it gives me a binary.
Better example would be using "make". You need to understand 'make'
philosophy to write all but most simple of Makefiles.
>
> Example:
> gcc main.c
>
> Think about all the defaults that are specified here! I don't
> explicitly tell it how to find libc.so or what path the dynamic linker
> is at. I don't even really need to tell it which operation it is
> performing, i.e. generating a binary, .o, .so, .os, .a, etc because it
> has a smart default.
And if you are smart, you never use this form, but "gcc -o main main.c".
And you have to specify '-lm' if you use math routines. Not that simple,
isn't it?
> This an order of magnitude more complex than any git operation in
> terms of implementation, but it is dead simple from the users
> perspective.
When git (or the concept of DVCS) is as old as gcc (or C compiler) is
now, then we can talk.
>> There is "Git User's Manual", "The Git Community Book", "Pro Git" and
>> many other references.
>
> Yeah, I've been reading them. I'm saying that the docs are a crutch.
> RTFM is the problem not the solution. It makes the user do more work
> to avoid fixing usability issues.
When the tool is more complicated (like DVCS), you can't use it in all
but simplest cases without understanding it.
> A CLI has some inherent limitations in that it doesn't have big
> labeled buttons to press. However, that doesn't mean it has to be hard
> to use. I think a lot of the strength of the linux CLI is that most of
> the utilities have actually pretty well thought out interfaces that
> have been refined over time. That one's that aren't like that... well,
> no one uses them.
>
> I'm not saying that a unixy approach is wrong, but that most unix
> utilities are much easier to use than git, and that git needs
> improvement on this front.
I'm not saying that git doesn't need UI (and documentation) improvements.
But first, your attitude is a bit grating, and second, your examples
are not it.
On the other hand there is inherent problems that serious git
contributors use git for a long time and are used to (and perhaps even
attached to) git UI warts, and newbies which start to use git not always
can distinguish between things that can be changed and things that cannot
be changed.
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: [StGit PATCH] Add import -p option
From: Karl Wiberg @ 2009-09-10 8:24 UTC (permalink / raw)
To: Catalin Marinas; +Cc: Gustav Hållberg, Git Mailing List
In-Reply-To: <b0943d9e0909091509i16b556f0x9dd3aa6788054298@mail.gmail.com>
On 2009-09-09 23:09:51 +0100, Catalin Marinas wrote:
> 2009/9/8 Karl Wiberg <kha@treskal.com>:
>
> > On 2009-09-08 22:43:39 +0100, Catalin Marinas wrote:
> >
> > > + if strip:
> > > + cmd += ['-p', strip]
> >
> > This test should probably be "if strip != None". It doesn't
> > _really_ matter, technically, since -p0 is the default, but still
> > ...
>
> I modified it after posting the patch. The git default is -p1, so we
> would miss the -p0 case.
Ah ha! Sometimes it actually does pay to be pedantic ...
--
Karl Wiberg, kha@treskal.com
www.treskal.com/kalle
^ permalink raw reply
* Re: tracking branch for a rebase
From: Johannes Schindelin @ 2009-09-10 7:47 UTC (permalink / raw)
To: Junio C Hamano
Cc: Jeff King, Björn Steinbrink, Michael J Gruber, Pete Wyckoff,
git
In-Reply-To: <7vzl93cncn.fsf@alter.siamese.dyndns.org>
Hi,
On Wed, 9 Sep 2009, Junio C Hamano wrote:
> I find a prefix % not descriptive enough (besides being ugly); if it were
> "^branch", as some people said, it would probably have matched its meaning
> "up", but that notation is already taken for "uninteresting".
How about ^^branch? *ducks*
Seriously again, I think that ^{tracking} (with shorthand ^t, maybe) is
not too shabby an option. The point is: if we make this unattractive
enough by requiring a lot of typing, we will never get to the point where
it is popular enough to make a shorthand: it just will not be used at all.
> When I say there is only one kind of magic notation for refs, I am
> primarily talking about the end-user perception. @{time}, @{number} and
> @{-number} all do their magic using the reflog, but that is about _how_
> they do what they do. End-user perception begins with _what_ they do, and
> at that level, the magic consistently works on refs and different genie is
> summoned depending on what is inside {}.
>
> The @{upstream} thing won't be using reflog to do its job, but that is
> about _how_ it is implemented, and the end users don't care.
Ah, I get what you're saying. @{2.days.ago} says something about this
branch locally, but @{upstream} says something about this branch remotely
(well, our local cache). From that view point, it makes sense.
But my point stands: @{upstream} is too awkward to type. Let's have _at
least_ a shortcut '@{up}'.
Ciao,
Dscho
^ permalink raw reply
* [PATCH v2] git-p4: Avoid modules deprecated in Python 2.6.
From: Reilly Grant @ 2009-09-10 7:02 UTC (permalink / raw)
To: git, gitster; +Cc: Reilly Grant
The popen2, sha and sets modules are deprecated in Python 2.6 (sha in
Python 2.5). Both popen2 and sha are not actually used in git-p4.
Replace usage of sets.Set with the builtin set object.
The built-in set object was added in Python 2.4 and is already used in
other parts of this script, so this dependency is nothing new.
Signed-off-by: Reilly Grant <reillyeon@qotw.net>
---
contrib/fast-import/git-p4 | 12 +++++-------
1 files changed, 5 insertions(+), 7 deletions(-)
diff --git a/contrib/fast-import/git-p4 b/contrib/fast-import/git-p4
index 38438f3..e710219 100755
--- a/contrib/fast-import/git-p4
+++ b/contrib/fast-import/git-p4
@@ -8,12 +8,10 @@
# License: MIT <http://www.opensource.org/licenses/mit-license.php>
#
-import optparse, sys, os, marshal, popen2, subprocess, shelve
-import tempfile, getopt, sha, os.path, time, platform
+import optparse, sys, os, marshal, subprocess, shelve
+import tempfile, getopt, os.path, time, platform
import re
-from sets import Set;
-
verbose = False
@@ -864,8 +862,8 @@ class P4Sync(Command):
self.usage += " //depot/path[@revRange]"
self.silent = False
- self.createdBranches = Set()
- self.committedChanges = Set()
+ self.createdBranches = set()
+ self.committedChanges = set()
self.branch = ""
self.detectBranches = False
self.detectLabels = False
@@ -1662,7 +1660,7 @@ class P4Sync(Command):
if len(self.changesFile) > 0:
output = open(self.changesFile).readlines()
- changeSet = Set()
+ changeSet = set()
for line in output:
changeSet.add(int(line))
--
1.6.3.3
^ permalink raw reply related
* Re: tracking branch for a rebase
From: Junio C Hamano @ 2009-09-10 6:42 UTC (permalink / raw)
To: Jeff King
Cc: Johannes Schindelin, Björn Steinbrink, Michael J Gruber,
Pete Wyckoff, git
In-Reply-To: <20090909104550.GA20108@coredump.intra.peff.net>
Jeff King <peff@peff.net> writes:
> I wonder if it is worth adding @{upstream} now, which is fairly safe,
> letting it cook for a while, and then adding a "%" alias later after the
> concept has proved itself (and people say "I like this feature, but it
> really is too much to type").
That's a sane suggestion, I think. We can always have a descriptive
longhand (e.g. "branch@{upstream}") and later add a shorthand for often
used ones (e.g. "branch^up", "branch/.up" --- the former is possible
because it cannot be upth parent of the commit at the tip of the branch,
and the latter is possible because component of hierarchical refname
cannot begin with a dot).
I find a prefix % not descriptive enough (besides being ugly); if it were
"^branch", as some people said, it would probably have matched its meaning
"up", but that notation is already taken for "uninteresting". If we are
going to use funny symbol as a notation to invoke magic, I think it is
easier for new people if we limit the number of symbols used. We already
have ^n, ^{type} and ~n magic, all of which operate on objects and peel
them in three different ways.
Then there currently is only one kind of magic that works on refs and it
is spelled as ref@{magic}. Let's try not to introduce more notation
before it is absolutely necessary.
When I say there is only one kind of magic notation for refs, I am
primarily talking about the end-user perception. @{time}, @{number} and
@{-number} all do their magic using the reflog, but that is about _how_
they do what they do. End-user perception begins with _what_ they do, and
at that level, the magic consistently works on refs and different genie is
summoned depending on what is inside {}.
The @{upstream} thing won't be using reflog to do its job, but that is
about _how_ it is implemented, and the end users don't care.
What is more important is _what_ it does. Given a ref, the @{} magic
notation finds something that is related to the ref. @{time} and
@{number} finds what the ref itself used to point at. @{-number}
(applicable only to HEAD ref) finds the ref it used to point at. And
@{upstream} will find another ref that it merges from (or rebases onto).
^ permalink raw reply
* Re: [PATCHv5 00/14] git notes
From: Stephen R. van den Berg @ 2009-09-10 6:23 UTC (permalink / raw)
To: Johan Herland
Cc: Johannes Schindelin, git, Junio C Hamano, trast, tavestbo, git,
chriscool, spearce
In-Reply-To: <200909090046.45213.johan@herland.net>
Johan Herland wrote:
>I was, however, naive enough to assume that when git.git decided on using
>2/38 fanout for its loose objects, then some performance-related thoughts
>went into that decision. If there are indications that multiple-of-2-type
I presume that that choice was based on the fact that on a typical filesystem
(e.g. ext2 old-style) without directory indexing, the sort-of optimal fanout
should aim for no more than 100-200 directory entries per directory.
--
Sincerely,
Stephen R. van den Berg.
Mommy, what happens to your files when you die?
^ permalink raw reply
* Re: obnoxious CLI complaints
From: Björn Steinbrink @ 2009-09-10 1:32 UTC (permalink / raw)
To: Brendan Miller; +Cc: git
In-Reply-To: <ef38762f0909091427m5b8f3am72c88fd4dbfebc59@mail.gmail.com>
On 2009.09.09 14:27:56 -0700, Brendan Miller wrote:
> 8. There's no obvious way to make a remote your default push pull
> location without editing the git config file. Why not just something
> like
>
> git remote setdefault origin
Because "git remote" is the wrong tool. The default remote for
fetch/push is configured per branch head, not globally.
> or even
>
> git remote add --default origin http://somegiturl.org/
Because that would likely mean changing all the existing branch head
configurations, quite possibly making them invalid, because the
branch.<name>.merge value suddenly makes no sense anymore.
> This come up in the use case where I:
> 1. set up a remote bare repo
> 2. push from my local repo, and thence forth want to keep local and
> remote in sink.
Maybe you want something like this?
http://thread.gmane.org/gmane.comp.version-control.git/107671
> Right now I have to modify .git/config to do this.
You can also do:
git config branch.<name>.remote <remote>
which does the config editing for you.
And maybe:
git config branch.<name>.merge <ref>
if you also want just "git pull" to work, or use push.default = tracking.
There's also still my old "retrack" hack, which John Wiegley extended:
http://github.com/jwiegley/git-scripts/blob/6ba3184d7b9f6dae3d10379a6bac29a01ceef190/git-retrack
That's a bit more comfortable, but probably doesn't work for a lot of
"non-standard" setups.
Björn
^ permalink raw reply
* Re: obnoxious CLI complaints
From: Todd Zullinger @ 2009-09-10 1:25 UTC (permalink / raw)
To: Brendan Miller; +Cc: Jakub Narebski, git
In-Reply-To: <ef38762f0909091709t7336d86dkd2f175e5b3a6a3f@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 634 bytes --]
Brendan Miller wrote:
> On Wed, Sep 9, 2009 at 2:54 PM, Jakub Narebski <jnareb@gmail.com> wrote:
>> Brendan Miller <catphive@catphive.net> writes:
>> First question: which git version do you use?
>
> It sounds like a bunch of things have been fixed in yet to be released
> versions. That's great.
If I am not mistaken, support for cloning an empty repo was available
in 1.6.2, which was released in March.
--
Todd OpenPGP -> KeyID: 0xBEAF0CE3 | URL: www.pobox.com/~tmz/pgp
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Drugs may lead to nowhere, but at least it's the scenic route.
[-- Attachment #2: Type: application/pgp-signature, Size: 542 bytes --]
^ 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