* 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
* Re: [VOTE] git versus mercurial (for DragonflyBSD)
From: Jakub Narebski @ 2008-10-27 18:01 UTC (permalink / raw)
To: Arne Babenhauserheide; +Cc: git, mercurial, SLONIK.AZ
In-Reply-To: <200810271512.26352.arne_bab@web.de>
On Mon, 27 Oct 2008, Arne Babenhauserheide wrote:
> Am Monday 27 October 2008 13:48:38 schrieben Sie:
>>> 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?
>
> I rather think it is because I was used the Subversion UI before I tried git
> and Mercurial.
I think Mercurial UI is more compatibile with Subversion UI than Git;
additionally Mercurial uses separate, different names to avoid
ambiguities: examples are 'hg rollback' and 'hg backout' for commands
which various SCM name reset and revert, sometimes referring to one
and sometimes to the other.
AFAIK Git mostly follows BitKeeper UI; it is quite natural as it was
meant as replacement for BitKeeper for Linux kernel development.
[...]
> Also, Mercurial is Python based with quite readable code and it's very easy to
> create extensions for new uses, when I need them.
>
> If you know Python, creating a new Mercurial extension isn't harder than
> creating a shell chain command for git, but it feels much cleaner and is
> nicely integrated once it's done. You can even change the operation of basic
> commands very easily without having to touch any existing code.
There are advantages and disadvantages to each method.
Git was developed in true Unix tools style, as described in TAOUP i.e.
"The Art of UNIX Programming" by ESR (http://catb.org/esr/writings/taoup/html/)
In "Programming Pearls" by Jon Bentley there is in one of chapters
description of prototyping 'spell' using ready UNIX tools, pipelines,
and a few of custom tools, to examine the needs of 'spell'.
One of the consequences of this type of design is that there isn't
(yet?) something like git library; this is caused by the fact that
tools (plumbing) that make up git are designed to run once, and let
operating system take care of freeing resources.
On the other hand clean and clear design of git repository made it
possible to create native Git (re)implementation in Java: the JGit
project. (Well, Git is GPLv2 and JGit/Egit is BSD 3-clause/EPL, so
reimplementation might have been needed for licensing purposes anyway.
Well, it is not _full_ implementation yet...
Besides is writing plugin in Python for Mercurial that much easier
than writing new command or stuff in C for Git? Well, perhaps it is,
as only recently there began to appear API documentation, and there
were created utility mini-libraries like strbuf, or string_list,
or parseopt.
Also often third-party projects or stuff in contrib gets incorporated
into git proper; sometimes stuff is moved from git core to contrib,
if there is no maintainer however (git-svnimport, git-p4import).
Git repository has many roots: one from git core, one with gitk
(graphical history viewer), one from what was git mail tools, one
with gitweb (web interface), and one with git-gui (graphical commit
tool).
The extending via plugins idea used by Mercurial, so succesfull IMHO
for Firefox, and I think quite successfull for ikiwiki for example, is
not without drawbacks, especially that there is no plugins clearinghouse,
and plugins are required for what is considered pretty required
functionality, like bisect before hg 1.0.
See also blog post on vcscompare: "Plugins In Version Control"
http://vcscompare.blogspot.com/2008/06/plugins-in-version-cotnrol.html
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: Terminology question: "tracking" branches
From: Johannes Schindelin @ 2008-10-27 18:44 UTC (permalink / raw)
To: Marc Branchaud
Cc: Michael J Gruber, Björn Steinbrink, Peter Harris, git,
Junio C Hamano
In-Reply-To: <4905E1B0.8040601@xiplink.com>
Hi,
On Mon, 27 Oct 2008, Marc Branchaud wrote:
> Michael J Gruber wrote:
> >
> > [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?).
I agree; I do not think that you need an adjective here.
I'd also recommend thinking about the branches as "local" and "remote".
Not anything with "tracking" or "trailing" or somesuch. When you really
look at it from the non-technical view point, even the branches you have
in refs/remotes/*/ are the remote branches; the fact that you have a local
cached version of them is just a minor implementation detail.
And as to the "--track" thing? I'd not make that big a deal out of it.
At most, I'd say that a certain local branch happens to follow a certain
remote branch, but that can change over time, right? (Just change
branch.<name>.merge...)
Ciao,
Dscho
^ permalink raw reply
* problems with clone and .gitattributes
From: Leo Razoumov @ 2008-10-27 18:46 UTC (permalink / raw)
To: git
Hi Everyone,
I am using .gitattributes with clean/smudge filters to optimize
storage of OpenOffice binary files (zip compressed). So far it works
fine except for clone operation.
Apparently, "git clone" does not call smudge filter when checking out a branch.
I have to manually remove openoffice files and then do "git co -f" to
re-checkout them again, this time smudge filter gets applied.
There is a little catch-22 problem here. .gitattributes are stored
in-tree and git clone does not know about these files existence until
it checks the tree out, by that time it is already too late to apply
filters.
Of course, there could be several obvious workarounds:
(1) git clone can redo checkout when it finds files affected by gitattributes
(2) before doing checkout "git clone" inspects tree-object and looks
for .gitattributes files. If found it checks them out first before all
other files. Now it can apply the attributes found as the checkout
process progresses.
IMHO, both workarounds are somewhat clumsy.
Is there anything cleaner that can be done to solve the problem?
--Leo--
^ permalink raw reply
* Re: [RFC PATCH] detection of directory renames
From: Yann Dirson @ 2008-10-27 19:13 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <m3fxmignz3.fsf@localhost.localdomain>
On Mon, Oct 27, 2008 at 06:35:44AM -0700, Jakub Narebski wrote:
> 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...
I'm slowly bugfixing it, and plan to post a slightly updated version
soon.
^ permalink raw reply
* Re: Can't merge
From: Rémi Vanicat @ 2008-10-27 19:14 UTC (permalink / raw)
To: html-kurs; +Cc: git
In-Reply-To: <20081027165247.141110@gmx.net>
html-kurs@gmx.de writes:
> 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?
When git say "Already up-to-date" it tell you that all change introduced
in the foo branch are in master. But there could be change in master
that are not in foo, making foo and master different. You could try
> gitk foo..master
to see commit that are in master but not in foo and that could introduce
the difference between the foo and master branch.
--
Rémi Vanicat
^ permalink raw reply
* Some hooks turned on by default in FreeBSD 4
From: Robert Boone @ 2008-10-27 19:14 UTC (permalink / raw)
To: git
This was a fresh install from the git repository using the master branch
git version: 1.6.0.3.523.g304d0
Is this something that can be fixed with a recompile and different arguments?
[root@user /usr/local/cpanel.git]# git commit
fatal: exec .git/hooks/pre-commit failed.
[root@user /usr/local/cpanel.git]# ls -l .git/hooks/
total 52
-rw-r--r-- 1 root wheel 441 Oct 27 10:14 applypatch-msg
-rwxr-xr-x 1 root wheel 452 Oct 27 10:14 applypatch-msg.sample
-rw-r--r-- 1 root wheel 887 Oct 27 10:14 commit-msg
-rwxr-xr-x 1 root wheel 894 Oct 27 10:14 commit-msg.sample
-rw-r--r-- 1 root wheel 152 Oct 27 10:14 post-commit
-rwxr-xr-x 1 root wheel 160 Oct 27 10:14 post-commit.sample
-rw-r--r-- 1 root wheel 510 Oct 27 10:14 post-receive
-rwxr-xr-x 1 root wheel 553 Oct 27 10:14 post-receive.sample
-rw-r--r-- 1 root wheel 207 Oct 27 10:14 post-update
-rwxr-xr-x 1 root wheel 189 Oct 27 10:14 post-update.sample
-rw-r--r-- 1 root wheel 387 Oct 27 10:14 pre-applypatch
-rwxr-xr-x 1 root wheel 398 Oct 27 10:14 pre-applypatch.sample
-rw-r--r-- 1 root wheel 1706 Oct 27 10:14 pre-commit
-rwxr-xr-x 1 root wheel 519 Oct 27 10:14 pre-commit.sample
-rw-r--r-- 1 root wheel 4262 Oct 27 10:14 pre-rebase
-rwxr-xr-x 1 root wheel 4942 Oct 27 10:14 pre-rebase.sample
-rw-r--r-- 1 root wheel 1196 Oct 27 10:14 prepare-commit-msg
-rwxr-xr-x 1 root wheel 1219 Oct 27 10:14 prepare-commit-msg.sample
-rw-r--r-- 1 root wheel 2910 Oct 27 10:14 update
-rwxr-xr-x 1 root wheel 2892 Oct 27 10:14 update.sample
^ permalink raw reply
* Re: Some hooks turned on by default in FreeBSD 4
From: Pieter de Bie @ 2008-10-27 19:23 UTC (permalink / raw)
To: Robert Boone, Git Mailinglist
In-Reply-To: <435624390810271214s16b964cbo131772ea4a760ef7@mail.gmail.com>
On 27 okt 2008, at 20:14, Robert Boone wrote:
> [root@user /usr/local/cpanel.git]# ls -l .git/hooks/
> total 52
> -rw-r--r-- 1 root wheel 441 Oct 27 10:14 applypatch-msg
> -rwxr-xr-x 1 root wheel 452 Oct 27 10:14 applypatch-msg.sample
You probably installed the new git over an older one? The old files in
the templates weren't deleted, so now you have both the old version
without .sample and the new ones in your template folder.
^ permalink raw reply
* [PATCH 1/3] Disallow git branch -m for symrefs.
From: Miklos Vajna @ 2008-10-27 19:50 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jeff King, Brandon Casey, git
In-Reply-To: <cover.1225136865.git.vmiklos@frugalware.org>
This had two problems with symrefs. First, it copied the actual sha1
instead of the "pointer", second it failed to remove the old ref after a
successful rename.
Given that till now delete_ref() always dereferenced symrefs, a new
parameters has been introduced to delete_ref() to allow deleting refs
without a dereference.
For now, we just don't allow renaming symref as no real-word workflow
needs it and doing so would be just an accent.
Signed-off-by: Miklos Vajna <vmiklos@frugalware.org>
---
builtin-branch.c | 2 +-
builtin-receive-pack.c | 2 +-
builtin-remote.c | 4 ++--
builtin-reset.c | 2 +-
builtin-send-pack.c | 2 +-
builtin-tag.c | 2 +-
builtin-update-ref.c | 2 +-
cache.h | 2 +-
refs.c | 33 +++++++++++++++++++++++----------
t/t3200-branch.sh | 9 +++++++++
10 files changed, 41 insertions(+), 19 deletions(-)
diff --git a/builtin-branch.c b/builtin-branch.c
index 8d634ff..2b3613f 100644
--- a/builtin-branch.c
+++ b/builtin-branch.c
@@ -160,7 +160,7 @@ static int delete_branches(int argc, const char **argv, int force, int kinds)
continue;
}
- if (delete_ref(name, sha1)) {
+ if (delete_ref(name, sha1, 0)) {
error("Error deleting %sbranch '%s'", remote,
argv[i]);
ret = 1;
diff --git a/builtin-receive-pack.c b/builtin-receive-pack.c
index 45e3cd9..ab5fa1c 100644
--- a/builtin-receive-pack.c
+++ b/builtin-receive-pack.c
@@ -224,7 +224,7 @@ static const char *update(struct command *cmd)
warning ("Allowing deletion of corrupt ref.");
old_sha1 = NULL;
}
- if (delete_ref(name, old_sha1)) {
+ if (delete_ref(name, old_sha1, 0)) {
error("failed to delete %s", name);
return "failed to delete";
}
diff --git a/builtin-remote.c b/builtin-remote.c
index df2be06..e396a3a 100644
--- a/builtin-remote.c
+++ b/builtin-remote.c
@@ -337,7 +337,7 @@ static int remove_branches(struct string_list *branches)
const char *refname = item->string;
unsigned char *sha1 = item->util;
- if (delete_ref(refname, sha1))
+ if (delete_ref(refname, sha1, 0))
result |= error("Could not remove branch %s", refname);
}
return result;
@@ -565,7 +565,7 @@ static int prune(int argc, const char **argv)
const char *refname = states.stale.items[i].util;
if (!dry_run)
- result |= delete_ref(refname, NULL);
+ result |= delete_ref(refname, NULL, 0);
printf(" * [%s] %s\n", dry_run ? "would prune" : "pruned",
abbrev_ref(refname, "refs/remotes/"));
diff --git a/builtin-reset.c b/builtin-reset.c
index 16e6bb2..9514b77 100644
--- a/builtin-reset.c
+++ b/builtin-reset.c
@@ -279,7 +279,7 @@ int cmd_reset(int argc, const char **argv, const char *prefix)
update_ref(msg, "ORIG_HEAD", orig, old_orig, 0, MSG_ON_ERR);
}
else if (old_orig)
- delete_ref("ORIG_HEAD", old_orig);
+ delete_ref("ORIG_HEAD", old_orig, 0);
prepend_reflog_action("updating HEAD", msg, sizeof(msg));
update_ref_status = update_ref(msg, "HEAD", sha1, orig, 0, MSG_ON_ERR);
diff --git a/builtin-send-pack.c b/builtin-send-pack.c
index 910db92..bbf6e0a 100644
--- a/builtin-send-pack.c
+++ b/builtin-send-pack.c
@@ -234,7 +234,7 @@ static void update_tracking_ref(struct remote *remote, struct ref *ref)
if (args.verbose)
fprintf(stderr, "updating local tracking ref '%s'\n", rs.dst);
if (ref->deletion) {
- delete_ref(rs.dst, NULL);
+ delete_ref(rs.dst, NULL, 0);
} else
update_ref("update by push", rs.dst,
ref->new_sha1, NULL, 0, 0);
diff --git a/builtin-tag.c b/builtin-tag.c
index b13fa34..1ff7b37 100644
--- a/builtin-tag.c
+++ b/builtin-tag.c
@@ -125,7 +125,7 @@ static int for_each_tag_name(const char **argv, each_tag_name_fn fn)
static int delete_tag(const char *name, const char *ref,
const unsigned char *sha1)
{
- if (delete_ref(ref, sha1))
+ if (delete_ref(ref, sha1, 0))
return 1;
printf("Deleted tag '%s'\n", name);
return 0;
diff --git a/builtin-update-ref.c b/builtin-update-ref.c
index 56a0b1b..d8f3142 100644
--- a/builtin-update-ref.c
+++ b/builtin-update-ref.c
@@ -48,7 +48,7 @@ int cmd_update_ref(int argc, const char **argv, const char *prefix)
die("%s: not a valid old SHA1", oldval);
if (delete)
- return delete_ref(refname, oldval ? oldsha1 : NULL);
+ return delete_ref(refname, oldval ? oldsha1 : NULL, 0);
else
return update_ref(msg, refname, sha1, oldval ? oldsha1 : NULL,
no_deref ? REF_NODEREF : 0, DIE_ON_ERR);
diff --git a/cache.h b/cache.h
index b0edbf9..a3c77f0 100644
--- a/cache.h
+++ b/cache.h
@@ -434,7 +434,7 @@ extern int commit_locked_index(struct lock_file *);
extern void set_alternate_index_output(const char *);
extern int close_lock_file(struct lock_file *);
extern void rollback_lock_file(struct lock_file *);
-extern int delete_ref(const char *, const unsigned char *sha1);
+extern int delete_ref(const char *, const unsigned char *sha1, int delopt);
/* Environment bits from configuration mechanism */
extern int trust_executable_bit;
diff --git a/refs.c b/refs.c
index 0a126fa..31a2057 100644
--- a/refs.c
+++ b/refs.c
@@ -921,25 +921,33 @@ static int repack_without_ref(const char *refname)
return commit_lock_file(&packlock);
}
-int delete_ref(const char *refname, const unsigned char *sha1)
+int delete_ref(const char *refname, const unsigned char *sha1, int delopt)
{
struct ref_lock *lock;
- int err, i, ret = 0, flag = 0;
+ int err, i = 0, ret = 0, flag = 0;
lock = lock_ref_sha1_basic(refname, sha1, 0, &flag);
if (!lock)
return 1;
if (!(flag & REF_ISPACKED)) {
/* loose */
- i = strlen(lock->lk->filename) - 5; /* .lock */
- lock->lk->filename[i] = 0;
- err = unlink(lock->lk->filename);
+ const char *path;
+
+ if (!(delopt & REF_NODEREF)) {
+ i = strlen(lock->lk->filename) - 5; /* .lock */
+ lock->lk->filename[i] = 0;
+ path = lock->lk->filename;
+ } else {
+ path = git_path(refname);
+ }
+ err = unlink(path);
if (err && errno != ENOENT) {
ret = 1;
error("unlink(%s) failed: %s",
- lock->lk->filename, strerror(errno));
+ path, strerror(errno));
}
- lock->lk->filename[i] = '.';
+ if (!(delopt & REF_NODEREF))
+ lock->lk->filename[i] = '.';
}
/* removing the loose one could have resurrected an earlier
* packed one. Also, if it was not loose we need to repack
@@ -964,11 +972,16 @@ int rename_ref(const char *oldref, const char *newref, const char *logmsg)
struct ref_lock *lock;
struct stat loginfo;
int log = !lstat(git_path("logs/%s", oldref), &loginfo);
+ const char *symref = NULL;
if (S_ISLNK(loginfo.st_mode))
return error("reflog for %s is a symlink", oldref);
- if (!resolve_ref(oldref, orig_sha1, 1, &flag))
+ symref = resolve_ref(oldref, orig_sha1, 1, &flag);
+ if (flag & REF_ISSYMREF)
+ return error("refname %s is a symbolic ref, renaming it is not supported",
+ oldref);
+ if (!symref)
return error("refname %s not found", oldref);
if (!is_refname_available(newref, oldref, get_packed_refs(), 0))
@@ -988,12 +1001,12 @@ int rename_ref(const char *oldref, const char *newref, const char *logmsg)
return error("unable to move logfile logs/%s to tmp-renamed-log: %s",
oldref, strerror(errno));
- if (delete_ref(oldref, orig_sha1)) {
+ if (delete_ref(oldref, orig_sha1, 0)) {
error("unable to delete old %s", oldref);
goto rollback;
}
- if (resolve_ref(newref, sha1, 1, &flag) && delete_ref(newref, sha1)) {
+ if (resolve_ref(newref, sha1, 1, &flag) && delete_ref(newref, sha1, 0)) {
if (errno==EISDIR) {
if (remove_empty_directories(git_path("%s", newref))) {
error("Directory not empty: %s", newref);
diff --git a/t/t3200-branch.sh b/t/t3200-branch.sh
index 2147eac..20b6c18 100755
--- a/t/t3200-branch.sh
+++ b/t/t3200-branch.sh
@@ -112,6 +112,15 @@ test_expect_success 'config information was renamed, too' \
"test $(git config branch.s.dummy) = Hello &&
test_must_fail git config branch.s/s/dummy"
+test_expect_success 'renaming a symref should fail' \
+'
+ git symbolic-ref refs/heads/master2 refs/heads/master &&
+ test_must_fail git branch -m master2 master3 &&
+ git symbolic-ref refs/heads/master2 &&
+ test -f .git/refs/heads/master &&
+ ! test -f .git/refs/heads/master3
+'
+
test_expect_success \
'git branch -m u v should fail when the reflog for u is a symlink' '
git branch -l u &&
--
1.6.0.2
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox