* Re: [PATCH 2/2] sort_in_topological_order(): avoid setting a commit flag
From: Junio C Hamano @ 2008-07-23 1:01 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: pasky, git, gitster
In-Reply-To: <alpine.DEB.1.00.0807230150480.8986@racer>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> This is the same behavior as before, since indegree could not be
> non-zero when TOPOSORT was unset.
>
> Incidentally, this fixes the bug in show-branch where the 8th column
> was not shown: show-branch sorts the commits in topological order,
> assuming that all the commit flags are available for show-branch's
> private matters.
Do people still actively use show-branch as a G/CUI, especially after that
"log --graph" thing was introduced?
If that is the case, it might also make sense to stop using the object
flags but allocate necessary number of bits (not restricted to 25 or so)
pointed at by commit->util field to remove its limitation.
Hint, hint...
^ permalink raw reply
* [PATCH] git-checkout: fix argument parsing to detect ambiguous arguments.
From: Pierre Habouzit @ 2008-07-23 1:02 UTC (permalink / raw)
To: git; +Cc: gitster, Pierre Habouzit
Note that it also fix a bug, git checkout -- <path> would be badly
understood as git checkout <branch> if <path> is ambiguous with a branch.
Testcases included.
Signed-off-by: Pierre Habouzit <madcoder@debian.org>
---
A user on #git happened to have issues that made me realize that
builtin-checkout is badly broken wrt argument parseing.
This clearly needs to be applied to master, probably to maint too.
The patch is against next though, but should probably apply to other
branches just fine.
builtin-checkout.c | 9 +++++++--
t/t2010-checkout-ambiguous.sh | 27 +++++++++++++++++++++++++++
2 files changed, 34 insertions(+), 2 deletions(-)
create mode 100755 t/t2010-checkout-ambiguous.sh
diff --git a/builtin-checkout.c b/builtin-checkout.c
index fbd5105..1490e8e 100644
--- a/builtin-checkout.c
+++ b/builtin-checkout.c
@@ -438,9 +438,14 @@ int cmd_checkout(int argc, const char **argv, const char *prefix)
opts.track = git_branch_track;
- argc = parse_options(argc, argv, options, checkout_usage, 0);
- if (argc) {
+ argc = parse_options(argc, argv, options, checkout_usage,
+ PARSE_OPT_KEEP_DASHDASH);
+
+ if (argc && strcmp(argv[0], "--")) {
arg = argv[0];
+
+ if (argc == 1 || strcmp(argv[1], "--"))
+ verify_non_filename(NULL, arg);
if (get_sha1(arg, rev))
;
else if ((new.commit = lookup_commit_reference_gently(rev, 1))) {
diff --git a/t/t2010-checkout-ambiguous.sh b/t/t2010-checkout-ambiguous.sh
new file mode 100755
index 0000000..c1a86a2
--- /dev/null
+++ b/t/t2010-checkout-ambiguous.sh
@@ -0,0 +1,26 @@
+#!/bin/sh
+
+test_description='checkout and pathspecs/refspecs ambiguities'
+
+. ./test-lib.sh
+
+test_expect_success 'setup' '
+ echo hello >world &&
+ git add world &&
+ git commit -m initial &&
+ git branch world
+'
+
+test_expect_success 'branch switching' '
+ git checkout world --
+'
+
+test_expect_success 'checkout world from the index' '
+ git checkout -- world
+'
+
+test_expect_success 'ambiguous call' '
+ test_must_fail git checkout world
+'
+
+test_done
--
1.6.0.rc0.154.g60644
^ permalink raw reply related
* Re: regression in 92392b4
From: Pierre Habouzit @ 2008-07-23 1:09 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Johannes Schindelin, Git ML, Junio C Hamano
In-Reply-To: <20080723004108.GB14668@spearce.org>
[-- Attachment #1: Type: text/plain, Size: 3351 bytes --]
On Wed, Jul 23, 2008 at 12:41:08AM +0000, Shawn O. Pearce wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> > On Wed, 23 Jul 2008, Pierre Habouzit wrote:
> >
> > > Hi, here is a manual painful down-secting (opposed to a bisect ;P) I
> > > did, since git in next cannot fetch on a regular basis for me. The
> > > culprit seems to be commit 92392b4:
> > >
> > > ┌─(1:11)──<~/dev/scm/git 92392b4....>──
> > > └[artemis] git fetch
> > > remote: Counting objects: 461, done.
> > > remote: Compressing objects: 100% (141/141), done.
> > > remote: Total 263 (delta 227), reused 155 (delta 121)
> > > Receiving objects: 100% (263/263), 95.55 KiB, done.
> > > fatal: Out of memory, malloc failed
> > > fatal: index-pack failed
> > > [2] 16674 abort (core dumped) git fetch
> ....
> >
> > Just a guess:
> ....
> > diff --git a/index-pack.c b/index-pack.c
> > index ac20a46..19c39e5 100644
> > --- a/index-pack.c
> > +++ b/index-pack.c
> > @@ -257,6 +257,7 @@ static void unlink_base_data(struct base_data *c)
> > base_cache = NULL;
> > if (c->data) {
> > free(c->data);
> > + c->data = NULL;
> > base_cache_used -= c->size;
> > }
> > }
>
> Oh. This is a pointless assignment. If you look at any call sites
> for unlink_base_data() you will find that the struct passed in as
> "c" here is going out of scope after unlink_base_data() returns. In
> no such case does the value of c->data get tested once this free is
> complete.
>
> We need the if (c->data) guard because we only want to decrement
> base_cache_used if the memory is still allocated. It may have been
> released earlier, in which case base_cache_used has already been
> decreased and we don't want to double-decrement it.
>
> This patch makes the code more obvious, so Ack I guess, but it is
> not a solution to Pierre's woes. Something else is wrong.
>
> Reading above shows we got a "fatal: Out of memory, malloc failed"
> right before the segfault. What's odd is we segfaulted after we
> ran out of memory and should have die'd.
>
> There's at least two bugs in the above output:
>
> a) index-pack ran out of memory on a small pull (95 KiB).
> b) fetch segfaulted when index-pack failed.
>
> And this patch will unfortunately address neither of them. :-|
>
> I've had a long past couple of days, and another one tomorrow.
> I'm not going to be able to debug this myself until perhaps Thursday
> or Friday. Sorry. If nobody beats me to it, I will put this on
> the top of the pile and try to fix it once I get back online at my
> new home.
Like I said, I had a core that I stupidly lost, but I remember that
the broken malloc was:
static void *get_data_from_pack(struct object_entry *obj)
{
off_t from = obj[0].idx.offset + obj[0].hdr_size;
unsigned long len = obj[1].idx.offset - from;
unsigned long rdy = 0;
unsigned char *src, *data;
z_stream stream;
int st;
src = xmalloc(len);
^^^^^^^^^^^^^^^^^^
len was horribly big, and outputing obj[1].idx showed that `sha1` had
text in it. I mean something like "could not\r\n han" IIRC.
I don't remember the rest of the backtrace, and have stupidly not kept
any ways of reproducing it.
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: [PATCH] Respect crlf attribute even if core.autocrlf has not been set
From: Johannes Schindelin @ 2008-07-23 1:10 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vy73tihl6.fsf@gitster.siamese.dyndns.org>
Hi,
On Tue, 22 Jul 2008, Junio C Hamano wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>
> > When a file's crlf attribute is explicitely set, it does not make
> > sense to ignore it, just because the config variable core.autocrlf has
> > not been set.
>
> I am not sure if I agree with that reasoning.
>
> Attribute defines what each path is. Is it a text file, is it a binary?
> The nature of the contents does not change between people on POSIX and
> Windows, and that is why it is described in .gitattributes and cloned
> across repositories.
>
> On the other hand, the configuration defines what to do with contents with
> various attributes in this particular repository. Do I want to see a text
> file checked out with CRLF endings, or LF?
Actually, I now see that I expressed myself badly. Extremely badly.
The whole issue is about _check in_, as can be seen from the test case I
provided.
And I think it is even a bug in crlf handling, as gitattributes.txt has
this to say about crlf=input:
This is similar to setting the attribute to `true`, but
also forces git to act as if `core.autocrlf` is set to
`input` for the path.
It suggests to this coder that core.autocrlf is not even looked at when
crlf=input.
> So it is perfectly valid and normal for a cross-platform minded project
> to use the crlf atttribute to say "These files are text" and expect them
> to be checked out with LF endings on POSIX while making sure they are
> checked out with CRLF on Windows. Adding CR at the end of line for such
> files on POSIX systems is positively a wrong thing to do in such a case.
>
> Projects like the kernel that originate from LF side of the world may not
> bother marking things as such, though.
I fully agree.
However, if you want to avoid CRs to _enter_ the repository, when you have
a lot of binary files tracked, you _do_ want to force all repositories to
crlf=input.
Now, if you look at the patch, you will see that it _only_ touches
crlf_to_git(), but not only for crlf=input, but also for crlf=true.
I maintain that this respects the law of least surprise, namely that if
you set the attribute crlf=true, and some person forgets to set
core.autocrlf=true, at _check in_ CRs are stripped, but at _check out_, no
CR is added (as the person did not ask for core.autocrlf, but that should
not punish all the others who do not want to have CRs in the repository).
But yes, the commit message, and the oneline in particular are severely
lacking.
Tomorrow,
Dscho
^ permalink raw reply
* Re: [PATCH] git-checkout: fix argument parsing to detect ambiguous arguments.
From: Pierre Habouzit @ 2008-07-23 1:13 UTC (permalink / raw)
To: git; +Cc: gitster
In-Reply-To: <1216774940-4955-1-git-send-email-madcoder@debian.org>
[-- Attachment #1: Type: text/plain, Size: 2557 bytes --]
On Wed, Jul 23, 2008 at 01:02:20AM +0000, Pierre Habouzit wrote:
> Note that it also fix a bug, git checkout -- <path> would be badly
> understood as git checkout <branch> if <path> is ambiguous with a branch.
>
> Testcases included.
>
> Signed-off-by: Pierre Habouzit <madcoder@debian.org>
> ---
>
> A user on #git happened to have issues that made me realize that
> builtin-checkout is badly broken wrt argument parseing.
>
> This clearly needs to be applied to master, probably to maint too.
>
> The patch is against next though, but should probably apply to other
> branches just fine.
>
>
> builtin-checkout.c | 9 +++++++--
> t/t2010-checkout-ambiguous.sh | 27 +++++++++++++++++++++++++++
> 2 files changed, 34 insertions(+), 2 deletions(-)
> create mode 100755 t/t2010-checkout-ambiguous.sh
>
> diff --git a/builtin-checkout.c b/builtin-checkout.c
> index fbd5105..1490e8e 100644
> --- a/builtin-checkout.c
> +++ b/builtin-checkout.c
> @@ -438,9 +438,14 @@ int cmd_checkout(int argc, const char **argv, const char *prefix)
>
> opts.track = git_branch_track;
>
> - argc = parse_options(argc, argv, options, checkout_usage, 0);
> - if (argc) {
> + argc = parse_options(argc, argv, options, checkout_usage,
> + PARSE_OPT_KEEP_DASHDASH);
> +
> + if (argc && strcmp(argv[0], "--")) {
> arg = argv[0];
> +
> + if (argc == 1 || strcmp(argv[1], "--"))
> + verify_non_filename(NULL, arg);
> if (get_sha1(arg, rev))
> ;
> else if ((new.commit = lookup_commit_reference_gently(rev, 1))) {
> diff --git a/t/t2010-checkout-ambiguous.sh b/t/t2010-checkout-ambiguous.sh
> new file mode 100755
> index 0000000..c1a86a2
> --- /dev/null
> +++ b/t/t2010-checkout-ambiguous.sh
> @@ -0,0 +1,26 @@
> +#!/bin/sh
> +
> +test_description='checkout and pathspecs/refspecs ambiguities'
> +
> +. ./test-lib.sh
> +
> +test_expect_success 'setup' '
> + echo hello >world &&
> + git add world &&
> + git commit -m initial &&
> + git branch world
> +'
> +
> +test_expect_success 'branch switching' '
> + git checkout world --
> +'
> +
> +test_expect_success 'checkout world from the index' '
> + git checkout -- world
> +'
Okay those two tests are stupid in the sense that they don't check
git-checkout does what it's supposed to do. One should check the first
one outputs 'Switched to branch "world"'
and the second should rather be:
'
echo "bye bye" > world &&
git checkout -- world &&
git diff --quiet --exit-code
'
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: [PATCH] Rename ".dotest/" to ".git/rebase" and ".dotest-merge" to "rebase-merge"
From: Stephan Beyer @ 2008-07-23 1:13 UTC (permalink / raw)
To: Junio C Hamano
Cc: Olivier Marin, Theodore Tso, Nanako Shiraishi,
Johannes Schindelin, René Scharfe, Joe Fiorini, git,
Jari Aalto
In-Reply-To: <7vbq0pifwq.fsf@gitster.siamese.dyndns.org>
Hi,
Junio C Hamano wrote:
> Stephan Beyer <s-beyer@gmx.net> writes:
> > Junio C Hamano wrote:
> >> Olivier Marin <dkr+ml.git@free.fr> writes:
> >> > @@ -203,9 +204,10 @@ then
> >> >
> >> > case "$abort" in
> >> > t)
> >> > - rm -fr "$dotest" &&
> >> > + git rerere clear &&
> >> > git read-tree -m -u ORIG_HEAD &&
> > [...]
> >> diff --git a/git-am.sh b/git-am.sh
> >> index a44bd7a..5cbf8f4 100755
> >> --- a/git-am.sh
> >> +++ b/git-am.sh
> >> @@ -203,9 +203,9 @@ then
> >>
> >> case "$abort" in
> >> t)
> >> - rm -fr "$dotest" &&
> >> - git read-tree -m -u ORIG_HEAD &&
> >> - git reset ORIG_HEAD && :
> >> + git rerere clear
> >> + git read-tree --reset -u HEAD ORIG_HEAD
> >
> > Perhaps I am confused, but ...
> > Why is there "HEAD" and "ORIG_HEAD" and not only "ORIG_HEAD"?
>
> Just being a bit defensive -- in this case I think it might be Ok to say
> "read-tree --reset -u ORIG_HEAD", but I haven't checked in a conflicted
> case.
Well, the test suite fails:
* FAIL 4: am --abort goes back after failed am
git-am --abort &&
git rev-parse HEAD >actual &&
git rev-parse initial >expect &&
test_cmp expect actual &&
here> test_cmp file-2-expect file-2 &&
... git diff-index --exit-code --cached HEAD &&
test ! -f .git/rr-cache/MERGE_RR
* FAIL 7: am --abort goes back after failed am -3
git-am --abort &&
git rev-parse HEAD >actual &&
git rev-parse initial >expect &&
test_cmp expect actual &&
and here> test_cmp file-2-expect file-2 &&
git diff-index --exit-code --cached HEAD &&
test ! -f .git/rr-cache/MERGE_RR
So no reason to be defensive ;)
> If some path was added between ORIG_HEAD (that is where we started from)
> and HEAD (that is where we are and we decide we do not want it), and that
> path is conflicted in the index, a single tree form "read-tree --reset -u
> HEAD" would leave it behind in the working tree, wouldn't it?
Seems so.
The reason of my question was that I *blindly* incorporated the change into
sequencer to make it able to work on a dirty working tree and thus to be
able to migrate am onto it without losing the ability to apply patches
on a dirty working tree....
All am tests applied afterwards, but the sequencer and the rebase-i
test suite failed in a place where I didn't expect it. I *then* had
a deeper look at the read-tree line and I was wondering what the "HEAD"
should achieve.
I removed it and all tests passed. (I didn't have t4151 in my branch
at that point.)
Now, because t4151 does not pass, I am wondering what's the best thing
I could do...
Regards,
Stephan
--
Stephan Beyer <s-beyer@gmx.net>, PGP 0x6EDDD207FCC5040F
^ permalink raw reply
* Re: [PATCH] git-checkout: fix argument parsing to detect ambiguous arguments.
From: Johannes Schindelin @ 2008-07-23 1:17 UTC (permalink / raw)
To: Pierre Habouzit; +Cc: git, gitster
In-Reply-To: <1216774940-4955-1-git-send-email-madcoder@debian.org>
Hi,
On Wed, 23 Jul 2008, Pierre Habouzit wrote:
> diff --git a/builtin-checkout.c b/builtin-checkout.c
> index fbd5105..1490e8e 100644
> --- a/builtin-checkout.c
> +++ b/builtin-checkout.c
> @@ -438,9 +438,14 @@ int cmd_checkout(int argc, const char **argv, const char *prefix)
>
> opts.track = git_branch_track;
>
> - argc = parse_options(argc, argv, options, checkout_usage, 0);
> - if (argc) {
> + argc = parse_options(argc, argv, options, checkout_usage,
> + PARSE_OPT_KEEP_DASHDASH);
> +
> + if (argc && strcmp(argv[0], "--")) {
> arg = argv[0];
> +
> + if (argc == 1 || strcmp(argv[1], "--"))
> + verify_non_filename(NULL, arg);
Why "argc == 1"? Should "git checkout <path>" really fail? That would be
a change in behavior that _would_ hit me.
However, you may want to verify_non_filename() when argc == 1 _and_
get_sha1() succeeded. Because then, <path> is ambiguous.
Ciao,
Dscho
^ permalink raw reply
* Re: regression in 92392b4
From: Johannes Schindelin @ 2008-07-23 1:20 UTC (permalink / raw)
To: Pierre Habouzit; +Cc: Shawn O. Pearce, Git ML, Junio C Hamano
In-Reply-To: <20080723010928.GG11831@artemis.madism.org>
Hi,
On Wed, 23 Jul 2008, Pierre Habouzit wrote:
> I had a core that I stupidly lost, but I remember that the broken malloc
> was:
>
>
> static void *get_data_from_pack(struct object_entry *obj)
> {
> off_t from = obj[0].idx.offset + obj[0].hdr_size;
> unsigned long len = obj[1].idx.offset - from;
> unsigned long rdy = 0;
> unsigned char *src, *data;
> z_stream stream;
> int st;
>
> src = xmalloc(len);
> ^^^^^^^^^^^^^^^^^^
>
> len was horribly big, and outputing obj[1].idx showed that `sha1` had
> text in it. I mean something like "could not\r\n han" IIRC.
>
> I don't remember the rest of the backtrace, and have stupidly not kept
> any ways of reproducing it.
That would not have helped. The memory corruption almost _certainly_ took
place way before that.
Ciao,
Dscho
^ permalink raw reply
* [RFC] Git User's Survey 2008
From: Jakub Narebski @ 2008-07-23 1:25 UTC (permalink / raw)
To: git; +Cc: Stephan Beyer
It's been around a year since last Git User's Survey. It would be
interesting to find what changed since then. For example to see if
there were visible improvements in easing learning curve and in
usability. Therefore the idea to have another survey.
(If there is no suck^W volunteer to create survey, announce it, and
finally summarize results and publish summary on Git Wiki, I would do
the 2008 survey.)
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).
Second, what questions should be put in the survey, and in the case of
single choice and ultiple choice questions what possible answers
should be? I'd rather avoid free-form questions, even if they are more
interesting, as they are PITA to analyse and summarize, especially to
create some kind of histogram from free-form replies data (some of 2007
free-form responses are not fully summarized even now). Below are
slightly extended questions from the last survey. Please comment on
it.
Third, where to send survey to / where to publish information about the
survey? Last year the announcement was send to git mailing list, to
LKML (Linux kernel mailing list), and mailing list for git projects
found on GitProjects page on GIT wiki. Now that the number of projects
using Git as version control system has grown, I don't think it would
be good idea to "spam" all those mailing list; and if we don't send
notice to all other projects I'm not sure if we should include LKML.
Last year survey announcement was put on Git Homepage (thanks Pasky),
and on front page of Git Wiki; info about survey was also put on two
git hosting sites: kernel.org and repo.or.cz. It would be nice if it
was possible to put announcement about Git User's Survey 2008 at front
pages of other Git hosting sites, like GitHub (one of most popular, I
think), Gitorious, Freedesktop.org. If you know some other popular Git
hosting sites, and even better if you know who to contact about putting
survey announcement, please write. Is there some channel that I have
forgot about? Should info/announcement about Git User's Survey 2008 be
sent also to one of on-line magazines like LinuxToday or LWN, or asked
to put on some blog? I'll add it as journal entry for #git on Ohloh,
and try to make it so it would appear in "News" section for Ohloh
project page for Git: http://www.ohloh.net/projects/git.
Fourth, how long should the survey last? When sending announcement we
should say where notice about Git User's Survey 2008 should be taken
down. Last year the survey was meant to take three weeks, but was up
longer.
Below there is initial version of announcement email (I should probably
come up also with boilerplate announcement for web pages), and initial
version of this year round of questions. Comments are prefixed by '+',
and does not mean to be included in the survey text.
----
Hi all,
We would like to ask you a few questions about your use of the Git
version control system. This survey is mainly to understand who is
using Git, how and why.
The results will be published to the Git wiki and discussed on the git
mailing list.
We'll close the survey in <duration> starting from today, <date>.
Please devote a few minutes of your time to fill this simple
questionnaire, it will help a lot the git community to understand your
needs, what you like of git, and of course what you don't like of it.
The survey can be found here:
<survey URL>
----
About you
01. What country are you in?
02. What is your preferred non-programming language?
(or) What is the language you want computer communicate with you?
03. How old are you (in years)?
(free form, integer)
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,...?)
Getting started with GIT
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(*)
+ the problem is with having not very long list (not too many
choices), but spanning all possibilities.
+ is this question interesting/important to have in survey?
06. Did you find GIT easy to learn?
- very easy/easy/reasonably/hard/very hard
07. What helped you most in learning to use it?
(free form question)
08. What did you find hardest in learning Git?
What did you find harderst in using Git?
(free form question)
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.
Other SCMs (shortened compared with 2007 survey)
10. What other SCM did or do you use?
(zero or more: multiple choice)
- CVS, Subversion, GNU Arch or arch clone (ArX, tla, ...),
Bazaar-NG, Darcs, Mercurial, Monotone, SVK, AccuRev, Perforce,
BitKeeper, ClearCase, MS Visual Source Safe, MS Visual Studio
Team System, custom, other(*)
10b.If you selected other above, what SCM it was?
(free form)
11. Why did you choose Git? (if you use Git)
What do you like about using Git?
(free form, not to be tabulated)
12. Why did you choose other SCMs? (if you use other SCMs)
What do you like about using other SCMs?
Note: please write name of SCMs you are talking about.
(free form, not to be tabulated).
How you use Git
13. Do you use Git for work, unpaid projects, or both?
(single choice)
- work/unpaid projects/both
14. How do you obtain Git?
- binary package/source package or source script(*)/
source tarball/pull from main repository
(*) this includes source based distributions like Gentoo
+ added new option: source package or source script
+ should this be multiple choice?
15. What operating system do you use Git on?
(one or more: multiple choice, as one can use more than one OS)
- Linux, *BSD (FreeBSD, OpenBSD, etc.), MS Windows/Cygwin,
MS Windows/msysGit, MacOS X, other UNIX, other
+ "What hardware platforms do you use GIT on?" question was
removed; should it stay?
15b.If you selected "other UNIX", or "other", what operating system
or systems it was/were?
(free form)
16. Which porcelains / interfaces / implementations do you use?
(zero or more: multiple choice)
- core-git, Cogito (deprecated), StGIT, Guilt, pg (deprecated),
Pyrite, Easy Git, IsiSetup, jgit, my own scripts, other
16b.If you selected "other porcelain", what is its name?
(free form)
17. Which git GUI (commit tool or history viewer, or both) do you use
(zero or more: multiple choice)
- CLI, gitk, git-gui, qgit, gitview, giggle, tig, instaweb,
(h)gct, qct, KGit, git-cola / ugit, GitNub, Pyrite, git.el, other
17b.If you selected "other GUI", what is its name?
(free form)
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)
19. How do you publish/propagate your changes?
(zero or more: multiple choice)
- push, pull request, format-patch + email, bundle, other
19b.If the way you publish your changes is not mentioned above, how
do you publish your changes?
(free form)
20. Does git.git repository include code produced by you?
- yes/no
What you think of Git
21. Overall, how happy are you with Git?
- unhappy/not so happy/happy/very happy/completely ecstatic
22. How does Git compare to other SCM tools you have used?
- worse/equal (or comparable)/better
23. What would you most like to see improved about Git?
(features, bugs, plug-ins, documentation, ...)
24. If you want to see Git more widely used, what do you
think we could do to make this happen?
+ Is this question necessary/useful? Do we need wider adoption?
Changes in Git (since year ago, or since you started using it)
25. Did you participate in previous Git User's Surveys?
(zero or more, multiple choice)
- 2006, 2007
26. How do you compare current version with version from year ago?
- current version is: better/worse/no changes
27. Which of the following features do you use?
(zero or more: multiple choice)
- git-gui or other commit tool, gitk or other history viewer, patch
management interface (e.g. StGIT), bundle, eol conversion,
gitattributes, submodules, separate worktree, reflog, stash,
shallow clone, detaching HEAD, mergetool, interactive rebase,
add --interactive or other partial commit helper, commit
templates, bisect, other (not mentioned here)
+ should probably be sorted in some resemblance of order
+ are there any new features which should be listed here?
28. If you use some important Git features not mentioned above,
what are it?
(free form)
Documentation
29. Do you use the Git wiki?
- yes/no
30. Do you find Git wiki useful?
- yes/no/somewhat
31. Do you contribute to Git wiki?
- yes/no/only corrections or spam removal
32. Do you find Git's on-line help (homepage, documentation) useful?
- yes/no/somewhat
33. Do you find help distributed with Git useful
(manpages, manual, tutorial, HOWTO, release notes)?
- yes/no/somewhat
34. What could be improved on the Git homepage?
(free form)
35. What could be improved in Git documentation?
(free form)
Getting help, staying in touch
36. Have you tried to get Git help from other people?
- yes/no
37. What channel did you use to request help?
(zero or more: multiple choice)
- git mailing list, git users group, IRC, blog post,
other
+ this is one question which doesn't need, I think, explanation
of "other" choice
38. If yes, did you get these problems resolved quickly
and to your liking?
- yes/no
39. Would commerical (paid) support from a support vendor
be of interest to you/your organization?
- yes/no/not applicable
40. Do you read the mailing list?
- yes/no
41. If yes, do you find it useful?
- yes/no (optional)
42. Do you find traffic levels on Git mailing list OK.
- yes/no? (optional)
43. Do you use the IRC channel (#git on irc.freenode.net)?
- yes/no
44. If yes, do you find IRC channel useful?
- yes/no (optional)
45. Did you have problems getting GIT help on mailing list or
on IRC channel? What were it? What could be improved?
(free form)
Open forum
46. What other comments or suggestions do you have that are not
covered by the questions above?
(free form)
--
Jakub Narebski
Poland
^ permalink raw reply
* [RESEND PATCH] git-checkout: fix argument parsing to detect ambiguous arguments.
From: Pierre Habouzit @ 2008-07-23 1:27 UTC (permalink / raw)
To: git; +Cc: gitster
In-Reply-To: <1216774940-4955-1-git-send-email-madcoder@debian.org>
[-- Attachment #1: Type: text/plain, Size: 3041 bytes --]
Note that it also fix a bug, git checkout -- <path> would be badly
understood as git checkout <branch> if <path> is ambiguous with a branch.
Testcases included.
Signed-off-by: Pierre Habouzit <madcoder@debian.org>
---
This is a resend with proper patches that made me realize that my
previous patch had silly mistakes and wasn't testing thigns properly.
builtin-checkout.c | 23 +++++++++++++++++------
t/t2010-checkout-ambiguous.sh | 35 +++++++++++++++++++++++++++++++++++
2 files changed, 52 insertions(+), 6 deletions(-)
create mode 100755 t/t2010-checkout-ambiguous.sh
diff --git a/builtin-checkout.c b/builtin-checkout.c
index fbd5105..97321e6 100644
--- a/builtin-checkout.c
+++ b/builtin-checkout.c
@@ -438,12 +438,17 @@ int cmd_checkout(int argc, const char **argv, const char *prefix)
opts.track = git_branch_track;
- argc = parse_options(argc, argv, options, checkout_usage, 0);
- if (argc) {
+ argc = parse_options(argc, argv, options, checkout_usage,
+ PARSE_OPT_KEEP_DASHDASH);
+
+ if (argc && strcmp(argv[0], "--")) {
+ int may_be_ambiguous = argc == 1 || strcmp(argv[1], "--");
+
arg = argv[0];
- if (get_sha1(arg, rev))
- ;
- else if ((new.commit = lookup_commit_reference_gently(rev, 1))) {
+ if (get_sha1(arg, rev)) {
+ if (may_be_ambiguous)
+ verify_filename(NULL, arg);
+ } else if ((new.commit = lookup_commit_reference_gently(rev, 1))) {
new.name = arg;
setup_branch_path(&new);
if (resolve_ref(new.path, rev, 1, NULL))
@@ -454,10 +459,16 @@ int cmd_checkout(int argc, const char **argv, const char *prefix)
source_tree = new.commit->tree;
argv++;
argc--;
+ if (may_be_ambiguous)
+ verify_non_filename(NULL, arg);
} else if ((source_tree = parse_tree_indirect(rev))) {
argv++;
argc--;
- }
+ if (may_be_ambiguous)
+ verify_non_filename(NULL, arg);
+ } else
+ if (may_be_ambiguous)
+ verify_filename(NULL, arg);
}
if (argc && !strcmp(argv[0], "--")) {
diff --git a/t/t2010-checkout-ambiguous.sh b/t/t2010-checkout-ambiguous.sh
new file mode 100755
index 0000000..389ba8c
--- /dev/null
+++ b/t/t2010-checkout-ambiguous.sh
@@ -0,0 +1,35 @@
+#!/bin/sh
+
+test_description='checkout and pathspecs/refspecs ambiguities'
+
+. ./test-lib.sh
+
+test_expect_success 'setup' '
+ echo hello >world &&
+ echo hello >all &&
+ git add all world &&
+ git commit -m initial &&
+ git branch world
+'
+
+test_expect_success 'branch switching' '
+ test "refs/heads/master" = "$(git symbolic-ref HEAD)" &&
+ git checkout world -- &&
+ test "refs/heads/world" = "$(git symbolic-ref HEAD)"
+'
+
+test_expect_success 'checkout world from the index' '
+ echo bye > world &&
+ git checkout -- world &&
+ git diff --exit-code --quiet
+'
+
+test_expect_success 'non ambiguous call' '
+ git checkout all
+'
+
+test_expect_success 'ambiguous call' '
+ test_must_fail git checkout world
+'
+
+test_done
--
1.6.0.rc0.154.ge2a39.dirty
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply related
* [PATCH] Respect crlf attribute in "git add" even if core.autocrlf has not been set
From: Johannes Schindelin @ 2008-07-23 1:31 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Dmitry Potapov
In-Reply-To: <alpine.DEB.1.00.0807230203350.8986@racer>
When a file's crlf attribute is explicitely set, it does not make sense
to ignore it when adding the file, just because the config variable
core.autocrlf has not been set.
The alternative would be risking to get CR/LF files into the repository
just because one user forgot to set core.autocrlf.
This patch does not affect the case when the crlf attribute is unset,
or when checking files out.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---
Okay, so I lied and did not go to sleep (but that part comes
now). Only the wording in the commit message has changed.
convert.c | 2 +-
t/t0020-crlf.sh | 10 ++++++++++
2 files changed, 11 insertions(+), 1 deletions(-)
diff --git a/convert.c b/convert.c
index 78efed8..d038d2f 100644
--- a/convert.c
+++ b/convert.c
@@ -126,7 +126,7 @@ static int crlf_to_git(const char *path, const char *src, size_t len,
struct text_stat stats;
char *dst;
- if ((action == CRLF_BINARY) || !auto_crlf || !len)
+ if ((action == CRLF_BINARY) || (!auto_crlf && action < 0) || !len)
return 0;
gather_stats(src, len, &stats);
diff --git a/t/t0020-crlf.sh b/t/t0020-crlf.sh
index 1be7446..0bb3e6f 100755
--- a/t/t0020-crlf.sh
+++ b/t/t0020-crlf.sh
@@ -436,4 +436,14 @@ test_expect_success 'invalid .gitattributes (must not crash)' '
'
+test_expect_success 'attribute crlf is heeded even without core.autocrlf' '
+
+ echo "allcrlf crlf=input" > .gitattributes &&
+ git config --unset core.autocrlf &&
+ git add allcrlf &&
+ git show :allcrlf | append_cr > expect &&
+ test_cmp allcrlf expect
+
+'
+
test_done
--
1.6.0.rc0.22.gf2096d.dirty
^ permalink raw reply related
* Re: [PATCH] git-checkout: fix argument parsing to detect ambiguous arguments.
From: Pierre Habouzit @ 2008-07-23 1:32 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git, gitster
In-Reply-To: <alpine.DEB.1.00.0807230215480.8986@racer>
[-- Attachment #1: Type: text/plain, Size: 1540 bytes --]
On Wed, Jul 23, 2008 at 01:17:52AM +0000, Johannes Schindelin wrote:
> Hi,
>
> On Wed, 23 Jul 2008, Pierre Habouzit wrote:
>
> > diff --git a/builtin-checkout.c b/builtin-checkout.c
> > index fbd5105..1490e8e 100644
> > --- a/builtin-checkout.c
> > +++ b/builtin-checkout.c
> > @@ -438,9 +438,14 @@ int cmd_checkout(int argc, const char **argv, const char *prefix)
> >
> > opts.track = git_branch_track;
> >
> > - argc = parse_options(argc, argv, options, checkout_usage, 0);
> > - if (argc) {
> > + argc = parse_options(argc, argv, options, checkout_usage,
> > + PARSE_OPT_KEEP_DASHDASH);
> > +
> > + if (argc && strcmp(argv[0], "--")) {
> > arg = argv[0];
> > +
> > + if (argc == 1 || strcmp(argv[1], "--"))
> > + verify_non_filename(NULL, arg);
>
> Why "argc == 1"? Should "git checkout <path>" really fail? That would be
> a change in behavior that _would_ hit me.
No I was mistaken about what verify_non_filename did, actually I
should not code when I'm so obviously tired, and I wanted
verify_non_filename to do what I meant instead of checking what it does
;P
I believe my resent patch is better.
> However, you may want to verify_non_filename() when argc == 1 _and_
> get_sha1() succeeded. Because then, <path> is ambiguous.
Yes and the reverse when we have sucessfully parsed something that
looks like a path as a path. Anyways, someone should carefully proofread
my resent patch, it's likely that errors slipped through given my sleep
deprivation atm.
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: [RESEND PATCH] git-checkout: fix argument parsing to detect ambiguous arguments.
From: Pierre Habouzit @ 2008-07-23 1:39 UTC (permalink / raw)
To: git, gitster
In-Reply-To: <20080723012751.GI11831@artemis.madism.org>
[-- Attachment #1: Type: text/plain, Size: 3747 bytes --]
On Wed, Jul 23, 2008 at 01:27:51AM +0000, Pierre Habouzit wrote:
> Note that it also fix a bug, git checkout -- <path> would be badly
> understood as git checkout <branch> if <path> is ambiguous with a branch.
>
> Testcases included.
>
> Signed-off-by: Pierre Habouzit <madcoder@debian.org>
> ---
>
> This is a resend with proper patches that made me realize that my
> previous patch had silly mistakes and wasn't testing thigns properly.
>
> builtin-checkout.c | 23 +++++++++++++++++------
> t/t2010-checkout-ambiguous.sh | 35 +++++++++++++++++++++++++++++++++++
> 2 files changed, 52 insertions(+), 6 deletions(-)
> create mode 100755 t/t2010-checkout-ambiguous.sh
>
> diff --git a/builtin-checkout.c b/builtin-checkout.c
> index fbd5105..97321e6 100644
> --- a/builtin-checkout.c
> +++ b/builtin-checkout.c
> @@ -438,12 +438,17 @@ int cmd_checkout(int argc, const char **argv, const char *prefix)
>
> opts.track = git_branch_track;
>
> - argc = parse_options(argc, argv, options, checkout_usage, 0);
> - if (argc) {
> + argc = parse_options(argc, argv, options, checkout_usage,
> + PARSE_OPT_KEEP_DASHDASH);
> +
> + if (argc && strcmp(argv[0], "--")) {
> + int may_be_ambiguous = argc == 1 || strcmp(argv[1], "--");
> +
> arg = argv[0];
> - if (get_sha1(arg, rev))
> - ;
> - else if ((new.commit = lookup_commit_reference_gently(rev, 1))) {
> + if (get_sha1(arg, rev)) {
> + if (may_be_ambiguous)
> + verify_filename(NULL, arg);
Dscho mentionned on irc that this bit is superfluous, we already know
that 'arg' cannot be a refspec here, so in the worse case, if it's not a
file at all, this will generate a curious error message about
"ambiguous" arguments, whereas it should fail with an "unknown file"
error or sth similar. This two lines should probably remain ';' like it
previously was.
The rest looks correct to me, but it's late...
> + } else if ((new.commit = lookup_commit_reference_gently(rev, 1))) {
> new.name = arg;
> setup_branch_path(&new);
> if (resolve_ref(new.path, rev, 1, NULL))
> @@ -454,10 +459,16 @@ int cmd_checkout(int argc, const char **argv, const char *prefix)
> source_tree = new.commit->tree;
> argv++;
> argc--;
> + if (may_be_ambiguous)
> + verify_non_filename(NULL, arg);
> } else if ((source_tree = parse_tree_indirect(rev))) {
> argv++;
> argc--;
> - }
> + if (may_be_ambiguous)
> + verify_non_filename(NULL, arg);
> + } else
> + if (may_be_ambiguous)
> + verify_filename(NULL, arg);
> }
>
> if (argc && !strcmp(argv[0], "--")) {
> diff --git a/t/t2010-checkout-ambiguous.sh b/t/t2010-checkout-ambiguous.sh
> new file mode 100755
> index 0000000..389ba8c
> --- /dev/null
> +++ b/t/t2010-checkout-ambiguous.sh
> @@ -0,0 +1,35 @@
> +#!/bin/sh
> +
> +test_description='checkout and pathspecs/refspecs ambiguities'
> +
> +. ./test-lib.sh
> +
> +test_expect_success 'setup' '
> + echo hello >world &&
> + echo hello >all &&
> + git add all world &&
> + git commit -m initial &&
> + git branch world
> +'
> +
> +test_expect_success 'branch switching' '
> + test "refs/heads/master" = "$(git symbolic-ref HEAD)" &&
> + git checkout world -- &&
> + test "refs/heads/world" = "$(git symbolic-ref HEAD)"
> +'
> +
> +test_expect_success 'checkout world from the index' '
> + echo bye > world &&
> + git checkout -- world &&
> + git diff --exit-code --quiet
> +'
> +
> +test_expect_success 'non ambiguous call' '
> + git checkout all
> +'
> +
> +test_expect_success 'ambiguous call' '
> + test_must_fail git checkout world
> +'
> +
> +test_done
> --
> 1.6.0.rc0.154.ge2a39.dirty
>
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* RFC: git rebase -i and root commits
From: Eric Raible @ 2008-07-23 1:58 UTC (permalink / raw)
To: git
My normal workflow is to create a .gitignore in my initial commit.
When I later realize that I've forgotten something from that file
I could of course just commit the changes, but I'd rather use "git rebase -i"
in the normal way to make myself appear smarter than I am.
Especially since this realization usually comes early on
(and certainly before publishing).
But rebase can't go all the way to a root ("fatal: Needed a single revision").
The best I've found is:
1) git checkout -b temp <root commit>
2) echo '*.tmp' >> .gitignore
3) git commit --amend .gitignore
4) git rebase --onto temp <root commit> master
If there really is an asymmetry here and I haven't missed anything
(a large assumption), then what's the best way to think about it?
Is there a role for a default commit (e.g. the sha1 of "") here so that
'rebase -i' can update all commits and not just the ones with parents?
Or should I just get used to it and move on?
Thanks - Eric
^ permalink raw reply
* Re: RFC: git rebase -i and root commits
From: Stephan Beyer @ 2008-07-23 2:02 UTC (permalink / raw)
To: Eric Raible; +Cc: git
In-Reply-To: <loom.20080723T013019-412@post.gmane.org>
Hi,
Eric Raible wrote:
> My normal workflow is to create a .gitignore in my initial commit.
>
> When I later realize that I've forgotten something from that file
> I could of course just commit the changes, but I'd rather use "git rebase -i"
> in the normal way to make myself appear smarter than I am.
> Especially since this realization usually comes early on
> (and certainly before publishing).
>
> But rebase can't go all the way to a root ("fatal: Needed a single revision").
I think this has been fixed recently.
Regards,
Stephan
--
Stephan Beyer <s-beyer@gmx.net>, PGP 0x6EDDD207FCC5040F
^ permalink raw reply
* Git's config core.pager doesn't respect color.pager
From: Benjamin Kudria @ 2008-07-23 2:10 UTC (permalink / raw)
To: git
I'm seeing a problem with git. It's easier to demonstrate than
explain. The relevant parts of my .gitconfig:
[core]
pager = tig
[color]
diff = auto
pager = false
tig is a console-based git client that can also act as a pager,
colorizing git output.
So, with the above config, when I do:
git diff | tig
Everything works correctly - git sends no color codes, because of
color.pager = false.
However, if I do just:
git diff
git uses core.pager to display the output, but still sends color
codes, which is OK for, say, less, bit not so good for tig, which does
it's own colorizing, and displays the color codes git sends as-is.
Shouldn't core.pager respect color.pager, and not send the color codes?
Benjamin Kudria
--
http://ben.kudria.net | Jabber: ben@kudria.net
^ permalink raw reply
* Re: [PATCH] bring description of git diff --cc up to date
From: Jonathan Nieder @ 2008-07-23 3:55 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, David Greaves
In-Reply-To: <7vfxq1igh0.fsf@gitster.siamese.dyndns.org>
On Tue, 22 Jul 2008, Junio C Hamano wrote:
>> + This flag implies the '-c' option and makes the patch output
>> + even more compact by omitting uninteresting hunks. A hunk is
>> + considered uninteresting if the person merging had two versions
>> + to choose between among all of the parents and the result shows
>
> the above makes me confused into
> thinking that even if there are 47 parent versions, it is Ok if I looked
> at only two versions and picked from one of them
Here's another attempt. I grimace at the sound of it, but it might be
more clear.
--- snipsnip ---
Subject: document diff --cc's long-ago-changed semantics
In February 2006 [1], the definition of "interesting hunk" for
git's compact-combined diff format changed without a
corresponding change in documentation. This patch brings the
documentation up to date.
[1] commit bf1c32bdec8223785c779779d0a660a099f69a63
combine-diff: update --cc "uninteresting hunks" logic
Signed-off-by: Jonathan Nieder <jrnieder@uchicago.edu>
---
Documentation/git-diff-tree.txt | 12 +++++++-----
Documentation/rev-list-options.txt | 9 +++++----
2 files changed, 12 insertions(+), 9 deletions(-)
diff --git a/Documentation/git-diff-tree.txt b/Documentation/git-diff-tree.txt
index 0e45b58..7f8dc5b 100644
--- a/Documentation/git-diff-tree.txt
+++ b/Documentation/git-diff-tree.txt
@@ -92,12 +92,14 @@ include::pretty-options.txt[]
--cc::
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
+ and '-p' options and makes the patch output
+ even more compact by omitting uninteresting hunks. A hunk is
+ considered uninteresting if it shows no changes from at least
+ one of the parents and shows the same changes from each of the
+ parents from which it shows changes.
+ 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.
+ message are 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..d75de78 100644
--- a/Documentation/rev-list-options.txt
+++ b/Documentation/rev-list-options.txt
@@ -111,10 +111,11 @@ 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.
+ This flag implies the '-c' option and makes the patch output
+ even more compact by omitting uninteresting hunks. A hunk is
+ considered uninteresting if it shows no changes from at least
+ one of the parents and shows the same changes from each of the
+ parents from which it shows changes.
-r::
--
1.5.6.3.549.g8ca11
^ permalink raw reply related
* Re: [RFC] Git User's Survey 2008
From: Junio C Hamano @ 2008-07-23 4:39 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git, Stephan Beyer
In-Reply-To: <200807230325.04184.jnareb@gmail.com>
Jakub Narebski <jnareb@gmail.com> writes:
> 15. What operating system do you use Git on?
> (one or more: multiple choice, as one can use more than one OS)
> - Linux, *BSD (FreeBSD, OpenBSD, etc.), MS Windows/Cygwin,
> MS Windows/msysGit, MacOS X, other UNIX, other
Shouldn't we at least name the ones we have specific support in our
Makefile instead of blanketting them into one "other Unices"? We may not
necessarily want to list all of them, but at least major ones like SunOS,
HP-UX and AIX deserve to be listed, methinks.
> + "What hardware platforms do you use GIT on?" question was
> removed; should it stay?
I think the removal of "hardware platform" question is a good idea.
> 24. If you want to see Git more widely used, what do you
> think we could do to make this happen?
> + Is this question necessary/useful? Do we need wider adoption?
My stance on this has always been that wider adoption, even though it
might eventually come as a consequence of being the best in the field, is
never a goal.
> 27. Which of the following features do you use?
> (zero or more: multiple choice)
> - git-gui or other commit tool, gitk or other history viewer, patch
> management interface (e.g. StGIT), bundle, eol conversion,
> gitattributes, submodules, separate worktree, reflog, stash,
> shallow clone, detaching HEAD, mergetool, interactive rebase,
> add --interactive or other partial commit helper, commit
> templates, bisect, other (not mentioned here)
> + should probably be sorted in some resemblance of order
> + are there any new features which should be listed here?
The above is a valid and interesting question, but "Which features do you
find unique and useful ones, compared to other systems?" would be another
interesting question to ask to people with experience with other systems.
> 28. If you use some important Git features not mentioned above,
> what are it?
> (free form)
"rerere"?
> 40. Do you read the mailing list?
> - yes/no
Which mailing list? Do we want to ask about alternative lists?
I am not sure how and where, but I think j/egit should also be
mentioned and/or asked about.
^ permalink raw reply
* Re: [PATCH] Respect crlf attribute in "git add" even if core.autocrlf has not been set
From: Steffen Prohaska @ 2008-07-23 5:49 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Junio C Hamano, git, Dmitry Potapov
In-Reply-To: <alpine.DEB.1.00.0807230229410.8986@racer>
On Jul 23, 2008, at 3:31 AM, Johannes Schindelin wrote:
> When a file's crlf attribute is explicitely set, it does not make
> sense
> to ignore it when adding the file, just because the config variable
> core.autocrlf has not been set.
Your patch is not about core.autocrlf unset, but about
core.autocrlf=false.
On Unix, the two cases seem to be identical, but on Windows they are
not.
(see below).
> The alternative would be risking to get CR/LF files into the
> repository
> just because one user forgot to set core.autocrlf.
Git could help the user *and* the maintainer of the repository if we
chose core.autocrlf=input as the default on Unix. We would never
let CR/LF enter the repository unless explicitly requested to do so
by core.autocrlf=false. This setting however would not be recommended
to the average user.
But with Unix' default core.autocrlf=false, it makes sense to let the
maintainer of a repository enforce stripping CR from all files if not
explicitly configured otherwise for specific paths. Setting
"crlf=input"
in .gitattribute seems to be the documented way to do so --- although
the documentation in gitattributes.txt is a bit complex to read.
> This patch does not affect the case when the crlf attribute is unset,
> or when checking files out.
>
> Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
> ---
>
> Okay, so I lied and did not go to sleep (but that part comes
> now). Only the wording in the commit message has changed.
>
> convert.c | 2 +-
> t/t0020-crlf.sh | 10 ++++++++++
> 2 files changed, 11 insertions(+), 1 deletions(-)
>
> diff --git a/convert.c b/convert.c
> index 78efed8..d038d2f 100644
> --- a/convert.c
> +++ b/convert.c
> @@ -126,7 +126,7 @@ static int crlf_to_git(const char *path, const
> char *src, size_t len,
> struct text_stat stats;
> char *dst;
>
> - if ((action == CRLF_BINARY) || !auto_crlf || !len)
> + if ((action == CRLF_BINARY) || (!auto_crlf && action < 0) || !len)
I think we should strictly follow the documentation, so this should read
+ if ((action == CRLF_BINARY) || (!auto_crlf && action !=
CRLF_INPUT) || !len)
>
> return 0;
>
> gather_stats(src, len, &stats);
> diff --git a/t/t0020-crlf.sh b/t/t0020-crlf.sh
> index 1be7446..0bb3e6f 100755
> --- a/t/t0020-crlf.sh
> +++ b/t/t0020-crlf.sh
> @@ -436,4 +436,14 @@ test_expect_success 'invalid .gitattributes
> (must not crash)' '
>
> '
>
> +test_expect_success 'attribute crlf is heeded even without
> core.autocrlf' '
> +
> + echo "allcrlf crlf=input" > .gitattributes &&
> + git config --unset core.autocrlf &&
You should set core.autocrlf explicitly to false:
git config core.autocrlf false
Otherwise the test would pick up the user's global default.
>
> + git add allcrlf &&
> + git show :allcrlf | append_cr > expect &&
> + test_cmp allcrlf expect
> +
> +'
> +
> test_done
> --
> 1.6.0.rc0.22.gf2096d.dirty
... and we should verify that we only treat crlf=input specially, but
not "crlf".
The following changes could be applied on top of yours. (Apologies if
lines are
wrapped. I am composing this mail with the wrong email client.)
diff --git a/t/t0020-crlf.sh b/t/t0020-crlf.sh
index b37059b..e51e810 100755
--- a/t/t0020-crlf.sh
+++ b/t/t0020-crlf.sh
@@ -436,7 +436,7 @@ test_expect_success 'invalid .gitattributes (must
not crash)' '
'
-test_expect_success 'attribute crlf is heeded even without
core.autocrlf' '
+test_expect_success 'attribute crlf=input is heeded even with
core.autocrlf=false' '
echo "allcrlf crlf=input" > .gitattributes &&
git config core.autocrlf false &&
@@ -446,4 +446,15 @@ test_expect_success 'attribute crlf is heeded
even without core.autocrlf' '
'
+test_expect_success 'attribute crlf is ignored with
core.autocrlf=false' '
+
+ echo "allcrlf crlf" > .gitattributes &&
+ git config core.autocrlf false &&
+ git read-tree --reset HEAD &&
+ git add allcrlf &&
+ git show :allcrlf > expect &&
+ test_cmp allcrlf expect
+
+'
+
test_done
^ permalink raw reply related
* Re: [PATCH/RFC] git add: do not add files from a submodule
From: Junio C Hamano @ 2008-07-23 6:40 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <alpine.DEB.1.00.0807222230490.8986@racer>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> Do you plan to apply the split-up builtin-add enhancments you did a few
> nights ago,...
I have a few updates to that one, I'll be sending them out shortly.
Switching branches between revs that have and do not have submodule at a
given path has always been broken. It is not even a "known breakage",
which is a word used for something that has a sensible design already is
worked out but the implementation does not do so.
If we started the process of diagnosing and fixing these issues earlier,
and had plausible code to address the issue already in 'next' before the
current -rc cycle started, the topic would have been an obvious candidate
for the coming release and I'd further say it would be even worth delaying
the release for a few weeks if it takes more time. But I have to say it
is too late for 1.6.0 now if we are just noticing and starting the
discussion. This comment goes to the issue Pierre raised last night as
well.
Nobody prevents us from starting the process to discuss and prepare to put
something in 'next' for 1.6.1 cycle now, though.
^ permalink raw reply
* Re: [PATCH v2] git daemon: avoid waking up too often
From: Johannes Sixt @ 2008-07-23 6:51 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git, Junio C Hamano
In-Reply-To: <alpine.DEB.1.00.0807222302440.8986@racer>
Johannes Schindelin schrieb:
> To avoid waking up unnecessarily, a pipe is set up that is only ever
> written to by child_handler(), when a child disconnects, as suggested
> per Junio.
>
> This avoids waking up the main process every second to see if a child
> was disconnected.
This makes porting this beast to Windows practically impossible because we
cannot have a poll() implementation that waits both on a listening socket
and a pipe. :-(
-- Hannes
^ permalink raw reply
* [PATCH 1/2] builtin-add.c: restructure the code for maintainability
From: Junio C Hamano @ 2008-07-23 7:01 UTC (permalink / raw)
To: git
A private function add_files_to_cache() in builtin-add.c was borrowed by
checkout and commit re-implementors without getting properly refactored to
more library-ish place. This does the refactoring.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
* This is just code movement.
builtin-add.c | 57 -----------------------------------------------------
cache.h | 1 +
read-cache.c | 61 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++
3 files changed, 62 insertions(+), 57 deletions(-)
diff --git a/builtin-add.c b/builtin-add.c
index fc3f96e..0de516a 100644
--- a/builtin-add.c
+++ b/builtin-add.c
@@ -8,10 +8,6 @@
#include "dir.h"
#include "exec_cmd.h"
#include "cache-tree.h"
-#include "diff.h"
-#include "diffcore.h"
-#include "commit.h"
-#include "revision.h"
#include "run-command.h"
#include "parse-options.h"
@@ -79,59 +75,6 @@ static void fill_directory(struct dir_struct *dir, const char **pathspec,
prune_directory(dir, pathspec, baselen);
}
-struct update_callback_data
-{
- int flags;
- int add_errors;
-};
-
-static void update_callback(struct diff_queue_struct *q,
- struct diff_options *opt, void *cbdata)
-{
- int i;
- struct update_callback_data *data = cbdata;
-
- for (i = 0; i < q->nr; i++) {
- struct diff_filepair *p = q->queue[i];
- const char *path = p->one->path;
- switch (p->status) {
- default:
- die("unexpected diff status %c", p->status);
- case DIFF_STATUS_UNMERGED:
- case DIFF_STATUS_MODIFIED:
- case DIFF_STATUS_TYPE_CHANGED:
- if (add_file_to_cache(path, data->flags)) {
- if (!(data->flags & ADD_CACHE_IGNORE_ERRORS))
- die("updating files failed");
- data->add_errors++;
- }
- break;
- case DIFF_STATUS_DELETED:
- if (!(data->flags & ADD_CACHE_PRETEND))
- remove_file_from_cache(path);
- if (data->flags & (ADD_CACHE_PRETEND|ADD_CACHE_VERBOSE))
- printf("remove '%s'\n", path);
- break;
- }
- }
-}
-
-int add_files_to_cache(const char *prefix, const char **pathspec, int flags)
-{
- struct update_callback_data data;
- struct rev_info rev;
- init_revisions(&rev, prefix);
- setup_revisions(0, NULL, &rev, NULL);
- rev.prune_data = pathspec;
- rev.diffopt.output_format = DIFF_FORMAT_CALLBACK;
- rev.diffopt.format_callback = update_callback;
- data.flags = flags;
- data.add_errors = 0;
- rev.diffopt.format_callback_data = &data;
- run_diff_files(&rev, DIFF_RACY_IS_MODIFIED);
- return !!data.add_errors;
-}
-
static void refresh(int verbose, const char **pathspec)
{
char *seen;
diff --git a/cache.h b/cache.h
index 38985aa..6f374ad 100644
--- a/cache.h
+++ b/cache.h
@@ -375,6 +375,7 @@ extern int remove_file_from_index(struct index_state *, const char *path);
#define ADD_CACHE_VERBOSE 1
#define ADD_CACHE_PRETEND 2
#define ADD_CACHE_IGNORE_ERRORS 4
+#define ADD_CACHE_IGNORE_REMOVAL 8
extern int add_to_index(struct index_state *, const char *path, struct stat *, int flags);
extern int add_file_to_index(struct index_state *, const char *path, int flags);
extern struct cache_entry *make_cache_entry(unsigned int mode, const unsigned char *sha1, const char *path, int stage, int refresh);
diff --git a/read-cache.c b/read-cache.c
index a50a851..6833af6 100644
--- a/read-cache.c
+++ b/read-cache.c
@@ -8,6 +8,11 @@
#include "cache-tree.h"
#include "refs.h"
#include "dir.h"
+#include "tree.h"
+#include "commit.h"
+#include "diff.h"
+#include "diffcore.h"
+#include "revision.h"
/* Index extensions.
*
@@ -1444,3 +1449,59 @@ int read_index_unmerged(struct index_state *istate)
istate->cache_nr = dst - istate->cache;
return !!last;
}
+
+struct update_callback_data
+{
+ int flags;
+ int add_errors;
+};
+
+static void update_callback(struct diff_queue_struct *q,
+ struct diff_options *opt, void *cbdata)
+{
+ int i;
+ struct update_callback_data *data = cbdata;
+
+ for (i = 0; i < q->nr; i++) {
+ struct diff_filepair *p = q->queue[i];
+ const char *path = p->one->path;
+ switch (p->status) {
+ default:
+ die("unexpected diff status %c", p->status);
+ case DIFF_STATUS_UNMERGED:
+ case DIFF_STATUS_MODIFIED:
+ case DIFF_STATUS_TYPE_CHANGED:
+ if (add_file_to_index(&the_index, path, data->flags)) {
+ if (!(data->flags & ADD_CACHE_IGNORE_ERRORS))
+ die("updating files failed");
+ data->add_errors++;
+ }
+ break;
+ case DIFF_STATUS_DELETED:
+ if (data->flags & ADD_CACHE_IGNORE_REMOVAL)
+ break;
+ if (!(data->flags & ADD_CACHE_PRETEND))
+ remove_file_from_index(&the_index, path);
+ if (data->flags & (ADD_CACHE_PRETEND|ADD_CACHE_VERBOSE))
+ printf("remove '%s'\n", path);
+ break;
+ }
+ }
+}
+
+int add_files_to_cache(const char *prefix, const char **pathspec, int flags)
+{
+ struct update_callback_data data;
+ struct rev_info rev;
+ init_revisions(&rev, prefix);
+ setup_revisions(0, NULL, &rev, NULL);
+ rev.prune_data = pathspec;
+ rev.diffopt.output_format = DIFF_FORMAT_CALLBACK;
+ rev.diffopt.format_callback = update_callback;
+ data.flags = flags;
+ data.add_errors = 0;
+ rev.diffopt.format_callback_data = &data;
+ run_diff_files(&rev, DIFF_RACY_IS_MODIFIED);
+ return !!data.add_errors;
+}
+
--
1.6.0.rc0.15.g0dda1
^ permalink raw reply related
* [PATCH 2/2] builtin-add.c: optimize -A option and "git add $paths..."
From: Junio C Hamano @ 2008-07-23 7:01 UTC (permalink / raw)
To: git
In-Reply-To: <1216796502-11227-1-git-send-email-gitster@pobox.com>
The earlier "git add -A" change was done in a quite inefficient
way (i.e. it is as unefficient as "git add -u && git add ." modulo
one fork/exec and read/write index).
For that matter, the original "git add $paths..." could be improved.
When the user asks "git add .", we do not have to examine all paths
we encounter and perform the excluded() and dir_add_name()
processing, both of which are slower code and use slower data structure
by git standards, especially when the index is already reasonably well
populated.
Instead, we implement "git add $pathspec..." as:
- read the index;
- read_directory() to process untracked, unignored files the current
way, that is, recursively doing readdir(), filtering them by pathspec
and excluded(), queueing them via dir_add_name() and finally do
add_files(); and
- iterate over the index, filtering them by pathspec, and update only
the modified/type changed paths but not deleted ones.
And "git add -A" becomes exactly the same as above, modulo:
- missing $pathspec means "." instead of being an error; and
- "iterate over the index" part handles deleted ones as well,
i.e. exactly what the current update_callback() in builtin-add.c does.
In either case, because fill_directory() does not use read_directory() to
read everything in, we need to add an extra logic to iterate over the
index to catch mistyped pathspec.
In a fully populated kernel tree (without any local change), best of ten
runs:
(with this patch)
$ /usr/bin/time ~/git-test/bin/git add .
0.16user 0.17system 0:00.34elapsed 99%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (0major+3231minor)pagefaults 0swaps
(without this patch)
$ /usr/bin/time ~/git-master/bin/git add .
0.21user 0.21system 0:00.42elapsed 99%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (0major+3647minor)pagefaults 0swaps
Under the same condition, but after "rm .git/index" to force re-indexing
everything (the patch should not make any difference):
(with this patch)
$ /usr/bin/time ~/git-test/bin/git add .
3.22user 2.10system 1:35.10elapsed 5%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (30037major+63003minor)pagefaults 0swaps
(without this patch)
$ /usr/bin/time ~/git-master/bin/git add .
3.31user 2.28system 1:44.77elapsed 5%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (30472major+62563minor)pagefaults 0swaps
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
builtin-add.c | 43 +++++++++++++++++++++++++++++++------------
1 files changed, 31 insertions(+), 12 deletions(-)
diff --git a/builtin-add.c b/builtin-add.c
index 0de516a..1834e2d 100644
--- a/builtin-add.c
+++ b/builtin-add.c
@@ -18,6 +18,27 @@ static const char * const builtin_add_usage[] = {
static int patch_interactive = 0, add_interactive = 0;
static int take_worktree_changes;
+static void fill_pathspec_matches(const char **pathspec, char *seen, int specs)
+{
+ int num_unmatched = 0, i;
+
+ /*
+ * Since we are walking the index as if we are warlking the directory,
+ * we have to mark the matched pathspec as seen; otherwise we will
+ * mistakenly think that the user gave a pathspec that did not match
+ * anything.
+ */
+ for (i = 0; i < specs; i++)
+ if (!seen[i])
+ num_unmatched++;
+ if (!num_unmatched)
+ return;
+ for (i = 0; i < active_nr; i++) {
+ struct cache_entry *ce = active_cache[i];
+ match_pathspec(pathspec, ce->name, ce_namelen(ce), 0, seen);
+ }
+}
+
static void prune_directory(struct dir_struct *dir, const char **pathspec, int prefix)
{
char *seen;
@@ -37,6 +58,7 @@ static void prune_directory(struct dir_struct *dir, const char **pathspec, int p
*dst++ = entry;
}
dir->nr = dst - dir->entries;
+ fill_pathspec_matches(pathspec, seen, specs);
for (i = 0; i < specs; i++) {
if (!seen[i] && !file_exists(pathspec[i]))
@@ -201,7 +223,7 @@ int cmd_add(int argc, const char **argv, const char *prefix)
if (addremove && take_worktree_changes)
die("-A and -u are mutually incompatible");
- if (addremove && !argc) {
+ if ((addremove || take_worktree_changes) && !argc) {
static const char *here[2] = { ".", NULL };
argc = 1;
argv = here;
@@ -214,7 +236,9 @@ int cmd_add(int argc, const char **argv, const char *prefix)
flags = ((verbose ? ADD_CACHE_VERBOSE : 0) |
(show_only ? ADD_CACHE_PRETEND : 0) |
- (ignore_add_errors ? ADD_CACHE_IGNORE_ERRORS : 0));
+ (ignore_add_errors ? ADD_CACHE_IGNORE_ERRORS : 0) |
+ (!(addremove || take_worktree_changes)
+ ? ADD_CACHE_IGNORE_REMOVAL : 0));
if (require_pathspec && argc == 0) {
fprintf(stderr, "Nothing specified, nothing added.\n");
@@ -223,24 +247,19 @@ int cmd_add(int argc, const char **argv, const char *prefix)
}
pathspec = get_pathspec(prefix, argv);
- /*
- * If we are adding new files, we need to scan the working
- * tree to find the ones that match pathspecs; this needs
- * to be done before we read the index.
- */
- if (add_new_files)
- fill_directory(&dir, pathspec, ignored_too);
-
if (read_cache() < 0)
die("index file corrupt");
+ if (add_new_files)
+ /* This picks up the paths that are not tracked */
+ fill_directory(&dir, pathspec, ignored_too);
+
if (refresh_only) {
refresh(verbose, pathspec);
goto finish;
}
- if (take_worktree_changes || addremove)
- exit_status |= add_files_to_cache(prefix, pathspec, flags);
+ exit_status |= add_files_to_cache(prefix, pathspec, flags);
if (add_new_files)
exit_status |= add_files(&dir, flags);
--
1.6.0.rc0.15.g0dda1
^ permalink raw reply related
* [PATCH] Fix git-svnimport against libsvn_ra.
From: P. Christeas @ 2008-07-23 7:10 UTC (permalink / raw)
To: git; +Cc: Gerrit Pape
In r27729, libsvn introduced an assert which explicitly
forbids searching the tree at "/". Luckily enough, it
still accepts an empty string "" as the starting point.
http://svn.collab.net/viewvc/svn/trunk/subversion/libsvn_ra/ra_loader.c?r1=27653&r2=27729
---
contrib/examples/git-svnimport.perl | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/contrib/examples/git-svnimport.perl
b/contrib/examples/git-svnimport.perl
index ea8c1b2..a13bb6a 100755
--- a/contrib/examples/git-svnimport.perl
+++ b/contrib/examples/git-svnimport.perl
@@ -933,7 +933,7 @@ while ($to_rev < $opt_l) {
$to_rev = $from_rev + $repack_after;
$to_rev = $opt_l if $opt_l < $to_rev;
print "Fetching from $from_rev to $to_rev ...\n" if $opt_v;
- $svn->{'svn'}->get_log("/",$from_rev,$to_rev,0,1,1,\&commit_all);
+ $svn->{'svn'}->get_log("",$from_rev,$to_rev,0,1,1,\&commit_all);
my $pid = fork();
die "Fork: $!\n" unless defined $pid;
unless($pid) {
--
1.5.6
^ permalink raw reply related
* [PATCH] rebase -i: When an 'edit' stops, mention the commit
From: Johannes Sixt @ 2008-07-23 7:46 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Johannes Schindelin, Git Mailing List
From: Johannes Sixt <johannes.sixt@telecom.at>
In a rebase session where more than one commit is to be 'edit'ed, and the
user spends considerable time to 'edit' a commit, it is easy to forget what
one wanted to 'edit' at the individual commits. It would be helpful to see
at which commit the rebase stopped.
Incidentally, if the rebase stopped due to merge conflicts or other errors,
the commit was already reported ("Could not apply $sha1..."), but when
rebase stopped after successfully applying an "edit" commit, it would not
mention it. With this change the commit is reported.
Signed-off-by: Johannes Sixt <johannes.sixt@telecom.at>
---
git-rebase--interactive.sh | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/git-rebase--interactive.sh b/git-rebase--interactive.sh
index e63a864..4e334ba 100755
--- a/git-rebase--interactive.sh
+++ b/git-rebase--interactive.sh
@@ -277,7 +277,7 @@ do_next () {
die_with_patch $sha1 "Could not apply $sha1... $rest"
make_patch $sha1
: > "$DOTEST"/amend
- warn
+ warn "Stopped at $sha1... $rest"
warn "You can amend the commit now, with"
warn
warn " git commit --amend"
--
1.6.0.rc0.956.g7bc0
^ permalink raw reply related
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