* [PATCH 2/2] moved some variables into narrower scopes
From: Benjamin Kramer @ 2009-03-07 20:02 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
they weren't used outside and can be safely moved
builtin-fmt-merge-msg: moved variable to narrower scope
combine-diff: moved variable to narrower scope
log-tree: moved variable to narrower scope
upload-pack: moved variable to narrower scope
upload-pack: removed unused assignment
Signed-off-by: Benjamin Kramer <benny.kra@googlemail.com>
---
builtin-fmt-merge-msg.c | 5 ++---
combine-diff.c | 3 +--
log-tree.c | 6 +++---
upload-pack.c | 5 ++---
4 files changed, 8 insertions(+), 11 deletions(-)
diff --git a/builtin-fmt-merge-msg.c b/builtin-fmt-merge-msg.c
index df18f40..5c5b310 100644
--- a/builtin-fmt-merge-msg.c
+++ b/builtin-fmt-merge-msg.c
@@ -257,7 +257,7 @@ static void shortlog(const char *name, unsigned char *sha1,
int fmt_merge_msg(int merge_summary, struct strbuf *in, struct strbuf *out) {
int limit = 20, i = 0, pos = 0;
char line[1024];
- char *p = line, *sep = "";
+ char *sep = "";
unsigned char head_sha1[20];
const char *current_branch;
@@ -271,9 +271,8 @@ int fmt_merge_msg(int merge_summary, struct strbuf
*in, struct strbuf *out) {
/* get a line */
while (pos < in->len) {
int len;
- char *newline;
+ char *newline, *p = in->buf + pos;
- p = in->buf + pos;
newline = strchr(p, '\n');
len = newline ? newline - p : strlen(p);
pos += len + !!newline;
diff --git a/combine-diff.c b/combine-diff.c
index bccc018..b3b86ae 100644
--- a/combine-diff.c
+++ b/combine-diff.c
@@ -526,7 +526,6 @@ static void dump_sline(struct sline *sline,
unsigned long cnt, int num_parent,
return; /* result deleted */
while (1) {
- struct sline *sl = &sline[lno];
unsigned long hunk_end;
unsigned long rlines;
const char *hunk_comment = NULL;
@@ -592,7 +591,7 @@ static void dump_sline(struct sline *sline,
unsigned long cnt, int num_parent,
struct lline *ll;
int j;
unsigned long p_mask;
- sl = &sline[lno++];
+ struct sline *sl = &sline[lno++];
ll = (sl->flag & no_pre_delete) ? NULL : sl->lost_head;
while (ll) {
fputs(c_old, stdout);
diff --git a/log-tree.c b/log-tree.c
index 84a74e5..63cff74 100644
--- a/log-tree.c
+++ b/log-tree.c
@@ -79,18 +79,18 @@ void show_decorations(struct rev_info *opt, struct
commit *commit)
*/
static int detect_any_signoff(char *letter, int size)
{
- char ch, *cp;
+ char *cp;
int seen_colon = 0;
int seen_at = 0;
int seen_name = 0;
int seen_head = 0;
cp = letter + size;
- while (letter <= --cp && (ch = *cp) == '\n')
+ while (letter <= --cp && *cp == '\n')
continue;
while (letter <= cp) {
- ch = *cp--;
+ char ch = *cp--;
if (ch == '\n')
break;
diff --git a/upload-pack.c b/upload-pack.c
index e15ebdc..a49d872 100644
--- a/upload-pack.c
+++ b/upload-pack.c
@@ -397,12 +397,11 @@ static int get_common_commits(void)
static char line[1000];
unsigned char sha1[20];
char hex[41], last_hex[41];
- int len;
save_commit_buffer = 0;
for(;;) {
- len = packet_read_line(0, line, sizeof(line));
+ int len = packet_read_line(0, line, sizeof(line));
reset_timeout();
if (!len) {
@@ -410,7 +409,7 @@ static int get_common_commits(void)
packet_write(1, "NAK\n");
continue;
}
- len = strip(line, len);
+ strip(line, len);
if (!prefixcmp(line, "have ")) {
switch (got_sha1(line+5, sha1)) {
case -1: /* they have what we do not */
--
1.6.2.81.ge603.dirty
^ permalink raw reply related
* [PATCH 1/2] removed some unused variables
From: Benjamin Kramer @ 2009-03-07 20:02 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
these variables were unused and can be removed safely
builtin-clone: removed unused variable 'option_no_hardlinks'
builtin-clone: removed unused variable 'use_separate_remote'
builtin-fetch-pack: removed unused variable 'len'
builtin-remote: removed unused variable 'symref'
diff: removed unused variable 'total'
diffcore-break: removed unused variable 'base_size'
fast-import: removed unused variable 'date'
fast-import: removed unused variable 'sign'
fsck: removed unused variable 'o_sha1'
fsck: removed unused variable 'sha1'
xdiff-interface: removed unused variable 'read_some'
Signed-off-by: Benjamin Kramer <benny.kra@googlemail.com>
---
builtin-clone.c | 6 ------
builtin-fetch-pack.c | 3 +--
builtin-remote.c | 3 +--
diff.c | 4 +---
diffcore-break.c | 3 +--
fast-import.c | 8 +++-----
fsck.c | 6 +-----
xdiff-interface.c | 3 +--
8 files changed, 9 insertions(+), 27 deletions(-)
diff --git a/builtin-clone.c b/builtin-clone.c
index c338910..92826cd 100644
--- a/builtin-clone.c
+++ b/builtin-clone.c
@@ -365,8 +365,6 @@ static void install_branch_config(const char *local,
int cmd_clone(int argc, const char **argv, const char *prefix)
{
- int use_local_hardlinks = 1;
- int use_separate_remote = 1;
int is_bundle = 0;
struct stat buf;
const char *repo_name, *repo, *work_tree, *git_dir;
@@ -388,9 +386,6 @@ int cmd_clone(int argc, const char **argv, const
char *prefix)
if (argc == 0)
die("You must specify a repository to clone.");
- if (option_no_hardlinks)
- use_local_hardlinks = 0;
-
if (option_mirror)
option_bare = 1;
@@ -399,7 +394,6 @@ int cmd_clone(int argc, const char **argv, const
char *prefix)
die("--bare and --origin %s options are incompatible.",
option_origin);
option_no_checkout = 1;
- use_separate_remote = 0;
}
if (!option_origin)
diff --git a/builtin-fetch-pack.c b/builtin-fetch-pack.c
index 67fb80e..c2e5adc 100644
--- a/builtin-fetch-pack.c
+++ b/builtin-fetch-pack.c
@@ -216,9 +216,8 @@ static int find_common(int fd[2], unsigned char
*result_sha1,
if (args.depth > 0) {
char line[1024];
unsigned char sha1[20];
- int len;
- while ((len = packet_read_line(fd[0], line, sizeof(line)))) {
+ while (packet_read_line(fd[0], line, sizeof(line))) {
if (!prefixcmp(line, "shallow ")) {
if (get_sha1_hex(line + 8, sha1))
die("invalid shallow line: %s", line);
diff --git a/builtin-remote.c b/builtin-remote.c
index ac69d37..e171096 100644
--- a/builtin-remote.c
+++ b/builtin-remote.c
@@ -484,9 +484,8 @@ static int mv(int argc, const char **argv)
struct string_list_item *item = remote_branches.items + i;
int flag = 0;
unsigned char sha1[20];
- const char *symref;
- symref = resolve_ref(item->string, sha1, 1, &flag);
+ resolve_ref(item->string, sha1, 1, &flag);
if (!(flag & REF_ISSYMREF))
continue;
if (delete_ref(item->string, NULL, REF_NODEREF))
diff --git a/diff.c b/diff.c
index 3feca1b..e06c937 100644
--- a/diff.c
+++ b/diff.c
@@ -875,7 +875,7 @@ static void fill_print_name(struct diffstat_file *file)
static void show_stats(struct diffstat_t* data, struct diff_options *options)
{
- int i, len, add, del, total, adds = 0, dels = 0;
+ int i, len, add, del, adds = 0, dels = 0;
int max_change = 0, max_len = 0;
int total_files = data->nr;
int width, name_width;
@@ -978,14 +978,12 @@ static void show_stats(struct diffstat_t* data,
struct diff_options *options)
*/
add = added;
del = deleted;
- total = add + del;
adds += add;
dels += del;
if (width <= max_change) {
add = scale_linear(add, width, max_change);
del = scale_linear(del, width, max_change);
- total = add + del;
}
show_name(options->file, prefix, name, len, reset, set);
fprintf(options->file, "%5d%s", added + deleted,
diff --git a/diffcore-break.c b/diffcore-break.c
index 31cdcfe..d7097bb 100644
--- a/diffcore-break.c
+++ b/diffcore-break.c
@@ -45,7 +45,7 @@ static int should_break(struct diff_filespec *src,
* The value we return is 1 if we want the pair to be broken,
* or 0 if we do not.
*/
- unsigned long delta_size, base_size, max_size;
+ unsigned long delta_size, max_size;
unsigned long src_copied, literal_added, src_removed;
*merge_score_p = 0; /* assume no deletion --- "do not break"
@@ -64,7 +64,6 @@ static int should_break(struct diff_filespec *src,
if (diff_populate_filespec(src, 0) || diff_populate_filespec(dst, 0))
return 0; /* error but caught downstream */
- base_size = ((src->size < dst->size) ? src->size : dst->size);
max_size = ((src->size > dst->size) ? src->size : dst->size);
if (max_size < MINIMUM_BREAK_SIZE)
return 0; /* we do not break too small filepair */
diff --git a/fast-import.c b/fast-import.c
index 3748ddf..beeac0d 100644
--- a/fast-import.c
+++ b/fast-import.c
@@ -1745,21 +1745,19 @@ static void parse_data(struct strbuf *sb)
static int validate_raw_date(const char *src, char *result, int maxlen)
{
const char *orig_src = src;
- char *endp, sign;
- unsigned long date;
+ char *endp;
errno = 0;
- date = strtoul(src, &endp, 10);
+ strtoul(src, &endp, 10);
if (errno || endp == src || *endp != ' ')
return -1;
src = endp + 1;
if (*src != '-' && *src != '+')
return -1;
- sign = *src;
- date = strtoul(src + 1, &endp, 10);
+ strtoul(src + 1, &endp, 10);
if (errno || endp == src || *endp || (endp - orig_src) >= maxlen)
return -1;
diff --git a/fsck.c b/fsck.c
index 97f76c5..511b82c 100644
--- a/fsck.c
+++ b/fsck.c
@@ -148,20 +148,17 @@ static int fsck_tree(struct tree *item, int
strict, fsck_error error_func)
struct tree_desc desc;
unsigned o_mode;
const char *o_name;
- const unsigned char *o_sha1;
init_tree_desc(&desc, item->buffer, item->size);
o_mode = 0;
o_name = NULL;
- o_sha1 = NULL;
while (desc.size) {
unsigned mode;
const char *name;
- const unsigned char *sha1;
- sha1 = tree_entry_extract(&desc, &name, &mode);
+ tree_entry_extract(&desc, &name, &mode);
if (strchr(name, '/'))
has_full_path = 1;
@@ -207,7 +204,6 @@ static int fsck_tree(struct tree *item, int
strict, fsck_error error_func)
o_mode = mode;
o_name = name;
- o_sha1 = sha1;
}
retval = 0;
diff --git a/xdiff-interface.c b/xdiff-interface.c
index d782f06..b9b0db8 100644
--- a/xdiff-interface.c
+++ b/xdiff-interface.c
@@ -15,11 +15,10 @@ static int parse_num(char **cp_p, int *num_p)
{
char *cp = *cp_p;
int num = 0;
- int read_some;
while ('0' <= *cp && *cp <= '9')
num = num * 10 + *cp++ - '0';
- if (!(read_some = cp - *cp_p))
+ if (!(cp - *cp_p))
return -1;
*cp_p = cp;
*num_p = num;
--
1.6.2.81.ge603.dirty
^ permalink raw reply related
* Re: [PATCH] Brown paper bag fix for MinGW 64-bit stat
From: Junio C Hamano @ 2009-03-07 20:00 UTC (permalink / raw)
To: Johannes Sixt; +Cc: git, gitster, Johannes Schindelin
In-Reply-To: <03fcab37c921f5728deded11c07bdf32a263b79b.1236436185u.git.johannes.schindelin@gmx.de>
Johannes Schindelin <johannes.schindelin@gmx.de> writes:
> When overriding the identifier "stat" so that "struct stat" will be
> substituted with "struct _stati64" everywhere, I tried to fix the calls
> to the _function_ stat(), too, but I forgot to change the earlier
> attempt "stat64" to "_stati64" there.
>
> So, the stat() calls were overridden by calls to _stati64() instead.
>
> Unfortunately, there is a function _stati64() so that I missed that
> calls to stat() were not actually overridden by calls to mingw_lstat(),
> but t4200-rerere.sh showed the error.
>
> Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Since this is a fix-up to a new on 'master', I've applied the patch
myself, but how would we want to handle MinGW related patches in general?
My preference is to have somebody I can rely on receiving Acked forwards
from (or pulling from).
^ permalink raw reply
* Re: [GSoC] Google Summer of Code 2009 - new ideas
From: P Baker @ 2009-03-07 19:59 UTC (permalink / raw)
To: git
In-Reply-To: <200903070144.17457.jnareb@gmail.com>
I posted to this list serve a few days ago about one of the 2008 SoC
ideas. Are those ideas still plausible? Specifically, I'm interested
in pursuing the git-submodule update. Is this off the drawing board?
P Baker
On 3/6/09, Jakub Narebski <jnareb@gmail.com> wrote:
> Time to submit application as mentoring organization to
> Google Summer of Code 2009 is close: March 9 -- March 13.
>
> I'd like to add a few ideas to SoC2009Ideas wiki page, but before I do
> this I'd like to ask for comments. (The proposals also lacks proposed
> mentor).
>
> I am wondering if it would be worth it to make a separate class between
> "New to Git?" easy tasks, and "Larger Projects" hard tasks...
>
> BTW. some of ideas didn't make it from SoC2008Ideas wiki page to current
> year page, namely:
> * Apply sparse To Fix Errors
> * Lazy clone / remote alternates
> * Implement git-submodule using .gitlink file
> * Teach git-apply the 3-way merge fallback git-am knows
> * Better Emacs integration
> Was this ommision deliberate or accidental?
>
>
> -- >8 --
>
> = New To Git? New To Open Source Development? =
>
> == Packfile caching for git-daemon ==
>
> Even with delta reuse, enumerating objects to be present in packfile
> generates significant load on server for pack-generating protocols,
> such as git:// protocol used by git-daemon. Many of requests result in
> the same packfile to be generated and sent; examples include full
> clone, or fetch of all branches since last update. It would make sense
> then to save (cache) packfiles, and if possible avoid regenerating
> packfiles by sending them from cache. (Possible extension would be to
> send slightly larger pack than needed if one can reuse cached packfile
> instead).
>
> The goal is for git-daemon to cache packfiles, use cached packfiles if
> possible, and to manage packfile cache. Note that one would need in
> the final version some way to specify upper limit on packfile cache
> size and some cache entry expire policy.
>
> '''Goal:''' Support for packfile cache in git-daemon,
> benchmark server load
> '''Language:''' C
>
> == Single credentials ==
>
> Currently if you don't save your username and password in plain-text
> `.netrc` file (for HTTP transport), or avoid need for interactive
> credentials using public key / private key pair (for SSH), you need to
> repeat credentials many times during single git-fetch or git-clone
> command. The goal is to reuse existing connections if possible, so the
> whole transaction occurs using single connection and single
> credentials; if that is not possible cache credentials (in secure way)
> so user need to provide username and password at most once.
>
> '''Goal:''' git-fetch and git-clone over HTTPS and git://
> requiring providing username and password at most once
> '''Language:''' C (perhaps also shell script)
>
>
> = Larger Projects =
>
> == Directory renames ==
>
> Git deals quite well with renames when merging. One of the corner cases
> is when one side renamed some directory, and other side created ''new
> files'' in the old-name directory. Git currently creates new files in
> resurrected old-name directory, while it could create new files under
> new-name directory instead.
>
> There is a bit of controversy about this feature, as for example in
> some programming languages (e.g. Java) or in some project build tool
> info it is not posible to simply move a file (or create new file in
> different directory) without changing file contents. Some say that
> is better to fail than to do wrongly clean merge.
>
> '''Goal:''' At minimum option enabling wholesame directory rename
> detection. Preferred to add dealing with directory renames also to
> merge. At last, one can try to implement "git log --follow" for
> directories.
> '''Language:''' C
> '''See:''' [http://thread.gmane.org/gmane.comp.version-control.git/99529
> |RFC PATCH v2 0/2| Detection of directory renames] thread on git
> mailing list (via GMane)
> '''See also:'''
> *
> [http://thread.gmane.org/gmane.comp.version-control.git/80912/focus=81362
> merge renamed files/directories?] subthread on git mailing list
> * [http://thread.gmane.org/gmane.comp.version-control.git/108106
> Comments on "Understanding Version Control" by Eric S. Raymond] thread
> contains some thoughts on wholesame directory rename detection
> * [http://blog.teksol.info/2008/01/16/directory-renames-under-git
> Directory renames under Git] blog post notice the issue
> * [http://www.markshuttleworth.com/archives/123 Renaming is the killer
> app of distributed version control] blog post by Mak Shuttleworth
> (pro-Bazaar).
>
> --
> Jakub Narebski
> Poland
>
> --
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply
* Re: [PATCH] MinGW: fix diff --no-index /dev/null ...
From: Johannes Sixt @ 2009-03-07 19:56 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git, gitster
In-Reply-To: <dba002b9e521c639847650fbaeb8b87b66b9562e.1236441065u.git.johannes.schindelin@gmx.de>
On Samstag, 7. März 2009, Johannes Schindelin wrote:
> --- a/diff-no-index.c
> +++ b/diff-no-index.c
> @@ -38,6 +38,10 @@ static int get_mode(const char *path, int *mode)
>
> if (!path || !strcmp(path, "/dev/null"))
> *mode = 0;
> +#ifdef _WIN32
> + else if (!strcasecmp(path, "nul"))
> + *mode = 0;
> +#endif
> else if (!strcmp(path, "-"))
> *mode = create_ce_mode(0666);
> else if (lstat(path, &st))
IMO this #ifdef is a reasonable compromise. Trying to move this into
git-compat-util.h or mingw.h somehow would only obfuscate the code.
Tested-by: Johannes Sixt <j6t@kdbg.org>
-- Hannes
^ permalink raw reply
* Re: git-mergetool changes file rights?
From: Grzegorz Kossakowski @ 2009-03-07 19:54 UTC (permalink / raw)
To: Charles Bailey; +Cc: git
In-Reply-To: <20090307194821.GA29312@hashpling.org>
Charles Bailey pisze:
> On Sat, Mar 07, 2009 at 04:55:38PM +0100, Grzegorz Kossakowski wrote:
>> grek@linux-p3yg:~/asf/git/infrastructure/apache-git-mirrors/bin> git mergetool
>> merge tool candidates: kdiff3 kdiff3 tkdiff xxdiff meld gvimdiff opendiff emerge vimdiff
>> Merging the files: email-update.sh
>>
>> Normal merge conflict for 'email-update.sh':
>> {local}: modified
>> {remote}: modified
>> Hit return to start merge resolution tool (kdiff3):
>> error: open("bin/email-update.sh"): Permission denied
>> error: unable to index file bin/email-update.sh
>> fatal: updating files failed
>
> Looking at this sequence of error messages it looks like mergetool ran
> kdiff3 and this 'succeeded', but when mergetool came to 'git add' the
> result of the merge it fell over in a heap because it couldn't read
> the file because of the strange ---x------ permissions.
>
> mergetool just uses mv to create a backup of the to-be-merged path and
> then uses cp to recreate the original path before invoking kdiff3. I
> haven't managed to get cp to do anything other that use the same mode
> as the source file for a copied file.
>
> What version of kdiff3 are you using? I ask because this fix looks
> like it may be relevant:
>
> http://kdiff3.svn.sourceforge.net/viewvc/kdiff3/trunk/kdiff3/src-QT4/fileaccess.cpp?r1=84&r2=96
>
> The changelog for 0.9.95 includes this:
>
> - Fixed permissions when writing executable file. (Un*x only)
Hi Charles,
I didn't thought of blaming kdiff3 which seems to be the real guilty for my problems. I'm using 0.9.94 version but I'm
in the process of update.
I'll try that version and report back if it fixes my problem.
Thanks for your help!
--
Best regards,
Grzegorz Kossakowski
^ permalink raw reply
* Re: git-mergetool changes file rights?
From: Charles Bailey @ 2009-03-07 19:48 UTC (permalink / raw)
To: Grzegorz Kossakowski; +Cc: git
In-Reply-To: <49B298FA.2050803@tuffmail.com>
On Sat, Mar 07, 2009 at 04:55:38PM +0100, Grzegorz Kossakowski wrote:
> grek@linux-p3yg:~/asf/git/infrastructure/apache-git-mirrors/bin> git mergetool
> merge tool candidates: kdiff3 kdiff3 tkdiff xxdiff meld gvimdiff opendiff emerge vimdiff
> Merging the files: email-update.sh
>
> Normal merge conflict for 'email-update.sh':
> {local}: modified
> {remote}: modified
> Hit return to start merge resolution tool (kdiff3):
> error: open("bin/email-update.sh"): Permission denied
> error: unable to index file bin/email-update.sh
> fatal: updating files failed
Looking at this sequence of error messages it looks like mergetool ran
kdiff3 and this 'succeeded', but when mergetool came to 'git add' the
result of the merge it fell over in a heap because it couldn't read
the file because of the strange ---x------ permissions.
mergetool just uses mv to create a backup of the to-be-merged path and
then uses cp to recreate the original path before invoking kdiff3. I
haven't managed to get cp to do anything other that use the same mode
as the source file for a copied file.
What version of kdiff3 are you using? I ask because this fix looks
like it may be relevant:
http://kdiff3.svn.sourceforge.net/viewvc/kdiff3/trunk/kdiff3/src-QT4/fileaccess.cpp?r1=84&r2=96
The changelog for 0.9.95 includes this:
- Fixed permissions when writing executable file. (Un*x only)
--
Charles Bailey
http://ccgi.hashpling.plus.com/blog/
^ permalink raw reply
* Re: [PATCH] Brown paper bag fix for MinGW 64-bit stat
From: Johannes Sixt @ 2009-03-07 19:46 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git, gitster
In-Reply-To: <03fcab37c921f5728deded11c07bdf32a263b79b.1236436185u.git.johannes.schindelin@gmx.de>
On Samstag, 7. März 2009, Johannes Schindelin wrote:
> Actually, it was quite funny that t4200 displayed the bug; I
> _guess_ it was due to a time zone issue, as the times were exactly
> one hour off (and the machine I tested on is at UTC+0100 right now).
>
> And due to that bug, "rerere gc" would not collect the garbage.
U-oh, you are right! I was 100% sure that I ran the test-suite suite with your
earlier patch and it was all OK before I gave my ACK. But appearently I did
something wrong because today I see the failure in t4200, too, and this fixes
it, and it is the right thing to do.
> -#define stat64(x,y) mingw_lstat(x,y)
> +#define _stati64(x,y) mingw_lstat(x,y)
Acked-by: Johannes Sixt <j6t@kdbg.org>
-- Hannes
^ permalink raw reply
* Re: [PATCH 3/3] builtin-merge: add support for default merge options
From: jean-luc malet @ 2009-03-07 19:31 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jay Soffian, git
In-Reply-To: <7vzlfxpzqq.fsf@gitster.siamese.dyndns.org>
as a user,
1) I looked how to override defaults, since merge seems to use --ff as
default, I looked if there was any global config to override that.
nothing found... so go back to google
2) I found on the web that we can set it using
branch.branchname.mergeoptions so I said "what if I use a branch named
*, the config file was correct and git didn't insult me so.... but not
the expected result...
since the commands have allready defaults builtin, why not storing
thoses defaults in the config file? like this it's easier to update
them or change the way git behave....
JLM
On Sat, Mar 7, 2009 at 8:18 AM, Junio C Hamano <gitster@pobox.com> wrote:
> Jay Soffian <jaysoffian@gmail.com> writes:
>
>> On Fri, Mar 6, 2009 at 7:58 PM, Junio C Hamano <gitster@pobox.com> wrote:
>>> I think it would be much better if you did not introduce a new
>>> configuration merge.options which is not consistent with everything else
>>> to begin with.
>>>
>>> Instead, if your addition was literally to allow saying things like this,
>>> it would be much easier to understand.
>>>
>>> [branch "*"]
>>> mergeoptions = ...
>>> remote = origin
>>> rebase = true
>>
>> Okay. That's probably a more invasive patch, because a lot more code
>> paths look at [branch ...], but I'll look into it.
>
> Note that you do not have to cover branch.*.remote and other things in the
> same patch. The first one could just handle branch.*.mergeoptions and you
> can let later patches to implement the fallbacks for other variables.
>
>
--
KISS! (Keep It Simple, Stupid!)
(garde le simple, imbécile!)
"mais qu'est-ce que tu m'as pondu comme usine à gaz? fait des choses
simples et qui marchent, espèce d'imbécile!"
-----------------------------
"Si vous pensez que vous êtes trop petit pour changer quoique ce soit,
essayez donc de dormir avec un moustique dans votre chambre." Betty
Reese
http://www.grainesdechangement.com/citations.htm
^ permalink raw reply
* Re: What's in git.git (Mar 2009, #02; Thu, 05)
From: René Scharfe @ 2009-03-07 19:14 UTC (permalink / raw)
To: Junio C Hamano, carlos.duclos; +Cc: git
In-Reply-To: <7vfxhs2shk.fsf@gitster.siamese.dyndns.org>
Junio C Hamano schrieb:
> * The 'master' branch has these since v1.6.2 in addition to the above.
>
> Carlos Manuel Duclos Vergara (1):
> git-archive: add --output=<file> to send output to a file
It just hit me that this is option can be used for a DoS attack (or
perhaps worse) when used in connection with --remote. We need to apply
it on the client side instead of sending it to the remote end. And
git-upload-archive needs to filter it out. Ugh.
Here's a quick and dirty patch to do the latter.
---
archive.c | 14 +++++++++-----
archive.h | 2 +-
2 files changed, 10 insertions(+), 6 deletions(-)
diff --git a/archive.c b/archive.c
index c6aea83..c7534d7 100644
--- a/archive.c
+++ b/archive.c
@@ -260,7 +260,8 @@ static void create_output_file(const char *output_file)
PARSE_OPT_NOARG | PARSE_OPT_NONEG | PARSE_OPT_HIDDEN, NULL, (p) }
static int parse_archive_args(int argc, const char **argv,
- const struct archiver **ar, struct archiver_args *args)
+ const struct archiver **ar,
+ struct archiver_args *args, int local)
{
const char *format = "tar";
const char *base = NULL;
@@ -310,8 +311,11 @@ static int parse_archive_args(int argc, const char **argv,
if (!base)
base = "";
- if (output)
+ if (output) {
+ if (!local)
+ die("Unexpected option --output");
create_output_file(output);
+ }
if (list) {
for (i = 0; i < ARRAY_SIZE(archivers); i++)
@@ -343,13 +347,13 @@ static int parse_archive_args(int argc, const char **argv,
}
int write_archive(int argc, const char **argv, const char *prefix,
- int setup_prefix)
+ int local)
{
const struct archiver *ar = NULL;
struct archiver_args args;
- argc = parse_archive_args(argc, argv, &ar, &args);
- if (setup_prefix && prefix == NULL)
+ argc = parse_archive_args(argc, argv, &ar, &args, local);
+ if (local && prefix == NULL)
prefix = setup_git_directory();
parse_treeish_arg(argv, &args, prefix);
diff --git a/archive.h b/archive.h
index 0b15b35..f6c3c89 100644
--- a/archive.h
+++ b/archive.h
@@ -24,6 +24,6 @@ extern int write_tar_archive(struct archiver_args *);
extern int write_zip_archive(struct archiver_args *);
extern int write_archive_entries(struct archiver_args *args, write_archive_entry_fn_t write_entry);
-extern int write_archive(int argc, const char **argv, const char *prefix, int setup_prefix);
+extern int write_archive(int argc, const char **argv, const char *prefix, int local);
#endif /* ARCHIVE_H */
--
1.6.2
^ permalink raw reply related
* Re: Using Git with windows
From: Pascal Obry @ 2009-03-07 19:04 UTC (permalink / raw)
To: Robin Rosenberg; +Cc: Tim Visher, Tariq Hassanen, git
In-Reply-To: <200903072002.38698.robin.rosenberg.lists@dewire.com>
Robin Rosenberg a écrit :
> I think that worked fine when I tried using cygwin's apache. Mixing a cygwin
> git with a win32 apache did not work well.
Well, I tried with lighttpd IIRC. I do not want Apache just for browsing
a Git repo.
--
--|------------------------------------------------------
--| Pascal Obry Team-Ada Member
--| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE
--|------------------------------------------------------
--| http://www.obry.net - http://v2p.fr.eu.org
--| "The best way to travel is by means of imagination"
--|
--| gpg --keyserver keys.gnupg.net --recv-key F949BD3B
^ permalink raw reply
* Re: Using Git with windows
From: Robin Rosenberg @ 2009-03-07 19:02 UTC (permalink / raw)
To: pascal; +Cc: Tim Visher, Tariq Hassanen, git
In-Reply-To: <49B2B638.2090506@obry.net>
lördag 07 mars 2009 19:00:24 skrev Pascal Obry <pascal@obry.net>:
>
> oh yes one issue. I have never been able to make git instaweb working on
> Cygwin and never had time to look at this problem.
>
> Pascal.
>
I think that worked fine when I tried using cygwin's apache. Mixing a cygwin
git with a win32 apache did not work well.
-- robin
^ permalink raw reply
* Re: Clone a repo and checkout a specifc remote branch
From: Patrick Notz @ 2009-03-07 18:53 UTC (permalink / raw)
To: Paolo Ciarrocchi; +Cc: git list
In-Reply-To: <4d8e3fd30903070342q584315cjcd059dcfe558dcfd@mail.gmail.com>
On Sat, Mar 7, 2009 at 4:42 AM, Paolo Ciarrocchi
<paolo.ciarrocchi@gmail.com> wrote:
> Hi list,
> I've got a few questions from a friend that used git for the first
> time, I answered to all of them but the following.
>
> Scenario:
> He knows the URl of a git repository which contains a few branches. He
> is interested only to a single specific branch.
> He expected to manage to clone the specific remote branch with a
> single command, instead he had to learn the following procedure:
>
> $ git clone git://uri_of_the_repo localdir
> $ cd localdir
> $ git branch
> * master
> # OK, so now he cloned the whole repository and checked out the master branch
> $ git checkout mybranch origin/coolbranch
>
> Wouldn't be an improvement to let the user to specify which remote
> branch he want to be checked out after a clone?
> Something like:
> $ git clone git://uri_of_the_repo:coolbranch localdir
> to get a clone of the whole repository and to check out the
> origin/coolbranch remote branch?
>
Here's a link to a recent thread on this topic (that started with a
proposed patch)
http://thread.gmane.org/gmane.comp.version-control.git/111967
You can read the arguments there. Johannes Schindelin noted that the
normal way to do this is like this:
<quote>
Besides, the common way to check out something different than the remote's
HEAD is like this:
$ git clone -n $URL
$ cd $DIR
$ git checkout -t origin/$BRANCH
</quote>
> I quickly discussed this scenario on the #git channel and a user
> suggested to use the following procedure:
> $ git init
> $ git fetch git://uri_of_the_repo coolbranch
> which was new to me, I tried it as follow:
> $ git fetch git://git.kernel.org/pub/scm/git/git.git man
> remote: Counting objects: 7319, done.←[K
> remote: Compressing objects: 100% (1536/1536), done.←[K
> remote: Total 7319 (delta 5640), reused 7290 (delta 5625)←[K
> Receiving objects: 100% (7319/7319), 1.40 MiB | 110 KiB/s, done.
> Resolving deltas: 100% (5640/5640), done.
> From git://git.kernel.org/pub/scm/git/git
> * branch man -> FETCH_HEAD
>
> but now I don't understand how to checkout the branch :-/
>
> Ciao,
> --
> Paolo
> http://paolo.ciarrocchi.googlepages.com/
> http://mypage.vodafone.it/
> --
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply
* Re: jGit Eclipse Plugin Feature
From: Tor Arne Vestbø @ 2009-03-07 18:40 UTC (permalink / raw)
To: Robin Rosenberg; +Cc: Robert Navarro, git
In-Reply-To: <200903071845.20855.robin.rosenberg.lists@dewire.com>
Robin Rosenberg wrote:
> lördag 07 mars 2009 16:58:47 skrev Tor Arne Vestbø <torarnv@gmail.com>:
>> Robert Navarro wrote:
>>> Hello,
>>>
>>> Sorry about my last "subscribe" email, skipped over this part in the
>>> wiki...."You don't even need to be subscribed to post, just send an
>>> email to: "
>>>
>>> Anyways.....I wasn't sure where to post this but I'll give it a shot
>>> here.....I know there is an eclipse jGit plugin in the works and I
>>> wanted to know if it would be possible to get a remember or recently
>>> used servers feature added to the push/pull feature.
>> I have done some initial prototyping of a Remotes View. I'll see if I
>> can bring that to life somehow.
>
> I assumed the feature is about the push dialog. If we have a remotes
> view it'd be nice to see it there too.
Yepp. I imagine something like a list of remotes, which can be
referenced at any point a remote is needed, like the push dialog.
Wizards that need a remote, can display the list of the existing
remotes, with a "create new" option, which would launch the page from
the "create new remote" wizard (similar to the "Add new CVS Repository"
stuff). Something along those lines.
> Where should it remembered? In the workspace or .git/config?
Good question. Will need some thinking :)
Tor Arne
^ permalink raw reply
* Re: Using Git with windows
From: Pascal Obry @ 2009-03-07 18:00 UTC (permalink / raw)
To: Tim Visher; +Cc: Tariq Hassanen, git
In-Reply-To: <c115fd3c0903060638lfc52073nd40e0d7379d7f593@mail.gmail.com>
oh yes one issue. I have never been able to make git instaweb working on
Cygwin and never had time to look at this problem.
Pascal.
--
--|------------------------------------------------------
--| Pascal Obry Team-Ada Member
--| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE
--|------------------------------------------------------
--| http://www.obry.net - http://v2p.fr.eu.org
--| "The best way to travel is by means of imagination"
--|
--| gpg --keyserver keys.gnupg.net --recv-key F949BD3B
^ permalink raw reply
* Re: Using Git with windows
From: Pascal Obry @ 2009-03-07 17:58 UTC (permalink / raw)
To: Tim Visher; +Cc: Tariq Hassanen, git
In-Reply-To: <c115fd3c0903060638lfc52073nd40e0d7379d7f593@mail.gmail.com>
Tim Visher a écrit :
> I wouldn't bother waiting. Git is plenty mature on Windows, either
> via msys or via Cygwin. There's no real reason to delay. :)
I second that. I'm using Cygwin's Git for almost 2 years now on more
than 15 repositories. Some are plain Git, the most of them are git-svn.
No issue, working perfectly under Cygwin.
Pascal.
--
--|------------------------------------------------------
--| Pascal Obry Team-Ada Member
--| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE
--|------------------------------------------------------
--| http://www.obry.net - http://v2p.fr.eu.org
--| "The best way to travel is by means of imagination"
--|
--| gpg --keyserver keys.gnupg.net --recv-key F949BD3B
^ permalink raw reply
* Re: [JGit] Push to new Amazon S3 does not work? ("funny refname")
From: Robin Rosenberg @ 2009-03-07 17:50 UTC (permalink / raw)
To: Daniel Cheng, spearce; +Cc: git
In-Reply-To: <ff6a9c820903070805m34f792dard6b17d2029e41dfe@mail.gmail.com>
lördag 07 mars 2009 17:05:02 skrev Daniel Cheng <j16sdiz+freenet@gmail.com>:
> Pushing to new Amazon S3 repository does not work.
> It say "funny refname" without pushing anything:
>
> <<<<<<<<<
> $ jgit push s3 master
> To amazon-s3://0NQ4APQ8R7S6HQ65TWR2@egitsdiz/1.git
> ! [remote rejected] master -> master (funny refname)
> $ s3cmd la
> DIR s3://egitsdiz/1.git/
> $
> >>>>>>>>>
>
> Any idea what's happening here?
>
>
> The code is in WalkPushConnection.java line 137:
> <<<<<<<<<
> 134 final List<RemoteRefUpdate> updates = new ArrayList<RemoteRefUpdate>();
> 135 for (final RemoteRefUpdate u : refUpdates.values()) {
> 136 final String n = u.getRemoteName();
> 137 if (!n.startsWith("refs/") || !Repository.isValidRefName(n)) {
> 138 u.setStatus(Status.REJECTED_OTHER_REASON);
> 139 u.setMessage("funny refname");
> 140 continue;
> 141 }
> >>>>>>>>>
>
> u.getRemoteName() gives "master" here.
> Removing n.startsWith("refs/") would generate a bad `packed-refs`
> file in later code.
> I tried to fix this, but failed to do so without breaking GitSsh transports
This is not specific to s3. It seems jgit wants a fully qualified ref for the remote
side, so refs/heads/master will work for the other protocols, and I guess s3 too.
- robin
^ permalink raw reply
* Re: jGit Eclipse Plugin Feature
From: Robin Rosenberg @ 2009-03-07 17:45 UTC (permalink / raw)
To: Tor Arne Vestbø; +Cc: Robert Navarro, git
In-Reply-To: <49B299B7.80009@gmail.com>
lördag 07 mars 2009 16:58:47 skrev Tor Arne Vestbø <torarnv@gmail.com>:
> Robert Navarro wrote:
> > Hello,
> >
> > Sorry about my last "subscribe" email, skipped over this part in the
> > wiki...."You don't even need to be subscribed to post, just send an
> > email to: "
> >
> > Anyways.....I wasn't sure where to post this but I'll give it a shot
> > here.....I know there is an eclipse jGit plugin in the works and I
> > wanted to know if it would be possible to get a remember or recently
> > used servers feature added to the push/pull feature.
>
> I have done some initial prototyping of a Remotes View. I'll see if I
> can bring that to life somehow.
I assumed the feature is about the push dialog. If we have a remotes
view it'd be nice to see it there too. Where should it remembered? In
the workspace or .git/config?
-- robin
^ permalink raw reply
* Re: [PATCH v2] http: use strbuf API in quote_ref_url
From: Johannes Schindelin @ 2009-03-07 17:32 UTC (permalink / raw)
To: Tay Ray Chuan; +Cc: git
In-Reply-To: <49B2A519.8050802@gmail.com>
Hi,
On Sun, 8 Mar 2009, Tay Ray Chuan wrote:
> In addition, ''quote_ref_url'' inserts a slash between the base URL and
> remote ref path only if needed. Previously, this insertion wasn't
> contingent on the lack of a separating slash.
>
> Signed-off-by: Tay Ray Chuan <rctay89@gmail.com>
Thanks, and ACK ;-)
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH 0/3] config --bool-or-int fixes
From: Jeff King @ 2009-03-07 17:16 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano, Felipe Contreras
In-Reply-To: <1236446046-18319-1-git-send-email-peff@peff.net>
On Sat, Mar 07, 2009 at 12:14:03PM -0500, Jeff King wrote:
> The interesting one is 2/3, which fixes a bogus usage message due to the
> recent parseopt conversion. The others are cleanups that I noticed while
> fixing it.
>
> [PATCH 1/3] t1300: use test_must_fail as appropriate
> [PATCH 2/3] config: set help text for --bool-or-int
> [PATCH 3/3] document config --bool-or-int
I failed to mention, but it may have been obvious: these should go on
top of the fc/parseopt-config topic in next.
-Peff
^ permalink raw reply
* [PATCH 3/3] document config --bool-or-int
From: Jeff King @ 2009-03-07 17:14 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano, Felipe Contreras, Jeff King
In-Reply-To: <1236446046-18319-1-git-send-email-peff@peff.net>
The documentation is just a pointer to the --bool and --int
options, but it makes sense to at least mention that it
exists.
Signed-off-by: Jeff King <peff@peff.net>
---
Maybe it is pointless to document this; it seems to have been added by
c35b0b5 purely as a way for t1300 to test the git_config_bool_or_int
feature.
In that case, 2/3 should probably be hiding it instead of describing it,
as well.
Documentation/git-config.txt | 4 ++++
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/Documentation/git-config.txt b/Documentation/git-config.txt
index 7d14007..82ce89e 100644
--- a/Documentation/git-config.txt
+++ b/Documentation/git-config.txt
@@ -131,6 +131,10 @@ See also <<FILES>>.
in the config file will cause the value to be multiplied
by 1024, 1048576, or 1073741824 prior to output.
+--bool-or-int::
+ 'git-config' will ensure that the output matches the format of
+ either --bool or --int, as described above.
+
-z::
--null::
For all options that output values and/or keys, always
--
1.6.2.195.g44251.dirty
^ permalink raw reply related
* [PATCH 2/3] config: set help text for --bool-or-int
From: Jeff King @ 2009-03-07 17:14 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano, Felipe Contreras, Jeff King
In-Reply-To: <1236446046-18319-1-git-send-email-peff@peff.net>
The conversion to parse_opt left this as NULL; on glibc
systems, the usage message prints
--bool-or-int (null)
and on other ones, segfaults.
Signed-off-by: Jeff King <peff@peff.net>
---
I found this by running t1300 on a non-glibc system. I guess printing
(null) is friendlier for real code, but for the test suite, it would be
much more convenient to have it segfault to detect the bug. This is not
the first such error we've had that I've caught in the same way.
builtin-config.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/builtin-config.c b/builtin-config.c
index b11a096..1a3baa1 100644
--- a/builtin-config.c
+++ b/builtin-config.c
@@ -68,7 +68,7 @@ static struct option builtin_config_options[] = {
OPT_GROUP("Type"),
OPT_BIT(0, "bool", &types, "value is \"true\" or \"false\"", TYPE_BOOL),
OPT_BIT(0, "int", &types, "value is decimal number", TYPE_INT),
- OPT_BIT(0, "bool-or-int", &types, NULL, TYPE_BOOL_OR_INT),
+ OPT_BIT(0, "bool-or-int", &types, "value is --bool or --int", TYPE_BOOL_OR_INT),
OPT_GROUP("Other"),
OPT_BOOLEAN('z', "null", &end_null, "terminate values with NUL byte"),
OPT_END(),
--
1.6.2.195.g44251.dirty
^ permalink raw reply related
* [PATCH 1/3] t1300: use test_must_fail as appropriate
From: Jeff King @ 2009-03-07 17:14 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano, Felipe Contreras, Jeff King
In-Reply-To: <1236446046-18319-1-git-send-email-peff@peff.net>
Some of the tests checked the exit code manually, even going
so far as to run git outside of the test_expect harness.
Signed-off-by: Jeff King <peff@peff.net>
---
Just a cleanup I noticed when one of the tests failed for me.
t/t1300-repo-config.sh | 10 +++++-----
1 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/t/t1300-repo-config.sh b/t/t1300-repo-config.sh
index 11b82f4..3c06842 100755
--- a/t/t1300-repo-config.sh
+++ b/t/t1300-repo-config.sh
@@ -336,10 +336,10 @@ test_expect_success 'get bool variable with empty value' \
'git config --bool emptyvalue.variable > output &&
cmp output expect'
-git config > output 2>&1
-
-test_expect_success 'no arguments, but no crash' \
- "test $? = 129 && grep usage output"
+test_expect_success 'no arguments, but no crash' '
+ test_must_fail git config >output 2>&1 &&
+ grep usage output
+'
cat > .git/config << EOF
[a.b]
@@ -373,7 +373,7 @@ EOF
test_expect_success 'new variable inserts into proper section' 'cmp .git/config expect'
test_expect_success 'alternative GIT_CONFIG (non-existing file should fail)' \
- 'git config --file non-existing-config -l; test $? != 0'
+ 'test_must_fail git config --file non-existing-config -l'
cat > other-config << EOF
[ein]
--
1.6.2.195.g44251.dirty
^ permalink raw reply related
* [PATCH 0/3] config --bool-or-int fixes
From: Jeff King @ 2009-03-07 17:14 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano, Felipe Contreras
The interesting one is 2/3, which fixes a bogus usage message due to the
recent parseopt conversion. The others are cleanups that I noticed while
fixing it.
[PATCH 1/3] t1300: use test_must_fail as appropriate
[PATCH 2/3] config: set help text for --bool-or-int
[PATCH 3/3] document config --bool-or-int
^ permalink raw reply
* [PATCH v2] http: use strbuf API in quote_ref_url
From: Tay Ray Chuan @ 2009-03-07 16:47 UTC (permalink / raw)
To: git, Johannes Schindelin
In addition, ''quote_ref_url'' inserts a slash between the base URL and
remote ref path only if needed. Previously, this insertion wasn't
contingent on the lack of a separating slash.
Signed-off-by: Tay Ray Chuan <rctay89@gmail.com>
---
Differences from v1:
*use buf when checking for '/'
*remove for's braces
http.c | 30 ++++++++++--------------------
1 files changed, 10 insertions(+), 20 deletions(-)
diff --git a/http.c b/http.c
index cdedeb6..1691498 100644
--- a/http.c
+++ b/http.c
@@ -577,31 +577,21 @@ static inline int hex(int v)
static char *quote_ref_url(const char *base, const char *ref)
{
+ struct strbuf buf = STRBUF_INIT;
const char *cp;
- char *dp, *qref;
- int len, baselen, ch;
+ int ch;
- baselen = strlen(base);
- len = baselen + 2; /* '/' after base and terminating NUL */
- for (cp = ref; (ch = *cp) != 0; cp++, len++)
+ strbuf_addstr(&buf, base);
+ if (buf.len && buf.buf[buf.len - 1] != '/' && *ref != '/')
+ strbuf_addstr(&buf, "/");
+
+ for (cp = ref; (ch = *cp) != 0; cp++)
if (needs_quote(ch))
- len += 2; /* extra two hex plus replacement % */
- qref = xmalloc(len);
- memcpy(qref, base, baselen);
- dp = qref + baselen;
- *(dp++) = '/';
- for (cp = ref; (ch = *cp) != 0; cp++) {
- if (needs_quote(ch)) {
- *dp++ = '%';
- *dp++ = hex((ch >> 4) & 0xF);
- *dp++ = hex(ch & 0xF);
- }
+ strbuf_addf(&buf, "%%%02x", ch);
else
- *dp++ = ch;
- }
- *dp = 0;
+ strbuf_addch(&buf, *cp);
- return qref;
+ return strbuf_detach(&buf, NULL);
}
int http_fetch_ref(const char *base, struct ref *ref)
--
1.6.2.rc1
^ 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