headers
jidanni | 1 Jan 2009 03:54
Favicon
Gravatar

Re: shallow clone, shallow fetch?

Last week I did git-clone --depth 1 This week I wanted to freshen my
repository, with the same goal: "I don't care about history, just
fast forward me with the least bytes transfered." But all I can find
is just plain git pull. Did I achieve my goal?
$ git pull
remote: Counting objects: 7007, done.
remote: Compressing objects: 100% (3057/3057), done.
remote: Total 7007 (delta 4280), reused 6076 (delta 3625)
Receiving objects: 100% (7007/7007), 2.96 MiB | 26 KiB/s, done.
Resolving deltas: 100% (4280/4280), done.
From git://git.kernel.org/pub/scm/git/git
   2fa431b..bbbb865  html       -> origin/html
   a9012e3..936b705  maint      -> origin/maint
   dfd79c7..794d84e  man        -> origin/man
   159c88e..c32f76f  master     -> origin/master
   3b9b952..6f67462  next       -> origin/next
 + b14a7fb...89bdc19 pu         -> origin/pu  (forced update)
Merge made by recursive.
 Documentation/Makefile             |    9 +++++----
 Documentation/RelNotes-1.6.1.1.txt |   23 +++++++++++++++++++++++
 Documentation/cat-texi.perl        |    8 ++++++--
 Documentation/git-reset.txt        |   29 ++++++++++++++++++++++++++++-
 builtin-pack-objects.c             |    9 ++++++++-
 builtin-reset.c                    |   26 ++++++++++++++++++--------
 gitweb/gitweb.perl                 |    5 +++--
 t/t5302-pack-index.sh              |    1 +
 8 files changed, 92 insertions(+), 18 deletions(-)
 create mode 100644 Documentation/RelNotes-1.6.1.1.txt
Permalink | Reply | 1 comment |
headers
Anatol Pomozov | 1 Jan 2009 03:50
Picon
Gravatar

Re: why still no empty directory support in git

Hi

On Mon, Dec 29, 2008 at 10:09 PM, Liu Yubao <yubao.liu <at> gmail.com> wrote:
>
> Ping Yin wrote:
> > Yes, i know this topic has been discussed for many times. However, i
> > am still not clear about the real reason.
> >
> > So which is the reason?
> >
> > 1. it's by design, intentional
> It's saied somewhere git is a "stupid content tracker", it cares file content
> not file name, and empty directories will complicate the merge algorithm
> unnecessarily.

Could you please explain how will it complicate merging. What is the
difference between merging 2 directories with 0 and 5 files and
merging 2 directories with 5 and 10 files?

+1 that git should respect empty directories. Git should handle file
content and not decide for user does he want to keep empty directory
in the source tree or not.

--
anatol
Permalink | Reply | 0 comments |
headers
jidanni | 1 Jan 2009 05:24
Favicon
Gravatar

[PATCH] Documentation/git-bundle.txt: Dumping contents of any bundle

>>>>> "JK" == Jeff King <peff <at> peff.net> writes:

JK> AFAIK, there is no tool to try salvaging strings from an incomplete pack
JK> (and you can't just run "strings" because the deltas are zlib
JK> compressed). So if I were in the police forensics department, I think I
JK> would read Documentation/technical/pack-format.txt and start hacking a
JK> solution as quickly as possible.

Hogwash. Patch follows. Maybe even better methods are available.

Signed-off-by: jidanni <jidanni <at> jidanni.org>
---
 Documentation/git-bundle.txt |   22 ++++++++++++++++++++++
 1 files changed, 22 insertions(+), 0 deletions(-)

diff --git a/Documentation/git-bundle.txt b/Documentation/git-bundle.txt
index 1b66ab7..80248f5 100644
--- a/Documentation/git-bundle.txt
+++ b/Documentation/git-bundle.txt
 <at>  <at>  -164,6 +164,28  <at>  <at>  $ git pull bundle
 would treat it as if it is talking with a remote side over the
 network.

+DUMPING CONTENTS OF ANY BUNDLE
+-----------------------
+
+Even if we cannot unbundle a bundle,
+
+------------
+$ git init
(Continue reading)

