* Deprecated help message
From: Jeroen van der Ham @ 2012-11-06 9:44 UTC (permalink / raw)
To: git
Hi,
It seems I hit a deprecated help message:
% git pull
There is no tracking information for the current branch.
Please specify which branch you want to merge with.
See git-pull(1) for details
git pull <remote> <branch>
If you wish to set tracking information for this branch you can do so with:
git branch --set-upstream nsiv2 origin/<branch>
% git branch --set-upstream nsiv2 origin/nsiv2
The --set-upstream flag is deprecated and will be removed. Consider using --track or --set-upstream-to
Branch nsiv2 set up to track remote branch nsiv2 from origin.
Jeroen.
^ permalink raw reply
* Bug: write-tree corrupts intent-to-add index state
From: Jonathon Mah @ 2012-11-06 8:53 UTC (permalink / raw)
To: git@vger.kernel.org
Hi revisionaries,
I came across what appears to be a bug while working today. I had several changes, both staged and unstaged, and two files that I had marked with intent-to-add (git add -N).
$ git status -sb
## Library-3.x...origin/Library-3.x [ahead 4]
M Library/LIRootSource.m
M Library/Library.xcodeproj/project.pbxproj
[...]
M Library/SceneKit/LISceneKitBookshelfScene.m
AM Library/SceneKit/LISceneKitDisplayedMediumProxy.h
AM Library/SceneKit/LISceneKitDisplayedMediumProxy.m
(The last two files were added with -N.) I then attempted to stash my work, but that failed:
$ git stash -k
error: Entry 'Library/SceneKit/LISceneKitDisplayedMediumProxy.h' not uptodate. Cannot merge.
Cannot save the current worktree state
Re-checking the status showed that the intent-to-add files were now simply modified, yet they did not appear in git ls-tree -r HEAD.
$ git status -sb
## Library-3.x...origin/Library-3.x [ahead 4]
M Library/LIRootSource.m
M Library/Library.xcodeproj/project.pbxproj
[...]
M Library/SceneKit/LISceneKitBookshelfScene.m
M Library/SceneKit/LISceneKitDisplayedMediumProxy.h
M Library/SceneKit/LISceneKitDisplayedMediumProxy.m
It appears the index forgot that those files were new. So not only has the intent-to-add status been lost, but git status shows a file existing in neither HEAD nor the index as not-new-but-modified.
Tracing through it, I narrowed it down to git write-tree affecting the index state. As far as I can tell, it's incorrect for that command to change the index. I'm now out of my (shallow) depth in the git codebase, so I'm throwing it out there for someone to tackle (hopefully). I've attached a failing test case.
Additional notes for bug hunters:
- I've only seen files in already-existing subdirectories lose intent-to-add status, whereas marking a file in the top-level as i-t-a is preserved during write-tree.
- The 'git ls-files -s --debug' output doesn't change across the write-tree:
100644 e69de29bb2d1d6434b8b29ae775ad8c2e48c5391 0 dir/baz
ctime: 0:0
mtime: 0:0
dev: 0 ino: 0
uid: 0 gid: 0
size: 0 flags: 20004000
---
t/t2203-add-intent.sh | 22 ++++++++++++++++++++++
1 file changed, 22 insertions(+)
diff --git a/t/t2203-add-intent.sh b/t/t2203-add-intent.sh
index ec35409..fcc67c0 100755
--- a/t/t2203-add-intent.sh
+++ b/t/t2203-add-intent.sh
@@ -62,5 +62,27 @@ test_expect_success 'can "commit -a" with an i-t-a entry' '
git commit -a -m all
'
+test_expect_success 'i-t-a status unaffected by write-tree' '
+ git reset --hard &&
+ mkdir dir &&
+ echo frotz >dir/bar &&
+ git add dir &&
+ git commit -m "establish dir" &&
+ echo fizfaz >foo &&
+ echo fragz >dir/baz &&
+ git add rezrov &&
+ git add -N foo &&
+ git add -N dir/baz &&
+ cat >expect <<-\EOF &&
+ AM dir/baz
+ AM foo
+ EOF
+ git status --untracked-files=no --porcelain >actual &&
+ test_cmp actual expect &&
+ git write-tree &&
+ git status --untracked-files=no --porcelain >actual &&
+ test_cmp actual expect
+'
+
test_done
--
1.8.0
Jonathon Mah
me@JonathonMah.com
^ permalink raw reply related
* Re: git-p4 clone @all error
From: Arthur @ 2012-11-06 8:55 UTC (permalink / raw)
To: git
In-Reply-To: <20121106002515.5b7eba50@fenix.utopia.dhis.org>
Thanks for your support,
If i get latest révision on Perforce i have this errors :
/ 590 errors reported
Librarian checkout
depot/mainline/02_subsystem/10_arinc_429/00_cots/01_bsp_aim/original
files/api429decryption.txt failed.
open for read:
depot/mainline/02_subsystem/10_arinc_429/00_cots/01_bsp_aim/original
files/api429decryption.txt,v: Le fichier spcifi est introuvable.
Librarian checkout
depot/mainline/02_subsystem/10_arinc_429/00_cots/01_bsp_aim/original
files/api429linuxrelnotes.pdf failed.
open for read:
depot/mainline/02_subsystem/10_arinc_429/00_cots/01_bsp_aim/original
files/api429linuxrelnotes.pdf,d\1.1150: Le chemin d'accs spcifi est
introuvable.
Librarian checkout
depot/mainline/02_subsystem/10_arinc_429/00_cots/01_bsp_aim/original
files/lien vers readme.txt failed.
.../
Perforce can't find the files because they were removed. (option
obliterate...)
So the error on the Perforce clone may come from this.
How i can show git-p4.branchList ?
My depot structure :
MAINLINE
DEV_DATA
RELEASE_1.0
RELEASE_1.0.0
--
View this message in context: http://git.661346.n2.nabble.com/git-p4-clone-all-error-tp7570219p7570622.html
Sent from the git mailing list archive at Nabble.com.
^ permalink raw reply
* Re: [PATCH 1/4] strbuf_split_buf(): use ALLOC_GROW()
From: Michael Haggerty @ 2012-11-06 7:54 UTC (permalink / raw)
To: Jeff King; +Cc: Junio C Hamano, git
In-Reply-To: <20121104114101.GA336@sigill.intra.peff.net>
On 11/04/2012 12:41 PM, Jeff King wrote:
> On Sun, Nov 04, 2012 at 07:46:51AM +0100, Michael Haggerty wrote:
>
>> Use ALLOC_GROW() rather than inline code to manage memory in
>> strbuf_split_buf(). Rename "pos" to "nr" because it better describes
>> the use of the variable and it better conforms to the "ALLOC_GROW"
>> idiom.
>
> I suspect this was not used originally because ALLOC_GROW relies on
> alloc_nr, which does fast growth early on. At (x+16)*3/2, we end up with
> 24 slots for the first allocation. We are typically splitting 1 or 2
> values.
>
> It probably doesn't make a big difference in practice, though, as we're
> talking about wasting less than 200 bytes on a 64-bit platform, and we
> do not tend to keep large numbers of split lists around.
I did a little bit of archeology, and found out that
* ALLOC_GROW() did indeed exist when this code was developed, so it
*could have* been used.
* OTOH, I didn't find any indication on the mailing list that the
choice not to use ALLOC_GROW() was a conscious decision.
So history doesn't give us much guidance.
If the size of the initial allocation is a concern, then I would suggest
adding a macro like ALLOC_SET_SIZE(ary,nr,alloc) that could be called to
initialize the size to some number less than 24. Such a macro might be
useful elsewhere, too. It wouldn't, of course, slow the growth rate
*after* the first allocation.
FWIW, the "max" parameter of strbuf_split*() is only used in one place,
though strbuf_split*() is used in some other places where not too many
substrings would be expected.
I am working on some patch series that will eliminate even more uses of
strbuf_split*(), so I won't work more on optimizing its resource usage
unless somebody gives me a stronger nudge.
Michael
--
Michael Haggerty
mhagger@alum.mit.edu
http://softwareswirl.blogspot.com/
^ permalink raw reply
* Re: Support for a series of patches, i.e. patchset or changeset?
From: Johannes Sixt @ 2012-11-06 7:44 UTC (permalink / raw)
To: Eric Miao; +Cc: Michael J Gruber, git
In-Reply-To: <CAMPhdO_yK02r4c5tTZxFGikmcPiG4G=PMzsPrYOtKCR51Ep0sw@mail.gmail.com>
Am 11/6/2012 7:56, schrieb Eric Miao:
> On Tue, Nov 6, 2012 at 2:39 PM, Johannes Sixt <j.sixt@viscovery.net> wrote:
>> Am 11/6/2012 1:58, schrieb Eric Miao:
>>> E.g. when we merged a series of patches:
>>>
>>> [PATCH 00/08]
>>> [PATCH 01/08]
>>> ...
>>> [PATCH 08/08]
>>>
>>> How do we know this whole series after merged when only one of these
>>> commits are known?
>>
>> You can use git name-rev. For example:
>>
>> $ git name-rev 9284bdae3
>> 9284bdae3 remotes/origin/pu~2^2~7
>>
>> This tell you that the series was merged two commits before origin/pu, and
>> then it is the 7th from the tip of the series. Now you can
>>
>> $ git log origin/pu~2^..origin/pu~2^2
>>
>> to see the whole series.
>
> I'm just curious how this is implemented in git, are we keeping the info
> of the series that's applied in a whole?
If the maintainer did his job well, then everything that you had in [PATCH
01/08] ... [PATCH 08/08] is in the commits of the series, and [PATCH
00/08] (the cover letter) is in the commit that merged the series.
Anything else that I didn't mention but you consider as "the info of the
series"?
> But this still looks like be inferred basing on a branch head, and I'm
> afraid this may not be applicable in every case.
What's the problem? That it's inferred? Or that it needs a branch head?
-- Hannes
^ permalink raw reply
* Re: [PATCH v4 6/8] longest_ancestor_length(): require prefix list entries to be normalized
From: Michael Haggerty @ 2012-11-06 7:34 UTC (permalink / raw)
To: Ramsay Jones
Cc: Jeff King, Junio C Hamano, Jiang Xin, Lea Wiemann, Johannes Sixt,
git, David Aguilar
In-Reply-To: <50901B31.7000402@ramsay1.demon.co.uk>
On 10/30/2012 07:23 PM, Ramsay Jones wrote:
> [...]
> Just to be clear, this is true for the MinGW port to Windows, but *not*
> the cygwin port.
>
> [...]
>
> ditto
Thanks for clarifying these points. It seems like this patch series is
not going to be usable (because of fears that it might cause performance
degradation in some as-yet-unexplained scenarios), but if that situation
seems to change then I will incorporate your corrections.
Michael
--
Michael Haggerty
mhagger@alum.mit.edu
http://softwareswirl.blogspot.com/
^ permalink raw reply
* Re: Support for a series of patches, i.e. patchset or changeset?
From: Eric Miao @ 2012-11-06 6:56 UTC (permalink / raw)
To: Johannes Sixt; +Cc: Michael J Gruber, git
In-Reply-To: <5098B09B.7060501@viscovery.net>
On Tue, Nov 6, 2012 at 2:39 PM, Johannes Sixt <j.sixt@viscovery.net> wrote:
> Am 11/6/2012 1:58, schrieb Eric Miao:
>> On Mon, Nov 5, 2012 at 10:40 PM, Michael J Gruber
>> <git@drmicha.warpmail.net> wrote:
>>> Eric Miao venit, vidit, dixit 05.11.2012 15:12:
>>>> The problem is, most cases we have no idea of the base rev1, and commit rev2
>>>> which it's leading up to. E.g. for a single patch which is between
>>>> commit rev1..rev2,
>>>> how do we find out rev1 and rev2.
>>
>> E.g. when we merged a series of patches:
>>
>> [PATCH 00/08]
>> [PATCH 01/08]
>> ...
>> [PATCH 08/08]
>>
>> How do we know this whole series after merged when only one of these
>> commits are known?
>
> You can use git name-rev. For example:
>
> $ git name-rev 9284bdae3
> 9284bdae3 remotes/origin/pu~2^2~7
>
> This tell you that the series was merged two commits before origin/pu, and
> then it is the 7th from the tip of the series. Now you can
>
> $ git log origin/pu~2^..origin/pu~2^2
>
> to see the whole series.
I'm just curious how this is implemented in git, are we keeping the info
of the series that's applied in a whole?
But this still looks like be inferred basing on a branch head, and I'm
afraid this may not be applicable in every case.
>
> -- Hannes
^ permalink raw reply
* Re: Support for a series of patches, i.e. patchset or changeset?
From: Johannes Sixt @ 2012-11-06 6:39 UTC (permalink / raw)
To: Eric Miao; +Cc: Michael J Gruber, git
In-Reply-To: <CAMPhdO-Z3E352KbTvnrxJqCecAUGfHCwOoFRUKzObh35uLnrSw@mail.gmail.com>
Am 11/6/2012 1:58, schrieb Eric Miao:
> On Mon, Nov 5, 2012 at 10:40 PM, Michael J Gruber
> <git@drmicha.warpmail.net> wrote:
>> Eric Miao venit, vidit, dixit 05.11.2012 15:12:
>>> The problem is, most cases we have no idea of the base rev1, and commit rev2
>>> which it's leading up to. E.g. for a single patch which is between
>>> commit rev1..rev2,
>>> how do we find out rev1 and rev2.
>
> E.g. when we merged a series of patches:
>
> [PATCH 00/08]
> [PATCH 01/08]
> ...
> [PATCH 08/08]
>
> How do we know this whole series after merged when only one of these
> commits are known?
You can use git name-rev. For example:
$ git name-rev 9284bdae3
9284bdae3 remotes/origin/pu~2^2~7
This tell you that the series was merged two commits before origin/pu, and
then it is the 7th from the tip of the series. Now you can
$ git log origin/pu~2^..origin/pu~2^2
to see the whole series.
-- Hannes
^ permalink raw reply
* Re: Support for a series of patches, i.e. patchset or changeset?
From: Eric Miao @ 2012-11-06 0:58 UTC (permalink / raw)
To: Michael J Gruber; +Cc: git
In-Reply-To: <5097CFCB.7090506@drmicha.warpmail.net>
On Mon, Nov 5, 2012 at 10:40 PM, Michael J Gruber
<git@drmicha.warpmail.net> wrote:
> Eric Miao venit, vidit, dixit 05.11.2012 15:12:
>> The problem is, most cases we have no idea of the base rev1, and commit rev2
>> which it's leading up to. E.g. for a single patch which is between
>> commit rev1..rev2,
>> how do we find out rev1 and rev2.
>
> So, then the question is: What do you know/have? Is your patch the
> output of "git format-patch", "git diff", or just some sort of diff
> without any git information?
That doesn't matter, all the info can be obtained from the SHA1 id, the
question is: do we have a mechanism in git (or hopefully we could add)
to record the patchset or series the patch belongs to, without people to
guess heuristically.
E.g. when we merged a series of patches:
[PATCH 00/08]
[PATCH 01/08]
...
[PATCH 08/08]
How do we know this whole series after merged when only one of these
commits are known?
^ permalink raw reply
* Re: git compilation problem
From: Konstantin Khomoutov @ 2012-11-06 0:53 UTC (permalink / raw)
To: git-users-/JYPxA39Uh5TLH3MbocFFw; +Cc: git-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <f4b73b42-0c5e-40ad-9f84-e4d8d00a226a-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org>
On Mon, Nov 05, 2012 at 09:21:13AM -0800, Mathieu Dutour wrote:
First, note that this list is a support channel for Git newbies, and
your question appears to be more about Git source code itself so I'd say
it better fits the main Git list which is git at vger.kernel.org.
I Cc'ed this my response here in the hope someone with the platform
similar to yours might chime in; so please keep the Cc list in your
responses.
> I tried to install git on an IBM power 6 computer and I had the following
> problem when doing "gmake install"
This doesn't sound quite descriptive. From what I gather from the
Internet, IBM POWER 6 is a CPU brand, targeted at mainframes. I vaguely
recall IBM mainframes typically run their own OS (z/OS?) but have
extensive support for virtualization so I recall I read somewhere it's
customary to run, say, a virtualized Linux-based OS on it.
Since what matters here is a *software* platform, please be (way) more
precise about this.
> ./configure[6213]: syntax error at line 6367 : `;' unexpected
"configure" is just a shell script usually generated by the "autoconf"
program from a template file named "configure.in".
"configure" is meant to be über-portable, but it assumes your /bin/sh is
a shell implementing the command language defined by POSIX, plus a
standard set of text-processing tools (such as sed and grep) is
available.
I can make a guess that whatever is available as /bin/sh in your system
might not quite fit the expectations of "configure".
I envision two ways to fix this:
1) Install autoconf and run it to regenerate the configure script;
then try the compilation again.
2) Try to force configure using a different shell, if available.
GNU bash should cut it, ash and dash [1] too.
In either case note that there isn't any indication that that syntax
error actually made the build process to fail; the only failing error
in the output you quoted is that of the `install` command which runs
after the compilation is done to install things (obviously).
By this I mean, if you will be able to fix that `install` error it might
turn out you could ignore the configure error whatsoever.
> gmake[2]: `GIT-VERSION-FILE' is up to date.
> GEN git-instaweb
> SUBDIR git-gui
> SUBDIR gitk-git
> gmake[1]: Nothing to be done for `all'.
> SUBDIR perl
> SUBDIR git_remote_helpers
> SUBDIR templates
> install -d -m 755 '/home/ar69ovim/opt/git-1.8.0/bin'
> /usr/bin/getopt: Not a recognized flag: d
> Usage: install [-c DirectoryA] [-f DirectoryB] [-i] [-m] [-M Mode] [-O
> Owner]
> [-G Group] [-S] [-n DirectoryC] [-o] [-s] File [DirectoryX
> ...]
Supposedly Git makefiles expect the `install` program to support the
"-d" command line option. On my Linux system with `install` provided by
GNU coreutils [2], the "-d" command line option of this tool is used to
create the whole directory hierarchy according to the argument passed to
that option. Obviously your `install` does not support this option.
Moreover, from the error output it follows, that your `install` is
implemented as a shell script which calls /usr/bin/getopt to parse its
command-line options.
Again, I can see several ways to fix that:
1) Patch Git makefile(s) to use some other means to create directory
hierarchies. For instance, some versions of `mkdir` support the "-p"
command line option to do this. You could combine `mkdir -p` with
`chmod 755` to do what `install -d -m 755` would do.
2) (Somehow) get GNU coreutils and make Git makefiles see
/usr/bin/install provided by this package.
3) Patch your `install` to support "-d".
> gmake: *** [install] Error 2
That's what makes the whole thing fail.
1. http://en.wikipedia.org/wiki/Debian_Almquist_shell
2. http://gnu.org/software/coreutils
--
^ permalink raw reply
* Re: git-p4 clone @all error
From: Vitor Antunes @ 2012-11-06 0:25 UTC (permalink / raw)
To: Arthur; +Cc: Pete Wyckoff, git
In-Reply-To: <20121105221212.GA12003@padd.com>
On Mon, 5 Nov 2012 17:12:12 -0500
Pete Wyckoff <pw@padd.com> wrote:
> Thanks, that is interesting output.
>
> Adding Vitor who knows his way around the branch detection
> code. The first mail by Arthur is here, which focuses more
> on the backtrace from "p4 describe" errors, but also suggests
> something is dodgy in branch detection:
>
> http://thread.gmane.org/gmane.comp.version-control.git/208693
>
> I'm not sure if this is a --verbose run, though, as I don't see
> any chatter like "branch is xxx". So I'm not sure if the
> auto-parent detection code got run.
>
> The "unable to resolve reference" comes from refs.c, which is
> when fast-import calls update_branch() on each of the changed
> branches as it is finishing.
>
> Vitor, what could git-p4 have done to create a branch name called
> "refs/remotes/p4/depot/MAINLINE/02_SubSystem/10_ARINC_429"?
> Any other questions for Arthur?
>
Hi Arthur,
Could you please share with us your git-p4.branchList configuration?
Would it also be possible to describe a bit more on your depot
structure? I'm particularly concerned about its integration history.
I suspect the error you are experiencing is connected to a wrong
configuration. Please take into account that each entry must be in the
form of origin:destination, where "origin" is the folder used as the
source of the integration to "destination" when first created.
Vitor
^ permalink raw reply
* [PATCH] gitweb: make remote_heads config setting work.
From: Phil Pennock @ 2012-11-05 23:50 UTC (permalink / raw)
To: git, gitster
Git configuration items can not contain underscores in their name; the
'remote_heads' feature can not be enabled on a per-repository basis with
that name.
This changes the git-config option to be `gitweb.remoteheads` but does
not change the gitweb.conf option, to avoid backwards compatibility
issues. We strip underscores from keys before looking through
git-config output for them.
Signed-off-by: Phil Pennock <phil@apcera.com>"
---
gitweb/gitweb.perl | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index 10ed9e5..f2144c8 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -541,7 +541,7 @@ our %feature = (
# $feature{'remote_heads'}{'default'} = [1];
# To have project specific config enable override in $GITWEB_CONFIG
# $feature{'remote_heads'}{'override'} = 1;
- # and in project config gitweb.remote_heads = 0|1;
+ # and in project config gitweb.remoteheads = 0|1;
'remote_heads' => {
'sub' => sub { feature_bool('remote_heads', @_) },
'override' => 0,
@@ -2702,6 +2702,7 @@ sub git_get_project_config {
$key = lc($key);
}
$key =~ s/^gitweb\.//;
+ $key =~ s/_//g;
return if ($key =~ m/\W/);
# type sanity check
--
1.7.10.3
^ permalink raw reply related
* Fwd: [PATCH] Remove terminal symbols from non-terminal console
From: Michael Naumov @ 2012-11-05 23:17 UTC (permalink / raw)
To: git, gitster
In-Reply-To: <CABHRWd1T=a8Mze20G9koiTr0L2Nrq0g3vGLC9mEZ7rA45vgfSA@mail.gmail.com>
As per discussion on msysgit user group:
https://groups.google.com/forum/?fromgroups=#!topic/msysgit/U_a982_a3rc/discussion
we found the following patch is required to get rid of weird terminal
characters for other tools such as GitExtensions for Windows
---8<---
diff --git a/sideband.c b/sideband.c
index d5ffa1c..bd3e5a8 100644
--- a/sideband.c
+++ b/sideband.c
@@ -29,7 +29,7 @@ int recv_sideband(const char *me, int in_stream, int out)
memcpy(buf, PREFIX, pf);
term = getenv("TERM");
- if (term && strcmp(term, "dumb"))
+ if (isatty(out) && term && strcmp(term, "dumb"))
suffix = ANSI_SUFFIX;
else
suffix = DUMB_SUFFIX;
---8<---
^ permalink raw reply related
* git log --follow --reverse ignores --follow
From: Valentin Spreckels @ 2012-11-05 22:51 UTC (permalink / raw)
To: git; +Cc: Uli Schlachter
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi,
I found something looking like a bug:
The following lines prepares a small exmaple:
# create git repo
git init
# create file a and commit it
touch a && git add a && git commit -m first
# rename a to b and commit it
git mv a b && git commit -m second
After this git log's behavior differs from my expectations, when run
like this:
git log --follow --reverse b
Expected result:
A list of both commits starting with second or a error message if git
log cannot run with --follow and --reverse combined.
Actual result:
A list showing only the second commit.
It looks like git log silently ignores --follow when run with --reverse.
Observed with git versions 1.7.8.6 and 1.7.11.2
Valentin
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)
iQIcBAEBAgAGBQJQmEL/AAoJEANdk65I57uzbE0P/i0p8mlBcGWI+WyPqU7dhAmO
3jHLMmqNV12bm9zeNKuKxQPDS5IzMWRwDpO6GXdn8BQauQtpwB0POLXBIWl9pP2g
TOGJjIUL/Rd7+G4FF1vcSUxd9LESlPDQTL+J2F3B7+KRMRzxxsbNv/5826w7HQHg
ck6XfrmkFxoIn6w6CH6pCncRFl6cb7EqrMZIhGclJvDqXKi4DHRa3XpPRCle/Xa1
2P65kb0va+LzX2nUdfKR/WeH0V0XPURyObr/NN0ecVIrLj3roV/0OZBg/AsQwu3Z
Zw4CM5nL0DsgD81FEc8cToe5eJwi5/VH56+CbDyr+wcLj4BO4niS3eQqQKmyiJS7
2/Pny+IZOZmIJzh5+6d0puufKut877PIRoJTs0P8l+dXU9xIbzwVTTcWDpKQt5Mx
Mzi6oSpCLDuvBo+WCjanqtF2oNoLnbfq9nD/KgmIH/XTLKsryL48PFXx1b+7vGuG
hmzlcRies3Xpkx0cegzqSngl3/I1Rq8hEbJhcJA4SrJFS2sVj8lGALPgFQdhif2L
N0c5DNUD9F5pH/U11a0YnOxtkFyB+LjXqE2zN9Mz+t0TZ69+y6qZMrxHbAoeNDMX
Do22J9jgSc80VE3Cdn8Cwe/xVLoJCvc7wSUpBbTQjDhOZbv7Zbtjl1venS3/q4fk
wcOSFLYb0Heqm8Qxwf+d
=D+B2
-----END PGP SIGNATURE-----
^ permalink raw reply
* Re: how the commit ID come from in GIT?
From: Konstantin Khomoutov @ 2012-11-05 23:04 UTC (permalink / raw)
To: hong zhang; +Cc: git
In-Reply-To: <1352145846.26267.YahooMailClassic@web141404.mail.bf1.yahoo.com>
On Mon, Nov 05, 2012 at 12:04:06PM -0800, hong zhang wrote:
> Could anyone explain how the git commit ID will include all the files
> that devloper makes changes on?
>
> How git commit ID works?
To expand on the answer provided by Magnus, I would also suggest reading
the classic "Git from the bottom up" document [1], and if you want a
totally informal and fun introduction to how these cryptographic hashes
come about and why they are useful, I suggest reading
"The Git Parable" [2].
1. http://newartisans.com/2008/04/git-from-the-bottom-up/
2. http://tom.preston-werner.com/2009/05/19/the-git-parable.html
^ permalink raw reply
* Re: "git am" crash (builtin/apply.c:2108) + small repro
From: Alexey Spiridonov @ 2012-11-05 22:55 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Björn Gustavsson, Nguyen Thai Ngoc Duy
In-Reply-To: <7vlifb2tfp.fsf@alter.siamese.dyndns.org>
Thanks for looking into this, guys!
I seem to run into this with some regularity, but my setting is
apply.whitespace=strip rather than 'fix'.
Is there an obvious workaround?
Here are my remaining settings, sanitized for file paths and URLs:
svn.rmdir=true
push.default=upstream
color.ui=auto
color.diff=auto
color.status=auto
color.branch=auto
color.interactive=auto
color.branch.current=white blue bold
color.branch.local=blue
color.branch.remote=green
color.diff.plain=white
color.diff.meta=yellow bold
color.diff.frag=magenta bold
color.diff.old=red
color.diff.new=green
color.diff.whitespace=red blink
color.status.added=yellow
color.status.changed=green
color.status.untracked=cyan
svn.followparent=true
log.date=relative
blame.date=short
diff.renames=copies
diff.copies=true
diff.mnemonicprefix=true
apply.whitespace=strip
merge.tool=emerge
status.relativepaths=true
web.browser=lynx
rebase.stat=true
core.repositoryformatversion=0
core.filemode=true
core.bare=false
core.logallrefupdates=true
rerere.enabled=true
branch.autosetuprebase=always
-a
On Fri, Oct 12, 2012 at 3:53 PM, Junio C Hamano <gitster@pobox.com> wrote:
> Junio C Hamano <gitster@pobox.com> writes:
>
>> I've never been a fan of update_pre_post_images(). I think I know
>> what is going on (--whitespace=fix). Will post a fix sometime
>> later.
>
> It bisects down to 5166714 (apply: Allow blank context lines to
> match beyond EOF, 2010-03-06).
>
> I do not like this patch at all (I _think_ it should somehow check
> the corresponding postimage is sane when the "ah, we ran out of
> preimage because the caller fixed it to reduce trailing blank lines"
> case), but at least this should get the ball rolling.
>
> Björn, both of the changes involved are yours, so I am thinking that
> you may be a good person to give a sanity check on this. No need to
> hurry, as this is not a recent regression and we are in a pre-release
> freeze.
>
> Thanks.
>
> -- >8 --
> Subject: apply.c:update_pre_post_images(): the preimage can be truncated
>
> 5166714 (apply: Allow blank context lines to match beyond EOF,
> 2010-03-06) and then later 0c3ef98 (apply: Allow blank *trailing*
> context lines to match beyond EOF, 2010-04-08) taught "git apply"
> to trim new blank lines at the end in the patch text when matching
> the contents being patched and the preimage recorded in the patch,
> under --whitespace=fix mode.
>
> When a preimage is modified to match the current contents in
> preparation for such a "fixed" patch application, the context lines
> in the postimage must be updated to match (otherwise, it would
> reintroduce whitespace breakages), and update_pre_post_images()
> function is responsible for doing this. However, this function was
> not updated to take into account a case where the removal of
> trailing blank lines reduces the number of lines in the preimage,
> and triggered an assertion error.
>
> The logic to fix the postimage by copying the corrected context
> lines from the preimage was not prepared to handle this case,
> either, but it was protected by the assert() and only got exposed
> when the assertion is corrected.
>
> Signed-off-by: Junio C Hamano <gitster@pobox.com>
> ---
> builtin/apply.c | 23 +++++++++++++++++------
> 1 file changed, 17 insertions(+), 6 deletions(-)
>
> diff --git c/builtin/apply.c w/builtin/apply.c
> index 156b3ce..6c11e8b 100644
> --- c/builtin/apply.c
> +++ w/builtin/apply.c
> @@ -2095,7 +2095,7 @@ static void update_pre_post_images(struct image *preimage,
> char *buf,
> size_t len, size_t postlen)
> {
> - int i, ctx;
> + int i, ctx, reduced;
> char *new, *old, *fixed;
> struct image fixed_preimage;
>
> @@ -2105,8 +2105,10 @@ static void update_pre_post_images(struct image *preimage,
> * free "oldlines".
> */
> prepare_image(&fixed_preimage, buf, len, 1);
> - assert(fixed_preimage.nr == preimage->nr);
> - for (i = 0; i < preimage->nr; i++)
> + assert(postlen
> + ? fixed_preimage.nr == preimage->nr
> + : fixed_preimage.nr <= preimage->nr);
> + for (i = 0; i < fixed_preimage.nr; i++)
> fixed_preimage.line[i].flag = preimage->line[i].flag;
> free(preimage->line_allocated);
> *preimage = fixed_preimage;
> @@ -2126,7 +2128,8 @@ static void update_pre_post_images(struct image *preimage,
> else
> new = old;
> fixed = preimage->buf;
> - for (i = ctx = 0; i < postimage->nr; i++) {
> +
> + for (i = reduced = ctx = 0; i < postimage->nr; i++) {
> size_t len = postimage->line[i].len;
> if (!(postimage->line[i].flag & LINE_COMMON)) {
> /* an added line -- no counterparts in preimage */
> @@ -2145,8 +2148,15 @@ static void update_pre_post_images(struct image *preimage,
> fixed += preimage->line[ctx].len;
> ctx++;
> }
> - if (preimage->nr <= ctx)
> - die(_("oops"));
> +
> + /*
> + * preimage is expected to run out, if the caller
> + * fixed addition of trailing blank lines.
> + */
> + if (preimage->nr <= ctx) {
> + reduced++;
> + continue;
> + }
>
> /* and copy it in, while fixing the line length */
> len = preimage->line[ctx].len;
> @@ -2159,6 +2169,7 @@ static void update_pre_post_images(struct image *preimage,
>
> /* Fix the length of the whole thing */
> postimage->len = new - postimage->buf;
> + postimage->nr -= reduced;
> }
>
> static int match_fragment(struct image *img,
^ permalink raw reply
* Re: Like commit -a, but...
From: Andreas Schwab @ 2012-11-05 22:36 UTC (permalink / raw)
To: Andreas Krey; +Cc: git
In-Reply-To: <20121105205628.GG21244@inner.h.apk.li>
Andreas Krey <a.krey@gmx.de> writes:
> But is there a direct way to convert the current working tree into a
> tree object?
You can create a temporary index by setting the GIT_INDEX_FILE env var.
Andreas.
--
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
^ permalink raw reply
* Re: git-p4 clone @all error
From: Pete Wyckoff @ 2012-11-05 22:12 UTC (permalink / raw)
To: Arthur; +Cc: git, Vitor Antunes
In-Reply-To: <1352109747598-7570575.post@n2.nabble.com>
a.foulon@amesys.fr wrote on Mon, 05 Nov 2012 02:02 -0800:
> Hi,
>
> Here is my import :
>
> Importing from //depot@all into XXXXX
> Initialized empty Git repository in
> /home/arthur/projets_git/XXXXX/XXXXX/.git/
> Importing revision 4258 (43%)
> Importing new branch depot/DEV_DATA
>
> Resuming with change 4258
> Importing revision 5828 (63%)
> Importing new branch depot/RELEASE_1.0
>
> Resuming with change 5828
> Importing revision 7720 (88%)
> Importing new branch depot/RELEASE_1.0.0
>
> Resuming with change 7720
> Importing revision 8588 (100%)
> Updated branches: DEV_DATA RELEASE_1.0 MAINLINE/02_SubSystem/10_ARINC_429
> MAINLINE RELEASE_1.0.0
> fast-import failed: error: unable to resolve reference
> refs/remotes/p4/depot/MAINLINE/02_SubSystem/10_ARINC_429: Not a directory
> error: Unable to lock
> refs/remotes/p4/depot/MAINLINE/02_SubSystem/10_ARINC_429
> error: unable to resolve reference
> refs/remotes/p4/depot/MAINLINE/02_SubSystem/10_ARINC_429: Not a directory
> error: Unable to lock
> refs/remotes/p4/depot/MAINLINE/02_SubSystem/10_ARINC_429
> error: unable to resolve reference
> refs/remotes/p4/depot/MAINLINE/02_SubSystem/10_ARINC_429: Not a directory
> error: Unable to lock
> refs/remotes/p4/depot/MAINLINE/02_SubSystem/10_ARINC_429
> error: unable to resolve reference
> refs/remotes/p4/depot/MAINLINE/02_SubSystem/10_ARINC_429: Not a directory
> error: Unable to lock
> refs/remotes/p4/depot/MAINLINE/02_SubSystem/10_ARINC_429
> error: unable to resolve reference
> refs/remotes/p4/depot/MAINLINE/02_SubSystem/10_ARINC_429: Not a directory
> error: Unable to lock
> refs/remotes/p4/depot/MAINLINE/02_SubSystem/10_ARINC_429
> error: unable to resolve reference
> refs/remotes/p4/depot/MAINLINE/02_SubSystem/10_ARINC_429: Not a directory
> error: Unable to lock
> refs/remotes/p4/depot/MAINLINE/02_SubSystem/10_ARINC_429
> error: unable to resolve reference
> refs/remotes/p4/depot/MAINLINE/02_SubSystem/10_ARINC_429: Not a directory
> error: Unable to lock
> refs/remotes/p4/depot/MAINLINE/02_SubSystem/10_ARINC_429
> git-fast-import statistics:
> ---------------------------------------------------------------------
> Alloc'd objects: 170000
> Total objects: 169644 ( 195421 duplicates )
> blobs : 92182 ( 186294 duplicates 74565 deltas)
> trees : 70889 ( 9127 duplicates 57686 deltas)
> commits: 6573 ( 0 duplicates 0 deltas)
> tags : 0 ( 0 duplicates 0 deltas)
> Total branches: 8 ( 8 loads )
> marks: 1024 ( 0 unique )
> atoms: 19603
> Memory total: 19217 KiB
> pools: 12576 KiB
> objects: 6640 KiB
> ---------------------------------------------------------------------
> pack_report: getpagesize() = 4096
> pack_report: core.packedGitWindowSize = 33554432
> pack_report: core.packedGitLimit = 268435456
> pack_report: pack_used_ctr = 19803
> pack_report: pack_mmap_calls = 65
> pack_report: pack_open_windows = 10 / 11
> pack_report: pack_mapped = 257715823 / 268009874
> ---------------------------------------------------------------------
>
>
> Import crash after importing revision, my import have not files
Thanks, that is interesting output.
Adding Vitor who knows his way around the branch detection
code. The first mail by Arthur is here, which focuses more
on the backtrace from "p4 describe" errors, but also suggests
something is dodgy in branch detection:
http://thread.gmane.org/gmane.comp.version-control.git/208693
I'm not sure if this is a --verbose run, though, as I don't see
any chatter like "branch is xxx". So I'm not sure if the
auto-parent detection code got run.
The "unable to resolve reference" comes from refs.c, which is
when fast-import calls update_branch() on each of the changed
branches as it is finishing.
Vitor, what could git-p4 have done to create a branch name called
"refs/remotes/p4/depot/MAINLINE/02_SubSystem/10_ARINC_429"?
Any other questions for Arthur?
-- Pete
^ permalink raw reply
* Re: VSS to git
From: victorcruz @ 2012-11-05 22:08 UTC (permalink / raw)
To: git
In-Reply-To: <b0a3bf780903020915g60d97b76pfdbbd60017625f0a@mail.gmail.com>
To migrate from VSS to GIT can use the following script to run on windows:
https://github.com/victorcruz/vsstogit
--
View this message in context: http://git.661346.n2.nabble.com/VSS-to-git-tp2410442p7570605.html
Sent from the git mailing list archive at Nabble.com.
^ permalink raw reply
* Re: Like commit -a, but...
From: Tomas Carnecky @ 2012-11-05 21:36 UTC (permalink / raw)
To: Andreas Krey, git
In-Reply-To: <20121105205628.GG21244@inner.h.apk.li>
On Mon, 05 Nov 2012 21:56:28 +0100, Andreas Krey <a.krey@gmx.de> wrote:
> On Mon, 05 Nov 2012 21:29:48 +0000, Andreas Krey wrote:
> ...
> > But still I'd like to know if there is a cleaner solution,
> > esp. with respect to the index.
>
> Actually, it seems
>
> commit -m 'index'
> commit -a -m 'worktree'
> ...push
> git reset HEAD^
> git reset --soft HEAD^
>
> might do the index trick.
>
> But is there a direct way to convert the current working tree into a
> tree object?
PARENT=$(git rev-parse HEAD)
TREE=$(git write-tree)
COMMIT=$(git commit-tree -p $PARENT -m "message' $TREE)
git push origin $COMMIT:refs/heads/teh-branch
write-tree+commit-tree is what git-commit does internally.
^ permalink raw reply
* Re: why '--init' in git-submodule update
From: Heiko Voigt @ 2012-11-05 21:30 UTC (permalink / raw)
To: Francis Moreau; +Cc: git
In-Reply-To: <CAC9WiBgpHWFGW-z5fnQR_EWnfGJUw+G3b7C6tYMGuVu1S-kP9A@mail.gmail.com>
Hi,
On Mon, Nov 05, 2012 at 05:30:51PM +0100, Francis Moreau wrote:
> I'm wondering why the --init option from git-submodule-update is not
> at least the defaut. Or even wilder, why this option exists at all and
> git-submodule-update always behave like --init was always passed.
That was a design decision. People may not be interested in all
submodules but just a subset they are working with. E.g. think of a
large media directory as a submodule the developers might not be
interested in having it around all the time because only the designers
are heavily working with it.
So the rationale is that you should ask for a certain submodule to be
initialized to get it. If there is demand for it we could of course think
about offering a config option in .gitmodules to allow enabling it by
default for some submodules.
Cheers Heiko
^ permalink raw reply
* Like commit -a, but...
From: Andreas Krey @ 2012-11-05 20:29 UTC (permalink / raw)
To: git
Hi all,
I have a workflow for which I can't quite find the git tooling.
Essentially what I want is like 'git commit -a', except that I
want the resulting commit on a branch I name instead of the current
one, and I want my current index not being modified. At the moment
I emulate that via
git commit -a -m TEMP": `date` $*" && \
git push -f nsd master:temp && \
git reset HEAD^ && \
but that a) changes the index (ok, not that bad), and it
will change my current commit in the case that there are
no unmodified files (no commit -> head doesn't point
where I want). Ok, that can be prevented by --allow-empty.
But still I'd like to know if there is a cleaner solution,
esp. with respect to the index.
(Ah, the point of all this is to take the exact current worktree and
push it to a compile&deploy server; I don't want to chop my work into
commits before I even could compile it.)
Andreas
--
"Totally trivial. Famous last words."
From: Linus Torvalds <torvalds@*.org>
Date: Fri, 22 Jan 2010 07:29:21 -0800
^ permalink raw reply
* Re: Like commit -a, but...
From: Andreas Krey @ 2012-11-05 20:56 UTC (permalink / raw)
To: git
In-Reply-To: <20121105202948.GA17505@inner.h.apk.li>
On Mon, 05 Nov 2012 21:29:48 +0000, Andreas Krey wrote:
...
> But still I'd like to know if there is a cleaner solution,
> esp. with respect to the index.
Actually, it seems
commit -m 'index'
commit -a -m 'worktree'
...push
git reset HEAD^
git reset --soft HEAD^
might do the index trick.
But is there a direct way to convert the current working tree into a
tree object?
Andreas
--
"Totally trivial. Famous last words."
From: Linus Torvalds <torvalds@*.org>
Date: Fri, 22 Jan 2010 07:29:21 -0800
^ permalink raw reply
* Re: how the commit ID come from in GIT?
From: Magnus Bäck @ 2012-11-05 20:26 UTC (permalink / raw)
To: hong zhang; +Cc: git
In-Reply-To: <1352145846.26267.YahooMailClassic@web141404.mail.bf1.yahoo.com>
On Monday, November 05, 2012 at 15:04 EST,
hong zhang <henryzhang62@yahoo.com> wrote:
> Could anyone explain how the git commit ID will include all the files
> that devloper makes changes on?
>
> How git commit ID works?
In short, a Git commit points to a tree object that describes the full
state of the source tree plus metadata like the commit author, date,
description, and a pointer to the commit object(s) that preceded the
commit. The commit id itself is the SHA-1 of the contents of the commit
object. Any change of the source tree will affect the top-level tree
object's SHA-1 which in turn affects the SHA-1 of the commit. Also,
because a commit contains the timestamp of the commit object's creation
even two commits that are content-wise identical will have different
SHA-1s.
If you haven't read it, the Pro Git books explains Git's object model in
detail: http://git-scm.com/book/en/Git-Internals-Git-Objects
That description is quite detailed, and most users don't need to go that
deep.
--
Magnus Bäck
baeck@google.com
^ permalink raw reply
* how the commit ID come from in GIT?
From: hong zhang @ 2012-11-05 20:04 UTC (permalink / raw)
To: git
List,
Could anyone explain how the git commit ID will include all the files that devloper makes changes on?
How git commit ID works?
Thanks for any help!
---henry
^ 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