On Jul 2, 2013, at 09:55, Andreas Schwab wrote:
Kyle McKay mack...@gmail.com writes:
Do you feel that it's important to accept these alternate URL
versions
that are not listed on the project page:
1) Optional trailing '/'
2) For the ssh scp form, optional leading '/'
3) Optional trailing
On Tue, Jul 02, 2013 at 04:53:48PM -0700, Brandon Casey wrote:
From: Brandon Casey draf...@gmail.com
When pushing, each ref in the local repository must be paired with a
ref advertised by the remote server. Currently, this is performed by
first applying the refspec to the local ref to
On Wed, Jul 3, 2013 at 12:55 AM, Johan Herland jo...@herland.net wrote:
I assume that in most cases the expected value of the remote ref would
equal the current value of the corresponding remote-tracking ref in
the user's repo, so why not use that as the default expected value?
E.g.:
$ git
Am 03.07.2013 01:26, schrieb Chris Packham:
On Wed, Jul 3, 2013 at 4:56 AM, Jens Lehmann jens.lehm...@web.de wrote:
Am 02.07.2013 12:12, schrieb Chris Packham:
--- a/Documentation/git-submodule.txt
+++ b/Documentation/git-submodule.txt
@@ -159,7 +159,9 @@ update::
This will make the
As I've mentioned before on the list, I don't use git-send-email, but
rather a home-grown script that interacts more closely with my regular
MUA. After embarrassing myself on multiple occasions by its inability
to automatically handle sending patches by other authors, I decided to
implement
In the current code, callers are expected to fill in the
pretty_print_context, and then the pretty.c functions simply
read from it. This leaves no room for the pretty.c functions
to communicate with each other by manipulating the context
(e.g., data seen while printing the header may impact how we
Format-patch generates emails with the From address set to
the author of each patch. If you are going to send the
emails, however, you would want to replace the author
identity with yours (if they are not the same), and bump the
author identity to an in-body header.
Normally this is handled by
On Wed, Jul 3, 2013 at 3:08 AM, Jeff King p...@peff.net wrote:
Format-patch generates emails with the From address set to
the author of each patch. If you are going to send the
emails, however, you would want to replace the author
identity with yours (if they are not the same), and bump the
Am 02.07.2013 23:42, schrieb Fredrik Gustafsson:
Add the --depth option to the add and update commands of git submodule,
which is then passed on to the clone command. This is useful when the
submodule(s) are huge and you're not really interested in anything but
the latest commit.
Tests are
On 03/07/13 18:55, Jens Lehmann wrote:
Am 03.07.2013 01:26, schrieb Chris Packham:
On Wed, Jul 3, 2013 at 4:56 AM, Jens Lehmann jens.lehm...@web.de wrote:
Am 02.07.2013 12:12, schrieb Chris Packham:
--- a/Documentation/git-submodule.txt
+++ b/Documentation/git-submodule.txt
@@ -159,7 +159,9
On 07/03/2013 12:21 AM, Junio C Hamano wrote:
Ramkumar Ramachandra artag...@gmail.com writes:
def get(self, name, default=''):
try:
values = self._split(read_git_output(
['config', '--get', '--null', '%s.%s' % (self.section,
name)],
Jens Lehmann jens.lehm...@web.de writes:
Am 02.07.2013 23:42, schrieb Fredrik Gustafsson:
Add the --depth option to the add and update commands of git submodule,
which is then passed on to the clone command. This is useful when the
submodule(s) are huge and you're not really interested in
Michael Haggerty mhag...@alum.mit.edu writes:
I would be happy to add the checking that you described, but I didn't
have the impression that it is the usual convention. Does code that
wants a single value from the config usually verify that there is
one-and-only-one value, or does it
On Wed, Jul 03, 2013 at 10:02:34AM +0200, Michael Haggerty wrote:
On 07/03/2013 12:21 AM, Junio C Hamano wrote:
Ramkumar Ramachandra artag...@gmail.com writes:
def get(self, name, default=''):
try:
values = self._split(read_git_output(
On Wed, Jul 03, 2013 at 09:29:02AM +0100, John Keeping wrote:
Doesn't git config --get return an error if there are multiple values?
The answer is apparently no - I wrote the text below from
git-config(1) and then checked the behaviour. This seems to be a
regression in git-config (bisect
On Wed, Jul 03, 2013 at 01:13:12AM -0700, Junio C Hamano wrote:
Jens Lehmann jens.lehm...@web.de writes:
The only minor problem is that this patch still does not apply cleanly
to master, next or pu (I wonder what you based this on ;-).
Thanks; will replace what I queued on 'pu'.
I based
On 03/07/13 19:54, Chris Packham wrote:
On a related note should I be updating Documentation/config.txt as well?
Even if it's a statement that this feature exists refer to
git-submodule(1) for details.
Answering my own question. While 'update' is mentioned it's possible
values are not.
--
Johan Herland jo...@herland.net writes:
Overnight, it occured to me that --force-if-expected could be
simplified by leveraging the existing --force option; for the above
two examples, respectively:
$ git push --force --expect
# validate foo @ origin == @{upstream} before pushing
and
Benoît Person benoit.per...@ensimag.fr writes:
Do we want to add that ':' unconditionally? Could GITPERLLIB be
empty?
For now, GITPERLLIB is only used in that kind of statements:
use lib (split(/:/, $ENV{GITPERLLIB} || ... ));
The trailing ':' does not really matter, split will ignore it.
Jeff King p...@peff.net writes:
However, doing it right is kind of tricky due to rfc822 quoting, rfc2047
encoding, and handling non-ascii names correctly. Instead, this patch
series takes a different approach: it teaches format-patch to do the
transformation itself, so that it can be used by
Users can set submodule.$name.update to '!command' which will cause
'command' to be run instead of checkout/merge/rebase. This allows the
user some finer grained control over how the update is done. The primary
motivation for this was interoperability with stgit however being able
to intercept
On Wed, Jul 03, 2013 at 01:58:22AM -0700, Junio C Hamano wrote:
Jeff King p...@peff.net writes:
However, doing it right is kind of tricky due to rfc822 quoting, rfc2047
encoding, and handling non-ascii names correctly. Instead, this patch
series takes a different approach: it teaches
Commit e83d36b66fc turned print STDOUT into print {*STDOUT}, as
suggested by perlcritic. Unfortunately, it also changed two binmode
STDOUT calls the same way, which does not work and yield a Not a GLOB
reference error.
Signed-off-by: Matthieu Moy matthieu@imag.fr
---
benoit.per...@ensimag.fr writes:
--- a/contrib/mw-to-git/t/test-gitmw-lib.sh
+++ b/contrib/mw-to-git/t/test-gitmw-lib.sh
@@ -62,12 +62,8 @@ test_check_precond () {
test_done
fi
- if [ ! -f $GIT_BUILD_DIR/git-remote-mediawiki ];
- then
- echo No
Ed Hutchins e...@demeterr.com writes:
I realize that branch names are ephemeral repo-specific things, but it
would be really useful to be able to determine what branch a commit
was authored from (as a hint to ancestry graph layout tools, for
example). Is there any way to do this currently, is
Fix a typo (remote remote-tracking) going back to the big cleanup
in 2010 (8b3f3f84 etc). Also, remove some more occurrences of
tracking and remote tracking in favor of remote-tracking.
Signed-off-by: Michael Schubert msc...@elegosoft.com
---
Documentation/git-p4.txt | 2 +-
For now, GITPERLLIB is only used in that kind of statements:
use lib (split(/:/, $ENV{GITPERLLIB} || ... ));
The trailing ':' does not really matter, split will ignore it.
That may be true with the current use, but For now leaves funny
taste, doesn't it?
definitely. For me, the issue was
On Wed, Jul 3, 2013 at 10:49 AM, Junio C Hamano gits...@pobox.com wrote:
Johan Herland jo...@herland.net writes:
Overnight, it occured to me that --force-if-expected could be
simplified by leveraging the existing --force option; for the above
two examples, respectively:
$ git push --force
On Mon, Jul 01, 2013 at 01:49:37PM -0400, Phil Hord wrote:
It would be nice to support more generic specs for the --branch
switch. But it is complicated because the refs have not been fetched
yet during the clone, and so normal refs operations -- which expect to
work on a local repository --
On Wed, Jul 3, 2013 at 11:12 AM, Michael Schubert msc...@elegosoft.com wrote:
Fix a typo (remote remote-tracking) going back to the big cleanup
in 2010 (8b3f3f84 etc). Also, remove some more occurrences of
tracking and remote tracking in favor of remote-tracking.
Signed-off-by: Michael
On Mon, Jul 1, 2013 at 6:20 PM, Junio C Hamano gits...@pobox.com wrote:
I am not sure if we should care that deeply about them in the first
place.
Fine by me; I don't really have a strong opinion on the matter.
Besides, I think you can make a hardlink to a file that you cannot
read.
Not
On Wed, Jul 3, 2013 at 12:06 PM, Jonathan del Strother
maill...@steelskies.com wrote:
I'm struggling to think of instances where I wouldn't want this
CAS-like behaviour. Wouldn't it be better to make it the default when
pushing, and allowing the current behaviour with git push
--blind-force
Michael Haggerty wrote:
On 07/02/2013 09:23 PM, Ramkumar Ramachandra wrote:
git_multimail.py wrote:
#! /usr/bin/env python2
Do all distributions ship it as python2 now?
No, but nor is python always Python version 2.x (I believe that Arch
Linux now installs Python 3 as python). This topic
Junio C Hamano wrote:
It is not nobody is working on, but it has already been used to
help the transision and served its purpose, and is no longer is very
useful for follow-up work because the majority of remaining matches
it finds are false positives.
Please amend the commit message
Junio C Hamano wrote:
For --short and --symbolic-full-name, I have a feeling that we
should make describe a front-end for these.
[...]
All very good. If and when someone does write that functionality (I
personally find the task boring), we can remove this completer. Until
such a time, the
On 07/03/2013 12:39 AM, benoit.per...@ensimag.fr wrote:
From: Benoit Person benoit.per...@ensimag.fr
For now, bin-wrappers (based on wrap-for-bin.sh) redefine some
environnement variables (like $GITPERLLIB). If we want to chain to
those scripts and define one of those variables before, our
Innerhalb von IT den nächsten und zusätzlich 3. Stufe Ballungsräumen, die
kleinen Kunden von einem lokalen nike free 5.0 herren
http://www.schuhenkaufenonline.de/nike-free/nike-free-5-0 Marke um
zusätzliche Personen identifiziert werden sich bestimmt, aber das Wagnis der
Individualität sein
On 07/03/2013 12:11 PM, Johan Herland wrote:
On Wed, Jul 3, 2013 at 12:06 PM, Jonathan del Strother
maill...@steelskies.com wrote:
I'm struggling to think of instances where I wouldn't want this
CAS-like behaviour. Wouldn't it be better to make it the default when
pushing, and allowing the
benoit.per...@ensimag.fr writes:
diff --git a/wrap-for-bin.sh b/wrap-for-bin.sh
index 53a8dd0..dbebe49 100644
--- a/wrap-for-bin.sh
+++ b/wrap-for-bin.sh
@@ -14,7 +14,7 @@ else
GIT_TEMPLATE_DIR='@@BUILD_DIR@@/templates/blt'
export GIT_TEMPLATE_DIR
fi
Ramkumar Ramachandra wrote:
New-style class. I wonder why you suddenly switched.
? All of the classes are new-style classes.
When you say class Foo:, aren't you declaring an old-style class by
default in python2? New-style classes are those that explicitly
inherit from object (implicit
On 07/03/2013 12:23 PM, Ramkumar Ramachandra wrote:
Michael Haggerty wrote:
On 07/02/2013 09:23 PM, Ramkumar Ramachandra wrote:
git_multimail.py wrote:
#! /usr/bin/env python2
Do all distributions ship it as python2 now?
No, but nor is python always Python version 2.x (I believe that Arch
On 3 July 2013 11:00, Johan Herland jo...@herland.net wrote:
On Wed, Jul 3, 2013 at 10:49 AM, Junio C Hamano gits...@pobox.com wrote:
Johan Herland jo...@herland.net writes:
Overnight, it occured to me that --force-if-expected could be
simplified by leveraging the existing --force option; for
I'm not trying to change the way git does things (which works perfectly
well), I'm asking for some extra information to be added to the commit
so that analysis of the ancestry graph can be tied to the branch topics
that the original author was working from. Currently if you have a
On Tue, Jul 2, 2013 at 10:34 PM, Ed Hutchins e...@demeterr.com wrote:
On the other hand
trying to figure
out the history of events from a large directed graph of commits
without any clue about
what topics first spawned each commit is actively harmful in many
cases (trying to display
a clear
Chris Packham judge.pack...@gmail.com writes:
On 03/07/13 19:54, Chris Packham wrote:
On a related note should I be updating Documentation/config.txt as well?
Even if it's a statement that this feature exists refer to
git-submodule(1) for details.
Answering my own question. While 'update'
Chris Packham judge.pack...@gmail.com writes:
Users can set submodule.$name.update to '!command' which will cause
'command' to be run instead of checkout/merge/rebase. This allows the
user some finer grained control over how the update is done. The primary
motivation for this was
Jens Lindström j...@opera.com writes:
On Mon, Jul 1, 2013 at 6:20 PM, Junio C Hamano gits...@pobox.com wrote:
I am not sure if we should care that deeply about them in the first
place.
Fine by me; I don't really have a strong opinion on the matter.
Besides, I think you can make a hardlink
I might be able to switch our corporate workflow to adding non-ff merge
commits, but the reason we moved away from using github's big red button
in the first place was to avoid the extra noise of merge-only commits.
Actually you've pointed out an inconsistency: why is it okay for merge
commits to
Jens Lehmann jens.lehm...@web.de writes:
The only minor problem is that this patch still does not apply cleanly
to master, next or pu (I wonder what you based this on ;-).
Older iteration of the topic has been queued directly on top of
v1.8.3. When I replace a topic with its new version, I
Ed Hutchins e...@demeterr.com writes:
I'm not trying to change the way git does things (which works perfectly
well), I'm asking for some extra information to be added to the commit
so that analysis of the ancestry graph can be tied to the branch topics
that the original author was working
On Tue, Jul 2, 2013 at 11:23 PM, Jeff King p...@peff.net wrote:
On Tue, Jul 02, 2013 at 04:53:48PM -0700, Brandon Casey wrote:
From: Brandon Casey draf...@gmail.com
When pushing, each ref in the local repository must be paired with a
ref advertised by the remote server. Currently, this is
Ed Hutchins e...@demeterr.com writes:
I might be able to switch our corporate workflow to adding non-ff merge
commits, but the reason we moved away from using github's big red button
in the first place was to avoid the extra noise of merge-only commits.
Actually you've pointed out an
On Wed, Jul 03, 2013 at 07:27:39PM +0100, John Keeping wrote:
Since commit 00b347d (git-config: do not complain about duplicate
entries, 2012-10-23), git config --get does not exit with an error if
there are multiple values for the specified key but instead returns the
last value. Update the
Michael Schubert wrote:
--- a/Documentation/git-p4.txt
+++ b/Documentation/git-p4.txt
@@ -180,7 +180,7 @@ subsequent 'sync' operations.
Import changes into given branch. If the branch starts with
'refs/', it will be used as is. Otherwise if it does not start
with 'p4/',
Brandon Casey draf...@gmail.com writes:
Right. For repos with few refs on either side, I don't think there
will be any measurable difference. When pushing a single ref to a
repo with a very large number of refs, we will see a very small net
loss for the time required to prepare the string
John Keeping j...@keeping.me.uk writes:
Since commit 00b347d (git-config: do not complain about duplicate
entries, 2012-10-23), git config --get does not exit with an error if
there are multiple values for the specified key but instead returns the
last value. Update the documentation to
On Wed, Jul 03, 2013 at 11:40:12AM -0700, Junio C Hamano wrote:
Brandon Casey draf...@gmail.com writes:
Right. For repos with few refs on either side, I don't think there
will be any measurable difference. When pushing a single ref to a
repo with a very large number of refs, we will
Thanks.
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
On 7/3/2013 11:40 AM, Junio C Hamano wrote:
Brandon Casey draf...@gmail.com writes:
Right. For repos with few refs on either side, I don't think there
will be any measurable difference. When pushing a single ref to a
repo with a very large number of refs, we will see a very small net
loss
Johan Herland jo...@herland.net writes:
I'll leave the name open but tentatively use this name in the
following, primarily to see how well it sits on the command line
examples.
I agree that neither --expect nor --validate are very good. I also
don't like --lockref, mostly because there is
Jonathan del Strother maill...@steelskies.com writes:
I'm struggling to think of instances where I wouldn't want this
CAS-like behaviour. Wouldn't it be better to make it the default when
pushing, and allowing the current behaviour with git push
--blind-force or something?
Not until we run
Johannes Sixt j.s...@viscovery.net writes:
I don't think that is necessary. We already have *two* options to
force-push a ref: the + in front of refspec, and --force.
They mean exactly the same thing; the only difference being that +
prefix is per target ref, while --force covers everything,
Hello,
I see over the last year (on the web and in this mailing list) there
was some activity to extend subtree with a .gittrees file and
push-all/pull-all commands.
Perhaps I missed it, but looking through the latest git code on the
github mirror I can't find any reference to the .gittrees file
On Tue, Jul 02, 2013 at 12:41:03PM -0700, Junio C Hamano wrote:
Alexey Shumkin alex.crez...@gmail.com writes:
v8 of this patch series includes the following changes against v7:
Oops, isn't this already in 'next'? In that case, please feed
incremental updates on top of the patches that
On 7/3/2013 12:00 PM, Jeff King wrote:
On Wed, Jul 03, 2013 at 11:40:12AM -0700, Junio C Hamano wrote:
Brandon Casey draf...@gmail.com writes:
Right. For repos with few refs on either side, I don't think there
will be any measurable difference. When pushing a single ref to a
repo with a
Alexey Shumkin alex.crez...@gmail.com writes:
On Tue, Jul 02, 2013 at 12:41:03PM -0700, Junio C Hamano wrote:
Alexey Shumkin alex.crez...@gmail.com writes:
v8 of this patch series includes the following changes against v7:
Oops, isn't this already in 'next'? In that case, please feed
Junio C Hamano gits...@pobox.com writes:
Jonathan del Strother maill...@steelskies.com writes:
I'm struggling to think of instances where I wouldn't want this
CAS-like behaviour. Wouldn't it be better to make it the default when
pushing, and allowing the current behaviour with git push
My system doesn't have the en_US.UTF-8 locale (or plain en_US), which
causes t4205 to fail by counting bytes instead of UTF-8 codepoints.
Instead of using sed for this, use Perl which behaves predictably
whatever locale is in use.
Signed-off-by: John Keeping j...@keeping.me.uk
---
This patch is
On Tue, Jul 02, 2013 at 09:22:09AM +0200, Johannes Sixt wrote:
Am 7/2/2013 0:50, schrieb Alexey Shumkin:
On Mon, Jul 01, 2013 at 09:00:55AM +0200, Johannes Sixt wrote:
Am 6/26/2013 12:19, schrieb Alexey Shumkin:
test_expect_success 'setup complex body' '
git config i18n.commitencoding
Brandon Casey bca...@nvidia.com writes:
... by penalizing the common case by how much? If it is not too
much, then this obviously would be a good change.
For something the size of the git repo, 5 branches, and pushing with
matching refspecs, I can't measure any difference. The fastest time
Matthieu Moy matthieu@grenoble-inp.fr writes:
benoit.per...@ensimag.fr writes:
diff --git a/wrap-for-bin.sh b/wrap-for-bin.sh
index 53a8dd0..dbebe49 100644
--- a/wrap-for-bin.sh
+++ b/wrap-for-bin.sh
@@ -14,7 +14,7 @@ else
GIT_TEMPLATE_DIR='@@BUILD_DIR@@/templates/blt'
Jonathan Nieder jrnie...@gmail.com writes:
Michael Schubert wrote:
--- a/Documentation/git-p4.txt
+++ b/Documentation/git-p4.txt
@@ -180,7 +180,7 @@ subsequent 'sync' operations.
Import changes into given branch. If the branch starts with
'refs/', it will be used as is.
Junio C Hamano gits...@pobox.com writes:
Matthieu Moy matthieu@grenoble-inp.fr writes:
benoit.per...@ensimag.fr writes:
diff --git a/wrap-for-bin.sh b/wrap-for-bin.sh
index 53a8dd0..dbebe49 100644
--- a/wrap-for-bin.sh
+++ b/wrap-for-bin.sh
@@ -14,7 +14,7 @@ else
CC this to Johannes Sixt
On Wed, Jul 03, 2013 at 09:18:08PM +0100, John Keeping wrote:
My system doesn't have the en_US.UTF-8 locale (or plain en_US), which
causes t4205 to fail by counting bytes instead of UTF-8 codepoints.
Instead of using sed for this, use Perl which behaves predictably
http://thread.gmane.org/gmane.comp.version-control.git/229291
this is why CCed
CC this to Johannes Sixt
On Wed, Jul 03, 2013 at 09:18:08PM +0100, John Keeping wrote:
My system doesn't have the en_US.UTF-8 locale (or plain en_US), which
causes t4205 to fail by counting bytes instead of
This script lists people that might be interested in a patch by going
back through the history for each patch hunk, and finding people that
reviewed, acknowledge, signed, authored, or were Cc:'d on the code the
patch is modifying.
It does this by running git-blame incrementally on each hunk and
As a convenience, accept the same style since committish as accepted
by git-format-patch. For example:
% git contacts master
will consider commits in the current branch built atop 'master', just as
git format-patch master will format commits built atop 'master'.
Signed-off-by: Eric Sunshine
This is v2 of the Perl rewrite of Felipe Contreras' git-related v9 patch
series[1] which was written in Ruby. v2 addresses (hopefully all of)
Junio's v1[2] review points.
[1]: http://thread.gmane.org/gmane.comp.version-control.git/226065/
[2]:
For example:
% git contacts master..feature
Committishes and patch files can be mentioned in the same
invocation:
% git contacts master..feature extra/*.patch
Signed-off-by: Eric Sunshine sunsh...@sunshineco.com
---
contrib/contacts/git-contacts | 38 --
Ramkumar Ramachandra artag...@gmail.com writes:
Yeah, this is good reasoning. And yes, I'm on Arch: python points to
python3, and python2 points to python2.
I'm also on Arch and it has been this way since October 2010 [1].
Ubuntu plans to remove python2 from the desktop CD images in 14.04
John Keeping j...@keeping.me.uk writes:
My system doesn't have the en_US.UTF-8 locale (or plain en_US), which
causes t4205 to fail by counting bytes instead of UTF-8 codepoints.
Instead of using sed for this, use Perl which behaves predictably
whatever locale is in use.
Signed-off-by: John
Matthieu Moy matthieu@grenoble-inp.fr writes:
I don't get it. It Git Mediawiki's tests, the tests scripts source
test-lib.sh, that unsets GITPERLLIB. Then, it calls the
mw-to-git/bin-wrapper/git that sets it properly, and calls the
toplevel's bin-wrapper.
Ah, OK. I somehow was assuming
On Wed, Jul 03, 2013 at 02:41:06PM -0700, Junio C Hamano wrote:
John Keeping j...@keeping.me.uk writes:
My system doesn't have the en_US.UTF-8 locale (or plain en_US), which
causes t4205 to fail by counting bytes instead of UTF-8 codepoints.
Instead of using sed for this, use Perl which
(cc-ing Jakub, gitweb wrangler)
Tony Finch wrote:
There are often parent pages logically above the gitweb projects
list, e.g. home pages of the organization and department that host
the gitweb server. This change allows you to include links to those
pages in gitweb's breadcrumb trail.
Neat.
On Wed, Jul 3, 2013 at 11:59 PM, Jonathan Nieder jrnie...@gmail.com wrote:
Tony Finch wrote:
+@extra_breadcrumbs::
+ Additional links to be added to the start of the breadcrumb trail,
+ that are logically above the gitweb projects list. For example,
+ links to the organization
On Wed, Jul 03, 2013 at 02:41:06PM -0700, Junio C Hamano wrote:
John Keeping j...@keeping.me.uk writes:
My system doesn't have the en_US.UTF-8 locale (or plain en_US), which
causes t4205 to fail by counting bytes instead of UTF-8 codepoints.
Instead of using sed for this, use Perl which
On Wed, Jul 03, 2013 at 10:53:03PM +0100, John Keeping wrote:
On Wed, Jul 03, 2013 at 02:41:06PM -0700, Junio C Hamano wrote:
John Keeping j...@keeping.me.uk writes:
My system doesn't have the en_US.UTF-8 locale (or plain en_US), which
causes t4205 to fail by counting bytes instead of
gits...@pobox.com wrote on Wed, 03 Jul 2013 13:33 -0700:
Jonathan Nieder jrnie...@gmail.com writes:
Michael Schubert wrote:
--- a/Documentation/git-p4.txt
+++ b/Documentation/git-p4.txt
@@ -180,7 +180,7 @@ subsequent 'sync' operations.
Import changes into given branch. If the
Hello!
I lost a previously untracked file that I added to the index in the
middle of a git rebase --interactive session after a git rebase --abort.
This was unexpected.
$ ls forgotten_file
forgotten_file
$ git rebase --interactive HEAD~3
[change first rebase command from pick
Paul A. Kennedy wrote:
If we don't expect this, should we update the documentation for the
--abort heading in the git rebase man page to indicate that newly
staged content will be lost after a git rebase --abort?
How about something along these lines?
diff --git
Jonathan Nieder jrnie...@gmail.com writes:
Paul A. Kennedy wrote:
If we don't expect this, should we update the documentation for the
--abort heading in the git rebase man page to indicate that newly
staged content will be lost after a git rebase --abort?
How about something along these
Hi,
I had a pretty sucky thing happen to me today: while remote tracking a
non-master branch, I force pushed. This had the intended effect of force
pushing the branch I was working on, but also the unintended function of force
pushing all branches I wasn't on.
I'm open to anyone's thoughts
Hi Dany,
Dany wrote:
I had a pretty sucky thing happen to me today: while remote tracking
a non-master branch, I force pushed. This had the intended effect of
force pushing the branch I was working on, but also the unintended
function of force pushing all branches I wasn't on.
Yeah, I agree
[I'm sorry about breaking Cc: chain - responding via GMane web interface]
Junio C Hamano gitster at pobox.com writes:
Ed Hutchins eh at demeterr.com writes:
I'm not trying to change the way git does things (which works perfectly
well), I'm asking for some extra information to be added to
Hey Jonathan,
Thanks for the quick reply. I think that's a great message; I do have to say
that I wouldn't have known what the `matching` and `simple` modes are without
that message; I just had to look it up is all. It may be helpful to tell users
that `simple` is probably what they want :)
lol, confusion abound. this message was intended to be in response to Re:
Feature request: prevent push -f from pushing all branches at once
On Jul 3, 2013, at 4:52 PM, Dany nes...@gmail.com wrote:
Hey Jonathan,
Thanks for the quick reply. I think that's a great message; I do have to say
On 4 July 2013 09:46, Jakub Narebski jna...@gmail.com wrote:
Junio C Hamano gitster at pobox.com writes:
It is not just misleading but is actively wrong to recording the
name of the original branch in commits and carrying them forward via
rebase. If you want a record of what a group of commits
On Sat, Jun 29, 2013 at 07:13:40PM -0700, Junio C Hamano wrote:
brian m. carlson sand...@crustytoothpaste.net writes:
diff --git a/t/t3900/UTF-8-invalid.txt b/t/t3900/UTF-8-invalid.txt
new file mode 100644
index 000..343684d
--- /dev/null
+++ b/t/t3900/UTF-8-invalid.txt
@@ -0,0
brian m. carlson sand...@crustytoothpaste.net writes:
git format-patch --binary seems to produce the exact same output as
without the --binary option. Is there a different way I should be
selecting the binary option?
These days --binary is a no-op option for format-patch (we used to
default
Am 7/3/2013 21:53, schrieb Junio C Hamano:
Johannes Sixt j.s...@viscovery.net writes:
I don't think that is necessary. We already have *two* options to
force-push a ref: the + in front of refspec, and --force.
They mean exactly the same thing; the only difference being that +
prefix is
1 - 100 of 101 matches
Mail list logo
