* 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
* [PATCH v4] Add to gitk an --argscmd flag to get the list of refs to draw at refresh time.
From: Yann Dirson @ 2007-11-17 19:58 UTC (permalink / raw)
To: Paul Mackerras; +Cc: git
This allows to display a set of refs, when the refs in the set may
themselves change between two refresh operations (eg. the set of
patches in a patch stack), and is expected to be called from other
porcelain suites.
The command is expected to generate a list of commits, which will be
appended to the commits litterally passed on the command-line. That
command is handled similarly to the litteral refs, and has its own
field in the saved view, and an edit field in the view editor.
Signed-off-by: Yann Dirson <ydirson@altern.org>
---
Documentation/gitk.txt | 7 +++++++
gitk | 50 ++++++++++++++++++++++++++++++++++++++----------
2 files changed, 47 insertions(+), 10 deletions(-)
diff --git a/Documentation/gitk.txt b/Documentation/gitk.txt
index 8dbfb0d..f1f3410 100644
--- a/Documentation/gitk.txt
+++ b/Documentation/gitk.txt
@@ -41,6 +41,13 @@ frequently used options.
Show all branches.
+--argscmd=<command>::
+ Command to be run each time gitk has to determine the list of
+ <revs> to show. The command is expected to print on its standard
+ output a list of additional revs to be shown, one per line.
+ Use this instead of explicitly specifying <revs> if the set of
+ commits to show may vary between refreshes.
+
<revs>::
Limit the revisions to show. This can be either a single revision
diff --git a/gitk b/gitk
index 1da0b0a..aba9100 100755
--- a/gitk
+++ b/gitk
@@ -82,7 +82,7 @@ proc dorunq {} {
proc start_rev_list {view} {
global startmsecs
global commfd leftover tclencoding datemode
- global viewargs viewfiles commitidx viewcomplete vnextroot
+ global viewargs viewargscmd viewfiles commitidx viewcomplete vnextroot
global showlocalchanges commitinterest mainheadid
global progressdirn progresscoords proglastnc curview
@@ -90,13 +90,23 @@ proc start_rev_list {view} {
set commitidx($view) 0
set viewcomplete($view) 0
set vnextroot($view) 0
+ set args $viewargs($view)
+ if {$viewargscmd($view) ne {}} {
+ if {[catch {
+ set str [exec sh -c $viewargscmd($view)]
+ } err]} {
+ error_popup "Error executing --argscmd command: $err"
+ exit 1
+ }
+ set args [concat $args [split $str "\n"]]
+ }
set order "--topo-order"
if {$datemode} {
set order "--date-order"
}
if {[catch {
set fd [open [concat | git log --no-color -z --pretty=raw $order --parents \
- --boundary $viewargs($view) "--" $viewfiles($view)] r]
+ --boundary $args "--" $viewfiles($view)] r]
} err]} {
error_popup "Error executing git rev-list: $err"
exit 1
@@ -1154,7 +1164,7 @@ proc savestuff {w} {
global canv canv2 canv3 mainfont textfont uifont tabstop
global stuffsaved findmergefiles maxgraphpct
global maxwidth showneartags showlocalchanges
- global viewname viewfiles viewargs viewperm nextviewnum
+ global viewname viewfiles viewargs viewargscmd viewperm nextviewnum
global cmitmode wrapcomment datetimeformat limitdiffs
global colors bgcolor fgcolor diffcolors diffcontext selectbgcolor
@@ -1193,7 +1203,7 @@ proc savestuff {w} {
puts -nonewline $f "set permviews {"
for {set v 0} {$v < $nextviewnum} {incr v} {
if {$viewperm($v)} {
- puts $f "{[list $viewname($v) $viewfiles($v) $viewargs($v)]}"
+ puts $f "{[list $viewname($v) $viewfiles($v) $viewargs($v) $viewargscmd($v)]}"
}
}
puts $f "}"
@@ -1849,7 +1859,7 @@ proc shellsplit {str} {
proc newview {ishighlight} {
global nextviewnum newviewname newviewperm uifont newishighlight
- global newviewargs revtreeargs
+ global newviewargs revtreeargs viewargscmd newviewargscmd curview
set newishighlight $ishighlight
set top .gitkview
@@ -1860,13 +1870,14 @@ proc newview {ishighlight} {
set newviewname($nextviewnum) "View $nextviewnum"
set newviewperm($nextviewnum) 0
set newviewargs($nextviewnum) [shellarglist $revtreeargs]
+ set newviewargscmd($nextviewnum) $viewargscmd($curview)
vieweditor $top $nextviewnum "Gitk view definition"
}
proc editview {} {
global curview
global viewname viewperm newviewname newviewperm
- global viewargs newviewargs
+ global viewargs newviewargs viewargscmd newviewargscmd
set top .gitkvedit-$curview
if {[winfo exists $top]} {
@@ -1876,6 +1887,7 @@ proc editview {} {
set newviewname($curview) $viewname($curview)
set newviewperm($curview) $viewperm($curview)
set newviewargs($curview) [shellarglist $viewargs($curview)]
+ set newviewargscmd($curview) $viewargscmd($curview)
vieweditor $top $curview "Gitk: edit view $viewname($curview)"
}
@@ -1896,7 +1908,15 @@ proc vieweditor {top n title} {
grid $top.al - -sticky w -pady 5
entry $top.args -width 50 -textvariable newviewargs($n) \
-background white -font uifont
+
grid $top.args - -sticky ew -padx 5
+ message $top.ac -aspect 1000 -font uifont \
+ -text "Command to generate more commits to include:"
+ grid $top.ac - -sticky w -pady 5
+ entry $top.argscmd -width 50 -textvariable newviewargscmd($n) \
+ -background white -font uifont
+
+ grid $top.argscmd - -sticky ew -padx 5
message $top.l -aspect 1000 -font uifont \
-text "Enter files and directories to include, one per line:"
grid $top.l - -sticky w
@@ -1942,7 +1962,7 @@ proc allviewmenus {n op args} {
proc newviewok {top n} {
global nextviewnum newviewperm newviewname newishighlight
global viewname viewfiles viewperm selectedview curview
- global viewargs newviewargs viewhlmenu
+ global viewargs newviewargs viewargscmd newviewargscmd viewhlmenu
if {[catch {
set newargs [shellsplit $newviewargs($n)]
@@ -1966,6 +1986,7 @@ proc newviewok {top n} {
set viewperm($n) $newviewperm($n)
set viewfiles($n) $files
set viewargs($n) $newargs
+ set viewargscmd($n) $newviewargscmd($n)
addviewmenu $n
if {!$newishighlight} {
run showview $n
@@ -1982,9 +2003,11 @@ proc newviewok {top n} {
# doviewmenu $viewhlmenu 1 [list addvhighlight $n] \
# entryconf [list -label $viewname($n) -value $viewname($n)]
}
- if {$files ne $viewfiles($n) || $newargs ne $viewargs($n)} {
+ if {$files ne $viewfiles($n) || $newargs ne $viewargs($n) || \
+ $newviewargscmd($n) ne $viewargscmd($n)} {
set viewfiles($n) $files
set viewargs($n) $newargs
+ set viewargscmd($n) $newviewargscmd($n)
if {$curview == $n} {
run updatecommits
}
@@ -8505,8 +8528,9 @@ set mergeonly 0
set revtreeargs {}
set cmdline_files {}
set i 0
+set revtreeargscmd {}
foreach arg $argv {
- switch -- $arg {
+ switch -glob -- $arg {
"" { }
"-d" { set datemode 1 }
"--merge" {
@@ -8517,6 +8541,9 @@ foreach arg $argv {
set cmdline_files [lrange $argv [expr {$i + 1}] end]
break
}
+ "--argscmd=*" {
+ set revtreeargscmd [string range $arg 10 end]
+ }
default {
lappend revtreeargs $arg
}
@@ -8618,6 +8645,7 @@ set highlight_files {}
set viewfiles(0) {}
set viewperm(0) 0
set viewargs(0) {}
+set viewargscmd(0) {}
set cmdlineok 0
set stopped 0
@@ -8633,7 +8661,7 @@ tkwait visibility .
wm title . "[file tail $argv0]: [file tail [pwd]]"
readrefs
-if {$cmdline_files ne {} || $revtreeargs ne {}} {
+if {$cmdline_files ne {} || $revtreeargs ne {} || $revtreeargscmd ne {}} {
# create a view for the files/dirs specified on the command line
set curview 1
set selectedview 1
@@ -8641,6 +8669,7 @@ if {$cmdline_files ne {} || $revtreeargs ne {}} {
set viewname(1) "Command line"
set viewfiles(1) $cmdline_files
set viewargs(1) $revtreeargs
+ set viewargscmd(1) $revtreeargscmd
set viewperm(1) 0
addviewmenu 1
.bar.view entryconf Edit* -state normal
@@ -8654,6 +8683,7 @@ if {[info exists permviews]} {
set viewname($n) [lindex $v 0]
set viewfiles($n) [lindex $v 1]
set viewargs($n) [lindex $v 2]
+ set viewargscmd($n) [lindex $v 3]
set viewperm($n) 1
addviewmenu $n
}
^ permalink raw reply related
* BUG in gitk (was: Re: BUG: git-svn does not escape literal backslashes in author names.)
From: Benoit Sigoure @ 2007-11-17 20:18 UTC (permalink / raw)
To: Adrian Wilkins; +Cc: git
In-Reply-To: <1213a9470711120628l4ccab632n17635295ec897a2@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2329 bytes --]
On Nov 12, 2007, at 3:28 PM, Adrian Wilkins wrote:
> Recently converted a large (11,000+ revisions) repository.
>
> We authenticate against the NT domain controller, so all our revision
> authors are of the form "domain\user". (You can switch off mod_sspi
> reporting the domain part, but I didn't know about this at the time,
> so it continues for historical reasons.)
>
> git-svn treats the literal backslashes in the author names as escapes.
> This leads to authors like
>
> domainkevin
> domain\
> ichard
Hi Adrian,
I tried to reproduce the error but didn't succeed (see below). Which
version of Git did you use?
However, gitk fails to properly render the various properties when
they contain backslash sequences. If a gitk expert could have a
look, I tried but didn't find a standard Tcl procedure to escape
everything properly and I didn't feel like recoding my own procedure
because I guess this already exists...
Cheers,
$ svnadmin create repo
$ svn co file://`pwd`/repo wc
Checked out revision 0.
$ cd wc
$ svn mkdir trunk tags branches
A trunk
A tags
A branches
$ svn ci -m stdlayout
Adding branches
Adding tags
Adding trunk
Committed revision 1.
$ cd trunk
$ touch plop && svn add plop
A plop
$ svn ci -m test --username 'domain\name\richard\test\\ok'
Adding trunk/plop
Transmitting file data .
Committed revision 2.
$ cd ../..
$ git svn clone --stdlayout file://`pwd`/repo git
Initialized empty Git repository in .git/
r1 = dc86087745d9b6378114f49c1e480d178cf328f9 (trunk)
A plop
r2 = de5affcfdc897bfa77a2402a447771f0a88b04bf (trunk)
Checked out HEAD:
file:///tmp/repo/trunk r2
$ cd git
$ git log
commit de5affcfdc897bfa77a2402a447771f0a88b04bf
Author: domain\name\richard\test\\ok <domain\name\richard\test\
\ok@e88f2f36-2641-46fb-97e4-5fd9951470b2
Date: Sat Nov 17 12:17:29 2007 +0000
test
git-svn-id: file:///tmp/repo/trunk@2
e88f2f36-2641-46fb-97e4-5fd9951470b2
commit dc86087745d9b6378114f49c1e480d178cf328f9
Author: tsuna <tsuna@e88f2f36-2641-46fb-97e4-5fd9951470b2>
Date: Sat Nov 17 12:16:29 2007 +0000
stdlayout
git-svn-id: file:///tmp/repo/trunk@1
e88f2f36-2641-46fb-97e4-5fd9951470b2
$ gitk # Oops
--
Benoit Sigoure aka Tsuna
EPITA Research and Development Laboratory
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 186 bytes --]
^ permalink raw reply
* Re: BUG: git-svn does not escape literal backslashes in author names.
From: Eric Wong @ 2007-11-17 20:43 UTC (permalink / raw)
To: Adrian Wilkins; +Cc: git
In-Reply-To: <1213a9470711120628l4ccab632n17635295ec897a2@mail.gmail.com>
Adrian Wilkins <adrian.wilkins@gmail.com> wrote:
> Recently converted a large (11,000+ revisions) repository.
>
> We authenticate against the NT domain controller, so all our revision
> authors are of the form "domain\user". (You can switch off mod_sspi
> reporting the domain part, but I didn't know about this at the time,
> so it continues for historical reasons.)
>
> git-svn treats the literal backslashes in the author names as escapes.
> This leads to authors like
>
> domainkevin
> domain\
> ichard
>
> I know, I should have read the manual and used my "authors" file. Bah.
>
> I'm sure that part of the revision hash in git includes the author
> name... so I guess I'm looking at another multi-day conversion. :-(
git-filter-branch should be able to take care of it. If you find
an invocation that's useful to others, it'd be great to post it
on the list as well :)
> Can I suggest that you make the authors file compulsory by default as well?
Not going to happen. I personally _hate_ having to track down author
information and make an authors file, and I suspect many others feel the
same. I've never used this feature in git-svn on any real repository.
--
Eric Wong
^ 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