* [PATCH] 64-bit fix for date.c.
From: Bernd Ahlers @ 2009-04-06 17:26 UTC (permalink / raw)
To: git
Hello!
This unbreaks the localtime_r call on OpenBSD/sparc64 and removes
the following compiler warning.
"passing arg 1 of `localtime_r' from incompatible pointer type"
---
date.c | 4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/date.c b/date.c
index 1165d30..409a17d 100644
--- a/date.c
+++ b/date.c
@@ -871,13 +871,15 @@ unsigned long approxidate(const char *date)
int number = 0;
struct tm tm, now;
struct timeval tv;
+ time_t time_sec;
char buffer[50];
if (parse_date(date, buffer, sizeof(buffer)) > 0)
return strtoul(buffer, NULL, 10);
gettimeofday(&tv, NULL);
- localtime_r(&tv.tv_sec, &tm);
+ time_sec = tv.tv_sec;
+ localtime_r(&time_sec, &tm);
now = tm;
for (;;) {
unsigned char c = *date;
--
1.6.2.2
^ permalink raw reply related
* Re: git diff bug?
From: Junio C Hamano @ 2009-04-06 17:56 UTC (permalink / raw)
To: Matthieu Moy; +Cc: Jeff King, David Abrahams, git
In-Reply-To: <vpqeiw53cpy.fsf@bauges.imag.fr>
Matthieu Moy <Matthieu.Moy@imag.fr> writes:
> Jeff King <peff@peff.net> writes:
>
>> But the latter two lines are about preference: "here is how _I_ would
>> like to generate diffs for el files".
>
> ... and they are commands to be executed. If they were in the
> repository, and propagated with clone, then doing
>
> git clone git://some.git/repo
> cd repo
> git diff
>
> would execute arbitrary commands, which wouldn't be acceptable for
> security reasons.
Other configuration variables have such security implications, but diff
hunk header bit doesn't. You are a bit overly cautious in this particular
case.
^ permalink raw reply
* Re: git diff bug?
From: David Abrahams @ 2009-04-06 17:58 UTC (permalink / raw)
To: Michael J Gruber; +Cc: Jeff King, git
In-Reply-To: <49DA156A.1000105@drmicha.warpmail.net>
On Apr 6, 2009, at 10:44 AM, Michael J Gruber wrote:
>
> Well, I don't think anayone else has tried putting config lines into
> .gitattributes ;)
>
> The "*.el" line goes into .gitattributes (or .git/info/a...), the
> other
> lines are config lines and thus goe into .git/config or .gitconfig.
Aha, thanks. The hunk header section in the gitattributes manpage
turns out to be the only one that shows config stuff without
mentioning a config file, thus my confusion. I suggest a tiny patch
('cept I don't know how to write manpage format)
--
David Abrahams
BoostPro Computing
http://boostpro.com
^ permalink raw reply
* Re: [PATCH v2] Add configuration variable for sign-off to format-patch
From: Heiko Voigt @ 2009-04-06 18:09 UTC (permalink / raw)
To: Matthieu Moy; +Cc: Andreas Ericsson, Junio C Hamano, Jeff King, git
In-Reply-To: <vpqvdpi5807.fsf@bauges.imag.fr>
On Mon, Apr 06, 2009 at 01:36:24PM +0200, Matthieu Moy wrote:
> Andreas Ericsson <exon@op5.com> writes:
>
> > How about:
> > "Some projects (notably the Linux kernel and git itself) put special
> > meaning in a 'Signed-off-by' line while other's dont. Please refer
> > to your project's documentation for appropriate behaviour."
> >
> > Optionally with the following amendment:
> >
> > "In general, you should refrain from signing off on a patch containing
> > material that you're not sure can be legally spread under the project's
> > license."
>
> To me, this is at least an improvement over refering to
> SubmittingPatches (which is targeted to Git contributors) in the
> documentation (targeted to Git users), yes.
To me too. When writing I was probably too focused on Git.
> Not sure whether these two sentences should come in the documentation
> for the config option or the command-line switch.
I think you should be able to get to this note from all locations where
this option is provided (+ the commit option) so maybe a link ?
cheers Heiko
^ permalink raw reply
* Ref refs/heads/master is at *** but expected ***
From: Rick Martinez @ 2009-04-06 18:11 UTC (permalink / raw)
To: git
Hey guys,
So I was doing an interactive rebase and when I continued after fixing
a conflict, I got:
error: Ref refs/heads/master is at
13c56aa5628c03953912a683136f38cad852471b but expected
25713c34497cf07e4476291e6cd720d8a667701c
fatal: Cannot lock the ref 'refs/heads/master'.
When I do a git status, I get:
# On branch master
# Your branch and 'origin/master' have diverged,
# and have 6 and 5 different commit(s) each, respectively.
#
nothing to commit (working directory clean)
Any ideas on what to do next to try and get my branch back in order?
Thanks!
Rick
^ permalink raw reply
* Re: git diff bug?
From: David Abrahams @ 2009-04-06 18:16 UTC (permalink / raw)
To: Jeff King; +Cc: git
In-Reply-To: <20090406155303.GA3275@sigill.intra.peff.net>
On Apr 6, 2009, at 11:53 AM, Jeff King wrote:
> All of that being said, it is obviously a documentation failure if it
> didn't explain in which files the various parts go. If you don't mind,
> can you skim over the documentation you read one more time and point
> out
> where it led you wrong? Maybe we can make it a little clearer.
Wow, that is a *really* admirable response. Git itself may be a tad
arcane, but the community has been fantastic. Thanks billionses for
that -- it can only mean more a more learnable Git down the road. I
posted an answer to your question in a different reply.
--
David Abrahams
BoostPro Computing
http://boostpro.com
^ permalink raw reply
* Re: [RFC/PATCH 0/2] New 'stage' command
From: Junio C Hamano @ 2009-04-06 18:30 UTC (permalink / raw)
To: David Kågedal
Cc: git, David Aguilar, Sverre Rabbelier, markus.heidelberg,
Felipe Contreras
In-Reply-To: <871vs5kjfw.fsf@krank.kagedal.org>
David Kågedal <davidk@lysator.liu.se> writes:
> What do you mean? This was a suggestion for how git diff should
> work. I fail to see how you would need a WORKTREEANDTHEINDEX there.
You are talking only about "git diff". I am talking about the whole git
suite, because you have to worry about how such a proposal would affect
other parts of the UI.
For example, what, if anything, should be done to "git grep --cached" and
"git apply --index"? Leave them unchanged and only change "git diff"?
> I think this is a basic usability issue for a high-level porcelain
> command such as diff.
I do not think there is any usability issue. Why do you think saying
STAGE in all capital makes it easier to _use_ instead of saying --cached
(or --index-only)? In either way, you need to understand the underlying
concept, such as:
- there are three distinct kinds of states: a committed state, the state
in the index (aka "what you have staged so far to the index"), and the
state in your work tree.
- many commands understand that you want to operate on and/or inspect
states in one or more of these states. They default to what is often
used (e.g. "git diff" compares the index and the work tree, "git grep"
looks in the work tree, "git apply" patches the work tree [*1*]), but
you can tell them to use different entities via options and arguments.
How does it help understanding any of the above to introduce STAGE?
The only difference I see is that you change "via options and arguments"
to "via arguments of different kinds, either a real commit object name or
some fake token that stands for the index or the work tree state".
Spelled out more explicitly, the current "options and arguments" works
this way:
- when you want to work with a committed state (or more in general,
with a tree-ish), you give the name of the commit;
- when you want to work with the index, you say --cached;
- when you want to work with both the index and the work tree at the
same time, you say --index.
- for all commands, working with work tree is the default, so there is
no --work-tree option (we could add one, if you really want).
and the STAGE would work something like this:
- when you want to work with a committed state (or more in general,
with a tree-ish), you give the name of the commit;
- when you want to work with the index, you say STAGE; not that you
cannot have a ref called STAGE and if you have a file in the work
tree whose name is STAGE you need to say "git command ... -- STAGE"
to name the file, or "git command ... STAGE --" to clarify that you
do not mean the file but you mean to use the fake toekn STAGE.
- when you want to work with both the index and the work tree at the
same time, you say STAGEANDWORKTREE (the same disambiguation caveat
applies).
- for all commands, working with work tree is the default, but you can
still say WORKTREE (the same disambiguation caveat applies).
If anything, I think these capitalized fake tokens spread more confusion.
Sure, "git diff HEAD STAGED" and "git diff HEAD WORKTREE" may make the
command lines look as if what these fake tokens represent are "sort of"
commits, but that is only true while you are using a command that has
modes to work on the index and/or on the work tree.
These fake tokens do not work everywhere, and it is not an implementation
limit. Fundamentally they cannot work everywhere.
Think. What does "git log STAGE" mean? Can you explain why it does not
make any sense?
The user needs to be aware that the index is NOT a commit to understand
why such a command line doesn't make sense _anyway_.
I think it is counterproductive for the learning curve of new people to
make these different concepts look as if they belong to the same family by
using STAGE (that look too similar to HEAD). You seem to think it would
make it easier for them to learn if these different concepts are not
presented as different. But they are different, and if new people start
with a false impression that these are "sort of" commits, they need to
unlearn that at some point, and that "some point" is not "advanced use".
Even bog standard "git log" exposes why hiding the conceptual differences
between these three states does not work.
Teach that different things are different, and express that in the UI.
That would avoid the confusion down the line.
[Footnote]
*1* "git apply" was originally done to replace use of "GNU patch" in
Linus's workflow because "patch" was deliberately too lenient, and as
such, it does not look at the index by default. In a git repository, as
long as a patch does not contain creation of new files, this is a good
default, too. You can "git apply incoming.patch && git diff -U20" to see
what the patch does in wider context, for example. If "git apply --index"
were the default, the same can be done with "git diff -U20 HEAD" and it
won't risk forgetting new files. But it is a huge backward incompatible
change that won't happen without deep thought.
^ permalink raw reply
* Re: git diff bug?
From: Jeff King @ 2009-04-06 18:48 UTC (permalink / raw)
To: David Abrahams; +Cc: Junio C Hamano, Michael J Gruber, git
In-Reply-To: <D4B0EDF7-E1BD-44E3-858F-002CFF2C496A@boostpro.com>
On Mon, Apr 06, 2009 at 01:58:08PM -0400, David Abrahams wrote:
>> The "*.el" line goes into .gitattributes (or .git/info/a...), the other
>> lines are config lines and thus goe into .git/config or .gitconfig.
>
> Aha, thanks. The hunk header section in the gitattributes manpage turns
> out to be the only one that shows config stuff without mentioning a config
> file, thus my confusion. I suggest a tiny patch ('cept I don't know how
> to write manpage format)
Neither do I, but fortunately the git docs are all written in asciidoc. :)
Junio, does the patch below make sense to you?
-- >8 --
Subject: [PATCH] doc/gitattributes: clarify location of config text
The gitattributes documentation has a section on the "diff"
attribute, with subsections for each of the things you might
want to configure in your diff config section (external
diff, hunk headers, etc). The first such subsection
specifically notes that the definition of the diff driver
should go into $GIT_DIR/config, but subsequent sections do
not.
This location is implied if you are reading the
documentation sequentially, but it is not uncommon for a new
user to jump to (or be referred to) a specific section. For
a new user who does not know git well enough to recognize
the config syntax, it is not clear that those directives
don't also go into the gitattributes file.
This patch just mentions the config file in each subsection,
similar to the way it is mentioned in the first.
Signed-off-by: Jeff King <peff@peff.net>
---
Mentioning $GIT_DIR/config _and_ $HOME/.gitconfig in each subsection may
seem like overkill, but I really think we shouldn't make any assumption
that a reader has seen the previous sections. They otherwise stand alone
very well.
I arrived at these three sections by grepping for '^[' to find example
config file syntax.
Documentation/gitattributes.txt | 9 ++++++---
1 files changed, 6 insertions(+), 3 deletions(-)
diff --git a/Documentation/gitattributes.txt b/Documentation/gitattributes.txt
index 55668e3..b6260b1 100644
--- a/Documentation/gitattributes.txt
+++ b/Documentation/gitattributes.txt
@@ -297,7 +297,8 @@ for paths.
Then, you would define a "diff.tex.xfuncname" configuration to
specify a regular expression that matches a line that you would
-want to appear as the hunk header "TEXT", like this:
+want to appear as the hunk header "TEXT". Add a section to your
+`$GIT_DIR/config` file (or `$HOME/.gitconfig` file) like this:
------------------------
[diff "tex"]
@@ -345,7 +346,8 @@ split words in a line, by specifying an appropriate regular expression
in the "diff.*.wordRegex" configuration variable. For example, in TeX
a backslash followed by a sequence of letters forms a command, but
several such commands can be run together without intervening
-whitespace. To separate them, use a regular expression such as
+whitespace. To separate them, use a regular expression in your
+`$GIT_DIR/config` file (or `$HOME/.gitconfig` file) like this:
------------------------
[diff "tex"]
@@ -373,7 +375,8 @@ resulting text on stdout.
For example, to show the diff of the exif information of a
file instead of the binary information (assuming you have the
-exif tool installed):
+exif tool installed), add the following section to your
+`$GIT_DIR/config` file (or `$HOME/.gitconfig` file):
------------------------
[diff "jpg"]
--
1.6.2.2.585.g1e067
^ permalink raw reply related
* Re: [PATCH v2] Documentation: clarify .gitattributes search
From: Jeff King @ 2009-04-06 18:59 UTC (permalink / raw)
To: Jason Merrill; +Cc: Junio C Hamano, git
In-Reply-To: <49DA19C8.5010308@redhat.com>
On Mon, Apr 06, 2009 at 11:03:36AM -0400, Jason Merrill wrote:
> Junio C Hamano wrote:
>> (2) also wondered why you were confused to think if your home directory
>> (for that matter, any higher directory, like /.gitattributes at the
>> filesystem root level) that is clearly outside of the project could
>> possibly affect what happens inside a project; and
>
> Because it would be useful if it did; specifically, it would be
> convenient to be able to say that ChangeLog files use git-merge-changelog
> wherever they appear, and not have to repeat that in all my projects. I
> didn't really expect it, but thought that maybe it was designed to work
> that way.
I don't think per-user attribute patterns are an unreasonable thing to
want, but I think traversing above the git worktree root is not a good
way to implement it. Specifically:
1. It's inefficient. If your repo is only two directories deep, we now
might look at 2 gitattributes files. But if you put your repo in
/some/long/path/in/your/filesystem, we now have to check _each_ of
those, even though they are very unlikely to contain gitattributes
files.
2. It doesn't cover the per-user case very well. Repositories in your
home directory and repositories in (for example) /tmp would need
two separate gitattributes files.
Specifically checking $HOME/.gitattributes does make some sense to me
(though perhaps it is worth giving it a different basename in case your
home directory actually is a git repository).
The argument against it would be that it is up to the repo to define the
_types_ of its files, and for the user to define what to do with those
types. But if you have many repos, I could certainly see it being
convenient to globally say "for lack of better information, assume *.foo
files are type foo".
And there is already some precedent, as you note, in core.excludesfile.
-Peff
^ permalink raw reply
* Re: started a cvsps testsuite Was: Re: [PATCH v3 0/2] cvsimport: add test illustrating a bug in cvsps
From: Heiko Voigt @ 2009-04-06 19:01 UTC (permalink / raw)
To: Michael Haggerty
Cc: Michael J Gruber, Junio C Hamano, Heiko Voigt, ydirson, git,
CVSps
In-Reply-To: <49C8667B.5050506@alum.mit.edu>
On Tue, Mar 24, 2009 at 05:50:03AM +0100, Michael Haggerty wrote:
> Heiko Voigt wrote:
> > I just started a very simple but hopefully effective testsuite to
> > collect all the issues we found with cvsps. [...]
> >
> > Maybe Michael can add his tests as well. You should just need to
> > construct the expected cvsps output.
>
> Please note that the cvsps output format itself is not rich enough to
> represent all of the information needed, so it is not trivial to
> construct the "expected" output.
But its possible ;) I have extracted some tests from the scripts you
send and pushed them into the repo. The output format definitely needs
extension. I already included that in the expected output. Maybe you
want to have a look. Tell me what you think.
> The following is from an email that I
> sent to the Mercurial mailing list [1]:
>
> > I spent some time looking into cvsps, and I don't think that its
> > output format, let alone the output itself, is suitable for
> > industrial-strength conversion from CVS. For example, as far as I
> > can tell from my brief investigation:
> >
> > * log messages are not unambiguously separable from the metadata
> >
Thats one issue which could be addressed by escaping the sequences which
lead to the ambiguity.
All issues described below could be addressed by the examples I included in
the tests.
> > * it seems to only allow a single tag per changeset
> >
> > * it seems to only apply tags to single changesets, whereas in CVS
> > files can be added to a tag at different times.
> > ...
> >
> > * it seems to completely ignore a branch tag if no commits were
> > ever made on that branch.
> >
> > * it seems to ignore the effect that a second import to a vendor
> > branch has on the main branch.
>
> You might also be interested to know that there has been some work in
> the Mercurial project on a Python-based "cvsps". I believe they use
> their own version for their cvsimport extension. I don't know how
> different their cvsps is from the original.
Thats indeed interesting I have to try it once the testsuite is ready.
Maybe we can then just replace the original.
cheers Heiko
^ permalink raw reply
* [PATCH] git-gui: run post-checkout hook after clone
From: Jens Lehmann @ 2009-04-06 19:05 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: git, gitster, peff
git-gui is using "git-read-tree -u" when cloning which doesn't
invoke the post-checkout hook as a plain git-clone would.
So git-gui must call the hook itself.
Signed-off-by: Jens Lehmann <Jens.Lehmann@web.de>
---
git-gui/lib/choose_repository.tcl | 29 ++++++++++++++++++++++++++++-
1 files changed, 28 insertions(+), 1 deletions(-)
diff --git a/git-gui/lib/choose_repository.tcl b/git-gui/lib/choose_repository.tcl
index f9ff62a..00f388f 100644
--- a/git-gui/lib/choose_repository.tcl
+++ b/git-gui/lib/choose_repository.tcl
@@ -964,7 +964,34 @@ method _readtree_wait {fd} {
return
}
- set done 1
+ # -- Run the post-checkout hook.
+ #
+ set fd_ph [githook_read post-checkout [string repeat 0 40] \
+ [git rev-parse HEAD] 1]
+ if {$fd_ph ne {}} {
+ global pch_error
+ set pch_error {}
+ fconfigure $fd_ph -blocking 0 -translation binary -eofchar {}
+ fileevent $fd_ph readable [cb _postcheckout_wait $fd_ph]
+ } else {
+ set done 1
+ }
+}
+
+method _postcheckout_wait {fd_ph} {
+ global pch_error
+
+ append pch_error [read $fd_ph]
+ fconfigure $fd_ph -blocking 1
+ if {[eof $fd_ph]} {
+ if {[catch {close $fd_ph}]} {
+ hook_failed_popup post-checkout $pch_error 0
+ }
+ unset pch_error
+ set done 1
+ return
+ }
+ fconfigure $fd_ph -blocking 0
}
######################################################################
--
1.6.2.2.405.g4396
^ permalink raw reply related
* Re: [PATCH] 64-bit fix for date.c.
From: Jeff King @ 2009-04-06 19:06 UTC (permalink / raw)
To: Bernd Ahlers; +Cc: git
In-Reply-To: <20090406172637.GA17437@jenna.bytemine.net>
On Mon, Apr 06, 2009 at 07:26:37PM +0200, Bernd Ahlers wrote:
> @@ -871,13 +871,15 @@ unsigned long approxidate(const char *date)
> struct timeval tv;
> + time_t time_sec;
> [...]
> gettimeofday(&tv, NULL);
> - localtime_r(&tv.tv_sec, &tm);
> + time_sec = tv.tv_sec;
> + localtime_r(&time_sec, &tm);
Hmph. According to POSIX, tv_sec _is_ a time_t. But I see on FreeBSD,
also, it is actually a "long". So I think this fix makes sense.
-Peff
^ permalink raw reply
* Re: [RFC/PATCH 0/2] New 'stage' command
From: Felipe Contreras @ 2009-04-06 19:13 UTC (permalink / raw)
To: Junio C Hamano
Cc: David Kågedal, git, David Aguilar, Sverre Rabbelier,
markus.heidelberg
In-Reply-To: <7vy6ud4otd.fsf@gitster.siamese.dyndns.org>
On Mon, Apr 6, 2009 at 9:30 PM, Junio C Hamano <gitster@pobox.com> wrote:
> David Kågedal <davidk@lysator.liu.se> writes:
>
>> What do you mean? This was a suggestion for how git diff should
>> work. I fail to see how you would need a WORKTREEANDTHEINDEX there.
>
> You are talking only about "git diff". I am talking about the whole git
> suite, because you have to worry about how such a proposal would affect
> other parts of the UI.
How do currently do you something like this:
git diff HEAD^..STAGE
You can't.
This is not an issue for any other git commands, that's why --stage,
--cache, --index make sense for _other_ commands, not 'git diff'.
--
Felipe Contreras
^ permalink raw reply
* Re: [RFC/PATCH 0/2] New 'stage' command
From: Björn Steinbrink @ 2009-04-06 19:25 UTC (permalink / raw)
To: Felipe Contreras
Cc: Junio C Hamano, David Kågedal, git, David Aguilar,
Sverre Rabbelier, markus.heidelberg
In-Reply-To: <94a0d4530904061213pabd87aj9db577aaa231945c@mail.gmail.com>
On 2009.04.06 22:13:26 +0300, Felipe Contreras wrote:
> On Mon, Apr 6, 2009 at 9:30 PM, Junio C Hamano <gitster@pobox.com> wrote:
> > David Kågedal <davidk@lysator.liu.se> writes:
> >
> >> What do you mean? This was a suggestion for how git diff should
> >> work. I fail to see how you would need a WORKTREEANDTHEINDEX there.
> >
> > You are talking only about "git diff". I am talking about the whole git
> > suite, because you have to worry about how such a proposal would affect
> > other parts of the UI.
>
> How do currently do you something like this:
> git diff HEAD^..STAGE
git diff --cached HEAD^
The "hard" (and pretty weird) one would be "git diff STAGE..HEAD^",
which is:
git diff -R --cached HEAD^
Björn
^ permalink raw reply
* Re: Broken umlaut in my name, again
From: Björn Steinbrink @ 2009-04-06 19:28 UTC (permalink / raw)
To: Jeff King; +Cc: Marius Storm-Olsen, Junio C Hamano, git
In-Reply-To: <20090406164732.GA11724@sigill.intra.peff.net>
On 2009.04.06 12:47:33 -0400, Jeff King wrote:
> On Mon, Apr 06, 2009 at 01:46:18PM +0200, Björn Steinbrink wrote:
>
> > On 2009.03.31 17:30:39 +0200, Björn Steinbrink wrote:
> > > While it makes no sense to map some email address to an empty one, doing
> > > things the other way around can be useful. For example when using
> > > filter-branch with an env-filter that employs a mailmap to fix up an
> > > import that created such broken commits with empty email addresses.
> > >
> > > Signed-off-by: Björn Steinbrink <B.Steinbrink@gmx.de>
> >
> > The umlaut (ö) in my name is broken in the commit that made it into
> > git.git --> 5288dd58356e53d61e2b3804fc7d8d23c3a46ab3
>
> The mail you sent that presumably became 5288dd58 looks fine (both the
> >From and body are properly marked as iso8859-1), and "git am" applies it
> correctly here. I wonder if Junio did something unusual while applying.
Hm, ok, so I take it that it wasn't me who broke things. Then I'm
already happy. I don't care much about my name being messed up, but just
wanted to make sure that it wasn't my fault.
Thanks,
Björn
^ permalink raw reply
* Re: git diff bug?
From: Matthieu Moy @ 2009-04-06 19:32 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jeff King, David Abrahams, git
In-Reply-To: <7vskkl64yu.fsf@gitster.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> Matthieu Moy <Matthieu.Moy@imag.fr> writes:
>
>> Jeff King <peff@peff.net> writes:
>>
>>> But the latter two lines are about preference: "here is how _I_ would
>>> like to generate diffs for el files".
>>
>> ... and they are commands to be executed. If they were in the
>> repository, and propagated with clone, then doing
>>
>> git clone git://some.git/repo
>> cd repo
>> git diff
>>
>> would execute arbitrary commands, which wouldn't be acceptable for
>> security reasons.
>
> Other configuration variables have such security implications, but diff
> hunk header bit doesn't. You are a bit overly cautious in this particular
> case.
Oops, right, I was thinking of other parameters in the same section of
the config file. Thanks for correcting.
--
Matthieu
^ permalink raw reply
* [PATCH] git-gui: fix use of undeclared variable diff_empty_count
From: Joerg Bornemann @ 2009-04-06 19:59 UTC (permalink / raw)
To: git
Commit 584fa9cc introduced the global variable diff_empty_count, which
is used in diff.tcl. This variable wasn't declared anywhere which
resulted in an ugly error message box instead of the intended
informative message.
Signed-off-by: Joerg Bornemann <joerg.bornemann@web.de>
---
git-gui.sh | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/git-gui.sh b/git-gui.sh
index e4a9230..46b056f 100755
--- a/git-gui.sh
+++ b/git-gui.sh
@@ -1131,6 +1131,7 @@ set current_diff_path {}
set is_3way_diff 0
set is_conflict_diff 0
set selected_commit_type new
+set diff_empty_count 0
set nullid "0000000000000000000000000000000000000000"
set nullid2 "0000000000000000000000000000000000000001"
--
1.6.0.2.1172.ga5ed0
^ permalink raw reply related
* Re: [PATCH 0/3] git remote update: Check args and fallback to remotes
From: Jeff King @ 2009-04-06 20:18 UTC (permalink / raw)
To: Finn Arne Gangstad; +Cc: git, gitster
In-Reply-To: <1239025262-16960-1-git-send-email-finnag@pvv.org>
On Mon, Apr 06, 2009 at 03:40:59PM +0200, Finn Arne Gangstad wrote:
> This series is on top of next.
>
> git remote update <non-existing> would previously silently do nothing.
> With this patch series, it will (with 1/3) error out when non-existing groups
> are given, and with 2/3 & 3/3 it will use a remote if a group cannot be found.
Great, this was on my todo list so I am happy that procrastination saved
me some work. :)
The patches look fine to me, except that there are no tests. The patch
below adds a "remote groups" test script. There is a slight bit of
overlap with the update tests from t5505, but I don't think it is a
problem.
It is intended to be applied before your series. Your 1/3 would switch
t5506.3 from expect_failure to expect_success, and 3/3 would switch
t5506.6 from failure to success.
-- >8 --
Subject: [PATCH] add tests for remote groups
This tries to systematically cover existing behavior, and
also mark some expect_failure cases for desired behavior.
Signed-off-by: Jeff King <peff@peff.net>
---
t/t5506-remote-groups.sh | 81 ++++++++++++++++++++++++++++++++++++++++++++++
1 files changed, 81 insertions(+), 0 deletions(-)
create mode 100755 t/t5506-remote-groups.sh
diff --git a/t/t5506-remote-groups.sh b/t/t5506-remote-groups.sh
new file mode 100755
index 0000000..6653a9c
--- /dev/null
+++ b/t/t5506-remote-groups.sh
@@ -0,0 +1,81 @@
+#!/bin/sh
+
+test_description='git remote group handling'
+. ./test-lib.sh
+
+mark() {
+ echo "$1" >mark
+}
+
+update_repo() {
+ (cd $1 &&
+ echo content >>file &&
+ git add file &&
+ git commit -F ../mark)
+}
+
+update_repos() {
+ update_repo one $1 &&
+ update_repo two $1
+}
+
+repo_fetched() {
+ if test "`git log -1 --pretty=format:%s $1 --`" = "`cat mark`"; then
+ echo >&2 "repo was fetched: $1"
+ return 0
+ fi
+ echo >&2 "repo was not fetched: $1"
+ return 1
+}
+
+test_expect_success 'setup' '
+ mkdir one && (cd one && git init) &&
+ mkdir two && (cd two && git init) &&
+ git remote add -m master one one &&
+ git remote add -m master two two
+'
+
+test_expect_success 'no group updates all' '
+ mark update-all &&
+ update_repos &&
+ git remote update &&
+ repo_fetched one &&
+ repo_fetched two
+'
+
+test_expect_failure 'nonexistant group produces error' '
+ mark nonexistant &&
+ update_repos &&
+ test_must_fail git remote update nonexistant &&
+ ! repo_fetched one &&
+ ! repo_fetched two
+'
+
+test_expect_success 'updating group updates all members' '
+ mark group-all &&
+ update_repos &&
+ git config --add remotes.all one &&
+ git config --add remotes.all two &&
+ git remote update all &&
+ repo_fetched one &&
+ repo_fetched two
+'
+
+test_expect_success 'updating group does not update non-members' '
+ mark group-some &&
+ update_repos &&
+ git config --add remotes.some one &&
+ git remote update some &&
+ repo_fetched one &&
+ ! repo_fetched two
+'
+
+test_expect_failure 'updating remote name updates that remote' '
+ mark remote-name &&
+ update_repos &&
+ git remote update one &&
+ repo_fetched one &&
+ ! repo_fetched two
+'
+
+test_done
--
1.6.2.2.585.g1e067
^ permalink raw reply related
* [PATCH] git-svn: add fetch --parent option
From: Jason Merrill @ 2009-04-06 20:37 UTC (permalink / raw)
To: git
[-- Attachment #1: Type: text/plain, Size: 0 bytes --]
[-- Attachment #2: 0001-git-svn-add-fetch-parent-option.patch --]
[-- Type: text/x-patch, Size: 2481 bytes --]
Signed-off-by: Jason Merrill <jason@redhat.com>
---
rebase fetches only the SVN parent of the current HEAD; it should
be possible to do that with fetch as well, for instance to support
rebasing with stg rebase rather than git rebase.
Documentation/git-svn.txt | 3 +++
git-svn.perl | 18 ++++++++++++++----
2 files changed, 17 insertions(+), 4 deletions(-)
diff --git a/Documentation/git-svn.txt b/Documentation/git-svn.txt
index b7b1af8..85b2c8d 100644
--- a/Documentation/git-svn.txt
+++ b/Documentation/git-svn.txt
@@ -97,6 +97,9 @@ COMMANDS
makes 'git-log' (even without --date=local) show the same times
that `svn log` would in the local timezone.
+--parent;;
+ Fetch only from the SVN parent of the current HEAD.
+
This doesn't interfere with interoperating with the Subversion
repository you cloned from, but if you wish for your local Git
repository to be able to interoperate with someone else's local Git
diff --git a/git-svn.perl b/git-svn.perl
index d919798..cb718b8 100755
--- a/git-svn.perl
+++ b/git-svn.perl
@@ -63,7 +63,7 @@ $sha1_short = qr/[a-f\d]{4,40}/;
my ($_stdin, $_help, $_edit,
$_message, $_file,
$_template, $_shared,
- $_version, $_fetch_all, $_no_rebase,
+ $_version, $_fetch_all, $_no_rebase, $_fetch_parent,
$_merge, $_strategy, $_dry_run, $_local,
$_prefix, $_no_checkout, $_url, $_verbose,
$_git_format, $_commit_url, $_tag);
@@ -112,6 +112,7 @@ my %cmd = (
fetch => [ \&cmd_fetch, "Download new revisions from SVN",
{ 'revision|r=s' => \$_revision,
'fetch-all|all' => \$_fetch_all,
+ 'parent|p' => \$_fetch_parent,
%fc_opts } ],
clone => [ \&cmd_clone, "Initialize and fetch revisions",
{ 'revision|r=s' => \$_revision,
@@ -381,12 +382,21 @@ sub cmd_fetch {
}
my ($remote) = @_;
if (@_ > 1) {
- die "Usage: $0 fetch [--all] [svn-remote]\n";
+ die "Usage: $0 fetch [--all] [--parent] [svn-remote]\n";
}
- $remote ||= $Git::SVN::default_repo_id;
- if ($_fetch_all) {
+ if ($_fetch_parent) {
+ my ($url, $rev, $uuid, $gs) = working_head_info('HEAD');
+ unless ($gs) {
+ die "Unable to determine upstream SVN information from ",
+ "working tree history\n";
+ }
+ # just fetch, don't checkout.
+ $_no_checkout = 'true';
+ $_fetch_all ? $gs->fetch_all : $gs->fetch;
+ } elsif ($_fetch_all) {
cmd_multi_fetch();
} else {
+ $remote ||= $Git::SVN::default_repo_id;
Git::SVN::fetch_all($remote, Git::SVN::read_all_remotes());
}
}
--
1.6.2.2
^ permalink raw reply related
* [PATCH 2/2] git-checkout.txt: clarify that <branch> applies when no path is given.
From: Matthieu Moy @ 2009-04-06 20:45 UTC (permalink / raw)
To: gitster, git; +Cc: Matthieu Moy
In-Reply-To: <1239050722-1227-1-git-send-email-Matthieu.Moy@imag.fr>
Otherwise, the sentence "Defaults to HEAD." can be mis-read to mean
that "git checkout -- hello.c" checks-out from HEAD.
Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr>
---
This may be a bit too verbose, but I've been biten by this (reading
the doc not carrefully enough, I really thought git checkout would
take HEAD, then I thought it was actually a documentation bug, and
then I realized I miss-read). This patch would have saved me time. But
if other disagree, I won't fight ;-).
Documentation/git-checkout.txt | 9 +++++++--
1 files changed, 7 insertions(+), 2 deletions(-)
diff --git a/Documentation/git-checkout.txt b/Documentation/git-checkout.txt
index 0b5485b..58bf508 100644
--- a/Documentation/git-checkout.txt
+++ b/Documentation/git-checkout.txt
@@ -126,9 +126,14 @@ the conflicted merge in the specified paths.
<new_branch>::
Name for the new branch.
+<tree-ish>::
+ Tree to checkout from (when path are given). If not specified,
+ the index will be used.
+
<branch>::
- Branch to checkout; may be any object ID that resolves to a
- commit. Defaults to HEAD.
+ Branch to checkout (when no path are given); may be any object
+ ID that resolves to a commit. Defaults to HEAD.
+
+
When this parameter names a non-branch (but still a valid commit object),
your HEAD becomes 'detached'.
--
1.6.2.1.427.g061ea
^ permalink raw reply related
* [PATCH 1/2] git-checkout.txt: fix incorrect statement about HEAD and index
From: Matthieu Moy @ 2009-04-06 20:45 UTC (permalink / raw)
To: gitster, git; +Cc: Matthieu Moy
The command "git checkout" checks out from the index by default, not
HEAD (the introducing comment were correct, but the detailled
explanation added below were not).
Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr>
---
Documentation/git-checkout.txt | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/Documentation/git-checkout.txt b/Documentation/git-checkout.txt
index 1a6c19e..0b5485b 100644
--- a/Documentation/git-checkout.txt
+++ b/Documentation/git-checkout.txt
@@ -191,7 +191,7 @@ $ git checkout hello.c <3>
+
<1> switch branch
<2> take a file out of another commit
-<3> restore hello.c from HEAD of current branch
+<3> restore hello.c from the index
+
If you have an unfortunate branch that is named `hello.c`, this
step would be confused as an instruction to switch to that branch.
--
1.6.2.1.427.g061ea
^ permalink raw reply related
* Re: [RFC/PATCH 0/2] New 'stage' command
From: Matthieu Moy @ 2009-04-06 20:49 UTC (permalink / raw)
To: Junio C Hamano
Cc: David Kågedal, git, David Aguilar, Sverre Rabbelier,
markus.heidelberg, Felipe Contreras
In-Reply-To: <7vy6ud4otd.fsf@gitster.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> - there are three distinct kinds of states: a committed state, the state
> in the index (aka "what you have staged so far to the index"), and the
> state in your work tree.
>
> - many commands understand that you want to operate on and/or inspect
> states in one or more of these states. They default to what is often
> used (e.g. "git diff" compares the index and the work tree, "git grep"
> looks in the work tree, "git apply" patches the work tree [*1*]), but
> you can tell them to use different entities via options and arguments.
>
> How does it help understanding any of the above to introduce STAGE?
For the first, if there are three kinds of states, I would find it
natural to have three kinds of ways to talk about these states.
Sure, it doesn't change the second, since it makes things more
explicit, it doesn't make them more concise.
> - when you want to work with the index, you say --cached;
But that doesn't apply to "git diff". Both "git diff" and "git diff
--cached" work with the index. "git diff" works with the index and work
tree, while "git diff --cached" work with the index and HEAD.
> - when you want to work with both the index and the work tree at the
> same time, you say --index.
... which is everything but intuitive. The option name doesn't tell
the user what the command is doing. First thing is that with Git, the
user has to learn 3 words for one concept (index, cache, staging
area). And then, he has to learn that although people use "index" and
"cache" as synomyms, --index and --cached have different meanings.
And that one can also have a --cache, and that it's possible to have a
--stage too, but with different meaning.
I can understand the historical reasons, but I think finding a way to
get rid of this historical terminology mess should be encourraged.
> - for all commands, working with work tree is the default, so there is
> no --work-tree option (we could add one, if you really want).
Except "git checkout", which takes the index by default, and
a commit if specified. It makes sense since checking-out from the
working tree doesn't make sense, but it is a special case, and
learning the general rules you give doesn't tell the user what "git
checkout" does.
Except "git ls-files", too. And I may have missed some.
See, you complain about special cases with the proposal, but the
current UI _has_ tons of special cases like this.
> and the STAGE would work something like this:
>
> - when you want to work with a committed state (or more in general,
> with a tree-ish), you give the name of the commit;
It's not just "I want to work with". It's also about the role of the
things you want to work with.
"git diff WORKTREE STAGE" would mean "diff from the worktree to the
staging area", while "git diff STAGE WORKTREE" would mean the other
way around.
> Think. What does "git log STAGE" mean? Can you explain why it does not
> make any sense?
It could make sense. Actually, gitk does show the work-tree and the
index in a way similar to commits. Fundamentally, I don't see a
difference between "git log" and "gitk" except that gitk is graphical.
Sure, STAGE and WORKTREE cannot have a commit message, and hardly have
an author, but I could very well imagine "git log --stat WORKTREE"
showing roughly what "git diff --stat; git diff --stat --cached; git
log --stat HEAD" does today. I don't know how usefull this would be,
but I wouldn't say it doesn't make sense either.
--
Matthieu
^ permalink raw reply
* Re: Running 'git pull' from an unnamed branch
From: Markus Heidelberg @ 2009-04-06 21:05 UTC (permalink / raw)
To: Björn Steinbrink; +Cc: Reece Dunn, Junio C Hamano, Git List
In-Reply-To: <20090406100305.GD20356@atjola.homenet>
Björn Steinbrink, 06.04.2009:
> Maybe:
> You asked me to pull without telling me which branch you want to merge
> with and as you have no branch checked out, I cannot look for any
> defaults to use.
Hmm, let's prove this.
> Please name which branch you want to merge on the
> command line and try again
Set the config options:
$ git config branch..remote origin
$ git config branch..merge refs/heads/master
Verify them:
$ git config branch..remote
origin
$ git config branch..merge
refs/heads/master
Fine, the unnamed branch is set up properly for git-pull.
It _has_ to work.
$ git checkout origin/master~1
Note: moving to "origin/master" which isn't a local branch
If you want to create a new branch from this checkout, you may do so
(now or later) by using -b with the checkout command again. Example:
git checkout -b <new_branch_name>
HEAD is now at fbdc056... Merge branch 'jc/name-branch'
Never mind. I can ignore this message, I don't need a real branch.
git-pull will work, since I set up defaults for the unnamed branch
properly.
$ git pull
You asked me to pull without telling me which branch you
want to merge with, and 'branch..merge' in
your configuration file does not tell me either. Please
name which branch you want to merge on the command line and
try again (e.g. 'git pull <repository> <refspec>').
See git-pull(1) for details on the refspec.
If you often merge with the same branch, you may want to
configure the following variables in your configuration
file:
branch..remote = <nickname>
branch..merge = <remote-ref>
remote.<nickname>.url = <url>
remote.<nickname>.fetch = <refspec>
See git-config(1) for details.
Hey, above I've made sure, that branch..remote and branch..merge were
set up properly.
Damn :)
^ permalink raw reply
* [PATCH] git-pull.sh: better warning message for "git pull" on detached head.
From: Matthieu Moy @ 2009-04-06 21:14 UTC (permalink / raw)
To: gitster, git; +Cc: Matthieu Moy
Otherwise, git complains about not finding a branch to pull from in
'branch..merge', which is hardly understandable.
Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr>
---
git-pull.sh | 43 ++++++++++++++++++++++++++-----------------
1 files changed, 26 insertions(+), 17 deletions(-)
diff --git a/git-pull.sh b/git-pull.sh
index 8a26763..ab29a9e 100755
--- a/git-pull.sh
+++ b/git-pull.sh
@@ -90,23 +90,32 @@ error_on_no_merge_candidates () {
curr_branch=${curr_branch#refs/heads/}
- echo "You asked me to pull without telling me which branch you"
- echo "want to merge with, and 'branch.${curr_branch}.merge' in"
- echo "your configuration file does not tell me either. Please"
- echo "name which branch you want to merge on the command line and"
- echo "try again (e.g. 'git pull <repository> <refspec>')."
- echo "See git-pull(1) for details on the refspec."
- echo
- echo "If you often merge with the same branch, you may want to"
- echo "configure the following variables in your configuration"
- echo "file:"
- echo
- echo " branch.${curr_branch}.remote = <nickname>"
- echo " branch.${curr_branch}.merge = <remote-ref>"
- echo " remote.<nickname>.url = <url>"
- echo " remote.<nickname>.fetch = <refspec>"
- echo
- echo "See git-config(1) for details."
+ if [ -z "$curr_branch" ]; then
+ echo "You asked me to pull without telling me which branch you want"
+ echo "to merge with, and you are on a detached HEAD, so I cannot"
+ echo "know from 'branch.<branchname>.merge' in your configuration"
+ echo "file. Please name which branch you want to merge on the command"
+ echo "line and try again (e.g. 'git pull <repository> <refspec>')."
+ echo "See git-pull(1) for details on the refspec."
+ else
+ echo "You asked me to pull without telling me which branch you"
+ echo "want to merge with, and 'branch.${curr_branch}.merge' in"
+ echo "your configuration file does not tell me either. Please"
+ echo "name which branch you want to merge on the command line and"
+ echo "try again (e.g. 'git pull <repository> <refspec>')."
+ echo "See git-pull(1) for details on the refspec."
+ echo
+ echo "If you often merge with the same branch, you may want to"
+ echo "configure the following variables in your configuration"
+ echo "file:"
+ echo
+ echo " branch.${curr_branch}.remote = <nickname>"
+ echo " branch.${curr_branch}.merge = <remote-ref>"
+ echo " remote.<nickname>.url = <url>"
+ echo " remote.<nickname>.fetch = <refspec>"
+ echo
+ echo "See git-config(1) for details."
+ fi
exit 1
}
--
1.6.2.2.449.g92961.dirty
^ permalink raw reply related
* Re: [question] how can i verify whether a local branch is tracking a remote branch?
From: Jeff King @ 2009-04-06 21:25 UTC (permalink / raw)
To: Paolo Ciarrocchi; +Cc: git
In-Reply-To: <4d8e3fd30904060130l985b0a5x331d215ca6106fd4@mail.gmail.com>
On Mon, Apr 06, 2009 at 10:30:21AM +0200, Paolo Ciarrocchi wrote:
> I often act like a GIT "evangelist" trying to help friends and
> colleagues in starting using GIT and one of the "complaint" I'm
> getting is that people expect to get this information out of the
> branch command.
>
> I mean something like:
> $ git branch
> * foo <-> origin/foo
>
> What do you think?
Ah. Well, if you just want it for human consumption, that is much
easier. :) That information is already shown by "git status":
$ git status
# On branch next
# Your branch is ahead of 'origin/next' by 8 commits.
...
"git branch -v" is already looking at the information, but it
prints only the "ahead/behind" summary. E.g.,:
$ git branch -v
bar 1e0672d [behind 5] some commit
* baz dccc1cd [ahead 1, behind 3] other commit
foo 787d5a8 [ahead 1] another commit
master a0e632e actual upstream master
It would be pretty trivial to make it do something fancier. The
(extremely rough) patch below shows the tracking branch when
double-verbosity is given:
$ git branch -vv
* next 2d44318 [origin/next: ahead 9] branch -vv wip
So the questions are:
- is this worth it? The verbose information is already available via
git status, but only for the current branch.
- should it be the default with "-v", or require "-vv"? It take up a
bit of screen real estate, which is already in short supply for
"branch -v"
- in both the "status" and "branch" cases, we show nothing if they
are equivalent. I guess you would want to see
* next 2d44318 [origin/next] branch -vv wip
or
* next 2d44318 [origin/next: uptodate] branch -vv wip
-Peff
^ 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