* Re: [PATCH] Only update the cygwin-related configuration during state auto-setup
From: Nanako Shiraishi @ 2008-10-27 10:20 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Alex Riesen, Mark Levedahl, spearce, dpotapov, git
In-Reply-To: <7viqri35dq.fsf@gitster.siamese.dyndns.org>
Quoting Junio C Hamano <gitster@pobox.com>:
> This is the answer to the question I asked in:
>
> http://thread.gmane.org/gmane.comp.version-control.git/97986/focus=98066
>
> Perhaps we should use a separate variable as the original patch did, in:
>
> http://article.gmane.org/gmane.comp.version-control.git/97987
>
> How about doing it like this instead?
Junio, may I ask what the status of this patch is? I see you did not write tests nor commit message --- are you waiting for others to write them?
--
Nanako Shiraishi
http://ivory.ap.teacup.com/nanako3/
^ permalink raw reply
* Re: [RFC PATCH v2] fetch-pack: log(n)-transmission find_common()
From: Nanako Shiraishi @ 2008-10-27 10:29 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Thomas Rast, git
In-Reply-To: <1224790716-20551-1-git-send-email-trast@student.ethz.ch>
Quoting Thomas Rast <trast@student.ethz.ch>:
> Replaces the existing simple history search with a more sophisticated
> algorithm:
>
> 1) Walk history with exponentially increasing stride lengths; i.e.,
> send the 1st commit, then the 2nd after that, then the 4th after
> that, and so on.
>
> 2) Bisect the resulting intervals.
Junio, may I ask what the status of this patch is? I see Nicolas responded and said "I gave this a quick try". Wasn't it a good enough review?
--
Nanako Shiraishi
http://ivory.ap.teacup.com/nanako3/
^ permalink raw reply
* Re: [VOTE] git versus mercurial (for DragonflyBSD)
From: Leslie P. Polzer @ 2008-10-27 10:12 UTC (permalink / raw)
To: Jakub Narebski; +Cc: Arne Babenhauserheide, slonik.az, mercurial, git
In-Reply-To: <200810271041.54511.jnareb@gmail.com>
> I'm not sure if I should have mentioned transactions in databases here.
> Oh, well... Note however that there are advanced way of doing
> transactions in relational databases which lead to dangling things
> to be purged when transaction is interrupted.
For the record: transactions are applicable to all kinds of databases,
not only relational ones.
Leslie
^ permalink raw reply
* Re: [VOTE] git versus mercurial (for DragonflyBSD)
From: Jakub Narebski @ 2008-10-27 10:57 UTC (permalink / raw)
To: Benoit Boissinot; +Cc: Arne Babenhauserheide, SLONIK.AZ, mercurial, git
In-Reply-To: <40f323d00810270229w7dfecabcm86e5e611fb4250ef@mail.gmail.com>
Dnia poniedziałek 27. października 2008 10:29, Benoit Boissinot napisał:
> On Mon, Oct 27, 2008 at 2:52 AM, Jakub Narebski <jnareb@gmail.com> wrote:
>> On Mon, 27 Oct 2008, Arne Babenhauserheide wrote:
>>> Am Sonntag 26 Oktober 2008 19:55:09 schrieb Jakub Narebski:
>>>>
>>>> I agree, and I think it is at least partially because of Git having
>>>> cleaner design, even if you have to understand more terms at first.
>>>
>>> What do you mean by "cleaner design"?
>>
>> Clean _underlying_ design. Git has very nice underlying model of graph
>> (DAG) of commits (revisions), and branches and tags as pointers to this
>> graph.
>
> Git and Mercurial are very close from that point of view.
>
> Mercurial explicitely disallow octopus merges (and we don't think there's
> a good reason to allow them, although I agree with Linus, they look very nice
> in gitk ;) ).
From what I see Mercurial disallows octopus merges (merges with more
than two parents) because of its rigid-record database repository
design, while Git is more like object database. Fixed width records
of VMS vs delimited records of Unix... There is simply place on
zero, one or two parents (two parent fields, which can be null) in
Mercurial changerev format.
By the way flexibility of Git design allowed to add 'encoding' header
to commit message (if commits message is encoded not in utf-8) after
the fact, without affecting older repository data, and playing well
with old git installations which do not understand this header.
> And we don't have "branches as pointer" in core, but the bookmark
> extension does that.
I disagree. Mercurial implementation of tags is strange, and from
what I remember and from discussion on #revctrl implementation
of local named branches is also strange (CVS-like). They are IMHO
not well designed.
Also the 'hidden' branches after fetching from remote repository
(hg pull) but before merging (hg update) are IMHO worse design
than explicit remote-tracking branches in Git, especially in presence
of multiple [named] branches in repositories.
> Apart from that I think the underlying format are interchangeable,
> someone could use the git format with the hg ui, or use revlogs
> (the basic format of mercurial) like packs.
I don't think so. The 'content addressed filesystem' idea of Git
is quite pervasive along Git implementation and Git thoughtflows.
>
> The only special thing about revlogs is the linkrev stuff, it's a
> pointer to the first revision that introduced an object, so we can
> easily find what to send in our network protocol (we don't have to
> read the manifest, ie the "tree" of objects"). linkrev can be useful
> to speedup "hg log" too.
At first I thought: what a nice idea... but then I realized that in
distributed environment there is no way to define "first revision that
introduced an object". Take for example the following history
(independent introduction):
.---.---.---.---x---.---.---.
\
--x---.---.
where both 'x' have the same version of an object. The top branch
appeared first in current repository, but the bottom branch had 'x'
with earlier timestamp (earlier authordate).
Git just relies on the fact that traversing revision is a part of it
that is heavily optimized and really fast. Git very much by design
doesn't store any backlinks in repository object database.
>> I have read description of Mercurial's repository format, and it is not
>> very clear in my opinion. File changesets, bound using manifest, bound
>> using changerev / changelog.
>>
>
> just do a s/// with the git terminology:
> filelog -> blob
> manifest -> tree
> changelog -> commit object
True. But as I see it they are bound in reverse order in Mercurial:
deltas are stored in filelog, filelogs are bound together in manifest,
manifest are bound using changelog, while in Git commit object
references tree (and parents), trees references blobs, and blob store
content of a file. But that might be just my impression.
.......................................................................
By the way, going back to the matter of choosing version control system
for DragonflyBSD; some time ago I have written post
* "Mercurial's only true "plugin" extension: inotify...
and can it be done in Git?"
http://thread.gmane.org/gmane.comp.version-control.git/76661
(current answer: it is possible using 'assume unchanged' bit)
about how nearly every Mercurial extension has equivalent functionality
in Git.
But what about the reverse, about the following features and
issues in Mercurial:
* Merging in presence of criss-cross merges[1], and in presence of
file renames, i.e what merge-recursive does in Git.
* git-rerere, reusing recorded resolution of conflicted merges.
Resolving the same merge happens often if you use topic branches
and trial merging.
* git-grep that allows you to "and" the match criteria together,
and also pick a file (not a line) that matches all the criteria;
and of course allow searching given revision and not only working
directory.
* pickaxe search (git log -S) which contrary to blame/annotate
allow to find commit which _deleted_ given fragment.
* easy management of multiple repositories you fetch from with
remote-tracking branches and git-remote command.
* blame that follows block-of-line movement (it was invented by Linus
as a vision long time ago, but it took very long time to materialize).
* a way to review merge resolution, something that is done in git
by using combined diff format
* git-stash, allowing to stash away changes to go back to them later;
it allows to stash away even partially resolved merge conflict
(merge resolution in progress).
* git-filter-branch (based on cg-admin-rewrite-hist), which allow
to rewrite history for example to remove file which should never
be added to version control (for example because of copyright
or license).
References:
===========
[1] http://revctrl.org/CrissCrossMerge
BTW I wonder why reverting spam is made so hard on revctrl.org wiki
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: git working tree status
From: Mike Clarke @ 2008-10-27 11:37 UTC (permalink / raw)
To: git
In-Reply-To: <73f525b90810270412o234bc88by16c67df9df067649@mail.gmail.com>
On Sun, Oct 26, 2008 at 11:23 PM, Miklos Vajna <vmiklos@frugalware.org> wrote:
> On Sun, Oct 26, 2008 at 09:54:03PM +0000, Mike Clarke <clarkema@gmail.com> wrote:
>> b) all changes checked in, but there are some stashes; or
>
> git update-index -q --refresh
> test -z "$(git diff-index --name-only HEAD --)" && echo "everything committed"
>
>> c) 'dirty' in some way -- new files, uncommitted changes, etc.
>
> git update-index -q --refresh
> test -z "$(git diff-index --name-only HEAD --)" && echo "dirty"
>
> see GIT-VERSION-GEN in git.git
>
>> 1) Is there already some way of doing this that I've overlooked?
>> 2) Would the preferred approach be an option (git status --is-clean)
>> or a sub-command (git is-clean)? A sub-command would probably result
>> in cleaner internal code, but would also clutter the interface.
>
> I guess you overlooked the fact that plumbing is supposed to be used
> from scripts and porcelain by the users. git status is porcelain, so
> in general just don't use it from scripts.
>
>> 3) Is a patch for such a feature likely to be accepted?
>
> I don't think so, see above.
Thanks for the pointers! To add a bit of context to the original post, we deal
with a lot of small project repositories at work, and we swap between them
quite a lot. As a result, management of the repositories can be somewhat
burdensome; it's easy to leave a tree in the middle of something, and
then forget.
To get around this, I'm writing a Perl script, called git-map, which
a) can be used to apply a given git command (say, 'fetch') to a whole group of
repositories
b) gives you an overview of the state of all your repos. For example:
546 clarkema@swiss:~/git> git-map summary
C /home/clarkema/git/apollo
C /home/clarkema/git/cerebro
C /home/clarkema/git/dionysus
S /home/clarkema/git/dotfiles
C /home/clarkema/git/packaging/eAccelerator.git
C /home/clarkema/git/programmes/cleo-vc-doc-version-2_0
D /home/clarkema/git/programmes/cumbria-libraries/cumbria-libraries-version-1_0.git
C /home/clarkema/git/services/cleo-service-loadbalancers.git
C /home/clarkema/git/services/cleo-service-proxypac.git
C /home/clarkema/git/services/cleo-service-vc.git
C /home/clarkema/git/services/cleo-service-webgw.git
C /home/clarkema/git/software/configutils.git
C /home/clarkema/git/software/listbuilder.git
C /home/clarkema/git/software/luns-sdp
C /home/clarkema/git/software/proxy-pac.git
C /home/clarkema/git/software/sgdsync.git
D /home/clarkema/git/software/vc-billing
C /home/clarkema/git/toybox/git-contrib-import
This shows me that most of me repos are clean. 'dotfiles' has a stash
on it, and two
others have uncommitted changes. The code I'm currently using, based
on the comments
above, is:
sub cmd_summary
{
foreach my $tree ( sort @trees ) {
local $CWD = $tree;
system( "$GIT update-index -q --refresh" );
# The redirection is somewhat dirty; but is designed to eat the error
# message that occurs if there is no HEAD yet.
system( "$GIT diff-index --quiet HEAD 2> /dev/null" );
if ( $CHILD_ERROR == -1 ) {
print STDERR "Failed to execute $GIT: $OS_ERROR\n";
}
elsif ( $CHILD_ERROR & 127 ) {
printf STDERR "Child died with signal %d\n", ( $CHILD_ERROR & 127 );
}
else {
my $exit_code = $CHILD_ERROR >> 8;
print " ";
if ( $exit_code == 0 ) {
if ( have_stash() ) {
print colored ['yellow'], "S";
}
else {
print colored ['green'], "C";
}
}
elsif ( $exit_code == 1 ) {
print colored ['red'], "D";
}
else {
print colored ['red'], "?";
}
print " $tree\n";
}
}
}
sub have_stash
{
my $ref_stash = 'refs/stash';
system( "$GIT rev-parse --verify $ref_stash > /dev/null 2>&1" );
if ( $CHILD_ERROR == -1 ) {
print STDERR "Failed to execute $GIT: $OS_ERROR\n";
}
elsif ( $CHILD_ERROR & 127 ) {
printf STDERR "Child died with signal %d\n", ( $CHILD_ERROR & 127 );
}
return ( $CHILD_ERROR >> 8 ) == 0;
}
Any comments or suggestions to improve the above would be gratefully received!
Thanks,
--
Mike Clarke
^ permalink raw reply
* Re: [VOTE] git versus mercurial (for DragonflyBSD)
From: David Soria Parra @ 2008-10-27 11:42 UTC (permalink / raw)
To: Emanuele Aina; +Cc: mercurial, git
In-Reply-To: <1225100597.31813.11.camel@abelardo.lan>
Emanuele Aina schrieb:
> Jakub Narebski precisò:
>
>>> What do you mean by "cleaner design"?
>> Clean _underlying_ design. Git has very nice underlying model of graph
>> (DAG) of commits (revisions), and branches and tags as pointers to this
>> graph.
>
> Just for reference, the abstract history model of Mercurial and GIT is
> the same, a DAG of changesets identified by their cryptographic hash as
> designed for Monotone, which can be considered the parent of both.
>
> GIT and Mercurial then differs in how this abstract model is written to
> disk, with different tradeoffs in terms of performances and how easily a
> specific feature can be implemented, but there is no reason something
> can be done in GIT but not in Mercurial or viceversa.
Yes, it's the same: a DAG with hashes. But there are limitations due to
the implementation (and not the design). Just as a bad and completely
useless example (don't start to argue, I know it's nothing someone would
like to have): you cannot force mercurial to merge two revisions and
create a merge commit if one is the others ancestor,which is possible in
git with git --no-ff. In addition they differ in some other ways:
Mercurial doesn't have an index to stage commits, which is something
that git has and allows very powerful features (such as git add -i, etc).
^ permalink raw reply
* New gitk feature - show where a line came from
From: Paul Mackerras @ 2008-10-27 11:47 UTC (permalink / raw)
To: git
I have just pushed out some commits for gitk which add a feature that
I have wanted for a long time - a way to point at a line in gitk and
say "where did that come from" and have gitk show you the answer. You
can now right-click on a line in the diff/file display pane (bottom
left) and select "Show origin of this line". Gitk will run a one-line
git blame on that line, and once the answer comes back, it will select
the commit that added that line, highlight the line with a light-blue
background, and scroll so that the line is visible. This works both
when displaying diffs and when displaying files.
There are still some minor rough edges, but I'd be interested in
hearing whether it's useful to people, or if people have problems
using it.
This builds on the work done by Alexander Gavrilov, who added the
context menu for the diff/file display pane and a menu item to start
an external git gui blame on a file.
Paul.
^ permalink raw reply
* Re: [VOTE] git versus mercurial (for DragonflyBSD)
From: Jakub Narebski @ 2008-10-27 12:48 UTC (permalink / raw)
To: Arne Babenhauserheide; +Cc: mercurial, SLONIK.AZ, git
In-Reply-To: <200810271114.03406.arne_bab@web.de>
On Mon, 27 Oct 2008, Arne Babenhauserheide wrote:
> Am Montag 27 Oktober 2008 10:41:53 schrieb Jakub Narebski:
>>>
>>> If you tell a disk "give me files a, b, c, d, e, f (of the whole abc)",
>>> it is faster then if you tell it "give me files a k p q s t", because the
>>> filesystem can easier optimize that call.
>>
>> I would expect _good_ filesystem to be able to optimize this call as
>> well. As I said it looks like Mercurial and Git are optimized for
>> different cases: Git relies on filesystem for caching, and optimizes
>> for warm cache performance.
>
> The problem is by which knowledge the filesystem should optimize this call
> when it is storing the files in the first place.
Well, that is a question for filesystem designer, and VFS designer...
What I want to emphasize that perhaps Mercurial is optimized for
"streaming access", but fully packed Git repository requires only
single (well, up to details) mmap, which I think is even better.
>>> relying on crontab which might not be available in all systems (I only
>>> use GNU/Linux, but what about friends of mine who have to use Windows?)
>>
>> But that doesn't matter in the context of this discussion, which is
>> DragonflyBSD; worse or better support for MS Windows doesn't matter
>> here, does it?
>
> It only matters, if some developers are forced to work on Windows
> machines at times.
DragonFly BSD developers? I think they would work on DragonFly BSD
(eating one's own dogfood and all that...).
Sidenote: I don't know if DragonFly BSD is more like Linux kernel, or
as Linux distribution. It would be in my opinion good idea to ask
similar projects about the impressions about SCM they use (Linux kernel,
Android, ALT Linux distribution, Debian (build tools etc.), CRUX Linux
distribution, Exherbo, grml, Source Mage GNU/Linux for impressions
on their Git usage; OpenSolaris, Conary, Heretix, Linux HA, perhaps
Mozilla for impressions on their Mercurial usage;
IIRC ALSA moved from Mercurial to Git, so they could be of help there.
[...]
>> Git just uses different way to keep operations atomic, different way
>> of implementing transactions.
>> And probably requires transactions and locks for that. Git simply uses
>> atomic write solution for atomic update of references.
>
> Doesn't atomic write also need locks, though on a lower level (to ensure
> atomicity)?
No, you can use create then rename to final place trick, making use
of the fact (assumption) that renames are atomic. And Git first write
data, then write references which are used to access this data (this
relies on pruning dangling objects).
I'm not saying that git does not use locks at all, because it does,
for example to edit config file, or update branch and its reflog as
atomic operation. But it needs locking in very few places.
>> Behind the scenes, at a lower level, Git does necessary delta resolving.
>> Delta chains in packs have limited length (as they have in Mercurial).
>
> So both do snapshots - they seem more and more similar to me :)
There are differences: Mercurial from what I understand uses forward
deltas (from older to never) while Git prefers recency order; delta
chains in Git doesn't need to form single line, but can be forest of
delta chains; Git searches for good delta basis from large range of
objects (see pack.window); there is pack index which allow for random
access as if objects were in loose format (resolving deltas behind the
scenes).
I also don't know how Mercurial deals with binary files; in Git pack
format uses binary delta from LibXDiff by Davide Libenzi (File
Differential Library), heavy modified.
>> The answer usually is: did you have this repository packed? I admit
>> that it might be considered one of disadvantages of git, this having
>> to do garbage collection from time to time... just like in C ;-)
>
> I cloned from the official repositories.
>
> I hope Linus had his repository packed :)
Well, that also depends on _when_ did you try this. In older versions
of Git pack file got from network (git:// and ssh:// protocols) was
exploded into loose objects; now is kept if it is large enough, only
expanding it to make it thick, self contained pack file.
Unless you used http:// protocol, which I think kept packs as they were,
and as dumb protocol (along ftp:// and rsync://) depends on remote
repository being well packed.
>> Well, understanding "git checkout ." doesn't require understanding
>> inner workings of git. Your friend was incorrect here. I'll agree
>> though that it is a bit of quirk in UI[1] (but I use usually
>> "git reset --hard" to reset to last committed state).
>
> Damn - one more way how I could have archieved what I wanted...
> one more way I didn't find.
Well, there is a difference between "git checkout ." and
"git reset --hard", but it does not matter here.
By the way, the design of Git allowed to add lately new feature:
"git checkout --merge <file>..." to recreate conflicted merge in
specified paths. For example if you completely borked merge resolution,
and want to start from scratch.
>> Just Google for "Worse is Better". But what I actually mean that Git
>> feature set and UI has evolved from very bare-bones plumbing, adding
>> features and UI _as needed_, instead of being designed according to
>> what designer thought it was needed.
>
> And that's how it feels to me.
>
> A great testing ground, but it developed too many stumbling blocks
> which keep me from trying things.
Well, as shown in "Worse is better", evolved design wins (Lisp machines
versus Unix) :-)
> When I now use git, I only do the most basic operations: clone, pull, push,
> add, commit, checkout. When anything else arises, I check if it is worth the
> risk of having to read up for hours - and since that wasn't the case for the
> last few months, I then just ignore the problem or ask someone else if he can
> fix it.
Understanding Git "mental model" certainly helps.
[...]
> All in all it's a UI issue - while the git UI bit me quite often, the
> Mercurial UI just works.
But _that_ might be because you are used to Mercurial UI, isn't it?
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: [PATCH] Add support for uintmax_t type on FreeBSD 4.9
From: David Syzdek @ 2008-10-27 13:23 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v1vy2imt2.fsf@gitster.siamese.dyndns.org>
On Sun, Oct 26, 2008 at 10:17 PM, Junio C Hamano <gitster@pobox.com> wrote:
> "David Syzdek" <syzdek@gmail.com> writes:
>
>> On Sun, Oct 26, 2008 at 9:30 PM, Junio C Hamano <gitster@pobox.com> wrote:
>> ...
>>> I have a stupid question.
>>>
>>> Would it be a more appropriate improvement to do it like this:
>>>
>>> ifdef USE_THIS_AS_UINTMAX_T
>>> BASIC_CFLAGS += -Duintmax_t="$(USE_THIS_AS_UINTMAX_T)"
>>> endif
>>>
>>> and then add a section for FreeBSD 4.9-SECURITY like this:
>>>
>>> ifeq ($(uname_R),4.9-SECURITY)
>>> USE_THIS_AS_UINTMAX_T = uint32_t
>>> endif
>>>
>>> That way, an oddball 64-bit machine can use uint64_t here if it wants to,
>>> possibly including FreeBSD 4.9-SECURITY backported to 64-bit ;-).
>>>
>>
>> Your suggestion provides more flexibility for other environments. I
>> was making the assumption that 64-bit systems would define uintmax_t,
>> however in retrospect that would be unwise.
>> Would you like me to resubmit the patches with your modifications?
>
> Actually there was a reason why I said this was a "stupid" question. I
> think your assumption on 64-bit platforms would hold in practice, and my
> suggestion could be an unnecessary overengineering. If nobody knows of a
> system that would benefit from such a generalization, your original patch
> would be better, partly because I think:
>
> (1) USE_THIS_AS_UINTMAX_T is just for demonstration of concept and is a
> terrible name we cannot possibly use in our Makefile. We have to
> spend brain cycles to come up with a better name; and
>
> (2) It may be tricky to come up with autoconf macros to determine what to
> set USE_THIS_AS_UINTMAX_T to.
>
> As a slightly unrelated aside, I find it somewhat unfortunate that the
> conditional says "4.9-SECURITY", which is a bit too explicit and specific.
> to my taste. I do not know how FreeBSD versioning scheme works, but
> wouldn't your change work equally well for 4.9-RELEASE or 4.11-RELEASE?
>
> I suspect that you would want to say "$(uname_R) that begins with '4.' or
> smaller needs this workaround", as strtoul(3) manual page seems to appear
> first in FreeBSD 5.0-RELEASE (but not found in FreeBSD 4.11-RELEASE).
>
The following should match against FreeBSD 4.x:
FREEBSD_MAJOR := $(shell sh -c 'echo $(uname_R) |cut -d. -f1')
ifeq ($(FREEBSD_MAJOR),4)
NO_UINTMAX_T = YesPlease
NO_STRTOUMAX = YesPlease
endif
Is the use of FREEBSD_MAJOR okay, or would another name be more appropriate?
--
An earthquake wiped out Etchisketchistan today.
-- Onion TV
^ permalink raw reply
* Re: [RFC PATCH] detection of directory renames
From: Jakub Narebski @ 2008-10-27 13:35 UTC (permalink / raw)
To: Yann Dirson; +Cc: git
In-Reply-To: <20080925213819.27029.47944.stgit@gandelf.nowhere.earth>
Yann Dirson <ydirson@altern.org> writes:
> This is a first very preliminar patch, mostly so people can comment
> early on the big picture. It has a number of limitations, many but
> not all already listed as FIXME's in the patch itself. If anything in
> this patch seems so wrong it is not worth polishing it, it's the
> perfect time to say so :)
What happened to this work? I din't see it mentioned in "what's
cooking..." announcements...
--
Jakub Narebski
Poland
ShadeHawk on #git
^ permalink raw reply
* rebase, file permissions and removed file
From: Pascal Obry @ 2008-10-27 14:02 UTC (permalink / raw)
To: Git Mailing List
In short,
- a branch is created
- a file is removed from master
- the same file has its permissions changed on the branch
- we rebase the branch on master
- how to resolve the conflict?
Following is a script to reproduce the problem, see comment at the end.
Any idea? Thanks.
<<
-- #!/bin/sh
rm -fr repo
mkdir repo
cd repo
git init
touch file1 file2
chmod a+x file*
git add .
git ci -m "First rev"
git checkout -b fixperms
chmod a-x file1
git add file1
git ci -m "Fix perm file1"
git checkout master
git rm file1
git ci -m "Remove file1"
git checkout fixperms
git rebase master
# At this point there is a conflict as expected
# file1 has been removed on master, and file1 had its permissions changed
# on fixperms branch.
#
# What I find confusing is that:
# $ git diff
# and
# $ git diff --cached
#
# are reporting nothing.
#
# Ok, file1 has been removed, let's then remove it as it is right:
#
# $ git rm file1
# fatal: pathspec 'file1' did not match any files
#
# Ok, so what's the proper way to fix that! What should I do to be able to
# continue the rebase:
#
# $ git rebase --continue
>>
--
--|------------------------------------------------------
--| Pascal Obry Team-Ada Member
--| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE
--|------------------------------------------------------
--| http://www.obry.net
--| "The best way to travel is by means of imagination"
--|
--| gpg --keyserver wwwkeys.pgp.net --recv-key C1082595
^ permalink raw reply
* Re: [VOTE] git versus mercurial (for DragonflyBSD)
From: 0000 vk @ 2008-10-27 14:29 UTC (permalink / raw)
To: Jakub Narebski; +Cc: mercurial, git
In-Reply-To: <200810271157.20313.jnareb@gmail.com>
[-- Attachment #1.1: Type: text/plain, Size: 6464 bytes --]
2008/10/27 Jakub Narebski <jnareb@gmail.com>
> Dnia poniedziałek 27. października 2008 10:29, Benoit Boissinot napisał:
> > On Mon, Oct 27, 2008 at 2:52 AM, Jakub Narebski <jnareb@gmail.com>
> wrote:
> >> On Mon, 27 Oct 2008, Arne Babenhauserheide wrote:
> >>> Am Sonntag 26 Oktober 2008 19:55:09 schrieb Jakub Narebski:
> >>>>
> >>>> I agree, and I think it is at least partially because of Git having
> >>>> cleaner design, even if you have to understand more terms at first.
> >>>
> >>> What do you mean by "cleaner design"?
> >>
> >> Clean _underlying_ design. Git has very nice underlying model of graph
> >> (DAG) of commits (revisions), and branches and tags as pointers to this
> >> graph.
> >
> > Git and Mercurial are very close from that point of view.
> >
> > Mercurial explicitely disallow octopus merges (and we don't think there's
> > a good reason to allow them, although I agree with Linus, they look very
> nice
> > in gitk ;) ).
>
> From what I see Mercurial disallows octopus merges (merges with more
> than two parents) because of its rigid-record database repository
> design, while Git is more like object database. Fixed width records
> of VMS vs delimited records of Unix... There is simply place on
> zero, one or two parents (two parent fields, which can be null) in
> Mercurial changerev format.
>
> By the way flexibility of Git design allowed to add 'encoding' header
> to commit message (if commits message is encoded not in utf-8) after
> the fact, without affecting older repository data, and playing well
> with old git installations which do not understand this header.
>
> > And we don't have "branches as pointer" in core, but the bookmark
> > extension does that.
>
> I disagree. Mercurial implementation of tags is strange, and from
> what I remember and from discussion on #revctrl implementation
> of local named branches is also strange (CVS-like). They are IMHO
> not well designed.
>
> Also the 'hidden' branches after fetching from remote repository
> (hg pull) but before merging (hg update) are IMHO worse design
> than explicit remote-tracking branches in Git, especially in presence
> of multiple [named] branches in repositories.
>
> > Apart from that I think the underlying format are interchangeable,
> > someone could use the git format with the hg ui, or use revlogs
> > (the basic format of mercurial) like packs.
>
> I don't think so. The 'content addressed filesystem' idea of Git
> is quite pervasive along Git implementation and Git thoughtflows.
>
> >
> > The only special thing about revlogs is the linkrev stuff, it's a
> > pointer to the first revision that introduced an object, so we can
> > easily find what to send in our network protocol (we don't have to
> > read the manifest, ie the "tree" of objects"). linkrev can be useful
> > to speedup "hg log" too.
>
> At first I thought: what a nice idea... but then I realized that in
> distributed environment there is no way to define "first revision that
> introduced an object". Take for example the following history
> (independent introduction):
>
> .---.---.---.---x---.---.---.
> \
> --x---.---.
>
> where both 'x' have the same version of an object. The top branch
> appeared first in current repository, but the bottom branch had 'x'
> with earlier timestamp (earlier authordate).
>
>
> Git just relies on the fact that traversing revision is a part of it
> that is heavily optimized and really fast. Git very much by design
> doesn't store any backlinks in repository object database.
>
> >> I have read description of Mercurial's repository format, and it is not
> >> very clear in my opinion. File changesets, bound using manifest, bound
> >> using changerev / changelog.
> >>
> >
> > just do a s/// with the git terminology:
> > filelog -> blob
> > manifest -> tree
> > changelog -> commit object
>
> True. But as I see it they are bound in reverse order in Mercurial:
> deltas are stored in filelog, filelogs are bound together in manifest,
> manifest are bound using changelog, while in Git commit object
> references tree (and parents), trees references blobs, and blob store
> content of a file. But that might be just my impression.
>
>
> .......................................................................
>
> By the way, going back to the matter of choosing version control system
> for DragonflyBSD; some time ago I have written post
> * "Mercurial's only true "plugin" extension: inotify...
> and can it be done in Git?"
> http://thread.gmane.org/gmane.comp.version-control.git/76661
> (current answer: it is possible using 'assume unchanged' bit)
> about how nearly every Mercurial extension has equivalent functionality
> in Git.
>
> But what about the reverse, about the following features and
> issues in Mercurial:
>
> * Merging in presence of criss-cross merges[1], and in presence of
> file renames, i.e what merge-recursive does in Git.
>
> * git-rerere, reusing recorded resolution of conflicted merges.
> Resolving the same merge happens often if you use topic branches
> and trial merging.
>
> * git-grep that allows you to "and" the match criteria together,
> and also pick a file (not a line) that matches all the criteria;
> and of course allow searching given revision and not only working
> directory.
>
> * pickaxe search (git log -S) which contrary to blame/annotate
> allow to find commit which _deleted_ given fragment.
>
> * easy management of multiple repositories you fetch from with
> remote-tracking branches and git-remote command.
>
> * blame that follows block-of-line movement (it was invented by Linus
> as a vision long time ago, but it took very long time to materialize).
>
> * a way to review merge resolution, something that is done in git
> by using combined diff format
>
> * git-stash, allowing to stash away changes to go back to them later;
> it allows to stash away even partially resolved merge conflict
> (merge resolution in progress).
>
> * git-filter-branch (based on cg-admin-rewrite-hist), which allow
> to rewrite history for example to remove file which should never
> be added to version control (for example because of copyright
> or license).
>
> References:
> ===========
> [1] http://revctrl.org/CrissCrossMerge
> BTW I wonder why reverting spam is made so hard on revctrl.org wiki
>
> --
> Jakub Narebski
> Poland
>
Jakub,
Do you know if git supports the equivalent of hg bundle?
Thanks.
vk
[-- Attachment #1.2: Type: text/html, Size: 8102 bytes --]
^ permalink raw reply
* Re: rebase, file permissions and removed file
From: Johannes Sixt @ 2008-10-27 14:38 UTC (permalink / raw)
To: Pascal Obry; +Cc: Git Mailing List
In-Reply-To: <a2633edd0810270702x416bb659ke183b0cc6266071@mail.gmail.com>
Pascal Obry schrieb:
> # At this point there is a conflict as expected
> # file1 has been removed on master, and file1 had its permissions changed
> # on fixperms branch.
> #
> # What I find confusing is that:
> # $ git diff
> # and
> # $ git diff --cached
> #
> # are reporting nothing.
> #
> # Ok, file1 has been removed, let's then remove it as it is right:
> #
> # $ git rm file1
> # fatal: pathspec 'file1' did not match any files
> #
> # Ok, so what's the proper way to fix that! What should I do to be able to
> # continue the rebase:
Since you don't have any content to lose, you can always just
$ touch file1
$ git add file1
$ git rm file1
-- Hannes
^ permalink raw reply
* Re: [VOTE] git versus mercurial (for DragonflyBSD)
From: Jakub Narebski @ 2008-10-27 14:57 UTC (permalink / raw)
To: 0000 vk; +Cc: mercurial, git
In-Reply-To: <fa27bd940810270729w488edd2clbd309093062558d6@mail.gmail.com>
On Mon, 27 Oct 2008, 0000 vk wrote:
> 2008/10/27 Jakub Narebski <jnareb@gmail.com>
> > By the way, going back to the matter of choosing version control
> > system for DragonflyBSD; some time ago I have written post
> > * "Mercurial's only true "plugin" extension: inotify...
> > and can it be done in Git?"
> > http://thread.gmane.org/gmane.comp.version-control.git/76661
> > (current answer: it is possible using 'assume unchanged' bit)
> > about how nearly every Mercurial extension has equivalent functionality
> > in Git.
> >
> > But what about the reverse, about the following features and
> > issues in Mercurial:
[...]
>
> Jakub,
>
> Do you know if git supports the equivalent of hg bundle?
> Thanks.
The equivalent of "hg bundle" (http://www.selenic.com/mercurial/hg.1.html#bundle)
would be "git bundle" (http://git.or.cz/man/git-bundle). I think
git-bundle was inspired by Mercurial feature, just like fast-import
format and bisect went in other direction.
P.S. Could you _please_ quote only relevant fragments of email you are
replying to, especially if it is so long?
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: rebase, file permissions and removed file
From: Pascal Obry @ 2008-10-27 15:09 UTC (permalink / raw)
To: Johannes Sixt; +Cc: Git Mailing List
In-Reply-To: <4905D276.9020308@viscovery.net>
On Mon, Oct 27, 2008 at 3:38 PM, Johannes Sixt <j.sixt@viscovery.net> wrote:
> Since you don't have any content to lose, you can always just
>
> $ touch file1
> $ git add file1
> $ git rm file1
Does not work:
$ git rebase --continue
Applying: Fix perm file1
No changes - did you forget to use 'git add'?
When you have resolved this problem run "git rebase --continue".
If you would prefer to skip this patch, instead run "git rebase --skip".
To restore the original branch and stop rebasing run "git rebase --abort".
The only solution I found is to abort the rebase, edit my topic branch (fixperms
in this example) to remove file1 from the commit and redo the rebase... Not
that simple especially since there was many other commits on my topic branch.
--
--|------------------------------------------------------
--| Pascal Obry Team-Ada Member
--| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE
--|------------------------------------------------------
--| http://www.obry.net
--| "The best way to travel is by means of imagination"
--|
--| gpg --keyserver wwwkeys.pgp.net --recv-key C1082595
^ permalink raw reply
* Re: rebase, file permissions and removed file
From: Johannes Sixt @ 2008-10-27 15:21 UTC (permalink / raw)
To: Pascal Obry; +Cc: Git Mailing List
In-Reply-To: <a2633edd0810270809w7fec93b2rc314cc025f41d41f@mail.gmail.com>
Pascal Obry schrieb:
> On Mon, Oct 27, 2008 at 3:38 PM, Johannes Sixt <j.sixt@viscovery.net> wrote:
>> Since you don't have any content to lose, you can always just
>>
>> $ touch file1
>> $ git add file1
>> $ git rm file1
>
> Does not work:
Yes, it did! ;)
> $ git rebase --continue
> Applying: Fix perm file1
> No changes - did you forget to use 'git add'?
This is an entirely different matter. My interpretation is that the
permission change of file1 was the only change in this commit. Since this
is no longer needed, you should run 'git rebase --skip'.
-- Hannes
^ permalink raw reply
* Gitk/Cygwin bug: phony local changes
From: Hannu Koivisto @ 2008-10-27 15:22 UTC (permalink / raw)
To: git
Greetings,
git clone git://git.kernel.org/pub/scm/git/git.git
cd git
gitk
with Cygwin build of git version 1.6.0.3.523.g304d0 in Windows XP
SP2 with Cygwin dll version 1.5.24 results to gitk showing "Local
uncommitted changes, not checked in to index" entry in the history
tree and if I select that entry, it seems to indicate that all
files have changed but without any actual content changes.
git status doesn't show any changes.
If I run git diff (which displays no changes) or git reset and then
run gitk again, there is no longer that "Local uncommitted
changes..." entry.
Since it was suggested on #irc, I tried "git config --global
core.trustctime false" but that didn't help, which I suppose was
expected since the documentation talks about differences between
the index and the working copy and I haven't added anything to the
index.
I can reproduce this problem with another (private) repository as
well.
--
Hannu
^ permalink raw reply
* Re: rebase, file permissions and removed file
From: Pascal Obry @ 2008-10-27 15:33 UTC (permalink / raw)
To: Johannes Sixt; +Cc: Git Mailing List
In-Reply-To: <4905DC90.6050503@viscovery.net>
On Mon, Oct 27, 2008 at 4:21 PM, Johannes Sixt <j.sixt@viscovery.net> wrote:
> Pascal Obry schrieb:
>> On Mon, Oct 27, 2008 at 3:38 PM, Johannes Sixt <j.sixt@viscovery.net> wrote:
>>> Since you don't have any content to lose, you can always just
>>>
>>> $ touch file1
>>> $ git add file1
>>> $ git rm file1
>>
>> Does not work:
>
> Yes, it did! ;)
Well, on my side I add to use:
$ git rm --cached file1
For the last command.
> This is an entirely different matter. My interpretation is that the
> permission change of file1 was the only change in this commit. Since this
> is no longer needed, you should run 'git rebase --skip'.
No no :) Too easy! I have plenty of other permission changes in my commit
that I do not want to loose!
Pascal.
--
--|------------------------------------------------------
--| Pascal Obry Team-Ada Member
--| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE
--|------------------------------------------------------
--| http://www.obry.net
--| "The best way to travel is by means of imagination"
--|
--| gpg --keyserver wwwkeys.pgp.net --recv-key C1082595
^ permalink raw reply
* Re: Terminology question: "tracking" branches
From: Marc Branchaud @ 2008-10-27 15:43 UTC (permalink / raw)
To: Michael J Gruber; +Cc: Björn Steinbrink, Peter Harris, git, Junio C Hamano
In-Reply-To: <490030AB.8090207@drmicha.warpmail.net>
Michael J Gruber wrote:
>
> remote tracking branch: Synonymous with tracking branch. [remote is a
> noun, an object for track here]
Er, "remote" is an adjective there... :)
> [adjective to be found] branch: A local branch which is set up to pull
> or rebase automatically from a tracking branch. Used for local
> modifications to remote branches. [I'm tempted to use local tracking
> branch here, but that would just add to the confusion.]
I say there's no need for an adjective here, as this is just a plain old
branch that git-branch creates by default (right?).
What's needed is an adjective for when git-branch is given the
--no-track option (or when branch.automergesetup is false).
"Non-tracking branch" perhaps?
Marc
^ permalink raw reply
* Re: Terminology question: "tracking" branches
From: Björn Steinbrink @ 2008-10-27 16:17 UTC (permalink / raw)
To: Marc Branchaud; +Cc: Michael J Gruber, Peter Harris, git, Junio C Hamano
In-Reply-To: <4905E1B0.8040601@xiplink.com>
On 2008.10.27 11:43:44 -0400, Marc Branchaud wrote:
> Michael J Gruber wrote:
>>
>> remote tracking branch: Synonymous with tracking branch. [remote is a
>> noun, an object for track here]
>
> Er, "remote" is an adjective there... :)
Hm? It's a "branch that tracks (a branch of) a remote". Looks like a
noun to me.
>> [adjective to be found] branch: A local branch which is set up to pull
>> or rebase automatically from a tracking branch. Used for local
>> modifications to remote branches. [I'm tempted to use local tracking
>> branch here, but that would just add to the confusion.]
>
> I say there's no need for an adjective here, as this is just a plain old
> branch that git-branch creates by default (right?).
By default, no. It depends on the branch.automergesetup configuration
and whether you create the branch from a remote tracking branch, a local
branch or some other committish.
autosetupmerge = false
----
git branch foo origin/foo --> --no-track
git branch foo master --> --no-track
git branch foo origin/foo^0 --> --no-track
autosetupmerge = true
----
git branch foo origin/foo --> --track
git branch foo master --> --no-track
git branch foo origin/foo^0 --> --no-track
autosetupmerge = always
----
git branch foo origin/foo --> --track
git branch foo master --> --track
git branch foo origin/foo^0 --> --no-track
> What's needed is an adjective for when git-branch is given the
> --no-track option (or when branch.automergesetup is false).
> "Non-tracking branch" perhaps?
Isn't that easily confused with "[remote] tracking branch"? Especially
since the "remote" is optional...
Björn
^ permalink raw reply
* Re: Terminology question: "tracking" branches
From: Björn Steinbrink @ 2008-10-27 16:28 UTC (permalink / raw)
To: Michael J Gruber; +Cc: Marc Branchaud, Peter Harris, git, Junio C Hamano
In-Reply-To: <490030AB.8090207@drmicha.warpmail.net>
On 2008.10.23 10:07:07 +0200, Michael J Gruber wrote:
> That leaves open:
>
> - What does "remote branch" mean, if it means anything at all? It could
> be used for a branch in a remote repository, i.e. the other side of
> fetch/push refspec (remote branch:tracking branch).
I prefer to say "the branch on the remote" there, but that's just to
avoid confusion with "remote tracking branch".
> - How to name a local branch created with --track off of a (remote)
> tracking branch? Local tracking branch? Downstream/work/modification branch?
You can also have a local branch that "--track"s another local branch,
so those names look a bit suboptimal to me, but I don't have any better
ideas either :-/ For a second I thought about "pulling branch" but that
doesn't really describe it either, I guess...
> I think that linguistically, the confusion comes from using the noun as
> well as the adjective "remote". As an adjective: "remote something"
> cleary is something residing remotely. As a noun it's the config added
> by "git remote add".
>
> Note that the glossary doesn't define remote at all. I'd volunteer
> changing that once the discussion reaches a consensus.
>
> My suggestion would be:
>
> remote (noun): A configuration as created by "git remote add" which
> points to a remote repository (using a URL) and sets up refspecs for
> fetching and/or pulling. Note that the URL may point to a local
> filesystem or even ".". See also remote (adjective).
>
> remote (adjective): Anything residing in another repository. See also
> remote (noun).
>
> local: Sometimes used to emphasize things residing "locally", i.e. in
> the repository at hand, as opposed to "remotely".
>
> tracking branch: A branch tracking a (remote) branch on a remote
> repository, i.e. a local branch stored under refs/remotes/ which is a
> "copy" of a branch on a remote repository; typically created by "git
> clone" or "git remote add/update".
>
> remote tracking branch: Synonymous with tracking branch. [remote is a
> noun, an object for track here]
Those look good, to me at least.
> [adjective to be found] branch: A local branch which is set up to pull
> or rebase automatically from a tracking branch.
"merge or rebase", and instead of "tracking" it should be "another" I
think. Again, because you can also --track a local branch.
> Used for local modifications to remote branches. [I'm tempted to use
> local tracking branch here, but that would just add to the confusion.]
Same here, it doesn't apply to "remote branches" only.
> Come to think of it: "Off-track" branch would be the ideal name for a
> local branch created off of a (remote) tracking branch, using --track to
> specify the track where things go off. But I'm not sure everyone would
> like the implied pun...
Haha :-)
thanks,
Björn
^ permalink raw reply
* Re: rebase, file permissions and removed file
From: Samuel Tardieu @ 2008-10-27 16:39 UTC (permalink / raw)
To: Pascal Obry; +Cc: Johannes Sixt, Git Mailing List
In-Reply-To: <a2633edd0810270833q482260b4pf0ae11dcf2d4936f@mail.gmail.com>
>>>>> "Pascal" == Pascal Obry <pascal@obry.net> writes:
Pascal> I have plenty of other permission changes in my commit that I
Pascal> do not want to loose!
Why do you do a "rebase" in this case rather than a merge? Doesn't it
make little sense to record a permission change on a *deleted* file?
Sam
--
Samuel Tardieu -- sam@rfc1149.net -- http://www.rfc1149.net/
^ permalink raw reply
* Can't merge
From: html-kurs @ 2008-10-27 16:52 UTC (permalink / raw)
To: git
Hi,
I've run in trouble when trying to merge a branch:
I've got a branch "foo".
I checkout master.
> git diff foo
shows many diffs.
But
> git merge foo
says:
Already up-to-date.
I'm using version 1.6.0.2
Any idea what I'm doing wrong?
TIA,
Martin
--
Psssst! Schon vom neuen GMX MultiMessenger gehört? Der kann`s mit allen: http://www.gmx.net/de/go/multimessenger
^ permalink raw reply
* Fwd: Can't merge
From: html-kurs @ 2008-10-27 17:03 UTC (permalink / raw)
To: git
I'm sorry. for the first mail.
The changes were all made in master ...
So what I wanted was
> git checkout foo
> git merge master
Anyone got a can of perri air for me ? ;-)
-------- Original-Nachricht --------
Datum: Mon, 27 Oct 2008 17:52:47 +0100
Von: html-kurs@gmx.de
An: git@vger.kernel.org
Betreff: Can\'t merge
Hi,
I've run in trouble when trying to merge a branch:
I've got a branch "foo".
I checkout master.
> git diff foo
shows many diffs.
But
> git merge foo
says:
Already up-to-date.
I'm using version 1.6.0.2
Any idea what I'm doing wrong?
TIA,
Martin
--
Psssst! Schon vom neuen GMX MultiMessenger gehört? Der kann`s mit allen: http://www.gmx.net/de/go/multimessenger
--
"Feel free" - 10 GB Mailbox, 100 FreeSMS/Monat ...
Jetzt GMX TopMail testen: http://www.gmx.net/de/go/topmail
^ permalink raw reply
* Re: rebase, file permissions and removed file
From: Pascal Obry @ 2008-10-27 17:12 UTC (permalink / raw)
To: Samuel Tardieu; +Cc: Johannes Sixt, Git Mailing List
In-Reply-To: <2008-10-27-17-39-43+trackit+sam@rfc1149.net>
Samuel Tardieu a écrit :
> Why do you do a "rebase" in this case rather than a merge? Doesn't it
> make little sense to record a permission change on a *deleted* file?
Because this is in the context of git-svn, and I really want to rebase
my work before pushing it back to the Subversion repository.
--
--|------------------------------------------------------
--| Pascal Obry Team-Ada Member
--| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE
--|------------------------------------------------------
--| http://www.obry.net
--| "The best way to travel is by means of imagination"
--|
--| gpg --keyserver wwwkeys.pgp.net --recv-key C1082595
^ 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