* Re: JGIT: discuss: diff/patch implementation
From: Francis Galiegue @ 2008-11-10 20:21 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Git Mailing List, Shawn O. Pearce, Robin Rosenberg
In-Reply-To: <alpine.DEB.1.00.0811102030180.30769@pacific.mpi-cbg.de>
Le Monday 10 November 2008 20:46:02 Johannes Schindelin, vous avez écrit :
> Hi,
>
> On Mon, 10 Nov 2008, Francis Galiegue wrote:
> > A very nice git feature, without even going as far as merges, is the
> > cherry pick feature.
> >
> > For this to be doable from within the Eclipse Git plugin, a diff/patch
> > implementation needs to be found, in a license compatible with the
> > current JGit license (3-clause BSD, as far as I can tell). Or a new
> > implementation can be rewritten from scratch, of course.
>
> Do not forget creating efficient packs. They also need an efficient diff
> engine.
>
I wasn't even thinking about this, honestly :p
Let's say that as far as IDE users are concerned, they do have disk space, and
having the ability to cherry-pick is more of a priority than packs ;) Even a
less efficient but "to the point" engine will be good enough for the time
being, or at least, this is what I think.
I understand way too little about the algorithm myself to tell whether it's
also efficient for such a purpose. Maybe it is...
--
fge
^ permalink raw reply
* Re: Something like $Id$, $Revision$ or $Date$?
From: Jakub Narebski @ 2008-11-10 20:17 UTC (permalink / raw)
To: Michal Nazarewicz; +Cc: git
In-Reply-To: <871vxjl5af.fsf@erwin.mina86.com>
Michal Nazarewicz wrote:
> Jakub Narebski <jnareb@gmail.com> writes:
>> Dnia poniedziałek 10. listopada 2008 18:38, Michal Nazarewicz napisał:
>>> Jakub Narebski <jnareb@gmail.com> writes:
>>>
>>>> The reason why git doesn't support keywords like $Revision$ or $Date$
>>>> is performance: the $Revision$ and $Date$ are keywords related to
>>>> _commit_ data, not blob data.
>>>
>>> In my case identifying content not commit would be even better.
>>
>> Well, in that case using `ident` attribute would be enough
>> (but cryptic).
>
> Yes, but it forces me to do some voodoo magic (ie. checkout) to get the
> Id in the file, ;) like so:
>
> #v+
> $ echo '$Id$'>bar && git add bar && git commit -m 'Added bar' && cat bar
> Created commit d49d436: Added bar
> 1 files changed, 1 insertions(+), 0 deletions(-)
> create mode 100644 bar
> $Id$
> $ rm bar && git checkout bar && cat bar
> $Id: 055c8729cdcc372500a08db659c045e16c4409fb $
> #v-
Well, _some_ command has to be invoked to expand keywords. "git add"
doesn't do that (perhaps it should?), so you need to use checkout.
And checkout doesn't touch file if it is identical, so you need
to remove it first; nevertheless you don't need to use commit in
betwen, as "git checkout bar" would checkout file out of index (you
added contents of file to index with "git add bar").
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: Git Notes - Track rebase/etc + reverse-lookup for bugs ideas
From: Johan Herland @ 2008-11-10 20:01 UTC (permalink / raw)
To: git; +Cc: Jeff King, Johannes Schindelin, Thomas Harning
In-Reply-To: <20081110195120.GA3688@sigill.intra.peff.net>
On Monday 10 November 2008, Jeff King wrote:
> On Mon, Nov 10, 2008 at 08:51:50PM +0100, Johannes Schindelin wrote:
> > > Not that I know of, but then again, I'm not sure exactly what you
> > > mean by "track rebases".
> >
> > I guess he means that you could have something like this
> >
> > rebased from <SHA-1>
> >
> > in the notes for any given commit, so that _if_ you have the commit,
> > e.g. gitk could show that connection (maybe dashed in the graphical
> > history display, and as a "Rebased from:" link).
>
> You don't really need "notes" for that, though, since you can put that
> information into the commit message (or headers) if you choose. I guess
> it has the advantage of not polluting the commit for others.
Does it make sense to teach "git rebase" the -x option from "git
cherry-pick"? As with "git cherry-pick -x" it only makes sense to use it if
your rebasing from a public branch.
Have fun!
...Johan
--
Johan Herland, <johan@herland.net>
www.herland.net
^ permalink raw reply
* Re: Something like $Id$, $Revision$ or $Date$?
From: Michal Nazarewicz @ 2008-11-10 20:00 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <200811101903.27685.jnareb@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1278 bytes --]
Jakub Narebski <jnareb@gmail.com> writes:
> Dnia poniedziałek 10. listopada 2008 18:38, Michal Nazarewicz napisał:
>> Jakub Narebski <jnareb@gmail.com> writes:
>>
>> > The reason why git doesn't support keywords like $Revision$ or $Date$
>> > is performance: the $Revision$ and $Date$ are keywords related to
>> > _commit_ data, not blob data.
>>
>> In my case identifying content not commit would be even better.
>
> Well, in that case using `ident` attribute would be enough
> (but cryptic).
Yes, but it forces me to do some voodoo magic (ie. checkout) to get the
Id in the file, ;) like so:
#v+
$ echo '$Id$' >bar && git add bar && git commit -m 'Added bar' && cat bar
Created commit d49d436: Added bar
1 files changed, 1 insertions(+), 0 deletions(-)
create mode 100644 bar
$Id$
$ rm bar && git checkout bar && cat bar
$Id: 055c8729cdcc372500a08db659c045e16c4409fb $
#v-
But never mind, since it seems hard to accomplish in git, I'll have to
learn to live without it. ;)
--
Best regards, _ _
.o. | Liege of Serenly Enlightened Majesty of o' \,=./ `o
..o | Computer Science, Michal "mina86" Nazarewicz (o o)
ooo +--<mina86*tlen.pl>--<jid:mina86*jabber.org>--ooO--(_)--Ooo--
[-- Attachment #2: Type: application/pgp-signature, Size: 196 bytes --]
^ permalink raw reply
* Re: Git Notes - Track rebase/etc + reverse-lookup for bugs ideas
From: Jeff King @ 2008-11-10 19:51 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Thomas Harning, git
In-Reply-To: <alpine.DEB.1.00.0811102049460.30769@pacific.mpi-cbg.de>
On Mon, Nov 10, 2008 at 08:51:50PM +0100, Johannes Schindelin wrote:
> > Not that I know of, but then again, I'm not sure exactly what you mean
> > by "track rebases".
>
> I guess he means that you could have something like this
>
> rebased from <SHA-1>
>
> in the notes for any given commit, so that _if_ you have the commit, e.g.
> gitk could show that connection (maybe dashed in the graphical history
> display, and as a "Rebased from:" link).
You don't really need "notes" for that, though, since you can put that
information into the commit message (or headers) if you choose. I guess
it has the advantage of not polluting the commit for others.
-Peff
^ permalink raw reply
* Re: multiple-commit cherry-pick?
From: Johannes Schindelin @ 2008-11-10 19:58 UTC (permalink / raw)
To: Alex Riesen; +Cc: Linus Torvalds, Junio C Hamano, Miles Bader, git
In-Reply-To: <20081109102528.GA5463@blimp.localdomain>
Hi,
On Sun, 9 Nov 2008, Alex Riesen wrote:
> Linus Torvalds, Fri, Nov 07, 2008 19:08:36 +0100:
> > On Fri, 7 Nov 2008, Alex Riesen wrote:
> > >
> > > Does not work if there are ranges given :-/
> > > It'd be very nice to have: git show #c1..$c2 $c3 $c4 $c5..$c6
> >
> > Yeah, we've very fundamentally never supported that. Not for show, but
> > also not for anything else (ie "gitk a..b c..d" does _not_ give you
> > two ranges).
> >
> > It's easy to see why once you understand what 'a..b' really means (ie
> > it just expands to '^a' and 'b'), and how it's not really a "range"
> > operation as much as a set operation that interacts with all the other
> > arguments too. But unless you're very aware of that, it can be
> > surprising.
> >
>
> Oh, I am. But it is just so convenient to have range support for
> commands which just show commits. Besides, git-show just errors out,
> instead of producing the commits like git-log does.
Have fun implementing the support, and then explaining to users why this
shows only one commit:
git show HEAD^..HEAD HEAD~10
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] Fixed non-literal format in printf-style calls
From: Brandon Casey @ 2008-11-10 19:47 UTC (permalink / raw)
To: Daniel Lowe; +Cc: git
In-Reply-To: <1226344517-16120-1-git-send-email-dlowe@bitmuse.com>
Daniel Lowe wrote:
<snip>
> }
> diff --git a/grep.c b/grep.c
> index e2c190a..1db60d9 100644
> --- a/grep.c
> +++ b/grep.c
> @@ -514,7 +514,7 @@ static int grep_buffer_1(struct grep_opt *opt, const char *name,
> if (from <= last_shown)
> from = last_shown + 1;
> if (last_shown && from != last_shown + 1)
> - printf(hunk_mark);
> + printf("%s", hunk_mark);
Perhaps these should by changed to use fputs() instead.
<snip>
> diff --git a/path.c b/path.c
> index eb24017..ae2c724 100644
> --- a/path.c
> +++ b/path.c
> @@ -41,7 +41,7 @@ char *mksnpath(char *buf, size_t n, const char *fmt, ...)
> len = vsnprintf(buf, n, fmt, args);
> va_end(args);
> if (len >= n) {
> - snprintf(buf, n, bad_path);
> + snprintf(buf, n, "%s", bad_path);
and these should use strlcpy.
-brandon
^ permalink raw reply
* Re: Git Notes - Track rebase/etc + reverse-lookup for bugs ideas
From: Johannes Schindelin @ 2008-11-10 19:51 UTC (permalink / raw)
To: Jeff King; +Cc: Thomas Harning, git
In-Reply-To: <20081110191134.GA3329@sigill.intra.peff.net>
Hi,
On Mon, 10 Nov 2008, Jeff King wrote:
> On Mon, Nov 10, 2008 at 12:37:20PM -0500, Thomas Harning wrote:
>
> > Just wondering, has there been any looking into whether the git-notes
> > concept can track rebases?
>
> Not that I know of, but then again, I'm not sure exactly what you mean
> by "track rebases".
I guess he means that you could have something like this
rebased from <SHA-1>
in the notes for any given commit, so that _if_ you have the commit, e.g.
gitk could show that connection (maybe dashed in the graphical history
display, and as a "Rebased from:" link).
Ciao,
Dscho
^ permalink raw reply
* Re: pull --preserve-merges
From: Johannes Schindelin @ 2008-11-10 19:48 UTC (permalink / raw)
To: Stephen Haberman; +Cc: git, fg
In-Reply-To: <20081110130518.3eb64ceb.stephen@exigencecorp.com>
Hi,
On Mon, 10 Nov 2008, Stephen Haberman wrote:
> [citing someone, presumably himself]
>
> > Awhile ago I brought up wanting to have a "rebase with preserve
> > merges" option for `git pull`:
> >
> > http://thread.gmane.org/gmane.comp.version-control.git/96513
> >
> > Andreas had a patch to help by supporting manually typing out `git
> > pull --rebase --preserve-merges`:
> >
> > http://thread.gmane.org/gmane.comp.version-control.git/96593
> >
> > And then I did another small copy/paste patch on top to add a config
> > setting of `branch.<name>.preservemerges` much like the existing
> > `branch.<name>.rebase`.
>
> I just noticed the `branch.<name>.mergeoptions` flag in the merge docs.
> Instead of having both `branch.<name>.rebase` and `.preservemerges`, and
> possibly even more config parameters for whatever other people what to
> configure as well, would something like `branch.<name>.pulloptions` be a
> better idea?
Or we can stay backwards-compatible and support
[branch "<name">]
rebase = preserve-merges
Ciao,
Dscho
^ permalink raw reply
* Re: JGIT: discuss: diff/patch implementation
From: Johannes Schindelin @ 2008-11-10 19:46 UTC (permalink / raw)
To: Francis Galiegue; +Cc: Git Mailing List, Shawn O. Pearce, Robin Rosenberg
In-Reply-To: <200811101522.13558.fg@one2team.net>
Hi,
On Mon, 10 Nov 2008, Francis Galiegue wrote:
> A very nice git feature, without even going as far as merges, is the
> cherry pick feature.
>
> For this to be doable from within the Eclipse Git plugin, a diff/patch
> implementation needs to be found, in a license compatible with the
> current JGit license (3-clause BSD, as far as I can tell). Or a new
> implementation can be rewritten from scratch, of course.
Do not forget creating efficient packs. They also need an efficient diff
engine.
> I found this:
>
> http://code.google.com/p/google-diff-match-patch
Nice.
As was pointed out already, it is more meant to work on text than I'd like
to, and it also seems to have cute DWIMery for HTML.
I did not find any implementation, so I started implementing my own
version of Gene Myers' algorithm, with the plan to extend it with a
patience diff option.
My code so far can generate a diff between two files, but does not use
O(D) space (where D is the number of differences), but O(D^2), as I did
not have enough time (a conference, and traveling around the world can do
that to you).
Having looked at the source code of diff-patch-match, I admit that I do
not understand enough of the algorithm with so little documentation, so I
will continue my fun project.
Ciao,
Dscho
^ permalink raw reply
* [PATCH] Fixed non-literal format in printf-style calls
From: Daniel Lowe @ 2008-11-10 19:15 UTC (permalink / raw)
To: git; +Cc: Daniel Lowe
These were found using gcc 4.3.2-1ubuntu11 with the warning:
warning: format not a string literal and no format arguments
---
builtin-check-attr.c | 2 +-
builtin-remote.c | 2 +-
bundle.c | 4 ++--
environment.c | 2 +-
fsck.c | 2 +-
grep.c | 6 +++---
hash-object.c | 2 +-
path.c | 4 ++--
refs.c | 2 +-
unpack-trees.c | 2 +-
10 files changed, 14 insertions(+), 14 deletions(-)
diff --git a/builtin-check-attr.c b/builtin-check-attr.c
index 4921341..15a04b7 100644
--- a/builtin-check-attr.c
+++ b/builtin-check-attr.c
@@ -97,7 +97,7 @@ int cmd_check_attr(int argc, const char **argv, const char *prefix)
else if (stdin_paths && doubledash < argc)
errstr = "Can't specify files with --stdin";
if (errstr) {
- error (errstr);
+ error("%s", errstr);
usage_with_options(check_attr_usage, check_attr_options);
}
diff --git a/builtin-remote.c b/builtin-remote.c
index e396a3a..47deb0a 100644
--- a/builtin-remote.c
+++ b/builtin-remote.c
@@ -320,7 +320,7 @@ static int add_branch_for_removal(const char *refname,
/* make sure that symrefs are deleted */
if (flags & REF_ISSYMREF)
- return unlink(git_path(refname));
+ return unlink(git_path("%s", refname));
item = string_list_append(refname, branches->branches);
item->util = xmalloc(20);
diff --git a/bundle.c b/bundle.c
index 7d17a1f..daecd8e 100644
--- a/bundle.c
+++ b/bundle.c
@@ -114,7 +114,7 @@ int verify_bundle(struct bundle_header *header, int verbose)
continue;
}
if (++ret == 1)
- error(message);
+ error("%s", message);
error("%s %s", sha1_to_hex(e->sha1), e->name);
}
if (revs.pending.nr != p->nr)
@@ -139,7 +139,7 @@ int verify_bundle(struct bundle_header *header, int verbose)
for (i = 0; i < req_nr; i++)
if (!(refs.objects[i].item->flags & SHOWN)) {
if (++ret == 1)
- error(message);
+ error("%s", message);
error("%s %s", sha1_to_hex(refs.objects[i].item->sha1),
refs.objects[i].name);
}
diff --git a/environment.c b/environment.c
index bf93a59..bb96ac0 100644
--- a/environment.c
+++ b/environment.c
@@ -118,7 +118,7 @@ const char *get_git_work_tree(void)
work_tree = git_work_tree_cfg;
/* make_absolute_path also normalizes the path */
if (work_tree && !is_absolute_path(work_tree))
- work_tree = xstrdup(make_absolute_path(git_path(work_tree)));
+ work_tree = xstrdup(make_absolute_path(git_path("%s", work_tree)));
} else if (work_tree)
work_tree = xstrdup(make_absolute_path(work_tree));
git_work_tree_initialized = 1;
diff --git a/fsck.c b/fsck.c
index 0cf5f01..97f76c5 100644
--- a/fsck.c
+++ b/fsck.c
@@ -326,7 +326,7 @@ int fsck_error_function(struct object *obj, int type, const char *fmt, ...)
die("this should not happen, your snprintf is broken");
}
- error(sb.buf);
+ error("%s", sb.buf);
strbuf_release(&sb);
return 1;
}
diff --git a/grep.c b/grep.c
index e2c190a..1db60d9 100644
--- a/grep.c
+++ b/grep.c
@@ -514,7 +514,7 @@ static int grep_buffer_1(struct grep_opt *opt, const char *name,
if (from <= last_shown)
from = last_shown + 1;
if (last_shown && from != last_shown + 1)
- printf(hunk_mark);
+ printf("%s", hunk_mark);
while (from < lno) {
pcl = &prev[lno-from-1];
show_line(opt, pcl->bol, pcl->eol,
@@ -524,7 +524,7 @@ static int grep_buffer_1(struct grep_opt *opt, const char *name,
last_shown = lno-1;
}
if (last_shown && lno != last_shown + 1)
- printf(hunk_mark);
+ printf("%s", hunk_mark);
if (!opt->count)
show_line(opt, bol, eol, name, lno, ':');
last_shown = last_hit = lno;
@@ -535,7 +535,7 @@ static int grep_buffer_1(struct grep_opt *opt, const char *name,
* we need to show this line.
*/
if (last_shown && lno != last_shown + 1)
- printf(hunk_mark);
+ printf("%s", hunk_mark);
show_line(opt, bol, eol, name, lno, '-');
last_shown = lno;
}
diff --git a/hash-object.c b/hash-object.c
index 20937ff..846e91a 100644
--- a/hash-object.c
+++ b/hash-object.c
@@ -110,7 +110,7 @@ int main(int argc, const char **argv)
}
if (errstr) {
- error (errstr);
+ error("%s", errstr);
usage_with_options(hash_object_usage, hash_object_options);
}
diff --git a/path.c b/path.c
index eb24017..ae2c724 100644
--- a/path.c
+++ b/path.c
@@ -41,7 +41,7 @@ char *mksnpath(char *buf, size_t n, const char *fmt, ...)
len = vsnprintf(buf, n, fmt, args);
va_end(args);
if (len >= n) {
- snprintf(buf, n, bad_path);
+ snprintf(buf, n, "%s", bad_path);
return buf;
}
return cleanup_path(buf);
@@ -63,7 +63,7 @@ static char *git_vsnpath(char *buf, size_t n, const char *fmt, va_list args)
goto bad;
return cleanup_path(buf);
bad:
- snprintf(buf, n, bad_path);
+ snprintf(buf, n, "%s", bad_path);
return buf;
}
diff --git a/refs.c b/refs.c
index 42bde72..33ced65 100644
--- a/refs.c
+++ b/refs.c
@@ -940,7 +940,7 @@ int delete_ref(const char *refname, const unsigned char *sha1, int delopt)
lock->lk->filename[i] = 0;
path = lock->lk->filename;
} else {
- path = git_path(refname);
+ path = git_path("%s", refname);
}
err = unlink(path);
if (err && errno != ENOENT) {
diff --git a/unpack-trees.c b/unpack-trees.c
index e5749ef..54f301d 100644
--- a/unpack-trees.c
+++ b/unpack-trees.c
@@ -352,7 +352,7 @@ static int unpack_failed(struct unpack_trees_options *o, const char *message)
discard_index(&o->result);
if (!o->gently) {
if (message)
- return error(message);
+ return error("%s", message);
return -1;
}
return -1;
--
1.6.0.4
^ permalink raw reply related
* Re: Git Notes - Track rebase/etc + reverse-lookup for bugs ideas
From: Jeff King @ 2008-11-10 19:11 UTC (permalink / raw)
To: Thomas Harning; +Cc: git
In-Reply-To: <6A0F154C-B9FE-4770-BF70-82A5BEBF907C@gmail.com>
On Mon, Nov 10, 2008 at 12:37:20PM -0500, Thomas Harning wrote:
> Just wondering, has there been any looking into whether the git-notes
> concept can track rebases?
Not that I know of, but then again, I'm not sure exactly what you mean
by "track rebases".
> Reading over what git-notes is leads me to think it could be a good
> mechanism for the distributed bug-tracking idea I had some time ago.
> The only gotcha I see is that there would have to be some reverse mapping
> / fast lookup to track the commit objects that given notes are attached
> to.... and to facilitate individual assignment... notes applied to notes.
You can really think of the notes facility as a way of mapping
SHA1 -> SHA1. So the oft-discussed concept of "attach some text
to this commit" would be a commit sha1 mapping to a blob that
contains the text. You have the commit, and you want to look up
the attached text.
How fast you can do a reverse lookup depends on what you are given. If
you are saying "I want to look through the list of all notes, and see
which commits they are attached to" that is quick. You are iterating
through the mapping, so you just look at the left hand side.
But if you are given a SHA-1 (say, of a blob with some text) and
ask "which commits map to this blob", then you will have to
linearly search through the mapping. Which really _isn't_ that
painful, if you are doing one such search per user request, but
can be slow if you want to do it for 10,000 notes.
And in the latter case, I would suggest simply building a reverse
mapping. Which you _could_ make as a parallel notes namespace,
but then you have to keep the two in sync. I would suggest
instead simply building a hash table on the fly for the reverse
mapping (which is basically what the forward-lookup does, anyway,
since our tree lookup is necessarily linear).
As far as attaching notes to notes, again it depends what you
mean. If you mean "map a blob SHA-1 to another blob SHA-1", then
that is simple. E.g., if you have some commit mapping to the text
note "foo", then you can map another note "bar" onto "foo".
But if you want to put a note onto the actual mapping, that is a
bit different. Since notes are a commit history of trees, I would
think you would simply make a new commit, and put your note into
the commit message. And if you need to do so after the fact, then
of course it is just putting a note onto the commit in the notes
history.
But bear in mind that the whole point of notes is annotating
commits after the fact, since commits must remain immutable. So
might it not be simpler to just update the note itself, with the
new information, rather than creating a note of a note?
> Operations for bug-tracking:
>
> 1) List all 'BUG'-type items that would refer to individual notes
> 2) List 'BUG' items reachable from a point
> Perhaps with criterion that a certain 'bug note' attribute is not
> set...
> or that a 'BUG_CLOSED' note is not attached to the given 'bug note'
I'm not sure that doing bug tracking in this way makes sense with
notes. If notes are a mapping of a commit sha-1 to a blob, then
how do I have a commit with _two_ bugs? I think a bug database
should be indexed by bug id, not by commit id which has the bug.
-Peff
^ permalink raw reply
* Re: force a merge conflict
From: Brett Simmers @ 2008-11-10 19:11 UTC (permalink / raw)
To: Caleb Cushing; +Cc: Deskin Miller, git
In-Reply-To: <81bfc67a0811091219t393ab1faj8d1c4df6de3c260c@mail.gmail.com>
> I tried that but I don't see that it's any different than a fast
> forward in this scenario. Actually I don't see any difference between
> it and a fast-forward.
If you want to be given a chance to edit the result before the merge
commit, you probably want 'git merge --no-commit'.
-Brett
^ permalink raw reply
* Re: [PATCH] very small cleanup: #undef a macro that isn't used anywhere else
From: Francis Galiegue @ 2008-11-10 19:09 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Git Mailing List
In-Reply-To: <alpine.DEB.1.00.0811102008330.30769@pacific.mpi-cbg.de>
Le Monday 10 November 2008 20:09:21 Johannes Schindelin, vous avez écrit :
> Hi,
>
> On Mon, 10 Nov 2008, Francis Galiegue wrote:
> > In xdiff-interface.c, the FIRST_FEW_BYTES macro is defined, is never
> > used anwhere else, so we might as well undefine it after we're done with
> > it.
>
> Would not the consequence be that we end up with a ton of #undefines all
> over the place, reducing readability incredibly?
>
Hmwell, this is a twofold argument, I guess...
* for: the macro is defined, not undefined: it means that potentially, it can
be used somewhere else in the file; but it isn't (in this case);
* against: macros defined in a C file only ever have scope in said file
(unless so mischievous Makefile cats two C files together before compile and
file order is important -- but git doesn't do that), so why #undefine
anything?
Personally, I'm with the first argument. YMMV, of course.
--
fge
^ permalink raw reply
* Re: pull --preserve-merges
From: Stephen Haberman @ 2008-11-10 19:05 UTC (permalink / raw)
To: git; +Cc: Johannes.Schindelin, fg
In-Reply-To: <20081107160138.aa96405c.stephen@exigencecorp.com>
> Awhile ago I brought up wanting to have a "rebase with preserve merges"
> option for `git pull`:
>
> http://thread.gmane.org/gmane.comp.version-control.git/96513
>
> Andreas had a patch to help by supporting manually typing out `git pull
> --rebase --preserve-merges`:
>
> http://thread.gmane.org/gmane.comp.version-control.git/96593
>
> And then I did another small copy/paste patch on top to add a config
> setting of `branch.<name>.preservemerges` much like the existing
> `branch.<name>.rebase`.
I just noticed the `branch.<name>.mergeoptions` flag in the merge docs.
Instead of having both `branch.<name>.rebase` and `.preservemerges`, and
possibly even more config parameters for whatever other people what to
configure as well, would something like `branch.<name>.pulloptions` be a
better idea?
In our case, we could then set all the `branch.<name>.pulloptions` to
"--rebase --preserve-merges" (likely via a post-checkout hook) and be
happy with `git pull` "just working".
Adding pulloptions would make the patch a little bit trickier, for me
to implement anyway, and I assume the rebase flag would have to stay
for backwards compatibility, but if a pulloptions config parameter
approach would be more acceptable than an explicit preservemerges
config (and hence more likely to get the patches accepted), I'd be
willing to work on that.
Thanks,
Stephen
^ permalink raw reply
* Re: [PATCH] very small cleanup: #undef a macro that isn't used anywhere else
From: Johannes Schindelin @ 2008-11-10 19:09 UTC (permalink / raw)
To: Francis Galiegue; +Cc: Git Mailing List
In-Reply-To: <200811101928.27207.fg@one2team.net>
Hi,
On Mon, 10 Nov 2008, Francis Galiegue wrote:
> In xdiff-interface.c, the FIRST_FEW_BYTES macro is defined, is never
> used anwhere else, so we might as well undefine it after we're done with
> it.
Would not the consequence be that we end up with a ton of #undefines all
over the place, reducing readability incredibly?
Ciao,
Dscho
^ permalink raw reply
* [PATCH] very small cleanup: #undef a macro that isn't used anywhere else
From: Francis Galiegue @ 2008-11-10 18:28 UTC (permalink / raw)
To: Git Mailing List
In xdiff-interface.c, the FIRST_FEW_BYTES macro is defined, is never used
anwhere else, so we might as well undefine it after we're done with it.
---
xdiff-interface.c | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/xdiff-interface.c b/xdiff-interface.c
index e8ef46d..2cf30cd 100644
--- a/xdiff-interface.c
+++ b/xdiff-interface.c
@@ -226,6 +226,7 @@ int buffer_is_binary(const char *ptr, unsigned long size)
size = FIRST_FEW_BYTES;
return !!memchr(ptr, 0, size);
}
+#undef FIRST_FEW_BYTES
struct ff_regs {
int nr;
--
1.6.0.3
--
fge
^ permalink raw reply related
* Re: [PATCH] git send-email: edit recipient addresses with the --compose flag
From: Ian Hilt @ 2008-11-10 18:12 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Francis Galiegue, Git Mailing List, Pierre Habouzit
In-Reply-To: <7vbpwo88gh.fsf@gitster.siamese.dyndns.org>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 1517 bytes --]
On Mon, 10 Nov 2008, Junio C Hamano wrote:
> Ian Hilt <ian.hilt@gmx.com> writes:
>
> > On Sun, 9 Nov 2008, Junio C Hamano wrote:
> >> Ian Hilt <ian.hilt@gmx.com> writes:
> >>
> >> > On Sun, 9 Nov 2008, Francis Galiegue wrote:
> >> >> Le Sunday 09 November 2008 13:59:48 Ian Hilt, vous avez écrit :
> >> >> > + if ($c_file =~ /^To:\s*+(.+)\s*\nCc:/ism) {
> >> >>
> >> >> Greedy operators are only supported with perl 5.10 or more... I think it's a
> >> >> bad idea to use them...
> >> ...
> >> You expect something non-blank there anyway, so why not do:
> >>
> >> To:\s*(\S.*?)\s*\n....
> >
> > That works. Although, I seem to be missing Francis' point. According
> > to perlre, a quantified subpattern is "greedy". So a "greedy operator"
> > is any one of the standard quantified subpatterns. The "+" and "?"
> > modify its matching behavior. And it seems to me that it _has_ to use a
> > q.s. to work ...
>
> The "perlre" documentation you are reading is from Perl 5.10.0; check
> "perldelta" documentation next to it.
>
> I think you are wrong in saying that "it _has_ to use". Yes, you _can_
> use possessive quantifiers to write that pattern (provided if you can
> limit your users to Perl 5.10.0 or later), but you do _not_ have to (and I
> just showed you how). By not using the new feature, you can make it work
> for people with older version of Perl.
Right. I was saying it has to use quantifiers, in general, not that it
has to use possessive quantifiers.
^ permalink raw reply
* Re: JGIT: discuss: diff/patch implementation
From: Francis Galiegue @ 2008-11-10 18:11 UTC (permalink / raw)
To: Robin Rosenberg; +Cc: Git Mailing List, Shawn O. Pearce
In-Reply-To: <200811101759.03864.robin.rosenberg@dewire.com>
Le Monday 10 November 2008 17:59:03 Robin Rosenberg, vous avez écrit :
[Sorry if this is offtopic for the git mailing list...]
> >
> > Well, this API has a problem from the get go, since it does... Char by
> > char comparison. Ouch.
> >
> > I'll try and hack it so that it does line by line, but given my Java
> > skills, uh...
>
> We might want a byte-oriented version. Converting to char first is way
> too slow.
>
Well, AFAICT, here is how the current git code detects whether a file is
binary or not:
----
#define FIRST_FEW_BYTES 8000
int buffer_is_binary(const char *ptr, unsigned long size)
{
if (FIRST_FEW_BYTES < size)
size = FIRST_FEW_BYTES;
return !!memchr(ptr, 0, size);
}
----
Easy enough to be coded in Java, hey, even I could do it :p
So, provided binary files are dealt with already, what penalty is left for
Java to deal with?
--
fge
^ permalink raw reply
* Re: git commit -v does not removes the patch
From: Jeff King @ 2008-11-10 18:10 UTC (permalink / raw)
To: Santi Béjar; +Cc: Git Mailing List
In-Reply-To: <adf1fd3d0811100720n52ac1d47id9b7f402412aa0d3@mail.gmail.com>
On Mon, Nov 10, 2008 at 04:20:51PM +0100, Santi Béjar wrote:
> Hi *,
>
> $subject since:
>
> 4f672ad (wt-status: load diff ui config, 2008-10-26)
>
> I tried to make a test case, but failed. I think because it is a bit
> tricky the fake_editor/stdin/stdout stuff, so at the end I bisected it
> by hand
Sorry, I don't quite understand what the problem is. From reading your
subject line, I expected that "git commit -v" would show the diff in
your editor, but then accidentally also include it in the final commit
message. But I can't seem to reproduce that.
Can you describe the problem in more detail?
-Peff
^ permalink raw reply
* Re: [PATCH (GITK) v3 6/6] gitk: Explicitly position popup windows.
From: Alex Riesen @ 2008-11-09 10:26 UTC (permalink / raw)
To: Johannes Sixt; +Cc: Paul Mackerras, Alexander Gavrilov, git
In-Reply-To: <49146EC0.4050006@viscovery.net>
Johannes Sixt, Fri, Nov 07, 2008 17:37:20 +0100:
> Alex Riesen schrieb:
> > 2008/11/7 Paul Mackerras <paulus@samba.org>:
> >> Is there any reason to call tk::PlaceWindow under Linux or MacOS?
> >> If not I'd rather add an if statement so we only call it on Windows.
> >>
> >
> > Yes, please. I rather like the smart placement in compiz.
>
> Just out of curiosity because I don't use compiz: Did you mean
> "Yes, please call tk::PlaceWindow on Linux"
> or
> "Yes, please add the if statement"
That one. So PlaceWindow is NOT called.
^ permalink raw reply
* Re: multiple-commit cherry-pick?
From: Alex Riesen @ 2008-11-09 10:25 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Junio C Hamano, Miles Bader, git
In-Reply-To: <alpine.LFD.2.00.0811071004170.3468@nehalem.linux-foundation.org>
Linus Torvalds, Fri, Nov 07, 2008 19:08:36 +0100:
> On Fri, 7 Nov 2008, Alex Riesen wrote:
> >
> > Does not work if there are ranges given :-/
> > It'd be very nice to have: git show #c1..$c2 $c3 $c4 $c5..$c6
>
> Yeah, we've very fundamentally never supported that. Not for show, but
> also not for anything else (ie "gitk a..b c..d" does _not_ give you two
> ranges).
>
> It's easy to see why once you understand what 'a..b' really means (ie it
> just expands to '^a' and 'b'), and how it's not really a "range" operation
> as much as a set operation that interacts with all the other arguments
> too. But unless you're very aware of that, it can be surprising.
>
Oh, I am. But it is just so convenient to have range support for
commands which just show commits. Besides, git-show just errors out,
instead of producing the commits like git-log does.
^ permalink raw reply
* Re: Something like $Id$, $Revision$ or $Date$?
From: Jakub Narebski @ 2008-11-10 18:03 UTC (permalink / raw)
To: Michal Nazarewicz; +Cc: git
In-Reply-To: <8763mvlbwb.fsf@erwin.mina86.com>
Dnia poniedziałek 10. listopada 2008 18:38, Michal Nazarewicz napisał:
> Jakub Narebski <jnareb@gmail.com> writes:
>
> > The reason why git doesn't support keywords like $Revision$ or $Date$
> > is performance: the $Revision$ and $Date$ are keywords related to
> > _commit_ data, not blob data.
>
> In my case identifying content not commit would be even better.
Well, in that case using `ident` attribute would be enough
(but cryptic).
# set `ident` attribute for all files
$ echo '* ident' > .gitattributes
# check that it is set for file 'foo'
$ git check-attr ident -- foo
foo: ident: set
# edit file to contain '$Id$' keyword
$ cat foo
...
... $Id$ ...
...
# make a commit
$ git commit -a
# $Id$ keyword is replaced on checkout
$ git add foo
$ git checkout foo
# and check that it got replaced
$ cat foo
...
... $Id: 0ca1524d4460ba6bc91bf3adc9dab13212599243 $ ...
...
But you need git to make use of this SHA-1 _blob_ (contents) identifier
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: Install issues
From: Miklos Vajna @ 2008-11-10 17:51 UTC (permalink / raw)
To: H.Merijn Brand; +Cc: git
In-Reply-To: <20081110173101.3d76613b@pc09.procura.nl>
[-- Attachment #1: Type: text/plain, Size: 693 bytes --]
On Mon, Nov 10, 2008 at 05:31:01PM +0100, "H.Merijn Brand" <h.m.brand@xs4all.nl> wrote:
> --- Makefile.org 2008-11-10 17:29:53.000000000 +0100
> +++ Makefile 2008-11-10 17:29:39.000000000 +0100
> @@ -1329,6 +1329,10 @@ check-sha1:: test-sha1$X
> ./test-sha1.sh
>
> check: common-cmds.h
> + @`sparse </dev/null 2>/dev/null` || (\
> + echo "The 'sparse' command is not available, so I cannot make the 'check' target" ;\
> + echo "Did you mean 'make test' instead?" ;\
> + exit 1 )
> for i in *.c; do sparse $(ALL_CFLAGS) $(SPARSE_FLAGS) $$i || exit; done
Please read Documentation/SubmittingPatches, your patch lacks a signoff
and a commit message.
Thanks.
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: Something like $Id$, $Revision$ or $Date$?
From: Michal Nazarewicz @ 2008-11-10 17:38 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <m3iqqvefmo.fsf@localhost.localdomain>
[-- Attachment #1: Type: text/plain, Size: 2015 bytes --]
Jakub Narebski <jnareb@gmail.com> writes:
> The reason why git doesn't support keywords like $Revision$ or $Date$
> is performance: the $Revision$ and $Date$ are keywords related to
> _commit_ data, not blob data.
In my case identifying content not commit would be even better.
> 1. You can try to use either hooks (post-commit, post-update I think)
> or smudge / clean filters (via gitattributes) to do keyword
> expansion. This hits performance, and you probably would have the
> problems CVS ad with keyword expansion.
Earlier in the thread there was following code for a pre-commit hook
mentioned:
#v+
files=$(git diff-index --name-only --diff-filter=AM HEAD)
perl -pi -e 's/\$Id.*?\$/\$Id: '$(TZ=UTC date +%s)' \$/g' $files
git add $files
#v-
Now, this meats all my needs except that (i) it adds all the files that
were modified (ie. makes `git commit` work like `git commit -a`) and
(ii) it modifies files even if the commit was aborted.
So, it seems that, what I need is: (i) a pre-commit-post-message-hook
and (ii) a way to get a list of files that are being committed.
> 2. You can use `export-subst` gitattribute and make git-archive do
> keyword expansion, which can include things like '$Format:%aD$'
> for commit date (equivalent of $Date:$?).
>
> 3. You can run some local equivalent of GIT-VERSION-GEN script git
> and Linux kernel uses, and make your build system (Makefile)
> replace '@@VERSION@@' or '++VERSION++' keywords / placeholders
> as part of compiling process.
That would work but the thing is I'd like to have visioning without the
need of creating releases or doing some other voodoo magic -- simply `scp
file remote:file` or attach to an email.
--
Best regards, _ _
.o. | Liege of Serenly Enlightened Majesty of o' \,=./ `o
..o | Computer Science, Michal "mina86" Nazarewicz (o o)
ooo +--<mina86*tlen.pl>--<jid:mina86*jabber.org>--ooO--(_)--Ooo--
[-- Attachment #2: Type: application/pgp-signature, Size: 196 bytes --]
^ 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