* Re: Files with colons under Cygwin
From: Dmitry Potapov @ 2008-10-04 23:39 UTC (permalink / raw)
To: Giovanni Funchal; +Cc: git, Shawn O. Pearce
In-Reply-To: <c475e2e60810020702q573570dcp31a5dc18bf98ef30@mail.gmail.com>
On Thu, Oct 02, 2008 at 04:02:23PM +0200, Giovanni Funchal wrote:
>
> Cygwin does not allow files with colons, I think this is Windows stuff
> one just can't avoid.
At least, you cannot use colon in Win32 API. They say Windows "native"
API has less restrictions over what symbols are not allowed in file
names, but I guess it is still not allowed.
> If you have files with colons in a git
> repository and try pulling them on cygwin, the file is empty, its name
> is truncated and the status is wrong.
>
> linux $ date > a:b
> linux $ git init
> linux $ git add a:b
> linux $ git commit -m test
> linux $ git push
> cygwin $ git pull
Strange... What version of Cygwin did you use? When I tried this with
Cygwin 1.5.25, I got the following error:
error: git checkout-index: unable to create file a:b (No medium found)
Apparently, Git tried to create 'b' file on the drive 'a', and creating
files outside of the working tree is not a very good thing to do from
the security point of view, as it can easily overwrite anything in
c:/windows/.
So, here is a patch. It basically disallow backslashes and colons in
file names on Windows (whether it is MinGW or Cygwin).
I wonder if the problem exists on Mac OS X too. From what I heard, it
does not treat ':' as a normal symbol. But I have no access to Mac OS X,
so here is a patch for Windows only.
-- >8 --
From: Dmitry Potapov <dpotapov@gmail.com>
Date: Sat, 4 Oct 2008 22:57:19 +0400
Subject: [PATCH] correct verify_path for Windows
Colon and backslash in names may be used on Windows to overwrite files
outside of the working directory.
Signed-off-by: Dmitry Potapov <dpotapov@gmail.com>
---
read-cache.c | 10 ++++++++++
1 files changed, 10 insertions(+), 0 deletions(-)
diff --git a/read-cache.c b/read-cache.c
index 901064b..972592e 100644
--- a/read-cache.c
+++ b/read-cache.c
@@ -701,6 +701,16 @@ inside:
}
return 0;
}
+#if defined(_WIN32) || defined(__CYGWIN__)
+ /*
+ * There is a bunch of other characters that are not allowed
+ * in Win32 API, but the following two create a security hole
+ * by allowing to overwrite files outside of the working tree,
+ * therefore they are explicitly prohibited.
+ */
+ else if (c == ':' || c == '\\')
+ return 0;
+#endif
c = *path++;
}
}
--
1.6.0.2.445.g1198
-- >8 --
^ permalink raw reply related
* Re: How to list versioned files with modification status
From: Linus Torvalds @ 2008-10-04 23:10 UTC (permalink / raw)
To: Mark Burton; +Cc: git
In-Reply-To: <loom.20081004T215458-15@post.gmane.org>
On Sat, 4 Oct 2008, Mark Burton wrote:
>
> 'git diff --name-status' looks useful but it only shows the files that have
> changed - I would like to see the names of the files that haven't changed. Even
> svn could do that (svn status).
Nobody has ever asked for such a crazy thing, but here's a test-patch to
teach 'git ls-files' the '--unmodified' flag.
It's strictly bigger than need be, partly because ls-files is a horror,
partly because it needed that 'name_status()' helper function to make it
not turn into something even worse.
I also fixed a git ls-files buglet: a deleted file implies modification,
so if you ask for --deleted _and_ --modified at the same time, you'll see
a deleted file listed twice. Use '-v' to see the type. This makes it
only show it once - as deleted if you asked for that information,
otherwise as modified.
So with something like this, you can do
git ls-files -v --modified --deleted --unmodified
and you'll see all files with a tag in front (the tag for unmodified is
empty).
Not very well tested (aka "Hey, it's a patch from Linus, caveat emptor!")
Linus
---
builtin-ls-files.c | 48 +++++++++++++++++++++++++++++++++++++++---------
1 files changed, 39 insertions(+), 9 deletions(-)
diff --git a/builtin-ls-files.c b/builtin-ls-files.c
index 068f424..27a318a 100644
--- a/builtin-ls-files.c
+++ b/builtin-ls-files.c
@@ -18,6 +18,7 @@ static int show_others;
static int show_stage;
static int show_unmerged;
static int show_modified;
+static int show_unmodified;
static int show_killed;
static int show_valid_bit;
static int line_terminator = '\n';
@@ -35,6 +36,7 @@ static const char *tag_removed = "";
static const char *tag_other = "";
static const char *tag_killed = "";
static const char *tag_modified = "";
+static const char *tag_unmodified = "";
/*
@@ -218,6 +220,20 @@ static void show_ce_entry(const char *tag, struct cache_entry *ce)
write_name_quoted(ce->name + offset, stdout, line_terminator);
}
+enum show_state {
+ unmodified, deleted, modified
+};
+
+static enum show_state name_status(struct cache_entry *ce)
+{
+ struct stat st;
+ int err = lstat(ce->name, &st);
+
+ if (err)
+ return deleted;
+ return ce_modified(ce, &st, 0) ? modified : unmodified;
+}
+
static void show_files(struct dir_struct *dir, const char *prefix)
{
int i;
@@ -248,19 +264,27 @@ static void show_files(struct dir_struct *dir, const char *prefix)
show_ce_entry(ce_stage(ce) ? tag_unmerged : tag_cached, ce);
}
}
- if (show_deleted | show_modified) {
+ if (show_deleted | show_modified | show_unmodified) {
for (i = 0; i < active_nr; i++) {
struct cache_entry *ce = active_cache[i];
- struct stat st;
- int err;
int dtype = ce_to_dtype(ce);
if (excluded(dir, ce->name, &dtype) != dir->show_ignored)
continue;
- err = lstat(ce->name, &st);
- if (show_deleted && err)
- show_ce_entry(tag_removed, ce);
- if (show_modified && ce_modified(ce, &st, 0))
- show_ce_entry(tag_modified, ce);
+ switch (name_status(ce)) {
+ default:
+ if (show_unmodified)
+ show_ce_entry(tag_unmodified, ce);
+ break;
+ case deleted:
+ if (show_deleted) {
+ show_ce_entry(tag_removed, ce);
+ break;
+ }
+ /* Fall through */
+ case modified:
+ if (show_modified)
+ show_ce_entry(tag_modified, ce);
+ }
}
}
}
@@ -457,6 +481,7 @@ int cmd_ls_files(int argc, const char **argv, const char *prefix)
tag_modified = "C ";
tag_other = "? ";
tag_killed = "K ";
+ tag_unmodified = " ";
if (arg[1] == 'v')
show_valid_bit = 1;
continue;
@@ -474,6 +499,11 @@ int cmd_ls_files(int argc, const char **argv, const char *prefix)
require_work_tree = 1;
continue;
}
+ if (!strcmp(arg, "--unmodified")) {
+ show_unmodified = 1;
+ require_work_tree = 1;
+ continue;
+ }
if (!strcmp(arg, "-o") || !strcmp(arg, "--others")) {
show_others = 1;
require_work_tree = 1;
@@ -593,7 +623,7 @@ int cmd_ls_files(int argc, const char **argv, const char *prefix)
/* With no flags, we default to showing the cached files */
if (!(show_stage | show_deleted | show_others | show_unmerged |
- show_killed | show_modified))
+ show_killed | show_modified | show_unmodified))
show_cached = 1;
read_cache();
^ permalink raw reply related
* Re: How to list versioned files with modification status
From: Dmitry Potapov @ 2008-10-04 23:09 UTC (permalink / raw)
To: Mark Burton; +Cc: git
In-Reply-To: <20081004131256.586a5fbf@smartavionics.com>
On Sat, Oct 04, 2008 at 01:12:56PM +0100, Mark Burton wrote:
>
> I would like to be able to easily find those files in a git tree that
> don't have pending modifications. Although ls-files can list the
> files that are modified, it can't list those that aren't
Well, it is a rather unusual task to have a special option devoted
to it, and you always combine a few commands together like that:
comm -3 <(git ls-files|sort) <(git ls-files -m|sort)
Dmitry
^ permalink raw reply
* Re: How to list versioned files with modification status
From: Mark Burton @ 2008-10-04 23:02 UTC (permalink / raw)
To: git
In-Reply-To: <81b0412b0810041534o7b38507qe63db47cd07fdc16@mail.gmail.com>
> > 'git diff --name-status' looks useful but it only shows the files that have
> > changed - I would like to see the names of the files that haven't changed.
>
> There is nothing to do something like that, but...
>
> > Even svn could do that (svn status).
>
> what exactly are trying to achieve? It is just strange that no one
> asked for something like this before...
What I am trying to achieve is to list the versioned files that have no
pending modifications (didn't I say that in the original posting?)
Strange, perhaps, but not completely useless in that it does tell you
something about the state of the current working set of files.
BTW - and sorry for posting the same question in two different emails, I
thought the first one had not made it onto the list - I shall be more
patient in the future.
Mark
^ permalink raw reply
* Re: Question: How to list files that haven't been modified?
From: Elijah Newren @ 2008-10-04 23:01 UTC (permalink / raw)
To: Mark Burton; +Cc: git
In-Reply-To: <loom.20081004T195935-879@post.gmane.org>
On Sat, Oct 4, 2008 at 2:07 PM, Mark Burton <markb@ordern.com> wrote:
>
> Hi,
>
> It's still early days for me and I haven't yet discovered how to ask git to list
> all the files in a tree that don't have pending modifications (staged or not). I
> have read about ls-files but it doesn't seem to offer that option. As far as I
> can tell, it can list the files known to git and the files that have been
> modified but not the difference between those sets.
You could manually construct the difference between the lists:
$ comm -3 <(git ls-files) <(git ls-files --modified)
^ permalink raw reply
* Re: How to list versioned files with modification status
From: deskinm @ 2008-10-04 22:52 UTC (permalink / raw)
To: Alex Riesen; +Cc: Mark Burton, git
In-Reply-To: <81b0412b0810041534o7b38507qe63db47cd07fdc16@mail.gmail.com>
On Sun, Oct 05, 2008 at 12:34:31AM +0200, Alex Riesen wrote:
> 2008/10/5 Mark Burton <markb@ordern.com>:
> > Alex Riesen <raa.lkml <at> gmail.com> writes:
> >> 2008/10/4 Mark Burton <markb <at> smartavionics.com>:
> >> > I would like to be able to easily find those files in a git tree that
> >> > don't have pending modifications. Although ls-files can list the
> >> > files that are modified, it can't list those that aren't or list all
> >> > files with their modification status.
> >>
> >> Maybe if you look at git diff and diff-index, you will find something
> >> what suits you better? Because "modification" is just a difference
> >> between a known (recorded in a commit or index) state and your
> >> working tree.
> >
> > 'git diff --name-status' looks useful but it only shows the files that have
> > changed - I would like to see the names of the files that haven't changed.
>
> There is nothing to do something like that, but...
>
> > Even svn could do that (svn status).
>
> what exactly are trying to achieve? It is just strange that no one
> asked for something like this before...
Apologies for the duplicate message; fighting between gmail and
vger.kernel.org.
Here's a terrible way to do this:
$ GIT_EDITOR=: git commit -a -m 'throwaway' >/dev/null
$ (git ls-tree -r HEAD; git ls-tree -r HEAD~1) \
| sort | uniq -d | sed -e 's/^[^ ]* [^ ]* [^\t]*\t//'
$ git reset HEAD~1 >/dev/null
Deskin Miller
^ permalink raw reply
* Re: [PATCH] Use "git_config_string" to simplify "remote.c" code in "handle_config"
From: Alex Riesen @ 2008-10-04 22:46 UTC (permalink / raw)
To: David Bryson; +Cc: Andreas Ericsson, git
In-Reply-To: <20081003200613.GO20571@eratosthenes.cryptobackpack.org>
2008/10/3 David Bryson <david@statichacks.org>:
> On Fri, Oct 03, 2008 at 07:28:42AM +0200 or thereabouts, Andreas Ericsson wrote:
>> David Bryson wrote:
> Oh I agree entirely, it is quite vague, however like I mentioned I tried
> to keep to the conventios in the file. This strategy(v) is used in several
> other places in remote.c, if this is Bad Code, then I have no problem
> changing it.
>
> Thoughts from anybody else ?
>
You can redeclare of the variable in the contexts where
it is used and not even rename it: it is close to its users then.
^ permalink raw reply
* Re: How to list versioned files with modification status
From: Alex Riesen @ 2008-10-04 22:34 UTC (permalink / raw)
To: Mark Burton; +Cc: git
In-Reply-To: <loom.20081004T215458-15@post.gmane.org>
2008/10/5 Mark Burton <markb@ordern.com>:
> Alex Riesen <raa.lkml <at> gmail.com> writes:
>> 2008/10/4 Mark Burton <markb <at> smartavionics.com>:
>> > I would like to be able to easily find those files in a git tree that
>> > don't have pending modifications. Although ls-files can list the
>> > files that are modified, it can't list those that aren't or list all
>> > files with their modification status.
>>
>> Maybe if you look at git diff and diff-index, you will find something
>> what suits you better? Because "modification" is just a difference
>> between a known (recorded in a commit or index) state and your
>> working tree.
>
> 'git diff --name-status' looks useful but it only shows the files that have
> changed - I would like to see the names of the files that haven't changed.
There is nothing to do something like that, but...
> Even svn could do that (svn status).
what exactly are trying to achieve? It is just strange that no one
asked for something like this before...
^ permalink raw reply
* Re: How to list versioned files with modification status
From: Mark Burton @ 2008-10-04 22:09 UTC (permalink / raw)
To: git
In-Reply-To: <81b0412b0810041440w131647aeo9c14f55cd38da635@mail.gmail.com>
Alex Riesen <raa.lkml <at> gmail.com> writes:
>
> 2008/10/4 Mark Burton <markb <at> smartavionics.com>:
> > I would like to be able to easily find those files in a git tree that
> > don't have pending modifications. Although ls-files can list the
> > files that are modified, it can't list those that aren't or list all
> > files with their modification status.
>
> Maybe if you look at git diff and diff-index, you will find something
> what suits you better? Because "modification" is just a difference
> between a known (recorded in a commit or index) state and your
> working tree.
>
'git diff --name-status' looks useful but it only shows the files that have
changed - I would like to see the names of the files that haven't changed. Even
svn could do that (svn status).
Thanks,
Mark
^ permalink raw reply
* Re: Forcing progerss output for clone
From: Alex Riesen @ 2008-10-04 21:42 UTC (permalink / raw)
To: Constantine Plotnikov; +Cc: git
In-Reply-To: <85647ef50810031301k641c5f24n65fb213c2b481e7@mail.gmail.com>
2008/10/3 Constantine Plotnikov <constantine.plotnikov@gmail.com>:
> Is there a way to force a progress output on stderr for git clone
> preferably using options or environment variables?
No, but "-v" option is not used for anything yet, so you are free to
implement it.
^ permalink raw reply
* Re: How to list versioned files with modification status
From: Alex Riesen @ 2008-10-04 21:40 UTC (permalink / raw)
To: Mark Burton; +Cc: git
In-Reply-To: <20081004131256.586a5fbf@smartavionics.com>
2008/10/4 Mark Burton <markb@smartavionics.com>:
> I would like to be able to easily find those files in a git tree that
> don't have pending modifications. Although ls-files can list the
> files that are modified, it can't list those that aren't or list all
> files with their modification status.
Maybe if you look at git diff and diff-index, you will find something
what suits you better? Because "modification" is just a difference
between a known (recorded in a commit or index) state and your
working tree.
^ permalink raw reply
* How to list versioned files with modification status
From: Mark Burton @ 2008-10-04 12:12 UTC (permalink / raw)
To: git
Hi,
I would like to be able to easily find those files in a git tree that
don't have pending modifications. Although ls-files can list the
files that are modified, it can't list those that aren't or list all
files with their modification status.
Thanks,
Mark
--
Smart Avionics Ltd. -- producer of innovative avionics for homebuilt
aircraft.
^ permalink raw reply
* Question: How to list files that haven't been modified?
From: Mark Burton @ 2008-10-04 20:07 UTC (permalink / raw)
To: git
Hi,
It's still early days for me and I haven't yet discovered how to ask git to list
all the files in a tree that don't have pending modifications (staged or not). I
have read about ls-files but it doesn't seem to offer that option. As far as I
can tell, it can list the files known to git and the files that have been
modified but not the difference between those sets.
Thanks,
Mark
^ permalink raw reply
* Re: git apply: git diff header lacks filename information for git diff --no-index patch
From: Linus Torvalds @ 2008-10-04 17:48 UTC (permalink / raw)
To: Jeff King; +Cc: Imre Deak, git
In-Reply-To: <alpine.LFD.2.00.0810041004290.3208@nehalem.linux-foundation.org>
On Sat, 4 Oct 2008, Linus Torvalds wrote:
>
> Ahh, never mind, this one is broken.
Ok, so here's a much better version, I think.
It just refuses to use an invalid name for anything visible in the diff.
Now, this fixes the "git diff --no-index --binary a /dev/null" kind of
case (and we'll end up using "a" as the basename), but some other insane
cases are impossible to handle. If you do
git diff --no-index --binary a /bin/echo
you'll still get a patch like
diff --git a/a b/bin/echo
old mode 100644
new mode 100755
index ...
and "git apply" will refuse to apply it for a couple of reasons, and the
diff is simply bogus.
And that, btw, is no longer a bug, I think. It's impossible to know whethe
the user meant for the patch to be a rename or not. And as such, refusing
to apply it because you don't know what name you should use is probably
_exactly_ the right thing to do!
Linus
----
diff.c | 4 ++++
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/diff.c b/diff.c
index 9053d4d..197533e 100644
--- a/diff.c
+++ b/diff.c
@@ -1493,6 +1493,10 @@ static void builtin_diff(const char *name_a,
b_prefix = o->b_prefix;
}
+ /* Never use a non-valid filename anywhere if at all possible */
+ name_a = DIFF_FILE_VALID(one) ? name_a : name_b;
+ name_b = DIFF_FILE_VALID(two) ? name_b : name_a;
+
a_one = quote_two(a_prefix, name_a + (*name_a == '/'));
b_two = quote_two(b_prefix, name_b + (*name_b == '/'));
lbl[0] = DIFF_FILE_VALID(one) ? a_one : "/dev/null";
^ permalink raw reply related
* Re: git apply: git diff header lacks filename information for git diff --no-index patch
From: Linus Torvalds @ 2008-10-04 17:08 UTC (permalink / raw)
To: Jeff King; +Cc: Imre Deak, git
In-Reply-To: <alpine.LFD.2.00.0810040918290.3208@nehalem.linux-foundation.org>
On Sat, 4 Oct 2008, Linus Torvalds wrote:
>
> Anyway, for now I'd suggest a patch like this. Hmm? The "diff --git"
> format assumes that the names are the same, so make it so.
Ahh, never mind, this one is broken. It's not _horribly_ so, but I
shouldhave checked the test breakage. It changes non-broken cases from
diff --git a/file b/file
into
diff --git a/file a/file
so the header thing would need to be done differently. Don't even bother
with that broken patch. I'll think about doing it better.
Linus
^ permalink raw reply
* Re: git apply: git diff header lacks filename information for git diff --no-index patch
From: Linus Torvalds @ 2008-10-04 16:54 UTC (permalink / raw)
To: Jeff King; +Cc: Imre Deak, git
In-Reply-To: <20081004041714.GA12413@coredump.intra.peff.net>
On Sat, 4 Oct 2008, Jeff King wrote:
> On Thu, Oct 02, 2008 at 09:27:36PM +0300, Imre Deak wrote:
> > $ git apply patch
> > fatal: git diff header lacks filename information (line 4)
> > $ cat patch
> > diff --git a/dev/null b/a
> > new file mode 100644
> > index 0000000000000000000000000000000000000000..1f2a4f5ef3df7f7456d91c961da36fc58904f2f1
> > GIT binary patch
Ok, this patch is broken in so many ways..
> Hmm. The problem is that "git apply" doesn't accept that "a/dev/null"
> and "b/a" are the same, so it rejects them as a name. I guess on a text
> patch, we would just pull that information from the "---" and "+++"
> lines, so we don't care that it's not on the diff commandline.
Exactly. In order to avoid all the ambiguities, we want the filename to
match on the 'diff -' line to even be able to guess, and if it doesn't, we
should pick it up from the "rename from" lines (for a git diff), or from
the '--- a/filename'/'+++ b/filename' otherwise (if it's not a rename, or
not a git diff).
And being a binary diff, and a creation event, all of this fails.
To make things worse, git has also screwed up the "/dev/null" and
prepended the prefix to it, making it even harder to see any patterns to
the names. Gaah.
> However, a _non_ --no-index patch doesn't produce the same output. It
> will actually produce the line:
>
> diff --git a/a b/a
>
> even if it is a creation patch. So I'm not sure which piece of code is
> at fault.
It's some of both. I think --no-index is broken, that "a/dev/null" is
total crap regardless of anything else. There's no way that thing is
correct, and even if you were not to want "a/a", it should have been just
plain "/dev/null".
But for a native git patch, we shouldn't even use the (at least slightly
more correct) "/dev/null", since native git application doesn't actually
do the "is_dev_null()" for native patches, and just wants the filename to
be the same.
So I think "git apply" is correct, and "git diff --no-index" is broken.
That said, I think git-apply being "correct" is not a great excuse, and we
should do the "be liberal in what you accept, conservative in what you
generate", and think about how to make git-apply be more willing to handle
this case too.
Quite frankly, I should have doen the explicit headers as
"new file " <mode> SP <name>
instead of
"new file mode " <mode>
(and same for "deleted file", obviously) and the patch would have been
more readable _and_ we'd have avoided this issue. But when I did all that,
I didn't even think of binary diffs (they weren't an issue originally).
Dang.
Anyway, for now I'd suggest a patch like this. Hmm? The "diff --git"
format assumes that the names are the same, so make it so.
Linus
---
diff.c | 5 +++--
1 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/diff.c b/diff.c
index 9053d4d..0910b4e 100644
--- a/diff.c
+++ b/diff.c
@@ -1479,7 +1479,7 @@ static void builtin_diff(const char *name_a,
{
mmfile_t mf1, mf2;
const char *lbl[2];
- char *a_one, *b_two;
+ char *a_one, *b_two, *h_name;
const char *set = diff_get_color_opt(o, DIFF_METAINFO);
const char *reset = diff_get_color_opt(o, DIFF_RESET);
const char *a_prefix, *b_prefix;
@@ -1497,7 +1497,8 @@ static void builtin_diff(const char *name_a,
b_two = quote_two(b_prefix, name_b + (*name_b == '/'));
lbl[0] = DIFF_FILE_VALID(one) ? a_one : "/dev/null";
lbl[1] = DIFF_FILE_VALID(two) ? b_two : "/dev/null";
- fprintf(o->file, "%sdiff --git %s %s%s\n", set, a_one, b_two, reset);
+ h_name = DIFF_FILE_VALID(one) ? a_one : b_two;
+ fprintf(o->file, "%sdiff --git %s %s%s\n", set, h_name, h_name, reset);
if (lbl[0][0] == '/') {
/* /dev/null */
fprintf(o->file, "%snew file mode %06o%s\n", set, two->mode, reset);
^ permalink raw reply related
* GitTogether topics status (4th of October)
From: Christian Couder @ 2008-10-04 16:16 UTC (permalink / raw)
To: git; +Cc: Shawn O. Pearce, Junio C Hamano, Scott Chacon, Sam Vilain,
Petr Baudis
Hi,
As can be seen on the GitTogether page on the wiki:
http://git.or.cz/gitwiki/GitTogether
the planned speakers/topics changed a lot during the last weeks and are now:
- Johannes Schindelin (Google Tech Talk, 1 hour):
Contributing with Git (or: all your rebase are belong to us)
- Shawn O. Pearce (Talk + Brainstorm, 1 hour):
Introduce the secret bundle project
- Shawn O. Pearce (Talk + Debate, 0.5 hour):
JGit, where is it going?
- Shawn O. Pearce (Talk + Plan Hacking, 1 hour):
Pack v4, what's stopping you?
- Sam Vilain (?):
GitTorrent, Git as a DB backend, perl.git conversion
- Junio C Hamano (Talk, 1 hour):
Git Chronicle, Recent Additions to Git
- Scott Chacon (Talk/Discussion, 1 hour):
Linkable library, Scriptability
- Scott Chacon (Hack Session(proposed)):
Architecting / Building a usable linkable library
- Scott Chacon (Lightning Talk, 10 min):
iGitHub - git daemon and repository browser on the iPhone
- Tom Preston-Werner (Talk/Discussion, 1 hour)
Git ideas from GitHub
- ? (Talk/Discussion, 1 hour):
New git homepage hammering out
- ? (Talk/Discussion, 1 hour):
Git GUI that even a designer would use
There are still many things that are not clear or undecided. So more input
is welcome.
The topics suggested on the wiki are:
* GitTorrent: current state, security considerations, future direction
* Submodules: how to make a UI for this important feature that is intuitive
and complete
* PackV4
* JGit, quo vadis?
* Using Git for everything but source (Git as a backup tool, how to handle
large blobs, using as a DB back-end, etc)
* How to make Git more attractive to the Google Code folks?
* Success/War stories (big wanking session for Gits)
* perl.git - the joy of grokking Perforce metadata using Postgres, and
writing a transactional git-fastimport exporter SamV
* Linkable library for basic object access (libification or new library)
* Scriptability, using git in other languages (using interfaces vs calling
plumbing vs reimplementting)
* Git GUI that even a designer could use (GitCheetah, AKA TortoiseGit?) (UI
session?)
* Git integration with IDE, RAD, and editors (UI session?)
* New Git Homepage hammering-out (UI session?)
* Shawn's current bundle related secret project
* TopGit introduction/design/integration(?)
* Pasky's current pickaxe related "secret project" (if tangible by then)
* Extending Git with volatile metadata database (see
[http://mid.gmane.org/20080910164045.GL10360@machine.or.cz
20080910164045.GL10360@machine.or.cz])
* Git improvement ideas gleaned from creating and running Git``Hub as a
social layer on top of Git
* Git Survey 2008 results and discussion
* Free form "We tried to use git in our project this way, didn't work very
well" session, where participants are not allowed to say "Your workflow is
broken".
Thanks,
Christian.
^ permalink raw reply
* RE: [QGit] [PATCH] Modify Highlight Color at File Context View.
From: Li Frank-B20596 @ 2008-10-04 14:32 UTC (permalink / raw)
To: Marco Costalba; +Cc: git
In-Reply-To: <e5bfff550810032319s57a0cd52m37aeb8d801019150@mail.gmail.com>
Marco:
It is difference between my patch and you applied patch.
Git diff HEAD^
- item->setForeground(b);
+ item->setForeground(fore);
+ item->setForeground(back);
item->setFont(f);
In my patch:
- item->setForeground(b);
+ item->setForeground(fore);
+ item->setBackground(back);
It should be setBackground(back), not setForeground(back);
Best regards
Frank Li
-----Original Message-----
From: Marco Costalba [mailto:mcostalba@gmail.com]
Sent: Saturday, October 04, 2008 2:20 PM
To: Li Frank-B20596
Cc: git@vger.kernel.org
Subject: Re: [QGit] [PATCH] Modify Highlight Color at File Context View.
On Wed, Oct 1, 2008 at 8:47 AM, Marco Costalba <mcostalba@gmail.com>
wrote:
> On Mon, Sep 29, 2008 at 3:27 AM, Li Frank-B20596
<Frank.Li@freescale.com> wrote:
>> Marco:
>>
>> I don't get my patch by git-pull.
>> There are not my patch at
>> http://git.kernel.org/?p=qgit/qgit4.git;a=summary.
>>
>> best regards
>> Frank Li
>> ________________________________
>
> I have pushed to my local repo, I will be able to push to public repo
> only this week end.
>
Ok. Now is pushed to public repo.
Frank, are you sure it works? for me it does not seem to make any
difference.
Marco
^ permalink raw reply
* [PATCH v3] Add git-svn branch to allow branch creation in SVN repositories
From: Deskin Miller @ 2008-10-04 14:24 UTC (permalink / raw)
To: rafl, normalperson; +Cc: spearce, git
>From 7a8a811bbb229825da8c90e71c57a60634a9280b Mon Sep 17 00:00:00 2001
From: Florian Ragwitz <rafl@debian.org>
Date: Tue, 2 Sep 2008 14:20:39 +0000
Signed-off-by: Florian Ragwitz <rafl@debian.org>
Signed-off-by: Deskin Miller <deskinm@umich.edu>
---
Eric Wong <normalperson <at> yhbt.net> writes:
> Florian Ragwitz <rafl <at> debian.org> wrote:
> > Signed-off-by: Florian Ragwitz <rafl <at> debian.org>
>
> The patch looks good, but can you add a test for this functionality?
Here's a new patch with tests for this feature. There are also some minor
changes to Florian's patch: branch now parses -t/--tag, and some of the
messages in cmd_branch change depending on $_tag also.
Florian, I apologise if I'm stepping on your toes here; this is a feature I
would've written if I was better at Perl, so I want to see it included, and I'm
glad for your work on it.
Documentation/git-svn.txt | 24 ++++++++++++++++-
git-svn.perl | 46 +++++++++++++++++++++++++++++++-
t/t9128-git-svn-cmd-branch.sh | 59 +++++++++++++++++++++++++++++++++++++++++
3 files changed, 127 insertions(+), 2 deletions(-)
create mode 100755 t/t9128-git-svn-cmd-branch.sh
diff --git a/Documentation/git-svn.txt b/Documentation/git-svn.txt
index 1e644ca..0fe4955 100644
--- a/Documentation/git-svn.txt
+++ b/Documentation/git-svn.txt
@@ -149,6 +149,22 @@ and have no uncommitted changes.
is very strongly discouraged.
--
+'branch'::
+ Create a branch in the SVN repository.
+
+-m;;
+--message;;
+ Allows to specify the commit message.
+
+-t;;
+--tag;;
+ Create a tag by using the tags_subdir instead of the branches_subdir
+ specified during git svn init.
+
+'tag'::
+ Create a tag in the SVN repository. This is a shorthand for
+ 'branch -t'.
+
'log'::
This should make it easy to look up svn log messages when svn
users refer to -r/--revision numbers.
@@ -372,7 +388,8 @@ Passed directly to 'git-rebase' when using 'dcommit' if a
-n::
--dry-run::
-This can be used with the 'dcommit' and 'rebase' commands.
+This can be used with the 'dcommit', 'rebase', 'branch' and 'tag'
+commands.
For 'dcommit', print out the series of git arguments that would show
which diffs would be committed to SVN.
@@ -381,6 +398,9 @@ For 'rebase', display the local branch associated with the upstream svn
repository associated with the current branch and the URL of svn
repository that will be fetched from.
+For 'branch' and 'tag', display the urls that will be used for copying when
+creating the branch or tag.
+
--
ADVANCED OPTIONS
@@ -498,6 +518,8 @@ Tracking and contributing to an entire Subversion-managed project
git svn clone http://svn.foo.org/project -T trunk -b branches -t tags
# View all branches and tags you have cloned:
git branch -r
+# Create a new branch in SVN
+ git svn branch waldo
# Reset your master to trunk (or any other branch, replacing 'trunk'
# with the appropriate name):
git reset --hard remotes/trunk
diff --git a/git-svn.perl b/git-svn.perl
index 80a5728..e7b9254 100755
--- a/git-svn.perl
+++ b/git-svn.perl
@@ -66,7 +66,7 @@ my ($_stdin, $_help, $_edit,
$_version, $_fetch_all, $_no_rebase,
$_merge, $_strategy, $_dry_run, $_local,
$_prefix, $_no_checkout, $_url, $_verbose,
- $_git_format, $_commit_url);
+ $_git_format, $_commit_url, $_tag);
$Git::SVN::_follow_parent = 1;
my %remote_opts = ( 'username=s' => \$Git::SVN::Prompt::_username,
'config-dir=s' => \$Git::SVN::Ra::config_dir,
@@ -131,6 +131,15 @@ my %cmd = (
'revision|r=i' => \$_revision,
'no-rebase' => \$_no_rebase,
%cmt_opts, %fc_opts } ],
+ branch => [ \&cmd_branch,
+ 'Create a branch in the SVN repository',
+ { 'message|m=s' => \$_message,
+ 'dry-run|n' => \$_dry_run,
+ 'tag|t' => \$_tag } ],
+ tag => [ sub { $_tag = 1; cmd_branch(@_) },
+ 'Create a tag in the SVN repository',
+ { 'message|m=s' => \$_message,
+ 'dry-run|n' => \$_dry_run } ],
'set-tree' => [ \&cmd_set_tree,
"Set an SVN repository to a git tree-ish",
{ 'stdin|' => \$_stdin, %cmt_opts, %fc_opts, } ],
@@ -537,6 +546,41 @@ sub cmd_dcommit {
unlink $gs->{index};
}
+sub cmd_branch {
+ my ($branch_name, $head) = @_;
+
+ die ($_tag ? "tag" : "branch") . " name required\n"
+ unless $branch_name;
+ $head ||= 'HEAD';
+
+ my ($src, $rev, undef, $gs) = working_head_info($head);
+
+ my $remote = Git::SVN::read_all_remotes()->{svn};
+ my $glob = $remote->{ $_tag ? 'tags' : 'branches' };
+ my ($lft, $rgt) = @{ $glob->{path} }{qw/left right/};
+ my $dst = join '/', $remote->{url}, $lft, $branch_name, ($rgt || ());
+
+ my $ctx = SVN::Client->new(
+ auth => Git::SVN::Ra::_auth_providers(),
+ log_msg => sub {
+ ${ $_[0] } = defined $_message
+ ? $_message
+ : 'Create ' . ($_tag ? 'tag ' : 'branch ' )
+ . $branch_name;
+ },
+ );
+
+ eval {
+ $ctx->ls($dst, 'HEAD', 0);
+ } and die "branch ${branch_name} already exists\n";
+
+ print "Copying ${src} at r${rev} to ${dst}...\n";
+ $ctx->copy($src, $rev, $dst)
+ unless $_dry_run;
+
+ $gs->fetch_all;
+}
+
sub cmd_find_rev {
my $revision_or_hash = shift or die "SVN or git revision required ",
"as a command-line argument\n";
diff --git a/t/t9128-git-svn-cmd-branch.sh b/t/t9128-git-svn-cmd-branch.sh
new file mode 100755
index 0000000..47c4d4d
--- /dev/null
+++ b/t/t9128-git-svn-cmd-branch.sh
@@ -0,0 +1,59 @@
+#!/bin/sh
+#
+# Copyright (c) 2008 Deskin Miller
+#
+
+test_description='git svn partial-rebuild tests'
+. ./lib-git-svn.sh
+
+test_expect_success 'initialize svnrepo' '
+ mkdir import &&
+ (
+ cd import &&
+ mkdir trunk branches tags &&
+ cd trunk &&
+ echo foo > foo &&
+ cd .. &&
+ svn import -m "import for git-svn" . "$svnrepo" >/dev/null &&
+ cd .. &&
+ rm -rf import &&
+ svn co "$svnrepo"/trunk trunk &&
+ cd trunk &&
+ echo bar >> foo &&
+ svn ci -m "updated trunk" &&
+ cd .. &&
+ rm -rf trunk
+ )
+'
+
+test_expect_success 'import into git' '
+ git svn init --stdlayout "$svnrepo" &&
+ git svn fetch &&
+ git checkout remotes/trunk
+'
+
+test_expect_success 'git svn branch tests' '
+ git svn branch a &&
+ base=$(git rev-parse HEAD:) &&
+ test $base = $(git rev-parse remotes/a:) &&
+ git svn branch -m "created branch b blah" b &&
+ test $base = $(git rev-parse remotes/b:) &&
+ test_must_fail git branch -m "no branchname" &&
+ git svn branch -n c &&
+ test_must_fail git rev-parse remotes/c &&
+ test_must_fail git svn branch a &&
+ git svn branch -t tag1 &&
+ test $base = $(git rev-parse remotes/tags/tag1:) &&
+ git svn branch --tag tag2 &&
+ test $base = $(git rev-parse remotes/tags/tag2:) &&
+ git svn tag tag3 &&
+ test $base = $(git rev-parse remotes/tags/tag3:) &&
+ git svn tag -m "created tag4 foo" tag4 &&
+ test $base = $(git rev-parse remotes/tags/tag4:) &&
+ test_must_fail git svn tag -m "no tagname" &&
+ git svn tag -n tag5 &&
+ test_must_fail git rev-parse remotes/tags/tag5 &&
+ test_must_fail git svn tag tag1
+'
+
+test_done
--
1.6.0.2.307.gc427
^ permalink raw reply related
* Build bug report: 'make check' needs sparse, but configure doesn't check it
From: Ed Avis @ 2008-10-04 13:19 UTC (permalink / raw)
To: git
When you build git-1.6.0.2 and 'make check', it tries to run sparse and fails if
sparse is not there. But the configure script does not check sparse is
installed.
I suggest that 'make check' skip the sparse tests if sparse is not there. As I
understand it, they are really more for the developers to get a report of
possible errors in the source code and not to test that the built executables
work, so it would not be dangerous to just skip running those tests for ordinary
users who don't have the tool.
Alternatively, if running sparse is really important for a thorough 'make
check', the configure script should check for it and warn you to install it.
--
Ed Avis <ed@membled.com>
^ permalink raw reply
* Re: git apply: git diff header lacks filename information for git diff --no-index patch
From: Jakub Narebski @ 2008-10-04 8:28 UTC (permalink / raw)
To: git
In-Reply-To: <20081004041714.GA12413@coredump.intra.peff.net>
[Cc: git@vger.kernel.org, Jeff King <peff@peff.net>,
Imre Deak <imre.deak@gmail.com>]
Jeff King wrote:
> On Thu, Oct 02, 2008 at 09:27:36PM +0300, Imre Deak wrote:
>
>> $ git apply patch
>> fatal: git diff header lacks filename information (line 4)
>> $ cat patch
>> diff --git a/dev/null b/a
>> new file mode 100644
>> index 0000000000000000000000000000000000000000..1f2a4f5ef3df7f7456d91c961da36fc58904f2f1
>> GIT binary patch
>
> Hmm. The problem is that "git apply" doesn't accept that "a/dev/null"
> and "b/a" are the same, so it rejects them as a name. I
Shouldn't it be "/dev/null", not "a/dev/null"?
Besides git-diff(1) states:
1. It is preceded with a "git diff" header, that looks like
this:
diff --git a/file1 b/file2
The `a/` and `b/` filenames are the same unless rename/copy is
involved. Especially, even for a creation or a deletion,
`/dev/null` is _not_ used in place of `a/` or `b/` filenames.
Looks like a bug in patch generation code...
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: [PATCHv4] gitweb: parse parent..current syntax from pathinfo
From: Jakub Narebski @ 2008-10-04 7:48 UTC (permalink / raw)
To: Giuseppe Bilotta; +Cc: git, Petr Baudis, Junio C Hamano, Shawn O. Pearce
In-Reply-To: <cb7bb73a0810040024q4dfad117uf719f0aaa17ae95b@mail.gmail.com>
Giuseppe Bilotta wrote:
> On Sat, Oct 4, 2008 at 3:31 AM, Jakub Narebski <jnareb@gmail.com> wrote:
>> On Thu, 2 Oct 2008, Giuseppe Bilotta wrote:
>>
>>> This makes it possible to use an URL such as
>>> $project/somebranch..otherbranch:/filename to get a diff between
>>> different version of a file. Paths like
>>> $project/$action/somebranch:/somefile..otherbranch:/otherfile are parsed
>>> as well.
>>>
>>
>> In short, it allows to have link to '*diff' views using path_info URL,
>> or in general to pass $hash_[parent_]base and $file_parent using
>> path_info.
>
> Yes, that's probably a better form for the commit message.
I have thought about this rather as supplement (addition) to the
current commit message (which states explicitly new form of supported
path_info URL), than replacing it.
>> The following path_info layouts with '..' make sense:
>>
>> hpb:fp..hb:f
>> hpb..hb:f == hpb:f..hb:f
>> hp..h
>
> And these are matched by the above regexp
>
>> And the layout below can be though to make sense, but it is just
>> plain weird.
>>
>> hpb:fp..f == hpb:fp..HEAD:f
>
> I'm afraid I'm not going to support that, although it's probably easy
> to support hpb:fp..:f (i.e. accept a missing refname but on condition
> of having a : in front of the file spec).
No, not supporting this form is just fine.
>>> + if (defined $input_params{'file_parent'}) {
>>> + $input_params{'hash_parent'} ||= git_get_hash_by_path($input_params{'hash_parent_base'}, $input_params{'file_parent'});
>>
>> This line is bit long, and I think it should be wrapped..
>
> By the way, on the first revision of the path_info patchset, you had me discard
>
> $hash ||= git_get_hash_by_path($hash_base, $file_name);
>
> in the simple case on the basis that it was an extra call to external git.
>
> I actually forgot to remove it from this part of the patchset too at
> the time, so this gets me wondering about this: should I put it back
> in place in the simple case, or remove it from here too?
I think you should remove it here too. IMHO if needed, it should be
dealt with (and I think is dealt with) in appropriate action subroutine.
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: [PATCHv4] gitweb: parse parent..current syntax from pathinfo
From: Giuseppe Bilotta @ 2008-10-04 7:24 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git, Petr Baudis, Junio C Hamano, Shawn O. Pearce
In-Reply-To: <200810040331.27605.jnareb@gmail.com>
On Sat, Oct 4, 2008 at 3:31 AM, Jakub Narebski <jnareb@gmail.com> wrote:
> On Thu, 2 Oct 2008, Giuseppe Bilotta wrote:
>
>> This makes it possible to use an URL such as
>> $project/somebranch..otherbranch:/filename to get a diff between
>> different version of a file. Paths like
>> $project/$action/somebranch:/somefile..otherbranch:/otherfile are parsed
>> as well.
>>
>
> In short, it allows to have link to '*diff' views using path_info URL,
> or in general to pass $hash_[parent_]base and $file_parent using
> path_info.
Yes, that's probably a better form for the commit message.
>> Signed-off-by: Giuseppe Bilotta <giuseppe.bilotta@gmail.com>
>> ---
>> gitweb/gitweb.perl | 26 ++++++++++++++++++++++++--
>> 1 files changed, 24 insertions(+), 2 deletions(-)
>>
>> diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
>> index 3e5b2b7..89e360f 100755
>> --- a/gitweb/gitweb.perl
>> +++ b/gitweb/gitweb.perl
>> @@ -534,7 +534,9 @@ if ($path_info && !defined $action) {
>>
>> # we can now parse ref and pathnames in PATH_INFO
>> if ($path_info) {
>> - my ($refname, $pathname) = split(/:/, $path_info, 2);
>> + $path_info =~ /^((.+?)(:(.+))?\.\.)?(.+?)(:(.+))?$/;
>> + my ($parentrefname, $parentpathname, $refname, $pathname) = (
>> + $2, $4, $5, $7);
>
> Style: I would use (but that is perhaps matter of taste)
>
> + my ($parentrefname, $parentpathname, $refname, $pathname) =
> + ($2, $4, $5, $7);
Right, I'm not sure why I put the ( on the previous line.
> Also it would be I think simpler to use instead non-catching grouping,
> i.e. (?: xxx ) extended pattern (see perlre(1)), and use
> ($1, $2, $3, $4), or even simpler 'list = (string =~ regexp)' form.
Good idea, I'll rework it in that sense.
> I also think that the situation is more complicated than that, if we
> want to be more correct.
>
> The following path_info layouts with '..' make sense:
>
> hpb:fp..hb:f
> hpb..hb:f == hpb:f..hb:f
> hp..h
And these are matched by the above regexp
> And the layout below can be though to make sense, but it is just
> plain weird.
>
> hpb:fp..f == hpb:fp..HEAD:f
I'm afraid I'm not going to support that, although it's probably easy
to support hpb:fp..:f (i.e. accept a missing refname but on condition
of having a : in front of the file spec).
>> + if (defined $input_params{'file_parent'}) {
>> + $input_params{'hash_parent'} ||= git_get_hash_by_path($input_params{'hash_parent_base'}, $input_params{'file_parent'});
>
> This line is bit long, and I think it should be wrapped..
By the way, on the first revision of the path_info patchset, you had me discard
$hash ||= git_get_hash_by_path($hash_base, $file_name);
in the simple case on the basis that it was an extra call to external git.
I actually forgot to remove it from this part of the patchset too at
the time, so this gets me wondering about this: should I put it back
in place in the simple case, or remove it from here too?
--
Giuseppe "Oblomov" Bilotta
^ permalink raw reply
* Re: [QGit] [PATCH] Modify Highlight Color at File Context View.
From: Marco Costalba @ 2008-10-04 6:19 UTC (permalink / raw)
To: Li Frank-B20596; +Cc: git
In-Reply-To: <e5bfff550809302347r59621e09sdea5c679ef3794c8@mail.gmail.com>
On Wed, Oct 1, 2008 at 8:47 AM, Marco Costalba <mcostalba@gmail.com> wrote:
> On Mon, Sep 29, 2008 at 3:27 AM, Li Frank-B20596 <Frank.Li@freescale.com> wrote:
>> Marco:
>>
>> I don't get my patch by git-pull.
>> There are not my patch at
>> http://git.kernel.org/?p=qgit/qgit4.git;a=summary.
>>
>> best regards
>> Frank Li
>> ________________________________
>
> I have pushed to my local repo, I will be able to push to public repo
> only this week end.
>
Ok. Now is pushed to public repo.
Frank, are you sure it works? for me it does not seem to make any difference.
Marco
^ permalink raw reply
* Re: git apply: git diff header lacks filename information for git diff --no-index patch
From: Jeff King @ 2008-10-04 4:17 UTC (permalink / raw)
To: Imre Deak; +Cc: Linus Torvalds, git
In-Reply-To: <500f3d130810021127j570bb540p901f6a73f58a6cb1@mail.gmail.com>
On Thu, Oct 02, 2008 at 09:27:36PM +0300, Imre Deak wrote:
> $ git apply patch
> fatal: git diff header lacks filename information (line 4)
> $ cat patch
> diff --git a/dev/null b/a
> new file mode 100644
> index 0000000000000000000000000000000000000000..1f2a4f5ef3df7f7456d91c961da36fc58904f2f1
> GIT binary patch
Hmm. The problem is that "git apply" doesn't accept that "a/dev/null"
and "b/a" are the same, so it rejects them as a name. I guess on a text
patch, we would just pull that information from the "---" and "+++"
lines, so we don't care that it's not on the diff commandline.
However, a _non_ --no-index patch doesn't produce the same output. It
will actually produce the line:
diff --git a/a b/a
even if it is a creation patch. So I'm not sure which piece of code is
at fault. Either:
1. git apply is right to reject, and "git diff --no-index" should be
putting the actual filename on the commandline of a binary patch
instead of /dev/null, even if it is a creation patch.
or
2. git apply should accept this construct. Perhaps we should relax the
"both names must be the same" rule if one of the names is /dev/null
(and we would take the other)?
Linus, the "both names must be the same" code in git_header_name blames
to you (5041aa70). Thoughts on number 2?
-Peff
^ 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