* What's in git.git (Oct 2008, #03; Tue, 14)
From: Junio C Hamano @ 2008-10-14 22:08 UTC (permalink / raw)
To: git
Just trying to get my development repository back in sync with what I
received from Shawn. Thanks to everybody, I think maint is ready for
1.6.0.3.
* The 'maint' branch has these fixes since the last announcement.
Junio C Hamano (1):
Update draft release notes to 1.6.0.3
* The 'master' branch has these since the last announcement
in addition to the above.
Jeff King (1):
tests: shell negation portability fix
Junio C Hamano (1):
Update draft release notes to 1.6.1
^ permalink raw reply
* Re: [PATCH v2] Fix fetch/pull when run without --update-head-ok
From: Junio C Hamano @ 2008-10-14 22:07 UTC (permalink / raw)
To: Daniel Barkalow; +Cc: Johannes Schindelin, git, spearce
In-Reply-To: <alpine.LNX.1.00.0810141258050.19665@iabervon.org>
Daniel Barkalow <barkalow@iabervon.org> writes:
> On Tue, 14 Oct 2008, Daniel Barkalow wrote:
> ...
>> That is, it uses --update-head-ok because "git pull origin master:master"
>> will work correctly, regardless of whether the local master is
>> yet-to-be-born or not.
>
> In particular, the --update-head-ok is from b10ac50f, which is what added
> the check to prohibit fetching into the current branch otherwise, back in
> August 2005. There's never been anything preventing updating the current
> branch using "pull".
What you wrote above is correct, and it is all that is necessary to make
"pull master:master" (when 'master' is the current branch) work correctly,
in normal situations. Dscho's patch is in itself is a good thing to do,
but is not necessary when the caller gives --update-head-ok.
Nor is it sufficient. Have you tested the current "git-pull" with or
without Dscho's patch applied to "git-fetch" when 'master' is an unborn
branch? "git-pull" has this piece:
curr_head=$(git rev-parse --verify HEAD 2>/dev/null)
if test "$curr_head" != "$orig_head"
then
# The fetch involved updating the current branch.
# The working tree and the index file is still based on the
# $orig_head commit, but we are merging into $curr_head.
# First update the working tree to match $curr_head.
echo >&2 "Warning: fetch updated the current branch head."
...
fi
The above part (written by yours truly) did not care what happens when the
current branch is unborn. Back then when git-pull was originally written,
nobody was crazy enough to pull into an empty branch and expect it to
work. The code to allow that craziness (look for "initial pull" in the
same script to find a 6-line block near the end) came much later, and the
commit that added the "initial pull" support should have adjusted the
above codeblock if it really wanted to support pulling into an unborn
branch, but it forgot to do so. It also forgot to handle the case where
the originally unborn current branch was fetched into.
If we really care about is "git pull origin master:master" into an unborn
branch, I think we need the attached patch on top, and this is regardless
of Dscho's patch that tightens the check when -update-head-ok is not given.
git-pull.sh | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git c/git-pull.sh w/git-pull.sh
index 75c3610..664fe34 100755
--- c/git-pull.sh
+++ w/git-pull.sh
@@ -124,7 +124,7 @@ orig_head=$(git rev-parse --verify HEAD 2>/dev/null)
git fetch --update-head-ok "$@" || exit 1
curr_head=$(git rev-parse --verify HEAD 2>/dev/null)
-if test "$curr_head" != "$orig_head"
+if test -n "$orig_head" && test "$curr_head" != "$orig_head"
then
# The fetch involved updating the current branch.
@@ -172,7 +172,7 @@ esac
if test -z "$orig_head"
then
- git update-ref -m "initial pull" HEAD $merge_head "" &&
+ git update-ref -m "initial pull" HEAD $merge_head "$curr_head" &&
git read-tree --reset -u HEAD || exit 1
exit
fi
^ permalink raw reply related
* Re: Git and tagging hook
From: Daniel Barkalow @ 2008-10-14 21:33 UTC (permalink / raw)
To: Kristis Makris
Cc: Jan Hudec, Andreas Ericsson, Jakub Narebski, git, scmbug-users
In-Reply-To: <1224007401.4073.40.camel@localhost>
On Tue, 14 Oct 2008, Kristis Makris wrote:
> Jan, thanks for trying to clarify this for me.
>
> I am working on adding integration support of Git with bug-trackers,
> using Scmbug. There may be an argument here towards/against distributed
> bug-trackers when it comes to Git.
>
> Maybe there are things here I don't fully understand yet.
>
> On Tue, 2008-10-14 at 19:22 +0200, Jan Hudec wrote:
> > >>> Kristis Makris wrote:
> > >>>> I want the integration when I apply the tag to a local repository, NOT
> > >>>> only when I push/pull.
> >
> > Care to explain why that would ever be useful? It's local, which means that:
> > - the user can take it back without a trace it ever happened (git tag -d or
> > even git update-ref -d) and
> > - noone except the user will see it anyway, so it's not like they should
> > care either.
>
> I have two use cases:
>
> (1) A developer maintains besides his local copy a local bug-tracking
> system in which he tracks his changes. We would like to apply various
> verification policies when he commits or tags. For example, for tagging
> we wants to ensure that he tags giving consistent labels to his
> intermediate builds. e.g. as in:
>
> http://files.mkgnu.net/files/scmbug/SCMBUG_RELEASE_0-26-9/manual/html-single/manual.html#VERIFICATION-CHECKS-CONVENTION-BASED-LABELING
>
> Or he may want to have Git force him to also supply a log message along
> with a tag, so that he can remember later more accurately why a tag was
> created and what it really captures. Even if Git (or other SCM systems)
> don't natively support log messages on tags. Scmbug plans to implement
> this.
Git supports using tags for a variety of other purposes in addition to the
traditional ones (for example, you can tag a version as "the changes I'm
sure of" or "the version I know is broken"; furthermore, your regression
testing system could give you a tag that tags the commit you sent for
testing with the test results). The bug tracker integration should only
care about the traditional use (providing a persistant, human-recognizable
name for a revision). Actually, it would probably be best, for integration
with git, to skip tags entirely, and use the hash. With projects using
git, it is routine to know that the bug was found in some particular
flawed commit that didn't get tagged.
> http://bugzilla.mkgnu.net/show_bug.cgi?id=219
>
>
> (2) I would like to apply various verification policies when work from a
> local repository is finally merged with the central repository. I assume
> there can/will be a central repository, and there is one "software
> product" that is being released somewhere among the many copies.
>
> When its time to merge local changes to a central repository, the
> verification policies may deem that changes are not acceptable to be
> merged with the mainline. e.g. because log messages are too short,
> commits during the merge are issued against bugs in "a central"
> bugtracker that are either closed, assigned to someone else, or just
> plain wrong bug-numbers that belong to other products:
>
> http://files.mkgnu.net/files/scmbug/SCMBUG_RELEASE_0-26-9/manual/html-single/manual.html#VERIFICATION-CHECKS-VALID-LOG-MESSAGE-SIZE
> http://files.mkgnu.net/files/scmbug/SCMBUG_RELEASE_0-26-9/manual/html-single/manual.html#VERIFICATION-CHECKS-OPEN-BUG-STATE
> http://files.mkgnu.net/files/scmbug/SCMBUG_RELEASE_0-26-9/manual/html-single/manual.html#VERIFICATION-CHECKS-VALID-BUG-OWNER
> http://files.mkgnu.net/files/scmbug/SCMBUG_RELEASE_0-26-9/manual/html-single/manual.html#VERIFICATION-CHECKS-VALID-PRODUCT-NAME
>
> (I'm not very clear whether this is how Git works)
>
> Does someone get to write-up a brand new log comment during the merge
> and the merge totally disregards older log comments ? My understanding
> is that log comments on the local copy are preserved (and will need to
> be mapped to bug-numbers in the central bug-tracker.
In general, you send to the central repository, and it rejects you if (a)
a merge would be required; you have to fetch and merge in your local
repository; or (b) there's something wrong with the changes you're making.
For (a), you make a merge commit and try again; the new commit has a log
message, but the old commits retain their log messages. For (b), you make
a different set of commits that does follow the required policy. "git
rebase -i origin/master" will guide you through this process. In general,
you do this before sharing your changes with anybody else, or at least
before sharing them with anyone who cares about the end result, so that
other people see nice commits. It's also possible to rearrange the changes
you made in a bunch of local commits into a series that looks nice and
makes sense and follows the project rules, when your initial work had you
introducing a lot of silly mistakes and fixing them.
> Thus the local verification policies may need to have already been
> configured to comply with future verification policies of the central
> repository. Else (perhaps considerable) mappings/adjustments will be
> needed during the push to the central copy.
In general, there's a ton of adjustment needed between working on a
project and pushing to the central location in any system. With git,
however, version control may be used locally before these adjustments are
made, and this provides a huge benefit in terms of being able to prepare
commits just how they should be, and in terms of being able to avoid
losing work during the adjustments.
In general, you want to have a local understanding of the central
repository rules, so that you can do this mapping while you don't have
network, but there's no reason to prevent saving your work before it
conforms.
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* Problem with CRLF line endings and colored diff
From: Jean-Luc Herren @ 2008-10-14 21:13 UTC (permalink / raw)
To: Git List
Hello list!
I'm using CRLF line endings on the files of a project and I'm
running into odd output from 'git diff'. Here are the steps to
reproduce:
git init
echo -e 'line1\r' > file
git add file
echo -e 'line2\r' > file
PAGER='less -R' git diff --color
The output looks like this:
diff --git a/file b/file
index 495181c..a1413a4 100644
--- a/file
+++ b/file
@@ -1 +1 @@
-line1
+line2^M
Note the trailing ^M on the '+' line. After examining that line
it seems it's a bug in git, as that line really looks like this
(<...> denoting ANSI sequences or CR/LF):
<GREEN FOREGROUND>+<RESET><GREEN FOREGROUND>
line2<RESET><RED BACKGROUND><CR><RESET><LF>
The CR and the LF are not after each other, there's an ANSI
sequence in between (because the CR is being highlighted as white
space). That confuses 'less'. The '-' line above does not do
that and thus doesn't have this problem. It also doesn't reset
the color between the '-' and the line:
<RED FOREGROUND>-line1<RESET><CR><LF>
I tried poking around the code, but the diff machinery is more
complex than could be quickly grasped, so I'll let someone that
knows it already have a look.
Using git 1.6.0.2, but have the same problem with HEAD.
jlh
^ permalink raw reply
* [PATCH] gitk: bind Key-Return to create on new branch dialog
From: Richard Quirk @ 2008-10-14 20:53 UTC (permalink / raw)
To: paulus; +Cc: git, Richard Quirk
The Return key can now be used as well as pressing the Create button
from the dialog box that is shown when selecting "Create new branch".
Signed-off-by: Richard Quirk <richard.quirk@gmail.com>
---
gitk | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/gitk b/gitk
index 2eaa2ae..81d6c80 100755
--- a/gitk
+++ b/gitk
@@ -7590,6 +7590,7 @@ proc mkbranch {} {
grid $top.id $top.sha1 -sticky w
label $top.nlab -text [mc "Name:"]
entry $top.name -width 40
+ bind $top.name <Key-Return> "[list mkbrgo $top]"
grid $top.nlab $top.name -sticky w
frame $top.buts
button $top.buts.go -text [mc "Create"] -command [list mkbrgo $top]
--
1.6.0.6.gc667
^ permalink raw reply related
* Re: Git and tagging hook
From: Andreas Ericsson @ 2008-10-14 20:49 UTC (permalink / raw)
To: Kristis Makris; +Cc: Jan Hudec, Jakub Narebski, git, scmbug-users
In-Reply-To: <1224007401.4073.40.camel@localhost>
Kristis Makris wrote:
> Jan, thanks for trying to clarify this for me.
>
> I am working on adding integration support of Git with bug-trackers,
> using Scmbug. There may be an argument here towards/against distributed
> bug-trackers when it comes to Git.
>
> Maybe there are things here I don't fully understand yet.
>
> On Tue, 2008-10-14 at 19:22 +0200, Jan Hudec wrote:
>>>>> Kristis Makris wrote:
>>>>>> I want the integration when I apply the tag to a local repository, NOT
>>>>>> only when I push/pull.
>> Care to explain why that would ever be useful? It's local, which means that:
>> - the user can take it back without a trace it ever happened (git tag -d or
>> even git update-ref -d) and
>> - noone except the user will see it anyway, so it's not like they should
>> care either.
>
> I have two use cases:
>
> (1) A developer maintains besides his local copy a local bug-tracking
> system in which he tracks his changes. We would like to apply various
> verification policies when he commits or tags. For example, for tagging
> we wants to ensure that he tags giving consistent labels to his
> intermediate builds. e.g. as in:
>
> http://files.mkgnu.net/files/scmbug/SCMBUG_RELEASE_0-26-9/manual/html-single/manual.html#VERIFICATION-CHECKS-CONVENTION-BASED-LABELING
>
I'm guessing releases will be cut from some sort of central or official
repository anyway, so I fail to see why tags would need to be verified
at create-time rather than at push-time. It's sometimes useful to create
tags for ones own personal use, and commit messages that are no more than
"wip", without signoff or anything. This needs to be implemented at the
receiving end. Not at each developers end.
> Or he may want to have Git force him to also supply a log message along
> with a tag, so that he can remember later more accurately why a tag was
> created and what it really captures. Even if Git (or other SCM systems)
> don't natively support log messages on tags. Scmbug plans to implement
> this.
>
> http://bugzilla.mkgnu.net/show_bug.cgi?id=219
>
git supports optional log-messages on tags. There are two different kinds
of tags in git; "annotated" (with logmessage) and "lightweight" (without
logmessage). It's up to each user which sort of tag to create. Using the
example update hook, lightweight tags are by default not allowed to be
pushed to a repository.
>
> (2) I would like to apply various verification policies when work from a
> local repository is finally merged with the central repository. I assume
> there can/will be a central repository, and there is one "software
> product" that is being released somewhere among the many copies.
>
Merges happen in the local repository. When a merge is pushed to the
"release" repo, you can analyze the merges and all commits that the sender
is trying to push.
> When its time to merge local changes to a central repository, the
> verification policies may deem that changes are not acceptable to be
> merged with the mainline. e.g. because log messages are too short,
> commits during the merge are issued against bugs in "a central"
> bugtracker that are either closed, assigned to someone else, or just
> plain wrong bug-numbers that belong to other products:
>
That sort of work belongs in the update hook then. Cautious users, or
release engineers, might want to enable pre-merge hooks and whatnot.
> http://files.mkgnu.net/files/scmbug/SCMBUG_RELEASE_0-26-9/manual/html-single/manual.html#VERIFICATION-CHECKS-VALID-LOG-MESSAGE-SIZE
> http://files.mkgnu.net/files/scmbug/SCMBUG_RELEASE_0-26-9/manual/html-single/manual.html#VERIFICATION-CHECKS-OPEN-BUG-STATE
> http://files.mkgnu.net/files/scmbug/SCMBUG_RELEASE_0-26-9/manual/html-single/manual.html#VERIFICATION-CHECKS-VALID-BUG-OWNER
> http://files.mkgnu.net/files/scmbug/SCMBUG_RELEASE_0-26-9/manual/html-single/manual.html#VERIFICATION-CHECKS-VALID-PRODUCT-NAME
>
> (I'm not very clear whether this is how Git works)
>
> Does someone get to write-up a brand new log comment during the merge
> and the merge totally disregards older log comments ? My understanding
> is that log comments on the local copy are preserved (and will need to
> be mapped to bug-numbers in the central bug-tracker.
>
Try and find out. It would have been faster than writing that paragraph ;-)
> Thus the local verification policies may need to have already been
> configured to comply with future verification policies of the central
> repository. Else (perhaps considerable) mappings/adjustments will be
> needed during the push to the central copy.
>
>> Besides, you don't need git tag to create a tag in git, so the hook wouldn't
>> really be guaranteed anyway (I mean, just like the commit hook is not -- you
>> can still commit by calling write-tree, commit-tree and update-ref and avoid
>> the hook).
>
> I'm assuming someone who follows the recommended avenue of using Git
> wants the advantages of hooks. I certainly can't force people that
> bypass hooks to use them.
>
Hooks can also be disabled, and they aren't enabled by default. They're also
not cloned along with a repository (that would be stupid, as I most certainly
don't want the email-on-commit hooks we're using at work), so installing
said hooks would still be a manual job done by each developer that wishes to
comply with the policy you're outlining. I have a hard time seeing how that
can benefit the open community.
>> For integration with issue tracker, the local tag is neither final, nor
>> useful to anybody except the user who did it until it hits the central
>> repository. And working on the central repository directly does not seem like
>> a good idea either.
>
> The local tag is useful to the local user and his local bug-tracker. He
> can have tag operations intercepted so that the tag names show up as
> versions in his bug-tracker. In this way he can keep track of which bugs
> still exist or have recently been introduced/discovered to his local
> copy, before he decides to publish his polished, final version:
>
> http://files.mkgnu.net/files/scmbug/SCMBUG_RELEASE_0-26-9/manual/html-single/manual.html#TAGS
>
> And his "local bug-tracker" may be reachable on the web and useful by
> others that take a peek at the users progress (even fetching it with
> Git).
>
Relying on hooks on the developer side is fragile and *will* break.
It will break often, and it will break badly. Any sort of
"this-commit-is-releasable" verification simply *has* to be done in
the release repository. Otherwise you'll be limiting how devs can
use the scm while gaining absolutely nothing (since it has to be
done in the release repo too for those times when the dev forgot
to enable hook X in a newly cloned repository).
I still haven't figured out what the over-all plan is, so my
advice and warnings may be counter-productive at worst. However,
http://files.mkgnu.net/files/scmbug/doc/latest_manual/html-multi/x113.html
just doesn't make sense to me. It's invalidated by clear and
concise commit messages (which aren't always there, but education
is nine times out of ten better than enforcement; It's better
to understand *why* 6x7 = 42 rather than just knowing that it's
so).
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: [PATCH] remote.c: correct the check for a leading '/' in a remote name
From: Daniel Barkalow @ 2008-10-14 20:35 UTC (permalink / raw)
To: Brandon Casey; +Cc: Git Mailing List
In-Reply-To: <J-KL1Cgc2b78Lced5uBNDhP0MHdg91do73K_0waicFQYbDZHjYkocw@cipher.nrlssc.navy.mil>
On Tue, 14 Oct 2008, Brandon Casey wrote:
> This test is supposed to disallow remote entries in the config file of the
> form:
>
> [remote "/foobar"]
> ...
>
> The leading slash in '/foobar' is not acceptable.
>
> Instead it was incorrectly testing that the subkey had no leading '/', which
> had no effect since the subkey pointer was made to point at a '.' in the
> preceding lines.
>
> Signed-off-by: Brandon Casey <casey@nrlssc.navy.mil>
Good catch; looks like I was checking for a mistake that nobody ever
makes, but it's still good to check.
Acked-by: Daniel Barkalow <barkalow@iabervon.org>
^ permalink raw reply
* [PATCH] remote.c: correct the check for a leading '/' in a remote name
From: Brandon Casey @ 2008-10-14 20:30 UTC (permalink / raw)
To: Git Mailing List; +Cc: Daniel Barkalow
This test is supposed to disallow remote entries in the config file of the
form:
[remote "/foobar"]
...
The leading slash in '/foobar' is not acceptable.
Instead it was incorrectly testing that the subkey had no leading '/', which
had no effect since the subkey pointer was made to point at a '.' in the
preceding lines.
Signed-off-by: Brandon Casey <casey@nrlssc.navy.mil>
---
I stumbled across this code which looks like a mistake.
This patch seems like the correct fix.
-brandon
remote.c | 9 +++++----
1 files changed, 5 insertions(+), 4 deletions(-)
diff --git a/remote.c b/remote.c
index d5efadd..8a04066 100644
--- a/remote.c
+++ b/remote.c
@@ -341,13 +341,14 @@ static int handle_config(const char *key, const char *value, void *cb)
if (prefixcmp(key, "remote."))
return 0;
name = key + 7;
+ if (*name == '/') {
+ warning("Config remote shorthand cannot begin with '/': %s",
+ name);
+ return 0;
+ }
subkey = strrchr(name, '.');
if (!subkey)
return error("Config with no key for remote %s", name);
- if (*subkey == '/') {
- warning("Config remote shorthand cannot begin with '/': %s", name);
- return 0;
- }
remote = make_remote(name, subkey - name);
if (!strcmp(subkey, ".mirror"))
remote->mirror = git_config_bool(key, value);
--
1.6.0.2.468.gd5b83
^ permalink raw reply related
* [PATCH] t4018-diff-funcname: add objective-c xfuncname pattern to syntax test
From: Brandon Casey @ 2008-10-14 20:22 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Git Mailing List
Signed-off-by: Brandon Casey <casey@nrlssc.navy.mil>
---
t/t4018-diff-funcname.sh | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/t/t4018-diff-funcname.sh b/t/t4018-diff-funcname.sh
index 520e095..0320e19 100755
--- a/t/t4018-diff-funcname.sh
+++ b/t/t4018-diff-funcname.sh
@@ -32,7 +32,7 @@ EOF
sed 's/beer\\/beer,\\/' < Beer.java > Beer-correct.java
-builtin_patterns="bibtex html java pascal php python ruby tex"
+builtin_patterns="bibtex html java objc pascal php python ruby tex"
for p in $builtin_patterns
do
test_expect_success "builtin $p pattern compiles" '
--
1.6.0.2.468.gd5b83
^ permalink raw reply related
* Re: retrieving a diff from git
From: Matthieu Moy @ 2008-10-14 17:56 UTC (permalink / raw)
To: Folkert van Heusden; +Cc: Alex Riesen, git
In-Reply-To: <20081014172048.GW22427@vanheusden.com>
Folkert van Heusden <folkert@vanheusden.com> writes:
>> but ... Have you considered using Git for that?
>
> and check out the whole tree using Git? I did consider but then I would
> not have all bells and whistles to generate a Debian kernel package.
You can probably clone the Kernel repository, generate a huge diff
with git diff, and apply it to your Debian tree with patch or
git apply, but if the patch serie is not based on your tree, this
won't help with conflicts.
--
Matthieu
^ permalink raw reply
* Re: Git and tagging hook
From: Kristis Makris @ 2008-10-14 18:03 UTC (permalink / raw)
To: Jan Hudec
Cc: Andreas Ericsson, scmbug-users-G8y9j4K4DsPiwOUmbS1EgQ,
git-u79uwXL29TY76Z2rM5mHXA, Jakub Narebski
In-Reply-To: <20081014172227.GB6931-hYs7FtC5zV+YSD4dQj0czg@public.gmane.org>
[-- Attachment #1.1: Type: text/plain, Size: 4668 bytes --]
Jan, thanks for trying to clarify this for me.
I am working on adding integration support of Git with bug-trackers,
using Scmbug. There may be an argument here towards/against distributed
bug-trackers when it comes to Git.
Maybe there are things here I don't fully understand yet.
On Tue, 2008-10-14 at 19:22 +0200, Jan Hudec wrote:
> >>> Kristis Makris wrote:
> >>>> I want the integration when I apply the tag to a local repository, NOT
> >>>> only when I push/pull.
>
> Care to explain why that would ever be useful? It's local, which means that:
> - the user can take it back without a trace it ever happened (git tag -d or
> even git update-ref -d) and
> - noone except the user will see it anyway, so it's not like they should
> care either.
I have two use cases:
(1) A developer maintains besides his local copy a local bug-tracking
system in which he tracks his changes. We would like to apply various
verification policies when he commits or tags. For example, for tagging
we wants to ensure that he tags giving consistent labels to his
intermediate builds. e.g. as in:
http://files.mkgnu.net/files/scmbug/SCMBUG_RELEASE_0-26-9/manual/html-single/manual.html#VERIFICATION-CHECKS-CONVENTION-BASED-LABELING
Or he may want to have Git force him to also supply a log message along
with a tag, so that he can remember later more accurately why a tag was
created and what it really captures. Even if Git (or other SCM systems)
don't natively support log messages on tags. Scmbug plans to implement
this.
http://bugzilla.mkgnu.net/show_bug.cgi?id=219
(2) I would like to apply various verification policies when work from a
local repository is finally merged with the central repository. I assume
there can/will be a central repository, and there is one "software
product" that is being released somewhere among the many copies.
When its time to merge local changes to a central repository, the
verification policies may deem that changes are not acceptable to be
merged with the mainline. e.g. because log messages are too short,
commits during the merge are issued against bugs in "a central"
bugtracker that are either closed, assigned to someone else, or just
plain wrong bug-numbers that belong to other products:
http://files.mkgnu.net/files/scmbug/SCMBUG_RELEASE_0-26-9/manual/html-single/manual.html#VERIFICATION-CHECKS-VALID-LOG-MESSAGE-SIZE
http://files.mkgnu.net/files/scmbug/SCMBUG_RELEASE_0-26-9/manual/html-single/manual.html#VERIFICATION-CHECKS-OPEN-BUG-STATE
http://files.mkgnu.net/files/scmbug/SCMBUG_RELEASE_0-26-9/manual/html-single/manual.html#VERIFICATION-CHECKS-VALID-BUG-OWNER
http://files.mkgnu.net/files/scmbug/SCMBUG_RELEASE_0-26-9/manual/html-single/manual.html#VERIFICATION-CHECKS-VALID-PRODUCT-NAME
(I'm not very clear whether this is how Git works)
Does someone get to write-up a brand new log comment during the merge
and the merge totally disregards older log comments ? My understanding
is that log comments on the local copy are preserved (and will need to
be mapped to bug-numbers in the central bug-tracker.
Thus the local verification policies may need to have already been
configured to comply with future verification policies of the central
repository. Else (perhaps considerable) mappings/adjustments will be
needed during the push to the central copy.
> Besides, you don't need git tag to create a tag in git, so the hook wouldn't
> really be guaranteed anyway (I mean, just like the commit hook is not -- you
> can still commit by calling write-tree, commit-tree and update-ref and avoid
> the hook).
I'm assuming someone who follows the recommended avenue of using Git
wants the advantages of hooks. I certainly can't force people that
bypass hooks to use them.
> For integration with issue tracker, the local tag is neither final, nor
> useful to anybody except the user who did it until it hits the central
> repository. And working on the central repository directly does not seem like
> a good idea either.
The local tag is useful to the local user and his local bug-tracker. He
can have tag operations intercepted so that the tag names show up as
versions in his bug-tracker. In this way he can keep track of which bugs
still exist or have recently been introduced/discovered to his local
copy, before he decides to publish his polished, final version:
http://files.mkgnu.net/files/scmbug/SCMBUG_RELEASE_0-26-9/manual/html-single/manual.html#TAGS
And his "local bug-tracker" may be reachable on the web and useful by
others that take a peek at the users progress (even fetching it with
Git).
[-- Attachment #1.2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
[-- Attachment #2: Type: text/plain, Size: 188 bytes --]
_______________________________________________
scmbug-users mailing list
scmbug-users-G8y9j4K4DsPiwOUmbS1EgQ@public.gmane.org
http://lists.mkgnu.net/cgi-bin/mailman/listinfo/scmbug-users
^ permalink raw reply
* Re: retrieving a diff from git
From: Alex Riesen @ 2008-10-14 17:29 UTC (permalink / raw)
To: Folkert van Heusden; +Cc: git
In-Reply-To: <20081014172048.GW22427@vanheusden.com>
2008/10/14 Folkert van Heusden <folkert@vanheusden.com>:
>> > How would I retrieve the 'kmemcheck' patches from git for the 2.6.27
>> > kernel? I browsed to the url
>> > http://git.kernel.org/?p=linux%2Fkernel%2Fgit%2Fx86%2Flinux-2.6-tip.git...
>> > but could not find how to retrieve that diff.
>> Well, you can of course just click on "commitdiff" (and "raw" afterwords)
>> for every commit,
>
> Hmmm the outcome does not apply cleanly to 2.6.27.
That's because the patches are not based on 2.6.27.
>> but ... Have you considered using Git for that?
>
> and check out the whole tree using Git? I did consider but then I would
> not have all bells and whistles to generate a Debian kernel package.
I afraid, that in this particular case you have no other choice, but ask Ingo.
^ permalink raw reply
* Re: Git and tagging hook
From: Jan Hudec @ 2008-10-14 17:22 UTC (permalink / raw)
To: Andreas Ericsson; +Cc: Kristis Makris, Jakub Narebski, git
In-Reply-To: <48ECF072.3000506@op5.se>
On Wed, Oct 08, 2008 at 19:40:02 +0200, Andreas Ericsson wrote:
> Kristis Makris wrote:
>> On Tue, 2008-10-07 at 19:28 +0200, Jakub Narebski wrote:
>>> Kristis Makris wrote:
>>>> I want the integration when I apply the tag to a local repository, NOT
>>>> only when I push/pull.
Care to explain why that would ever be useful? It's local, which means that:
- the user can take it back without a trace it ever happened (git tag -d or
even git update-ref -d) and
- noone except the user will see it anyway, so it's not like they should
care either.
Besides, you don't need git tag to create a tag in git, so the hook wouldn't
really be guaranteed anyway (I mean, just like the commit hook is not -- you
can still commit by calling write-tree, commit-tree and update-ref and avoid
the hook).
>>> If you are talking about taging locally, you can simply make an alias
>>> or do something after tagging. Search archives for description when
>>> it is worth to add a hook, and when it is not.
>>
>> I am looking for a guarantee that is better than casually saying
>> "simply". I will be providing the integration work to users that may not
>> be as comfortable with making aliases.
>>
>> I still don't see why a hook on local tagging is not available. Is it
>> possible to add support in Git for such a hook ? Both pre-tag and
>> post-tag.
>
> Because noone's ever needed one before. If aliases can't do what you
> want, write a patch to support it and hope Junio accepts it. It's really
> quite straight-forward. Make sure you read Documentation/SubmittingPatches
> before you send it.
>
> Note though that use of tags on the developer's side will still be up
> to the developer and not something you can force through other means
> than policy or convention.
Being possible was never a reason to add features to git and the less it was
a reason to add hooks. And there does not seem to be a use-case that would
clearly benefit from having such hooks, or at least none was shown on the
list so far.
For integration with issue tracker, the local tag is neither final, nor
useful to anybody except the user who did it until it hits the central
repository. And working on the central repository directly does not seem like
a good idea either.
--
Jan 'Bulb' Hudec <bulb@ucw.cz>
^ permalink raw reply
* Re: retrieving a diff from git
From: Folkert van Heusden @ 2008-10-14 17:20 UTC (permalink / raw)
To: Alex Riesen; +Cc: git
In-Reply-To: <81b0412b0810141001w46227afam70123237025a2d4d@mail.gmail.com>
> > How would I retrieve the 'kmemcheck' patches from git for the 2.6.27
> > kernel? I browsed to the url
> > http://git.kernel.org/?p=linux%2Fkernel%2Fgit%2Fx86%2Flinux-2.6-tip.git...
> > but could not find how to retrieve that diff.
> Well, you can of course just click on "commitdiff" (and "raw" afterwords)
> for every commit,
Hmmm the outcome does not apply cleanly to 2.6.27.
> but ... Have you considered using Git for that?
and check out the whole tree using Git? I did consider but then I would
not have all bells and whistles to generate a Debian kernel package.
Folkert van Heusden
--
MultiTail is a versatile tool for watching logfiles and output of
commands. Filtering, coloring, merging, diff-view, etc.
http://www.vanheusden.com/multitail/
----------------------------------------------------------------------
Phone: +31-6-41278122, PGP-key: 1F28D8AE, www.vanheusden.com
^ permalink raw reply
* Re: [PATCH v2] Fix fetch/pull when run without --update-head-ok
From: Daniel Barkalow @ 2008-10-14 17:02 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Junio C Hamano, git, spearce
In-Reply-To: <alpine.LNX.1.00.0810141240510.19665@iabervon.org>
On Tue, 14 Oct 2008, Daniel Barkalow wrote:
> On Tue, 14 Oct 2008, Johannes Schindelin wrote:
>
> > Hi,
> >
> > On Tue, 14 Oct 2008, Daniel Barkalow wrote:
> >
> > > On Tue, 14 Oct 2008, Johannes Schindelin wrote:
> > >
> > > > On Mon, 13 Oct 2008, Daniel Barkalow wrote:
> > > >
> > > > > On Mon, 13 Oct 2008, Johannes Schindelin wrote:
> > > > >
> > > > > > I actually understand now why the tests started failing: the
> > > > > > change from resolve_ref() to get_branch() as requested by Daniel
> > > > > > are at fault: get_branch() does not check if the branch has an
> > > > > > initial commit.
> > > > > >
> > > > > > I am actually regretting making this change. Daniel, do you agree
> > > > > > that it might be better to change back to resolve_ref(), so that
> > > > > > the initial complaint (IIRC Han-Wen git pull'ed into a freshly
> > > > > > initialized repository with that utterly bogus "git pull origin
> > > > > > master:master" line) is not re-raised?
> > > > >
> > > > > Is it, in fact, okay to fetch into the current branch if it's "yet
> > > > > to be born"? I feel like it shouldn't be, since you'll get exactly
> > > > > the same problem that you would if the branch already existed: the
> > > > > index reflects the previous state (in this case, it's empty), so git
> > > > > will show that you've staged removing all of the files, right? So
> > > > > this would make the check for --update-head-ok more strict than
> > > > > before, but I think the behavior change is correct.
> > > >
> > > > I think
> > > > http://thread.gmane.org/gmane.comp.version-control.git/31351/focus=31544
> > > > is the best link to see what Han-Wen said. Granted, it was a
> > > > misunderstanding on his part, but there have been quite a few people
> > > > with the same misunderstanding.
> > > >
> > > > So what they did was
> > > >
> > > > $ mkdir just-one-branch
> > > > $ cd just-one-branch
> > > > $ git init
> > > > $ git remote add origin <url>
> > > > $ git pull origin master:master
> > > >
> > > > And this _will_ work correctly. Except when using get_branch(NULL)
> > > > instead of the validating resolve_ref().
> > >
> > > "git pull origin master:master" invokes "git fetch" with --update-head-ok,
> >
> > Does it? You're correct. I do not like it.
>
> The reason that it runs with --update-head-ok (and the reason that
> --update-head-ok exists in the first place) is that, when you're doing a
> pull, if you fetch into the current branch, pull will identify that you've
> actually fast-forwarded the current branch and will update the working
> tree and index accordingly (which it's allowed to do because it's expected
> to perform a merge in the working tree and index).
>
> That is, it uses --update-head-ok because "git pull origin master:master"
> will work correctly, regardless of whether the local master is
> yet-to-be-born or not.
In particular, the --update-head-ok is from b10ac50f, which is what added
the check to prohibit fetching into the current branch otherwise, back in
August 2005. There's never been anything preventing updating the current
branch using "pull".
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* Re: retrieving a diff from git
From: Alex Riesen @ 2008-10-14 17:01 UTC (permalink / raw)
To: Folkert van Heusden; +Cc: git
In-Reply-To: <20081014145112.GR22427@vanheusden.com>
2008/10/14 Folkert van Heusden <folkert@vanheusden.com>:
> How would I retrieve the 'kmemcheck' patches from git for the 2.6.27
> kernel? I browsed to the url
> http://git.kernel.org/?p=linux%2Fkernel%2Fgit%2Fx86%2Flinux-2.6-tip.git...
> but could not find how to retrieve that diff.
Well, you can of course just click on "commitdiff" (and "raw" afterwords)
for every commit, but ... Have you considered using Git for that?
^ permalink raw reply
* Re: [PATCH v2] Fix fetch/pull when run without --update-head-ok
From: Daniel Barkalow @ 2008-10-14 16:52 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Junio C Hamano, git, spearce
In-Reply-To: <alpine.DEB.1.00.0810141815490.22125@pacific.mpi-cbg.de.mpi-cbg.de>
On Tue, 14 Oct 2008, Johannes Schindelin wrote:
> Hi,
>
> On Tue, 14 Oct 2008, Daniel Barkalow wrote:
>
> > On Tue, 14 Oct 2008, Johannes Schindelin wrote:
> >
> > > On Mon, 13 Oct 2008, Daniel Barkalow wrote:
> > >
> > > > On Mon, 13 Oct 2008, Johannes Schindelin wrote:
> > > >
> > > > > I actually understand now why the tests started failing: the
> > > > > change from resolve_ref() to get_branch() as requested by Daniel
> > > > > are at fault: get_branch() does not check if the branch has an
> > > > > initial commit.
> > > > >
> > > > > I am actually regretting making this change. Daniel, do you agree
> > > > > that it might be better to change back to resolve_ref(), so that
> > > > > the initial complaint (IIRC Han-Wen git pull'ed into a freshly
> > > > > initialized repository with that utterly bogus "git pull origin
> > > > > master:master" line) is not re-raised?
> > > >
> > > > Is it, in fact, okay to fetch into the current branch if it's "yet
> > > > to be born"? I feel like it shouldn't be, since you'll get exactly
> > > > the same problem that you would if the branch already existed: the
> > > > index reflects the previous state (in this case, it's empty), so git
> > > > will show that you've staged removing all of the files, right? So
> > > > this would make the check for --update-head-ok more strict than
> > > > before, but I think the behavior change is correct.
> > >
> > > I think
> > > http://thread.gmane.org/gmane.comp.version-control.git/31351/focus=31544
> > > is the best link to see what Han-Wen said. Granted, it was a
> > > misunderstanding on his part, but there have been quite a few people
> > > with the same misunderstanding.
> > >
> > > So what they did was
> > >
> > > $ mkdir just-one-branch
> > > $ cd just-one-branch
> > > $ git init
> > > $ git remote add origin <url>
> > > $ git pull origin master:master
> > >
> > > And this _will_ work correctly. Except when using get_branch(NULL)
> > > instead of the validating resolve_ref().
> >
> > "git pull origin master:master" invokes "git fetch" with --update-head-ok,
>
> Does it? You're correct. I do not like it.
The reason that it runs with --update-head-ok (and the reason that
--update-head-ok exists in the first place) is that, when you're doing a
pull, if you fetch into the current branch, pull will identify that you've
actually fast-forwarded the current branch and will update the working
tree and index accordingly (which it's allowed to do because it's expected
to perform a merge in the working tree and index).
That is, it uses --update-head-ok because "git pull origin master:master"
will work correctly, regardless of whether the local master is
yet-to-be-born or not.
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* Re: How many users of parsecvs are there?
From: Mike Ralphson @ 2008-10-14 16:51 UTC (permalink / raw)
To: Alex Bennee; +Cc: git, keithp, Johannes Schindelin
In-Reply-To: <alpine.DEB.1.00.0810141820110.22125@pacific.mpi-cbg.de.mpi-cbg.de>
On Tue, 14 Oct 2008, Alex Bennee wrote:
>
> I'm wondering how many people are there still using parsecvs to to track
> a live CVS tree?
I used it to import some problematic historical CVS projects into git.
It coped with the (probably) broken history better than cvsps did at
the time, though I had to hack it to ignore some non-standard
directives in the ,v files (deltatype, permissions etc).
At the time that was a one-off exercise, but the project which
replaced that project has now itself been cancelled and it is just
possible the original will be revived (!)
Hopefully though, the egit project would now be sufficient for us to
go forward based on the converted history in git and leave CVS behind.
Mike
^ permalink raw reply
* [PATCH] Fix mkpath abuse in dwim_ref/sha1_name.c
From: Alex Riesen @ 2008-10-14 16:23 UTC (permalink / raw)
To: Git Mailing List; +Cc: Junio C Hamano, Shawn O. Pearce
[-- Attachment #1: Type: text/plain, Size: 445 bytes --]
Otherwise the function sometimes fail to resolve obviously correct refnames,
because the string data pointed to by "ref" argument were reused.
Signed-off-by: Alex Riesen <raa.lkml@gmail.com>
---
sha1_name.c | 6 ++++--
1 files changed, 4 insertions(+), 2 deletions(-)
Frankly, I'm having hard time trying to justify _any_ use of mkpath.
It is a bug waiting to happen every time is any code between the
call site and assignment but strdup.
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-Fix-mkpath-abuse-in-sha1_name.c.patch --]
[-- Type: text/x-patch; name=0001-Fix-mkpath-abuse-in-sha1_name.c.patch, Size: 1529 bytes --]
From 052e137d4ad8687d78bb2570390ed4f6b19f7cba Mon Sep 17 00:00:00 2001
From: Alex Riesen <raa.lkml@gmail.com>
Date: Tue, 14 Oct 2008 18:14:20 +0200
Subject: [PATCH] Fix mkpath abuse in sha1_name.c
Otherwise the function sometimes fail to resolve obviously correct refnames,
because the string data pointed to by "ref" argument were reused.
Signed-off-by: Alex Riesen <raa.lkml@gmail.com>
---
sha1_name.c | 6 ++++--
1 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/sha1_name.c b/sha1_name.c
index 41b6809..b5b53bf 100644
--- a/sha1_name.c
+++ b/sha1_name.c
@@ -242,6 +242,7 @@ int dwim_ref(const char *str, int len, unsigned char *sha1, char **ref)
{
const char **p, *r;
int refs_found = 0;
+ char fullref[PATH_MAX];
*ref = NULL;
for (p = ref_rev_parse_rules; *p; p++) {
@@ -249,7 +250,8 @@ int dwim_ref(const char *str, int len, unsigned char *sha1, char **ref)
unsigned char *this_result;
this_result = refs_found ? sha1_from_ref : sha1;
- r = resolve_ref(mkpath(*p, len, str), this_result, 1, NULL);
+ snprintf(fullref, sizeof(fullref), *p, len, str);
+ r = resolve_ref(fullref, this_result, 1, NULL);
if (r) {
if (!refs_found++)
*ref = xstrdup(r);
@@ -272,7 +274,7 @@ int dwim_log(const char *str, int len, unsigned char *sha1, char **log)
char path[PATH_MAX];
const char *ref, *it;
- strcpy(path, mkpath(*p, len, str));
+ snprintf(path, sizeof(path), *p, len, str);
ref = resolve_ref(path, hash, 1, NULL);
if (!ref)
continue;
--
1.6.0.2.494.gb25da
^ permalink raw reply related
* Re: How many users of parsecvs are there?
From: Johannes Schindelin @ 2008-10-14 16:21 UTC (permalink / raw)
To: Alex Bennee; +Cc: git, keithp
In-Reply-To: <b2cdc9f30810140310l647eb2fbld3f6a1c608d029a@mail.gmail.com>
Hi,
On Tue, 14 Oct 2008, Alex Bennee wrote:
> I'm wondering how many people are there still using parsecvs to to track
> a live CVS tree?
I used it in conjunction with clonecvs at some stage, but did not need to
use parsecvs in the end, so I stayed with cvsimport.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH v2] Fix fetch/pull when run without --update-head-ok
From: Johannes Schindelin @ 2008-10-14 16:17 UTC (permalink / raw)
To: Daniel Barkalow; +Cc: Junio C Hamano, git, spearce
In-Reply-To: <alpine.LNX.1.00.0810141148010.19665@iabervon.org>
Hi,
On Tue, 14 Oct 2008, Daniel Barkalow wrote:
> On Tue, 14 Oct 2008, Johannes Schindelin wrote:
>
> > On Mon, 13 Oct 2008, Daniel Barkalow wrote:
> >
> > > On Mon, 13 Oct 2008, Johannes Schindelin wrote:
> > >
> > > > I actually understand now why the tests started failing: the
> > > > change from resolve_ref() to get_branch() as requested by Daniel
> > > > are at fault: get_branch() does not check if the branch has an
> > > > initial commit.
> > > >
> > > > I am actually regretting making this change. Daniel, do you agree
> > > > that it might be better to change back to resolve_ref(), so that
> > > > the initial complaint (IIRC Han-Wen git pull'ed into a freshly
> > > > initialized repository with that utterly bogus "git pull origin
> > > > master:master" line) is not re-raised?
> > >
> > > Is it, in fact, okay to fetch into the current branch if it's "yet
> > > to be born"? I feel like it shouldn't be, since you'll get exactly
> > > the same problem that you would if the branch already existed: the
> > > index reflects the previous state (in this case, it's empty), so git
> > > will show that you've staged removing all of the files, right? So
> > > this would make the check for --update-head-ok more strict than
> > > before, but I think the behavior change is correct.
> >
> > I think
> > http://thread.gmane.org/gmane.comp.version-control.git/31351/focus=31544
> > is the best link to see what Han-Wen said. Granted, it was a
> > misunderstanding on his part, but there have been quite a few people
> > with the same misunderstanding.
> >
> > So what they did was
> >
> > $ mkdir just-one-branch
> > $ cd just-one-branch
> > $ git init
> > $ git remote add origin <url>
> > $ git pull origin master:master
> >
> > And this _will_ work correctly. Except when using get_branch(NULL)
> > instead of the validating resolve_ref().
>
> "git pull origin master:master" invokes "git fetch" with --update-head-ok,
Does it? You're correct. I do not like it.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH v2] Fix fetch/pull when run without --update-head-ok
From: Johannes Schindelin @ 2008-10-14 16:15 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Daniel Barkalow, Junio C Hamano, git
In-Reply-To: <20081014150227.GC4856@spearce.org>
Hi,
On Tue, 14 Oct 2008, Shawn O. Pearce wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> > On Mon, 13 Oct 2008, Daniel Barkalow wrote:
> >
> > > On Mon, 13 Oct 2008, Johannes Schindelin wrote:
> > >
> > > > I actually understand now why the tests started failing: the change from
> > > > resolve_ref() to get_branch() as requested by Daniel are at fault:
> > > > get_branch() does not check if the branch has an initial commit.
> >
> > So, my vote is to revert back to resolve_ref(), even if it needs more
> > lines.
>
> Yes, I agree, resolve_ref() is the best thing to be using here,
> even if it is more code. get_branch() validates the commit and we
> don't want that. We really just want to know if the current branch
> is going to be updated, we don't care to what/why.
Actually, get_branch() does _not_ validate. Which is why it thinks that
the current branch is "master" even if there is no commit yet.
OTOH, resolve_ref() reads the SHA-1 of the ref, which fails in the case
that there has not been any commit yet.
Still, I think that it would be nice to allow "git pull origin
master:master" in a freshly initied non-bare repository, so I like
resolve_ref() better.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH v2] Fix fetch/pull when run without --update-head-ok
From: Daniel Barkalow @ 2008-10-14 16:04 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Johannes Schindelin, Junio C Hamano, git
In-Reply-To: <20081014150227.GC4856@spearce.org>
On Tue, 14 Oct 2008, Shawn O. Pearce wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> > On Mon, 13 Oct 2008, Daniel Barkalow wrote:
> >
> > > On Mon, 13 Oct 2008, Johannes Schindelin wrote:
> > >
> > > > I actually understand now why the tests started failing: the change from
> > > > resolve_ref() to get_branch() as requested by Daniel are at fault:
> > > > get_branch() does not check if the branch has an initial commit.
> >
> > So, my vote is to revert back to resolve_ref(), even if it needs more
> > lines.
>
> Yes, I agree, resolve_ref() is the best thing to be using here,
> even if it is more code. get_branch() validates the commit and we
> don't want that. We really just want to know if the current branch
> is going to be updated, we don't care to what/why.
It doesn't validate the commit; it doesn't even validate the symref. The
resolve_ref()-using code validates the symref, and I think that's an
error; we also don't care what state we'd update the current branch from.
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* Re: [PATCH v2] Fix fetch/pull when run without --update-head-ok
From: Daniel Barkalow @ 2008-10-14 15:57 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Junio C Hamano, git, spearce
In-Reply-To: <alpine.DEB.1.00.0810141145491.22125@pacific.mpi-cbg.de.mpi-cbg.de>
On Tue, 14 Oct 2008, Johannes Schindelin wrote:
> Hi,
>
> On Mon, 13 Oct 2008, Daniel Barkalow wrote:
>
> > On Mon, 13 Oct 2008, Johannes Schindelin wrote:
> >
> > > I actually understand now why the tests started failing: the change from
> > > resolve_ref() to get_branch() as requested by Daniel are at fault:
> > > get_branch() does not check if the branch has an initial commit.
> > >
> > > I am actually regretting making this change. Daniel, do you agree
> > > that it might be better to change back to resolve_ref(), so that the
> > > initial complaint (IIRC Han-Wen git pull'ed into a freshly initialized
> > > repository with that utterly bogus "git pull origin master:master"
> > > line) is not re-raised?
> >
> > Is it, in fact, okay to fetch into the current branch if it's "yet to be
> > born"? I feel like it shouldn't be, since you'll get exactly the same
> > problem that you would if the branch already existed: the index reflects
> > the previous state (in this case, it's empty), so git will show that
> > you've staged removing all of the files, right? So this would make the
> > check for --update-head-ok more strict than before, but I think the
> > behavior change is correct.
>
> I think
> http://thread.gmane.org/gmane.comp.version-control.git/31351/focus=31544
> is the best link to see what Han-Wen said. Granted, it was a
> misunderstanding on his part, but there have been quite a few people with
> the same misunderstanding.
>
> So what they did was
>
> $ mkdir just-one-branch
> $ cd just-one-branch
> $ git init
> $ git remote add origin <url>
> $ git pull origin master:master
>
> And this _will_ work correctly. Except when using get_branch(NULL)
> instead of the validating resolve_ref().
"git pull origin master:master" invokes "git fetch" with --update-head-ok,
so it doesn't matter for this case what "git fetch" does without
--update-head-ok.
The check would block:
$ git fetch origin master:master
but this also would fail to update the working directory and would leave
the index as if you're removing everything.
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* Re: EGIT compare editor
From: Shawn O. Pearce @ 2008-10-14 15:05 UTC (permalink / raw)
To: Chris Dumoulin; +Cc: git
In-Reply-To: <48F4AA33.40605@oanda.com>
Chris Dumoulin <dumoulin@oanda.com> wrote:
> I seem to have successfully installed EGIT in Eclipse 3.4.1, but I can't
> figure out how to bring up the compare editor to view diffs.
>
> I expect that after right-clicking on a changed file, I would have some
> option under "Compare With" or "Team" that would allow me to diff the
> current file against the HEAD or some other revision using the compare
> editor, but I can't seem to find any way to do this. How do I bring up
> the compare editor to view diffs?
Robin knows the Eclipse integration better than I, but we may be
missing the feature to compare the working directory revision to
the last committed revision (or the index revision).
I'm pretty sure the compare editor is available in the History view
(Team -> Show resource in History) by double clicking the file
path when a commit node is selected. But that's obviously only
historical diffs.
--
Shawn.
^ 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