* Re: [PATCH] describe: when failing, tell the user about options that work
From: Nicolas Pitre @ 2009-10-23 0:13 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Alex Riesen, Thomas Rast, Eugene Sajine, git
In-Reply-To: <7v63a7f4ka.fsf@alter.siamese.dyndns.org>
On Thu, 22 Oct 2009, Junio C Hamano wrote:
> Alex Riesen <raa.lkml@gmail.com> writes:
>
> > These are quite verbose. Could they be conditional on something like
> > advice.describeHints?
>
> Concurred. Please make it so.
I don't have a strong opinion either ways, but is having a less verbose
message in the _error_ path really a big issue?
Nicolas
^ permalink raw reply
* Git 1.6.5.1 for Windows
From: Johannes Schindelin @ 2009-10-22 23:29 UTC (permalink / raw)
To: msysgit, git
Git Release Notes (Git-1.6.5.1-preview20091022)
Last update: 22 October 2009
Find it at http://code.google.com/p/msysgit/downloads/list
These release notes describe issues specific to the Windows release.
General release notes covering the history of the core git commands are
included in the subdirectory doc/git/html of the installation directory.
Look for files starting with RelNotes.
Known issues
- Some commands are not yet supported on Windows and excluded from the
installation; namely: git archimport, git cvsexportcommit, git cvsimport,
git cvsserver, git instaweb, git shell.
- The Logitec QuickCam software can cause spurious crashes. See "Why does
make often crash creating a sh.exe.stackdump file when I try to compile my
source code?" on the MinGW Wiki
(http://www.mingw.org/wiki/Environment_issues)
- The Quick Launch icon will only be installed for the user running setup
(typically the Administrator). This is a technical restriction and will
not change.
- Git Bash launched through the Explorer shell extension does not have the
git icon in its taskbar. This is a technical restriction and will not
change.
- curl uses $HOME/_netrc instead of $HOME/.netrc.
- If you want to specify a different location for --upload-pack, you have to
start the absolute path with two slashes. Otherwise MSys will mangle the
path.
- git and bash have serious problems with non-ASCII file names (Issue 80,
159).
- If configured to use plink, you will have to connect with putty first and
accept the host key.
- When run from cmd.exe instead of Git Bash, some characters seem to be
"swallowed" from Git's output (Issue 192).
- There are a spurious write errors during rebase (Issue 200) that seem not
to be reproducible on most computers.
- As merge tools are executed using the MSys bash, options starting with "/"
need to be handled specially: MSys would interpret that as a POSIX path,
so you need to double the slash (Issue 226). Example: instead of "/base",
say "//base". Also, extra care has to be paid to pass Windows programs
Windows paths, as they have no clue about MSys style POSIX paths -- You can
use something like $(cmd //c echo "$POSIXPATH").
Changes since Git-1.6.4-preview20090729
New Features
- Comes with official git 1.6.5.1.
- Thanks to Johan 't Hart, files and directories starting with a single dot
(such as '.git') will now be marked hidden (you can disable this setting
with core.hideDotFiles=false in your config) (Issue 288).
- Thanks to Thorvald Natvig, Git on Windows can simulate symbolic links by
using reparse points when available. For technical reasons, this only
works for symbolic links pointing to files, not directories.
- A lot of work has been put into making it possible to compile Git's source
code (the part written in C, of course, not the scripts) with Microsoft
Visual Studio. This work is ongoing.
- Thanks to Sebastian Schuberth, we only offer the (Tortoise)Plink option in
the installer if the presence of Plink was detected and at least one Putty
session was found (Issue 319).
- Thanks to Sebastian Schuberth, the installer has a nicer icon now.
Bugfixes
- Thanks to Sebastian Schuberth, git svn picks up the SSH setting specified
with the installer (Issue 305).
^ permalink raw reply
* Re: ks/precompute-completion (was Re: What's cooking in git.git (Oct 2009, #04; Wed, 21))
From: A Large Angry SCM @ 2009-10-22 23:05 UTC (permalink / raw)
To: Sverre Rabbelier
Cc: git, Shawn O. Pearce, Junio C Hamano, Kirill Smelkov,
Stephen Boyd
In-Reply-To: <fabb9a1e0910221556s694a344ag8e5ae07c35351ee4@mail.gmail.com>
Sverre Rabbelier wrote:
> How am i forcing completion on those that did not ask for it? Nothing
> changes compared to the old situation....
>
>> On Oct 22, 2009 5:20 PM, "A Large Angry SCM" <gitzilla@gmail.com
>> <mailto:gitzilla@gmail.com>> wrote:
>>
>> Sverre Rabbelier wrote: > > Heya, > > On Thu, Oct 22, 2009 at 03:34,
>> Stephen Boyd <bebarino@gmail.co...
>>
>> Please do not for completion on those that did not ask for it.
>
Your original email included 'make && make install'; it's the "make
install" part I'm concerned about.
^ permalink raw reply
* Re: ks/precompute-completion (was Re: What's cooking in git.git (Oct 2009, #04; Wed, 21))
From: Johannes Schindelin @ 2009-10-22 23:07 UTC (permalink / raw)
To: A Large Angry SCM
Cc: Sverre Rabbelier, Stephen Boyd, Junio C Hamano, git,
Kirill Smelkov, Shawn O. Pearce
In-Reply-To: <4AE0DAB3.1030103@gmail.com>
Hi,
On Thu, 22 Oct 2009, A Large Angry SCM wrote:
> Sverre Rabbelier wrote:
> > Heya,
> >
> > On Thu, Oct 22, 2009 at 03:34, Stephen Boyd <bebarino@gmail.com> wrote:
> > > Junio C Hamano wrote:
> > > > * ks/precompute-completion (2009-10-05) 1 commit.
> > > > (merged to 'next' on 2009-10-14 at adf722a)
> > > > + Speedup bash completion loading
> > > >
> > > > Are people happy with this?
> > > No. I now have rebase.sh, am.sh, etc. in my completion
> >
> > I would really like it if running 'make && make install' in git.git
> > would also build the completion script, I don't want to have to
> > remember to run 'cd contrib/completion && make' every time we get new
> > completion options :P.
> >
>
> Please do not for completion on those that did not ask for it.
It is about installing git-completion.bash, AFAICT, not about forcing your
shell into loading them by default. IOW something I wished for already in
Feb 2008, but was unable to convince anybody of.
Ciao,
Dscho
^ permalink raw reply
* Re: ks/precompute-completion (was Re: What's cooking in git.git (Oct 2009, #04; Wed, 21))
From: A Large Angry SCM @ 2009-10-22 22:20 UTC (permalink / raw)
To: Sverre Rabbelier
Cc: Stephen Boyd, Junio C Hamano, git, Kirill Smelkov,
Shawn O. Pearce
In-Reply-To: <fabb9a1e0910221011r957246dx3162cd675ff16800@mail.gmail.com>
Sverre Rabbelier wrote:
> Heya,
>
> On Thu, Oct 22, 2009 at 03:34, Stephen Boyd <bebarino@gmail.com> wrote:
>> Junio C Hamano wrote:
>>> * ks/precompute-completion (2009-10-05) 1 commit.
>>> (merged to 'next' on 2009-10-14 at adf722a)
>>> + Speedup bash completion loading
>>>
>>> Are people happy with this?
>> No. I now have rebase.sh, am.sh, etc. in my completion
>
> I would really like it if running 'make && make install' in git.git
> would also build the completion script, I don't want to have to
> remember to run 'cd contrib/completion && make' every time we get new
> completion options :P.
>
Please do not for completion on those that did not ask for it.
^ permalink raw reply
* Re: [PATCH] describe: when failing, tell the user about options that work
From: Junio C Hamano @ 2009-10-22 22:26 UTC (permalink / raw)
To: Alex Riesen; +Cc: Thomas Rast, Eugene Sajine, git
In-Reply-To: <81b0412b0910220940n78ddb774i30338147327b198a@mail.gmail.com>
Alex Riesen <raa.lkml@gmail.com> writes:
> These are quite verbose. Could they be conditional on something like
> advice.describeHints?
Concurred. Please make it so.
^ permalink raw reply
* Re: [RFC/PATCH] git-merge: forbid fast-forward and up-to-date when --no-commit is given
From: Junio C Hamano @ 2009-10-22 22:26 UTC (permalink / raw)
To: Nanako Shiraishi
Cc: git, Clemens Buchacher, Bjorn Steinbrink, Daniel Barkalow,
Thomas Rast
In-Reply-To: <20091022192145.6117@nanako3.lavabit.com>
Nanako Shiraishi <nanako3@lavabit.com> writes:
> the change breaks --squash to merge a branch, doesn't it?
>
> % git checkout feature # from your master branch
> % work; git commit; work; git commit
> % git checkout master # go back to your master branch
> % git merge --squash feature
>
> This is a useful way to clean up changes that were built
> in small steps that turned out to be worth only a commit.
Incidentally we seemed to have seen an end user request for exactly this
workflow.
A reroll has been queued, as below, with an update to a test script that
expects --no-commit to be a no-op for fast-forward.
-- >8 --
Traditionally "git merge --no-commit" meant just that: do not create a new
commit even when a merge succeeds. But this leads to confusion when the
merged commit is a descendant of the current commit, in which case we
succeed the merge by fast-forwarding and without creating a new commit.
Also when the merged commit is already a part of the history, we succeeded
without doing anything.
Error out when --no-commit is given but the merge would result in a
fast-forward or an up-to-date.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
builtin-merge.c | 11 +++++++++++
t/t7600-merge.sh | 4 +---
2 files changed, 12 insertions(+), 3 deletions(-)
diff --git a/builtin-merge.c b/builtin-merge.c
index b6b8428..2149aed 100644
--- a/builtin-merge.c
+++ b/builtin-merge.c
@@ -829,6 +829,12 @@ static int evaluate_result(void)
return cnt;
}
+static void check_no_commit(const char *msg)
+{
+ if (!option_commit)
+ die("The merge will %s but --no-commit was given.", msg);
+}
+
int cmd_merge(int argc, const char **argv, const char *prefix)
{
unsigned char result_tree[20];
@@ -996,6 +1002,7 @@ int cmd_merge(int argc, const char **argv, const char *prefix)
* If head can reach all the merge then we are up to date.
* but first the most common case of merging one remote.
*/
+ check_no_commit("be a no-op because you are up-to-date");
finish_up_to_date("Already up-to-date.");
return 0;
} else if (allow_fast_forward && !remoteheads->next &&
@@ -1006,6 +1013,9 @@ int cmd_merge(int argc, const char **argv, const char *prefix)
struct object *o;
char hex[41];
+ if (allow_fast_forward && !squash)
+ check_no_commit("fast forward");
+
strcpy(hex, find_unique_abbrev(head, DEFAULT_ABBREV));
if (verbosity >= 0)
@@ -1074,6 +1084,7 @@ int cmd_merge(int argc, const char **argv, const char *prefix)
}
}
if (up_to_date) {
+ check_no_commit("be a no-op because you are up-to-date");
finish_up_to_date("Already up-to-date. Yeeah!");
return 0;
}
diff --git a/t/t7600-merge.sh b/t/t7600-merge.sh
index e5b210b..86b0537 100755
--- a/t/t7600-merge.sh
+++ b/t/t7600-merge.sh
@@ -265,9 +265,7 @@ test_debug 'gitk --all'
test_expect_success 'merge c0 with c1 (no-commit)' '
git reset --hard c0 &&
- git merge --no-commit c1 &&
- verify_merge file result.1 &&
- verify_head $c1
+ test_must_fail git merge --no-commit c1
'
test_debug 'gitk --all'
--
1.6.5.1.124.g746fb6
^ permalink raw reply related
* Re: requesting info page (and pdf) doc releases
From: Rustom Mody @ 2009-10-22 22:13 UTC (permalink / raw)
To: Sebastian Pipping; +Cc: git
In-Reply-To: <4AE0C362.3030900@gentoo.org>
On Fri, Oct 23, 2009 at 2:11 AM, Sebastian Pipping <sping@gentoo.org> wrote:
>
> hi there!
>
>
> would be nice to get info pages (and pdf) doc releases in addition to
> html and man pages. i imagine such a change to the release machine
> should not be too hard to integrate. we could use it in gentoo.
>
> thanks,
>
>
>
> sebastian
+1
Why only gentoo? I would use it on ubuntu or windows as well
^ permalink raw reply
* Re: Any way to "flatten" a series of changes in git
From: Jakub Narebski @ 2009-10-22 21:57 UTC (permalink / raw)
To: Howard Miller; +Cc: git
In-Reply-To: <26ae428a0910221411l73aa7cbak5c060925ccdf4cea@mail.gmail.com>
On Thu, 22 Oct 2009, Howard Miller wrote:
> > You can use either "git merge --squash" or "git rebase --interactive"
> > (changing 'pick' to 'squash').
> >
>
> Actually thinking some more.... I don't understand something about
> this. I don't actually want to merge or rebase with anything. I just
> want to say "make those commits a series of commits on a branch into
> just one commit with a new message". I seriously suspect I'm missing
> the point somewhere but what has that got to do with merging or
> rebasing?
Actually using "git merge --squash" is a bit different from using
"git rebase --interactive".
1. "git merge --squash"
>From documentation:
--squash::
Produce the working tree and index state as if a real
merge happened (except for the merge information),
but do not actually make a commit or
move the `HEAD`, nor record `$GIT_DIR/MERGE_HEAD` to
cause the next `git commit` command to create a merge
commit. This allows you to create a single commit on
top of the current branch whose effect is the same as
merging another branch (or more in case of an octopus).
This means for example if you did your changes on a separate
topic branch, and you want to merge your changes into 'master'
branch, you would do
$ git checkout master
$ git merge side-branch
which would result in the following history:
---*---*---*---*---*---*---*---M <-- master
\ /
\-.---.---.---.---.---.-/ <-- side-branch
If you used '--squash' option to git-merge, because changes were
made in throwaway topic branch, and as you said only final result
matter, you would get:
$ git checkout master
$ git merge --squash side-branch
---*---*---*---*---*---*---*---M' <-- master
\
\-.---.---.---.---.---. <-- side-branch
where commit M' has the same contents (the same tree) as commit M
in previous example, but is not a merge commit.
If you simply want to squash last say 5 commits into one, you can
use "git merge --squash" for it in the following way:
$ git reset --hard HEAD~5
$ git merge --squash --no-ff HEAD@{1}
which means basically: rewind to state 5 commits back, then merge
in changes from before rewind, squashing them. The --no-ff is needed
because otherwise it would be fast-forward and no commit would be
created.
2. "git rebase --interactive"
The interactive rebase is meant to edit commits being rebased, but
it can be used simply to edit commits. It includes 'squash' command
that can be used to concatenate (squash) commits.
So to squash last say 5 commits into one, you would use
$ git rebase --interactive HEAD~5
then edit provided list of commands and commits to read something like
this:
pick deadbee The oneline of this commit
squash fa1afe1 The oneline of the next commit
...
squash beedead The oneline of the that commit
i.e. replace 'pick' command by 'squash' command.
This is a very powerfull command, and can be used for example to turn
series of say 5 commits into series of say 2 commits; not simply squashing
to a single commit, but reducing number of commits (and presumably
cleaning up those commits).
HTH (hope that helps)
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: What's cooking in git.git (Oct 2009, #04; Wed, 21)
From: Junio C Hamano @ 2009-10-22 21:42 UTC (permalink / raw)
To: skillzero
Cc: Nguyen Thai Ngoc Duy, Jakub Narebski, Junio C Hamano,
Git Mailing List
In-Reply-To: <2729632a0910220831x4b67021eg772abc8b751ef7e5@mail.gmail.com>
skillzero@gmail.com writes:
> Just an FYI, but I've been using this series for a while. I'm actually
> relying on sparse support in our internal build system (via my private
> build with this series) so I hope it doesn't go away :) I haven't
> really noticed any problems (I thought the index state got out of sync
> once, but I couldn't reproduce the problem later). Here's some
> feedback though:
> ...
> That said, the current level of sparse support provided by this series
> is good enough for me because I can build my own scripts like this on
> top of it to automate things.
Thanks for sharing. It is the best approach to start by adding minimum
core level support and then to let people (like you) with real-world needs
to experiment with custom wrapper scripts, to figure out what user-level
concepts and workflows work and useful (and what don't and aren't), and
what additional core level features is helpful to support them. Over
time, successful custom wrappers will become the best-current-practice and
can be folded back into the mainline, and everybody will benefit.
^ permalink raw reply
* Re: feature "git tag -r" to show tags and commits they are pointing to
From: Junio C Hamano @ 2009-10-22 21:35 UTC (permalink / raw)
To: Eugene Sajine; +Cc: git
In-Reply-To: <76c5b8580910221424n220449b9vda26f032174b6fa7@mail.gmail.com>
Eugene Sajine <euguess@gmail.com> writes:
> Hi,
>
> Currently there is no way you can get the commits your tags are
> pointing to by using git tag.
> The only way i found is to use rev-parse (which is by the way not
> supported by the bash_completion)
>
> It seems reasonable to have upper level command like:
>
> $ git tag -r
>
> to output
>
> v0.1 8794hke84f9e8h9ef9eh949793...
> v0.2 jhkd934398e9f499f47w9789o97...
>
> $ git tag -n -r
>
> v0.1 "super message" 8794hke84f9e8h9ef9eh949793...
> v0.2 "another message" jhkd934398e9f499f47w9789o9f...
>
> $ git tag -r v0.2
> v0.2 jhkd934398e9f499f47w9789o9f...
>
>
> What do you think?
Not intereseted at all, as this does not look anything more than "because
I could", not "because this is useful and sorely lacking".
The "super message" and such are actually useful to humans, but "v0.1" is
much more useful than 8794hke to humans, and these tag names are just as
usable as the hexadecimal commit object names to the tools. You can say
"git show v0.1^0" and "git show 8794hke" and get the same thing.
Heck, "8794hke" is not even hexadecimal, and the fact that you did not
even notice it is a _S*RE_ sign that they are not useful to humans.
If you _are_ a human, that is ;-)
In other words, please do not justify such a proposal with "I want to have
'git tag' command to show the commit object name". Rather, justify _why_
(1) you _need_ to show the commit object name to begin with, and (2) the
output _has_ to come from 'git tag' and not 'git rev-parse'.
^ permalink raw reply
* Re: Any way to "flatten" a series of changes in git
From: Howard Miller @ 2009-10-22 21:24 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <26ae428a0910221411l73aa7cbak5c060925ccdf4cea@mail.gmail.com>
2009/10/22 Howard Miller <howard@e-learndesign.co.uk>:
>> You can use either "git merge --squash" or "git rebase --interactive"
>> (changing 'pick' to 'squash').
>>
>
> Actually thinking some more.... I don't understand something about
> this. I don't actually want to merge or rebase with anything. I just
> want to say "make those commits a series of commits on a branch into
> just one commit with a new message". I seriously suspect I'm missing
> the point somewhere but what has that got to do with merging or
> rebasing?
>
> Thanks again
>
Oh..... more reading of the help. It's this I take it...
" For example, if you want to reorder the last 5 commits, such that
what was HEAD~4 becomes the new HEAD. To achieve that, you
would call git-rebase like this:
$ git rebase -i HEAD~5"
Would it be ungrateful to suggest that the existence of that option
isn't clear from the synopsis at the start of the help? :-) I guess
I can put the SHA1 identifier of the first commit in my branch too?
Anyway, I'll go and try it and see what happens.
^ permalink raw reply
* feature "git tag -r" to show tags and commits they are pointing to
From: Eugene Sajine @ 2009-10-22 21:24 UTC (permalink / raw)
To: git; +Cc: Eugene Sajine
Hi,
Currently there is no way you can get the commits your tags are
pointing to by using git tag.
The only way i found is to use rev-parse (which is by the way not
supported by the bash_completion)
It seems reasonable to have upper level command like:
$ git tag -r
to output
v0.1 8794hke84f9e8h9ef9eh949793...
v0.2 jhkd934398e9f499f47w9789o97...
$ git tag -n -r
v0.1 "super message" 8794hke84f9e8h9ef9eh949793...
v0.2 "another message" jhkd934398e9f499f47w9789o9f...
$ git tag -r v0.2
v0.2 jhkd934398e9f499f47w9789o9f...
What do you think?
Thanks,
Eugene
^ permalink raw reply
* [PATCH 2/2] fetch: Speed up fetch of large numbers of refs
From: Julian Phillips @ 2009-10-22 21:06 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <20091022210444.18084.61685.julian@quantumfyre.co.uk>
When there are large numbers of refs, calling read_ref for each ref is
inefficent (and infact downright slow) - so instead use for_each_ref
to build up a string list of all the refs that we currently have,
which significantly improves the volume.
Signed-off-by: Julian Phillips <julian@quantumfyre.co.uk>
---
builtin-fetch.c | 17 ++++++++++++++---
1 files changed, 14 insertions(+), 3 deletions(-)
diff --git a/builtin-fetch.c b/builtin-fetch.c
index acb08e4..0f53cbd 100644
--- a/builtin-fetch.c
+++ b/builtin-fetch.c
@@ -489,7 +489,8 @@ static int add_existing(const char *refname, const unsigned char *sha1,
int flag, void *cbdata)
{
struct string_list *list = (struct string_list *)cbdata;
- string_list_insert(refname, list);
+ struct string_list_item *item = string_list_insert(refname, list);
+ item->util = (void *)sha1;
return 0;
}
@@ -606,9 +607,14 @@ static void check_not_current_branch(struct ref *ref_map)
static int do_fetch(struct transport *transport,
struct refspec *refs, int ref_count)
{
+ struct string_list existing_refs = { NULL, 0, 0, 0 };
+ struct string_list_item *peer_item = NULL;
struct ref *ref_map;
struct ref *rm;
int autotags = (transport->remote->fetch_tags == 1);
+
+ for_each_ref(add_existing, &existing_refs);
+
if (transport->remote->fetch_tags == 2 && tags != TAGS_UNSET)
tags = TAGS_SET;
if (transport->remote->fetch_tags == -1)
@@ -631,8 +637,13 @@ static int do_fetch(struct transport *transport,
check_not_current_branch(ref_map);
for (rm = ref_map; rm; rm = rm->next) {
- if (rm->peer_ref)
- read_ref(rm->peer_ref->name, rm->peer_ref->old_sha1);
+ if (rm->peer_ref) {
+ peer_item = string_list_lookup(rm->peer_ref->name,
+ &existing_refs);
+ if (peer_item)
+ hashcpy(rm->peer_ref->old_sha1,
+ peer_item->util);
+ }
}
if (tags == TAGS_DEFAULT && autotags)
--
1.6.5.rc2
^ permalink raw reply related
* [PATCH 0/2] Speedup fetch with large numbers of refs
From: Julian Phillips @ 2009-10-22 21:06 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
These two commits make fetch quite a bit faster when dealing with
large numbers of refs. Unfortunately I've lost the exact figures, but
my silly test respository (50000 tags, 1 branch) went from something
like 30s for a "fetch --tags" that did nothing, to about 5.
Julian Phillips (2):
remote: Make ref_remove_duplicates faster for large numbers of refs
fetch: Speed up fetch of large numbers of refs
builtin-fetch.c | 17 ++++++++++++++---
remote.c | 39 +++++++++++++++++++++------------------
2 files changed, 35 insertions(+), 21 deletions(-)
^ permalink raw reply
* [PATCH 1/2] remote: Make ref_remove_duplicates faster for large numbers of refs
From: Julian Phillips @ 2009-10-22 21:06 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <20091022210444.18084.61685.julian@quantumfyre.co.uk>
The ref_remove_duplicates function was very slow at dealing with very
large numbers of refs. This is because it was using a linear search
through all remaining refs to find any duplicates of the current ref.
Rewriting it to use a string list to keep track of which refs have
already been seen and removing duplicates when they are found is much
more efficient.
Signed-off-by: Julian Phillips <julian@quantumfyre.co.uk>
---
remote.c | 39 +++++++++++++++++++++------------------
1 files changed, 21 insertions(+), 18 deletions(-)
diff --git a/remote.c b/remote.c
index 73d33f2..a97c2c3 100644
--- a/remote.c
+++ b/remote.c
@@ -6,6 +6,7 @@
#include "revision.h"
#include "dir.h"
#include "tag.h"
+#include "string-list.h"
static struct refspec s_tag_refspec = {
0,
@@ -734,29 +735,31 @@ int for_each_remote(each_remote_fn fn, void *priv)
void ref_remove_duplicates(struct ref *ref_map)
{
- struct ref **posn;
- struct ref *next;
+ struct string_list refs = { NULL, 0, 0, 0 };
+ struct string_list_item *item = NULL;
+ struct ref *prev = NULL;
for (; ref_map; ref_map = ref_map->next) {
if (!ref_map->peer_ref)
continue;
- posn = &ref_map->next;
- while (*posn) {
- if ((*posn)->peer_ref &&
- !strcmp((*posn)->peer_ref->name,
- ref_map->peer_ref->name)) {
- if (strcmp((*posn)->name, ref_map->name))
- die("%s tracks both %s and %s",
- ref_map->peer_ref->name,
- (*posn)->name, ref_map->name);
- next = (*posn)->next;
- free((*posn)->peer_ref);
- free(*posn);
- *posn = next;
- } else {
- posn = &(*posn)->next;
- }
+
+ item = string_list_lookup(ref_map->peer_ref->name, &refs);
+ if (item) {
+ if (strcmp(((struct ref *)item->util)->name,
+ ref_map->name))
+ die("%s tracks both %s and %s",
+ ref_map->peer_ref->name,
+ ((struct ref *)item->util)->name,
+ ref_map->name);
+ prev->next = ref_map->next;
+ free(ref_map->peer_ref);
+ free(ref_map);
}
+
+ item = string_list_insert(ref_map->peer_ref->name, &refs);
+ item->util = ref_map;
+ prev = ref_map;
}
+ string_list_clear(&refs, 0);
}
int remote_has_url(struct remote *remote, const char *url)
--
1.6.5.rc2
^ permalink raw reply related
* Re: Any way to "flatten" a series of changes in git
From: Howard Miller @ 2009-10-22 21:11 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <m3hbtrdu1r.fsf@localhost.localdomain>
> You can use either "git merge --squash" or "git rebase --interactive"
> (changing 'pick' to 'squash').
>
Actually thinking some more.... I don't understand something about
this. I don't actually want to merge or rebase with anything. I just
want to say "make those commits a series of commits on a branch into
just one commit with a new message". I seriously suspect I'm missing
the point somewhere but what has that got to do with merging or
rebasing?
Thanks again
^ permalink raw reply
* Re: Any way to "flatten" a series of changes in git
From: Jakub Narebski @ 2009-10-22 20:59 UTC (permalink / raw)
To: Howard Miller; +Cc: git
In-Reply-To: <26ae428a0910221303n493fb7s701269d694110685@mail.gmail.com>
Howard Miller <howard@e-learndesign.co.uk> writes:
> I have a branch with a whole series of commits. I want to export this
> work to be customer (to their svn repo if that has any bearing on it).
> All the stuff in the history is irrelevant to my customer ("committing
> now, going to bed" etc.) so I'd like to create a new branch that only
> has one commit.. the end point with a new message. Is this possible?
You can use either "git merge --squash" or "git rebase --interactive"
(changing 'pick' to 'squash').
--
Jakub Narebski
Poland
ShadeHawk on #git
^ permalink raw reply
* Re: Any way to "flatten" a series of changes in git
From: Howard Miller @ 2009-10-22 20:58 UTC (permalink / raw)
To: Jacob Helwig; +Cc: Bill Lear, git
In-Reply-To: <8c9a060910221351w12e6c610kb842263e1c02ea63@mail.gmail.com>
>
> Alternatively, you could use git merge --squash
>
> git checkout master
> git merge --squash topic
>
> See git-merge(1) for details.
>
> rebase --interactive it excellent for cleaning up history, especially
> if you want to end up with more than one commit at the end. merge
> --squash is usually sufficient if all you need is one commit at the
> end.
>
Brilliant, thanks everybody!! I'll go and back up my database and have
a play with these options.
^ permalink raw reply
* Re: Any way to "flatten" a series of changes in git
From: Jacob Helwig @ 2009-10-22 20:51 UTC (permalink / raw)
To: Bill Lear; +Cc: Howard Miller, git
In-Reply-To: <19168.50232.47935.864407@lisa.zopyra.com>
On Thu, Oct 22, 2009 at 13:44, Bill Lear <rael@zopyra.com> wrote:
> On Thursday, October 22, 2009 at 15:30:53 (-0500) Bill Lear writes:
>>On Thursday, October 22, 2009 at 21:03:44 (+0100) Howard Miller writes:
>>>Hello,
>>>
>>>I have a branch with a whole series of commits. I want to export this
>>>work to be customer (to their svn repo if that has any bearing on it).
>>>All the stuff in the history is irrelevant to my customer ("committing
>>>now, going to bed" etc.) so I'd like to create a new branch that only
>>>has one commit.. the end point with a new message. Is this possible?
>>
>>git rebase is your friend.
>
> Someone correct me if I'm wrong.
>
> % git branch
> * master
> % git checkout -b my_work_branch
> % [work work work, commit, commit, commit]
> % git rebase -i master
>
Alternatively, you could use git merge --squash
git checkout master
git merge --squash topic
See git-merge(1) for details.
rebase --interactive it excellent for cleaning up history, especially
if you want to end up with more than one commit at the end. merge
--squash is usually sufficient if all you need is one commit at the
end.
^ permalink raw reply
* Re: Any way to "flatten" a series of changes in git
From: Bill Lear @ 2009-10-22 20:44 UTC (permalink / raw)
To: Howard Miller, git
In-Reply-To: <19168.49405.775024.649626@lisa.zopyra.com>
On Thursday, October 22, 2009 at 15:30:53 (-0500) Bill Lear writes:
>On Thursday, October 22, 2009 at 21:03:44 (+0100) Howard Miller writes:
>>Hello,
>>
>>I have a branch with a whole series of commits. I want to export this
>>work to be customer (to their svn repo if that has any bearing on it).
>>All the stuff in the history is irrelevant to my customer ("committing
>>now, going to bed" etc.) so I'd like to create a new branch that only
>>has one commit.. the end point with a new message. Is this possible?
>
>git rebase is your friend.
Someone correct me if I'm wrong.
% git branch
* master
% git checkout -b my_work_branch
% [work work work, commit, commit, commit]
% git rebase -i master
You'll then get an editor buffer that looks like this:
pick 16730c6 baz 0
pick 2a844e7 baz 1
pick d6e71dc baz 2
pick d1a6995 baz 3
pick 157e675 baz 4
# Rebase ef0a89e..157e675 onto ef0a89e
#
# Commands:
# p, pick = use commit
# e, edit = use commit, but stop for amending
# s, squash = use commit, but meld into previous commit
#
# If you remove a line here THAT COMMIT WILL BE LOST.
# However, if you remove everything, the rebase will be aborted.
#
Edit this to keep what you need:
pick 16730c6 baz 0
squash 2a844e7 baz 1
squash d6e71dc baz 2
squash d1a6995 baz 3
squash 157e675 baz 4
then exit the editor. It'll pop you in another editor session to
type in a commit message for these, just type in what you need and
exit and you'll have the new commit with all the olds ones squashed
into it.
Bill
^ permalink raw reply
* Detached HEAD and "git log --all"
From: Jakub Narebski @ 2009-10-22 20:37 UTC (permalink / raw)
To: git
When discussing differences between concept and implementation
of branches in Git and in Mercurial on StackOverflow[1] (abusing
SO comment system a bit), Steve Losh[2] wrote that he was surprised
by the fact that "git log --all" doesn't include commits made
on detached HEAD.
While documentation clearly states:
--all Pretend as if all the refs in `$GIT_DIR/refs/` are listed
on the command line as <commit>.
and HEAD is in `$GIT_DIR/HEAD`, which is outside `$GIT_DIR/refs/`,
it is nevertheless a bit strange that "git log --all" doesn't list
all (everything).
This is of course only an issue if we are on detached HEAD; I guess
that semantics of `--all` option to git-log predates this feature.
[1] http://stackoverflow.com/questions/1598759/git-and-mercurial-compare-and-contrast/1599930#1599930
[2] http://stevelosh.com/blog/entry/2009/8/30/a-guide-to-branching-in-mercurial/
--
Jakub Narębski http://stackoverflow.com/users/46058/jakub-narebski
^ permalink raw reply
* requesting info page (and pdf) doc releases
From: Sebastian Pipping @ 2009-10-22 20:41 UTC (permalink / raw)
To: git
hi there!
would be nice to get info pages (and pdf) doc releases in addition to
html and man pages. i imagine such a change to the release machine
should not be too hard to integrate. we could use it in gentoo.
thanks,
sebastian
^ permalink raw reply
* Re: [RFC PATCH v3 00/17] Return of smart HTTP
From: Marcus Camen @ 2009-10-22 19:48 UTC (permalink / raw)
To: git
In-Reply-To: <ca433830910161604g5a6bde76n26eb2b1e8155fb36@mail.gmail.com>
On Samstag 17 Oktober 2009, Mark Lodato wrote:
> I just realized I forgot to say something in my last email: THANK
> YOU!!! I have been looking forward to this for a long time. I was
> planning to one day to sit down and start thinking about how to
> implement a smart protocol, and then I see a post saying that not only
> has someone figured out the protocol, but he has implemented it!
> Amazing! This is really crucial for corporate adoption, at least at
> my job. We need to have strong authentication for many users, and the
> SSH key management is just a nightmare, not to mention that not all
> users can SSH due to firewalls. This will save me so much time and
> frustration. Thanks!
As I am using git in a corporate environment I couldn't agree more. smart-
http definitely is the most import addition to git in the last months.
So far I didn't carry out extensive production runs but my first tests
already showed that the smart-http backend solves many problems we have
with the dumb webdav approach (no hooks, insane amount of http requests,
slow performance, ...).
As I have a systems engineer (not a C coder) perspective on git I cannot
comment an any possible glitches of this implementation. I just want to
make sure that everyone recognizes just how import smart-http is for
corporate environments and that the current patch already solves a lot of
problems.
Regards,
Marcus
^ permalink raw reply
* Re: Updating a branch.
From: Tim Henigan @ 2009-10-22 20:31 UTC (permalink / raw)
To: elyod72; +Cc: git
In-Reply-To: <26015707.post@talk.nabble.com>
On Thu, Oct 22, 2009 at 3:21 PM, elyod72 <elyod72@gmail.com> wrote:
>
> I am a newbie to git, so please bear with me.
> Here is the scenario that I am struggling with:
>
> I have my Master branch.
> I then create a new branch named Test.
> I then make changes and additions to the test branch.
> At the same time I make changes to the Master branch.
> Now I want to update the Test branch with the latest information from the
> Master branch.
>
> How do I go about doing that?
In general, the following is recommended:
1) If possible, complete your work on the Test branch without merging
the changes. Save your merge (and any potential conflict resolution)
for when the Test branch is complete and fully tested.
2) If Test absolutely requires the changes made in Master, then perform
a "git rebase master" from your Test branch. This operation replays
the commits you have made to Test on top of your latest commit to
Master.
See the gitworkflows man page [1] for further information. The section on
"Topic Branches" should be helpful.
This post [2] on StackOverflow has some helpful info as well.
-Tim
[1] http://www.kernel.org/pub/software/scm/git/docs/gitworkflows.html
[2] http://stackoverflow.com/questions/457927/git-workflow-and-rebase-vs-merge-questions
^ 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