* Re: Managing several threads of the same project in GIT
From: Santi Béjar @ 2008-12-26 11:50 UTC (permalink / raw)
To: pggrd; +Cc: git
In-Reply-To: <loom.20081226T110416-269@post.gmane.org>
2008/12/26 pggrd <git@paggard.com>:
> Hello,
>
> I've been studying GIT for some time already, but still have not figured out if
> it can be used for the scenario like this:
>
> for example:
>
> I have a project, which divides to threads aiming to different clients
I suppose what you call threads are branches in git.
> most of the code in the project is shared between the threads
> in certain files there are different code parts to meet client requirements
> but even those files share the rest of the code
>
> What I need to be able to do is:
> - to get code for any thread I like at any time
> - to be able to develop each thread separately
> - to be able to merge certain changes from one thread to another, at the same
> time without loosing the changes specific to the thread, and keep track of merge
> history
>
Git works best with convergent branches, so all branches should have
more or less the same code.
What you can do is to have different configuration for each client (or
Makefile variables), in the same way git supports different
architectures, different sha1 implementations, etc. All the code is
there and you just choose which one to use.
Santi
^ permalink raw reply
* Managing several threads of the same project in GIT
From: pggrd @ 2008-12-26 11:20 UTC (permalink / raw)
To: git
Hello,
I've been studying GIT for some time already, but still have not figured out if
it can be used for the scenario like this:
for example:
I have a project, which divides to threads aiming to different clients
most of the code in the project is shared between the threads
in certain files there are different code parts to meet client requirements
but even those files share the rest of the code
What I need to be able to do is:
- to get code for any thread I like at any time
- to be able to develop each thread separately
- to be able to merge certain changes from one thread to another, at the same
time without loosing the changes specific to the thread, and keep track of merge
history
With GIT strategy to treat content as a single unity - if you will try to merge
branches - everything will be merged thus overwriting the changes that need to
stay. But in the example above, if I make a change in the shared code in one
thread, I need to be able to populate this change to all the threads, but this
change only.
so - is this possible in GIT and if yes - what kind of strategy should be used?
thanks
^ permalink raw reply
* [PATCH] git-shortlog.txt: improve documentation about .mailmap files
From: Adeodato Simó @ 2008-12-26 11:18 UTC (permalink / raw)
To: git, gitster
The previous .mailmap example made it seem like .mailmap files are only
useful for commits with a wrong address for an author, when they are about
fixing the real name. Explained this better in the text, and replaced the
existing example with a new one that hopefully makes things clearer.
---
Documentation/git-shortlog.txt | 31 ++++++++++++++++++++++++-------
1 files changed, 24 insertions(+), 7 deletions(-)
diff --git a/Documentation/git-shortlog.txt b/Documentation/git-shortlog.txt
index 7ccf31c..69e10a4 100644
--- a/Documentation/git-shortlog.txt
+++ b/Documentation/git-shortlog.txt
@@ -48,15 +48,32 @@ OPTIONS
FILES
-----
-If the file `.mailmap` exists, it will be used for mapping author
-email addresses to a real author name. One mapping per line, first
-the author name followed by the email address enclosed by
-'<' and '>'. Use hash '#' for comments. Example:
+If a file `.mailmap` exists in the toplevel directory of the repository,
+it will be used for mapping author email addresses to a canonical real
+name. This can be used to coalesce together commits by the same person
+where their name was spelled differently (whether with the same email
+address or not).
+
+The format of the file is one mapping per line, first the desired author
+name followed by the email address enclosed by '<' and '>'. Use hash '#'
+for comments. For example, if your history contains commits by these
+committers:
+
+------------
+Author: Joe Developer <joe@random.com>
+Author: Joe R. Developer <joe@random.com>
+Author: Jane Doe <jane@the-does.name>
+Author: Jane Doe <jane@laptop.(none)>
+Author: Jane D. <jane@desktop.(none)>
+------------
+
+Then a proper `.mailmap` file would be:
------------
-# Keep alphabetized
-Adam Morrow <adam@localhost.localdomain>
-Eve Jones <eve@laptop.(none)>
+# Note how we don't need an entry for <jane@laptop.(none)>, because the
+# real name of that author is correct already, and coalesced directly.
+Jane Doe <jane@desktop.(none)>
+Joe R. Developer <joe@random.com>
------------
Author
--
1.6.1
^ permalink raw reply related
* Re: [PATCH] ls-tree: add --full-tree option
From: demerphq @ 2008-12-26 10:31 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Johannes Sixt, git, Deskin Miller
In-Reply-To: <7vmyejpb6o.fsf@gitster.siamese.dyndns.org>
2008/12/26 Junio C Hamano <gitster@pobox.com>:
> Johannes Sixt <j6t@kdbg.org> writes:
>
>> On Freitag, 26. Dezember 2008, Junio C Hamano wrote:
>>> This new option makes the command operate on the full tree object,
>>> regardless of where in the work tree it is run from. It also implies the
>>> behaviour that is triggered by the existing --full-name option.
>>
>> What's wrong with using 'git ls-tree ${rev}:'?
>>
>> Except that it does not work...
>
> Hmph... you seem to be describing the exact issue they discussed on #git,
> which triggered the patch in the message you are responding to. I am not
> sure what to say to your "What's wrong with...".
AFAIK I started that discussion, and during it we also mentioned that
it would be very useful to be able to use git ls-files in non
recursive mode. As the advantage of using ls-tree, prior to your fix,
was that it is the only way to get a list of files for the current
working directory and only the current working directory.
Since you have fixed that bug what command does one us to get a list
of tracked files for the current working directory without recursing
into subdirectories? Can we have a switch on ls-files that disables
recursion? Please?
Cheers,
Yves
--
perl -Mre=debug -e "/just|another|perl|hacker/"
^ permalink raw reply
* [PATCH] merge-file: handle freopen() failure
From: René Scharfe @ 2008-12-26 10:17 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Git Mailing List
In-Reply-To: <1230284785.6728.26.camel@ubuntu.ubuntu-domain>
Report the error if redirection of stderr to /dev/null failed.
This silences a compiler warning about ignoring the return value
of freopen() on Ubuntu 8.10.
Signed-off-by: Rene Scharfe <rene.scharfe@lsrfire.ath.cx>
---
builtin-merge-file.c | 7 +++++--
1 files changed, 5 insertions(+), 2 deletions(-)
diff --git a/builtin-merge-file.c b/builtin-merge-file.c
index 9d4e874..96edb97 100644
--- a/builtin-merge-file.c
+++ b/builtin-merge-file.c
@@ -51,8 +51,11 @@ int cmd_merge_file(int argc, const char **argv, const char *prefix)
argc = parse_options(argc, argv, options, merge_file_usage, 0);
if (argc != 3)
usage_with_options(merge_file_usage, options);
- if (quiet)
- freopen("/dev/null", "w", stderr);
+ if (quiet) {
+ if (!freopen("/dev/null", "w", stderr))
+ return error("failed to redirect stderr to /dev/null: "
+ "%s\n", strerror(errno));
+ }
for (i = 0; i < 3; i++) {
if (!names[i])
^ permalink raw reply related
* [PATCH 3/3] daemon: cleanup: factor out xstrdup_tolower()
From: René Scharfe @ 2008-12-26 10:12 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Git Mailing List
In-Reply-To: <1230285717.6728.40.camel@ubuntu.ubuntu-domain>
Add xstrdup_tolower(), a helper to get a lower case copy of a
string, and use it in two cases.
Signed-off-by: Rene Scharfe <rene.scharfe@lsrfire.ath.cx>
---
daemon.c | 34 +++++++++++++---------------------
1 files changed, 13 insertions(+), 21 deletions(-)
diff --git a/daemon.c b/daemon.c
index 4468fb9..60bf6c7 100644
--- a/daemon.c
+++ b/daemon.c
@@ -397,6 +397,14 @@ static void make_service_overridable(const char *name, int ena)
die("No such service %s", name);
}
+static char *xstrdup_tolower(const char *str)
+{
+ char *p, *dup = xstrdup(str);
+ for (p = dup; *p; p++)
+ *p = tolower(*p);
+ return dup;
+}
+
/*
* Separate the "extra args" information as supplied by the client connection.
*/
@@ -405,7 +413,6 @@ static void parse_extra_args(char *extra_args, int buflen)
char *val;
int vallen;
char *end = extra_args + buflen;
- char *hp;
while (extra_args < end && *extra_args) {
saw_extended_args = 1;
@@ -423,7 +430,7 @@ static void parse_extra_args(char *extra_args, int buflen)
tcp_port = xstrdup(port);
}
free(hostname);
- hostname = xstrdup(host);
+ hostname = xstrdup_tolower(host);
}
/* On to the next one */
@@ -432,19 +439,10 @@ static void parse_extra_args(char *extra_args, int buflen)
}
/*
- * Replace literal host with lowercase-ized hostname.
- */
- hp = hostname;
- if (!hp)
- return;
- for ( ; *hp; hp++)
- *hp = tolower(*hp);
-
- /*
* Locate canonical hostname and its IP address.
*/
+ if (hostname) {
#ifndef NO_IPV6
- {
struct addrinfo hints;
struct addrinfo *ai, *ai0;
int gai;
@@ -468,9 +466,7 @@ static void parse_extra_args(char *extra_args, int buflen)
}
freeaddrinfo(ai0);
}
- }
#else
- {
struct hostent *hent;
struct sockaddr_in sa;
char **ap;
@@ -491,8 +487,8 @@ static void parse_extra_args(char *extra_args, int buflen)
canon_hostname = xstrdup(hent->h_name);
free(ip_address);
ip_address = xstrdup(addrbuf);
- }
#endif
+ }
}
@@ -945,12 +941,8 @@ int main(int argc, char **argv)
char *arg = argv[i];
if (!prefixcmp(arg, "--listen=")) {
- char *p = arg + 9;
- char *ph = listen_addr = xmalloc(strlen(arg + 9) + 1);
- while (*p)
- *ph++ = tolower(*p++);
- *ph = 0;
- continue;
+ listen_addr = xstrdup_tolower(arg + 9);
+ continue;
}
if (!prefixcmp(arg, "--port=")) {
char *end;
--
1.6.1
^ permalink raw reply related
* [PATCH 2/3] daemon: cleanup: replace loop with if
From: René Scharfe @ 2008-12-26 10:01 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Git Mailing List
In-Reply-To: <1230284785.6728.26.camel@ubuntu.ubuntu-domain>
Replace a loop around an enter_repo() call, which was used to retry
a single time with a different parameter in case the first call fails,
with two calls and an if. This is shorter and cleaner.
Signed-off-by: Rene Scharfe <rene.scharfe@lsrfire.ath.cx>
---
daemon.c | 18 +++++-------------
1 files changed, 5 insertions(+), 13 deletions(-)
diff --git a/daemon.c b/daemon.c
index 8c317be..4468fb9 100644
--- a/daemon.c
+++ b/daemon.c
@@ -150,7 +150,6 @@ static char *path_ok(char *directory)
{
static char rpath[PATH_MAX];
static char interp_path[PATH_MAX];
- int retried_path = 0;
char *path;
char *dir;
@@ -219,22 +218,15 @@ static char *path_ok(char *directory)
dir = rpath;
}
- do {
- path = enter_repo(dir, strict_paths);
- if (path)
- break;
-
+ path = enter_repo(dir, strict_paths);
+ if (!path && base_path && base_path_relaxed) {
/*
* if we fail and base_path_relaxed is enabled, try without
* prefixing the base path
*/
- if (base_path && base_path_relaxed && !retried_path) {
- dir = directory;
- retried_path = 1;
- continue;
- }
- break;
- } while (1);
+ dir = directory;
+ path = enter_repo(dir, strict_paths);
+ }
if (!path) {
logerror("'%s': unable to chdir or not a git archive", dir);
--
1.6.1
^ permalink raw reply related
* [PATCH 1/3] daemon: handle freopen() failure
From: René Scharfe @ 2008-12-26 9:46 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Git Mailing List
Die if stderr couldn't be sent to /dev/null when operating in inetd
mode and report the error message from the OS.
This fixes a compiler warning about the return value of freopen()
being ignored on Ubuntu 8.10.
Signed-off-by: Rene Scharfe <rene.scharfe@lsrfire.ath.cx>
---
daemon.c | 4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/daemon.c b/daemon.c
index 1cef309..8c317be 100644
--- a/daemon.c
+++ b/daemon.c
@@ -1118,7 +1118,9 @@ int main(int argc, char **argv)
struct sockaddr *peer = (struct sockaddr *)&ss;
socklen_t slen = sizeof(ss);
- freopen("/dev/null", "w", stderr);
+ if (!freopen("/dev/null", "w", stderr))
+ die("failed to redirect stderr to /dev/null: %s",
+ strerror(errno));
if (getpeername(0, peer, &slen))
peer = NULL;
--
1.6.1
^ permalink raw reply related
* Re: [ANNOUNCE] git-cola 1.3.4
From: David Aguilar @ 2008-12-26 9:38 UTC (permalink / raw)
To: R. Tyler Ballance; +Cc: Git Mailing List
In-Reply-To: <1230281078.14882.89.camel@starfruit>
On Fri, Dec 26, 2008 at 12:44 AM, R. Tyler Ballance <tyler@slide.com> wrote:
>
> This whole set up is very confusing to me, it appears that those files
> (judging by your .gitignore) are being generated by the Qt4 .ui files,
> but how that translates into submitting a patch I haven't the faintest
> idea :)
>
>
> I got something running at the very least I suppose :)
>
> Cheers
>
> --
> -R. Tyler Ballance
> Slide, Inc.
>
I figured out a workaround that'll work for now. I've pushed it out
so if you're building from source you should be golden. I'll file a
bug report and see what they have to say. Until then we should be
good to go =)
Thanks for the report and let me know if there's anything else you run into.
--
David
^ permalink raw reply
* Re: [PATCH] ls-tree: add --full-tree option
From: Junio C Hamano @ 2008-12-26 8:55 UTC (permalink / raw)
To: Johannes Sixt; +Cc: git, Deskin Miller
In-Reply-To: <200812260916.45401.j6t@kdbg.org>
Johannes Sixt <j6t@kdbg.org> writes:
> On Freitag, 26. Dezember 2008, Junio C Hamano wrote:
>> This new option makes the command operate on the full tree object,
>> regardless of where in the work tree it is run from. It also implies the
>> behaviour that is triggered by the existing --full-name option.
>
> What's wrong with using 'git ls-tree ${rev}:'?
>
> Except that it does not work...
Hmph... you seem to be describing the exact issue they discussed on #git,
which triggered the patch in the message you are responding to. I am not
sure what to say to your "What's wrong with...".
^ permalink raw reply
* Re: [ANNOUNCE] git-cola 1.3.4
From: R. Tyler Ballance @ 2008-12-26 8:44 UTC (permalink / raw)
To: David Aguilar; +Cc: Git Mailing List
In-Reply-To: <402731c90812252359r5b6b9420hcadbfa076f561feb@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2694 bytes --]
On Thu, 2008-12-25 at 23:59 -0800, David Aguilar wrote:
> I'm on debian. There's official debian packages these days that are
> making their way into both ubuntu and debian.
>
> I'm probably doing something wrong since maybe pyuic4 isn't supposed
> to be called via subprocess.Popen()? See the INSTALL file under
> 'build issues'. Your pyuic4 is missing a shebang line at the top of
> the file. I'm not sure if that's a packaging bug (openSUSE) or pyqt4
> bug. debian's pyuic4 has a #!/bin/sh line at the top and thus doesn't
> have this issue. I should probably change it so that it works either
> way... i'll see if I can work around that.
Impressive call! Adding the shebang to pyuic4 solved the issue, but I'm
as far in the dark as you are as to whose packaging domain this bug
falls under.
So that issue is out of the way, here's the next one I figure I should
pass your way :)
tyler@starfruit:~/source/git/git> git cola
Traceback (most recent call last):
File "/usr/local/bin/git-cola", line 54, in <module>
main()
File "/usr/local/lib64/python2.6/site-packages/cola/main.py",
line 114, in main
view = View(app.activeWindow())
File
"/usr/local/lib64/python2.6/site-packages/cola/views/main.py",
line 22, in __init__
self.setupUi(self)
File
"/usr/local/lib64/python2.6/site-packages/cola/gui/main.py",
line 183, in setupUi
self.splitter.setSortingEnabled(__sortingEnabled)
AttributeError: setSortingEnabled
tyler@starfruit:~/source/git/git>
(Pdb) self.splitter
<PyQt4.QtGui.QSplitter object at 0x9d88d0>
(Pdb) [f for f in dir(self.splitter) if f.lower().find('sort') >= 0]
[]
(Pdb)
I went ahead and changed the following lines in cola/gui/main.py to get
it up and running:
181 item = QtGui.QTreeWidgetItem(self.status_tree)
182 item = QtGui.QTreeWidgetItem(self.status_tree)
183 #self.splitter.setSortingEnabled(__sortingEnabled)
184 self.horizontalLayout_2.addWidget(self.splitter)
185
#self.centralwidget.setSortingEnabled(__sortingEnabled)
186 main.setCentralWidget(self.centralwidget)
This whole set up is very confusing to me, it appears that those files
(judging by your .gitignore) are being generated by the Qt4 .ui files,
but how that translates into submitting a patch I haven't the faintest
idea :)
I got something running at the very least I suppose :)
Cheers
--
-R. Tyler Ballance
Slide, Inc.
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: [PATCH] ls-tree: add --full-tree option
From: Johannes Sixt @ 2008-12-26 8:16 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Deskin Miller
In-Reply-To: <7v63l7rc1s.fsf@gitster.siamese.dyndns.org>
On Freitag, 26. Dezember 2008, Junio C Hamano wrote:
> This new option makes the command operate on the full tree object,
> regardless of where in the work tree it is run from. It also implies the
> behaviour that is triggered by the existing --full-name option.
What's wrong with using 'git ls-tree ${rev}:'?
Except that it does not work and still silently inserts the subdirectory,
which I consider a serious bug...
-- Hannes
^ permalink raw reply
* Re: [ANNOUNCE] git-cola 1.3.4
From: David Aguilar @ 2008-12-26 7:59 UTC (permalink / raw)
To: R. Tyler Ballance; +Cc: Git Mailing List
In-Reply-To: <1230277737.14882.54.camel@starfruit>
On Thu, Dec 25, 2008 at 11:48 PM, R. Tyler Ballance <tyler@slide.com> wrote:
>
> Looks pretty nice, I was trying to give this a whirl on Python 2.6 and
> was receiving the following errors while trying to build:
>
>
> tyler@starfruit:~/source/git/git-cola> /usr/bin/python setup.py
> build
> Traceback (most recent call last):
> pyqtver = utils.run_cmd('pyuic4', '--version').split()[-1]
> OSError: [Errno 8] Exec format error
> tyler@starfruit:~/source/git/git-cola>
>
>
> openSUSE 11.1 (my current OS) ships with 2.6 by default now, so I'm
> curious as to the environment you're running cola in?
>
> Looks fancy, can't wait to get it running :)
>
> Cheers
> --
> -R. Tyler Ballance
> Slide, Inc.
>
I'm on debian. There's official debian packages these days that are
making their way into both ubuntu and debian.
I'm probably doing something wrong since maybe pyuic4 isn't supposed
to be called via subprocess.Popen()? See the INSTALL file under
'build issues'. Your pyuic4 is missing a shebang line at the top of
the file. I'm not sure if that's a packaging bug (openSUSE) or pyqt4
bug. debian's pyuic4 has a #!/bin/sh line at the top and thus doesn't
have this issue. I should probably change it so that it works either
way... i'll see if I can work around that.
--
David
^ permalink raw reply
* Re: [ANNOUNCE] git-cola 1.3.4
From: R. Tyler Ballance @ 2008-12-26 7:48 UTC (permalink / raw)
To: David Aguilar; +Cc: git
In-Reply-To: <20081225233625.GA11029@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1540 bytes --]
On Thu, 2008-12-25 at 15:36 -0800, David Aguilar wrote:
> The latest git-cola release v1.3.4 is available at the
> usual places:
Looks pretty nice, I was trying to give this a whirl on Python 2.6 and
was receiving the following errors while trying to build:
tyler@starfruit:~/source/git/git-cola> /usr/bin/python setup.py
build
Traceback (most recent call last):
File "setup.py", line 131, in <module>
main()
File "setup.py", line 21, in main
__check_pyqt_version()
File "setup.py", line 98, in __check_pyqt_version
pyqtver = utils.run_cmd('pyuic4', '--version').split()[-1]
File "/home/tyler/source/git/git-cola/cola/utils.py", line 50,
in run_cmd
return git.Git.execute(command)
File "/home/tyler/source/git/git-cola/cola/git.py", line 96,
in execute
stdout=subprocess.PIPE)
File "/usr/lib64/python2.6/subprocess.py", line 595, in
__init__
errread, errwrite)
File "/usr/lib64/python2.6/subprocess.py", line 1106, in
_execute_child
raise child_exception
OSError: [Errno 8] Exec format error
tyler@starfruit:~/source/git/git-cola>
openSUSE 11.1 (my current OS) ships with 2.6 by default now, so I'm
curious as to the environment you're running cola in?
Looks fancy, can't wait to get it running :)
Cheers
--
-R. Tyler Ballance
Slide, Inc.
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: a few scenarios before I create my first repo [Scanned]
From: Sitaram Chamarty @ 2008-12-26 6:00 UTC (permalink / raw)
To: git
In-Reply-To: <gj1aoj$jas$1@ger.gmane.org>
On 2008-12-26, Zorba <cr@altmore.co.uk> wrote:
> Ok, I'll install git on workstation, where I'll be running the bash / gui
> from
> but I'll create the repo on the server (for backup purposes) - so won't need
> to install git there I'm assuming?
I would certainly go for making that also a git repo instead
of just a file-based backup server.
This has has 2 benefits: (1) it allows people to work
together in a more controlled fashion than ad hoc push/pull
from each other (2) being a full-blown git repo, it can
store a lot more history, *and* it's faster and uses less
space/network bw doing so.
Such servers usually have a "bare repository", meaning
what's inside the ".git" subdirectory is all there is, and
there is nothing actually checked out.
^ permalink raw reply
* Re: a few scenarios before I create my first repo [Scanned]
From: Sitaram Chamarty @ 2008-12-26 2:07 UTC (permalink / raw)
To: git
In-Reply-To: <7vabajrcfn.fsf@gitster.siamese.dyndns.org>
On 2008-12-26, Junio C Hamano <gitster@pobox.com> wrote:
> What's [scanned]?
>
> "Conor Rafferty" <conor.rafferty@altmore.co.uk> writes:
>> (3) if I create a repo and commit the first baseline, can I later create
>> an ancestor commit to that baseline, if I subsequently find an older
>> version of the project lying around on the file system (or, same concept
>> i guess, if i find a project version that sits between say version v1.0
>> and v1.1 (where v1.0 is the parent tag of v1.1) can i interleave the
>> project files as say v1.01.
>
> You can graft the older ones behind the root commit and filter-branch the
> result to cast the graft in stone. You are strongly recommended to do
> that in one repository first, and have reasonable level of confidence in
> the result before you publish it to other repositories, as running
> filter-branch to rewrite the history after people (or yourself) cloned the
> history to multiple places would cause trouble to thoese .
Considering the level of questions that Conor had, I thought
the following may be useful:
The way git works is that each commit is represented by a
sha-1 hash, which is an immutable 160-bit number that
"represents" that commit. The hash of the parent commit(s),
if any, as well as the contents of the current "tree" are
inputs to this hash, so if you create or change a parent,
the hash will change.
The sanctity of these hashes is fundamental to the
distributedness of git, so when you do something like that,
you're causing problems to any other repos which "pull"ed
from you, or which you "push"ed to -- they thought your
"latest" commit had, say, hash "A", but now hash "A" no
longer exists in your repo and has been replaced by hash
"B".
I have not (yet) had occasion to use either grafting or
filter-branch, but I'm pretty sure someone would have a nice
tutorial somewhere they can point to...
^ permalink raw reply
* Re: [ANNOUNCE] GIT 1.6.1
From: Sitaram Chamarty @ 2008-12-26 1:38 UTC (permalink / raw)
To: git; +Cc: linux-kernel
In-Reply-To: <20081225114443.GD6115@zakalwe.fi>
["Followup-To:" header set to gmane.comp.version-control.git.]
On 2008-12-25, Heikki Orsila <shdl@zakalwe.fi> wrote:
> * What would be the probability for a single bit flip to corrupt the
> repository?
> * And what is the situation where a single bit flip can not corrupt the
> database?
These two questions are not specific to git; whatever
answers apply to sha1 also apply here. Sha1 will always be
strong enough to detect any combination of random errors.
As for deliberate attacks, it is considered strong enough to
resist all but the most computationally intensive attacks
(the kind that require a worldwide effort or maybe NSA type
facilities).
> * When (which commands/functions) is error detection done?
"git fsck --full" will do it of course, but I'm not sure
what other operations also start off or end up doing a
check.
^ permalink raw reply
* git-difftool
From: David Aguilar @ 2008-12-26 1:30 UTC (permalink / raw)
To: git
[-- Attachment #1: Type: text/plain, Size: 1051 bytes --]
Several co-workers have found this script useful.
It's basically git-mergetool modified to operate on the git
index/worktree. There's some things about the script that
aren't very gitish (for example, the way revargs are
processed) but it's useful nonetheless.
The usual use case for this script is when you have either
staged or unstaged changes and you'd like to see the changes
in a side-by-side diff viewer (e.g. xxdiff, tkdiff, etc).
git difftool [<filename>*]
Another use case is when you'd like to see the same
information but are comparing arbitrary commits
(this is the part where the revarg parsing could be better)
git difftool --start=HEAD^ --end=HEAD [-- <filename>*]
The last use case is when you'd like to compare your current
worktree to something other than HEAD (e.g. a tag)
git difftool --commit=v1.0.0 [-- <filename>*]
It's a generally useful script so I thought I'd share it here.
If others find it useful then maybe we can fix it up and ship
it along with the other useful goodies in contrib/.
enjoy,
--
David
[-- Attachment #2: git-difftool.sh --]
[-- Type: application/x-sh, Size: 12218 bytes --]
^ permalink raw reply
* Re: a few scenarios before I create my first repo [Scanned]
From: Zorba @ 2008-12-26 1:07 UTC (permalink / raw)
To: git
In-Reply-To: <7vabajrcfn.fsf@gitster.siamese.dyndns.org>
Junio,
I am deeply priveleged that a guy like you would answer my simple Q's,
especially in holiday time !
Especially as now I've discovered a seperate list for users at
gman.comp.version-control.git.user - apologies for posting here...
> What's [scanned]?
sorry, its just something Sophos adds to our outgoing email to show its
virus checked it
>> (1a) Do I need to install windows git on the same machine I want to
>> store the files on ? Or can I install git on my workstation PC and
>> create the repo on the server ?
>
> The model employed by git is not "client working with centralized server".
> On whichever machine you want to be recording your changes (aka "running
> 'git commit'"), you would need to have git installed.
Ok, I'll install git on workstation, where I'll be running the bash / gui
from
but I'll create the repo on the server (for backup purposes) - so won't need
to install git there I'm assuming?
>> (1b) if i create a repo on my office PC, can it easily be moved
>> (including all history) to another PC (e.g. LAN server) if we decide to
>> implement git across the team (If not, or its inconvenient, I need to
>> create the repo on the server)
>
> git is a distributed source code management system. People often deploy
> one (or more, in hierarchical fashion in an advanced set-up) bare server
> repository for everybody to meet and synchronize. Each developer has one
> repository (or more) on his or her own on his or her machines. Most
> notably, if you work on your notebook and on your desktop (i.e. two
> machines), you will have (at least) one repository on each of them [*1*].
>
>> (2) if i create a repo on my work PC, can it easily be migrated
>> (including all history) to a repo on github (etc.) ?
>
> I do not know about github in particular (that's #github question) but in
> principle, yes. Easy exchange of development histories across
> repositories is the whole point of distributedness.
super!
I'm sorry distributed SCM was new to me
last time I used SCM was 10yrs ago - Visual Sourcesafe, PVCS (grrr),
clearcase (not bad)
>> (3) if I create a repo and commit the first baseline, can I later create
>> an ancestor commit to that baseline, if I subsequently find an older
>> version of the project lying around on the file system (or, same concept
>> i guess, if i find a project version that sits between say version v1.0
>> and v1.1 (where v1.0 is the parent tag of v1.1) can i interleave the
>> project files as say v1.01.
>
> You can graft the older ones behind the root commit and filter-branch the
> result to cast the graft in stone. You are strongly recommended to do
> that in one repository first, and have reasonable level of confidence in
> the result before you publish it to other repositories, as running
> filter-branch to rewrite the history after people (or yourself) cloned the
> history to multiple places would cause trouble to thoese .
that's great, it will allow us to capture the flow of work in our project so
far, and amend if some other version turns up !
Your answers are enough for me to proceed and give git a go.
> For more details, see the user-manual. Don't dive into manual pages for
> individual commands, which are for people who already understood the basic
> concepts in the user manual.
thanks, your overview here has really helped
> [Footnote]
> *1* Maybe we should change our pricing structure to be based on the number
> of repositories, not on the number of users. Currently we charge $0 per
> user, but we should change $0 per repository ;-)
LOL !
you guys are great, thank you on behalf of people like me
Happy Christmas !
^ permalink raw reply
* [PATCH] ls-tree: add --full-tree option
From: Junio C Hamano @ 2008-12-26 0:54 UTC (permalink / raw)
To: git; +Cc: Deskin Miller
The established behaviour of "git ls-tree $commit" run from a subdirectory
"sub/dir" in a work tree is to limit the output to the paths in the
subdirectory, and strip off the leading "sub/dir" from the output, since
3c5e846 (ls-tree: major rewrite to do pathspec, 2005-11-26).
This was a "usability" feature made back in the days when the line between
Porcelain and plumbing was blurry, and in retrospect, it probably was
misguided. The behaviour may be what the end user would expect when the
command is run interactively from a subdirectory, but it also means that a
scripted Porcelain that wants to use the command to list the full contents
of a tree object has to do cd_to_toplevel (and save the output from
"rev-parse --show-prefix" before doing so, so that it can be used as a
pathspec if it wants to limit its operation to the original subdirectory
in other commands).
This new option makes the command operate on the full tree object,
regardless of where in the work tree it is run from. It also implies the
behaviour that is triggered by the existing --full-name option.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
* There was a discussion on #git between Ilari and deskin this morning;
hopefully I captured what they wanted correctly.
I do not care too deeply with this change myself, though...
builtin-ls-tree.c | 5 +++++
1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/builtin-ls-tree.c b/builtin-ls-tree.c
index cb61717..c386aa5 100644
--- a/builtin-ls-tree.c
+++ b/builtin-ls-tree.c
@@ -156,6 +156,11 @@ int cmd_ls_tree(int argc, const char **argv, const char *prefix)
chomp_prefix = 0;
break;
}
+ if (!strcmp(argv[1]+2, "full-tree")) {
+ ls_tree_prefix = prefix = NULL;
+ chomp_prefix = 0;
+ break;
+ }
if (!prefixcmp(argv[1]+2, "abbrev=")) {
abbrev = strtoul(argv[1]+9, NULL, 10);
if (abbrev && abbrev < MINIMUM_ABBREV)
--
1.6.1
^ permalink raw reply related
* Re: a few scenarios before I create my first repo [Scanned]
From: Junio C Hamano @ 2008-12-26 0:46 UTC (permalink / raw)
To: Conor Rafferty; +Cc: git
In-Reply-To: <BB5F02FD3789B54E8964D38D6775E718242D00@ALTMORE-SVR.altmore.local>
What's [scanned]?
"Conor Rafferty" <conor.rafferty@altmore.co.uk> writes:
> (1a) Do I need to install windows git on the same machine I want to
> store the files on ? Or can I install git on my workstation PC and
> create the repo on the server ?
The model employed by git is not "client working with centralized server".
On whichever machine you want to be recording your changes (aka "running
'git commit'"), you would need to have git installed.
> (1b) if i create a repo on my office PC, can it easily be moved
> (including all history) to another PC (e.g. LAN server) if we decide to
> implement git across the team (If not, or its inconvenient, I need to
> create the repo on the server)
git is a distributed source code management system. People often deploy
one (or more, in hierarchical fashion in an advanced set-up) bare server
repository for everybody to meet and synchronize. Each developer has one
repository (or more) on his or her own on his or her machines. Most
notably, if you work on your notebook and on your desktop (i.e. two
machines), you will have (at least) one repository on each of them [*1*].
> (2) if i create a repo on my work PC, can it easily be migrated
> (including all history) to a repo on github (etc.) ?
I do not know about github in particular (that's #github question) but in
principle, yes. Easy exchange of development histories across
repositories is the whole point of distributedness.
> (3) if I create a repo and commit the first baseline, can I later create
> an ancestor commit to that baseline, if I subsequently find an older
> version of the project lying around on the file system (or, same concept
> i guess, if i find a project version that sits between say version v1.0
> and v1.1 (where v1.0 is the parent tag of v1.1) can i interleave the
> project files as say v1.01.
You can graft the older ones behind the root commit and filter-branch the
result to cast the graft in stone. You are strongly recommended to do
that in one repository first, and have reasonable level of confidence in
the result before you publish it to other repositories, as running
filter-branch to rewrite the history after people (or yourself) cloned the
history to multiple places would cause trouble to thoese .
For more details, see the user-manual. Don't dive into manual pages for
individual commands, which are for people who already understood the basic
concepts in the user manual.
[Footnote]
*1* Maybe we should change our pricing structure to be based on the number
of repositories, not on the number of users. Currently we charge $0 per
user, but we should change $0 per repository ;-)
^ permalink raw reply
* Re: RFE: git-import-dsc should support http-links
From: Junio C Hamano @ 2008-12-26 0:27 UTC (permalink / raw)
To: Rolf Leggewie; +Cc: git, Guido Guenther
In-Reply-To: <gj06ks$ao9$1@ger.gmane.org>
Rolf Leggewie <no2spam@nospam.arcornews.de> writes:
> merry Christmas everyone. I hope this is the right place for this, I
> looked around and it seemed to me it was, so here it goes.
Sorry, I have never heard of git-import-dsc and had to google for it, only
to find that it is one [*1*] of a set [*2*] of debian local tools somebody
I've never heard of (Cc'ed) on this list has written.
> It would be nice if the following just worked:
>
> "git-import-dsc
> http://ftp.de.debian.org/debian/pool/main/g/gnucash/gnucash_2.2.6-2.dsc"
> Regards
>
> Rolf
> PS: How about some kind of official bug tracker for git?
Even if there were such a thing, I do not think this report belongs to it.
I would imagine a better place would be here:
http://bugs.debian.org/cgi-bin/pkgreport.cgi?package=git-buildpackage
[References]
*1* http://honk.sigxcpu.org/projects/git-buildpackage/manual-html/gbp.man.git.import.dsc.html
*2* http://honk.sigxcpu.org/projects/git-buildpackage/manual-html/gbp.man.git.buildpackage.html
^ permalink raw reply
* a few scenarios before I create my first repo [Scanned]
From: Conor Rafferty @ 2008-12-26 0:17 UTC (permalink / raw)
To: git
Dear All,
Apols for the newbie-ness of this post - I couldn't find a seperate
list/forum for user support.
I have no SCM for my projects and its becoming a nightmare. Lots of
folders lying around, with various versions.
Need to manage all this and do the work to catalog and archive the work
done so far and set up a good config mgmt framewrok for future work.
Been searching for an SCM and git seems good.
Before I create a repo of live files, I just wanna check:
(1a)
Do I need to install windows git on the same machine I want to store the
files on ?
Or can I install git on my workstation PC and create the repo on the
server ?
(1b)
if i create a repo on my office PC, can it easily be moved (including
all history) to another PC (e.g. LAN server) if we decide to implement
git across the team
(If not, or its inconvenient, I need to create the repo on the server)
(2)
if i create a repo on my work PC, can it easily be migrated (including
all history) to a repo on github (etc.) ?
(3)
if I create a repo and commit the first baseline, can I later create an
ancestor commit to that baseline, if I subsequently find an older
version of the project lying around on the file system
(or, same concept i guess, if i find a project version that sits between
say version v1.0 and v1.1 (where v1.0 is the parent tag of v1.1) can i
interleave the project files as say v1.01.
I've a feeling the answer's will be YES to 1 & 2 and NO to 3, but the
documentation is too low level for a newb like me.
many thanks
--
Conor Rafferty BSc (Hons.)
REGIONAL MANAGER
Altmore IT Recruitment
Townsend Enterprise Park
28 Townsend Street
Belfast BT13 2ES
T: +44 (0)28 9032 8400
E: conor.rafferty@altmore.co.uk
W: www.altmore.co.uk
LinkedIn: http://www.linkedin.com/in/conorrafferty
------------------------------------------------------------------------
--------
This electronic message contains information from Altmore IT Recruitment
which may be privileged or confidential. The information is intended to
be for the use of the individual(s) or entity named above. If you are
not the intended recipient be aware that any disclosure, copying
distribution or use of the contents of this information is prohibited.
If you have received this electronic message in error, please notify us
by telephone or email (to the numbers or address above) immediately.
^ permalink raw reply
* [ANNOUNCE] git-cola 1.3.4
From: David Aguilar @ 2008-12-25 23:36 UTC (permalink / raw)
To: git
The latest git-cola release v1.3.4 is available at the
usual places:
git-cola homepage:
http://cola.tuxfamily.org/
git-cola on github:
git clone git://github.com/davvid/git-cola.git
http://github.com/davvid/git-cola/tree/master
git-cola is a powerful git gui written in Python.
git-cola uses the PyQt4 gui toolkit and is supported on all
platforms where git is available, including Windows/msysgit.
The latest versions of git-cola sport a fresh new interface and
several new helpful dialogs. One of the newer git-cola dialogs
is the 'Commit Comparison' dialog which allows you to compare
arbitrary commits using standard merge tools (e.g. xxdiff).
git-cola uses a custom git command called git-difftool to
drive the merge tools. This is useful if you'd like
to use the functionality in your own scripts or from the
command line. I will post the current version of git-difftool
to the list for feedback and possible inclusion in the
git contrib/ area since it is a generally useful utility.
See the online documentation for more information.
---------------------------------------------------------------
Changes since v1.3.3 are as follows:
Barry Roberts (3):
Fix stash typo
Context menu items for Commits list
Speed up file identification
David Aguilar (15):
i18n: fix a few more places where we weren't unicode-safe
compare: reinstate the Commit -> Compare File... menu action
views: fix obsolete references to the old dockwidgets
diff gui: properly restore the scroll bar values on update
cola: pass --no-color to 'git diff' to avoid receiving ANSI sequences
controllers: fix a typo when restoring the scrollbar values on rescan
options dialog: fix some annoyances with the font handling
compare: fix an edge case when decreasing the number of log results
Use 'utf-8' instead of 'utf8' in core.encode()
models: call 'git update-index --refresh' in get_workdir_state()
rebase: list all branches in the branch chooser, not just local ones
INSTALL: remove references to the now unused 'file' command
win32: add a win32/ folder for storing all of the win32 hacks
INSTALL: fix a typo in the windows installation section
remote: add a rebase checkbox to the pull dialog
--
David
^ permalink raw reply
* Re: git rev-list with --name-status?
From: skillzero @ 2008-12-25 20:13 UTC (permalink / raw)
To: git
In-Reply-To: <7vr63w84iy.fsf@gitster.siamese.dyndns.org>
On Thu, Dec 25, 2008 at 10:59 AM, Junio C Hamano <gitster@pobox.com> wrote:
> You seem to be referring to contrib/hooks/post-receive-email as "The
> script that comes with git". It does have customization possibility
> already implemented and documented:
>
> hooks.showrev
> The shell command used to format each revision in the email, with
> "%s" replaced with the commit id. Defaults to "git rev-list -1
> --pretty %s", displaying the commit id, author, date and log
> message. To list full patches separated by a blank line, you
> could set this to "git show -C %s; echo".
>
> ...
>
> I think you can use "git show --name-status %s; echo" instead, if you like
> the --name-status output.
Thanks, that's perfect. I was using an older version of
contrib/hooks/post-receive-email that didn't have hooks.showrev so I
didn't realize it already had support for what I wanted.
^ 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