* Re: [PATCH 03/14] Define SNPRINTF_SIZE_CORR=1 for Microsoft Visual C++
From: Junio C Hamano @ 2009-08-21 22:11 UTC (permalink / raw)
To: Johannes Sixt
Cc: Marius Storm-Olsen, Johannes.Schindelin, msysgit, git, lznuaa
In-Reply-To: <200908212341.37531.j6t@kdbg.org>
Johannes Sixt <j6t@kdbg.org> writes:
> Not quite. The parameter *is* the size of the buffer and vsnprintf does not
> write beyond the buffer. However, it has the awkward behavior that if the
> buffer is too short by exactly one byte...
Thanks; I was fooled by the leading comment. How about ...
compat/snprintf.c | 3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/compat/snprintf.c b/compat/snprintf.c
index 6c0fb05..4d07087 100644
--- a/compat/snprintf.c
+++ b/compat/snprintf.c
@@ -3,7 +3,8 @@
/*
* The size parameter specifies the available space, i.e. includes
* the trailing NUL byte; but Windows's vsnprintf expects the
- * number of characters to write without the trailing NUL.
+ * number of characters to write, and does not necessarily write the
+ * trailing NUL.
*/
#ifndef SNPRINTF_SIZE_CORR
#if defined(__MINGW32__) && defined(__GNUC__) && __GNUC__ < 4
^ permalink raw reply related
* Re: [PATCH 0/6 RFC] Series to correct xutils incomplete line handling.
From: Alex Riesen @ 2009-08-21 22:16 UTC (permalink / raw)
To: Thell Fowler; +Cc: Johannes Schindelin, git
In-Reply-To: <alpine.DEB.2.00.0908211228000.2012@GWPortableVCS>
On Fri, Aug 21, 2009 at 19:39, Thell Fowler<git@tbfowler.name> wrote:
> What is _REALLY_ odd is that it didn't make any tests fail in the test
> dir using master, next, and pu.
The test suite has a very good coverage, but it surely is not complete.
> Perhaps someone can explain what I did wrong when testing?
>
> git checkout master
> make -s clean && make -s all && make -s install && cd t && make
This should have worked. Although I prefer just:
$ make -j4 && make test -j16
^ permalink raw reply
* [ANNOUNCE] Stacked Git 0.15-rc2
From: Catalin Marinas @ 2009-08-21 22:25 UTC (permalink / raw)
To: Git Mailing List; +Cc: Karl Wiberg
The second release candidate for StGit 0.15 is available from the
git://repo.or.cz/stgit.git or http://download.gna.org/stgit/. Bugs can
be reported on the Git mailing list or via the project bugs page
(https://gna.org/bugs/?group=stgit).
StGit is a Python application providing similar functionality to Quilt
(i.e. pushing/popping patches to/from a stack) on top of Git. These
operations are performed using Git commands and the patches are stored
as Git commit objects, allowing easy merging of the StGit patches into
other repositories using standard Git functionality.
The main changes since release 0.15-rc1 (I may miss some important
features but they can be found in the log):
- Several Emacs mode improvements
- Two new commands: prev and next
- Bug-fixes
Acknowledgements:
Gustav Hållberg (62):
stgit.el: Correct documentation for stgit-insert-patch-files
stgit.el: Remove unused variable stgit-work-ewoc
stgit.el: Refactor: remove unused argument to two functions
stgit.el: Run "git rm" with "-q" to reduce spam
stgit.el: Bugfix moving symlinks to/from index
stgit.el: Make stgit-{index,worktree}-node buffer local
stgit new: Do not open editor if --save-template was specified
stgit.el: Add stgit-branch-name-face
stgit.el: Move stgit-{un,}commit to \C-c\C-{u,c}
stgit.el: Add "U" for stgit-revert-file
stgit.el: Change key binding for stgit-repair from "R" to "\C-u g"
stgit.el: Add "R" for stgit-resolve-file
stgit.el: Refresh from work tree when index is empty
stgit.el: Refactor: add stgit-find-copies-harder-diff-arg helper function
stgit.el: Allow showing patch on Index and Work tree
stgit.el: Open the destination file on applied renames or copies
stgit.el: Forbid stgit-{delete,edit,mark,rename} on index and work tree
stgit.el: Add customizable face for "Index" and "Work tree" titles
stgit.el: Make it configurable where to show index and work tree
stgit.el: Default to expanding index and work tree
stgit.el: Garbage collect selected patches on reload
stgit.el: Document stgit-select properly
stgit.el: Allow operating on the end of each line
stgit.el: Refactor: simplify temporary marker handling
stgit.el: Fix face "spilling" in some places
stgit.el: Refactor: simplify stgit-patch-pp a bit
stgit.el: Add "t i/u" for showing files ignored by or unknown to git
stgit.el: Move point properly after stgit-{file-toggle-index,reload}
stgit.el: Handle negative argument to stgit-{un,}commit
stgit.el: Rename stgit-expand-find-copies-harder to
stgit-find-copies-harder
stgit.el: Handle unmerged files better
stgit.el: Add "d" for a few diff commands, similar to git.el
stgit.el: Ignore space in diff with prefix argument
stgit.el: Set patch names to be word syntax throughout
stgit.el: Add stgit-redo as C-c C-_ and C-c C-/
stgit.el: Verify that we're running on Emacs 22 or later
stgit.el: Default to showing index and work tree
stgit.el: Bugfix listing copied/renamed files
stgit.el: Abbreviate renames/copies with common prefix/suffix
stgit.el: Move point correctly after stgit-revert-file
stgit.el: Move point in sane way after stgit-file-toggle-index on renames
stgit.el: Allow moving ignored files to index
stgit.el: Minor documentation corrections
stgit.el: Bugfix mode change display
stgit.el: Add better help text for stgit-mode
stgit.el: Add C-c C-b for stgit-rebase
stgit.el: Improve use of def{group,custom,face}
stgit.el: Bugfix of stgit-move-patches to top of stack
stgit.el: Fix problem where standard-output isn't bound correctly
stgit.el: Bugfix "P" when point is not on a patch line
stgit.el: Fix some incorrect indentation
stgit.el: Add +/- to expand/collapse selected patches
stgit.el: Allow revert on index and work tree
stgit.el: Allow toggle-index on index and work tree
stgit.el: Verify we're in stgit-mode before running commands
stgit.el: Add stgit-toggle-mark
stgit.el: Add menu bar menu
stgit.el: Add flags to stgit-patches-marked-or-at-point
stgit.el: Consistently use "marked" about marked patches
stgit.el: Make sure "M" retains the order of the patches
stgit.el: Allow "P" to operate on all marked files
stgit.el: Improve stgit-mode help text slightly
David Kågedal (15):
stgit.el: Use declare to hint the debugger and indentation
stgit.el: Remove the unused allow-file parameter to stgit-patch-at-point
stgit.el: Rename stgit-toggle-patch-file-list to stgit-select-patch
stgit.el: Use an 'entry-type text property
stgit.el: Use a defstruct to store patch data
stgit.el: Use ewoc to keep track of the patch list.
stgit.el: Invalidate ewoc node when marking or unmarking instead
of modifying buffer directly
stgit.el: Get rid of the stgit-patchsym property
stgit.el: Refactor file list formatting
stgit.el: Use ewoc to keep track of the file list.
stgit.el: Add work tree and index as pseudo-patches
stgit.el: Add the stgit-file-toggle-index command
stgit.el: Add stgit-toggle-worktree to toggle visibility of
index and working tree
stgit.el: Only refresh the relevant parts when the index or
worktree changes
stgit.el: Add stgit-new-and-refresh command
Catalin Marinas (10):
Merge commit 'kha/safe'
Set the LESS environment if the pager is 'less'
Fix the import --url command
Merge commit 'kha/safe'
Handle multi-line Subject header better
Improve the description/diff splitting when parsing patches
Only get the first line from 'git describe --all'
Reverse commit 9876a650 - return the first line from git describe
Add release notes file
Add the next/prev commands to the RELEASENOTES file
Karl Wiberg (8):
Karl got married
t2800: Adapt to changes in git's conflict markers
Work around performance bug in subprocess.Popen.communicate()
Merge branch 'proposed' of git://github.com/gustavh/stgit
Release notes: Turn the 0.15-rc1 release notes into 0.15 release notes
Release notes: Reformat for better legibility, and update
Documentation: Rename remaining link macros
Tutorial: Use the new StGit repo URL in clone example
Hannes Eder (2):
fix "stg float -s FILE" for FILE != "-"
Add 'stg prev' and 'stg next'
Chris Packham (1):
Re-send [StGit BUG/PATCH] config.py: fix unset
--
Catalin
^ permalink raw reply
* Raw commands to add object to existing tree
From: D Sundstrom @ 2009-08-21 22:31 UTC (permalink / raw)
To: git
Both the community git manual:
http://book.git-scm.com/7_raw_git.html
and Pro Git book:
http://progit.org/book/ch9-2.html
walk you though low level details of creating objects and trees in git, and
then committing these new trees.
However, they do not show you how to add and commit into existing trees.
Speaking in terms of files, I have a web application that needs to replace
a file in a known directory in a known branch of a bare repository. I know the
SHA1s of the directory tree and file. I want to commit directly into a bare
repository to avoid having to manage working directories for different
branches from the web application.
Thanks!
David
^ permalink raw reply
* Re: Raw commands to add object to existing tree
From: Avery Pennarun @ 2009-08-21 22:39 UTC (permalink / raw)
To: D Sundstrom; +Cc: git
In-Reply-To: <ef72456d0908211531m5e261805p2f67d3a8a16a0b5@mail.gmail.com>
On Fri, Aug 21, 2009 at 10:31 PM, D Sundstrom<sunds@peapod.net> wrote:
> Both the community git manual:
> http://book.git-scm.com/7_raw_git.html
>
> and Pro Git book:
> http://progit.org/book/ch9-2.html
>
> walk you though low level details of creating objects and trees in git, and
> then committing these new trees.
>
> However, they do not show you how to add and commit into existing trees.
Naturally, you can't change an "existing" tree, because any given tree
(identified by its sha-1 hash) can never change. You presumably want
to create a *new* tree and commit that.
The easiest way I know to do this is to create a new indexfile, fill
it with what you want, and create the tree for that.
(Warning: untested code follows)
export GIT_INDEX_FILE=/tmp/my-temp-index
git read-tree PREVIOUS_COMMIT_OR_TREE_ID
hash=$(git hash-object NEW_FILE)
git update-index --cacheinfo "0644 $hash path/of/file/in/tree"
commitid=$(echo COMMIT MESSAGE | git commit-tree $(git write-tree))
git update-ref refs/heads/BRANCHNAME $commitid PREVIOUS_COMMIT_OR_TREE_ID
Have fun,
Avery
^ permalink raw reply
* Re: Issue with gitweb + tag + branch of the same name from master branch commit
From: Jakub Narebski @ 2009-08-21 22:49 UTC (permalink / raw)
To: Nicholas A. Bellinger; +Cc: git, J.H., H. Peter Anvin
In-Reply-To: <1250811031.26147.42.camel@haakon2.linux-iscsi.org>
"Nicholas A. Bellinger" <nab@linux-iscsi.org> writes:
> I have recently been trying to make a tag and branch of the same name
But why? Why do you want to confuse git and yourself?
> from a previous <COMMIT> on a master branch on a kernel.org tree using
> the following commands:
>
> # Create the tag:
> git tag -a lio-x.y <COMMIT>
> # Push the tags:
> git push --tags origin
> # Fetch to be sure
> git fetch origin
> # Make tagged branch:
> git checkout -b lio-x.y <COMMIT>
> # Make <NEW_COMMIT> to lio-x.y and commit
> git commit frob
> # Switch back to master branch
> git checkout master
> # Push local branch to origin
> git push origin refs/heads/lio-x.y
>
> At this point after pushing to origin, I can do a fresh clone of the
> tree, and do a 'git checkout origin/lio-x.y and I see '<NEW_COMMIT>',
> and the logs and blobs look as expected..
>
> However, after checking gitweb log for branch lio-x.y on kernel.org, I
> only see <COMMIT>, and not <NEW_COMMIT>, and all of the blobs in branch
> lio-x.y still reference the original <COMMIT>, et al.
I guess that you meant here gitweb's 'log' / 'shortlog' view linked
from 'heads' view, don't you?
> John Hawley has been helping to resolve the issue (I am just going to
> use different tag/branch names instead), and hpa asked me to report this
> as it is easy to reproduce with the gitweb version on kernel.org..
> 22:42 < warthog9> I would got show this to the git people, it *could*
> just be an old bug in gitweb (ours is not particularly
> up to date) but if I can replicate it here easily enough
> I'm guessing there's still a bug elsewhere
This is an old and long fixed (or rather worked around) issue in
gitweb, fixed in bf901f8 (gitweb: disambiguate heads and tags withs
the same name, 2007-12-15)... well if by fixed you can consider
passing around "fully qualified" refnames, i.e. the 'shortlog' link in
'heads' view now uses 'refs/heads/frob', and not only 'frob'.
J.H., you might want to consider cherry-picking this... unless you
have done that, or independently fixed this issue.
--
Jakub Narebski
Poland
ShadeHawk on #git
^ permalink raw reply
* Re: Raw commands to add object to existing tree
From: Linus Torvalds @ 2009-08-21 22:49 UTC (permalink / raw)
To: Avery Pennarun; +Cc: D Sundstrom, git
In-Reply-To: <32541b130908211539ke64bd2bif0aa7cff6bc6ae8f@mail.gmail.com>
On Fri, 21 Aug 2009, Avery Pennarun wrote:
> (Warning: untested code follows)
>
> export GIT_INDEX_FILE=/tmp/my-temp-index
> git read-tree PREVIOUS_COMMIT_OR_TREE_ID
> hash=$(git hash-object NEW_FILE)
> git update-index --cacheinfo "0644 $hash path/of/file/in/tree"
> commitid=$(echo COMMIT MESSAGE | git commit-tree $(git write-tree))
> git update-ref refs/heads/BRANCHNAME $commitid PREVIOUS_COMMIT_OR_TREE_ID
Looks roughly correct, but you need to add a a "-p $PREVIOUS_COMMIT" to
that git commit-tree thing. Otherwise the new commit will be a root
commit. Which _might_ be what you want, of course, but I kind of expect it
wasn't.
And no, I didn't test that either, so there may be other things that need
fixing too.
Looking at that thing, I have ugly flashbacks to my git scripts in 2005 ;)
Linus
^ permalink raw reply
* Re: Raw commands to add object to existing tree
From: Avery Pennarun @ 2009-08-21 22:56 UTC (permalink / raw)
To: Linus Torvalds; +Cc: D Sundstrom, git
In-Reply-To: <alpine.LFD.2.01.0908211546250.3158@localhost.localdomain>
On Fri, Aug 21, 2009 at 10:49 PM, Linus
Torvalds<torvalds@linux-foundation.org> wrote:
> Looking at that thing, I have ugly flashbacks to my git scripts in 2005 ;)
It rather resembles my git scripts in 2009, in which I'm using a web
service to let people upload Microsoft Access databases and version
control and branch them. Long story, but I'm sure glad this plumbing
stuff exists :)
And yes, my scripts use the -p option. Oops.
Have fun,
Avery
^ permalink raw reply
* Re: Continue git clone after interruption
From: Sam Vilain @ 2009-08-21 23:07 UTC (permalink / raw)
To: Nicolas Pitre
Cc: Jakub Narebski, Tomasz Kontusz, git, Johannes Schindelin,
Scott Chacon
In-Reply-To: <alpine.LFD.2.00.0908211614220.6044@xanadu.home>
On Fri, 2009-08-21 at 17:07 -0400, Nicolas Pitre wrote:
> > 2. There is support in git pack format to do 'deepening' of shallow
> > clone, which means that git can generate incrementals in top-down
> > order, _similar to how objects are ordered in packfile_.
>
> Well... the pack format was not meant for that "support". The fact
> that
> the typical object order used by pack-objects when serving fetch
> request
> is amenable to incremental top-down updates is rather coincidental
> and
> not really planned.
Mmm. And the problem with 'thin' packs is that they normally allow
deltas the other way.
I think the first step here would be to allow thin pack generation to
accept a bounded range of commits, any of the objects within which may
be used as delta base candidates. That way, these "top down" thin packs
can be generated. Currently of course it just uses the --not and makes
"bottom up" thin packs.
> > Another solution would be to try to come up with some sort of stable
> > sorting of objects so that packfile generated for the same
> > parameters (endpoints) would be always byte-for-byte the same. But
> > that might be difficult, or even impossible.
>
> And I don't want to commit to that either. Having some flexibility
> in object ordering makes it possible to improve on the packing
> heuristics.
You don't have to lose that for storage. It's only for generating the
thin packs that it matters; also, the restriction is relaxed when it
comes to objects which are all being sent in the same pack, which can
freely delta amongst themselves in any direction.
What did you think about the bundle slicing stuff?
Sam
^ permalink raw reply
* Re: git diffall, open all diff files immediatly (eg tabbed window?in BC)
From: David Aguilar @ 2009-08-21 23:45 UTC (permalink / raw)
To: Seba Illingworth; +Cc: git
In-Reply-To: <loom.20090821T074953-77@post.gmane.org>
On Fri, Aug 21, 2009 at 05:54:48AM +0000, Seba Illingworth wrote:
> David Aguilar <davvid <at> gmail.com> writes:
> > To make it work irrespective of the configuration...
>
> Hi David, great to get your comments, thanks for the pointers!
One last note (I promise ;)):
I would recommend against saying 'git difftool head' on your
blog beause that only works on OSX with its case-preserving yet
case-insensitive filesystem. It might be worth mentioning that.
If you try 'git diff head' on a different filesystem (for
example, if you tried it on Linux) you'll find that it doesn't
work because the file is .git/HEAD; .git/head doesn't exist.
On OSX the filesystem tells git that .git/head exists even
though it's actually finding .git/HEAD.
--
David
^ permalink raw reply
* Re: [PATCH v2 05/14] Change regerror() definition from K&R style to ANSI C (C89)
From: Frank Li @ 2009-08-22 0:15 UTC (permalink / raw)
To: Marius Storm-Olsen; +Cc: msysgit, git
In-Reply-To: <0123e22f50dfd5e1b483a02cf550e5373125f1d.1250860247.git.mstormo@gmail.com>
> The MSVC headers typedef errcode as int, and thus confused the
> compiler in the K&R style definition. ANSI style deconfuses it.
>
It is better
best regards
Frank Li
^ permalink raw reply
* Re: [PATCH] git-tag(1): Refer to git-check-ref-format(1) for <name>
From: Nanako Shiraishi @ 2009-08-22 0:45 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Jari Aalto
In-Reply-To: <7veirs6qxn.fsf@alter.siamese.dyndns.org>
Quoting Junio C Hamano <gitster@pobox.com>
but at the same time, I wish if we can somehow teach people that the
branches and the tags are just two special cases of refs that follow
exactly the same set of rules, we would not have to apply another
similar patch to git-branch documentation and instead we can teach what
the naming rules are for refs in general. Then the readers can learn
the rule once, and extend the knowledge to other types of refs
(e.g. notes) in the future.
I read the help page for the git-branch command and noticed that we don't
need a similar patch. I think the git-branch help is nicer than git-tag
help because it doesn't reproduce the rule in an incomplete way that can
lead to confusion, divergence, and additional maintenance hassle.
-- 8< -- 8< -- 8< -- cut here >8 -- >8 -- >8 --
Subject: Documentation: consistently refer to check-ref-format
Change the <name> placeholder to <tagname> in the SYNOPSIS section of
git-tag documentation, and describe it in the OPTIONS section in a way
similar to how documentation for git-branch does.
Add SEE ALSO section to list the other documentation pages these two pages
refer to.
Signed-off-by: Nanako Shiraishi <nanako3@lavabit.com>
---
Documentation/git-branch.txt | 6 ++++++
Documentation/git-tag.txt | 20 ++++++++++++++------
2 files changed, 20 insertions(+), 6 deletions(-)
diff --git a/Documentation/git-branch.txt b/Documentation/git-branch.txt
index ae201de..9998887 100644
--- a/Documentation/git-branch.txt
+++ b/Documentation/git-branch.txt
@@ -209,6 +209,12 @@ but different purposes:
- `--no-merged` is used to find branches which are candidates for merging
into HEAD, since those branches are not fully contained by HEAD.
+SEE ALSO
+--------
+linkgit:git-check-ref-format[1],
+linkgit:git-fetch[1],
+linkgit:git-remote[1].
+
Author
------
Written by Linus Torvalds <torvalds@osdl.org> and Junio C Hamano <gitster@pobox.com>
diff --git a/Documentation/git-tag.txt b/Documentation/git-tag.txt
index 1118ce2..5113eae 100644
--- a/Documentation/git-tag.txt
+++ b/Documentation/git-tag.txt
@@ -10,17 +10,15 @@ SYNOPSIS
--------
[verse]
'git tag' [-a | -s | -u <key-id>] [-f] [-m <msg> | -F <file>]
- <name> [<commit> | <object>]
-'git tag' -d <name>...
+ <tagname> [<commit> | <object>]
+'git tag' -d <tagname>...
'git tag' [-n[<num>]] -l [--contains <commit>] [<pattern>]
-'git tag' -v <name>...
+'git tag' -v <tagname>...
DESCRIPTION
-----------
-Adds a 'tag' reference in `.git/refs/tags/`. The tag <name> must pass
-linkgit:git-check-ref-format[1] which basicly means that control characters,
-space, ~, ^, :, ?, *, [ and \ are prohibited.
+Adds a tag reference in `.git/refs/tags/`.
Unless `-f` is given, the tag must not yet exist in
`.git/refs/tags/` directory.
@@ -88,6 +86,12 @@ OPTIONS
Implies `-a` if none of `-a`, `-s`, or `-u <key-id>`
is given.
+<tagname>::
+ The name of the tag to create, delete, or describe.
+ The new tag name must pass all checks defined by
+ linkgit:git-check-ref-format[1]. Some of these checks
+ may restrict the characters allowed in a tag name.
+
CONFIGURATION
-------------
By default, 'git-tag' in sign-with-default mode (-s) will use your
@@ -252,6 +256,10 @@ $ GIT_COMMITTER_DATE="2006-10-02 10:31" git tag -s v1.0.1
------------
+SEE ALSO
+--------
+linkgit:git-check-ref-format[1].
+
Author
------
Written by Linus Torvalds <torvalds@osdl.org>,
--
Nanako Shiraishi
http://ivory.ap.teacup.com/nanako3/
^ permalink raw reply related
* Re: Continue git clone after interruption
From: Nicolas Pitre @ 2009-08-22 0:59 UTC (permalink / raw)
To: Jakub Narebski; +Cc: Tomasz Kontusz, git, Johannes Schindelin, Scott Chacon
In-Reply-To: <200908212341.33324.jnareb@gmail.com>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 4528 bytes --]
On Fri, 21 Aug 2009, Jakub Narebski wrote:
> On Fri, 21 Aug 2009, Nicolas Pitre wrote:
> > On Fri, 21 Aug 2009, Jakub Narebski wrote:
> >> On Thu, 20 Aug 2009, Nicolas Pitre wrote:
> >>> On Thu, 20 Aug 2009, Jakub Narebski wrote:
>
> >>>> It is however only 2.5 MB out of 37 MB that are resumable, which is 7%
> >>>> (well, that of course depends on repository). Not that much that is
> >>>> resumable.
> >>>
> >>> Take the Linux kernel then. It is more like 75 MB.
> >>
> >> Ah... good example.
> >>
> >> On the other hand Linux is fairly large project in terms of LoC, but
> >> it had its history cut when moving to Git, so the ratio of git-archive
> >> of HEAD to the size of packfile is overemphasized here.
> >
> > That doesn't matter. You still need that amount of data up front to do
> > anything. And I doubt people with slow links will want the full history
> > anyway, regardless if it goes backward 4 years or 18 years back.
>
> On the other hand unreliable link doesn't need to mean unreasonably
> slow link.
In my experience speed and reliability are more or less tied together.
And the slower is your link, the longer your transfer will last, the
greater are the chances for you to have troubles.
> Hopefully GitTorrent / git-mirror-sync would finally come out of
> vapourware and wouldn't share the fate of Duke Nukem Forever ;-),
> and we would have this as an alternative to clone large repositories.
Well... Maybe.
> Well, supposedly there is some code, and last year GSoC project at
> least shook the dust out of initial design and made it simplier, IIUC.
The BitTorrent protocol is a nifty thing (although I doubt the
intertainment industry think so). But its efficiency relies on the fact
that many many people are expected to download the same stuff at the
same time. I have some doubts about the availability of the right
conditions in the context of git for a BitTorrent-like protocol to work
well in practice. But this is Open Source and no one has to wait for me
or anyone else to be convinced before attempting it and showing results
to the world.
> >> This was plain text RFC for the Git Packfile Protocol, generated from
> >> rfc2629 XML sources at http://github.com/schacon/gitserver-rfc
> >
> > I suggest you track it down and prod/propose a version for merging in
> > the git repository.
>
> Scott Chacon was (and is) CC-ed.
He might not have followed all our exchange so deeply in this thread
though. So maybe another thread with him in the To: field might be
required to get his attention.
> I don't know if you remember mentioned discussion about pack protocol,
> stemming from the fact that some of git (re)implementations (Dulwich,
> JGit) failed to implement it properly, where properly = same as
> git-core, i.e. the original implementation in C... because there were
> not enough documentation.
Yes I followed the discussion. I still think that, since that
documentation exists now, that would be a good idea to have a copy
included in the git sources.
> > The format I was envisioning is really simple:
> >
> > First the size of the raw commit object data content in decimal,
> > followed by a 0 byte, followed by the actual content of the commit
> > object, followed by a 0 byte. (Note: this could be the exact same
> > content as the canonical commit object data with the "commit" prefix,
> > but as all the rest are all blob content this would be redundant.)
> >
> > Then, for each file:
> >
> > - The file mode in octal notation just as in tree objects
> > - a space
> > - the size of the file in decimal
> > - a tab
> > - the full path of the file
> > - a 0 byte
> > - the file content as found in the corresponding blob
> > - a 0 byte
> >
> > And finally some kind of marker to indicate the end of the stream.
> >
> > Put the lot through zlib and you're done.
>
> So you don't want to just tack commit object (as extended pax header,
> or a comment - if it is at all possible) to the existing 'tar' and
> 'zip' archive formats. Probably better to design format from scratch.
As René Scharfe mentioned, the existing archive formats have limitations
and complexities that we might simply avoid altogether by creating a
simpler format that is more likely to never fail to faithfully reproduce
a git revision content. Maybe the git-fast-import format could do it
even better, and maybe not. That's an implementation detail that needs
to be worked out once one is ready to get real with actual coding.
Nicolas
^ permalink raw reply
* Re: how to do "git merge --abort"
From: bill lam @ 2009-08-22 1:56 UTC (permalink / raw)
To: git
In-Reply-To: <200908211726.21593.trast@student.ethz.ch>
Thanks to both of you. I'll try it when the next merge conflicts.
--
regards,
====================================================
GPG key 1024D/4434BAB3 2008-08-24
gpg --keyserver subkeys.pgp.net --recv-keys 4434BAB3
^ permalink raw reply
* Re: git diffall, open all diff files immediatly (eg tabbed window?in BC)
From: Seba Illingworth @ 2009-08-22 2:10 UTC (permalink / raw)
To: git
In-Reply-To: <20090821234512.GA58248@gmail.com>
David Aguilar <davvid <at> gmail.com> writes:
> I would recommend against saying 'git difftool head' on your
> blog beause that only works on OSX with its case-preserving yet
> case-insensitive filesystem....
Thanks David, understood and updated to 'HEAD'. 'head' had worked for me with my
sloppy Windows ways ;)
I struggled with your previous suggestion for handling paths with spaces;
I couldn't get the for-loop to split the input into individual filenames
on the line-break separator (after outer quotes expanded the result?).
But rewriting it this way seems to work well and handles spaces (Windows):
git diff --name-only "$@" | while read filename; do
git difftool "$@" --no-prompt "$filename" &
done
Hope you can comment on this variation?
And thanks for all the tips! Seba
^ permalink raw reply
* How to recover from "reset --hard"
From: Ping Yin @ 2009-08-22 2:53 UTC (permalink / raw)
To: git mailing list
After adding a file to index, i do a "reset --hard", then how do i
recovery the file?
I want write all lost files to a directory and find it according to
the file size.
Does "git fsck --lost-found" write this file to .git\lost-found\other ?
Ping Yin
^ permalink raw reply
* Re: [PATCH JGIT] Ensure created test repositories use canonical paths
From: Jonas Fonseca @ 2009-08-22 3:32 UTC (permalink / raw)
To: Robin Rosenberg; +Cc: Shawn O. Pearce, git
In-Reply-To: <200908210035.10825.robin.rosenberg.lists@dewire.com>
[With correct CC list. Sorry for the resend Robin]
On Thu, Aug 20, 2009 at 18:35, Robin
Rosenberg<robin.rosenberg.lists@dewire.com> wrote:
> onsdag 19 augusti 2009 15:18:11 skrev Jonas Fonseca <fonseca@diku.dk>:
>> Fixes breakage in the RepositoryCacheTest when running tests using:
>>
>> mvn -f ./jgit-maven/jgit/pom.xml test
>> [...]
>> @@ -217,7 +217,7 @@ public void setUp() throws Exception {
>> trash = new File(trashParent,"trash"+System.currentTimeMillis()+"."+(testcount++));
>> - trash_git = new File(trash, ".git");
>> + trash_git = new File(trash, ".git").getCanonicalFile();
>> @@ -307,7 +307,7 @@ protected Repository createNewEmptyRepo() throws IOException {
>> protected Repository createNewEmptyRepo(boolean bare) throws IOException {
>> final File newTestRepo = new File(trashParent, "new"
>> + System.currentTimeMillis() + "." + (testcount++)
>> - + (bare ? "" : "/") + ".git");
>> + + (bare ? "" : "/") + ".git").getCanonicalFile();
>
> We use getCanonicalFile here and Repository.gitDir is initialized with getAbsoluteDir.
BTW, a simpler fix would be to initialize trashParent to a canonical
path, which might be less intrusive.
> Does this work on all platforms?
I have only tested on Linux.
> Seems linux normalized things when you do things like, but I'm not sure that happens everywhere.
If you think it is a problem, let's drop the patch. It just seemed
like a simple way to increase robustness.
--
Jonas Fonseca
^ permalink raw reply
* Re: Continue git clone after interruption
From: Nicolas Pitre @ 2009-08-22 3:37 UTC (permalink / raw)
To: Sam Vilain
Cc: Jakub Narebski, Tomasz Kontusz, git, Johannes Schindelin,
Scott Chacon
In-Reply-To: <1250896025.19039.7.camel@maia.lan>
On Sat, 22 Aug 2009, Sam Vilain wrote:
> On Fri, 2009-08-21 at 17:07 -0400, Nicolas Pitre wrote:
> > > 2. There is support in git pack format to do 'deepening' of shallow
> > > clone, which means that git can generate incrementals in top-down
> > > order, _similar to how objects are ordered in packfile_.
> >
> > Well... the pack format was not meant for that "support". The fact
> > that
> > the typical object order used by pack-objects when serving fetch
> > request
> > is amenable to incremental top-down updates is rather coincidental
> > and
> > not really planned.
>
> Mmm. And the problem with 'thin' packs is that they normally allow
> deltas the other way.
Sure. The pack format is flexible.
> I think the first step here would be to allow thin pack generation to
> accept a bounded range of commits, any of the objects within which may
> be used as delta base candidates. That way, these "top down" thin packs
> can be generated. Currently of course it just uses the --not and makes
> "bottom up" thin packs.
The pack is still almost top-down. It's only the missing delta base
that are in the other direction, refering to objects you have locally
and therefore older.
> > > Another solution would be to try to come up with some sort of stable
> > > sorting of objects so that packfile generated for the same
> > > parameters (endpoints) would be always byte-for-byte the same. But
> > > that might be difficult, or even impossible.
> >
> > And I don't want to commit to that either. Having some flexibility
> > in object ordering makes it possible to improve on the packing
> > heuristics.
>
> You don't have to lose that for storage. It's only for generating the
> thin packs that it matters;
What matters?
> also, the restriction is relaxed when it
> comes to objects which are all being sent in the same pack, which can
> freely delta amongst themselves in any direction.
That's always the case within a pack, but only for REF_DELTA objects.
The OFS_DELTA objects have to be ordered. And yes, having deltas across
packs is disallowed to avoid cycles and to keep the database robust.
The only exception is for thin packs, but those are never created on
disk. Thin packs are only used for transport and quickly "fixed" upon
reception by appending the missing objects to them so they are not
"thin" anymore.
> What did you think about the bundle slicing stuff?
If I didn't comment on it already, then I probably missed it and have no
idea.
Nicolas
^ permalink raw reply
* Re: hitting home directory's parent
From: Nguyen Thai Ngoc Duy @ 2009-08-22 4:10 UTC (permalink / raw)
To: Daniel Convissor; +Cc: Git Mailing List
In-Reply-To: <20090821200503.GA19660@panix.com>
On Sat, Aug 22, 2009 at 3:05 AM, Daniel
Convissor<danielc@analysisandsolutions.com> wrote:
> Hi:
>
> I just installed git in my Cygwin installation for the first time. The
> git version is 1.6.1.2, which is the latest version they have. When I
> enter one of the following commands:
> git --help
> git config --global user.name "Daniel Convissor"
>
> I get this error:
> fatal: Cannot change to /home/danielc/..: Permission denied
>
> Though "git --version" executes fine.
>
> I've been using Cygwin for many years and no other program has ever
> produced this issue for me. For example, svn --help, ls --help, etc work
> just fine.
>
> Why is git venturing into to the home directory's parent directory? Is
> this a bug? If not, is this really necessary?
I guess it tried to find .git directory upward. I think you can set
GIT_CEILING_DIRECTORIES to make it stop at /home/danielc. Excerpt from
git.txt
-'GIT_CEILING_DIRECTORIES'::
This should be a colon-separated list of absolute paths.
If set, it is a list of directories that git should not chdir
up into while looking for a repository directory.
It will not exclude the current working directory or
a GIT_DIR set on the command line or in the environment.
(Useful for excluding slow-loading network directories.)
-
Duy
^ permalink raw reply
* Re: [PATCH 0/6 RFC] Series to correct xutils incomplete line handling.
From: Thell Fowler @ 2009-08-22 4:23 UTC (permalink / raw)
To: Alex Riesen; +Cc: Thell Fowler, Johannes Schindelin, git
In-Reply-To: <81b0412b0908211516l4db79249h180e50ffb8e2c1ab@mail.gmail.com>
Alex Riesen (raa.lkml@gmail.com) wrote on Aug 21, 2009:
> On Fri, Aug 21, 2009 at 19:39, Thell Fowler<git@tbfowler.name> wrote:
> > What is _REALLY_ odd is that it didn't make any tests fail in the test
> > dir using master, next, and pu.
>
> The test suite has a very good coverage, but it surely is not complete.
>
Well, two lessons learned...
1) Don't do isolated tests and count on the bundled tests to catch the
corner cases.
2) Write more tests.
> > Perhaps someone can explain what I did wrong when testing?
> >
> > git checkout master
> > make -s clean && make -s all && make -s install && cd t && make
>
> This should have worked. Although I prefer just:
>
> $ make -j4 && make test -j16
>
Good to know I was on the right track. Thanks.
--
Thell
^ permalink raw reply
* Re: [PATCH v2 5/9] revert: libify pick
From: Christian Couder @ 2009-08-22 4:35 UTC (permalink / raw)
To: Junio C Hamano
Cc: git, Johannes Schindelin, Stephan Beyer, Daniel Barkalow,
Jakub Narebski
In-Reply-To: <7v8whdip1l.fsf@alter.siamese.dyndns.org>
On Friday 21 August 2009, Junio C Hamano wrote:
> Christian Couder <chriscool@tuxfamily.org> writes:
> > From: Stephan Beyer <s-beyer@gmx.net>
> >
> > This commit is made of code from the sequencer GSoC project:
> >
> > git://repo.or.cz/git/sbeyer.git
> >
> > (commit 5a78908b70ceb5a4ea9fd4b82f07ceba1f019079)
> >
> > The goal of this commit is to abstract out pick functionnality
> > into a new pick() function made of code from "builtin-revert.c".
> >
> > The new pick() function is in a new "pick.c" file with an
> > associated "pick.h".
>
> Is it pick() or pick_commit()?
It is pick_commit(). Sorry I didn't properly update the commit message.
> By the way, this comment applies to other messages in the series, but do
> these original commits by Stephan lack any meaningful messages?
Well, in Stephan's repo the commit
(94a568a78d243d7a6c13778bc6b7ac1eb46e48cc) that created the pick.c and
pick.h files had this message:
------
Libify cherry-pick and revert.
A poor start.
------
(Note that I have seen far worse commit messages in other GSoC students'
repo.)
And then quite a few other commits improved on this one, and the whole gives
the code that is in this patch.
> I would
> actually have expected to see a commit log message that looks more like:
>
> From: Stephan Beyer <...>
>
> Meaningful log message Stephan describes what this commit does in
> sufficient detail, perhaps with clarification and rewording by
> Christian.
>
> Second and subsequent paragraph to explain it as necessary.
>
> [cc: this is based on 5a78908b70ceb5a4ea9fd4b82f07ceba1f019079
> from Stephan's git://repo.or.cz/git/sbeyer.git]
>
> Signed-off-by: ...
>
> The point is that the "origin info" would be a side-note, not the first
> and the most important thing in the message.
I tried to improve some commit messages like this in the v3 that will follow
this email.
Thanks,
Christian.
^ permalink raw reply
* [PATCH v3 0/9] more changes to port rebase -i to C using sequencer code
From: Christian Couder @ 2009-08-22 4:16 UTC (permalink / raw)
To: Junio C Hamano
Cc: git, Johannes Schindelin, Stephan Beyer, Daniel Barkalow,
Jakub Narebski
This is another reroll of the series I first sent on August the 12th.
The only changes since v2 are in the commit messages. References to the
pick() function have been replaced by references to pick_commit(), and I
tried to describe the purpose of the patch first.
Christian Couder (5):
sequencer: add "--fast-forward" option to "git sequencer--helper"
sequencer: let "git sequencer--helper" callers set "allow_dirty"
rebase -i: use "git sequencer--helper --fast-forward"
pick: libify "pick_help_msg()"
rebase -i: use "git sequencer--helper --cherry-pick"
Stephan Beyer (4):
sequencer: add "do_fast_forward()" to perform a fast forward
revert: libify pick
sequencer: add "do_commit()" and related functions
sequencer: add "--cherry-pick" option to "git sequencer--helper"
Makefile | 2 +
builtin-revert.c | 293 ++++++-----------------------------------
builtin-sequencer--helper.c | 305 +++++++++++++++++++++++++++++++++++++++++--
git-rebase--interactive.sh | 22 ++--
pick.c | 232 ++++++++++++++++++++++++++++++++
pick.h | 14 ++
6 files changed, 599 insertions(+), 269 deletions(-)
create mode 100644 pick.c
create mode 100644 pick.h
^ permalink raw reply
* [PATCH v3 1/9] sequencer: add "do_fast_forward()" to perform a fast forward
From: Christian Couder @ 2009-08-22 4:16 UTC (permalink / raw)
To: Junio C Hamano
Cc: git, Johannes Schindelin, Stephan Beyer, Daniel Barkalow,
Jakub Narebski
In-Reply-To: <20090822041157.4261.92491.chriscool@tuxfamily.org>
From: Stephan Beyer <s-beyer@gmx.net>
This code is taken from the sequencer GSoC project:
git://repo.or.cz/git/sbeyer.git
(commit e7b8dab0c2a73ade92017a52bb1405ea1534ef20)
but the messages have been changed to be the same as those
displayed by git-rebase--interactive.sh.
Mentored-by: Daniel Barkalow <barkalow@iabervon.org>
Mentored-by: Christian Couder <chriscool@tuxfamily.org>
Signed-off-by: Stephan Beyer <s-beyer@gmx.net>
Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
---
builtin-sequencer--helper.c | 9 +++++++++
1 files changed, 9 insertions(+), 0 deletions(-)
diff --git a/builtin-sequencer--helper.c b/builtin-sequencer--helper.c
index be030bc..0cd7e98 100644
--- a/builtin-sequencer--helper.c
+++ b/builtin-sequencer--helper.c
@@ -171,6 +171,15 @@ static struct commit *get_commit(const char *arg)
return lookup_commit_reference(sha1);
}
+static int do_fast_forward(const unsigned char *sha)
+{
+ if (reset_almost_hard(sha))
+ return error("Cannot fast forward to %s", sha1_to_hex(sha));
+ if (verbosity > 1)
+ printf("Fast forward to %s\n", sha1_to_hex(sha));
+ return 0;
+}
+
static int set_verbosity(int verbose)
{
char tmp[] = "0";
--
1.6.4.271.ge010d
^ permalink raw reply related
* [PATCH v3 2/9] sequencer: add "--fast-forward" option to "git sequencer--helper"
From: Christian Couder @ 2009-08-22 4:16 UTC (permalink / raw)
To: Junio C Hamano
Cc: git, Johannes Schindelin, Stephan Beyer, Daniel Barkalow,
Jakub Narebski
In-Reply-To: <20090822041157.4261.92491.chriscool@tuxfamily.org>
This new option uses the "do_fast_forward()" function to perform
a fast forward.
Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
---
builtin-sequencer--helper.c | 16 ++++++++++++----
1 files changed, 12 insertions(+), 4 deletions(-)
diff --git a/builtin-sequencer--helper.c b/builtin-sequencer--helper.c
index 0cd7e98..bd72f65 100644
--- a/builtin-sequencer--helper.c
+++ b/builtin-sequencer--helper.c
@@ -19,6 +19,7 @@ static unsigned char head_sha1[20];
static const char * const git_sequencer_helper_usage[] = {
"git sequencer--helper --make-patch <commit>",
"git sequencer--helper --reset-hard <commit> <reflog-msg> <verbosity>",
+ "git sequencer--helper --fast-forward <commit> <reflog-msg> <verbosity>",
NULL
};
@@ -218,11 +219,14 @@ int cmd_sequencer__helper(int argc, const char **argv, const char *prefix)
{
char *patch_commit = NULL;
char *reset_commit = NULL;
+ char *ff_commit = NULL;
struct option options[] = {
OPT_STRING(0, "make-patch", &patch_commit, "commit",
"create a patch from commit"),
OPT_STRING(0, "reset-hard", &reset_commit, "commit",
"reset to commit"),
+ OPT_STRING(0, "fast-forward", &ff_commit, "commit",
+ "fast forward to commit"),
OPT_END()
};
@@ -239,15 +243,16 @@ int cmd_sequencer__helper(int argc, const char **argv, const char *prefix)
return 0;
}
- if (reset_commit) {
+ if (ff_commit || reset_commit) {
unsigned char sha1[20];
+ char *commit = ff_commit ? ff_commit : reset_commit;
if (argc != 2)
usage_with_options(git_sequencer_helper_usage,
options);
- if (get_sha1(reset_commit, sha1)) {
- error("Could not find '%s'", reset_commit);
+ if (get_sha1(commit, sha1)) {
+ error("Could not find '%s'", commit);
return 1;
}
@@ -258,7 +263,10 @@ int cmd_sequencer__helper(int argc, const char **argv, const char *prefix)
return 1;
}
- return reset_almost_hard(sha1);
+ if (ff_commit)
+ return do_fast_forward(sha1);
+ else
+ return reset_almost_hard(sha1);
}
usage_with_options(git_sequencer_helper_usage, options);
--
1.6.4.271.ge010d
^ permalink raw reply related
* [PATCH v3 4/9] rebase -i: use "git sequencer--helper --fast-forward"
From: Christian Couder @ 2009-08-22 4:16 UTC (permalink / raw)
To: Junio C Hamano
Cc: git, Johannes Schindelin, Stephan Beyer, Daniel Barkalow,
Jakub Narebski
In-Reply-To: <20090822041157.4261.92491.chriscool@tuxfamily.org>
when fast forwarding.
Note that in the first hunk of this patch, there was this line:
test "a$1" = a-n && output git reset --soft $current_sha1
but the test always failed.
Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
---
git-rebase--interactive.sh | 11 +++--------
1 files changed, 3 insertions(+), 8 deletions(-)
diff --git a/git-rebase--interactive.sh b/git-rebase--interactive.sh
index 0041994..7651fd6 100755
--- a/git-rebase--interactive.sh
+++ b/git-rebase--interactive.sh
@@ -154,11 +154,8 @@ pick_one () {
die "Could not get the parent of $sha1"
current_sha1=$(git rev-parse --verify HEAD)
if test "$no_ff$current_sha1" = "$parent_sha1"; then
- git sequencer--helper --reset-hard $sha1 \
+ git sequencer--helper --fast-forward $sha1 \
"$GIT_REFLOG_ACTION" "$VERBOSE"
- test "a$1" = a-n && output git reset --soft $current_sha1
- sha1=$(git rev-parse --short $sha1)
- output warn Fast forward to $sha1
else
output git cherry-pick "$@"
fi
@@ -238,10 +235,8 @@ pick_one_preserving_merges () {
done
case $fast_forward in
t)
- output warn "Fast forward to $sha1"
- git sequencer--helper --reset-hard $sha1 \
- "$GIT_REFLOG_ACTION" "$VERBOSE" ||
- die "Cannot fast forward to $sha1"
+ git sequencer--helper --fast-forward $sha1 \
+ "$GIT_REFLOG_ACTION" "$VERBOSE" || exit
;;
f)
first_parent=$(expr "$new_parents" : ' \([^ ]*\)')
--
1.6.4.271.ge010d
^ 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