* 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: 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: 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: 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: [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: [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: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
* [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: [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
* 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: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
* 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: Johannes Schindelin @ 2009-09-10 15:22 UTC (permalink / raw)
To: Jeff King
Cc: Junio C Hamano, Björn Steinbrink, Michael J Gruber,
Pete Wyckoff, git
In-Reply-To: <20090910141618.GB4942@coredump.intra.peff.net>
Hi,
On Thu, 10 Sep 2009, Jeff King wrote:
> Also, I seem to be able to stimulate a segfault on a detached HEAD, but
> I haven't investigated it yet.
Aaargh!
Mikachu pointed that out recently, provided a test, I fixed it, and in the
meantime I managed to forget about it!
/me needs to do less things per day.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] Introduce <branch>@{tracked} as shortcut to the tracked branch
From: Johannes Schindelin @ 2009-09-10 15:24 UTC (permalink / raw)
To: Jeff King
Cc: Junio C Hamano, Björn Steinbrink, Michael J Gruber,
Pete Wyckoff, git
In-Reply-To: <20090910142628.GA7275@coredump.intra.peff.net>
Hi,
On Thu, 10 Sep 2009, Jeff King wrote:
> On Thu, Sep 10, 2009 at 10:16:18AM -0400, Jeff King wrote:
>
> 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) {
Almost.
My version dies if tracking is NULL.
Ciao,
Dscho
^ permalink raw reply
* [PATCH v2] Introduce <branch>@{upstream} as shortcut to the tracked branch
From: Johannes Schindelin @ 2009-09-10 15:25 UTC (permalink / raw)
To: Jeff King
Cc: Junio C Hamano, Björn Steinbrink, Michael J Gruber,
Pete Wyckoff, git
In-Reply-To: <alpine.DEB.1.00.0909101723260.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>@{upstream}' can be used to access that tracked branch.
A special shortcut '@{upstream}' refers to the branch tracked by the
current branch.
Suggested by Pasky.
The syntax was suggested by Junio.
A test for a now-fixed crash was provided by Mikael Magnusson.
The crash has been pointed out by Peff again (because this here developer
managed to forget about the fix).
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---
Changes since v1:
- changed to @{upstream} (and @{u})
- included the fix I forgot about
Documentation/git-rev-parse.txt | 4 ++
sha1_name.c | 39 ++++++++++++++++++++--
t/t1506-rev-parse-tracked.sh | 69 +++++++++++++++++++++++++++++++++++++++
3 files changed, 109 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 '@{upstream}' to a ref (short form 'blabla@{u}') 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..ae4280e 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[] = { "@{upstream}", "@{u}" };
+ 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>@{upstream}.
*/
static char *substitute_branch_name(const char **string, int *len)
{
@@ -254,6 +270,21 @@ 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)
+ die ("No tracking branch found for '%s'", ref);
+ if (tracking->merge && tracking->merge[0]->dst) {
+ *string = xstrdup(tracking->merge[0]->dst);
+ *len = strlen(*string);
+ return (char *)*string;
+ }
+ }
+
return NULL;
}
@@ -340,8 +371,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..72d0579
--- /dev/null
+++ b/t/t1506-rev-parse-tracked.sh
@@ -0,0 +1,69 @@
+#!/bin/sh
+
+test_description='test <branch>@{upstream} 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 '@{upstream} resolves to correct full name' '
+ test refs/remotes/origin/master = "$(full_name @{upstream})"
+'
+
+test_expect_success '@{u} resolves to correct full name' '
+ test refs/remotes/origin/master = "$(full_name @{u})"
+'
+
+test_expect_success 'my-side@{upstream} resolves to correct full name' '
+ test refs/remotes/origin/side = "$(full_name my-side@{u})"
+'
+
+test_expect_success 'my-side@{u} 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@{u})"
+'
+
+test_expect_success 'not-tracking@{u} fails' '
+ test_must_fail full_name non-tracking@{u} &&
+ (cd clone && git checkout --no-track -b non-tracking) &&
+ test_must_fail full_name non-tracking@{u}
+'
+
+test_expect_success '<branch>@{u}@{1} resolves correctly' '
+ test_commit 6 &&
+ (cd clone && git fetch) &&
+ test 5 = $(commit_subject my-side@{u}@{1})
+'
+
+test_expect_success '% without specifying branch crashes on a detached HEAD' '
+ git checkout HEAD^0 &&
+ test_must_fail git rev-parse @{u}
+'
+
+test_done
--
1.6.4.313.g3d9e3
^ permalink raw reply related
* git svn propset support
From: David Fraser @ 2009-09-10 15:41 UTC (permalink / raw)
To: git; +Cc: David Moore
In-Reply-To: <1699967795.351252597251356.JavaMail.root@klofta.sjsoft.com>
[-- Attachment #1: Type: text/plain, Size: 868 bytes --]
Hi
I've been trying to hack at getting manually property setting support for git-svn.
I've got a start of a patch that basically stores an attribute 'svn-properties' for each file that needs them changed, and then sets the properties when committing.
Issues remaining:
* The way it edits the .gitattributes file is suboptimal - it just appends to the end the latest version
* It could use the existing code to get the current svn properties to see if properties need to be changed; but this doesn't work on add
* It would be better to cache all the svn properties locally - this could be done automatically in .gitattributes but I'm not sure everyone would want this, etc
* No support for deleting properties
Usage is:
git svn propset PROPNAME PROPVALUE PATH
Patch attached (against 1.6.0.2) - any comments welcome
David
--
David Fraser
St James Software
[-- Attachment #2: git-svn-propset-0.patch --]
[-- Type: text/x-patch, Size: 5427 bytes --]
--- git-1.6.0.2/git-svn.perl 2008-12-15 15:52:14.000000000 +0200
+++ git-svn.perl 2009-09-10 17:35:04.000000000 +0200
@@ -66,7 +66,7 @@
$_version, $_fetch_all, $_no_rebase,
$_merge, $_strategy, $_dry_run, $_local,
$_prefix, $_no_checkout, $_url, $_verbose,
- $_git_format, $_commit_url);
+ $_git_format, $_commit_url, $_set_svn_props);
$Git::SVN::_follow_parent = 1;
my %remote_opts = ( 'username=s' => \$Git::SVN::Prompt::_username,
'config-dir=s' => \$Git::SVN::Ra::config_dir,
@@ -128,6 +128,7 @@
'dry-run|n' => \$_dry_run,
'fetch-all|all' => \$_fetch_all,
'commit-url=s' => \$_commit_url,
+ 'set-svn-props=s' => \$_set_svn_props,
'revision|r=i' => \$_revision,
'no-rebase' => \$_no_rebase,
%cmt_opts, %fc_opts } ],
@@ -141,6 +142,9 @@
'propget' => [ \&cmd_propget,
'Print the value of a property on a file or directory',
{ 'revision|r=i' => \$_revision } ],
+ 'propset' => [ \&cmd_propset,
+ 'Set the value of a property on a file or directory - will be set on commit',
+ {} ],
'proplist' => [ \&cmd_proplist,
'List all properties of a file or directory',
{ 'revision|r=i' => \$_revision } ],
@@ -700,6 +704,64 @@
print $props->{$prop} . "\n";
}
+sub check_attr
+{
+ my ($attr,$path) = @_;
+ if ( open my $fh, '-|', "git", "check-attr", $attr, "--", $path )
+ {
+ my $val = <$fh>;
+ close $fh;
+ $val =~ s/^[^:]*:\s*[^:]*:\s*(.*)\s*$/$1/;
+ return $val;
+ }
+ else
+ {
+ return undef;
+ }
+}
+
+# cmd_propset (PROPNAME, PROPVAL, PATH)
+# ------------------------
+# Adjust the SVN property PROPNAME to PROPVAL for PATH.
+sub cmd_propset {
+ my ($propname, $propval, $path) = @_;
+ $path = '.' if not defined $path;
+ $path = $cmd_dir_prefix . $path;
+ usage(1) if not defined $propname;
+ usage(1) if not defined $propval;
+ my $file = basename($path);
+ my $dn = dirname($path);
+ my $current_properties = check_attr( "svn-properties", $path );
+ my $new_properties = "";
+ if ($current_properties eq "unset" || $current_properties eq "" || $current_properties eq "set") {
+ $new_properties = "$propname=$propval";
+ } else {
+ # TODO: handle combining properties better
+ my @props = split(/;/, $current_properties);
+ my $replaced_prop = 0;
+ foreach my $prop (@props) {
+ # Parse 'name=value' syntax and set the property.
+ if ($prop =~ /([^=]+)=(.*)/) {
+ my ($n,$v) = ($1,$2);
+ if ($n eq $propname)
+ {
+ $v = $propval;
+ $replaced_prop = 1;
+ }
+ if ($new_properties eq "") { $new_properties="$n=$v"; }
+ else { $new_properties="$new_properties;$n=$v"; }
+ }
+ }
+ if ($replaced_prop eq 0) {
+ $new_properties = "$new_properties;$propname=$propval";
+ }
+ }
+ my $attrfile = "$dn/.gitattributes";
+ open my $attrfh, '>>', $attrfile or die "Can't open $attrfile: $!\n";
+ # TODO: don't simply append here if $file already has svn-properties
+ print $attrfh "$file svn-properties=$new_properties\n";
+}
+
# cmd_proplist (PATH)
# -------------------
# Print the list of SVN properties for PATH.
@@ -3598,6 +3660,34 @@
}
}
+sub apply_manualprops {
+ my ($self, $file, $fbat) = @_;
+ my $path = $cmd_dir_prefix . $file;
+ my $pending_properties = ::check_attr( "svn-properties", $path );
+ if ($pending_properties eq "") { return; }
+ # Parse the list of properties to set.
+ my @props = split(/;/, $pending_properties);
+ # TODO: get existing properties to compare to - this fails for add so currently not done
+ # my $existing_props = ::get_svnprops($file);
+ my $existing_props = {};
+ # TODO: caching svn properties or storing them in .gitattributes would make that faster
+ foreach my $prop (@props) {
+ # Parse 'name=value' syntax and set the property.
+ if ($prop =~ /([^=]+)=(.*)/) {
+ my ($n,$v) = ($1,$2);
+ for ($n, $v) {
+ s/^\s+//; s/\s+$//;
+ }
+ # FIXME: clearly I don't know perl and couldn't work out how to evaluate this better
+ if (defined $existing_props->{$n} && $existing_props->{$n} eq $v) {
+ my $needed = 0;
+ } else {
+ $self->change_file_prop($fbat, $n, $v);
+ }
+ }
+ }
+}
+
sub A {
my ($self, $m) = @_;
my ($dir, $file) = split_path($m->{file_b});
@@ -3606,6 +3696,7 @@
undef, -1);
print "\tA\t$m->{file_b}\n" unless $::_q;
$self->apply_autoprops($file, $fbat);
+ $self->apply_manualprops($file, $fbat);
$self->chg_file($fbat, $m);
$self->close_file($fbat,undef,$self->{pool});
}
@@ -3617,6 +3708,7 @@
my $fbat = $self->add_file($self->repo_path($m->{file_b}), $pbat,
$self->url_path($m->{file_a}), $self->{r});
print "\tC\t$m->{file_a} => $m->{file_b}\n" unless $::_q;
+ $self->apply_manualprops($file, $fbat);
$self->chg_file($fbat, $m);
$self->close_file($fbat,undef,$self->{pool});
}
@@ -3636,6 +3728,7 @@
my $fbat = $self->add_file($self->repo_path($m->{file_b}), $pbat,
$self->url_path($m->{file_a}), $self->{r});
print "\tR\t$m->{file_a} => $m->{file_b}\n" unless $::_q;
+ $self->apply_manualprops($file, $fbat);
$self->chg_file($fbat, $m);
$self->close_file($fbat,undef,$self->{pool});
@@ -3651,6 +3744,7 @@
my $fbat = $self->open_file($self->repo_path($m->{file_b}),
$pbat,$self->{r},$self->{pool});
print "\t$m->{chg}\t$m->{file_b}\n" unless $::_q;
+ $self->apply_manualprops($file, $fbat);
$self->chg_file($fbat, $m);
$self->close_file($fbat,undef,$self->{pool});
}
^ permalink raw reply
* Re: [PATCH v2] Introduce <branch>@{upstream} as shortcut to the tracked branch
From: Jeff King @ 2009-09-10 15:55 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.0909101724520.8306@pacific.mpi-cbg.de>
On Thu, Sep 10, 2009 at 05:25:57PM +0200, Johannes Schindelin wrote:
> Changes since v1:
> - changed to @{upstream} (and @{u})
Hmm. After applying v2, I accidentally tried "git rev-parse @{t}" and
was surprised to find that it worked! The problem, of course, is that we
saw that it was not one of our keywords and therefore dumped it into
approxidate, which happily converted it into the current time, and
provided me with HEAD@{now}.
Which is sad, because it means "HEAD@{usptream}" will silently produce
incorrect results.
I don't see a way around it, though, short of tightening approxidate's
parsing. Maybe it could keep a flag for "I noticed _anything_ of value
in this string", and we could barf if it isn't set. That would still
allow arbitrary stuff like:
the 6th of july
and keep Linus' favorite
I ate 6 hot dogs in July.
but disallow the most obviously wrong dates like:
t
usptream
total bogosity
> + 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)
> + die ("No tracking branch found for '%s'", ref);
> + if (tracking->merge && tracking->merge[0]->dst) {
> + *string = xstrdup(tracking->merge[0]->dst);
> + *len = strlen(*string);
> + return (char *)*string;
> + }
> + }
> +
I don't think it is a good idea to die for !tracking, but not for
!tracking->merge. That leads to inconsistent user-visible results:
$ git checkout HEAD^0
$ git rev-parse HEAD@{u}
fatal: No tracking branch found for 'HEAD'
$ git rev-parse bogus@{u}
bogus@{u}
fatal: ambiguous argument 'bogus@{u}': unknown revision or path not in the working tree.
Use '--' to separate paths from revisions
Shouldn't both cases say the same thing?
Also, your die message has two problems:
1. It looks at ref immediately after it is free'd, spewing junk.
2. Ref can be the empty string, which gives you the ugly:
fatal: No tracking branch found for ''
Should we munge that into HEAD (or "the current branch") for the
user?
-Peff
^ permalink raw reply
* Re: [PATCH v2] Introduce <branch>@{upstream} as shortcut to the tracked branch
From: Johannes Schindelin @ 2009-09-10 16:18 UTC (permalink / raw)
To: Jeff King
Cc: Junio C Hamano, Björn Steinbrink, Michael J Gruber,
Pete Wyckoff, git
In-Reply-To: <20090910155547.GA12409@coredump.intra.peff.net>
Hi,
On Thu, 10 Sep 2009, Jeff King wrote:
> I wrote:
>
> > + 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)
> > + die ("No tracking branch found for '%s'", ref);
> > + if (tracking->merge && tracking->merge[0]->dst) {
> > + *string = xstrdup(tracking->merge[0]->dst);
> > + *len = strlen(*string);
> > + return (char *)*string;
> > + }
> > + }
> > +
>
> I don't think it is a good idea to die for !tracking, but not for
> !tracking->merge. That leads to inconsistent user-visible results:
>
> $ git checkout HEAD^0
> $ git rev-parse HEAD@{u}
> fatal: No tracking branch found for 'HEAD'
> $ git rev-parse bogus@{u}
> bogus@{u}
> fatal: ambiguous argument 'bogus@{u}': unknown revision or path not in the working tree.
> Use '--' to separate paths from revisions
>
> Shouldn't both cases say the same thing?
>
> Also, your die message has two problems:
>
> 1. It looks at ref immediately after it is free'd, spewing junk.
>
> 2. Ref can be the empty string, which gives you the ugly:
>
> fatal: No tracking branch found for ''
>
> Should we munge that into HEAD (or "the current branch") for the
> user?
All true, but I cannot take care of it today.
Ciao,
Dscho
^ permalink raw reply
* Re: What's cooking in git.git (Sep 2009, #02; Mon, 07)
From: Daniel Barkalow @ 2009-09-10 16:18 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vtyzexnhm.fsf@alter.siamese.dyndns.org>
On Mon, 7 Sep 2009, Junio C Hamano wrote:
> * db/vcs-helper (2009-09-03) 16 commits
> - Allow helpers to report in "list" command that the ref is unchanged
> - Add support for "import" helper command
> - Add a config option for remotes to specify a foreign vcs
> - Allow programs to not depend on remotes having urls
> - Allow fetch to modify refs
> - Use a function to determine whether a remote is valid
> - Use a clearer style to issue commands to remote helpers
> - Make the "traditionally-supported" URLs a special case
> (merged to 'next' on 2009-08-07 at f3533ba)
> + Makefile: install hardlinks for git-remote-<scheme> supported by libcurl if possible
> + Makefile: do not link three copies of git-remote-* programs
> + Makefile: git-http-fetch does not need expat
> (merged to 'next' on 2009-08-06 at 15da79d)
> + http-fetch: Fix Makefile dependancies
> + Add transport native helper executables to .gitignore
> (merged to 'next' on 2009-08-05 at 33d491e)
> + git-http-fetch: not a builtin
> + Use an external program to implement fetching with curl
> + Add support for external programs for handling native fetches
> (this branch is used by jh/cvs-helper.)
>
> I'd really want to have this in 1.6.5 so that we can eject -lcurl from the
> main "git" binary. The patches in 'pu' got some review comments, and I
> thought Daniel's responses were sensible. Comments?
I'm pretty sure that there were no objections to 'Make the
"traditonally-supported"...' patch, and directly after that is a
reasonable stopping point (everything that used to work works the same,
nothing new and user-visible is introduced, the implementation is
reasonably straightforward and tidy, and the git binary doesn't
link against -lcurl). I'd suggest putting everything up to that point into
master and debating the rest of the series on its own merits (and likely
deferring it to post-1.6.5, since it doesn't have an in-tree user to
exercise it yet).
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* Re: obnoxious CLI complaints
From: Jakub Narebski @ 2009-09-10 16:50 UTC (permalink / raw)
To: Wincent Colaiuta; +Cc: Brendan Miller, git
In-Reply-To: <4C1FB36D-F8A6-4C01-A42A-8AD2355A9961@wincent.com>
Dnia czwartek 10. września 2009 00:06, Wincent Colaiuta napisał:
> El 09/09/2009, a las 23:54, Jakub Narebski escribió:
>> Brendan Miller <catphive@catphive.net> writes:
>>
>>> 5. Most commands require lots of flags, and don't have reasonable
>>> defaults. e.g. archive.
>>>
>>> $ git archive --format=tar --prefix=myproject/ HEAD |
>>> > gzip myproject.tar.gz
>>>
>>> Should just be:
>>> git archive
>>> run from the root of the repo.
>>
>> I'd rather not have "git archive" work without specifying tree-ish.
>
> Why, out of interest? I would've thought that HEAD would be a pretty
> good default, although I confess that I have never used "git archive"
> without specifying a particular signed tag.
First, it would be consistent with how ordinary archivers such as tar
or zip are used, where you have to specify list of files to archive
(in our case this list is HEAD). Second, I'd rather not accidentally
dump binary to terminal: "git archive [HEAD]" dumps archive to standard
output.
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: What's cooking in git.git (Sep 2009, #02; Mon, 07)
From: Johannes Schindelin @ 2009-09-10 16:53 UTC (permalink / raw)
To: Daniel Barkalow; +Cc: Junio C Hamano, git
In-Reply-To: <alpine.LNX.2.00.0909101206540.28290@iabervon.org>
Hi,
On Thu, 10 Sep 2009, Daniel Barkalow wrote:
> I'm pretty sure that there were no objections to 'Make the
> "traditonally-supported"...' patch,
Well, there were. By me.
There is a reason why you call the series "foreign" vcs helpers. And
that's because it would be very wrong to pretend that they are the rule,
and the current URL schemes the exception. Very wrong, indeed.
Thankyouvermuch,
Dscho
^ permalink raw reply
* Re: What's cooking in git.git (Sep 2009, #02; Mon, 07)
From: Daniel Barkalow @ 2009-09-10 17:55 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Junio C Hamano, git
In-Reply-To: <alpine.DEB.1.00.0909101852080.8306@pacific.mpi-cbg.de>
On Thu, 10 Sep 2009, Johannes Schindelin wrote:
> Hi,
>
> On Thu, 10 Sep 2009, Daniel Barkalow wrote:
>
> > I'm pretty sure that there were no objections to 'Make the
> > "traditonally-supported"...' patch,
>
> Well, there were. By me.
>
> There is a reason why you call the series "foreign" vcs helpers. And
> that's because it would be very wrong to pretend that they are the rule,
> and the current URL schemes the exception. Very wrong, indeed.
The current URL scheme *is* an "exception" to the "rule" that all remotes
are foreign, or the current "rule" that all remotes are ssh-style. Any
patterns that we currently support are handled by recognizing a particular
pattern (starts with "git://", starts with "rsync://", starts with
"https://", is a local file, is a local directory, etc), so they're all
special cases. They're further special cases by virtue of the fact that
the code to handle them is in the git distribution.
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* Re: obnoxious CLI complaints
From: Eric Schaefer @ 2009-09-10 18:18 UTC (permalink / raw)
To: git
In-Reply-To: <200909101116.55098.jnareb@gmail.com>
2009/9/10 Jakub Narebski <jnareb@gmail.com>:
> This is a good way to separate important from unimportant bug reports
> and feature requests ;-)
"Unimportant bug reports"? Interesting concept... ;-)
BTW: A bug tracker has the advantage that bugs don't fall on the
floor. They can be postponed for later fixing but you will not forget
them.
But you are right about feature request. You would either have to have
a rigorous policy of dropping bogus or unwanted (unimportant) requests
or you go with the mailing list approach to keep the pile from
stinking. ;-)
Eric
^ permalink raw reply
* Re: [PATCH v2] git-p4: Avoid modules deprecated in Python 2.6.
From: Junio C Hamano @ 2009-09-10 18:22 UTC (permalink / raw)
To: Reilly Grant; +Cc: git
In-Reply-To: <1252566158-13305-1-git-send-email-reillyeon@qotw.net>
Reilly Grant <reillyeon@qotw.net> writes:
> 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.
Thanks for a resend. Will apply.
^ permalink raw reply
* Re: [PATCH] Introduce <branch>@{tracked} as shortcut to the tracked branch
From: Junio C Hamano @ 2009-09-10 18:29 UTC (permalink / raw)
To: Jeff King
Cc: Johan Herland, git, Michael J Gruber, Johannes Schindelin,
Junio C Hamano, Björn Steinbrink, Pete Wyckoff
In-Reply-To: <20090910111156.GA2910@coredump.intra.peff.net>
Jeff King <peff@peff.net> writes:
> 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
After re-reading the discussion in the thread that contains the quoted
article, it sounds like we may want to fix "branch --track X Y". X does
not "track" Y in the same sense as origin/master "tracks" master at
origin. Rather, X builds on Y.
^ 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