* 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
* Re: [PATCHv2 2/2] git p4: add support for 'p4 move' in P4Submit
From: Pete Wyckoff @ 2012-11-05 17:57 UTC (permalink / raw)
To: Vitor Antunes; +Cc: git, ggibons
In-Reply-To: <loom.20121105T183530-627@post.gmane.org>
vitor.hda@gmail.com wrote on Mon, 05 Nov 2012 17:37 +0000:
> Pete Wyckoff <pw <at> padd.com> writes:
>
> >
> > From: Gary Gibbons <ggibbons <at> perforce.com>
> >
> > For -M option (detectRenames) in P4Submit, use 'p4 move' rather
> > than 'p4 integrate'. Check Perforce server for exisitence of
> > 'p4 move' and use it if present, otherwise revert to 'p4 integrate'.
> >
>
> Hi Pete,
>
> I've just been hit by a situation where this command is available but is
> disabled in the server. I don't know what is the best approach to avoid
> this issue.
Really? The command exists in the server because it returns the
text output for "p4 help move". But "p4 move" itself fails
because it is somehow disabled in the server?
I didn't even know it was possible to administratively disable
commands.
What's the actual error message? And versions of your client and
server (p4 -V, p4d -V, p4 info).
Any ideas Gary?
-- Pete
^ permalink raw reply
* Re: checkout-index: unable to create file foo (File exists)
From: Pete Wyckoff @ 2012-11-05 17:53 UTC (permalink / raw)
To: Brian J. Murrell; +Cc: git
In-Reply-To: <5097DA5C.9020603@interlinx.bc.ca>
brian@interlinx.bc.ca wrote on Mon, 05 Nov 2012 10:25 -0500:
> On 12-11-04 05:10 PM, Pete Wyckoff wrote:
> > Which network filesystem and OS are you using?
>
> The filesystem is Lustre. So not only is it networked, it is
> distributed where the namespace and data store are handled by different
> nodes, to it's not at all as atomic as NFS-on-(say-)ext4. Given that,
> it's entirely possible to imagine a scenario where a namespace (MDT in
> the Lustre nomenclature) operation could get interrupted after the
> namespace entry has been created but before the open(2) completes. So
> the question here is who's responsibility is it to handle that situation?
That's all in the filesystem. Hopefully it doesn't really work
like that because the fs is incosistent at this point.
ERESTARTSYS handling is done entirely in the kernel, not in glibc
and not git. A possible in-kernel fix is not to handle any
signals (except KILL) when waiting for the open mechanics to
finish.
> > The third option is
> > that there is a bug in the filesystem client.
>
> Yep. But before we can go on to determining a bug, the proper/expected
> behavior needs to be determined. I guess that's taking this a bit OT
> for this list though. I'm not really sure where else to go to determine
> this though. :-(
You could toss this to lustre support. Or try first to come up
with a reduced testcase with lots of opens and SIGALRMs racing
against each other. Maybe xfstests or some other suite might
also tickle the bug.
I don't think it is feasible to try to handle this error
condition in applications.
-- Pete
^ permalink raw reply
* Re: [PATCHv2 2/2] git p4: add support for 'p4 move' in P4Submit
From: Vitor Antunes @ 2012-11-05 17:37 UTC (permalink / raw)
To: git
In-Reply-To: <1342135740-30290-3-git-send-email-pw@padd.com>
Pete Wyckoff <pw <at> padd.com> writes:
>
> From: Gary Gibbons <ggibbons <at> perforce.com>
>
> For -M option (detectRenames) in P4Submit, use 'p4 move' rather
> than 'p4 integrate'. Check Perforce server for exisitence of
> 'p4 move' and use it if present, otherwise revert to 'p4 integrate'.
>
Hi Pete,
I've just been hit by a situation where this command is available but is
disabled in the server. I don't know what is the best approach to avoid
this issue.
Thanks,
Vitor
^ permalink raw reply
* why '--init' in git-submodule update
From: Francis Moreau @ 2012-11-05 16:30 UTC (permalink / raw)
To: git
Hello,
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.
Thanks
--
Francis
^ permalink raw reply
* Re: Lack of netiquette, was Re: [PATCH v4 00/13] New remote-hg helper
From: Felipe Contreras @ 2012-11-05 16:15 UTC (permalink / raw)
To: Michael J Gruber
Cc: Andreas Ericsson, René Scharfe, Junio C Hamano,
Johannes Schindelin, Jonathan Nieder, Jeff King, git,
Sverre Rabbelier, Ilari Liusvaara, Daniel Barkalow
In-Reply-To: <5097E290.4030700@drmicha.warpmail.net>
On Mon, Nov 5, 2012 at 5:00 PM, Michael J Gruber
<git@drmicha.warpmail.net> wrote:
> [trimmed down heavily by mjg]
> Felipe Contreras venit, vidit, dixit 05.11.2012 16:22:
>> On Mon, Nov 5, 2012 at 10:25 AM, Michael J Gruber
>> <git@drmicha.warpmail.net> wrote:
>>> Felipe Contreras venit, vidit, dixit 02.11.2012 17:09:
>>>> On Fri, Nov 2, 2012 at 12:03 PM, Michael J Gruber
>>>> <git@drmicha.warpmail.net> wrote:
>
>> There is no lack of openness from my part. I hear all technical
>> arguments, and I reply on a technical basis. The problem seems to be
>> is that you expect the code submitted to be criticized, but not the
>> criticism it receives. IOW; the submitter has to put up with anything
>> anybody says about his/her code and ideas, but the *reviewer* is
>> untouchable; the submitter cannot ever criticize the reviewer. I can
>
> Feel free to criticize the criticism, just don't offend the criticizer
> (be it the reviewer or the submitter).
As I've said before; I've yet to see where exactly I have done so.
>>> And no, using the same or similar language does not make us the same at
>>> all. Using the same language is the natural prerequisite for successful
>>> communication.
>>
>> Nobody said otherwise.
>
> Well, you did in the post I responded to:
>
>>>> The dangers of "everyone" following the same style of communication,
>>>> and making "everyone" feel comfortable, is that "everyone" ends up
>>>> being the same kind of people
Style of communication != language.
You can use the same language and have vastly different styles of communication.
Imagine a society where everyone has the same style of communication.
Where your free speech ends the moment you diverge from this style.
Well, historically we know these societies have not worked, because
there's people with different styles of communication, and quite often
it's these styles of communication that are needed for certain
messages important to society to be heard.
Sure, it doesn't make you all the same, but it certainly makes it a
narrow spectrum.
> In any case, I feel I've showed enough efforts and there's no point in
> dragging this on.
How convenient. When I ask you specifically for examples where I have
offended anybody, or been harsh, you feel you have "showed enough
efforts"?
Claims require evidence.
Cheers.
--
Felipe Contreras
^ permalink raw reply
* Re: Lack of netiquette, was Re: [PATCH v4 00/13] New remote-hg helper
From: Michael J Gruber @ 2012-11-05 16:00 UTC (permalink / raw)
To: Felipe Contreras
Cc: Andreas Ericsson, René Scharfe, Junio C Hamano,
Johannes Schindelin, Jonathan Nieder, Jeff King, git,
Sverre Rabbelier, Ilari Liusvaara, Daniel Barkalow
In-Reply-To: <CAMP44s3i1M9YtQb-EG+LS8DbwX10q2xE-LdxZCy3Xa_x3tQ9kA@mail.gmail.com>
[trimmed down heavily by mjg]
Felipe Contreras venit, vidit, dixit 05.11.2012 16:22:
> On Mon, Nov 5, 2012 at 10:25 AM, Michael J Gruber
> <git@drmicha.warpmail.net> wrote:
>> Felipe Contreras venit, vidit, dixit 02.11.2012 17:09:
>>> On Fri, Nov 2, 2012 at 12:03 PM, Michael J Gruber
>>> <git@drmicha.warpmail.net> wrote:
> There is no lack of openness from my part. I hear all technical
> arguments, and I reply on a technical basis. The problem seems to be
> is that you expect the code submitted to be criticized, but not the
> criticism it receives. IOW; the submitter has to put up with anything
> anybody says about his/her code and ideas, but the *reviewer* is
> untouchable; the submitter cannot ever criticize the reviewer. I can
Feel free to criticize the criticism, just don't offend the criticizer
(be it the reviewer or the submitter).
> tell you that doesn't happen in the Linux kernel; the review process
> is a _discussion_, not a one-way communication, and discussions can be
> heated up, but the end result is better code, *both* sides are open to
> criticism, the submitter, *and* the reviewer.
Exactly, both.
>> And no, using the same or similar language does not make us the same at
>> all. Using the same language is the natural prerequisite for successful
>> communication.
>
> Nobody said otherwise.
Well, you did in the post I responded to:
>>> The dangers of "everyone" following the same style of communication,
>>> and making "everyone" feel comfortable, is that "everyone" ends up
>>> being the same kind of people
In any case, I feel I've showed enough efforts and there's no point in
dragging this on.
Michael
^ permalink raw reply
* Re: Lack of netiquette, was Re: [PATCH v4 00/13] New remote-hg helper
From: Felipe Contreras @ 2012-11-05 15:58 UTC (permalink / raw)
To: Michael J Gruber
Cc: Andreas Ericsson, René Scharfe, Junio C Hamano,
Johannes Schindelin, Jonathan Nieder, Jeff King, git,
Sverre Rabbelier, Ilari Liusvaara, Daniel Barkalow
In-Reply-To: <CAMP44s3i1M9YtQb-EG+LS8DbwX10q2xE-LdxZCy3Xa_x3tQ9kA@mail.gmail.com>
On Mon, Nov 5, 2012 at 4:22 PM, Felipe Contreras
<felipe.contreras@gmail.com> wrote:
> On Mon, Nov 5, 2012 at 10:25 AM, Michael J Gruber
> <git@drmicha.warpmail.net> wrote:
>> For one thing, contributors on the kernel list are open to technical
>> arguments, and that includes the arguments of others; just like we are
>> here. On the other hand, you seem to rebuke "any" (most) technical
>> argument in harsh words as if it were a personal attack; at least that's
>> how your answers come across to me (and apparently others). That really
>> makes it difficult for most of us here to argue with you technically,
>> which is a pity. That lack of openness for the arguments of others would
>> make your life difficult on the kernel list also.
...
> If that's not the case, show me a single instance when I rebuke
> technical arguments in *harsh* words... perhaps, you think any
> rebuking is "harsh". Specifically, show me an instance were *I* was
> harsh, and the reviewer was not.
>
> If you cannot show instances of this, then your statement that I
> rebuke harshly doesn't stand; I rebuke, that's all.
In addition to this, I'm still waiting for an answer of what's wrong
with the words that started this thread:
On Wed, 31 Oct 2012, Felipe Contreras wrote:
> It doesn't get any more obvious than that. But to each his own.
Cheers.
--
Felipe Contreras
^ permalink raw reply
* [PATCH v2 4/5] remote-bzr: add support for remote repositories
From: Felipe Contreras @ 2012-11-05 15:56 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano, Jeff King, Johannes Schindelin, Felipe Contreras
In-Reply-To: <1352130980-3998-1-git-send-email-felipe.contreras@gmail.com>
Strictly speaking bzr doesn't need any changes to interact with remote
repositories, but it's dead slow.
Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
---
contrib/remote-helpers/git-remote-bzr | 26 ++++++++++++++++++++++++--
1 file changed, 24 insertions(+), 2 deletions(-)
diff --git a/contrib/remote-helpers/git-remote-bzr b/contrib/remote-helpers/git-remote-bzr
index 9e0062f..c981fda 100755
--- a/contrib/remote-helpers/git-remote-bzr
+++ b/contrib/remote-helpers/git-remote-bzr
@@ -547,7 +547,7 @@ def parse_reset(parser):
parsed_refs[ref] = mark_to_rev(from_mark)
def do_export(parser):
- global parsed_refs, dirname
+ global parsed_refs, dirname, peer
parser.next()
@@ -570,6 +570,8 @@ def do_export(parser):
for ref, revid in parsed_refs.iteritems():
if ref == 'refs/heads/master':
repo.generate_revision_history(revid, marks.get_tip('master'))
+ revno, revid = repo.last_revision_info()
+ peer.import_last_revision_info_and_tags(repo, revno, revid)
print "ok %s" % ref
print
@@ -598,8 +600,28 @@ def do_list(parser):
print
def get_repo(url, alias):
+ global dirname, peer
+
+ clone_path = os.path.join(dirname, 'clone')
origin = bzrlib.controldir.ControlDir.open(url)
- return origin.open_branch()
+ remote_branch = origin.open_branch()
+
+ if os.path.exists(clone_path):
+ # pull
+ d = bzrlib.controldir.ControlDir.open(clone_path)
+ branch = d.open_branch()
+ result = branch.pull(remote_branch, [], None, False)
+ else:
+ # clone
+ d = origin.sprout(clone_path, None,
+ hardlink=True, create_tree_if_local=False,
+ source_branch=remote_branch)
+ branch = d.open_branch()
+ branch.bind(remote_branch)
+
+ peer = remote_branch
+
+ return branch
def main(args):
global marks, prefix, dirname
--
1.8.0
^ permalink raw reply related
* [PATCH v2 5/5] remote-bzr: update working tree
From: Felipe Contreras @ 2012-11-05 15:56 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano, Jeff King, Johannes Schindelin, Felipe Contreras
In-Reply-To: <1352130980-3998-1-git-send-email-felipe.contreras@gmail.com>
Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
---
contrib/remote-helpers/git-remote-bzr | 2 ++
1 file changed, 2 insertions(+)
diff --git a/contrib/remote-helpers/git-remote-bzr b/contrib/remote-helpers/git-remote-bzr
index c981fda..1a06a0a 100755
--- a/contrib/remote-helpers/git-remote-bzr
+++ b/contrib/remote-helpers/git-remote-bzr
@@ -572,6 +572,8 @@ def do_export(parser):
repo.generate_revision_history(revid, marks.get_tip('master'))
revno, revid = repo.last_revision_info()
peer.import_last_revision_info_and_tags(repo, revno, revid)
+ wt = peer.bzrdir.open_workingtree()
+ wt.update()
print "ok %s" % ref
print
--
1.8.0
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox