* [PATCH 1/3] builtin-push: also ask config for remote information
From: Johannes Schindelin @ 2006-04-30 13:23 UTC (permalink / raw)
To: git
Now you can store your remote information in the config file like this:
[remote.upstream]
url = me@company.com:the-project
push = master:iceballs
Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
---
Obviously, this is on top of the patch to parse Pull: lines, too.
builtin-push.c | 33 +++++++++++++++++++++++++++++++++
1 files changed, 33 insertions(+), 0 deletions(-)
e55eb69f6332087c45082e16ccbf4e510d721e29
diff --git a/builtin-push.c b/builtin-push.c
index 4e659f0..e3131ed 100644
--- a/builtin-push.c
+++ b/builtin-push.c
@@ -72,6 +72,36 @@ #define MAX_REFSPECS 10
static int current_refspec = 0;
static char *refspecs_[MAX_REFSPECS];
+static int repo_len = 0;
+static const char *repo_ = NULL;
+static int current_uri = 0;
+static const char **uri_;
+
+static int get_value(const char* key, const char* value)
+{
+ if (!strncmp(key, "remote.", 7) && !strncmp(key + 7, repo_, repo_len)) {
+ if (!strcmp(key + 7 + repo_len, ".url"))
+ uri_[current_uri++] = strdup(value);
+ else if (!strcmp(key + 7 + repo_len, ".push")
+ && current_refspec < MAX_REFSPECS)
+ refspecs_[current_refspec++] = strdup(value);
+ }
+
+ return 0;
+}
+
+static int get_config_remotes_uri(const char *repo, const char *uri[MAX_URI])
+{
+ repo_len = strlen(repo);
+ repo_ = repo;
+ current_uri = 0;
+ uri_ = uri;
+
+ git_config(get_value);
+
+ return current_uri;
+}
+
static int get_remotes_uri(const char *repo, const char *uri[MAX_URI])
{
int n = 0;
@@ -153,6 +183,9 @@ static int get_uri(const char *repo, con
if (*repo != '/') {
current_refspec = 0;
+ n = get_config_remotes_uri(repo, uri);
+ if (n > 0)
+ return n;
n = get_remotes_uri(repo, uri);
if (n > 0)
return n;
--
1.3.1.g38c00-dirty
^ permalink raw reply related
* [PATCH 2/3] fetch, pull: ask config for remote information
From: Johannes Schindelin @ 2006-04-30 13:24 UTC (permalink / raw)
To: git
Now you can say
[remote.junio]
url = git://git.kernel.org/pub/scm/git/git.git
pull = next:next
in your .git/config.
Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
---
git-parse-remote.sh | 55 +++++++++++++++++++++++++++++++++++++++++++++++----
1 files changed, 51 insertions(+), 4 deletions(-)
5a1cf349639823183fce287be9f809d797f2cd84
diff --git a/git-parse-remote.sh b/git-parse-remote.sh
index c9b899e..8ce57c8 100755
--- a/git-parse-remote.sh
+++ b/git-parse-remote.sh
@@ -4,13 +4,43 @@ # git-ls-remote could be called from out
# this would fail in that case and would issue an error message.
GIT_DIR=$(git-rev-parse --git-dir 2>/dev/null) || :;
+if [ -d "$GIT_DIR"/remotes -a "$GIT_REWRITE_REMOTES" = true ]; then
+ echo "Rewriting $GIT_DIR/remotes" >&2
+ error=0
+ # rewrite into config
+ {
+ cd "$GIT_DIR"/remotes
+ ls | while read f; do
+ name=$(echo -n "$f" | tr -c "A-Za-z0-9" ".")
+ sed -n \
+ -e "s/^URL: /remote.$name.url . /p" \
+ -e "s/^Pull: /remote.$name.pull ^$ /p" \
+ -e "s/^Push: /remote.$name.push ^$ /p" \
+ < "$f"
+ done
+ echo done
+ } | while read key regex value; do
+ case $key in
+ done)
+ if [ $error = 0 ]; then
+ mv "$GIT_DIR"/remotes "$GIT_DIR"/remotes.old
+ fi ;;
+ *)
+ git-repo-config $key "$value" $regex || error=1 ;;
+ esac
+ done
+fi
+
get_data_source () {
case "$1" in
*/*)
# Not so fast. This could be the partial URL shorthand...
token=$(expr "z$1" : 'z\([^/]*\)/')
remainder=$(expr "z$1" : 'z[^/]*/\(.*\)')
- if test -f "$GIT_DIR/branches/$token"
+ if test "$(git-repo-config --get "remote.$token.url")"
+ then
+ echo config-partial
+ elif test -f "$GIT_DIR/branches/$token"
then
echo branches-partial
else
@@ -18,7 +48,10 @@ get_data_source () {
fi
;;
*)
- if test -f "$GIT_DIR/remotes/$1"
+ if test "$(git-repo-config --get "remote.$1.url")"
+ then
+ echo config
+ elif test -f "$GIT_DIR/remotes/$1"
then
echo remotes
elif test -f "$GIT_DIR/branches/$1"
@@ -35,6 +68,15 @@ get_remote_url () {
case "$data_source" in
'')
echo "$1" ;;
+ config-partial)
+ token=$(expr "z$1" : '\([^/]*\)/')
+ remainder=$(expr "z$1" : '[^/]*/\(.*\)')
+ url=$(git-repo-config --get "remote.$token.url")
+ echo "$url/$remainder"
+ ;;
+ config)
+ git-repo-config --get "remote.$1.url"
+ ;;
remotes)
sed -ne '/^URL: */{
s///p
@@ -56,8 +98,10 @@ get_remote_url () {
get_remote_default_refs_for_push () {
data_source=$(get_data_source "$1")
case "$data_source" in
- '' | branches | branches-partial)
+ '' | config-partial | branches | branches-partial)
;; # no default push mapping, just send matching refs.
+ config)
+ git-repo-config --get-all "remote.$1.push" ;;
remotes)
sed -ne '/^Push: */{
s///p
@@ -111,8 +155,11 @@ # Returns list of src: (no store), or sr
get_remote_default_refs_for_fetch () {
data_source=$(get_data_source "$1")
case "$data_source" in
- '' | branches-partial)
+ '' | config-partial | branches-partial)
echo "HEAD:" ;;
+ config)
+ canon_refs_list_for_fetch \
+ $(git-repo-config --get-all "remote.$1.pull") ;;
branches)
remote_branch=$(sed -ne '/#/s/.*#//p' "$GIT_DIR/branches/$1")
case "$remote_branch" in '') remote_branch=master ;; esac
--
1.3.1.g38c00-dirty
^ permalink raw reply related
* [PATCH 3/3] fetch: optionally store the current remote information in the config
From: Johannes Schindelin @ 2006-04-30 13:24 UTC (permalink / raw)
To: git
Instead of editing files, you can now say
git pull --store junio \
git://git.kernel.org/pub/scm/git/git.git next:next
and next time, just
git pull junio
Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
---
This is what the patch series is all about.
If there is no interest in a feature like this, let's just forget
about the whole "remote info in config" thing.
If there is interest, I could add the same functionality to
builtin-push.
Documentation/fetch-options.txt | 6 ++++++
git-fetch.sh | 19 +++++++++++++++++++
git-pull.sh | 8 ++++++--
3 files changed, 31 insertions(+), 2 deletions(-)
6bd937b0de211465e9664f8dc890fc5066617b73
diff --git a/Documentation/fetch-options.txt b/Documentation/fetch-options.txt
index 13f34d3..caf98de 100644
--- a/Documentation/fetch-options.txt
+++ b/Documentation/fetch-options.txt
@@ -16,6 +16,12 @@
fetches is a descendant of `<lbranch>`. This option
overrides that check.
+-S, \--store <nick>::
+ Store the URL and the refnames in the config file so that
+ `git fetch <nick>` repeats the exercise.
+ If the nick exists already, edit the URL, but append the
+ refnames.
+
\--no-tags::
By default, `git-fetch` fetches tags that point at
objects that are downloaded from the remote repository
diff --git a/git-fetch.sh b/git-fetch.sh
index 280f62e..ac122da 100755
--- a/git-fetch.sh
+++ b/git-fetch.sh
@@ -15,8 +15,10 @@ no_tags=
tags=
append=
force=
+keep=
verbose=
update_head_ok=
+store=
exec=
upload_pack=
while case "$#" in 0) break ;; esac
@@ -34,6 +36,10 @@ do
-f|--f|--fo|--for|--forc|--force)
force=t
;;
+ -S|--s|--st|--sto|--stor|--store)
+ store="$2"
+ shift
+ ;;
-t|--t|--ta|--tag|--tags)
tags=t
;;
@@ -235,6 +241,12 @@ then
fi
fi
+if test "$store"
+then
+ git-repo-config remote."$store".url $remote ||
+ die "Could not store into $store"
+fi
+
fetch_main () {
reflist="$1"
refs=
@@ -243,6 +255,11 @@ fetch_main () {
do
refs="$refs$LF$ref"
+ if test "$store"
+ then
+ git-repo-config remote."$store".pull "$ref" '^$'
+ fi
+
# These are relative path from $GIT_DIR, typically starting at refs/
# but may be HEAD
if expr "z$ref" : 'z\.' >/dev/null
@@ -381,6 +398,8 @@ fetch_main () {
fetch_main "$reflist"
+store=
+
# automated tag following
case "$no_tags$tags" in
'')
diff --git a/git-pull.sh b/git-pull.sh
index 4611ae6..ab0fba3 100755
--- a/git-pull.sh
+++ b/git-pull.sh
@@ -8,7 +8,7 @@ USAGE='[-n | --no-summary] [--no-commit]
LONG_USAGE='Fetch one or more remote refs and merge it/them into the current HEAD.'
. git-sh-setup
-strategy_args= no_summary= no_commit=
+strategy_args= no_summary= no_commit= store=
while case "$#,$1" in 0) break ;; *,-*) ;; *) break ;; esac
do
case "$1" in
@@ -31,6 +31,10 @@ do
esac
strategy_args="${strategy_args}-s $strategy "
;;
+ -S|--store)
+ store="-S $2"
+ shift
+ ;;
-h|--h|--he|--hel|--help)
usage
;;
@@ -43,7 +47,7 @@ do
done
orig_head=$(git-rev-parse --verify HEAD) || die "Pulling into a black hole?"
-git-fetch --update-head-ok "$@" || exit 1
+git-fetch --update-head-ok $store "$@" || exit 1
curr_head=$(git-rev-parse --verify HEAD)
if test "$curr_head" != "$orig_head"
--
1.3.1.g38c00-dirty
^ permalink raw reply related
* Re: cg-clone not fetching all tags?
From: Wolfgang Denk @ 2006-04-30 13:48 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, pasky
In-Reply-To: <7vaca31z50.fsf@assigned-by-dhcp.cox.net>
Dear Junio,
in message <7vaca31z50.fsf@assigned-by-dhcp.cox.net> you wrote:
>
> I suspect there is no need to manufacture the tag. Something
> like this should do.
Great! Thanks a lot.
> *WARNING* Since I do not do Porcelain, and I am not a Cogito
> user, this is obviously untested. In addition, I am seriously
> drunk right now...
Good enough. This one actually works:
> -- >8 --
> [PATCH] (cogito) Auto-follow lightweight tags as well.
--- a/cg-fetchG 2006-04-10 19:14:14.000000000 +0200
+++ b/cg-fetch 2006-04-30 14:35:03.000000000 +0200
@@ -211,7 +211,8 @@
git-ls-remote --tags "$uri" |
# SHA1 refs/tags/v0.99.8^{} --> SHA1 tags/v0.99.8
# where SHA1 is the object v0.99.8 tag points at.
- sed -ne 's:\([^ ]\) refs/\(tags/.*\)^{}$:\1 \2:p' |
+ sed -n -e 's:\([^ ]\) refs/\(tags/.*\)^{}$:\1 \2:p' \
+ -e 's:\([^ ]\) refs/\(tags/.*\)$:\1 \2:p' | \
while read sha1 tagname; do
# Do we have the tag itself?
[ -s "$_git/refs/$tagname" ] && continue
Best regards,
Wolfgang Denk
--
Software Engineering: Embedded and Realtime Systems, Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
It's hard to think of you as the end result of millions of years of
evolution.
^ permalink raw reply
* Re: [PATCH 3/3] fetch: optionally store the current remote information in the config
From: Jakub Narebski @ 2006-04-30 14:19 UTC (permalink / raw)
To: git
In-Reply-To: <Pine.LNX.4.63.0604301524080.2646@wbgn013.biozentrum.uni-wuerzburg.de>
There was thread about storing somewhere default branch we merge to during
pull, instead of using always surrent one. Different schemes were proposed,
most of them depending on the remotes configuration being available [also]
in config file.
Perhaps it would be easiest to extend existing notation in the following
way:
<from>:<to>[:<merge>]
By the way: it would be nice to have command/script to trasform freely
between 'remotes/' and config file.
P.S. I wonder if it would be difficult to implement 'include <file>' for
config file...
--
Jakub Narebski
Warsaw, Poland
^ permalink raw reply
* Re: [PATCH 3/3] fetch: optionally store the current remote information in the config
From: sean @ 2006-04-30 14:30 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <Pine.LNX.4.63.0604301524080.2646@wbgn013.biozentrum.uni-wuerzburg.de>
On Sun, 30 Apr 2006 15:24:22 +0200 (CEST)
Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> Instead of editing files, you can now say
>
> git pull --store junio \
> git://git.kernel.org/pub/scm/git/git.git next:next
>
> and next time, just
>
> git pull junio
>
> Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
>
> ---
>
> This is what the patch series is all about.
>
> If there is no interest in a feature like this, let's just forget
> about the whole "remote info in config" thing.
>
> If there is interest, I could add the same functionality to
> builtin-push.
Well I agree with you that doing something like this is important. We
should take this moment of moving things to the config file to correct
the terminology and help make things clear. We're not storing "Pull:"
information, we're storing config/remote.$NICK.fetch data. It's really
used just by fetch, pull just happens to call fetch.
Along that same line of reasoning, it seems more appropriate to use
git fetch --store ... rather than git pull --store ... to set this
information. And there needs to be a way to change and delete the
nick information, perhaps git fetch store junio "" would delete the
entry. Or maybe people should just be instructed to use git-repo-config
for setting, changing and deleting?
Pull needs additional logic that allows it to merge from the proper
local branch after it calls fetch. Right now it just uses whatever
fetch sets as FETCH_HEAD. It's not clear to me what is set as
FETCH_HEAD when multiple refs are fetched from the remote. It'll
be even more confusing once it's possible to fetch from multiple
remotes at once.
As for these specific patches, it doesn't appear that your change to
builtin-push allows the push variable to hold more than one remote
repo URI or even more than one refspec, or did I misread that?
Also it seems that the refspec is used from the config file even if
the user tries to override it by specifying an alternative on the
command line.
Sean
^ permalink raw reply
* Re: [RFC] [PATCH 0/5] Implement 'prior' commit object links (and
From: Jakub Narebski @ 2006-04-30 15:21 UTC (permalink / raw)
To: git
In-Reply-To: <e30k0n$ij5$1@sea.gmane.org>
Jakub Narebski wrote:
> Junio C Hamano wrote:
>
>> Jakub Narebski <jnareb@gmail.com> writes:
>>
>>> * "prior" - heads that represent topic branch merges
>>
>> This is not any different from usual "parent" at all (but you
>> have to think about it a bit to realize it).
> [cut]
> Thanks for an explanation.
>
> I would say that "prior" is not THAT different from usual "parent",
> rather than it is not ANY different.
>
> My doubts about recording previous head of a "union" (pu-like) branch
> is that for merge (e.g. 'pu' to 'next', cherrypick to/from 'pu', 'pu'
> rebase) is that for merge algorithm all parents are equivalent, with
> eventual exception of first which can be treated special ('ours').
Additionally with "prior" (or at least some convention on which of parents
is to prior head of "union (pu-like) branch) I think we could fast-forward
such branches...
--
Jakub Narebski
Warsaw, Poland
^ permalink raw reply
* Re: [PATCH 3/3] fetch: optionally store the current remote information in the config
From: Johannes Schindelin @ 2006-04-30 15:49 UTC (permalink / raw)
To: sean; +Cc: git
In-Reply-To: <BAYC1-PASMTP08069B2CE6005391A1AFF9AEB00@CEZ.ICE>
Hi,
On Sun, 30 Apr 2006, sean wrote:
> On Sun, 30 Apr 2006 15:24:22 +0200 (CEST)
> Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
>
> > Instead of editing files, you can now say
> >
> > git pull --store junio \
> > git://git.kernel.org/pub/scm/git/git.git next:next
> >
> > and next time, just
> >
> > git pull junio
> >
> > Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
> >
> > ---
> >
> > This is what the patch series is all about.
> >
> > If there is no interest in a feature like this, let's just forget
> > about the whole "remote info in config" thing.
> >
> > If there is interest, I could add the same functionality to
> > builtin-push.
>
> Well I agree with you that doing something like this is important. We
> should take this moment of moving things to the config file to correct
> the terminology and help make things clear. We're not storing "Pull:"
> information, we're storing config/remote.$NICK.fetch data. It's really
> used just by fetch, pull just happens to call fetch.
I have no strong feelings either way.
> Along that same line of reasoning, it seems more appropriate to use
> git fetch --store ... rather than git pull --store ... to set this
> information.
Both works.
> And there needs to be a way to change and delete the nick information,
> perhaps git fetch store junio "" would delete the entry. Or maybe
> people should just be instructed to use git-repo-config for setting,
> changing and deleting?
The latter should be done, because "git fetch" really is about fetching,
not playing games with the config.
> Pull needs additional logic that allows it to merge from the proper
> local branch after it calls fetch. Right now it just uses whatever
> fetch sets as FETCH_HEAD. It's not clear to me what is set as
> FETCH_HEAD when multiple refs are fetched from the remote. It'll
> be even more confusing once it's possible to fetch from multiple
> remotes at once.
FETCH_HEAD can contain multiple refs. And I don't get the part about
fetching from multiple remotes: my patch does not allow for that.
> As for these specific patches, it doesn't appear that your change to
> builtin-push allows the push variable to hold more than one remote
> repo URI or even more than one refspec, or did I misread that?
But it does! Note the "uri_[current_uri++]" part of the patch.
> Also it seems that the refspec is used from the config file even if
> the user tries to override it by specifying an alternative on the
> command line.
No. It is only used when there were no refspecs specified on the command
line:
if (refspec_nr == 0)
set_refspecs((const char**)refspecs_, current_refspec);
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH 3/3] fetch: optionally store the current remote information in the config
From: Johannes Schindelin @ 2006-04-30 15:52 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <e32h0o$15n$1@sea.gmane.org>
Hi,
On Sun, 30 Apr 2006, Jakub Narebski wrote:
> There was thread about storing somewhere default branch we merge to during
> pull, instead of using always surrent one. Different schemes were proposed,
> most of them depending on the remotes configuration being available [also]
> in config file.
I was not following that thread closely, since it became too confusing for
me. However, I think that my patch could be a start in that direction.
> By the way: it would be nice to have command/script to trasform freely
> between 'remotes/' and config file.
If you set the environment variable GIT_REWRITE_REMOTES to "true", and
call git-parse-remotes.sh, it will do the rewriting to the config file.
Obviously, I did not test that part of the patch all that well.
> P.S. I wonder if it would be difficult to implement 'include <file>' for
> config file...
You really need that?
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH 3/3] fetch: optionally store the current remote information in the config
From: Jakub Narebski @ 2006-04-30 16:07 UTC (permalink / raw)
To: git
In-Reply-To: <Pine.LNX.4.63.0604301749130.3641@wbgn013.biozentrum.uni-wuerzburg.de>
Johannes Schindelin wrote:
> On Sun, 30 Apr 2006, Jakub Narebski wrote:
>
>> P.S. I wonder if it would be difficult to implement 'include <file>' for
>> config file...
>
> You really need that?
Need? Not exactly. I don't think git ever reach complexity of Apache or
Samba configuration files, and _need_ for includes. Still dividing separate
areas of configuration (core, user, default commands options, remotes) has
it's merits.
--
Jakub Narebski
Warsaw, Poland
^ permalink raw reply
* Re: [PATCH 3/3] fetch: optionally store the current remote information in the config
From: sean @ 2006-04-30 16:37 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <Pine.LNX.4.63.0604301743370.3641@wbgn013.biozentrum.uni-wuerzburg.de>
On Sun, 30 Apr 2006 17:49:06 +0200 (CEST)
Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> > the terminology and help make things clear. We're not storing "Pull:"
> > information, we're storing config/remote.$NICK.fetch data. It's really
> > used just by fetch, pull just happens to call fetch.
>
> I have no strong feelings either way.
Yeah, once you "get" it, it's not a problem; but it's not easy when you're
just learning git to separate fetch and pull. It's made harder if git
can't even keep them straight internally. :o/
[...]
> The latter should be done, because "git fetch" really is about fetching,
> not playing games with the config.
Then we should also remove the --store option from pull and fetch. It
can be set with git-repo-config.
> FETCH_HEAD can contain multiple refs.
Which head does git-pull then use to merge, all of them?
> And I don't get the part about fetching from multiple remotes:
> my patch does not allow for that.
Actually it does :o) User just needs multiple remote.$nick.url entries
in his config.
> But it does! Note the "uri_[current_uri++]" part of the patch.
[...]
> No. It is only used when there were no refspecs specified on the command
> line:
>
> if (refspec_nr == 0)
> set_refspecs((const char**)refspecs_, current_refspec);
Right you are, on both counts.
Sean
^ permalink raw reply
* Re: [PATCH 3/3] fetch: optionally store the current remote information in the config
From: Jakub Narebski @ 2006-04-30 16:51 UTC (permalink / raw)
To: git
In-Reply-To: <BAYC1-PASMTP03034CC49FFA3042562BCBAEB00@CEZ.ICE>
sean wrote:
> On Sun, 30 Apr 2006 17:49:06 +0200 (CEST)
> Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
>
>
>> > the terminology and help make things clear. We're not storing "Pull:"
>> > information, we're storing config/remote.$NICK.fetch data. It's really
>> > used just by fetch, pull just happens to call fetch.
>>
>> I have no strong feelings either way.
>
> Yeah, once you "get" it, it's not a problem; but it's not easy when you're
> just learning git to separate fetch and pull. It's made harder if git
> can't even keep them straight internally. :o/
Well, it could also contain default head we merge to (instead of using what
fetch set as FETCH_HEAD, usually current head while fetching), as
pull = master:origin:merger
> [...]
>
> > The latter should be done, because "git fetch" really is about fetching,
> > not playing games with the config.
>
> Then we should also remove the --store option from pull and fetch. It
> can be set with git-repo-config.
The --store option is similar to using 'git checkout -b newbranch' as a
shortcut for 'git branch newbranch' followed by 'git checkout newbranch'.
--
Jakub Narebski
Warsaw, Poland
^ permalink raw reply
* Re: [PATCH 3/3] fetch: optionally store the current remote information in the config
From: Johannes Schindelin @ 2006-04-30 17:09 UTC (permalink / raw)
To: sean; +Cc: git
In-Reply-To: <BAYC1-PASMTP03034CC49FFA3042562BCBAEB00@CEZ.ICE>
Hi,
On Sun, 30 Apr 2006, sean wrote:
> On Sun, 30 Apr 2006 17:49:06 +0200 (CEST)
> Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
>
>
> > The latter should be done, because "git fetch" really is about fetching,
> > not playing games with the config.
>
> Then we should also remove the --store option from pull and fetch. It
> can be set with git-repo-config.
Well, with "--store", "git fetch" still fetches. It just happens to write
down -- for convenience -- the possibly long url and the refspecs.
> > FETCH_HEAD can contain multiple refs.
>
> Which head does git-pull then use to merge, all of them?
The first one.
> > And I don't get the part about fetching from multiple remotes:
> > my patch does not allow for that.
>
> Actually it does :o) User just needs multiple remote.$nick.url entries
> in his config.
You are right. But you are also wrong. The patch uses
git-repo-config --get remote.$nick.url
which fails if there are more than one matching line. Note that
"--get-all" is used to get _all_ remote.$nick.pull lines...
But of course, Linus "built git-push in" so that multiple urls are
allowed and handled. It is probably confusing, if you can push but
cannot fetch with the same remote information... But then, I fail to see
how you could possibly specify the refspecs for the different urls.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH 3/3] fetch: optionally store the current remote information in the config
From: sean @ 2006-04-30 17:19 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <e32pto$p3a$1@sea.gmane.org>
On Sun, 30 Apr 2006 18:51:54 +0200
Jakub Narebski <jnareb@gmail.com> wrote:
> Well, it could also contain default head we merge to (instead of using what
> fetch set as FETCH_HEAD, usually current head while fetching), as
>
> pull = master:origin:merger
Then lets take a simple case; we clone a new repo, and it has:
[remote.origin]
url = git://outthere.com
fetch = master:origin:master
fetch = next:next
And we create two new branches:
git branch br1 next ; git branch br2 next
Now say that we want a bare "git pull" to cause a merge from
the "next" branch regardless of which new branch we have checked
out. In the above scheme we have to do something like:
fetch = next:next:br1:br2
That doesn't look right. It seems better to have:
[branch.origin]
description = "Pristine master from Junio"
[branch.br1]
description = "blah"
defaultMerge = "next"
[branch.br2]
description = "More blah"
LastMerge = 03/27/2008 3am
defaultMerge = "next"
qgitTagColor = Blue
> The --store option is similar to using 'git checkout -b newbranch' as a
> shortcut for 'git branch newbranch' followed by 'git checkout newbranch'.
Okay.
Sean
^ permalink raw reply
* Re: [PATCH 3/3] fetch: optionally store the current remote information in the config
From: sean @ 2006-04-30 17:28 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <Pine.LNX.4.63.0604301859280.3977@wbgn013.biozentrum.uni-wuerzburg.de>
On Sun, 30 Apr 2006 19:09:18 +0200 (CEST)
Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> > Which head does git-pull then use to merge, all of them?
>
> The first one.
Which can be confusing since you can only specify one "first one"
in a remotes file (or .git/config) yet you can pull while
having any random local branch being checkout out, each with
a different merge branch being appropriate.
> You are right. But you are also wrong. The patch uses
>
> git-repo-config --get remote.$nick.url
>
> which fails if there are more than one matching line. Note that
> "--get-all" is used to get _all_ remote.$nick.pull lines...
>
> But of course, Linus "built git-push in" so that multiple urls are
> allowed and handled. It is probably confusing, if you can push but
> cannot fetch with the same remote information... But then, I fail to see
> how you could possibly specify the refspecs for the different urls.
Yeah, I was speaking only of git push, but see you were speaking of
fetch.
Anyway, thanks for helping me understand your proposal, it seems
flexible enough to handle just about any case one might want to
throw at it.
Cheers,
Sean
^ permalink raw reply
* Re: [PATCH 3/3] fetch: optionally store the current remote information in the config
From: Jakub Narebski @ 2006-04-30 17:35 UTC (permalink / raw)
To: git
In-Reply-To: <BAYC1-PASMTP054CF113E95D45B8778DACAEB00@CEZ.ICE>
sean wrote:
> [branch.origin]
> description = "Pristine master from Junio"
I'd like to add
> pristine = true
and for git to warn if we try to commit to branch which is supposed to be
pristine (tracking external repository).
--
Jakub Narebski
Warsaw, Poland
^ permalink raw reply
* [PATCH] Conditionally define _GNU_SOURCE in mailinfo.c
From: Art Haas @ 2006-04-30 18:19 UTC (permalink / raw)
To: Junio C Hamano, git
Hi.
Place the '#define _GNU_SOURCE' within an #ifndef/#endif block testing
if '_GNU_SOURCE' is already defined.
Signed-off-by: Art Haas <ahaas@airmail.net>
---
mailinfo.c | 2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
d3932a8fca2faac8ed14bfd0e65c1f0135dc1d4b
diff --git a/mailinfo.c b/mailinfo.c
index b276519..4b99ccf 100644
--- a/mailinfo.c
+++ b/mailinfo.c
@@ -2,7 +2,9 @@
* Another stupid program, this one parsing the headers of an
* email to figure out authorship and subject
*/
+#ifndef _GNU_SOURCE
#define _GNU_SOURCE
+#endif
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
--
1.3.1.g66ae
--
Man once surrendering his reason, has no remaining guard against absurdities
the most monstrous, and like a ship without rudder, is the sport of every wind.
-Thomas Jefferson to James Smith, 1822
^ permalink raw reply related
* [RFC] Terms to add to glossary
From: Jakub Narebski @ 2006-04-30 19:18 UTC (permalink / raw)
To: git
I'd like the following terms to be added to and described in git glossary:
Any takers?
topic branches::
pickaxe::
cherry pick:: (cherry picking)
refspec::
patch::
rev::
revert:: (commit)
fast-forward:: (branch)
annotate:: (blame)
symbolic ref::
BTW. it might be worth to take a look at
http://en.wikipedia.org/wiki/Revision_control#Vocabulary
and either expand git glossary, or correct Wikipedia entry.
--
Jakub Narebski
Warsaw, Poland
^ permalink raw reply
* Re: [PATCH] git builtin "push"
From: Jeff Garzik @ 2006-04-30 19:58 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Junio C Hamano, Git Mailing List
In-Reply-To: <Pine.LNX.4.64.0604292111570.9901@g5.osdl.org>
Linus Torvalds wrote:
> Now, the reason I did it as a built-in is partly because it's yet another
> step on relying less on shell, but it's actually mostly because I've
> wanted to be able to push to _multiple_ repositories, and the most obvious
> and simplest interface for that would seem be to just have a "remotes"
> file that has multiple URL entries.
Thanks! This is why I still use rsync, even though everybody and their
mother tells me "Linus says rsync is deprecated."
Fact is, rsync is still the best to push a _bunch_ of branches, in the
same tree, all in one command. In an attempt to get away from rsync, I
even tried putting multiple git:// entries into .git/remotes/origin,
then doing "git push" with no args, without success.
Each time I have a non-trivial libata update, I've updated twelve (12)
branches, and think its highly silly to have to run
url=git://git.kernel.org/...jgarzik/...
git push $url $branch:$branch
twelve times.
Jeff
^ permalink raw reply
* Re: [PATCH] git builtin "push"
From: Linus Torvalds @ 2006-04-30 20:07 UTC (permalink / raw)
To: Jeff Garzik; +Cc: Junio C Hamano, Git Mailing List
In-Reply-To: <445516F5.1090204@garzik.org>
On Sun, 30 Apr 2006, Jeff Garzik wrote:
> Linus Torvalds wrote:
> > Now, the reason I did it as a built-in is partly because it's yet another
> > step on relying less on shell, but it's actually mostly because I've wanted
> > to be able to push to _multiple_ repositories, and the most obvious and
> > simplest interface for that would seem be to just have a "remotes" file that
> > has multiple URL entries.
>
> Thanks! This is why I still use rsync, even though everybody and their mother
> tells me "Linus says rsync is deprecated."
No. You're using rsync because you're actively doing something _wrong_.
> Fact is, rsync is still the best to push a _bunch_ of branches, in the same
> tree, all in one command.
Not so. My builtin thing doesn't help at all, because it doesn't _need_ to
help that case. You can already push as many branches as you want with the
old "git push".
My builtin thing helps push to multiple _repositories_, not to multiple
branches. I push out my stuff to two separate repos at master.kernel.org,
and one at an osdl.org server machine, because if I lose my tree, I want
to be sure I have alternate backups.
> In an attempt to get away from rsync, I even tried putting multiple
> git:// entries into .git/remotes/origin, then doing "git push" with no
> args, without success.
That's not how it works, and not how it has ever worked.
The way it works is that
"git push repo"
with no branch specs will update all branches that are IN COMMON between
your tree and the repository you're pushing to. In other words, it's meant
to sync up the branches that you have already pushed.
If you want to push other branches, you need to do
git push repo branch1 branch2 branch3 ...
or
git push --all repo
where the latter does exactly what it says (use "--tags" instead of
"--all" to just send all tags).
In all cases you will find that it's a hell of a lot more efficient than
rsync ever has been.
Linus
^ permalink raw reply
* Re: [PATCH] git builtin "push"
From: sean @ 2006-04-30 20:50 UTC (permalink / raw)
To: Linus Torvalds; +Cc: jeff, junkio, git
In-Reply-To: <Pine.LNX.4.64.0604301303010.5231@g5.osdl.org>
On Sun, 30 Apr 2006 13:07:42 -0700 (PDT)
Linus Torvalds <torvalds@osdl.org> wrote:
> The way it works is that
>
> "git push repo"
>
> with no branch specs will update all branches that are IN COMMON between
> your tree and the repository you're pushing to. In other words, it's meant
> to sync up the branches that you have already pushed.
True, as long as you don't have any Push: lines in your .git/remotes/repo
file. Any such lines act just like you gave them on the command line
which afaik effectively removes the ability to say "update all branches
we have in common".
Sean
^ permalink raw reply
* Re: [PATCH] git builtin "push"
From: Linus Torvalds @ 2006-04-30 21:05 UTC (permalink / raw)
To: sean; +Cc: jeff, junkio, git
In-Reply-To: <BAYC1-PASMTP037751CEC096DA29400513AEB00@CEZ.ICE>
On Sun, 30 Apr 2006, sean wrote:
> On Sun, 30 Apr 2006 13:07:42 -0700 (PDT)
> Linus Torvalds <torvalds@osdl.org> wrote:
>
> > The way it works is that
> >
> > "git push repo"
> >
> > with no branch specs will update all branches that are IN COMMON between
> > your tree and the repository you're pushing to. In other words, it's meant
> > to sync up the branches that you have already pushed.
>
> True, as long as you don't have any Push: lines in your .git/remotes/repo
> file. Any such lines act just like you gave them on the command line
> which afaik effectively removes the ability to say "update all branches
> we have in common".
Ok, so my built-in version "fixes" that "feature".
Linus
^ permalink raw reply
* Re: [PATCH] git builtin "push"
From: Jeff Garzik @ 2006-04-30 21:30 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Junio C Hamano, Git Mailing List
In-Reply-To: <Pine.LNX.4.64.0604301303010.5231@g5.osdl.org>
Linus Torvalds wrote:
> If you want to push other branches, you need to do
>
> git push repo branch1 branch2 branch3 ...
>
> or
>
> git push --all repo
>
> where the latter does exactly what it says (use "--tags" instead of
> "--all" to just send all tags).
After experimenting, "--all" does indeed provide most of the features
that rsync provides. A few minor niggles:
1) Doesn't propagate local branch deletions to the remote, like rsync does.
2) git-push "-f" doesn't seem to work, but "--force" does.
3) You still have to provide a $repo argument to 'git pull $repo'.
Would like to list the default remote push URL in
.git/remotes/{somefile} so that I need only to do "git push --all" to
have changes send to any number of remote servers.
4) Propagation of alternatives is unclear (at least in docs). Without
my current pack file pre-sharing and hardlinking, I fear needlessly
uploading vanilla linux-2.6.git changes back to kernel.org, when I do a
push. Currently, pack files are downloaded _once_ from kernel.org to
local, and never re-uploaded.
Regards,
Jeff
^ permalink raw reply
* Re: [PATCH] git builtin "push"
From: Junio C Hamano @ 2006-04-30 21:47 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0604301405070.2922@g5.osdl.org>
Linus Torvalds <torvalds@osdl.org> writes:
>> True, as long as you don't have any Push: lines in your .git/remotes/repo
>> file. Any such lines act just like you gave them on the command line
>> which afaik effectively removes the ability to say "update all branches
>> we have in common".
>
> Ok, so my built-in version "fixes" that "feature".
>
> Linus
Alternatively/additionally you could do something like the
attached patch. However,...
I suspect that destination repositories that you would want to
define Push: and the ones you do not want to have any Push: are
of different nature and you would not mix them. When you do
want to have any Push: line for a repository, you would _never_
want to use the "matching refs" semantics for that repository.
So in that sense, the "fix" is not necessary, and fixing it
would probably lead to more confusion.
The Push: lines can do two related but independent things:
- limit the set of refs that are published (hide the uncooked topics)
- remap the source and destination refs (e.g. push master to origin)
The first can be done by not having Push: at all and by solely
relying on "matching refs" semantics. Then usually you can just
keep doing "git push <destination>" until you have something new
to add, at that point you say "git push <destination>
<newbranch>" just once, and after that keep doing the "matching
refs" push. You are having the remote repository remember what
the set of refs you would want there, instead of listing them on
the local "Push:" lines. All should work well that way.
I use Push: lines to push into my private, non-bare, repository
at kernel.org machines for the second reason. I have:
Push: heads/master:heads/origin
Push: heads/next:heads/next
Push: +heads/pu:heads/pu
Push: heads/maint:heads/maint
and leave the "master" branch checked out over there. After
pushing, I log-in, and start my work by "git pull . origin".
The "matching refs" feature actively does a wrong thing to
remote repositories managed this way.
-- >8 --
[PATCH] git push --common <repo>
If you usually push only specific branches, it is handy to have
Push: lines only for those branches in your remotes/<repo> file.
But with that, you cannot access the underlying git-send-pack's
ability to push "only matching refs". The flag --common can be
given to ignore Push: lines and push only matching refs.
---
diff --git a/git-push.sh b/git-push.sh
index f10cadb..381b76f 100755
--- a/git-push.sh
+++ b/git-push.sh
@@ -11,6 +11,7 @@ has_exec=
has_thin=--thin
remote=
do_tags=
+do_common=
while case "$#" in 0) break ;; esac
do
@@ -19,6 +20,8 @@ do
has_all=--all ;;
--tags)
do_tags=yes ;;
+ --common)
+ do_common=yes ;;
--force)
has_force=--force ;;
--exec=*)
@@ -45,10 +48,21 @@ esac
. git-parse-remote
remote=$(get_remote_url "$@")
-case "$has_all" in
---all)
+case "$has_all,$do_common" in
+--all,yes)
+ die "Both --common and --all given." ;;
+--all,)
set x ;;
-'')
+,yes)
+ case "$do_tags,$#" in
+ ,1)
+ set x ;;
+ yes,*)
+ die "Both --common and --tags given." ;;
+ *)
+ die "Both --common and an explicit refspec given." ;;
+ esac ;;
+,)
case "$do_tags,$#" in
yes,1)
set x $(cd "$GIT_DIR/refs" && find tags -type f -print) ;;
^ permalink raw reply related
* Re: [PATCH] Conditionally define _GNU_SOURCE in mailinfo.c
From: Junio C Hamano @ 2006-04-30 21:51 UTC (permalink / raw)
To: Art Haas; +Cc: git
In-Reply-To: <20060430181931.GE6626@artsapartment.org>
"Art Haas" <ahaas@airmail.net> writes:
> Place the '#define _GNU_SOURCE' within an #ifndef/#endif block testing
> if '_GNU_SOURCE' is already defined.
>
> d3932a8fca2faac8ed14bfd0e65c1f0135dc1d4b
> diff --git a/mailinfo.c b/mailinfo.c
> index b276519..4b99ccf 100644
> --- a/mailinfo.c
> +++ b/mailinfo.c
> @@ -2,7 +2,9 @@
> * Another stupid program, this one parsing the headers of an
> * email to figure out authorship and subject
> */
> +#ifndef _GNU_SOURCE
> #define _GNU_SOURCE
> +#endif
Hmph.... I understand that this makes any difference only if
you use -D_GNU_SOURCE in CFLAGS, which implies there are _other_
things you need to have "#define _GNU_SOURCE" to compile for
your setup. I wonder what it is...
^ 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