* Re: VCS comparison table
From: Jakub Narebski @ 2006-10-21 13:05 UTC (permalink / raw)
To: git; +Cc: bazaar-ng
In-Reply-To: <20061021123027.GB29843@artax.karlin.mff.cuni.cz>
Jan Hudec wrote:
> On Fri, Oct 20, 2006 at 12:05:35AM -0400, Aaron Bentley wrote:
>> Tim Webster wrote:
>> > Also svn does not allow files in the same directory to live in
>> > multiple repos
>>
>> It would surprise me if many SCMs that support atomic commit also
>> support intermixing files from multiple repos in the same directory.
>
> In fact I think svk would. You would have to switch them by setting
> an environment variable, but it's probably doable. That is because
> unlike other version control systems, it does not store the information
> about checkout in the checkout, but in the central directory and that
> can be set. I don't know git well enough to tell whether git could do
> the same by setting GIT_DIR.
You can very simply embed one "clothed" repository into another in GIT,
like shown below
project/.git
project/subdir/
project/subdir/file
project/subproject/
project/subproject/.git
project/subproject/file
...
It depends on circumstances if one wants files belonging to subdirectory
be ignored by top repository. You would want to ignore .git/ directory,
though.
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: VCS comparison table
From: Matthew D. Fuller @ 2006-10-21 13:01 UTC (permalink / raw)
To: Carl Worth
Cc: Aaron Bentley, Linus Torvalds, Andreas Ericsson, bazaar-ng, git,
Jakub Narebski
In-Reply-To: <87irie1wvv.wl%cworth@cworth.org>
On Fri, Oct 20, 2006 at 02:48:52PM -0700 I heard the voice of
Carl Worth, and lo! it spake thus:
>
> The entire discussion is about how to name things in a distributed
> system.
I think we're getting into scratched-record-mode on this.
Git: Revnos aren't globally unique or persistent.
Bzr: Yes, we know.
G: Therefore they're useless.
B: No, they're very useful in [situation] and [situation], and we deal
with [situation] all the time, and they work great for that.
G: But they fall apart totally in [situation].
B: Yes, so use revids there.
G: So use revids everywhere.
B: Revnos are handier tools for [situation] and [situation] for
[reason] and [reason].
*brrrrrrrrrrrrrrrrip!!!* *skip back to start*
I'm not sure there's any unturned stone left along this line, so I'm
not sure how productive it really is to keep walking down it. So, to
make something productive of it, I'm going to put it onto my todo list
to spend some time with bzr trying to use revids for stuff. I'm
fairly certain that, due to the bzr cultural tendancy to use revnos
where possible, there are some rough edges in the UI when using revids
that should be filed down (though I think it much less likely to turn
up underlying model failures that interfere with using revids).
> It may be that the centralization bias
I think it's more accurately describable as a branch-identity bias.
The git claim seems to be that the two statements are identical, but I
have some trouble swallowing that.
> I'm still not sure exactly what a bzr branch is, but it's clearly
> something different from a git branch,
The term is somewhat overloaded, which is why it's causing you trouble
(and did me). It refers both to the conceptual entity ("a line of
development" roughly, much like what 'branch' means in git and VCS in
general), and to the physical location (directory, URL) where that
branch is stored, and where it'll often have a working tree. Branches
are always referred to by location, never by name.
> (and I'd be interested to see a "corrected" version of the commands
> above to fix the storage inefficiencies).
The 'corrected' step would be:
> mkdir bzrtest; cd bzrtest
bzr init-repo .
> mkdir master; cd master; bzr init
Then all branches stored under that 'bzrtest' dir will use the
bzrtest/.bzr/ dir for storing the revisions, and shared revisions will
only exist once saving the space/time for multiple copies.
Probably, you'd actually want 'init-repo --trees' in this case,
because repos default to being [working]tree-less. In a tree-less
setup, you'd create a [lightweight] checkout of the branch(es) you
wanted to work on elsewhere, giving you a layout much like CVS or SVN
where "my VCS files are THERE, my working tree is HERE".
> (since pull seems the only way to synch up without infinite new
> merge commits being added back and forth).
The infinite-merge-commits case doesn't happen in bzr-land because we
generally don't merge other branches except when the branch owner says
"Hey, I've got something for you to merge". If you were to setup a
script to merge two branches back and forth until they were 'equal',
yes, it'd churn away until you filled up your disk with the N bytes of
metadata every new revision uses up.
--
Matthew Fuller (MF4839) | fullermd@over-yonder.net
Systems/Network Administrator | http://www.over-yonder.net/~fullermd/
On the Internet, nobody can hear you scream.
^ permalink raw reply
* Re: VCS comparison table
From: Matthew D. Fuller @ 2006-10-21 12:30 UTC (permalink / raw)
To: Jakub Narebski; +Cc: bazaar-ng, git
In-Reply-To: <eha926$uc$2@sea.gmane.org>
On Fri, Oct 20, 2006 at 12:40:11PM +0200 I heard the voice of
Jakub Narebski, and lo! it spake thus:
>
> I'd like to put ComparisonWithBazaarNG page on GitWiki
> (http://git.or.cz/gitwiki/) some time soon,
This is a good idea; I think we've plowed a lot of ground in this
thread that would be useful to document somewhere easily
referenceable. I've thought a few times while going through these
mails of putting some of the material up on the Bazaar wiki. I'm not
really the best person to try and sort it out, but I may try and put
together some notes at least.
--
Matthew Fuller (MF4839) | fullermd@over-yonder.net
Systems/Network Administrator | http://www.over-yonder.net/~fullermd/
On the Internet, nobody can hear you scream.
^ permalink raw reply
* Re: VCS comparison table
From: Jan Hudec @ 2006-10-21 12:30 UTC (permalink / raw)
To: Aaron Bentley
Cc: Tim Webster, Christian MICHON, Andreas Ericsson, bazaar-ng, git,
Matthieu Moy
In-Reply-To: <45384B0F.4040901@utoronto.ca>
On Fri, Oct 20, 2006 at 12:05:35AM -0400, Aaron Bentley wrote:
> Tim Webster wrote:
> > Also svn does not allow files in the same directory to live in
> > multiple repos
>
> It would surprise me if many SCMs that support atomic commit also
> support intermixing files from multiple repos in the same directory.
In fact I think svk would. You would have to switch them by setting
an environment variable, but it's probably doable. That is because
unlike other version control systems, it does not store the information
about checkout in the checkout, but in the central directory and that
can be set. I don't know git well enough to tell whether git could do
the same by setting GIT_DIR.
--------------------------------------------------------------------------------
- Jan Hudec `Bulb' <bulb@ucw.cz>
^ permalink raw reply
* [PATCH] Add -v option to git-branch.sh
From: Lars Hjemli @ 2006-10-21 11:32 UTC (permalink / raw)
To: git; +Cc: Lars Hjemli
Teach git-branch to show sha1 and subject for each branch tip.
This requires branch names to be max 20 chars for the output to be
properly aligned. Not optimal, but doing an extra pass just to find
the longest name didn't seem reasonable either.
Signed-off-by: Lars Hjemli <hjemli@gmail.com>
---
git-branch.sh | 14 ++++++++++++--
1 files changed, 12 insertions(+), 2 deletions(-)
diff --git a/git-branch.sh b/git-branch.sh
index 4379a07..6a425e0 100755
--- a/git-branch.sh
+++ b/git-branch.sh
@@ -1,6 +1,6 @@
#!/bin/sh
-USAGE='[-l] [(-d | -D) <branchname>] | [[-f] <branchname> [<start-point>]] | -r'
+USAGE='[-l] [(-d | -D) <branchname>] | [[-f] <branchname> [<start-point>]] | -r | -v'
LONG_USAGE='If no arguments, show available branches and mark current branch with a star.
If one argument, create a new branch <branchname> based off of current HEAD.
If two arguments, create a new branch <branchname> based off of <start-point>.'
@@ -56,6 +56,7 @@ ls_remote_branches () {
force=
create_log=
+verbose=
while case "$#,$1" in 0,*) break ;; *,-*) ;; *) break ;; esac
do
case "$1" in
@@ -73,6 +74,9 @@ do
-l)
create_log="yes"
;;
+ -v)
+ verbose="yes"
+ ;;
--)
shift
break
@@ -96,7 +100,13 @@ case "$#" in
else
pfx=' '
fi
- echo "$pfx $ref"
+ if test "$verbose" = "yes"
+ then
+ log=$(git-log --max-count=1 --pretty=oneline $ref)
+ printf "%s %-20s %s\n" "$pfx" "$ref" "$log"
+ else
+ echo "$pfx $ref"
+ fi
done
exit 0 ;;
1)
--
1.4.3.ge193
^ permalink raw reply related
* New software uploaded by Judy on Oct 21 14:50:00 MSK 2006
From: Adobe Software @ 2004-04-06 11:51 UTC (permalink / raw)
To: git
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit, Size: 6581 bytes --]
Judy has uploaded some new software for you!
Click here to view available updated software:
http://update.eroemina.com/?Judy
To enable the filters, you need to define a set of rules for the
66:#4 0xf012a183 in open ()
Supplementary Documents. O'Reilly & Associates, Inc., 1994.
values filled in for the pw and pl capabilities in the /etc/printcap
You can substitute any program for /sbin/init, as long as you keep in
Presuming you have successfully installed the recompiled kernel and
o An actual bug report should be filed by using the send-pr(1)
/compat/linux/lib/libc.so.4 -> libc.so.4.6.27
This is done on the Kerberos server only. First make sure that your do
``standard'' location for these cards.
output slip\x0d, input 10 Username:, if failure stop, -
mkdir -p /var/spool/lpd/rattan /var/spool/lpd/bamboo
were printed on top of each other on one line.
o DEC FDDI (DEFPA/DEFEA) NICs
your Makefile will not accomplish this, so please use ${DIST_SUBDIR}.)
Warning: Quality control on these drives varies greatly. One FreeBSD
can build ports directly off the CDROM by building them in the link
[For an Adaptec AHA274x, 284x etc controller]
Can not run more than 2 bus master devices. Admitted Intel
By enabling header pages, LPD will produce a long header, a full page
capability:
Here is a list of common do's and dont's that you encounter during the
for user ppp, so keep them around for reference. The easiest way to do
This part was used in the original IBM PC and IBM PC/XT. The
for us improving it.
10.4.5.7.12.
2. Leave the lp capability blank, explicitly (:lp=:).
correspondence. If you do not receive confirmation in a timely
All three of the commands lpr, lprm, and lpq accept an option ``-P
device sb0 at isa? port 0x220 irq 7 conflicts drq 1 vector sbintr
This device provides IDE CD-ROM support. Be sure to leave wdc1
Password:
Bit 4 Reserved, always 0.
to handle these aspects. And the bad news is that most of the time
signals, so if you have problems, such as a login session not going
using other drivers, or when particular combinations of events occur
device addressing.
Triton chip set, we ``fixed it there''.
If your ${DISTNAME} does not look like
pseudo-device loop
perform the following steps:
using lptest. You can do so by putting the program in a file and typ-
filter for a Hewlett Packard LaserJet III-Si printer:
______________________________________________________________________
typesetting data, into formats your printer can understand. After
The same mechanism is used in Hewlett-Packard's SureStore 2000i tape
if you are printing standard input.
# cd databases/gnats
It will also look at the subdirectory with the same name on the backup
limit on file size. Note that the limit applies to files in a job,
relevant partitions. So, when installing FreeBSD you must answer any
Mar 29 21:16:37 yedi /386bsd: aha0 targ 5 lun 0: <ARCHIVE VIPER 150 21247-005>
-m Send mail after completing the print job. With this option, the
1. Fix it yourself. Technical details can be found in ``Porting
xxx.xxx.yy's into the network address of your own SLIP subnet (be sure
number or certain types of problems have been detected. As part of
controller, then for an Adaptec 174x board, and so on. The lines
sites support access to CTM:
o Laser5 in Japan has graciously donated a portion of their profits
o ftp.ibp.fr/pub/FreeBSD
Since the DMA cycle only transfers a single byte at a time, the FDC
QIC (Quarter-Inch Cartridge)
0xde write Write All Mask Register Bits
sio2: type 16550A
devices are in their factory default configuration in terms of IRQs,
sticky bit set. The filter can create the link, but it will not be
New Password: <---- enter RANDOM here
1024 (this will allow internal users to rsh/rlogin to the outside).
nameserver 158.152.1.65
printer; here is bamboo's entry:
determine the root filesystem and initialize user-land things. This
o You know how to configure your modem (probably via a terminal
latest version of the port you want, you'll need to download the
In case of problems, please contact the hostmaster for this
Reported by: Stefan Esser seZPR.Uni-Koeln.DE
# chflags schg /kernel
leads to some interesting possibilities shown below.
more easily around our sites?
For a variable-speed configuration, you will need to configure your
10.3.1. * Video cards
If it is only one or two versions out of date in the in the trailing
fastws: freebox:/sharedfs /project nfs rw,-w=1024 0 0 as a manual
page and how many pages were in a user's job. For more information on
filesystem on each floppy. You can use the `disklabel' and `newfs'
Modern high speed modems (2400, 9600, 14,400, and 19,200bps) in
Digital Equipment EtherWorks 2 and EtherWorks 3 (DEPCA,
o Switch 6: UP - Carrier Detect Normal
signals, carried on 50 wires. (If you do not know what single-ended
the events occurs. The 8250/16450/16550 UART
use this new feature. It will save you a lot of grief whenever you
the past have resulted from the use of improperly formatted media,
root access to these filesystems
See ``Header Pages'' for details.
and the text filter generate the header page. The filters should
; put your userid here:
commonly-used filesystems in the kernel, but feel free to comment out
18. Contributing to FreeBSD
the command line interface invoked by 'math' is unaffected by this
pppd) and it is thus somewhat hard to debug and/or modify
PATH=/bin:/sbin:/usr/sbin:/usr/bin
several completely different things).
error message about /etc/host.conf if you leave this out.
/compat/linux/lib/libc.so.4.6.29
usage of the term Baud to describe the overall communication speed
has a network interface in addition (or in place of) a more
instructions: you will need to be root on your FreeBSD system to do
flow control. The locking devices are used to lock flags on ports to
Also, refer to programs/files from other ports with the variables
control.
the host CPU for data movement.
the ``makeflp.bat'' command. NOTE: If you are running FreeBSD
:sm=255.255.255.0:\
Destination Gateway Flags Refs Use Netif Expire
are using one of the multiport cards where shared interrupts are
Bit 2 Parity Error (PE)
lpr: multiple copies are not allowed
`libcrypt' contains only the code involved in performing the one-way
FreeBSD. Here's an overview of the user-level commands:
10.4.5.7.1.
your printer to spew out hundreds of sheets of paper.
[for the cdrom]
device sio5 at isa? port 0x108 tty flags 0xb05
You should set ${DISTNAME} to be the base name of your port. The
^ permalink raw reply
* Re: [RFC] Syntax highlighting for combined diff
From: Junio C Hamano @ 2006-10-21 10:40 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <200610211202.00314.jnareb@gmail.com>
Jakub Narebski <jnareb@gmail.com> writes:
> Junio C Hamano wrote:
>> Jakub Narebski <jnareb@gmail.com> writes:
>>
>> > Do I understand code correctly, and the last '+' or '-'
>> > in the parents column means?
>> >
>> > for (i = 0; i < ecbdata->nparents && len; i++) {
>> > if (line[i] == '-')
>> > color = DIFF_FILE_OLD;
>> > else if (line[i] == '+')
>> > color = DIFF_FILE_NEW;
>> > }
>> >
>> > Anyone who wrote this code, could you answer me, please?
>>
>> The "up to ecbdata->nparents" is Johannes in cd112ce. But you
>> are looking at a wrong code, I am afraid, if your original
>> question was about the combined format (there is a comment about
>> the codepath dealing only with two-way diffs by Johannes, above
>> the part you quoted). The output for combined diff is coming
>> from combine-diff.c:dump_sline().
>
> I was asking both about combined diff format, and how it is colored
> by git-diff --color, to add colored combined diff output to gitweb.
I was answering about both. dump_sline() implements both format
and coloring.
> Any other ideas how combined commitdiff should look like in gitweb?
Combined or no combined, one thing that mildly irritates me
sometimes is that there does not seem to be an easy and obvious
way to do a rough equivalent of typing SPACE repeatedly while
viewing "git log -p".
In other words, I think it would be a nice addition to have "go
to commitdiff page of this parent" links near the top on the
commitdiff page.
^ permalink raw reply
* Re: [ANNOUNCE] Example Cogito Addon - cogito-bundle
From: Jakub Narebski @ 2006-10-21 10:34 UTC (permalink / raw)
To: Matthieu Moy; +Cc: bazaar-ng, git
In-Reply-To: <vpq64eeyo8v.fsf@ecrins.imag.fr>
Matthieu Moy wrote:
> Another relevant difference between a patch and a bundle is that the
> bundles knows its ancestor, so, when you apply the bundle, it builds
> the new revision with exact patching. If you need a merge, then it
> will happen exactly in the same way as a merge between two branches
> (ie. three-way merge for example).
By the way, if patch send via email is git enchanced patch, with
[shortened] sha1 of blobs (file contents), and our repository has
the blob the patch is supposedly to apply to (but for example line
of development moved forwards) we can request via --3way command
option to git-am to fall back on 3-way merge if the patch doesn't
apply cleanly.
It is not as powerfull as merge of branches, but it is sufficient
in most cases. And in other cases you have to resolve conflict by
hand, anyway; git-rerere (which records resolving of conflicts and
reuses them) can help there.
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: [ANNOUNCE] Example Cogito Addon - cogito-bundle
From: Matthieu Moy @ 2006-10-21 10:09 UTC (permalink / raw)
To: Jakub Narebski; +Cc: bazaar-ng, git
In-Reply-To: <200610211036.44679.jnareb@gmail.com>
Jakub Narebski <jnareb@gmail.com> writes:
> Ah, that explains this. So why people use bundles instead of patches
> (with some metainfo like commit message)?
You need more metainfo than the commit message. Since revision-id is
not based on the content, you need at least to specify the
revision-id.
And bzr's bundle give indeed _all_ the information that is in the
repository about this revision (i.e. commit message, ancestors, ...).
Another relevant difference between a patch and a bundle is that the
bundles knows its ancestor, so, when you apply the bundle, it builds
the new revision with exact patching. If you need a merge, then it
will happen exactly in the same way as a merge between two branches
(ie. three-way merge for example).
> And do bzr have command to apply in correct ordering series of
> bundles send either chain replied to (each patch in the series is
> reply to previous patch) or being replies to patchseries
> introductory message?
Not directly AFAIK, but since the bundle knows which revision it
applies to, it will refuse to apply the second if the first one is not
in your repository already for example.
It would probably be interesting to have more features to help sending
series of bundles and apply them, but no one have been really asking
for it up to now.
--
Matthieu
^ permalink raw reply
* Re: [RFC] Syntax highlighting for combined diff
From: Jakub Narebski @ 2006-10-21 10:02 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vfydigg4w.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
> Jakub Narebski <jnareb@gmail.com> writes:
>
> > Do I understand code correctly, and the last '+' or '-'
> > in the parents column means?
> >
> > for (i = 0; i < ecbdata->nparents && len; i++) {
> > if (line[i] == '-')
> > color = DIFF_FILE_OLD;
> > else if (line[i] == '+')
> > color = DIFF_FILE_NEW;
> > }
> >
> > Anyone who wrote this code, could you answer me, please?
>
> The "up to ecbdata->nparents" is Johannes in cd112ce. But you
> are looking at a wrong code, I am afraid, if your original
> question was about the combined format (there is a comment about
> the codepath dealing only with two-way diffs by Johannes, above
> the part you quoted). The output for combined diff is coming
> from combine-diff.c:dump_sline().
I was asking both about combined diff format, and how it is colored
by git-diff --color, to add colored combined diff output to gitweb.
> Combined diff output logic pretty much guarantees that you never
> will see plus and minus on the same line.
That's enough for me.
Any other ideas how combined commitdiff should look like in gitweb?
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: [ANNOUNCE] GIT 1.4.3
From: Andreas Schwab @ 2006-10-21 9:53 UTC (permalink / raw)
To: Petr Baudis; +Cc: Linus Torvalds, Junio C Hamano, git, linux-kernel
In-Reply-To: <20061021002251.GO20017@pasky.or.cz>
Petr Baudis <pasky@suse.cz> writes:
> (I personally consider alternate screen an abomination. It would be so
> nice if the terminal emulators would just make it optional.)
$ xterm -rm "*titeInhibit: true"
Andreas.
--
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
^ permalink raw reply
* Re: [RFC] Syntax highlighting for combined diff
From: Junio C Hamano @ 2006-10-21 9:41 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <200610211049.56477.jnareb@gmail.com>
Jakub Narebski <jnareb@gmail.com> writes:
> Do I understand code correctly, and the last '+' or '-'
> in the parents column means?
>
> for (i = 0; i < ecbdata->nparents && len; i++) {
> if (line[i] == '-')
> color = DIFF_FILE_OLD;
> else if (line[i] == '+')
> color = DIFF_FILE_NEW;
> }
>
> Anyone who wrote this code, could you answer me, please?
The "up to ecbdata->nparents" is Johannes in cd112ce. But you
are looking at a wrong code, I am afraid, if your original
question was about the combined format (there is a comment about
the codepath dealing only with two-way diffs by Johannes, above
the part you quoted). The output for combined diff is coming
from combine-diff.c:dump_sline().
Combined diff output logic pretty much guarantees that you never
will see plus and minus on the same line.
^ permalink raw reply
* Re: [PATCH] make cg-commit --review restore original tree state afterwards
From: Sam Vilain @ 2006-10-21 9:40 UTC (permalink / raw)
To: Petr Baudis; +Cc: git
In-Reply-To: <20061021014723.B8E9C13810D@magnus.utsl.gen.nz>
Ok, I ruined the error message.
This could also do with some enhancement; if you edit hunks of the
patch, then the numbers in the hunks could be updated so as to not make
the patch abort. Also, if it does abort you should get the option of
undoing everything, or editing the patch again...
Will try again with this another time.
Sam.
Sam Vilain wrote:
> If you delete hunks from the patch that 'cg-commit -p' shows you, then
> they are lost 'forever'. Let's put back everything how it was
> beforehand instead.
> ---
> cg-commit | 25 +++++++++++++++++--------
> 1 files changed, 17 insertions(+), 8 deletions(-)
>
> diff --git a/cg-commit b/cg-commit
> index 01a4eb7..81b3619 100755
> --- a/cg-commit
> +++ b/cg-commit
> @@ -568,18 +568,16 @@ else
> fi
> rm "$LOGMSG2"
>
> +pine_for_darcs() {
> + die "unable to revert the new patch; the original patch is available in $PATCH, your edited patch is available in $PATCH2, your log message is in $LOGMSG, your working copy is in undefined state now and the world is about to end in ten minutes, have a nice day"
> +}
> +
> if [ "$review" ]; then
> if ! cmp -s "$PATCH" "$PATCH2"; then
> echo "Reverting the original patch..."
> - if ! cg-patch -R < "$PATCH"; then
> - die "unable to revert the original patch; the original patch is available in $PATCH, your edited patch is available in $PATCH2, your log message is in $LOGMSG, your working copy is in undefined state now and the world is about to end in ten minutes, have a nice day"
> - fi
> + cg-patch -R < "$PATCH" || pine_for_darcs
> echo "Applying the edited patch..."
> - if ! cg-patch < "$PATCH2"; then
> - # FIXME: Do something better to alleviate this situation.
> - # At least restore the tree to the original state.
> - die "unable to apply the edited patch; the original patch is available in $PATCH, your edited patch is available in $PATCH2, your log message is in $LOGMSG, your working copy is in undefined state now and the world is about to end in five minutes, have a nice day"
> - fi
> + cg-patch < "$PATCH2" || pine_for_darcs
> fi
> fi
>
> @@ -625,6 +623,17 @@ if [ "$amend" ]; then
> fi
>
> treeid="$(git-write-tree ${missingok})"
> +
> +if [ "$review" ]; then
> + if ! cmp -s "$PATCH" "$PATCH2"; then
> + echo "Reverting the new patch..."
> + cg-patch -R < "$PATCH2" || pine_for_darcs
> + echo "Applying the old patch..."
> + cg-patch < "$PATCH" || pine_for_darcs
> + fi
> +fi
> +
> +
> [ "$treeid" ] || die "git-write-tree failed"
> if [ ! "$force" ] && [ ! "$merging" ] && [ "$oldhead" ] &&
> [ "$treeid" = "$(cg-object-id -t)" ]; then
^ permalink raw reply
* Re: VCS comparison table
From: Erik Bågfors @ 2006-10-21 8:48 UTC (permalink / raw)
To: Jakub Narebski; +Cc: bazaar-ng, git
In-Reply-To: <ehclkf$v3e$1@sea.gmane.org>
On 10/21/06, Jakub Narebski <jnareb@gmail.com> wrote:
> Sean wrote:
>
> > On Tue, 17 Oct 2006 13:45:31 +0200
> > Jakub Narebski <jnareb@gmail.com> wrote:
> >
> >> Git cannot do that remotely (with exception of git-tar-tree/git-archive
> >> which has --remote option), yet. But you can get contents of a file
> >> (with "git cat-file -p [<revision>:|:<stage>:]<filename>"), list
> >> directory (with "git ls-tree <tree-ish>") and compare files or
> >> directories (git diff family of commands) without need for working
> >> directory.
> >
> > Interesting, I didn't know about the --remote option. So in fact as long
> > as the remote has enabled upload-tar then anyone can do a "light
> > checkout".
>
> Not exactly. "Light checkout" (aka "lazy one-branch clone") in bzr
> contains also info about the repository it came from, and has some
> metadata that you can commit to it locally. git tar-tree --remote
> just gets snapshot.
No, a lightweight checkout doesn't have that. A lightweight checkout
is basically just the latest revision checked out, a snapshot. For
everything else it needs to go the remote branch to get information.
You cannot commit locally on a "lightwieght checkout"
A "normal/heavyweight" checkout has the ability to commit locally.
/Erik
^ permalink raw reply
* Re: [RFC] Syntax highlighting for combined diff
From: Jakub Narebski @ 2006-10-21 8:49 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vslhigld7.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
> Jakub Narebski <jnareb@gmail.com> writes:
>
>> So the question is how to color combined diff format (what should be syntax
>> highlighting for combined diff format). If branches columns have only
>> pluses we use the same color as for adding line in ordinary diff; if
>> branches column consist only of minuses we use the same color as for
>> removing line in ordinary diff. Can there be mixture of plusses and
>> minuses? How git-diff --color solves this?
>
> UTSL ;-).
>
> Otherwise (iow, if you refuse to use the source), you could
> cheat and let "git diff" do the coloring for you, and then
> regexp replace the output. You could even use the same coloring
> logic for normal diff if you did so.
Do I understand code correctly, and the last '+' or '-'
in the parents column means?
for (i = 0; i < ecbdata->nparents && len; i++) {
if (line[i] == '-')
color = DIFF_FILE_OLD;
else if (line[i] == '+')
color = DIFF_FILE_NEW;
}
Anyone who wrote this code, could you answer me, please?
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: [ANNOUNCE] Example Cogito Addon - cogito-bundle
From: Jakub Narebski @ 2006-10-21 8:40 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Jan Hudec, bazaar-ng, Jeff Licquia, Linus Torvalds
In-Reply-To: <7vk62ujw7j.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
> For people new to the list, the message is:
>
> http://thread.gmane.org/gmane.comp.version-control.git/27/focus=217
>
> I think I've quoted this link at least three times on this list;
> I consider it is _the_ most important message in the whole list
> archive. If you haven't read it, read it now, print it out,
> read it three more times, place it under the pillow before you
> sleep tonight. Repeat that until you can recite the whole
> message. It should not take more than a week.
>
> To me, personally, achieving that ideal "drill down" dream was
> one of the more important goals of my involvement in this
> project. I did diffcore-rename to fill some part of the dream,
> and then diffcore-pickaxe to fill some other part. Neither was
> even close. I think the recent round of pickaxe is getting much
> closer.
What I find lacking in this mail, and in git as it is now, is
somehow remembering and perhaps even propagating user's corrections
to automatic contents movement (which includes file renames and
file copying) detection.
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: [ANNOUNCE] Example Cogito Addon - cogito-bundle
From: Jakub Narebski @ 2006-10-21 8:36 UTC (permalink / raw)
To: Matthieu Moy; +Cc: bazaar-ng, git
In-Reply-To: <vpqk62uhzkk.fsf@ecrins.imag.fr>
Matthieu Moy wrote:
> Jakub Narebski <jnareb@gmail.com> writes:
>
>>> It's my understanding that most changes discussed on lkml are provided
>>> as a series of patches. Bazaar bundles are intended as a direct
>>> replacement for patches in that use case.
>>
>> As _series_ of patches. You have git-format-patch + git-send-email
>> to format and send them, git-am to apply them (as patches, not as branch).
>>
>> I was under an impression that user sees only mega-patch of all the
>> revisions in bundle together, and rest is for machine consumption only.
>
> Nothing prevents you from using series of bundles.
>
> A bundle for a single revision looks like a patch with a few comments
> on top and bottom. _If_ you have several revisions in your patch, you
> get the diff as human readable, and the intermediate revisions as
> MIME-encoded.
>
> For big changes, people do send several bundles.
>
> So, a bundle is a direct replacement for a patch, not for series of
> patches.
Ah, that explains this. So why people use bundles instead of patches
(with some metainfo like commit message)? And do bzr have command to
apply in correct ordering series of bundles send either chain replied
to (each patch in the series is reply to previous patch) or being
replies to patchseries introductory message?
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: VCS comparison table
From: Jakub Narebski @ 2006-10-21 8:32 UTC (permalink / raw)
To: git
In-Reply-To: <Pine.LNX.4.64.0610201854350.3962@g5.osdl.org>
Linus Torvalds wrote:
> On Fri, 20 Oct 2006, Junio C Hamano wrote:
>>
>> I was not talking about "git pull". I was talking about "git
>> show".
>
> Duh. I don't know why I misread that.
>
> Yeah, that makes no sense at all. I _think_ "git show" should be the same
> thing as a single-entry "git log -p".
Huh?
$ git show ff49fae6a547e5c70117970e01c53b64d983cd10
commit ff49fae6a547e5c70117970e01c53b64d983cd10
Merge: 7ad4ee7... 75f9007... 14eab2b... 0b35995... eee4609...
[...]
diff --cc Makefile
index 36b9e06,68ae43b,66c8b4b,66c8b4b,09f60bb..a2f2f7c
[...]
"git show" doesn't prefer first parent: it uses compact combined
(that is the meaning of --cc, isn't it?) format for merges.
git version 1.4.2.1
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: VCS comparison table
From: Jakub Narebski @ 2006-10-21 8:27 UTC (permalink / raw)
To: bazaar-ng; +Cc: git
In-Reply-To: <20061017080702.615a3b2f.seanlkml__27953.817000571$1161408618$gmane$org@sympatico.ca>
Sean wrote:
> On Tue, 17 Oct 2006 13:45:31 +0200
> Jakub Narebski <jnareb@gmail.com> wrote:
>
>> Git cannot do that remotely (with exception of git-tar-tree/git-archive
>> which has --remote option), yet. But you can get contents of a file
>> (with "git cat-file -p [<revision>:|:<stage>:]<filename>"), list
>> directory (with "git ls-tree <tree-ish>") and compare files or
>> directories (git diff family of commands) without need for working
>> directory.
>
> Interesting, I didn't know about the --remote option. So in fact as long
> as the remote has enabled upload-tar then anyone can do a "light
> checkout".
Not exactly. "Light checkout" (aka "lazy one-branch clone") in bzr
contains also info about the repository it came from, and has some
metadata that you can commit to it locally. git tar-tree --remote
just gets snapshot.
> However, it appears that kernel.org for instance doesn't enable this
> feature.
One can get snapshot from gitweb... if gitweb is new enough and
has this feature enabled (it is enabled by default). Again not
the case of kernel.org
^ permalink raw reply
* Re: [ANNOUNCE] Example Cogito Addon - cogito-bundle
From: Matthieu Moy @ 2006-10-21 7:56 UTC (permalink / raw)
To: Jakub Narebski; +Cc: bazaar-ng, git
In-Reply-To: <ehao3e$2qv$1@sea.gmane.org>
Jakub Narebski <jnareb@gmail.com> writes:
>> It's my understanding that most changes discussed on lkml are provided
>> as a series of patches. Bazaar bundles are intended as a direct
>> replacement for patches in that use case.
>
> As _series_ of patches. You have git-format-patch + git-send-email
> to format and send them, git-am to apply them (as patches, not as branch).
>
> I was under an impression that user sees only mega-patch of all the
> revisions in bundle together, and rest is for machine consumption only.
Nothing prevents you from using series of bundles.
A bundle for a single revision looks like a patch with a few comments
on top and bottom. _If_ you have several revisions in your patch, you
get the diff as human readable, and the intermediate revisions as
MIME-encoded.
For big changes, people do send several bundles.
So, a bundle is a direct replacement for a patch, not for series of
patches.
--
Matthieu
^ permalink raw reply
* Re: [RFC] Syntax highlighting for combined diff
From: Junio C Hamano @ 2006-10-21 7:48 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <ehbq0k$24l$1@sea.gmane.org>
Jakub Narebski <jnareb@gmail.com> writes:
> So the question is how to color combined diff format (what should be syntax
> highlighting for combined diff format). If branches columns have only
> pluses we use the same color as for adding line in ordinary diff; if
> branches column consist only of minuses we use the same color as for
> removing line in ordinary diff. Can there be mixture of plusses and
> minuses? How git-diff --color solves this?
UTSL ;-).
Otherwise (iow, if you refuse to use the source), you could
cheat and let "git diff" do the coloring for you, and then
regexp replace the output. You could even use the same coloring
logic for normal diff if you did so.
^ permalink raw reply
* Re: Signed git-tag doesn't find default key
From: Andy Parkins @ 2006-10-21 7:44 UTC (permalink / raw)
To: git
In-Reply-To: <200610210052.k9L0q88T005342@laptop13.inf.utfsm.cl>
[-- Attachment #1: Type: text/plain, Size: 492 bytes --]
On Saturday 2006, October 21 01:52, Horst H. von Brand wrote:
> There very well might be... say you have a key for signing git stuff,
> another one for emailing, another one for signing RPMs you create, ... I
> believe that is the idea of the GPG comment field, precisely.
Either way, you're arguing for the fault being with Git - which has no notion
of comment fields and so won't find the key anyway.
Andy
--
Dr Andrew Parkins, M Eng (Hons), AMIEE
andyparkins@gmail.com
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH 2/2] Remove dead code after direct graph drawing
From: Marco Costalba @ 2006-10-21 6:35 UTC (permalink / raw)
To: Josef Weidendorfer; +Cc: git
In-Reply-To: <200610200111.26259.Josef.Weidendorfer@gmx.de>
Josef,
I think ther's a leak somewhere.
Checking memory use with ksysguard is see memory use going up
scrolling up and down also on the same revisions list view subset.
I'm not sure it depends on your patch though.
Marco
^ permalink raw reply
* Re: VCS comparison table
From: Junio C Hamano @ 2006-10-21 5:49 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0610191258290.3962@g5.osdl.org>
Linus Torvalds <torvalds@osdl.org> writes:
> For example, while git now does "annotate" (or "blame"), it's not
> lightning fast, and I simply don't care. Doing a
>
> git blame kernel/sched.c
>
> takes about three seconds for me, and that's on a pretty good machine (and
> on the kernel tree, which for me is always in the cache ;).
ll.6041-6091 of that file is blamed to arch/ia64/kernel/domain.c
by pickaxe -C (attributed to commit 2.6.12-rc2) while blame says
they are brought in by commit 9c1cfa, which says "Move the ia64
domain setup code to the generic code". I am slowly realizing
that comparing the output from blame and pickaxe might be a good
way to study the project history.
^ permalink raw reply
* Re: [ANNOUNCE] GIT 1.4.3
From: Al Viro @ 2006-10-21 5:40 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vbqo6i6da.fsf@assigned-by-dhcp.cox.net>
On Fri, Oct 20, 2006 at 10:29:37PM -0700, Junio C Hamano wrote:
> Al Viro <viro@ftp.linux.org.uk> writes:
>
> > Speaking of irritations... There is a major (and AFAICS fixable)
> > suckitude in git-cherry. Basically, what it does is...
>
> Yeah, that sucks big time. I never realized there are people
> who still are using it, though. git-format-patch used to use it,
> but the version was retired exactly five months ago, and there
> is no in-tree users anymore.
Huh? If you have a saner way to do reordering/changeset-by-changeset
rebasing of branches... git-cherry followed by selective cherry-pick
works and is much more convenient than messing with implementing what
I need via git-am and shitloads of editing...
^ 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