* Re: [PATCH 3/3] rebase: refuse to rebase with -s ours
From: Thomas Rast @ 2009-11-15 18:44 UTC (permalink / raw)
To: Sverre Rabbelier
Cc: git, Nicolas Sebrecht, Baz, Peter Krefting, Johannes Schindelin,
Björn Steinbrink
In-Reply-To: <fabb9a1e0911151039g7c7373b5o3c14a9056c419f6@mail.gmail.com>
Sverre Rabbelier wrote:
> Heya,
>
> On Sun, Nov 15, 2009 at 19:25, Thomas Rast <trast@student.ethz.ch> wrote:
> > + if test "$STRATEGY" = "-s ours"
>
> Is this solid? Would "-s ours" (two spaces) work?
Well, the variable is set by the case immediately before the new test:
case "$#,$1" in
*,*=*)
STRATEGY="-s "$(expr "z$1" : 'z-[^=]*=\(.*\)') ;;
1,*)
usage ;;
*)
STRATEGY="-s $2"
shift ;;
esac
I didn't want to split that for a direct comparison with the second
half of the value, but unless I'm missing something, you'd have to say
-s ' ours' to make the test fail.
--
Thomas Rast
trast@{inf,student}.ethz.ch
^ permalink raw reply
* Re: [PATCH] Update 'git remote' usage and man page to match.
From: Tim Henigan @ 2009-11-15 19:29 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Nanako Shiraishi, git
In-Reply-To: <7vr5s0qhnp.fsf@alter.siamese.dyndns.org>
On Sun, Nov 15, 2009 at 4:08 AM, Junio C Hamano <gitster@pobox.com> wrote:
> You noticed a good issue to address. That is, "git remote -h" output
> looks Ok but "git remote add -h" and friends show way suboptimal help.
> The current output looks like:
>
> $ git remote add -h
> usage: git remote [-v | --verbose]
> or: git remote add [-t <branch>] [-m <master>] [-f] [--mirror] <name>
> <url>
> or: git remote rename <old> <new>
> or: git remote rm <name>
> or: git remote set-head <name> [-a | -d | <branch>]
> or: git remote show [-n] <name>
> or: git remote prune [-n | --dry-run] <name>
> or: git remote [-v | --verbose] update [-p | --prune] [group]
>
> add specific options
> -f, --fetch fetch the remote branches
> -t, --track <branch> branch(es) to track
> -m, --master <branch>
> master branch
> --mirror no separate remotes
>
> As the user already knows "add" is the subcommand she is interested in,
> this is insane.
>
> My preference is:
>
> (1) to drop your change to the synopsis section ("git remote -v" is a
> valid way to get more verbose information, isn't it?);
Sounds reasonable.
> (2) to keep the current output of "git remote -h";
The usage string for "git remote update" should still be modified to match
the changes made to the man page in commit b344e161. That commit
taught 'git remote update' to understand [group | remote]. The man page
was changed to document the new feature, but the usage string was not.
I will send v2 of this patch to make this change and add the author of
b344e161 (Finn Arne Gangstad) to the CC list to confirm.
> (3) to drop the general description section altogether from "git remote
> add -h" output;
Okay, I will look into this. If I find a good solution, I will send
an RFC patch
that updates 'git remote add'. Based on the email threads you cited below,
it sounds like the usage string for 'git push' is a good model to
follow. If the
change looks sane, I will follow up with a patch series that updates each of
the 'git remote' subcommands.
> I think this is related to a bigger issue of how we generally would want
> to show help in response to "-h", and also in the manual pages.
>
> http://thread.gmane.org/gmane.comp.version-control.git/129399/focus=129424
> http://thread.gmane.org/gmane.comp.version-control.git/129906/focus=130646
^ permalink raw reply
* [PATCH v2] Update 'git remote update' usage string to match man page.
From: Tim Henigan @ 2009-11-15 19:46 UTC (permalink / raw)
To: Junio C Hamano, finnag; +Cc: git, Nanako Shiraishi
Commit b344e161 taught 'git remote update' to understand
[group | remote] as its argument. The man page was updated
to document this change, but the usage string was not.
Signed-off-by: Tim Henigan <tim.henigan@gmail.com>
---
This updates the patch found at:
http://article.gmane.org/gmane.comp.version-control.git/132953
The change to the man page synopsis has been dropped. This
patch now only updates the usage string in builtin-remote.c.
The author of commit b344e161 has been added to the CC list.
Based on advice from Junio, further changes to the usage string
and man pages will be explored in a separate patch series.
builtin-remote.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/builtin-remote.c b/builtin-remote.c
index 0777dd7..c4edb86 100644
--- a/builtin-remote.c
+++ b/builtin-remote.c
@@ -15,7 +15,7 @@ static const char * const builtin_remote_usage[] = {
"git remote set-head <name> [-a | -d | <branch>]",
"git remote show [-n] <name>",
"git remote prune [-n | --dry-run] <name>",
- "git remote [-v | --verbose] update [-p | --prune] [group]",
+ "git remote [-v | --verbose] update [-p | --prune] [group | remote]",
NULL
};
--
1.6.5.2.185.gb7fba.dirty
^ permalink raw reply related
* Re: Question about "git pull --rebase"
From: Johan 't Hart @ 2009-11-15 19:47 UTC (permalink / raw)
To: Francis Moreau; +Cc: git
In-Reply-To: <m2my2noo0g.fsf@gmail.com>
Francis Moreau schreef:
> Looks like you did :)
>
> I've been somehow confused by the git-pull man page, which says:
>
> A parameter <ref> without a colon is equivalent to <ref>: when
> pulling/fetching, so it merges <ref> into the current branch without
> storing the remote branch anywhere locally
>
> So I thought that both of the commands were equivalent for 'git pull
> --rebase'.
>
> Thanks for the explanation.
Ah that part.
It means that
$ git pull --rebase origin master
means the same as:
$ git pull --rebase origin master:
(note extra colon at the end)
But not as:
$ git pull --rebase origin master:foo
It means that, when you give a refspec without a colon, it is the same
as the refspec with the colon and without the right side.
^ permalink raw reply
* Re: git svn fetch loses data
From: Johan 't Hart @ 2009-11-15 19:52 UTC (permalink / raw)
To: Thomas Rast; +Cc: Victor Engmark, Sverre Rabbelier, git
In-Reply-To: <200911151433.54797.trast@student.ethz.ch>
Thomas Rast schreef:
> Victor Engmark wrote:
>> On Sun, Nov 15, 2009 at 12:35 AM, Johan 't Hart <johanthart@gmail.com> wrote:
>>> Sverre Rabbelier schreef:
>>>
>>>> $ git rebase git-svn
>>> Why not just
>>> $ git svn rebase
>> What is the difference between the two?
>
> 'git svn rebase' magically[*] picks the right remote branch to rebase
> against, and also first talks to the network to update said branch.
>
>
> [*] actually it looks at the first git-svn-id line found in git log
> --first-parent.
>
I didn't even know you could also do
$ git rebase git-svn
Unless git-svn is a ref...
^ permalink raw reply
* Re: Question about "git pull --rebase"
From: Junio C Hamano @ 2009-11-15 20:18 UTC (permalink / raw)
To: Johan 't Hart; +Cc: Francis Moreau, git
In-Reply-To: <4B005AEC.1000002@gmail.com>
Johan 't Hart <johanthart@gmail.com> writes:
> Francis Moreau schreef:
>> Looks like you did :)
>>
>> I've been somehow confused by the git-pull man page, which says:
>>
>> A parameter <ref> without a colon is equivalent to <ref>: when
>> pulling/fetching, so it merges <ref> into the current branch without
>> storing the remote branch anywhere locally
>>
>> So I thought that both of the commands were equivalent for 'git pull
>> --rebase'.
>>
>> Thanks for the explanation.
>
> Ah that part.
>
> It means that
> $ git pull --rebase origin master
>
> means the same as:
> $ git pull --rebase origin master:
> (note extra colon at the end)
>
> But not as:
> $ git pull --rebase origin master:foo
>
> It means that, when you give a refspec without a colon, it is the same
> as the refspec with the colon and without the right side.
Thanks for clearing it up.
I was puzzled by the above pointing-finger because I wanted to see where a
misinformation originated from to fix it at the source. But still don't
see anything wrong with it.
Perhaps there was some other part of the manual that confused Francis to
think master: and master:foo are equivalent in that context? I somehow
doubt it, but if there is one, we would need to fix that
In a separate thread, Thomas reported a gross misinformation in github
wiki he recently fixed:
From: Thomas Rast <trast@student.ethz.ch>
Subject: Re: [PATCH] pull: refuse complete src:dst fetchspec arguments
Date: Sun, 15 Nov 2009 13:24:03 +0100
Message-ID: <200911151324.05109.trast@student.ethz.ch>
Perhaps that page had some impact on this misunderstanding?
^ permalink raw reply
* Re: [PATCH] pull: refuse complete src:dst fetchspec arguments
From: Junio C Hamano @ 2009-11-15 20:22 UTC (permalink / raw)
To: Thomas Rast; +Cc: git
In-Reply-To: <200911151324.05109.trast@student.ethz.ch>
Thomas Rast <trast@student.ethz.ch> writes:
> Yesterday on IRC I helped 'thrope' with the github pull requests
> guide. This is a wiki page, but placed at a sufficiently prominent
> URL to make it look like an authoritative guide to a new user.
>
> http://github.com/guides/pull-requests
>
> I have since replaced the part in question ...
Thanks.
It is hard to control the quality of random third-party documents, and
such a help as yours is greatly appreciated.
A document with gross misinformation is much worse than not having it.
^ permalink raw reply
* Re: Question about "git pull --rebase"
From: Johan 't Hart @ 2009-11-15 20:32 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Francis Moreau, git
In-Reply-To: <7vlji7k0dm.fsf@alter.siamese.dyndns.org>
Junio C Hamano schreef:
> Johan 't Hart <johanthart@gmail.com> writes:
>>> I've been somehow confused by the git-pull man page, which says:
>>>
>>> A parameter <ref> without a colon is equivalent to <ref>: when
>>> pulling/fetching, so it merges <ref> into the current branch without
>>> storing the remote branch anywhere locally
>>>
> Thanks for clearing it up.
>
> I was puzzled by the above pointing-finger because I wanted to see where a
> misinformation originated from to fix it at the source. But still don't
> see anything wrong with it.
>
My guess is that he was confused by '<ref>:' not meaning '<ref>:<ref>'.
But I can't speak for him ofcource :)
Refspecs confused me too at the beginning... But knowing more and more
about git, it seems that this part of the docs look OK to me.. At most
an example might make things a little more clear, but I doubt it is
necessary.
^ permalink raw reply
* Re: git svn fetch loses data
From: Thomas Rast @ 2009-11-15 20:52 UTC (permalink / raw)
To: Johan 't Hart; +Cc: Victor Engmark, Sverre Rabbelier, git
In-Reply-To: <4B005C14.8090607@gmail.com>
Johan 't Hart wrote:
> I didn't even know you could also do
> $ git rebase git-svn
> Unless git-svn is a ref...
You can't, but in git-svn's default configuration (without
--stdlayout) the cloned SVN history is called refs/remotes/git-svn.
--
Thomas Rast
trast@{inf,student}.ethz.ch
^ permalink raw reply
* Re: [RFC] format-patch: Ensure that author and commit time are not lost
From: Junio C Hamano @ 2009-11-15 21:03 UTC (permalink / raw)
To: Björn Gustavsson; +Cc: git
In-Reply-To: <4B000141.5070503@gmail.com>
Björn Gustavsson <bgustavsson@gmail.com> writes:
> 'git format-patch' encodes the author of the commit in the From: header
> and the time of the commit in the Date: header. Depending on how the
> email is sent, however, those headers can be lost before the email
> reaches its destination.
>
> Therefore, if the sender of the email (i.e. the configuration options
> user.name and user.email) are different from the author of a commit,
> insert From: and Date: headers at the beginning of the body of the
> commit message.
I think you are addressing a very valid issue, but I suspect that you are
doing so at a wrong place in the "patch mail-out" workflow.
> +static int sender_is_not_author(const char *message)
> +{
> + const char **msg_p = &message;
> +
> + for (;;) {
> ...
> + }
> +}
This new function is not about "Is the _sender_ the same as the author?",
but is about "Is the person who is running format-patch the same as the
author?". There is a big difference.
What you want to catch is really "Does the MUA that sends out the final
message have the name of the author on its 'From: ' header?", and that
depends on how the output from format-patch command is processed in the
downstream of the workflow.
You may read the file into your MUA edit session. You would typically
edit the first three lines out and move Subject: to the MUA's subject line.
You can choose to keep From:/Date: when you do so. This happens to be the
way I work, by the way.
The output may not even be used by a MUA; you may upload it to web based
thingy like Bugzilla or FrySpray. The recipient will download the whole
thing and there is no need to edit.
I would expect the right solution would be to give send-email an ability
to either (1) use "Sender:" to record the operator of the MUA while
keeping "From: " taken from the payload, or (2) duplicate "From: " as an
in-body header when it sends out.
It is a separate issue if that ability should be on by default or
controlled by an option, of course. But I do not think it should be in
the format-patch.
^ permalink raw reply
* Re: Make Gitweb behave like Apache mod_userdir
From: Junio C Hamano @ 2009-11-15 21:03 UTC (permalink / raw)
To: Jakub Narebski, Petr Baudis, Luben Tuikov, J.H.; +Cc: git, Sylvain Rabot
In-Reply-To: <7fce93be0911150204h259b7424md251c54186d05b7d@mail.gmail.com>
Sylvain Rabot <sylvain@abstraction.fr> writes:
> I made gitweb behave a bit like UserDir module will in apache.
> In fact it's only configuration but I think it could be useful to others.
Thanks. Any comment from gitweb gangs?
> Basicly it allows users of your server who use git to be able to use
> gitweb to browse their own root project. E.G. :
>
> Alice's private repos :
>
> /home/alice/git/product_a.git (cloned from /var/git/product_a.git)
> /home/alice/git/product_b.git (cloned from /var/git/product_b.git)
> /home/alice/git/product_c.git (cloned from /var/git/product_c.git)
>
> Alice's links to her repos which she wants to be able to browse with gitweb :
>
> /home/alice/gitweb/product_a -> /home/alice/git/product_a.git/.git
> /home/alice/gitweb/product_c -> /home/alice/git/product_c.git/.git
>
> Bare repos :
>
> /var/git/product_a.git
> /var/git/product_b.git
> /var/git/product_c.git
> /var/git/product_d.git
>
> /etc/gitweb.conf :
>
> $projectroot = $ENV{'GITWEB_PROJECTROOT'} || "/var/git/";
>
> Apache configuration :
>
> RewriteRule ^/~([^\/]+)/?$ /cgi-bin/gitweb.cgi
> [QSA,E=GITWEB_PROJECTROOT:/home/$1/gitweb/,L,PT]
>
> So now all users with a gitweb folder in their home will be able to
> browse all git repos in it through http://<host>/~<user>.
>
> You will find a patch enclosed which try to describe best what I did
> and why in the gitweb/README.
^ permalink raw reply
* Re: [PATCH v2] Update 'git remote update' usage string to match man page.
From: Junio C Hamano @ 2009-11-15 21:04 UTC (permalink / raw)
To: Tim Henigan; +Cc: finnag, git, Nanako Shiraishi
In-Reply-To: <32c343770911151146m82ac4a3p12ecc988da88ab6b@mail.gmail.com>
Thanks, will queue.
^ permalink raw reply
* Re: [PATCH 0/3] Document and refuse rebase -s ours
From: Junio C Hamano @ 2009-11-15 21:04 UTC (permalink / raw)
To: Thomas Rast
Cc: git, Nicolas Sebrecht, Baz, Peter Krefting, Johannes Schindelin,
Björn Steinbrink
In-Reply-To: <cover.1258309432.git.trast@student.ethz.ch>
Thomas Rast <trast@student.ethz.ch> writes:
> I also implemented Nicolas's suggestion to reject -s ours outright;
> I'm not really happy with starting a blacklist there, but maybe it
> helps the next unwary user.
I am inclined to agree with you and Nicolas on this, but I'll let the list
decide if [3/3] is a good idea.
I'd rewrite [3/3] in the following way to keep it easier to maintain the
blacklist, like this.
case "$1" in
- ours)
+ ours | theirs | octopus | subtree)
die "Refusing to rebase with $1; see git help rebase."
esac
It would also make it easier to turn this into a whitelist if we choose
to,
git-rebase--interactive.sh | 5 +----
git-rebase.sh | 5 +----
git-sh-setup.sh | 7 +++++++
3 files changed, 9 insertions(+), 8 deletions(-)
diff --git a/git-rebase--interactive.sh b/git-rebase--interactive.sh
index 53d35f3..de7448b 100755
--- a/git-rebase--interactive.sh
+++ b/git-rebase--interactive.sh
@@ -571,10 +571,7 @@ first and then run 'git rebase --continue' again."
STRATEGY="-s $2"
shift ;;
esac
- if test "$STRATEGY" = "-s ours"
- then
- die "Refusing to rebase with 'ours' strategy; see git help rebase."
- fi
+ git_check_merge_strategy_used_in_rebase "${STRATEGY#-s }"
;;
-m)
# we use merge anyway
diff --git a/git-rebase.sh b/git-rebase.sh
index 2d7d566..dd9ec63 100755
--- a/git-rebase.sh
+++ b/git-rebase.sh
@@ -306,10 +306,7 @@ do
strategy="$2"
shift ;;
esac
- if test $strategy = ours
- then
- die "Refusing to rebase with 'ours' strategy; see git help rebase."
- fi
+ git_check_merge_strategy_used_in_rebase "$strategy"
do_merge=t
;;
-n|--no-stat)
diff --git a/git-sh-setup.sh b/git-sh-setup.sh
index c41c2f7..724955f 100755
--- a/git-sh-setup.sh
+++ b/git-sh-setup.sh
@@ -199,3 +199,10 @@ case $(uname -s) in
}
;;
esac
+
+git_check_merge_strategy_used_in_rebase () {
+ case "$1" in
+ ours)
+ die "Refusing to rebase with $1; see git help rebase."
+ esac
+}
^ permalink raw reply related
* Re: [PATCH 2/3] rebase docs: clarify --merge and --strategy
From: Junio C Hamano @ 2009-11-15 21:05 UTC (permalink / raw)
To: Thomas Rast
Cc: git, Nicolas Sebrecht, Baz, Peter Krefting, Johannes Schindelin,
Björn Steinbrink
In-Reply-To: <b7f805f2497d748b685544b64cd91a36c3bdf5d6.1258309432.git.trast@student.ethz.ch>
Thomas Rast <trast@student.ethz.ch> writes:
> Add a paragraph about the swapped sides in a --merge rebase, which was
> otherwise only documented in the sources.
>
> Add a paragraph about the effects of the 'ours' strategy to the -s
> description. Also remove the mention of the 'octopus' strategy, which
> was copied from the git-merge description but is pointless in a
> rebase.
Instead of saying "peculiarities" without saying what is peculiar about
it, it might be better to give an explanation that would help the reader
understand why they appear "swapped".
Here is my attempt. Thoughts?
Documentation/git-rebase.txt | 12 ++++++++----
1 files changed, 8 insertions(+), 4 deletions(-)
diff --git a/Documentation/git-rebase.txt b/Documentation/git-rebase.txt
index e802421..a6f8182 100644
--- a/Documentation/git-rebase.txt
+++ b/Documentation/git-rebase.txt
@@ -229,9 +229,11 @@ OPTIONS
strategy is used, this allows rebase to be aware of renames on the
upstream side.
+
-Note that in a rebase merge (hence merge conflict), the sides are
-swapped: "theirs" is the to-be-applied patch, and "ours" is the so-far
-rebased series, starting with <upstream>.
+Note that a rebase merge works by replaying each commit from the working
+branch on top of the <upstream> branch. Because of this, when a merge
+conflict happens, the side reported as 'ours' is the so-far rebased
+series, starting with <upstream>, and 'theirs' is the working branch. In
+other words, the sides are swapped.
-s <strategy>::
--strategy=<strategy>::
@@ -239,7 +241,9 @@ rebased series, starting with <upstream>.
If there is no `-s` option 'git-merge-recursive' is used
instead. This implies --merge.
+
-Due to the peculiarities of 'git-rebase' (see \--merge above), using
+Because 'git-rebase' replays each commit from the working branch
+on top of the <upstream> branch using the given strategy,
+(see \--merge above), using
the 'ours' strategy simply discards all patches from the <branch>,
which makes little sense. Thus 'git-rebase' does not accept this
strategy.
^ permalink raw reply related
* Re: [PATCH 2/3] rebase docs: clarify --merge and --strategy
From: Thomas Rast @ 2009-11-15 21:11 UTC (permalink / raw)
To: Junio C Hamano
Cc: git, Nicolas Sebrecht, Baz, Peter Krefting, Johannes Schindelin,
Björn Steinbrink
In-Reply-To: <7v7htrfqi1.fsf@alter.siamese.dyndns.org>
Junio C Hamano wrote:
> diff --git a/Documentation/git-rebase.txt b/Documentation/git-rebase.txt
> index e802421..a6f8182 100644
> --- a/Documentation/git-rebase.txt
> +++ b/Documentation/git-rebase.txt
> @@ -229,9 +229,11 @@ OPTIONS
> strategy is used, this allows rebase to be aware of renames on the
> upstream side.
> +
> -Note that in a rebase merge (hence merge conflict), the sides are
> -swapped: "theirs" is the to-be-applied patch, and "ours" is the so-far
> -rebased series, starting with <upstream>.
> +Note that a rebase merge works by replaying each commit from the working
> +branch on top of the <upstream> branch. Because of this, when a merge
> +conflict happens, the side reported as 'ours' is the so-far rebased
> +series, starting with <upstream>, and 'theirs' is the working branch. In
> +other words, the sides are swapped.
This is much nicer than mine!
> -Due to the peculiarities of 'git-rebase' (see \--merge above), using
> +Because 'git-rebase' replays each commit from the working branch
> +on top of the <upstream> branch using the given strategy,
> +(see \--merge above), using
> the 'ours' strategy simply discards all patches from the <branch>,
> which makes little sense. Thus 'git-rebase' does not accept this
> strategy.
Here I'm not sure if it makes such a big difference, since we already
explained the problem in --merge (and point to it). But yours is fine
too.
--
Thomas Rast
trast@{inf,student}.ethz.ch
^ permalink raw reply
* Re: [PATCH 0/3] Document and refuse rebase -s ours
From: Thomas Rast @ 2009-11-15 21:13 UTC (permalink / raw)
To: Junio C Hamano
Cc: git, Nicolas Sebrecht, Baz, Peter Krefting, Johannes Schindelin,
Björn Steinbrink
In-Reply-To: <7veinzfqj9.fsf@alter.siamese.dyndns.org>
Junio C Hamano wrote:
>
> I'd rewrite [3/3] in the following way to keep it easier to maintain the
> blacklist, like this.
>
> case "$1" in
> - ours)
> + ours | theirs | octopus | subtree)
I agree with the rewrite; it's easier to maintain, even though it's
now in a quite strange place.
However, I think the example you gave is misleading: 'subtree' is a
useful strategy if you want to rebase across a subtree merge boundary,
isn't it?
--
Thomas Rast
trast@{inf,student}.ethz.ch
^ permalink raw reply
* [PATCH RFC] git remote: Separate usage strings for subcommands
From: Tim Henigan @ 2009-11-15 21:43 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
When the usage string for a subcommand must be printed,
only print the information relevant to that command.
Signed-off-by: Tim Henigan <tim.henigan@gmail.com>
---
This patch is based on:
http://article.gmane.org/gmane.comp.version-control.git/132953
All usage strings are still only located at the top of file. However,
separate usage
string arrays have been created for each subcommand.
Does this look like a sane way to structure the code?
If anyone else should be added to the CC list, please let me know.
builtin-remote.c | 57 +++++++++++++++++++++++++++++++++--------------------
1 files changed, 35 insertions(+), 22 deletions(-)
diff --git a/builtin-remote.c b/builtin-remote.c
index 0777dd7..ec65a4b 100644
--- a/builtin-remote.c
+++ b/builtin-remote.c
@@ -7,18 +7,35 @@
#include "run-command.h"
#include "refs.h"
+#define REMOTE_BARE_USAGE "git remote [-v | --verbose]"
+#define REMOTE_ADD_USAGE "git remote add [-t <branch>] [-m <master>]
[-f] [--mirror] <name> <url>"
+#define REMOTE_RENAME_USAGE "git remote rename <old> <new>"
+#define REMOTE_RM_USAGE "git remote rm <name>"
+#define REMOTE_SETHEAD_USAGE "git remote set-head <name> [-a | -d | <branch>]"
+#define REMOTE_SHOW_USAGE "git remote show [-n] <name>"
+#define REMOTE_PRUNE_USAGE "git remote prune [-n | --dry-run] <name>"
+#define REMOTE_UPDATE_USAGE "git remote [-v | --verbose] update [-p |
--prune] [group]"
+
static const char * const builtin_remote_usage[] = {
- "git remote [-v | --verbose]",
- "git remote add [-t <branch>] [-m <master>] [-f] [--mirror] <name> <url>",
- "git remote rename <old> <new>",
- "git remote rm <name>",
- "git remote set-head <name> [-a | -d | <branch>]",
- "git remote show [-n] <name>",
- "git remote prune [-n | --dry-run] <name>",
- "git remote [-v | --verbose] update [-p | --prune] [group]",
+ REMOTE_BARE_USAGE,
+ REMOTE_ADD_USAGE,
+ REMOTE_RENAME_USAGE,
+ REMOTE_RM_USAGE,
+ REMOTE_SETHEAD_USAGE,
+ REMOTE_SHOW_USAGE,
+ REMOTE_PRUNE_USAGE,
+ REMOTE_UPDATE_USAGE,
NULL
};
+static const char * const builtin_remote_add_usage[] = {
REMOTE_ADD_USAGE, NULL };
+static const char * const builtin_remote_rename_usage[] = {
REMOTE_RENAME_USAGE, NULL };
+static const char * const builtin_remote_rm_usage[] = {
REMOTE_RM_USAGE, NULL };
+static const char * const builtin_remote_sethead_usage[] = {
REMOTE_SETHEAD_USAGE, NULL };
+static const char * const builtin_remote_show_usage[] = {
REMOTE_SHOW_USAGE, NULL };
+static const char * const builtin_remote_prune_usage[] = {
REMOTE_PRUNE_USAGE, NULL };
+static const char * const builtin_remote_update_usage[] = {
REMOTE_UPDATE_USAGE, NULL };
+
#define GET_REF_STATES (1<<0)
#define GET_HEAD_NAMES (1<<1)
#define GET_PUSH_REF_STATES (1<<2)
@@ -70,7 +87,6 @@ static int add(int argc, const char **argv)
int i;
struct option options[] = {
- OPT_GROUP("add specific options"),
OPT_BOOLEAN('f', "fetch", &fetch, "fetch the remote branches"),
OPT_CALLBACK('t', "track", &track, "branch",
"branch(es) to track", opt_parse_track),
@@ -79,11 +95,11 @@ static int add(int argc, const char **argv)
OPT_END()
};
- argc = parse_options(argc, argv, NULL, options, builtin_remote_usage,
+ argc = parse_options(argc, argv, NULL, options, builtin_remote_add_usage,
0);
if (argc < 2)
- usage_with_options(builtin_remote_usage, options);
+ usage_with_options(builtin_remote_add_usage, options);
name = argv[0];
url = argv[1];
@@ -540,7 +556,7 @@ static int mv(int argc, const char **argv)
int i;
if (argc != 3)
- usage_with_options(builtin_remote_usage, options);
+ usage_with_options(builtin_remote_rename_usage, options);
rename.old = argv[1];
rename.new = argv[2];
@@ -681,7 +697,7 @@ static int rm(int argc, const char **argv)
int i, result;
if (argc != 2)
- usage_with_options(builtin_remote_usage, options);
+ usage_with_options(builtin_remote_rm_usage, options);
remote = remote_get(argv[1]);
if (!remote)
@@ -984,7 +1000,7 @@ static int show(int argc, const char **argv)
struct string_list info_list = { NULL, 0, 0, 0 };
struct show_info info;
- argc = parse_options(argc, argv, NULL, options, builtin_remote_usage,
+ argc = parse_options(argc, argv, NULL, options, builtin_remote_show_usage,
0);
if (argc < 1)
@@ -1088,7 +1104,7 @@ static int set_head(int argc, const char **argv)
"delete refs/remotes/<name>/HEAD"),
OPT_END()
};
- argc = parse_options(argc, argv, NULL, options, builtin_remote_usage,
+ argc = parse_options(argc, argv, NULL, options, builtin_remote_sethead_usage,
0);
if (argc)
strbuf_addf(&buf, "refs/remotes/%s/HEAD", argv[0]);
@@ -1114,7 +1130,7 @@ static int set_head(int argc, const char **argv)
if (delete_ref(buf.buf, NULL, REF_NODEREF))
result |= error("Could not delete %s", buf.buf);
} else
- usage_with_options(builtin_remote_usage, options);
+ usage_with_options(builtin_remote_sethead_usage, options);
if (head_name) {
unsigned char sha1[20];
@@ -1138,16 +1154,15 @@ static int prune(int argc, const char **argv)
{
int dry_run = 0, result = 0;
struct option options[] = {
- OPT_GROUP("prune specific options"),
OPT__DRY_RUN(&dry_run),
OPT_END()
};
- argc = parse_options(argc, argv, NULL, options, builtin_remote_usage,
+ argc = parse_options(argc, argv, NULL, options, builtin_remote_prune_usage,
0);
if (argc < 1)
- usage_with_options(builtin_remote_usage, options);
+ usage_with_options(builtin_remote_prune_usage, options);
for (; argc; argc--, argv++)
result |= prune_remote(*argv, dry_run);
@@ -1228,13 +1243,12 @@ static int update(int argc, const char **argv)
struct string_list list = { NULL, 0, 0, 0 };
static const char *default_argv[] = { NULL, "default", NULL };
struct option options[] = {
- OPT_GROUP("update specific options"),
OPT_BOOLEAN('p', "prune", &prune,
"prune remotes after fetching"),
OPT_END()
};
- argc = parse_options(argc, argv, NULL, options, builtin_remote_usage,
+ argc = parse_options(argc, argv, NULL, options, builtin_remote_update_usage,
PARSE_OPT_KEEP_ARGV0);
if (argc < 2) {
argc = 2;
@@ -1334,7 +1348,6 @@ static int show_all(void)
int cmd_remote(int argc, const char **argv, const char *prefix)
{
struct option options[] = {
- OPT__VERBOSE(&verbose),
OPT_END()
};
int result;
--
1.6.5.2.185.gb7fba.dirty
^ permalink raw reply related
* Re: [RFC] format-patch: Ensure that author and commit time are not lost
From: Björn Gustavsson @ 2009-11-15 22:16 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vzl6nfqkx.fsf@alter.siamese.dyndns.org>
2009/11/15 Junio C Hamano <gitster@pobox.com>:
> I think you are addressing a very valid issue, but I suspect that you are
> doing so at a wrong place in the "patch mail-out" workflow.
[...]
> This new function is not about "Is the _sender_ the same as the author?",
> but is about "Is the person who is running format-patch the same as the
> author?". There is a big difference.
Yes, I kind of suspected that my solution would not
be general enough to suit all users and workflows.
Thanks for the feedback.
/Björn
--
Björn Gustavsson, Erlang/OTP, Ericsson AB
^ permalink raw reply
* Re: What's cooking in git.git (Nov 2009, #03; Sun, 15)
From: Daniel Barkalow @ 2009-11-15 22:26 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vtywwm6i4.fsf@alter.siamese.dyndns.org>
On Sun, 15 Nov 2009, Junio C Hamano wrote:
> * sr/vcs-helper (2009-11-06) 12 commits
> - Add Python support library for remote helpers
> - Basic build infrastructure for Python scripts
> - Allow helpers to request the path to the .git directory
> - Allow helpers to report in "list" command that the ref is unchanged
> - Allow helper to map private ref names into normal names
> - Add support for "import" helper command
> - Allow specifying the remote helper in the url
> - Add a config option for remotes to specify a foreign vcs
> - Allow fetch to modify refs
> - Use a function to determine whether a remote is valid
> - Allow programs to not depend on remotes having urls
> - Fix memory leak in helper method for disconnect
>
> Re-rolled series that contains Daniel's and Johan's.
> Any comments? Is everybody happy?
My initial cleanup for "Allow helper to map private ref names into normal
names" was wrong (and the original was supposed to be RFC, and isn't
signed-off); I identified the bug he reported in it, but haven't gotten
positive test results from him yet, and the series obviously needs a
proper version rolled in before it goes into next.
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* Re: What's cooking in git.git (Nov 2009, #03; Sun, 15)
From: Sverre Rabbelier @ 2009-11-15 23:32 UTC (permalink / raw)
To: Daniel Barkalow; +Cc: Junio C Hamano, git
In-Reply-To: <alpine.LNX.2.00.0911151711170.14365@iabervon.org>
Heya,
On Sun, Nov 15, 2009 at 23:26, Daniel Barkalow <barkalow@iabervon.org> wrote:
> My initial cleanup for "Allow helper to map private ref names into normal
> names" was wrong (and the original was supposed to be RFC, and isn't
> signed-off); I identified the bug he reported in it, but haven't gotten
> positive test results from him yet, and the series obviously needs a
> proper version rolled in before it goes into next.
Sorry, I tested, got primary positive results, then wanted to test
something else and instead of:
~/code$ rm -rf test
I did:
~/code$ rm -rf git
I hate it when my fingers don't listen. Anyway, I ^C-ed and managed to
save my worktree, but most of my git/.git was gone already. I'll get
back to you tomorrow with more results since the time I was going to
spend on running it through valgrind was wasted trying to recover my
git repo :P.
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* Re: What's cooking in git.git (Nov 2009, #03; Sun, 15)
From: Peter Weseloh @ 2009-11-15 23:40 UTC (permalink / raw)
To: git
In-Reply-To: <7vtywwm6i4.fsf@alter.siamese.dyndns.org>
Junio C Hamano <gitster <at> pobox.com> writes:
> * nd/sparse (2009-08-20) 19 commits.
>
> The latest update I didn't look at very closely but I had an impression
> that it was touching very generic codepath that would affect non sparse
> cases, iow the patch looked very scary (the entire series already is).
Hi,
I'm new here so first of all thanks a lot for such a great tool!
Does that mean this feature will not make it into 'master' any time soon?
I'm currently trying to convince my managment to switch from CVS to git.
What causes some trouble is that we have quite some files (> 40k) in various
(>300) CVS modules and splitting them into sub-repos seams somewhat difficult.
git has no problem even with that many files but commands that stat the
working copy (e.g. 'git status') take quite long on our filers
(it's either a problem with the filers or with nfs or both, I don't know yet).
Having the ability to do sparse checkouts only of the repo sounds like a
way out.
Annother question: What's the timeline for 1.7.0? I couldn't find anything
about it neither here nor in the wiki.
Thanks,
Peter
^ permalink raw reply
* Re: What's cooking in git.git (Nov 2009, #03; Sun, 15)
From: Junio C Hamano @ 2009-11-16 0:11 UTC (permalink / raw)
To: Daniel Barkalow; +Cc: Junio C Hamano, git
In-Reply-To: <alpine.LNX.2.00.0911151711170.14365@iabervon.org>
Daniel Barkalow <barkalow@iabervon.org> writes:
> My initial cleanup for "Allow helper to map private ref names into normal
> names" was wrong (and the original was supposed to be RFC, and isn't
> signed-off); I identified the bug he reported in it, but haven't gotten
> positive test results from him yet, and the series obviously needs a
> proper version rolled in before it goes into next.
Thanks; will wait for a re-roll.
^ permalink raw reply
* Re: What's cooking in git.git (Nov 2009, #03; Sun, 15)
From: James Pickens @ 2009-11-16 0:13 UTC (permalink / raw)
To: Peter Weseloh; +Cc: git
In-Reply-To: <loom.20091116T003914-635@post.gmane.org>
On Sun, Nov 15, 2009 at 4:40 PM, Peter Weseloh <Peter.Weseloh@gmail.com> wrote:
> I'm currently trying to convince my managment to switch from CVS to git.
> What causes some trouble is that we have quite some files (> 40k) in various
> (>300) CVS modules and splitting them into sub-repos seams somewhat difficult.
> git has no problem even with that many files but commands that stat the
> working copy (e.g. 'git status') take quite long on our filers
> (it's either a problem with the filers or with nfs or both, I don't know yet).
> Having the ability to do sparse checkouts only of the repo sounds like a
> way out.
Make sure you have set core.preloadindex to true. It makes life on NFS much
more tolerable.
James
^ permalink raw reply
* Re: .gitignore polution
From: Sverre Rabbelier @ 2009-11-16 0:22 UTC (permalink / raw)
To: Jeff King; +Cc: Git List
In-Reply-To: <20091115094352.GA21477@coredump.intra.peff.net>
Heya,
On Sun, Nov 15, 2009 at 10:43, Jeff King <peff@peff.net> wrote:
> The other option is to mark them for ignore outside of the
> branch-specific ignore:
>
> git ls-files -o --exclude-standard >>.git/info/exclude
Ah, that would work, thanks! :)
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* Re: What's cooking in git.git (Nov 2009, #03; Sun, 15)
From: Junio C Hamano @ 2009-11-16 0:26 UTC (permalink / raw)
To: Peter Weseloh; +Cc: git
In-Reply-To: <loom.20091116T003914-635@post.gmane.org>
Peter Weseloh <Peter.Weseloh@gmail.com> writes:
> Does that mean this feature will not make it into 'master' any time soon?
It does not mean anything about this _feature_, but it does mean this
particular _implementation_ is not likely to.
> Having the ability to do sparse checkouts only of the repo sounds like a
> way out.
There is a big difference between (a) a feature is desirable and (b) a
particular implementation of that feature does things right.
The change in the topic is very intrusive and I am hesitant to merge it
into even 'next'. Before considering inclusion to 'next', it does not
matter that much if a topic realizes the feature as it advertises, but it
does matter a lot if it breaks things for people who do not need the
feature. While 'pu' has carried this topic for quite a long time, we
haven't heard much success report from folks like you with the need for
the feature if this implementation worked well for them without breaking
things.
I am not convinced that it won't regress fundamental things for the common
codepaths when "sparse" is not used, and the latest update patch posted to
the list (I do not think I picked it up) seemed very likely to regress
things for the normal codepath.
> Another question: What's the timeline for 1.7.0? I couldn't find anything
> about it neither here nor in the wiki.
When it is ready. But it is likely that there won't be 1.6.7.
^ 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