* Re: [PATCH] Fix t9101 test failure caused by Subversion "auto-props"
From: Wincent Colaiuta @ 2007-11-17 13:28 UTC (permalink / raw)
To: Junio C Hamano
Cc: Björn Steinbrink, Benoit Sigoure, Git Mailing List,
Väinö Järvelä
In-Reply-To: <7vy7cxwwoo.fsf@gitster.siamese.dyndns.org>
El 17/11/2007, a las 1:19, Junio C Hamano escribió:
> Wincent Colaiuta <win@wincent.com> writes:
>
>> If a user has an "auto-prop" in his/her ~/.subversion/config file for
>> automatically setting the svn:keyword Id property on all ".c" files
>> (a reasonably common configuration in the Subversion world) then one
>> of the "svn propset" operations in the very first test would become a
>> no-op, which in turn would make the next commit a no-op.
>
> Thanks for diagnosing and fixing.
>
> I presume this fix also applies to both 'maint' and 'master',
> right?
I prepared it against master, but I believe it will apply cleanly to
maint, where it's also needed.
Cheers,
Wincent
^ permalink raw reply
* Re: [PATCH 1/3] send-pack: track errors for each ref
From: Alex Riesen @ 2007-11-17 13:34 UTC (permalink / raw)
To: Jeff King; +Cc: Junio C Hamano, git, Pierre Habouzit, Daniel Barkalow
In-Reply-To: <20071117125426.GA23186@sigill.intra.peff.net>
Jeff King, Sat, Nov 17, 2007 13:54:27 +0100:
> Instead of keeping the 'ret' variable, we instead have a
> status flag for each ref that tracks what happened to it.
> We then print the ref status after all of the refs have
> been examined.
>
> This paves the way for three improvements:
> - updating tracking refs only for non-error refs
> - incorporating remote rejection into the printed status
> - printing errors in a different order than we processed
> (e.g., consolidating non-ff errors near the end with
> a special message)
>
> Signed-off-by: Jeff King <peff@peff.net>
Acked-by: Alex Riesen <raa.lkml@gmail.com>
Still would like to see the deletion of tracing branches checked.
Like this perhaps?
diff --git a/t/t5404-tracking-branches.sh b/t/t5404-tracking-branches.sh
index 799e47e..4fe4a07 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 &&
@@ -23,6 +24,7 @@ test_expect_success 'prepare pushable branches' '
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 &&
@@ -45,4 +47,12 @@ test_expect_success 'check tracking branches not updated for failed refs' '
test "$(git rev-parse origin/b2)" = "$b2"
'
+test_expect_success 'delete remote branch' '
+ git push origin :refs/heads/b3 &&
+ {
+ git rev-parse --verify origin/b3
+ test $? != 0
+ }
+'
+
test_done
--
1.5.3.5.747.gf06543
^ permalink raw reply related
* Re: [PATCH 2/3] send-pack: check ref->status before updating tracking refs
From: Alex Riesen @ 2007-11-17 13:45 UTC (permalink / raw)
To: Jeff King; +Cc: Junio C Hamano, git, Pierre Habouzit, Daniel Barkalow
In-Reply-To: <20071117125515.GB23186@sigill.intra.peff.net>
Jeff King, Sat, Nov 17, 2007 13:55:15 +0100:
> diff --git a/t/t5404-tracking-branches.sh b/t/t5404-tracking-branches.sh
> index 799e47e..1493a92 100755
> --- a/t/t5404-tracking-branches.sh
> +++ b/t/t5404-tracking-branches.sh
> @@ -45,4 +45,9 @@ test_expect_success 'check tracking branches not updated for failed refs' '
> test "$(git rev-parse origin/b2)" = "$b2"
> '
>
> +test_expect_success 'deleted branches have their tracking branches removed' '
> + git push origin :b1 &&
> + test "$(git rev-parse origin/b1)" = "origin/b1"
> +'
> +
> test_done
Oh, missed that.
Completely-Acked-By: Alex "Sleepy" Riesen <raa.lkml@gmail.com>
^ permalink raw reply
* Re: [PATCH 2/3] send-pack: check ref->status before updating tracking refs
From: Jeff King @ 2007-11-17 13:53 UTC (permalink / raw)
To: Alex Riesen; +Cc: Junio C Hamano, git, Pierre Habouzit, Daniel Barkalow
In-Reply-To: <20071117134546.GC2716@steel.home>
On Sat, Nov 17, 2007 at 02:45:46PM +0100, Alex Riesen wrote:
> > +test_expect_success 'deleted branches have their tracking branches removed' '
> > + git push origin :b1 &&
> > + test "$(git rev-parse origin/b1)" = "origin/b1"
> > +'
> > +
> > test_done
>
> Oh, missed that.
>
> Completely-Acked-By: Alex "Sleepy" Riesen <raa.lkml@gmail.com>
Yes, I didn't put it in the first patch, because it was broken there. ;)
-Peff
^ permalink raw reply
* Re: New repo quickly corrupted
From: Robin Rosenberg @ 2007-11-17 14:13 UTC (permalink / raw)
To: Christian Couder
Cc: Andreas Ericsson, Linus Torvalds, Nicolas Pitre, Jason Sewall,
git, Junio C Hamano
In-Reply-To: <200711171353.45310.chriscool@tuxfamily.org>
lördag 17 november 2007 skrev Christian Couder:
> Le vendredi 16 novembre 2007, Andreas Ericsson a écrit :
> > Christian Couder wrote:
> > > Le jeudi 15 novembre 2007, Linus Torvalds a écrit :
> > >> On Thu, 15 Nov 2007, Nicolas Pitre wrote:
> > >>> Does "dos2unix" override file access bits? Because the object store
> > >>> is always made read-only.
> > >>
> > >> Almost all programs like that will entirely ignor the fact that
> > >> something is read-only.
> > >
> > > What if the .git/objects/ sudirectories were also read-only ?
> >
> > Then git wouldn't be able to write to it without chmod()'ing it each
> > time.
>
> Yes, but some (not manly enough) people might want the extra safety even if
> it means a performance penalty.
Those do manly enough to do run find . -exec ;)
-- robin
^ permalink raw reply
* Re: [PATCH] Rewrite some function exit paths to avoid "unreachable code" traps
From: Robin Rosenberg @ 2007-11-17 14:31 UTC (permalink / raw)
To: Alex Riesen; +Cc: Guido Ostkamp, Junio C Hamano, git
In-Reply-To: <20071117122317.GA2716@steel.home>
lördag 17 november 2007 skrev Alex Riesen:
> Robin Rosenberg, Sat, Nov 17, 2007 11:39:32 +0100:
> > lördag 17 november 2007 skrev Alex Riesen:
> > > Noticed by Guido Ostkamp for Sun's Workshop cc.
> > >
> > > Originally-by: Guido Ostkamp <git@ostkamp.fastmail.fm>
> > > Signed-off-by: Alex Riesen <raa.lkml@gmail.com>
> > > ---
> > > Guido Ostkamp, Fri, Nov 16, 2007 23:52:01 +0100:
> > > >
> > > > What about the xdiff/xdiffi.c problem that should also be solved?
> > > >
> > >
> >
> > Please... This just looks bad. I'm sure we'll have fixup patches on the list
> > to fix those gotos.
> >
> > Do we support any such stupid compiler that requires a dummy goto?
>
> It is more for the compilers we don't know about yet.
>
> Userspace programming, especially with intent to be portable, often
> means supporting *bugs* of the platform where it happens.
*If* it happens. We do not workaround every hypothetical compiler bug or every hypotetical
buggy compiler. Compilers we don't know about does not "exist", expect for the perfectly
confirming ones, but they aren't buggy.
It seems the return in utf8.c was introduced by mistake and Junio has made his decision now.
-- robin
^ permalink raw reply
* gitk in a bare repo?
From: Joakim Tjernlund @ 2007-11-17 15:09 UTC (permalink / raw)
To: git
How do I tell gitk I am in a bare repo?
^ permalink raw reply
* Re: [PATCH] Git.pm: Don't return 'undef' in vector context.
From: Jakub Narebski @ 2007-11-17 15:19 UTC (permalink / raw)
To: Dan Zwell; +Cc: Petr Baudis, Git Mailing List
In-Reply-To: <473E5E08.2090609@zwell.net>
On Saturday, 17 November 2007, Dan Zwell wrote:
> Jakub Narebski wrote:
> >
> > By the way, what do you think about changing Git.pm config handling
> > to the 'eager' one used currently by gitweb, namely reading all the
> > config to hash, and later getting config values from hash instead of
> > calling git-config? Or at least make it an option?
> >
>
> That seems appropriate, though it may be a slight trade-off between
> complexity and efficiency. I don't think it's strictly necessary, at
> least for git-add--interactive.
On one hand it adds a bit of complexity, as you have to check if
config was parsed (and either parse, as it is done now in gitweb,
or perhaps fallback on calling git-config per variable), and you
have to do type checking / conversion to bool and int (size suffixes!)
in Perl, and deal with single-value and multi-value variables.
On the other hand I think that error handling will be simplier.
> My experience is that the nine calls to
> config() (that I am adding) do not slow down the program from a user
> perspective (though I haven't tested on a slower computer).
The problem is not so much with a slower computer, as operating
systems with inefficient, slow fork implementation, like MS Windows
and (if I remember) correctly MacOS X.
But it is true that the config() performance is needed less for desktop
(commands like git-add--interactive) than for web (gitweb for example).
> The big reason to do it would be if you wanted to convert gitweb to use
> the standard config() call from Git.pm. Because right now, config()
> isn't efficient, but it probably doesn't need to be.
There are two reasons against convering gitweb to use Git.pm, at least
for now.
First, it makes installing gitweb harder, as one would have to install
(and perhaps compile) Git.pm to use gitweb. It would add additional
dependency. But perhaps this is not as much a problem as I think...
Second, gitweb code contain in few places pipelines (e.g. tar.gz and
tar.bz2 snapshot pipelines); even if some of them can be eliminated,
some will be added (syntax highlighting in blob view). Git.pm doesn't
as of yet support this...
It would be nice if Git.pm could take advantage of libification project,
and git have fast bindings not only for Python but also for Perl. If I
remember correctly the early attempts to use "git library" directly
were abandoned becaue they were not sufficiently portable, and the
fallback-to-Perl idea was thought too complex to implement...
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: git-cvsimport bug with dates
From: Elijah Newren @ 2007-11-17 15:39 UTC (permalink / raw)
To: Robin Rosenberg; +Cc: Junio C Hamano, git
In-Reply-To: <200711171112.23150.robin.rosenberg.lists@dewire.com>
On Nov 17, 2007 3:12 AM, Robin Rosenberg
<robin.rosenberg.lists@dewire.com> wrote:
> fredag 16 november 2007 skrev Elijah Newren:
>
> > On Nov 15, 2007 11:06 PM, Junio C Hamano <gitster@pobox.com> wrote:
> > > When you use "branch@{date}" notation, you are not asking a
> > > question on the project history, but a question on the local
> > > view from _your_ repository on that project.
> >
> > Interesting; that makes sense from a merge or pull viewpoint, but
> > wouldn't it make more sense to have cvsimport ensure the commits are
> > treated as though they actually existed in master as of the date
> > specified in CVS?
>
> Reflog do not work that way. They don't say when a commit entered a repo,
> only when a ref changed. For a CVS import things could work as you suggest
> but I think the confusion among newcomers would be massive if people start
> using reflogs 'as if' it said anyting about when a commit entered. It can be used
> as a hint.
Okay...so I guess my suggestion could be translated as: don't worry
about when the commit entered; instead make git-cvsimport mark the
refs as changed as of the CVS date mentioned instead of as of the
import time.
I guess there would be reluctance to do this whenever git-cvsimport
would be used for incremental commits on a repository that also had
local commits? Sounds like the issue is deeper than I first realized
and this probably isn't worth the effort it'd take.
Thanks for the explanations.
Elijah
^ permalink raw reply
* Re: gitk in a bare repo?
From: Matthias Kestenholz @ 2007-11-17 16:06 UTC (permalink / raw)
To: Joakim Tjernlund; +Cc: git
In-Reply-To: <004101c8292b$cd4b5d20$5267a8c0@Jocke>
Hi Joakim,
2007/11/17, Joakim Tjernlund <joakim.tjernlund@transmode.se>:
> How do I tell gitk I am in a bare repo?
>
The following command works for me:
$ ls
foo.git
$ GIT_DIR=foo.git gitk &
^ permalink raw reply
* Re: wishlist: git info
From: Jan Hudec @ 2007-11-17 16:21 UTC (permalink / raw)
To: Thomas Neumann; +Cc: Johannes Schindelin, git
In-Reply-To: <47398B43.30408@users.sourceforge.net>
[-- Attachment #1: Type: text/plain, Size: 1534 bytes --]
On Tue, Nov 13, 2007 at 12:32:19 +0100, Thomas Neumann wrote:
> > Is slightly troubles me that you put so much emphasis on what I would call
> > "remote information". I understand that in svn, your working directory
> > without the server is not very useful. But we do not have that problem.
> that is true. My usage pattern probably stems from the fact that I am a
> long term svn user :) And I use git for work now, where there is indeed
> some kind of central repository just as in a Subversion setting.
> In a fully decentralized setting the remote information is probably not
> as important, although you might still want to know what happens if you
> issue "git pull".
The remote URL isn't /the/ useful bit, most of the time. Either you have just
one remote, which is the project central repository and you probably know
which it is just by knowing which project it is, or you have many of them and
their names tell you enough.
Note, that unlike in Subversion, the branch name is /not/ part of the URL.
And that is the useful bit of the information. So what 'git info' probably
should show is:
- Which branch is currently checked out
- Which branch it is tracking (inspect the config)
- List of n (where n is small integer) "closest" branches, where the
distance to a branch is number of commits in HEAD since common ancestor
with that branch.
- Latest included tag. Basically something like git describe.
- Short log of last few commits.
--
Jan 'Bulb' Hudec <bulb@ucw.cz>
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH] user-manual: Talk about tracking third-party snapshots
From: Jan Hudec @ 2007-11-17 16:45 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <fhcb29$ef$2@ger.gmane.org>
On Tue, Nov 13, 2007 at 15:07:05 +0100, Jakub Narebski wrote:
> Michael Smith wrote:
>
> > +You can use the gitlink:git-cherry[1] command to display the commit
> > +IDs that are only present on your local branch, or only on the remote
> > +branch, respectively:
>
> I think git-cherry is deprecated in favor of "git log --left-right" (with
> appropriate format, for example '--abbrev-commit --pretty=oneline')
git log has such option?
$ man git-log | grep -e --left-right; echo $?
1
$ git --version
git version 1.5.3.5
--
Jan 'Bulb' Hudec <bulb@ucw.cz>
^ permalink raw reply
* RE: gitk in a bare repo?
From: Joakim Tjernlund @ 2007-11-17 16:48 UTC (permalink / raw)
To: 'Matthias Kestenholz'; +Cc: git
In-Reply-To: <1f6632e50711170806x3d0c73eam7e341e73f637fc83@mail.gmail.com>
> -----Original Message-----
> From: mk@feinheit.ch [mailto:mk@feinheit.ch] On Behalf Of
> Matthias Kestenholz
> Sent: den 17 november 2007 17:06
>
> Hi Joakim,
>
> 2007/11/17, Joakim Tjernlund <joakim.tjernlund@transmode.se>:
> > How do I tell gitk I am in a bare repo?
> >
>
> The following command works for me:
>
> $ ls
> foo.git
> $ GIT_DIR=foo.git gitk &
>
Ahh, didn't think of that. Tride passing --bare in diffrent ways
Thanks,
Jocke
^ permalink raw reply
* Re: [Newbie] How to *actually* get rid of remote tracking branch?
From: Jan Hudec @ 2007-11-17 16:56 UTC (permalink / raw)
To: Sergei Organov; +Cc: Johannes Schindelin, Jakub Narebski, git
In-Reply-To: <874pfq7zpg.fsf@osv.gnss.ru>
[-- Attachment #1: Type: text/plain, Size: 1937 bytes --]
On Tue, Nov 13, 2007 at 21:44:11 +0300, Sergei Organov wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>
> > Hi,
> >
> > On Tue, 13 Nov 2007, Sergei Organov wrote:
> >
> >> Sorry, but *I* didn't *explicitly* fetch it _again_!
> >>
> >> 1. I cloned git.git repo making no custom steps.
> >
> > Which means that you wanted to track that repository. Yes, the complete
> > repository. Not a single branch. Not all branches except a single one.
> >
> >> 2. I decided I don't need to track some of branches.
> >
> > The you should have done that.
>
> I think I did my best to try to do that (basing my attempts on current
> git documentation). Isn't it?
>
> > But that is different from "I decided to delete the tracking
> > _branch_".
>
> Yes, but the question is *why*? Isn't it an obvious application of
> deleting tracking branch?
No, it's not. Fetching has to bring you any heads that were newly created in
the remote repo. It can't tell whether a head is new since last fetch or you
just for whatever reason didn't have the tracking branch before.
> And, as I've already asked in another
> sub-thread of this one, what the following example in the man git-branch
> is supposed to achieve?:
>
> <quote Documentation/git-branch.txt>
> Delete unneeded branch::
> +
> ------------
> $ git clone git://git.kernel.org/.../git.git my.git
> $ cd my.git
> $ git branch -d -r origin/todo origin/html origin/man <1>
> $ git branch -D test <2>
> ------------
> +
> <1> Delete remote-tracking branches "todo", "html", "man"
> </quote>
>
> Sorry, but I still believe that it's not me who needs fixing.
That documentation is precise. But it could maybe contain a footnote saying,
that if you remove a tracking branch, next fetch will create it again unless
you reconfigure it not to.
--
Jan 'Bulb' Hudec <bulb@ucw.cz>
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH 3/3] send-pack: assign remote errors to each ref
From: Daniel Barkalow @ 2007-11-17 18:05 UTC (permalink / raw)
To: Jeff King; +Cc: Junio C Hamano, git, Alex Riesen, Pierre Habouzit
In-Reply-To: <20071117125602.GC23186@sigill.intra.peff.net>
On Sat, 17 Nov 2007, Jeff King wrote:
> This lets us show remote errors (e.g., a denied hook) along
> with the usual push output.
>
> There is a slightly clever optimization in receive_status
> that bears explanation. We need to correlate the returned
> status and our ref objects, which naively could be an O(m*n)
> operation. However, since the current implementation of
> receive-pack returns the errors to us in the same order that
> we sent them, we optimistically look for the next ref to be
> looked up to come after the last one we have found. So it
> should be an O(m+n) merge if the receive-pack behavior
> holds, but we fall back to a correct but slower behavior if
> it should change.
>
> Signed-off-by: Jeff King <peff@peff.net>
> ---
> builtin-send-pack.c | 51 +++++++++++++++++++++++++++++++++++++++-----
> cache.h | 2 +
> t/t5406-remote-rejects.sh | 24 +++++++++++++++++++++
> 3 files changed, 71 insertions(+), 6 deletions(-)
> create mode 100755 t/t5406-remote-rejects.sh
>
> diff --git a/builtin-send-pack.c b/builtin-send-pack.c
> index c7d07aa..bcf7143 100644
> --- a/builtin-send-pack.c
> +++ b/builtin-send-pack.c
> @@ -146,19 +146,43 @@ static void get_local_heads(void)
> for_each_ref(one_local_ref, NULL);
> }
>
> -static int receive_status(int in)
> +static struct ref *set_ref_error(struct ref *refs, const char *line)
> {
> + struct ref *ref;
> +
> + for (ref = refs; ref; ref = ref->next) {
> + const char *msg;
> + if (prefixcmp(line, ref->name))
> + continue;
> + msg = line + strlen(ref->name);
> + if (*msg++ != ' ')
> + continue;
> + ref->status = REF_STATUS_REMOTE_REJECT;
> + ref->error = xstrdup(msg);
> + ref->error[strlen(ref->error)-1] = '\0';
> + return ref;
> + }
> + return NULL;
> +}
Maybe this should take both the full list and the hint and do both passes
internally? IMHO, the logic in receive_status() looks like it might be
setting the error twice or not at all, unless you read very carefully.
But, regardless,
Acked-by: Daniel Barkalow <barkalow@iabervon.org>
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* Re: [PATCH 2/3] send-pack: check ref->status before updating tracking refs
From: Daniel Barkalow @ 2007-11-17 18:05 UTC (permalink / raw)
To: Jeff King; +Cc: Junio C Hamano, git, Alex Riesen, Pierre Habouzit
In-Reply-To: <20071117125515.GB23186@sigill.intra.peff.net>
On Sat, 17 Nov 2007, Jeff King wrote:
> Previously, we manually checked the 'NONE' and 'UPTODATE'
> conditions. Now that we have ref->status, we can easily
> say "only update if we pushed successfully".
>
> This adds a test for and fixes a regression introduced in
> ed31df31 where deleted refs did not have their tracking
> branches removed. This was due to a bogus per-ref error test
> that is superseded by the more accurate ref->status flag.
>
> Signed-off-by: Jeff King <peff@peff.net>
Acked-by: Daniel Barkalow <barkalow@iabervon.org>
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* Re: [PATCH 1/3] send-pack: track errors for each ref
From: Daniel Barkalow @ 2007-11-17 18:05 UTC (permalink / raw)
To: Jeff King; +Cc: Junio C Hamano, git, Alex Riesen, Pierre Habouzit
In-Reply-To: <20071117125426.GA23186@sigill.intra.peff.net>
On Sat, 17 Nov 2007, Jeff King wrote:
> diff --git a/builtin-send-pack.c b/builtin-send-pack.c
> index 418925e..90ca2d3 100644
> --- a/builtin-send-pack.c
> +++ b/builtin-send-pack.c
> @@ -218,15 +219,105 @@ static const char *prettify_ref(const char *name)
>
> #define SUMMARY_WIDTH (2 * DEFAULT_ABBREV + 3)
>
> +static void print_ref_status(char flag, const char *summary, struct ref *to, struct ref *from, const char *msg)
Isn't "from" always "to->peer_ref"? It'd be nice to make this function
unable to print something different from what we actually did. (Actually
it might be "to->deletion ? NULL : to->peer_ref", but that would also be
better to have as an explicit feature of how you display "to", rather than
implicit in the set of callers.
> +static const char *status_abbrev(unsigned char sha1[20])
> +{
> + const char *abbrev;
> + abbrev = find_unique_abbrev(sha1, DEFAULT_ABBREV);
> + return abbrev ? abbrev : sha1_to_hex(sha1);
> +}
Maybe we should have a find_unique_abbrev()-like function that doesn't
mind if the requested object doesn't exist?
> +
> +static void print_ok_ref_status(struct ref *ref)
> +{
> + if (ref->deletion)
> + print_ref_status('-', "[deleted]", ref, NULL, NULL);
> + else if (is_null_sha1(ref->old_sha1))
> + print_ref_status('*',
> + (!prefixcmp(ref->name, "refs/tags/") ? "[new tag]" :
> + "[new branch]"),
> + ref, ref->peer_ref, NULL);
> + else {
> + char quickref[83];
Shouldn't this be 40 + 3 + 40 + 1?
> + char type;
> + const char *msg;
> +
> + strcpy(quickref, status_abbrev(ref->old_sha1));
> + if (ref->nonfastforward) {
> + strcat(quickref, "...");
> + type = '+';
> + msg = " (forced update)";
> + }
> + else {
Coding style, IIRC.
Regardless of these nits, it all looks good to me.
Acked-by: Daniel Barkalow <barkalow@iabervon.org>
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* Re: [PATCH] user-manual: Talk about tracking third-party snapshots
From: Jakub Narebski @ 2007-11-17 18:18 UTC (permalink / raw)
To: Jan Hudec; +Cc: git
In-Reply-To: <20071117164501.GB5198@efreet.light.src>
On Sat, Nov 17, 2007, Jan Hudec wrote:
> On Tue, Nov 13, 2007 at 15:07:05 +0100, Jakub Narebski wrote:
>> Michael Smith wrote:
>>
>>> +You can use the gitlink:git-cherry[1] command to display the commit
>>> +IDs that are only present on your local branch, or only on the remote
>>> +branch, respectively:
>>
>> I think git-cherry is deprecated in favor of "git log --left-right" (with
>> appropriate format, for example '--abbrev-commit --pretty=oneline')
Not true. git-cherry is more than --left-right, as it checks
if changesets matches, not if commit id matches.
> git log has such option?
>
> $ man git-log | grep -e --left-right; echo $?
> 1
> $ git --version
> git version 1.5.3.5
It has, although it is hidden in git-rev-list(1) manpage. It is a bit
obscure corner...
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: preserving mtime
From: Wayne Davison @ 2007-11-17 18:22 UTC (permalink / raw)
To: Andreas Ericsson; +Cc: git
In-Reply-To: <473D6DC6.8040804@op5.se>
On Fri, Nov 16, 2007 at 11:15:34AM +0100, Andreas Ericsson wrote:
>> is it possible to tell git to preserve the file modification time in
>> a checked out copy?
> Fabrizio Pollastri wrote:
> No. Doing so would seriously break build-systems.
I wish that the initial clone would set the modification time to the
commit time. It would make the intial checkout have a more accurate
representation of when a file was last changed instead of all files
being set to the clone date. Then, files that are being updated would
get their time set as they do now. I supposed I'll just use the handy
git-set-file-times script (mentioned in another reply) every time I do
a clone.
..wayne..
^ permalink raw reply
* Re: [Newbie] How to *actually* get rid of remote tracking branch?
From: Jan Hudec @ 2007-11-17 19:12 UTC (permalink / raw)
To: osv; +Cc: Jakub Narebski, Steffen Prohaska, git
In-Reply-To: <87d4ue81tv.fsf@osv.gnss.ru>
[-- Attachment #1: Type: text/plain, Size: 1027 bytes --]
On Tue, Nov 13, 2007 at 20:58:20 +0300, osv@javad.com wrote:
> Guys, could you please read man git-branch? What do you think this
> example is doing?:
>
> <quote Documentation/git-branch.txt>
> Delete unneeded branch::
> +
> ------------
> $ git clone git://git.kernel.org/.../git.git my.git
> $ cd my.git
> $ git branch -d -r origin/todo origin/html origin/man <1>
> $ git branch -D test <2>
> ------------
> +
> <1> Delete remote-tracking branches "todo", "html", "man"
> </quote>
>
> That's *exactly* what I did! And it *doesn't work*! Well, it does delete
> the branches, but they are automagically re-created on the next fetch,
> so "deleting" them this way is useless.
Of course it *does* work. It *deletes* the branches. There is not a single
word about stopping fetch getting them!
Obviously given that the example is slightly contrived, it should really
be mentioned that it does not affect fetch at all.
--
Jan 'Bulb' Hudec <bulb@ucw.cz>
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* [Advance Warning PATCH] Move gitk to its own subdirectory
From: Junio C Hamano @ 2007-11-17 19:15 UTC (permalink / raw)
To: git
As some people may be aware, i18n effort for gitk has been
discussed and one requirement for that is to have separate
Makefile, or at least separate Makefile entries, to manage
message source files and rules to build and install them.
The plan is to stop merging gitk.git as a single file project
into git.git but instead use the subtree merge strategy into its
own subdirectory of git.git. We can use subproject support in
the future, but once _a_ subproject is used that means the
project's history is not pullable with subproject unaware
versions of git anymore, so I'd avoid it for now.
This patch is just a preview to see reations from the list when
such a transtion should be made. Earlier I mumbled "Let's slow
down for 1.5.4 freeze" on the list, but it seems that we do not
see -rc0 near the horizon yet. I think transitions like this
should better be done sooner rather than later.
The mock gitk-git/Makefile entries in the following patch is
very minimum, and will need to be replaced with the real one
that we pull from Paul's gitk.git repository, along with the
i18n and any other goodies gitk.git will have.
-- >8 --
This is to prepare for gitk i18n effort that makes gitk not a single file
project anymore. We may use subproject to bind git.git and gitk.git more
loosely in the future, but we do not want to require everybody to have
subproject aware git to be able to pull from git.git yet.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
Makefile | 14 +++-----------
gitk-git/Makefile | 29 +++++++++++++++++++++++++++++
gitk => gitk-git/gitk | 0
3 files changed, 32 insertions(+), 11 deletions(-)
create mode 100644 gitk-git/Makefile
rename gitk => gitk-git/gitk (100%)
mode change 100755 => 100644
diff --git a/Makefile b/Makefile
index e830bc7..8110d36 100644
--- a/Makefile
+++ b/Makefile
@@ -270,9 +270,6 @@ ALL_PROGRAMS += git-merge-subtree$X
# what 'all' will build but not install in gitexecdir
OTHER_PROGRAMS = git$X gitweb/gitweb.cgi
-ifndef NO_TCLTK
-OTHER_PROGRAMS += gitk-wish
-endif
# Set paths to tools early so that they can be used for version tests.
ifndef SHELL_PATH
@@ -773,6 +770,7 @@ endif
all::
ifndef NO_TCLTK
$(QUIET_SUBDIR0)git-gui $(QUIET_SUBDIR1) all
+ $(QUIET_SUBDIR0)gitk-git $(QUIET_SUBDIR1) all
endif
$(QUIET_SUBDIR0)perl $(QUIET_SUBDIR1) PERL_PATH='$(PERL_PATH_SQ)' prefix='$(prefix_SQ)' all
$(QUIET_SUBDIR0)templates $(QUIET_SUBDIR1)
@@ -780,12 +778,6 @@ endif
strip: $(PROGRAMS) git$X
$(STRIP) $(STRIP_OPTS) $(PROGRAMS) git$X
-gitk-wish: gitk GIT-GUI-VARS
- $(QUIET_GEN)$(RM) $@ $@+ && \
- sed -e '1,3s|^exec .* "$$0"|exec $(subst |,'\|',$(TCLTK_PATH_SQ)) "$$0"|' <gitk >$@+ && \
- chmod +x $@+ && \
- mv -f $@+ $@
-
git.o: git.c common-cmds.h GIT-CFLAGS
$(QUIET_CC)$(CC) -DGIT_VERSION='"$(GIT_VERSION)"' \
$(ALL_CFLAGS) -c $(filter %.c,$^)
@@ -1026,7 +1018,7 @@ install: all
$(MAKE) -C templates DESTDIR='$(DESTDIR_SQ)' install
$(MAKE) -C perl prefix='$(prefix_SQ)' install
ifndef NO_TCLTK
- $(INSTALL) gitk-wish '$(DESTDIR_SQ)$(bindir_SQ)'/gitk
+ $(MAKE) -C gitk-git install
$(MAKE) -C git-gui install
endif
if test 'z$(bindir_SQ)' != 'z$(gitexecdir_SQ)'; \
@@ -1119,7 +1111,7 @@ clean:
$(MAKE) -C templates/ clean
$(MAKE) -C t/ clean
ifndef NO_TCLTK
- $(RM) gitk-wish
+ $(MAKE) -C gitk-git clean
$(MAKE) -C git-gui clean
endif
$(RM) GIT-VERSION-FILE GIT-CFLAGS GIT-GUI-VARS
diff --git a/gitk-git/Makefile b/gitk-git/Makefile
new file mode 100644
index 0000000..9bc1e24
--- /dev/null
+++ b/gitk-git/Makefile
@@ -0,0 +1,29 @@
+# The default target of this Makefile is...
+all::
+
+prefix ?= $(HOME)
+bindir ?= $(prefix)/bin
+TCLTK_PATH ?= wish
+INSTALL ?= install
+RM ?= rm -f
+
+DESTDIR_SQ = $(subst ','\'',$(DESTDIR))
+bindir_SQ = $(subst ','\'',$(bindir))
+TCLTK_PATH_SQ = $(subst ','\'',$(TCLTK_PATH))
+
+ifndef V
+ QUIET = @
+ QUIET_GEN = $(QUIET)echo ' ' GEN $@ &&
+endif
+
+all:: gitk-wish
+install:: all
+ $(INSTALL) gitk-wish '$(DESTDIR_SQ)$(bindir_SQ)'/gitk
+clean::
+ $(RM) gitk-wish
+
+gitk-wish: gitk
+ $(QUIET_GEN)$(RM) $@ $@+ && \
+ sed -e '1,3s|^exec .* "$$0"|exec $(subst |,'\|',$(TCLTK_PATH_SQ)) "$$0"|' <gitk >$@+ && \
+ chmod +x $@+ && \
+ mv -f $@+ $@
diff --git a/gitk b/gitk-git/gitk
old mode 100755
new mode 100644
similarity index 100%
rename from gitk
rename to gitk-git/gitk
--
1.5.3.5.1806.g3e393
^ permalink raw reply related
* Re: [PATCH] user-manual: Talk about tracking third-party snapshots
From: Jan Hudec @ 2007-11-17 19:18 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <200711171918.40981.jnareb@gmail.com>
On Sat, Nov 17, 2007 at 19:18:40 +0100, Jakub Narebski wrote:
> On Sat, Nov 17, 2007, Jan Hudec wrote:
> > On Tue, Nov 13, 2007 at 15:07:05 +0100, Jakub Narebski wrote:
> >> Michael Smith wrote:
> >>
> >>> +You can use the gitlink:git-cherry[1] command to display the commit
> >>> +IDs that are only present on your local branch, or only on the remote
> >>> +branch, respectively:
> >>
> >> I think git-cherry is deprecated in favor of "git log --left-right" (with
> >> appropriate format, for example '--abbrev-commit --pretty=oneline')
>
> Not true. git-cherry is more than --left-right, as it checks
> if changesets matches, not if commit id matches.
>
> > git log has such option?
> >
> > $ man git-log | grep -e --left-right; echo $?
> > 1
> > $ git --version
> > git version 1.5.3.5
>
> It has, although it is hidden in git-rev-list(1) manpage. It is a bit
> obscure corner...
I hope the new option parsing ifrastructure will take over quickly and start
to be used to generate the short help and probably even option section in the
man pages. It's unfortunately not the only option that is not mentioned in
the manual page of a command that has it.
--
Jan 'Bulb' Hudec <bulb@ucw.cz>
^ permalink raw reply
* [PATCH] Improve description of git-branch -d and -D in man page.
From: Jan Hudec @ 2007-11-17 19:51 UTC (permalink / raw)
To: osv; +Cc: Jakub Narebski, Steffen Prohaska, git, Junio C Hamano
In-Reply-To: <20071117191256.GD5198@efreet.light.src>
Some users expect that deleting a remote-tracking branch would prevent
fetch from creating it again, so be explcit about that it's not the case.
Also be a little more explicit about what fully merged means.
Signed-off-by: Jan Hudec <bulb@ucw.cz>
---
On Sat, Nov 17, 2007 at 20:12:56 +0100, Jan Hudec wrote:
> On Tue, Nov 13, 2007 at 20:58:20 +0300, osv@javad.com wrote:
> > <quote Documentation/git-branch.txt>
> > Delete unneeded branch::
> > +
> > ------------
> > $ git clone git://git.kernel.org/.../git.git my.git
> > $ cd my.git
> > $ git branch -d -r origin/todo origin/html origin/man <1>
> > $ git branch -D test <2>
> > ------------
> > +
> > <1> Delete remote-tracking branches "todo", "html", "man"
> > </quote>
> >
> > That's *exactly* what I did! And it *doesn't work*! Well, it does delete
> > the branches, but they are automagically re-created on the next fetch,
> > so "deleting" them this way is useless.
>
> Of course it *does* work. It *deletes* the branches. There is not a single
> word about stopping fetch getting them!
>
> Obviously given that the example is slightly contrived, it should really
> be mentioned that it does not affect fetch at all.
Would this make the description obvious enough?
--
Jan 'Bulb' Hudec <bulb@ucw.cz>
Documentation/git-branch.txt | 21 ++++++++++++++-------
1 files changed, 14 insertions(+), 7 deletions(-)
diff --git a/Documentation/git-branch.txt b/Documentation/git-branch.txt
index 5ce905d..f87b696 100644
--- a/Documentation/git-branch.txt
+++ b/Documentation/git-branch.txt
@@ -45,17 +45,22 @@ to happen.
With a `-d` or `-D` option, `<branchname>` will be deleted. You may
specify more than one branch for deletion. If the branch currently
-has a reflog then the reflog will also be deleted. Use -r together with -d
-to delete remote-tracking branches.
+has a reflog then the reflog will also be deleted.
+
+Use -r together with -d to delete remote-tracking branches. Note, that it
+only makes sense to delete remote-tracking branches if they no longer exist
+in remote repository or if gitlink:git-fetch[1] was configured not to fetch
+them again. See also 'prune' subcommand of gitlink:git-remote[1] for way to
+clean up all obsolete remote-tracking branches.
OPTIONS
-------
-d::
- Delete a branch. The branch must be fully merged.
+ Delete a branch. The branch must be fully merged in HEAD.
-D::
- Delete a branch irrespective of its index status.
+ Delete a branch irrespective of its merged status.
-l::
Create the branch's reflog. This activates recording of
@@ -153,9 +158,11 @@ $ git branch -d -r origin/todo origin/html origin/man <1>
$ git branch -D test <2>
------------
+
-<1> Delete remote-tracking branches "todo", "html", "man"
-<2> Delete "test" branch even if the "master" branch does not have all
-commits from test branch.
+<1> Delete remote-tracking branches "todo", "html", "man". Next 'fetch' or
+'pull' will create them again unless you configure them not to. See
+gitlink:git-fetch[1].
+<2> Delete "test" branch even if the "master" branch (or whichever branch is
+currently checked out) does not have all commits from test branch.
Notes
--
1.5.3.5
^ permalink raw reply related
* Re: [PATCH] user-manual: Talk about tracking third-party snapshots
From: Jakub Narebski @ 2007-11-17 19:54 UTC (permalink / raw)
To: Jan Hudec; +Cc: git
In-Reply-To: <20071117191846.GE5198@efreet.light.src>
Jan Hudec wrote:
> On Sat, Nov 17, 2007 at 19:18:40 +0100, Jakub Narebski wrote:
>> On Sat, Nov 17, 2007, Jan Hudec wrote:
>>> git log has such option?
>>>
>>> $ man git-log | grep -e --left-right; echo $?
>>> 1
>>> $ git --version
>>> git version 1.5.3.5
>>
>> It has, although it is hidden in git-rev-list(1) manpage. It is a bit
>> obscure corner...
>
> I hope the new option parsing ifrastructure will take over quickly and start
> to be used to generate the short help and probably even option section in the
> man pages. It's unfortunately not the only option that is not mentioned in
> the manual page of a command that has it.
Truth to be told _this_ one option I don't mean it is only
in git-rev-parse (which git-log references, together with git-diff)
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: [PATCH v3] Add to gitk an --argscmd flag to get the list of refs to draw at refresh time.
From: Yann Dirson @ 2007-11-17 19:56 UTC (permalink / raw)
To: Paul Mackerras; +Cc: git
In-Reply-To: <18238.54272.198637.788805@cargo.ozlabs.ibm.com>
Hi Paul,
I hope I did not introduce other problems while trying to adress those.
On Sat, Nov 17, 2007 at 10:44:00PM +1100, Paul Mackerras wrote:
> What this will do is interpret the output of the program according to
> Tcl list syntax.
I'm not sure of why this interpretation is done, so it may well be that
the updated patch would behave the same.
> use error_popup rather than just writing to stderr.
While testing that, I realized that the current behaviour is not very
friendly. While it is OK to exit on error here, when the command has
been entered on command-line, it would be rude to exit when the user
makes a typo when editing the view. It would be more friendly to get
back to the "edit view" dialog instead; I'm not sure we can already
tell in which of the 2 situations we are - would you conisider adding
a global flag for tracking this to be an adequate solution ?
> > +set revtreeargscmd None
>
> Why the string "None" rather than the empty string? Is this a
> python-ism that has crept in?
Note completely - since there were already occurences of None in gitk, I
assumed it was a special value in Tcl. Should I have searched in more
details, I would have noticed the string comparisons.
Best regards,
--
Yann
^ 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