* 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
* 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: 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: [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: [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: 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: 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: 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: 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: 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: 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
* 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
* [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
* 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
* 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: What's cooking in git.git (Aug 2009, #03; Thu, 20)
From: Junio C Hamano @ 2009-08-21 21:43 UTC (permalink / raw)
To: Mark A Rada; +Cc: Jakub Narebski, git
In-Reply-To: <F4C7A2F3-B030-449A-87AC-B54CA2B647B4@mailservices.uwaterloo.ca>
Mark A Rada <marada@uwaterloo.ca> writes:
> Unless I missed a case, the tests show that the extra condition check
> that was added in the &git_snapshot routine is never actually executed,
> because a disabled snapshot format is not added to @snapshot_fmts, which
> is checked first.
>
> snippet:
> 5178 } elsif (!grep($_ eq $format, @snapshot_fmts)) {
> 5179 die_error(403, "Unsupported snapshot format");
> 5180 } elsif ($known_snapshot_formats{$format}{'disabled'}) {
> 5181 die_error(403, "Snapshot format not allowed");
> 5182 }
> 5183
True; filter_snapshot_fmts looks at 'disabled' first.
I do not mind keeping these two lines as belt-and-suspender, though.
^ permalink raw reply
* Re: Continue git clone after interruption
From: Jakub Narebski @ 2009-08-21 21:41 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: Tomasz Kontusz, git, Johannes Schindelin, Scott Chacon
In-Reply-To: <alpine.LFD.2.00.0908211614220.6044@xanadu.home>
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.
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, supposedly there is some code, and last year GSoC project at
least shook the dust out of initial design and made it simplier, IIUC.
>> You make use here of a few facts:
[...]
>> 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.
Ooops. I meant "git pack PROTOCOL" here, not "git pack _format_".
the one about want/have/shallow/deepen exchange.
[...]
>>> A special
>>> mode to pack-object could place commit objects only after all the
>>> objects needed to create that revision. So once you get a commit object
>>> on the receiving end, you could assume that all objects reachable from
>>> that commit are already received, or you had them locally already.
>>
>> Yes, with such mode (which I think wouldn't reduce / interfere with
>> ability for upload-pack to pack more tightly by reordering objects
>> and choosing different deltas) it would be easy to do a salvage of
>> a partially completed / transferred packfile. Even if there is no
>> extension to tell git server which objects we have ("have" is only
>> about commits), if there is at least one commit object in received
>> part of packfile, we can try to continue from later (from more);
>> there is less left to download.
>
> Exact. Suffice to set the last received commit(s) (after validation) as
> one of the shallow points.
Assuming that received commit is full (has all prerequisites), and
is connected to the rest of body of partially [shallow] cloned
repository.
>>>> Documentation/technical/shallow.txt doesn't cover "shallow", "unshallow"
>>>> and "deepen" commands from 'shallow' capability extension to git pack
>>>> protocol (http://git-scm.com/gitserver.txt).
>>>
>>> 404 Not Found
>>>
>>> Maybe that should be committed to git in Documentation/technical/ as
>>> well?
>>
>> 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.
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.
>>>> P.S. As you can see implementing resumable clone isn't easy...
>>>
>>> I've been saying that all along for quite a while now. ;-)
>>
>> Well, on the other hand side we have example of how long it took to
>> come to current implementation of git submodules. But if finally
>> got done.
>
> In this case there is still no new line of code what so ever. Thinking
> it through is what takes time.
Measure twice, cut once :-)
In this case I think design upfront is a good solution.
>> The git-archive + deepening approach you proposed can be split into
>> smaller individual improvements. You don't need to implement it all
>> at once.
[...]
>> 3. Create new git-archive pseudoformat, used to transfer single commit
>> (with commit object and original branch name in some extended header,
>> similar to how commit ID is stored in extended pax header or ZIP
>> comment). It would imply not using export-* gitattributes.
>
> 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.
>> 4. Implement alternate ordering of objects in packfile, so commit object
>> is put immediately after all its prerequisites.
>
> That would require some changes in the object enumeration code which is
> an area of the code I don't know well.
Oh.
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: [PATCH 03/14] Define SNPRINTF_SIZE_CORR=1 for Microsoft Visual C++
From: Johannes Sixt @ 2009-08-21 21:41 UTC (permalink / raw)
To: Junio C Hamano
Cc: Marius Storm-Olsen, Johannes.Schindelin, msysgit, git, lznuaa
In-Reply-To: <7vr5v4dgz0.fsf@alter.siamese.dyndns.org>
On Freitag, 21. August 2009, Junio C Hamano wrote:
> Marius Storm-Olsen <mstormo@gmail.com> writes:
> > From: Frank Li <lznuaa@gmail.com>
> >
> > The Microsoft C runtime's vsnprintf function does not add NUL at
> > the end of the buffer.
>
> This contradicts the way I read the comment in compat/snprintf.c from
> f4626df (Add target architecture MinGW., 2007-12-01).
>
> As far as I can see, the correction is about the meaning of the size
> parameter to the function, namely, that a broken implementation may
> mistakenly think that it was told the maximum length of the meat of the
> string to write, and it is allowed to append a NUL beyond the limit, when
> the caller actually is telling it the size of the buffer.
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, i.e. there is room for the complete
string, but not for the terminating NUL, then vsnprintf does not report an
error!
Therefore, we tell vsnprintf that the buffer is shorter by one byte and always
write NUL in the last position so that we get a correctly terminated string
even in this case.
-- Hannes
^ permalink raw reply
* Re: [PATCH] Add tests for rev-list --graph with options that simplify history
From: Adam Simpkins @ 2009-08-21 21:23 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Git Mailing List
In-Reply-To: <7vbpm8exeo.fsf@alter.siamese.dyndns.org>
On Fri, Aug 21, 2009 at 01:15:27PM -0700, Junio C Hamano wrote:
> Adam Simpkins <simpkins@facebook.com> writes:
>
> > +# There's more than one "correct" way to represent the history graphically.
> > +# These tests depend on the current behavior of the graphing code. If the
> > +# graphing code is ever changed to draw the output differently, these tests
> > +# cases will need to be updated to know about the new layout.
>
> An ideal solution to such a problem would be not to write the tests that
> way to require _the exact layout_ of the output.
Yeah. In the past I've been hesitant to submit tests for the graph
behavior for precisely this reason. However, having tests that check
the exact layout seems better than not having tests at all.
> What was the bug you were trying to fix? Was it that in a simplified
> history some arcs are not connected whey they should be?
It was an issue with a missing arc between two commits that should
have been connected. In the past, other bugs (e.g., the one fixed in
2ecbd0a0) have caused arcs to appear connected to the wrong commit.
> Can you test that without relying on other aspect (say, commits are marked
> with '*' right now but a patch might change it to '^' for some commits) of
> the output?
>
> I am just wondering how feasible it is the problem you are trying to
> solve, not demanding you to solve it.
In general, it seems like its not worthwhile trying to solve this
problem. I don't expect changes to the graph layout to occur often.
Modifying this test case if and when they do occur seems simpler and
less error-prone than trying to write code that attempts to anticipate
changes we might make in the future.
When I wrote this comment, I was thinking more about potential changes
in the way arcs are drawn in the output, or in the amount of padding.
The problem you mentioned (accepting other characters other than '*'
for commits) is easier, but I'm still not convinced we should try to
solve it. For example, it's nice that the current code also tests
that boundary commits are represented differently than non-boundary
commits. Being too permissive in what we accept could also
potentially hide bugs in the future.
--
Adam Simpkins
simpkins@facebook.com
^ permalink raw reply
* Re: git rebase --interactive problem
From: Alex Riesen @ 2009-08-21 21:18 UTC (permalink / raw)
To: Lenka Dubcova; +Cc: git
In-Reply-To: <1250889145942-3492625.post@n2.nabble.com>
On Fri, Aug 21, 2009 at 23:12, Lenka Dubcova<dubcova@gmail.com> wrote:
> Unknown command: sqaush 43ce3ae my commit message
> Please fix this in the file
> /home/lenka/hermes2d/.git/.dotest-merge/git-rebase-todo.
>
> Moreover it jumped from my branch to (no branch).
>
> So I corrected it in "git-rebase-todo" and saved, but I don't know what to
> do next.
Try "git rebase --continue"
^ permalink raw reply
* Re: [PATCH 03/14] Define SNPRINTF_SIZE_CORR=1 for Microsoft Visual C++
From: Johan 't Hart @ 2009-08-21 21:18 UTC (permalink / raw)
To: Junio C Hamano
Cc: Marius Storm-Olsen, Johannes.Schindelin, msysgit, git, lznuaa
In-Reply-To: <7vr5v4dgz0.fsf@alter.siamese.dyndns.org>
Junio C Hamano schreef:
> Marius Storm-Olsen <mstormo@gmail.com> writes:
>
>> From: Frank Li <lznuaa@gmail.com>
>>
>> The Microsoft C runtime's vsnprintf function does not add NUL at
>> the end of the buffer.
> So if my reading is correct, it is not about "does not add NUL at the end"
> at all; it is "adds NUL beyond the end of given output buffer."
>
As far as I know, the windows implementation does not add a terminating
NUL when the string to write is greater or equal to the given buffer
size. Otherwise it does add the NUL.
Same as for strncpy() on windows.
In my experience the windows implementation does never write behind the
given buffer, not even a terminating zero.
^ permalink raw reply
* Re: [PATCH 09/14] Avoid including windows.h in winansi.c for MSVC build
From: Reece Dunn @ 2009-08-21 21:16 UTC (permalink / raw)
To: Junio C Hamano
Cc: Marius Storm-Olsen, Johannes.Schindelin, msysgit, git, lznuaa
In-Reply-To: <7vmy5sdgoc.fsf@alter.siamese.dyndns.org>
2009/8/21 Junio C Hamano <gitster@pobox.com>:
> Marius Storm-Olsen <mstormo@gmail.com> writes:
>
>> From: Frank Li <lznuaa@gmail.com>
>>
>> compat/msvc.h includes winsock2.h which conflicts with windows.h.
>> msvc.h also defines the oldest Windows API version required.
>
> The first sentence sort-of makes sense; compat/msvc.h will be included by
> git-compat-util.h and including <windows.h> here will bring conflicting
> definitions, so we avoid doing so when on MSC.
>
> The second sentence does not make any sense to me. It may be correctly
> stating a fact (i.e. "defines required WAPI version"), but it is unclear
> what relevance it has to this change to stop including <windows.h>.
The way things are configured, windows.h is pulling in winsock.h. In
git-compat-util.h, winsock2.h is included which has conflicting
definitions of various functions and data structures.
> Having said that, the first sentence hints me that perhaps you guys should
> include (conditionally only on windows but not with MSC) <windows.h> not
> from this file, but from git-compat-util.h?
It would make sense for windows.h to be included in git-compat-util.h.
According to http://social.msdn.microsoft.com/Forums/en-US/windowssdk/thread/4a90b143-1fb8-43e9-a54c-956127e0c579,
the following will work:
#define _WINSOCKAPI_ // stops windows.h including winsock.h
#include <winsock2.h>
#include <windows.h>
Also, if you define WIN32_LEAN_AND_MEAN, windows.h will pull in a
subset of the Windows header files (which also improves compilation
times). Adding this may prevent it from pulling in winsock.h. This
would be a better approach (and would make sense to go into
git-compat-util.h).
I don't have access to a Windows dev box at the moment, so can't
verify that this does indeed work.
- Reece
^ permalink raw reply
* git rebase --interactive problem
From: Lenka Dubcova @ 2009-08-21 21:12 UTC (permalink / raw)
To: git
Hi,
I wanted to squash one commit to another using git rebase --interactive
HEAD~2, but I made a typo, instead of squash I wrote sqaush, so it stopped
and left this message
Unknown command: sqaush 43ce3ae my commit message
Please fix this in the file
/home/lenka/hermes2d/.git/.dotest-merge/git-rebase-todo.
Moreover it jumped from my branch to (no branch).
So I corrected it in "git-rebase-todo" and saved, but I don't know what to
do next.
Thanks,
Lenka
--
View this message in context: http://n2.nabble.com/git-rebase-interactive-problem-tp3492625p3492625.html
Sent from the git mailing list archive at Nabble.com.
^ permalink raw reply
* Re: Continue git clone after interruption
From: Nicolas Pitre @ 2009-08-21 21:07 UTC (permalink / raw)
To: Jakub Narebski; +Cc: Tomasz Kontusz, git, Johannes Schindelin, Scott Chacon
In-Reply-To: <200908211207.38555.jnareb@gmail.com>
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.
> You make use here of a few facts:
>
> 1. Objects in packfile are _usually_ sorted in recency order, with most
> recent commits, and most recent versions of trees and tags being in
> the front of pack file, and being base objects for a large set of
> objects. Note the "usually" part; it is not set in stone as for RCS
> (and CVS) reverse delta based repository format.
Exact. In theory the object order could be totally random and the pack
would still be valid. The only restriction at the moment has to do with
OFS_DELTA objects as the reference to the base object is encoded as a
downward offset from the beginning of that OFS_DELTA object. Hence the
base object has to appear first. In the case of REF_DELTA objects, the
base can be located anywhere in the pack (or anywhere else outside of
the pack in the thin pack case).
> 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.
> 3. git-archive output is stable. _git-archive can be made resumable_
> (with range/partial requests), and can be made so it can create
> single-head depth 0 shallow clone.
>
> Also, with top-down deepening order even if you don't use
> 'git clone --continue' but 'git clone --skip' (or something), you
> would have got usable shallow clone. In the most extreme case when
> you are able to get only the fully resumable part, i.e. git-archive
> part (with top commit), you would have single-branch depth 0
> shallow clone (not very usable, but still better than nothing).
Right.
> > A special
> > mode to pack-object could place commit objects only after all the
> > objects needed to create that revision. So once you get a commit object
> > on the receiving end, you could assume that all objects reachable from
> > that commit are already received, or you had them locally already.
>
> Yes, with such mode (which I think wouldn't reduce / interfere with
> ability for upload-pack to pack more tightly by reordering objects
> and choosing different deltas) it would be easy to do a salvage of
> a partially completed / transferred packfile. Even if there is no
> extension to tell git server which objects we have ("have" is only
> about commits), if there is at least one commit object in received
> part of packfile, we can try to continue from later (from more);
> there is less left to download.
Exact. Suffice to set the last received commit(s) (after validation) as
one of the shallow points.
> >> Documentation/technical/shallow.txt doesn't cover "shallow", "unshallow"
> >> and "deepen" commands from 'shallow' capability extension to git pack
> >> protocol (http://git-scm.com/gitserver.txt).
> >
> > 404 Not Found
> >
> > Maybe that should be committed to git in Documentation/technical/ as
> > well?
>
> 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.
> The description in Documentation/technical/pack-protocol.txt is very
> brief, and Documentation/technical/shallow.txt doesn't cover 'shallow'
> capability of git pack protocol.
Yeah. I finally had a look directly at the code to understand how it
works.
> >> P.S. As you can see implementing resumable clone isn't easy...
> >
> > I've been saying that all along for quite a while now. ;-)
>
> Well, on the other hand side we have example of how long it took to
> come to current implementation of git submodules. But if finally
> got done.
In this case there is still no new line of code what so ever. Thinking
it through is what takes time.
> The git-archive + deepening approach you proposed can be split into
> smaller individual improvements. You don't need to implement it all
> at once.
>
> 1. Improve deepening of shallow clone. This means sending only required
> objects, and being able to use as a base objects that other side has
> and send thin pack.
Yes. And now that I understand how shallow clones are implemented, I
Probably will fix that flaw soon. Won't be hard at all.
> 2. Add support for resuming (range request) of git-archive. It is up
> to client to translate size of partial transfer of compressed file
> into range request of original (uncompressed) archive.
>
> 3. Create new git-archive pseudoformat, used to transfer single commit
> (with commit object and original branch name in some extended header,
> similar to how commit ID is stored in extended pax header or ZIP
> comment). It would imply not using export-* gitattributes.
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.
> 4. Implement alternate ordering of objects in packfile, so commit object
> is put immediately after all its prerequisites.
That would require some changes in the object enumeration code which is
an area of the code I don't know well.
> 5. Implement 'salvage' operation, which given partially transferred
> packfile would deepen shallow clone, or advance tracking branches,
> ensuring that repository would pass fsck after this operation.
>
> Probably requires 4; might be not possible or much harder to salvage
> anything with current ordering of objects in packfile.
>
> 6. Implement resumable clone ("git clone --keep <URL> [<directory>]",
> "git clone --resume" / "git clone --continue", "git clone --abort",
> "git clone --make-shallow" / "git clone --salvage").
Right. This is all doable fairly easily.
Nicolas
^ permalink raw reply
* Re: [PATCH 01/14] Fix non-constant array creation
From: Junio C Hamano @ 2009-08-21 21:04 UTC (permalink / raw)
To: Erik Faye-Lund
Cc: Marius Storm-Olsen, Johannes.Schindelin, msysgit, git, lznuaa
In-Reply-To: <40aa078e0908210641m660b003do6f637535293672ae@mail.gmail.com>
Erik Faye-Lund <kusmabite@googlemail.com> writes:
> How about using alloca instead?
I tend to avoid it; historically, alloca has been a worse portability
nightmare.
^ permalink raw reply
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