Am 5/10/2013 3:13, schrieb Junio C Hamano:
> * On the other hand, "git log 'fc/*'" might be a handy thing for
>any command that wants to have multiple starting points for
>revision traversal, so in principle I would not mind such an
>enhancement to rev-list machinery.
Currently, we sp
Johannes Sixt writes:
> Am 5/8/2013 18:16, schrieb Matt McClure:
>> That begs a follow-up question. It sounds as though Git will typically
>> delete unreachable objects. My team often shares links like
>> https://git.example.com/foo.git/log/d59051721bb0a3758f7c6ea0452bac122a377645?hp=0055e0959c
Am 5/8/2013 18:16, schrieb Matt McClure:
> That begs a follow-up question. It sounds as though Git will typically
> delete unreachable objects. My team often shares links like
> https://git.example.com/foo.git/log/d59051721bb0a3758f7c6ea0452bac122a377645?hp=0055e0959cd13780494fe33832bae9bcf91e4a9
Hi,
I just installed the latest Git released a few days ago. I can't seem to get an
application icon or find it on my Mac. I can only find the installer. Am I
doing something wrong?
I'm just beginning to learn Git.
Thanks,
Esther--
To unsubscribe from this list: send the line "unsubscribe git"
On Thu, May 09, 2013 at 03:17:30PM -0700, David Aguilar wrote:
> Generally, "mergetool..cmd" is not general enough since we've
> always special cased the base vs. no-base code paths and we run
> different commands depending on whether a base is available.
Then this is a deficiency of the ".cmd" me
Felipe Contreras writes:
> On Thu, May 9, 2013 at 6:27 PM, Junio C Hamano wrote:
> ...
>> That is the kind of thing that needs to be said, not in the
>> discussion but in the history, either in the log or in a new test,
>> or both.
>
> If only I had known that when I wrote the commit message.
T
Hi,
Michael Hunley wrote:
> Ok, we can filter that out. But worse is that actual errors in a pull
> request are sent to stdout instead of standard error. For example,
> merge conflicts or pull failures because you have unstaged changes.
Yes, errors and progress output should go to stderr. The
Filipe Cabecinhas writes:
> Sorry for the delay. I've updated the patch to work as you suggested (I
> think).
> It's attached.
A few comments.
First, the formalities. Please see Documentation/SubmittingPatches,
notably:
- Please do not send a patch as an attachment.
- The attached pat
On Fri, May 10, 2013 at 6:07 AM, Ruediger Meier wrote:
> Hi,
>
> I have a use case where I'd like to improve performance using "git
> clone --depth". But I also need "git describe" working on that clone.
>
> So something like
> git clone --depth=describable
> would be nice to have.
What does --d
Junio C Hamano writes:
> Felipe Contreras writes:
>
>> On Thu, May 9, 2013 at 6:23 PM, Junio C Hamano wrote:
>>> Simple. You treat everything as refspecs and form revision ranges
>>> out of them. Note that that is exactly the reason why "git push"
>>> can take "master" as a short-hand for "ma
On Thu, May 9, 2013 at 7:21 PM, Junio C Hamano wrote:
> Felipe Contreras writes:
>
>> On Thu, May 9, 2013 at 6:23 PM, Junio C Hamano wrote:
>>> Simple. You treat everything as refspecs and form revision ranges
>>> out of them. Note that that is exactly the reason why "git push"
>>> can take "m
Felipe Contreras writes:
> On Thu, May 9, 2013 at 6:23 PM, Junio C Hamano wrote:
>> Simple. You treat everything as refspecs and form revision ranges
>> out of them. Note that that is exactly the reason why "git push"
>> can take "master" as a short-hand for "master:master" [*1*].
> ...
>> So
On Thu, May 9, 2013 at 6:27 PM, Junio C Hamano wrote:
> Felipe Contreras writes:
>
>> On Thu, May 9, 2013 at 5:17 PM, Junio C Hamano wrote:
>>> Felipe Contreras writes:
>>>
We don't want to pass arguments specific to fast-export to
setup_revisions.
>>>
>>> Interesting. What bad thing
On Thu, May 9, 2013 at 6:23 PM, Junio C Hamano wrote:
> Felipe Contreras writes:
>
>> Of course, but how do you implement that? That's mixing refspecs and
>> revlist arguments, which AFAIK don't mix:
>
> Simple. You treat everything as refspecs and form revision ranges
> out of them. Note that
Felipe Contreras writes:
> On Thu, May 9, 2013 at 5:17 PM, Junio C Hamano wrote:
>> Felipe Contreras writes:
>>
>>> We don't want to pass arguments specific to fast-export to
>>> setup_revisions.
>>
>> Interesting. What bad things happen with the current order?
>>
>> Does "fast-export --export
Felipe Contreras writes:
> Of course, but how do you implement that? That's mixing refspecs and
> revlist arguments, which AFAIK don't mix:
Simple. You treat everything as refspecs and form revision ranges
out of them. Note that that is exactly the reason why "git push"
can take "master" as a
On Thu, May 9, 2013 at 8:14 AM, John Keeping wrote:
> On Thu, May 09, 2013 at 02:13:30AM -0700, David Aguilar wrote:
>> Mac OS X Mountain Lion prints warnings when building git:
>>
>> warning: 'SHA1_Init' is deprecated
>> (declared at /usr/include/openssl/sha.h:121)
>>
>> Silence the w
On Thu, May 9, 2013 at 6:09 PM, Junio C Hamano wrote:
> John Szakmeister writes:
>
>> On Wed, May 8, 2013 at 9:16 PM, Felipe Contreras
>> wrote:
>>> Signed-off-by: Felipe Contreras
>>> ---
>>> builtin/fast-export.c | 24
>>> 1 file changed, 12 insertions(+), 12 deletio
John Szakmeister writes:
> On Wed, May 8, 2013 at 9:16 PM, Felipe Contreras
> wrote:
>> Signed-off-by: Felipe Contreras
>> ---
>> builtin/fast-export.c | 24
>> 1 file changed, 12 insertions(+), 12 deletions(-)
>>
>> diff --git a/builtin/fast-export.c b/builtin/fast-ex
Felipe Contreras writes:
> White-spaces, missing braces, standardize --[no-]foo.
>
> Signed-off-by: Felipe Contreras
This is uncomfortably big at this phase of the release cycle, but
thanks anyway.
Because I didn't want to review this patch only to spot silly
formatting mistakes that may break
Hi,
I have a use case where I'd like to improve performance using "git
clone --depth". But I also need "git describe" working on that clone.
So something like
git clone --depth=describable
would be nice to have.
Would it be possible to add such feature?
cu,
Rudi
--
To unsubscribe from this li
Thanks; no brainer.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
On Thu, May 9, 2013 at 5:17 PM, Junio C Hamano wrote:
> Felipe Contreras writes:
>
>> We don't want to pass arguments specific to fast-export to
>> setup_revisions.
>
> Interesting. What bad things happen with the current order?
>
> Does "fast-export --export-marks=foo" causes setup_revisions()
Hi Junio,
Sorry for the delay. I've updated the patch to work as you suggested (I think).
It's attached.
Thank you,
Filipe
F
On Tue, Apr 9, 2013 at 3:50 PM, Junio C Hamano wrote:
> Filipe Cabecinhas writes:
>
>>
>> Testing with dd bs=INT_MAX+1 count=1 also gets me an “Invalid
>> argument
Felipe Contreras writes:
> +test_expect_success 'use refspec' '
> + git fast-export --refspec refs/heads/master:refs/heads/foobar master | \
> + grep "^commit " | sort | uniq > actual &&
You do not need backslash after the pipe symbol at the end of line;
the shell knows you haven
On Thu, May 9, 2013 at 5:32 PM, Junio C Hamano wrote:
> Felipe Contreras writes:
>
>> +test_expect_success 'use refspec' '
>> + git fast-export --refspec refs/heads/master:refs/heads/foobar master |
>> \
>> + grep "^commit " | sort | uniq > actual &&
>
> You do not need backslash
On Thu, May 09, 2013 at 06:16:36PM +0200, Heiko Voigt wrote:
> This is an update with the comments of the second iteration[1] incorporated.
>
> [1] http://thread.gmane.org/gmane.comp.version-control.git/217811
>
> Heiko Voigt (5):
> config: factor out config file stack management
> config: d
On Thu, May 09, 2013 at 06:21:02PM +0200, Heiko Voigt wrote:
> diff --git a/builtin/config.c b/builtin/config.c
> index 8d01b7a..de32977 100644
> --- a/builtin/config.c
> +++ b/builtin/config.c
> @@ -219,9 +219,11 @@ static int get_value(const char *key_, const char
> *regex_)
> }
>
On Thu, May 09, 2013 at 06:20:18PM +0200, Heiko Voigt wrote:
> +static int config_buf_fgetc(struct config_source *conf)
> +{
> + if (conf->buf.pos < conf->buf.len && conf->buf.buf[conf->buf.pos])
> + return conf->buf.buf[conf->buf.pos++];
> +
> + return EOF;
> +}
It probably w
On Thu, May 09, 2013 at 06:19:32PM +0200, Heiko Voigt wrote:
> diff --git a/config.c b/config.c
> index 046642b..2390458 100644
> --- a/config.c
> +++ b/config.c
> @@ -10,20 +10,41 @@
> #include "strbuf.h"
> #include "quote.h"
>
> -typedef struct config_file {
> - struct config_file *prev;
Felipe Contreras writes:
> We don't want to pass arguments specific to fast-export to
> setup_revisions.
Interesting. What bad things happen with the current order?
Does "fast-export --export-marks=foo" causes setup_revisions() to
mistakenly eat --export-marks=foo and barf?
>
> Signed-off-by:
On Thu, May 9, 2013 at 12:15 PM, Junio C Hamano wrote:
> John Keeping writes:
>
>> On Thu, May 09, 2013 at 09:10:51AM -0700, Junio C Hamano wrote:
>>> David Aguilar writes:
>>>
>>> > Marked "RFC" because I am kinda against adding more configuration
>>> > variables.
>>>
>>> Just like "git merge"
The latest maintenance release Git v1.8.2.3 is now available at
the usual places.
The release tarballs are found at:
http://code.google.com/p/git-core/downloads/list
and their SHA-1 checksums are:
2831f7deec472db4d0d0cdffb4d82d91cecdf295 git-1.8.2.3.tar.gz
b8d6b3c4077d37b34bf08b6eb53c4ee59
Here are the topics that have been cooking. Commits prefixed with
'-' are only in 'pu' (proposed updates) while commits prefixed with
'+' are in 'next'.
I'll tag 1.8.3-rc2 by the end of the week, and hopefully we can have
a solid final release late next week. One embarrassing regression
was foun
Am 09.05.2013 22:35 schrieb Ramsay Jones:
> Note that '-Icompat/poll' is passed on the command-line (it is split at -Icomp
> above), which comes from:
>
> ramsay (tmp) ms $ git grep -n 'compat/poll'
> Makefile:647:LIB_H += compat/poll/poll.h
> Makefile:1235: COMPAT_CFLAGS += -DNO_POLL
On Thursday 09 May 2013 04:19 AM, Junio C Hamano wrote:
> [...] which in turn made me realize that some commands may not even know
> if the user mistyped a ref. It is not an objection to this patch
> per-se, but a useful future enhancement may be to allow the callers
> call guess_mistyped_ref() d
Heiko Voigt writes:
> I fixed all the issues I know of so this should be ready for master.
Thanks for working on thsi, but that is 'master after 1.8.3' at this
point in the release cycle.
I am declaring patch bankruptcy and will not be picking up new
patches that are not regression fixes meant
Sven Strickroth wrote:
> Am 31.01.2013 19:28 schrieb Ramsay Jones:
>> Commit 0f77dea9 ("mingw: move poll out of sys-folder", 24-10-2011), along
>> with other commits in the 'ef/mingw-upload-archive' branch (see commit
>> 7406aa20), effectively reintroduced the same problem addressed by commit
>> 56
wor...@alum.mit.edu (Dale R. Worley) writes:
> body, the "From e87227..." line will have no place to go. And perhaps
> it is an important part of the patch, since "git format-patch" outputs
> it?
As you noticed (correctly), the output of "format-patch" is meant to
be usable by "am" that reads fr
Junio C Hamano writes:
> Miklos Vajna writes:
>
>> When a single argument was a non-commit, the error message used to be:
>>
>> fatal: BUG: expected exactly one commit from walk
>>
>> For multiple arguments, when none of the arguments was a commit, the error
>> was:
>>
>> fatal: empty
> From: Junio C Hamano
>
> > From e87227498ef3d50dc20584c24c53071cce63c555 Mon Sep 17 00:00:00 2001
> > From: Dale Worley
> > Date: Tue, 7 May 2013 13:39:46 -0400
> > Subject: [PATCH] CodingGuidelines: make it clear which files in
> > Documentation/ are the sources
>
> These five lines are pr
On Wed, May 8, 2013 at 12:05 PM, Matt McClure wrote:
> On Wed, May 8, 2013 at 10:41 AM, Johannes Sixt wrote:
>> git gc moves unreachable objects that were packed before to the loose
>> object store, from where they can be pruned.
>
> Thanks. That was the piece I was missing. I assumed `git gc` di
Miklos Vajna writes:
> When a single argument was a non-commit, the error message used to be:
>
> fatal: BUG: expected exactly one commit from walk
>
> For multiple arguments, when none of the arguments was a commit, the error
> was:
>
> fatal: empty commit set passed
>
> Finally, wh
On Thu, May 9, 2013 at 1:38 PM, Junio C Hamano wrote:
> Felipe Contreras writes:
>
if (!author)
- die ("Could not find author in commit %s",
+ die("Could not find author in commit %s",
sha1_to_hex(commit->object.sha1));
On Mon, May 6, 2013 at 10:43 PM, Jeff King wrote:
> Once we read the packed-refs file into memory, we cache it
> to save work on future ref lookups. However, our cache may
> be out of date with respect to what is on disk if another
> process is simultaneously packing the refs. Normally it
> is acc
John Keeping writes:
> On Thu, May 09, 2013 at 09:10:51AM -0700, Junio C Hamano wrote:
>> David Aguilar writes:
>>
>> > Marked "RFC" because I am kinda against adding more configuration
>> > variables.
>>
>> Just like "git merge" has -X escape hatch to allow us to
>> pass backend-specific opti
Am 09.05.2013 20:21, schrieb Eric Sunshine:
On Thu, May 9, 2013 at 9:13 AM, René Scharfe
wrote:
$ tar tf tenk.tar; echo $?
tar: Cannot identify format. Searching...
tar: End of archive volume 1 reached
tar: Sorry, unable to determine archive format.
Missing
John Szakmeister writes:
> On Thu, May 9, 2013 at 4:53 AM, Felipe Contreras
> wrote:
> [snip]
@@ -562,9 +561,7 @@ static void handle_tags_and_duplicates(struct
string_list *extra_refs)
break;
case OBJ_COMMIT:
Felipe Contreras writes:
>>> if (!author)
>>> - die ("Could not find author in commit %s",
>>> + die("Could not find author in commit %s",
>>> sha1_to_hex(commit->object.sha1));
>>
>> It looks like your simple replace didn't account for cal
On Wed, May 8, 2013 at 5:12 PM, Junio C Hamano wrote:
> sha1_name.c: signal if @{-N} was a true branch nameor a detached head
s/nameor/name or/
> The original API read "checkout: moving from (.*) to ..." from the
> reflog of the HEAD, and returned the substring between "from" and
> "to", but the
On Thu, May 9, 2013 at 12:20 PM, Heiko Voigt wrote:
> This can be used to read configuration values directly from gits
s/gits/git's/
> database. For example it is useful for reading to be checked out
> .gitmodules files directly from the database.
>
> Signed-off-by: Heiko Voigt
--
To unsubscrib
On Thu, May 9, 2013 at 12:21 PM, Heiko Voigt wrote:
> If a config parsing error in a file occurs we can die and let the user
> fix the issue. This is different for the buf parsing function since it
> can be used to parse blobs of .gitmodules files. If a parsing error
> occurs here we should procee
On Thu, May 9, 2013 at 9:13 AM, René Scharfe
wrote:
> Test 2 of t5004 checks if a supposedly empty tar archive really
> contains no files. 24676f02 (t5004: fix issue with empty archive test
> and bsdtar) removed our commit hash to make it work with bsdtar, but
> the test still fails on NetBSD and
On 05/09/13 08:10, René Scharfe wrote:
> Am 06.05.2013 22:16, schrieb Stephen Boyd:
>> Ok. I tested it and it definitely helps.
>>
>> ==10728== LEAK SUMMARY:
>> ==10728==definitely lost: 316,355,458 bytes in 8,652 blocks
>> ==10728==indirectly lost: 1,327,251,588 bytes in 16,180,628 blocks
On Thu, May 09, 2013 at 09:10:51AM -0700, Junio C Hamano wrote:
> David Aguilar writes:
>
> > Marked "RFC" because I am kinda against adding more configuration
> > variables.
>
> Just like "git merge" has -X escape hatch to allow us to
> pass backend-specific options, perhaps you can add a mecha
Torsten Bögershausen wrote:
> On 2013-05-04 01.14, Junio C Hamano wrote:
>>
>> Cygwin portability; both were reviewed by Jonathan, and the tip one
>> seems to want a bit further explanation. Needs positive report
>> from Cygwin 1.7 users who have been on 1.7 to make sure it does not
>> regress
Signed-off-by: Jiang Xin
Helped-by: Eric Sunshine
---
Documentation/git-clean.txt | 71 +++--
1 file changed, 69 insertions(+), 2 deletions(-)
diff --git a/Documentation/git-clean.txt b/Documentation/git-clean.txt
index 186e34..4512f7 100644
--- a/Documen
Add new wrapper `scan_clean_candidates`, which determines the del_list
(i.e. the cleaning candidates). This function will be reused later in
the interactive git-clean, so we can change flags of git-clean and
refresh the del_list.
Signed-off-by: Jiang Xin
---
builtin/clean.c | 169 +++
Add new action in the interactive mode, so that the user can change
git-clean flags, such as -x/-X/-d/-ff, and refresh the cleaning
candidates list.
Signed-off-by: Jiang Xin
---
builtin/clean.c | 117
1 file changed, 101 insertions(+), 16
Save some options in variable clean_flags, such as -ff (force > 1),
-x (ignored), -X (ignored_only), and -d (remove_directories). We may
change clean_flags later in the interactive git-clean.
Signed-off-by: Jiang Xin
---
builtin/clean.c | 46 +++---
1 file
Add a new action for interactive git-clean: ask each. It's just like
the "rm -i" command, that the user must confirm one by one for each
file or directory to be cleaned.
Signed-off-by: Jiang Xin
---
builtin/clean.c | 36
1 file changed, 36 insertions(+)
diff
Add a new action for interactive git-clean: filter by pattern. When
the user chooses this action, user can input space-separated
patterns (the same syntax as gitignore), and each clean candidate
that matches with one of the patterns will be excluded from cleaning.
When the user feels it's OK, press
Draw a multiple choice menu using `list_and_choose` to select items
to be deleted by numbers.
User can input:
* 1,5-7 : select 1,5,6,7 items to be deleted
* * : select all items to be deleted
* -*: unselect all, nothing will be deleted
*: (empty) finish selecting, and retur
Rewrite menu using a new method `list_and_choose`, which is borrowed
from `git-add--interactive.perl`. We will use this framework to add
new actions for interactive git-clean later.
Please NOTE:
* Method `list_and_choose` return an array of integers, and
* it is up to you to free the allocated
Show header, help, error messages, and prompt in colors for interactive
git-clean. Re-use config variables for other git commands, such as
git-add--interactive and git-stash:
* color.interactive: When set to always, always use colors for
interactive prompts and displays. When false (or never),
When there are lots of items to be cleaned, it is hard to see them all
in one screen. Show them in columns instead of in one column will solve
this problem.
Signed-off-by: Jiang Xin
Comments-by: Matthieu Moy
---
Documentation/config.txt | 4
builtin/clean.c | 49 +
Show what would be done and the user must confirm before actually
cleaning.
Would remove ...
Would remove ...
Would remove ...
Remove (y/n) ?
Press "y" to start cleaning, and press "n" if you want to abort.
Signed-off-by: Jiang Xin
---
Documentation/git-clean.txt | 10 ++--
Refactor git-clean operations into two phases:
* collect cleaning candidates in del_list,
* and remove them in a separate loop at the end.
We will introduce an interactive git-clean between the two phases.
The interactive git-clean will show what would be done and confirm
before do real cleanin
Updates since v7 series:
* Eliminate global variable "**the_prefix".
* Save relative paths in del_list.
* Split 1/10 of v7 into 3 patches for readability.
* Change orders of patches, thanks to Eric.
* Update menu and hotkeys with the help of Eric.
Usage:
When the command enters the interact
Jeff King writes:
> Since the point of marking the detached HEAD is to turn off things like
> "@{-1}@{u}", we would want to be generous and err on the side of
> assuming it is a branch if it _might_ be one.
I am not sure X and Y mesh well in your "Since X, we would want Y".
It seems to argue for
2013/5/9 Junio C Hamano :
>> @@ -15,9 +15,12 @@
>> #include "quote.h"
>>
>> static int force = -1; /* unset */
>> +static int interactive;
>> +static struct string_list del_list = STRING_LIST_INIT_DUP;
>> +static const char **the_prefix;
>
> Ehh, why?
Next reroll will save relative paths in del_
Counting of lines did not skip this line when generating the hunk
header.
Signed-off-by: Heiko Voigt
---
Here is an attempt at fixing the no newline issue. I would appreciate
another pair of eyes though.
git-gui/lib/diff.tcl | 11 +--
1 file changed, 9 insertions(+), 2 deletions(-)
dif
This can be used to read configuration values directly from gits
database. For example it is useful for reading to be checked out
.gitmodules files directly from the database.
Signed-off-by: Heiko Voigt
---
builtin/config.c | 31 +++---
cache.h| 6 +++-
config.
If a config parsing error in a file occurs we can die and let the user
fix the issue. This is different for the buf parsing function since it
can be used to parse blobs of .gitmodules files. If a parsing error
occurs here we should proceed since otherwise a database containing such
an error in a si
Hi,
I fixed all the issues I know of so this should be ready for master.
This is an update with the comments of the second iteration[1] incorporated.
[1] http://thread.gmane.org/gmane.comp.version-control.git/217811
Heiko Voigt (5):
config: factor out config file stack management
config: dr
To simplify adding other sources we extract all functions needed for
parsing into a list of callbacks. We implement those callbacks for the
current file parsing. A new source can implement its own set of callbacks.
Instead of storing the concrete FILE pointer for parsing we store a void
pointer. A
The global variable cf is set with an initialized value in all codepaths before
calling this function.
The complete call graph looks like this:
git_config_from_file
-> do_config_from
-> git_parse_file
-> get_next_char
-> get_value
-> get_next_char
Because a config callback may start parsing a new file, the
global context regarding the current config file is stored
as a stack. Currently we only need to manage that stack from
git_config_from_file. Let's factor it out to allow new
sources of config data.
Signed-off-by: Heiko Voigt
---
config
David Aguilar writes:
> Marked "RFC" because I am kinda against adding more configuration
> variables.
Just like "git merge" has -X escape hatch to allow us to
pass backend-specific options, perhaps you can add a mechanism to
"git mergetool" to let the user pass --no-auto from the command
line?
I am misusing git as a store-and-forward tool to transfer reports to a
server in a resilient manner.
The context is puppet (and ppg, I've spammed the list about it... ).
The reports are small, with small deltas, but created frequently.
With the exaction of the final destination, I want to expire
On Thu, May 09, 2013 at 02:13:30AM -0700, David Aguilar wrote:
> Mac OS X Mountain Lion prints warnings when building git:
>
> warning: 'SHA1_Init' is deprecated
> (declared at /usr/include/openssl/sha.h:121)
>
> Silence the warnings by disabling OpenSSH in favor of BLK_SHA1.
>
> Sig
Am 06.05.2013 22:16, schrieb Stephen Boyd:
Ok. I tested it and it definitely helps.
==10728== LEAK SUMMARY:
==10728==definitely lost: 316,355,458 bytes in 8,652 blocks
==10728==indirectly lost: 1,327,251,588 bytes in 16,180,628 blocks
==10728== possibly lost: 677,049,918 bytes in 7,
Am 09.05.2013 15:21, schrieb Jonathan Nieder:
Hi,
Sven Strickroth wrote:
With MSVC initializing a variable with "int a=a" causes a warning about
using an uninitialized value.
[...]
--- a/builtin/rev-list.c
+++ b/builtin/rev-list.c
@@ -338,7 +338,7 @@ int cmd_rev_list(int argc, const char **a
> -Original Message-
> From: David Goldfarb
> Sent: Wednesday, May 08, 2013 5:38 AM
>
> Here's one more data point. It suggests that the problem is due to
> either Cygwin or possibly Git 1.7.9.
>
>
> My Ubuntu box is actually a VM, hosted by my windows box in VMWare
> Player.
>
> So, I
Am 09.05.2013 15:21 schrieb Jonathan Nieder:
> Sven Strickroth wrote:
>
>> With MSVC initializing a variable with "int a=a" causes a warning about
>> using an uninitialized value.
> [...]
>> --- a/builtin/rev-list.c
>> +++ b/builtin/rev-list.c
>> @@ -338,7 +338,7 @@ int cmd_rev_list(int argc, cons
Add a test to verify the emptiness of an archive by extracting its
contents. Don't run this test if the version of tar doesn't support
archives containing only a comment header, though.
The existing check 'tar archive of empty tree is empty' used to work
like that (minus the tar capability check)
Hi,
Sven Strickroth wrote:
> With MSVC initializing a variable with "int a=a" causes a warning about
> using an uninitialized value.
[...]
> --- a/builtin/rev-list.c
> +++ b/builtin/rev-list.c
> @@ -338,7 +338,7 @@ int cmd_rev_list(int argc, const char **argv, const char
> *prefix)
>
Test 2 of t5004 checks if a supposedly empty tar archive really
contains no files. 24676f02 (t5004: fix issue with empty archive test
and bsdtar) removed our commit hash to make it work with bsdtar, but
the test still fails on NetBSD and OpenBSD, which use their own tar
that considers a tar file c
Versions of tar that don't know pax headers -- like the ones in NetBSD 6
and OpenBSD 5.2 -- extract them as regular files. Explicitly ignore the
file created for our global header when checking the list of extracted
files, as this is normal and harmless fall-back behaviour. This fixes
test 3 of t
On Thu, May 09, 2013 at 03:13:39AM +0200, Sven Strickroth wrote:
> With MSVC initializing a variable with "int a=a" causes a warning about
> using an uninitialized value.
>
> Signed-off-by: Sven Strickroth
> ---
> builtin/rev-list.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> di
On Thu, May 9, 2013 at 5:24 AM, Ramkumar Ramachandra wrote:
> Felipe Contreras wrote:
>> AFAIK neither the git or the Linux code-style specify how multiple
>> lines with open parenthesis should align.
>
> git style inherits from linux style. See Chapter 9 of
> Documentation/CodingStyle in linux.g
Felipe Contreras wrote:
> AFAIK neither the git or the Linux code-style specify how multiple
> lines with open parenthesis should align.
git style inherits from linux style. See Chapter 9 of
Documentation/CodingStyle in linux.git. It has elisp snippets you can
stick in your .emacs.
--
To unsubsc
On Thu, May 9, 2013 at 4:30 AM, John Szakmeister wrote:
> On Thu, May 9, 2013 at 4:50 AM, Felipe Contreras
> wrote:
>> On Thu, May 9, 2013 at 3:46 AM, John Szakmeister
>> wrote:
>>> On Wed, May 8, 2013 at 9:16 PM, Felipe Contreras
> [snip]
@@ -289,13 +289,13 @@ static void handle_commit(st
On Thu, May 9, 2013 at 4:50 AM, Felipe Contreras
wrote:
> On Thu, May 9, 2013 at 3:46 AM, John Szakmeister wrote:
>> On Wed, May 8, 2013 at 9:16 PM, Felipe Contreras
[snip]
>>> @@ -289,13 +289,13 @@ static void handle_commit(struct commit *commit,
>>> struct rev_info *rev)
>>> parse_comm
Mac OS X Mountain Lion prints warnings when building git:
warning: 'SHA1_Init' is deprecated
(declared at /usr/include/openssl/sha.h:121)
Silence the warnings by disabling OpenSSH in favor of BLK_SHA1.
Signed-off-by: David Aguilar
---
I know I can create config.mak, but do we pr
The `kdiff3 --auto` help message is, "No GUI if all conflicts are auto-
solvable." This flag was carried over from the original mergetool
commands. diff_cmd() is for two-way comparisons only so remove the
superfluous flag.
Signed-off-by: David Aguilar
---
This one is not RFC; just a trivial fix
By default, "git mergetool" passes the `--auto` flag to `kdiff3` when
merging a file. The `--auto` flag tells `kdiff3` to skip showing the
GUI and automatically save the merged result when it is able to
trivially resolve a merge.
Some users prefer to eyeball the merged result using mergetool and
On Thu, May 9, 2013 at 4:53 AM, Felipe Contreras
wrote:
[snip]
>>> @@ -562,9 +561,7 @@ static void handle_tags_and_duplicates(struct
>>> string_list *extra_refs)
>>> break;
>>> case OBJ_COMMIT:
>>> /* create refs pointing to already
On Thu, May 9, 2013 at 3:52 AM, John Szakmeister wrote:
> On Wed, May 8, 2013 at 9:16 PM, Felipe Contreras
> wrote:
>> Cast the object to a commit, only to get the object back?
>>
>> Signed-off-by: Felipe Contreras
>> ---
>> builtin/fast-export.c | 5 +
>> 1 file changed, 1 insertion(+), 4
On Wed, May 8, 2013 at 9:16 PM, Felipe Contreras
wrote:
> Cast the object to a commit, only to get the object back?
>
> Signed-off-by: Felipe Contreras
> ---
> builtin/fast-export.c | 5 +
> 1 file changed, 1 insertion(+), 4 deletions(-)
>
> diff --git a/builtin/fast-export.c b/builtin/fast-
1 - 100 of 103 matches
Mail list logo
