* [PATCH] add freebsd support in Makefile
From: Alecs King @ 2006-01-26 18:04 UTC (permalink / raw)
To: git
fbsd needs iconv and third party lib/headers are inside /usr/local
Signed-off-by: Alecs King <alecsk@gmail.com>
e3b0db75ae3521b979a0b7ab115abdfab24b3111
diff --git a/Makefile b/Makefile
index 2e95353..6910448 100644
--- a/Makefile
+++ b/Makefile
@@ -251,6 +251,11 @@ ifeq ($(uname_O),Cygwin)
NO_IPV6 = YesPlease
X = .exe
endif
+ifeq ($(uname_S),FreeBSD)
+ NEEDS_LIBICONV = YesPlease
+ ALL_CFLAGS += -I/usr/local/include
+ ALL_LDFLAGS += -L/usr/local/lib
+endif
ifeq ($(uname_S),OpenBSD)
NO_STRCASESTR = YesPlease
NEEDS_LIBICONV = YesPlease
--
Alecs King
^ permalink raw reply related
* Re: How to create and keep up to date a naked/bare repository?
From: Mathieu Chouquet-Stringer @ 2006-01-26 18:27 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v64o7fac1.fsf@assigned-by-dhcp.cox.net>
junkio@cox.net (Junio C Hamano) writes:
> It sounds like you are not telling fetch to update the refs you
> track from outside. Perhaps, this may help (untested):
>
> $ GIT_DIR=/pub/scm/git/git.git git fetch \
> --update-head-ok $remote master:master
I guess I'm a little bit confused here as I'm not quite sure what I'm
trying to accomplish...
Here's what I ran:
% GIT_DIR=. git fetch \
--update-head-ok git://www.kernel.org/pub/scm/git/git master:master
Isn't git supposed to fetch master:origin as my remotes/origin file
contains (I actually tried both and refs/heads/origin and refs/heads/master
have the same value):
URL: git://www.kernel.org/pub/scm/git/git.git
Pull: master:origin
Pull: todo:todo
Pull: html:html
Pull: maint:maint
Pull: man:man
Pull: pu:pu
So it knows about the repository and the ref spec so all I need would be
the --update-head-ok flag then, no?
--
Mathieu Chouquet-Stringer
"Le disparu, si l'on vénère sa mémoire, est plus présent et
plus puissant que le vivant".
-- Antoine de Saint-Exupéry, Citadelle --
^ permalink raw reply
* Funny accidents with two servers
From: Johannes Schindelin @ 2006-01-26 23:45 UTC (permalink / raw)
To: git
Hi,
I usually pull master, todo and pu from git.kernel.org. Evidently, one of
the two servers behind that address lags behind a lot. So, half of the
time I get the message "* refs/heads/junio: does not fast forward to
branch 'master' of junio;".
The real fun starts when I do it again, and the other server is picked. No
matter what, I get all objects of "pu" which are not in "master", since
the versions of "pu" on the two servers do not fast forward to the other,
respectively.
If I would not happen to know which server has the up-to-date version of
"master", I could not tell if the version of "pu" is up-to-date or not,
since "pu" is rebased every so often, and therefore one the ref is
updated, even if it is an older version of pu.
So, I played a bit with "pu" only to find out after quite a while, that it
was not the current version after all.
Hthop,
Dscho
^ permalink raw reply
* Re: How to create and keep up to date a naked/bare repository?
From: Junio C Hamano @ 2006-01-27 3:36 UTC (permalink / raw)
To: Mathieu Chouquet-Stringer; +Cc: git
In-Reply-To: <m34q3q9759.fsf@localhost.localdomain>
Mathieu Chouquet-Stringer <ml2news@free.fr> writes:
> junkio@cox.net (Junio C Hamano) writes:
>> It sounds like you are not telling fetch to update the refs you
>> track from outside. Perhaps, this may help (untested):
>>
>> $ GIT_DIR=/pub/scm/git/git.git git fetch \
>> --update-head-ok $remote master:master
>
> I guess I'm a little bit confused here as I'm not quite sure what I'm
> trying to accomplish...
>
> Here's what I ran:
> % GIT_DIR=. git fetch \
> --update-head-ok git://www.kernel.org/pub/scm/git/git master:master
>
> Isn't git supposed to fetch master:origin as my remotes/origin file
> contains (I actually tried both and refs/heads/origin and refs/heads/master
> have the same value):
>
> URL: git://www.kernel.org/pub/scm/git/git.git
> Pull: master:origin
> Pull: todo:todo
> Pull: html:html
> Pull: maint:maint
> Pull: man:man
> Pull: pu:pu
>
> So it knows about the repository and the ref spec so all I need would be
> the --update-head-ok flag then, no?
True.
The latest git-clone.sh stopped creating both refs/heads/origin
and remotes/origin. The former was to prevent common mistake
when using it as a shared repository, but removal of the latter
might have been a mistake. I dunno.
Let's step back a bit and think about the modes of usage for a
bare cloned repository.
- A central distribution point for a (sub)project.
This is the original mode of operation bare repositories were
to be used. Think of bare repositories on kernel.org public
machines. Subsystem maintainers never work in them; the
maintainers push into them from their private development
trees. Most importantly, fetching into them is not usually
done. Fetching from upstream or sibling is done first into
maintainers' private development trees, and then either
vanilla upstream tip and/or merge result with it are pushed
into this bare repository.
- A shared repository, CVS style.
This is a natural extension of the above, but instead of
having one person (the owner of the central distribution
point for the subproject, aka subsystem maintainer), members
of a group push into it. Other aspects of the repository are
not different from the above. For example, if the project
has an upstream, the changes from the upstream is fetched by
people into their own development tree, merged appropriately
and pushed back to the shared repository.
- A mirror of somebody else's work.
I suspect this is what you are doing. Instead of individual
developers pulling directly from upstream, you would want to
fetch and update the bare cloned repository and have your
developers fetch from it.
The first two forms are equivalent. The first one is a special
case of having only one user of the shared repository. The
mirror usage can be combined with the shared repository style.
Let's outline how.
What I would suggest is to arrange things like this:
+-------------------------------------------+
| Your upstream repository |
| git://git.kernel.org/pub/scm/git/git.git/ |
+-------------------------------------------+
| ^
| (1) | (5)
| |
v |
+-----------------+ +----------------+
| Your central | (4) | My development |
| bare repository |-------------------->| tree |
+-----------------+ +----------------+
| ^
| (2) | (3)
| |
v |
+------------------+
| Your developers' |+
| trees ||+
+------------------+||
+-----------------+|
+-----------------+
(1) is initially done with "clone --bare". You have already
done this. To let your developers fetch the upstream
without directly going to kernel.org/, you would need a
mirror, which means you would want to keep all branches from
the upstream that your developers might be interested in.
So I would suggest to have something like this in this
repository:
$ cat remotes/origin
URL: git://git.kernel.org/pub/scm/git/git.git/
Pull: master:mirror
Pull: maint:maint
Pull: +pu:pu
Pull: todo:todo
Pull: html:html
Pull: man:man
$ mv refs/heads/origin refs/heads/mirror
You may not particularly interested in the last three, in
which case you can safely omit them. Also note that I
renamed "origin" to "mirror" here.
I imagine that your developers would be making updates to
git, and wish to share the changes with outside world (the
repository is not strict a mirror in that sense), so you
would need your own branch or two. Your "master" branch is
used for that.
Periodically, you could mirror me with:
$ GIT_DIR=. git fetch
Which would update the branch heads listed on the RHS of
Pull: lines above. Note that the branch HEAD points at is
refs/heads/master and is not listed on the RHS of Pull:
lines, so --update-ok is not needed. My "master" will be
mirrored as "mirror" in this repository.
(2) is created by "git clone" from your "central bare repository", and
maintained by subsequent "git pull". I am not offhand certain
what remotes/origin file they would get by default, but I would
recommend having something like this in their trees:
$ cat .git/remotes/origin
URL: git://your.host/your/git.git
Push: master:master
Pull: master:public
Pull: mirror:mirror
Pull: +pu:pu
Again, you may not particularly interested in all my branches, so
I've omitted most from the above. Your developers should never
touch branches that are used to keep track of outside branches in
their repositories (they are "public", "mirror" and "pu" in the
above example). Have them work on their "master" branch.
$ git pull
would fetch from the "master" of your central bare repository and
keep track of it as the "public" branch [*1*][*2], and merge the
result of other developers in your group into the "master" branch.
If you would want to see how well your work works with the latest
upstream:
$ git branch -f test mirror
$ git checkout test
$ git pull . master
would create a "test" branch based on my tip of "master", and
merge your development histories into it. Substitute "mirror"
with "pu" if you want to see how well your development works with
the tip of "pu" branch.
(3) Your developers will make commits to their own "master" branch,
and when things are ready, push the branch back:
$ git push origin
which would attempt to update "master" in your central bare
repository with developer's "master". This will fail if the
developer is not up to date --- in which case another git
pull and a merge would be needed to incorporate other developer's
changes.
(4) If you got fixes and enhancements for public consumption,
drop me a "please pull from here" note. I'll pull your
changes into my development tree [*3*].
(5) And I would push them out to the public repository. The
next fetch from me by your central bare repository and then
your developer's pull from it would complete the full
circle.
Does this make sense now?
[Footnotes]
*1* The "public" branch represents what other developers in your
group have done.
*2* At the same time, it would fetch "mirror", which is my
"master", and keep track of it as the "mirror" branch head,
and "pu", which is also my "pu", and stores it as "pu".
So if you are interested in what I've done in the past
couple of days, you could:
$ git whatchanged --since=3.days pu ;# everything
$ git whatchanged --since=3.days mirror ;# my "master"
*3* This is one reason I did not recommend frequent merging from
"mirror" to "master" in workflow (2). If you do not expect me to
pull from you, merging "mirror" into "master" to update the
development base might be easier to handle for your developers.
^ permalink raw reply
* Re: What is "-u" supposed to mean in git-fetch?
From: Junio C Hamano @ 2006-01-27 3:37 UTC (permalink / raw)
To: Johannes Schindelin, torvalds; +Cc: git
In-Reply-To: <7voe1zfbsm.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> writes:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>...
>> Also, in the course of researching this, I tried
>>
>> git-whatchanged git-fetch-script
>
> As in Linus' message, "git whatchanged -- git-fetch-script" is
> supposed to be the kosher way now, but it does *not* work.
Here is an attempt to fix it.
It is not perfect. As I said in a different message, the option
parsing by rev-parse in whatchanged might have outlived its
usefulness, especially after rev-list acquired path limit
arguments. If you see what 'sh -x git-whatchanged' does, you
will notice that the path limiter is not given to rev-list, but
is given to diff-tree.
-- >8 --
[PATCH] rev-parse: make "whatchanged -- git-fetch-script" work again.
The latest update to avoid misspelled revs interfered when we
were not interested in parsing non flags or arguments not meant
for rev-list. This makes these two forms work again:
git whatchanged -- git-fetch-script
We could enable "!def" in the part this change touches to make
the above work without '--', but then it would cause misspelled
v2.6.14..v2.6.16 to be given to diff-tree and defeats the whole
point of the previous fix.
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
rev-parse.c | 4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
f63fb6067037890d4928e35f7839f2a133a08d80
diff --git a/rev-parse.c b/rev-parse.c
index 7abad35..9567b0f 100644
--- a/rev-parse.c
+++ b/rev-parse.c
@@ -294,7 +294,9 @@ int main(int argc, char **argv)
}
if (verify)
die("Needed a single revision");
- if (lstat(arg, &st) < 0)
+ if ((filter & DO_REVS) &&
+ (filter & DO_NONFLAGS) && /* !def && */
+ lstat(arg, &st) < 0)
die("'%s': %s", arg, strerror(errno));
as_is = 1;
show_file(arg);
--
1.1.4.g2cff
^ permalink raw reply related
* git rev-list
From: Aneesh Kumar @ 2006-01-27 3:46 UTC (permalink / raw)
To: junkio, git
I am right now making a gnome based git repository browser [1] . I use
git-rev-list to get the revision list. What i found is that from the
second commit on wards i am finding some control character at the
beginning of the first line with respect to each commit. You can
reproduce it easily by redirecting the output to a file and reading
the file using vi. I am using the latest git built from git repository
[1] http://www.flickr.com/photos/17388011@N00/91636482/
This is based on bzrk GUI frontend to bazaar and written in python
-aneesh
^ permalink raw reply
* [PATCH] Treat "stg --help cmd" and "stg help cmd" like "stg cmd --help"
From: Pavel Roskin @ 2006-01-27 5:17 UTC (permalink / raw)
To: git, Catalin Marinas
User's intention is perfectly clear if "-h", "--help" or "help" is
followed by a valid command - show help for that command.
Signed-off-by: Pavel Roskin <proski@gnu.org>
---
stgit/main.py | 8 ++++++--
1 files changed, 6 insertions(+), 2 deletions(-)
diff --git a/stgit/main.py b/stgit/main.py
index 2336a43..6d86ee4 100644
--- a/stgit/main.py
+++ b/stgit/main.py
@@ -125,8 +125,12 @@ def main():
cmd = sys.argv[1]
if cmd in ['-h', '--help', 'help']:
- print_help()
- sys.exit(0)
+ if len(sys.argv) == 3 and sys.argv[2] in commands:
+ cmd = sys.argv[2]
+ sys.argv[2] = '--help';
+ else:
+ print_help()
+ sys.exit(0)
if cmd in ['-v', '--version', 'version']:
print 'Stacked GIT %s' % version
os.system('git --version')
--
Regards,
Pavel Roskin
^ permalink raw reply related
* RFC: Running StGIT in subdirectories
From: Pavel Roskin @ 2006-01-27 6:33 UTC (permalink / raw)
To: Catalin Marinas, git
Hello!
This was intended as a patch, but I feel it needs to be discussed.
StGIT, as it stands now, is quite unaware of the fact that the current
directory may not match the top-level directory of the repository.
It works in most cases because git takes care of the issue, or because
StGIT is operating on repository wide objects (patches). But in some
cases, StGIT fails or produces unexpected results. My first encounter
was "stg refresh":
[proski@dv doc]$ stg refresh
Refreshing patch "docs"...error: doc/doc/Makefile: does not exist and --remove not passed
fatal: Unable to process file doc/Makefile
stg refresh: Failed git-update-index
What's worse is "stg export" creating patches that only cover changes
under the current directory. I think the patches should be complete
unless the user requests otherwise.
Fortunately, it seems that most commands are doing the right thing, and
some commands are actually useful in subdirectories (e.g. add and rm).
I think it should be possible to fix the remaining commands or (in cases
when user's expectations are unclear) to disable them in subdirectories,
at least by default.
Here's the patch for "stg refresh". It also introduces a function to
get the relative patch of the current directory.
Since the output of git-update-index uses path from the top, the path to
the current directory needs to be stripped from it. I wonder if it's a
bug in git-update-index, by the way.
I'm a Python beginner. I think there should be a way to avoid creating
a new list fsrel. Also, I only want to replace the first occurrence of
rel_path, and only if it's in the beginning of the filename. Maybe I
need regex for that? Or maybe slicing would work?
Until it's done properly, it's not a 100% correct patch, but it's
working for me.
---
[PATCH] Add support for running "stg refresh" in subdirectories.
git-diff-index uses full path from the top of the repository in all
filenames it prints. The path to the current directory needs to be
stripped.
Only files under the current directory will be refreshed.
---
stgit/git.py | 16 ++++++++++++++--
1 files changed, 14 insertions(+), 2 deletions(-)
diff --git a/stgit/git.py b/stgit/git.py
index 582e803..045866e 100644
--- a/stgit/git.py
+++ b/stgit/git.py
@@ -90,6 +90,17 @@ def get_base_dir():
else:
return _output_one_line('git-rev-parse --git-dir')
+__rel_path = None
+
+def get_rel_path():
+ """Return path of the current directory relative to the top
+ """
+ global __rel_path
+
+ if not __rel_path:
+ __rel_path = _output_one_line('git-rev-parse --show-prefix')
+ return __rel_path
+
def get_commit(id_hash):
"""Commit objects factory. Save/look-up them in the __commits
dictionary
@@ -207,8 +218,9 @@ def __tree_status(files = None, tree_id
# the rest
for line in _output_lines(['git-diff-index', tree_id] + files):
fs = tuple(line.rstrip().split(' ',4)[-1].split('\t',1))
- if fs[1] not in conflicts:
- cache_files.append(fs)
+ fsrel = (fs[0], fs[1].replace(get_rel_path(), ''))
+ if fsrel[1] not in conflicts:
+ cache_files.append(fsrel)
return cache_files
--
Regards,
Pavel Roskin
^ permalink raw reply related
* Re: git rev-list
From: Junio C Hamano @ 2006-01-27 7:35 UTC (permalink / raw)
To: Aneesh Kumar; +Cc: git
In-Reply-To: <cc723f590601261946h101d7000oa1990c31c5b642fc@mail.gmail.com>
Aneesh Kumar <aneesh.kumar@gmail.com> writes:
> ... I use
> git-rev-list to get the revision list. What i found is that from the
> second commit on wards i am finding some control character at the
> beginning of the first line with respect to each commit.
If you are using "git-rev-list --header" format, it uses an
ASCII NUL (0) to delimit each record. Technically, it is not
"beginning of the first line starting from the second commit",
but "at the end of each commit".
With Perl, you would read such NUL separated record by:
local $/ = "\0";
my $item = <>;
Admittedly my Python is quite rusty, and I do not offhand recall
there was no such "line separator is NUL instead of normal LF"
configuration on readable file objects. You may need to do
something ugly like this:
-- >8 --
import os
def rev_list(rev_range):
revlist = os.popen('git rev-list --header %s' % rev_range)
stash = []
while 1:
line = revlist.readline()
if line == '':
break
if line[0] == '\0':
yield ''.join(stash)
stash = []
line = line[1:]
if line == '':
break
stash.append(line)
if len(stash):
yield ''.join(stash)
for commit in rev_list('master..pu'):
# Use commit which is from a single record..
print "*<*", commit, "*>*"
^ permalink raw reply
* Re: Safe way to remove .temp objects?
From: Erik Mouw @ 2006-01-27 10:14 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Andreas Ericsson, git
In-Reply-To: <7v1wyvfa8p.fsf@assigned-by-dhcp.cox.net>
On Thu, Jan 26, 2006 at 04:24:06AM -0800, Junio C Hamano wrote:
> What is being asked is not about loose objects but droppings
> commit walkers make when interrupted.
That's indeed what I meant.
> I think *.temp files are garbage and you can safely remove
> them. They are not even correct objects.
It looks like it was safe to remove, all git commands I tried just
work.
Thanks,
Erik
--
+-- Erik Mouw -- www.harddisk-recovery.com -- +31 70 370 12 90 --
| Lab address: Delftechpark 26, 2628 XH, Delft, The Netherlands
^ permalink raw reply
* Refs naming after clone (was: Re: How to create and keep up to date a naked/bare repository?)
From: Josef Weidendorfer @ 2006-01-27 10:30 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vd5ie735a.fsf@assigned-by-dhcp.cox.net>
Hi,
On Friday 27 January 2006 04:36, Junio wrote:
> The latest git-clone.sh stopped creating both refs/heads/origin
> and remotes/origin. The former was to prevent common mistake
> when using it as a shared repository, but removal of the latter
> might have been a mistake. I dunno.
IMHO it is convenient if git-clone remembers the origin repository
in any case.
> Let's step back a bit and think about the modes of usage for a
> bare cloned repository.
It would be nice to have a default which is working nice in all cases
(not only bare ones as discussed here).
IMHO the main problem with the current default (creating master and origin
heads after cloning) is that two namespaces are mixed up:
(1) local (possible development) heads
(2) and heads tracking remote heads
Any compatibility issues aside, wouldn't it be better to have another
namespace for (2), similar to the proposed ref namespaces for subprojects,
like refs/remote/<remote-shortcut>/heads/<remote-head> ?
Clone would create a head refs/remote/origin/heads/master to track the
master of the origin remote repo.
In the case of a the mirror discussed here, you would default to
quite cumbersome long head names:
Tracking master of git://git.kernel.org/pub/scm/git/git.git in
the central mirroring repository would be done on "remote/origin/heads/master",
and tracking this mirror head in developer repos would give a head
name "remote/origin/remote/origin/heads/master".
Still, I think this is nice because everybody can see that above head
is tracking a remote head which is tracking itself another remote
head. gitk could give remote tracking heads another color.
Note that I talk only about the default setup, which of course can be
changed by changing .git/remotes/origin.
Eg. in the mirror case, you probably want local and remote namespace
being the same, ie. .git/refs/heads/* -> .git/refs/remote/origin/heads/*
Perhaps a command to rename head names, which automatically updates
pull/push lines of .git/remotes/ accordingly would be nice here.
Also a command to rename remote shortcuts (e.g. origin to gitmain),
renaming above proposed head names accordingly would be nice.
Josef
^ permalink raw reply
* Re: How to create and keep up to date a naked/bare repository?
From: Mathieu Chouquet-Stringer @ 2006-01-27 13:34 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vd5ie735a.fsf@assigned-by-dhcp.cox.net>
Thanks and sorry for making you write this long message...
junkio@cox.net (Junio C Hamano) writes:
> [...]
> - A mirror of somebody else's work.
>
> I suspect this is what you are doing. Instead of individual
> developers pulling directly from upstream, you would want to
> fetch and update the bare cloned repository and have your
> developers fetch from it.
Correct.
> Let's outline how.
>
> What I would suggest is to arrange things like this:
>
> +-------------------------------------------+
> | Your upstream repository |
> | git://git.kernel.org/pub/scm/git/git.git/ |
> +-------------------------------------------+
> | ^
> | (1) | (5)
> | |
> v |
> +-----------------+ +----------------+
> | Your central | (4) | My development |
> | bare repository |-------------------->| tree |
> +-----------------+ +----------------+
> | ^
> | (2) | (3)
> | |
> v |
> +------------------+
> | Your developers' |+
> | trees ||+
> +------------------+||
> +-----------------+|
> +-----------------+
> [...]
> Does this make sense now?
It totally does. I guess this email could end up in the Documentation
folder in some way!?
--
Mathieu Chouquet-Stringer
"Le disparu, si l'on vénère sa mémoire, est plus présent et
plus puissant que le vivant".
-- Antoine de Saint-Exupéry, Citadelle --
^ permalink raw reply
* Two newbie question: "dead" branches and merging after cherry-pick.
From: Romano Giannetti @ 2006-01-27 17:36 UTC (permalink / raw)
To: git
Hi,
this is a "really-newbie-question"... git is the first SCM that I try to
use, and I am really fascinated with it. I develop my software on three
different PC and git solves all my problems of keeping uptodate with
myself in a really nice way.
I have a couple of doubts that probably are at the very silly level but...
Here I go:
- I use to work on a topic branch to make test, try solutions for
bugs, etc. Say I am done with the branch "test-bill-idea". I decide
it's a dead branch, so that I do not want to see it in day-by-day
work (git branch, basically), but I do not want to loose it. If I
delete the branch I will loose all its commit at the next prune,
correct? There is a way to maintain it as a dead or hidden branch,
shown for example just by gitk --all? If I tag the tip of the
branch, and then delete .git/refs/head/test-bill-idea, will the
"dead branch commits" be preserved by next prune(s)?
- Easier: suppose I cheery-picked "abababab" from branch "testing"
to master branch. What will happen if later I decide to merge
all "testing" to master branch? I will have a merge conflict (trying
to apply two times the same fix) or not?
Thank you very much for your time! Have a nice week end,
Romano
--
Romano Giannetti - Univ. Pontificia Comillas (Madrid, Spain)
Electronic Engineer - phone +34 915 422 800 ext 2416 fax +34 915 596 569
http://www.dea.icai.upcomillas.es/romano/
^ permalink raw reply
* Re: How to create and keep up to date a naked/bare repository?
From: Junio C Hamano @ 2006-01-27 18:41 UTC (permalink / raw)
To: Mathieu Chouquet-Stringer; +Cc: git
In-Reply-To: <m34q3p7q1n.fsf@localhost.localdomain>
Mathieu Chouquet-Stringer <ml2news@free.fr> writes:
> Thanks and sorry for making you write this long message...
Hey, I do not mind "I appreciate", but don't be sorry. I
actually enjoyed drawing the ASCII art.
>...
> It totally does. I guess this email could end up in the Documentation
> folder in some way!?
Maybe somebody so inclined could copyedit it, find an
appropriate place for it somewhere in the tutorial.txt or
core-tutorial.txt and feed that back to me in a patch form.
Hint, hint,... ;-).
^ permalink raw reply
* Re: How to create and keep up to date a naked/bare repository?
From: J. Bruce Fields @ 2006-01-27 19:01 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Mathieu Chouquet-Stringer, git
In-Reply-To: <7v3bj9344w.fsf@assigned-by-dhcp.cox.net>
On Fri, Jan 27, 2006 at 10:41:19AM -0800, Junio C Hamano wrote:
> Mathieu Chouquet-Stringer <ml2news@free.fr> writes:
>
> > Thanks and sorry for making you write this long message...
>
> Hey, I do not mind "I appreciate", but don't be sorry. I
> actually enjoyed drawing the ASCII art.
>
> >...
> > It totally does. I guess this email could end up in the Documentation
> > folder in some way!?
>
> Maybe somebody so inclined could copyedit it, find an
> appropriate place for it somewhere in the tutorial.txt or
> core-tutorial.txt and feed that back to me in a patch form.
> Hint, hint,... ;-).
It might make sense just to dump it in Documentation/howto/ for now.
--b.
^ permalink raw reply
* Re: Two newbie question: "dead" branches and merging after cherry-pick.
From: Alex Riesen @ 2006-01-27 19:47 UTC (permalink / raw)
To: Romano Giannetti; +Cc: git
In-Reply-To: <20060127173619.GA26199@pern.dea.icai.upcomillas.es>
Romano Giannetti, Fri, Jan 27, 2006 18:36:19 +0100:
> - I use to work on a topic branch to make test, try solutions for
> bugs, etc. Say I am done with the branch "test-bill-idea". I decide
> it's a dead branch, so that I do not want to see it in day-by-day
> work (git branch, basically), but I do not want to loose it. If I
> delete the branch I will loose all its commit at the next prune,
> correct? There is a way to maintain it as a dead or hidden branch,
> shown for example just by gitk --all? If I tag the tip of the
> branch, and then delete .git/refs/head/test-bill-idea, will the
> "dead branch commits" be preserved by next prune(s)?
Yes, it will.
You can actually move the reference file anywhere under .git/refs/,
and "git prune" will never touch it and gitk will show it different
color (looks grey to me). The tags are shown yellow, which can be
associated with "dead for some time" already.
> - Easier: suppose I cheery-picked "abababab" from branch "testing"
> to master branch. What will happen if later I decide to merge
> all "testing" to master branch? I will have a merge conflict (trying
> to apply two times the same fix) or not?
Yes, you probably will have to deal with a conflict (it can match the
branch to be merged exactly, which is hardly a conflict).
^ permalink raw reply
* Re: Two newbie question: "dead" branches and merging after cherry-pick.
From: Junio C Hamano @ 2006-01-27 20:59 UTC (permalink / raw)
To: Romano Giannetti; +Cc: git
In-Reply-To: <20060127173619.GA26199@pern.dea.icai.upcomillas.es>
Romano Giannetti <romano@dea.icai.upcomillas.es> writes:
> - I use to work on a topic branch to make test, try solutions for
> bugs, etc. Say I am done with the branch "test-bill-idea". I decide
> it's a dead branch, so that I do not want to see it in day-by-day
> work (git branch, basically), but I do not want to loose it. ...
First let me make sure if I understand you correctly.
You are done with what you did in the branch for now, but you
have not merged the work to your day-to-day development "master"
for some reason. In the meantime you would want to switch to
other topic branches to work on other topics, and while working
on them you do not want to "git branch" and "git show-branch" to
show the topic you are done with but not merged yet. Later you
would want to come back to it to do some interesting stuff with
it (maybe finally merge into "master", or format-patch to send
upstream). Is that what is happening here?
If so, I would have chosen "postponed" not "dead" to describe
the situation but you said "dead" and that is why I am wondering
if I am getting you correctly.
> ... If I
> delete the branch I will loose all its commit at the next prune,
> correct? ...
Yes. If you do not have anything under .git/refs pointing at
the tip of a development trail, that trail will be lost by the
next prune. Even if you do not prune, it would be cumbersome to
find it. "git lost-found" would find it for you but it still is
cumbersome.
> ... There is a way to maintain it as a dead or hidden branch,
> shown for example just by gitk --all? If I tag the tip of the
> branch, and then delete .git/refs/head/test-bill-idea, will the
> "dead branch commits" be preserved by next prune(s)?
Yes. You have the tag under .git/refs which points at the tip
of that postponed branch head, so the development trail will not
be lost. When you are done with other topics and would want to
come back to that topic again, you could do this:
$ git checkout -b test-bill-idea tag-bill-idea-postponed
Until recently I used to have "jc/link" topic branch to play
with "gitlink"-style subproject support suggested by Linus. It
is not finished yet, and in the meantime I have suggested
another way to do subproject support, which I've been spending
more time on, in "jc/bind" topic branch. I have not abandoned
"jc/link" topic completely, so I am not ready to do throw away
that branch with "git branch -D jc/link" yet, but at the same
time it clutters output from "git branch". So I did exactly
what you outlined [*1*]:
$ git tag hold/jc/gitlink jc/link ;# copy it to tags/
$ git branch -D jc/link ;# delete it from heads/
Now "git branch" would not show it, but "gitk --all" still would.
> - Easier: suppose I cheery-picked "abababab" from branch "testing"
> to master branch. What will happen if later I decide to merge
> all "testing" to master branch? I will have a merge conflict (trying
> to apply two times the same fix) or not?
This is easy to experiment so I'd suggest you to try it and tell
us what you see, like this:
$ git checkout -b test-merge-throwaway master
$ git cherry-pick abababab
$ ... play with it, maybe making a couple of commits
$ git pull . testing
I would not be surprised if this resolves cleanly. If abababab
is the only thing that touches the set of paths it touches,
other than what are in "testing" and what you did since
"testing" forked from "master", it is likely that the merge
would resolve cleanly.
Otherwise you would likely to see conflicts --- in which case
you may want to suggest if/how we can reduce it. "cherry-pick"
without -r drops a hint of which commit was picked in the commit
log so it _might_ be a good idea to teach git to optionally take
that information into account while doing the merge. I dunno.
Once you are done experimenting, you can come back to master and
delete the test-merge-throwaway branch:
$ git checkout master
$ git branch -D test-merge-throwaway
[Footnote]
*1* As my personal convention, each of my topic branches is
named with two-letter name, '/', and a short topic word, and
postponed tags have names starting with "hold/". Sticking to a
convention makes it easy for me to do things like this:
$ git show-branch --topo-order master "heads/??/*"
^ permalink raw reply
* Re: How to create and keep up to date a naked/bare repository?
From: Junio C Hamano @ 2006-01-27 21:00 UTC (permalink / raw)
To: J. Bruce Fields; +Cc: git
In-Reply-To: <20060127190157.GF23949@fieldses.org>
"J. Bruce Fields" <bfields@fieldses.org> writes:
>> Maybe somebody so inclined could copyedit it, find an
>> appropriate place for it somewhere in the tutorial.txt or
>> core-tutorial.txt and feed that back to me in a patch form.
>> Hint, hint,... ;-).
>
> It might make sense just to dump it in Documentation/howto/ for now.
Perhaps, but I forgot to say "after some discussion".
I think people on the list have better suggestion than what I
outlined, and I suspect I probably have some details wrong in
that message.
^ permalink raw reply
* Re: LCA06 Cogito/GIT workshop - (Re: git-whatchanged: exit out early on errors)
From: Linus Torvalds @ 2006-01-28 4:47 UTC (permalink / raw)
To: Martin Langhoff; +Cc: Junio C Hamano, Git Mailing List
In-Reply-To: <46a038f90601251810m1086d353ne8c7147edee4962a@mail.gmail.com>
On Thu, 26 Jan 2006, Martin Langhoff wrote:
>
> During the presentation someone mentioned errors when running
> git-cvsimport which I'm keen on hearing more about.
Martin, I talked to Keith, and apparently you fixed some cvsimport problem
they had with Cairo during dinner last night? Was that something that
could have affected other people, or was it very specific to whatever
Cairo CVS insanity? I've not seen any messages from you on it..
Linus
^ permalink raw reply
* [ANNOUNCE] GIT 1.1.5
From: Junio C Hamano @ 2006-01-28 4:48 UTC (permalink / raw)
To: git; +Cc: linux-kernel
The latest maintenance release GIT 1.1.5 is available at the
usual places:
http://www.kernel.org/pub/software/scm/git/
git-1.1.5.tar.{gz,bz2} (tarball)
RPMS/$arch/git-*-1.1.5-1.$arch.rpm (RPM)
Mark Wooding noticed that there is a bug in git-checkout-index
to overflow its internal buffer, if you construct a blob that
records an insanely long symbolic link in your index file and
try to check it out. This makes it dump core or worse.
The fix for this problem is the only change from v1.1.4. The
master branch has been updated with the same fix (so has "pu").
---
By the way, "dump core or worse" is a subtle way to say that
this is a security fix. To be victimized, you have to somehow
first get such a bogus symbolic link in your index. Merging
with somebody of dubious trustworthiness is a way to do so;
please practice safe merge ;-).
^ permalink raw reply
* [RFC] Adding specialized indexes to speed up slow operations
From: Martin Langhoff (CatalystIT) @ 2006-01-28 5:18 UTC (permalink / raw)
To: Junio C Hamano, git
The git internal storage model is optimized for some operations (those
that Linus considers common in his workflow), while some other commands
end up being rather expensive, like git-whatchanged
/some/deep/path/file.c or git-log /someother/file/deep/in/the/tree.c
For some stuff I'm working on (cvs daemon emulation) my plan is to have
a stupid && rebuildable set of indexes to speed up cvs-like annotates
and per-file cvs-like changelogs. Knowing very little about efficient
data structures, I'll probably use something uninspiring like SQLite.
But it's one of those things that perhaps belongs in the core -- not
cvs-like stuff, but utilities to build and maintain some specialized
indexes.
cheers,
martin
--
-----------------------------------------------------------------------
Martin @ Catalyst .Net .NZ Ltd, PO Box 11-053, Manners St, Wellington
WEB: http://catalyst.net.nz/ PHYS: Level 2, 150-154 Willis St
OFFICE: +64(4)916-7224 MOB: +64(21)364-017
Make things as simple as possible, but no simpler - Einstein
-----------------------------------------------------------------------
^ permalink raw reply
* Re: LCA06 Cogito/GIT workshop - (Re: git-whatchanged: exit out early on errors)
From: Martin Langhoff @ 2006-01-28 5:33 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Junio C Hamano, Git Mailing List, keithp
In-Reply-To: <Pine.LNX.4.64.0601272345540.2909@evo.osdl.org>
On 1/28/06, Linus Torvalds <torvalds@osdl.org> wrote:
> > During the presentation someone mentioned errors when running
> > git-cvsimport which I'm keen on hearing more about.
>
> Martin, I talked to Keith, and apparently you fixed some cvsimport problem
> they had with Cairo during dinner last night? Was that something that
> could have affected other people, or was it very specific to whatever
> Cairo CVS insanity? I've not seen any messages from you on it..
I've got a few small improvements to cvsimport in my laptop that I'll
push out for Junio to merge as soon as I get back to the office. I've
run "99% successful" imports of cairo and of x.org (modular and
monolithic) with all their branches and tags. It isn't literally the
20 years of commits Jim talked initially about -- cvs holds just the
last ~5 years.
The repos *are* a bit broken -- files missing (not moved, but really
missing) so some of the fixes are to make it easier to discover where
it is dying and workaround it. There are a few more things that I need
to debug in cvsimport -- there's a small delta between what I should
have and what I do have. As soon as they are 100% right I'll put them
on http://locke.catalyst.net.nz/gitweb for the X.org team to have a
look at them -- and a cronjob to keep them up to date with official
CVS.
BTW, have you still got that patch to git-merge to seed the commit msg
with conflicted files? ;-)
cheers,
m
^ permalink raw reply
* Re: LCA06 Cogito/GIT workshop - (Re: git-whatchanged: exit out early on errors)
From: Linus Torvalds @ 2006-01-28 5:53 UTC (permalink / raw)
To: Martin Langhoff; +Cc: Junio C Hamano, Git Mailing List, keithp
In-Reply-To: <46a038f90601272133o53438987ka6b97c21d0cdf921@mail.gmail.com>
On Sat, 28 Jan 2006, Martin Langhoff wrote:
>
> BTW, have you still got that patch to git-merge to seed the commit msg
> with conflicted files? ;-)
Nope. But it was something like the appended (totally untested, and
slightly improved).
The point being that we'd fill in a template that the committer will
hopefully edit to explain what he did to fix up the merge for each file
that had conflicts.
Linus
---
diff --git a/git-merge.sh b/git-merge.sh
index 0a158ef..9f828f3 100755
--- a/git-merge.sh
+++ b/git-merge.sh
@@ -301,5 +301,9 @@ then
"Automatic merge went well; stopped before committing as requested"
exit 0
else
+ echo >"$GIT_DIR/MERGE_MSG"
+ echo "Conflicts in" >"$GIT_DIR/MERGE_MSG"
+ git-ls-files --unmerged | cut -f2 | uniq |
+ sed 's/^.*/ \0:/' >"$GIT_DIR/MERGE_MSG"
die "Automatic merge failed; fix up by hand"
fi
^ permalink raw reply related
* Re: LCA06 Cogito/GIT workshop - (Re: git-whatchanged: exit out early on errors)
From: Junio C Hamano @ 2006-01-28 6:32 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Martin Langhoff, Git Mailing List, keithp
In-Reply-To: <Pine.LNX.4.64.0601280047240.2909@evo.osdl.org>
Linus Torvalds <torvalds@osdl.org> writes:
> The point being that we'd fill in a template that the committer will
> hopefully edit to explain what he did to fix up the merge for each file
> that had conflicts.
That is a sound idea from the point of view of good practice.
While on the topic of conflicting merge, I've been wondering if
it would make sense to do the "combined diff" between stage 2,
stage 3 and the working tree file, in addition to the --ours and
--theirs enhancements you added lately.
This would let you sanity check the merge you _could_ commit, in
the same format you would see later when you examine the merge
commit.
^ permalink raw reply
* No merge strategy handled the merge (git version 1.1.GIT)
From: Roberto Nibali @ 2006-01-28 10:53 UTC (permalink / raw)
To: git
Hello,
I've been hacking on some features for IPVS in the Linux kernel recently
but abandoned work for 3 weeks. Today I wanted to re-sync with Linus to
work in a more up-to-date tree and simply typed (forgot I had previously
done work in that tree)
git-pull
in my local repository tree, which resulted in following:
[...]
ff/df76b725bc7c0ce7db0b123957c21989674aaf
pack/pack-0741dd55e7c560f401c7f37120f3203ad8664bb0.idx
pack/pack-0741dd55e7c560f401c7f37120f3203ad8664bb0.pack
wrote 43124 bytes read 122278591 bytes 66461.13 bytes/sec
total size is 122060858 speedup is 1.00
* refs/heads/origin: fast forward to branch 'master' of
rsync://rsync.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6
Trying really trivial in-index merge...
fatal: Merge requires file-level merging
Nope.
Merging HEAD with 3ee68c4af3fd7228c1be63254b9f884614f9ebb2
Merging:
03f7e47c28dc1273395112c72ee198e86f2d576d Merge
rsync://rsync.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6
3ee68c4af3fd7228c1be63254b9f884614f9ebb2 [SPARC64]: Use
compat_sys_futimesat in 32-bit syscall table.
found 1 common ancestor(s):
48ea753075aa15699bd5fac26faa08431aaa697b Merge branch 'release' of
git://git.kernel.org/pub/scm/linux/kernel/git/aegl/linux-2.6
Removing arch/sh/boards/hp6xx/hp620/mach.c
Removing arch/ia64/ia32/ia32_ioctl.c
Removing drivers/net/sk98lin/skproc.c
Removing include/asm-arm/arch-epxa10db/timer00.h
Removing arch/powerpc/xmon/start_32.c
Removing arch/arm/mach-integrator/dma.c
Removing drivers/video/aty/xlinit.c
Removing arch/arm/mach-epxa10db/Makefile.boot
Removing scripts/lxdialog/lxdialog.c
Removing include/asm-mips/.gitignore
Removing arch/ppc/platforms/pmac_smp.c
Removing drivers/scsi/sym53c8xx_defs.h
Removing arch/ppc/platforms/pmac_pci.c
Removing arch/sparc64/kernel/ioctl32.c
Removing arch/powerpc/xmon/start_8xx.c
Removing arch/um/include/time_user.h
Removing include/asm-mips/riscos-syscall.h
Removing drivers/char/rio/poll.h
Removing drivers/char/rio/brates.h
Removing scripts/lxdialog/inputbox.c
Removing drivers/char/rio/eisa.h
Removing arch/ppc/boot/openfirmware/coffmain.c
Removing drivers/char/rio/proto.h
Removing drivers/char/rio/riowinif.h
Removing drivers/char/rio/riscos.h
Removing drivers/serial/uart00.c
Removing net/ipv6/netfilter/ip6t_length.c
Removing arch/sh/kernel/cpu/irq_ipr.c
Removing arch/s390/crypto/des_z990.c
Removing scripts/lxdialog/yesno.c
Removing arch/x86_64/boot/compressed/miscsetup.h
Removing net/ipv6/netfilter/ip6t_mark.c
Removing net/ipv6/netfilter/ip6t_NFQUEUE.c
Removing include/asm-arm/arch-epxa10db/io.h
Removing drivers/char/rio/hosthw.h
Removing arch/ppc/platforms/pmac_time.c
Removing net/ipv6/netfilter/ip6t_MARK.c
Removing kernel/crash_dump.c
Removing arch/arm/mach-epxa10db/irq.c
Removing arch/ppc/platforms/pmac_low_i2c.c
Removing drivers/char/rio/cmd.h
Removing drivers/net/arm/ether00.c
Removing arch/mips/kernel/ioctl32.c
Removing arch/um/kernel/skas/mem_user.c
Removing drivers/i2c/busses/i2c-pmac-smu.c
Removing drivers/input/mouse/maplemouse.c
Removing drivers/char/rio/rtahw.h
Removing drivers/char/rio/mca.h
Removing scripts/lxdialog/textbox.c
Auto-merging net/ipv4/ipvs/ip_vs_ctl.c
Traceback (most recent call last):
File "/home/ratz/bin/git-merge-recursive", line 915, in ?
firstBranch, secondBranch, graph)
File "/home/ratz/bin/git-merge-recursive", line 87, in merge
branch1Name, branch2Name)
File "/home/ratz/bin/git-merge-recursive", line 160, in mergeTrees
if not processEntry(entry, branch1Name, branch2Name):
File "/home/ratz/bin/git-merge-recursive", line 868, in processEntry
branch1Name, branch2Name)
File "/home/ratz/bin/git-merge-recursive", line 212, in mergeFile
src1, orig, src2], returnCode=True)
File "/home/ratz/share/git-core/python/gitMergeCommon.py", line 72,
in runProgram
raise ProgramError(progStr, e.strerror)
ProgramError: merge -L HEAD/net/ipv4/ipvs/ip_vs_ctl.c -L
orig/net/ipv4/ipvs/ip_vs_ctl.c -L
3ee68c4af3fd7228c1be63254b9f884614f9ebb2/net/ipv4/ipvs/ip_vs_ctl.c
.merge_file_uofMwv .merge_file_hcesLs .merge_file_TwtEqw: No such file
or directory
No merge strategy handled the merge.
I'm all for verbosity when it comes to a problem with software, however
this output does not tell me much about what I could do to achieve
following state:
1. Sync my local tree to Linus' tree.
2. Merge my changes I've done locally with the resulting tree of 1.
git-diff shows me 222 unmerged paths, along with my changes:
~> git-diff net/ipv4/ipvs/
* Unmerged path net/ipv4/ipvs/ip_vs_ctl.c
diff --git a/net/ipv4/ipvs/ip_vs_ctl.c b/net/ipv4/ipvs/ip_vs_ctl.c
* Unmerged path net/ipv4/ipvs/ip_vs_lblc.c
diff --git a/net/ipv4/ipvs/ip_vs_lblc.c b/net/ipv4/ipvs/ip_vs_lblc.c
* Unmerged path net/ipv4/ipvs/ip_vs_lblcr.c
diff --git a/net/ipv4/ipvs/ip_vs_lblcr.c b/net/ipv4/ipvs/ip_vs_lblcr.c
* Unmerged path net/ipv4/ipvs/ip_vs_proto_tcp.c
diff --git a/net/ipv4/ipvs/ip_vs_proto_tcp.c
b/net/ipv4/ipvs/ip_vs_proto_tcp.c
Would it be faster for me to clone the current master again and diff the
old (master, probably inconsistent) tree to master and merge the changes
by hand? Of course I can start my work again from scratch, it's only
been around 200 lines of changes so far ;).
Oh, btw, how is git branch -D supposed to work? Isn't there some code
missing?
Thanks for any insights,
Roberto Nibali, ratz
--
echo
'[q]sa[ln0=aln256%Pln256/snlbx]sb3135071790101768542287578439snlbxq' | dc
^ 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