* [PATCH] AsciiDoc fixes for the git-svnimport manpage
From: Florian Weimer @ 2006-01-21 19:06 UTC (permalink / raw)
Change "SVN:: Perl" to "SVN::Perl", wrap a long line, and clean up the
description of positional arguments.
Signed-off-by: Florian Weimer <fw@deneb.enyo.de>
---
Documentation/git-svnimport.txt | 12 ++++--------
1 files changed, 4 insertions(+), 8 deletions(-)
592699f759a61aee33060d91cfe13ff432c147cf
diff --git a/Documentation/git-svnimport.txt b/Documentation/git-svnimport.txt
index db1ce38..63e28b8 100644
--- a/Documentation/git-svnimport.txt
+++ b/Documentation/git-svnimport.txt
@@ -21,7 +21,7 @@ DESCRIPTION
Imports a SVN repository into git. It will either create a new
repository, or incrementally import into an existing one.
-SVN access is done by the SVN:: Perl module.
+SVN access is done by the SVN::Perl module.
git-svnimport assumes that SVN repositories are organized into one
"trunk" directory where the main development happens, "branch/FOO"
@@ -74,8 +74,8 @@ When importing incrementally, you might
-l <max_rev>::
Specify a maximum revision number to pull.
- Formerly, this option controlled how many revisions to pull, due to
- SVN memory leaks. (These have been worked around.)
+ Formerly, this option controlled how many revisions to pull,
+ due to SVN memory leaks. (These have been worked around.)
-v::
Verbosity: let 'svnimport' report what it is doing.
@@ -100,11 +100,7 @@ with a 40x error pretty quickly.
If you're using the "-d" or "-D" option, this is the URL of the SVN
repository itself; it usually ends in "/svn".
-<SVN_repository_URL>::
- The URL of the SVN module you want to import. For local
- repositories, use "file:///absolute/path".
-
-<path>
+<path>::
The path to the module you want to check out.
-h::
--
1.1.3
^ permalink raw reply related
* Re: [PATCH] stgit: make tutorial a valid asciidoc article
From: Catalin Marinas @ 2006-01-21 18:32 UTC (permalink / raw)
To: Pavel Roskin; +Cc: git
In-Reply-To: <1137451068.5043.19.camel@dv>
On 16/01/06, Pavel Roskin <proski@gnu.org> wrote:
> Also, I've added a makefile. It's not used by default, but those who
> want to read a tutorial, can generate it in html or pdf format.
>
> Here's the new patch.
That's great, thanks. I'll push it, probably tomorrow.
--
Catalin
^ permalink raw reply
* Re: StGIT: "stg new" vs "stg new --force"
From: Catalin Marinas @ 2006-01-21 18:31 UTC (permalink / raw)
To: Pavel Roskin; +Cc: git, Charles Lever
In-Reply-To: <1137517300.20556.26.camel@dv>
On 17/01/06, Pavel Roskin <proski@gnu.org> wrote:
> I was going to suggest that would be logical to run "stg refresh"
> implicitly if "stg new" is used on modified files. But then I realized
> that it would be even better if future versions of StGIT allowed to
> refresh (i.e. add changes to) patches other that the current one.
I think that would be useful but not easy to implement. StGIT was
designed so that all operations happen on the top patch. The current
tree changes depend on the top patch and refreshing a different patch
with those changes would involve a three-way merge operation. This
merging can generate conflicts which are not relevant to the top tree
and they might even destroy the changes (depending on the merge
options).
The way I work is, again, through a dummy patch which can be folded
into the patch I want. This way I am sure that I still have the
changes in the dummy patch if I'm not happy with the merge. Maybe all
these could be done transparently and automatically remove the dummy
patch if conflicts exist.
--
^ permalink raw reply
* Re: StGIT: "stg new" vs "stg new --force"
From: Catalin Marinas @ 2006-01-21 18:24 UTC (permalink / raw)
To: Pavel Roskin; +Cc: Yann Dirson, git, Charles Lever
In-Reply-To: <1137539762.12454.11.camel@dv>
On 17/01/06, Pavel Roskin <proski@gnu.org> wrote:
> I think if would be better to improve "stg fold" to work on arbitrary
> patches. This way, you prepare the patch in the editor (which would not
> be harder than finding hunk numbers) and fold it into the patch of your
> choice. stg should check that the stack remains valid, possibly doing
> trivial adjustments to the higher patches. The current tree should not
> be impacted.
Note that 'stg fold' uses git-apply-patch which doesn't take fuzzy
patches (a feature I began to like actually). Modifying the patch in
an editor might create some problems with applying.
--
Catalin
^ permalink raw reply
* Re: StGIT: "stg new" vs "stg new --force"
From: Catalin Marinas @ 2006-01-21 18:20 UTC (permalink / raw)
To: Yann Dirson; +Cc: Pavel Roskin, git, Charles Lever
In-Reply-To: <20060117215752.GH32585@nowhere.earth>
On 17/01/06, Yann Dirson <ydirson@altern.org> wrote:
> It would even be useful sometimes to dispatch changes to a single file
> into several patches. When they are distinct enough to be in
> different diff hunks, it is pretty easy to split an existing patch,
> but it could also be useful to only refresh a patch with specific diff
> hunks. A possibility would be to add a filterdiff-like "-#<n>" flag,
> in addition to the above-suggested "refresh <file>" (and possibly only
> allow to specify a single file together with this flag).
Limiting the refresh to a set of file wouldn't be hard but doing it
per hunk it's a bit more complicated because StGIT only handles the
changes to the current tree over to GIT so that a new commit object is
created. It doesn't control the individual hunks.
What I usually do is create a dummy patch from the current changes,
pop it from the stack and only apply parts of it using emacs. Pushing
the dummy patch back would also show what changes were left to merge
in a proper patch.
--
Catalin
^ permalink raw reply
* Re: cg-update bug?
From: walt @ 2006-01-21 15:03 UTC (permalink / raw)
To: git
In-Reply-To: <dqo6fs$sr$1@sea.gmane.org>
walt wrote:
> ...there is no -v flag for cg-update. Could it be added
> so I can get the old behavior back?
Thanks for adding the flag, Petr. I tried it on git and
the kernel this morning, and in each case cg-update -v
printed the name of only one file. From looking at the
logs I'm pretty sure there were multiple files updated,
not just one. Does it print all filenames for you?
^ permalink raw reply
* Re: git-grep documentation
From: sean @ 2006-01-21 14:13 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vvewet330.fsf@assigned-by-dhcp.cox.net>
On Sat, 21 Jan 2006 00:09:07 -0800
Junio C Hamano <junkio@cox.net> wrote:
> I'd prefer to keep the options before path parameters if only
> for the sanity's sake. How about this instead
Hi Junio,
I like your patch and it fixes the "-e" problem on the command
line nicely. Some comments below though...
> [PATCH] git-grep: clarification on parameters.
>
> We forgot to make sure that there is no more than one pattern
> parameter. Also when looking for files in a directory called
> '--others', it passed that path limiter without preceding the
> end-of-options marker '--' to underlying git-ls-files, which
> misunderstood it as one of its options instead.
Actually I misinterpreted the intent of git-grep as wanting to
allow additional git-ls-files options to be given after the '--'
marker on its command line. This misconception arose because
of the following comment in git-grep.sh :
--)
# The rest are git-ls-files paths (or flags)
So your new patch should also fix that comment to remove the
"(or flags)" portion.
[...]
> -'git-grep' [<option>...] <pattern> [<path>...]
> +'git-grep' [<option>...] [-e] <pattern> [<path>...]
>
> DESCRIPTION
> -----------
> @@ -18,13 +18,32 @@ containing a match to the given pattern.
>
> OPTIONS
> -------
> +`--`::
> + Signals the end of options; the rest of the parameters
> + are <path> limiters.
> +
Since you comment on the -- marker here I think it should
also appear in the command line above:
'git-grep' [<option>...] [-e] <pattern> [--] [<path>...]
> <option>...::
> Either an option to pass to `grep` or `git-ls-files`.
> Some `grep` options, such as `-C` and `-m`, that take
> - parameters are known to `git-grep`.
> + parameters are known to `git-grep`. Among options
> + applicable to git-ls-files`, `--others` and
> + `--exclude=*` (and other variants of exclusion) may be
> + of interest. Only `-o` is recognized as an option to
> + `git-ls-files` in the short form (e.g. `-d` and `-m` are
> + given to `grep`, not to `git-ls-files` as synonym
> + for `--deleted` and `--modifed`), so you need to spell
> + out `git-ls-files` options in longer form
> + e.g. `--deleted`.
I would argue that this is too verbose and strays into the internal
implementation too much. For example a user doesn't care that
git-grep.sh needs to specially handle "grep" parameters that happen
to take a single parameter (like -C and -m).
Instead it is more useful for them to be told _specificly_ which
git-ls-files options are available and that all others will be
passed to grep. Somthing like:
Either an option to pass to `grep` or `git-ls-files`.
The following are the specific `git-ls-files` options
that may be given: `-o`, `--cached`, `--deleted`, `--others`,
`--killed`, `--ignored`, `--modified`, `--exclude=*`,
`--exclude-from=*`, and `--exclude-per-directory=*`.
All other options will be passed to `grep`.
>
> <pattern>::
> - The pattern to look for.
> + The pattern to look for. The first non option is taken
> + as the pattern; if your pattern begins with a dash, use
> + `-e <pattern>`. When a pattern is found without `-e`, it
> + also terminates the option processing and the rest of
> + the parameters are used as the `<path>...`, and you do
> + not specifically add `--` to protect the path limiter
> + that happens to begin with a dash from being mistaken as
> + an option.
And here I think only your first two sentences are needed and the
rest actually isn't. Your patch fixes the problem case and
there is no reason now to warn the user away from supplying the --
marker in addition to the "-e"; it'll work properly in either case.
That's it and the rest looked good. In case you agree with anything
i've said here, find an amended version of your patch below.
Cheers,
Sean
diff --git a/Documentation/git-grep.txt b/Documentation/git-grep.txt
index 2bfd8ed..7fd675b 100644
--- a/Documentation/git-grep.txt
+++ b/Documentation/git-grep.txt
@@ -8,7 +8,7 @@ git-grep - print lines matching a patter
SYNOPSIS
--------
-'git-grep' [<option>...] <pattern> [<path>...]
+'git-grep' [<option>...] [-e] <pattern> [--] [<path>...]
DESCRIPTION
-----------
@@ -18,13 +18,24 @@ containing a match to the given pattern.
OPTIONS
-------
+`--`::
+ Signals the end of options; the rest of the parameters
+ are <path> limiters.
+
<option>...::
Either an option to pass to `grep` or `git-ls-files`.
- Some `grep` options, such as `-C` and `-m`, that take
- parameters are known to `git-grep`.
+
+ The following are the specific `git-ls-files` options
+ that may be given: `-o`, `--cached`, `--deleted`, `--others`,
+ `--killed`, `--ignored`, `--modified`, `--exclude=*`,
+ `--exclude-from=*`, and `--exclude-per-directory=*`.
+
+ All other options will be passed to `grep`.
<pattern>::
- The pattern to look for.
+ The pattern to look for. The first non option is taken
+ as the pattern; if your pattern begins with a dash, use
+ `-e <pattern>`.
<path>...::
Optional paths to limit the set of files to be searched;
diff --git a/git-grep.sh b/git-grep.sh
index 2ed8e95..d815c09 100755
--- a/git-grep.sh
+++ b/git-grep.sh
@@ -3,22 +3,32 @@
# Copyright (c) Linus Torvalds, 2005
#
-USAGE='<option>... <pattern> <path>...'
+USAGE='[<option>...] [-e] <pattern> [<path>...]'
SUBDIRECTORY_OK='Yes'
. git-sh-setup
+got_pattern () {
+ if [ -z "$no_more_patterns" ]
+ then
+ pattern="$1" no_more_patterns=yes
+ else
+ die "git-grep: do not specify more than one pattern"
+ fi
+}
+
+no_more_patterns=
pattern=
flags=()
git_flags=()
while : ; do
case "$1" in
- --cached|--deleted|--others|--killed|\
- --ignored|--exclude=*|\
+ -o|--cached|--deleted|--others|--killed|\
+ --ignored|--modified|--exclude=*|\
--exclude-from=*|\--exclude-per-directory=*)
git_flags=("${git_flags[@]}" "$1")
;;
-e)
- pattern="$2"
+ got_pattern "$2"
shift
;;
-A|-B|-C|-D|-d|-f|-m)
@@ -26,7 +36,7 @@ while : ; do
shift
;;
--)
- # The rest are git-ls-files paths (or flags)
+ # The rest are git-ls-files paths
shift
break
;;
@@ -34,8 +44,9 @@ while : ; do
flags=("${flags[@]}" "$1")
;;
*)
- if [ -z "$pattern" ]; then
- pattern="$1"
+ if [ -z "$no_more_patterns" ]
+ then
+ got_pattern "$1"
shift
fi
break
@@ -46,5 +57,5 @@ done
[ "$pattern" ] || {
usage
}
-git-ls-files -z "${git_flags[@]}" "$@" |
- xargs -0 grep "${flags[@]}" -e "$pattern"
+git-ls-files -z "${git_flags[@]}" -- "$@" |
+ xargs -0 grep "${flags[@]}" -e "$pattern" --
^ permalink raw reply related
* problem installing latest cogito
From: dave morgan @ 2006-01-21 14:08 UTC (permalink / raw)
To: git
(some lines might have been wrapped by my mailer)
david@tower2:~/cogito$ cg-update
Fetching head...
Fetching objects...
progress: 51 objects, 83346 bytes
Fetching tags...
Tree change:
795023aaeaac0522d6af2fb63a14699c980782b7:d1a89167fbe0287cc43609bf37534ba1a98614d9
Applying changes...
Fast-forwarding 795023aaeaac0522d6af2fb63a14699c980782b7 ->
d1a89167fbe0287cc43609bf37534ba1a98614d9
on top of 795023aaeaac0522d6af2fb63a14699c980782b7...
david@tower2:~/cogito$ make install
Generating cg-version...
install -m755 -d /home/david/bin
install cg-object-id cg-add cg-admin-lsobj cg-admin-uncommit
cg-branch-add cg-branch-ls cg-reset cg-clone cg-commit cg-diff
cg-export cg-help cg-init cg-log cg-merge cg-mkpatch cg-patch cg-fetch
cg-restore cg-rm cg-seek cg-status cg-tag cg-tag-ls cg-update cg
cg-admin-ls cg-push cg-branch-chg cg-admin-cat cg-clean
cg-admin-setuprepo cg-switch cg-version /home/david/bin
for i in 'cg-cancel:cg-reset' 'commit-id:cg-object-id' \
'tree-id:cg-object-id' 'parent-id:cg-object-id' \
'cg-commit-id:cg-object-id' \
'cg-tree-id:cg-object-id' 'cg-parent-id:cg-object-id'
\
'cg-pull:cg-fetch'; do \
old=`echo $i | cut -d : -f 1`; \
new=`echo $i | cut -d : -f 2`; \
rm -f /home/david/bin/$old; \
ln -s $new /home/david/bin/$old; \
done
install -m755 -d /home/david/lib/cogito
install cg-Xlib cg-Xmergefile cg-Xfetchprogress /home/david/lib/cogito
cd /home/david/bin; \
for file in cg-object-id cg-add cg-admin-lsobj
cg-admin-uncommit cg-branch-add cg-branch-ls cg-reset cg-clone
cg-commit cg-diff cg-export cg-help cg-init cg-log cg-merge cg-mkpatch
cg-patch cg-fetch cg-restore cg-rm cg-seek cg-status cg-tag cg-tag-ls
cg-update cg cg-admin-ls cg-push cg-branch-chg cg-admin-cat cg-clean
cg-admin-setuprepo cg-switch cg-version; do \
sed -e
's/\${COGITO_LIB}/\${COGITO_LIB:-\/home\/david\/lib\/cogito\/}/g; \
s/\${COGITO_SHARE}/\${COGITO_SHARE:-\/home\/david\/share\/cogito\/}/g'
\
$file > $file.new; \
cat $file.new > $file; rm $file.new; \
done
sed: -e expression #1, char 145: unterminated address regex
sed: -e expression #1, char 145: unterminated address regex
sed: -e expression #1, char 145: unterminated address regex
sed: -e expression #1, char 145: unterminated address regex
sed: -e expression #1, char 145: unterminated address regex
sed: -e expression #1, char 145: unterminated address regex
sed: -e expression #1, char 145: unterminated address regex
sed: -e expression #1, char 145: unterminated address regex
sed: -e expression #1, char 145: unterminated address regex
sed: -e expression #1, char 145: unterminated address regex
sed: -e expression #1, char 145: unterminated address regex
sed: -e expression #1, char 145: unterminated address regex
sed: -e expression #1, char 145: unterminated address regex
sed: -e expression #1, char 145: unterminated address regex
sed: -e expression #1, char 145: unterminated address regex
sed: -e expression #1, char 145: unterminated address regex
sed: -e expression #1, char 145: unterminated address regex
sed: -e expression #1, char 145: unterminated address regex
sed: -e expression #1, char 145: unterminated address regex
sed: -e expression #1, char 145: unterminated address regex
sed: -e expression #1, char 145: unterminated address regex
sed: -e expression #1, char 145: unterminated address regex
sed: -e expression #1, char 145: unterminated address regex
sed: -e expression #1, char 145: unterminated address regex
sed: -e expression #1, char 145: unterminated address regex
sed: -e expression #1, char 145: unterminated address regex
sed: -e expression #1, char 145: unterminated address regex
sed: -e expression #1, char 145: unterminated address regex
sed: -e expression #1, char 145: unterminated address regex
sed: -e expression #1, char 145: unterminated address regex
sed: -e expression #1, char 145: unterminated address regex
sed: -e expression #1, char 145: unterminated address regex
sed: -e expression #1, char 145: unterminated address regex
sed: -e expression #1, char 145: unterminated address regex
cd /home/david/lib/cogito; \
for file in cg-Xlib cg-Xmergefile cg-Xfetchprogress; do \
sed -e
's/\${COGITO_LIB}/\${COGITO_LIB:-\/home\/david\/lib\/cogito\/}/g; \
s/\${COGITO_SHARE}/\${COGITO_SHARE:-\/home\/david\/share\/cogito\/}/g'
\
$file > $file.new; \
cat $file.new > $file; rm $file.new; \
done
sed: -e expression #1, char 145: unterminated address regex
sed: -e expression #1, char 145: unterminated address regex
sed: -e expression #1, char 145: unterminated address regex
install -m755 -d /home/david/share/cogito
install -m644 default-exclude /home/david/share/cogito
david@tower2:~/cogito$
net result - a pile of zero length files in /home/david/bin/ :-(
can I just copy the cg-files from to cogito directory over?
Dave
^ permalink raw reply
* Re: git pull and remote tags
From: Andreas Ericsson @ 2006-01-21 13:29 UTC (permalink / raw)
To: Andrey Borzenkov; +Cc: git
In-Reply-To: <200601211119.09268.arvidjaar@mail.ru>
Andrey Borzenkov wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> I initialized repository (it was udev by the way) using git clone when it was
> on release 080. Now after 081 was out I did "git pull" and it did pulled
> changes but I do not see tag 081. What is the proper way to sync remote
> repository with local copy while retaining all refs?
>
Upgrade to the very latest git suite or do
$ git fetch --tags
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: What is in git.git
From: Alexander Litvinov @ 2006-01-21 10:36 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v3bjiuhxb.fsf@assigned-by-dhcp.cox.net>
Somehow first mail was not reached the list, resending it.
> The "bind commit" experiments for subproject support is coming
> along rather nicely. Near the tip of the "pu" branch, there
> are:
...
>
> I think the first four are more-or-less well debugged.
>
> I am reasonably confident that I did not break rev-list for
> repositories without "bind" commits, but I have no clue how
> correct it is when dealing with commits with "bind" lines. This
> is the last major remaining piece of the puzzle, and the rest is
> just the matter of scripting. I'd be sending out a request for
> help on the rev-list in a separate message.
>
> There still is no barebone Porcelainish work done using these
> changes. The attached script demonstrates a superproject that
> binds two subprojects with their own development histories.
I tested this with your script. It works well. But I have found some
downsides.
subpro and main are separate projects and master is the join of them. If I
want to modify subpro I have to checkout subpro branch, edit files. When I
have to got to master and bind new version of subpro to it. Worse, if I will
edit subpro's files bined to master branch changes will go to master branch
instead of subpro's history. As a result all other project (imagine master-2)
that use subpro will lose this change.
1. Can I bind some branch instead of tag (commit) ?
2. Is it possible to commit changes of subpro's file in master branch into
subpro branch to make this changes visible to master-2 ?
Thanks for attention.
Alexander Litvinov.
^ permalink raw reply
* Re: What is in git.git
From: Alexander Litvinov @ 2006-01-21 10:33 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <200601211524.03096.lan@ac-sw.com>
> 1. Can I bind some branch instead of tag (commit) ?
> 2. Is it possible to commit changes of subpro's file in master branch into
> subpro branch to make this changes visible to master-2 ?
One more comment: it seems to me it is not possible to make two branches on
separate subprojects with the same name.
^ permalink raw reply
* [PATCH/RFC] rev-list: simplify --object list generation.
From: Junio C Hamano @ 2006-01-21 8:24 UTC (permalink / raw)
To: git; +Cc: torvalds
We have a provision to list only blobs (or tags or trees)
separately, but that was never exercised. Simplify the code by
using a single variable to control either listing of all objects
or nothing but the commit ancestry chain.
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
* I think there isn't much controversial about this. I am
sending this out only because the other one applies on top of
this.
rev-list.c | 30 ++++++++++++------------------
1 files changed, 12 insertions(+), 18 deletions(-)
8ac50f00d0799f8f235d2993c18e8d49e035d0cd
diff --git a/rev-list.c b/rev-list.c
index d060966..f2534fd 100644
--- a/rev-list.c
+++ b/rev-list.c
@@ -37,9 +37,7 @@ static const char rev_list_usage[] =
static int dense = 1;
static int unpacked = 0;
static int bisect_list = 0;
-static int tag_objects = 0;
-static int tree_objects = 0;
-static int blob_objects = 0;
+static int list_objects = 0;
static int verbose_header = 0;
static int show_parents = 0;
static int hdr_termination = 0;
@@ -168,7 +166,7 @@ static struct object_list **process_blob
{
struct object *obj = &blob->object;
- if (!blob_objects)
+ if (!list_objects)
return p;
if (obj->flags & (UNINTERESTING | SEEN))
return p;
@@ -181,7 +179,7 @@ static struct object_list **process_tree
struct object *obj = &tree->object;
struct tree_entry_list *entry;
- if (!tree_objects)
+ if (!list_objects)
return p;
if (obj->flags & (UNINTERESTING | SEEN))
return p;
@@ -253,7 +251,7 @@ static void show_commit_list(struct comm
static void mark_blob_uninteresting(struct blob *blob)
{
- if (!blob_objects)
+ if (!list_objects)
return;
if (blob->object.flags & UNINTERESTING)
return;
@@ -265,7 +263,7 @@ static void mark_tree_uninteresting(stru
struct object *obj = &tree->object;
struct tree_entry_list *entry;
- if (!tree_objects)
+ if (!list_objects)
return;
if (obj->flags & UNINTERESTING)
return;
@@ -612,7 +610,7 @@ static struct commit_list *limit_list(st
continue;
p = &commit_list_insert(commit, p)->next;
}
- if (tree_objects)
+ if (list_objects)
mark_edges_uninteresting(newlist);
if (paths && dense)
compress_list(newlist);
@@ -640,7 +638,7 @@ static struct commit *get_commit_referen
while (object->type == tag_type) {
struct tag *tag = (struct tag *) object;
object->flags |= flags;
- if (tag_objects && !(object->flags & UNINTERESTING))
+ if (list_objects && !(object->flags & UNINTERESTING))
add_pending_object(object, tag->tag);
object = parse_object(tag->tagged->sha1);
if (!object)
@@ -667,7 +665,7 @@ static struct commit *get_commit_referen
*/
if (object->type == tree_type) {
struct tree *tree = (struct tree *)object;
- if (!tree_objects)
+ if (!list_objects)
return NULL;
if (flags & UNINTERESTING) {
mark_tree_uninteresting(tree);
@@ -682,7 +680,7 @@ static struct commit *get_commit_referen
*/
if (object->type == blob_type) {
struct blob *blob = (struct blob *)object;
- if (!blob_objects)
+ if (!list_objects)
return NULL;
if (flags & UNINTERESTING) {
mark_blob_uninteresting(blob);
@@ -777,9 +775,7 @@ int main(int argc, const char **argv)
continue;
}
if (!strcmp(arg, "--objects")) {
- tag_objects = 1;
- tree_objects = 1;
- blob_objects = 1;
+ list_objects = 1;
continue;
}
if (!strcmp(arg, "--unpacked")) {
@@ -850,8 +846,7 @@ int main(int argc, const char **argv)
handle_one_commit(commit, &list);
}
- if (!list &&
- (!(tag_objects||tree_objects||blob_objects) && !pending_objects))
+ if (!list && !list_objects && !pending_objects)
usage(rev_list_usage);
paths = get_pathspec(prefix, argv + i);
@@ -865,8 +860,7 @@ int main(int argc, const char **argv)
if (!merge_order) {
sort_by_date(&list);
- if (list && !limited && max_count == 1 &&
- !tag_objects && !tree_objects && !blob_objects) {
+ if (list && !limited && max_count == 1 && !list_objects) {
show_commit(list->item);
return 0;
}
--
1.1.4.g5a4c
^ permalink raw reply related
* [PATCH/RFC] rev-list: understand bound commits.
From: Junio C Hamano @ 2006-01-21 8:23 UTC (permalink / raw)
To: torvalds; +Cc: git
This adds support for "bind" lines in commit objects, so that
"rev-list --objects piped to pack-objects" pattern can be used
for git native transports.
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
* Linus, I would really appreciate if you can proofread and
comment on this patch. I am reasonably sure that I did not
break things when no commit with "bind" lines are involved,
but I am not sure if this makes --objects do the right thing
to produce correct packs. The goal is still to have:
$ git rev-list --objects A..B
to produce list of objects that are needed to complete B for
somebody who has A, taking into account the objects contained
in the subproject commits, while:
$ git rev-list A..B
should not worry anything about subproject commits.
rev-list.c | 65 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++----
1 files changed, 61 insertions(+), 4 deletions(-)
e0571c156e9abd75473c6c85e224965dae842a65
diff --git a/rev-list.c b/rev-list.c
index f2534fd..339926a 100644
--- a/rev-list.c
+++ b/rev-list.c
@@ -201,6 +201,37 @@ static struct object_list **process_tree
return p;
}
+static struct object_list **process_commit_part(struct commit *, struct object_list **, const char *);
+
+static struct object_list **process_bound_commit(struct commit *bound, struct object_list **p, const char *name)
+{
+ struct object *obj = &bound->object;
+
+ if (!list_objects)
+ return p;
+ if (obj->flags & (UNINTERESTING|SEEN))
+ return p;
+ if (parse_commit(bound) < 0)
+ die("bad commit object %s", sha1_to_hex(obj->sha1));
+ obj->flags |= SEEN;
+ p = add_object(obj, p, name);
+ return process_commit_part(bound, p, name);
+}
+
+static struct object_list **process_commit_part(struct commit *commit, struct object_list **p, const char *name)
+{
+ p = process_tree(commit->tree, p, name);
+ if (commit->binds) {
+ struct commit_list *bp = commit->binds;
+ while (bp) {
+ struct commit *bound = bp->item;
+ bp = bp->next;
+ p = process_bound_commit(bound, p, name);
+ }
+ }
+ return p;
+}
+
static struct object_list *pending_objects = NULL;
static void show_commit_list(struct commit_list *list)
@@ -209,7 +240,7 @@ static void show_commit_list(struct comm
while (list) {
struct commit *commit = pop_most_recent_commit(&list, SEEN);
- p = process_tree(commit->tree, p, "");
+ p = process_commit_part(commit, p, "");
if (process_commit(commit) == STOP)
break;
}
@@ -231,6 +262,10 @@ static void show_commit_list(struct comm
p = process_blob((struct blob *)obj, p, name);
continue;
}
+ if (obj->type == commit_type) {
+ p = process_bound_commit((struct commit *)obj, p, name);
+ continue;
+ }
die("unknown pending object %s (%s)", sha1_to_hex(obj->sha1), name);
}
while (objects) {
@@ -285,6 +320,16 @@ static void mark_tree_uninteresting(stru
}
}
+static void mark_bound_commits(struct commit *commit, int flags)
+{
+ struct commit_list *clist = commit->binds;
+ while (clist) {
+ struct commit *bound = clist->item;
+ bound->object.flags |= flags;
+ clist = clist->next;
+ }
+}
+
static void mark_parents_uninteresting(struct commit *commit)
{
struct commit_list *parents = commit->parents;
@@ -305,6 +350,13 @@ static void mark_parents_uninteresting(s
mark_parents_uninteresting(commit);
/*
+ * Subproject commits bound to an uninteresting
+ * parent is not interesting.
+ */
+ if (commit->binds)
+ mark_bound_commits(commit, UNINTERESTING);
+
+ /*
* A missing commit is ok iff its parent is marked
* uninteresting.
*
@@ -520,6 +572,7 @@ static void add_parents_to_list(struct c
p->object.flags |= UNINTERESTING;
if (p->parents)
mark_parents_uninteresting(p);
+ mark_bound_commits(p, UNINTERESTING);
if (p->object.flags & SEEN)
continue;
p->object.flags |= SEEN;
@@ -599,9 +652,12 @@ static struct commit_list *limit_list(st
obj->flags |= UNINTERESTING;
if (unpacked && has_sha1_pack(obj->sha1))
obj->flags |= UNINTERESTING;
- add_parents_to_list(commit, &list);
+ if (commit->parents)
+ add_parents_to_list(commit, &list);
if (obj->flags & UNINTERESTING) {
- mark_parents_uninteresting(commit);
+ if (commit->parents)
+ mark_parents_uninteresting(commit);
+ mark_bound_commits(commit, UNINTERESTING);
if (everybody_uninteresting(list))
break;
continue;
@@ -654,8 +710,9 @@ static struct commit *get_commit_referen
object->flags |= flags;
if (parse_commit(commit) < 0)
die("unable to parse commit %s", name);
- if (flags & UNINTERESTING)
+ if ((flags & UNINTERESTING) && commit->parents)
mark_parents_uninteresting(commit);
+ mark_bound_commits(commit, flags);
return commit;
}
--
1.1.4.g5a4c
^ permalink raw reply related
* git pull and remote tags
From: Andrey Borzenkov @ 2006-01-21 8:19 UTC (permalink / raw)
To: git
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
I initialized repository (it was udev by the way) using git clone when it was
on release 080. Now after 081 was out I did "git pull" and it did pulled
changes but I do not see tag 081. What is the proper way to sync remote
repository with local copy while retaining all refs?
TIA
- -andrey
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)
iD8DBQFD0e59R6LMutpd94wRAl+AAJ9KeMouJnpJi5eAk1lF9kbY58+ImQCfaWtF
AGAs+9VdGY0vSyUZWd3DeDo=
=w8zY
-----END PGP SIGNATURE-----
^ permalink raw reply
* Re: git-grep documentation
From: Junio C Hamano @ 2006-01-21 8:09 UTC (permalink / raw)
To: sean; +Cc: git
In-Reply-To: <BAYC1-PASMTP07F7EA1F3B544C07AA01F8AE1F0@CEZ.ICE>
sean <seanlkml@sympatico.ca> writes:
> It looks as though git-grep.sh was coded to allow git-ls-files
> options to be passed after a '--' marker...
I'd prefer to keep the options before path parameters if only
for the sanity's sake. How about this instead?
-- >8 --
[PATCH] git-grep: clarification on parameters.
We forgot to make sure that there is no more than one pattern
parameter. Also when looking for files in a directory called
'--others', it passed that path limiter without preceding the
end-of-options marker '--' to underlying git-ls-files, which
misunderstood it as one of its options instead.
$ git grep --others -e Meta/Make Meta
$ git grep -o -e Meta/Make Meta
$ git grep -o Meta/Make Meta
look for a string "Meta/Make" from untracked files in Meta/
directory.
$ git grep Meta/Make --others
looks for the same string from tracked files in ./--others
directory.
On the other hand,
$ git grep -e Meta/Make --others
does not have a freestanding pattern, so everybody is parameter
and there is no path specifier. It looks for the string in all
the untracked files without any path limiter.
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
Documentation/git-grep.txt | 25 ++++++++++++++++++++++---
git-grep.sh | 27 +++++++++++++++++++--------
2 files changed, 41 insertions(+), 11 deletions(-)
b11f9315a792d65a0113e10e478e740ce4f8be73
diff --git a/Documentation/git-grep.txt b/Documentation/git-grep.txt
index 2bfd8ed..55d3bed 100644
--- a/Documentation/git-grep.txt
+++ b/Documentation/git-grep.txt
@@ -8,7 +8,7 @@ git-grep - print lines matching a patter
SYNOPSIS
--------
-'git-grep' [<option>...] <pattern> [<path>...]
+'git-grep' [<option>...] [-e] <pattern> [<path>...]
DESCRIPTION
-----------
@@ -18,13 +18,32 @@ containing a match to the given pattern.
OPTIONS
-------
+`--`::
+ Signals the end of options; the rest of the parameters
+ are <path> limiters.
+
<option>...::
Either an option to pass to `grep` or `git-ls-files`.
Some `grep` options, such as `-C` and `-m`, that take
- parameters are known to `git-grep`.
+ parameters are known to `git-grep`. Among options
+ applicable to git-ls-files`, `--others` and
+ `--exclude=*` (and other variants of exclusion) may be
+ of interest. Only `-o` is recognized as an option to
+ `git-ls-files` in the short form (e.g. `-d` and `-m` are
+ given to `grep`, not to `git-ls-files` as synonym
+ for `--deleted` and `--modifed`), so you need to spell
+ out `git-ls-files` options in longer form
+ e.g. `--deleted`.
<pattern>::
- The pattern to look for.
+ The pattern to look for. The first non option is taken
+ as the pattern; if your pattern begins with a dash, use
+ `-e <pattern>`. When a pattern is found without `-e`, it
+ also terminates the option processing and the rest of
+ the parameters are used as the `<path>...`, and you do
+ not specifically add `--` to protect the path limiter
+ that happens to begin with a dash from being mistaken as
+ an option.
<path>...::
Optional paths to limit the set of files to be searched;
diff --git a/git-grep.sh b/git-grep.sh
index 2ed8e95..23b1e03 100755
--- a/git-grep.sh
+++ b/git-grep.sh
@@ -3,22 +3,32 @@
# Copyright (c) Linus Torvalds, 2005
#
-USAGE='<option>... <pattern> <path>...'
+USAGE='[<option>...] [-e] <pattern> [<path>...]'
SUBDIRECTORY_OK='Yes'
. git-sh-setup
+got_pattern () {
+ if [ -z "$no_more_patterns" ]
+ then
+ pattern="$1" no_more_patterns=yes
+ else
+ die "git-grep: do not specify more than one pattern"
+ fi
+}
+
+no_more_patterns=
pattern=
flags=()
git_flags=()
while : ; do
case "$1" in
- --cached|--deleted|--others|--killed|\
- --ignored|--exclude=*|\
+ -o|--cached|--deleted|--others|--killed|\
+ --ignored|--modified|--exclude=*|\
--exclude-from=*|\--exclude-per-directory=*)
git_flags=("${git_flags[@]}" "$1")
;;
-e)
- pattern="$2"
+ got_pattern "$2"
shift
;;
-A|-B|-C|-D|-d|-f|-m)
@@ -34,8 +44,9 @@ while : ; do
flags=("${flags[@]}" "$1")
;;
*)
- if [ -z "$pattern" ]; then
- pattern="$1"
+ if [ -z "$no_more_patterns" ]
+ then
+ got_pattern "$1"
shift
fi
break
@@ -46,5 +57,5 @@ done
[ "$pattern" ] || {
usage
}
-git-ls-files -z "${git_flags[@]}" "$@" |
- xargs -0 grep "${flags[@]}" -e "$pattern"
+git-ls-files -z "${git_flags[@]}" -- "$@" |
+ xargs -0 grep "${flags[@]}" -e "$pattern" --
--
1.1.4.g5c4a-dirty
^ permalink raw reply related
* Re: [PATCH] DT_UNKNOWN: do not fully trust existence of DT_UNKNOWN
From: Junio C Hamano @ 2006-01-21 8:09 UTC (permalink / raw)
To: Alex Riesen; +Cc: git
In-Reply-To: <20060120215314.GA4203@steel.home>
Alex Riesen <raa.lkml@gmail.com> writes:
>> +#undef DT_UNKNOWN
>> +#undef DT_DIR
>> +#undef DT_REG
>> +#undef DT_LNK
>
> yes, of course
That is technically correct but I suspect it would not matter in
practice. The only thing you are avoiding is four compiler
warnings when compiling for Cygwin of this week (I heard this is
already fixed in Cygwin CVS). On older Cygwin you simply would
not use NO_D_TYPE_IN_DIRENT, since d_type worked before. No?
^ permalink raw reply
* What is in git.git
From: Junio C Hamano @ 2006-01-21 8:03 UTC (permalink / raw)
To: git
The "bind commit" experiments for subproject support is coming
along rather nicely. Near the tip of the "pu" branch, there
are:
- read-tree --prefix;
- write-tree --prefix and write-tree --exclude;
- commit-tree --bind;
- fsck-objects and convert-objects that understand "bind" lines
in commit objects;
- rev-list --objects that understand "bind" lines
in commit objects;
I think the first four are more-or-less well debugged.
I am reasonably confident that I did not break rev-list for
repositories without "bind" commits, but I have no clue how
correct it is when dealing with commits with "bind" lines. This
is the last major remaining piece of the puzzle, and the rest is
just the matter of scripting. I'd be sending out a request for
help on the rev-list in a separate message.
There still is no barebone Porcelainish work done using these
changes. The attached script demonstrates a superproject that
binds two subprojects with their own development histories.
-- >8 --
#!/bin/sh
rm -fr .git
git init-db
: >main
for i in 1 2
do
echo "Version #$i of primary subproject" >main
git add main
git commit -a -m "`cat main`"
git tag main-$i
done
git branch main
rm -f .git/refs/heads/master .git/index
mkdir dir
: >sub1
: >dir/sub2
for i in A B C
do
echo "subproject sub1 ($i)" >sub1
echo "subproject dir/sub2 ($i)" >dir/sub2
git add sub1 dir/sub2
git commit -a -m "subproject #$i"
git tag subpro-$i
done
git branch subpro
rm -fr dir sub1 main
rm -f .git/refs/heads/master .git/index
git read-tree main-1
git read-tree --prefix=sub/ subpro-A
toptree=`git write-tree`
topcommit=$(echo "Initial top commit" |
git commit-tree $toptree \
--bind `git rev-parse --verify main-1` / \
--bind `git rev-parse --verify subpro-A` sub/)
echo $topcommit >.git/refs/heads/master
git tag top-1A
git read-tree main-1
git read-tree --prefix=sub/ subpro-B
toptree=`git write-tree`
topcommit=$(echo "Second top commit" |
git commit-tree $toptree \
-p `git rev-parse --verify top-1A` \
--bind `git rev-parse --verify main-1` / \
--bind `git rev-parse --verify subpro-B` sub/)
echo $topcommit >.git/refs/heads/master
git tag top-1B
git read-tree main-2
git read-tree --prefix=sub/ subpro-C
toptree=`git write-tree`
topcommit=$(echo "Third top commit" |
git commit-tree $toptree \
-p `git rev-parse --verify top-1B` \
--bind `git rev-parse --verify main-2` / \
--bind `git rev-parse --verify subpro-C` sub/)
echo $topcommit >.git/refs/heads/master
git tag top-2C
git log
git rev-list --objects top-1A..top-2C |
git name-rev --tags --stdin
^ permalink raw reply
* [RFC] Reverting "git push logic change"?
From: Junio C Hamano @ 2006-01-21 7:46 UTC (permalink / raw)
To: git; +Cc: Greg KH
In-Reply-To: <20060121001547.GA30712@kroah.com>
The change introduced by 9e9b267 commit broke "correct" usage of
git push to push matching refs, to work around a problem
observed in a usage pattern on a shared repository.
I think I made a bad judgement in evaluating the scenario, and
made a bad change to "fix" a problem that did not exist. I
apologize for having caused this confusion.
My conclusion after thinking about the problem again is that we
would be better of if we reverted that commit. This message is
to make my intention clear, and solicit objections or comments
from the list.
The use case that prompted this change was this:
- A shared repository is created by cloning Linus repository.
This repository gets "origin" (then-current Linus master) and
"master" (the same).
$ git clone --naked \
git://git.kernel.org/.../linux-2.6.git/ project.git
- Two developers use this as their shared repository. They
first start out by cloning from it, do their development in
their "master" branch and pushing back to the "master" branch
of the shared repository. Their workflow is:
0. Clone it (once per developer):
$ git clone ssh://pub.example.com/project.git/ work
1. To make sure the developers are in sync:
$ git pull ssh://pub.example.com/project.git/ ;# (a) or
$ git pull origin ;# (b)
2. His own development:
$ edit;compile;test;git commit
3. Pull from upstream, to avoid conflicts with it (only when needed):
$ git pull git://git.kernel.org/.../linux-2.6.git/
4. Push back the result to shared repository:
$ git push ssh://pub.example.com/project.git/
With this workflow, in the two developer repositories, "origin"
branch is not really well maintained. If "git pull origin" was
used with the remotes/origin file "git clone" initially gave
him, it would have kept track of the latest push into the shared
"master" closely, but if the explicit URL was used, "origin" of
the developer repository would have been left behind.
This is not problem as far as the correctness of the "master"
branch is concerned. The fast-forward check when pushing into
the shared repository "master" branch prevents the two
developers from losing commits. In other words, either way to
pull from the shared repository is legal/valid.
However, the push done in step 4. triggers the default "push all
matching refs" behaviour. All three repositories have "origin"
and "master", which means this results in "origin" being updated
in the shared repository. But one developer repository has a
stale "origin" while the other developer has an up-to-date
"origin". This triggers a "not a fast forward" error, which
does not cause the push of "master" to fail, but still looks
worrisome.
I think the correct thing to do in this workflow is to simply
remove "origin" branch from the shared repository.
Using or not using "origin" as a reference branch to keep track
of what was fetched from the shared repository is a matter of
personal taste for each developer, and there is no reason to
enforce either (1-a) or (1-b). This means that the branch is
not maintained the same way in developer repositories, and there
is no point pushing into it --- there is no point to have
"origin" in the shared repository.
Once "origin" branch is removed from that shared repository,
then, either "push all matching refs", or "push 'master'
explicitly" would work well for these developers.
^ permalink raw reply
* Re: [PATCH] Lower priority of Cogito's default exclude patterns
From: Petr Baudis @ 2006-01-21 2:04 UTC (permalink / raw)
To: Karl Hasselström; +Cc: git
In-Reply-To: <20060119140728.GA14998@diana.vm.bytemark.co.uk>
Thanks, patch applied and pushed out.
Dear diary, on Thu, Jan 19, 2006 at 03:07:28PM CET, I got a letter
where Karl Hasselström <kha@treskal.com> said that...
> On 2006-01-19 13:42:44 +0100, Petr Baudis wrote:
> > Oh, now I remember - one my major concern is that now Cogito will
> > not work if not make install'd, which is how I actually primarily
> > use it on my machine.
>
> The not-installed case could easily be worked around by users if
> cogito looked at /etc/cogito/exclude and ~/.cogito/exclude as well.
> (Or maybe that should be /etc/git/exclude and ~/.gitexclude, so that
> e.g. stgit can use the same files.) Would you accept a patch that did
> this?
Sorry, this doesn't make sense to me - how would that help? The user can
as well just make install in that case, instead of manually copying out
one file.
if [ -n "${COGITO_SHARE}" ]; then
COGITO_REAL_SHARE="${COGITO_SHARE}"
return
fi
if [ "${0%/*}" != "$0" ]; then
COGITO_REAL_SHARE="${0%/*}/"
return
fi
# I'm not sure if the following normally ever gets triggered.
# I can only do it by `sh cg-status`. --pasky
COGITO_REAL_SHARE="./$_git_relpath/"
should work well, though.
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
Of the 3 great composers Mozart tells us what it's like to be human,
Beethoven tells us what it's like to be Beethoven and Bach tells us
what it's like to be the universe. -- Douglas Adams
^ permalink raw reply
* Re: "git push" logic changed?
From: Junio C Hamano @ 2006-01-21 0:59 UTC (permalink / raw)
To: Greg KH; +Cc: git
In-Reply-To: <20060121001547.GA30712@kroah.com>
Greg KH <greg@kroah.com> writes:
> It would be nicer not to break a previously working command :)
Well the change was not about breaking things but the command's
natural way of "working" (which was fine for you and other
people, me included) was not so helpful to the shared repository
people, and unfortunately I couldn't have it both ways X-<.
^ permalink raw reply
* Re: "git push" logic changed?
From: Junio C Hamano @ 2006-01-21 0:54 UTC (permalink / raw)
To: Greg KH; +Cc: git
In-Reply-To: <20060121001547.GA30712@kroah.com>
Greg KH <greg@kroah.com> writes:
> Well what should I do then to push to "orgin"?
>...
> Yes, but "git push origin" used to push my local changes there, and
> that's all I really want.
>
> Someone off-list told me I could edit my .git/branches/parent file to
> fix this issue for that branch. Since I hand-created that file in the
> first place, that's not a bit deal. But I was relying on git to get the
> "origin" branch right, as I didn't edit it at all :)
If you cloned from "origin", then you would have gotton
something like:
URL: that.machine:/this/directory.git
Pull: master:origin
in your ".git/remotes/origin". Since there are more downloaders
and individual developers than subsystem maintainers, this is a
good default for the former class of people.
You as the tree owner would then add "Push:" line(s) to push
back from your local repository. For example:
$ cat .git/remotes/origin
URL: that.machine:/this/directory.git
Pull: master:origin
Push: master:master
With this,
$ git push origin
would push master branch to that.machine:/this/directory.git/
repository. With --tags or --all:
$ git push --tags origin
$ git push --all origin
These "Push:" lines are for people who have write access to the
other side (which is a minority compared to downloaders), so git
does not create them by default when you clone the repository.
^ permalink raw reply
* Re: "git push" logic changed?
From: Greg KH @ 2006-01-21 0:15 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vlkxa30rd.fsf@assigned-by-dhcp.cox.net>
On Fri, Jan 20, 2006 at 04:03:50PM -0800, Junio C Hamano wrote:
> Greg KH <greg@kroah.com> writes:
>
> > As of the git development tree from last night, 'git push' seems to work
> > a bit differently now.
>
> The change was 9e9b267. I suspect the earlier way was a bit
> more friendly to savvier people (especially the subsystem
> maintainers and the project lead), but it was found to be
> confusing for people who clone from an upstream and then use
> that as a shared repository. Their developers further clone
> from that shared repository, and as needed pull from the true
> upstream. When they push their changes back, "git push
> central:/shared.git/" would trigger a "remote origin does not
> fast forward" error, depending on when these developers fetched
> from the shared repository the last time, and whether they
> stored what they fetched from the shared repository in their
> "origin" or not. If you do "git pull central:/shared.git/", not
> "git pull origin" (taking advantage of remotes/origin file),
> your "origin" branch would become out-of-date. Which is OK for
> the purpose of maintaining "master" branch properly, but pushing
> meaningless "origin" back to "origin" at the shared repository
> (which is also meaningless) was triggering an error and causing
> confusion in that setup.
Well what should I do then to push to "orgin"?
$ git push
Where would you want to push today?
Usage: /home/greg/bin/git-push [--all] [--tags] [--force] <repository> [<refspec>...]
$ git push origin
No refs given to be pushed.
> > Or should I always be doing --all?
>
> In order to make sure all your local refs are on the "parent",
> then yes. And this is not new. It used to push all the refs
> that appear in _both_ your local repo and the "parent" repo, so
> your new tags and branches did not get propagated so you needed
> to use '--all' in such a case anyway. We now also have '--tags'
> to push all tags.
Yes, but "git push origin" used to push my local changes there, and
that's all I really want.
Someone off-list told me I could edit my .git/branches/parent file to
fix this issue for that branch. Since I hand-created that file in the
first place, that's not a bit deal. But I was relying on git to get the
"origin" branch right, as I didn't edit it at all :)
So, what I'm really just looking for is a simple way to push back to the
repository that I cloned this one from, as I only have one "repo" here.
> We could probably resurrect the earlier behaviour with a
> '--matching' option or something if you'd like.
It would be nicer not to break a previously working command :)
Or at least show me how to change it so I can just easily push back to
where I cloned the original from...
thanks,
greg k-h
^ permalink raw reply
* Re: "git push" logic changed?
From: Junio C Hamano @ 2006-01-21 0:03 UTC (permalink / raw)
To: Greg KH; +Cc: git
In-Reply-To: <20060120225336.GA29206@kroah.com>
Greg KH <greg@kroah.com> writes:
> As of the git development tree from last night, 'git push' seems to work
> a bit differently now.
The change was 9e9b267. I suspect the earlier way was a bit
more friendly to savvier people (especially the subsystem
maintainers and the project lead), but it was found to be
confusing for people who clone from an upstream and then use
that as a shared repository. Their developers further clone
from that shared repository, and as needed pull from the true
upstream. When they push their changes back, "git push
central:/shared.git/" would trigger a "remote origin does not
fast forward" error, depending on when these developers fetched
from the shared repository the last time, and whether they
stored what they fetched from the shared repository in their
"origin" or not. If you do "git pull central:/shared.git/", not
"git pull origin" (taking advantage of remotes/origin file),
your "origin" branch would become out-of-date. Which is OK for
the purpose of maintaining "master" branch properly, but pushing
meaningless "origin" back to "origin" at the shared repository
(which is also meaningless) was triggering an error and causing
confusion in that setup.
> Or should I always be doing --all?
In order to make sure all your local refs are on the "parent",
then yes. And this is not new. It used to push all the refs
that appear in _both_ your local repo and the "parent" repo, so
your new tags and branches did not get propagated so you needed
to use '--all' in such a case anyway. We now also have '--tags'
to push all tags.
We could probably resurrect the earlier behaviour with a
'--matching' option or something if you'd like.
^ permalink raw reply
* "git push" logic changed?
From: Greg KH @ 2006-01-20 22:53 UTC (permalink / raw)
To: git
As of the git development tree from last night, 'git push' seems to work
a bit differently now.
When I do:
$ git push parent
it responds with
No refs given to be pushed.
This used to work before.
Now I have to do:
$ git push --all parent
to get things to be pushed.
Or should I always be doing --all?
thanks,
greg k-h
^ permalink raw reply
* Re: [PATCH] DT_UNKNOWN: do not fully trust existence of DT_UNKNOWN
From: Alex Riesen @ 2006-01-20 21:53 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Christopher Faylor
In-Reply-To: <7vzmlqaf5o.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano, Fri, Jan 20, 2006 20:10:59 +0100:
> >> The recent Cygwin defines DT_UNKNOWN although it does not have d_type
> >> in struct dirent. Give an option to tell us not to use d_type on such
> >> platforms. Hopefully this problem will be transient.
> >
> > You still have to #undef all the DT_ macros if you have a somewhat
> > old Cygwin (before Christopher removed the macros).
>
> Ah, you mean something like this?
>
> +#undef DT_UNKNOWN
> +#undef DT_DIR
> +#undef DT_REG
> +#undef DT_LNK
yes, of course
^ 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