* Re: HP-UX issues (WAS: Re: [RFC] Git User's Survey 2008)
From: Miklos Vajna @ 2008-07-23 23:45 UTC (permalink / raw)
To: Jakub Narebski; +Cc: Junio C Hamano, git
In-Reply-To: <200807232338.04340.jnareb@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1572 bytes --]
On Wed, Jul 23, 2008 at 11:38:00PM +0200, Jakub Narebski <jnareb@gmail.com> wrote:
> > 2) Have coreutils installed. (But then I think it would be good to list
> > this dependency in INSTALL.)
>
> It would be good idea, although "POSIX-compliant shells" implies
> coreutils somewhat; shell scripts usually do require some utilities,
> like sed, grep, cat, test etc.
Sure, but we already use test_cmp instead of diff -u, avoid grep -a,
etc. These tricks are for running without GNU coreutils, I guess.
> > 3) Patch git to use automake's install-sh. (Would such a patch be ever
> > accepted?)
>
> I think it would. It would allow us also to uncomment the
> AC_PROG_INSTALL line in configure.ac file to find 'install'
> automatically (autoconf requires having install.sh or install-sh
> fallback in the sources).
>
> The problem is coming up with minimal yet portable (at least as
> portable as git itself) fallback install.sh script.
I just checked automake-1.10.1's install-sh script, it works properly
with HP-UX's ksh.
I think it would be possible to:
1) Just use it: in long-term this would mean no additional maintenance
cost, since if any problem occurs, it could be just updated from
automake.
2) Or make it as minimal as possible: As far as I see the current git
build system just uses the -d and -m switches, so the support for the
-c, -C, -g, -o, -s, -t and -T switches could be removed. This way we
would get a minimal install-sh, but then it would have to be maintained
inside git.git.
I think 1) would be better.
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: [PATCH] rebase -i: only automatically amend commit if HEAD did not change
From: Junio C Hamano @ 2008-07-23 23:41 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <alpine.DEB.1.00.0807222235520.8986@racer>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> If the user called "rebase -i", marked a commit as "edit", "rebase
> --continue" would automatically amend the commit when there were
> staged changes.
>
> However, this is actively wrong when the current commit is not the
> one marked with "edit". So guard against this.
At what point in what valid workflow sequence does HEAD become different
from dotest/amend?
> @@ -419,7 +419,9 @@ do
> else
> . "$DOTEST"/author-script ||
> die "Cannot find the author identity"
> - if test -f "$DOTEST"/amend
> + if test -f "$DOTEST"/amend &&
> + test $(git rev-parse HEAD) = \
> + $(cat "$DOTEST"/amend)
> then
> git reset --soft HEAD^ ||
> die "Cannot rewind the HEAD"
In what way is this "guarding against it"? It goes on and makes an
unrelated commit without erroring out nor giving indication to the user
what is going on, doesn't it?
I am sure you meant well and the code is good, but I find that the
explanation is a bit lacking...
^ permalink raw reply
* Re: [RFC] Git User's Survey 2008
From: Johannes Schindelin @ 2008-07-23 23:33 UTC (permalink / raw)
To: Jakub Narebski; +Cc: Robin Rosenberg, git
In-Reply-To: <200807240130.31649.jnareb@gmail.com>
Hi,
On Thu, 24 Jul 2008, Jakub Narebski wrote:
> C# for git#/widgit
widgit is _dead_.
> and perhaps Git-Cheetah
C# for Git-Cheetah? Over my dead cold body.
Ciao,
Dscho "who still shakes his head that Jakub could even _think_ that"
^ permalink raw reply
* Re: [PATCH] t9700/test.pl: backwards compatibility improvements
From: Junio C Hamano @ 2008-07-23 23:33 UTC (permalink / raw)
To: Brandon Casey; +Cc: Git Mailing List
In-Reply-To: <k-pcfapbFwwISYvjf34W3d-E7j-DCb9tf-MW1z8rFObaPKgPJEmD7Q@cipher.nrlssc.navy.mil>
I have applied everything except for this one. I think it is Ok, but
let's hear success or breakage stories from the list first and then remind
me if the patch seems Ok, please?
^ permalink raw reply
* Re: [RFC] Git User's Survey 2008
From: Jakub Narebski @ 2008-07-23 23:30 UTC (permalink / raw)
To: Robin Rosenberg; +Cc: Johannes Schindelin, git
In-Reply-To: <200807231654.18019.robin.rosenberg.lists@dewire.com>
Dnia środa 23. lipca 2008 16:54, Robin Rosenberg napisał:
> onsdagen den 23 juli 2008 15.18.40 skrev Johannes Schindelin:
>> On Wed, 23 Jul 2008, Jakub Narebski wrote:
>>> On Wed, 23 Jul 2008, Johannes Schindelin wrote:
>>>> On Wed, 23 Jul 2008, Jakub Narebski wrote:
>>>>
>>>>> 04. Which programming languages you are proficient with?
>>>>> (The choices include programming languages used by git)
>>>>> (zero or more: multiple choice)
>>>>> - C, shell, Perl, Python, Tcl/Tk
>>>>> + (should we include other languages, like C++, Java, PHP,
>>>>> Ruby,...?)
>>>>
>>>> Yes, I think this should be a long list.
>>>
>>> I'd rather not have a "laundry list" of languages. I have put C++
>>> because QGit uses it, Java because of egit/jgit, PHP for web
>>> interfaces, Ruby because of GitHub and because of Ruby comminity
>>> choosing Git. I should perhaps add Emacs Lisp, HTML+CSS and
>>> JavaScript here. What other languages should be considered?
>>
>> C# at least, since we had one (pretty unsuccessful) attempt at
>> reimplementing Git in it.
>
> What is the reason for the question? Do we want to know what languages
> people would like to contribute to Git in or do we want to know what "kind"
> of programmers are attracted by Git? Making it a long list should make
> it easier to tabulate the responses.
The idea is, I think, to know what languages people could contribute
to Git; see analysis of this question at GitSurvey2007 page on git wiki:
http://git.or.cz/gitwiki/GitSurvey2007#head-ecb5564d71e4093e2e93e508380407a26dbcbdea
C++ is for QGit, Java for egit/jgit, C# for git#/widgit and perhaps
Git-Cheetah, PHP for web interfaces, Ruby because of GitHub, Python
because some contrib is in Python, Emacs Lisp for git.el, HTML+CSS
and JavaScript for web interfaces; perhaps we should also add AsciiDoc
for documentation. And of course "I am not programmer" response...
But I'm not too tied to this question; I guess it can be simply
removed if it doesn't offer some important (for us) information.
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: [PATCH] perl/Makefile: update NO_PERL_MAKEMAKER section
From: Junio C Hamano @ 2008-07-23 23:29 UTC (permalink / raw)
To: Brandon Casey; +Cc: Git Mailing List
In-Reply-To: <XKT02T_QW2tKLHpR7e3VuZjLXv3RP2E0GD54gXKrdIFm8xQsKvAyjg@cipher.nrlssc.navy.mil>
Brandon Casey <casey@nrlssc.navy.mil> writes:
> The perl modules must be copied to blib/lib so they are available for
> testing.
True, but private-Error needs to be handled a bit more carefully, I
think.
How about this on top of your patch?
perl/Makefile | 10 ++++++----
1 files changed, 6 insertions(+), 4 deletions(-)
diff --git a/perl/Makefile b/perl/Makefile
index 2b0d3d5..b8547db 100644
--- a/perl/Makefile
+++ b/perl/Makefile
@@ -25,13 +25,15 @@ $(makfile): ../GIT-CFLAGS Makefile
echo all: private-Error.pm Git.pm > $@
echo ' mkdir -p blib/lib' >> $@
echo ' $(RM) blib/lib/Git.pm; cp Git.pm blib/lib/' >> $@
- echo ' $(RM) blib/lib/Error.pm; \
- cp private-Error.pm blib/lib/Error.pm' >> $@
+ echo ' $(RM) blib/lib/Error.pm' >> $@
+ '$(PERL_PATH_SQ)' -MError -e 'exit($$Error::VERSION < 0.15009)' || \
+ echo ' cp private-Error.pm blib/lib/Error.pm' >> $@
echo install: >> $@
echo ' mkdir -p $(instdir_SQ)' >> $@
echo ' $(RM) $(instdir_SQ)/Git.pm; cp Git.pm $(instdir_SQ)' >> $@
- echo ' $(RM) $(instdir_SQ)/Error.pm; \
- cp private-Error.pm $(instdir_SQ)/Error.pm' >> $@
+ echo ' $(RM) $(instdir_SQ)/Error.pm' >> $@
+ '$(PERL_PATH_SQ)' -MError -e 'exit($$Error::VERSION < 0.15009)' || \
+ echo ' cp private-Error.pm $(instdir_SQ)/Error.pm' >> $@
echo instlibdir: >> $@
echo ' echo $(instdir_SQ)' >> $@
else
^ permalink raw reply related
* Re: [PATCH] bring description of git diff --cc up to date
From: Junio C Hamano @ 2008-07-23 23:15 UTC (permalink / raw)
To: Jonathan Nieder; +Cc: git
In-Reply-To: <Pine.GSO.4.62.0807222210540.3408@harper.uchicago.edu>
Jonathan Nieder <jrnieder@uchicago.edu> writes:
> On Tue, 22 Jul 2008, Junio C Hamano wrote:
>
> Here's another attempt. I grimace at the sound of it, but it might be
> more clear.
Let's just do this. I think it is clear enough.
Documentation/git-diff-tree.txt | 10 +++++-----
Documentation/rev-list-options.txt | 6 +++---
2 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/Documentation/git-diff-tree.txt b/Documentation/git-diff-tree.txt
index 0e45b58..8c8f35b 100644
--- a/Documentation/git-diff-tree.txt
+++ b/Documentation/git-diff-tree.txt
@@ -93,11 +93,11 @@ include::pretty-options.txt[]
This flag changes the way a merge commit patch is displayed,
in a similar way to the '-c' option. It implies the '-c'
and '-p' options and further compresses the patch output
- by omitting hunks that show differences from only one
- parent, or show the same change from all but one parent
- for an Octopus merge. When this optimization makes all
- hunks disappear, the commit itself and the commit log
- message is not shown, just like in any other "empty diff" case.
+ by omitting uninteresting hunks whose the contents in the parents
+ have only two variants and the merge result picks one of them
+ without modification. When all hunks are uninteresting, the commit
+ itself and the commit log message is not shown, just like in any other
+ "empty diff" case.
--always::
Show the commit itself and the commit log message even
diff --git a/Documentation/rev-list-options.txt b/Documentation/rev-list-options.txt
index b6f5d87..3aa3809 100644
--- a/Documentation/rev-list-options.txt
+++ b/Documentation/rev-list-options.txt
@@ -112,9 +112,9 @@ options may be given. See linkgit:git-diff-files[1] for more options.
--cc::
This flag implies the '-c' options and further compresses the
- patch output by omitting hunks that show differences from only
- one parent, or show the same change from all but one parent for
- an Octopus merge.
+ patch output by omitting uninteresting hunks whose contents in
+ the parents have only two variants and the merge result picks
+ one of them without modification.
-r::
^ permalink raw reply related
* [PATCH] bash completion: Add completion for 'git help'
From: Lee Marlow @ 2008-07-23 23:13 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: git, Lee Marlow
Renamed cached __git_commandlist to __git_porcelain_commandlist
and added __git_all_commandlist that only filters out *--* helpers.
Completions for 'git help' will use the __git_all_commandlist, while
__git_porcelain_commandlist is used for git command completion.
Users who actually read man pages may want to see help for plumbing
commands.
Options added: --all --info --man --web
Signed-off-by: Lee Marlow <lee.marlow@gmail.com>
---
contrib/completion/git-completion.bash | 46 +++++++++++++++++++++++++++-----
1 files changed, 39 insertions(+), 7 deletions(-)
diff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash
index 2edb341..0e37b71 100755
--- a/contrib/completion/git-completion.bash
+++ b/contrib/completion/git-completion.bash
@@ -349,10 +349,10 @@ __git_complete_revlist ()
esac
}
-__git_commands ()
+__git_all_commands ()
{
- if [ -n "$__git_commandlist" ]; then
- echo "$__git_commandlist"
+ if [ -n "$__git_all_commandlist" ]; then
+ echo "$__git_all_commandlist"
return
fi
local i IFS=" "$'\n'
@@ -360,6 +360,24 @@ __git_commands ()
do
case $i in
*--*) : helper pattern;;
+ *) echo $i;;
+ esac
+ done
+}
+__git_all_commandlist=
+__git_all_commandlist="$(__git_all_commands 2>/dev/null)"
+
+__git_porcelain_commands ()
+{
+ if [ -n "$__git_porcelain_commandlist" ]; then
+ echo "$__git_porcelain_commandlist"
+ return
+ fi
+ local i IFS=" "$'\n'
+ for i in 'help' $__git_all_commands
+ do
+ case $i in
+ *--*) : helper pattern;;
applymbox) : ask gittus;;
applypatch) : ask gittus;;
archimport) : import;;
@@ -427,8 +445,8 @@ __git_commands ()
esac
done
}
-__git_commandlist=
-__git_commandlist="$(__git_commands 2>/dev/null)"
+__git_porcelain_commandlist=
+__git_porcelain_commandlist="$(__git_porcelain_commands 2>/dev/null)"
__git_aliases ()
{
@@ -767,6 +785,18 @@ _git_gc ()
COMPREPLY=()
}
+_git_help ()
+{
+ local cur="${COMP_WORDS[COMP_CWORD]}"
+ case "$cur" in
+ --*)
+ __gitcomp "--all --info --man --web"
+ return
+ ;;
+ esac
+ __gitcomp "$(__git_all_commands)"
+}
+
_git_ls_remote ()
{
__gitcomp "$(__git_remotes)"
@@ -1369,7 +1399,8 @@ _git ()
case "$i" in
--git-dir=*) __git_dir="${i#--git-dir=}" ;;
--bare) __git_dir="." ;;
- --version|--help|-p|--paginate) ;;
+ --version|-p|--paginate) ;;
+ --help) command="help"; break ;;
*) command="$i"; break ;;
esac
c=$((++c))
@@ -1389,7 +1420,7 @@ _git ()
--help
"
;;
- *) __gitcomp "$(__git_commands) $(__git_aliases)" ;;
+ *) __gitcomp "$(__git_porcelain_commands) $(__git_aliases)" ;;
esac
return
fi
@@ -1414,6 +1445,7 @@ _git ()
fetch) _git_fetch ;;
format-patch) _git_format_patch ;;
gc) _git_gc ;;
+ help) _git_help ;;
log) _git_log ;;
ls-remote) _git_ls_remote ;;
ls-tree) _git_ls_tree ;;
--
1.6.0.rc0.14.g95f8
^ permalink raw reply related
* [PATCH] Make non-static functions, that may be static, static
From: Stephan Beyer @ 2008-07-23 23:09 UTC (permalink / raw)
To: git; +Cc: gitster, Stephan Beyer
Signed-off-by: Stephan Beyer <s-beyer@gmx.net>
---
Or are there any reasons against that? :)
builtin-commit.c | 2 +-
builtin-config.c | 2 +-
builtin-for-each-ref.c | 2 +-
builtin-merge.c | 2 +-
4 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/builtin-commit.c b/builtin-commit.c
index 97e64de..9d7100c 100644
--- a/builtin-commit.c
+++ b/builtin-commit.c
@@ -877,7 +877,7 @@ static void print_summary(const char *prefix, const unsigned char *sha1)
}
}
-int git_commit_config(const char *k, const char *v, void *cb)
+static int git_commit_config(const char *k, const char *v, void *cb)
{
if (!strcmp(k, "commit.template"))
return git_config_string(&template_file, k, v);
diff --git a/builtin-config.c b/builtin-config.c
index 0cf191a..91fdc49 100644
--- a/builtin-config.c
+++ b/builtin-config.c
@@ -145,7 +145,7 @@ free_strings:
return ret;
}
-char *normalize_value(const char *key, const char *value)
+static char *normalize_value(const char *key, const char *value)
{
char *normalized;
diff --git a/builtin-for-each-ref.c b/builtin-for-each-ref.c
index 76282ad..445039e 100644
--- a/builtin-for-each-ref.c
+++ b/builtin-for-each-ref.c
@@ -809,7 +809,7 @@ static struct ref_sort *default_sort(void)
return sort;
}
-int opt_parse_sort(const struct option *opt, const char *arg, int unset)
+static int opt_parse_sort(const struct option *opt, const char *arg, int unset)
{
struct ref_sort **sort_tail = opt->value;
struct ref_sort *s;
diff --git a/builtin-merge.c b/builtin-merge.c
index 8825dcf..e78fa18 100644
--- a/builtin-merge.c
+++ b/builtin-merge.c
@@ -431,7 +431,7 @@ static void merge_name(const char *remote, struct strbuf *msg)
sha1_to_hex(remote_head->sha1), remote);
}
-int git_merge_config(const char *k, const char *v, void *cb)
+static int git_merge_config(const char *k, const char *v, void *cb)
{
if (branch && !prefixcmp(k, "branch.") &&
!prefixcmp(k + 7, branch) &&
--
1.6.0.rc0.102.ga1791
^ permalink raw reply related
* Re: [PATCH] editor.c: Libify launch_editor()
From: Stephan Beyer @ 2008-07-23 23:09 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git, Junio C Hamano
In-Reply-To: <alpine.DEB.1.00.0807181405510.3932@eeepc-johanness>
Hi,
Johannes Schindelin wrote:
> > This patch removes exit()/die() calls and builtin-specific messages from
> > launch_editor(), so that it can be used as a general libgit.a function
> > to launch an editor.
>
> Thanks. Now we have to convince Junio that it is a good idea :-)
Well, I've seen that *a lot* of lib code (15 functions, see below) is in
the builtins.
Cleaning that up seems to be good to have a real separation between
libgit and builtins, but I guess such a change would not find its way
into 1.6.0, would it?
Regards,
Stephan
PS: I've spontaneously decided to make a list:
defined-in func-name - used in builtin-\1.c
builtin-add.c:
add_files_to_cache() - add, checkout, commit
interactive_add() - add, commit
builtin-archive.c:
parse_pathspec_arg() - archive, uploard-archive
builtin-init-db.c:
init_db() - init-db, clone
builtin-ls-files.c:
overlay_tree_on_cache() - ls-files, commit
report_path_error() - ls-files, checkout, commit
builtin-mailsplit.c:
read_line_with_nul() - mailsplit, mailinfo
builtin-merge-recursive.c:
write_tree_from_memory() - merge-recursive, checkout
builtin-prune-packed.c:
prune_packed_objects() - prune-packed, prune
builtin-shortlog.c:
shortlog_add_commit() - shortlog, log
shortlog_init() - shortlog, log
shortlog_output() - shortlog, log
shortlog_init() - shortlog, log
builtin-stripspace.c:
stripspace() - stripspace, commit, tag
And launch_editor() that is handled by the patch in this thread.
Then there are functions that are non-static, but not declined in
any .h file. A patch that makes them static follows in a separate mail.
--
Stephan Beyer <s-beyer@gmx.net>, PGP 0x6EDDD207FCC5040F
^ permalink raw reply
* Re: [PATCH 2/2] git-checkout: improve error messages, detect ambiguities.
From: Junio C Hamano @ 2008-07-23 23:04 UTC (permalink / raw)
To: Pierre Habouzit; +Cc: git
In-Reply-To: <1216808133-31919-3-git-send-email-madcoder@debian.org>
Pierre Habouzit <madcoder@debian.org> writes:
> The patch is twofold: it moves the option consistency checks just under
> the parse_options call so that it doesn't get in the way of the tree
> reference vs. pathspecs desambiguation.
I think this goes a bit too far.
Even if you have a file called 'master' tracked in your project, when you
say:
$ git checkout master
that's almost always branch switching. Forcing "git checkout master --"
disambiguation for such a common case is simply a wrong thing to do from
the usability point of view.
So how about (obviously we are interested only in the case without
disambiguating '--' here):
(3-1) if there is only one token left and if it is a rev, that's the
branch to check out or commit to detach to.
(3-2) otherwise the user might have mistyped one of the paths, so help
avoiding by making sure the first token is unambiguously either
a rev or a path (but not both).
^ permalink raw reply
* Re: git-svn - failed to clone repository
From: Derek Fawcus @ 2008-07-23 22:59 UTC (permalink / raw)
To: Avery Pennarun; +Cc: SZEDER Gábor, git
In-Reply-To: <32541b130807231249l1028a757i2f29e9ca6e38fc5a@mail.gmail.com>
On Wed, Jul 23, 2008 at 03:49:00PM -0400, Avery Pennarun wrote:
> I believe this was fixed by my patch
> 29c70e0b3e3183f86f93500882177d0c74069988, which was included in git
> 1.5.6.2.
Thanks folks. Building my own 1.5.6.4 allowed the clone to complete.
^ permalink raw reply
* Re: [RFC] Git User's Survey 2008
From: Miguel Arroz @ 2008-07-23 22:46 UTC (permalink / raw)
To: Jean-François Veillette; +Cc: Jakub Narebski, Git
In-Reply-To: <169F15EC-1A58-4C2A-84FC-3D14F7B4F1C5@yahoo.ca>
[-- Attachment #1: Type: text/plain, Size: 1615 bytes --]
Hello all,
Jakub, by now you should already have received an invitation to
join the Survs beta.
Information about the beta is included in the email. I don't know
if your project will go beyond the beta period and I cannot comment
about costs right now, but rest assured we'll have very competitive
pricing plans.
We sincerely hope our application proves to be useful to achieve
your goals.
Finally thank you Jean-François for mentioning us, we really
appreciate it.
Regards,
Miguel Arroz
On 2008/07/23, at 16:14, Jean-François Veillette wrote:
> Le 08-07-22 à 21:25, Jakub Narebski a écrit :
>
>>
>> First there is a question about the form of survey. Should we use web
>> based survey, as the survey before (http://www.survey.net.nz),
>> sending
>> emails with link to this survey, or perhaps do email based survey,
>> with email Reply-To: address put for this survey alone? Should we
>> use
>> the same web survey service as before (found by Paolo Ciarrocchi for
>> first, 2006 survey, and used also for 2007 survey), or is there one
>> better (it would better be free, and without limitations on the
>> number
>> of responses; in 2006 there were around 117 responses, in 2007 there
>> were 683 individual responses).
>
> Consider
> http://www.survs.com
> It is still in beta but already years ahead of the proposed solution.
> I don't know about the specific of the beta (cost, availability,
> etc.) but I had a live presentation of the product and it is an
> amazingly great product !
>
> - jfv
>
http://www.survs.com
[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 2417 bytes --]
^ permalink raw reply
* Re: [PATCHv3] git-filter-branch.sh: Allow running in bare repositories
From: Junio C Hamano @ 2008-07-23 22:29 UTC (permalink / raw)
To: Petr Baudis; +Cc: Johannes Schindelin, git
In-Reply-To: <20080723221221.12055.8509.stgit@localhost>
Thanks. Applied.
^ permalink raw reply
* Re: [PATCH] git-filter-branch.sh: Allow running in bare repositories
From: Junio C Hamano @ 2008-07-23 22:29 UTC (permalink / raw)
To: Petr Baudis; +Cc: git
In-Reply-To: <20080723215509.32438.49155.stgit@localhost>
Petr Baudis <pasky@suse.cz> writes:
> Commit 46eb449c restricted git-filter-branch to non-bare repositories
> unnecessarily; git-filter-branch can work on bare repositories just
> fine.
>
> Cc: Johannes Schindelin <Johannes.Schindelin@gmx.de>
> Signed-off-by: Petr Baudis <pasky@suse.cz>
> ---
>
> I have my own opinion about the readability-fork ratio in this particular
> case, but there's no use arguing about this. ;-)
Grouping commands is perfectly fine when you think the readers may find it
easlier to follow the logic if you grouped them. Use { } for that kind of
grouping; I do not have any problem with that.
Use of subshell ( ) is often done by inexperienced people or by careless
people without thinking. Sometimes you would explicitly want to have a
subshell (e.g. when you want to chdir to do something there but do not
want to affect the main program), and sometimes you don't (e.g. you are
grouping just for precedence, and want assignments and side effects done
inside the group visible by the main program).
Careless uses of ( ) wastes reviewer's time because the code inside has to
be studied to find out if the writer really wanted to have an isolated
separate process that subshell gives, or just being plain careless.
^ permalink raw reply
* [PATCH] builtin-branch.c: optimize --merged and --no-merged
From: Junio C Hamano @ 2008-07-23 22:15 UTC (permalink / raw)
To: Ingo Molnar; +Cc: SZEDER Gábor, git
In-Reply-To: <7vy73seb2p.fsf@gitster.siamese.dyndns.org>
"git branch --no-merged $commit" used to compute the merge base between
the tip of each and every branch with the named $commit, but this was
wasteful when you have many branches. Inside append_ref() we literally
ran has_commit() between the tip of the branch and the merge_filter_ref.
Instead, we can let the revision machinery traverse the history as if we
are running:
$ git rev-list --branches --not $commit
by queueing the tips of branches we encounter as positive refs (this
mimicks the "--branches" option in the above command line) and then
appending the merge_filter_ref commit as a negative one, and finally
calling prepare_revision_walk() to limit the list..
After the traversal is done, branch tips that are reachable from $commit
are painted UNINTERESTING; they are already fully contained in $commit
(i.e. --merged). Tips that are not painted UNINTERESTING still have
commits that are not reachable from $commit, thus "--no-merged" will show
them.
With an artificial repository that has "master" and 1000 test-$i branches
where they were created by "git branch test-$i master~$i":
(with patch)
$ /usr/bin/time git-branch --no-merged master >/dev/null
0.12user 0.02system 0:00.15elapsed 99%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (0major+1588minor)pagefaults 0swaps
$ /usr/bin/time git-branch --no-merged test-200 >/dev/null
0.15user 0.03system 0:00.18elapsed 100%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (0major+1711minor)pagefaults 0swaps
(without patch)
$ /usr/bin/time git-branch --no-merged master >/dev/null
0.69user 0.03system 0:00.72elapsed 100%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (0major+2229minor)pagefaults 0swaps
$ /usr/bin/time git-branch --no-merged test-200 >/dev/null
0.58user 0.03system 0:00.61elapsed 100%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (0major+2248minor)pagefaults 0swaps
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
builtin-branch.c | 59 ++++++++++++++++++++++++++++++++++-------------------
1 files changed, 38 insertions(+), 21 deletions(-)
diff --git a/builtin-branch.c b/builtin-branch.c
index 3708a50..5db8ad8 100644
--- a/builtin-branch.c
+++ b/builtin-branch.c
@@ -13,6 +13,8 @@
#include "remote.h"
#include "parse-options.h"
#include "branch.h"
+#include "diff.h"
+#include "revision.h"
static const char * const builtin_branch_usage[] = {
"git branch [options] [-r | -a] [--merged | --no-merged]",
@@ -179,25 +181,21 @@ static int delete_branches(int argc, const char **argv, int force, int kinds)
struct ref_item {
char *name;
unsigned int kind;
- unsigned char sha1[20];
+ struct commit *commit;
};
struct ref_list {
+ struct rev_info revs;
int index, alloc, maxwidth;
struct ref_item *list;
struct commit_list *with_commit;
int kinds;
};
-static int has_commit(const unsigned char *sha1, struct commit_list *with_commit)
+static int has_commit(struct commit *commit, struct commit_list *with_commit)
{
- struct commit *commit;
-
if (!with_commit)
return 1;
- commit = lookup_commit_reference_gently(sha1, 1);
- if (!commit)
- return 0;
while (with_commit) {
struct commit *other;
@@ -213,6 +211,7 @@ static int append_ref(const char *refname, const unsigned char *sha1, int flags,
{
struct ref_list *ref_list = (struct ref_list*)(cb_data);
struct ref_item *newitem;
+ struct commit *commit;
int kind;
int len;
static struct commit_list branch;
@@ -227,8 +226,12 @@ static int append_ref(const char *refname, const unsigned char *sha1, int flags,
} else
return 0;
+ commit = lookup_commit_reference_gently(sha1, 1);
+ if (!commit)
+ return error("branch '%s' does not point at a commit", refname);
+
/* Filter with with_commit if specified */
- if (!has_commit(sha1, ref_list->with_commit))
+ if (!has_commit(commit, ref_list->with_commit))
return 0;
/* Don't add types the caller doesn't want */
@@ -239,12 +242,8 @@ static int append_ref(const char *refname, const unsigned char *sha1, int flags,
branch.item = lookup_commit_reference_gently(sha1, 1);
if (!branch.item)
die("Unable to lookup tip of branch %s", refname);
- if (merge_filter == SHOW_NOT_MERGED &&
- has_commit(merge_filter_ref, &branch))
- return 0;
- if (merge_filter == SHOW_MERGED &&
- !has_commit(merge_filter_ref, &branch))
- return 0;
+ add_pending_object(&ref_list->revs,
+ (struct object *)branch.item, refname);
}
/* Resize buffer */
@@ -258,7 +257,7 @@ static int append_ref(const char *refname, const unsigned char *sha1, int flags,
newitem = &(ref_list->list[ref_list->index++]);
newitem->name = xstrdup(refname);
newitem->kind = kind;
- hashcpy(newitem->sha1, sha1);
+ newitem->commit = commit;
len = strlen(newitem->name);
if (len > ref_list->maxwidth)
ref_list->maxwidth = len;
@@ -305,7 +304,13 @@ static void print_ref_item(struct ref_item *item, int maxwidth, int verbose,
{
char c;
int color;
- struct commit *commit;
+ struct commit *commit = item->commit;
+
+ if (merge_filter != NO_FILTER) {
+ int is_merged = !!(item->commit->object.flags & UNINTERESTING);
+ if (is_merged != (merge_filter == SHOW_MERGED))
+ return;
+ }
switch (item->kind) {
case REF_LOCAL_BRANCH:
@@ -333,7 +338,7 @@ static void print_ref_item(struct ref_item *item, int maxwidth, int verbose,
strbuf_init(&subject, 0);
stat[0] = '\0';
- commit = lookup_commit(item->sha1);
+ commit = item->commit;
if (commit && !parse_commit(commit)) {
pretty_print_commit(CMIT_FMT_ONELINE, commit,
&subject, 0, NULL, NULL, 0, 0);
@@ -346,7 +351,7 @@ static void print_ref_item(struct ref_item *item, int maxwidth, int verbose,
printf("%c %s%-*s%s %s %s%s\n", c, branch_get_color(color),
maxwidth, item->name,
branch_get_color(COLOR_BRANCH_RESET),
- find_unique_abbrev(item->sha1, abbrev),
+ find_unique_abbrev(item->commit->object.sha1, abbrev),
stat, sub);
strbuf_release(&subject);
} else {
@@ -359,22 +364,34 @@ static void print_ref_list(int kinds, int detached, int verbose, int abbrev, str
{
int i;
struct ref_list ref_list;
+ struct commit *head_commit = lookup_commit_reference_gently(head_sha1, 1);
memset(&ref_list, 0, sizeof(ref_list));
ref_list.kinds = kinds;
ref_list.with_commit = with_commit;
+ if (merge_filter != NO_FILTER)
+ init_revisions(&ref_list.revs, NULL);
for_each_ref(append_ref, &ref_list);
+ if (merge_filter != NO_FILTER) {
+ struct commit *filter;
+ filter = lookup_commit_reference_gently(merge_filter_ref, 0);
+ filter->object.flags |= UNINTERESTING;
+ add_pending_object(&ref_list.revs,
+ (struct object *) filter, "");
+ ref_list.revs.limited = 1;
+ prepare_revision_walk(&ref_list.revs);
+ }
qsort(ref_list.list, ref_list.index, sizeof(struct ref_item), ref_cmp);
detached = (detached && (kinds & REF_LOCAL_BRANCH));
- if (detached && has_commit(head_sha1, with_commit)) {
+ if (detached && head_commit && has_commit(head_commit, with_commit)) {
struct ref_item item;
item.name = xstrdup("(no branch)");
item.kind = REF_LOCAL_BRANCH;
- hashcpy(item.sha1, head_sha1);
+ item.commit = head_commit;
if (strlen(item.name) > ref_list.maxwidth)
- ref_list.maxwidth = strlen(item.name);
+ ref_list.maxwidth = strlen(item.name);
print_ref_item(&item, ref_list.maxwidth, verbose, abbrev, 1);
free(item.name);
}
--
1.6.0.rc0.31.g128c7
^ permalink raw reply related
* [PATCHv3] git-filter-branch.sh: Allow running in bare repositories
From: Petr Baudis @ 2008-07-23 22:15 UTC (permalink / raw)
To: gitster; +Cc: Johannes Schindelin, git
In-Reply-To: <20080723220657.GA10151@machine.or.cz>
Commit 46eb449c restricted git-filter-branch to non-bare repositories
unnecessarily; git-filter-branch can work on bare repositories just
fine.
Cc: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Signed-off-by: Petr Baudis <pasky@suse.cz>
---
Sorry for the spam. This time I actually did make git-filter-branch
before running the testsuite.
git-filter-branch.sh | 36 ++++++++++++++++++++----------------
t/t7003-filter-branch.sh | 8 ++++++++
2 files changed, 28 insertions(+), 16 deletions(-)
diff --git a/git-filter-branch.sh b/git-filter-branch.sh
index d04c346..507c50e 100755
--- a/git-filter-branch.sh
+++ b/git-filter-branch.sh
@@ -97,9 +97,11 @@ USAGE="[--env-filter <command>] [--tree-filter <command>] \
OPTIONS_SPEC=
. git-sh-setup
-git diff-files --quiet &&
- git diff-index --cached --quiet HEAD -- ||
- die "Cannot rewrite branch(es) with a dirty working directory."
+if [ "$(is_bare_repository)" = false ]; then
+ git diff-files --quiet &&
+ git diff-index --cached --quiet HEAD -- ||
+ die "Cannot rewrite branch(es) with a dirty working directory."
+fi
tempdir=.git-rewrite
filter_env=
@@ -434,18 +436,20 @@ rm -rf "$tempdir"
trap - 0
-unset GIT_DIR GIT_WORK_TREE GIT_INDEX_FILE
-test -z "$ORIG_GIT_DIR" || {
- GIT_DIR="$ORIG_GIT_DIR" && export GIT_DIR
-}
-test -z "$ORIG_GIT_WORK_TREE" || {
- GIT_WORK_TREE="$ORIG_GIT_WORK_TREE" &&
- export GIT_WORK_TREE
-}
-test -z "$ORIG_GIT_INDEX_FILE" || {
- GIT_INDEX_FILE="$ORIG_GIT_INDEX_FILE" &&
- export GIT_INDEX_FILE
-}
-git read-tree -u -m HEAD
+if [ "$(is_bare_repository)" = false ]; then
+ unset GIT_DIR GIT_WORK_TREE GIT_INDEX_FILE
+ test -z "$ORIG_GIT_DIR" || {
+ GIT_DIR="$ORIG_GIT_DIR" && export GIT_DIR
+ }
+ test -z "$ORIG_GIT_WORK_TREE" || {
+ GIT_WORK_TREE="$ORIG_GIT_WORK_TREE" &&
+ export GIT_WORK_TREE
+ }
+ test -z "$ORIG_GIT_INDEX_FILE" || {
+ GIT_INDEX_FILE="$ORIG_GIT_INDEX_FILE" &&
+ export GIT_INDEX_FILE
+ }
+ git read-tree -u -m HEAD
+fi
exit $ret
diff --git a/t/t7003-filter-branch.sh b/t/t7003-filter-branch.sh
index e26f726..a0ab096 100755
--- a/t/t7003-filter-branch.sh
+++ b/t/t7003-filter-branch.sh
@@ -38,6 +38,14 @@ test_expect_success 'result is really identical' '
test $H = $(git rev-parse HEAD)
'
+test_expect_success 'rewrite bare repository identically' '
+ (git config core.bare true && cd .git && git-filter-branch branch)
+'
+git config core.bare false
+test_expect_success 'result is really identical' '
+ test $H = $(git rev-parse HEAD)
+'
+
test_expect_success 'rewrite, renaming a specific file' '
git-filter-branch -f --tree-filter "mv d doh || :" HEAD
'
^ permalink raw reply related
* [PATCH 1/2] builtin-branch.c: remove unused code in append_ref() callback function
From: Junio C Hamano @ 2008-07-23 22:09 UTC (permalink / raw)
To: Ingo Molnar; +Cc: SZEDER Gábor, git
In-Reply-To: <7vy73seb2p.fsf@gitster.siamese.dyndns.org>
We let for_each_ref() to feed all refs to append_ref() but we are only
ever interested in local or remote tracking branches.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
* I ended up splitting the patch into two, not three as I originally
thought I would.
builtin-branch.c | 10 +++-------
1 files changed, 3 insertions(+), 7 deletions(-)
diff --git a/builtin-branch.c b/builtin-branch.c
index b885bd1..3708a50 100644
--- a/builtin-branch.c
+++ b/builtin-branch.c
@@ -22,10 +22,8 @@ static const char * const builtin_branch_usage[] = {
NULL
};
-#define REF_UNKNOWN_TYPE 0x00
#define REF_LOCAL_BRANCH 0x01
#define REF_REMOTE_BRANCH 0x02
-#define REF_TAG 0x04
static const char *head;
static unsigned char head_sha1[20];
@@ -215,7 +213,7 @@ static int append_ref(const char *refname, const unsigned char *sha1, int flags,
{
struct ref_list *ref_list = (struct ref_list*)(cb_data);
struct ref_item *newitem;
- int kind = REF_UNKNOWN_TYPE;
+ int kind;
int len;
static struct commit_list branch;
@@ -226,10 +224,8 @@ static int append_ref(const char *refname, const unsigned char *sha1, int flags,
} else if (!prefixcmp(refname, "refs/remotes/")) {
kind = REF_REMOTE_BRANCH;
refname += 13;
- } else if (!prefixcmp(refname, "refs/tags/")) {
- kind = REF_TAG;
- refname += 10;
- }
+ } else
+ return 0;
/* Filter with with_commit if specified */
if (!has_commit(sha1, ref_list->with_commit))
--
1.6.0.rc0.31.g128c7
^ permalink raw reply related
* Re: [PATCH 2/2] sort_in_topological_order(): avoid setting a commit flag
From: Junio C Hamano @ 2008-07-23 22:07 UTC (permalink / raw)
To: Petr Baudis; +Cc: Johannes Schindelin, git
In-Reply-To: <20080723214942.GZ10151@machine.or.cz>
Petr Baudis <pasky@suse.cz> writes:
> On Tue, Jul 22, 2008 at 06:01:30PM -0700, Junio C Hamano wrote:
>> Do people still actively use show-branch as a G/CUI, especially after that
>> "log --graph" thing was introduced?
>
> To me, show-branch is just more convenient to use; I can see more easily
> which patches are with which branches, which is useful especially for my
> new sick-twisted use of feature branches for individual patches, thus
> having a lot of interdependencies.
Heh, I still recall hearing from many people that its output is hard to
decipher and UI is unintuitive. What changed their mind, I have to
wonder...
^ permalink raw reply
* Re: [PATCH] git-filter-branch.sh: Allow running in bare repositories
From: Petr Baudis @ 2008-07-23 22:06 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: gitster, git
In-Reply-To: <alpine.DEB.1.00.0807232257500.8986@racer>
Hi,
On Wed, Jul 23, 2008 at 10:59:03PM +0100, Johannes Schindelin wrote:
> On Wed, 23 Jul 2008, Petr Baudis wrote:
>
> > Commit 46eb449c restricted git-filter-branch to non-bare repositories
> > unnecessarily; git-filter-branch can work on bare repositories just
> > fine.
> >
> > Cc: Johannes Schindelin <Johannes.Schindelin@gmx.de>
>
> Funny, I did not get Cc:ed.
sorry, I have to copy the Cc around manually with StGIT. :/
> > -git diff-files --quiet &&
> > - git diff-index --cached --quiet HEAD -- ||
> > - die "Cannot rewrite branch(es) with a dirty working directory."
> > +if [ "$(is_bare_repository)" = false ]; then
> > + git diff-files --quiet &&
> > + git diff-index --cached --quiet HEAD --) ||
>
> ^
>
> I doubt this has ever passed the test suite, let alone run.
It did... provided that I didn't make after modifying the script.
> Besides, this extra-funny extra indent is quite brutal on my eyes.
I kept the original indentation.
Petr "Pasky" Baudis
^ permalink raw reply
* Re: [PATCH] Documentation/git-filter-branch: Remove Useless Use of Plumbing
From: Petr Baudis @ 2008-07-23 22:02 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vd4l5jwi4.fsf@gitster.siamese.dyndns.org>
On Tue, Jul 22, 2008 at 05:05:07PM -0700, Junio C Hamano wrote:
> Petr Baudis <pasky@suse.cz> writes:
>
> > The example to remove file using index-filter uses git update-index
> > --remove where git rm --cached works as well.
>
> I am not sure "works as well" is a good enough justification to choose a
> Porcelain command over a plumbing command in this particular context.
> After all, filter-branch is a scripting enviornment, isn't it?
But one of the few that are regularly used even by "mere users", who
would be probably put off unnecessarily by using this mysterious command.
(We might also say that I'm testing Dscho's suggestions, though this
patch was of course provoked by a "huh" of a user I was helping.)
> There also is another subtle difference. "git rm" takes pathspecs while
> "update-index" takes paths.
>
> So after running one of these commands:
>
> $ git rm --cached 'Makefil?'
> $ git update-index --force-remove 'Makefil?'
>
> output from:
>
> $ git diff --cached --stat
>
> would be different.
I don't think this is relevant for the example in question. Users are as
likely to be bit by or take advantage of this as by regular git rm
usage.
--
Petr "Pasky" Baudis
As in certain cults it is possible to kill a process if you know
its true name. -- Ken Thompson and Dennis M. Ritchie
^ permalink raw reply
* Re: [RFC] Git User's Survey 2008
From: Jakub Narebski @ 2008-07-23 21:59 UTC (permalink / raw)
To: Petr Baudis; +Cc: git
In-Reply-To: <20080723214433.GO32184@machine.or.cz>
On Wed, 23 Jul 2008, Petr Baudis wrote:
> On Wed, Jul 23, 2008 at 03:25:03AM +0200, Jakub Narebski wrote:
> >
> > 18. Which (main) git web interface do you use for your projects?
> > (zero or more: multiple choice)
> > - gitweb, cgit, wit (Ruby), git-php, viewgit (PHP), other
> > + should there be a question about web server (Apache, IIS, ...)
> > used to host git web interface?
> > 18b.If you selected "other web interface", what it was?
> > (free form)
>
> I think many people "just use GitHub", or repo.or.cz, or Gitorious; for
> GitHub or Gitorious, there's even no good answer to the question above.
For Gitorious there is a good answer: Gitorious web interface (which
is OSS, and you can deploy on your own).
> So I would either make a separate question for these or include them in
> the list above.
Fact, I have forgot to add question about which git hosting site one
uses; I have meant to add it in the second version of proposal for
Git User's Survey 2008 questions list.
xx. Which git hosting site do you use for your projects?
(zero or more: multiple choice)
- repo.or.cz, GitHub, Gitorious, kernel.org, freedesktop.org,
Savannah, Assembla, Unfuddle, Alioth, Fedora Hosted, other
+ of course "if other, which"
+ should some other web hosting sites be included as well?
> > 19. How do you publish/propagate your changes?
> > (zero or more: multiple choice)
> > - push, pull request, format-patch + email, bundle, other
>
> I agree about the git-svn mention.
I'll add it, then.
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: [PATCH] git-filter-branch.sh: Allow running in bare repositories
From: Johannes Schindelin @ 2008-07-23 21:59 UTC (permalink / raw)
To: Petr Baudis; +Cc: gitster, git
In-Reply-To: <20080723215509.32438.49155.stgit@localhost>
Hi,
On Wed, 23 Jul 2008, Petr Baudis wrote:
> Commit 46eb449c restricted git-filter-branch to non-bare repositories
> unnecessarily; git-filter-branch can work on bare repositories just
> fine.
>
> Cc: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Funny, I did not get Cc:ed.
> -git diff-files --quiet &&
> - git diff-index --cached --quiet HEAD -- ||
> - die "Cannot rewrite branch(es) with a dirty working directory."
> +if [ "$(is_bare_repository)" = false ]; then
> + git diff-files --quiet &&
> + git diff-index --cached --quiet HEAD --) ||
^
I doubt this has ever passed the test suite, let alone run.
Besides, this extra-funny extra indent is quite brutal on my eyes.
Ciao,
Dscho
^ permalink raw reply
* [PATCH] git-filter-branch.sh: Allow running in bare repositories
From: Petr Baudis @ 2008-07-23 21:55 UTC (permalink / raw)
To: gitster; +Cc: git
In-Reply-To: <7v8wvtjwa8.fsf@gitster.siamese.dyndns.org>
Commit 46eb449c restricted git-filter-branch to non-bare repositories
unnecessarily; git-filter-branch can work on bare repositories just
fine.
Cc: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Signed-off-by: Petr Baudis <pasky@suse.cz>
---
I have my own opinion about the readability-fork ratio in this particular
case, but there's no use arguing about this. ;-)
git-filter-branch.sh | 36 ++++++++++++++++++++----------------
t/t7003-filter-branch.sh | 8 ++++++++
2 files changed, 28 insertions(+), 16 deletions(-)
diff --git a/git-filter-branch.sh b/git-filter-branch.sh
index d04c346..ddf7187 100755
--- a/git-filter-branch.sh
+++ b/git-filter-branch.sh
@@ -97,9 +97,11 @@ USAGE="[--env-filter <command>] [--tree-filter <command>] \
OPTIONS_SPEC=
. git-sh-setup
-git diff-files --quiet &&
- git diff-index --cached --quiet HEAD -- ||
- die "Cannot rewrite branch(es) with a dirty working directory."
+if [ "$(is_bare_repository)" = false ]; then
+ git diff-files --quiet &&
+ git diff-index --cached --quiet HEAD --) ||
+ die "Cannot rewrite branch(es) with a dirty working directory.
+fi
tempdir=.git-rewrite
filter_env=
@@ -434,18 +436,20 @@ rm -rf "$tempdir"
trap - 0
-unset GIT_DIR GIT_WORK_TREE GIT_INDEX_FILE
-test -z "$ORIG_GIT_DIR" || {
- GIT_DIR="$ORIG_GIT_DIR" && export GIT_DIR
-}
-test -z "$ORIG_GIT_WORK_TREE" || {
- GIT_WORK_TREE="$ORIG_GIT_WORK_TREE" &&
- export GIT_WORK_TREE
-}
-test -z "$ORIG_GIT_INDEX_FILE" || {
- GIT_INDEX_FILE="$ORIG_GIT_INDEX_FILE" &&
- export GIT_INDEX_FILE
-}
-git read-tree -u -m HEAD
+if [ "$(is_bare_repository)" = false ]; then
+ unset GIT_DIR GIT_WORK_TREE GIT_INDEX_FILE
+ test -z "$ORIG_GIT_DIR" || {
+ GIT_DIR="$ORIG_GIT_DIR" && export GIT_DIR
+ }
+ test -z "$ORIG_GIT_WORK_TREE" || {
+ GIT_WORK_TREE="$ORIG_GIT_WORK_TREE" &&
+ export GIT_WORK_TREE
+ }
+ test -z "$ORIG_GIT_INDEX_FILE" || {
+ GIT_INDEX_FILE="$ORIG_GIT_INDEX_FILE" &&
+ export GIT_INDEX_FILE
+ }
+ git read-tree -u -m HEAD
+fi
exit $ret
diff --git a/t/t7003-filter-branch.sh b/t/t7003-filter-branch.sh
index e26f726..a0ab096 100755
--- a/t/t7003-filter-branch.sh
+++ b/t/t7003-filter-branch.sh
@@ -38,6 +38,14 @@ test_expect_success 'result is really identical' '
test $H = $(git rev-parse HEAD)
'
+test_expect_success 'rewrite bare repository identically' '
+ (git config core.bare true && cd .git && git-filter-branch branch)
+'
+git config core.bare false
+test_expect_success 'result is really identical' '
+ test $H = $(git rev-parse HEAD)
+'
+
test_expect_success 'rewrite, renaming a specific file' '
git-filter-branch -f --tree-filter "mv d doh || :" HEAD
'
^ permalink raw reply related
* Re: [RFC] Git User's Survey 2008
From: Jakub Narebski @ 2008-07-23 21:49 UTC (permalink / raw)
To: Dmitry Potapov; +Cc: git
In-Reply-To: <20080723143810.GR2925@dpotapov.dyndns.org>
On Wed, 23 Jul 2008, Dmitry Potapov wrote:
> On Wed, Jul 23, 2008 at 03:25:03AM +0200, Jakub Narebski wrote:
> >
> > 02. What is your preferred non-programming language?
> > (or) What is the language you want computer communicate with you?
>
> IMHO, the later wording of the question is much better.
First just satisfies demographic curiosity. Second is more question
about internationalization (i18n).
I'm not sure however if it is worth it, and not just simply remove
this question from the survey.
> > 05. How did you hear about Git?
> > (single choice?, in 2007 it was free-form)
> > - Linux kernel news (LKML, LWN, KernelTrap, KernelTraffic,...),
> > news site or magazine, blog entry, some project uses it,
> > presentation or seminar (real life, not on-line), SCM research,
> > IRC, mailing list, other Internet, other off-line, other(*)
>
> I think "friend" would be a reasonable choice here too.
Or: "word of mouth (off-line)". Good catch, thanks.
> > 09. When did you start using git? From which version?
> > - pre 1.0, 1.0, 1.1, 1.2, 1.3, 1.4, 1.5
> > + might be important when checking "what did you find hardest" etc.
> > + perhaps we should ask in addition to this question, or in place
> > of this question (replacing it) what git version one uses; it
> > should be multiple choice, and allow 'master', 'next', 'pu',
> > 'dirty (with own modifications)' versions in addition.
>
> I think: "What version do you use now?" and "How long do you use git?"
> may be more useful here. From which version may give rather confusing
> results because someone may "start" with 1.4 a week ago just because
> that is the version included in Debian Etch and after realizing that
> version 1.4 has serious usability issues upgraded git to 1.5. Besides,
> 1.5 is around for a long time now (as most as long as all previous
> versions), so 1.5 can mean either one month of usage or 18 months...
Good idea (provided that for "How long do you use git?" there is an
answer "Don't remember").
Should "What version do you use now?" be multiple choice (using git
on more than one machine / operating system)? What should be possible
choices for "How long do you use git?"? Perhaps.
10. How long do you use git?
(single choice)
- never/few days/few weeks/month/few months/year/few years/
from beginning/I wrote it(*)
+ (*) just kidding ;-)
--
Jakub Narebski
Poland
^ 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