* Re: Really happy with cogito for inhouse teamwork, now that I've figured out cg-clone...
From: Josef Weidendorfer @ 2005-09-29 15:15 UTC (permalink / raw)
To: Git Mailing List
In-Reply-To: <46a038f905092822587f5414d4@mail.gmail.com>
On Thursday 29 September 2005 07:58, Martin Langhoff wrote:
> Doing the checkout the 'right' way:
> $ cg-clone git+ssh://locke.catalyst.net.nz/var/git/project.git#branchname
> localdirname
>
> Work cycle:
> # work work work
> $ cg-commit
> $ cg-update
> $ cg-push
Yes, this works very well here, too.
And it works officially since cg-push allows to push on a
non-master remote head (based on git's advanced push allowing mapping of
different head names on local and remote side).
[Before, I used a hack in cg-clone: with e.g. cloning remote head "rem",
symlink local master to a local "rem". This was working quite fine, too]
The following is equally fine (smaller work per commit, with lot more commits
relative to the pushing to the central rep - gives more documentation
on the development history):
# work
$ cg-commit
# work
$ cg-commit
# work
$ cg-commit
$ cg-update
$ cg-push
Aditionally, we have in the central repository a head per developer,
to publish experimental/instable work, and they are regularly merged
back into the central master.
The key to simplicity is here, to have one clone for every remote head.
Introducing Git/Cogito to other people this way almost needs no tutorial at
all.
This is complemented by an automated mail to a project mailing list
via use of the update-hook in the central repository, so that every
developer is kept up-to-date on work of others. The mail is
formatted to include URLs for every commit to a matching
gitweb interface. Was really easy to setup and quite handy.
Josef
^ permalink raw reply
* [howto] Kernel hacker's guide to git, updated
From: Jeff Garzik @ 2005-09-29 11:03 UTC (permalink / raw)
To: Linux Kernel; +Cc: Git Mailing List
Just updated my KHGtG to include the latest goodies available in
git-core, the Linux kernel standard SCM tool:
http://linux.yyz.us/git-howto.html
Several changes in git-core have made working with git a lot easier, so
be sure to re-familiarize yourself with the development process.
Comments, corrections, and notes of omission welcome. This document
mainly reflects my typical day-to-day git activities, and may not be
very applicable outside of kernel work.
Jeff
^ permalink raw reply
* Re: [PATCH] Added an option to cvsimport to specify email domain
From: Alexey Nezhdanov @ 2005-09-29 10:26 UTC (permalink / raw)
To: git
In-Reply-To: <200509270834.55486.snake@penza-gsm.ru>
On Tuesday, 27 September 2005 08:34 Alexey Nezhdanov wrote:
Clarification: I'm currently working on patch for cvsps that will allow import
proper usernames with emails. It is already working now but have one glitch
that I'd like to remove prior to publishing.
> On September 14, 2005 23:34 Petr Baudis wrote:
> > Dear diary, on Wed, Sep 07, 2005 at 09:18:03PM CEST, I got a letter
> > where Junio C Hamano <junkio@cox.net> told me that...
> >
> > > David K?.A?Negedal <davidk@lysator.liu.se> writes:
> > > > The authorship info in commits created by git-cvsimport-script
> > > > only contains the username of the CVS committer. This patch
> > > > adds a flag -e <domain> to git-cvsimport-script that makes it
> > > > possible to specify an email domain that is added to all email
> > > > addresses in the commit "author" and "committer" fields.
> > > >
> > > > ---
> > > > I have stopped using cvsimport, because cvsps seems to produce bad
> > > > output on the repository I'm using it with, but I had already
> > > > prepared this patch.
> > >
> > > Hmph. One reason the original implementation did not do this is
> > > because Linus and other people wanted to have a repeatability,
> > > so making this an optional thing is good, but if we go this
> > > route, I think if it would be nicer to have a --author-map
> > > option that lets you feed a list of:
> > >
> > > <author> ==> "A U Thor <author@author.dom>"
> > >
> > > mappings, instead of a single -e, which essentially does not add
> > > much information to the result.
> > >
> > > I take that your oob comment indicates that you do not have much
> > > incentive/inclination to further hack on this, so I am not
> > > asking you to do the above even if you find my suggestion
> > > worthwhile.
> >
> > Various tools use CVSROOT/users to map usernames to realname <email>.
> > I actually wanted to send a patch, looked at the cvsimport script and
> > got totally scared away (at least for now)... ;-)
>
> git uses cvsps output to determine authorship. Do you think if this problem
> should be solved on cvsps side? It should be relatively easy IMHO.
> David, can you add another key to output CVSROOT/users mapping result
> instead of usernames if available?
--
Respectfully
Alexey Nezhdanov
^ permalink raw reply
* Re: [PATCH] fetch-pack should not ask for a ref which is already there
From: Johannes Schindelin @ 2005-09-29 9:30 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vhdc4grrf.fsf@assigned-by-dhcp.cox.net>
Hi,
On Thu, 29 Sep 2005, Junio C Hamano wrote:
> I suspect it would be cleaner to return (struct ref *) from
> fetch_pack (ideally use NULL to signal failure but there is no
> need -- it just dies) and print the refs from main() only after
> seeing the last close and finish_connect succeed.
Here's my next try:
[PATCH] fetch-pack should not ask for a ref which is already there
From: Johannes Schindelin <gene099@localhost>
Date: 1127950437 +0200
With this patch, instead of blindly asking for every remote ref, fetch-pack
first looks in the local repository if that ref is already there.
Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
---
fetch-pack.c | 56 ++++++++++++++++++++++++++++++++++++--------------------
1 files changed, 36 insertions(+), 20 deletions(-)
210c4c6fe4a353d59e4ca2871d7f2a3c1b9b1238
diff --git a/fetch-pack.c b/fetch-pack.c
--- a/fetch-pack.c
+++ b/fetch-pack.c
@@ -16,20 +16,27 @@ static int find_common(int fd[2], unsign
int count = 0, flushes = 0, retval;
FILE *revs;
- revs = popen("git-rev-list $(git-rev-parse --all)", "r");
- if (!revs)
- die("unable to run 'git-rev-list'");
-
while (refs) {
unsigned char *remote = refs->old_sha1;
- if (verbose)
- fprintf(stderr,
- "want %s (%s)\n", sha1_to_hex(remote),
- refs->name);
- packet_write(fd[1], "want %s\n", sha1_to_hex(remote));
+ if(!has_sha1_file(remote)) {
+ if (verbose)
+ fprintf(stderr,
+ "want %s (%s)\n", sha1_to_hex(remote),
+ refs->name);
+ packet_write(fd[1], "want %s\n", sha1_to_hex(remote));
+ count++;
+ }
refs = refs->next;
}
packet_flush(fd[1]);
+
+ if(count==0)
+ return 1;
+
+ revs = popen("git-rev-list $(git-rev-parse --all)", "r");
+ if (!revs)
+ die("unable to run 'git-rev-list'");
+
flushes = 1;
retval = -1;
while (fgets(line, sizeof(line), revs) != NULL) {
@@ -74,7 +81,7 @@ static int find_common(int fd[2], unsign
return retval;
}
-static int fetch_pack(int fd[2], int nr_match, char **match)
+static struct ref *fetch_pack(int fd[2], int nr_match, char **match)
{
struct ref *ref;
unsigned char sha1[20];
@@ -86,7 +93,10 @@ static int fetch_pack(int fd[2], int nr_
packet_flush(fd[1]);
die("no matching remote head");
}
- if (find_common(fd, sha1, ref) < 0)
+ status = find_common(fd, sha1, ref);
+ if(status > 0)
+ return ref;
+ if(status < 0)
fprintf(stderr, "warning: no common commits\n");
pid = fork();
if (pid < 0)
@@ -109,12 +119,7 @@ static int fetch_pack(int fd[2], int nr_
int code = WEXITSTATUS(status);
if (code)
die("git-unpack-objects died with error code %d", code);
- while (ref) {
- printf("%s %s\n",
- sha1_to_hex(ref->old_sha1), ref->name);
- ref = ref->next;
- }
- return 0;
+ return ref;
}
if (WIFSIGNALED(status)) {
int sig = WTERMSIG(status);
@@ -125,10 +130,11 @@ static int fetch_pack(int fd[2], int nr_
int main(int argc, char **argv)
{
- int i, ret, nr_heads;
+ int i, nr_heads;
char *dest = NULL, **heads;
int fd[2];
pid_t pid;
+ struct ref *ref;
nr_heads = 0;
heads = NULL;
@@ -160,9 +166,19 @@ int main(int argc, char **argv)
pid = git_connect(fd, dest, exec);
if (pid < 0)
return 1;
- ret = fetch_pack(fd, nr_heads, heads);
+ ref = fetch_pack(fd, nr_heads, heads);
+ if(!ref)
+ return 1;
+
+ while (ref) {
+ printf("%s %s\n",
+ sha1_to_hex(ref->old_sha1), ref->name);
+ ref = ref->next;
+ }
+
close(fd[0]);
close(fd[1]);
finish_connect(pid);
- return ret;
+
+ return 0;
}
^ permalink raw reply
* Re: [PATCH] fetch-pack should not ask for a ref which is already there
From: Junio C Hamano @ 2005-09-29 9:14 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <Pine.LNX.4.63.0509291034450.20717@wgmdd8.biozentrum.uni-wuerzburg.de>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> Yeah, sorry. I did not test that one. Maybe an automated test for
> git-fetch-pack would be useful after all...
Sounds sensible. I think git-send-pack has one.
> How about the following? (I avoided an ugly goto, but had to duplicate
> code :-( )
I suspect it would be cleaner to return (struct ref *) from
fetch_pack (ideally use NULL to signal failure but there is no
need -- it just dies) and print the refs from main() only after
seeing the last close and finish_connect succeed.
^ permalink raw reply
* Re: Use of the -f flag on checkout
From: Junio C Hamano @ 2005-09-29 9:02 UTC (permalink / raw)
To: Alan Chandler; +Cc: git
In-Reply-To: <200509290754.30017.alan@chandlerfamily.org.uk>
Alan Chandler <alan@chandlerfamily.org.uk> writes:
> I notice that Jeff is using the -f flag on checkout whereas you don't.
>
> What is the risk in not using it (ie what are the cases when you should use
> it)?
'git checkout' without '-f' means "I know my index file is
derived from my current HEAD commit. I may have recorded
changes since the HEAD commit in index and also in the working
tree. I now want to switch to the named branch head commit but
I'd like to take those local changes with me."
My examples worked in topic branches and after finishing work in
each branch (meaning, making commits to record changes to each
branch I was working on), switched to another branch. After
making a commit, the index file exactly matches the current HEAD
(i.e. "git diff HEAD" would report empty) and the working tree
exactly matches the index file (i.e. "git diff" would report
empty too), so there is no local changes to carry around.
Note that this is not always possible. If the local
modifications you have contradict with what the switched-to
branch has, 'git checkout' would complain and refuse to check
things out. But if you know your index file and the working
tree is in sync with the HEAD commit, 'git checkout' is the
preferred way to switch branches. It is somewhat more efficient,
too.
On the other hand, what 'git checkout -f' is telling git is that
"I do not want you to trust what the index file records or what
the current HEAD is. I just want to have my index matched to
the named branch head commit, and have those blobs recorded in
that commit checked out in the working tree". It is designed to
work even when you do not have a clue about the relationship
between what your index records, what your working tree files
are and what your current HEAD commit has, and can be used as
the last resort after a failed merge really messed up your
working tree and you would rather start the merge from scratch.
Switching to the current branch ('git checkout -f HEAD') makes
sense in that situation, while 'git checkout HEAD' never does.
Here is a short demonstration (my "ls" is aliased to "ls -aF").
$ git show-branch
* [master] Initial - have frotz
! [nitfol] Add nitfol
! [rezrov] Add rezrov
---
+ [rezrov] Add rezrov
+ [nitfol] Add nitfol
+++ [master] Initial - have frotz
$ ls
./ ../ .git/ frotz
The 'master' branch has one file, 'frotz'. Two branches are
derived from it, 'rezrov' and 'nitfol', each adds one file with
the same name as the branch name, without touching 'frotz'. We
are on the 'master' branch.
$ git checkout nitfol
$ git ls-files
frotz
nitfol
$ ls
./ ../ .git/ frotz nitfol
We use 'git checkout' without '-f'. It checked out 'nitfol' and
kept 'frotz'.
$ git checkout -f rezrov
$ git ls-files
frotz
rezrov
$ ls
./ ../ .git/ frotz nitfol rezrov
This time, we tried 'git checkout' with '-f'. It checked out
'rezrov' and kept 'frotz', but failed to remove 'nitfol',
because we told it to ignore the fact that we came from 'nitfol'
branch. If it were allowed to use that information, it would
have noticed that the original branch had 'nitfol' recorded but
the branch we are switching to did not have it, and would have
removed it from the working tree. Also notice that the index
file matches the 'rezrov' commit -- it does not know about
'nitfol' file anymore.
$ rm -f nitfol
$ date >xyzzy
$ git add xyzzy
Now, after removing the unwanted 'nitfol' file, let's introduce
some local changes. Remember we are still on 'rezrov' branch.
$ git checkout nitfol
$ git ls-files
frotz
nitfol
xyzzy
$ ls
./ ../ .git/ frotz nitfol xyzzy
$ git diff --name-status HEAD
A xyzzy
Now we tell 'git checkout' to switch to 'nitfol' branch, without
losing our local changes. The file 'nitfol' is back (checked
out), and 'rezrov' is gone (because this time it was allowed to
trust the current HEAD and noticed 'rezrov' was there in the
original but not in the branch we are switching to).
However, neither the working file nor the index matches the
'nitfol' branch head -- it kept the local addition of new file
'xyzzy' (i.e. your local changes were preserved).
One typical scenario I use 'git checkout' without '-f' is:
* on some branch, start working on something.
* realize that the change I am making belongs to a different
topic.
* 'git checkout' to that other topic branch, with my
changes.
* keep working and make commit on the other topic branch.
* come back (with 'git checkout') to the original branch.
But usually I am even less organized -- I'd usually end up
doing:
* on some branch, start working on something.
* realize that some the changes I am making belong to a
different topic, while other changes belong to the
curren branch.
* stash away "git diff HEAD" output. revert parts that
are not relevant to the current topic branch.
* make commit on the current topic branch.
* 'git checkout' to that other topic branch. Apply the
rest of the diff output.
* keep working and make commit on the other topic branch.
Personally I don't remember using 'git checkout -f' myself.
When I really want to sync my index file and the working tree to
the current branch head, I tend to do 'git reset --hard'
instead. Unlike 'git checkout -f HEAD', this removes the files
I added to the working tree and the index since my current HEAD
commit. One downside is that 'git reset --hard' *is* a very
expensive operation.
^ permalink raw reply
* Re: [PATCH] Fix git-pull output message
From: Robert Watson @ 2005-09-29 8:48 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git, Junio C Hamano
In-Reply-To: <Pine.LNX.4.58.0509280823260.3308@g5.osdl.org>
On 9/28/05, Linus Torvalds <torvalds@osdl.org> wrote:
>
>
> On Wed, 28 Sep 2005, Robert Watson wrote:
> >
> > Notice that the git.git directory is truncated. It seems the
> > intension is to truncate at the .git
> > directory level. The following patch fixes it.
>
> No, the intention really is to remove the ".git" at the end. At least
> that's how I use it.
>
> I like seeing my merges say
>
> Merge branch 'for-linus' from master.kernel.org:/pub/scm/linux/kernel/git/roland/infiniband
>
> even though the _real_ directory was ".../infiniband.git/", simply because
> the ".git" doesn't really add any extra information when you're already in
> git.
>
> _outside_ of git, the ".git" tells you something: it tells you that you're
> entering a git archive. But when merging in git, that part is kind of
> taken for granted, isn't it?
>
> This also matches what "git-receive-pack" and "git-upload-pack" does:
>
> ...
> /* chdir to the directory. If that fails, try appending ".git" */
> if (chdir(dir) < 0) {
> if (chdir(mkpath("%s.git", dir)) < 0)
> die("unable to cd to %s", dir);
> }
>
> /* If we have a ".git" directory, chdir to it */
> chdir(".git");
> ...
>
> Note how it _both_ will append ".git" to the directory name (if it can't
> find one without ".git" _and_ will try to chdir to a ".git" directory
> _within_ the directory name.
>
> So if you use the native pack ssh interfaces, you really can say
>
> git pull master.kernel.org:.../infiniband
>
> because the tools (well, the "native pack" ones - not the http/rsync/scp
> ones) will automatically DTRT.
>
> Linus
>
Now, I understand it. Thanks Linus and Junio.
Robertoo
^ permalink raw reply
* Re: First cut at git port to Cygwin
From: Johannes Schindelin @ 2005-09-29 8:46 UTC (permalink / raw)
To: H. Peter Anvin; +Cc: Git Mailing List
In-Reply-To: <433B3B10.5050407@zytor.com>
Hi,
On Wed, 28 Sep 2005, H. Peter Anvin wrote:
> Another funny which I haven't been able to figure out yet is that 'gitk'
> scrunches all its output up into a few pixels at the top of the window.
See my mail about rootless X11. I went about working around that
particular Tk bug by specifying the dimensions of the panes explicitely.
However, I was not especially happy with my workaround, since it did not
reproduce the layout exactly after a restart. Maybe you can figure it out
how to do that.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] fetch-pack should not ask for a ref which is already there
From: Johannes Schindelin @ 2005-09-29 8:42 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vll1gl4ms.fsf@assigned-by-dhcp.cox.net>
Hi,
On Thu, 29 Sep 2005, Junio C Hamano wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>
> > With this patch, instead of blindly asking for every remote ref, fetch-pack
> > first looks in the local repository if that ref is already there.
>
> This patch breaks things. git-fetch-pack is supposed to report
> the resulting SHA1 and refs on its standard output. If you are
> up to date with this patch you would lose that.
Yeah, sorry. I did not test that one. Maybe an automated test for
git-fetch-pack would be useful after all...
How about the following? (I avoided an ugly goto, but had to duplicate
code :-( )
---
[PATCH] fetch-pack should not ask for a ref which is already there
With this patch, instead of blindly asking for every remote ref, fetch-pack
first looks in the local repository if that ref is already there.
Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
---
fetch-pack.c | 36 ++++++++++++++++++++++++++----------
1 files changed, 26 insertions(+), 10 deletions(-)
fbef982e4c5c4591b8d5517ef1694ab71e29c9e5
diff --git a/fetch-pack.c b/fetch-pack.c
--- a/fetch-pack.c
+++ b/fetch-pack.c
@@ -16,20 +16,27 @@ static int find_common(int fd[2], unsign
int count = 0, flushes = 0, retval;
FILE *revs;
- revs = popen("git-rev-list $(git-rev-parse --all)", "r");
- if (!revs)
- die("unable to run 'git-rev-list'");
-
while (refs) {
unsigned char *remote = refs->old_sha1;
- if (verbose)
- fprintf(stderr,
- "want %s (%s)\n", sha1_to_hex(remote),
- refs->name);
- packet_write(fd[1], "want %s\n", sha1_to_hex(remote));
+ if(!has_sha1_file(remote)) {
+ if (verbose)
+ fprintf(stderr,
+ "want %s (%s)\n", sha1_to_hex(remote),
+ refs->name);
+ packet_write(fd[1], "want %s\n", sha1_to_hex(remote));
+ count++;
+ }
refs = refs->next;
}
packet_flush(fd[1]);
+
+ if(count==0)
+ return 1;
+
+ revs = popen("git-rev-list $(git-rev-parse --all)", "r");
+ if (!revs)
+ die("unable to run 'git-rev-list'");
+
flushes = 1;
retval = -1;
while (fgets(line, sizeof(line), revs) != NULL) {
@@ -86,7 +93,16 @@ static int fetch_pack(int fd[2], int nr_
packet_flush(fd[1]);
die("no matching remote head");
}
- if (find_common(fd, sha1, ref) < 0)
+ status = find_common(fd, sha1, ref);
+ if(status > 0) {
+ while (ref) {
+ printf("%s %s\n",
+ sha1_to_hex(ref->old_sha1), ref->name);
+ ref = ref->next;
+ }
+ return 0;
+ }
+ if(status < 0)
fprintf(stderr, "warning: no common commits\n");
pid = fork();
if (pid < 0)
^ permalink raw reply
* Re: Edit log message after commit
From: Catalin Marinas @ 2005-09-29 8:35 UTC (permalink / raw)
To: Kevin Leung; +Cc: git
In-Reply-To: <dhfjcu$36f$1@sea.gmane.org>
Kevin Leung <hysoka@gmail.com> wrote:
> Is there any method to edit the log message after committed? I
> couldn't find any information in Documentation and in git mailing
> list.
As the others said, a commit object is immutable but it can be
replaced with a new one and the path from HEAD changed. If you need to
do this often, have a look at StGIT. It allows you to create patches
as git commit objects and indefinitely edit them (both file changes
and commit information like log messages, author etc.).
In the latest snapshot, I also added a commit command to permanently
store the patches into the repository after which you won't be able to
edit them anymore (that's useful for maintainers using StGIT, not only
contributors).
--
Catalin
^ permalink raw reply
* Re: Edit log message after commit
From: Kevin Leung @ 2005-09-29 7:45 UTC (permalink / raw)
To: git
In-Reply-To: <dhfjcu$36f$1@sea.gmane.org>
Thank you all of you. I was able to redo the commit.
But as Tony has pointed out. I would have needed to redo all the subsequent commits if I was to change non-HEAD commit message. What is the proper way of doing that? Is it the same as Documentation/howto/revert-branch-rebase.txt ?
One more question is that, how to use the git commit --reedit-message flag? According to Documentation/howto/rebase-and-edit.txt, I guess the meaning is to re-apply one commit to current HEAD?
^ permalink raw reply
* Re: [PATCH] fetch-pack should not ask for a ref which is already there
From: Junio C Hamano @ 2005-09-29 7:22 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <Pine.LNX.4.63.0509290149230.19126@wgmdd8.biozentrum.uni-wuerzburg.de>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> With this patch, instead of blindly asking for every remote ref, fetch-pack
> first looks in the local repository if that ref is already there.
This patch breaks things. git-fetch-pack is supposed to report
the resulting SHA1 and refs on its standard output. If you are
up to date with this patch you would lose that.
^ permalink raw reply
* Re: Use of the -f flag on checkout
From: Matthias Urlichs @ 2005-09-29 7:09 UTC (permalink / raw)
To: git
In-Reply-To: <200509290754.30017.alan@chandlerfamily.org.uk>
Hi, Alan Chandler wrote:
> What is the risk in not using it (ie what are the cases when you should
> use it)?
The risk of using it is that you kill your local changes, even if you want
to keep them. They're *gone*.
The risk of not using it is that you check local changes into a branch
where they don't belong.
=> IMHO, "checkout -f" should be avoided in scripts. If you want to be
safe, check that you don't have local changes or additional files *before*
doing the work.
--
Matthias Urlichs | {M:U} IT Design @ m-u-it.de | smurf@smurf.noris.de
Disclaimer: The quote was selected randomly. Really. | http://smurf.noris.de
- -
To me, home is not rooms and places. It is the people I want to be with.
-- FJ van Wingerde
^ permalink raw reply
* Re: Pull from one branch to another?
From: Junio C Hamano @ 2005-09-29 7:06 UTC (permalink / raw)
To: Jeff Garzik; +Cc: git
In-Reply-To: <433B84BD.8030003@pobox.com>
Jeff Garzik <jgarzik@pobox.com> writes:
> ... It's been working for me, for months, but...
... will stop working as of Oct 1st? ;-)
> git-resolve-script HEAD $1 "`pwd` branch '$1'"
It is planned that we will stop installing *-script
compatibility symbolic links starting as of 0.99.8.
^ permalink raw reply
* Use of the -f flag on checkout
From: Alan Chandler @ 2005-09-29 6:54 UTC (permalink / raw)
To: git
In-Reply-To: <7vbr2cmle2.fsf@assigned-by-dhcp.cox.net>
On Thursday 29 Sep 2005 07:35, Junio C Hamano wrote:
> Jeff Garzik <jgarzik@pobox.com> writes:
> > My question: is this the best/right way to pull one branch into
> > another? It's been working for me, for months, but...
>
> Yes, that is how 'resolve' is designed to work.
>
> You could instead use standard 'git pull' from the local
> repository. Here is what I usually do in git.git repository:
>
> $ git checkout foo
> $ ... work in foo "topic" branch
> $ git checkout bar
> $ ... work in bar "topic" branch
> $ git checkout pu
I notice that Jeff is using the -f flag on checkout whereas you don't.
What is the risk in not using it (ie what are the cases when you should use
it)?
--
Alan Chandler
http://www.chandlerfamily.org.uk
^ permalink raw reply
* Re: Pull from one branch to another?
From: Junio C Hamano @ 2005-09-29 6:35 UTC (permalink / raw)
To: Jeff Garzik; +Cc: git
In-Reply-To: <433B84BD.8030003@pobox.com>
Jeff Garzik <jgarzik@pobox.com> writes:
> My question: is this the best/right way to pull one branch into
> another? It's been working for me, for months, but...
Yes, that is how 'resolve' is designed to work.
You could instead use standard 'git pull' from the local
repository. Here is what I usually do in git.git repository:
$ git checkout foo
$ ... work in foo "topic" branch
$ git checkout bar
$ ... work in bar "topic" branch
$ git checkout pu
$ git pull . foo bar
End result: foo and bar branches are pulled from the local
repository and merged into pu branch, as an Octopus.
Of course, I could instead:
$ git checkout pu
$ git pull . foo
$ git pull . bar
to pull 'foo' and then 'bar' in sequence, which is easier if
these topic branches touch overlapping area, because Octopus
does not allow manual resolving. On the other hand if I know
foo and bar are independent work, there is no point recording
the order of merges (merging foo first and then bar does not
have any significance) and I tend to let Octopus to happen.
^ permalink raw reply
* [PATCH] Cogito README: add a block describing team workflow with git+ssh
From: Martin Langhoff @ 2005-09-29 6:31 UTC (permalink / raw)
To: git; +Cc: Martin Langhoff
The README doesn't talk about teams with "peer" access to a shared repo.
It took me a while to figure our the /right/ way to do it. Document for
future generations and general happiness.
Signed-off-by: Martin Langhoff <martin@catalyst.net.nz>
---
README | 35 +++++++++++++++++++++++++++++++++++
1 files changed, 35 insertions(+), 0 deletions(-)
ffd2191e527f6b7c67fa7939927a0bd30270c11a
diff --git a/README b/README
--- a/README
+++ b/README
@@ -268,6 +268,41 @@ Note that we gave only a glimpse to the
- merging (`cg-merge`), moving your tree to an older commit (`cg-seek`),
pushing (`cg-push`), etc.
+Using Cogito for Team Work
+--------------------------
+
+A small team with SSH access to a shared server can use Cogito in a way
+similar to traditional CVS over SSH.
+
+If you are bootstrapping the project, and you have a local Cogito working copy,
+you must set up the shared repository and push a local head to it.
+
+To set up the shared repository, for example in
+remoteserver:/var/git, login to the remote server and do
+
+ $ umask 002
+ $ mkdir /var/git
+ $ chgroup gitcommit /var/git
+ $ chmod 2775 /var/git
+ $ mkdir -p /var/git/projectname.git
+ $ GIT_DIR=/var/git/projectname.git git-init-db
+
+Note: All the developers with "commit" access must belong to the gitcommit
+group and have a 002 umask on the remote server.
+
+Going back to your Cogito working copy, run
+
+ $ git-push remoteserver:/var/git/projectname.git master branchname
+
+Now your other teammembers can start working with you, doing
+
+ $ cg-clone git+ssh://remoteserver/var/git/project.git#branchname localdir
+
+And when they are ready to push their work onto the shared repository, just do
+
+ $ cg-update
+ $ cg-push
+
Understanding GIT branching and merging
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
^ permalink raw reply
* Re: First cut at git port to Cygwin
From: H. Peter Anvin @ 2005-09-29 6:19 UTC (permalink / raw)
To: Martin Langhoff; +Cc: Git Mailing List
In-Reply-To: <46a038f905092821462d08f86a@mail.gmail.com>
Martin Langhoff wrote:
>
>>I have set up a git-on-Cygwin temporary tree at:
>>
>>http://www.kernel.org/pub/scm/git/git-cygwin.git
>
> Getting a 404 on that. Doesn't show up on gitweb either. I guess I
> have to wait...
>
Well, it's up there now.
-hpa
^ permalink raw reply
* Pull from one branch to another?
From: Jeff Garzik @ 2005-09-29 6:07 UTC (permalink / raw)
To: Git Mailing List
[-- Attachment #1: Type: text/plain, Size: 827 bytes --]
I currently use the attached script to merge the contents of one branch
into another branch, in my kernel trees:
$ cd /repo/netdev-2.6
$ git checkout -f sky2
$ ... merge patches ...
$ git checkout -f upstream
$ ... merge more patches ...
$ git checkout -f ALL
$ git-pull-branch upstream
$ git-pull-branch sky2
End result: 'ALL' branch contains everything in 'sky2' and 'upstream'
branches. I use the above for creating an all-inclusive branch that
users can test, and that Andrew Morton can pull into his -mm kernel tree.
Right now, my git-pull-branch script (attached) simply calls
git-resolve-script, which nicely skips the fetch step and any
complications related to that.
My question: is this the best/right way to pull one branch into
another? It's been working for me, for months, but...
Jeff
[-- Attachment #2: git-pull-branch --]
[-- Type: text/plain, Size: 59 bytes --]
#!/bin/sh
git-resolve-script HEAD $1 "`pwd` branch '$1'"
^ permalink raw reply
* Really happy with cogito for inhouse teamwork, now that I've figured out cg-clone...
From: Martin Langhoff @ 2005-09-29 5:58 UTC (permalink / raw)
To: Git Mailing List
Just wanted to mention something that isn't in Cogito's readme, and
has been crucial in making our use of cogito straightforward.
We've made the transition a few weeks ago, and we've been _really_
happy with git/cogito (over cvs and tla, our "other" SCMs). Whoever,
there was something we all found ackward in how we did
clone/pull/push.
The _right_ way to do for a team with git-over-ssh is:
Doing the checkout the 'right' way:
$ cg-clone git+ssh://locke.catalyst.net.nz/var/git/project.git#branchname
localdirname
Work cycle:
# work work work
$ cg-commit
$ cg-update
$ cg-push
The README doesn't talk about teams with "peer" access to a shared
repo. So I fumbled about and we were doing cg-clone using rsync (rsync
protocol or over ssh), or just straight http. This made pushing back
to the repo impossible with Cogito. So we were calling git-push
directly, with the risk of pushing to the wrong head (only really
risky for two very closely related heads, but still).
Now, I should put this into a patch to Cogito's README.... give me 5'...
martin
^ permalink raw reply
* Re: First cut at git port to Cygwin
From: Junio C Hamano @ 2005-09-29 5:13 UTC (permalink / raw)
To: Martin Langhoff; +Cc: git
In-Reply-To: <46a038f905092821462d08f86a@mail.gmail.com>
Martin Langhoff <martin.langhoff@gmail.com> writes:
> Is there a way to get gitweb to "compare" branches using git-cherry? I
> often look at branches via git-web and it's impossible to tell what
> makes them unique...
Now that you mention it, I felt that too. Maybe git-show-branch
output could help somehow?
^ permalink raw reply
* Re: GIT 0.99.7d, and end of week status.
From: Junio C Hamano @ 2005-09-29 5:11 UTC (permalink / raw)
To: git
In-Reply-To: <pan.2005.09.29.04.40.14.655977@smurf.noris.de>
Matthias Urlichs <smurf@smurf.noris.de> writes:
> I tend to agree -- intentional octopus merges are rare enough.
> For most people, anyway. ;-)
I agree, *and* I think what I proposed is consistent with that.
Essentially, you cannot create an Octopus without asking from
the command line, period.
^ permalink raw reply
* Re: First cut at git port to Cygwin
From: H. Peter Anvin @ 2005-09-29 5:07 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v64skpkbb.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
> "H. Peter Anvin" <hpa@zytor.com> writes:
>
>
>>There are still funnies. In particular, Cygwin and Samba handle
>>symlinks differently, so you can't trivially share a repository via
>>Samba. Linus' "symbolic refs" changes should eventually take care of that.
>
>
> I just sent out "The other side of Linus' symbolic refs" patch,
> saying that Cygwin capable of doing symlink would probably made
> it irrelevant. But it may not be a waste after all, considering
> what you said above.
>
After looking at it some more, what Samba does when talking to a host
that doesn't support Unix extensions is that it simply resolves the
symlink, in effect turning it into a hard link. That might be all git
needs. The reverse still doesn't work, though.
-hpa
^ permalink raw reply
* Re: Edit log message after commit
From: Brian Gerst @ 2005-09-29 4:58 UTC (permalink / raw)
To: Kevin Leung; +Cc: git
In-Reply-To: <dhfjcu$36f$1@sea.gmane.org>
Kevin Leung wrote:
> Hi,
>
> Is there any method to edit the log message after committed? I couldn't
> find any information in Documentation and in git mailing list.
The commit must be at the head, or else you can't change it without
breaking the chain of following commits. If you are using Cogito, use
cg-admin-uncommit and then re-commit it. Otherwise, create a new commit
object for the same tree and parent(s) as the old commit, with the new
message. The new commit object is your new head.
--
Brian Gerst
^ permalink raw reply
* Re: GIT 0.99.7d, and end of week status.
From: Matthias Urlichs @ 2005-09-29 4:40 UTC (permalink / raw)
To: git
In-Reply-To: <20050927101744.GD30889@pasky.or.cz>
Hi, Petr Baudis wrote:
> However, I still think
> that the user should be required to specify the to-be-merged head manually
> if the default choice isn't explicitly written in the remotes file.
I tend to agree -- intentional octopus merges are rare enough.
For most people, anyway. ;-)
--
Matthias Urlichs | {M:U} IT Design @ m-u-it.de | smurf@smurf.noris.de
Disclaimer: The quote was selected randomly. Really. | http://smurf.noris.de
- -
It is not a good omen when goldfish commit suicide.
^ 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