* Re: Getting correct tree layout when importing svn repo into git
From: Andreas Ericsson @ 2008-09-17 6:56 UTC (permalink / raw)
To: Michael Kerrisk; +Cc: Dmitry Potapov, mtk.manpages, git, michael.kerrisk
In-Reply-To: <c49095e30809162216m5c7885dbibbb022e65f43231c@mail.gmail.com>
Michael Kerrisk wrote:
> Hi Dimitry,
>
> On Tue, Sep 16, 2008 at 6:18 PM, Dmitry Potapov <dpotapov@gmail.com> wrote:
>> On Wed, Sep 17, 2008 at 01:40:36AM +0200, Michael Kerrisk wrote:
>>> $ git svn init file:///home/mtk/man-pages-rep/ -t tags -T trunk -b branches
>>>
>>> takes about half an hour to run, the other command (which I already
>>> started yesterday) seems to be taking (far) more than a day!
>> What version of Git do you use?
>
> 1.5.4.5, on Linux.
>
An upgrade would do you good.
>> If you use a version earlier than 1.5.6
>> than you can notice *considerable* speed up by upgrading to the latest
>
> How much is "considerable"? My import is *still* running.
>
The greatest factor will usually be network round trip time, so if
this is a one-shot conversion, rsync the repository to somewhere
close and run the import over a local network. I've had some "fun"
trying to import sourceforge svn repositories that were large-ish
but not huge (same seat you're in, basically), but since I get up
to 800ms round trip time from sweden, conversion took forever.
>>
>>> Therefore, so far, I have not had a chance to run the command to
>>> completion to see if it gives the desired result. The greatly
>>> increased tun time also made me suspicious about whether the command
>>> was going to do the right thing. And, I end up with a lot of strange
>>> looking tags in the (as yet incompletely) imported tree:
>>>
>>> $ git branch -a
>>> tags/man-pages-2.00
>>> tags/man-pages-2.00@117
>>> tags/man-pages-2.01
>>> tags/man-pages-2.01@145
>>> tags/man-pages-2.02
>>> tags/man-pages-2.02@184
>>> tags/man-pages-2.03
>>> tags/man-pages-2.03@232
>>> tags/man-pages-2.04
>>> tags/man-pages-2.04@283
>>>
>>> What are the @nnn tags about?
>> I have never encounted them. Are you sure that you import into a clean
>> Git repo?
>
> Yes. It's a clean repo in a new directory.
>
I've seen such tags before. They were added by an automatic build bot
as a marker to say "hey, I just built this".
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* git-svn checksum mismatch importing large file
From: Pascal Obry @ 2008-09-17 7:53 UTC (permalink / raw)
To: git list
[-- Attachment #1: Type: text/plain, Size: 737 bytes --]
I get this error:
Checksum mismatch: trunk/data
expected: 7c59e4dd67b5a9fde6c61cada070537b
got: 3fcd9d077a5aa51a784a452c9d78d6e0
To reproduce launch run.sh in attached archive.
I have had this problem since some time now and I finally got some time
to create a reproducer. I have reproduced this problem with yesterday
master Git version.
--
--|------------------------------------------------------
--| Pascal Obry Team-Ada Member
--| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE
--|------------------------------------------------------
--| http://www.obry.net
--| "The best way to travel is by means of imagination"
--|
--| gpg --keyserver wwwkeys.pgp.net --recv-key C1082595
[-- Attachment #2: bug-git.tar --]
[-- Type: application/octet-stream, Size: 10240 bytes --]
^ permalink raw reply
* combined diff, but not condensed, howto?
From: Johannes Sixt @ 2008-09-17 8:00 UTC (permalink / raw)
To: Git Mailing List
After a merge conflict, 'git diff' shows a combined diff, which presents
only the parts that conflicted or where there are near-by changes from
different parents (potential conflicts). Is there a command line switch so
that *all* changes are shown, even non-conflicting ones?
'git diff', 'git diff --cc', and 'git diff -c' all show the same output.
-- Hannes
^ permalink raw reply
* Re: [IRC/patches] Failed octopus merge does not clean up
From: Jakub Narebski @ 2008-09-17 8:11 UTC (permalink / raw)
To: Andreas Ericsson; +Cc: Junio C Hamano, Thomas Rast, git, Miklos Vajna
In-Reply-To: <48D0A776.1000009@op5.se>
Andreas Ericsson wrote:
> Jakub Narebski wrote:
> > Junio C Hamano wrote:
>>> (1) while it merges other heads one-by-one, it gets conflicts on an
>>> earlier one, before it even attempts to merge all of them. Recording
>>> the heads that it so far attempted to merge in MERGE_HEAD is wrong
>>> (the result won't be an Octopus the end user wanted to carete), and
>>> recording all the heads the user gave in MERGE_HEAD is even more
>>> wrong (it hasn't even looked at the later heads yet, so there is no
>>> way for the index or work tree to contain anything from them).
>>>
>>> The above is hitting this case.
[...]
>> BTW. does it mean that "git merge a b" might be not the same as
>> "git merge b a"?
>>
>
> No. Git merges all the sub-things together and then merges the result
> of that jumble into the branch you're on.
>
> Someone might have to correct me on that, but that's as far as I've
> understood it.
>From what I understand from above explanation, and from thread on git
mailing list about better implementation of and documenting finding
merge bases for multiple heads, I think octopus merge is done by merging
[reduced] heads one by one into given branch.
This means that "git merge a b" does internally "git merge a; git merge b"
as I understand it.
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: git-svn checksum mismatch importing large file
From: Björn Steinbrink @ 2008-09-17 8:25 UTC (permalink / raw)
To: Pascal Obry; +Cc: git list, Eric Wong, Avery Pennarun
In-Reply-To: <48D0B77E.7010308@obry.net>
On 2008.09.17 09:53:34 +0200, Pascal Obry wrote:
> I get this error:
>
> Checksum mismatch: trunk/data
> expected: 7c59e4dd67b5a9fde6c61cada070537b
> got: 3fcd9d077a5aa51a784a452c9d78d6e0
>
> To reproduce launch run.sh in attached archive.
>
> I have had this problem since some time now and I finally got some time
> to create a reproducer. I have reproduced this problem with yesterday
> master Git version.
Your /tmp is probably to small to hold the temporary file that git-svn
creates. At least it doesn't fail for me unless I fill my /tmp first.
This should be fixed since 29c70e0b3e3183f86f93500882177d0c74069988, at
least it got me a useful error message when I tested it back then.
Avery, any ideas?
Björn
^ permalink raw reply
* Re: Getting correct tree layout when importing svn repo into git
From: Michael J Gruber @ 2008-09-17 8:25 UTC (permalink / raw)
To: mtk.manpages; +Cc: git, michael.kerrisk
In-Reply-To: <cfd18e0f0809161505g4c04bd88vaf4fd7c40f67b243@mail.gmail.com>
Michael Kerrisk venit, vidit, dixit 17.09.2008 00:05:
> Hello,
>
> I'm currently trying to import an svn repository, along with its tags,
> into git, and everything seems okay except that after the import I
> expect to have the following structure to my checked out repository:
>
> [root-dir]
> .git
> <checked-out-files>
>
> But instead I end up with
>
> [root-dir]
> .git
> man-pages <-- name of my svn project
> <checked-out-files>
>
> I've tried out a few different command-line flag settings but so far I
> haven't managed to get the desired layout. I guess that I'm missing
> something trivial, but I haven't worked out what it is so far.
>
> The commands I'm using to do the import are:
>
> $ git svn init file:///home/mtk/man-pages-rep/ -t tags -T trunk -b branches
> $ git svn fetch
>
> The svn tags are getting imported okay, since:
>
> git branch -a | head
> tags/man-pages-2.00
> tags/man-pages-2.01
> ...
> tags/man-pages-3.08
> tags/man-pages-3.09
> trunk
>
> The following commands show the layout of my svn repo, which is pretty
> much standard:
>
> $ svn list file:///home/mtk/man-pages-rep
> branches/
> tags/
> trunk/
> $ svn list file:///home/mtk/man-pages-rep/trunk
> man-pages/
That's the part that says that your layout is non-standard. What do your
branches and tags look like? Do they have that superfluous "man-pages"
part as well?
> $ svn list file:///home/mtk/man-pages-rep/trunk/man-pages
> Changes
> Changes.old
> Makefile
> README
> man-pages-3.09.Announce
> ...
> man7/
> man8/
> scripts/
> $ svn list file:///home/mtk/man-pages-rep/tags
> man-pages-2.00/
> man-pages-2.01/
> ...
> man-pages-3.08/
> man-pages-3.09/
>
> What 'git svn init' command do I need to get the layout that I want
> for my imported git repo?
It depends on the structure of your branches and tags. My guess would be
that you have something like tags/man-pages-2.00/man-pages/ etc., in
which case you would need a special configuration if you want to get rid
of the "man-pages" part. Tells us your structure, we'll tell you the
config ;)
Also, updating your git is strongly advised, but unrelated to the
problem at hand.
Michael
^ permalink raw reply
* Re: Teach git status to do "git diff --name-status HEAD"
From: Michael J Gruber @ 2008-09-17 8:42 UTC (permalink / raw)
To: Martin Langhoff; +Cc: Git Mailing List
In-Reply-To: <aba84270809162340n4ea3f5feqc71d01fa6e035b79@mail.gmail.com>
Martin Langhoff venit, vidit, dixit 17.09.2008 08:40:
> I just did
>
> $ git checkout -b mdl19-offlinetony
> A README.offline
> M lib/javascript.php
> (...)
> A lib/offline/offlinemoodle.user.js
>
> I *like* this "brief status" style - takes me back to my cvs days :-).
> Perusing the source I found show_local_changes() which in turn led me
> to trying `git diff --name-status HEAD`. Now, including 'HEAD' in an
> alias defined in git config is going to lead to trouble... :-/
Nice!
HEAD is default, no need to stick your HEAD into the config ;)
> I might still make an alias to `git diff --name-status`. This would be
> a great thing to have as git status "--brief" IMHO... :-)
git status also shows untracked files. I don't know how to tell diff to
show untracked files as well. --diff-filter=X doesn't do it.
Michael
^ permalink raw reply
* Re: [PATCH 15/16] checkout: add new options to support narrow checkout
From: Jakub Narebski @ 2008-09-17 9:07 UTC (permalink / raw)
To: Nguyen Thai Ngoc Duy; +Cc: git
In-Reply-To: <fcaeb9bf0809160521o24fd26e4l40f1798228d51712@mail.gmail.com>
On Tue, 16 Sep 2008, Nguyen Thai Ngoc Duy wrote:
> On 9/16/08, Jakub Narebski <jnareb@gmail.com> wrote:
>>>> Couldn't you simply escape ':', i.e. write for example Git\:\:Tag.3pm,
>>>> or Eichten_PRD21\:313,1980_erratum.tex, or \:0.log, or perhaps
>>>> kmail/jnareb@gmail.com\:@pop.gmail.com\:995, or even something like
>>>> Mail/inbox/cur/1194202360.32296.mprnq\:2,S, in the same way like you
>>>> can escape other special characters, for example wildcard characters
>>>> like '\*' for '*' and '\?' for '?', and of course '\\' for '\'?
>>>
>>> Sure. Somehow I forgot that.
>>
>> Well, if it is possible, it should be stated in documentation.
>> Even if it is obvious.
>
> I mean it should be possible, but not yet implemented. Next time
> document will be updated when '\' escape is implemented.
I was thinking about explicitly stating this limitation (that ':' in
paths are not permitted/can be not escaped), or put it in "Bugs" aka
"Known Limitations" ;-) (sub)section.
>>> --<--
>>> Narrow checkout
>>> ---------------
>>>
>>> Normally when you do checkout a branch, your working directory
>>> will be fully populated. In some situations, you just need to
>>> work on certain files, no full checkout is needed. Narrow
>>> checkout is a mode that limits checkout area according to your
>>> needs.
>>
>> You have decided then on the term 'narrow checkout', and not
>> 'partial checkout' or 'sparse checkout', then?
>
> Not yet. I tend to prefer partial/sparse checkout. Probably should
> have a look at how other SCMs do and what term they use. If Git's
> functionality is so different, a different term might notice people
> about that.
Perhaps whip up a survey? Just kidding (or not).
>>> Because narrow checkout uses new index format, it will be
>>> incompatible with git prior to 1.6.0 regarding worktree operations.
>>> Repository-only operations such as clone, push, pull... should not be
>>
>> s/pull/fetch/. pull affects working repository, and it can affect
>> narrow checkout unexpectedly by conflicts during merge part of pull.
>
> Bad writing. I mean pull/fetch from a narrow-checkout-ed repository to
> another fully populated one. Will fix.
Well, I though that you were referring to operations done _inside_
given repository, not on repository from outside. So I would say
something like repository-only operations (operations which do
not affect index and/or working area) such as fetch and pull, and
by definition all remote operations such as fetching from repository,
or cloning this repository... but this also isn't IMHO best way to
say it.
>>> affected by narrow checkout. In order to make your working directory
>>> work again with those versions, you can use `git checkout --full` to
>>> return to normal mode (and compatible index format).
>>
>>
>> By the way, you have made "git checkout <file>" get file and mark
>> it "wanted", i.e. clear/zero "no-checkout" bit. Wouldn't then
>> "git checkout ." be shorter equivalent to "git checkout --full"?
>> I'm not saying that '--full' option should be abandoned...
>
> It is not equivalent. "git checkout ." will happily overwrite any
> modified files in your working directory.
True, I fortgot about this. Sorry, my mistake.
>>> When you apply new narrow spec to your working directory using either
>>> --path, --add-path or --remove-path, it will update "checkout" status
>>> in index accordingly. Moreover, if a file is marked "no-checkout" and
>>> is present in working directory, it will be removed. If a file is
>>> turned from "no-checkout" to "checkout", then it will be added again
>>> to working directory. Modified and unmerged entries can't bear
>>> "no-checkout" status, if narrow spec applies to them, "git checkout"
>>> will refuse to update working directory.
>>
>>
>> Do I understand correctly, that if one uses --path=<colon separated list>
>> _only_ filenames matching one of patterns specified would be checked out,
>> --add-path=<path> would additionally checkout given path and mark "wanted",
>> and --remove-path=<path> would additionally mark "no-checkout" and remove
>> path?
>
> --add-path/--remove-path also use narrow spec, which could be more
> than one pattern.
What is the difference then between --add-path and --path? The fact
that --add-path can be incremental, and --path starts always from
an empty set?
>> What --add-path starts from, i.e. does
>>
>> $ git checkout --add-path=.gitignore
>>
>> starts from empty set if --add-path is first, or from full set as without
>> --add-path?
>
> I'm not sure I understand this.
Well, what I wanted to ask is if --remove-path starts from fully
checked out repository, for example if
$ git checkout --remove-path=some_large_file
would checkout all files _except_ 'some_large_file'.
>> And is <pathspec> matched against full pathname, or like .gitignore
>> rules, i.e. as full pathname if it has at least one '/' in it?
>
> like shell wildcard, full pathname must match. On my way back home, I
> thought I should have removed mention of "pathspec", which behaves a
> little bit different.
>
> Also those specs are relative to working directory though, so if you
> are in b/c and want to match d, you only need to type --add-path=d
> instead of --add-path=b/c/d. Will add this to doc.
I would have thought that you follow the same rules (perhaps with
exception of !path excluding rule) like for gitignore and gitattributes.
--
Jakub Narebski
Poland
^ permalink raw reply
* GIT presentation
From: Paolo Ciarrocchi @ 2008-09-17 9:08 UTC (permalink / raw)
To: Git Mailing List
Hi all,
some friend part of a LUG asked me to do a quick
presentation/introduction to GIT
to a group of people probably completely unaware of it.
Is there any available presentation that I can as a base for my presentation?
I'm of course, more then willing to publish the work a let everybody
to use/modify it.
Thanks.
Ciao,
--
Paolo
http://paolo.ciarrocchi.googlepages.com/
^ permalink raw reply
* Re: GIT presentation
From: Johan Herland @ 2008-09-17 9:32 UTC (permalink / raw)
To: Paolo Ciarrocchi; +Cc: git
In-Reply-To: <4d8e3fd30809170208t3730cde1t4cbcdb1e609d6be6@mail.gmail.com>
On Wednesday 17 September 2008, Paolo Ciarrocchi wrote:
> Hi all,
> some friend part of a LUG asked me to do a quick
> presentation/introduction to GIT
> to a group of people probably completely unaware of it.
>
> Is there any available presentation that I can as a base for my
> presentation?
There are several:
Bart Trojanowski: Ottawa Group of Ruby Enthusiasts:
http://excess.org/article/2008/07/ogre-git-tutorial/
Scott Chacon: RailsConf 2008 Git Tech Talk:
http://www.gitcasts.com/git-talk
Randal Schwartz, Google Tech Talk:
http://video.google.com/videoplay?docid=-3999952944619245780
(can't seem to find the slides from this one...)
There's also lots of resources on the Git Wiki:
http://git.or.cz/gitwiki/GitDocumentation
Have fun!
...Johan
--
Johan Herland, <johan@herland.net>
www.herland.net
^ permalink raw reply
* Re: git-svn checksum mismatch importing large file
From: Pascal Obry @ 2008-09-17 9:39 UTC (permalink / raw)
To: Björn Steinbrink; +Cc: git list, Eric Wong, Avery Pennarun
In-Reply-To: <20080917082506.GA8849@atjola.homenet>
Björn,
> Your /tmp is probably to small to hold the temporary file that git-svn
> creates. At least it doesn't fail for me unless I fill my /tmp first.
Hum probably, I did not thought about this given the error message!
> This should be fixed since 29c70e0b3e3183f86f93500882177d0c74069988, at
> least it got me a useful error message when I tested it back then.
> Avery, any ideas?
I'm using Git on master. This commit is there, the error message is not
that useful on my side :)
Anyway, what's the best option? Is there a way to specify another tmp
directory to use with git-svn?
--
--|------------------------------------------------------
--| Pascal Obry Team-Ada Member
--| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE
--|------------------------------------------------------
--| http://www.obry.net
--| "The best way to travel is by means of imagination"
--|
--| gpg --keyserver wwwkeys.pgp.net --recv-key C1082595
^ permalink raw reply
* Re: git-svn checksum mismatch importing large file
From: Björn Steinbrink @ 2008-09-17 10:07 UTC (permalink / raw)
To: Pascal Obry; +Cc: git list, Eric Wong, Avery Pennarun
In-Reply-To: <48D0D03B.4040108@obry.net>
On 2008.09.17 11:39:07 +0200, Pascal Obry wrote:
> > Your /tmp is probably to small to hold the temporary file that git-svn
> > creates. At least it doesn't fail for me unless I fill my /tmp first.
>
> Hum probably, I did not thought about this given the error message!
Yeah, I only came up with the idea because of the previous breakage,
otherwise I'd not have guessed that either :-)
> > This should be fixed since 29c70e0b3e3183f86f93500882177d0c74069988, at
> > least it got me a useful error message when I tested it back then.
> > Avery, any ideas?
>
> I'm using Git on master. This commit is there, the error message is not
> that useful on my side :)
Yeah, I tested with yesterday's master as well, thus I was asking Avery
if he has any clue of what's going on. Should probably have mentioned
that...
> Anyway, what's the best option? Is there a way to specify another tmp
> directory to use with git-svn?
Looks like the code honors the TMPDIR environment variable, but I didn't
actually try that.
Björn
^ permalink raw reply
* Re: [ANNOUNCE] TopGit v0.3
From: Petr Baudis @ 2008-09-17 10:11 UTC (permalink / raw)
To: Michael Radziej; +Cc: git
In-Reply-To: <20080915080131.GA30396@noris.de>
Hi,
On Mon, Sep 15, 2008 at 10:01:31AM +0200, Michael Radziej wrote:
> I wonder about the .topmsg and .topdeps files. Why is this information
> within the topic branch? It tends to get into the way even though a special
> merge driver is provided. For example, you cannot do octopus merges (which I
> found very confusing as first-time user).
what do octopus merge have to do with that? If these files prevent
octopus merges somehow, I think that'd be a Git bug. (TopGit making
octopus merges whenever possible is deep on my mental TODO list.)
> And it might also confuse people
> cloning a TopGit repository and want to use a topgit branch. They might not
> be aware of these special TopGit things.
They need to be properly educated by whoever gives them the clone URL.
Using TopGit branches outside of TopGit is still dangerous - they have
*unholy* history and they are not really suitable for non-TopGit merging
etc. If TopGit users want non-TopGit users to use their work, they
should tg export.
> I'd rather have a dedicated branched named e.g. 'TopGit' which includes the
> information that is currently in .topmsg and .topdeps, but for all branches
> in a repository.
This was indeed a difficult design decision, perhaps the most major
one I had to make. Both approaches have their pros and cons, and in the
end I chose the .top* files mainly to keep the changes atomicity - if
you revert your branch to older version, your .topmsg and .topdeps are
rewound appropriately as well, and if you change something in your
branch that affects your topmessage, these changes are connected
appropriately. Also, you do not need to use special tools to edit your
top message and merges are much simpler than if you had to merge two
people's work on a single branch (besides, the merge semantics of the
TopGit branch would be really, really nasty, perhaps downright
impossible to specify properly).
Hmm, well, oops. Merging of two people's work on a single branch is
broken right now anyway, because we unconditionally use our 'ours' merge
driver in these cases. I wonder how to fix this best... swapping two
gitattributes files in .git/info/attributes during tg update seems like
the only solution to me.
--
Petr "Pasky" Baudis
The next generation of interesting software will be done
on the Macintosh, not the IBM PC. -- Bill Gates
^ permalink raw reply
* Re: Getting correct tree layout when importing svn repo into git
From: Michael Kerrisk @ 2008-09-17 10:28 UTC (permalink / raw)
To: Andreas Ericsson
Cc: Michael Kerrisk, Dmitry Potapov, git, michael.kerrisk,
Michael J Gruber
In-Reply-To: <48D0AA1A.5060209@op5.se>
Hi Andreas,
On Tue, Sep 16, 2008 at 11:56 PM, Andreas Ericsson <ae@op5.se> wrote:
> Michael Kerrisk wrote:
>>
>> Hi Dimitry,
>>
>> On Tue, Sep 16, 2008 at 6:18 PM, Dmitry Potapov <dpotapov@gmail.com>
>> wrote:
>>>
>>> On Wed, Sep 17, 2008 at 01:40:36AM +0200, Michael Kerrisk wrote:
>>>>
>>>> $ git svn init file:///home/mtk/man-pages-rep/ -t tags -T trunk -b
>>>> branches
>>>>
>>>> takes about half an hour to run, the other command (which I already
>>>> started yesterday) seems to be taking (far) more than a day!
>>>
>>> What version of Git do you use?
>>
>> 1.5.4.5, on Linux.
>>
>
> An upgrade would do you good.
But, is it going to make this much difference to the run time? By
now, the import using
$ git svn init file:///home/mtk/man-pages-rep/ -t tags -T
trunk/man-pages -b branches
has been running for over 2 days (and I still don't know if it will
give the layout I want), and seems to be slowing down exponentially as
it gets further along in the import process, so at this rate it looks
like it would take several more days to complete, whereas
$ git svn init file:///home/mtk/man-pages-rep/ -t tags -T trunk -b branches
which doesn't give the layout I want, takes less than an hour. We're
talking about a factor of at least 100 x in the speed difference for
the two imports.
>>> If you use a version earlier than 1.5.6
>>> than you can notice *considerable* speed up by upgrading to the latest
>>
>> How much is "considerable"? My import is *still* running.
>>
>
> The greatest factor will usually be network round trip time, so if
> this is a one-shot conversion, rsync the repository to somewhere
> close and run the import over a local network. I've had some "fun"
> trying to import sourceforge svn repositories that were large-ish
> but not huge (same seat you're in, basically), but since I get up
> to 800ms round trip time from sweden, conversion took forever.
Perhaps I should have stated earleir, that the import is from a local
svn repo (note the 'file:///' in the 'git svn init'...). 176 MB, land
less than 5000 commits.
Cheers,
Michael
>>>> Therefore, so far, I have not had a chance to run the command to
>>>> completion to see if it gives the desired result. The greatly
>>>> increased tun time also made me suspicious about whether the command
>>>> was going to do the right thing. And, I end up with a lot of strange
>>>> looking tags in the (as yet incompletely) imported tree:
>>>>
>>>> $ git branch -a
>>>> tags/man-pages-2.00
>>>> tags/man-pages-2.00@117
>>>> tags/man-pages-2.01
>>>> tags/man-pages-2.01@145
>>>> tags/man-pages-2.02
>>>> tags/man-pages-2.02@184
>>>> tags/man-pages-2.03
>>>> tags/man-pages-2.03@232
>>>> tags/man-pages-2.04
>>>> tags/man-pages-2.04@283
>>>>
>>>> What are the @nnn tags about?
>>>
>>> I have never encounted them. Are you sure that you import into a clean
>>> Git repo?
>>
>> Yes. It's a clean repo in a new directory.
>>
>
> I've seen such tags before. They were added by an automatic build bot
> as a marker to say "hey, I just built this".
>
> --
> Andreas Ericsson andreas.ericsson@op5.se
> OP5 AB www.op5.se
> Tel: +46 8-230225 Fax: +46 8-230231
>
--
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
man-pages online: http://www.kernel.org/doc/man-pages/online_pages.html
Found a bug? http://www.kernel.org/doc/man-pages/reporting_bugs.html
^ permalink raw reply
* Re: Getting correct tree layout when importing svn repo into git
From: Michael Kerrisk @ 2008-09-17 10:38 UTC (permalink / raw)
To: Michael J Gruber; +Cc: git, michael.kerrisk
In-Reply-To: <48D0BEF1.10008@drmicha.warpmail.net>
Hello Michael,
On Wed, Sep 17, 2008 at 1:25 AM, Michael J Gruber
<git@drmicha.warpmail.net> wrote:
> Michael Kerrisk venit, vidit, dixit 17.09.2008 00:05:
>> Hello,
>>
>> I'm currently trying to import an svn repository, along with its tags,
>> into git, and everything seems okay except that after the import I
>> expect to have the following structure to my checked out repository:
>>
>> [root-dir]
>> .git
>> <checked-out-files>
>>
>> But instead I end up with
>>
>> [root-dir]
>> .git
>> man-pages <-- name of my svn project
>> <checked-out-files>
>>
>> I've tried out a few different command-line flag settings but so far I
>> haven't managed to get the desired layout. I guess that I'm missing
>> something trivial, but I haven't worked out what it is so far.
>>
>> The commands I'm using to do the import are:
>>
>> $ git svn init file:///home/mtk/man-pages-rep/ -t tags -T trunk -b branches
>> $ git svn fetch
>>
>> The svn tags are getting imported okay, since:
>>
>> git branch -a | head
>> tags/man-pages-2.00
>> tags/man-pages-2.01
>> ...
>> tags/man-pages-3.08
>> tags/man-pages-3.09
>> trunk
>>
>> The following commands show the layout of my svn repo, which is pretty
>> much standard:
>>
>> $ svn list file:///home/mtk/man-pages-rep
>> branches/
>> tags/
>> trunk/
>> $ svn list file:///home/mtk/man-pages-rep/trunk
>> man-pages/
>
> That's the part that says that your layout is non-standard. What do your
> branches and tags look like? Do they have that superfluous "man-pages"
> part as well?
$ svn list file:///home/mtk/man-pages-rep/tags
man-pages-2.00
man-pages-2.01
man-pages-2.02
man-pages-2.03
...
$ svn list file:///home/mtk/man-pages-rep/tags/man-pages-2.00
man-pages
$ svn list file:///home/mtk/man-pages-rep/tags/man-pages-2.01
man-pages
[and so on]
$ svn list file:///home/mtk/man-pages-rep/branches
$
(i.e., no branches, since this has been a linear svn repo.)
>> $ svn list file:///home/mtk/man-pages-rep/trunk/man-pages
>> Changes
>> Changes.old
>> Makefile
>> README
>> man-pages-3.09.Announce
>> ...
>> man7/
>> man8/
>> scripts/
>> $ svn list file:///home/mtk/man-pages-rep/tags
>> man-pages-2.00/
>> man-pages-2.01/
>> ...
>> man-pages-3.08/
>> man-pages-3.09/
>>
>> What 'git svn init' command do I need to get the layout that I want
>> for my imported git repo?
>
> It depends on the structure of your branches and tags. My guess would be
> that you have something like tags/man-pages-2.00/man-pages/ etc., in
> which case you would need a special configuration if you want to get rid
> of the "man-pages" part. Tells us your structure, we'll tell you the
> config ;)
Do you now have enough info above?
Thanks,
Michael
--
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
man-pages online: http://www.kernel.org/doc/man-pages/online_pages.html
Found a bug? http://www.kernel.org/doc/man-pages/reporting_bugs.html
^ permalink raw reply
* Re: Getting correct tree layout when importing svn repo into git
From: Michael Gebetsroither @ 2008-09-17 10:42 UTC (permalink / raw)
To: git
In-Reply-To: <cfd18e0f0809170328pb039331m1c4dc42fd398a4d@mail.gmail.com>
* Michael Kerrisk <mtk.manpages@googlemail.com> wrote:
> But, is it going to make this much difference to the run time? By
> now, the import using
>
> $ git svn init file:///home/mtk/man-pages-rep/ -t tags -T
> trunk/man-pages -b branches
>
> has been running for over 2 days (and I still don't know if it will
> give the layout I want), and seems to be slowing down exponentially as
> it gets further along in the import process, so at this rate it looks
> like it would take several more days to complete, whereas
git-svn conversions are _much_ faster here if done on tmpfs with
occasional git gc runs (in parallel).
May be the fault of the xfs.
cu,
michael
--
It's already too late!
^ permalink raw reply
* Re: [ANNOUNCE] TopGit v0.3
From: Jan Nieuwenhuizen @ 2008-09-17 10:48 UTC (permalink / raw)
To: martin f krafft; +Cc: Petr Baudis, git
In-Reply-To: <20080912181442.GA5407@lapse.rw.madduck.net>
On vr, 2008-09-12 at 19:14 +0100, martin f krafft wrote:
> I've considered this question a lot before and could not come up
> with anything; you cannot undo a merge.
Isn't that overly pessimistic? Can't we have git create a merge
commit that can be reverted with git revert?
For our ooo-build use case, I'm hoping to use [top]git as "a better
patch" and hope to have mostly orthogonal topic branches. With patch,
to "undo a merge" usually means patch -R and remove the patch from
the dependency list. I can hardly imagine something easily possible
with patch is still impossible with git.
Greetings,
Jan.
--
Jan Nieuwenhuizen <janneke@gnu.org> | GNU LilyPond - The music typesetter
http://www.xs4all.nl/~jantien | http://www.lilypond.org
^ permalink raw reply
* [PATCH] Teach git diff about Objective-C syntax
From: Jonathan del Strother @ 2008-09-17 10:49 UTC (permalink / raw)
To: git; +Cc: vmiklos, Jonathan del Strother
In-Reply-To: <1221610063-33610-1-git-send-email-jon.delStrother@bestbefore.tv>
Add support for recognition of Objective-C class & instance methods, C functions, and class implementation/interfaces.
Signed-off-by: Jonathan del Strother <jon.delStrother@bestbefore.tv>
---
This version of the patch adds the negate line to avoid picking up if()/while()/etc statements as funcnames
I also took the liberty of replacing the invisible tab characters in the java pattern with \t's - is that OK?
Documentation/gitattributes.txt | 2 ++
diff.c | 19 ++++++++++++++-----
2 files changed, 16 insertions(+), 5 deletions(-)
diff --git a/Documentation/gitattributes.txt b/Documentation/gitattributes.txt
index 6f3551d..c1f13e2 100644
--- a/Documentation/gitattributes.txt
+++ b/Documentation/gitattributes.txt
@@ -315,6 +315,8 @@ patterns are available:
- `java` suitable for source code in the Java language.
+- `objc` suitable for source code in the Objective-C language.
+
- `pascal` suitable for source code in the Pascal/Delphi language.
- `php` suitable for source code in the PHP language.
diff --git a/diff.c b/diff.c
index 998dcaa..fdfdf26 100644
--- a/diff.c
+++ b/diff.c
@@ -1398,17 +1398,26 @@ static struct builtin_funcname_pattern {
} builtin_funcname_pattern[] = {
{ "bibtex", "\\(@[a-zA-Z]\\{1,\\}[ \t]*{\\{0,1\\}[ \t]*[^ \t\"@',\\#}{~%]*\\).*$" },
{ "html", "^\\s*\\(<[Hh][1-6]\\s.*>.*\\)$" },
- { "java", "!^[ ]*\\(catch\\|do\\|for\\|if\\|instanceof\\|"
+
+ { "java", "!^[ \t]*\\(catch\\|do\\|for\\|if\\|instanceof\\|"
"new\\|return\\|switch\\|throw\\|while\\)\n"
- "^[ ]*\\(\\([ ]*"
+ "^[ \t]*\\(\\([ \t]*"
"[A-Za-z_][A-Za-z_0-9]*\\)\\{2,\\}"
- "[ ]*([^;]*\\)$" },
+ "[ \t]*([^;]*\\)$" },
+
+ { "objc", "![ \t]*\\(do\\|for\\|if\\|else\\|return\\|switch\\|while\\)\n" /* Negate C statements that can look like functions */
+ "^[ \t]*\\([-+][ \t]*([ \t]*[A-Za-z_][A-Za-z_0-9]*.*).*\\)$" /* Objective-C methods */
+ "\\|"
+ "^[ \t]*\\(\\([ \t]*[A-Za-z_][A-Za-z_0-9]*\\)\\{2,\\}[ \t]*([^;]*\\)$" /* C functions */
+ "\\|"
+ "^@\\(implementation\\|interface\\|protocol\\).*"}, /* Objective-C class/protocol definitions */
+
{ "pascal", "^\\(\\(procedure\\|function\\|constructor\\|"
"destructor\\|interface\\|implementation\\|"
"initialization\\|finalization\\)[ \t]*.*\\)$"
"\\|"
- "^\\(.*=[ \t]*\\(class\\|record\\).*\\)$"
- },
+ "^\\(.*=[ \t]*\\(class\\|record\\).*\\)$"},
+
{ "php", "^[\t ]*\\(\\(function\\|class\\).*\\)" },
{ "python", "^\\s*\\(\\(class\\|def\\)\\s.*\\)$" },
{ "ruby", "^\\s*\\(\\(class\\|module\\|def\\)\\s.*\\)$" },
--
1.6.0.2.250.g2fdd2.dirty
^ permalink raw reply related
* Re: Getting correct tree layout when importing svn repo into git
From: Björn Steinbrink @ 2008-09-17 10:56 UTC (permalink / raw)
To: mtk.manpages
Cc: Andreas Ericsson, Michael Kerrisk, Dmitry Potapov, git,
michael.kerrisk, Michael J Gruber
In-Reply-To: <cfd18e0f0809170328pb039331m1c4dc42fd398a4d@mail.gmail.com>
On 2008.09.17 03:28:46 -0700, Michael Kerrisk wrote:
> Hi Andreas,
>
> On Tue, Sep 16, 2008 at 11:56 PM, Andreas Ericsson <ae@op5.se> wrote:
> > Michael Kerrisk wrote:
> >>
> >> Hi Dimitry,
> >>
> >> On Tue, Sep 16, 2008 at 6:18 PM, Dmitry Potapov <dpotapov@gmail.com>
> >> wrote:
> >>>
> >>> On Wed, Sep 17, 2008 at 01:40:36AM +0200, Michael Kerrisk wrote:
> >>>>
> >>>> $ git svn init file:///home/mtk/man-pages-rep/ -t tags -T trunk -b
> >>>> branches
> >>>>
> >>>> takes about half an hour to run, the other command (which I already
> >>>> started yesterday) seems to be taking (far) more than a day!
> >>>
> >>> What version of Git do you use?
> >>
> >> 1.5.4.5, on Linux.
> >>
> >
> > An upgrade would do you good.
>
> But, is it going to make this much difference to the run time? By
> now, the import using
It should.
> $ git svn init file:///home/mtk/man-pages-rep/ -t tags -T
> trunk/man-pages -b branches
>
> has been running for over 2 days (and I still don't know if it will
> give the layout I want), and seems to be slowing down exponentially as
> it gets further along in the import process, so at this rate it looks
> like it would take several more days to complete, whereas
>
> $ git svn init file:///home/mtk/man-pages-rep/ -t tags -T trunk -b branches
>
> which doesn't give the layout I want, takes less than an hour. We're
> talking about a factor of at least 100 x in the speed difference for
> the two imports.
I guess your old import doesn't see any relations between the trunk and
the tags/branches, right? Then the huge increase in runtime would be, at
least in part, explained by git-svn searching for ancestry. That you see
those tags/1.2.3@123 things also means that the 1.2.3 tags got deleted
and recreated, or at least git-svn thinks so. Maybe the ancestry
detection goes nuts, hard to tell.
Is that svn repo available anywhere?
Björn
^ permalink raw reply
* Re: Teach git status to do "git diff --name-status HEAD"
From: Jakub Narebski @ 2008-09-17 11:04 UTC (permalink / raw)
To: Michael J Gruber; +Cc: Martin Langhoff, Git Mailing List
In-Reply-To: <48D0C2DF.7010308@drmicha.warpmail.net>
Michael J Gruber <git@drmicha.warpmail.net> writes:
> Martin Langhoff venit, vidit, dixit 17.09.2008 08:40:
> > I just did
> >
> > $ git checkout -b mdl19-offlinetony
> > A README.offline
> > M lib/javascript.php
> > (...)
> > A lib/offline/offlinemoodle.user.js
> >
> > I *like* this "brief status" style - takes me back to my cvs days :-).
> > Perusing the source I found show_local_changes() which in turn led me
> > to trying `git diff --name-status HEAD`. Now, including 'HEAD' in an
> > alias defined in git config is going to lead to trouble... :-/
[...]
> > I might still make an alias to `git diff --name-status`. This would be
> > a great thing to have as git status "--brief" IMHO... :-)
>
> git status also shows untracked files. I don't know how to tell diff to
> show untracked files as well. --diff-filter=X doesn't do it.
git-ls-files?
--
Jakub Narebski
Poland
ShadeHawk on #git
^ permalink raw reply
* Re: Getting correct tree layout when importing svn repo into git
From: Björn Steinbrink @ 2008-09-17 11:05 UTC (permalink / raw)
To: mtk.manpages; +Cc: Michael J Gruber, git, michael.kerrisk
In-Reply-To: <cfd18e0f0809170338v168c2991ma3964392e44e0194@mail.gmail.com>
On 2008.09.17 03:38:12 -0700, Michael Kerrisk wrote:
> $ svn list file:///home/mtk/man-pages-rep/tags
> man-pages-2.00
> man-pages-2.01
> man-pages-2.02
> man-pages-2.03
> ...
> $ svn list file:///home/mtk/man-pages-rep/tags/man-pages-2.00
> man-pages
> $ svn list file:///home/mtk/man-pages-rep/tags/man-pages-2.01
> man-pages
> [and so on]
> $ svn list file:///home/mtk/man-pages-rep/branches
> $
> (i.e., no branches, since this has been a linear svn repo.)
That means that you also need to pass the "man-pages" suffix for the
tags and branches.
git svn clone file:///path/to/repo \
-T trunk/man-pages \
-b branches/*/man-pages \
-t tags/*/man-pages
Might require a more recent git-svn version, not sure about that.
Björn
^ permalink raw reply
* Re: [PATCH] Teach git diff about Objective-C syntax
From: Johannes Schindelin @ 2008-09-17 11:06 UTC (permalink / raw)
To: Jonathan del Strother; +Cc: git, vmiklos
In-Reply-To: <1221648564-56239-1-git-send-email-jon.delStrother@bestbefore.tv>
Hi,
On Wed, 17 Sep 2008, Jonathan del Strother wrote:
> - "^[ ]*\\(\\([ ]*"
> + "^[ \t]*\\(\\([ \t]*"
Why?
> "[A-Za-z_][A-Za-z_0-9]*\\)\\{2,\\}"
> - "[ ]*([^;]*\\)$" },
> + "[ \t]*([^;]*\\)$" },
> +
> + { "objc", "![ \t]*\\(do\\|for\\|if\\|else\\|return\\|switch\\|while\\)\n" /* Negate C statements that can look like functions */
> + "^[ \t]*\\([-+][ \t]*([ \t]*[A-Za-z_][A-Za-z_0-9]*.*).*\\)$" /* Objective-C methods */
I see you still have these awfully long lines.
Ciao,
Dscho
^ permalink raw reply
* Re: Getting correct tree layout when importing svn repo into git
From: Michael J Gruber @ 2008-09-17 11:14 UTC (permalink / raw)
To: mtk.manpages; +Cc: git, michael.kerrisk
In-Reply-To: <cfd18e0f0809170338v168c2991ma3964392e44e0194@mail.gmail.com>
Michael Kerrisk venit, vidit, dixit 17.09.2008 12:38:
> Hello Michael,
>
> On Wed, Sep 17, 2008 at 1:25 AM, Michael J Gruber
> <git@drmicha.warpmail.net> wrote:
>> Michael Kerrisk venit, vidit, dixit 17.09.2008 00:05:
>>> Hello,
>>>
>>> I'm currently trying to import an svn repository, along with its tags,
>>> into git, and everything seems okay except that after the import I
>>> expect to have the following structure to my checked out repository:
>>>
>>> [root-dir]
>>> .git
>>> <checked-out-files>
>>>
>>> But instead I end up with
>>>
>>> [root-dir]
>>> .git
>>> man-pages <-- name of my svn project
>>> <checked-out-files>
>>>
>>> I've tried out a few different command-line flag settings but so far I
>>> haven't managed to get the desired layout. I guess that I'm missing
>>> something trivial, but I haven't worked out what it is so far.
>>>
>>> The commands I'm using to do the import are:
>>>
>>> $ git svn init file:///home/mtk/man-pages-rep/ -t tags -T trunk -b branches
>>> $ git svn fetch
>>>
>>> The svn tags are getting imported okay, since:
>>>
>>> git branch -a | head
>>> tags/man-pages-2.00
>>> tags/man-pages-2.01
>>> ...
>>> tags/man-pages-3.08
>>> tags/man-pages-3.09
>>> trunk
>>>
>>> The following commands show the layout of my svn repo, which is pretty
>>> much standard:
>>>
>>> $ svn list file:///home/mtk/man-pages-rep
>>> branches/
>>> tags/
>>> trunk/
>>> $ svn list file:///home/mtk/man-pages-rep/trunk
>>> man-pages/
>> That's the part that says that your layout is non-standard. What do your
>> branches and tags look like? Do they have that superfluous "man-pages"
>> part as well?
>
> $ svn list file:///home/mtk/man-pages-rep/tags
> man-pages-2.00
> man-pages-2.01
> man-pages-2.02
> man-pages-2.03
> ...
> $ svn list file:///home/mtk/man-pages-rep/tags/man-pages-2.00
> man-pages
> $ svn list file:///home/mtk/man-pages-rep/tags/man-pages-2.01
> man-pages
> [and so on]
Bingo!
> $ svn list file:///home/mtk/man-pages-rep/branches
> $
> (i.e., no branches, since this has been a linear svn repo.)
git-svn converts svn tags into git branches (because they can change).
So you will get a git repo with lots of branches which are subsets (HEAD
commit is in master/trunk) of master/trunk.
>>> $ svn list file:///home/mtk/man-pages-rep/trunk/man-pages
>>> Changes
>>> Changes.old
>>> Makefile
>>> README
>>> man-pages-3.09.Announce
>>> ...
>>> man7/
>>> man8/
>>> scripts/
>>> $ svn list file:///home/mtk/man-pages-rep/tags
>>> man-pages-2.00/
>>> man-pages-2.01/
>>> ...
>>> man-pages-3.08/
>>> man-pages-3.09/
>>>
>>> What 'git svn init' command do I need to get the layout that I want
>>> for my imported git repo?
>> It depends on the structure of your branches and tags. My guess would be
>> that you have something like tags/man-pages-2.00/man-pages/ etc., in
>> which case you would need a special configuration if you want to get rid
>> of the "man-pages" part. Tells us your structure, we'll tell you the
>> config ;)
>
> Do you now have enough info above?
Yes, thanks. If you use git-svn init -s (which is equivalent to -T trunk
-t tags -b branches) you get an "exact" clone of your svn repo in
reasonable time, as you already noticed.
In order to get rid of the "man-pages" path component you can either:
- remove it after the fact using git filter-branch
or
- remove it during the conversion process
For the latter, do the following:
git svn init -s file:///home/mtk/man-pages-rep/
as usual. Then, before the first fetch, make sure your .git/config svn
section looks as follows:
[svn-remote "svn"]
url = file:///home/mtk/man-pages-rep/
fetch = trunk/man-pages:refs/remotes/trunk
branches = branches/*/man-pages:refs/remotes/*
tags = tags/*/man-pages:refs/remotes/tags/*
That is, if you used "git svn init -s" you only have to add "/man-pages"
three times on the left hand side of the refspecs. You can also do this
using "git config", of course, if you watch out for the shell quoting.
Cheers,
Michael
^ permalink raw reply
* Re: [ANNOUNCE] TopGit v0.3
From: Michael Radziej @ 2008-09-17 11:17 UTC (permalink / raw)
To: Petr Baudis; +Cc: git
In-Reply-To: <20080917101111.GR10360@machine.or.cz>
Hi Petr!
Petr Baudis <pasky@suse.cz> wrote:
> On Mon, Sep 15, 2008 at 10:01:31AM +0200, Michael Radziej wrote:
> > I wonder about the .topmsg and .topdeps files. Why is this information
> > within the topic branch? It tends to get into the way even though a special
> > merge driver is provided. For example, you cannot do octopus merges (which I
> > found very confusing as first-time user).
>
> what do octopus merge have to do with that? If these files prevent
> octopus merges somehow, I think that'd be a Git bug. (TopGit making
> octopus merges whenever possible is deep on my mental TODO list.)
Hmm. Is there a way to to the octopus merge? If I do it straight away
git merge b1 b2 b3 b4
then git does not use the "ours" merge driver for the .topfiles, since the
attribute setting is only used for 3-way-merges. Then I get conflicts, and
git cannot handle conflicts during octopus merges.
> > And it might also confuse people
> > cloning a TopGit repository and want to use a topgit branch. They might not
> > be aware of these special TopGit things.
>
> They need to be properly educated by whoever gives them the clone URL.
> Using TopGit branches outside of TopGit is still dangerous - they have
> *unholy* history and they are not really suitable for non-TopGit merging
> etc. If TopGit users want non-TopGit users to use their work, they
> should tg export.
With *unholy* you mean the lots of merges? I usually avoid them by doing
"tg update" only when I get conflicts. Are there other problems?
> > I'd rather have a dedicated branched named e.g. 'TopGit' which includes the
> > information that is currently in .topmsg and .topdeps, but for all branches
> > in a repository.
>
> This was indeed a difficult design decision, perhaps the most major
> one I had to make. Both approaches have their pros and cons, and in the
> end I chose the .top* files mainly to keep the changes atomicity - if
> you revert your branch to older version, your .topmsg and .topdeps are
> rewound appropriately as well, and if you change something in your
> branch that affects your topmessage, these changes are connected
> appropriately. Also, you do not need to use special tools to edit your
> top message
Yeah, you're right about git-reset on branches. I tend to see the patch
description independent from the patch, so I don't see this as a big
problem. But how often does one really change the .topfiles?
> and merges are much simpler than if you had to merge two
> people's work on a single branch (besides, the merge semantics of the
> TopGit branch would be really, really nasty, perhaps downright
> impossible to specify properly)
I don't use the merge result as a TopGit branch - it's like a regular git
branch for me.
I use merging in different ways. I merge all topic branches to get a testing
branch, which I throw away later. And I also temporarily merge the upstream
branch with all the topic branches just to check for conflicts. If I get a
conflict, I use tg update for the conflicting branches. I'll probably script
this sooner or later :-)
> Hmm, well, oops. Merging of two people's work on a single branch is
> broken right now anyway, because we unconditionally use our 'ours' merge
> driver in these cases. I wonder how to fix this best... swapping two
> gitattributes files in .git/info/attributes during tg update seems like
> the only solution to me.
I don't have enough insight into TopGit to really think through this, at
least for now. Does it make sense at all build a TopGit branch on top of two
other TopGit branches from different repositories?
Michael
^ permalink raw reply
* Re: Teach git status to do "git diff --name-status HEAD"
From: Michael J Gruber @ 2008-09-17 11:26 UTC (permalink / raw)
To: Jakub Narebski; +Cc: Martin Langhoff, Git Mailing List
In-Reply-To: <m3ej3jm3ux.fsf@localhost.localdomain>
Jakub Narebski venit, vidit, dixit 17.09.2008 13:04:
> Michael J Gruber <git@drmicha.warpmail.net> writes:
>
>> Martin Langhoff venit, vidit, dixit 17.09.2008 08:40:
>>> I just did
>>>
>>> $ git checkout -b mdl19-offlinetony
>>> A README.offline
>>> M lib/javascript.php
>>> (...)
>>> A lib/offline/offlinemoodle.user.js
>>>
>>> I *like* this "brief status" style - takes me back to my cvs days :-).
>>> Perusing the source I found show_local_changes() which in turn led me
>>> to trying `git diff --name-status HEAD`. Now, including 'HEAD' in an
>>> alias defined in git config is going to lead to trouble... :-/
> [...]
>>> I might still make an alias to `git diff --name-status`. This would be
>>> a great thing to have as git status "--brief" IMHO... :-)
>> git status also shows untracked files. I don't know how to tell diff to
>> show untracked files as well. --diff-filter=X doesn't do it.
>
> git-ls-files?
Yes, "git ls-files -t -d -m -o --directory" does something like
"otherscmyouknowwho status". But it's plumbing, and the most obvious
porcelain place for such functionality is "git status", followed by "git
diff".
I do understand that "git status" is mostly "git commit --dry-run". But
shouldn't we have something like Martin suggested readily available
(including, optionally, untracked or ignored files).
Michael
^ 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