* Status of dumb http transport?
From: Martin Langhoff @ 2011-01-30 15:07 UTC (permalink / raw)
To: Git Mailing List
Hi List!
What is the state of dumb http transport today, for fetching updates?
Is the client code smart enough to fetch indexes and use range
requests? If so, how does that fare for latency?
Background: I am looking at whether yum repositories' data (currently
in sqlite & xml) could benefit from being a git (or very gittish)
database -- with a bit of re-organizing to make it git-efficient of
course.
Not the data that would benefit, but rather, users pulling updates
from fast-moving repos (updates, updates-testing, rawhide...).
One of the constraints is that this has to be http, and work well
across a universe of mirrors (that won't install or configure
software) and the good bad and ugly world of http proxies. Yum can be
taught to use the git proto, but that won't gain widespread use
quickly -- http is and will be the mainstay for a long time.
m
--
martin.langhoff@gmail.com
martin@laptop.org -- Software Architect - OLPC
- ask interesting questions
- don't get distracted with shiny stuff - working code first
- http://wiki.laptop.org/go/User:Martinlanghoff
^ permalink raw reply
* Remote branchs -- how can I check them out?
From: João Paulo Melo de Sampaio @ 2011-01-30 15:05 UTC (permalink / raw)
To: GIT Mailing List
Hello, people.
When I just cloned git using
git clone git://git.kernel.org/pub/scm/git/git.git
and I type
git branch
it shows me I have only the 'master' branch in my local repository
* master
and when I type
git branch -a
it shows that there's all these branches remotely
* master
remotes/origin/HEAD -> origin/master
remotes/origin/html
remotes/origin/maint
remotes/origin/man
remotes/origin/master
remotes/origin/next
remotes/origin/pu
remotes/origin/todo
What do I have to do to be able to see what's in the 'maint', 'next'
and 'todo' branches, for example?
And by the way, what are those branches all about? Their names
suggests they are maintenance branches (where you keep backward
compatibility with an older version?), the next version of git (1.7.4
version?) and future features under implementation (the to-do list?).
Thank you for your time!
--
João Paulo Melo de Sampaio
Computer Engineering Student @ UFSCar
Website: http://www.jpmelos.com
Twitter: twitter.com/jpmelos (@jpmelos)
^ permalink raw reply
* Status of dumb http transport?
From: Martin Langhoff @ 2011-01-30 14:57 UTC (permalink / raw)
To: Git Mailing List
--
martin.langhoff@gmail.com
martin@laptop.org -- Software Architect - OLPC
- ask interesting questions
- don't get distracted with shiny stuff - working code first
- http://wiki.laptop.org/go/User:Martinlanghoff
^ permalink raw reply
* Re: Re: Updating a submodule with a compatible version from another submodule version using the parent meta-repository
From: Julian Ibarz @ 2011-01-30 9:44 UTC (permalink / raw)
To: Heiko Voigt; +Cc: Junio C Hamano, Jens Lehmann, git
In-Reply-To: <20110129110807.GA21864@book.hvoigt.net>
Today I have started to implement a proof of concept in C (I know a
script would be better but I am really not good in sh so...). I
struggle with the manipulation of the git API. I have pushed my work
here:
http://gitorious.org/julian_ibarz_git/julian_ibarz_git
in branch submodule_checkout
My work is in:
builtin/submodulecheckout.c
And my questions are prepended by the keyword QUESTION (two questions
for now only).
Any help is welcome.
Thanks,
Julian Ibarz
On Sat, Jan 29, 2011 at 6:08 AM, Heiko Voigt <hvoigt@hvoigt.net> wrote:
> Hi,
>
> On Wed, Jan 26, 2011 at 02:05:43PM -0800, Junio C Hamano wrote:
>> If that version of submodule B is explicitly bound to a commit in the
>> superproject A, you know which version of A and C were recorded, and the
>> problem is solved.
>>
> [...]
>>
>> If you are confident that you didn't introduce different kind of
>> dependency to other submodules while developing your "old_feature" branch
>> in submodule B, one strategy may be to find an ancestor, preferrably the
>> fork point, of your "old_feature" branch that is bound to the superproject
>> A. Then at that point at least you know whoever made that commit in A
>> tested the combination of what was recorded in that commit, together with
>> the version of B and C, and you can go forward from there, replaying the
>> changes you made to the "old_feature" branch in submodule B.
>
> Lets extend your explanation a little further and maybe demonstrate the problem
> Julian is having a little more. I think what Julian searches for is a tool in
> git that does the lookup for you which is AFAIK not that easy currently. It
> seems to be a quite useful feature. Here what I understand Julian wants:
>
> 1. Find the most recent superproject commit X'' in A that records a submodule
> commit X' in B which contains the commit X in B you are searching for.
>
> For this we would need use something similar to git describe --contains
> but instead of using the list of existing tags in B it should use the list
> of commits in B which are recorded in A.
>
> Here a drawing to explain (linear history for simplicity):
>
> superproject A:
>
> O---O---X''---O
> \
> submodule B: \
> \
> O---X---O---X'---O---O
>
> 2. Look up the commit of C which is recorded in X'' of A and check it
> out.
>
> Step 2 is easy but for Step 1 the lookup of X' is missing for the commandline.
> Is there already anything that implements git describe --contains for a defined
> list of commits instead of refs?
>
> Cheers Heiko
>
^ permalink raw reply
* Re: [RFC] Add --create-cache to repack
From: Junio C Hamano @ 2011-01-30 8:05 UTC (permalink / raw)
To: Shawn Pearce; +Cc: Nicolas Pitre, Johannes Sixt, git, John Hawley
In-Reply-To: <AANLkTimuW-7D4YA2jeF+y4DPE=CdqtL713MQK+1Gtp-d@mail.gmail.com>
Shawn Pearce <spearce@spearce.org> writes:
> Using this for object enumeration shaves almost 1 minute off server
> packing time; the clone dropped from 3m28s to 2m29s. That is close to
> what I was getting with the cached pack idea, but the network transfer
> stayed the small 376 MiB.
I like this result.
The amount of transfer being that small was something I didn't quite
expect, though. Doesn't it indicate that our pathname based object
clustering heuristics is not as effective as we hoped?
^ permalink raw reply
* Re: [RFC] Add --create-cache to repack
From: Junio C Hamano @ 2011-01-30 6:51 UTC (permalink / raw)
To: Shawn Pearce; +Cc: Nicolas Pitre, Johannes Sixt, git, John Hawley
In-Reply-To: <AANLkTi=U7qRRij=BQXC1Goqa9toDFfaVKT=+-8zYxCcc@mail.gmail.com>
Shawn Pearce <spearce@spearce.org> writes:
> I fully implemented the reuse of a cached pack behind a thin pack idea
> I was trying to describe in this thread. It saved 1m7s off the JGit
> running time, but increased the data transfer by 25 MiB. I didn't
> expect this much of an increase, I honestly expected the thin pack
> portion to be well, thinner. The issue is the thin pack cannot delta
> against all of the history, its only delta compressing against the tip
> of the cached pack. So long-lived side branches that forked off an
> older part of the history aren't delta compressing well, or at all,
> and that is significantly bloating the thin pack. (Its also why that
> "newer" pack is 57M, but should be 14M if correctly combined with the
> cached pack.) If I were to consider all of the objects in the cached
> pack as potential delta base candidates for the thin pack, the entire
> benefit of the cached pack disappears.
What if you instead use the cached pack this way?
0. You perform the proposed pre-traversal until you hit the tip of cached
pack(s), and realize that you will end up sending everything.
1. Instead of sending the new part of the history first and then sending
the cached pack(s), you send the contents of cached pack(s), but also
note what objects you sent;
2. Then you send the new part of the history, taking full advantage of
what you have already sent, perhaps doing only half of the reuse-delta
logic (i.e. you reuse what you can reuse, but you do _not_ punt on an
object that is not a delta in an existing pack).
^ permalink raw reply
* Re: cvsimport still not working with cvsnt
From: Guy Rouillier @ 2011-01-30 6:33 UTC (permalink / raw)
To: Junio C Hamano
Cc: Jonathan Nieder, Martin Langhoff, Emil Medve, git, Pascal Obry,
Clemens Buchacher
In-Reply-To: <7v8vynnokt.fsf@alter.siamese.dyndns.org>
Sorry for the delay in following up, work has been busy.
On 1/14/2011 4:49 PM, Junio C Hamano wrote:
> As the general principle, in a "we see two, and we cannot tell which one
> the user wants to use" situation like this, I tend to prefer erroring out
> to _force_ the user to fix the configuration once and for all.
That was my original inclination. As no other opinions have been posted
since your message, here is my amended patch, incorporating Martin's
ideas and dieing if the script finds both CVS and CVSNT password files.
I don't know why diff got tripped up on brace indentation; I used only
tabs and everything looks fine in vi.
--- git-cvsimport.org 2011-01-09 03:52:39.000000000 -0500
+++ git-cvsimport.perl 2011-01-30 00:59:29.000000000 -0500
@@ -260,19 +260,27 @@
if ($pass) {
$pass = $self->_scramble($pass);
} else {
- open(H,$ENV{'HOME'}."/.cvspass") and do {
+ my @cvspasslocations = ($ENV{'HOME'}."/.cvspass", $ENV{'HOME'}."/.cvs/cvspass");
+ my $filecount = 0;
+ foreach my $cvspass (@cvspasslocations) {
+
+ open(H, $cvspass) and do {
# :pserver:cvs@mea.tmt.tele.fi:/cvsroot/zmailer Ah<Z
+ $filecount++;
while (<H>) {
chomp;
s/^\/\d+\s+//;
- my ($w,$p) = split(/\s/,$_,2);
+ my ($w,$p) = split(/[\s=]/,$_,2);
if ($w eq $rr or $w eq $rr2) {
$pass = $p;
last;
}
}
};
- $pass = "A" unless $pass;
+ }
+
+ die("Two CVS password files found: @cvspasslocations, please remove one") if $filecount > 1;
+ die("Password not found for CVSROOT: $opt_d\n") unless $pass;
}
my ($s, $rep);
--
Guy Rouillier
^ permalink raw reply
* https://github.com/github/dmca/blob/master/2011-01-27-sony.markdown
From: Luke Kenneth Casson Leighton @ 2011-01-30 5:59 UTC (permalink / raw)
To: git
oops. anyone still think a truly peer-to-peer version of git is
like... a waste of time?
l.
^ permalink raw reply
* Re: [PATCH] Handle rename of case only, for Windows
From: René Scharfe @ 2011-01-30 2:22 UTC (permalink / raw)
To: git; +Cc: msysgit
In-Reply-To: <1296344717.25999.1417928123@webmail.messagingengine.com>
Am 30.01.2011 00:45, schrieb Tim Abell:
>> Hmm, not so good. st_ino is always 0 on Windows, so this would make
>> false positives, no?
>
> I tested this on windows 7 under cygwin (which is what I have
> available) and st_ino reports real numbers for me, I also tested that
> attempting to overwrite another file without --force still fails and
> added a new test case for this scenario. I have now made sure that if
> zero is returned then git won't accidentally overwrite other files as
> I hadn't thought of this before. So this patch shouldn't be
> regressive even if other versions of windows or other filesystems
> don't provide valid inode data.
On MinGW on Vista st_ino is zero, git mv refuses to overwrite and the
added case change test fails as a consequence.
>> I wonder if we can make lstat_case() that would only return 0 if it
>> matches exactly the filename, even on FAT. FindFirstFile/FindNextFile
>> should return true file name, I think. If not, we can make
>> lstat_case() take two paths (src and dst) and move all inode
>> comparison code in there. Much cleaner.
>
> I'm afraid this is a bit beyond me at the moment, but I'm fairly
> happy with the solution I have. Thanks for the feedback though.
Hmm, if the patch only works for Cygwin and maybe OS X it's a step
forward, I guess. A more complete solution would be better, of course.
> diff --git a/builtin/mv.c b/builtin/mv.c
> index cdbb094..c2f726a 100644
> --- a/builtin/mv.c
> +++ b/builtin/mv.c
> @@ -165,17 +165,27 @@ int cmd_mv(int argc, const char **argv, const char *prefix)
> } else if (cache_name_pos(src, length) < 0)
> bad = "not under version control";
> else if (lstat(dst, &st) == 0) {
> - bad = "destination exists";
> - if (force) {
> - /*
> - * only files can overwrite each other:
> - * check both source and destination
> - */
> - if (S_ISREG(st.st_mode) || S_ISLNK(st.st_mode)) {
> - warning("%s; will overwrite!", bad);
> - bad = NULL;
> - } else
> - bad = "Cannot overwrite";
> + /* If we are on a case insensitive file system (windows) and we are only
> + * changing the case of the file then lstat for the destination will
> + * return != 0 because it sees the source file.
> + * To prevent this causing failure, lstat is used to get the inode of the src
> + * and see if it's actually the same file as dst. If the inode == 0 then
> + * we can't tell whether it is the same file so we fail regardless. */
Can you make the lines 80 characters long at most? This subtly helps
avoiding excessive levels of indentation by encouraging to factor out
nice and small functions.
> + struct stat src_st;
> + lstat(src, &src_st);
Shouldn't you check the return value of this call? OK, the source
probably always exists, but still. Oh, we actually know that because
that's the first lstat() call in this for loop. You can reuse its
result instead of calling the function again.
> + if (src_st.st_ino == 0 || src_st.st_ino != st.st_ino) {
It may be nice to avoid adding another level of indentation by combining
this if with the preceding one.
> + bad = "destination exists";
> + if (force) {
> + /*
> + * only files can overwrite each other:
> + * check both source and destination
> + */
> + if (S_ISREG(st.st_mode) || S_ISLNK(st.st_mode)) {
> + warning("%s; will overwrite!", bad);
> + bad = NULL;
> + } else
> + bad = "Cannot overwrite";
> + }
> }
> } else if (string_list_has_string(&src_for_dst, dst))
> bad = "multiple sources for the same target";
René
^ permalink raw reply
* [PATCH] Handle rename of case only, for Windows
From: Tim Abell @ 2011-01-29 23:45 UTC (permalink / raw)
To: git; +Cc: Erik Faye-Lund, Nguyen Thai Ngoc Duy, msysGit
>From ddab003ede9f25d93f4e7eea833523a0aa29d16d Mon Sep 17 00:00:00 2001
From: Tim Abell <tim@timwise.co.uk>
Date: Thu, 27 Jan 2011 22:53:31 +0000
Subject: [PATCH] Handle rename of case only, for Windows
Added test to show rename failing in windows.
Added test to show that this patch doesn't break protection against overwriting
an existing file, and another to show that "mv --force" still works.
Altered mv.c to check whether the source and destination file are actually
the same file based on inode number before failing.
If the inode is zero then the data is no use so old behaviour is maintained.
A message from Linus on the subject:
http://kerneltrap.org/mailarchive/git/2008/3/21/1220814
(apparently he never got the energy :-)
Signed-off-by: Tim Abell <tim@timwise.co.uk>
---
Hi folks, this is my second attempt at providing a useful patch for this issue.
Thanks for all the great feedback from my first attempt. I've attempted to address the problems raised.
Hopefully my commit message is more like what is needed this time.
I hadn't realised before that you can split the commit message from this bit with the "---".
>Hmm, not so good. st_ino is always 0 on Windows, so this would make
>false positives, no?
I tested this on windows 7 under cygwin (which is what I have available) and st_ino reports real numbers for me, I also tested that attempting to overwrite another file without --force still fails and added a new test case for this scenario. I have now made sure that if zero is returned then git won't accidentally overwrite other files as I hadn't thought of this before. So this patch shouldn't be regressive even if other versions of windows or other filesystems don't provide valid inode data.
Adding the following line after "lstat(src, &src_st);" shows the inode numbers when calling git mv:
printf("src inode: %lu, dst inode: %lu", (unsigned long) src_st.st_ino, (unsigned long) st.st_ino);
And here is my ouput showing it in action:
$ git mv foo.txt bar.txt
fatal: destination exists, source=foo.txt, destination=bar.txt
src inode: 67064, dst inode: 229369
$ git mv foo.txt Foo.txt
src inode: 67064, dst inode: 67064
>I wonder if we can make lstat_case() that would only return 0 if it
>matches exactly the filename, even on FAT. FindFirstFile/FindNextFile
>should return true file name, I think. If not, we can make
>lstat_case() take two paths (src and dst) and move all inode
>comparison code in there. Much cleaner.
I'm afraid this is a bit beyond me at the moment, but I'm fairly happy with the solution I have. Thanks for the feedback though.
>Couldn't this be moved inside the scope around "cache_name_pos"?
>That's the only scope it is valid inside anyway...
Done. I wasn't sure about this initially as I'm not very experienced with C programming. Thanks for the pointer.
>Perhaps you could use the full URL (and maybe put it in the commit
>message insted)? It'd be nice if we could reach this information even
>if is.gd disappears...
Good point. I've put the full url in the commit message instead.
>Uhm, is this debug-leftovers? #warning is a preprocessor-construct,
>and it can't understand varaibles in c. Especially not formatted as
>strings. Can #warning even do varags? :P
Yes, it was a debug line. Doh! Complete chance that it compiled, I've been doing too much bash scripting recently it seems. I've stripped it out. A better version is available above should anyone want to see the inode numbers.
Thanks all, I welcome any more feedback.
Does this now look like something that anyone on the git project would like to pick up as a contribution?
Yours
Tim Abell
builtin/mv.c | 32 +++++++++++++++++++++-----------
t/t7001-mv.sh | 35 +++++++++++++++++++++++++++++++++++
2 files changed, 56 insertions(+), 11 deletions(-)
diff --git a/builtin/mv.c b/builtin/mv.c
index cdbb094..c2f726a 100644
--- a/builtin/mv.c
+++ b/builtin/mv.c
@@ -165,17 +165,27 @@ int cmd_mv(int argc, const char **argv, const char *prefix)
} else if (cache_name_pos(src, length) < 0)
bad = "not under version control";
else if (lstat(dst, &st) == 0) {
- bad = "destination exists";
- if (force) {
- /*
- * only files can overwrite each other:
- * check both source and destination
- */
- if (S_ISREG(st.st_mode) || S_ISLNK(st.st_mode)) {
- warning("%s; will overwrite!", bad);
- bad = NULL;
- } else
- bad = "Cannot overwrite";
+ /* If we are on a case insensitive file system (windows) and we are only
+ * changing the case of the file then lstat for the destination will
+ * return != 0 because it sees the source file.
+ * To prevent this causing failure, lstat is used to get the inode of the src
+ * and see if it's actually the same file as dst. If the inode == 0 then
+ * we can't tell whether it is the same file so we fail regardless. */
+ struct stat src_st;
+ lstat(src, &src_st);
+ if (src_st.st_ino == 0 || src_st.st_ino != st.st_ino) {
+ bad = "destination exists";
+ if (force) {
+ /*
+ * only files can overwrite each other:
+ * check both source and destination
+ */
+ if (S_ISREG(st.st_mode) || S_ISLNK(st.st_mode)) {
+ warning("%s; will overwrite!", bad);
+ bad = NULL;
+ } else
+ bad = "Cannot overwrite";
+ }
}
} else if (string_list_has_string(&src_for_dst, dst))
bad = "multiple sources for the same target";
diff --git a/t/t7001-mv.sh b/t/t7001-mv.sh
index 65a35d9..abaecb6 100755
--- a/t/t7001-mv.sh
+++ b/t/t7001-mv.sh
@@ -255,4 +255,39 @@ test_expect_success SYMLINKS 'git mv should overwrite file with a symlink' '
rm -f moved symlink
+test_expect_success 'git mv should not fail when only changing case' '
+
+ rm -fr .git &&
+ git init &&
+ >foo.txt &&
+ git add foo.txt &&
+ git mv foo.txt Foo.txt
+'
+
+rm *.txt
+
+test_expect_success 'git mv should not overwrite existing file' '
+
+ rm -fr .git &&
+ git init &&
+ >foo.txt &&
+ >bar.txt &&
+ git add foo.txt &&
+ test_must_fail git mv foo.txt bar.txt
+'
+
+rm *.txt
+
+test_expect_success 'git mv -f should overwrite existing file' '
+
+ rm -fr .git &&
+ git init &&
+ >foo.txt &&
+ >bar.txt &&
+ git add foo.txt &&
+ git mv -f foo.txt bar.txt
+'
+
+rm *.txt
+
test_done
--
1.7.3.5.3.g2b35a
^ permalink raw reply related
* Re: Project- vs. Package-Level Branching in Git
From: David Aguilar @ 2011-01-29 23:28 UTC (permalink / raw)
To: Thomas Hauk
Cc: Enrico Weigelt, git, Ævar Arnfjörð Bjarmason,
Jakub Narebski
In-Reply-To: <20110129194258.GE602@nibiru.local>
On Sat, Jan 29, 2011 at 08:42:59PM +0100, Enrico Weigelt wrote:
> * Jakub Narebski <jnareb@gmail.com> wrote:
>
> > That is only if lib{a,b,c} is _internal_ dependency. In usual case
> > project A might depend on library B *to be installed*, but it doesn't
> > mean that source code of library B has to be in repository for project
> > A. And in usual case when project A depends on library B, it relies
> > on library B public stable API (its build system might check if you
> > have new enough library B installed). If you depend on specific
> > version of library, patched, that is your problem...
>
> To make it more clear:
>
> At buildtime, a _package_ (not project!) "A" requires a already built
> and installed package B in some sane place where the toolchain can find it.
> On deployment of package "A", it has to be made sure that package "B"
> is also deployed (eg. by a dependency-handling package manager).
>
> These are two entirely separate stages in a software's lifecycle.
> Buildtime and deployment dependencies may be different (even deployment
> and runtime deps may differ).
This is exactly how we do it at my workplace. We have literally
hundreds of individual git repositories. Naturally, some
packages depend on others and the only "trick" is building them
in the correct dependency order. A simple dependency tree
handles this for us.
We use same-named branches across several repos when coordinating
features across many projects. e.g. we had an "el6" branch
when we were gettings things ready for that platform. It's a
convention but it helps when writing helper scripts.
We can clone and work on any subset of the entire tree by
cloning just the repos we are interested in. Setting
$LD_LIBRARY_PATH and $PATH helps when testing builds in their
sandboxes. You still need to get the compiler/linker to
construct paths into the sandboxes instead of the standard
release area.
This is what the pkg-config command does. It respects the
$PKG_CONFIG_PATH environment variable which can be used to
point to staged installs so that you don't have to deploy the
package before building against it. The idea is so simple
that you could write an equivalent command in an afternoon and
extend it to work however you need in the event that pkg-config
does not fit.
There's only two components that are needed to make this work:
1. a simple shell wrapper to aid in setting the env. variables
on the fly. Let's call it "devo". That way you can say
"devo foo bar baz" and it'll put
foo/linux-x64/lib64/pkgconfig and bar/linux-x64/lib64/pkgconfig
(assuming linux-x64 is the "make install"ed path)
at the front of the PKG_CONFIG_PATH, foo/linux-x86/bin in PATH,
etc.
You can do without a wrapper by either setting the variables
manually or by having a shell scriplet that you 'source'
whenever you want the settings.
2. the build must use the pkg-config command when constructing
include/library paths.
As I mentioned, perhaps you don't want to use pkg-config.
The idea ("overridable projects using a single env. variable")
is the important part. You can certainly write something
tailored to your needs if you want something simpler.
--
David
^ permalink raw reply
* Re: Features from GitSurvey 2010
From: Jonathan Nieder @ 2011-01-29 23:13 UTC (permalink / raw)
To: Dmitry S. Kravtsov; +Cc: git, Jakub Narebski
In-Reply-To: <AANLkTi=gf9_618iojpYJgN_msAe-FBq-Jao=sj76VQak@mail.gmail.com>
Hi Dmitry,
Dmitry S. Kravtsov wrote:
> I want to dedicate my coursework at University to implementation of
> some useful git feature. So I'm interesting in some kind of list of
> development status of these features
[...]
> Or I'll be glad to know what features are now 'free' and what are
> currently in active development.
Interesting question. The short answer is that they are all "free".
Generally people seem to be happy to learn of an alternative approach
to what they have been working on.
[For the following pointers, the easiest way to follow up is probably
to search the mailing list archives.]
> better support for big files (large media)
For a conservative approach, you might want to get in touch with Sam
Hocevar, Nicolas Pitre, and Miklos Vajna. The idea is to stream big
files directly to pack and not waste time trying to compress them.
For an alternative approach, Joey Hess's git-annex might be
interesting.
> resumable clone/fetch (and other remote operations)
Jakub Narebski seems to be interested in this and Nicolas Pitre has
given some good advice about it. You can get something usable today
by putting up a git bundle for download over HTTP or rsync, so it is
possible that this just involves some UI (porcelain) and documentation
work to become standard practice.
> GitTorrent Protocol, or git-mirror
Sam Vilain and Jonas Fonseca did some good work on this, but it's
stalled.
> lazy clone / on-demand fetching of object
There's a patch. As is, it is not likely to be useful outside
specialized circumstances imho.
http://thread.gmane.org/gmane.comp.version-control.git/73117
> subtree clone
Nguyễn Thái Ngọc Duy and Elijah Newren have done some design and
prototyping work.
> support for tracking empty directories
Tricky to get the UI right. I am interested in and would be glad to
help with this one.
> environment variables in config
> better undo/abort/continue, and for more commands
These might involve nice "bite-sized" projects. Christian Couder
and Johannes Schindelin have discussed cherry-pick --abort/--continue
and they might be interested in patches on that subject. Stephen
Beyer's sequencer might be interesting for inspiration:
git://repo.or.cz/git/sbeyer.git
> '-n' like option for each command, which describes what would happen
> warn before/when rewriting published history
> git push --create
> "commands issued" (or "command equivalents") in git-gui / gitk
Go for it. "git init --remote" might be a good companion to "git push
--create".
> side-by-side diffs and/or color-words diff in gitweb
> admin and/or write features in gitweb
> graphical history view in gitweb
There may or may not have been design work on some of these for Pavan
Kumar Sunkara's last summer of code project. John 'Warthog9' Hawley,
Jakub Narebski, and Petr Baudis might have advice.
> GUI for rebase in git-gui
> GUI for creating repository in git-gui
> graphical diff/merge tool integrated with git-gui
> syntax highlighting in git-gui
Pat Thoyts is probably the one to talk to.
> filename encoding (in repository vs in filesystem)
This is important for the Windows port and likely to be a nuisance
on Unix. I think there has been some work on it on the msysgit list?
> localization of command-line messages (i18n)
Ævar Arnfjörð Bjarmason did some work which is in pu. It needs
some polishing. I am also interested.
> wholesame directory rename detection
Yann Dirson wrote a patch. It needs some polishing (I'd be glad to
help --- it would be exciting to see this move forward).
> union checkouts (some files from one branch, some from other)
Not sure I understand the use case?
> advisory locking / "this file is being edited"
Probably better to implement out of band (using hooks?). I don't
know of any work or documentation in that direction.
> built-in gitjour/bananajour support
A good start might be to submit one or both of these to contrib?
> better support for submodules
Jens Lehmann has done some great work on this and presumably would
be happy for help.
https://github.com/jlehmann/git-submod-enhancements/wiki
Hope that helps,
Jonathan
^ permalink raw reply
* Re: New Version Control System to be used for some software development projects
From: David Aguilar @ 2011-01-29 22:55 UTC (permalink / raw)
To: APARNA SHARAN; +Cc: git
In-Reply-To: <20332362.193911296114372251.JavaMail.weblogic@epml08>
On Thu, Jan 27, 2011 at 07:46:12AM +0000, APARNA SHARAN wrote:
>
> Hi,
>
> We are looking for 1 day training program on GIT, the open source distributed version control system used to manage small to large projects with speed and efficiency. Our company is based in Noida.
>
> Kindly let us know if someone has an expertise in this area and can do the training for us.
>
> Regards
>
> Aparna Sharan
> Asst. Manager - HR
> SEL-India
> Noida
> Mb: +91-9910019281
Hello Aparna,
github offers professional git training.
https://github.com/training
I'm not affiliated with github but have recommended them at my
workplace with great results.
Cheers,
--
David
^ permalink raw reply
* Re: Is there a specific reason that git gui does not respect comment lines added by a git hook?
From: David Aguilar @ 2011-01-29 22:45 UTC (permalink / raw)
To: Wilbert van Dolleweerd; +Cc: Git ML
In-Reply-To: <AANLkTingTLM8MCEBdS_4OAE5DU1L4xndRzQMq_gdvKaL@mail.gmail.com>
On Wed, Jan 26, 2011 at 11:14:28AM +0100, Wilbert van Dolleweerd wrote:
> Hello,
>
> I've written a prepare-commit-msg hook [...snip...]
> I'm using comments in the commit message to give additional
> information to the user. For example, when the Team Foundation Server
> is not available, I add the following comment to the top of the commit
> message.
I have the impression that you're running into this behavior
because this information is at the top of the commit message
(line 1). Users then fill in the actual message on the
lines below this, I presume?
Try to see what happens if you set it up so that users fill
in the commit message above the auto-generated comment.
I have a feeling that it only strips out '#' lines after
it's read in the commit message proper.
I haven't read the code so I'm not certain of this, but it seems
like that is what's going on. Also, "git gui" uses plumbing
commands underneath the hood and does not actually call
"git commit" directly. That might help explain this subtle
difference in behavior.
> Because the line starts with a # sign, it is not added to the actual
> commit message...when using git commit. If I use git gui, the above
> comment appears in the git gui interface but *is* actually added to
> the git commit message when committing.
>
> Is there a specific reason that git gui is actually adding lines
> starting with a # sign? I was expecting it to ignore those lines.
>
> --
> Kind regards,
>
> Wilbert van Dolleweerd
> Blog: http://walkingthestack.wordpress.com/
> Twitter: http://www.twitter.com/wvandolleweerd
--
David
^ permalink raw reply
* Re: Can't find the revelant commit with git-log
From: René Scharfe @ 2011-01-29 20:26 UTC (permalink / raw)
Cc: Junio C Hamano, Francis Moreau, git, Johannes Sixt
In-Reply-To: <4D437CA0.1070006@lsrfire.ath.cx>
Am 29.01.2011 03:34, schrieb René Scharfe:
> Am 29.01.2011 01:02, schrieb Junio C Hamano:
>> Let's look at the original code before your patch again.
>>
>> 1. If all the parents of a commit are the same, we will see (tree_same &&
>> !tree_changed), so we get TREESAME.
>>
>> 2. If some but not all of the parents are the same, we will see (tree_same
>> && tree_changed), and we end up getting TREESAME.
>>
>> 3. If none of the parents is the same, (!tree_same && tree_changed) holds
>> true, and we do not get TREESAME.
>
> For completeness, a fourth case (!tree_same && !tree_changed), which
> would be triggered by commits whose parents are all classified as
> REV_TREE_NEW. That's another corner case for sure, but the old code
> would mark it TREESAME and your patch changes that.
Ugh, forget this part, I failed to notice the /* fallthrough */ at the
end of the REV_TREE_NEW case..
René
^ permalink raw reply
* Re: Can't find the revelant commit with git-log
From: René Scharfe @ 2011-01-29 20:26 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Francis Moreau, git, Johannes Sixt
In-Reply-To: <7vsjwcb6rh.fsf@alter.siamese.dyndns.org>
Am 29.01.2011 06:47, schrieb Junio C Hamano:
> René Scharfe <rene.scharfe@lsrfire.ath.cx> writes:
>
>> Perhaps we should check my underlying assumption first: is it
>> reasonable to expect a git log command to show the same commits
>> with and without a path spec that covers all changed files?
>
> The simplest case would be "git log ." vs "git log" from the root
> level of the repository, right? Traditionally, the former is "please
> show _one_ simplest history that can explain how the current commit
> came to be" (i.e. with merge simplification), while the latter is
> "please list everything that is behind the current commit" (i.e.
> without), I think.
>
> It feels unintuitive, but my understanding of the rationale behind
> the design is that, the expectation Linus had when he first did the
> pathspec limited traversal was that most of the time "git log $path"
> is used to get an explanation. It follows that having to say "git
> log --simplify $path" would have been a nuisance, so "with pathspec,
> we simplify" was thought to be a reasonable default.
I think simplifying the history whenever a pathspec restricts the set of
interesting commits makes sense.
I'm not so sure about "." vs. none, and it feels odd that the only way
to turn off simplification is to not use pathspecs, as --full-history
will still remove merges if tree_same in revision.c is true.
Simplification by default (even without a pathspec) and --full-history
reporting, well, the full history seems more intuitive to me.
So currently pickaxe can't be used reliable to search for strings that
have been removed: either one has to refrain from using pathspecs, which
is prohibitively slow in the kernel repo, or git is free to take a
short-cut through a branch of history that never contained the string at
all.
Your patch extends --full-history coverage sufficiently to make pickaxe
work in Francis' use case. One just has to remember to specify this
option if one hunts for removed strings using -S. Below is an equivalent
patch, only with the simplify_history test moved into the loop and the
needed test script modification.
-- >8 --
Subject: revision: let --full-history keep half-interesting merges
Don't simplify merges away that have at least one parent with changes in
the interesting subset of files if --full-history has been specified.
The previous behaviour hid merges with one uninteresting parent, which
could lead to history that removed code to become undetectable.
E.g., this command run against the Linux kernel repo only found one
merge that brought the specified function in (and the regular commit
which added it in the first place), but missed the 92 merges that
removed it, as well as 67 other merges that added it back:
$ git log -m --full-history -Sblacklist_iommu \
v2.6.26..v2.6.29 -- drivers/pci/intel-iommu.c
Reported-by: Francis Moreau <francis.moro@gmail.com>
Signed-off-by: Rene Scharfe <rene.scharfe@lsrfire.ath.cx>
---
revision.c | 2 ++
t/t6016-rev-list-graph-simplify-history.sh | 1 +
2 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/revision.c b/revision.c
index 7b9eaef..84c231b 100644
--- a/revision.c
+++ b/revision.c
@@ -434,6 +434,8 @@ static void try_to_simplify_commit(struct rev_info *revs, struct commit *commit)
case REV_TREE_OLD:
case REV_TREE_DIFFERENT:
tree_changed = 1;
+ if (!revs->simplify_history)
+ return;
pp = &parent->next;
continue;
}
diff --git a/t/t6016-rev-list-graph-simplify-history.sh b/t/t6016-rev-list-graph-simplify-history.sh
index f7181d1..50ffcf4 100755
--- a/t/t6016-rev-list-graph-simplify-history.sh
+++ b/t/t6016-rev-list-graph-simplify-history.sh
@@ -168,6 +168,7 @@ test_expect_success '--graph --full-history --simplify-merges -- bar.txt' '
echo "|\\ " >> expected &&
echo "| * $C4" >> expected &&
echo "* | $A5" >> expected &&
+ echo "* | $A4" >> expected &&
echo "* | $A3" >> expected &&
echo "|/ " >> expected &&
echo "* $A2" >> expected &&
--
1.7.3.4
^ permalink raw reply related
* Re: Project- vs. Package-Level Branching in Git
From: Enrico Weigelt @ 2011-01-29 19:42 UTC (permalink / raw)
To: git
In-Reply-To: <m3tygt9xmn.fsf@localhost.localdomain>
* Jakub Narebski <jnareb@gmail.com> wrote:
> That is only if lib{a,b,c} is _internal_ dependency. In usual case
> project A might depend on library B *to be installed*, but it doesn't
> mean that source code of library B has to be in repository for project
> A. And in usual case when project A depends on library B, it relies
> on library B public stable API (its build system might check if you
> have new enough library B installed). If you depend on specific
> version of library, patched, that is your problem...
To make it more clear:
At buildtime, a _package_ (not project!) "A" requires a already built
and installed package B in some sane place where the toolchain can find it.
On deployment of package "A", it has to be made sure that package "B"
is also deployed (eg. by a dependency-handling package manager).
These are two entirely separate stages in a software's lifecycle.
Buildtime and deployment dependencies may be different (even deployment
and runtime deps may differ).
> In the case of internal dependency, where you co-develop both project
> A and library B, it makes most sense to have separate repositories for
> A and for B, and tie them up using submodules or subtree merge.
I, personally, wouldn't use submodules - too complicated. Instead have
just one tree per package(-variant) and keep these completely separate.
> > I understand that Git was designed with a specific feature set in
> > mind -- to manage Linux kernel development -- and as such isn't
> > going to satisfy everyone. But I'm having trouble figuring out how
> > to integrate it as the SCM in my projects, which aren't organized
> > any differently than any other projects I've seen.
>
> Well, you are braindamaged by your SCM ;-) ... just kidding.
>
> Take a look how LibreOffice (Go-OOo), KDE, GNOME, GNU SourceMage Linux
> distribution organize their repositories -- all of them are highly
> modular / componentized.
Well, I wouldn't say LO is really modularized, yet. (but we're
working on that ...).
cu
--
----------------------------------------------------------------------
Enrico Weigelt, metux IT service -- http://www.metux.de/
phone: +49 36207 519931 email: weigelt@metux.de
mobile: +49 151 27565287 icq: 210169427 skype: nekrad666
----------------------------------------------------------------------
Embedded-Linux / Portierung / Opensource-QM / Verteilte Systeme
----------------------------------------------------------------------
^ permalink raw reply
* Re: Project- vs. Package-Level Branching in Git
From: Enrico Weigelt @ 2011-01-29 19:33 UTC (permalink / raw)
To: git
In-Reply-To: <15B7CA2E-C584-4563-B9E3-D80861CD9565@shaggyfrog.com>
* Thomas Hauk <tom@shaggyfrog.com> wrote:
> Imagine a project that uses liba and libb, which both reference libc.
> To use Git, I'd have to have copies of libc existing in three
> repositories, and copies of liba and lib in two repositories each.
No, just leave them as they are: separate packages. Period.
Let a dist buildsystem handle the project's build process,
including dependency resolving, packaging, etc.
> Git just doesn't seem to scale when it comes to componentized
> projects.
These "componentized" projects (as you call it - I'd rather call
it the exact opposite) suffer from an ideology that doens't know
to differenciate between the fundamental stages of an software
building up to deployment, they try do to everything in one fat
blob - that's why fail or burn expensive resources frequently.
(I've seen that often enough in my last 15 years of software
engineering ...)
cu
--
----------------------------------------------------------------------
Enrico Weigelt, metux IT service -- http://www.metux.de/
phone: +49 36207 519931 email: weigelt@metux.de
mobile: +49 151 27565287 icq: 210169427 skype: nekrad666
----------------------------------------------------------------------
Embedded-Linux / Portierung / Opensource-QM / Verteilte Systeme
----------------------------------------------------------------------
^ permalink raw reply
* Re: [PATCH] am: Allow passing exclude and include args to apply
From: maximilian attems @ 2011-01-29 19:31 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Thiago Farina, git, klibc
In-Reply-To: <7v4oa9frmr.fsf@alter.siamese.dyndns.org>
hello,
sorry for the time it took to reply, but "things" went crazy
around christmas.
On Sun, 19 Dec 2010, Junio C Hamano wrote:
> maximilian attems <max@stro.at> writes:
>
> > ...
> > when one wants to promote a specific new feature, it is much better to
> > come up with it's use case, as burden is on Maintainer to keep it working.
>
> You need to do that with test suite, not with the log message. Otherwise
> you are adding undue burden on the Maintainer to download klibc and dash
> just to run regression testing whenever somebody else makes changes to
> "am/apply" callchain down the road.
ok thanks for the point.
> While I love patches that are backed by a strong "here is a real-world
> problem we needed to solve, and this change made our life much easier by
> doing so-and-so" statement, I also tend to think twice before considering
> a change that could potentially encourage a bad version control
> discipline.
sure, one sees your careful planning.
> Your use case description in the log message however lacks crucial
> information to be useful when judging that aspect. You said that the
> directory structure is "different", but didn't say they are different in
> what way. In order to skip one mail exchange turnaround, I'd speculate.
sorry about that, will answer below.
> If dash repository keeps (perhaps slightly stale version of) the same
> files as klibc repository in its libc/ subdirectory, a patch to dash that
> fixes its libc part may all have its pathnames prefixed with libc/. In
> order to apply such a patch to the klibc tree, you would need to give -p2
> to strip one extra level (if you are going the other way, you would
> instead give --directory=libc/ to deepen it). But then I do not see a
> need for --exclude to remove parts from the patch that touch outside of
> libc/ tree.
>
> If the dash patch you needed to deal with touched both inside libc/ and
> outside, and if you are taking only libc/ part and discarding everything
> else, I see two issues with respect to promoting pottentially bad version
> control disciplines.
>
> - Should you be reusing the information in the commit without editing? I
> am not worried about Signed-off-by which is about asserting the origin,
> and origin of the libc/ part is the same as the origin of the whole.
> But what about reviewers' and tester's assertion at the end? Also the
> description of the change itself may need to be adjusted to the new
> context you are reusing the change for.
>
> - Why does the patch touch two unrelated parts in the first place, if its
> libc/ part can stand on its own? This is not about the discipline of
> the user of "am", but of the originating project.
Life is simpler in effect, considering this usecase.
So the code lives in dash repo and from to time is ported to klibc.
So dash has no klibc code on it's own it's only klibc, which is carrying
a copy of dash in order to have an useful shell for early userspace.
It is not a full copy of dash and some things are not their,
that's the usage case for the exclude argument on the git am call.
> Another thing that came to my mind around the vague "different directory
> structure" is this question: what if directory A/ in "dash" corresponded
> to directory B/ in "klibc" and you saw a patch to A/ (and some others) for
> "dash" that you wanted to reuse in "klibc"? Do we need more changes to
> make it work, or do we already have enough support for this combination?
>
> I would imagine that "git am --directory=B/ -p2 --exclude=\* --include=A/"
> or something like that should work, but I didn't think it through nor I
> didn't check the command line syntax, either.
well mostly the current workflow looks like this:
1) Generate patches to import on dash git repository:
git format-patch --keep-subject <changeset>..
Path fixup:
perl -i -pe 's#^([-+]{3} [ab]/)src/#$1#g' 00*patch
2) Import patches on by one
git am --directory="usr/dash" --exclude="usr/dash/configure.ac" \
--exclude="usr/dash/ChangeLog" --exclude="usr/dash/dash.1" \
--exclude="usr/dash/Makefile.am" --exclude="usr/dash/mksignames.c" \
-i -s ../dash/000X-foo.patch
the path fixup with perl is needed as dash code lives in
"src/", but later it lands in "usr/dash/".
I do not have a use case for --include, I only added it out of
completness.
Unless objection I'd repost the patch with exclude only and relevant
testcase.
Of course if you'd know of a trick that makes the perl path mangling
useless I'd be more than happy to hear.
thank you.
--
maks
^ permalink raw reply
* Re: Project- vs. Package-Level Branching in Git
From: Enrico Weigelt @ 2011-01-29 19:08 UTC (permalink / raw)
To: git
In-Reply-To: <14F4737F-E8E4-4E4E-A625-16CA63CF9EFF@shaggyfrog.com>
* Thomas Hauk <tom@shaggyfrog.com> wrote:
> Back when I worked at a large games company, we used Perforce, and
> our repo structure looked a little something like this:
>
> /branches
> /alpha
> /beta
> /mainline
> /packages
> /external
> /foolib
> /1.0
> /1.1
> /2.0
> /internal
> /barlib
> /dev
> /1.0
> /2.0
> /bazlib
> /2.34
> /2.35
> /qux
> /dev
Ah, you're conditioned by a VCS that mixes up directory copies and branches,
just like SVN or TFS - those folks (VCS developers as well as their userbase)
still don't get the idea that these are orthogonal concepts ;-o
Needless to say that this makes working w/ branches quite hard (compared
to git ;-p), not even to mention things like remote tracking, rebase, etc.
(guess what: M$ itself recommends against branches or at least very beaurocratic
planning and processes in their own official TFS papers ;-p)
Just forget about that all, forget the whole idea of having dozens of
packages in one fat tree. Develop and track each package saparately and
use an separate dist build tool (eg. Briegel) to put things together.
It'll take some time to get your head around this ideology, but it'll pay out
if you do it consequently. (I've already been through this some years ago).
> At the package level, we would split up packages/libraries into two groups
> based on if they were developed at the company or not (external/internal),
Why exactly that split ? Why not having each package separately, independent
on the supplier ? Each package should stand completely on its own (assuming
dependencies resolved), or it isn't really a package but just a bunch of files.
> and inside each one, we might have multiple versions. In the example above,
> the repo is for the "qux" game, which uses an internal "bazlib" library
> developed by another group, and the "barlib" library which was developed
> for use on "qux" and may be used simultaneously on other projects.
That qualifies an _separate_ (generic) package, which should be developed
and deployed separately. If you need to tweak it for (potentially) each
project (so, have per-project branches of it), you'll most likely have
some serious architectural flaw.
> I've successfully used this repo structure with several other projects
> over the years at other companies (who were mostly using Subversion).
My current customer also used such a model (previously in PVCS, not TFS),
and they discuss hours over hours about how and when to branch and whether
certain things could be merged back at all, instead of just doing the
actual work.
For the product I'm currently working on (imagine that: an embedded linux
project that gets tracked via TFS ;-o) they always tried to do the projects
(each on essentially the same codebase, but each job/project has some
customer-specific changes) sequentially (and even mixed up with standard
feature development), so they could lie to themselves that they would
never need branches. In the end they had two completely separate
incompatible codebasis which now have to be "merged" together manually,
consuming several man-month. (now I'm there to clean up the mess ;-o).
> Now I'm trying to get into the Git swing of things, but it seems to be
> that Git only offers project-level branching, and doesn't allow for the
> kind of package-level branching I'm describing here.
On sourcetree-, not project-level. Projects and sourcetrees are
completely different concepts. Another important point that many
folks (especially IDE designers) never really understood.
> Am I incorrect or is there a way to accomplish with Git what I was
> doing before with P4 and SVN?
Not really. Rethink your project organization and workflows.
cu
--
----------------------------------------------------------------------
Enrico Weigelt, metux IT service -- http://www.metux.de/
phone: +49 36207 519931 email: weigelt@metux.de
mobile: +49 151 27565287 icq: 210169427 skype: nekrad666
----------------------------------------------------------------------
Embedded-Linux / Portierung / Opensource-QM / Verteilte Systeme
----------------------------------------------------------------------
^ permalink raw reply
* Re: Permissions and authorisations in git repository
From: Enrico Weigelt @ 2011-01-29 17:28 UTC (permalink / raw)
To: git
In-Reply-To: <20110128150631.33be0a9d.kostix@domain007.com>
* Konstantin Khomoutov <flatworm@users.sourceforge.net> wrote:
<snip>
In fact, git does not have any access control whatsoever. It relies
on what the underlying transport protocol allows it to do.
With ssh, you could wrap the commands into some script which checks,
the permissions on calling-in user or key (eg. restrict write access
on certain refs to certain people). You could do even more fancy
things like given everybody (or certain people) unrestricted write
access, but under the hood put their rename the updated refs
(eg. you can push 'master', but on the server, refs/heads/master
wont be overwritten, instead it goes to refs/heads/konstantin/master).
Some people (coming from strictly-central ideologies) might consider
git's access control angonsticity a drawback, but IMHO it's a very
good thing - git doesn't want to be a full-blown "out-of-the-box"
VCS (like, eg. clearcase), but more a lightweight toolkit to easily
build your own.
cu
--
----------------------------------------------------------------------
Enrico Weigelt, metux IT service -- http://www.metux.de/
phone: +49 36207 519931 email: weigelt@metux.de
mobile: +49 151 27565287 icq: 210169427 skype: nekrad666
----------------------------------------------------------------------
Embedded-Linux / Portierung / Opensource-QM / Verteilte Systeme
----------------------------------------------------------------------
^ permalink raw reply
* Re: Why git tags are there in git?
From: Enrico Weigelt @ 2011-01-29 17:17 UTC (permalink / raw)
To: git
In-Reply-To: <1296214676536-5969544.post@n2.nabble.com>
* vikram2rhyme <vikram2rhyme@gmail.com> wrote:
Hi,
> I am wondering why the tags are there in git. As they are just
> pointer to the commit we can refer those commit by SHA sum only
> then why tagging? Moreover a commit can be tagged more than once
> that result in multiple tags pointing to the same point in the history.
> Is this a design flaw?
No, it's an important design aspect.
Tag references (not to be mixed up w/ tag objects) are very useful
to add a conveniently named pointer to some object (not necessarily
a commit), so humans as well as programs can easily find them.
For example, in my OSS-QM repositories [1], I have some robots
importing releases (sometimes from upstream's git repos, sometimes
from foreign VCSs, tarballs or even distro packages) and tag
them into a normalized namespace, so automatic systems (eg. my
Briegel buildsystem) can easily fetch sourcetrees from there
w/o further manual tweaking.
cu
[1] http://www.metux.de/download/oss-qm/normalized_repository.pdf
--
----------------------------------------------------------------------
Enrico Weigelt, metux IT service -- http://www.metux.de/
phone: +49 36207 519931 email: weigelt@metux.de
mobile: +49 151 27565287 icq: 210169427 skype: nekrad666
----------------------------------------------------------------------
Embedded-Linux / Portierung / Opensource-QM / Verteilte Systeme
----------------------------------------------------------------------
^ permalink raw reply
* git svn clone stops after r2 for svn://mlton.org/mlton/trunk
From: Florian Weimer @ 2011-01-29 15:55 UTC (permalink / raw)
To: git
There's something strange going on there:
$ git svn clone svn://mlton.org/mlton/trunk mlton
Initialized empty Git repository in /home/fw/src/mlton/.git/
r2 = 61f0dd5ba401ece2ff4668bc7454b7742c60fa99 (refs/remotes/git-svn)
Checked out HEAD:
svn://mlton.org/mlton/trunk r2
$
"git svn fetch" is able to continue, though, so this is only a very
minor inconvenience.
^ permalink raw reply
* Re: Can't find the revelant commit with git-log
From: René Scharfe @ 2011-01-29 15:17 UTC (permalink / raw)
To: Francis Moreau; +Cc: git, Johannes Sixt, Nguyen Thai Ngoc Duy
In-Reply-To: <m2k4hn6cek.fsf@gmail.com>
Am 29.01.2011 14:57, schrieb Francis Moreau:
> René Scharfe <rene.scharfe@lsrfire.ath.cx> writes:
>
>> Am 29.01.2011 13:52, schrieb Francis Moreau:
>>> René Scharfe <rene.scharfe@lsrfire.ath.cx> writes:
>>>
>>>> Am 26.01.2011 19:11, schrieb René Scharfe:
>>
>>>>> - Make git grep report non-matching path specs (new feature).
>>>>
>>>> This is a bit complicated because grep can work on files, index entries
>>>> as well as versioned objects and supports wildcards,
>>>> so it's not that easy to tell if a path spec matches something or is a
>>>> rather typo. But it's not impossible either, of course.
>>>
>>> I don't understand this for the following use case:
>>>
>>> $ cd ~/linux-2.6/drivers/pci/
>>> $ git grep blacklist v2.6.27 -- drivers/pci/intel-iommu.c
>>>
>>> From what you said, it sounds that git grep is actually searching the
>>> string 'somewhere'. But where ?
>>
>> All files in the directory are looked at and checked if they match the
>> given path spec first. Since none of them do, no actual text search has
>> to take place.
>
> and in this case, it is complicated to tell that the given path spec
> match nothing. right ?
The specific case is easy to handle, but a complete solution would have
to address files, index entries as well as versioned objects and support
wildcards. Presumably it would come on top of Duy's pathspec work
that's in next now.
René
^ permalink raw reply
* Re: Can't find the revelant commit with git-log
From: Francis Moreau @ 2011-01-29 13:57 UTC (permalink / raw)
To: René Scharfe; +Cc: git, Johannes Sixt
In-Reply-To: <4D440FED.2010203@lsrfire.ath.cx>
René Scharfe <rene.scharfe@lsrfire.ath.cx> writes:
> Am 29.01.2011 13:52, schrieb Francis Moreau:
>> René Scharfe <rene.scharfe@lsrfire.ath.cx> writes:
>>
>>> Am 26.01.2011 19:11, schrieb René Scharfe:
>
>>>> - Make git grep report non-matching path specs (new feature).
>>>
>>> This is a bit complicated because grep can work on files, index entries
>>> as well as versioned objects and supports wildcards,
>>> so it's not that easy to tell if a path spec matches something or is a
>>> rather typo. But it's not impossible either, of course.
>>
>> I don't understand this for the following use case:
>>
>> $ cd ~/linux-2.6/drivers/pci/
>> $ git grep blacklist v2.6.27 -- drivers/pci/intel-iommu.c
>>
>> From what you said, it sounds that git grep is actually searching the
>> string 'somewhere'. But where ?
>
> All files in the directory are looked at and checked if they match the
> given path spec first. Since none of them do, no actual text search has
> to take place.
and in this case, it is complicated to tell that the given path spec
match nothing. right ?
--
Francis
^ 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