Skip to content

G
git

李少辉-开发者 / git
与 Fork 源项目一致

从无法访问的项目Fork

通知 2
Star 1
Fork 0
G
git

体验新版 GitCode，发现更多精彩内容 >>

切换分支/标签
  1. 16 9月, 2006 1 次提交
  3. 10 9月, 2006 2 次提交
    • F
      Add git-upload-archive · 39345a21
      由 Franck Bui-Huu 提交于 
      This command implements the git archive protocol on the server
side. This command is not intended to be used by the end user.
Underlying git-archive command line options are sent over the
protocol from "git-archive --remote=...", just like upload-tar
currently does with "git-tar-tree=...".

As for "git-archive" command implementation, this new command
does not execute any existing "git-{tar,zip}-tree" but rely
on the archive API defined by "git-archive" patch. Hence we
get 2 good points:

 - "git-archive" and "git-upload-archive" share all option
   parsing code.

 - All kind of git-upload-{tar,zip} can be deprecated.
Signed-off-by: NFranck Bui-Huu <vagabon.xyz@gmail.com>
Signed-off-by: NJunio C Hamano <junkio@cox.net>
      39345a21
    • F
      Add git-archive · 4df096a5
      由 Franck Bui-Huu 提交于 
      git-archive is a command to make TAR and ZIP archives of a git tree.
It helps prevent a proliferation of git-{format}-tree commands.

Instead of directly calling git-{tar,zip}-tree command, it defines
a very simple API, that archiver should implement and register in
"git-archive.c". This API is made up by 2 functions whose prototype
is defined in "archive.h" file.

 - The first one is used to parse 'extra' parameters which have
   signification only for the specific archiver. That would allow
   different archive backends to have different kind of options.

 - The second one is used to ask to an archive backend to build
   the archive given some already resolved parameters.

The main reason for making this API is to avoid using
git-{tar,zip}-tree commands, hence making them useless. Maybe it's
time for them to die ?

It also implements remote operations by defining a very simple
protocol: it first sends the name of the specific uploader followed
the repository name (git-upload-tar git://example.org/repo.git).
Then it sends options. It's done by sending a sequence of one
argument per packet, with prefix "argument ", followed by a flush.

The remote protocol is implemented in "git-archive.c" for client
side and is triggered by "--remote=<repo>" option. For example,
to fetch a TAR archive in a remote repo, you can issue:

$ git archive --format=tar --remote=git://xxx/yyy/zzz.git HEAD

We choose to not make a new command "git-fetch-archive" for example,
avoind one more GIT command which should be nice for users (less
commands to remember, keeps existing --remote option).
Signed-off-by: NFranck Bui-Huu <vagabon.xyz@gmail.com>
Acked-by: NRene Scharfe <rene.scharfe@lsrfire.ath.cx>
Signed-off-by: NJunio C Hamano <junkio@cox.net>
      4df096a5
  5. 09 9月, 2006 1 次提交
  7. 27 8月, 2006 1 次提交
    • R
      Add git-zip-tree · e4fbbfe9
      由 Rene Scharfe 提交于 
      In the Windows world ZIP files are better supported than tar files.
Windows even includes built-in support for ZIP files nowadays.

git-zip-tree is similar to git-tar-tree; it creates ZIP files out of
git trees.  It stores the commit ID (if available) in a ZIP file comment
which can be extracted by unzip.

There's still quite some room for improvement: this initial version
supports no symlinks, calls write() way too often (three times per file)
and there is no unit test.

[jc: with a minor typefix to avoid void* arithmetic]
Signed-off-by: NRene Scharfe <rene.scharfe@lsrfire.ath.cx>
Signed-off-by: NJunio C Hamano <junkio@cox.net>
      e4fbbfe9
  9. 11 8月, 2006 1 次提交
  11. 04 8月, 2006 6 次提交
  13. 03 8月, 2006 2 次提交
  15. 02 8月, 2006 2 次提交
  17. 29 7月, 2006 1 次提交
  19. 27 7月, 2006 1 次提交
  21. 09 7月, 2006 1 次提交
    • L
      builtin "git prune" · ba84a797
      由 Linus Torvalds 提交于 
      This actually removes the objects to be pruned, unless you specify "-n"
(at which point it will just tell you which files it would prune).

This doesn't do the pack-file pruning that the shell-script used to do,
but if somebody really wants to, they could add it easily enough. I wonder
how useful it is, though, considering that "git repack -a -d" is just a
lot more efficient and generates a better end result.
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
Signed-off-by: NJunio C Hamano <junkio@cox.net>
      ba84a797
  23. 04 7月, 2006 1 次提交
  25. 19 6月, 2006 6 次提交
  27. 11 6月, 2006 1 次提交
  29. 04 6月, 2006 1 次提交
  31. 25 5月, 2006 1 次提交
  33. 24 5月, 2006 8 次提交
  35. 20 5月, 2006 3 次提交
    • J
      built-in tar-tree and remote tar-tree · 21754264
      由 Junio C Hamano 提交于 
      This makes tar-tree a built-in.  As an added bonus, you can now
say:

	git tar-tree --remote=remote-repository <ent> [<base>]

This does not work with git-daemon yet, but should work with
localhost and git over ssh transports.
Signed-off-by: NJunio C Hamano <junkio@cox.net>
      21754264
    • L
      Add builtin "git rm" command · d9b814cc
      由 Linus Torvalds 提交于 
      This changes semantics very subtly, because it adds a new atomicity
guarantee.

In particular, if you "git rm" several files, it will now do all or
nothing. The old shell-script really looped over the removed files one by
one, and would basically randomly fail in the middle if "-f" was used and
one of the files didn't exist in the working directory.

This C builtin one will not re-write the index after each remove, but
instead remove all files at once. However, that means that if "-f" is used
(to also force removal of the file from the working directory), and some
files have already been removed from the workspace, it won't stop in the
middle in some half-way state like the old one did.

So what happens is that if the _first_ file fails to be removed with "-f",
we abort the whole "git rm". But once we've started removing, we don't
leave anything half done. If some of the other files don't exist, we'll
just ignore errors of removal from the working tree.

This is only an issue with "-f", of course.

I think the new behaviour is strictly an improvement, but perhaps more
importantly, it is _different_. As a special case, the semantics are
identical for the single-file case (which is the only one our test-suite
seems to test).

The other question is what to do with leading directories. The old "git
rm" script didn't do anything, which is somewhat inconsistent. This one
will actually clean up directories that have become empty as a result of
removing the last file, but maybe we want to have a flag to decide the
behaviour?
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
Signed-off-by: NJunio C Hamano <junkio@cox.net>
      d9b814cc
    • T
      Builtin git-init-db · c3c8835f
      由 Timo Hirvonen 提交于 
      Basically this just renames init-db.c to builtin-init-db.c and makes
some strings const.
Signed-off-by: NTimo Hirvonen <tihirvon@gmail.com>
Signed-off-by: NJunio C Hamano <junkio@cox.net>
      c3c8835f