From: Johan Herland
Subject: Re: Recording the current branch on each commit?
Date: Mon, 28 Apr 2014 01:39:26 +0200
> On Sun, Apr 27, 2014 at 10:55 PM, Jeremy Morton wrote:
>> On 27/04/2014 20:33, Johan Herland wrote:
>>> On Sun, Apr 27, 2014 at 7:38 PM, Jeremy Morton
>>> wrote:
On 27/04/20
> Personally, I am _strongly_ opposed. How I name and juggle my private
> branches is nobody else's business in a distributed version control
> system.
>
> They are private. My personal workflow. Not part of a commit.
Mercurial inherits the branch label from previous commit, unless
it's specif
Hi.
> Obviously, the feature would necessarily have to be optional, simply
> because Git would have to keep understanding the old commit object
> format for a LONG time (probably indefinitely), and there's nothing
> you can do to prevent others from creating old-style commit objects.
Doesn't git
Setup:
20 people (programmers, artists, designers) with prior SVN knowledge and a
desire to use Git for a new project (mostly on programmers side).
Non-programmers used TortoiseSVN before so choosing TortoiseGit as a GUI was an
obvios step.
We made an in-house presentation introducing basic Git
Hello,
I installed git for windows 1.9.0 but any push operation I tried with it
produced an error message saying "git: 'http-push' is not a git command". Other
commands like pull, add, and commit worked just fine.
At the end of this day I noticed that C:\Program Files
(x86)\Git\libexec\git-core
Johan Herland writes:
> Obviously, the feature would necessarily have to be optional, simply
> because Git would have to keep understanding the old commit object
> format for a LONG time (probably indefinitely), and there's nothing
> you can do to prevent others from creating old-style commit obj
On 04/27/2014 10:12 PM, Christian Couder wrote:
> It looks like the commit-msg hook is passed a commit
> message that can contain lines starting with a '#'.
> Those comment lines will be removed from the commit
> message after the hook is run.
>
> If we want "git interpret-trailers" to be able to
Translate 45 new messages came from git.pot update in 5e078fc
(l10n: git.pot: v2.0.0 round 1 (45 new, 28 removed)).
Signed-off-by: Ralf Thielow
Acked-by: Thomas Rast
---
po/de.po | 127 +--
1 file changed, 50 insertions(+), 77 deletion
On 04/28/2014 01:03 AM, Johan Herland wrote:
On Sun, Apr 27, 2014 at 7:38 PM, Jeremy Morton wrote:
On 27/04/2014 10:09, Johan Herland wrote:
On Sun, Apr 27, 2014 at 1:56 AM, Jeremy Morton
wrote:
Currently, git records a checksum, author, commit date/time, and commit
message with every commit
On Sun, Apr 27, 2014 at 10:55 PM, Jeremy Morton wrote:
> On 27/04/2014 20:33, Johan Herland wrote:
>> On Sun, Apr 27, 2014 at 7:38 PM, Jeremy Morton
>> wrote:
>>> On 27/04/2014 10:09, Johan Herland wrote:
>>> As far as I can tell from that discussion, the general opposition to
>>> encoding the bra
Jeremy Morton wrote:
>On 27/04/2014 22:40, James Denholm wrote:
>>> Also, you don't always have something you can link a commit to in an
>>> issue tracker. You may just be implementing a feature that has been
>>> agreed upon, independently of any such tracker. In that case,
>there's
>>> no bug#
On 27/04/2014 22:40, James Denholm wrote:
Also, you don't always have something you can link a commit to in an
issue tracker. You may just be implementing a feature that has been
agreed upon, independently of any such tracker. In that case, there's
no bug# to link to.
In which case, refer to
I'm skipping a lot of the discussion here, sorry about that, but
on one particular note:
Jeremy Morton wrote:
> (...) and besides it takes up space that could be
>used for a commit message. As short commit messages are valued in Git,
>it's particularly bad to waste space this way.
Not really.
On 27/04/2014 20:33, Johan Herland wrote:
On Sun, Apr 27, 2014 at 7:38 PM, Jeremy Morton wrote:
On 27/04/2014 10:09, Johan Herland wrote:
As far as I can tell from that discussion, the general opposition to
encoding the branch name as a structural part of the commit object is that,
for some peo
As I sent version 11 of the "Add interpret-trailers builtin" only a few
days ago, I am sending now a short series on top instead of another full
version.
Christian Couder (2):
trailer: fix to ignore any line starting with '#'
trailer: add examples to the documentation
Documentation/git-inter
Signed-off-by: Christian Couder
---
Documentation/git-interpret-trailers.txt | 98 +++-
1 file changed, 97 insertions(+), 1 deletion(-)
diff --git a/Documentation/git-interpret-trailers.txt
b/Documentation/git-interpret-trailers.txt
index 450ec54..42c2f71 100644
---
It looks like the commit-msg hook is passed a commit
message that can contain lines starting with a '#'.
Those comment lines will be removed from the commit
message after the hook is run.
If we want "git interpret-trailers" to be able to
process commit messages correctly in the commit-msg
hook we
Am 27.04.2014 18:46, schrieb Marius Ungureanu:
> Is it okay though if I add a few tests to show what is broken?
>
> I think this can’t be solved at a regex level.
It's OK to add tests that show breakages even if there is no immediate
solution.
>> You can mark a userdiff test case that demonstrat
On Sun, Apr 27, 2014 at 7:38 PM, Jeremy Morton wrote:
> On 27/04/2014 10:09, Johan Herland wrote:
>> On Sun, Apr 27, 2014 at 1:56 AM, Jeremy Morton
>> wrote:
>>> Currently, git records a checksum, author, commit date/time, and commit
>>> message with every commit (as get be seen from 'git log').
On Apr 22, 2014, at 11:54 AM, Eric Wong wrote:
> Jakob Stoklund Olesen wrote:
>> Subversion can put mergeinfo on any sub-directory to track cherry-picks.
>> Since cherry-picks are not represented explicitly in git, git-svn should
>> just ignore it.
>
> Hi, was git-svn trying to track cherry-pi
On Thu, Apr 03, 2014 at 11:31:51AM -0700, Junio C Hamano wrote:
> "Michael S. Tsirkin" writes:
>
> > Allow extracting To/Cc addresses from cover letter.
>
> Please say what you are doing with what you extract, which is the
> more important part of the objective. Extracting is merely a step
> to
Allow extracting To/Cc addresses from cover letter.
Signed-off-by: Michael S. Tsirkin
---
Documentation/git-send-email.txt | 12
git-send-email.perl | 16
2 files changed, 28 insertions(+)
diff --git a/Documentation/git-send-email.txt b/Documentation/g
Add tests for the new feature.
Signed-off-by: Michael S. Tsirkin
---
t/t9001-send-email.sh | 45 +
1 file changed, 45 insertions(+)
diff --git a/t/t9001-send-email.sh b/t/t9001-send-email.sh
index 1ecdacb..97cc094 100755
--- a/t/t9001-send-email.sh
++
On Thu, Apr 24, 2014 at 03:12:14PM -0700, Junio C Hamano wrote:
> "Michael S. Tsirkin" writes:
>
> >> > +--unstable::
> >> > +Use a non-symmetrical sum of hashes, such that reordering
> >>
> >> What is a non-symmetrical sum?
> >
> > Non-symmetrical combination function is better?
>
> I
update test to match behaviour change
Signed-off-by: Michael S. Tsirkin
---
t/t4204-patch-id.sh | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/t/t4204-patch-id.sh b/t/t4204-patch-id.sh
index 7732370..a8b0c2c 100755
--- a/t/t4204-patch-id.sh
+++ b/t/t4204-patch-id.sh
@@ -
Verify that patch ID supports an algorithm
that is stable against diff split and reordering.
Signed-off-by: Michael S. Tsirkin
---
t/t4204-patch-id.sh | 102 ++--
1 file changed, 91 insertions(+), 11 deletions(-)
diff --git a/t/t4204-patch-id.sh b
--stable has been the default in 'next' for a few weeks with no ill
effects.
Change the default to that so that users don't have to remember to
enable it.
Update documentation to match behaviour change.
Signed-off-by: Michael S. Tsirkin
---
builtin/patch-id.c | 4 ++--
Documentation
API and implementation as suggested by Junio.
Signed-off-by: Michael S. Tsirkin
---
t/README| 22 ++
t/test-lib-functions.sh | 5 +
2 files changed, 27 insertions(+)
diff --git a/t/README b/t/README
index caeeb9d..2d6232f 100644
--- a/t/README
+++ b/t/RE
Patch id changes if users reorder file diffs that make up a patch.
As the result is functionally equivalent, a different patch id is
surprising to many users.
In particular, reordering files using diff -O is helpful to make patches
more readable (e.g. API header diff before implementation diff).
git-imap-send was directly prompting for a password rather than using
git-credential. git-send-email, on the other hand, supports git-credential.
This is a necessary improvement for users that use two factor authentication, as
they should not be expected to remember all of their app specific passw
On Sat, Apr 26, 2014 at 2:39 PM, David Kastrup wrote:
>
> At least the stuff I fixed with regard to performance would seem to be
> done right in JGit to start with.
Hah! Its Java. We have to do things right, otherwise its too slow. :-)
>> Its still not as fast as I want it to be. :-)
>
> Most of
On 27/04/2014 10:09, Johan Herland wrote:
On Sun, Apr 27, 2014 at 1:56 AM, Jeremy Morton wrote:
Currently, git records a checksum, author, commit date/time, and commit
message with every commit (as get be seen from 'git log'). I think it would
be useful if, along with the Author and Date, git
On 27/04/2014 09:51, Robin Rosenberg wrote:
Currently, git records a checksum, author, commit date/time, and commit
message with every commit (as get be seen from 'git log'). I think it
would be useful if, along with the Author and Date, git recorded the
name of the current branch on each commit
> You can mark a userdiff test case that demonstrates a breakage by
> including the work "broken" somewhere in the file. See
> http://www.repo.or.cz/w/alt-git.git/commitdiff/9cc444f0570b196f1c51664ce2de1d8e1dee6046
> -- Hannes
Would you like me to add tests first, then fix them? Or just like this
On 27 Apr 2014, at 19:19, Johannes Sixt wrote:
> Am 27.04.2014 15:47, schrieb Marius Ungureanu:
>>
>> ---
>
> Thanks. Please signed off your patch.
>
Ah, yes, forgot to do that.
> When you re-send, please place [PATCH v3 n/m] in the subject (and drop
> the "Re:") and note what you changed c
Am 27.04.2014 15:47, schrieb Marius Ungureanu:
>
> ---
Thanks. Please signed off your patch.
When you re-send, please place [PATCH v3 n/m] in the subject (and drop
the "Re:") and note what you changed compared to the previous (or all
earlier) rounds. The place for this note is here, after the "-
- Original Message -
> On Sun, Apr 27, 2014 at 09:12:39AM +0700, Duy Nguyen wrote:
>
> > The intent of the commit was "that is a stupid thing to do, but it's
> > not so obvious from the first glance, do not freeze my system for my
> > mistake". But if it stops an actual use case, then I ag
Ugh, there’s an empty line at the beginning of the 2nd patch that shouldn’t be
there.
Thanks,
Marius--
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
---
t/t4018/csharp-constructor | 4
t/t4018/csharp-destructor | 4
t/t4018/csharp-function| 4
t/t4018/csharp-member | 4
t/t4018/csharp-namespace | 4
t/t4018/csharp-operator| 4
t/t4018/csharp-property| 4
t/t4018/csharp-skip-call | 5 +++
Remove all keywords since they don't cause conflicts.
Add method modifiers: abstract, async, explicit, extern, implicit,
partial, operator.
Add properties modifiers: abstract, readonly.
Add type modifiers: abstract.
Parse C# operator functions.
Fix constructor parsing.
Signed-off-by: Marius U
Heya, so I’ll add the patches in the next 2 emails.
I’ve changed a bit the main body of the methods/constructors regex.
Basically, I’ve made the first item after the modifiers optional. That’s
the return type and it’s not used in any case by operator overloads
or constructors/destructors.
I also
On 26 Apr 2014, at 21:50, Johannes Sixt wrote:
> Am 26.04.2014 20:33, schrieb Marius Ungureanu:
>> ... add as many unit tests I can.
>
> Great! Keep in mind that quantity is secondary. Quality counts.
Obviously. By ‘as many’, I meant to cover all the cases here.
>> I’ll start a new thread wit
Shawn Pearce writes:
> On Sat, Apr 26, 2014 at 10:30 AM, David Kastrup wrote:
>> David Kastrup writes:
>>
>> Here's some example:
>>
>> dak@lola:/usr/local/tmp/wortliste$ time git blame -n -s wortliste >/tmp/wl1
>>
>> real15m47.118s
>> user14m39.928s
>> sys 1m1.872s
>
> Hah, this is
On Sun, Apr 27, 2014 at 1:56 AM, Jeremy Morton wrote:
> Currently, git records a checksum, author, commit date/time, and commit
> message with every commit (as get be seen from 'git log'). I think it would
> be useful if, along with the Author and Date, git recorded the name of the
> current bran
- Ursprungligt meddelande -
> Från: "Jeremy Morton"
> Till: git@vger.kernel.org
> Skickat: söndag, 27 apr 2014 1:56:47
> Ämne: Recording the current branch on each commit?
>
> Currently, git records a checksum, author, commit date/time, and commit
> message with every commit (as get be
Hello!
We are a chinese company,
which specialized in manufacturing office supply:
1. Used duplicator machines
2. Spare parts for duplicators
3. Color&black toner cartridges
4.barcode printer
5.printhead
If you would like to know, Pls contact us in following way or reply this email:
pri
On Sun, Apr 27, 2014 at 09:12:39AM +0700, Duy Nguyen wrote:
> The intent of the commit was "that is a stupid thing to do, but it's
> not so obvious from the first glance, do not freeze my system for my
> mistake". But if it stops an actual use case, then I agree it should
> be reverted.
Thanks fo
On Sat, Apr 26, 2014 at 11:30:11AM -0700, Dan Albert wrote:
> I had resent a less broken patch after I noticed the tabs, but it seems to
> have gotten lost. Better formatted patch at the bottom of this message.
Your emails (including this one) are multipart/alternatives with an html
part, which w
48 matches
Mail list logo
