* Re: custom diff - text file diary entries
From: Santi Béjar @ 2010-12-30 13:47 UTC (permalink / raw)
To: Zenaan Harkness; +Cc: git
In-Reply-To: <AANLkTinAJ=Dzn6u7Xu=dqkzm+tiB2M_nGE2=EzRDnPEa@mail.gmail.com>
On Thu, Dec 30, 2010 at 1:36 PM, Zenaan Harkness <zen@freedbms.net> wrote:
> On Thu, Dec 30, 2010 at 23:22, Andreas Ericsson <ae@op5.se> wrote:
>> On 12/30/2010 12:33 PM, Zenaan Harkness wrote:
>>> Problem:
>>> Separate text file diary entries, committed in separate repos,
>>> cause merge clash when pushed to central repo,
>>> since git thinks the two entries are a single conflicting entry
>>> (since they begin at the same location in the same file).
>>>
>>> What we need is two diary entries automatically detected and inserted
>>> into the one file, one above the other (ordering is not so important).
> ...
>> If you really, really want to use git for this, you could create your
>> own custom merge driver. How to do so is reasonably well documented in
>> examples and man-pages. You'll want to sneak a peak at the attributes
>> page.
>
> "custom merge driver .. attributes page"
Maybe you are interested also in these ChangeLog merge driver for git:
https://git.wiki.kernel.org/index.php/Interfaces,_frontends,_and_tools#git-merge-changelog
HTH,
Santi
^ permalink raw reply
* Re: [PATCH] unpack_trees(): skip trees that are the same in all input
From: Nguyen Thai Ngoc Duy @ 2010-12-30 12:44 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Linus Torvalds
In-Reply-To: <7vd3oktmoo.fsf@alter.siamese.dyndns.org>
On Thu, Dec 30, 2010 at 2:15 AM, Junio C Hamano <gitster@pobox.com> wrote:
> By the way, I think info->data->skip_sparse_checkout should be fixed by
> renaming it to info->data->sparse_checkout. The flag controls a special
> case logic that should not be in effect unless explicitly asked, and
> forcing normal codepath to say "If skip_sparse_checkout is not false, do
> this" in double-negative is unnice than "If sparse_checkout is in effect,
> please run this special case" when reading the code.
It's something to do with zero value being "feature set by default".
Unless explicitly said otherwise, sparse checkout code should be in
effect so that skip-checkout bit is preserved in index. No, double
negation is not nice. But I don't know how I can set
unpack_trees_options.sparse_checkout = 1 by default.
--
Duy
^ permalink raw reply
* Re: [PATCH] Use a temporary index for interactive git-commit
From: Conrad Irwin @ 2010-12-30 12:41 UTC (permalink / raw)
To: Jeff King; +Cc: git
In-Reply-To: <20101230043355.GA24555@sigill.intra.peff.net>
On 30 December 2010 04:33, Jeff King <peff@peff.net> wrote:
>
> this behavior will not apply to "git add -p". So doesn't that introduce
> a new confusing inconsistency, that ^C from "git commit -p" abandons
> changes entirely, but from "git add -p" will silently stage changes?
>
That is an interesting observation. The intention of the commit was
not to make the
interactive add atomic, just isolated from the real index (much like
git commit /path/to/file.c
or git commit -a). This means that if you leave the commit message
empty (even after a
successful git-add--interactive) you have not staged any new files.
I'd agree that it would also make sense for git-add--interactive to be
atomic, so that when you
abort it forgets everything you've told it to do (and that this patch
highlights that very nicely).
At the moment git-add--interactive is atomic at a file level, i.e. it
remembers each decision for
git add --interactive, and for git add --patch, it saves your
decisions only once you've got to
the end of a file (not that you'd notice).
While I could fix git add -p in the same manner as git commit -p, by
using a temporary isolated
index, it would be better to change git-add--interactive directly, and
thus git checkout -p and
git reset -p too.
Conrad
^ permalink raw reply
* Re: custom diff - text file diary entries
From: Zenaan Harkness @ 2010-12-30 12:36 UTC (permalink / raw)
To: git
In-Reply-To: <4D1C7979.9050400@op5.se>
On Thu, Dec 30, 2010 at 23:22, Andreas Ericsson <ae@op5.se> wrote:
> On 12/30/2010 12:33 PM, Zenaan Harkness wrote:
>> Problem:
>> Separate text file diary entries, committed in separate repos,
>> cause merge clash when pushed to central repo,
>> since git thinks the two entries are a single conflicting entry
>> (since they begin at the same location in the same file).
>>
>> What we need is two diary entries automatically detected and inserted
>> into the one file, one above the other (ordering is not so important).
...
> If you really, really want to use git for this, you could create your
> own custom merge driver. How to do so is reasonably well documented in
> examples and man-pages. You'll want to sneak a peak at the attributes
> page.
"custom merge driver .. attributes page"
Thank you very much for these pointers,
Zen
^ permalink raw reply
* Re: custom diff - text file diary entries
From: Andreas Ericsson @ 2010-12-30 12:22 UTC (permalink / raw)
To: Zenaan Harkness; +Cc: git
In-Reply-To: <AANLkTimPTYEWr0qQwYM4jmJSLcrLRt27GC0nTVgVzHK2@mail.gmail.com>
On 12/30/2010 12:33 PM, Zenaan Harkness wrote:
> Problem:
> Separate text file diary entries, committed in separate repos,
> cause merge clash when pushed to central repo,
> since git thinks the two entries are a single conflicting entry
> (since they begin at the same location in the same file).
>
> What we need is two diary entries automatically detected and inserted
> into the one file, one above the other (ordering is not so important).
>
> Desired outcome:
> Two new diary entries - two separate insertions into the text file,
> not the conflict.
>
> Is there an easy way I can automate this diary entry merging, so my
> users don't have to manually resolve the conflict?
>
> Please note: SOMETIMES, one user will go and correct spelling and/ or
> grammar fixes in another person's diary entry, or in their own older
> diary entry - this is quite common.
>
It seems like what you really need is a database backend for this that
you simply take normal backups from every once in a while, or a script
that produces the desired output on the fly from many different files.
If you really, really want to use git for this, you could create your
own custom merge driver. How to do so is reasonably well documented in
examples and man-pages. You'll want to sneak a peak at the attributes
page.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
Considering the successes of the wars on alcohol, poverty, drugs and
terror, I think we should give some serious thought to declaring war
on peace.
^ permalink raw reply
* custom diff - text file diary entries
From: Zenaan Harkness @ 2010-12-30 11:33 UTC (permalink / raw)
To: git
Problem:
Separate text file diary entries, committed in separate repos,
cause merge clash when pushed to central repo,
since git thinks the two entries are a single conflicting entry
(since they begin at the same location in the same file).
What we need is two diary entries automatically detected and inserted
into the one file, one above the other (ordering is not so important).
Detail:
I have a repo of diary text files;
each diary entry is separated by three blank lines
and has an asterisked + dated header, and a body.
Here is an example diary file contents:
----
*20101230 by sarah, @~3:00pm
Phoned James and asked why he took so long shopping.
He said he had planned a one day trip, but got lost in Bunnings.
I told him 'yeah sure, like I believe that'. I asked him what he got.
This is the list he told me:
- pliers
- hammer
- nails
*20101229 by james
Today I went shopping.
Bought some eggs.
----
Each new diary entry gets added in the appropriate diary file
in reverse chronological order.
james, sarah and others each share a few diary files
(different diaries have different purposes).
The problem is:
james and sarah, each in their own clone of the central repo;
they each add a new diary entry to the same file, then commit, then push;
the second person to push will fail,
since each new diary entry occurs in the same location, the top of the file;
this requires a pull: result is git gives me the following (james pushed 2nd)
extract:
<<<<<<< HEAD
*20101231 by james
I took a day off today.
Didn't do much at all.
=======
*20101231 by sarah
James told me this morning he was taking a day off,
so bugger it, I decided to take a day off too.
I switched on the answering machine.
>>>>>>> a55d55a7a074bed5dbc24416f20a1d9391f2bb40
Desired outcome:
Two new diary entries - two separate insertions into the text file,
not the conflict.
Is there an easy way I can automate this diary entry merging, so my
users don't have to manually resolve the conflict?
Please note: SOMETIMES, one user will go and correct spelling and/ or
grammar fixes in another person's diary entry, or in their own older
diary entry - this is quite common.
TIA
Zen
^ permalink raw reply
* Re: [PATCH 1/6] Introduce sorted-array binary-search function.
From: Yann Dirson @ 2010-12-30 10:49 UTC (permalink / raw)
To: Erik Faye-Lund; +Cc: Junio C Hamano, git
In-Reply-To: <AANLkTimkemRW1H7XvwbECWUHHWVpGnvKukn06DiQO9Ce@mail.gmail.com>
On Thu, Dec 30, 2010 at 02:06:28AM +0100, Erik Faye-Lund wrote:
> On Thu, Dec 30, 2010 at 1:40 AM, Yann Dirson <ydirson@free.fr> wrote:
> > On Fri, Dec 10, 2010 at 02:29:09PM -0800, Junio C Hamano wrote:
> >> In addition, these macros in this patch are almost unreadable, but that
> >> probably is mostly a fault of C's macro, not yours.
> >
> > Yes. When writing those I sorely missed the readability of C++
> > templates - yuck :)
>
> Unfortunately, it's something that ends up subtracting from the value
> of the change; a couple of duplicate functions is often easier to
> maintain than nasty macros.
Well, I don't find this one much less readable than, say, vcs-svn/trp.h
At least the declare_gen_* ones are quite readable. Maybe making the
macro names shorter would help clarify the convenience wrappers ?
^ permalink raw reply
* HTTP push not respecting .netrc
From: David Borowitz @ 2010-12-30 6:56 UTC (permalink / raw)
To: git
Hi all,
I'm trying to push to a smart HTTP remote using the following command line:
http_proxy=localhost:4242 git push -v http://xxxxx:25989/git/foo
+refs/heads/*:refs/heads/*
(The weird proxy and port are not under my control.)
The webserver should return 401 for unauthorized access, and indeed it does:
error: RPC failed; result=65, HTTP code = 401
(The rest of the error text from git push is not particularly useful,
but I'm not worried about that at the moment.)
Making a request manually with curl --netrc shows that the auth header
is being sent[1]. But sniffing the HTTP traffic from git shows that
the auth header is not sent[2].
I also tried various other things like aliasing xxxxx to 127.0.0.1 and
removing the proxy and port number, and specifying user@xxxxx in the
URL, and nothing I've done makes git send the necessary auth header.
(In the last case it does prompt for a password.)
Anyone have any other ideas? I could swear this was working a few
weeks ago, so I must be missing something simple.
[1]
$ http_proxy=localhost:4242 curl -vvn
http://xxxxx:25989/git/foo/info/refs?service=git-receive-pack
* About to connect() to proxy localhost port 4242 (#0)
* Trying ::1... Connection refused
* Trying 127.0.0.1... connected
* Connected to localhost (127.0.0.1) port 4242 (#0)
* Server auth using Basic with user 'yyyyy' <----
> GET http://xxxxx:25989/git/foo/info/refs?service=git-receive-pack HTTP/1.1
> Authorization: Basic zzzzzzzz <----
> User-Agent: curl/7.19.7 (x86_64-pc-linux-gnu) libcurl/7.19.7 OpenSSL/0.9.8k zlib/1.2.3.3 libidn/1.15
> Host: xxxxx:25989
> Accept: */*
> Proxy-Connection: Keep-Alive
>
< HTTP/1.1 200 OK
...
[2]
GET http://xxxxx:25989/git/foo/info/refs?service=git-receive-pack HTTP/1.1
User-Agent: git/1.7.4.rc0
Host: xxxxx:25989
Accept: */*
Proxy-Connection: Keep-Alive
Pragma: no-cache
^ permalink raw reply
* Re: [PATCH 4/4] git-instaweb: Use "git-instaweb" as sitename (for page titles)
From: Eric Wong @ 2010-12-30 6:23 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <201012291750.09610.jnareb@gmail.com>
Jakub Narebski <jnareb@gmail.com> wrote:
> This is new feature, and doesn't need to be in 1.7.4
>
> It would be an RFC, if not for the fact that it is such trivial change.
Thanks Jakub. This series all looks reasonable to me (untested).
^ permalink raw reply
* Re: Rebasing multiple branches
From: Enrico Weigelt @ 2010-12-30 5:35 UTC (permalink / raw)
To: git
In-Reply-To: <4D121136.6050906@gmail.com>
* Leonid Podolny <leonidp.lists@gmail.com> wrote:
> Ah, nice. I didn't notice the -p option. However, the man page advises
> against using -p and -i together.
Last time I checked, -i required -p ...
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] Use a temporary index for interactive git-commit
From: Jeff King @ 2010-12-30 4:33 UTC (permalink / raw)
To: Conrad Irwin; +Cc: git, Matthieu Moy
In-Reply-To: <1293670038-8606-1-git-send-email-conrad.irwin@gmail.com>
On Thu, Dec 30, 2010 at 12:47:18AM +0000, Conrad Irwin wrote:
> Hitherto even an aborted git commit -p or git commit --interactive has
> added the selected changes to the index.
Hmm. I see how it could be confusing if you do ^C in "git commit -p" and
it actually commits what you had staged. But if I am reading the patch
right here:
> --- a/builtin/add.c
> +++ b/builtin/add.c
> @@ -378,7 +386,7 @@ int cmd_add(int argc, const char **argv, const char *prefix)
> if (patch_interactive)
> add_interactive = 1;
> if (add_interactive)
> - exit(interactive_add(argc - 1, argv + 1, prefix, patch_interactive));
> + exit(interactive_add(argc - 1, argv + 1, prefix, patch_interactive, NULL));
>
this behavior will not apply to "git add -p". So doesn't that introduce
a new confusing inconsistency, that ^C from "git commit -p" abandons
changes entirely, but from "git add -p" will silently stage changes?
-Peff
^ permalink raw reply
* Re: [PATCH 31/31] rebase -i: remove unnecessary state rebase-root
From: Martin von Zweigbergk @ 2010-12-29 22:31 UTC (permalink / raw)
To: Thomas Rast
Cc: Martin von Zweigbergk, git, Junio C Hamano, Johannes Schindelin,
Johannes Sixt, Christian Couder
In-Reply-To: <201012281740.52374.trast@student.ethz.ch>
On Tue, 28 Dec 2010, Thomas Rast wrote:
> Martin von Zweigbergk wrote:
> > @@ -168,11 +168,6 @@ pick_one () {
> > output git rev-parse --verify $sha1 || die "Invalid commit name: $sha1"
> > test -d "$REWRITTEN" &&
> > pick_one_preserving_merges "$@" && return
> > - if test -n "$rebase_root"
> > - then
> > - output git cherry-pick "$@"
> > - return
> > - fi
> > output git cherry-pick $ff "$@"
> > }
> [...]
> > While factoring out the state writing code a few patches back, I went
> > through each of the pieces of state that was written. I was a bit
> > hesitant to include this patch since I'm not quite sure why the code
> > was introduced, but I thought I would include it anyway to hear what
> > you have to say.
> >
> > There used to be bug when using --ff when rebasing a root commit. This
> > was fixed in 6355e50 (builtin/revert.c: don't dereference a NULL
> > pointer, 2010-09-27). Could this have been the reason for the check?
> > Thomas, do you remember?
>
> I think this just ended up being such a strange test because of the
> following hunk in 8e75abf (rebase -i: use new --ff cherry-pick option,
> 2010-03-06):
>
> @@ -232,16 +232,7 @@ pick_one () {
> output git cherry-pick "$@"
> return
> fi
> - parent_sha1=$(git rev-parse --verify $sha1^) ||
> - die "Could not get the parent of $sha1"
> - current_sha1=$(git rev-parse --verify HEAD)
> - if test -z "$no_ff" && test "$current_sha1" = "$parent_sha1"
> - then
> - output git reset --hard $sha1
> - output warn Fast-forward to $(git rev-parse --short $sha1)
> - else
> - output git cherry-pick "$@"
> - fi
> + output git cherry-pick $ff "$@"
> }
> --
Yes, I saw that one as well, so it would probably have made more sense
to ask Christian instead (the author of 8e75abf). So do you remember,
Christian?
Anyway, thanks for your input, Thomas. That makes me feel a little
less worried about this patch.
/Martin
^ permalink raw reply
* Re: [PATCH 18/31] rebase: extract merge code to new source file
From: Martin von Zweigbergk @ 2010-12-29 22:24 UTC (permalink / raw)
To: Johannes Sixt
Cc: Martin von Zweigbergk, git, Junio C Hamano, Johannes Schindelin,
Christian Couder
In-Reply-To: <201012292231.33333.j6t@kdbg.org>
On Wed, 29 Dec 2010, Johannes Sixt wrote:
> On Dienstag, 28. Dezember 2010, Martin von Zweigbergk wrote:
> > -run_interactive_rebase () {
> > +run_specific_rebase () {
> > if [ "$interactive_rebase" = implied ]; then
> > GIT_EDITOR=:
> > export GIT_EDITOR
> > fi
> > export onto autosquash strategy strategy_opts verbose rebase_root \
> > - force_rebase action preserve_merges upstream switch_to head_name
> > - exec git-rebase--interactive
> > + force_rebase action preserve_merges upstream switch_to head_name \
> > + state_dir orig_head onto_name GIT_QUIET revisions RESOLVEMSG \
> > + allow_rerere_autoupdate
> > + export -f move_to_original_branch
>
> Is export -f portable?
It seems like it isn't. What is a good way to check?
> > + test "$type" != am && exec git-rebase--$type
>
> I'd prefer to dispatch to the final rebase type using
>
> . git-rebase--$type
>
> This way, you can avoid to export the huge list of helper variables and the
> function. (And it might be faster by a millisecond - or a few dozens on
> Windows.)
Makes a lot of sense. Will change. Why didn't I do that from the
beginning?
Thanks,
Martin
^ permalink raw reply
* Re: [PATCH] Use a temporary index for interactive git-commit
From: Jonathan Nieder @ 2010-12-30 2:51 UTC (permalink / raw)
To: Conrad Irwin; +Cc: git, Matthieu Moy
In-Reply-To: <1293670038-8606-1-git-send-email-conrad.irwin@gmail.com>
Conrad Irwin wrote:
> I'm not sure that adding parameters to functions willy-nilly is the best
> way of doing this. Can anyone suggest a cleaner mechanism?
Would a simple
setenv(INDEX_ENVIRONMENT, index_file);
in the caller make sense?
^ permalink raw reply
* Re: [PATCH 1/6] Introduce sorted-array binary-search function.
From: Erik Faye-Lund @ 2010-12-30 1:06 UTC (permalink / raw)
To: Yann Dirson; +Cc: Junio C Hamano, git
In-Reply-To: <20101230004027.GB6639@home.lan>
On Thu, Dec 30, 2010 at 1:40 AM, Yann Dirson <ydirson@free.fr> wrote:
> On Fri, Dec 10, 2010 at 02:29:09PM -0800, Junio C Hamano wrote:
>> In addition, these macros in this patch are almost unreadable, but that
>> probably is mostly a fault of C's macro, not yours.
>
> Yes. When writing those I sorely missed the readability of C++
> templates - yuck :)
Unfortunately, it's something that ends up subtracting from the value
of the change; a couple of duplicate functions is often easier to
maintain than nasty macros.
Perhaps the pre-processor is not the right tool for the job? Some
times a generator (a perl script?) can be more readable.
Unfortunately, some times it's not :P
^ permalink raw reply
* [PATCH] Use a temporary index for interactive git-commit
From: Conrad Irwin @ 2010-12-30 0:47 UTC (permalink / raw)
To: git; +Cc: Matthieu Moy, Conrad Irwin
Hitherto even an aborted git commit -p or git commit --interactive has
added the selected changes to the index.
Signed-off-by: Conrad Irwin <conrad.irwin@gmail.com>
---
Following up to my email and patch of a few days ago to add support for
git commit -p (http://marc.info/?l=git&m=129338900419850&w=2).
I'm not sure that adding parameters to functions willy-nilly is the best
way of doing this. Can anyone suggest a cleaner mechanism?
Conrad
Documentation/git-commit.txt | 2 +-
builtin/add.c | 18 +++++++++++++-----
builtin/checkout.c | 2 +-
builtin/commit.c | 27 +++++++++++++++++++--------
builtin/reset.c | 2 +-
commit.h | 4 ++--
6 files changed, 37 insertions(+), 18 deletions(-)
diff --git a/Documentation/git-commit.txt b/Documentation/git-commit.txt
index 6e7ab5a..81156f0 100644
--- a/Documentation/git-commit.txt
+++ b/Documentation/git-commit.txt
@@ -43,7 +43,7 @@ The content to be added can be specified in several ways:
5. by using the --interactive or --patch switches with the 'commit' command
to decide one by one which files or hunks should be part of the commit,
before finalizing the operation. Currently, this is done by invoking
- 'git add --interactive' or 'git add --patch'.
+ 'git add --interactive' or 'git add --patch' on a temporary index.
The `--dry-run` option can be used to obtain a
summary of what is included by any of the above for the next
diff --git a/builtin/add.c b/builtin/add.c
index 3d074b3..6941fd6 100644
--- a/builtin/add.c
+++ b/builtin/add.c
@@ -214,10 +214,17 @@ static const char **validate_pathspec(int argc, const char **argv, const char *p
}
int run_add_interactive(const char *revision, const char *patch_mode,
- const char **pathspec)
+ const char **pathspec, const char *index_file)
{
int status, ac, pc = 0;
const char **args;
+ char index[PATH_MAX];
+ const char *env[2] = { NULL };
+
+ if (index_file && *index_file) {
+ env[0] = index;
+ snprintf(index, sizeof(index), "GIT_INDEX_FILE=%s", index_file);
+ }
if (pathspec)
while (pathspec[pc])
@@ -237,12 +244,13 @@ int run_add_interactive(const char *revision, const char *patch_mode,
}
args[ac] = NULL;
- status = run_command_v_opt(args, RUN_GIT_CMD);
+ status = run_command_v_opt_cd_env(args, RUN_GIT_CMD, NULL, env);
free(args);
return status;
}
-int interactive_add(int argc, const char **argv, const char *prefix, int patch)
+int interactive_add(int argc, const char **argv, const char *prefix, int patch,
+ const char *index_file)
{
const char **pathspec = NULL;
@@ -254,7 +262,7 @@ int interactive_add(int argc, const char **argv, const char *prefix, int patch)
return run_add_interactive(NULL,
patch ? "--patch" : NULL,
- pathspec);
+ pathspec, index_file);
}
static int edit_patch(int argc, const char **argv, const char *prefix)
@@ -378,7 +386,7 @@ int cmd_add(int argc, const char **argv, const char *prefix)
if (patch_interactive)
add_interactive = 1;
if (add_interactive)
- exit(interactive_add(argc - 1, argv + 1, prefix, patch_interactive));
+ exit(interactive_add(argc - 1, argv + 1, prefix, patch_interactive, NULL));
if (edit_interactive)
return(edit_patch(argc, argv, prefix));
diff --git a/builtin/checkout.c b/builtin/checkout.c
index 757f9a0..7212e42 100644
--- a/builtin/checkout.c
+++ b/builtin/checkout.c
@@ -636,7 +636,7 @@ static int git_checkout_config(const char *var, const char *value, void *cb)
static int interactive_checkout(const char *revision, const char **pathspec,
struct checkout_opts *opts)
{
- return run_add_interactive(revision, "--patch=checkout", pathspec);
+ return run_add_interactive(revision, "--patch=checkout", pathspec, NULL);
}
struct tracking_name_data {
diff --git a/builtin/commit.c b/builtin/commit.c
index f3cdf1d..599d9ff 100644
--- a/builtin/commit.c
+++ b/builtin/commit.c
@@ -297,14 +297,6 @@ static char *prepare_index(int argc, const char **argv, const char *prefix, int
if (is_status)
refresh_flags |= REFRESH_UNMERGED;
- if (interactive || patch_interactive) {
- if (interactive_add(argc, argv, prefix, patch_interactive) != 0)
- die("interactive add failed");
- if (read_cache_preload(NULL) < 0)
- die("index file corrupt");
- commit_style = COMMIT_AS_IS;
- return get_index_file();
- }
if (*argv)
pathspec = get_pathspec(prefix, argv);
@@ -312,6 +304,25 @@ static char *prepare_index(int argc, const char **argv, const char *prefix, int
if (read_cache_preload(pathspec) < 0)
die("index file corrupt");
+ if (interactive || patch_interactive) {
+ fd = hold_locked_index(&index_lock, 1);
+
+ refresh_cache_or_die(refresh_flags);
+
+ if (write_cache(fd, active_cache, active_nr) ||
+ close_lock_file(&index_lock))
+ die("unable to write new_index file");
+
+ if (interactive_add(argc, argv, prefix, patch_interactive, index_lock.filename) != 0)
+ die("interactive add failed");
+
+ discard_cache();
+ read_cache_from(index_lock.filename);
+
+ commit_style = COMMIT_NORMAL;
+ return index_lock.filename;
+ }
+
/*
* Non partial, non as-is commit.
*
diff --git a/builtin/reset.c b/builtin/reset.c
index 5de2bce..67d604e 100644
--- a/builtin/reset.c
+++ b/builtin/reset.c
@@ -184,7 +184,7 @@ static int interactive_reset(const char *revision, const char **argv,
if (*argv)
pathspec = get_pathspec(prefix, argv);
- return run_add_interactive(revision, "--patch=reset", pathspec);
+ return run_add_interactive(revision, "--patch=reset", pathspec, NULL);
}
static int read_from_tree(const char *prefix, const char **argv,
diff --git a/commit.h b/commit.h
index 951c22e..1a47bd4 100644
--- a/commit.h
+++ b/commit.h
@@ -160,9 +160,9 @@ extern struct commit_list *get_shallow_commits(struct object_array *heads,
int is_descendant_of(struct commit *, struct commit_list *);
int in_merge_bases(struct commit *, struct commit **, int);
-extern int interactive_add(int argc, const char **argv, const char *prefix, int patch);
+extern int interactive_add(int argc, const char **argv, const char *prefix, int patch, const char *index_file);
extern int run_add_interactive(const char *revision, const char *patch_mode,
- const char **pathspec);
+ const char **pathspec, const char *index_file);
static inline int single_parent(struct commit *commit)
{
--
1.7.3.4.629.g17fdc.dirty
^ permalink raw reply related
* Re: [PATCH 1/6] Introduce sorted-array binary-search function.
From: Yann Dirson @ 2010-12-30 0:40 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vwrnhb6tm.fsf@alter.siamese.dyndns.org>
On Fri, Dec 10, 2010 at 02:29:09PM -0800, Junio C Hamano wrote:
> Yann Dirson <ydirson@altern.org> writes:
>
> > +Suffix meanings are as follows:
> > +
> > +`check`::
> > +...
> > +* those defining the generic algorithms
>
> Yuck.
>
> All of these feel way overengineered and at the same time too rigid and
> brittle.
I confess a natural tendency towards overengineering stuff, but more
iterations usually help :). Indeed, most of the
overengineered-looking features added in the latest iterations are
things I already needed for the dir-rename series.
About rigidity, well, it is already less rigid than a couple of the
hardcoded implementations we have throughout the source, and as such
could be seen as an iterative step towards someting better - as I
mentionned, my primary intent was to just get things useful for that
dir-rename series, and at least on this point, I think the approach in
this series is not so bad.
It also looks generic enough to get the string-list lookup/insert
funcs use it, and this again does not look so bad to me, compared to
the stretching of the string-list API itself that would be required to
make it useful to the dir-rename stuff.
As for the "brittle" aspect, I'm not sure there is anything unfixable.
At the very least, more parentheses around the expnasion of macro args
would help making things more robust.
> I have a suspicion that the "convenience" macros that generate many
> functions and definitions are the main culprit.
Hm. I was reluctant at first to use so many macros for an API,
fearing it would confuse people (that resulted in the v5 API:
genericity made it too verbose to be useful). Then I saw how many
entry-points the linked-list API of the kernel has: that made me
reconsider, and I found the result much more usable, although I had to
write more doc.
> For example, why do all the functions generated by a "convenience"
> macro must share the same MAYBESTATIC?
The intention was that MAYBESTATIC only gets applied to the
explicitely-requested function, and that the transparently-generated
ones get "static". Only declare_sorted_array_search_check() does not
conform to that, that's a bug. That also ought to be documented in
the API.
> "binsearch" takes a comparison function pointer, and always
> picks the midpoint, but what is the performance implication if we wanted
> to use sorted-array.h to rewrite say sha1-lookup.c?
As I noted in the cover letter, I consider sha1-lookup.c too special.
What it is not doing is not a conventional binary search, and this
looks out of scope.
> How can an API user who wants to use
> declare_sorted_array_insert_checkbook() easily figure out what other
> macros fromt this family can be used without getting the same thing
> generated twice?
I have tried to make this explicit in the API reference, but things
can surely be made more clear by including examples.
> If somebody wanted to have a sorted array in a
> struct, it may be tempting to use declare_sorted_array() with an empty
> MAYBESTATIC inside struct's field declaration (even when the struct itself
> is static---which leaves a queasy feeling, but that is a separate issue),
> and the _current_ macro definition of declare_sorted_array() may allow
> such a usage work perfectly fine, but how can such an API user be rest
> assured it won't break in later revisions of these macros?
That would only work by side-effect. We can either decide to document
it and make it part of the API if we feel it's worth it, or
explicitely state it is not supported (or enforce it: defining _nr and
_alloc with =0 initializers would be a fairly good way of catching
such attempts).
> In addition, these macros in this patch are almost unreadable, but that
> probably is mostly a fault of C's macro, not yours.
Yes. When writing those I sorely missed the readability of C++
templates - yuck :)
--
Yann
^ permalink raw reply
* Re: [BUGFIX PATCH 1/4] git-instaweb: Fix issue with static files for 'plackup' server
From: Jakub Narebski @ 2010-12-30 0:40 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Tadeusz Sosnierz, Eric Wong
In-Reply-To: <7v1v50rvat.fsf@alter.siamese.dyndns.org>
On Thu, 30 Dec 2010, Junio C Hamano wrote:
> Jakub Narebski <jnareb@gmail.com> writes:
>
> > The default (in gitweb/Makefile) is to use relative paths for gitweb
> > static files, e.g. "static/gitweb.css" for GITWEB_CSS. But the
> > configuration for Plack::Middleware::Static in plackup_conf assumed
> > that static files must be absolute paths starting with "/gitweb/"
> > prefix which had to be stripped, e.g. "/gitweb/static/gitweb.css".
> > This in turn caused web server run by "git instaweb --httpd=plackup"
> > to not access static files (e.g. CSS) correctly.
> >
> > This is a minimal fixup, making 'plackup' web server in git-instaweb
> > work with default gitweb build configuration.
> >
> > Reported-by: Tadeusz Sośnierz <tadzikes@gmail.com>
> > Signed-off-by: Jakub Narebski <jnareb@gmail.com>
> > ---
> > The regexp is probably too strict: qr{^/static/} should be enough,
> > but I didn't want to change too much at once.
[...]
> > diff --git a/git-instaweb.sh b/git-instaweb.sh
> > index 10fcebb..bb57d81 100755
> > --- a/git-instaweb.sh
> > +++ b/git-instaweb.sh
> > @@ -549,7 +549,7 @@ my \$app = builder {
> > };
> > # serve static files, i.e. stylesheet, images, script
> > enable 'Static',
> > - path => sub { m!\.(js|css|png)\$! && s!^/gitweb/!! },
> > + path => qr{^/static/.*(?:js|css|png)\$},
>
> I wonder if you meant qr{^/static/.*\\.(?:js|css|png)\$} here, to make
> sure that these three tokens are file suffixes, not just random
> substring.
Yes, it should be qr{^/static/.*\\.(?:js|css|png)\$} though as I said:
"The regexp is probably too strict: qr{^/static/} should be enough,"
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: [PATCH v6] generalizing sorted-array handling
From: Yann Dirson @ 2010-12-30 0:01 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vd3p9b4d1.fsf@alter.siamese.dyndns.org>
On Fri, Dec 10, 2010 at 03:22:18PM -0800, Junio C Hamano wrote:
> Yann Dirson <ydirson@altern.org> writes:
>
> > ... I want to get my focus back to
> > bulk-rename/builk-rm patches, which will make heavy use of this API.
>
> Final comment. As the primary thing you want to use this is to change the
> way how the rename_dst/rename_src tables are managed, and these are both
> tables sorted by a string, I suspect a more reasonable might be to first
> updated them to use string-list API and add to that API whatever necessary
> features you might need, if any.
It sounds reasonable to build on existing stuff (furthermore, the
string-list binary search is one I had missed).
Using string-lists here however will imply some tradeofs:
* the additional char* pointer in every list element is possibly not
so high a price to pay
* using the "util" pointer for the payload will make memory management
even more hairy (eg. "util" as a pointer to a struct which contains
a pointer to a diff_filespec). Convenience wrappers will be highly
needed, and will also be required to keep calls to lookup/insert
readable, when the elements we deal with are not strings but indeed
the "util" stuff.
All in all, looks that the data-structure needed should have a higher
focus on the "util" field than string-list has.
Features that seem to miss from string-list today (for the
"dir-rename" series) include:
* custom string-comparison function (ie. prefix comparison): that
would not be so difficult to generalize by adding a cmp_func
parameter to get_entry_index(). That would imply changing
widely-used API funcs like string_list_lookup() to shallow wrappers
around variants that also take a cmp_func argument.
* lists indexed by 2 strings (bulkmove_candidates): could be replaced
by using string-lists of string-lists instead, but I'm not sure the
result would be that great
I still have mixed feelings about all of this.
--
Yann
^ permalink raw reply
* Re: [BUGFIX PATCH 1/4] git-instaweb: Fix issue with static files for 'plackup' server
From: Junio C Hamano @ 2010-12-29 23:52 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git, Tadeusz Sosnierz, Eric Wong
In-Reply-To: <201012291747.01288.jnareb@gmail.com>
Jakub Narebski <jnareb@gmail.com> writes:
> The default (in gitweb/Makefile) is to use relative paths for gitweb
> static files, e.g. "static/gitweb.css" for GITWEB_CSS. But the
> configuration for Plack::Middleware::Static in plackup_conf assumed
> that static files must be absolute paths starting with "/gitweb/"
> prefix which had to be stripped, e.g. "/gitweb/static/gitweb.css".
> This in turn caused web server run by "git instaweb --httpd=plackup"
> to not access static files (e.g. CSS) correctly.
>
> This is a minimal fixup, making 'plackup' web server in git-instaweb
> work with default gitweb build configuration.
>
> Reported-by: Tadeusz Sośnierz <tadzikes@gmail.com>
> Signed-off-by: Jakub Narebski <jnareb@gmail.com>
> ---
> The regexp is probably too strict: qr{^/static/} should be enough,
> but I didn't want to change too much at once.
>
> This bug was not noticed because we don't have any test for
> git-instaweb, not mentioning tests for all web servers supported. And
> the fact that I was checking "git instaweb -httpd=plackup" against
> gitweb.cgi built with custom configuration (including the fact that
> GITWEB_CSS="/gitweb/static/gitweb.css").
>
> tadzik, does that fix the issue you noticed?
>
> Junio, could you apply this before 1.7.4? Thanks in advance.
>
> git-instaweb.sh | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/git-instaweb.sh b/git-instaweb.sh
> index 10fcebb..bb57d81 100755
> --- a/git-instaweb.sh
> +++ b/git-instaweb.sh
> @@ -549,7 +549,7 @@ my \$app = builder {
> };
> # serve static files, i.e. stylesheet, images, script
> enable 'Static',
> - path => sub { m!\.(js|css|png)\$! && s!^/gitweb/!! },
> + path => qr{^/static/.*(?:js|css|png)\$},
I wonder if you meant qr{^/static/.*\\.(?:js|css|png)\$} here, to make
sure that these three tokens are file suffixes, not just random
substring.
> root => "$root/",
> encoding => 'utf-8'; # encoding for 'text/plain' files
> # convert CGI application to PSGI app
> --
> 1.7.3
^ permalink raw reply
* Re: [BUGFIX PATCH 1/4] git-instaweb: Fix issue with static files for 'plackup' server
From: Junio C Hamano @ 2010-12-29 23:24 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git, Tadeusz Sosnierz, Eric Wong
In-Reply-To: <201012291747.01288.jnareb@gmail.com>
Jakub Narebski <jnareb@gmail.com> writes:
> The default (in gitweb/Makefile) is to use relative paths for gitweb
> static files, e.g. "static/gitweb.css" for GITWEB_CSS. But the
> configuration for Plack::Middleware::Static in plackup_conf assumed
> that static files must be absolute paths starting with "/gitweb/"
> prefix which had to be stripped, e.g. "/gitweb/static/gitweb.css".
> This in turn caused web server run by "git instaweb --httpd=plackup"
> to not access static files (e.g. CSS) correctly.
>
> This is a minimal fixup, making 'plackup' web server in git-instaweb
> work with default gitweb build configuration.
>
> Reported-by: Tadeusz Sośnierz <tadzikes@gmail.com>
> Signed-off-by: Jakub Narebski <jnareb@gmail.com>
> ---
> The regexp is probably too strict: qr{^/static/} should be enough,
> but I didn't want to change too much at once.
>
> This bug was not noticed because we don't have any test for
> git-instaweb, not mentioning tests for all web servers supported. And
> the fact that I was checking "git instaweb -httpd=plackup" against
> gitweb.cgi built with custom configuration (including the fact that
> GITWEB_CSS="/gitweb/static/gitweb.css").
>
> tadzik, does that fix the issue you noticed?
>
> Junio, could you apply this before 1.7.4?
Hmph, I was kind of hoping that I can issue 1.7.3.5 tonight...
>
> git-instaweb.sh | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/git-instaweb.sh b/git-instaweb.sh
> index 10fcebb..bb57d81 100755
> --- a/git-instaweb.sh
> +++ b/git-instaweb.sh
> @@ -549,7 +549,7 @@ my \$app = builder {
> };
> # serve static files, i.e. stylesheet, images, script
> enable 'Static',
> - path => sub { m!\.(js|css|png)\$! && s!^/gitweb/!! },
> + path => qr{^/static/.*(?:js|css|png)\$},
> root => "$root/",
> encoding => 'utf-8'; # encoding for 'text/plain' files
> # convert CGI application to PSGI app
> --
> 1.7.3
^ permalink raw reply
* Re: [PATCH 3/3] gitweb: add css class to remote url titles
From: Jakub Narebski @ 2010-12-29 22:44 UTC (permalink / raw)
To: Sylvain Rabot; +Cc: git
In-Reply-To: <1293651215-4924-4-git-send-email-sylvain@abstraction.fr>
Sylvain Rabot <sylvain@abstraction.fr> writes:
> Signed-off-by: Sylvain Rabot <sylvain@abstraction.fr>
> ---
> gitweb/gitweb.perl | 8 ++++----
> gitweb/static/gitweb.css | 5 +++++
> 2 files changed, 9 insertions(+), 4 deletions(-)
>
> diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
> index eae75ac..cb169c7 100755
> --- a/gitweb/gitweb.perl
> +++ b/gitweb/gitweb.perl
> @@ -5146,13 +5146,13 @@ sub git_remote_block {
>
> if (defined $fetch) {
> if ($fetch eq $push) {
> - $urls_table .= format_repo_url("URL", $fetch);
> + $urls_table .= format_repo_url("<span class=\"metadata_remote_fetch_url\">URL</span>", $fetch);
> } else {
> - $urls_table .= format_repo_url("Fetch URL", $fetch);
> - $urls_table .= format_repo_url("Push URL", $push) if defined $push;
> + $urls_table .= format_repo_url("<span class=\"metadata_remote_fetch_url\">Fetch URL</span>", $fetch);
> + $urls_table .= format_repo_url("<span class=\"metadata_remote_push_url\">Push URL</span>", $push) if defined $push;
> }
> } elsif (defined $push) {
> - $urls_table .= format_repo_url("Push URL", $push);
> + $urls_table .= format_repo_url("<span class=\"metadata_remote_push_url\">Push URL</span>", $push);
> } else {
> $urls_table .= format_repo_url("", "No remote URL");
> }
I'm not sure if in this situation if it would not be better to extend
format_repo_url subroutine to take additional parameter describing
_type_ of repo URL; it then would do styling internally. Which means
moving wrapping 'URL', 'Fetch URL' etc. in span element to
format_repo_url from the caller.
> diff --git a/gitweb/static/gitweb.css b/gitweb/static/gitweb.css
> index 79d7eeb..631b20d 100644
> --- a/gitweb/static/gitweb.css
> +++ b/gitweb/static/gitweb.css
> @@ -579,6 +579,11 @@ div.remote {
> display: inline-block;
> }
>
> +.metadata_remote_fetch_url,
> +.metadata_remote_push_url {
> + font-weight: bold;
> +}
> +
Good!
--
Jakub Narebski
Poland
ShadeHawk on #git
^ permalink raw reply
* Re: [PATCH 0/3 v3] minor gitweb modifications
From: Jakub Narebski @ 2010-12-29 22:41 UTC (permalink / raw)
To: Sylvain Rabot; +Cc: git
In-Reply-To: <1293651215-4924-1-git-send-email-sylvain@abstraction.fr>
Sylvain Rabot <sylvain@abstraction.fr> writes:
> here a three patch serie with minor updates for gitweb based on master.
>
> This serie has been improved regarding the comments of :
>
> - Jakub Narebski <jnareb@gmail.com>
> - Jonathan Nieder <jrnieder@gmail.com>
>
> Regards.
A few comments, in this version about commit messages, not the code:
> Sylvain Rabot (3):
> gitweb: add extensions to highlight feature
It is about adding support for supporting additional file extensions
for syntax highlighting, not about extending the highlight feature or
adding some plugin thingy to it, as one can think on first read.
> gitweb: remove test when closing file descriptor
It is about closing open pipe (file descriptor) without checking for
error in the case where we don't care about errors in the caller; in
short about not testing status of closing filehandle in git_highlight
> gitweb: add css class to remote url titles
It is about distinguishing visually type of link using styles; adding
CSS class is just a way to do it.
This actually has few comments about code.
>
> gitweb/gitweb.perl | 18 +++++++++---------
> gitweb/static/gitweb.css | 5 +++++
> 2 files changed, 14 insertions(+), 9 deletions(-)
>
> --
> 1.7.3.4.523.g72f0d.dirty
>
--
Jakub Narebski
Poland
ShadeHawk on #git
^ permalink raw reply
* Re: Re* [RFC/PATCH] Re: git submodule -b ... of current HEAD fails
From: Jens Lehmann @ 2010-12-29 22:23 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jonathan Nieder, git, Klaus Ethgen, Sven Verdoolaege
In-Reply-To: <4D1BB26D.1010502@web.de>
Am 29.12.2010 23:13, schrieb Jens Lehmann:
> Am 29.12.2010 21:53, schrieb Junio C Hamano:
>> Jens Lehmann <Jens.Lehmann@web.de> writes:
>>> So we maybe want to fix this issue in "git checkout"? Then the patch
>>> will start working (and the test for it can be added in a later patch).
>>
>> So in conclusion, here is a patch that is not even compile tested ;-)
Just for the record: It does compile (at least for me ;-) and together
with Jonathan's patch referenced in the the subject passes all tests,
including the new 'submodule add --branch succeeds even when branch is
at HEAD' test I came up with to verify this issue.
^ permalink raw reply
* [PATCH 2/2] cvsimport: handle the parsing of uppercase config options
From: Michael J Gruber @ 2010-12-29 21:55 UTC (permalink / raw)
To: git
In-Reply-To: <cover.1293659350.git.git@drmicha.warpmail.net>
The current code leads to
fatal: bad config value for 'cvsimport.r' in .git/config
for a standard use case with cvsimport.r set:
cvsimport sets internal variables by checking the config for each
possible command line option. The problem is that config items are case
insensitive, so config.r and config.R are the same. The ugly error is
due to that fact that cvsimport expects a bool for -R (and thus
config.R) but a remote name for -r (and thus config.r).
Fix this by making cvsimport expect long names for uppercase options.
config options for cvsimport have been undocumented so far, though
present in the code and advertised in several tutorials. So one may read
"enhance" for "fix". Similarly, the names for the options are
"documented" in the code, waitiing for their lowercase equivalents to be
transformed into long config options, as well.
Helped-by: Junio C Hamano <gitster@pobox.com>
Signed-off-by: Michael J Gruber <git@drmicha.warpmail.net>
---
git-cvsimport.perl | 19 ++++++++++++++++++-
t/t9600-cvsimport.sh | 7 +++++--
2 files changed, 23 insertions(+), 3 deletions(-)
diff --git a/git-cvsimport.perl b/git-cvsimport.perl
index 7888b77..8e683e5 100755
--- a/git-cvsimport.perl
+++ b/git-cvsimport.perl
@@ -90,6 +90,14 @@ sub write_author_info($) {
}
# convert getopts specs for use by git config
+my %longmap = (
+ 'A:' => 'authors-file',
+ 'M:' => 'merge-regex',
+ 'P:' => undef,
+ 'R' => 'track-revisions',
+ 'S:' => 'ignore-paths',
+);
+
sub read_repo_config {
# Split the string between characters, unless there is a ':'
# So "abc:de" becomes ["a", "b", "c:", "d", "e"]
@@ -99,8 +107,17 @@ sub read_repo_config {
$key =~ s/://g;
my $arg = 'git config';
$arg .= ' --bool' if ($o !~ /:$/);
-
- chomp(my $tmp = `$arg --get cvsimport.$key`);
+ my $ckey = $key;
+
+ if (exists $longmap{$o}) {
+ # An uppercase option like -R cannot be
+ # expressed in the configuration, as the
+ # variable names are downcased.
+ $ckey = $longmap{$o};
+ next if (! defined $ckey);
+ $ckey =~ s/-//g;
+ }
+ chomp(my $tmp = `$arg --get cvsimport.$ckey`);
if ($tmp && !($arg =~ /--bool/ && $tmp eq 'false')) {
no strict 'refs';
my $opt_name = "opt_" . $key;
diff --git a/t/t9600-cvsimport.sh b/t/t9600-cvsimport.sh
index 432b82e..4c384ff 100755
--- a/t/t9600-cvsimport.sh
+++ b/t/t9600-cvsimport.sh
@@ -89,7 +89,8 @@ EOF
test_expect_success PERL 'update git module' '
(cd module-git &&
- git cvsimport -a -R -z 0 module &&
+ git config cvsimport.trackRevisions true &&
+ git cvsimport -a -z 0 module &&
git merge origin
) &&
test_cmp module-cvs/o_fortuna module-git/o_fortuna
@@ -117,7 +118,8 @@ test_expect_success PERL 'cvsimport.module config works' '
(cd module-git &&
git config cvsimport.module module &&
- git cvsimport -a -R -z0 &&
+ git config cvsimport.trackRevisions true &&
+ git cvsimport -a -z0 &&
git merge origin
) &&
test_cmp module-cvs/tick module-git/tick
@@ -137,6 +139,7 @@ test_expect_success PERL 'import from a CVS working tree' '
$CVS co -d import-from-wt module &&
(cd import-from-wt &&
+ git config cvsimport.trackRevisions false &&
git cvsimport -a -z0 &&
echo 1 >expect &&
git log -1 --pretty=format:%s%n >actual &&
--
1.7.3.4.865.ga2bc4
^ permalink raw reply related
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