* [PATCH 4/9] git-cat-file: Add --stdin option
From: Adam Roben @ 2007-10-25 10:25 UTC (permalink / raw)
To: git; +Cc: Junio Hamano, Adam Roben, Brian Downing
In-Reply-To: <1193307927-3592-4-git-send-email-aroben@apple.com>
This lets you specify object names on stdin instead of on the command line.
When printing object contents or pretty-printing, objects will be printed
preceded by their size:
<size>LF
<content>LF
Signed-off-by: Adam Roben <aroben@apple.com>
---
Brian Downing wrote:
> I think a far more reasonable output format for multiple objects would
> be something like:
>
> <count> LF
> <raw data> LF
>
> Where <count> is the number of bytes in the <raw data> as an ASCII
> decimal integer.
Agreed.
Documentation/git-cat-file.txt | 6 ++++-
builtin-cat-file.c | 43 ++++++++++++++++++++++++++++++++++-----
t/t1005-cat-file.sh | 35 ++++++++++++++++++++++++++++++++
3 files changed, 77 insertions(+), 7 deletions(-)
diff --git a/Documentation/git-cat-file.txt b/Documentation/git-cat-file.txt
index afa095c..588d71a 100644
--- a/Documentation/git-cat-file.txt
+++ b/Documentation/git-cat-file.txt
@@ -8,7 +8,7 @@ git-cat-file - Provide content or type/size information for repository objects
SYNOPSIS
--------
-'git-cat-file' [-t | -s | -e | -p | <type>] <object>
+'git-cat-file' [-t | -s | -e | -p | <type>] [--stdin | <object>]
DESCRIPTION
-----------
@@ -23,6 +23,10 @@ OPTIONS
For a more complete list of ways to spell object names, see
"SPECIFYING REVISIONS" section in gitlink:git-rev-parse[1].
+--stdin::
+ Read object names from stdin instead of specifying one on the
+ command line.
+
-t::
Instead of the content, show the object type identified by
<object>.
diff --git a/builtin-cat-file.c b/builtin-cat-file.c
index 3a0be4a..ee46ba4 100644
--- a/builtin-cat-file.c
+++ b/builtin-cat-file.c
@@ -76,7 +76,7 @@ static void pprint_tag(const unsigned char *sha1, const char *buf, unsigned long
write_or_die(1, cp, endp - cp);
}
-static int cat_one_file(int opt, const char *exp_type, const char *obj_name)
+static int cat_one_file(int opt, const char *exp_type, const char *obj_name, int print_size)
{
unsigned char sha1[20];
enum object_type type;
@@ -139,16 +139,26 @@ static int cat_one_file(int opt, const char *exp_type, const char *obj_name)
if (!buf)
die("git-cat-file %s: bad file", obj_name);
+ if (print_size) {
+ printf("%lu\n", size);
+ fflush(stdout);
+ }
write_or_die(1, buf, size);
+ if (print_size) {
+ printf("\n");
+ fflush(stdout);
+ }
return 0;
}
-static const char cat_file_usage[] = "git-cat-file [-t|-s|-e|-p|<type>] <sha1>";
+static const char cat_file_usage[] = "git-cat-file [-t|-s|-e|-p|<type>] [--stdin | <sha1>]";
int cmd_cat_file(int argc, const char **argv, const char *prefix)
{
- int i, opt = 0;
+ int i, opt = 0, print_size = 0;
+ int read_stdin = 0;
const char *exp_type = 0, *obj_name = 0;
+ struct strbuf buf;
git_config(git_default_config);
@@ -161,6 +171,11 @@ int cmd_cat_file(int argc, const char **argv, const char *prefix)
continue;
}
+ if (!strcmp(arg, "--stdin")) {
+ read_stdin = 1;
+ continue;
+ }
+
if (arg[0] == '-')
usage(cat_file_usage);
@@ -169,15 +184,31 @@ int cmd_cat_file(int argc, const char **argv, const char *prefix)
continue;
}
- if (obj_name)
+ if (obj_name || read_stdin)
usage(cat_file_usage);
obj_name = arg;
break;
}
- if (!exp_type || !obj_name)
+ if (!exp_type)
usage(cat_file_usage);
- return cat_one_file(opt, exp_type, obj_name);
+ if (!read_stdin) {
+ if (!obj_name)
+ usage(cat_file_usage);
+ return cat_one_file(opt, exp_type, obj_name, 0);
+ }
+
+ print_size = !opt || opt == 'p';
+
+ strbuf_init(&buf, 0);
+ while (strbuf_getline(&buf, stdin, '\n') != EOF) {
+ int error = cat_one_file(opt, exp_type, buf.buf, print_size);
+ if (error)
+ return error;
+ }
+ strbuf_release(&buf);
+
+ return 0;
}
diff --git a/t/t1005-cat-file.sh b/t/t1005-cat-file.sh
index 697354d..2b2d386 100755
--- a/t/t1005-cat-file.sh
+++ b/t/t1005-cat-file.sh
@@ -88,4 +88,39 @@ test_expect_success \
"Reach a blob from a tag pointing to it" \
"test '$hello_content' = \"\$(git cat-file blob $tag_sha1)\""
+sha1s="$hello_sha1
+$tree_sha1
+$commit_sha1
+$tag_sha1"
+
+sizes="$hello_size
+$tree_size
+$commit_size
+$tag_size"
+
+test_expect_success \
+ "Pass object hashes on stdin to retrieve sizes" \
+ "test '$sizes' = \"\$(echo '$sha1s' | git cat-file -s --stdin)\""
+
+example_content="Silly example"
+example_size=$(echo "$example_content" | wc -c)
+example_sha1=f24c74a2e500f5ee1332c86b94199f52b1d1d962
+
+echo "$example_content" > example
+
+git update-index --add example
+
+sha1s="$hello_sha1
+$example_sha1"
+
+contents="$hello_size
+$hello_content
+
+$example_size
+$example_content"
+
+test_expect_success \
+ "Pass object hashes on stdin to retrieve contents" \
+ "test '$contents' = \"\$(echo '$sha1s' | git cat-file blob --stdin)\""
+
test_done
--
1.5.3.4.1337.g8e67d-dirty
^ permalink raw reply related
* [PATCH 3/9] git-cat-file: Make option parsing a little more flexible
From: Adam Roben @ 2007-10-25 10:25 UTC (permalink / raw)
To: git; +Cc: Junio Hamano, Adam Roben
In-Reply-To: <1193307927-3592-3-git-send-email-aroben@apple.com>
This will make it easier to add newer options later.
Signed-off-by: Adam Roben <aroben@apple.com>
---
builtin-cat-file.c | 42 ++++++++++++++++++++++++++++++------------
1 files changed, 30 insertions(+), 12 deletions(-)
diff --git a/builtin-cat-file.c b/builtin-cat-file.c
index 34a63d1..3a0be4a 100644
--- a/builtin-cat-file.c
+++ b/builtin-cat-file.c
@@ -143,23 +143,41 @@ static int cat_one_file(int opt, const char *exp_type, const char *obj_name)
return 0;
}
+static const char cat_file_usage[] = "git-cat-file [-t|-s|-e|-p|<type>] <sha1>";
+
int cmd_cat_file(int argc, const char **argv, const char *prefix)
{
- int opt;
- const char *exp_type, *obj_name;
+ int i, opt = 0;
+ const char *exp_type = 0, *obj_name = 0;
git_config(git_default_config);
- if (argc != 3)
- usage("git-cat-file [-t|-s|-e|-p|<type>] <sha1>");
- exp_type = argv[1];
- obj_name = argv[2];
-
- opt = 0;
- if ( exp_type[0] == '-' ) {
- opt = exp_type[1];
- if ( !opt || exp_type[2] )
- opt = -1; /* Not a single character option */
+
+ for (i = 1; i < argc; ++i) {
+ const char *arg = argv[i];
+
+ if (!strcmp(arg, "-t") || !strcmp(arg, "-s") || !strcmp(arg, "-e") || !strcmp(arg, "-p")) {
+ exp_type = arg;
+ opt = exp_type[1];
+ continue;
+ }
+
+ if (arg[0] == '-')
+ usage(cat_file_usage);
+
+ if (!exp_type) {
+ exp_type = arg;
+ continue;
+ }
+
+ if (obj_name)
+ usage(cat_file_usage);
+
+ obj_name = arg;
+ break;
}
+ if (!exp_type || !obj_name)
+ usage(cat_file_usage);
+
return cat_one_file(opt, exp_type, obj_name);
}
--
1.5.3.4.1337.g8e67d-dirty
^ permalink raw reply related
* [PATCH 2/9] git-cat-file: Small refactor of cmd_cat_file
From: Adam Roben @ 2007-10-25 10:25 UTC (permalink / raw)
To: git; +Cc: Junio Hamano, Adam Roben
In-Reply-To: <1193307927-3592-2-git-send-email-aroben@apple.com>
I separated the logic of parsing the arguments from the logic of fetching and
outputting the data. cat_one_file now does the latter.
Signed-off-by: Adam Roben <aroben@apple.com>
---
builtin-cat-file.c | 38 ++++++++++++++++++++++----------------
1 files changed, 22 insertions(+), 16 deletions(-)
diff --git a/builtin-cat-file.c b/builtin-cat-file.c
index f132d58..34a63d1 100644
--- a/builtin-cat-file.c
+++ b/builtin-cat-file.c
@@ -76,31 +76,16 @@ static void pprint_tag(const unsigned char *sha1, const char *buf, unsigned long
write_or_die(1, cp, endp - cp);
}
-int cmd_cat_file(int argc, const char **argv, const char *prefix)
+static int cat_one_file(int opt, const char *exp_type, const char *obj_name)
{
unsigned char sha1[20];
enum object_type type;
void *buf;
unsigned long size;
- int opt;
- const char *exp_type, *obj_name;
-
- git_config(git_default_config);
- if (argc != 3)
- usage("git-cat-file [-t|-s|-e|-p|<type>] <sha1>");
- exp_type = argv[1];
- obj_name = argv[2];
if (get_sha1(obj_name, sha1))
die("Not a valid object name %s", obj_name);
- opt = 0;
- if ( exp_type[0] == '-' ) {
- opt = exp_type[1];
- if ( !opt || exp_type[2] )
- opt = -1; /* Not a single character option */
- }
-
buf = NULL;
switch (opt) {
case 't':
@@ -157,3 +142,24 @@ int cmd_cat_file(int argc, const char **argv, const char *prefix)
write_or_die(1, buf, size);
return 0;
}
+
+int cmd_cat_file(int argc, const char **argv, const char *prefix)
+{
+ int opt;
+ const char *exp_type, *obj_name;
+
+ git_config(git_default_config);
+ if (argc != 3)
+ usage("git-cat-file [-t|-s|-e|-p|<type>] <sha1>");
+ exp_type = argv[1];
+ obj_name = argv[2];
+
+ opt = 0;
+ if ( exp_type[0] == '-' ) {
+ opt = exp_type[1];
+ if ( !opt || exp_type[2] )
+ opt = -1; /* Not a single character option */
+ }
+
+ return cat_one_file(opt, exp_type, obj_name);
+}
--
1.5.3.4.1337.g8e67d-dirty
^ permalink raw reply related
* [PATCH 1/9] Add tests for git cat-file
From: Adam Roben @ 2007-10-25 10:25 UTC (permalink / raw)
To: git; +Cc: Junio Hamano, Adam Roben, Johannes Sixt
In-Reply-To: <1193307927-3592-1-git-send-email-aroben@apple.com>
Signed-off-by: Adam Roben <aroben@apple.com>
---
Johannes Sixt wrote:
> Adam Roben schrieb:
> > + test_expect_success \
> > + "$type exists" \
> > + "git cat-file -e $hello_sha1"
>
> You mean $sha1 here, right?
I most definitely did!
> > + test_expect_success \
> > + "Type of $type is correct" \
> > + "test $type = \"$(git cat-file -t $sha1)\""
>
> This should escape the $(...) in all the tests. Like this:
>
> "test $type = \"\$(git cat-file -t $sha1)\""
>
> > +test_expect_success \
> > + "Reach a blob from a tag pointing to it" \
> > + "test \"$hello_content\" = \"$(git cat-file blob $tag_sha1)\""
>
> And use single quotes without escaping the double-quotes here.
Done.
t/t1005-cat-file.sh | 91 +++++++++++++++++++++++++++++++++++++++++++++++++++
1 files changed, 91 insertions(+), 0 deletions(-)
create mode 100755 t/t1005-cat-file.sh
diff --git a/t/t1005-cat-file.sh b/t/t1005-cat-file.sh
new file mode 100755
index 0000000..697354d
--- /dev/null
+++ b/t/t1005-cat-file.sh
@@ -0,0 +1,91 @@
+#!/bin/sh
+
+test_description='git cat-file'
+
+. ./test-lib.sh
+
+function maybe_remove_timestamp()
+{
+ if test -z "$2"; then
+ echo "$1"
+ else
+ echo "$1" | sed -e 's/ [0-9]\{10\} [+-][0-9]\{4\}$//'
+ fi
+}
+
+function run_tests()
+{
+ type=$1
+ sha1=$2
+ size=$3
+ content=$4
+ pretty_content=$5
+ no_timestamp=$6
+
+ test_expect_success \
+ "$type exists" \
+ "git cat-file -e $sha1"
+ test_expect_success \
+ "Type of $type is correct" \
+ "test $type = \"\$(git cat-file -t $sha1)\""
+ test_expect_success \
+ "Size of $type is correct" \
+ "test $size = \"\$(git cat-file -s $sha1)\""
+ test -z "$content" || test_expect_success \
+ "Content of $type is correct" \
+ "test \"\$(maybe_remove_timestamp '$content' $no_timestamp)\" = \"\$(maybe_remove_timestamp \"\$(git cat-file $type $sha1)\" $no_timestamp)\""
+ test_expect_success \
+ "Pretty content of $type is correct" \
+ "test \"\$(maybe_remove_timestamp '$pretty_content' $no_timestamp)\" = \"\$(maybe_remove_timestamp \"\$(git cat-file -p $sha1)\" $no_timestamp)\""
+}
+
+hello_content="Hello World"
+hello_size=$(echo "$hello_content" | wc -c)
+hello_sha1=557db03de997c86a4a028e1ebd3a1ceb225be238
+
+echo "$hello_content" > hello
+
+git update-index --add hello
+
+run_tests 'blob' $hello_sha1 $hello_size "$hello_content" "$hello_content"
+
+tree_sha1=$(git write-tree)
+tree_size=33
+tree_pretty_content="100644 blob $hello_sha1 hello"
+
+run_tests 'tree' $tree_sha1 $tree_size "" "$tree_pretty_content"
+
+commit_message="Intial commit"
+commit_sha1=$(echo "$commit_message" | git commit-tree $tree_sha1)
+commit_size=177
+commit_content="tree $tree_sha1
+author $GIT_AUTHOR_NAME <$GIT_AUTHOR_EMAIL> 0000000000 +0000
+committer $GIT_COMMITTER_NAME <$GIT_COMMITTER_EMAIL> 0000000000 +0000
+
+$commit_message"
+
+run_tests 'commit' $commit_sha1 $commit_size "$commit_content" "$commit_content" 1
+
+tag_header="object $hello_sha1
+type blob
+tag hellotag
+tagger $GIT_COMMITTER_NAME <$GIT_COMMITTER_EMAIL>"
+tag_description="This is a tag"
+tag_content="$tag_header
+
+$tag_description"
+tag_pretty_content="$tag_header
+Thu Jan 1 00:00:00 1970 +0000
+
+$tag_description"
+
+tag_sha1=$(echo "$tag_content" | git mktag)
+tag_size=$(echo "$tag_content" | wc -c)
+
+run_tests 'tag' $tag_sha1 $tag_size "$tag_content" "$tag_pretty_content"
+
+test_expect_success \
+ "Reach a blob from a tag pointing to it" \
+ "test '$hello_content' = \"\$(git cat-file blob $tag_sha1)\""
+
+test_done
--
1.5.3.4.1337.g8e67d-dirty
^ permalink raw reply related
* [RESEND PATCH 0/9] Make git-svn fetch ~1.7x faster
From: Adam Roben @ 2007-10-25 10:25 UTC (permalink / raw)
To: git; +Cc: Junio Hamano
This is a resend of my previous patch series to speed up git-svn, taking into
account comments from Eric, Johannes, and Brian.
--
Documentation/git-cat-file.txt | 6 +-
Documentation/git-hash-object.txt | 5 +-
builtin-cat-file.c | 87 +++++++++++++++++----
git-svn.perl | 40 +++++-----
hash-object.c | 29 +++++++-
perl/Git.pm | 153 ++++++++++++++++++++++++++++++++++++-
t/t1005-cat-file.sh | 126 ++++++++++++++++++++++++++++++
t/t1006-hash-object.sh | 49 ++++++++++++
8 files changed, 452 insertions(+), 43 deletions(-)
^ permalink raw reply
* Re: best git practices, was Re: Git User's Survey 2007 unfinished summary continued
From: Andreas Ericsson @ 2007-10-25 10:24 UTC (permalink / raw)
To: Johannes Schindelin
Cc: Peter Baumann, J. Bruce Fields, Steffen Prohaska, Jakub Narebski,
Federico Mena Quintero, git
In-Reply-To: <Pine.LNX.4.64.0710251108330.25221@racer.site>
Johannes Schindelin wrote:
> Hi,
>
> On Thu, 25 Oct 2007, Andreas Ericsson wrote:
>
>> Johannes Schindelin wrote:
>>
>>> On Wed, 24 Oct 2007, Andreas Ericsson wrote:
>>>
>>>> Conceptually, I don't think it'll be any problem what so ever
>>>> telling anyone that the branches that aren't currently checked out
>>>> get merged automatically only if they result in a fast-forward.
>>> It would be a matter of seconds until someone asks "why only
>>> fast-forwards? Would it not be _much_ better to merge _always_?
>>> Stupid git."
>>>
>>> And all because the concept of "local" vs "remote" was blurred.
>> It's already blurred, since we have git-pull instead of just git-fetch.
>
> Huh? How is "I ask git pull to fetch the remote branch, and merge it into
> my local branch" a blurring of local vs remote branch?
>
> The local branch is still the local branch where it is _my_ responsibility
> to update or change anything.
True. So git pull saves you exactly one command. The various fetch-all-git-
repos-and-update-all-fast-forward-branches in circulation at the office
save us ~500 commands each time they're run. Or rather, they *could* do
that, but you can't know until you've run it.
So what should I do to make what I want possible, without having git-pull
muddy the waters of local vs remote? There's clearly a user desire for it,
besides that of my eight co-workers and myself. Introduce git-<cmd-156>?
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: best git practices, was Re: Git User's Survey 2007 unfinished summary continued
From: Johannes Schindelin @ 2007-10-25 10:17 UTC (permalink / raw)
To: Andreas Ericsson
Cc: Steffen Prohaska, Peter Baumann, J. Bruce Fields, Jakub Narebski,
Federico Mena Quintero, git
In-Reply-To: <47204297.5050109@op5.se>
Hi,
On Thu, 25 Oct 2007, Andreas Ericsson wrote:
> Johannes Schindelin wrote:
>
> > On Thu, 25 Oct 2007, Steffen Prohaska wrote:
> >
> > > On Oct 25, 2007, at 12:14 AM, Johannes Schindelin wrote:
> > >
> > > > But I think I have to drive my message home again: if what you
> > > > desire becomes reality, you take away the clear distinction
> > > > between local and remote branches. In fact, those branches are
> > > > neither local (because the next pull will automatically update
> > > > them with remote changes, but _only_ if they fast-forward) nor
> > > > remote (because you plan to work on them locally).
> > >
> > > Exactly, because I do not work on those branches alone. These are
> > > _shared_ branches. I can work on such a branch with a group of
> > > developers. I'm willing to accept this bit of chaos.
> >
> > It is not just a chaos. I see a serious problem here. On _your_
> > computer, you do _not_ have a shared branch. Which is visible _even_
> > in your modified work flow when you have unpushed changes.
>
> Ofcourse it is. People might pull from it. That's the whole point of a
> distributed model.
By that reasoning, left is right. Because your "left" is my "right".
> > So your desired illusion that your local branches are anything but
> > local branches will never be perfect enough.
> >
> > > Your rebase workflow is not possible if more than one dev wants to
> > > work on the topic branch together.
> >
> > Why not? I do it all the time. CVS users do it all the time, for
> > that matter.
>
> For 200 branches at a time, where any of them might have changed?
I slowly start to understand why your users are confused. _Nobody_ works
on 200 branches at the same time. (No, maintainers don't count: they do
not work _on_ the branches, but _with_; they merge them.)
When you're done with a topic, why do you leave it around? Cluttering up
your "git branch" output?
> > The problem I see here: you know git quite well. Others don't, and
> > will be mightily confused why pull updates local branches sometimes,
> > and sometimes not.
>
> Do you know this, or are you just guessing? I'm getting the exact same
> confusion with the current behaviour. "Why the hell doesn't git update
> all the branches I told the damn stupid tool to auto-merge when I pull?"
That's easy. A merge can have conflicts. Conflicts need a working
directory. You cannot have multiple working directories. (Actually, you
can, with git-new-workdir, which would break down _horribly_ with your
desired change.)
Oh? You don't have local changes? Then why _on earth_ do you have a
local branch?
Ciao,
Dscho
^ permalink raw reply
* Re: best git practices, was Re: Git User's Survey 2007 unfinished summary continued
From: Johannes Schindelin @ 2007-10-25 10:12 UTC (permalink / raw)
To: Andreas Ericsson
Cc: Peter Baumann, J. Bruce Fields, Steffen Prohaska, Jakub Narebski,
Federico Mena Quintero, git
In-Reply-To: <47204ECA.7040309@op5.se>
Hi,
On Thu, 25 Oct 2007, Andreas Ericsson wrote:
> Johannes Schindelin wrote:
>
> > On Wed, 24 Oct 2007, Andreas Ericsson wrote:
> >
> > > Conceptually, I don't think it'll be any problem what so ever
> > > telling anyone that the branches that aren't currently checked out
> > > get merged automatically only if they result in a fast-forward.
> >
> > It would be a matter of seconds until someone asks "why only
> > fast-forwards? Would it not be _much_ better to merge _always_?
> > Stupid git."
> >
> > And all because the concept of "local" vs "remote" was blurred.
>
> It's already blurred, since we have git-pull instead of just git-fetch.
Huh? How is "I ask git pull to fetch the remote branch, and merge it into
my local branch" a blurring of local vs remote branch?
The local branch is still the local branch where it is _my_ responsibility
to update or change anything. The remote branch is not. If at all, I can
push -- iff it fast-forwards.
The fact that you can set up local mirroring branches (with "git remote
add") which are only updated via "git fetch" is _no_ blurring of the
concepts: we make it quite explicit that you cannot check them out. They
are not local branches.
Hth,
Dscho
^ permalink raw reply
* Re: best git practices, was Re: Git User's Survey 2007 unfinished summary continued
From: Johannes Schindelin @ 2007-10-25 10:07 UTC (permalink / raw)
To: Andreas Ericsson
Cc: Jakub Narebski, J. Bruce Fields, Steffen Prohaska,
Federico Mena Quintero, git
In-Reply-To: <472048EB.1000707@op5.se>
Hi,
On Thu, 25 Oct 2007, Andreas Ericsson wrote:
> Jakub Narebski wrote:
> > On 10/24/07, Andreas Ericsson <ae@op5.se> wrote:
> >
> > > git pull. Not git push. git pull operates on one working branch at a
> > > time (by default), whereas git push uploads and fast-forwards all
> > > the common branches (by default). I want git pull to work like git
> > > push.
> >
> > git push is opposite (almost) to git fetch, not to git pull.
>
> Not to an end user that has no idea or desire to learn about git remotes
> or anything else.
At some point you _have_ to expect your users to learn something. In the
git documentation, we never pretend that pull is anything else than "fetch
+ merge".
So this assumption of your end user is a lack of training, really.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] git-cvsimport: Add -N option to force a new import
From: Johannes Schindelin @ 2007-10-25 9:56 UTC (permalink / raw)
To: Matt McCutchen; +Cc: Junio C Hamano, git
In-Reply-To: <1193284913.2619.23.camel@mattlaptop2>
Hi,
On Thu, 25 Oct 2007, Matt McCutchen wrote:
> On Wed, 2007-10-24 at 20:17 -0700, Junio C Hamano wrote:
> > Matt McCutchen <matt@mattmccutchen.net> writes:
> >
> > > I had a git repository for development of rsync and wanted to start
> > > importing the upstream CVS with git-cvsimport, but git-cvsimport saw
> > > that the git repository existed and insisted on updating a previous
> > > import. This patch adds an -N option to git-cvsimport to force a new
> > > import and updates the documentation appropriately.
> >
> > Sounds like a useful addition. Tests?
>
> Are there existing tests for git-cvsimport somewhere whose example I
> could follow? (I didn't see any in t/ .) If not, I suppose I will just
> write a simple script that runs git-cvsimport with and without -N and
> with and without an existing, empty git repository and checks that the
> right things happen.
My best bet: t/t9200-cvsexportcommit.sh
Hth,
Dscho
^ permalink raw reply
* Re: Feature request: Limit git-status reports to a directory
From: Johannes Schindelin @ 2007-10-25 9:55 UTC (permalink / raw)
To: Yin Ping; +Cc: Michel Marti, git
In-Reply-To: <46dff0320710241914t7d93aae1t991fbcaacde77046@mail.gmail.com>
Hi,
On Thu, 25 Oct 2007, Yin Ping wrote:
> On 10/25/07, Michel Marti <mma@objectxp.com> wrote:
> > I am sometimes interested in only seeing the status for a specific
> > directory (and its sub-directories), but git-status is no help in this
> > case - passing a directory does some sort of "git-commit --dry-run". I
> > first thought that this is a bug until I saw in the man-page that this
> > is actually a feature...
>
> It's also painful for me. IMHO, the behaviour of "git-status" should
> keep consistent with "git-diff" and "git-log" which allow for the path.
I am not so sure. In other SCMs, "git status" may be a way to do "git
diff --name-only" or "git ls-files", but not in git. Here, it strictly
means "what would be happening if I were to commit _right_ _now_?".
> Another point, It will be helpful to add a config item to change the
> default behaviour for 'git-diff" and "git-log". For example,
> 'diff.defaultcurrentpath=true' to let git only show difference in
> current directory instead of difference in top directory when typing
> 'git-diff'
IMHO it is not asking users too much when you say "git diff ." is for the
current directory, and "git diff" is for the whole working tree.
Besides, we cannot really change the default behaviour, since some
porcelains use "git log" (and certainly there are some which use "git
diff", too). They would suffer from this unexpected -- and indeed
inconsistent, since the setting can differ between repositories -- output.
Hth,
Dscho
^ permalink raw reply
* git-svnimport
From: Felipe Balbi @ 2007-10-25 9:25 UTC (permalink / raw)
To: git
Hello all,
I was importing busybox svn repository to git but I got a connection
timeout after more than 19k commits... is there a way to continue
where the error happened or should I do it all over again ??
Thanks
--
Best Regards,
Felipe Balbi
felipebalbi@users.sourceforge.net
^ permalink raw reply
* Re: best git practices, was Re: Git User's Survey 2007 unfinished summary continued
From: Steffen Prohaska @ 2007-10-25 8:25 UTC (permalink / raw)
To: Andreas Ericsson
Cc: Peter Baumann, Johannes Schindelin, J. Bruce Fields,
Jakub Narebski, Federico Mena Quintero, git
In-Reply-To: <47204C6D.3020900@op5.se>
On Oct 25, 2007, at 9:57 AM, Andreas Ericsson wrote:
> 50+ repositories, with stable, testing and maint branches. Some
> repos have more
> than that, so it amounts to roughly 200 branches. Each branch can
> be modified by
> anyone (we're a small company - everyone still works everywhere),
> but all changes
> should be done to the tip of the upstream branch. Especially for
> maint this is a
> bit of a problem, since we frequently have consultants out and
> about, and they
> sometimes find a bug that they commit locally to their own repo.
> They're in a
> hurry though, and have no connection to the mothership repo so they
> can't git-pull
> to get up to date. They aren't exactly developers, but savvy enough
> to fix a few
> simple bugs, but the concept of the locally-modifiable branches not
> being updated
> to their remote-tracking counterparts with each git-pull is just
> incomprehensible
> to them. To me, that suggests that we're doing something wrong.
Johannes described a workflow using rebase. It would create
a very clean history avoiding long "parallel roads" and it
mimics what experience git users would probably do: Just work
if you have no connection but cleanup your work by using rebase
before pushing it.
Johannes, and Peter, too, propose to delete local branches
asap to avoid the third copy besides the copy on the server
and the copy in remotes. They suggest that local branches
should be absolutely reserved for local work.
However, my feeling is that the current tools make it too hard
to work the way described. Therefore it's hard to sell such a
workflow to an unexperienced developer. For example checking
out a remote branch for doing some local work, pushing this
work, and cleaning up requires
git checkout -b <branch> origin/<branch>
# work work ...
git push origin <branch>
git checkout <don-t-work-here>
git branch -D <branch>
These are a lot of commands and some of them look quite
redundant. Nearly every command contains <branch>. Why isn't is
sufficient to tell the name of the branch I'm working on once.
And '-D' looks even dangerous to me because it overrides all
safety checks. This should not be needed in daily work.
Here are some questions:
Do you think a workflow using rebase is feasible for
unexperienced git users?
What would be needed to bring such a workflow down to a few,
simple and reliable commands?
I think the general question is what I described in a previous
mail: You have a shared repository containing stable and topic
branches. Provide a workflow that is as simple as possible
for as many as possible developers. The average developer
should need nothing more than equivalents of "cvs update",
"cvs commit" for daily work if there are no conflicts. Note,
there are no redundant branch names allowed in the commands.
If a developer doesn't switch branches there's no need to
tell the branch name. "git pull ; ... ; git push" is simple
but it has the problem of reporting errors that average devs
don't understand.
Steffen
^ permalink raw reply
* Re: best git practices, was Re: Git User's Survey 2007 unfinished summary continued
From: Andreas Ericsson @ 2007-10-25 8:07 UTC (permalink / raw)
To: Johannes Schindelin
Cc: Peter Baumann, J. Bruce Fields, Steffen Prohaska, Jakub Narebski,
Federico Mena Quintero, git
In-Reply-To: <Pine.LNX.4.64.0710242315310.25221@racer.site>
Johannes Schindelin wrote:
> Hi,
>
> On Wed, 24 Oct 2007, Andreas Ericsson wrote:
>
>> Conceptually, I don't think it'll be any problem what so ever telling
>> anyone that the branches that aren't currently checked out get merged
>> automatically only if they result in a fast-forward.
>
> It would be a matter of seconds until someone asks "why only
> fast-forwards? Would it not be _much_ better to merge _always_? Stupid
> git."
>
> And all because the concept of "local" vs "remote" was blurred.
>
It's already blurred, since we have git-pull instead of just git-fetch.
pull is the dwim version of fetch for anyone who isn't frequently pulling
from multiple repos that aren't configured as remotes (99% of git's users).
It really is. You configure it to merge this and that branch to those and
these branches. Sometimes it does and sometimes it doesn't, and the decision
is based on what branch you're currently on.
Only git-fetch has the clear local vs remote distinction, because it *never*
merges anything.
On a side-note, I'm starting to see why hg has gotten such a user-base.
Their docs focus on one repo per branch, which doesn't have this problem at
all.
So in short, letting "git-pull" fast-forward (or rebase; I like that idea)
the local copies of the remote tracking branches onto those remote tracking
branches will make life easier for:
* People who collaborate with others in a shared environment, where branch
heads frequently change in the mothership repo but all development is
supposed to be done at the tip of those mothership branches anyway.
Nearly all corporate users fall into this category.
* People who just want to track and test the latest and greatest version of
software X. Sometimes trying latest stable, and sometimes going with the
freshest beta. They won't want to do "git merge beta origin/beta" after
having done "git checkout beta", but they sure as hell don't want to run
anything but the latest either. They may contribute once in a while, but
generally just want to make sure they've got the bleeding edge.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: best git practices, was Re: Git User's Survey 2007 unfinished summary continued
From: Andreas Ericsson @ 2007-10-25 7:57 UTC (permalink / raw)
To: Peter Baumann
Cc: Johannes Schindelin, Steffen Prohaska, J. Bruce Fields,
Jakub Narebski, Federico Mena Quintero, git
In-Reply-To: <20071025073102.GD6069@xp.machine.xx>
Peter Baumann wrote:
> On Thu, Oct 25, 2007 at 09:15:35AM +0200, Andreas Ericsson wrote:
>> Johannes Schindelin wrote:
>>> Hi,
>>> On Thu, 25 Oct 2007, Steffen Prohaska wrote:
>>>> On Oct 25, 2007, at 12:14 AM, Johannes Schindelin wrote:
>>>>
>>>>> But I think I have to drive my message home again: if what you desire
>>>>> becomes reality, you take away the clear distinction between local and
>>>>> remote branches. In fact, those branches are neither local (because the
>>>>> next pull will automatically update them with remote changes, but _only_
>>>>> if they fast-forward) nor remote (because you plan to work on them
>>>>> locally).
>>>> Exactly, because I do not work on those branches alone. These are
>>>> _shared_ branches. I can work on such a branch with a group of
>>>> developers. I'm willing to accept this bit of chaos.
>>> It is not just a chaos. I see a serious problem here. On _your_
>>> computer, you do _not_ have a shared branch. Which is visible _even_ in
>>> your modified work flow when you have unpushed changes.
>> Ofcourse it is. People might pull from it. That's the whole point of a
>> distributed model.
>>
>>> So your desired illusion that your local branches are anything but local
>>> branches will never be perfect enough.
>>>> Your rebase workflow is not possible if more than one dev wants to work
>>>> on the topic branch together.
>>> Why not? I do it all the time. CVS users do it all the time, for that
>>> matter.
>> For 200 branches at a time, where any of them might have changed? Do they
>> *really* go into all those branches and make really, really sure they run
>> git pull before they ever do anything? Isn't there a teensy weensy risk of
>> them forgetting that sometime when they really meant to do it?
>>
>> On the other hand, if they absolutely *must* fork a branch at a specific
>> point in history (rather than "the latest published work this branch has"),
>> won't they run gitk/qgit/git-log/whatever, regardless of where their branch
>> head is?
>>
>>> The problem I see here: you know git quite well. Others don't, and will
>>> be mightily confused why pull updates local branches sometimes, and
>>> sometimes not.
>> Do you know this, or are you just guessing? I'm getting the exact same
>> confusion with the current behaviour. "Why the hell doesn't git update
>> all the branches I told the damn stupid tool to auto-merge when I pull?"
>> frequently echoes around the office. My co-workers aren't interested in
>> learning about git internals, or its reasons for doing what it does.
>> They don't give a damn about local vs remote namespaces for their branches.
>> They want to get some work done the smoothest way possible, but with our
>> small forest of repositories and the bushel of branches in each repo
>> makes life difficult for them, because they just can't imagine that
>> git doesn't do what they told it to, which is "this branch tracks that".
>> They may work on "this", but still want it to track "that" so they don't
>> have to run "git-update-all.sh", or "git-walk-everything.sh" or any other
>> of a dozen small and near-identical scripts floating around the office.
>>
>
> What actually wonders me why you guys do have 200 local branches. I
> usually just create a local branch from the remote IFF I'd like to do some
> work on it. And for inspecting a remote branch, a detached HEAD works just as
> fine ...
>
50+ repositories, with stable, testing and maint branches. Some repos have more
than that, so it amounts to roughly 200 branches. Each branch can be modified by
anyone (we're a small company - everyone still works everywhere), but all changes
should be done to the tip of the upstream branch. Especially for maint this is a
bit of a problem, since we frequently have consultants out and about, and they
sometimes find a bug that they commit locally to their own repo. They're in a
hurry though, and have no connection to the mothership repo so they can't git-pull
to get up to date. They aren't exactly developers, but savvy enough to fix a few
simple bugs, but the concept of the locally-modifiable branches not being updated
to their remote-tracking counterparts with each git-pull is just incomprehensible
to them. To me, that suggests that we're doing something wrong.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: best git practices, was Re: Git User's Survey 2007 unfinished summary continued
From: Andreas Ericsson @ 2007-10-25 7:42 UTC (permalink / raw)
To: Jakub Narebski
Cc: J. Bruce Fields, Steffen Prohaska, Johannes Schindelin,
Federico Mena Quintero, git
In-Reply-To: <8fe92b430710241648j609d4d00x121836001a69d1e6@mail.gmail.com>
Jakub Narebski wrote:
> On 10/24/07, Andreas Ericsson <ae@op5.se> wrote:
>
>> git pull. Not git push. git pull operates on one working branch
>> at a time (by default), whereas git push uploads and fast-forwards
>> all the common branches (by default). I want git pull to work like
>> git push.
>
> git push is opposite (almost) to git fetch, not to git pull.
>
Not to an end user that has no idea or desire to learn about git remotes
or anything else. They see "ok, push updates all the remote branches, but
only if it's a fast-forward". They also see "righto, git pull updates all
the local branches, and even merges and does other funny things", but they
*don't* understand why git-pull (in their eyes) only update ONE branch that
they can actually check out. From a technical standpoint, fetch and push
are the same, but from the user perspective, push and pull seem much more
alike.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: best git practices, was Re: Git User's Survey 2007 unfinished summary continued
From: Peter Baumann @ 2007-10-25 7:31 UTC (permalink / raw)
To: Andreas Ericsson
Cc: Johannes Schindelin, Steffen Prohaska, J. Bruce Fields,
Jakub Narebski, Federico Mena Quintero, git
In-Reply-To: <47204297.5050109@op5.se>
On Thu, Oct 25, 2007 at 09:15:35AM +0200, Andreas Ericsson wrote:
> Johannes Schindelin wrote:
>> Hi,
>> On Thu, 25 Oct 2007, Steffen Prohaska wrote:
>>> On Oct 25, 2007, at 12:14 AM, Johannes Schindelin wrote:
>>>
>>>> But I think I have to drive my message home again: if what you desire
>>>> becomes reality, you take away the clear distinction between local and
>>>> remote branches. In fact, those branches are neither local (because the
>>>> next pull will automatically update them with remote changes, but _only_
>>>> if they fast-forward) nor remote (because you plan to work on them
>>>> locally).
>>> Exactly, because I do not work on those branches alone. These are
>>> _shared_ branches. I can work on such a branch with a group of
>>> developers. I'm willing to accept this bit of chaos.
>> It is not just a chaos. I see a serious problem here. On _your_
>> computer, you do _not_ have a shared branch. Which is visible _even_ in
>> your modified work flow when you have unpushed changes.
>
> Ofcourse it is. People might pull from it. That's the whole point of a
> distributed model.
>
>> So your desired illusion that your local branches are anything but local
>> branches will never be perfect enough.
>>> Your rebase workflow is not possible if more than one dev wants to work
>>> on the topic branch together.
>> Why not? I do it all the time. CVS users do it all the time, for that
>> matter.
>
> For 200 branches at a time, where any of them might have changed? Do they
> *really* go into all those branches and make really, really sure they run
> git pull before they ever do anything? Isn't there a teensy weensy risk of
> them forgetting that sometime when they really meant to do it?
>
> On the other hand, if they absolutely *must* fork a branch at a specific
> point in history (rather than "the latest published work this branch has"),
> won't they run gitk/qgit/git-log/whatever, regardless of where their branch
> head is?
>
>> The problem I see here: you know git quite well. Others don't, and will
>> be mightily confused why pull updates local branches sometimes, and
>> sometimes not.
>
> Do you know this, or are you just guessing? I'm getting the exact same
> confusion with the current behaviour. "Why the hell doesn't git update
> all the branches I told the damn stupid tool to auto-merge when I pull?"
> frequently echoes around the office. My co-workers aren't interested in
> learning about git internals, or its reasons for doing what it does.
> They don't give a damn about local vs remote namespaces for their branches.
> They want to get some work done the smoothest way possible, but with our
> small forest of repositories and the bushel of branches in each repo
> makes life difficult for them, because they just can't imagine that
> git doesn't do what they told it to, which is "this branch tracks that".
> They may work on "this", but still want it to track "that" so they don't
> have to run "git-update-all.sh", or "git-walk-everything.sh" or any other
> of a dozen small and near-identical scripts floating around the office.
>
What actually wonders me why you guys do have 200 local branches. I
usually just create a local branch from the remote IFF I'd like to do some
work on it. And for inspecting a remote branch, a detached HEAD works just as
fine ...
-Peter
^ permalink raw reply
* Re: best git practices, was Re: Git User's Survey 2007 unfinished summary continued
From: Peter Baumann @ 2007-10-25 7:26 UTC (permalink / raw)
To: Andreas Ericsson
Cc: J. Bruce Fields, Steffen Prohaska, Johannes Schindelin,
Jakub Narebski, Federico Mena Quintero, git
In-Reply-To: <471FBF29.8030802@op5.se>
On Wed, Oct 24, 2007 at 11:54:49PM +0200, Andreas Ericsson wrote:
> Peter Baumann wrote:
>> On Wed, Oct 24, 2007 at 11:06:24PM +0200, Andreas Ericsson wrote:
>>> J. Bruce Fields wrote:
>>>> On Wed, Oct 24, 2007 at 10:12:29PM +0200, Steffen Prohaska wrote:
>>>>> On Oct 24, 2007, at 9:48 PM, J. Bruce Fields wrote:
>>>>>
>>>>>>> I want git pull to work like git push.
>>>>>> That strikes me as a less complete solution, since it only helps in
>>>>>> the
>>>>>> case where the other branches all happen to be unmodified locally
>>>>>> (hence
>>>>>> can be fast-forwarded). In other cases the "git push" will still emit
>>>>>> a
>>>>>> spurious error.
>>>>> Well, but then there's something you should really think
>>>>> about.
>>>> Perhaps, but not necessarily; you may have some branches with local
>>>> changes that you're content to leave unpushed (and un-updated).
>>> Sure, but that won't change. The only thing I'm proposing is that
>>> local copies of remote branches are automatically fast-forwarded
>>> on every pull, but only if
>>>
>>> * the branch has no modifications what so ever
>>> * the branch is set up to auto-merge with the particular branch
>>> fetched from the particular remote
>>>
>>> I really don't see any downsides what so ever with this. Those
>>> of you who do, please enlighten me.
>>>
>> You can't check what got added in your pull, e.g you can't review the new
>> code with something like
>> gitk next..origin/next
>
> That's what git-fetch is for.
>
If I run git pull <remote> and have a auto-merge setup, I would merge the
remote side into my local branch. Then doing
gitk ORIG_HEAD..
does the trick for to review what got added _and_ merged into my local
branch. I can't use this for other local branches not checked out. And as
I normally want to merge, your suggested behaviour is fine with me *IFF*
it is configurable _per_ branch.
>> I often do something like this, just to see what got changed. So at least
>> in my opinion you have to add a third point:
>> * the branch has no modifications what so ever
>> * the branch is set up to auto-merge with the particular branch
>> fetched from the particular remote
>> AND
>> * the user set a config option to always autofastfoward if the above
>> conditions are true! This could be implemented as a global option with
>> a per branch overwrite.
>
> I'd be fine with that, except I think it's fairly dangerous to have
> different defaults. The two first points are sort of the core of the
> case I've been arguing all along.
>
I aggree. And thats why I think your autofastforward should be set to
"false" per default, so that the distinction between local and remote
branches would still be clearly defined. Changing this would confuse new
users a lot more, me thinks.
But having the option for power users sounds fine!
>> Only if this option is added so a user can mark a branch to never
>> autofastforward (but it is still possible to have an auto-merge config)
>> you won't
>> loose valuable information.
>
> Sure. I was thinking something along these lines:
>
> [branch "foo"]
> remote = bar
> merge = some-branch
> autofastforward = false
>
Thats exactlcy what I had in mind. Maybe and a
[core]
global_autofastforward = true
so you could have a sane default for every branch which is missing the
autofastforward statement. (or make it per [remote "foo"] ?)
> Or use git-fetch. git-pull is "fetch + merge". Conceptually, I don't
> think it'll be any problem what so ever telling anyone that the branches
> that aren't currently checked out get merged automatically only if they
> result in a fast-forward.
>
I'm not so sure about that.
-Peter
^ permalink raw reply
* Re: best git practices, was Re: Git User's Survey 2007 unfinished summary continued
From: Andreas Ericsson @ 2007-10-25 7:15 UTC (permalink / raw)
To: Johannes Schindelin
Cc: Steffen Prohaska, Peter Baumann, J. Bruce Fields, Jakub Narebski,
Federico Mena Quintero, git
In-Reply-To: <Pine.LNX.4.64.0710250021430.25221@racer.site>
Johannes Schindelin wrote:
> Hi,
>
> On Thu, 25 Oct 2007, Steffen Prohaska wrote:
>
>> On Oct 25, 2007, at 12:14 AM, Johannes Schindelin wrote:
>>
>>> But I think I have to drive my message home again: if what you desire
>>> becomes reality, you take away the clear distinction between local and
>>> remote branches. In fact, those branches are neither local (because
>>> the next pull will automatically update them with remote changes, but
>>> _only_ if they fast-forward) nor remote (because you plan to work on
>>> them locally).
>> Exactly, because I do not work on those branches alone. These are
>> _shared_ branches. I can work on such a branch with a group of
>> developers. I'm willing to accept this bit of chaos.
>
> It is not just a chaos. I see a serious problem here. On _your_
> computer, you do _not_ have a shared branch. Which is visible _even_ in
> your modified work flow when you have unpushed changes.
>
Ofcourse it is. People might pull from it. That's the whole point of a
distributed model.
> So your desired illusion that your local branches are anything but local
> branches will never be perfect enough.
>
>> Your rebase workflow is not possible if more than one dev wants to work
>> on the topic branch together.
>
> Why not? I do it all the time. CVS users do it all the time, for that
> matter.
>
For 200 branches at a time, where any of them might have changed? Do they
*really* go into all those branches and make really, really sure they run
git pull before they ever do anything? Isn't there a teensy weensy risk of
them forgetting that sometime when they really meant to do it?
On the other hand, if they absolutely *must* fork a branch at a specific
point in history (rather than "the latest published work this branch has"),
won't they run gitk/qgit/git-log/whatever, regardless of where their branch
head is?
>
> The problem I see here: you know git quite well. Others don't, and will
> be mightily confused why pull updates local branches sometimes, and
> sometimes not.
Do you know this, or are you just guessing? I'm getting the exact same
confusion with the current behaviour. "Why the hell doesn't git update
all the branches I told the damn stupid tool to auto-merge when I pull?"
frequently echoes around the office. My co-workers aren't interested in
learning about git internals, or its reasons for doing what it does.
They don't give a damn about local vs remote namespaces for their branches.
They want to get some work done the smoothest way possible, but with our
small forest of repositories and the bushel of branches in each repo
makes life difficult for them, because they just can't imagine that
git doesn't do what they told it to, which is "this branch tracks that".
They may work on "this", but still want it to track "that" so they don't
have to run "git-update-all.sh", or "git-walk-everything.sh" or any other
of a dozen small and near-identical scripts floating around the office.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: [PATCH 6/7] walk PATH to generate list of commands for "help -a"
From: Scott Parish @ 2007-10-25 7:07 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vk5pb21xv.fsf@gitster.siamese.dyndns.org>
On Wed, Oct 24, 2007 at 10:33:32PM -0700, Junio C Hamano wrote:
> > Well, the ultimate reason that i've been working on all of this is
> > i'd like to push git as a viable development tool where i work. To
> > give an effective idea, lets say that shared tools get placed on
> > nfs servers, which can be mounted to different paths depending on
> > which nfs server is up or down or which system is the nfs client.
>
> It sounds to me that your nfs client systems might find what
> people usually expect in /usr/local/bin not there but on
> /mnt/random47/bin depending on the system, without a reasonable
> system administration effort that places stable symlinks to give
> end users a consistent view of the world regardless from which
> client, which sounds insane. I personally do not think we
> should support lazy system administrators by making git unsafe.
Well, the exact details are completely fictitious, made up to
illustrate the situation without breaking confidential agreements.
I'm not sure i completely agree with the design, but there are good
reasons for it, and at this point i have little or no control over
it.
> >> It may be nicer if the user can somehow tell from the output if
> >> each of the command is from the standard set (i.e. on
> >> GIT_EXEC_PATH or built-in), or from a non standard place (either
> >> custom command as intended, or an unintended obsolete leftover).
> >
> > What if git marked commands that weren't found in the location where
> > it thinks that it is running from?
>
> Currently "git help -a" says "available in $where" at the top.
> Perhaps make a separate list that is listed as "available from
> elsewhere" and show the ones that are on PATH but not masked by
> the ones on GIT_EXEC_PATH?
>
> git commands available in '/home/junio/git-next/bin'
> ----------------------------------------------------
> add gui rebase--interactive
> add--interactive hash-object receive-pack
> ...
>
> git commands available from elsewhere on your $PATH
> ----------------------------------------------------
> frotz nitfol
Nice! I'll try doing that, probably won't have time to finish until
later tomorrow.
sRp
--
Scott Parish
http://srparish.net/
^ permalink raw reply
* [PATCH 5/7] chdir() into list_commands() dir instead of building paths for stat()
From: Scott R Parish @ 2007-10-25 6:32 UTC (permalink / raw)
To: git; +Cc: Scott R Parish
In-Reply-To: <1193293802-3732-1-git-send-email-srp@srparish.net>
Signed-off-by: Scott R Parish <srp@srparish.net>
---
help.c | 18 +++---------------
1 files changed, 3 insertions(+), 15 deletions(-)
diff --git a/help.c b/help.c
index d6dfdff..322ddaa 100644
--- a/help.c
+++ b/help.c
@@ -96,36 +96,24 @@ static void pretty_print_string_list(struct cmdname **cmdname, int longest)
static void list_commands(const char *exec_path)
{
unsigned int longest = 0;
- char path[PATH_MAX];
const char *prefix = "git-";
int prefix_len = strlen(prefix);
- int dirlen;
DIR *dir = opendir(exec_path);
struct dirent *de;
- if (!dir) {
+ if (!dir || chdir(exec_path)) {
fprintf(stderr, "git: '%s': %s\n", exec_path, strerror(errno));
exit(1);
}
- dirlen = strlen(exec_path);
- if (PATH_MAX - 20 < dirlen) {
- fprintf(stderr, "git: insanely long exec-path '%s'\n",
- exec_path);
- exit(1);
- }
-
- memcpy(path, exec_path, dirlen);
- path[dirlen++] = '/';
-
while ((de = readdir(dir)) != NULL) {
struct stat st;
int entlen;
if (prefixcmp(de->d_name, prefix))
continue;
- strcpy(path+dirlen, de->d_name);
- if (stat(path, &st) || /* stat, not lstat */
+
+ if (stat(de->d_name, &st) || /* stat, not lstat */
!S_ISREG(st.st_mode) ||
!(st.st_mode & S_IXUSR))
continue;
--
gitgui.0.8.4.11178.g9a1bf-dirty
^ permalink raw reply related
* [PATCH 2/7] remove unused/unneeded "pattern" argument of list_commands
From: Scott R Parish @ 2007-10-25 6:30 UTC (permalink / raw)
To: git; +Cc: Scott R Parish
In-Reply-To: <7v640v3ix1.fsf@gitster.siamese.dyndns.org>
list_commands() currently accepts and ignores a "pattern" argument,
and then hard codes a prefix as well as some magic numbers. This
hardcodes the prefix inside of the function and removes the magic
numbers.
Signed-off-by: Scott R Parish <srp@srparish.net>
---
help.c | 14 ++++++++------
1 files changed, 8 insertions(+), 6 deletions(-)
diff --git a/help.c b/help.c
index b0d2dd4..d6dfdff 100644
--- a/help.c
+++ b/help.c
@@ -93,10 +93,12 @@ static void pretty_print_string_list(struct cmdname **cmdname, int longest)
}
}
-static void list_commands(const char *exec_path, const char *pattern)
+static void list_commands(const char *exec_path)
{
unsigned int longest = 0;
char path[PATH_MAX];
+ const char *prefix = "git-";
+ int prefix_len = strlen(prefix);
int dirlen;
DIR *dir = opendir(exec_path);
struct dirent *de;
@@ -120,7 +122,7 @@ static void list_commands(const char *exec_path, const char *pattern)
struct stat st;
int entlen;
- if (prefixcmp(de->d_name, "git-"))
+ if (prefixcmp(de->d_name, prefix))
continue;
strcpy(path+dirlen, de->d_name);
if (stat(path, &st) || /* stat, not lstat */
@@ -128,14 +130,14 @@ static void list_commands(const char *exec_path, const char *pattern)
!(st.st_mode & S_IXUSR))
continue;
- entlen = strlen(de->d_name);
+ entlen = strlen(de->d_name) - prefix_len;
if (has_extension(de->d_name, ".exe"))
entlen -= 4;
if (longest < entlen)
longest = entlen;
- add_cmdname(de->d_name + 4, entlen-4);
+ add_cmdname(de->d_name + prefix_len, entlen);
}
closedir(dir);
@@ -143,7 +145,7 @@ static void list_commands(const char *exec_path, const char *pattern)
printf("----------------------------");
mput_char('-', strlen(exec_path));
putchar('\n');
- pretty_print_string_list(cmdname, longest - 4);
+ pretty_print_string_list(cmdname, longest);
putchar('\n');
}
@@ -210,7 +212,7 @@ int cmd_help(int argc, const char **argv, const char *prefix)
else if (!strcmp(help_cmd, "--all") || !strcmp(help_cmd, "-a")) {
printf("usage: %s\n\n", git_usage_string);
if(exec_path)
- list_commands(exec_path, "git-*");
+ list_commands(exec_path);
exit(0);
}
--
gitgui.0.8.4.11178.g9a1bf-dirty
^ permalink raw reply related
* Re: best git practices, was Re: Git User's Survey 2007 unfinished summary continued
From: Karl Hasselström @ 2007-10-25 6:10 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git, Catalin Marinas
In-Reply-To: <8fe92b430710241627v3ec51b20qf0b4e60356336363@mail.gmail.com>
On 2007-10-25 01:27:10 +0200, Jakub Narebski wrote:
> On 10/24/07, Karl Hasselström <kha@treskal.com> wrote:
>
> > On 2007-10-24 13:04:01 +0200, Jakub Narebski wrote:
> >
> > > By the way, there is SRPM for StGIT in
> > > http://homepage.ntlworld.com/cmarinas/stgit/ (I need it because
> > > I have Python 2.4), but it is not listed on downloads page...
> >
> > I'll leave the webpage question to Catalin, but I'm curious about
> > the Python version remark. What exactly is the problem?
>
> If I remember correctly the StGIT RPM requires python 2.5 (and is
> build using python 2.5, so install with --force doesn't work).
Hmm. That's overkill, considering that only 2.4 is actually required
(and until recently, we tried to be careful to only require 2.3).
--
Karl Hasselström, kha@treskal.com
www.treskal.com/kalle
^ permalink raw reply
* Re: best git practices, was Re: Git User's Survey 2007 unfinished summary continued
From: Steffen Prohaska @ 2007-10-25 6:02 UTC (permalink / raw)
To: Johannes Schindelin
Cc: Peter Baumann, Andreas Ericsson, J. Bruce Fields, Jakub Narebski,
Federico Mena Quintero, git
In-Reply-To: <Pine.LNX.4.64.0710250021430.25221@racer.site>
On Oct 25, 2007, at 1:28 AM, Johannes Schindelin wrote:
> On Thu, 25 Oct 2007, Steffen Prohaska wrote:
>
>> On Oct 25, 2007, at 12:14 AM, Johannes Schindelin wrote:
>>
>>> But I think I have to drive my message home again: if what you
>>> desire
>>> becomes reality, you take away the clear distinction between
>>> local and
>>> remote branches. In fact, those branches are neither local (because
>>> the next pull will automatically update them with remote changes,
>>> but
>>> _only_ if they fast-forward) nor remote (because you plan to work on
>>> them locally).
>>
>> Exactly, because I do not work on those branches alone. These are
>> _shared_ branches. I can work on such a branch with a group of
>> developers. I'm willing to accept this bit of chaos.
>
> It is not just a chaos. I see a serious problem here. On _your_
> computer, you do _not_ have a shared branch. Which is visible
> _even_ in
> your modified work flow when you have unpushed changes.
>
> So your desired illusion that your local branches are anything but
> local
> branches will never be perfect enough.
Ok, there is not a fundamental difference between local branches
that automatically merge from remotes and local branches that
are purely local and _never_ merge anything automatically. Both
are only local branches.
But these two types of branches already behave differently when
I call "git pull". There is already some kind of "illusion"
that some local branches are more tightly connected to remote
branches than others.
"git pull" could help to make the illusion even better. The
illusion would be better if it was easier to keep the heads
of the local branches near to the heads of branches they
automatically merge from, as long as this is easily possible.
>> Your rebase workflow is not possible if more than one dev wants to
>> work
>> on the topic branch together.
>
> Why not? I do it all the time. CVS users do it all the time, for
> that
> matter.
You're right. You can rebase your local changes on top of the new
shared remote head. And this is probably the best thing you can do
to get a clean history. Maybe it should be easier.
So, do I understand correctly, what you propose is:
- never merge but only rebase
- Due to lacking support for this in "git pull", never use
git pull when working with shared branches but instead _always_ use
"git fetch; git rebase origin/<branch_I'm_on>".
So you say that one of the first messages in "git for CVS users",
"The equivalent of cvs update is git pull origin" [1], is wrong.
I don't think I'm able to sell your proposed workflow with the current
documentation. But maybe I try if I'm absolutely convinced that it
is superior.
[1] http://www.kernel.org/pub/software/scm/git/docs/cvs-migration.html
>>> But here is a proposal which should make you and your developers
>>> happy, _and_ should be even easier to explain:
>>>
>>> Work with topic branches. And when you're done, delete them.
>>
>> Again, if you want to share the topic branch the situation gets
>> more complex.
>
> Hardly so. In my proposed solution to your problem, there is nothing
> which prevents you from working off of another branch than "master".
Well if you have several local branches checked out that are
shared with others you run into the "git push" problem again ...
(see below at git push origin master).
>>> So the beginning of the day could look like this:
>>>
>>> git fetch
>>> git checkout -b todays-topic origin/master
>>>
>>> [hack hack hack]
>>> [test test test]
>>> [debug debug debug]
>>> [occasionally commit]
>>> [occasionally git rebase -i origin/master]
>>>
>>> and the end of the topic
>>>
>>> git branch -M master
Isn't this a bit dangerous? It forces to overwrite master
no matter what's on it. You don't see diffstats nor a fast
forward message that confirms what you're doing.
>>> git push origin master
I'd like to see "git push" here. But to make this work without
error you'd need to _delete_ master after you pushed. Otherwise
it could happen that you later work on a different shared
branch and "git push" would complain about master. "git push"
would recommend to do a "git pull" and we're back where the
discussion started.
Or do you propose to delete master at this point? That is do
you propose to _never_ have remote branches checked out locally.
Except for a very short period when you do
git branch -m <shared_branch>
git push origin <shared_branch>
git checkout do-not-work-here
git branch -D <shared_branch>
>>> If you should not be ready to push by the end of the day, no need to
>>> worry. Just stay on that topic branch, and before pushing, do
>>>
>>> git fetch
>>> git rebase origin/master
>>>
>>> In _every_ case where I explained git, I found that people
>>> appreciated the
>>> two-step procedures (like you will find in the examples I showed you
>>> above): one git command to work locally, and one to push/fetch to/
>>> from
>>> origin.
>>
>> Maybe. I know git quite well now and in a shared workflow "git pull"
>> with auto-fast-forward would help me. I often need to run "for each
>> local branch: git checkout ; git merge" to get rid of the errors
>> reported by "git push".
>
> The problem I see here: you know git quite well. Others don't, and
> will
> be mightily confused why pull updates local branches sometimes, and
> sometimes not.
But it already happens now. "git pull" sometimes merges a
remote branch (--track) and sometimes it reports an error that
is fails to do so (--no-track). It would only do more work
automatically in the future and report appropriate warnings
or errors if it runs into a problem.
Steffen
^ permalink raw reply
* Re: [PATCH 6/7] walk PATH to generate list of commands for "help -a"
From: Junio C Hamano @ 2007-10-25 5:33 UTC (permalink / raw)
To: Scott Parish; +Cc: git
In-Reply-To: <20071025050736.GG759@srparish.net>
Scott Parish <sRp@srparish.net> writes:
> On Wed, Oct 24, 2007 at 09:42:42PM -0700, Junio C Hamano wrote:
>
>> Scott R Parish <srp@srparish.net> writes:
>>
>> > Signed-off-by: Scott R Parish <srp@srparish.net>
>>
>> Rationale?
>
> Well, the ultimate reason that i've been working on all of this is
> i'd like to push git as a viable development tool where i work. To
> give an effective idea, lets say that shared tools get placed on
> nfs servers, which can be mounted to different paths depending on
> which nfs server is up or down or which system is the nfs client.
It sounds to me that your nfs client systems might find what
people usually expect in /usr/local/bin not there but on
/mnt/random47/bin depending on the system, without a reasonable
system administration effort that places stable symlinks to give
end users a consistent view of the world regardless from which
client, which sounds insane. I personally do not think we
should support lazy system administrators by making git unsafe.
But using PATH as a fallback is what we already do for scripts,
and that is good enough to deal with such an installation.
> Should i be putting all that in my commit messages?
Even in a well behaved installation, where everything is found
where they should be (iow, GIT_EXEC_PATH), this is needed
because 4/7 lets you run a custom "git that" command from PATH
and this 6/7 is to teach "help -a" about it. I think at least
that much needs to be said in the commit message.
>> There are two cases execv_git_cmd() runs "git-that" from a non
>> standard place, if we take your [PATCH 4/7].
>>
>> - If there is a directory that contains a location that used to
>> hold an old installation of git-* commands (some of which may
>> have been removed in the latest git) and if the user has that
>> directory on PATH, we would run obsolete git subcommand from
>> there.
>
> I could see that as being problematic. I suppose there are ways
> around that (have "git" pass to "git-cmd" an argument of what version
> it is) but none that i really like.
As I said, this is making git a bit less safe from unintended
leftover executables, but the scripts already work that way and
your 4/7 merely makes the C level in line with that behaviour.
I do not think it is too much of a problem anyway.
>> It may be nicer if the user can somehow tell from the output if
>> each of the command is from the standard set (i.e. on
>> GIT_EXEC_PATH or built-in), or from a non standard place (either
>> custom command as intended, or an unintended obsolete leftover).
>
> What if git marked commands that weren't found in the location where
> it thinks that it is running from?
Currently "git help -a" says "available in $where" at the top.
Perhaps make a separate list that is listed as "available from
elsewhere" and show the ones that are on PATH but not masked by
the ones on GIT_EXEC_PATH?
git commands available in '/home/junio/git-next/bin'
----------------------------------------------------
add gui rebase--interactive
add--interactive hash-object receive-pack
...
git commands available from elsewhere on your $PATH
----------------------------------------------------
frotz nitfol
^ 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