Permalink | Reply | 11 comments |
headers
jidanni | 1 Jan 2009 05:39
Favicon
Gravatar

[PATCH] Documentation/gitcli.txt: dashed forms not allowed anymore

Non dashed command forms now mandatory.

Signed-off-by: jidanni <jidanni <at> jidanni.org>
---
 Documentation/gitcli.txt |    4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/Documentation/gitcli.txt b/Documentation/gitcli.txt
index 29e5929..9f582f6 100644
--- a/Documentation/gitcli.txt
+++ b/Documentation/gitcli.txt
 <at>  <at>  -45,8 +45,8  <at>  <at>  disambiguating `\--` at appropriate places.
 Here are the rules regarding the "flags" that you should follow when you are
 scripting git:

- * it's preferred to use the non dashed form of git commands, which means that
-   you should prefer `"git foo"` to `"git-foo"`.
+ * it's required to use the non dashed form of git commands, which means that
+   you must use `"git foo"` and not `"git-foo"`. The latter no longer works.

  * splitting short options to separate words (prefer `"git foo -a -b"`
    to `"git foo -ab"`, the latter may not even work).
--

-- 
1.6.0.6
Permalink | Reply | 2 comments |
headers
Ping Yin | 1 Jan 2009 08:38
Picon

Re: git-difftool

On Thu, Jan 1, 2009 at 12:04 AM, Matthieu Moy <Matthieu.Moy <at> imag.fr> wrote:
> David Aguilar <davvid <at> gmail.com> writes:
>
>> The usual use case for this script is when you have either
>> staged or unstaged changes and you'd like to see the changes
>> in a side-by-side diff viewer (e.g. xxdiff, tkdiff, etc).
>>
>>       git difftool [<filename>*]
>
> Is it not a complex way of saying
>
>        GIT_EXTERNAL_DIFF=xxdiff git diff

$ cat mydiff
#!/bin/bash
exec vimdiff $2 $5

then i run

$ GIT_EXTERNAL_DIFF=mydiff  git diff

but it gives me the error
Vim: Warning: Output is not to a terminal

$ ps -ef | grep vimdiff
ping     20284 20283  1 15:37 pts/13   00:00:00 vimdiff
/tmp/.diff_XXXQK6 index.php
Permalink | Reply | 5 comments |
headers
Caleb Cushing | 1 Jan 2009 09:48
Picon
Gravatar

Re: git has modified files after clean checkout

>  The files you mention contain CRLF.  Do you have core.autocrlf set
>  globally somewhere, perhaps in your ~/.gitconfig?

yes I have it set to input

>  Anyways.. like I said -- I couldn't reproduce your problem so this is
>  pure speculation on my part =)

it's inconsistent although I see something more often than not, and
only with this particular repository. Sometimes it's one set of files
other times it's others. this time it was 2 sometimes it's more like
40 (just throwing numbers around) and that can be the same unchanged
clone. seem to happen on checkout. heck even noticed a git reset
--hard HEAD didn't clear it all the first time today, in one case.

after sleep I'll see if 1.6.1 fixes my issue.

--

-- 
Caleb Cushing

http://xenoterracide.blogspot.com
Permalink | Reply | 3 comments |
headers
Sitaram Chamarty | 1 Jan 2009 10:25
Picon

Re: shallow clone, shallow fetch?

On 2009-01-01, jidanni <at> jidanni.org <jidanni <at> jidanni.org> wrote:
> Last week I did git-clone --depth 1 This week I wanted to freshen my
> repository, with the same goal: "I don't care about history, just
> fast forward me with the least bytes transfered." But all I can find
> is just plain git pull. Did I achieve my goal?
> $ git pull
> remote: Counting objects: 7007, done.
> remote: Compressing objects: 100% (3057/3057), done.
> remote: Total 7007 (delta 4280), reused 6076 (delta 3625)
> Receiving objects: 100% (7007/7007), 2.96 MiB | 26 KiB/s, done.
> Resolving deltas: 100% (4280/4280), done.
> From git://git.kernel.org/pub/scm/git/git
>    2fa431b..bbbb865  html       -> origin/html
>    a9012e3..936b705  maint      -> origin/maint
>    dfd79c7..794d84e  man        -> origin/man
>    159c88e..c32f76f  master     -> origin/master
>    3b9b952..6f67462  next       -> origin/next
>  + b14a7fb...89bdc19 pu         -> origin/pu  (forced update)

