* Re: [PATCH] strbuf_readlink semantics update.
From: Junio C Hamano @ 2008-12-25 7:23 UTC (permalink / raw)
To: René Scharfe; +Cc: Pierre Habouzit, Linus Torvalds, git
In-Reply-To: <4952532F.5050704@lsrfire.ath.cx>
René Scharfe <rene.scharfe@lsrfire.ath.cx> writes:
> Pierre Habouzit schrieb:
>> On Tue, Dec 23, 2008 at 06:16:01PM +0000, Linus Torvalds wrote:
>>>
>>> On Tue, 23 Dec 2008, Pierre Habouzit wrote:
>>>> when readlink fails, the strbuf shall not be destroyed. It's not how
>>>> read_file_or_gitlink works for example.
>>> I disagree.
>>>
>>> This patch just makes things worse. Just leave the "strbuf_release()" in
>>> _one_ place.
> ...
> The "append or do nothing" rule is broken by strbuf_getline(), but I agree
> to your reasoning. How about refining this rule a bit to "do your thing
> and roll back changes if an error occurs"? I think it's not worth to undo
> allocation extensions, but making reverting first time allocations seems
> like a good idea. Something like this?
I think this is much better than Pierre's. Pierre's "if it is called
strbuf_*, it should always append" is a good uniformity to have in an API,
but making the caller suffer for clean-up is going backwards. The reason
we use strbuf when we can is so that the callers do not have to worry
about memory allocation issues too much.
^ permalink raw reply
* Re: [ANNOUNCE] GIT 1.6.1
From: Christian MICHON @ 2008-12-25 8:32 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v7i5odams.fsf@gitster.siamese.dyndns.org>
On Thu, Dec 25, 2008 at 7:36 AM, Junio C Hamano <gitster@pobox.com> wrote:
> The latest feature release GIT 1.6.1 is available at the usual
> places:
>
a nice christmas gift indeed! thanks for making this release possible.
my best wishes to the list for xmas and incoming 2009!
--
Christian
--
http://detaolb.sourceforge.net/, a linux distribution for Qemu with Git inside !
^ permalink raw reply
* Re: [ANNOUNCE] GIT 1.6.1
From: bill lam @ 2008-12-25 10:00 UTC (permalink / raw)
To: git
In-Reply-To: <7v7i5odams.fsf@gitster.siamese.dyndns.org>
On ubuntu64 8.10, the NO_UINTMAX_T seems cause some trouble, I have to
comment out the block (in the Makefile),
fdef NO_UINTMAX_T
BASIC_CFLAGS += -Duintmax_t=uint32_t
ndif
to make a successful compilation. Does it happen to me only?
--
regards,
====================================================
GPG key 1024D/4434BAB3 2008-08-24
gpg --keyserver subkeys.pgp.net --recv-keys 4434BAB3
唐詩282 白居易 後宮詞
淚濕羅巾夢不成 夜深前殿按歌聲 紅顏未老恩先斷 斜倚薰籠坐到明
^ permalink raw reply
* Re: [ANNOUNCE] GIT 1.6.1
From: Junio C Hamano @ 2008-12-25 10:13 UTC (permalink / raw)
To: bill lam; +Cc: git
In-Reply-To: <20081225100033.GA8451@b2j>
bill lam <cbill.lam@gmail.com> writes:
> On ubuntu64 8.10, the NO_UINTMAX_T seems cause some trouble, I have to
> comment out the block (in the Makefile),
>
> fdef NO_UINTMAX_T
> BASIC_CFLAGS += -Duintmax_t=uint32_t
> ndif
>
> to make a successful compilation. Does it happen to me only?
Nobody reported it since that was added about a month and half ago.
Why are you building with NO_UINTMAX_T to begin with? Isn't ubuntu 8.10 a
recent enough platform that ships with modern enough header files that
define ANSI uintmax_t type?
^ permalink raw reply
* Re: [ANNOUNCE] GIT 1.6.1
From: bill lam @ 2008-12-25 10:25 UTC (permalink / raw)
To: git
In-Reply-To: <7v3agca7fp.fsf@gitster.siamese.dyndns.org>
> Why are you building with NO_UINTMAX_T to begin with? Isn't ubuntu 8.10 a
> recent enough platform that ships with modern enough header files that
> define ANSI uintmax_t type?
No, I did not do anything on that,
make clean
./configure --prefix=/usr
make
and this is the error logged.
GIT_VERSION = 1.6.1
* new build flags or prefix
In file included from /usr/include/netinet/in.h:24,
from git-compat-util.h:78,
from builtin.h:4,
from fast-import.c:142:
/usr/include/stdint.h:136: error: conflicting types for ‘uint32_t’
/usr/include/stdint.h:52: error: previous declaration of ‘uint32_t’ was here
fast-import.c: In function ‘parse_progress’:
fast-import.c:2339: warning: ignoring return value of ‘fwrite’, declared with attribute warn_unused_result
make: *** [fast-import.o] Error 1
version of gcc:
gcc (Ubuntu 4.3.2-1ubuntu11) 4.3.2
--
regards,
====================================================
GPG key 1024D/4434BAB3 2008-08-24
gpg --keyserver subkeys.pgp.net --recv-keys 4434BAB3
唐詩105 杜甫 月夜
今夜鄜州月 閨中只獨看 遙憐小兒女 未解憶長安
香霧雲鬟濕 清輝玉臂寒 何時倚虛幌 雙照淚痕乾
^ permalink raw reply
* Re: [ANNOUNCE] GIT 1.6.1
From: René Scharfe @ 2008-12-25 11:42 UTC (permalink / raw)
To: bill lam; +Cc: git, Junio C Hamano
In-Reply-To: <20081225102527.GB8451@b2j>
bill lam schrieb:
>> Why are you building with NO_UINTMAX_T to begin with? Isn't ubuntu 8.10 a
>> recent enough platform that ships with modern enough header files that
>> define ANSI uintmax_t type?
>
> No, I did not do anything on that,
>
> make clean
> ./configure --prefix=/usr
> make
>
> and this is the error logged.
>
> GIT_VERSION = 1.6.1
> * new build flags or prefix
> In file included from /usr/include/netinet/in.h:24,
> from git-compat-util.h:78,
> from builtin.h:4,
> from fast-import.c:142:
> /usr/include/stdint.h:136: error: conflicting types for ‘uint32_t’
> /usr/include/stdint.h:52: error: previous declaration of ‘uint32_t’ was here
> fast-import.c: In function ‘parse_progress’:
> fast-import.c:2339: warning: ignoring return value of ‘fwrite’, declared with attribute warn_unused_result
> make: *** [fast-import.o] Error 1
>
> version of gcc:
> gcc (Ubuntu 4.3.2-1ubuntu11) 4.3.2
I don't get any error on Ubuntu 8.10 on x86_64 (but several of those
warnings about ignored return values), neither with the tar file nor a
cloned repository (in the former case I had to add a "make configure"
step, though).
Line 52 of /usr/include/stdint.h:
typedef unsigned int uint32_t;
Lines 134-136 of /usr/include/stdint.h:
#if __WORDSIZE == 64
typedef long int intmax_t;
typedef unsigned long int uintmax_t;
If you get to line 136, you probably are on a 64 bit installation, too,
correct?
configure seems to be confused. What happens if you take it out of the
equation, i.e. run the following commands?
$ make distclean
$ make prefix=/usr
René
^ permalink raw reply
* Re: [ANNOUNCE] GIT 1.6.1
From: Heikki Orsila @ 2008-12-25 11:44 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, linux-kernel
In-Reply-To: <7v7i5odams.fsf@gitster.siamese.dyndns.org>
On Wed, Dec 24, 2008 at 10:36:27PM -0800, Junio C Hamano wrote:
> * The packfile machinery hopefully is more robust when dealing with
> corrupt packs if redundant objects involved in the corruption are
> available elsewhere.
Has anyone written a summary of how Git's redundancy operates?
* What would be the probability for a single bit flip to corrupt the
repository?
* And what is the situation where a single bit flip can not corrupt the
database?
* When (which commands/functions) is error detection done?
Heikki
^ permalink raw reply
* Re: [ANNOUNCE] GIT 1.6.1
From: bill lam @ 2008-12-25 14:09 UTC (permalink / raw)
To: git
In-Reply-To: <49537197.1000805@lsrfire.ath.cx>
On Thu, 25 Dec 2008, René Scharfe wrote:
> configure seems to be confused. What happens if you take it out of the
> equation, i.e. run the following commands?
>
> $ make distclean
> $ make prefix=/usr
Thanks René! I followed your installation, deleted the old configure,
and it compiled successfully,
Happy holidays to everyone on mailing list!
--
regards,
====================================================
GPG key 1024D/4434BAB3 2008-08-24
gpg --keyserver subkeys.pgp.net --recv-keys 4434BAB3
唐詩104 李白 夜泊牛渚懷古
牛渚西江夜 青天無片雲 登舟望秋月 空憶謝將軍
余亦能高詠 斯人不可聞 明朝挂帆席 楓葉落紛紛
^ permalink raw reply
* Re: a few Topgit patches
From: martin f krafft @ 2008-12-25 14:58 UTC (permalink / raw)
To: Uwe Kleine-König, git, Petr Baudis
In-Reply-To: <20081223143035.GA24087@cassiopeia.tralala>
[-- Attachment #1: Type: text/plain, Size: 1175 bytes --]
also sprach Uwe Kleine-König <u.kleine-koenig@pengutronix.de> [2008.12.23.1530 +0100]:
> I hacked using topgit for some time now, and found the following changes
> to topgit useful:
>
> Uwe Kleine-König (3):
> tg export: implement skipping empty patches for collapse driver
> tg export: Implement flattening patch paths for quilt mode
> tg export (quilt): Implement numbering the patches
They all look good. I am a bit concerned about the use of
single-letter options at this stage. tg-export is bound to grow, and
using them all up now might mean breaking compatibility later, when
a more common option needs e.g. -f, which has already been taken.
--
.''`. martin f. krafft <madduck@d.o> Related projects:
: :' : proud Debian developer http://debiansystem.info
`. `'` http://people.debian.org/~madduck http://vcs-pkg.org
`- Debian - when you have better things to do than fixing systems
"oh what a tangled web we weave,
when first we practice to deceive.
but my how we improve the score,
as we practice more and more."
-- sir walter scott
[-- Attachment #2: Digital signature (see http://martin-krafft.net/gpg/) --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: [announce] gc
From: Stephen Haberman @ 2008-12-25 15:23 UTC (permalink / raw)
To: Mike Ralphson; +Cc: Matthieu Moy, git
In-Reply-To: <e2b179460812230706p12e4f052v960f162e08011ae6@mail.gmail.com>
> > I'm a little cautious about using words like corporate/enterprise as
> > there is nothing exclusively "corporate/enterprise" about any of the
> > hooks in the project, we just happened to be on a corporate/enterprise
> > project when we came up with them.
>
> As the workflows these seem to support are centralised (as you say
> these apply equally well in some non-corporate / enterprise projects),
> how about git-central?
Ah, that's excellent. Thanks for the suggestion.
- Stephen
^ permalink raw reply
* RFE: git-import-dsc should support http-links
From: Rolf Leggewie @ 2008-12-25 14:51 UTC (permalink / raw)
To: git
Hi,
merry Christmas everyone. I hope this is the right place for this, I
looked around and it seemed to me it was, so here it goes.
It would be nice if the following just worked:
"git-import-dsc
http://ftp.de.debian.org/debian/pool/main/g/gnucash/gnucash_2.2.6-2.dsc"
Regards
Rolf
PS: How about some kind of official bug tracker for git?
^ permalink raw reply
* Re: git rev-list with --name-status?
From: demerphq @ 2008-12-25 18:24 UTC (permalink / raw)
To: skillzero; +Cc: git
In-Reply-To: <2729632a0812241453x4ae50362g4bcd3317e5be0429@mail.gmail.com>
2008/12/24 <skillzero@gmail.com>:
> Is there a way to print the equivalent of --name-status with git
> rev-list? The post-receive script that comes with git for sending
> comment emails does this to generate the commit log:
>
> git rev-parse --not --branches | grep -v $(git rev-parse $refname) |
> git rev-list --pretty --stdin $oldrev..$newrev
>
> I'd like to also include the output of --name-status so the email
> shows which files were changed by each commit (rather than just a
> summary at the end since our pushes sometimes have a lot of commits in
> them).
>
> git rev-list doesn't seem to support --name-status and git log doesn't
> seem to support --stdin. Is there a better way to do what I want?
I wrote the following shell script function which you can add to your
post-receive-mail script. Any git rev-list --pretty statements there
can have the --pretty removed and have their output redirected to
this, and you get what you want. An existing function changed to use
it follows. Theres probably prettier ways to do this, but hope it
helps. Id send a diff of the script as a whole except that its full of
other likely irrelevent changes.
Yves
# show_log_for_sha1s_on_std()
#
# take a list of sha1's on STDIN and print out their logs.
#
# if there are
#
# 0 commits output a notice saying there no changes in this update
#
# 1 commits - show the log only
#
# >1 commits - show log with --name-status output (list of files with
M/D/A type tags
# next to them for Modified Deleted and Added)
#
# This partly exists because we can't use --name-status with rev-list, and
# because we cant use --stdin with git log (even tho the docs might say
# otherwise in older gits). Although since we count SHA1's we can also do some
# special stuff like dealing with the 0/1/N commits differently.
show_log_for_sha1s_on_stdin()
{
perl -e'
chomp(my @sha1= <>);
if (!@sha1) {
print "No new revisions added by this update\n";
}
else {
my $ns= @sha1 > 1 ? " --name-status" : "";
for my $idx (0..$#sha1) {
print $idx ? "\n" : "" ,
`git-log --pretty$ns -1 $sha1[$idx]`;
}
}
'
}
generate_create_branch_email()
{
# This is a new branch and so oldrev is not valid
echo " at $newrev ($newrev_type)"
echo ""
echo $LOGBEGIN
# This shows all log entries that are not already covered by
# another ref - i.e. commits that are now accessible from this
# ref that were previously not accessible
# (see generate_update_branch_email for the explanation of this
# command)
git rev-parse --not --branches | grep -v $(git rev-parse $refname) |
git rev-list --stdin $newrev | show_log_for_sha1s_on_stdin
echo $LOGEND
}
--
perl -Mre=debug -e "/just|another|perl|hacker/"
^ permalink raw reply
* Re: [ANNOUNCE] GIT 1.6.1
From: Junio C Hamano @ 2008-12-25 18:50 UTC (permalink / raw)
To: bill lam; +Cc: git
In-Reply-To: <20081225102527.GB8451@b2j>
bill lam <cbill.lam@gmail.com> writes:
>> Why are you building with NO_UINTMAX_T to begin with? Isn't ubuntu 8.10 a
>> recent enough platform that ships with modern enough header files that
>> define ANSI uintmax_t type?
>
> No, I did not do anything on that,
>
> make clean
> ./configure --prefix=/usr
> make
I do not use configure myself (use of configure is entirely optional, and
it is not tested often and core developers do not touch that part very
much --- in a sense, use of autoconf is a second-class citizen in our
build process); it is plausible that it has broken checks for detecting
the need of NO_UINTMAX_T.
Relevant part of configure.ac reads like this:
# Define NO_UINTMAX_T if your platform does not have uintmax_t
AC_CHECK_TYPE(uintmax_t,
[NO_UINTMAX_T=],
[NO_UINTMAX_T=YesPlease],[
#include <inttypes.h>
])
AC_SUBST(NO_UINTMAX_T)
and I do not see anything suspicious there...
Running "./configure --verbose" might leave some clues in config.log; for
me on my primary development box (Debian on x86_64), the relevant part
passes the test (iow, inclusion of inttypes.h does give a working
uintmax_t type) like this:
configure:5709: checking for uintmax_t
configure:5742: cc -c -g -O2 conftest.c >&5
configure:5748: $? = 0
configure:5763: result: yes
^ permalink raw reply
* Re: [ANNOUNCE] GIT 1.6.1
From: Pau Garcia i Quiles @ 2008-12-25 18:53 UTC (permalink / raw)
To: git
In-Reply-To: <20081225100033.GA8451@b2j>
On Thu, Dec 25, 2008 at 11:00 AM, bill lam <cbill.lam@gmail.com> wrote:
> On ubuntu64 8.10, the NO_UINTMAX_T seems cause some trouble, I have to
> comment out the block (in the Makefile),
>
> fdef NO_UINTMAX_T
> BASIC_CFLAGS += -Duintmax_t=uint32_t
> ndif
>
> to make a successful compilation. Does it happen to me only?
Works for me both in Hardy and Intrepid. If you have trouble building
from source, there are binary package for Hardy and Intrepid in my
PPA:
http://launchpad.net/~pgquiles/+archive
--
Pau Garcia i Quiles
http://www.elpauer.org
(Due to my workload, I may need 10 days to answer)
^ permalink raw reply
* Re: git rev-list with --name-status?
From: Junio C Hamano @ 2008-12-25 18:59 UTC (permalink / raw)
To: skillzero; +Cc: git
In-Reply-To: <2729632a0812241453x4ae50362g4bcd3317e5be0429@mail.gmail.com>
skillzero@gmail.com writes:
> Is there a way to print the equivalent of --name-status with git
> rev-list? The post-receive script that comes with git for sending
> comment emails does this to generate the commit log:
>
> git rev-parse --not --branches | grep -v $(git rev-parse $refname) |
> git rev-list --pretty --stdin $oldrev..$newrev
I should have noticed this earlier.
You seem to be referring to contrib/hooks/post-receive-email as "The
script that comes with git". It does have customization possibility
already implemented and documented:
hooks.showrev
The shell command used to format each revision in the email, with
"%s" replaced with the commit id. Defaults to "git rev-list -1
--pretty %s", displaying the commit id, author, date and log
message. To list full patches separated by a blank line, you
could set this to "git show -C %s; echo".
One of my day-job repositories has:
[hooks]
mailinglist = some-secret-project@day-job-domain.com
emailprefix = "[SOME-SECRET-PROJECT GIT] "
showrev = "git show --stat %s; echo"
I think you can use "git show --name-status %s; echo" instead, if you like
the --name-status output.
^ permalink raw reply
* Re: git rev-list with --name-status?
From: skillzero @ 2008-12-25 20:13 UTC (permalink / raw)
To: git
In-Reply-To: <7vr63w84iy.fsf@gitster.siamese.dyndns.org>
On Thu, Dec 25, 2008 at 10:59 AM, Junio C Hamano <gitster@pobox.com> wrote:
> You seem to be referring to contrib/hooks/post-receive-email as "The
> script that comes with git". It does have customization possibility
> already implemented and documented:
>
> hooks.showrev
> The shell command used to format each revision in the email, with
> "%s" replaced with the commit id. Defaults to "git rev-list -1
> --pretty %s", displaying the commit id, author, date and log
> message. To list full patches separated by a blank line, you
> could set this to "git show -C %s; echo".
>
> ...
>
> I think you can use "git show --name-status %s; echo" instead, if you like
> the --name-status output.
Thanks, that's perfect. I was using an older version of
contrib/hooks/post-receive-email that didn't have hooks.showrev so I
didn't realize it already had support for what I wanted.
^ permalink raw reply
* [ANNOUNCE] git-cola 1.3.4
From: David Aguilar @ 2008-12-25 23:36 UTC (permalink / raw)
To: git
The latest git-cola release v1.3.4 is available at the
usual places:
git-cola homepage:
http://cola.tuxfamily.org/
git-cola on github:
git clone git://github.com/davvid/git-cola.git
http://github.com/davvid/git-cola/tree/master
git-cola is a powerful git gui written in Python.
git-cola uses the PyQt4 gui toolkit and is supported on all
platforms where git is available, including Windows/msysgit.
The latest versions of git-cola sport a fresh new interface and
several new helpful dialogs. One of the newer git-cola dialogs
is the 'Commit Comparison' dialog which allows you to compare
arbitrary commits using standard merge tools (e.g. xxdiff).
git-cola uses a custom git command called git-difftool to
drive the merge tools. This is useful if you'd like
to use the functionality in your own scripts or from the
command line. I will post the current version of git-difftool
to the list for feedback and possible inclusion in the
git contrib/ area since it is a generally useful utility.
See the online documentation for more information.
---------------------------------------------------------------
Changes since v1.3.3 are as follows:
Barry Roberts (3):
Fix stash typo
Context menu items for Commits list
Speed up file identification
David Aguilar (15):
i18n: fix a few more places where we weren't unicode-safe
compare: reinstate the Commit -> Compare File... menu action
views: fix obsolete references to the old dockwidgets
diff gui: properly restore the scroll bar values on update
cola: pass --no-color to 'git diff' to avoid receiving ANSI sequences
controllers: fix a typo when restoring the scrollbar values on rescan
options dialog: fix some annoyances with the font handling
compare: fix an edge case when decreasing the number of log results
Use 'utf-8' instead of 'utf8' in core.encode()
models: call 'git update-index --refresh' in get_workdir_state()
rebase: list all branches in the branch chooser, not just local ones
INSTALL: remove references to the now unused 'file' command
win32: add a win32/ folder for storing all of the win32 hacks
INSTALL: fix a typo in the windows installation section
remote: add a rebase checkbox to the pull dialog
--
David
^ permalink raw reply
* a few scenarios before I create my first repo [Scanned]
From: Conor Rafferty @ 2008-12-26 0:17 UTC (permalink / raw)
To: git
Dear All,
Apols for the newbie-ness of this post - I couldn't find a seperate
list/forum for user support.
I have no SCM for my projects and its becoming a nightmare. Lots of
folders lying around, with various versions.
Need to manage all this and do the work to catalog and archive the work
done so far and set up a good config mgmt framewrok for future work.
Been searching for an SCM and git seems good.
Before I create a repo of live files, I just wanna check:
(1a)
Do I need to install windows git on the same machine I want to store the
files on ?
Or can I install git on my workstation PC and create the repo on the
server ?
(1b)
if i create a repo on my office PC, can it easily be moved (including
all history) to another PC (e.g. LAN server) if we decide to implement
git across the team
(If not, or its inconvenient, I need to create the repo on the server)
(2)
if i create a repo on my work PC, can it easily be migrated (including
all history) to a repo on github (etc.) ?
(3)
if I create a repo and commit the first baseline, can I later create an
ancestor commit to that baseline, if I subsequently find an older
version of the project lying around on the file system
(or, same concept i guess, if i find a project version that sits between
say version v1.0 and v1.1 (where v1.0 is the parent tag of v1.1) can i
interleave the project files as say v1.01.
I've a feeling the answer's will be YES to 1 & 2 and NO to 3, but the
documentation is too low level for a newb like me.
many thanks
--
Conor Rafferty BSc (Hons.)
REGIONAL MANAGER
Altmore IT Recruitment
Townsend Enterprise Park
28 Townsend Street
Belfast BT13 2ES
T: +44 (0)28 9032 8400
E: conor.rafferty@altmore.co.uk
W: www.altmore.co.uk
LinkedIn: http://www.linkedin.com/in/conorrafferty
------------------------------------------------------------------------
--------
This electronic message contains information from Altmore IT Recruitment
which may be privileged or confidential. The information is intended to
be for the use of the individual(s) or entity named above. If you are
not the intended recipient be aware that any disclosure, copying
distribution or use of the contents of this information is prohibited.
If you have received this electronic message in error, please notify us
by telephone or email (to the numbers or address above) immediately.
^ permalink raw reply
* Re: RFE: git-import-dsc should support http-links
From: Junio C Hamano @ 2008-12-26 0:27 UTC (permalink / raw)
To: Rolf Leggewie; +Cc: git, Guido Guenther
In-Reply-To: <gj06ks$ao9$1@ger.gmane.org>
Rolf Leggewie <no2spam@nospam.arcornews.de> writes:
> merry Christmas everyone. I hope this is the right place for this, I
> looked around and it seemed to me it was, so here it goes.
Sorry, I have never heard of git-import-dsc and had to google for it, only
to find that it is one [*1*] of a set [*2*] of debian local tools somebody
I've never heard of (Cc'ed) on this list has written.
> It would be nice if the following just worked:
>
> "git-import-dsc
> http://ftp.de.debian.org/debian/pool/main/g/gnucash/gnucash_2.2.6-2.dsc"
> Regards
>
> Rolf
> PS: How about some kind of official bug tracker for git?
Even if there were such a thing, I do not think this report belongs to it.
I would imagine a better place would be here:
http://bugs.debian.org/cgi-bin/pkgreport.cgi?package=git-buildpackage
[References]
*1* http://honk.sigxcpu.org/projects/git-buildpackage/manual-html/gbp.man.git.import.dsc.html
*2* http://honk.sigxcpu.org/projects/git-buildpackage/manual-html/gbp.man.git.buildpackage.html
^ permalink raw reply
* Re: a few scenarios before I create my first repo [Scanned]
From: Junio C Hamano @ 2008-12-26 0:46 UTC (permalink / raw)
To: Conor Rafferty; +Cc: git
In-Reply-To: <BB5F02FD3789B54E8964D38D6775E718242D00@ALTMORE-SVR.altmore.local>
What's [scanned]?
"Conor Rafferty" <conor.rafferty@altmore.co.uk> writes:
> (1a) Do I need to install windows git on the same machine I want to
> store the files on ? Or can I install git on my workstation PC and
> create the repo on the server ?
The model employed by git is not "client working with centralized server".
On whichever machine you want to be recording your changes (aka "running
'git commit'"), you would need to have git installed.
> (1b) if i create a repo on my office PC, can it easily be moved
> (including all history) to another PC (e.g. LAN server) if we decide to
> implement git across the team (If not, or its inconvenient, I need to
> create the repo on the server)
git is a distributed source code management system. People often deploy
one (or more, in hierarchical fashion in an advanced set-up) bare server
repository for everybody to meet and synchronize. Each developer has one
repository (or more) on his or her own on his or her machines. Most
notably, if you work on your notebook and on your desktop (i.e. two
machines), you will have (at least) one repository on each of them [*1*].
> (2) if i create a repo on my work PC, can it easily be migrated
> (including all history) to a repo on github (etc.) ?
I do not know about github in particular (that's #github question) but in
principle, yes. Easy exchange of development histories across
repositories is the whole point of distributedness.
> (3) if I create a repo and commit the first baseline, can I later create
> an ancestor commit to that baseline, if I subsequently find an older
> version of the project lying around on the file system (or, same concept
> i guess, if i find a project version that sits between say version v1.0
> and v1.1 (where v1.0 is the parent tag of v1.1) can i interleave the
> project files as say v1.01.
You can graft the older ones behind the root commit and filter-branch the
result to cast the graft in stone. You are strongly recommended to do
that in one repository first, and have reasonable level of confidence in
the result before you publish it to other repositories, as running
filter-branch to rewrite the history after people (or yourself) cloned the
history to multiple places would cause trouble to thoese .
For more details, see the user-manual. Don't dive into manual pages for
individual commands, which are for people who already understood the basic
concepts in the user manual.
[Footnote]
*1* Maybe we should change our pricing structure to be based on the number
of repositories, not on the number of users. Currently we charge $0 per
user, but we should change $0 per repository ;-)
^ permalink raw reply
* [PATCH] ls-tree: add --full-tree option
From: Junio C Hamano @ 2008-12-26 0:54 UTC (permalink / raw)
To: git; +Cc: Deskin Miller
The established behaviour of "git ls-tree $commit" run from a subdirectory
"sub/dir" in a work tree is to limit the output to the paths in the
subdirectory, and strip off the leading "sub/dir" from the output, since
3c5e846 (ls-tree: major rewrite to do pathspec, 2005-11-26).
This was a "usability" feature made back in the days when the line between
Porcelain and plumbing was blurry, and in retrospect, it probably was
misguided. The behaviour may be what the end user would expect when the
command is run interactively from a subdirectory, but it also means that a
scripted Porcelain that wants to use the command to list the full contents
of a tree object has to do cd_to_toplevel (and save the output from
"rev-parse --show-prefix" before doing so, so that it can be used as a
pathspec if it wants to limit its operation to the original subdirectory
in other commands).
This new option makes the command operate on the full tree object,
regardless of where in the work tree it is run from. It also implies the
behaviour that is triggered by the existing --full-name option.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
* There was a discussion on #git between Ilari and deskin this morning;
hopefully I captured what they wanted correctly.
I do not care too deeply with this change myself, though...
builtin-ls-tree.c | 5 +++++
1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/builtin-ls-tree.c b/builtin-ls-tree.c
index cb61717..c386aa5 100644
--- a/builtin-ls-tree.c
+++ b/builtin-ls-tree.c
@@ -156,6 +156,11 @@ int cmd_ls_tree(int argc, const char **argv, const char *prefix)
chomp_prefix = 0;
break;
}
+ if (!strcmp(argv[1]+2, "full-tree")) {
+ ls_tree_prefix = prefix = NULL;
+ chomp_prefix = 0;
+ break;
+ }
if (!prefixcmp(argv[1]+2, "abbrev=")) {
abbrev = strtoul(argv[1]+9, NULL, 10);
if (abbrev && abbrev < MINIMUM_ABBREV)
--
1.6.1
^ permalink raw reply related
* Re: a few scenarios before I create my first repo [Scanned]
From: Zorba @ 2008-12-26 1:07 UTC (permalink / raw)
To: git
In-Reply-To: <7vabajrcfn.fsf@gitster.siamese.dyndns.org>
Junio,
I am deeply priveleged that a guy like you would answer my simple Q's,
especially in holiday time !
Especially as now I've discovered a seperate list for users at
gman.comp.version-control.git.user - apologies for posting here...
> What's [scanned]?
sorry, its just something Sophos adds to our outgoing email to show its
virus checked it
>> (1a) Do I need to install windows git on the same machine I want to
>> store the files on ? Or can I install git on my workstation PC and
>> create the repo on the server ?
>
> The model employed by git is not "client working with centralized server".
> On whichever machine you want to be recording your changes (aka "running
> 'git commit'"), you would need to have git installed.
Ok, I'll install git on workstation, where I'll be running the bash / gui
from
but I'll create the repo on the server (for backup purposes) - so won't need
to install git there I'm assuming?
>> (1b) if i create a repo on my office PC, can it easily be moved
>> (including all history) to another PC (e.g. LAN server) if we decide to
>> implement git across the team (If not, or its inconvenient, I need to
>> create the repo on the server)
>
> git is a distributed source code management system. People often deploy
> one (or more, in hierarchical fashion in an advanced set-up) bare server
> repository for everybody to meet and synchronize. Each developer has one
> repository (or more) on his or her own on his or her machines. Most
> notably, if you work on your notebook and on your desktop (i.e. two
> machines), you will have (at least) one repository on each of them [*1*].
>
>> (2) if i create a repo on my work PC, can it easily be migrated
>> (including all history) to a repo on github (etc.) ?
>
> I do not know about github in particular (that's #github question) but in
> principle, yes. Easy exchange of development histories across
> repositories is the whole point of distributedness.
super!
I'm sorry distributed SCM was new to me
last time I used SCM was 10yrs ago - Visual Sourcesafe, PVCS (grrr),
clearcase (not bad)
>> (3) if I create a repo and commit the first baseline, can I later create
>> an ancestor commit to that baseline, if I subsequently find an older
>> version of the project lying around on the file system (or, same concept
>> i guess, if i find a project version that sits between say version v1.0
>> and v1.1 (where v1.0 is the parent tag of v1.1) can i interleave the
>> project files as say v1.01.
>
> You can graft the older ones behind the root commit and filter-branch the
> result to cast the graft in stone. You are strongly recommended to do
> that in one repository first, and have reasonable level of confidence in
> the result before you publish it to other repositories, as running
> filter-branch to rewrite the history after people (or yourself) cloned the
> history to multiple places would cause trouble to thoese .
that's great, it will allow us to capture the flow of work in our project so
far, and amend if some other version turns up !
Your answers are enough for me to proceed and give git a go.
> For more details, see the user-manual. Don't dive into manual pages for
> individual commands, which are for people who already understood the basic
> concepts in the user manual.
thanks, your overview here has really helped
> [Footnote]
> *1* Maybe we should change our pricing structure to be based on the number
> of repositories, not on the number of users. Currently we charge $0 per
> user, but we should change $0 per repository ;-)
LOL !
you guys are great, thank you on behalf of people like me
Happy Christmas !
^ permalink raw reply
* git-difftool
From: David Aguilar @ 2008-12-26 1:30 UTC (permalink / raw)
To: git
[-- Attachment #1: Type: text/plain, Size: 1051 bytes --]
Several co-workers have found this script useful.
It's basically git-mergetool modified to operate on the git
index/worktree. There's some things about the script that
aren't very gitish (for example, the way revargs are
processed) but it's useful nonetheless.
The usual use case for this script is when you have either
staged or unstaged changes and you'd like to see the changes
in a side-by-side diff viewer (e.g. xxdiff, tkdiff, etc).
git difftool [<filename>*]
Another use case is when you'd like to see the same
information but are comparing arbitrary commits
(this is the part where the revarg parsing could be better)
git difftool --start=HEAD^ --end=HEAD [-- <filename>*]
The last use case is when you'd like to compare your current
worktree to something other than HEAD (e.g. a tag)
git difftool --commit=v1.0.0 [-- <filename>*]
It's a generally useful script so I thought I'd share it here.
If others find it useful then maybe we can fix it up and ship
it along with the other useful goodies in contrib/.
enjoy,
--
David
[-- Attachment #2: git-difftool.sh --]
[-- Type: application/x-sh, Size: 12218 bytes --]
^ permalink raw reply
* Re: [ANNOUNCE] GIT 1.6.1
From: Sitaram Chamarty @ 2008-12-26 1:38 UTC (permalink / raw)
To: git; +Cc: linux-kernel
In-Reply-To: <20081225114443.GD6115@zakalwe.fi>
["Followup-To:" header set to gmane.comp.version-control.git.]
On 2008-12-25, Heikki Orsila <shdl@zakalwe.fi> wrote:
> * What would be the probability for a single bit flip to corrupt the
> repository?
> * And what is the situation where a single bit flip can not corrupt the
> database?
These two questions are not specific to git; whatever
answers apply to sha1 also apply here. Sha1 will always be
strong enough to detect any combination of random errors.
As for deliberate attacks, it is considered strong enough to
resist all but the most computationally intensive attacks
(the kind that require a worldwide effort or maybe NSA type
facilities).
> * When (which commands/functions) is error detection done?
"git fsck --full" will do it of course, but I'm not sure
what other operations also start off or end up doing a
check.
^ permalink raw reply
* Re: a few scenarios before I create my first repo [Scanned]
From: Sitaram Chamarty @ 2008-12-26 2:07 UTC (permalink / raw)
To: git
In-Reply-To: <7vabajrcfn.fsf@gitster.siamese.dyndns.org>
On 2008-12-26, Junio C Hamano <gitster@pobox.com> wrote:
> What's [scanned]?
>
> "Conor Rafferty" <conor.rafferty@altmore.co.uk> writes:
>> (3) if I create a repo and commit the first baseline, can I later create
>> an ancestor commit to that baseline, if I subsequently find an older
>> version of the project lying around on the file system (or, same concept
>> i guess, if i find a project version that sits between say version v1.0
>> and v1.1 (where v1.0 is the parent tag of v1.1) can i interleave the
>> project files as say v1.01.
>
> You can graft the older ones behind the root commit and filter-branch the
> result to cast the graft in stone. You are strongly recommended to do
> that in one repository first, and have reasonable level of confidence in
> the result before you publish it to other repositories, as running
> filter-branch to rewrite the history after people (or yourself) cloned the
> history to multiple places would cause trouble to thoese .
Considering the level of questions that Conor had, I thought
the following may be useful:
The way git works is that each commit is represented by a
sha-1 hash, which is an immutable 160-bit number that
"represents" that commit. The hash of the parent commit(s),
if any, as well as the contents of the current "tree" are
inputs to this hash, so if you create or change a parent,
the hash will change.
The sanctity of these hashes is fundamental to the
distributedness of git, so when you do something like that,
you're causing problems to any other repos which "pull"ed
from you, or which you "push"ed to -- they thought your
"latest" commit had, say, hash "A", but now hash "A" no
longer exists in your repo and has been replaced by hash
"B".
I have not (yet) had occasion to use either grafting or
filter-branch, but I'm pretty sure someone would have a nice
tutorial somewhere they can point to...
^ 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