Hi Jens,
(sorry for the dup. gmail insists on sending html)
I know I saw a few threads regarding support for moving submodules but I
lost track of the discussion.
At $dayjob we were discussing a potential re-org of our super-projects
to introduce a bit of hierarchy to the submodules (at the mome
I'm fairly new to git and am trying to determine if git subtree would
be helpful for managing our company's codebase, which has several
repos some of which depend on each other. All the examples I've seen
make sense to me as a one-time operation to merge separate repos into
one monolithic one or to
Hi Junio,
Additional pull request for git 1.8.2 l10n round 3, which has
Germany translation updates.
The following changes since commit 4dac0679feaebbf6545daec14480cf6b94cb74ed:
Git 1.8.2-rc1 (2013-02-25 09:03:26 -0800)
are available in the git repository at:
git://github.com/git-l10n/git-
Many times I checkout a remote branch, or a tag and after a while I
forget remember what ref I checked it out from. Saving the original
ref would help (or is it already saved somewhere?).
This exploits the fact that FETCH_HEAD stores extra info after the
SHA-1 and at least C Git is prepared to ign
Nguyễn Thái Ngọc Duy writes:
> Many times I checkout a remote branch, or a tag and after a while I
> forget remember what ref I checked it out from. Saving the original
> ref would help (or is it already saved somewhere?).
It is :-). Try e.g.
git checkout --detach
git checkout -
(analogous
On Tue, Feb 26, 2013 at 9:37 PM, Matthieu Moy
wrote:
> Nguyễn Thái Ngọc Duy writes:
>
>> Many times I checkout a remote branch, or a tag and after a while I
>> forget remember what ref I checked it out from. Saving the original
>> ref would help (or is it already saved somewhere?).
>
> It is :-).
On Mon, 2013-02-25 at 13:16 -0800, Junio C Hamano wrote:
> Carlos Martín Nieto writes:
>
> >> As packed-refs file is expected to be a text file, it is not
> >> surprising to get an undefined result if the it ends with an
> >> incomplete line.
> >
> > I guess that depends on what you mean by incom
When git gc fails on no more disk space, it leaves tmp_pack files lying
around that consume whatever space was available (and fill up the disk
to 100%). Shouldn't git be deleting these files?
Running git 1.7.9 on cygwin:
# git --version
git version 1.7.9
# uname -a
CYGWIN_NT-6.1-WOW64 1.7.
Carlos Martín Nieto writes:
> Since the libgit2 parser seems to work with it, it's perfectly possible
> I did mess about with the file and then promptly forgot. An error would
> definitely not help here, but I do think a warning should be issued if
> the file isn't quite as it should be. It seems
Hi,
the command:
git stash save "some message" --keep-index
stashes everything, including the index, and adds the "--keep-index"
to the message. The manual labor of separating index hunks from hunks
to stash is lost. This is in version 1.8.1.3.
This is a user error, of course (per the man page,
"jones.noamle" writes:
> # git gc
> Counting objects: 44626, done.
> Delta compression using up to 8 threads.
> Compressing objects: 100% (7756/7756), done.
> fatal: sha1 file '.git/objects/pack/tmp_pack_uJ0E5b' write error: No
> space left on device
In general when we encounter an unexpected er
Gunnlaugur Thor Briem writes:
> the command:
>
> git stash save "some message" --keep-index
>
> stashes everything, including the index, and adds the "--keep-index"
> to the message. The manual labor of separating index hunks from hunks
> to stash is lost. This is in version 1.8.1.3.
>
> This is
Hi Karsten,
On Tue, 26 Feb 2013, Karsten Blees wrote:
> @Pat, Dscho: the rebase-merge script should automatically drop patches
> found in upstream, correct?
Yep, that's the idea. Under some circumstances, --cherry will fail to pick
up on it and the commits will still be marked for 'pick', but wh
Junio C Hamano writes:
> Gunnlaugur Thor Briem writes:
>
>> the command:
>>
>> git stash save "some message" --keep-index
>>
>> stashes everything, including the index, and adds the "--keep-index"
>> to the message. The manual labor of separating index hunks from hunks
>> to stash is lost. This
On 26.02.13 05:08, Mark Levedahl wrote:
> On 02/25/2013 01:44 AM, Junio C Hamano wrote:
>> I was in "find leftover bits" mode today and found this thread hanging. Has
>> anything come out of this thread, or there is nothing to improve in this
>> area?
>
> The patch passed my simple tests (build
On Tue, Feb 26, 2013 at 4:10 PM, Junio C Hamano wrote:
> Then the user cannot say
>
> git stash save some message that consists of multiple words
>
> no? You may have a WIP to enhance the behaviour of one option and
> you might want to say
>
> git stash save wip: tweak behaviour o
On Mon, Feb 25, 2013 at 7:55 AM, Junio C Hamano wrote:
> Care to tie the loose end on this one, with a sign-off?
Yes, I'll get right to it, sorry for the delay!
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo i
On Tue, Feb 26, 2013 at 12:51 AM, Junio C Hamano wrote:
> My question was if msysgit folks
> want me to take your patch (which I cannot test myself) and then
> merge my tree to the msysgit tree as part of their regular updates
> to catch up with 1.8.2 (and future releases), or they want to test
>
This reverts commit 78457bc0ccc1af8b9eb776a0b17986ebd50442bc.
commit 28c5d9e ("vcs-svn: drop string_pool") previously removed
the only call-site for strtok_r. So let's get rid of the compat
implementation as well.
Signed-off-by: Erik Faye-Lund
Reviewed-by: Jonathan Nieder
---
Makefile
Matthieu Moy writes:
> I didn't even know that multi-words messages would be allowed this way.
> That seems to me to be really weird indeed.
Yeah, but it is understandable why it was done that way, considering
taht the whole point of "stash" is to save away quickly for higher
priority interrupt.
Thanks.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Hi Mike,
Mike Gorchak wrote:
> diff --git a/config.mak.uname b/config.mak.uname
> index 8743a6d..2d42ffe 100644
> --- a/config.mak.uname
> +++ b/config.mak.uname
> @@ -527,14 +527,21 @@ ifeq ($(uname_S),QNX)
> HAVE_STRINGS_H = YesPlease
> NEEDS_SOCKET = YesPlease
> NO_FNMATCH_CAS
Thanks.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Mike Gorchak writes:
>> Also, please leave the "autodetection" out. If it is common to have
>> strcasestr (or any other) on a newer QNX, then not defining the
>> symbol NO_STRCASESTR in this file may still be the right thing to
>> do, but the justification for such a change should not be because
Hi,
On Tue, Feb 26, 2013 at 12:25 PM, Matt Kraai wrote:
> I didn't realize that QNX 6.3.2 provided getpagesize. Its header
> files don't provide a prototype, so when I saw the warning, I assumed
> it wasn't available. Since NO_GETPAGESIZE is only used by QNX, if
> it's OK to reintroduce the war
Am 26.02.2013 09:09, schrieb Chris Packham:
> At $dayjob we were discussing a potential re-org of our super-projects
> to introduce a bit of hierarchy to the submodules (at the moment it's
> fairly flat). One downside of this is the potential loss of locally
> committed work. There is also a cost i
> Is there a point to the version checking? I don't know that anyone
> has tried to build Git on QNX 4, so adding a case for it seems
> misleading.
getpagesize() was introduced in QNX 6.4.1, it is present in QNX 6.5.0
also. So at least for this version checking is requied.
> I didn't realize tha
> I saw Matt has comment on this patch, so I'll keep the patch out of
> 'next' for now and let you two figure it out.
Anyway in current form this patch is broken. Junio, may I ask you
about the rest patches in a separate posts, have you applied any of
them?
Thanks.
--
To unsubscribe from this lis
> I don't think it's a good idea to just enable thread support. On QNX,
> once a process creates a thread, fork stops working. This breaks
> commands that create threads and then try to run other programs, such
> as "git fetch" with an https remote. If threads are enabled, I think
> that the use
> The test does _not_ fail. That if condition does return -1 on Linux
> and BSD, and making tm_to_time_t() return a failure, but the caller
> goes on, ending up with the right values in year/month/date in the
> tm struct, which is the primary thing the function is used for.
I said it wrong, test
Jeff King wrote:
> Thanks for the report. Clearly I should start running "make sparse" more
> often (the reason I don't is that it produces dozens of complaints about
> constants in /usr/include/bits/xopen_lim.h, which I could obviously care
> less about; I should look into suppressing that).
Hmm,
Jeff King wrote:
> On Sat, Feb 23, 2013 at 05:31:34PM -0500, Jeff King wrote:
>
>> On Sat, Feb 23, 2013 at 06:44:04PM +, Ramsay Jones wrote:
>>
>>> Sparse issues the following error and warnings:
>>>
>>> pkt-line.c:209:51: warning: Using plain integer as NULL pointer
>>> sideband.c:41:
Johannes Sixt wrote:
> Am 2/25/2013 7:54, schrieb Junio C Hamano:
>> Ramsay Jones writes:
>>
>>> As I mentioned recently, while discussing a cygwin specific patch
>>> (see "Version 1.8.1 does not compile on Cygwin 1.7.14" thread), the
>>> MSVC build is broken for me.
>>>
>>> The first 4 patches fi
Hi,
On Sun, Feb 24, 2013 at 09:54:43PM -0800, Junio C Hamano wrote:
> The idea to allow more kinds of sources specified for "config_file"
> structure is not bad per-se, but whenever you design an enhancement
> to something that currently supports only on thing to allow taking
> another kind, pleas
Because a config callback may start parsing a new file, the
global context regarding the current config file is stored
as a stack. Currently we only need to manage that stack from
git_config_from_file. Let's factor it out to allow new
sources of config data.
Signed-off-by: Heiko Voigt
---
Peff,
To simplify adding other sources we extract all functions needed for
parsing into a list of callbacks. We implement those callbacks for the
current file parsing. A new source can implement its own set of callbacks.
Instead of storing the concrete FILE pointer for parsing we store a void
pointer. A
This can be used to read configuration values directly from gits
database.
Signed-off-by: Heiko Voigt
---
.gitignore | 1 +
Makefile | 1 +
cache.h| 1 +
config.c | 47 +++
t/t1300-repo-config.
The only location where cf is set in this file is in do_config_from().
This function has only one callsite which is config_from_file(). In
config_from_file() its ensured that the f member is set to non-zero.
Signed-off-by: Heiko Voigt
---
config.c | 4 ++--
1 file changed, 2 insertions(+), 2 del
Am 25.02.2013 20:01, schrieb Johannes Schindelin:
> Can you please send a pull request on GitHub?
It's not github, but hopefully useful for you:
The following changes since commit bcd45b4085f9269a536c8fb1963ac8380bfac0e8:
Update draft release notes to 1.8.2 (2013-02-01 12:52:08 -0800)
are ava
Hello,
I'm trying to investigate some what changes have been done between two versions
of a software with the name IP.Board.
This proves more troublesome than I thought, since their release builder
appearantly updates the version number automatically in all files.
This causes a lot of files
On Tue, Feb 26, 2013 at 08:38:50PM +0100, Heiko Voigt wrote:
> Because a config callback may start parsing a new file, the
> global context regarding the current config file is stored
> as a stack. Currently we only need to manage that stack from
> git_config_from_file. Let's factor it out to allo
On Tue, Feb 26, 2013 at 08:40:23PM +0100, Heiko Voigt wrote:
> The only location where cf is set in this file is in do_config_from().
> This function has only one callsite which is config_from_file(). In
> config_from_file() its ensured that the f member is set to non-zero.
Makes sense, although.
It seems that we have a corner case bug in two-way merge to reset
away the conflicts with "read-tree -u --reset HEAD ORIG_HEAD".
In a freshly created repository:
rm -f A Z
for i in $(seq 100)
do
echo hello
done >Z
git add Z
git commit -m initial
git branch
On Tue, Feb 26, 2013 at 02:54:49PM -0500, Jeff King wrote:
> On Tue, Feb 26, 2013 at 08:38:50PM +0100, Heiko Voigt wrote:
> > +static int do_config_from(struct config_file *top, config_fn_t fn, void
> > *data)
> > +{
> > + int ret;
> > +
> > + /* push config-file parsing state stack */
> > +
Hi,
Please include me in the Cc field, since I'm not subscribed to the
list.
Mike Gorchak wrote:
> Do you have a testcase for this (without using git codebase)? I wrote
> numerous resource managers since QNX 6.0 using threads and fork()s for
> daemonization in different order and never experience
On Tue, Feb 26, 2013 at 09:09:41PM +0100, Heiko Voigt wrote:
> > This function name is a bit weird. I would have thought the "from" here
> > was going to be a file, or a string, or whatever. But the filename setup
> > happens outside this function (and yet this function depends on it being
> > set
On Tue, Feb 26, 2013 at 12:06:42PM -0800, Junio C Hamano wrote:
> It seems that we have a corner case bug in two-way merge to reset
> away the conflicts with "read-tree -u --reset HEAD ORIG_HEAD".
Isn't this a repeat of:
http://thread.gmane.org/gmane.comp.version-control.git/202440/focus=21231
On 26/02/13 00:04, Junio C Hamano wrote:
Philip Oakley writes:
On 25/02/13 05:29, Junio C Hamano wrote:
...
In other words, can't you change the side that launches the document
viewer so that we do not have to rename anything in the first place?
The current help code will only show either '
Am 26.02.2013 17:07, schrieb Junio C Hamano:
> "jones.noamle" writes:
>
>> # git gc
>> Counting objects: 44626, done.
>> Delta compression using up to 8 threads.
>> Compressing objects: 100% (7756/7756), done.
>> fatal: sha1 file '.git/objects/pack/tmp_pack_uJ0E5b' write error: No
>> space left o
> If I remove the call to pthread_create, it doesn't output anything and
> exits successfully.
I see. Most resource managers use procmgr_daemon(), which has no such
limitation. Anyway, as far as I can see current git sources do not use
fork together with pthread, except for daemonize() function.
-
The logic described in d020e27 (diff: Fix rename pretty-print when
suffix and prefix overlap, 2013-02-23) is wrong: The proof in the
comment is valid only if both strings are the same length. *One* of
old/new can reach a-1 (b-1, resp.) if 'a' is a suffix of 'b' (or vice
versa).
Since the intent w
Am 26.02.2013 21:32, schrieb Mike Gorchak:
>> If I remove the call to pthread_create, it doesn't output anything and
>> exits successfully.
>
> I see. Most resource managers use procmgr_daemon(), which has no such
> limitation. Anyway, as far as I can see current git sources do not use
> fork toge
On Tue, Feb 26, 2013 at 10:32:16PM +0200, Mike Gorchak wrote:
> I see. Most resource managers use procmgr_daemon(), which has no such
> limitation. Anyway, as far as I can see current git sources do not use
> fork together with pthread, except for daemonize() function.
If threads are enabled, git
Jeff King writes:
> On Tue, Feb 26, 2013 at 12:06:42PM -0800, Junio C Hamano wrote:
>
>> It seems that we have a corner case bug in two-way merge to reset
>> away the conflicts with "read-tree -u --reset HEAD ORIG_HEAD".
>
> Isn't this a repeat of:
>
> http://thread.gmane.org/gmane.comp.version
Thomas Rast writes:
> The logic described in d020e27 (diff: Fix rename pretty-print when
> suffix and prefix overlap, 2013-02-23) is wrong: The proof in the
> comment is valid only if both strings are the same length. *One* of
> old/new can reach a-1 (b-1, resp.) if 'a' is a suffix of 'b' (or vi
Jeff King writes:
> I wonder if it would be more obvious with the more usual OO-struct
> functions, like:
>
> struct config_source {
> ...
> };
> void config_source_init_file(struct config_source *, const char *fn);
> void config_source_init_strbuf(struct config_source *,
>
Heiko Voigt writes:
> The "do_config_from" means "parse from whatever is in 'top'". Later in
> the series its type changes from config_file to struct config.
Yuck. It would be nice to have it as struct config_src or
something. "struct config" sounds as if it represents the entire
configuration
Here are the topics that have been cooking. Commits prefixed with
'-' are only in 'pu' (proposed updates) while commits prefixed with
'+' are in 'next'.
The tip of the 'master' is a bit past 1.8.2-rc1. I am hoping to do
an -rc2 by the end of this week.
You can find the changes described here in
Various programs that I use ([Open|Libre]Office, Vym, etc) use a
zipped/.tgz'ed file format, usually containing multiple
(usually) plain-text files within.
I'm trying to figure out a way for git to treat these as virtual
directories for purposes of merging/diffing.
Reading up on clean/smudge fi
From: "Philip Oakley"
Sent: Sunday, February 24, 2013 9:50 PM
From: "Junio C Hamano"
Sent: Sunday, February 24, 2013 8:59 AM
David Aguilar writes:
This is referring to "git the command", not "git the system",
so it should not be changed according to the rule that was
applied when many "git"
I was on my master branch, I then checked out a branch (
origin/somebranch ), made no updates
but did a few git pulls on the branch over about a week; then made a
small change to only a single file & committed & pushed.
Now am trying to go back to my master branch and get:
error: The following
On Wed, Feb 27, 2013 at 2:01 AM, Jens Lehmann wrote:
> Am 26.02.2013 17:07, schrieb Junio C Hamano:
>> "jones.noamle" writes:
>>
>>> # git gc
>>> Counting objects: 44626, done.
>>> Delta compression using up to 8 threads.
>>> Compressing objects: 100% (7756/7756), done.
>>> fatal: sha1 file '.git
In commit 9db31bdf (submodule: Add --force option for git submodule
update, 2011-04-01) we added the option to the implementation's usage
synopsis but forgot to add it to the synopsis in the command
documentation. Add the option to the synopsis in the same location it
is reported in usage and re-w
On Wed, Feb 27, 2013 at 05:58:20AM +0530, Sitaram Chamarty wrote:
> > Ack. I just recently had to do
> >
> >git gc || rm -f .git/objects/*/tmp_*
> >
> > as workaround in the nightly housekeeping script on our CI server.
>
> it's not just 'git gc'; a failed push of a large repo (failed due to,
On Tue, Feb 26, 2013 at 04:08:55PM -0700, J.V. wrote:
> I was on my master branch, I then checked out a branch (
> origin/somebranch ), made no updates
> but did a few git pulls on the branch over about a week; then made a
> small change to only a single file & committed & pushed.
>
> Now am tryi
Am 2/26/2013 23:38, schrieb Tim Chase:
> Various programs that I use ([Open|Libre]Office, Vym, etc) use a
> zipped/.tgz'ed file format, usually containing multiple
> (usually) plain-text files within.
>
> I'm trying to figure out a way for git to treat these as virtual
> directories for purposes o
On 02/22/2013 09:57 PM, Adam Mercer wrote:
> I'm trying to setup the post-receive-email hook, from contrib, using a
> custom_showrev, from the script I do this by setting hooks.showrev
>
> # hooks.showrev
> # The shell command used to format each revision in the email, with
> # "%s" replaced w
On Tue, Feb 26, 2013 at 02:10:03PM -0800, Junio C Hamano wrote:
> Jeff King writes:
>
> > I wonder if it would be more obvious with the more usual OO-struct
> > functions, like:
> >
> > struct config_source {
> > ...
> > };
> > void config_source_init_file(struct config_source *,
On Tue, Feb 26, 2013 at 03:05:56PM -0500, Jeff King wrote:
> On Tue, Feb 26, 2013 at 08:40:23PM +0100, Heiko Voigt wrote:
>
> > The only location where cf is set in this file is in do_config_from().
> > This function has only one callsite which is config_from_file(). In
> > config_from_file() its
On Tue, Feb 26, 2013 at 02:12:23PM -0800, Junio C Hamano wrote:
> Heiko Voigt writes:
>
> > The "do_config_from" means "parse from whatever is in 'top'". Later in
> > the series its type changes from config_file to struct config.
>
> Yuck. It would be nice to have it as struct config_src or
> s
70 matches
Mail list logo