The hashes certainly agree with what I have (just did a pull
this minute), except I also have a new branch called
"origin/todo" at SHA1=6670008 which you seem to be missing.

I'm not familiar enough with shallow clones to draw any
conclusions though :-(
Permalink | Reply | 0 comments |
headers
Junio C Hamano | 1 Jan 2009 14:00
Picon
Picon
Favicon
Gravatar

Re: [RFC PATCH] builtin-apply: prevent non-explicit permission changes

Alexander Potashev <aspotashev <at> gmail.com> writes:

>  builtin-apply.c |    3 ++-
>  1 files changed, 2 insertions(+), 1 deletions(-)
>
> diff --git a/builtin-apply.c b/builtin-apply.c
> index 07244b0..071f6d8 100644
> --- a/builtin-apply.c
> +++ b/builtin-apply.c
>  <at>  <at>  -630,7 +630,7  <at>  <at>  static int gitdiff_index(const char *line, struct patch *patch)
>  	memcpy(patch->new_sha1_prefix, line, len);
>  	patch->new_sha1_prefix[len] = 0;
>  	if (*ptr == ' ')
> -		patch->new_mode = patch->old_mode = strtoul(ptr+1, NULL, 8);
> +		patch->old_mode = strtoul(ptr+1, NULL, 8);
>  	return 0;
>  }
>  
>  <at>  <at>  -2447,6 +2447,7  <at>  <at>  static int check_preimage(struct patch *patch, struct cache_entry **ce, struct s
>  	if (st_mode != patch->old_mode)
>  		fprintf(stderr, "warning: %s has type %o, expected %o\n",
>  			old_name, st_mode, patch->old_mode);
> +	patch->new_mode = st_mode;

Can you do this unconditionally, overwriting whatever we read from the
patch header metainfo lines?
Permalink | Reply | 3 comments |
headers
Miklos Vajna | 1 Jan 2009 15:40
Picon
Gravatar

Re: [PATCH] Documentation/gitcli.txt: dashed forms not allowed anymore

On Thu, Jan 01, 2009 at 12:39:39PM +0800, jidanni <at> jidanni.org wrote:
> - * it's preferred to use the non dashed form of git commands, which means that
> -   you should prefer `"git foo"` to `"git-foo"`.
> + * it's required to use the non dashed form of git commands, which means that
> +   you must use `"git foo"` and not `"git-foo"`. The latter no longer works.

I would append: "unless you add the output of `git --exec-path` to your
PATH."
Permalink | Reply | 1 comment |
headers
Johannes Schindelin | 1 Jan 2009 17:38
Picon
Picon

[PATCH 0/3] Teach Git about the patience diff algorithm


Nothing fancy, really, just a straight-forward implementation of the
heavily under-documented and under-analyzed paience diff algorithm.

One thing is a bit ugly: the libxdiff interface does not allow to
calculate diffs of ranges of lines.  So instead of reusing an initialized
environment (with line hashes and all), the simple structure of mmfile_t
is exploited to fake an mmfile_t of a file _part_, reusing the file's
buffer.

And this mmfile_t pair gets a new environment, recalculating hashes and 
all.

Davide, I think it would be easier to refactor xdl_do_diff() to take line
ranges, and use that interface both in xpatience.c and in xmerge.c.  
(Although I do not know if you took xmerge.c at all; you seemed a bit 
reluctant about it back when I sent it to you.)

For those interested in studying the code, I suggest starting with the 
short comment at the beginning of xpatience.c and then working yourself up 
from the end (i.e. xdl_do_patience_diff()).

It might be a good idea to think about using this code in our merging code
once it is well reviewed and tested, as it might help a substantial number
of otherwise non-trivial merge conflicts.

Oh, and the bash completions are so trivial I did not even bother to test
them.

Happy new year.
(Continue reading)

Permalink | Reply | 48 comments |

Gmane