* Re: git fetch,git merge and git rebase
From: Alexey Shumkin @ 2011-02-10 7:25 UTC (permalink / raw)
To: git
In-Reply-To: <1297315789338-6010561.post@n2.nabble.com>
> I am new to git .Can someone explain in simple terms what git fetch,git
> merge and git rebase do?..I tried googling but was very confused after going
> thro it.
and also https://git.wiki.kernel.org/index.php/GitFaq
^ permalink raw reply
* Re: "git add -u" broken in git 1.7.4?
From: Johannes Sixt @ 2011-02-10 7:46 UTC (permalink / raw)
To: Jeff King
Cc: Junio C Hamano, SZEDER Gábor, Matthieu Moy,
Sebastian Pipping, Git ML
In-Reply-To: <20110209234621.GA12575@sigill.intra.peff.net>
Am 2/10/2011 0:46, schrieb Jeff King:
> The current behavior is:
>
> add: error (and suggest "git add .")
> add -u: relative
> add -A: relative
> add -i: full-tree
> add -p: full-tree
> archive: relative
> checkout: full-tree (e.g., "git checkout -f")[1]
> checkout-index: n/a (only checks out arguments)
> clean: relative
> commit -a: full-tree[2]
> diff: full-tree
> diff-files: full-tree
> grep: relative
> ls-files: relative
> ls-tree: relative[3]
> status: shows full-tree, relative by default, absolute
> with status.relativePaths
> reset --hard: full-tree[4]
> log/show/etc: full-tree[5]
> blame: error[6]
rerere forget: relative
It is a destructive command, and the rerere cache is precious, IMO.
Therefore, I'd vote to make 'git rerere forget' without a pathspec an error.
-- Hannes
^ permalink raw reply
* Re: "git add -u" broken in git 1.7.4?
From: Joshua Juran @ 2011-02-10 8:13 UTC (permalink / raw)
To: Jeff King
Cc: Junio C Hamano, SZEDER Gábor, Matthieu Moy,
Sebastian Pipping, Git ML
In-Reply-To: <20110209234621.GA12575@sigill.intra.peff.net>
On Feb 9, 2011, at 3:46 PM, Jeff King wrote:
> The current behavior is:
>
> add: error (and suggest "git add .")
> add -u: relative
> add -A: relative
> add -i: full-tree
> add -p: full-tree
add -e: full-tree
Josh
^ permalink raw reply
* Re: git fetch,git merge and git rebase
From: Jonathan Nieder @ 2011-02-10 8:22 UTC (permalink / raw)
To: Alexey Shumkin; +Cc: git, Akash
In-Reply-To: <loom.20110210T082201-996@post.gmane.org>
Alexey Shumkin wrote:
> Akash writes:
>> I am new to git .Can someone explain in simple terms what git fetch,git
>> merge and git rebase do?..I tried googling but was very confused after going
>> thro it.
>>
>> Also, can someone prescribe a link which explains git in detail right from
>> scratch.
>
> RFTM, with all respect ))
> http://progit.org/book/
More hints:
- "man git" (or "git help git") has some hints to get started:
. a tutorial
. a list of "everyday git" commands to get going
. a short article on centralized, cvs-style workflow
. a user's manual
- when anything is unclear in those documents, I will be very happy
to learn about it (so cc me in that case :)). Please be specific
as possible about what is confusing.
- people on this mailing list and the #git channel on freenode are
generally happy to help if you are trying to do something
specific (or have some other specific question).
- there's much material on the web in addition to what's mentioned
above. For example the old git crash course for svn users at
http://git.or.cz/course/svn.html taught me a lot about both git and
svn. Theoretically, good material from a variety of sources can
gradually flow into the user's manual and reference manual pages,
though actual practice does not always match that theory.
Good luck.
Kind regards,
Jonathan
^ permalink raw reply
* [PATCH] compat: helper for detecting unsigned overflow
From: Jonathan Nieder @ 2011-02-10 9:35 UTC (permalink / raw)
To: git
Cc: Erik Faye-Lund, Jeff King, Nicolas Pitre, Pierre Habouzit,
Ilari Liusvaara
In-Reply-To: <1286263450-5372-1-git-send-email-kusmabite@gmail.com>
Date: Sun, 10 Oct 2010 21:59:26 -0500
The idiom (a + b < a) works fine for detecting that an unsigned
integer has overflowed, but a more explicit
unsigned_add_overflows(a, b)
might be easier to read.
Define such a macro, expanding roughly to ((a) < UINT_MAX - (b)).
Because the expansion uses each argument only once outside of sizeof()
expressions, it is safe to use with arguments that have side effects.
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
---
From the svn remote helper project. Sane?
git-compat-util.h | 6 ++++++
patch-delta.c | 2 +-
strbuf.c | 5 +++--
wrapper.c | 2 +-
4 files changed, 11 insertions(+), 4 deletions(-)
diff --git a/git-compat-util.h b/git-compat-util.h
index d6d269f..9c23622 100644
--- a/git-compat-util.h
+++ b/git-compat-util.h
@@ -31,6 +31,9 @@
#define maximum_signed_value_of_type(a) \
(INTMAX_MAX >> (bitsizeof(intmax_t) - bitsizeof(a)))
+#define maximum_unsigned_value_of_type(a) \
+ (UINTMAX_MAX >> (bitsizeof(uintmax_t) - bitsizeof(a)))
+
/*
* Signed integer overflow is undefined in C, so here's a helper macro
* to detect if the sum of two integers will overflow.
@@ -40,6 +43,9 @@
#define signed_add_overflows(a, b) \
((b) > maximum_signed_value_of_type(a) - (a))
+#define unsigned_add_overflows(a, b) \
+ ((b) > maximum_unsigned_value_of_type(a) - (a))
+
#ifdef __GNUC__
#define TYPEOF(x) (__typeof__(x))
#else
diff --git a/patch-delta.c b/patch-delta.c
index d218faa..56e0a5e 100644
--- a/patch-delta.c
+++ b/patch-delta.c
@@ -48,7 +48,7 @@ void *patch_delta(const void *src_buf, unsigned long src_size,
if (cmd & 0x20) cp_size |= (*data++ << 8);
if (cmd & 0x40) cp_size |= (*data++ << 16);
if (cp_size == 0) cp_size = 0x10000;
- if (cp_off + cp_size < cp_size ||
+ if (unsigned_add_overflows(cp_off, cp_size) ||
cp_off + cp_size > src_size ||
cp_size > size)
break;
diff --git a/strbuf.c b/strbuf.c
index 9b3c445..07e8883 100644
--- a/strbuf.c
+++ b/strbuf.c
@@ -63,7 +63,8 @@ void strbuf_attach(struct strbuf *sb, void *buf, size_t len, size_t alloc)
void strbuf_grow(struct strbuf *sb, size_t extra)
{
- if (sb->len + extra + 1 <= sb->len)
+ if (unsigned_add_overflows(extra, 1) ||
+ unsigned_add_overflows(sb->len, extra + 1))
die("you want to use way too much memory");
if (!sb->alloc)
sb->buf = NULL;
@@ -152,7 +153,7 @@ int strbuf_cmp(const struct strbuf *a, const struct strbuf *b)
void strbuf_splice(struct strbuf *sb, size_t pos, size_t len,
const void *data, size_t dlen)
{
- if (pos + len < pos)
+ if (unsigned_add_overflows(pos, len))
die("you want to use way too much memory");
if (pos > sb->len)
die("`pos' is too far after the end of the buffer");
diff --git a/wrapper.c b/wrapper.c
index 55b074e..4c147d6 100644
--- a/wrapper.c
+++ b/wrapper.c
@@ -53,7 +53,7 @@ void *xmalloc(size_t size)
void *xmallocz(size_t size)
{
void *ret;
- if (size + 1 < size)
+ if (unsigned_add_overflows(size, 1))
die("Data too large to fit into virtual memory space.");
ret = xmalloc(size + 1);
((char*)ret)[size] = 0;
--
1.7.4
^ permalink raw reply related
* Re: [PATCH] compat: helper for detecting unsigned overflow
From: Sverre Rabbelier @ 2011-02-10 12:11 UTC (permalink / raw)
To: Jonathan Nieder
Cc: git, Erik Faye-Lund, Jeff King, Nicolas Pitre, Pierre Habouzit,
Ilari Liusvaara
In-Reply-To: <20110210093536.GB365@elie>
Heya,
On Thu, Feb 10, 2011 at 10:35, Jonathan Nieder <jrnieder@gmail.com> wrote:
> unsigned_add_overflows(a, b)
> Define such a macro, expanding roughly to ((a) < UINT_MAX - (b)).
> Because the expansion uses each argument only once outside of sizeof()
> expressions, it is safe to use with arguments that have side effects.
> +#define unsigned_add_overflows(a, b) \
> + ((b) > maximum_unsigned_value_of_type(a) - (a))
I'm confused, you say you won't use it twice, and then you do use it twice?
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* Re: [PATCH] compat: helper for detecting unsigned overflow
From: Joshua Juran @ 2011-02-10 13:23 UTC (permalink / raw)
To: Sverre Rabbelier
Cc: Jonathan Nieder, git, Erik Faye-Lund, Jeff King, Nicolas Pitre,
Pierre Habouzit, Ilari Liusvaara
In-Reply-To: <AANLkTinqkSxj0C+GyMVR4a7d=yy_mh+oDuar0moZjZ8_@mail.gmail.com>
On Feb 10, 2011, at 4:11 AM, Sverre Rabbelier wrote:
> On Thu, Feb 10, 2011 at 10:35, Jonathan Nieder <jrnieder@gmail.com>
> wrote:
>> unsigned_add_overflows(a, b)
>
>> Define such a macro, expanding roughly to ((a) < UINT_MAX - (b)).
>> Because the expansion uses each argument only once outside of
>> sizeof()
>> expressions, it is safe to use with arguments that have side effects.
>
>> +#define unsigned_add_overflows(a, b) \
>> + ((b) > maximum_unsigned_value_of_type(a) - (a))
>
> I'm confused, you say you won't use it twice, and then you do use it
> twice?
The author is asserting that maximum_unsigned_value_of_type() is a
function of sizeof a, which would have no runtime effect.
Josh
^ permalink raw reply
* Re: Advices to imlement update hook
From: Francis Moreau @ 2011-02-10 13:24 UTC (permalink / raw)
To: Jeff King; +Cc: Johannes Sixt, git
In-Reply-To: <20110209170535.GA5254@sigill.intra.peff.net>
Hello,
On Wed, Feb 9, 2011 at 6:05 PM, Jeff King <peff@peff.net> wrote:
> On Wed, Feb 09, 2011 at 05:51:24PM +0100, Francis Moreau wrote:
>
>> >>> git diff-tree <oldref> <newref> -- ^b || exit 1
>> >>>
>> >>> but it doesn't work.
>> >>
>> >> git diff-tree --quiet <oldref> <newref> -- b
>> >
>> > should do it; it sets the exit code.
>>
>> but does that work if a commit modify b/ and another directory ?
>
> No, it just looks for commits that modified b. There is currently no way
> to specify a path to say "commit that did not modify b". You need to
> check the output of:
>
> git rev-list | git diff-tree --stdin -m --name-only
>
> which should list all paths modified by all commits. And then you can
> either blacklist or whitelist as appropriate (note that the names can be
> quoted; you might want to look at the "-z" option and do your
> list-checking in perl).
>
>> > But don't you also want to inspect all commits between oldref and newref?
>>
>> Yes I want to inspect all commits in the range.
>
> see above.
>
>> > Someone could have modified the directory, and then reverted the
>> > modification in a later commit. If these commits arrive in a single push,
>> > the above code wouldn't notice this.
>>
>> I agree but I thought that git diff-tree would list all changes made
>> between the 2 refs.
>
> Between the two endpoints. It won't even look at the commits in the
> middle, so as long as a later middle commit reverts the change of an
> earlier middle commit, the endpoints won't be affected.
Oh, I see. I undestand why the git-rev-list is needed now.
Thanks for your help !
--
Francis
^ permalink raw reply
* Re: [PATCH] Support different branch layouts in git-p4
From: Pete Wyckoff @ 2011-02-10 13:43 UTC (permalink / raw)
To: Ian Wienand; +Cc: Tor Arvid Lund, git
In-Reply-To: <4D520E2B.2080200@vmware.com>
ianw@vmware.com wrote on Tue, 08 Feb 2011 19:46 -0800:
> So here's another version; I agree some testing would be good as I've
> only run it locally on //depot/proj/branch clients
This is good. Thanks for fixing it up. One last pedantic whine
from me. Fix the regex for the error case:
arf$ python
>>> import re
>>> re.match('\%\%d', "%%3")
>>> re.match(r'%%\d', "%%3")
>>> <_sre.SRE_Match object at 0x1ec4168>
-- Pete
> ---
>
> diff --git a/contrib/fast-import/git-p4 b/contrib/fast-import/git-p4
> index 04ce7e3..3304f36 100755
> --- a/contrib/fast-import/git-p4
> +++ b/contrib/fast-import/git-p4
> @@ -910,6 +910,22 @@ class P4Sync(Command):
> return files
>
> def stripRepoPath(self, path, prefixes):
> + if self.useClientSpec:
> +
> + # if using the client spec, we use the output directory
> + # specified in the client. For example, a view
> + # //depot/foo/branch/... //client/branch/foo/...
> + # will end up putting all foo/branch files into
> + # branch/foo/
> + for val in self.clientSpecDirs:
> + if path.startswith(val[0]):
> + # replace the depot path with the client path
> + path = path.replace(val[0], val[1][1])
> + # now strip out the client (//client/...)
> + path = re.sub("^(//[^/]+/)", '', path)
> + # the rest is all path
> + return path
> +
> if self.keepRepoPath:
> prefixes = [re.sub("^(//[^/]+/).*", r'\1', prefixes[0])]
>
> @@ -1032,7 +1048,7 @@ class P4Sync(Command):
> includeFile = True
> for val in self.clientSpecDirs:
> if f['path'].startswith(val[0]):
> - if val[1] <= 0:
> + if val[1][0] <= 0:
> includeFile = False
> break
>
> @@ -1475,19 +1491,45 @@ class P4Sync(Command):
> for entry in specList:
> for k,v in entry.iteritems():
> if k.startswith("View"):
> +
> + # p4 has these %%1 to %%9 arguments in specs to
> + # reorder paths; which we can't handle (yet :)
> + if re.match('\%\%d', v) != None:
> + print "Sorry, can't handle %%n arguments in client specs"
> + sys.exit(1)
> +
> if v.startswith('"'):
> start = 1
> else:
> start = 0
> index = v.find("...")
> +
> + # save the "client view"; i.e the RHS of the view
> + # line that tells the client where to put the
> + # files for this view.
> + cv = v[index+3:].strip() # +3 to remove previous '...'
> +
> + # if the client view doesn't end with a
> + # ... wildcard, then we're going to mess up the
> + # output directory, so fail gracefully.
> + if not cv.endswith('...'):
> + print 'Sorry, client view in "%s" needs to end with wildcard' % (k)
> + sys.exit(1)
> + cv=cv[:-3]
> +
> + # now save the view; +index means included, -index
> + # means it should be filtered out.
> v = v[start:index]
> if v.startswith("-"):
> v = v[1:]
> - temp[v] = -len(v)
> + include = -len(v)
> else:
> - temp[v] = len(v)
> + include = len(v)
> +
> + temp[v] = (include, cv)
> +
> self.clientSpecDirs = temp.items()
> - self.clientSpecDirs.sort( lambda x, y: abs( y[1] ) - abs( x[1] ) )
> + self.clientSpecDirs.sort( lambda x, y: abs( y[1][0] ) - abs( x[1][0] ) )
>
> def run(self, args):
> self.depotPaths = []
> diff --git a/contrib/fast-import/git-p4.txt b/contrib/fast-import/git-p4.txt
> index 49b3359..e09da44 100644
> --- a/contrib/fast-import/git-p4.txt
> +++ b/contrib/fast-import/git-p4.txt
> @@ -191,6 +191,11 @@ git-p4.useclientspec
>
> git config [--global] git-p4.useclientspec false
>
> +The P4CLIENT environment variable should be correctly set for p4 to be
> +able to find the relevant client. This client spec will be used to
> +both filter the files cloned by git and set the directory layout as
> +specified in the client (this implies --keep-path style semantics).
> +
> Implementation Details...
> =========================
>
>
^ permalink raw reply
* [PATCH, TopGit] tg-annihilate: Pass --no-verify when committing.
From: Thomas Schwinge @ 2011-02-10 13:39 UTC (permalink / raw)
To: ceder, u.kleine-koenig, git; +Cc: Thomas Schwinge
This is needed in order to inhibit TopGit's pre-commit hook to run,
which would bark upon missing .top* files.
---
Hallo!
(Yeah, I'm still using TopGit for some things.) I needed the following
patch to make tg annihilate work if the base is a non-TopGit branch. Is
this the correct approach?
Grüße,
Thomas
tg-annihilate.sh | 4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/tg-annihilate.sh b/tg-annihilate.sh
index 219b8fe..89d192c 100644
--- a/tg-annihilate.sh
+++ b/tg-annihilate.sh
@@ -34,7 +34,9 @@ baserev="$(git rev-parse --verify "refs/top-bases/$name" 2>/dev/null)" ||
## Annihilate
mb="$(git merge-base "refs/top-bases/$name" "$name")"
git read-tree "$mb^{tree}"
-git commit -m"TopGit branch $name annihilated."
+# Need to pass --no-verify in order to inhibit TopGit's pre-commit hook to run,
+# which would bark upon missing .top* files.
+git commit --no-verify -m"TopGit branch $name annihilated."
info 'If you have shared your work, you might want to run `tg push` now.'
info 'Then you probably want to switch to another branch.'
--
1.7.1
^ permalink raw reply related
* Challenges for an octopus merge
From: Markus Elfring @ 2011-02-10 14:30 UTC (permalink / raw)
To: git
Hello,
I have got an update history like the following in a local repository with ten
patches in separate topic branches on my openSUSE 11.3 system.
master -> tag: v3.0 -> compilation_maintenance
/-> errno => C1
/-> braces => C2
/-> string => C3
/-> binary_search => C4
-> route1 ---> temporary_files => C5
\-> make_functions_static => C6
\-> const-correctness => C7
\-> signal_handling => C8
\-> enum => C9
\-> double_declaration_deletion => C10
elfring@Sonne:~/Projekte/BtYacc/lokal2> git --version && git checkout -b test3
git version 1.7.3.4
Switched to a new branch 'test3'
elfring@Sonne:~/Projekte/BtYacc/lokal2> git merge --no-ff --stat --verbose --log
-m 'Combination of six topics' errno braces string binary_search temporary_files
make_functions_static
Fast-forwarding to: errno
Trying simple merge with braces
Trying simple merge with string
Trying simple merge with binary_search
Trying simple merge with temporary_files
Simple merge did not work, trying automatic merge.
Auto-merging defs.h
Trying simple merge with make_functions_static
Simple merge did not work, trying automatic merge.
Auto-merging defs.h
ERROR: content conflict in defs.h
Auto-merging main.c
Auto-merging mkpar.c
fatal: merge program failed
Automatic merge failed; fix conflicts and then commit the result.
The merge description (suggested commit message) was fine in the display of the
tool "Git GUI 0.13.0" (Tcl/Tk version 8.5.8).
I delete the conflict section in the header file "defs.h" completely.
elfring@Sonne:~/Projekte/BtYacc/lokal2> git merge --no-ff --stat --verbose --log
-m 'Combination of four topics' const-correctness double_declaration_deletion
enum signal_handling
Trying simple merge with const-correctness
Simple merge did not work, trying automatic merge.
Auto-merging defs.h
Auto-merging output.c
Auto-merging reader.c
Trying simple merge with double_declaration_deletion
Simple merge did not work, trying automatic merge.
Auto-merging mkpar.c
ERROR: content conflict in mkpar.c
fatal: merge program failed
Automated merge did not work.
Should not be doing an Octopus.
Merge with strategy octopus failed.
The merge description was missing (no commit message) in this case.
Is this omission acceptable?
I have also got the impression that the corresponding source files did not
contain enough conflict markers.
Is my use case relevant for further considerations of details with this merging
process?
Regards,
Markus
^ permalink raw reply
* Re: Challenges for an octopus merge
From: Junio C Hamano @ 2011-02-10 16:09 UTC (permalink / raw)
To: Markus Elfring; +Cc: git
In-Reply-To: <4D53F694.1060105@web.de>
Markus Elfring <Markus.Elfring@web.de> writes:
> ...
> Automated merge did not work.
> Should not be doing an Octopus.
> Merge with strategy octopus failed.
>
>
> The merge description was missing (no commit message) in this case.
The second-to-last line of the output needs to be rephrased.
Octopus is not for recording conflicting merges and when it punts you
shouldn't be attempting to resolve and record it as an octopus merge.
^ permalink raw reply
* Question about git svn handling svn external
From: Hillel (Sabba) Markowitz @ 2011-02-10 16:44 UTC (permalink / raw)
To: git
I use a python script which calls git svn clone based on a text file
built from the svn externals of the form
dir1 url1
dir2 url2
to create a git project. Each subdirectory of course will have its own
.git and point back to the original svn repository so that I can
change a particular subdirectory.
For example, I have dirn from urln/trunk built and I want to change it
to urln/branches/mybranch.
Is there a good way of doing this without deleting everything under it?
If I wipe out the dirn directory, I would wipe out the externals that
came in with urln and I would have to pick up all the entries that
follow. I do not want to pick up the external pointer from svn as I
might not actually be using all of those. I want to only bring in the
entries from the configuration file. Of course, it would be more
useful if someone has already done it.
The project that I am on would like to use python for this, but if
someone has already written something, the language would not matter.
--
Sabba - סבא הלל - Hillel
Hillel (Sabba) Markowitz | Said the fox to the fish, "Join me ashore"
SabbaHillel@gmail.com | The fish are the Jews, Torah is our water
http://sabbahillel.blogspot.com
^ permalink raw reply
* Bug in "git diff-files"
From: Vampire @ 2011-02-10 17:56 UTC (permalink / raw)
To: git
Hi,
I found a bug in git diff-files.
git diff-files with a --diff-filter and --quiet given behaves bad.
I have a diff-filter of U and one file M and one U.
But diff-lib.c:105-107 in commit 1a9fe45 stops as soon as HAS_CHANGES is
true.
In my case it found the M file and stops searching as --quiet is given.
But then when applying the diff-filter, this M instance is filtered out
and thus 0 is returned instead of 1 which is returned with --exit-code
and without --quiet.
Regards
Björn Kautler
^ permalink raw reply
* Re: "git add -u" broken in git 1.7.4?
From: Matthieu Moy @ 2011-02-10 18:00 UTC (permalink / raw)
To: Jeff King; +Cc: Junio C Hamano, SZEDER Gábor, Sebastian Pipping, Git ML
In-Reply-To: <20110209234621.GA12575@sigill.intra.peff.net>
Jeff King <peff@peff.net> writes:
> I don't think it's worth moving ls-files/ls-tree. They're plumbing that
> people don't use frequently. So the cost of moving them is high (because
> we are breaking something meant to be scriptable) and the benefit is low
> (because users don't type them a lot).
Right. At some point, we may want to introduce a porcelain version of
"git ls-files", but we shouldn't change its default behavior.
> The archive behavior surprised me, and I would think it should be full-tree
> by default. But it is sort of plumbing-ish, in that people have probably
> scripted around and people _don't_ tend to create archives a lot.
Right. There are probably more calls to "git archive" in cron jobs and
web interface than directly from the command-line.
> That leaves clean. I would say from a consistency standpoint that it
> should go full-tree to match the other commands. But it is one of the
> most destructive commands, and making it full-tree makes it easier to
> accidentally delete, instead of accidentally fail to delete.
Agreed. That would be really bad surprise for an experience user to
upgrade Git, type "git clean -fdx" from a subdirectory, and to notice
the new behavior afterwards ;-).
> So depending on your view of the above, it may just be "add -u/-A" and
> "grep" that are worth switching.
Agreed.
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
^ permalink raw reply
* Re: Can't find the revelant commit with git-log
From: René Scharfe @ 2011-02-10 18:50 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Francis Moreau, git, Johannes Sixt
In-Reply-To: <7vk4hbsbjr.fsf@alter.siamese.dyndns.org>
Am 07.02.2011 23:51, schrieb Junio C Hamano:
> René Scharfe<rene.scharfe@lsrfire.ath.cx> writes:
>
>> diff --git a/t/t6016-rev-list-graph-simplify-history.sh b/t/t6016-rev-list-graph-simplify-history.sh
>> index f7181d1..50ffcf4 100755
>> --- a/t/t6016-rev-list-graph-simplify-history.sh
>> +++ b/t/t6016-rev-list-graph-simplify-history.sh
>> @@ -168,6 +168,7 @@ test_expect_success '--graph --full-history --simplify-merges -- bar.txt' '
>> echo "|\\ ">> expected&&
>> echo "| * $C4">> expected&&
>> echo "* | $A5">> expected&&
>> + echo "* | $A4">> expected&&
>> echo "* | $A3">> expected&&
>> echo "|/ ">> expected&&
>> echo "* $A2">> expected&&
>
> Thanks for a patch with a test; I am not sure if this is quite correct,
> though.
>
> A4 has three parents, C2, A3 and B2, and does not introduce any change
> with respect to bar.txt. A6 has bar.txt identical to that of A5, but we
> cannot omit it because we are showing its two parents (A5 and C4), and
> that is why we show it. A4 isn't even gets shown as a merge, so I don't
> understand why we need to show it?
Yes, this looks a bit silly on closer look. I thought that it matches
Francis' use case, but that's wrong -- having --simplify-merges instead
of -Sstring makes a difference, obviously.
After looking at the case again, I think I have a simpler solution: no
code change, just add --sparse (include all walked commits). This gives
the same results as the patched version:
$ git log --oneline -m --sparse --full-history \
-Sblacklist_iommu v2.6.26..v2.6.29 -- \
drivers/pci/intel-iommu.c | wc -l
160
Sorry for the noise.
So, the lesson would be: If you want to find commits that removed a
certain string in a certain set of files, add --full-history, -m and
--sparse to your "git log -Sstring -- files" command. This allows you
to catch merges that reverted those files to a state before the string
was introduced in the first place, otherwise history simplification can
hide them.
I'm not sure if there's a way to make the flags and their interactions
more intituitive.
René
^ permalink raw reply
* Re: [PATCH] Handle rename of case only, for Windows
From: Ramsay Jones @ 2011-02-10 18:58 UTC (permalink / raw)
To: Tim Abell; +Cc: git, Erik Faye-Lund, Nguyen Thai Ngoc Duy, msysGit
In-Reply-To: <1296344717.25999.1417928123@webmail.messagingengine.com>
[Sorry for the late reply to this... I'm somewhat backed-up!]
Tim Abell wrote:
>>From ddab003ede9f25d93f4e7eea833523a0aa29d16d Mon Sep 17 00:00:00 2001
> From: Tim Abell <tim@timwise.co.uk>
> Date: Thu, 27 Jan 2011 22:53:31 +0000
> Subject: [PATCH] Handle rename of case only, for Windows
This should not work with the MinGW or msvc build, since they *always* set
the st_ino to zero (see do_lstat() and mingw_fstat() in compat/mingw.c).
Also, *with default configuration*, it will also not work on cygwin... so
saying that this works on Windows may be overstating things a bit ... ;-)
[Hmm, I can't check, but it would probably work on Mac OS X ...]
> Added test to show rename failing in windows.
This fails for me. (er... just to be clear, test #30 fails with your patch
applied).
> Added test to show that this patch doesn't break protection against overwriting
> an existing file, and another to show that "mv --force" still works.
>
> Altered mv.c to check whether the source and destination file are actually
> the same file based on inode number before failing.
> If the inode is zero then the data is no use so old behaviour is maintained.
With default configuration, the st_ino will always be zero on cygwin. (see for
example the "schizophrenic l/stat() functions" commits adbc0b6, 7faee6b and
7974843, along with the "force core.filemode" commit c869753).
So, you must have core.filemode or core.ignorecygwinfstricks set somewhere in
your environment (in the system or global (user) config files?).
[I *always* set core.filemode after git-init or git-clone, so this patch may
actually work for me *in practice* (I haven't tested it), but I may well not
be a typical user...]
>> Hmm, not so good. st_ino is always 0 on Windows, so this would make
>> false positives, no?
>
> I tested this on windows 7 under cygwin (which is what I have available) and st_ino reports real numbers for me,
Again, you must have non-default configuration set...
ATB,
Ramsay Jones
^ permalink raw reply
* Re: Debugging Git push failure
From: Neal Kreitzinger @ 2011-02-10 19:06 UTC (permalink / raw)
To: Jeff Adamson; +Cc: git
In-Reply-To: <AANLkTimcGtDKZ2YU0Z_pc-aRtp-etXFWZ9-drSzpS3KN@mail.gmail.com>
On 2/9/2011 12:57 PM, Jeff Adamson wrote:
> Several developers on my team are experiencing an occasional failure
> during push. A subsequent push executed immediately afterward the
> failure will work fine. We are a small team of developers (about 10)
> and only a couple users seem to experience this and then only
> intermittently (every few days).
> This is happening on a LAN environment with otherwise reliable
> connectivity. We have some hook scripts for post-update and update
> configured within the repo.
>
> the server has git version 1.7.3.3 installed
> $ cat /etc/issue
> CentOS release 5.5 (Final)
> Kernel \r on an \m
> $ uname -a
> Linux core1.example.com 2.6.18-194.26.1.el5 #1 SMP Tue Nov 9 12:54:20
> EST 2010 x86_64 x86_64 x86_64 GNU/Linux
>
> Here is some output from one of the users during two sequential runs
> of `git push -v`. This user is git version 1.7.3.1.msysgit.0 (though
> similar behavior has been seen by another user with version 1.7.0.4 on
> ubuntu 10.04 LTS)
>> git push -v
> Pushing to ssh://git.example.com/data/git/example/scratch/bdd/cssearch-mockup.git
> Counting objects: 9, done.
> Delta compression using up to 8 threads.
> Compressing objects: 100% (5/5), done.
> Writing objects: 100% (5/5), 505 bytes, done.
> Total 5 (delta 4), reused 0 (delta 0)
> fatal: The remote end hung up unexpectedly
> fatal: The remote end hung up unexpectedly
>> git push -v
> Pushing to ssh://git.example.com/data/git/example/scratch/bdd/cssearch-mockup.git
> Counting objects: 9, done.
> Delta compression using up to 8 threads.
> Compressing objects: 100% (5/5), done.
> Writing objects: 100% (5/5), 505 bytes, done.
> Total 5 (delta 4), reused 0 (delta 0)
> To ssh://git.example.com/data/git/example/scratch/bdd/cssearch-mockup.git
> bffa1a7..8fd772d master -> master
>
>
> Anyone know what could be causing this and, just as important, how to
> debug it and issues like it in the future?
> Thanks for any help/insight which can be offered.
> --Jeff
I don't use ssh, but I use the git:// protocol and have also had push
errors locally. I run RHEL and when I get errors with git protocol I
check /var/log/messages. Find out where your log messages are going and
check them. You could also check permissions on the destination repo.
Look at its object store recursively, ie. .git/objects/, and do "ls -la"
to see the permissions. People could be pushing stuff up with the wrong
permissions and then someone else can't get to it. Just some ideas...
v/r,
Neal
^ permalink raw reply
* Re: Adding default remotes to a bare repository
From: Neal Kreitzinger @ 2011-02-10 19:08 UTC (permalink / raw)
To: Francis Moreau; +Cc: git
In-Reply-To: <AANLkTikVtSFs+qRiWJwxre8urOJs7q2HXBGPZkiTmn=i@mail.gmail.com>
On 2/9/2011 10:53 AM, Francis Moreau wrote:
> Hi,
>
> Is it possible to add some default remotes for a given repository ?
>
> That is when cloning the repository, I can use the default remotes in
> the cloned repository.
>
> Thanks
You could write a script that does the clone and then adds the remotes.
We have a "menu" written in bash scripts and it does the clones and
adds the default remotes automatically. So instead of just doing "git
clone", people would run that script to do the clone and add the remotes.
v/r,
Neal
^ permalink raw reply
* Re: [1.8.0] Remove deprecated commands
From: René Scharfe @ 2011-02-10 19:42 UTC (permalink / raw)
To: Jonathan Nieder; +Cc: Junio C Hamano, git
In-Reply-To: <20110202005748.GA13803@elie>
Am 02.02.2011 01:57, schrieb Jonathan Nieder:
>> git-lost-found 2007-11-08 git fsck --lost-found
>
> It can stay in contrib/examples for inspiration.
Sure.
>> git-peek-remote 2007-11-24 git ls-remote
>
> No one seems to be using it
> (github.com/gitpan/App-GitHub-FindRepository.git uses it as a fallback
> when ls-remote is not present).
How did you search for current usage? How comprehensive are the results?
>> git-repo-config 2008-01-17 git config
>
> giggle[1] still uses it --- see libgiggle-git/giggle-git-config-read.c
> and giggle-git-config-write.c.
>
> Likewise darcs2git[2] and the stgit testsuite.
>
> webkit's VCSUtils.pm only uses repo-config as a fallback when git
> config is not present.
Well, the release notes for 1.5.4 promised that the "next feature
release will remove it". Perhaps notifying the developers of the
projects you discovered is enough?
That said, the benefit for final removal of this command, which is
effectively just an alias, is the smallest of the four.
>> git-tar-tree 2007-11-08 git archive
>
> Already prints a deprecation notice. WWW::PkgFind from CPAN uses it
> but doesn't seem to be maintained.
>
> pilgrim[3] uses tar-tree in its "make dist" target. I wouldn't be
> surprised if some other projects use it in a similar way.
Possibly, and this shows that deprecation warnings don't fully solve the
problem of educating users to switch to the replacements.
I think it's relatively safe to remove the command anyway because the
users in this case are developers and packagers, i.e. the ones who put
the command in the Makefile in the first place. They should be able to
cope easily.
René
^ permalink raw reply
* Re: git fetch,git merge and git rebase
From: Neal Kreitzinger @ 2011-02-10 20:00 UTC (permalink / raw)
To: Akash; +Cc: git
In-Reply-To: <1297315789338-6010561.post@n2.nabble.com>
On 2/9/2011 11:29 PM, Akash wrote:
>
> Hi,
>
> I am new to git .Can someone explain in simple terms what git fetch,git
> merge and git rebase do?..I tried googling but was very confused after going
> thro it.
>
> Also, can someone prescribe a link which explains git in detail right from
> scratch.
>
>
git fetch: retrieve the latest version of a branch and store it in the
/remotes/* "remote tracking branches" of your local repo. you can view
these branches with "git branch -a". Once you have that local copy, you
can merge it into other branches, checkout objects from it, and run
diffs against it. You are not supposed to EVER make commits on a
remote/* branch. its sole purpose in life is to maintain an image the
the corresponding branchs that its tracking in the remote repo. you
update that image by performing git fetch. see man-page for details.
git merge: merges branch(s) into your current branch. see man-page for
details. lots and lots of details...
git rebase: takes all the local commits you've made on an old history
and rewrites them on-top of the new history. it makes it look like you
did your work based on the new history instead of the old history. it
keeps your history 'linear' instead of having all these merge DAG's in
your history like git-merge produces. see man page for details. lots
and lots of details are not easy to understand at first...
hope this helps.
v/r,
neal
^ permalink raw reply
* Re: [1.8.0] Remove deprecated commands
From: Jonathan Nieder @ 2011-02-10 20:56 UTC (permalink / raw)
To: René Scharfe; +Cc: Junio C Hamano, git
In-Reply-To: <4D543FB4.1040709@lsrfire.ath.cx>
René Scharfe wrote:
> How did you search for current usage? How comprehensive are the results?
By searching for "peek-remote" at http://www.google.com/codesearch
I tried to check out all hits that weren't just enumerating git
commands, but that doesn't rule out unindexed or non-public use.
No interesting hits.
But that's pretty weird, given that there was no deprecation
notice, nor anything else to encourage a transition.
*checks history*
Ah, peek-remote and ls-remote seem to have been introduced at the same
time. ls-remote could use all git-supported protocols, while
peek-remote could only use git protocol. So very few people had
reason to use peek-remote, anyway.
> Am 02.02.2011 01:57, schrieb Jonathan Nieder:
>>> git-repo-config 2008-01-17 git config
>>
>> giggle[1] still uses it
[...]
>> Likewise darcs2git[2] and the stgit testsuite.
[...]
> Well, the release notes for 1.5.4 promised that the "next feature
> release will remove it". Perhaps notifying the developers of the
> projects you discovered is enough?
The list is probably not exhaustive. On the bright side, repo-config
tends to be run in user-visible contexts, so I think a deprecation
notice could be effective.
> That said, the benefit for final removal of this command, which is
> effectively just an alias, is the smallest of the four.
After adding a deprecation notice and filing some bugs, I think we
can forget about it and wait another year. ;-)
>>> git-tar-tree 2007-11-08 git archive
[...]
>> pilgrim[3] uses tar-tree in its "make dist" target. I wouldn't be
>> surprised if some other projects use it in a similar way.
>
> Possibly, and this shows that deprecation warnings don't fully solve
> the problem of educating users to switch to the replacements.
>
> I think it's relatively safe to remove the command anyway because
> the users in this case are developers and packagers
I agree. The remaining users look like holdouts that will be hard to
get at by other means.
^ permalink raw reply
* Re: [1.8.0] Remove deprecated commands
From: Junio C Hamano @ 2011-02-10 21:08 UTC (permalink / raw)
To: Jonathan Nieder; +Cc: René Scharfe, git
In-Reply-To: <20110210205620.GD21144@elie>
Jonathan Nieder <jrnieder@gmail.com> writes:
> Ah, peek-remote and ls-remote seem to have been introduced at the same
> time. ls-remote could use all git-supported protocols, while
> peek-remote could only use git protocol.
Yes, peek-remote was a backend for ls-remote, just like http-fetch was one
of the backends for fetch.
^ permalink raw reply
* Using Origin hashes to improve rebase behavior
From: John Wiegley @ 2011-02-10 21:13 UTC (permalink / raw)
To: git
The following proposal is a check to see if this approach would be sane and
whether someone is already doing similar work. If not, I offer to implement
this solution.
THE PROBLEM
Say I have a master from which I have branched locally, and that this private
branch has four commits:
a b c
o---o---o
\
o---o---o---o
1 2 3 4
I then decide to cherry pick commit 3 onto master. Please believe that my
situation is such that I cannot immediately rebase the private branch to drop
the now-duplicated change. I end up with this:
a b c 3'
o---o---o---o
\
o---o---o---o
1 2 3 4
Later, there is work on master which changes the same lines of code that 3'
has changed. The commit which changes 3' is e*
a b c 3' d e* f
o---o---o---o---o---o---o
\
o---o---o---o
1 2 3 4
At a later date, I want to rebase the private branch onto master. What will
happen is that the changes in 3 will conflict with the rewritten changes in
e*. However, I'd like Git to know that 3 was already incorporated at some
earlier time, and *not consider it during the rebase*, since it doesn't need
to.
THE SOLUTION
For the purposes of this discussion, I'd like to define the term "aggregate
identity" (insert better name here) as a set including: a commit's sha, and
zero or more shas stored in a new field named "Origin-Ids".
If, when cherry-picking, the originating's commit id is stored in the
Origin-Ids field of the cherry-picked commit, then rebase could know whether a
given commit's changes had already been applied. The logic would look like
this:
1. When rebasing a branch A onto B, find the common ancestor of A and B.
2. Examine every commit on B since that common ancestor, collecting a
set of their aggregate identities.
3. For each commit on A, ignore it if its aggregate identity occurs in
that set.
This would cause commit 3 to be ignored during the rebase above, since 3'
would have an origin id referring to 3.
IMPLEMENTATION
A few things need to be done:
- Extend commit objects to have an Origin field, which can be zero, one or a
list of hashes.
- Add an option to git commit so that one or more origin ids can be specified
at the time any commit is made. There may be occasions when it's useful to
explicitly state that a new commit should somehow 'override' the contents
of another during a rebase.
- git cherry-pick and git am should add this Origin field, showing the commit
their contents originated from.
- git merge --squash would store the commit ids, and the origin ids, of every
commit involved in the merge into the resulting commit's Origin field.
Note that nothing can be done about rebasing a squashed merge commit onto
another squashed merge commit, even though it could be detected that they
had common changes. I don't believe it would even be useful to warn about
this, the user would just have to resolve the conflicts manually.
- git log could be extended to show the "parentage" (really, the aunt/uncle)
of commits with origin info, assuming those origin commits are not dangling
(which is OK, and likely to occur after the originating branch is deleted,
or if the originating branch is in another repository).
Where there are multiple Origin ids, a search could be done to find the set
of most descendent commits, so that history could be usefully shown after
an octopus squash, for example.
QUESTIONS
Is it allowable to add new metadata fields to a commit, and would this require
bumping the repository version number? Or should this be implemented by
appending a Header-style textual field at the end of the commit message?
--
John Wiegley
BoostPro Computing
http://www.boostpro.com
^ permalink raw reply
* Re: Adding default remotes to a bare repository
From: Francis Moreau @ 2011-02-10 21:24 UTC (permalink / raw)
To: Neal Kreitzinger; +Cc: git
In-Reply-To: <4D5437C4.6000401@gmail.com>
On Thu, Feb 10, 2011 at 8:08 PM, Neal Kreitzinger
<nkreitzinger@gmail.com> wrote:
>
> You could write a script that does the clone and then adds the remotes. We
> have a "menu" written in bash scripts and it does the clones and adds the
> default remotes automatically. So instead of just doing "git clone", people
> would run that script to do the clone and add the remotes.
>
Sure.
But I'm wondering why cloning operation can't import the remote
branches of the cloned repository.
Actually I'm wondering the same thing for hooks. If a repository setup
some hooks, can't these hooks be installed by default in the new
repositories ?
--
Francis
^ 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