Duy Nguyen writes:
> I think this applies to general case as well, not just shallow.
> Imagine I have a disconnected commit that points to the latest tree
> (i.e. it contains most of latest changes). Because it's disconnected,
> it'll be ignored by the server side. But if the servide side does
>
On Wed, Aug 7, 2013 at 4:00 PM, Stefan Beller
wrote:
> ---
> builtin/pack-objects.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/builtin/pack-objects.c b/builtin/pack-objects.c
> index 1742ea1..0bd8f3b 100644
> --- a/builtin/pack-objects.c
> +++ b/builtin/pack-objects.
Duy Nguyen writes:
> Haven't found time to read the rest yet, but this I can answer.
> .git/shallow records graft points. If a commit is in .git/shallow and
> it exists in the repository, the commit is considered to have no
> parents regardless of what's recorded in repository. So .git/shallow
>
Stefan Beller writes:
> Well if we make sure the whatchanged command can easily be reproduced
> with the log command, we could add the missing parameters to it, hence
> no change for the user. (git whatchanged == git log --raw --no-merges or
> git log --wc [to be done yet]).
>
> So I did not mean
If the current branch has an upstream branch, and there are changes
between the current branch and its upstream, some commands (such as
"git status", "git status -bs", and "git checkout") will report their
relationship. E.g.
$ git status
# On branch master
# Your branch is ahead of 'or
On Fri, Jul 12, 2013 at 5:01 AM, Matthijs Kooijman wrote:
> Hi folks,
>
> while playing with shallow fetches, I've found that in some
> circumstances running git fetch with --depth can return too many objects
> (in particular, _all_ the objects for the requested revisions are
> returned, even when
Junio C Hamano wrote:
> The only thing it does is to scratch an irrelevant itch by people
> who peek the codebase and find an old command whose existence does
> not even hurt them. They may have too much time on their hand, but
> that is not an excuse to waste other people's time by adding extra
>
On Wed, Aug 7, 2013 at 9:00 PM, Stefan Beller
wrote:
> ---
> pack-write.c | 5 +
> 1 file changed, 5 insertions(+)
>
> diff --git a/pack-write.c b/pack-write.c
> index e6aa7e3..b728ea2 100644
> --- a/pack-write.c
> +++ b/pack-write.c
> @@ -344,6 +344,11 @@ struct sha1file *create_tmp_packfile
On Wed, Aug 7, 2013 at 10:48 PM, Junio C Hamano wrote:
> Matthieu Moy writes:
>
>> [ It's cool you're working on this, I'd really like a git-repack in C.
>> That would fix this
>> http://thread.gmane.org/gmane.comp.version-control.git/226458 ]
>>
>> Stefan Beller writes:
>>
>>> From: Nguyễn
On Wed, Aug 7, 2013 at 7:10 AM, Martin Fick wrote:
>> I wonder if a simpler approach may be nearly efficient as
>> this one: keep the largest pack out, repack the rest at
>> fetch/push time so there are at most 2 packs at a time.
>> Or we we could do the repack at 'gc --auto' time, but
>> with low
On Wed, Aug 7, 2013 at 3:23 PM, Thomas Gummerer wrote:
>> On Sat, Jul 13, 2013 at 12:26 AM, Thomas Gummerer
>> wrote:
>>> +static void ce_queue_push(struct cache_entry **head,
>>> +struct cache_entry **tail,
>>> +struct cache_entry *ce)
>>>
On Wed, Jul 17, 2013 at 3:11 PM, Thomas Gummerer wrote:
> Duy Nguyen writes:
>
> [..]
>
>>> +static int read_entries(struct index_state *istate, struct directory_entry
>>> **de,
>>> + unsigned int *entry_offset, void **mmap,
>>> + unsigned long mmap_si
On Thu, Aug 8, 2013 at 8:01 AM, Junio C Hamano wrote:
> Matthijs Kooijman writes:
>
>>> > In your discussion (including the comment), you talk about "shallow
>>> > root" (I think that is the same as what we call "shallow boundary"),
>>> I think so, yes. I mean to refer to the commits referenced i
Matthijs Kooijman writes:
>> > In your discussion (including the comment), you talk about "shallow
>> > root" (I think that is the same as what we call "shallow boundary"),
>> I think so, yes. I mean to refer to the commits referenced in
>> .git/shallow, that have their parents "hidden".
> Could
Although many functions in this file take a "struct transport" as a
parameter, "fetch_one()" assigns to the global singleton instance
which is a file-scope static, in order to allow a parameterless
signal handler unlock_pack() to access it.
Rename the variable to gtransport to make sure these uses
Usually the upload-pack process running on the other side will give
us all the reachable tags we need during the primary object transfer
in do_fetch(). If that does not happen (e.g. the other side may be
running a third-party implementation of upload-pack), we will run
another fetch to pick up lef
A Git-aware "connect" transport allows the "transport_take_over" to
redirect generic transport requests like fetch(), push_refs() and
get_refs_list() to the native Git transport handling methods. The
take-over process replaces transport->data with a fake data that
these method implementations unde
Make a helper function prepare_transport() that returns a transport
to talk to a given remote.
The set_option() helper that used to always affect the file-scope
global "gtransport" now takes a transport as its parameter.
Signed-off-by: Junio C Hamano
---
builtin/fetch.c | 46 +++
"git fetch" sometimes needs to make a real request to the transport
after a single "fetch_refs" request, in order to follow tags that
the other end should have sent as part of the primary transfer with
"follow-tags" request.
However, a transport that defines "connect" has a gross hack that
destroy
This is an attempt to reproduce a problem reported for a third-party
custom "connect" remote helper. The conjecture is that sometimes
"git fetch" wants to make two connections (one for the primary
transfer with 'follow-tags' option set, and then after noticing that
some tags are not packed because
Hello, I need some guide that can explain me the following:
I wish to know the correct rule to make work cloning over http with my
configuration, without taking all the web server to server only as
github
I setup gitweb to it can show in a directory
by example, localhost/gitweb or 192.168.1.20/
On 08/07/2013 07:50 PM, Junio C Hamano wrote:
> Stefan Beller writes:
>
>> I'd deprecate it first for a year or such and remove it then.
>> In the meantime we could implement already remove the code
>> and change it to:
>>
>> + int cmd_whatchanged(int argc, const char **argv, const char *prefix)
On Wed, Aug 7, 2013 at 6:43 AM, Johannes Sixt wrote:
> Am 8/7/2013 8:24, schrieb shawn wilson:> ... create a repo for one of
>> these scripts and I'd like to keep the commit history.
>>
>> Ok, so:
>> % find -type f ! -iname "webban.pl" | while read f; do git
>> filter-branch -f --index-filter "git
On Aug 7, 2013, at 11:31, John Keeping wrote:
On Wed, Aug 07, 2013 at 11:01:57AM -0700, Kyle J. McKay wrote:
On Aug 7, 2013, at 09:00, Ramkumar Ramachandra wrote:
Hi,
This is the difference between whatchanged and log:
diff --git a/whatchanged b/log
index fa1b223..004d9aa 100644
--- a/tmp/wha
On Wed, Aug 07, 2013 at 11:01:57AM -0700, Kyle J. McKay wrote:
> On Aug 7, 2013, at 09:00, Ramkumar Ramachandra wrote:
> > Hi,
> >
> > This is the difference between whatchanged and log:
> >
> > diff --git a/whatchanged b/log
> > index fa1b223..004d9aa 100644
> > --- a/tmp/whatchanged
> > +++ b/tmp
On Tue, Aug 06, 2013 at 02:11:56PM -0700, Junio C Hamano wrote:
> Thanks, will replace the top two commits and queue. Looks like we
> are getting ready for 'next'?
I'm a bit curious about if we should move towards a reentrent libgit
(which would for example make multithreading easier) or not.
If
On Aug 7, 2013, at 09:00, Ramkumar Ramachandra wrote:
Hi,
This is the difference between whatchanged and log:
diff --git a/whatchanged b/log
index fa1b223..004d9aa 100644
--- a/tmp/whatchanged
+++ b/tmp/log
@@ -1,4 +1,4 @@
-int cmd_whatchanged(int argc, const char **argv, const char *prefix)
+i
Stefan Beller writes:
> I'd deprecate it first for a year or such and remove it then.
> In the meantime we could implement already remove the code
> and change it to:
>
> + int cmd_whatchanged(int argc, const char **argv, const char *prefix)
> + {
> + return cmd_log(argc, argv, prefix)
> + }
Am 06.08.2013 23:11, schrieb Junio C Hamano:
> Thanks, will replace the top two commits and queue. Looks like we
> are getting ready for 'next'?
I hope so, I'm not aware of any open issues.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vge
On 08/07/2013 06:00 PM, Ramkumar Ramachandra wrote:
> Hi,
>
> This is the difference between whatchanged and log:
>
> diff --git a/whatchanged b/log
> index fa1b223..004d9aa 100644
> --- a/tmp/whatchanged
> +++ b/tmp/log
> @@ -1,4 +1,4 @@
> -int cmd_whatchanged(int argc, const char **argv, const
On 08/07/2013 05:48 PM, Junio C Hamano wrote:
> Matthieu Moy writes:
>>
>> seems overkill to me: why don't you just let cmd_repack call
>> update_server_info(0)?
>
> My feeling exactly. I would rather see a patch that does not touch
> pack-objects at all, and use run_command() interface to spawn
2013/8/7 Matthieu Moy :
> Jiang Xin writes:
>
>> With this patch, "git status" will report relationship between current
>> branch and its upstream counterpart even if there is no difference.
>>
>> $ git status
>> # On branch master
>> # Your branch is identical to its tracking branch:
Hi,
This is the difference between whatchanged and log:
diff --git a/whatchanged b/log
index fa1b223..004d9aa 100644
--- a/tmp/whatchanged
+++ b/tmp/log
@@ -1,4 +1,4 @@
-int cmd_whatchanged(int argc, const char **argv, const char *prefix)
+int cmd_log(int argc, const char **argv, const char *pref
Problem:
"git log --follow filename" is not working for files after a big move.
Scenario:
Just performed a "git subtree add" where big projects were moved into
another repository, and I'm not able to view history for a single
file.
Sample output:
Output after subtree add (no output)
> git log
Jiang Xin writes:
> With this patch, "git status" will report relationship between current
> branch and its upstream counterpart even if there is no difference.
>
> $ git status
> # On branch master
> # Your branch is identical to its tracking branch: 'origin/master'.
Why not, but we
Matthieu Moy writes:
> [ It's cool you're working on this, I'd really like a git-repack in C.
> That would fix this
> http://thread.gmane.org/gmane.comp.version-control.git/226458 ]
>
> Stefan Beller writes:
>
>> From: Nguyễn Thái Ngọc Duy
>>
>> pack-objects learns a few more options to tak
If the current branch has an upstream branch, and there are differences
between the current branch and its upstream, some commands (such as
"git status", "git status -bs", and "git checkout") will report their
relationship. E.g.
$ git status
# On branch master
# Your branch is ahead of
Stefan Beller writes:
> On 08/07/2013 01:31 AM, Junio C Hamano wrote:
>> The parseopt parsing for OPT__FORCE() is implemented in terms of
>> OPT_BOOLEAN() and users of it can take advantage of the "counting
>> up" behaviour to implement increasing levels of forcefulness by
>> differentiating "git
[ It's cool you're working on this, I'd really like a git-repack in C.
That would fix this
http://thread.gmane.org/gmane.comp.version-control.git/226458 ]
Stefan Beller writes:
> From: Nguyễn Thái Ngọc Duy
>
> pack-objects learns a few more options to take over what's been done
> by git-rep
Hi Duy,
I applied your patch on the current master and added 3 patches,
so git compiles and the testsuite works without additional breakages.
The functionality is obviously not yet completed as the backup_file
function is still empty. What do you intend that function will do?
Stefan
Nguyễn Thá
From: Nguyễn Thái Ngọc Duy
pack-objects learns a few more options to take over what's been done
by git-repack.sh. cmd_repack() becomes a wrapper around
cmd_pack_objects().
---
Makefile | 2 +-
builtin.h | 1 +
builtin/pack-objects.c | 279 ++
---
builtin/pack-objects.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/builtin/pack-objects.c b/builtin/pack-objects.c
index 1742ea1..0bd8f3b 100644
--- a/builtin/pack-objects.c
+++ b/builtin/pack-objects.c
@@ -2585,7 +2585,7 @@ int cmd_pack_objects(int argc, const char **a
---
builtin/pack-objects.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/builtin/pack-objects.c b/builtin/pack-objects.c
index 0bd8f3b..0fe01fc 100644
--- a/builtin/pack-objects.c
+++ b/builtin/pack-objects.c
@@ -2795,6 +2795,9 @@ int cmd_repack(int argc, const char **argv, const char
*p
---
pack-write.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/pack-write.c b/pack-write.c
index e6aa7e3..b728ea2 100644
--- a/pack-write.c
+++ b/pack-write.c
@@ -344,6 +344,11 @@ struct sha1file *create_tmp_packfile(char **pack_tmp_name)
return sha1fd(fd, *pack_tmp_name);
}
# I am sorry. I forget title and signiture.
-
Hello.
I find 2 bug about Japanese' Documentation .
There are Documentation -> Book 's url. ( Please see the details below).
I want to bug-fix about this misspell.
Do you have Documentation (about Japanese language) on the GitHub?
Hello.
I find 2 bug about Japanese' Documentation .
There are Documentation -> Book 's url. ( Please see the details below).
I want to bug-fix about this misspell.
Do you have Documentation (about Japanese language) on the GitHub?
(1)
http://git-scm.com/book/ja/Git-%E3%81%AE%E5%9F%BA%E6%9C%AC-
On 07/29/2013 08:02 PM, Daniele Segato wrote:
On 07/26/2013 09:36 PM, Jonathan Nieder wrote:
Eventually the description section should probably be tweaked to start
by explaining what the command is actually for. ;-)
Elaborating from this suggestion you gave me I tried to
rewrite/rearrange the
Am 8/7/2013 8:24, schrieb shawn wilson:> ... create a repo for one of
> these scripts and I'd like to keep the commit history.
>
> Ok, so:
> % find -type f ! -iname "webban.pl" | while read f; do git
> filter-branch -f --index-filter "git rm --cached --ignore-unmatch $f"
> HEAD ; done
>
> Which bas
Hi Junio,
I haven't got a reply to my mail yet. Could you have a look, so I can
update and resubmit my patch?
On Fri, Jul 12, 2013 at 09:11:57AM +0200, Matthijs Kooijman wrote:
> > [administrivia: you seem to have mail-followup-to that points at you
> > and the list; is that really needed???]
> >
Matthieu Moy writes:
> Thomas Rast writes:
>
>>> + grep -v " " error
>>
>> Umm, doesn't that only test that _some_ line in the error does not
>> contain a tab?
>
> Indeed. It does work as the error message is just a one-liner, but let's
> be robust anyway.
Err, right. I actually applie
Some implementations of 'echo' (e.g. dash's built-in) interpret
backslash sequences in their arguments.
This triggered at least one bug: the error message of "rebase -i" was
turning \t in commit messages into actual tabulations. There may be
others.
Using "printf '%s\n'" instead avoids this bad b
Thomas Rast writes:
>> +grep -v " " error
>
> Umm, doesn't that only test that _some_ line in the error does not
> contain a tab?
Indeed. It does work as the error message is just a one-liner, but let's
be robust anyway.
> Whereas you need to test that _no_ line contains emp, or some
On Wed, Aug 07, 2013 at 11:17:08AM +0200, Thomas Rast wrote:
> This results from Peff's c17592a (commit: tweak empty cherry pick advice
> for sequencer, 2013-07-26):
>
> diff --git a/builtin/commit.c b/builtin/commit.c
> index a17a5df..39717d5 100644
> --- a/builtin/commit.c
> +++ b/built
Ralf Thielow writes:
>
The changes look good to me. The following is purely about the original
English messages.
> #: builtin/commit.c:62
> -#, fuzzy
> msgid ""
> "The previous cherry-pick is now empty, possibly due to conflict
> resolution.\n"
> "If you wish to commit it anyway, use:\n"
Matthieu Moy writes:
> At least GNU echo interprets backslashes in its arguments.
>
> This triggered at least one bug: the error message of "rebase -i" was
> turning \t in commit messages into actual tabulations. There may be
> others.
>
> Using "printf '%s\n'" instead avoids this bad behavior, a
Christian Couder writes:
> Users replacing an object with one of a different type were not
> prevented to do so, even if it was obvious, and stated in the doc,
> that bad things would result from doing that.
>
> To avoid mistakes, it is better to just forbid that though.
>
> The doc will be updat
Duy Nguyen writes:
> A little bit more..
>
> On Sat, Jul 13, 2013 at 12:26 AM, Thomas Gummerer
> wrote:
>> +static void ce_queue_push(struct cache_entry **head,
>> +struct cache_entry **tail,
>> +struct cache_entry *ce)
>> +{
>> + if
Duy Nguyen writes:
> On Sat, Jul 13, 2013 at 12:26 AM, Thomas Gummerer
> wrote:
>> +struct directory_entry {
>> + struct directory_entry *next;
>> + struct directory_entry *next_hash;
>> + struct cache_entry *ce;
>> + struct cache_entry *ce_last;
>> + struct confli
On 08/07/2013 01:31 AM, Junio C Hamano wrote:
> The parseopt parsing for OPT__FORCE() is implemented in terms of
> OPT_BOOLEAN() and users of it can take advantage of the "counting
> up" behaviour to implement increasing levels of forcefulness by
> differentiating "git cmd -f" and "git cmd -f -f".
59 matches
Mail list logo
