**** BEGIN LOGGING AT Mon May 30 02:59:59 2016
May 30 05:27:36 <ZeekHuge> Wormo: Hi !
May 30 05:28:10 <ZeekHuge> really confused on this side with all this ..
May 30 05:28:38 <ZeekHuge> 4.4.11 was released just about 3-4 days back ..
May 30 05:29:08 <ZeekHuge> so we should probably wait for it to came out as a distro ?
May 30 05:29:35 <ZeekHuge> even after that, we are not very sure of its working state.
May 30 05:30:23 <ZeekHuge> its already out till 4.4.9
May 30 05:30:24 <ZeekHuge> /home/zeekhuge/Kariya/DATA2/Android
May 30 05:30:24 <ZeekHuge> /home/zeekhuge/Kariya/DATA2/AndroidStudio
May 30 05:30:31 <ZeekHuge> ahh .. sorry !
May 30 05:30:37 <ZeekHuge> http://elinux.org/Beagleboard:BeagleBoneBlack_Debian#Jessie_Snapshot_iot
May 30 05:31:46 <ZeekHuge> tagged 3 days ago : https://github.com/RobertCNelson/linux-stable-rcn-ee/releases/tag/4.4.11-ti-r28
May 30 05:33:40 <ZeekHuge> its really a headache !
May 30 05:38:51 <ZeekHuge> basically the header main header file ie, the remoteproc.h itself is different in the two, and pruss_rproc needs that changes. Introducing which is resulting in a different symbol_number
May 30 11:56:18 <pmezydlo> ZeekHuge: Happy Birthday! I wish you every happiness on your special day
May 30 12:01:12 <ZeekHuge> Thank you pmezydlo ! :)
May 30 13:14:59 <kiran4399> alexhiam: ping
May 30 13:16:03 <kiran4399> Does anybody know which and how to modify file to access the secondary i2c interface for beaglebone black?
May 30 13:16:39 <kiran4399> like if I get the mpu 9150 address.. in which file should I give the slave id and the secondary i2c address?
May 30 16:07:47 <alexhiam> kiran4399: not sure what you mean by the secondary address, but with I2C devices on Linux you tell the core driver what device is at what address
May 30 16:08:20 <alexhiam> e.g. `echo inv-mpu6050 0x68 > /sys/class/i2c-adapter/i2c-X/new_device`
May 30 16:11:59 <alexhiam> kiran4399: what's the difference between the driver on your github and the one already in the bb.org kernel? https://github.com/beagleboard/linux/tree/4.4/drivers/iio/imu/inv_mpu6050
May 30 16:18:45 <alexhiam> kiran4399: I'm trying to understand the difference between the two drivers (both copyright 2012 Invensense, but clearly different), as well as the changes you're making
May 30 16:19:13 <alexhiam> :(
May 30 16:40:49 <kiran4399> alexhiam: I am sorry... afk for some time..
May 30 16:41:42 <kiran4399> alexhiam: I got the mpu generic driver for andriod kernel repository....
May 30 16:56:03 <kiran4399> alexhiam: The thing is I don't know how to put the addresses for the mpu 9150 on the i2c bus..
May 30 16:56:41 <alexhiam> kiran4399: did you see my messages? that's part of the core i2c driver
May 30 16:56:48 <kiran4399> alexhiam: Yeah..
May 30 16:56:49 <alexhiam> `echo inv-mpu6050 0x68 > /sys/class/i2c-adapter/i2c-X/new_device`
May 30 16:56:58 <alexhiam> or through device tree
May 30 16:57:19 <alexhiam> ooooh, you mean that secondary_addr property?
May 30 16:57:28 <kiran4399> alexhiam: yeah.. but don't you think I must do something like this while modifieng the drivers?
May 30 16:57:31 <kiran4399> yeah..
May 30 16:57:47 <kiran4399> alexhiam: https://android.googlesource.com/kernel/msm/+/android-msm-hammerhead-3.4-kk-fr2/drivers/staging/iio/imu/inv_mpu/README#123
May 30 16:57:50 <alexhiam> well for one I'm not sure why you're modifying it
May 30 16:58:15 <alexhiam> so that's an outdated README, because the board file has been replaced by Device Tree
May 30 16:59:02 <kiran4399> alexhiam: exactly.. that is what I was thinking..
May 30 16:59:42 <alexhiam> what is the secondary address?
May 30 16:59:53 <alexhiam> is that for an internal i2c bus?
May 30 17:00:39 <kiran4399> alexhiam:  MPU-6050 + AKM8963 on the secondary I2C interface
May 30 17:01:03 <alexhiam> right, ok
May 30 17:01:31 <kiran4399> alexhiam: so what do you say?
May 30 17:01:37 <alexhiam> so I would think that 9150 driver should work out of the box
May 30 17:02:36 <kiran4399> alexhiam: yeah.. so can you tellme which overlay I have to edit tou enter the secondary slave id, i2c-addr, orientation etc.?
May 30 17:02:54 <kiran4399> like in the line 123 in the readme file?
May 30 17:03:36 <kiran4399> alexhiam: what do you say about this?
May 30 17:03:37 <kiran4399> http://stackoverflow.com/questions/33549211/how-to-add-i2c-devices-on-the-beaglebone-black-using-device-tree-overlays
May 30 17:03:58 <alexhiam> kiran4399: you'd want something like this: https://groups.google.com/d/msg/beagleboard/hqqecmOjpTU/c69QBofcVJYJ
May 30 17:04:34 <alexhiam> and probably right in the base beaglebone blue DT
May 30 17:05:02 <alexhiam> with `compatible = "inv,mpu9150";` and whatever other properties you need
May 30 17:06:59 <kiran4399> alexhiam: OK.. cool!!
May 30 17:07:22 <kiran4399> alexhiam: so tomorrow I need to submit the weekly report right?
May 30 17:07:37 <alexhiam> yeah
May 30 17:09:10 <kiran4399> alexhiam: btw.. for the blue kernel... do you want me to build them as module or build them with 'y' in the defconfig file?
May 30 17:09:32 <kiran4399> I am talking about building kernel modules..
May 30 17:09:40 <kiran4399> alexhiam: ^^
May 30 17:10:39 <alexhiam> kiran4399: hmm, I think as modules... because the blue should have the same kernel as the black, green, etc., and you wouldn't want those drivers loaded on the other boards
May 30 17:11:36 <kiran4399> alexhiam: ok.. then in that case the only think I have to add is the mpu-9150..
May 30 17:11:37 <alexhiam> the only thing different between them should be the Device Tree
May 30 17:11:49 <kiran4399> *thing
May 30 17:12:08 <alexhiam> kiran4399: and the barometer, right?
May 30 17:12:37 <alexhiam> do you have the robotics cape yet?
May 30 17:13:02 <kiran4399> alexhiam: yeah.. got it tomrrow..
May 30 17:13:13 <kiran4399> alexhiam: sorry..
May 30 17:13:17 <kiran4399> I mean to say..
May 30 17:13:57 <kiran4399> my parents got .. it is there in my home.... I am leaving home day after tomrrow..
May 30 17:14:06 <kiran4399> *to home..
May 30 17:14:11 <alexhiam> cool
May 30 17:14:17 <alexhiam> so you'll be able to test soon
May 30 17:14:36 <alexhiam> kiran4399: wait, so what are the changes you've made to the mpu9150 driver?
May 30 17:14:40 <kiran4399> alexhiam: I hope it is working.. because I don't think it is available in india..
May 30 17:14:49 <kiran4399> alexhiam: step-1:
May 30 17:22:26 <kiran4399> i removed all unnecessary code which was ment for other mpu devices..
May 30 17:22:49 <kiran4399> alexhiam: step-2: added some header files in the /include/linux directory.
May 30 17:25:28 <alexhiam> kiran4399: I don't think any of the code was unnecessary... the driver was just made to support multiple mpu devices
May 30 17:26:37 <alexhiam> you should be replacing the current mpu6050 driver with the newer one that supports more devices, you don't want to pull it apart to make a whole separate driver for just one device
May 30 17:27:23 <alexhiam> it also isn't going to do much without the spi and i2c files...
May 30 17:29:14 <alexhiam> I think you basically just want to add that driver as you found it to linux/drivers/iio/imu/inv_mpu9150
May 30 17:30:05 <alexhiam> also, the current driver claims to support the 9150 already... https://github.com/beagleboard/linux/blob/4.4/drivers/iio/imu/inv_mpu6050/Kconfig#L16
May 30 17:30:37 <alexhiam> which seems odd since it doesn't seem to have any of the AKM89xx stuff there...
May 30 17:34:55 <alexhiam> ok, yeah, looks like the current driver can read the accel and gyro of the 9150 just fine, which makes since because that's just reading fromthe internel mpu6050. What that new driver adds is the control of the internal I2C master controller to access the magnetometer
May 30 17:39:04 <alexhiam> there's also this driver https://github.com/NoelMacwan/Kernel-10.4.1.B.0.101/tree/master/drivers/staging/iio/imu/inv_mpu
May 30 17:40:38 <alexhiam> seems like either Invensense wrote a bunch of different drivers for the same thing in 2012, or more likely multiple people have updated them separately for the same reason without updating any of the file headers :(
May 30 17:41:46 <alexhiam> this one seems different too http://lkml.iu.edu/hypermail/linux/kernel/1604.2/02970.html
May 30 17:47:09 <kiran4399_> alexhiam: there?
May 30 17:47:27 <kiran4399_> I am sorry.. I was in lab then.. got to my room..
May 30 17:47:35 <kiran4399_> alexhiam: got to my room..
May 30 17:47:46 <kiran4399_> so.. I got the earlier messages..
May 30 17:51:36 <nerdboy> yay, too many versions...
May 30 17:51:54 <nerdboy> kinda like arm device trees...
May 30 17:52:22 <kiran4399_> alexhiam: what do you think of this?
May 30 17:52:25 <kiran4399_> https://github.com/kiran4399/inv_mpu9150
May 30 18:06:11 <alexhiam> kiran4399_: I don't think the changes you made make sense, seems like it was ready to go then you removed a bunch of stuff..
May 30 18:06:26 <alexhiam> am I missing something?
May 30 18:07:10 <kiran4399_> alexhiam: https://github.com/kiran4399/inv_mpu9150/blob/master/inv_mpu_core.c#L174
May 30 18:07:25 <kiran4399_> things like these are already there right?? So what is the use of the i2c and spi files?
May 30 18:09:06 <alexhiam> wait, were they not there to begin with?
May 30 18:09:16 <alexhiam> you added them later https://github.com/kiran4399/inv_mpu9150/commit/6eb38fbaea926581e53fd3f3fcff4d26d7bde7cc
May 30 18:09:20 <alexhiam> then removed them again?
May 30 18:09:30 <kiran4399_> yeah..
May 30 18:09:34 <kiran4399_> alexhiam: you are right..
May 30 18:09:49 <kiran4399_> I thought I did not them..
May 30 18:10:23 <kiran4399_> alexhiam: ok..ok..
May 30 18:10:28 <kiran4399_> there is some confusion here.
May 30 18:10:31 <alexhiam> as an aside, you gotta be more clear with you commit messages/ that commit ^ added and removed multiple files, and the message "kernel files updated" doesn't describe it at all
May 30 18:10:50 <kiran4399_> alexhiam: yeah.. got it.. will be more clearn.
May 30 18:11:00 <alexhiam> where's the original files?
May 30 18:11:04 <kiran4399_> alexhiam: those i2c and spi files did not come with the mpu 9150 kernel drivers..
May 30 18:11:11 <alexhiam> yeah, I see that now
May 30 18:11:11 <kiran4399_> alexhiam: I actually took them from this:
May 30 18:11:59 <kiran4399_> https://github.com/beagleboard/linux/tree/4.4/drivers/iio/imu/inv_mpu6050
May 30 18:12:32 <kiran4399_> alexhiam: I actually removed some files which are for mpu 3050 and 6050..
May 30 18:13:08 <alexhiam> that I don't like, the point of this driver is that it supports the whole family of mpu parts
May 30 18:14:04 <alexhiam> I'd like to see you stick what's there on a separate branch, then go back to the original mpu9150 driver as you found it
May 30 18:14:11 <kiran4399_> alexhiam: yeah.. for example I removed this: https://android.googlesource.com/kernel/msm/+/android-msm-hammerhead-3.4-kk-fr2/drivers/staging/iio/imu/inv_mpu/inv_slave_bma250.c
May 30 18:14:16 <alexhiam> start with that for testing, and only make changes if things aren't working
May 30 18:14:36 <kiran4399_> even this.. i removed: https://android.googlesource.com/kernel/msm/+/android-msm-hammerhead-3.4-kk-fr2/drivers/staging/iio/imu/inv_mpu/inv_slave_pressure.c]
May 30 18:14:48 <kiran4399_> alexhiam: ok.. gotcha..
May 30 18:15:41 <kiran4399_> alexhiam: wait.. separate branch?
May 30 18:16:23 <alexhiam> yeah, you could just stash the changes you've made on another branch
May 30 18:17:38 <alexhiam> or perhaps make a new repo called inv_mpu, since that's what the driver was originally called
May 30 18:18:50 <alexhiam> oh interesting, that android tree gives some hints about the origin of that driver: https://android.googlesource.com/kernel/msm/+/269e618f72863849dacfd1c3e4b039f3d9750094
May 30 18:22:22 <kiran4399_> alexhiam: so you want to keep all the original files of the android inv_mpu driver and put the changes and modified stuff on another branch?
May 30 18:23:09 <alexhiam> whatever you want to do. Though I guess I would prefer a new repo called inv_mpu
May 30 18:36:58 <kiran4399_> alexhiam: there?
May 30 18:47:56 <chanakya-vc> hey Wormo are you there?
May 30 18:48:04 <Wormo> hi chanakya-vc
May 30 18:48:27 <chanakya-vc> Wormo, need some help with the firmware code for PRU
May 30 18:49:09 <Wormo> what's the question?
May 30 18:50:13 <chanakya-vc> Wormo, I am setting the P8_11 as the MOSI and want to set it as 1 or 0 according to the data.To do that the 15th bit on r30 register has to be changed.
May 30 18:50:41 <chanakya-vc> Wormo, So is there some direct way of access to this register?
May 30 18:51:07 <chanakya-vc> Wormo, Or I have to use a bit mask?
May 30 18:52:45 <chanakya-vc> Wormo,please refer to the first example given here:http://processors.wiki.ti.com/index.php/PRU_Training:_Hands-on_Labs
May 30 18:53:31 <Wormo> ok taking a look
May 30 18:53:37 <chanakya-vc> Here to toggle the led's they have used a bit mask.
May 30 18:54:04 <chanakya-vc> The C firmware code
May 30 18:54:30 <Wormo> ok so what do you mean as direct vs bit mask?
May 30 18:54:47 <Wormo> do you mean being able to set just one bit without reading out first?
May 30 18:55:12 <chanakya-vc> I mean direct memory access to that 1 bit
May 30 18:55:18 <chanakya-vc> Wormo, ^6
May 30 18:55:22 <chanakya-vc> *^
May 30 18:56:01 <chanakya-vc> Like a pointer to a memory address and then I could simply say *i=0 or 1 depending on the data.Is this possible?
May 30 18:56:06 <Wormo> there are some devices that have separate register for seting bits and another to clear bits, but I don't remember seeing
May 30 18:56:22 <Wormo> such a register for PRU
May 30 18:57:02 <Wormo> I could look, but I suspect the example would have used it if seperate set/clear registers were available
May 30 18:57:32 <chanakya-vc> So the way given there is the only way to go about for changing the value of the GPO'S is the way there?By using bitwise operators.
May 30 18:57:44 <Wormo> that is the normal method
May 30 18:58:04 <chanakya-vc> Wormo, Okay. I am new to all this :P
May 30 18:58:33 <chanakya-vc> So don't really know about this.Thanks!
May 30 18:58:58 <Wormo> I can look at the register set, or maybe somebody who wrote PRU code already could answer
May 30 18:59:38 <Wormo> what you're asking for is not all that unusual for GPIO registers, but I mostly see it in fancier cpus
May 30 18:59:44 <Wormo> have seen it
May 30 18:59:57 <chanakya-vc> Wormo, Wait. alexhiam gave me this link for the  PRU-ICSS Guide:http://elinux.org/Ti_AM33XX_PRUSSv2#Resources
May 30 19:00:52 <chanakya-vc> It has all the register stuff in it.There is only one configure register per PRU as far I have I have understood it.
May 30 19:02:04 <chanakya-vc> r30 is for output and r31 is for input in my understanding.
May 30 19:02:42 <chanakya-vc> Wormo, But then again I am not sure
May 30 19:03:52 <alexhiam> chanakya-vc: that's right
May 30 19:05:34 <chanakya-vc> Hey alexhiam !I been working on the firmware code. Have some questions.
May 30 19:05:54 <alexhiam> another good resource: http://processors.wiki.ti.com/index.php/Programmable_Realtime_Unit#General_Purpose_Inputs_.28R31.29
May 30 19:06:08 <alexhiam> that whole page, that is
May 30 19:06:30 <Wormo> It looks like since PRU is used so much for bitbanging, there is way to set/clear bits
May 30 19:07:02 <chanakya-vc> alexhiam, First I looked through the document that you gave me earlier.I could not figure out which bit do I have to set 0 or 1 in cfg register to declare a pin as input.
May 30 19:07:32 <Wormo> http://processors.wiki.ti.com/index.php/PRU_Assembly_Instructions#Set_Bit_.28SET.29
May 30 19:07:36 <alexhiam> chanakya-vc: they're not GPIO pins, there's separate banks of GPIs and GPOs
May 30 19:07:55 <Wormo> http://processors.wiki.ti.com/index.php/PRU_Assembly_Instructions#Clear_Bit_.28CLR.29
May 30 19:08:59 <alexhiam> oh right, it does have those instructions. though in C it's just the regular bitwise stuff
May 30 19:09:25 <chanakya-vc> But the instructions won't work in c right?
May 30 19:09:30 <chanakya-vc> Like my code?
May 30 19:09:32 <Wormo> right, what alexhiam said
May 30 19:09:36 <alexhiam> chanakya-vc: the R31 register maps to the inputs
May 30 19:09:49 <Wormo> it's separate instructions not separate registers
May 30 19:10:04 <Wormo> so the C compiler gets to use them to implement your code efficiently
May 30 19:10:41 <chanakya-vc> alexhiam, So I just look at what pins the r31 maps to and declare one of those as input
May 30 19:11:00 <alexhiam> no declaring it, you just use it
May 30 19:11:40 <chanakya-vc> alexhiam, But I saw a lot of parameters for output in the cfg register.Nothing for input.
May 30 19:11:52 <chanakya-vc> Okay got it
May 30 19:12:54 <chanakya-vc> Wormo, alexhiam So the only way to write data would be to use the bitmask right?
May 30 19:13:00 <alexhiam> using a bitwise & to check the bit(s) you care about
May 30 19:13:01 <Wormo> yes
May 30 19:13:20 <Wormo> that's read data, you mean?
May 30 19:13:30 <Wormo> you were just talkig about inputs...
May 30 19:14:11 <chanakya-vc> Wormo, No MOSI. Yes I was because I wasn't able to figure out how I will declare MISO
May 30 19:14:32 <Wormo> ok two separate questions then
May 30 19:14:41 <chanakya-vc> Yes
May 30 19:15:30 <Wormo> bitmasks do come into play for both though in and out though
May 30 19:16:51 <alexhiam> chanakya-vc: note that you could make it simpler by directly writing exactly the value you want to __R30, but the point of doing things like `|=` and `&= ~` is to only change particular bits without having any side effects
May 30 19:17:07 <chanakya-vc> alexhiam,Wormo  Last doubt on the work I have done so far:In the example that I just asked you to look at,they declare a register by just using volatile register uint32_t _R30
May 30 19:17:46 <chanakya-vc> So is _R30 a reserved keyword?
May 30 19:18:04 <alexhiam> right, so in some header file somewhere else there's probably an `extern volatile register uint32_t _R30` declaration
May 30 19:18:40 <alexhiam> not sure why they did it that way though
May 30 19:19:18 <chanakya-vc> Okay alexhiam Got it. I am going to pushing a very preliminary code for SPI by tomorrow noon my time
May 30 19:19:26 <alexhiam> awesome
May 30 19:19:52 <chanakya-vc> Yes it took a lot more effort than I thought it would
May 30 19:19:55 <chanakya-vc> alexhiam, ^^
May 30 19:20:05 <alexhiam> that'll happen
May 30 19:20:39 <chanakya-vc> I am going to be adding features after I get the basic MOSI,MISO and Clk right.Then give Slave select.
May 30 19:21:32 <alexhiam> kiran4399: I see you've reverted back to the original inv_mpu driver. A good goal for before you finish off this weeks report would be to get a kernel built with that and the pressure sensor driver using bb-kernel
May 30 19:26:53 * alexhiam goes afk
May 30 19:28:11 <chanakya-vc> Wormo, In C can I declare integer as binary numbers? Like int bi=0b1111 ?
May 30 19:28:46 <Wormo> no as hex 0xf
May 30 19:30:20 <chanakya-vc> Okay so binary.Actually since I have not written the driver,I wanted to test my code by giving a binary number and then bitbanging from left it and left shifting as it would happen in a SPI shift register
May 30 19:30:34 <chanakya-vc> Wormo, ^^
May 30 19:30:56 <Wormo> you'll have to use hex instead
May 30 19:31:23 <chanakya-vc> Okay Wormo Got it
May 30 20:13:15 <chanakya-vc> Hey ZeekHuge ,Are you there?
May 30 21:04:11 <chanakya-vc> Wormo, Are you there?
May 30 21:04:29 <chanakya-vc> Take a look:https://github.com/chanakya-vc/PRU-I2C_SPI_master/blob/wip_on_spi/pru0_spi.c
May 30 21:05:42 <chanakya-vc> It's not very neat though.I have stilll work a lot o it
May 30 21:07:17 <Wormo> I wouldn't use _MOSI for your own var, it's more for things you're pulling in like _R30
May 30 21:08:35 <chanakya-vc> Should I change the name?Wormo?
May 30 21:08:42 <chanakya-vc> I do need a local variable
May 30 21:09:02 <Wormo> yes a normal local var name would be more like 'mosi'
May 30 21:09:26 <chanakya-vc> Okay will change it. Otherwise how is it
May 30 21:09:46 <chanakya-vc> It took me more time to push it to Git than to write the actual code :P
May 30 21:09:52 <chanakya-vc> Worm^^
May 30 21:10:07 <chanakya-vc> Wormo, ^^
May 30 21:10:18 <Wormo> It would be a good idea to make it so you can test with prints on your dev computer
May 30 21:10:31 <Wormo> for quicker debugging
May 30 21:11:01 <Wormo> e.g. make a '#define TEST 1' and then '#ifdef TEST' stuff
May 30 21:12:00 <Wormo> when TEST is defined, use printfs to look at what you would be writing to reg
May 30 21:12:48 <Wormo> (your logic doesn't look quite correct yet, running in test mode should show it)
May 30 21:13:20 <Wormo> use normal gcc with 'CFLAGS=-DTEST' to build for host
May 30 21:27:22 <jic23> Quick drive by comment (reading logs).
May 30 21:27:46 <chanakya-vc> hey jic23 !
May 30 21:27:49 <Wormo> also chanakya-vc shouldn't it be __R30 ?
May 30 21:28:16 <chanakya-vc> double underscore?
May 30 21:28:30 <chanakya-vc> Wormo, I might have overlooked that
May 30 21:28:46 <chanakya-vc> It is a bit difficult to work with git in the terminal
May 30 21:29:15 <chanakya-vc> Wormo, Do you prefer the desktop version or the command line version?
May 30 21:29:23 <Wormo> command line
May 30 21:29:29 <Wormo> you'll get used to it
May 30 21:31:35 <chanakya-vc> I can't seem to remember all the commands at the moment.Like I have made some changes to my source file and to push it now I just say git push origin <branch name>?
May 30 21:31:42 <chanakya-vc> Wormo, ^^
May 30 21:31:59 <Wormo> it's a sequence of steps: add, commit, push
May 30 21:31:59 <jic23> Alexhiam and kiran4399 Inc mph driver in mainline is getting a lot of attention at the moment including support for slave devices done as properly as possible.  If you get time before I can send more details take a look at linux-iio archive.  Those slave busses are complex beasts!  Current approach is likely to merge soon, just waiting for additional review including from Ge at invensense.  Got to run.
May 30 21:32:33 <jic23> Bye chanakya-vc and all!
May 30 21:33:22 <chanakya-vc> jic23, Bye!
May 30 21:33:29 <chanakya-vc> Wormo, So git add . ?
May 30 21:33:48 <Wormo> 'git add -u .'
May 30 21:34:13 <Wormo> -u means get the files that have been previously committed and now updated
May 30 21:34:41 <chanakya-vc> Ohh
May 30 21:34:43 <Wormo> as opposed to any temp files you might have lying around but never committed, -u won't add those
May 30 21:35:39 <Wormo> then I like 'git commit -v' where -v is verbose to view what you're committing while composing the log message
May 30 21:36:25 <Wormo> finally 'git push origin HEAD' will get the branch you're working on back up to the server
May 30 21:36:59 <chanakya-vc> Okay got it.Have changed the variable name.Will work on the other stuff you told
May 30 21:37:42 <chanakya-vc> Wormo, Last thing this is wip branch.How do I add the stuff to the master when I am done?
May 30 21:38:27 <chanakya-vc> So locally I would have to copy to the master,change my head variable to point to the master?
May 30 21:38:34 <Wormo> at that point you check out the branch you're trying to change
May 30 21:38:41 <Wormo> 'git checkout master'
May 30 21:38:52 <Wormo> and you merge in the branch with new stuff
May 30 21:39:16 <Wormo> 'git merge wip_on_spi'
May 30 21:39:48 <chanakya-vc> wip merge with master..Okay got that.But then there when I would add I wouldn't say git add -u right?
May 30 21:39:57 <chanakya-vc> Wormo, ^^
May 30 21:40:21 <Wormo> you would not need 'add' when merging existing commits from another branch
May 30 21:40:37 <Wormo> purpose of 'add' is to pick out which things will be part of next commit
May 30 21:41:02 <chanakya-vc> Okay got it..Thanks Wormo
May 30 21:41:13 <Wormo> yw
**** ENDING LOGGING AT Tue May 31 02:59:58 2016