* Re: [PATCH/RFC 1/3] send-pack: track errors for each ref
From: Jeff King @ 2007-11-13 22:30 UTC (permalink / raw)
To: Alex Riesen; +Cc: git, Junio C Hamano, Pierre Habouzit, Daniel Barkalow
In-Reply-To: <20071113190447.GB3268@steel.home>
On Tue, Nov 13, 2007 at 08:04:47PM +0100, Alex Riesen wrote:
> > - unsigned char force;
> > - unsigned char merge;
> > + unsigned char force : 1;
> > + unsigned char merge : 1;
> > + unsigned char nonff : 1;
>
> unsigned char fastforward : 1; ? ffwd?
I agree it is a little funny to have a negative flag, but it is the
exceptional case to be nonff, so I think it makes the code flow a little
better (you would just be asking for !ref->fastforward all the time). I
am fine with a more readable name.
> > + unsigned char deletion : 1;
> > + enum {
> > + REF_STATUS_NONE = 0,
> > + REF_STATUS_OK,
> > + REF_STATUS_NONFF,
>
> isn't it a duplication of nonff?
No. The nonff flag is "is this push a non-fast forward". The
REF_STATUS_NONFF state is "we didn't push because this is a nonff case".
So you can have nonff = 1 and status = REF_STATUS_OK, which means that
the push was forced (either by ->force, or args.force).
So perhaps a better name is REF_STATUS_REJECT_NONFF (or something longer
if NONFF is too non-obvious).
An alternative is that the deletion and nonff flags can be folded into
the status. But then checking for "is everything OK" becomes
non-obvious (it's something like REF_STATUS_NONFF_FORCED ||
REF_STATUS_DELETION_OK || REF_STATUS_PUSH_OK). I tried it that way and
found the code is a bit more readable by pulling those features away
from status (so status is "did we succeed, or did we fail, and if the
latter, for what reason?").
-Peff
^ permalink raw reply
* Re: [Newbie] How to *actually* get rid of remote tracking branch?
From: Andreas Ericsson @ 2007-11-13 22:33 UTC (permalink / raw)
To: Steffen Prohaska; +Cc: Jakub Narebski, Sergei Organov, git
In-Reply-To: <473A027E.5000107@op5.se>
Andreas Ericsson wrote:
> Steffen Prohaska wrote:
>>
>> BTW, what's the right name for this type of branch.
>> I found "tracking branch", "remote tracking branch", and
>> "remote-tracking branch" in the manual. The glossary only
>> mentions "tracking branch". Or is it a "tracked remote branch"
>> as the output of "git remote show" suggests. I remember,
>> there was a lengthy discussion on this issue. Does someone
>> remember the conclusion?
>>
>
> It seems we agreed to disagree. However, a "tracked remote branch"
> is definitely not in your local repo. I think remote-tracking branch
> grammatically is the most correct, as that's the only non-ambiguous
> form (remote tracking branch might mean "remote tracking-branch" or
> "remote-tracking branch"). It's also the only form that works when
> used with "local" in front of it. "Tracked remote branch" will
> always be a "remote branch", no matter how you prefix it.
>
> I hate that part of git nomenclature with a passion. It's ambiguous
> at best and, as a consequence, downright wrong for some uses.
>
I confess myself corrected. The Documentation/glossary.txt file doesn't
mention them at all. It does however describe "tracking branch", and
mentions "Pull: " refspecs in the same sentence, indicating that that
particular description is a leftover from the pre-1.5 era.
I've got half a patch ready to change all occurrences of anything but
"remote-tracking branch" to that self-same description. This is what
I've got in Documentation/glossary.txt so far:
[[def_remote_tracking_branch]]remote-tracking branch:
A "remote-tracking branch" is a branch set up to track the
state of a branch in a remote repository which the user has named.
These branches follow exactly the same rules as the branches which
reside in the remote repository, except that they are manipulated
by `git fetch` instead of `git push`. That is, they can only be
updated if the update would result in a
<<def_fastforward,fast forward>>, or if the user supplies the
'--force' option.
They cannot be checked out or committed to by users, but serve
solely as local reference-pointers to their corresponding branches
in the remote repository.
The most common example of a remote-tracking branch is origin/master.
It's a bit long-winded. Anyone got any improvements?
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: [Newbie] How to *actually* get rid of remote tracking branch?
From: Jakub Narebski @ 2007-11-13 22:42 UTC (permalink / raw)
To: Andreas Ericsson; +Cc: Steffen Prohaska, Sergei Organov, git
In-Reply-To: <473A262B.4010205@op5.se>
Andreas Ericsson wrote:
> This is what I've got in Documentation/glossary.txt so far:
>
> [[def_remote_tracking_branch]]remote-tracking branch:
> A "remote-tracking branch" is a branch set up to track the
> state of a branch in a remote repository which the user has named.
> These branches follow exactly the same rules as the branches which
> reside in the remote repository, except that they are manipulated
> by `git fetch` instead of `git push`. That is, they can only be
> updated if the update would result in a
> <<def_fastforward,fast forward>>, or if the user supplies the
> '--force' option.
> They cannot be checked out or committed to by users, but serve
> solely as local reference-pointers to their corresponding branches
> in the remote repository.
> The most common example of a remote-tracking branch is origin/master.
If user supplies '--force' option, ur uses '+<src>:<dst>' refspec
('+<remote branch>:<remote-tracking branch>').
> It's a bit long-winded. Anyone got any improvements?
Long winded is good. Well, long is good.
I would add that remote-tracking branches reside in refs/remotes/<remote>.
I would skip the part about `git push`, and just say that they are
updated on fetch (`git fetch` or `git pull`).
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: git-clean won't read global ignore
From: Pierre Habouzit @ 2007-11-13 22:50 UTC (permalink / raw)
To: shunichi fuji; +Cc: git
In-Reply-To: <30046e3b0711131349h51d253d5n4e5649bde36dc36f@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 719 bytes --]
On Tue, Nov 13, 2007 at 09:49:00PM +0000, shunichi fuji wrote:
> hi, i setup git to use with eclipse through global excludesfile config.
> git-status report just ignore files, but git-clean deleted ignore files.
>
> ----
> $ git-config -l
> core.excludesfile=/home/pal/.gitignore
>
> $ cat /home/pal/.gitignore
> # ignore for eclipse
> ..project
> ..cproject
>
> $ git-status
> # On branch master
> nothing to commit (working directory clean)
>
> $ git-clean
> Removing .project
.project is not ..project right ?
--
·O· Pierre Habouzit
··O madcoder@debian.org
OOO http://www.madism.org
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: Git and Scmbug integration
From: David Symonds @ 2007-11-13 23:00 UTC (permalink / raw)
To: Kristis Makris; +Cc: git, scmbug-users
In-Reply-To: <1194980792.4106.6.camel@localhost>
On Nov 14, 2007 6:06 AM, Kristis Makris <kristis.makris@asu.edu> wrote:
> Hello,
>
> I've been working on adding Git support in Scmbug, a system that
> integrates software configuration management with bug-tracking. I've run
> across what seem to be limitations in the Git hooks mechanism (at least
> in version 1.5.1.3). In particular:
>
>
> (1)
>
> http://bugzilla.mkgnu.net/show_bug.cgi?id=991
>
> There's no hook that will trigger when a tag is applied.
I believe the 'update' hook is run when the tag is pushed.
> (2)
>
> http://bugzilla.mkgnu.net/show_bug.cgi?id=992
>
> Git does not offer metadata describing a change on the commit trigger
>
> The commit trigger seems to be "post-commit" but it supplies no arguments. The
> "update" trigger supplies a lot of information but that's only triggered when
> changes are published to a remote repository.
Isn't this some kind of centralised bug-tracking system anyway? It
would be nice, I see, for the 'commit' hook to take, say, the commit
SHA-1 hash as a parameter.
Dave.
^ permalink raw reply
* [PATCH] Improved and extended t5404
From: Alex Riesen @ 2007-11-13 23:02 UTC (permalink / raw)
To: git; +Cc: Jeff King, Junio C Hamano
In-Reply-To: <20071113194909.GD3268@steel.home>
Ignore exit code of git push in t5404, as it is not relevant for the
test: it already checks whether the references updated correctly.
Signed-off-by: Alex Riesen <raa.lkml@gmail.com>
---
This one is on top of what is in next. It also include the check for
deleting remote braches I sent before. Regarding this one: if a remote
branch is deleted, shouldn't the matching tracking branch be removed
as well? The code in master seem to do that.
t/t5404-tracking-branches.sh | 29 ++++++++++++++++++++++++++---
1 files changed, 26 insertions(+), 3 deletions(-)
diff --git a/t/t5404-tracking-branches.sh b/t/t5404-tracking-branches.sh
index 20718d4..a51bbdc 100755
--- a/t/t5404-tracking-branches.sh
+++ b/t/t5404-tracking-branches.sh
@@ -10,6 +10,7 @@ test_expect_success 'setup' '
git commit -m 1 &&
git branch b1 &&
git branch b2 &&
+ git branch b3 &&
git clone . aa &&
git checkout b1 &&
echo b1 >>file &&
@@ -19,10 +20,13 @@ test_expect_success 'setup' '
git commit -a -m b2
'
+start_dir="$(pwd)"
+
test_expect_success 'check tracking branches updated correctly after push' '
cd aa &&
b1=$(git rev-parse origin/b1) &&
b2=$(git rev-parse origin/b2) &&
+ b3=$(git rev-parse origin/b3) &&
git checkout -b b1 origin/b1 &&
echo aa-b1 >>file &&
git commit -a -m aa-b1 &&
@@ -32,9 +36,28 @@ test_expect_success 'check tracking branches updated correctly after push' '
git checkout master &&
echo aa-master >>file &&
git commit -a -m aa-master &&
- git push &&
- test "$(git rev-parse origin/b1)" = "$b1" &&
- test "$(git rev-parse origin/b2)" = "$b2"
+ {
+ git push
+ test "$(git rev-parse origin/b1)" = "$b1" &&
+ test "$(git rev-parse origin/b2)" = "$b2" &&
+ test "$(git rev-parse origin/b3)" = "$b3" &&
+ test "$(git rev-parse origin/master)" = \
+ "$(git rev-parse master)"
+ }
+'
+
+test_expect_success 'delete remote branch' '
+ git push origin :refs/heads/b3
+ {
+ git rev-parse origin/b3
+ test $? != 0 || \
+ say "Hmm... Maybe tracking ref should be deleted?"
+ } &&
+ cd "$start_dir" &&
+ {
+ git rev-parse refs/heads/b3
+ test $? != 0
+ }
'
test_done
^ permalink raw reply related
* Re: [Newbie] How to *actually* get rid of remote tracking branch?
From: J. Bruce Fields @ 2007-11-13 23:05 UTC (permalink / raw)
To: Andreas Ericsson; +Cc: Steffen Prohaska, Jakub Narebski, Sergei Organov, git
In-Reply-To: <473A262B.4010205@op5.se>
On Tue, Nov 13, 2007 at 11:33:15PM +0100, Andreas Ericsson wrote:
> Andreas Ericsson wrote:
>> Steffen Prohaska wrote:
>>>
>>> BTW, what's the right name for this type of branch.
>>> I found "tracking branch", "remote tracking branch", and
>>> "remote-tracking branch" in the manual. The glossary only
>>> mentions "tracking branch". Or is it a "tracked remote branch"
>>> as the output of "git remote show" suggests. I remember,
>>> there was a lengthy discussion on this issue. Does someone
>>> remember the conclusion?
>>>
>>
>> It seems we agreed to disagree. However, a "tracked remote branch"
>> is definitely not in your local repo. I think remote-tracking branch
>> grammatically is the most correct, as that's the only non-ambiguous
>> form (remote tracking branch might mean "remote tracking-branch" or
>> "remote-tracking branch"). It's also the only form that works when
>> used with "local" in front of it. "Tracked remote branch" will
>> always be a "remote branch", no matter how you prefix it.
>>
>> I hate that part of git nomenclature with a passion. It's ambiguous
>> at best and, as a consequence, downright wrong for some uses.
>>
>
> I confess myself corrected. The Documentation/glossary.txt file doesn't
> mention them at all. It does however describe "tracking branch", and
> mentions "Pull: " refspecs in the same sentence, indicating that that
> particular description is a leftover from the pre-1.5 era.
>
> I've got half a patch ready to change all occurrences of anything but
> "remote-tracking branch" to that self-same description. This is what
> I've got in Documentation/glossary.txt so far:
>
> [[def_remote_tracking_branch]]remote-tracking branch:
> A "remote-tracking branch" is a branch set up to track the
> state of a branch in a remote repository which the user has named.
> These branches follow exactly the same rules as the branches which
> reside in the remote repository, except that they are manipulated
> by `git fetch` instead of `git push`. That is, they can only be
> updated if the update would result in a <<def_fastforward,fast
> forward>>, or if the user supplies the '--force' option.
This is a little confusing--by default fetch does force updates.
--b.
> They cannot
> be checked out or committed to by users, but serve
> solely as local reference-pointers to their corresponding branches
> in the remote repository.
> The most common example of a remote-tracking branch is origin/master.
>
>
> It's a bit long-winded. Anyone got any improvements?
>
> --
> Andreas Ericsson andreas.ericsson@op5.se
> OP5 AB www.op5.se
> Tel: +46 8-230225 Fax: +46 8-230231
> -
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: Cloning empty repositories, was Re: What is the idea for bare repositories?
From: David Kastrup @ 2007-11-13 22:56 UTC (permalink / raw)
To: Johannes Schindelin
Cc: Nicolas Pitre, Junio C Hamano, Matthieu Moy, Bill Lear,
Jan Wielemaker, git
In-Reply-To: <Pine.LNX.4.64.0711122212540.4362@racer.site>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> If Alice and Bob clone from an empty repository, and both work on it,
> there is _no way_ that they can have a common ancestor[*]. Hence, an
> empty clone _would_ be a cause of that condition.
So where is the problem with that?
--
David Kastrup, Kriemhildstr. 15, 44793 Bochum
^ permalink raw reply
* Re: Integrating with hooks
From: Jakub Narebski @ 2007-11-13 23:07 UTC (permalink / raw)
To: git
In-Reply-To: <20071113173721.GI25282@penguin.codegnome.org>
[Cc: Todd A. Jacobs <nospam@codegnome.org>, git@vger.kernel.org]
Todd A. Jacobs wrote:
> I've created some bash functions which handle tagging some files with
> revision information, but even after reading the git manual I'm not
> really sure how to integrate them so that they remove revision expansion
> before each check-in (to avoid cluttering the repository with keyword
> substitutions), and add them back (with the current commit info) after
> each commit.
>
> These are the functions:
[...]
> How do I hook this in the way I want so that it's handled automatically?
Take a look at gitattributes(5), namely 'filter' attribute.
Although instead of implementing it "by hand", perhaps it would be
enough to use 'ident' and/or 'export-subs' attribute.
P.S. Because of the way git updates files, and git thinks about files
it is I think universally regarded to be bad idea to put in a file
any Id that depend on commit data.
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: [PATCH] Improved and extended t5404
From: Jeff King @ 2007-11-13 23:10 UTC (permalink / raw)
To: Alex Riesen; +Cc: git, Junio C Hamano
In-Reply-To: <20071113230234.GI3268@steel.home>
On Wed, Nov 14, 2007 at 12:02:34AM +0100, Alex Riesen wrote:
> This one is on top of what is in next. It also include the check for
> deleting remote braches I sent before. Regarding this one: if a remote
> branch is deleted, shouldn't the matching tracking branch be removed
> as well? The code in master seem to do that.
Yes, it should (the code in update_tracking_ref seems to handle that
case, but I haven't tested, so I may have bungled something). I am
literally walking out the door, now, though, so I will be out of touch
for at least a day.
-Peff
^ permalink raw reply
* [PATCH] Fix dependencies of parse-options test program
From: Alex Riesen @ 2007-11-13 23:16 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano, Johannes Schindelin
Signed-off-by: Alex Riesen <raa.lkml@gmail.com>
---
An old test-parse-options was breaking t0040.
Makefile | 2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/Makefile b/Makefile
index cd6d469..af827f6 100644
--- a/Makefile
+++ b/Makefile
@@ -999,6 +999,8 @@ test-date$X: date.o ctype.o
test-delta$X: diff-delta.o patch-delta.o
+test-parse-options$X: parse-options.o
+
.PRECIOUS: $(patsubst test-%$X,test-%.o,$(TEST_PROGRAMS))
test-%$X: test-%.o $(GITLIBS)
--
1.5.3.5.668.g22088
^ permalink raw reply related
* Re: [PATCH] revert/cherry-pick: allow starting from dirty work tree.
From: Johannes Schindelin @ 2007-11-13 23:37 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vd4udsv6b.fsf@gitster.siamese.dyndns.org>
Hi,
On Tue, 13 Nov 2007, Junio C Hamano wrote:
> There is no reason to forbid a dirty work tree when reverting or
> cherry-picking a change, as long as the index is clean.
>
> The scripted version used to allow it:
>
> case "$no_commit" in
> t)
> # We do not intend to commit immediately. We just want to
> # merge the differences in.
> head=$(git-write-tree) ||
> die "Your index file is unmerged."
> ;;
> *)
> head=$(git-rev-parse --verify HEAD) ||
> die "You do not have a valid HEAD"
> files=$(git-diff-index --cached --name-only $head) || exit
> if [ "$files" ]; then
> die "Dirty index: cannot $me (dirty: $files)"
> fi
> ;;
> esac
>
> but C rewrite tightened the check, probably by mistake.
Probably. Thanks.
While we're at cherry-pick: Two days ago I had to rebase in a dirty
working directory. Why? Because one of the submodules was not yet ready
to be committed to the superproject.
And you cannot easily stash away a submodule.
Now, my quick and dirty solution was to hack a GIT_IGNORE_SUBMODULES
patch:
http://repo.or.cz/w/git/mingw/4msysgit.git?a=commitdiff;h=9ef6b6bff4e368934c4262af13b0a309be19ebd4
But the more fundamental question is: should we eventually have a mode in
cherry-pick (or for that matter, apply!) which can change the submodule?
And if so, how to go about it?
I could imagine that in this case, both apply and cherry-pick should call
submodule with a to-be-created subcommand to reset the named submodule to
a given commit, given the current commit (to avoid races, just as with
update-ref <ref> <newsha1> <oldsha1>). Of course, this subcommand would
fail if the submodule's working directory is dirty.
Thoughts?
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH 2/2] git-diff: complain about >=8 consecutive spaces in initial indent
From: Josh Triplett @ 2007-11-13 23:37 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Brian Downing, dsymonds
In-Reply-To: <7vr6j95c84.fsf@gitster.siamese.dyndns.org>
[-- Attachment #1: Type: text/plain, Size: 2310 bytes --]
[CCing David Symonds, because the same comment also applies to his
patches.]
Junio C Hamano wrote:
> This introduces a new whitespace error type, "indent-with-non-tab".
> The error is about starting a line with 8 or more SP, instead of
> indenting it with a HT.
>
> This is not enabled by default, as some projects employ an
> indenting policy to use only SPs and no HTs.
>
> The kernel folks and git contributors may want to enable this
> detection with:
>
> [core]
> whitespace = indent-with-non-tab
This seems somewhat broken, whether a project uses tabs for
indentation or not. Lines can still legitimately start with many
spaces. Tab-based indentation should only use tabs to line up with
other tabs, not with characters. (Unfortunately most editors get this
wrong when indenting with tabs. I use spaces, not because I
ideologically oppose tabs, but because I can't get any editor I want
to use to do the right thing with tabs.)
My standard test case for this:
fprintf("some very long string",
arguments);
Type the first line, and press enter. A good editor should indent to
the open parenthesis. However, it should not use a tab, because it
needs to match up with the length of "fprintf(". All the editors I
know of use a tab; they just blindly replace a tab-width worth of
spaces with a tab in initial indentation.
That statement would normally appear indented in a function, so the
continuation line should have tabs up to the indentation level of the
fprintf, and then 8 spaces. An example more likely to appear at the
start of the line, where this indent-with-non-tab heuristic would flag
it:
#define macro(arg1, arg2) macro_content \
more_macro_content
Another example:
some_type function_name(arg1, arg2, argred, argblue,
argmore, argless)
Again, the indentation should use spaces if it wants to line up after
the open parenthesis, whether the project uses tabs or spaces for indentation.
(Those examples may or may not match all coding styles; some just
indent the continuation lines by a fixed number of tabs, and also
treat the first line as a continuation line to keep the indentation
consistent. Just presenting them as examples.)
- Josh Triplett
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 252 bytes --]
^ permalink raw reply
* Re: [PATCH] Fix dependencies of parse-options test program
From: Johannes Schindelin @ 2007-11-13 23:46 UTC (permalink / raw)
To: Alex Riesen; +Cc: git, Junio C Hamano
In-Reply-To: <20071113231636.GJ3268@steel.home>
Hi,
apparently I forgot to send this patch, which I thought was only relevant
in the builtin-commit branch of mine:
-- snipsnap --
[PATCH] Makefile: add correct dependencies for test-parse-options
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---
Makefile | 4 ++++
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/Makefile b/Makefile
index bda8762..2abb8da 100644
--- a/Makefile
+++ b/Makefile
@@ -996,6 +996,10 @@ test-date$X: date.o ctype.o
test-delta$X: diff-delta.o patch-delta.o
+test-parse-options$X: parse-options.o
+
+test-parse-options.o: parse-options.h
+
.PRECIOUS: $(patsubst test-%$X,test-%.o,$(TEST_PROGRAMS))
test-%$X: test-%.o $(GITLIBS)
--
1.5.3.5.1769.gc3bdd
^ permalink raw reply related
* Re: Git and Scmbug integration
From: Alex Riesen @ 2007-11-13 23:47 UTC (permalink / raw)
To: Kristis Makris; +Cc: git, scmbug-users
In-Reply-To: <1194980792.4106.6.camel@localhost>
Kristis Makris, Tue, Nov 13, 2007 20:06:32 +0100:
> http://bugzilla.mkgnu.net/show_bug.cgi?id=991
>
> There's no hook that will trigger when a tag is applied.
what for?
> http://bugzilla.mkgnu.net/show_bug.cgi?id=992
>
> Git does not offer metadata describing a change on the commit trigger
>
> The commit trigger seems to be "post-commit" but it supplies no arguments.
HEAD?
^ permalink raw reply
* Re: Git and Scmbug integration
From: David Symonds @ 2007-11-13 23:53 UTC (permalink / raw)
To: Alex Riesen; +Cc: Kristis Makris, git, scmbug-users
In-Reply-To: <20071113234722.GK3268@steel.home>
On Nov 14, 2007 10:47 AM, Alex Riesen <raa.lkml@gmail.com> wrote:
> Kristis Makris, Tue, Nov 13, 2007 20:06:32 +0100:
> > http://bugzilla.mkgnu.net/show_bug.cgi?id=991
> >
> > There's no hook that will trigger when a tag is applied.
>
> what for?
>
> > http://bugzilla.mkgnu.net/show_bug.cgi?id=992
> >
> > Git does not offer metadata describing a change on the commit trigger
> >
> > The commit trigger seems to be "post-commit" but it supplies no arguments.
>
> HEAD?
That wouldn't be particularly safe if you have a very quick succession
of commits (say, via a rebase, or automated operations) because HEAD
could be moved by the time the post-commit hook reads it.
Dave.
^ permalink raw reply
* Re: Git and Scmbug integration
From: Kristis Makris @ 2007-11-13 23:55 UTC (permalink / raw)
To: David Symonds, jnareb; +Cc: git, scmbug-users
In-Reply-To: <ee77f5c20711131500h6ee067ffv3e488ac7bde1d22c@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1771 bytes --]
On Wed, 2007-11-14 at 10:00 +1100, David Symonds wrote:
> > http://bugzilla.mkgnu.net/show_bug.cgi?id=991
> >
> > There's no hook that will trigger when a tag is applied.
>
> I believe the 'update' hook is run when the tag is pushed.
Even if that is true, there no hook that will trigger when a local tag
is applied.
> > (2)
> >
> > http://bugzilla.mkgnu.net/show_bug.cgi?id=992
> >
> > Git does not offer metadata describing a change on the commit trigger
> >
> > The commit trigger seems to be "post-commit" but it supplies no arguments. The
> > "update" trigger supplies a lot of information but that's only triggered when
> > changes are published to a remote repository.
>
> Isn't this some kind of centralised bug-tracking system anyway? It
> would be nice, I see, for the 'commit' hook to take, say, the commit
> SHA-1 hash as a parameter.
It isn't a centralized bug-tracking system necessarily. Because
different developers may used different, custom bug-tracking systems,
with custom hooks in their own local Git repositories that integrate
with only their own bug-tracking systems. And perhaps we can add the
support in the Scmbug Git frontend to integrate with a centralized
bug-tracker only on push operations if desired.
But we can't explore any of these issues, discussed in the thread below
too, unless we can extract what's needed from the hooks.
http://thread.gmane.org/gmane.comp.version-control.git/48981/focus=49011
I'd like the commit hook to provide enough information to be able to
tell which files were modified and their respective old/new version (or
perhaps their old/new SHA-1 hash). If the new SHA-1 hash can be used to
extract all that, that's ok with me. But right now there's nothing.
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: Cloning empty repositories, was Re: What is the idea for bare repositories?
From: Johannes Schindelin @ 2007-11-13 23:56 UTC (permalink / raw)
To: Matthieu Moy
Cc: Brian Gernhardt, Shawn O. Pearce, Junio C Hamano, Bill Lear,
Jan Wielemaker, git
In-Reply-To: <vpqhcjp6clm.fsf@bauges.imag.fr>
Hi,
On Tue, 13 Nov 2007, Matthieu Moy wrote:
> I would just appreciate if people stopped calling me (and other users
> interested in a sane empty clone behavior) idiot because I think it
> would make sense to do it.
Oh, come on. Nobody called _you_ idiot.
But I illustrated that cloning from an empty repository makes no sense.
There is a huge difference between calling somebody an idiot on the one
side, and investing some time to help somebody who has a suboptimal
workflow on the other one.
But I fear that you took my help as a personal attack, and as a
consequence you feel insulted, and I wasted my precious time.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] Add support for # in URLs in git-remote (was: Re: [PATCH] New script: git-changelog.perl - revised)
From: Josh Triplett @ 2007-11-13 23:56 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Ronald Landheer-Cieslak, Andreas Ericsson, git
In-Reply-To: <Pine.LNX.4.64.0711031526060.4362@racer.site>
[-- Attachment #1: Type: text/plain, Size: 853 bytes --]
Johannes Schindelin wrote:
> On Sat, 3 Nov 2007, Ronald Landheer-Cieslak wrote:
>> The attached patch adds support for # signs in URLs passed to git-remote
>> add.
>
> NACK!
>
> Please be polite enough to read up on the _many_ emails on this list about
> this very subject.
>
> Not doing so just _wastes_ our time.
>
> Sorry for being so harsh, but this very subject easily cost me 20 hours in
> total(!) in the last few weeks.
Perhaps this should go in the Git FAQ at
http://git.or.cz/gitwiki/GitFaq . Does your message with Message-ID
<Pine.LNX.4.64.0710162228560.25221@racer.site>, subject "Re:
remote#branch", accurately describe the full problem with using #,
namely that refs can contain #?
Any other problems besides not having the ability to reference more
than one branch with this syntax?
- Josh Triplett
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 252 bytes --]
^ permalink raw reply
* Re: git 1.5.3.5 error over NFS (pack data corruption)
From: Bill Lear @ 2007-11-13 23:56 UTC (permalink / raw)
To: Alex Riesen; +Cc: git
In-Reply-To: <20071113214802.GH3268@steel.home>
On Tuesday, November 13, 2007 at 22:48:02 (+0100) Alex Riesen writes:
>...
>> >I extend the part you quoted. The file is opened here:
>> >...
>> >This is strange. The current git should not produce anything like
>> >this (and does not, here). ...
>>
>> You are absolutely correct. My comrade ran this with 1.5.0.1 by
>> mistake. He reran the strace with 1.5.3.5, and I have replaced
>> the tarball on my server:
>>
>> http://www.zopyra.com/~rael/git/git-trace.tar.bz2
>
>Still looks like v1.5.0.1:
>
> write(2, "fatal: ", 7) = 7
> write(2, "cannot pread pack file: No such "..., 49) = 49
Well, I just grepped for the above string in git-1.5.3.5:
% grep 'cannot pread pack file' *.c
index-pack.c: die("cannot pread pack file: %s", strerror(errno));
>I think it got worse:
>
>> write(3, "\360]|\204\205\317|\352\336C\342\316\206\334\326\201\211"..., 4096) = 4096
>> write(3, "\20\t\33if (cached_vias.insert(die,\227\17"..., 4096) = 4096
>
>The data in packs is zlib-compressed. I don't think you should be able
>to see any readable strings in them (except for "PACK" in the header).
>I believe you have a data corruption now.
>
>Does git-fsck --all say anything about that, BTW?
I'll see if we can run it...
>Besides, could you try with a git compiled with NO_PREAD?
I'll try this also.
Bill
^ permalink raw reply
* Re: [Newbie] How to *actually* get rid of remote tracking branch?
From: Junio C Hamano @ 2007-11-13 23:56 UTC (permalink / raw)
To: Andreas Ericsson; +Cc: Steffen Prohaska, Jakub Narebski, Sergei Organov, git
In-Reply-To: <473A262B.4010205@op5.se>
Andreas Ericsson <ae@op5.se> writes:
> I've got half a patch ready to change all occurrences of anything but
> "remote-tracking branch" to that self-same description. This is what
> I've got in Documentation/glossary.txt so far:
>
> [[def_remote_tracking_branch]]remote-tracking branch:
> A "remote-tracking branch" is a branch set up to track the
> state of a branch in a remote repository which the user has named.
> These branches follow exactly the same rules as the branches which
> reside in the remote repository, except that they are manipulated
> by `git fetch` instead of `git push`. That is, they can only be
> updated if the update would result in a <<def_fastforward,fast
> forward>>, or if the user supplies the '--force' option. They cannot
> be checked out or committed to by users, but serve
> solely as local reference-pointers to their corresponding branches
> in the remote repository.
> The most common example of a remote-tracking branch is origin/master.
Please try to read it as if it were an entry in a glossary.
The sentence "... follow exactly the same rules as ..." was
"Huh?" to me. "rules? what rules? the set of valid characters
in their names?"
When branch 'foo' from remote is tracked with the standard layout
(post 1.3.0) it is copied to refs/remotes/origin/foo and people
often fork their local branch refs/heads/foo to build on top.
The use of the word "corresonding" feels a bit confusing,
because you can arguably say refs/heads/foo at remote
corresopnds to refs/heads/foo in your repository.
I'd drop "These branches follow ... the '--force' option. "
from the above. The rules on how they are updated are
irrelevant, before the reader understands what they are for.
How about this?
A "remote tracking branch" remembers which commit a branch
in the remote repository was pointing at last time you
checked. It cannot be checked out or committed because its
purpose is to serve as a local reference point after you
built your own changes on top of it in your local branch
forked from it. The most common example of a remote
tracking branch is "origin/master", which tracks the
"master" branch of the "origin" remote.
BTW, when you have this data-flow (probably typical in a shared
repository workflow):
Remote repository Your repository
refs/heads/foo -------(A)------> refs/remotes/origin/foo
^ |
| (B)
| |
| V
`-------------(C)---------- refs/heads/foo
(A) "git fetch" with remote.origin.fetch configuration
set to +refs/heads/*:refs/remotes/origin/* keeps
your refs/remotes/origin/foo up-to-date with their
refs/heads/foo
(B) "git merge origin/foo" while on "foo" branch (there
are few shorthands like "git pull origin foo" while
on "foo" branch. If you say "git branch --track
foo origin/foo", then running "git pull" without
parameter while on "foo" branch).
(C) "git push origin foo".
* Everybody seems to agree that "refs/remotes/origin/foo" is
called a "remote tracking branch";
* Your refs/heads/foo follows and builds on top of 'foo' branch
at the remote. Some people errorneously call it "tracking"
but that is because we do not have a good term for it;
* There is no good name for "refs/heads/foo at the remote". We
always say "the remote branch you follow" (or "track").
^ permalink raw reply
* Re: Git and Scmbug integration
From: Kristis Makris @ 2007-11-14 0:01 UTC (permalink / raw)
To: Alex Riesen, jnareb; +Cc: git, scmbug-users
In-Reply-To: <20071113234722.GK3268@steel.home>
[-- Attachment #1: Type: text/plain, Size: 1090 bytes --]
On Wed, 2007-11-14 at 00:47 +0100, Alex Riesen wrote:
> > There's no hook that will trigger when a tag is applied.
>
> what for?
To implement the synchronous verification checks provided by Scmbug:
http://www.mkgnu.net/?q=scmbug
http://files.mkgnu.net/files/scmbug/SCMBUG_RELEASE_0-23-0/manual/html-single/manual.html#VERIFICATION-CHECKS
In particular:
(1) Convention-based labeling
http://files.mkgnu.net/files/scmbug/SCMBUG_RELEASE_0-23-0/manual/html-single/manual.html#VERIFICATION-CHECKS-CONVENTION-BASED-LABELING
(2) The capability to freeze access to certain branches
http://bugzilla.mkgnu.net/show_bug.cgi?id=859
(3) Valid product-name verification
http://files.mkgnu.net/files/scmbug/SCMBUG_RELEASE_0-23-0/manual/html-single/manual.html#VERIFICATION-CHECKS-VALID-PRODUCT-NAME
There are a lot more checks, as you can see from the manual, that are
needed on a commit trigger, rather than just a tag trigger.
A lot of people find the integration provided by Scmbug useful and some
(Jakub, back me up here) have requested support for Git.
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: Git and Scmbug integration
From: David Symonds @ 2007-11-14 0:02 UTC (permalink / raw)
To: Kristis Makris; +Cc: jnareb, git, scmbug-users
In-Reply-To: <1194998142.4106.24.camel@localhost>
On Nov 14, 2007 10:55 AM, Kristis Makris <kristis.makris@asu.edu> wrote:
> On Wed, 2007-11-14 at 10:00 +1100, David Symonds wrote:
> > > http://bugzilla.mkgnu.net/show_bug.cgi?id=991
> > >
> > > There's no hook that will trigger when a tag is applied.
> >
> > I believe the 'update' hook is run when the tag is pushed.
>
> Even if that is true, there no hook that will trigger when a local tag
> is applied.
Unannotated tags don't make a proper new object, only a ref. If you
stick to annotated tags, you'll get new objects added which, I think,
should trigger the post-commit hook.
> I'd like the commit hook to provide enough information to be able to
> tell which files were modified and their respective old/new version (or
> perhaps their old/new SHA-1 hash). If the new SHA-1 hash can be used to
> extract all that, that's ok with me. But right now there's nothing.
If you have the new commit's SHA-1, it's very simple to get the parent
commit's SHA-1 and do whatever you want. A complexity would be with
handling merges, where a commit has multiple parents. If you have a
commit SHA-1 hash, you can just "git diff --name-only <hash>^ <hash>"
to get a list of the files changed by <hash>.
Dave.
^ permalink raw reply
* Re: [PATCH] Improved and extended t5404
From: Junio C Hamano @ 2007-11-14 0:02 UTC (permalink / raw)
To: Alex Riesen; +Cc: git, Jeff King
In-Reply-To: <20071113230234.GI3268@steel.home>
Alex Riesen <raa.lkml@gmail.com> writes:
> Ignore exit code of git push in t5404, as it is not relevant for the
> test
This proposed log message solicits a "Huh? -- Since when
ignoring exit code is an improvement?" reaction. If this push
is expected to error out, then wouldn't you want to make sure it
errors out as expected? If the problem is that the exit status
is unreliable, maybe we need to make it reliable instead?
^ permalink raw reply
* Re: git 1.5.3.5 error over NFS (pack data corruption)
From: Alex Riesen @ 2007-11-14 0:02 UTC (permalink / raw)
To: Bill Lear; +Cc: git
In-Reply-To: <18234.14781.55429.671459@lisa.zopyra.com>
Bill Lear, Wed, Nov 14, 2007 00:56:45 +0100:
> On Tuesday, November 13, 2007 at 22:48:02 (+0100) Alex Riesen writes:
> >...
> >> >I extend the part you quoted. The file is opened here:
> >> >...
> >> >This is strange. The current git should not produce anything like
> >> >this (and does not, here). ...
> >>
> >> You are absolutely correct. My comrade ran this with 1.5.0.1 by
> >> mistake. He reran the strace with 1.5.3.5, and I have replaced
> >> the tarball on my server:
> >>
> >> http://www.zopyra.com/~rael/git/git-trace.tar.bz2
> >
> >Still looks like v1.5.0.1:
> >
> > write(2, "fatal: ", 7) = 7
> > write(2, "cannot pread pack file: No such "..., 49) = 49
>
> Well, I just grepped for the above string in git-1.5.3.5:
>
> % grep 'cannot pread pack file' *.c
> index-pack.c: die("cannot pread pack file: %s", strerror(errno));
oh, you should be looking for usage.c, the function report (it is
called by default die handler). The old code used to fputs("fatal:"),
the new just vfprintf's everything, so the write should look like:
write(2, "fatal: cannot pread pack file: No such "...
^ 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